제3부: GPU 라이브러리 지원 - 파인튜닝 (Finetuning)

제3부: GPU 라이브러리 지원 - 파인튜닝 (Finetuning)

여기가 바로 우리 모두가 관심을 가지고 있으며, 수치로부터 멀어지는 지점입니다... 여기서 여러분이 무엇을 할 수 있고 할 수 없는지에 대해 짧게 언급하겠습니다. 왜냐하면 아래의 지표가 이미 모든 것을 요약하고 있기 때문입니다.

파인튜닝 (Finetuning) 과정에서 LoRA를 사용하여 모델을 파인튜닝할 때, 모델 파라미터의 0.5% - 1% 사이를 파인튜닝하고 이를 4096 컨텍스트 길이 (context length)로 수행하고자 할 때, 배치 사이즈 (batch size)와 같은 값들을 최솟값으로 설정하더라도 BF16 기준으로 모델 파라미터의 약 2.5-3.5배에 해당하는 GB 용량이 VRAM을 차지하게 됩니다.

예를 들어:

• Qwen3.5-14B는 BF16 파인튜닝 (finetuning) 시 VRAM에서 거의 50-60GB 정도를 차지하며, 여기에 체크포인트 (checkpoint)를 추가하면 빈도에 따라 55-70GB 사이로 변동됩니다. 바로 이 지점에서 양자화 (quantization)를 통한 파인튜닝이 등장합니다; bitsandbytes... 따라서 35B와 같은 모델을 AMD 및 MLX에서 효과적이고 건강하게 학습시키는 것은 매우 매우 어렵다고 말할 수 있습니다.
• 또한, 만약 transformers를 사용하여 학습을 시키고 싶다면 PyTorch, PEFT, TRL 등이 없습니다. 이를 적응시키려 해도 매우 어렵습니다.
• 파인튜닝 (Finetune)을 시작하면 FlashAttention과 같은 가속기들도 AMD 및 MLX에서는 여전히 안정적이지 않습니다...
  가장 중요한 멀티 노드 (Multi-node)! 애초에 VRAM을 신경 쓰지 않았다면 이러한 장치들을 구매하지 않았을 것입니다. 만약 구매했다 하더라도 반드시 더 많은 용량이 필요하게 될 것입니다. 그 시점에는 더 이상 이더넷 (ethernet)이나 RDMA 체이닝이 아니라, 텐서 병렬성 (tensor parallelism)이나 DDP와 같은 분산 RAM 사용을 원하게 될 것입니다.

바로 여기서 한계가 드러납니다... 왜냐하면 600GB 대역폭 (bandwidth)을 가진 M 칩들이 80GB Thunderbolt에 연결되고, AMD는 10GB 이더넷에 연결되기 때문입니다...

Nvidia는 여기서 제가 가장 선호하는 이유이기도 한 QSFP56를 사용하여 200Gbps를 사용하며, 이는 매우 가치 있는 부분입니다. 대역폭 (bandwidth)에 매우 근접하기 때문에 병목 현상 없이 DDP를 통해 추론 (inference)과 안정적인 파인튜닝 (finetuning)을 수행할 수 있는 기회를 제공하기 때문입니다.