LLM 파인튜닝 프레임워크 4종 비교 — Unsloth vs Axolotl vs TRL vs LLaMA-Factory (속도·VRAM·멀티 GPU)
대규모 언어 모델(LLM)을 우리 데이터에 맞게 다시 학습시키는 파인튜닝 작업을 할 때, 어떤 오픈소스 도구를 골라야 할까요? 이 글은 실무에서 가장 많이 쓰는 네 가지 프레임워크를 학습 속도, GPU 메모리(VRAM), 멀티 GPU 확장성 세 가지 기준으로 솔직하게 비교합니다.
1. 한 줄 요약 — 네 도구의 차이
네 프레임워크는 모두 PyTorch와 Hugging Face 생태계 위에서 동작합니다. 차이는 "어디에 공을 들이느냐"입니다.
- Unsloth — GPU 커널(저수준 연산 코드)을 직접 다시 작성해 속도와 메모리를 극단적으로 최적화
- Axolotl — 다양한 병렬화 전략(데이터·텐서·시퀀스)을 자유롭게 조합
- TRL — 다른 도구들이 내부적으로 호출하는 기준 트레이너 라이브러리
- LLaMA-Factory — 100개 이상 모델 지원 + 코드 없이 클릭으로 조작하는 Gradio UI
쉽게 말하면: Unsloth = 가성비 1등, Axolotl = 연구용 무한 확장, TRL = 모든 것의 토대, LLaMA-Factory = 클릭 한 번에 시작.
2. 핵심 용어 10개 먼저 정리
비교 내용을 이해하기 위해 자주 등장하는 용어를 먼저 정리했습니다. 한 번 훑고 가시면 글의 모든 숫자가 자연스럽게 읽힙니다.
3. Unsloth · Axolotl · TRL · LLaMA-Factory는 무엇이 다른가
TRL — 기준 구현 계층
SFTTrainer, DPOTrainer, GRPOTrainer, KTOTrainer, RewardTrainer, RLOOTrainer 같은 트레이너 클래스를 제공합니다. Axolotl과 LLaMA-Factory는 내부적으로 결국 TRL을 호출합니다. 즉 TRL은 다른 도구의 토대입니다.
Unsloth — 커널을 직접 다시 작성
일부 모델링 코드를 Triton 커널(GPU용 저수준 연산 코드)로 교체합니다. 역전파(오차를 뒤로 전파해 가중치를 갱신하는 과정)도 자동 미분(연쇄법칙을 자동으로 계산해주는 메커니즘)으로 생성하지 않고 직접 유도합니다. Hugging Face 공식 문서에 따르면 근사 없이 표준 QLoRA 대비 정확도 손실이 0%라고 합니다.
Axolotl — 병렬화 조합의 달인
Transformers, PEFT, TRL, Accelerate, DeepSpeed를 감싸는 YAML 기반 래퍼입니다. 핵심 차별점은 "커널 개발이 아니라 어떤 병렬화 전략을 어떤 조합으로 쓰느냐"입니다.
LLaMA-Factory — 클릭으로 시작, 100종 모델 지원
ACL 2024 시스템 시연 논문으로 소개된 프로젝트입니다. Gradio 기반 LlamaBoard 웹 UI를 제공하며, 저장소는 100개가 넘는 LLM과 VLM(비전-언어 모델)을 지원합니다. 코드를 한 줄도 안 짜고 파인튜닝을 시작할 수 있습니다.
4. 속도 비교 — 단일 GPU에서 누가 가장 빠른가
핵심 결론: 단일 GPU 기준 속도 왕좌는 Unsloth가 가져갑니다. 다만 모델 종류와 시퀀스 길이에 따라 격차가 크게 달라집니다.
Unsloth의 단일 GPU 우위
- Llama 3.1 8B와 Llama 3.3 70B QLoRA 학습에서 약 2배 속도 (Alpaca 데이터셋, 배치 2, 그래디언트 누적 4, 랭크 32)
- MoE 모델에서는 차이가 더 벌어집니다. B200 GPU에서 unsloth/gpt-oss-20b를 8K 컨텍스트로 학습할 때 스텝당 712ms vs Transformers v5는 5,226ms로 7.3배 차이
- 반대로 Qwen3-30B-A3B는 1K에서 1.7배였다가 16K에서는 1.1배로 효과가 줄어듭니다. 장점의 크기는 모델에 따라 다릅니다.
- AMD GPU와의 공동 테스트에서는 Llama-3.1-8B LoRA SFT가 스텝당 2.07초로, TRL + FlashAttention-2 조합(2.87초) 대비 1.39배 빠르면서 손실 곡선은 동일했습니다.
Axolotl — 커널은 빌려오고 병렬화는 기본 제공
2025년 2월 Unsloth에서 영감을 받아 LoRA용 Triton 커널을 추가했습니다. lora_mlp_kernel, lora_qkv_kernel, lora_o_kernel으로 선택적으로 켤 수 있습니다. 최근에는 SonicMoE LoRA 지원이 추가돼 grouped_mm 기준 대비 최대 1.45배 속도, 30% 메모리 절감(단일 H100 SXM, Qwen3.5-35B-A3B 8비트 LoRA)을 보고합니다.
TRL — 모두가 비교 기준으로 삼는 베이스라인
단일 GPU의 "절대 1등"이라기보다는 "비교 기준점" 역할을 합니다. 대신 패킹(여러 짧은 문장을 하나의 시퀀스로 묶는 기법), 패딩 없는 배치(빈 토큰 채우기 없이 배치 구성), 잘라내기, Liger Kernel, GRPO용 vLLM 절전 모드 같은 다양한 메모리·속도 조절 도구를 폭넓게 제공합니다. TRL은 공식 Unsloth 통합 기능을 제공하므로 두 도구는 양자택일이 아닙니다.
LLaMA-Factory — 위임을 통한 속도 향상
자체 커널은 작성하지 않습니다. 대신 설정 플래그 하나로 다른 프로젝트의 기술을 가져다 씁니다.
- use_unsloth: true → Unsloth 패치 활성화 (프로젝트 변경 이력 기준 상대 속도 170%)
- enable_liger_kernel: true → Liger Kernel 사용
- flash_attn: fa2 → FlashAttention-2 사용
5. VRAM 비교 — 메모리는 누가 가장 적게 쓰는가
보고된 최소 메모리
| 모델 크기 | 4비트 QLoRA | 16비트 LoRA | 전체 bf16 파인튜닝 |
|---|---|---|---|
| 7~8B | 6 GB | 22 GB | 약 60 GB |
| 30B | 24 GB | 약 80 GB | 약 240 GB |
| 70B | 41~48 GB | 164 GB | 600 GB |
더 중요한 지표: 주어진 VRAM에서 최대 컨텍스트 길이
같은 8GB GPU에서 Llama 3.1 8B QLoRA(랭크 32, 배치 1)를 돌릴 때:
| GPU VRAM | Unsloth 컨텍스트 | Transformers + FA2 |
|---|---|---|
| 8 GB | 2,972 토큰 | 메모리 부족(OOM) |
| 16 GB | 40,724 토큰 | 2,551 토큰 |
| 24 GB | 78,475 토큰 | 5,789 토큰 |
| 48 GB | 191,728 토큰 | 15,502 토큰 |
| 80 GB | 342,733 토큰 | 28,454 토큰 |
Unsloth는 이 결과를 자체 그래디언트 체크포인팅 알고리즘과 Apple의 Cut Cross Entropy 조합 덕분이라고 설명합니다. 80GB A100에서 Llama 3.3 70B를 돌릴 때는 89,389 토큰까지 가능했고, FlashAttention-2 베이스라인은 6,916 토큰에 그쳤습니다.
2026년 가장 크게 바뀐 영역: MoE 메모리
MoE 모델 학습에서 메모리 절감 효과가 가장 큽니다.
- Unsloth는 gpt-oss-20b를 12.8 GB로 파인튜닝 가능 (B200 8K 컨텍스트 47.43 GB vs Transformers v5 73.80 GB)
- Axolotl의 quantize_moe_experts: true 옵션은 GLM-4.7-Flash QLoRA의 예약 메모리를 약 127 GiB → 약 23 GiB로 줄여줍니다.
6. 멀티 GPU 비교 — 여러 장치로 확장할 때
순위가 뒤집히는 구간입니다. Unsloth가 단일 GPU에서 보인 우위는 멀티 GPU로 그대로 이어지지 않습니다.
| 비교 항목 | Unsloth | Axolotl | TRL | LLaMA-Factory |
|---|---|---|---|---|
| 문서화된 병렬화 폭 | 약함 | 가장 넓음 | 두 가지 시퀀스 분할 | 표준 + Megatron |
| 추천 셔딩 전략 | Accelerate / DeepSpeed | FSDP2 (FSDP1 비권장) | FSDP2 (Ring Attention) | FSDP2 + Megatron |
| TP / CP / EP 조합 | 미지원 | DeviceMesh로 폭넓게 조합 | Ring Attention·Ulysses 둘 다 | DeepSpeed AutoTP |
| 멀티 노드 학습 | 가능하나 수동 | torchrun · Ray | torchrun | FSDP2 + Ray |
| UX 편의성 | 단순 | 난이도 높음 | 중간 | 단일 노드 매우 쉬움 |
| 총평 | 단일 GPU 강자 | 확장성 1등 | 유연한 분산 | 다재다능 |
Axolotl의 시퀀스 병렬화 트레이드오프
시퀀스 길이는 거의 선형으로 늘어지만, GPU 4개 이상부터 처리량 효율이 급격히 떨어집니다. 공개된 H100 Llama 3.1 8B QLoRA 벤치마크:
| SP 차수 | 최대 컨텍스트 | 컨텍스트 확장 배율 | 초당 토큰 | 속도 효율 |
|---|---|---|---|---|
| 1 | 17,408 | 1.00배 | 9,104 | 100.0% |
| 2 | 34,816 | 2.00배 | 15,806 | 86.8% |
| 4 | 66,560 | 3.82배 | 12,314 | 33.8% |
| 8 | 129,024 | 7.41배 | 11,096 | 15.2% |
컨텍스트는 거의 선형으로 확장되지만 처리량 효율은 4개를 넘는 순간 급격히 무너집니다. 4090 GPU 8장 SP-8 구성에서는 오히려 속도가 0.88배로 떨어진 사례도 보고됐습니다.
TRL의 두 가지 시퀀스 분할 백엔드
- Ring Attention (CP) — FSDP2 위에서 동작. Accelerate 1.11.0 이상 필요. 100만 토큰 이상 시퀀스에 적합. 현재는 SDPA만 지원.
- ALST / Ulysses (SP) — DeepSpeed 위에서 동작. FlashAttention-2 호환. NVLink·InfiniBand 환경, 약 50만 토큰 이하에 적합. num_heads ≥ sp_size 제약.
LLaMA-Factory — 가장 저렴한 70B 학습 경로
FSDP + QLoRA 경로를 쓰면 24GB GPU 두 장으로 70B 모델을 파인튜닝할 수 있습니다. 비교 대상 중 가장 저렴하게 70B를 학습시키는 공식 문서화된 방법입니다. 다만 분산 설정은 LlamaBoard UI가 아니라 YAML과 CLI에서만 다룰 수 있어, 멀티 GPU로 확장하는 순간 UI 편의성을 잃습니다.
7. 각 도구가 약해지는 지점
8. 어떤 상황에 어떤 도구를 고를까
| 사용 상황 | 추천 프레임워크 | 이유 |
|---|---|---|
| 소비자용 GPU 1장 + LoRA/QLoRA | Unsloth | 컨텍스트 길이 여유가 압도적 |
| GPU 2~8장 + 긴 컨텍스트 + 전체 파인튜닝 | Axolotl | FSDP2 + 시퀀스 병렬화가 가장 잘 문서화됨 |
| RLHF 파이프라인 | Axolotl | 문서화된 GRPO·DPO 경로 |
| 커스텀 학습 루프, 새로운 사후 학습 알고리즘 개발 | TRL | Hugging Face와 가장 밀착된 기반 계층 |
| 비엔지니어가 가장 빠르게 시작 | LLaMA-Factory | LlamaBoard 무코드 UI |
| 폭넓은 모델 지원 + 빠른 첫 실행 | LLaMA-Factory | 100+ 모델 + Megatron 백엔드 옵션 |
이 선택들은 상호 배타적이지 않습니다. LLaMA-Factory는 Unsloth를 백엔드로 실행할 수 있고, TRL은 Unsloth 통합 기능을 제공하며, Axolotl은 내부에서 TRL 트레이너를 호출합니다. 한 가지만 고르기보다 상황에 맞게 겹쳐 쓰는 게 현실적입니다.
9. 자주 묻는 질문(FAQ)
Q1. GPU 한 장에 8GB만 있는데 7B 모델을 파인튜닝할 수 있나요?
예. 4비트 QLoRA를 쓰면 7~8B 모델은 6GB VRAM에서 동작합니다. Unsloth가 가장 친화적이며, 8GB에서도 약 3,000 토큰 컨텍스트까지 학습할 수 있습니다.
Q2. 70B 모델을 가장 저렴하게 학습시키려면?
LLaMA-Factory의 FSDP + QLoRA 경로를 쓰면 24GB GPU 두 장으로 70B 파인튜닝이 가능합니다. 단, 분산 설정은 YAML/CLI로 직접 해야 합니다.
Q3. MoE 모델(Qwen3-30B-A3B, gpt-oss 등)은 어떤 도구가 유리한가요?
Unsloth와 Axolotl 모두 MoE에 강합니다. Unsloth는 연산 순서를 바꿔 LoRA 델타를 메모리에 펼치지 않고, Axolotl은 quantize_moe_experts 옵션으로 로딩 시 전문가 가중치를 양자화해 약 127 GiB → 23 GiB까지 메모리를 줄입니다.
Q4. RLHF(인간 피드백 강화학습)를 하려면?
TRL의 GRPO/DPOTrainer를 직접 쓰거나, Axolotl의 문서화된 RLHF 경로를 따르면 됩니다. LLaMA-Factory에서도 DPO·PPO·GRPO를 UI로 켤 수 있지만, 확장은 CLI에서 진행해야 합니다.
Q5. 코드를 한 줄도 안 쓰고 시작할 수 있나요?
LLaMA-Factory의 LlamaBoard(Gradio 웹 UI)로 가능합니다. 단일 노드라면 클릭만으로 LoRA·DPO·GRPO를 시작할 수 있습니다. 단 GPU 여러 장으로 확장할 때는 YAML로 옮겨야 합니다.
Q6. 네 가지 도구를 동시에 써도 되나요?
네, 가능합니다. LLaMA-Factory → Unsloth 백엔드, TRL → Unsloth 통합, Axolotl → 내부적으로 TRL 호출 구조입니다. 실제로 한 프로젝트가 여러 도구를 겹쳐 쓰는 경우는 흔합니다.
Q7. 긴 컨텍스트(예: 10만 토큰 이상) 학습에 가장 적합한 도구는?
단일 GPU라면 Unsloth의 그래디언트 체크포인팅 + Cut Cross Entropy 조합이 압도적입니다(80GB A100에서 Llama 3.3 70B 89,389 토큰). 멀티 GPU라면 Axolotl의 시퀀스 병렬화 또는 TRL의 Ring Attention(100만 토큰 이상)을 권장합니다.
핵심 요점 정리
- Unsloth는 단일 GPU 속도와 컨텍스트 길이에서 우세하지만, 멀티 GPU는 문서상 약점으로 남아 있습니다.
- Axolotl은 가장 폭넓은 병렬화 행렬을 제공합니다. FSDP2, DeepSpeed, TP, CP, EP를 DeviceMesh(여러 GPU의 연결 토폴로지를 정의하는 PyTorch 객체)로 자유 조합할 수 있습니다.
- TRL은 다른 프레임워크가 감싸 쓰는 기준 트레이너 계층이며, Ring Attention과 ALST/Ulysses 시퀀스 분할을 모두 제공합니다.
- LLaMA-Factory는 깊이 대신 폭을 택합니다. 100개 이상 모델, 무코드 UI, Megatron 백엔드를 지원하지만 분산 설정은 CLI에서만 다룰 수 있습니다.
- 시퀀스 병렬화는 컨텍스트를 거의 선형으로 확장하지만 GPU 4개를 넘으면 처리량 효율이 급격히 떨어집니다.