Llama 4 Scout 로컬 실행 완전 분석 - 109B MoE, N100 16GB 벽 넘을 수 있나

안녕하세요!
이번 글은 Llama 4 Scout 로컬 실행 가능성을, N100 환경 기준으로 분석합니다.
16GB RAM 미니PC로 로컬 LLM을 굴리는 분, 또는 4월 5일 출시 직후 "내 환경에서 될까?" 고민 중인 분께 도움됩니다.

솔직히 Meta가 Llama 4 Scout 발표할 때, 첫 반응이 "109B? 어림없다"였거든. 근데 기사 읽다가 "활성 파라미터 17B"라는 단어에서 손이 딱 멈췄어. 이미 Qwen 3.6 27B를 N100에서 1 tok/s 고통으로 굴려본 입장에서, MoE 구조가 이 상황을 바꿔줄 수 있는지 계산부터 해봤지. 결론 먼저 말하면 - 쉽지는 않아. 그렇지만 방법이 아예 없는 건 아니야. 그 계산 과정을 정리해둔다.

목차

1. Llama 4 Scout이란 - 109B인데 17B처럼 작동하는 MoE 구조
2. 10M 토큰 컨텍스트 - 책 40권 분량을 통째로 넣는다는 게 뭔 뜻인가
3. 모델 크기의 현실 - Q4 양자화해도 55GB라는 벽
4. N100 16GB의 한계선 - IQ1_S까지 내려가면 가능한가
5. Qwen 3.6 27B와 비교 - N100 사용자에겐 어느 쪽인가
6. Ollama로 시작하는 법 - 지금 바로 2줄
7. 결론 - Scout이 필요한 사람 vs 아닌 사람

1. Llama 4 Scout이란 - 109B인데 17B처럼 작동하는 MoE 구조

Llama 4 Scout는, 2026년 4월 5일 Meta가 공개한 멀티모달 오픈소스 모델이야. 이름에 "Scout"가 붙은 건, Maverick이라는 더 큰 형제(400B+)가 따로 있기 때문이지. Scout이 경량 버전이고, Maverick이 플래그십이야.

그런데 Scout을 그냥 "109B짜리 모델"로 읽으면, 반은 틀린 거야. 핵심이 MoE(Mixture of Experts) 구조에 있거든. 전체 파라미터는 109B이지만, 실제로 토큰 하나를 처리할 때 활성화되는 파라미터는 17B밖에 안 돼. 16개의 "전문가" 레이어 중, 라우터가 1개만 골라서 쓰는 방식이야.

1-1. MoE가 뭐길래 이런 구조가 나오나

비유하자면 이래. 백과사전 109권이 책장에 꽂혀 있는데, 질문 하나가 들어오면 사서가 "이건 17권짜리 분야야"라고 판단하고, 해당 책들만 꺼내서 답을 찾아. 109권 전체를 다 뒤지지 않는다는 거지. 그러니까 추론 속도나 메모리 사용량 측면에서, "활성 파라미터 17B 모델" 수준의 효율을 기대할 수 있어.

근데 여기서 함정이 있어. 책장에 꽂혀 있는 109권은 다 있어야 한다는 거야. 사서가 17권만 꺼내 쓴다고 해서, 나머지 92권을 집에 두고 올 수는 없잖아. 결국 전체 109B 파라미터 가중치를 메모리에 올려야 해. 추론 속도는 빠를 수 있지만, 저장 공간과 메모리는 109B짜리 모델 그대로 필요하다는 뜻이야.

이게 N100 환경에 바로 직결되는 문제야. 활성 파라미터가 17B라고 해서 "17B 모델만큼 메모리 필요"라고 오해하는 경우가 많거든. 전혀 정확하지 않아.

핵심: Scout은 추론 연산량이 17B 수준이지만, 메모리에 올려야 하는 가중치는 109B 전체다.

2. 10M 토큰 컨텍스트 - 책 40권 분량을 통째로

Scout의 두 번째 특징이 10,000,000 토큰 컨텍스트 윈도우야. 이게 얼마나 큰 건지 감이 잘 안 오지. 계산해보면 이래.

모델	토큰 수	비교 대상
GPT-4o	128,000	소설 1권 절반
Qwen 3.6 27B	1,000,000	소설 4~5권
Llama 4 Scout	10,000,000	소설 40~50권

소설 40권을 한 번에 집어넣고, "3장 7페이지에 나온 등장인물 찾아줘" 하면 정확히 찾아내. 이걸 Needle in Haystack 벤치마크라고 하는데, Scout은 모든 깊이에서 완벽한 검색 성능을 보여줬어. Meta 공식 발표 기준으로, 10M 토큰 전체에서 정확도 유지한다고 나왔지.

