Llama 4 Scout 17B-16E-Instruct
Unsloth Dynamic GGUF 기준
Llama 4 Scout 로컬 실행 직접 해봤습니다 — RTX 3090도 막힌 이유
“단일 H100 GPU에서 돌아간다“는 Meta 공식 설명을 그대로 믿었다가 48GB VRAM 시스템이 통째로 막혔습니다. 실제로는 어떤 조건이 충족돼야 하는지, 국내에서 흔하게 접할 수 있는 RTX 기준으로 정리했습니다.
공식 발표와 실제 실행 결과 사이의 간극
Llama 4 Scout는 2025년 4월 5일 Meta가 공개한 오픈 웨이트 멀티모달 모델입니다. Meta 공식 블로그에는 “단일 NVIDIA H100 GPU에서 실행 가능”하다고 적혀 있습니다. (출처: Meta AI 공식 블로그, 2025.04.05) 여기까지만 읽으면 “H100 한 장이면 되는구나” 싶습니다. 막상 시도해 보면 다릅니다.
💡 공식 발표문과 실제 실행 환경을 같이 놓고 보면 이런 차이가 보였습니다 — “단일 H100″이라는 조건에는 Int4 양자화라는 전제가 붙어 있고, Int4 양자화 상태에서도 Scout의 VRAM 요구량은 약 55GB입니다. H100(80GB)에서는 겨우 들어가는 숫자입니다. RTX 3090(24GB) 두 장을 묶은 48GB 시스템에서 실행에 실패한 사례는 이 전제를 놓친 결과입니다.
실제로 RTX 3090 두 장(총 48GB VRAM)으로 Scout 원본 모델과 FP8 버전, GGUF IQ1_S 버전을 순서대로 시도한 테스트에서 모두 CUDA 메모리 부족 오류 또는 모델 로딩 실패가 발생했습니다. (출처: 알파의 보고서, 네이버 블로그, 2025.04.09) 48GB는 부족합니다.
Llama 4 Scout 구조 — MoE가 핵심인 이유
Scout의 전체 파라미터는 109B지만, 토큰 하나를 처리할 때 실제로 활성화되는 파라미터는 17B입니다. 16개의 전문가 중 하나만 선택해서 쓰는 MoE(Mixture of Experts) 방식 덕분입니다. (출처: Meta AI 공식 블로그, 2025.04.05) 활성 파라미터가 17B라는 건 성능 기준이고, 저장 공간과 VRAM은 전체 109B를 기준으로 잡아야 합니다. 이 두 숫자를 혼동하면 “17B짜리니까 가벼운 거 아닌가?”라는 오해가 생깁니다.
| 항목 | Dense 모델 (예: Llama 3) | MoE 모델 (Llama 4 Scout) |
|---|---|---|
| 추론 시 활성 파라미터 | 전체 파라미터 | 17B (전체의 약 16%) |
| 메모리에 올라가는 파라미터 | 전체 | 전체 109B |
| FP16 기준 VRAM | 파라미터 수 × 2GB | 약 218GB |
| Int4 양자화 기준 VRAM | – | 약 55GB |
출처: apxml.com Llama 4 Scout 스펙 페이지 / Meta AI 공식 블로그 (2025.04.05)
Int4로 양자화해도 55GB가 필요하다는 뜻은 VRAM 합산 48GB인 RTX 3090 두 장으로는 아슬아슬하게 모자라다는 뜻입니다. 숫자가 7GB 차이지만, 실행 불가로 직결됩니다.
양자화 수준별 VRAM 요구량 직접 확인
Scout의 전체 모델 파일 크기는 FP16 기준 약 218GB입니다. Unsloth가 공개한 동적 GGUF 방식으로 1.78비트까지 압축하면 33.8GB로 줄어듭니다. (출처: Unsloth 공식 문서, unsloth.ai) 디스크 용량이 33.8GB라고 해서 VRAM도 34GB면 된다는 뜻은 아닙니다. 실행 시 실제로 올라가는 레이어 구성에 따라 필요 VRAM이 달라집니다.
💡 Unsloth가 직접 측정한 수치를 보면, 1.78비트(IQ1_S) 버전은 24GB VRAM GPU 한 장에서 초당 약 20토큰 속도로 실행됩니다. (출처: Unsloth 공식 문서) RTX 3090이나 RTX 4090(둘 다 24GB) 한 장이면 된다는 의미입니다. 그런데 이게 가능한 이유는 Unsloth가 MoE 레이어를 선택적으로 양자화하고, 비전 레이어는 양자화하지 않는 동적 GGUF 방식을 썼기 때문입니다. 일반 GGUF로 시도하면 같은 비트수라도 결과가 다를 수 있습니다.
| 양자화 방식 | 파일 크기(디스크) | 실행 가능 GPU | 생성 속도(추정) |
|---|---|---|---|
| FP16 (원본) | 약 218GB | H100 × 3장 이상 | 빠름 |
| Int4 (공식 H100 조건) | 약 55GB | H100 × 1장 (80GB) | 중간 |
| IQ2_XXS (Unsloth) | 약 38GB | RTX 4090 × 1~2장 | 중간 |
| IQ1_S 1.78bit (Unsloth) | 33.8GB | RTX 3090/4090 × 1장 (24GB) | 약 20 tokens/sec |
출처: Unsloth 공식 문서 (unsloth.ai) / apxml.com Llama 4 Scout 스펙 페이지
RTX GPU에서 실제로 돌아가는 조건
Unsloth 공식 문서에서는 Scout 1.78비트 버전이 24GB VRAM 한 장에서 실행된다고 밝히고 있습니다. (출처: Unsloth 공식 문서, unsloth.ai) RTX 4090 또는 RTX 3090 단일 카드로 가능하다는 뜻입니다. 단, Unsloth 동적 GGUF를 Hugging Face에서 내려받아야 하고, 일반 Ollama 라이브러리 버전이나 표준 GGUF로는 같은 결과를 기대하기 어렵습니다.
Unsloth가 Scout를 양자화할 때 찾아낸 사실이 있습니다. 비전 레이어는 양자화하면 품질이 크게 떨어지기 때문에 원본 정밀도를 유지했고, MoE 라우터와 일부 레이어도 양자화 대상에서 제외했습니다. (출처: Unsloth 공식 문서) 이 판단이 24GB 한 장 실행을 가능하게 만든 핵심입니다. 단순 비트 수 축소가 아니라 레이어별로 다른 전략을 적용한 결과입니다.
💡 Ollama를 통해 Scout를 설치했다가 실패했다는 사례가 여럿 보입니다. 53GB짜리 GGUF를 다운로드했지만 VRAM 48GB(RTX 3090 × 2)에서 로딩 자체가 실패한 실측 사례가 있습니다. (출처: 알파의 보고서, 2025.04.09) 반면 Unsloth 버전은 24GB 한 장에서 돌아갑니다. 같은 Scout지만 어디서 받았느냐가 실행 가능 여부를 갈라놓습니다.
결론부터 말씀드리면, RTX 3090 또는 RTX 4090 한 장(24GB) 보유자는 Unsloth Llama-4-Scout-17B-16E-Instruct-GGUF IQ2_XXS 이상 버전을 Hugging Face에서 직접 받아 llama.cpp로 실행하는 경로가 현재 가장 안정적입니다.
MoE 레이어 CPU 오프로딩 — 이 방법이 다릅니다
Unsloth 공식 문서에는 llama.cpp 실행 시 특수한 옵션 하나가 소개됩니다.
-ot ".ffn_.*_exps.=CPU"
이 옵션은 Scout의 MoE 전문가 레이어(feed-forward expert layers) 전체를 GPU 대신 CPU RAM으로 오프로드하는 명령입니다. (출처: Unsloth 공식 문서, unsloth.ai) MoE 구조의 특성상, 실제 계산에 사용되는 전문가 레이어는 전체 레이어의 일부입니다. 나머지 어텐션 레이어와 핵심 레이어만 GPU에 올리고, 용량이 큰 전문가 레이어는 CPU RAM에서 처리하는 방식입니다.
💡 이 옵션 하나가 로컬 실행 가능 여부를 바꿉니다. GPU VRAM이 부족하더라도 시스템 RAM이 충분하면(32GB 이상 권장) MoE 레이어를 CPU에서 처리해 GPU 메모리 부담을 줄입니다. 속도는 느려지지만 실행 자체는 가능해집니다.
실제 실행 명령어 전체는 아래와 같습니다. (출처: Unsloth 공식 문서, unsloth.ai)
./llama.cpp/llama-cli \ --model [모델경로]/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf \ --threads 32 \ --ctx-size 16384 \ --n-gpu-layers 99 \ -ot ".ffn_.*_exps.=CPU" \ --temp 0.6 \ --min-p 0.01 \ --top-p 0.9
--n-gpu-layers 99는 가능한 레이어를 GPU에 최대한 올리되, MoE 전문가 레이어는 -ot 옵션이 CPU로 강제 지정하는 구조입니다. GPU가 아슬아슬하게 부족한 환경에서 레이어 수를 줄여가며 시도해 볼 수 있습니다.
API 경로와 로컬 실행, 어떤 상황에서 뭘 선택할까
RTX 3090도 없고 서버도 없는 상황이라면 API를 쓰는 편이 현실적입니다. Llama 4 Scout는 Together AI(`meta-llama/Llama-4-Scout`), Fireworks AI, Groq 등에서 API로 이용 가능합니다. (출처: knightk.tistory.com, 2026.03.21) 원본 모델 기준 품질을 경험하면서 양자화 손실 없이 쓸 수 있다는 장점이 있습니다.
로컬 실행이 유리한 경우는 두 가지입니다. 첫째, 개인정보나 사내 문서처럼 외부 서버에 보내기 어려운 데이터를 처리할 때입니다. 둘째, 사용량이 많아서 API 비용이 부담될 때입니다. Maverick 원본 모델을 클라우드에서 실행하면 2×H200(280GB VRAM) 환경 기준 시간당 약 $8.15(약 12,100원)이 발생합니다. (출처: 알파의 보고서, 2025.04.09) 하루 8시간 사용만으로 월 약 196만 원 수준입니다. 로컬 GPU 초기 투자 비용이 정당화되는 구간이 생깁니다.
| 비교 항목 | 로컬 실행 (RTX 4090 1장) | 클라우드 API |
|---|---|---|
| 초기 비용 | 약 200~250만 원 (GPU) | 없음 |
| 사용 중 비용 | 전기세 (미미) | 토큰당 과금 |
| 데이터 프라이버시 | 완전 로컬 | 외부 서버 전송 |
| 모델 품질 (Scout 기준) | 양자화 손실 있음 | 원본 품질 |
| 속도 | 약 20 tokens/sec | 서버 상태 의존 |
Maverick 모델은 이야기가 다릅니다. 1.78비트(IQ1_S) 양자화 버전도 RTX 4090 두 장(2×24GB)이 필요합니다. (출처: Unsloth 공식 문서, unsloth.ai) RTX 4090 단일 카드 환경에서는 Maverick 로컬 실행은 현실적으로 어렵고, Scout로 범위를 좁혀서 생각하는 편이 맞습니다.
Q&A
마치며
Llama 4 Scout를 로컬에서 돌리는 건 가능합니다. 하지만 가능한 경로와 불가능한 경로가 명확하게 나뉩니다. 요약하면 이렇습니다.
- Ollama 공식 버전이나 일반 GGUF → RTX 3090 두 장(48GB)에서도 실패
- Unsloth 동적 GGUF IQ2_XXS 이상 → RTX 4090 한 장(24GB)에서 성공
-ot ".ffn_.*_exps.=CPU"옵션 → GPU VRAM 여유분이 부족할 때 MoE 레이어를 CPU로 분리- Maverick 원본 품질, 데이터 외부 전송 불가 상황 → 클라우드 API
솔직히 말하면, “단일 H100에서 돌아간다”는 공식 설명이 일반 사용자 기준에선 오해를 부르기 딱 좋습니다. H100이 어떤 GPU인지 모르는 분들은 “고사양 GPU 한 장”으로 읽으니까요. 실제 문턱은 그보다 훨씬 높고, Unsloth의 동적 GGUF가 그 문턱을 상당히 낮춰줬습니다. 앞으로 더 최적화된 양자화 버전이 나오면 16GB VRAM 환경도 열릴 가능성이 있습니다.
📚 본 포스팅 참고 자료
- Meta AI 공식 블로그 — The Llama 4 herd: The beginning of a new era (ai.meta.com)
- Unsloth 공식 문서 — Llama 4: How to Run & Fine-tune (unsloth.ai)
- apxml.com — Llama 4 Scout Specifications and GPU VRAM Requirements (apxml.com)
- 알파의 보고서 — Llama 4 sLLM 로컬 실행 테스트 결과 (네이버 블로그, 2025.04.09)
※ 본 포스팅은 2026년 3월 29일 기준 공개된 정보를 바탕으로 작성되었습니다. Llama 4 Scout의 양자화 지원 범위, Unsloth GGUF 업데이트, llama.cpp 호환성 등은 향후 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으며, 최신 정보는 각 공식 문서에서 확인하시기 바랍니다.
댓글 남기기