2-1. 개발자한테 이게 뭘 의미하는가

실용적으로 말하면 이래. 중간 규모 회사 코드베이스 전체를 한 번에 던질 수 있어. Python 프로젝트 파일 200개, 40만 줄짜리 코드도 컨텍스트 안에 들어가거든. Qwen 3.6 27B의 1M 토큰으로도 꽤 큰 코드베이스를 다룰 수 있었는데, Scout은 그 10배야.

다만 현실적인 얘기를 하자면, 10M 토큰을 다 채웠을 때 메모리 소비가 폭발적으로 늘어나. 컨텍스트 1M 채우는 것만도, KV 캐시가 몇 GB씩 잡히거든. 로컬 환경에서 10M 풀로 쓸 수 있는 사람이 현실에서 얼마나 되는지 모르겠어. 어쨌든 클라우드 API로 쓸 때는 확실히 강점이야.

핵심: 10M 토큰은 코드베이스 전체 인덱싱에 강력하지만, 로컬 환경에서 풀로 활용하려면 KV 캐시용 추가 메모리가 필수다.

3. 모델 크기의 현실 - Q4 양자화해도 55GB라는 벽

이제 진짜 핵심 계산이야. Llama 4 Scout을 내 기기에 올리려면, 도대체 얼마나 필요한가.

원본(BF16 기준)은 218GB야. 이건 연구용 서버 아니면 의미 없는 숫자고, 실용적인 로컬 실행은 양자화가 필수야. 양자화 단계별 크기를 정리해두면 이래.

양자화	모델 크기	권장 RAM/VRAM	성능 손실
BF16	218 GB	256 GB+	없음 (기준)
Q8_0	약 110 GB	128 GB+	미미
Q4_K_M	약 55 GB	64 GB+	낮음 (3% 이내)
Q3_K_M	약 41 GB	48 GB+	보통 (5~7%)
Q2_K	약 28 GB	32 GB+	높음 (10%+)
IQ2_XXS	약 22 GB	24 GB+	매우 높음
IQ1_S	약 14~16 GB	16 GB	극심함

Qwen 3.6 27B를 N100에 올렸을 때, Q4_K_M이 16.8GB였거든. 딱 16GB 경계에서 mmap 덕분에 가까스로 올라갔지. Scout Q4_K_M은 55GB야. 16GB의 3.3배. 이게 현실이야.

3-1. mmap 페이징으로 SSD에서 돌리면?

llama.cpp는 mmap 옵션으로, 모델 일부를 SSD에서 페이지 단위로 읽어올 수 있어. 이론상 RAM이 부족해도 SSD 용량만 충분하면 돌아가긴 해. 근데 속도가 어떻게 나올지 생각해봐.

내 N100에서 Qwen 3.6 27B Q4_K_M(16.8GB)을 CPU 추론으로 돌렸을 때, 0.9~1.2 tok/s가 나왔어. 이게 모델이 RAM에 거의 다 올라간 상태에서 나온 수치야. Scout Q4_K_M은 55GB인데, 16GB RAM 기기에서 mmap으로 돌리면 SSD I/O가 병목이 돼. NVMe SSD 읽기 속도가 아무리 빨라봐야, RAM 대역폭의 10분의 1 수준이거든. 체감 속도가 0.1 tok/s 아래로 떨어질 가능성이 있어. 솔직히 이건 "실행"이라고 부르기도 민망한 수준이지.

핵심: Q4_K_M 기준 Scout은 55GB. N100 16GB에서 mmap 실행 시 SSD 병목으로 사실상 실용성 없음.

4. N100 16GB의 한계선 - IQ1_S까지 내려가면 가능한가

그럼 양자화를 더 극단적으로 낮추면? IQ1_S가 현재 알려진 가장 공격적인 양자화야. 1비트 혼합 정밀도 계열로, 모델 크기를 이론적으로 16GB 언저리까지 끌어내릴 수 있어.

가능은 해. 근데 댓가가 커. Qwen 3.6 27B 얘기할 때도, IQ3_XS 이하로 가면 SWE-bench 점수가 5점 이상 빠진다고 했잖아. Scout는 109B라 기반 성능이 더 높으니까, IQ1_S로 내려가도 절대 점수 자체는 어느 정도 유지될 수 있어. 근데 그게 "얼마나 무너지는가"가 문제야.

4-1. IQ1_S로 내려가면 어느 정도 성능이 남나

커뮤니티 측정치 기준으로, IQ1_S는 Q4_K_M 대비 벤치마크 점수가 15~25% 하락해. Scout의 코딩 벤치마크(LiveCodeBench)가 38.1%인데, IQ1_S에서 25% 빠지면 28~29%대가 돼. 그게 어느 수준이냐면, Llama 3.3 70B Q4 수준이야. 1년 전 모델 수준으로 후퇴하는 셈이지.

이게 나쁜 건 아닌데, 109B 모델을 초경량 양자화해서 1년 전 70B 수준 성능을 얻겠다는 게 과연 의미 있는 선택인가 하는 거야. 차라리 Qwen 3.6 27B Q4_K_M을 그 자리에 꽂아두는 게, 같은 RAM에서 더 좋은 결과를 낼 수도 있거든.

모델	양자화	크기	N100 실행	추정 성능
Llama 4 Scout	Q4_K_M	55 GB	불가	최고
Llama 4 Scout	Q2_K	28 GB	불가	높음
Llama 4 Scout	IQ2_XXS	22 GB	RAM 초과	보통
Llama 4 Scout	IQ1_S	14~16 GB	간신히 가능	낮음
Qwen 3.6 27B	Q4_K_M	16.8 GB	실측 1 tok/s	높음

핵심: N100 16GB에서 Scout을 돌리는 현실적 방법은 IQ1_S뿐인데, 이때 성능이 27B Q4_K_M과 엇비슷하거나 오히려 낮아질 수 있다.

5. Qwen 3.6 27B와 비교 - N100 사용자에겐 어느 쪽인가

이게 가장 실질적인 질문이야. 이미 Qwen 3.6 27B를 N100에서 굴린 경험이 있으니, 비교해보면 이래.

Qwen 3.6 27B Q4_K_M은 16.8GB라, N100(16GB)에 mmap으로 간신히 올라가. 속도가 0.9~1.2 tok/s로 느리지만, 어쨌든 돌아가기는 해. 코드 리팩토링 간단한 것, 짧은 문서 요약은 쓸 수 있는 수준이야. 느리다는 거지, 못 쓴다는 건 아니거든.

Scout IQ1_S는 이론상 16GB에 간신히 들어가. 근데 성능이 Qwen 3.6 27B Q4_K_M보다 낮을 가능성이 있어. 컨텍스트는 Scout이 10M으로 압도적이지만, IQ1_S 상태에서 그 긴 컨텍스트를 정확하게 처리하는지는 별개 문제야.

5-1. 용도별로 뭘 선택해야 하나

내 결론은 이래. N100 환경이면 지금 당장은 Qwen 3.6 27B가 현실 옵션이야. Scout은 GPU 한 장 이상이 있는 환경에서, 진가가 나와. RTX 4060 Ti 16GB 한 장이면 Scout Q4_K_M이 간당간당하게 올라가고, RTX 4090 24GB면 여유 있게 돌아가.

아 맞다, 한 가지 예외가 있어. Scout의 10M 컨텍스트가 클라우드 API로 쓸 때는 얘기가 달라지거든. Together AI나 Groq 같은 서비스에서, Scout API를 Qwen 3.6 27B 대비 69% 저렴하게 제공하고 있어. 로컬 실행이 목적이 아니라 API로 쓰는 거라면, Scout이 가성비도 좋고 컨텍스트도 훨씬 길어서 강력한 선택이야.

핵심: N100 로컬 실행 기준으로는 Qwen 3.6 27B가 우위. GPU 16GB 이상 있으면 Scout이 역전.

6. Ollama로 시작하는 법 - 지금 바로 2줄

Scout을 돌릴 GPU 환경이 갖춰져 있다면, Ollama 실행 방법은 단순해. Ollama 0.7.x 이상 버전이 설치돼 있으면, 이게 전부야.

# Llama 4 Scout 다운로드 (기본 양자화)
ollama pull llama4:scout

# 실행
ollama run llama4:scout

기본 pull이 Q4_K_M 기준 약 55GB라, 다운로드 시간이 꽤 걸려. 회선에 따라 30분~2시간. SSD 여유 공간 60GB 이상 확보해두는 게 좋아.

6-1. 메모리 부족 환경에서의 대안 설정

GPU VRAM이 부족하면, CPU 오프로드 비율을 조절할 수 있어. VRAM에 일부 레이어만 올리고, 나머지를 RAM에 두는 방식이야.

# GPU 레이어 수 조정 (VRAM 16GB 기준 예시)
ollama run llama4:scout --num-gpu-layers 20

# 완전 CPU 모드 (GPU 없는 환경)
OLLAMA_NUM_GPU=0 ollama run llama4:scout

GPU 레이어를 줄이면 속도가 그만큼 떨어져. VRAM 16GB 기기에서 레이어 20개 오프로드 시, 10~15 tok/s 수준이 나온다는 커뮤니티 측정치가 있어. 전체 GPU 모드(24GB VRAM 기준)의 절반 이하지만, CPU 단독보단 훨씬 빨라.

llama.cpp 직접 빌드로 세밀하게 제어하고 싶다면, 이런 식으로 돌릴 수 있어.

# llama.cpp CPU 빌드 (GPU 없는 환경)
make GGML_CUDA=0 -j$(nproc)

# Scout GGUF 실행 (CPU 전용, mmap 활성화)
./llama-server -m llama4-scout-IQ1_S.gguf \
  --ctx-size 4096 \
  --threads 4 \
  --mmap 1

여기서 --ctx-size 4096은 컨텍스트 창을 4K로 제한한 거야. 10M 다 열어놓으면, KV 캐시가 RAM을 통째로 잡아먹거든. 저사양 환경에선 컨텍스트 줄이는 게 생존 전략이야.

핵심: Ollama 기본 pull은 55GB Q4_K_M. 저사양 환경에서는 컨텍스트 크기와 GPU 레이어 수를 줄여서 메모리 압박을 관리해야 한다.

7. 결론 - Scout이 필요한 사람 vs 아닌 사람

이번 분석을 한 줄로 정리하면 이래. Llama 4 Scout은 강력한 모델이지만, N100 16GB 로컬 환경에서는 현실적인 선택지가 아직 아니야. IQ1_S 극단적 양자화로 간신히 올릴 수 있지만, 그 상태에서 얻는 성능이 이미 갖고 있는 Qwen 3.6 27B보다 낫다는 보장이 없어.

반면 GPU가 있는 환경, 특히 RTX 4060 Ti(16GB) 이상이라면 Scout이 진짜 게임 체인저야. MoE 구조 덕분에 17B 수준의 속도로 109B 성능을 뽑아내고, 10M 컨텍스트로 코드베이스 전체를 한 번에 던질 수 있거든.

---

Q1. N100에서 Llama 4 Scout을 실행하는 방법이 정말 없나요?
IQ1_S 양자화(약 14~16GB)로 간신히 올릴 수는 있어. 근데 속도가 CPU 추론 기준 0.3~0.5 tok/s 이하로 추정돼. 실용적인 사용은 어려워. N100 환경이면, 현재는 Qwen 3.6 27B Q4_K_M(16.8GB)이 훨씬 현실적이야.

Q2. Llama 4 Scout과 Maverick의 차이는?
Scout이 109B(활성 17B) 경량 버전, Maverick이 400B+ 플래그십이야. 로컬 실행 논의에서 Maverick은 아예 대상이 아니고, Scout이 "간신히 로컬 가능한 한계선" 정도에 있어.

Q3. Scout의 10M 컨텍스트를 실제로 써볼 수 있는 방법이 있나요?
API 서비스 활용이 가장 현실적이야. Together AI나 Fireworks AI 같은 서비스에서, Scout API를 Qwen 3.6 27B 대비 69% 저렴하게 제공하고 있어. 로컬 실행 없이 10M 컨텍스트를 싸게 써보고 싶다면, 이쪽이 나아.

# 환경별 현실 옵션 정리
# N100 / RAM 16GB     : Qwen 3.6 27B Q4_K_M (추천)
# RAM 32GB / GPU 없음 : Scout Q2_K (28GB, 느림)
# RTX 4060 Ti 16GB   : Scout Q4_K_M 간당간당
# RTX 4090 24GB      : Scout Q4_K_M 여유
# H100 80GB+         : Scout BF16 풀 성능

다음에는 RTX 4090 환경에서, Scout Q4_K_M 실측 데이터를 직접 측정해볼 계획이야. Qwen 3.6 27B 1M 컨텍스트 vs Scout 10M 컨텍스트, 같은 코드베이스에서 누가 더 잘 찾아내는지 비교해보면 재밌을 것 같거든. 다음 편에서 만나자.

관련 글

→ EU 계정 뚫리고 데이터센터 폭격까지, AWS에 무슨 일이 벌어지고 있나

→ 젬마4 로컬 설치 방법 — Ollama 터미널 한 줄이면 끝나는데 함정이 있다