개발하는 TeEm0

사내에 "AI 에이전트 붙여보자"는 얘기가 나오면 인프라 담당자 입장에서 제일 먼저 걸리는 건 성능이 아니다. 데이터가 밖으로 나간다는 것, 그리고 토큰 요금이 예측 불가능하다는 것이다. 특히 에이전트는 한 번의 사용자 요청에 툴 콜 10~20번을 돌리기 때문에 챗봇 대비 토큰 소모가 자릿수 단위로 다르다. 그래서 "로컬에서 돌리면 안 되나"는 얘기가 계속 나오고, 매번 "작은 모델은 툴 콜을 제대로 못 한다"에서 막혔다.

2026년 8월 10일 Meta Superintelligence Labs가 공개한 Muse Glimmer는 딱 이 지점을 노린 모델이다. 30B 파라미터, Apache 2.0 라이선스, 그리고 명시적으로 "always-on local agent workflows"에 최적화했다고 밝혔다. 개인적으로 흥미로웠던 건 모델 자체보다 메모리 예산을 어떻게 쪼갰는지를 블로그에서 대놓고 설명한 부분이다. 인프라 하는 사람이 읽으면 바로 계산기 두드리게 된다.

1. 왜 지금 이 모델이 화제인가

기존 로컬 모델 도입 시나리오는 대부분 이렇게 깨졌다.

• 7B급을 올린다 → 툴 스키마를 못 지킨다. JSON 필드명을 지 마음대로 바꾼다.
• 70B급을 올린다 → 소비자용 GPU 한 장에 안 들어간다. A100 두 장 얘기가 나오고 프로젝트가 죽는다.
• 중간 크기를 올린다 → 툴 콜 하나 실패하면 그냥 멈춘다. 재시도 로직을 스캐폴드에서 다 짜야 한다.

Muse Glimmer가 주장하는 차별점은 세 가지다. 첫째, 30B를 약 4비트로 양자화해 언어 모델 부분을 20GB 미만으로 줄였다는 것. 원문 기준 full precision이면 55GB가 넘는데, 이걸 압축해서 24GB 또는 32GB 메모리 안에 KV 캐시 + 이미지용 perception encoder + speculative decoding용 drafter까지 같이 올린다는 설계다. 둘째, DFlash 기반 경량 drafter로 speculative decoding을 기본 탑재했다는 것. 셋째, Failure Recovery를 학습 목표에 명시적으로 넣었다는 것 — 툴 콜이 실패하거나 예상 밖 결과를 반환하면 멈추지 말고 진단 후 재시도하도록 훈련했다고 한다.

세 번째가 실무자 입장에선 제일 크다. 로컬 에이전트를 돌려본 사람은 알겠지만, 실패의 90%는 "모델이 멍청해서"가 아니라 "툴이 404를 뱉었는데 모델이 그걸 못 읽고 그대로 종료해서"다.

2. 메모리 예산이라는 핵심 원리

로컬 LLM을 처음 올려보는 사람들이 가장 많이 하는 실수가 "모델 파일 크기 = 필요 VRAM"이라고 생각하는 것이다. 아니다. 실제로는 이렇게 나눠 먹는다.

[24GB VRAM 카드 기준 대략적인 배분 — 원문 설명 기반]

 모델 가중치 (4bit 양자화)   ~17-20GB
 KV 캐시 (컨텍스트 길이 비례)  가변
 perception encoder (이미지)   가변
 DFlash drafter (양자화 버전)  가변
 ────────────────────────────
 합계가 24GB / 32GB 안에 들어와야 함

원문에서 "K-Quant-17GB 모델"이라는 표현을 쓴 걸 보면, 실제 배포되는 양자화 변형 중 하나가 17GB 수준인 듯하다. 24GB 카드에서 17GB를 쓰면 나머지 7GB로 KV 캐시와 encoder, drafter를 다 감당해야 한다는 뜻이다. 컨텍스트를 길게 잡으면 여기서 터진다. 에이전트 워크로드는 툴 응답이 계속 쌓이기 때문에 컨텍스트가 금방 길어지는데, 이게 로컬 배포의 진짜 병목이다.

speculative decoding은 왜 필요한가

일반 생성은 토큰을 하나씩 뽑는다. 매 토큰마다 20GB짜리 가중치를 VRAM에서 읽어와야 하니, 소비자 GPU에서는 연산이 아니라 메모리 대역폭이 병목이 된다. 즉 GPU 코어는 놀고 있는데 데이터 읽느라 느린 상태다.

speculative decoding은 여기에 작은 drafter 모델을 붙인다. 비유하자면 이렇다. 선배가 문서를 검토하는데, 후배가 미리 다음 문단을 예상해서 초안을 통째로 써 온다. 선배는 그 초안을 한 번에 훑어보고 맞는 부분까지는 그대로 통과시키고, 틀린 지점부터 직접 고쳐 쓴다. 후배가 대충이라도 잘 맞히면 선배가 문장을 하나씩 쓰는 것보다 훨씬 빠르다. 중요한 건 최종 결과물의 품질은 선배가 직접 쓴 것과 동일하다는 점이다. 원문도 "producing identical output quality"라고 명시한다.

원문은 MacBook M4-Max, M5-Max, RTX-5090에서 속도를 측정했다고만 밝히고 있고 구체적인 tok/s 수치는 블로그 본문에 나오지 않는다. 실제 수치는 릴리스된 리포트와 각자 하드웨어에서 직접 재봐야 한다.

3. 실무 관점: 도입 전에 계산해야 할 것들

먼저 하드웨어부터 확인

뭘 하든 이것부터 찍고 시작한다.

$ nvidia-smi --query-gpu=name,memory.total,memory.used --format=csv
name, memory.total [MiB], memory.used [MiB]
NVIDIA GeForce RTX 4090, 24564 MiB, 412 MiB

# macOS (Apple Silicon)는 통합 메모리라 다르게 본다
$ system_profiler SPHardwareDataType | grep -E "Chip|Memory"
      Chip: Apple M4 Max
      Memory: 36 GB

맥은 통합 메모리라서 숫자만 보면 여유로워 보이지만, 기본적으로 GPU가 쓸 수 있는 상한이 따로 걸려 있다. 32GB 맥에서 20GB짜리 모델을 올리려다 실패하는 경우가 여기서 나온다. Metal 계열은 iogpu.wired_limit_mb 같은 sysctl로 상한을 조정할 수 있는데, 시스템 안정성에 영향을 주므로 남는 메모리를 다 밀어넣지는 말자.

Ollama로 최소 검증

원문에 따르면 Ollama, LM Studio, Unsloth, llama.cpp, ExecuTorch, MLX, vLLM, SGLang 등에서 지원 예정이다("in the coming days"로 표현되어 있으니, 실제 태그명과 지원 여부는 각 프로젝트 문서를 확인해야 한다). 로컬 검증 흐름 자체는 이런 형태가 된다.

# 1) 모델 pull (태그명은 공식 문서 확인 필요)
$ ollama pull muse-glimmer:30b-q4

# 2) 툴 콜이 실제로 스키마를 지키는지 확인
$ curl -s http://localhost:11434/api/chat -d '{
  "model": "muse-glimmer:30b-q4",
  "messages": [{"role":"user","content":"서울 날씨 알려줘"}],
  "tools": [{"type":"function","function":{
    "name":"get_weather",
    "parameters":{"type":"object",
      "properties":{"city":{"type":"string"}},
      "required":["city"]}}}],
  "stream": false
}' | jq '.message.tool_calls'

[
  {
    "function": {
      "name": "get_weather",
      "arguments": { "city": "Seoul" }
    }
  }
]

여기서 tool_calls가 null로 오고 대신 content에 {"name": "get_weather", ...} 같은 문자열이 박혀 나오면, 모델이 아니라 템플릿 문제일 확률이 높다. 툴 콜 포맷은 채팅 템플릿에 강하게 묶여 있어서, 잘못된 템플릿으로 돌리면 모델이 아무리 잘 훈련돼 있어도 파싱이 깨진다. 커스텀 Modelfile을 쓸 때 특히 자주 밟는다.

흔한 함정 1: OOM은 로딩이 아니라 대화 도중에 터진다

제일 헷갈리는 포인트다. 모델은 멀쩡히 올라갔는데, 에이전트가 툴을 5~6번 호출하고 나면 죽는다. KV 캐시가 컨텍스트 길이만큼 계속 자라기 때문이다.

llama_kv_cache_init: failed to allocate buffer for kv cache
ggml_backend_cuda_buffer_type_alloc_buffer: allocating 4096.00 MiB on device 0: cudaMalloc failed: out of memory
llama_new_context_with_model: failed to create context with model

# 또는 vLLM 쪽
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.00 GiB.
GPU 0 has a total capacity of 23.99 GiB of which 1.12 GiB is free.

대응은 세 가지다. (1) --ctx-size를 실제 필요한 만큼만 잡는다. 무작정 128k 잡지 말고 에이전트 트레이스 로그로 실측한 최대 길이 × 1.5 정도. (2) KV 캐시 자체를 양자화한다(llama.cpp의 --cache-type-k q8_0 등). (3) 이미지를 안 쓸 거면 perception encoder를 안 올리는 구성이 가능한지 확인한다 — 이건 배포 포맷마다 다르니 문서 확인이 필요하다.

흔한 함정 2: "always-on"의 진짜 비용

원문이 강조하는 always-on 로컬 에이전트를 진짜로 상시 띄워두면, 노트북 배터리와 발열이 먼저 항의한다. 개발자 맥북에 상시 데몬으로 올리는 구성은 실제로 해보면 팬이 계속 돈다. 현실적인 절충안은 이렇다.

• 사무실 구석에 24GB급 GPU 워크스테이션 한 대를 두고 팀 공용 로컬 엔드포인트로 쓴다. "온디바이스"의 프라이버시 이점(외부 전송 없음)은 유지되고, 개인 장비 부담은 사라진다.
• 다만 이 순간 동시성 문제가 생긴다. 개인용 로컬 추론 스택(Ollama, LM Studio)은 동시 요청 처리가 약하다. 사람이 3명 이상 붙으면 vLLM이나 SGLang으로 갈아타야 한다. 원문도 "serve it at scale with vLLM and SGLang"이라고 구분해서 언급한다.

흔한 함정 3: 벤치마크와 우리 워크로드는 다른 세계다

원문은 Gemma4-31B, Qwen3.6-27B와 비교해 동급에서 강하다고 하고, DeepSearch QA / MCP-Atlas / 𝜏-Bench / SWE-Bench를 언급한다. 그런데 우리 회사 내부 API 30개짜리 스키마에서 잘 도는지는 저 벤치마크가 답해주지 않는다.

도입 결정 전에 반드시 자체 평가셋을 만들어야 한다. 실제 툴 스키마 그대로, 대표 시나리오 20~30개, 각각 3회씩 돌려서 툴 이름 정확도 / 파라미터 스키마 유효성 / 실패 후 복구율 세 가지만 재도 판단은 충분히 선다. 특히 세 번째는 일부러 툴이 500을 뱉게 만들어놓고 모델이 재시도하는지 보는 식으로 테스트하면 된다. Muse Glimmer가 Failure Recovery를 학습했다고 주장하니, 검증할 값어치가 있는 지점이다.

대안은 여전히 유효하다

모든 걸 로컬로 옮길 필요는 없다. 실무에서 잘 먹히는 구성은 라우팅이다. 개인정보·사내 코드가 섞이는 요청은 로컬 30B로, 고난도 추론이나 대규모 리팩터링은 클라우드 프런티어 모델로 보낸다. 원문이 언급한 "Controllable Effort"(추론 강도 조절)도 같은 맥락에서 쓸 수 있다 — 단순 분류성 작업은 낮은 effort로 빠르게, 계획 수립은 높은 effort로.

4. 정리

한 줄 요약: Muse Glimmer는 "30B를 4비트로 눌러서 24GB 카드 한 장에 에이전트 스택 전체를 넣는다"는 엔지니어링 결과물이고, 로컬 에이전트가 드디어 현실적 검토 대상이 됐다는 신호다.

지금 당장 붙여볼 만한 경우:

• 외부 전송이 컴플라이언스상 막혀 있는데 에이전트가 필요한 조직
• 에이전트 툴 콜 때문에 클라우드 토큰 비용이 예산을 밟고 있는 팀
• 오프라인/폐쇄망 환경에서 코딩 보조나 문서 처리를 돌려야 하는 경우
• Apache 2.0이 필요한 상용 제품 내장 시나리오

아직 기다려도 되는 경우: 동시 사용자가 많은 서비스에 붙일 계획이라면 GPU 대수 계산부터 다시 해야 한다. 24GB 한 장에 한 인스턴스라는 제약은 동시성 관점에선 꽤 비싸다. 그리고 llama.cpp / MLX / ExecuTorch 통합이 원문 기준 "coming days" 단계라, 각 스택의 실제 지원 상태와 태그명은 공식 문서로 확인하고 움직이는 게 안전하다.

개인적으론 4비트 압축이 에이전틱 태스크에서 "minimal to no degradation"이라는 주장을 가장 먼저 검증해보고 싶다. 일반 벤치에선 멀쩡한데 긴 툴 콜 체인에서 스키마가 미묘하게 흔들리는 건 양자화 모델의 오래된 지병이라, 여기가 진짜 승부처다.

참고 자료

• Introducing Muse Glimmer: An Open Agentic Model That Runs on Your Device — Meta AI Research (원문)
• Hugging Face — 모델 가중치 배포처
• llama.cpp — 양자화/KV 캐시 옵션 문서
• MLX — Apple Silicon 추론 프레임워크
• vLLM 공식 문서 — 다중 사용자 서빙
• Ollama — 로컬 실행 및 툴 콜 API

1. 도입: GPU 없이 LLM을 돌린다는 것

얼마 전 Hacker News에 올라온 글 하나가 인프라 하는 사람들 사이에서 돌았다. 제목이 "Running Gemma 4 26B at 5 tokens/sec on a 13-year-old Xeon with no GPU"다. 요약하면 이렇다. 2013년산 HP StoreVirtual 스토리지 박스(듀얼 Ivy Bridge Xeon E5-2690 v2, DDR3, GPU 없음)에서 Google의 Gemma 4 26B MoE 모델을 초당 5토큰가량으로 돌렸다는 얘기다. 박스 값은 300달러도 안 든다.

왜 이게 우리한테 의미가 있냐. 온프레미스 굴리는 팀이라면 데이터센터나 사무실 랙에 은퇴 직전이거나 이미 은퇴한 엔터프라이즈 서버가 한두 대씩 굴러다닌다. 스토리지 노드 교체하고 남은 구형 박스, 리스 만료돼서 반납 안 하고 방치한 서버 같은 것들. 이걸 폐기하거나 창고에 처박아 두는 대신 "LLM 폴백 서버"나 "야간 배치용 추론 노드"로 재활용할 수 있다면 얘기가 달라진다.

여기서 짚고 넘어갈 점. 원문 저자도 강조하지만 이건 "GPU 대신 CPU 쓰면 됩니다" 같은 단순한 얘기가 아니다. MoE 아키텍처 모델이라 활성 파라미터가 적어서(26B-A4B, 즉 총 26B지만 토큰당 활성 4B) CPU에서도 견딜 만한 속도가 나온 거고, 저자의 CPU는 AVX2도 FMA3도 없는 세대라 기존 최적화 코드가 아예 빌드조차 안 됐다. 그걸 패치해서 겨우 돌린 사례다. 그냥 따라한다고 되는 게 아니라는 뜻이다.

2. 핵심: CPU 추론이 왜 되고, 왜 느린가

MoE 덕분에 26B가 CPU에서 견딘다

Gemma 4 26B-A4B는 Mixture-of-Experts 모델이다. 전체 파라미터는 26B지만 토큰 하나 생성할 때 실제로 계산에 참여하는 건 4B(A4B의 A가 active) 정도만 활성화된다. 이게 CPU 추론에서 결정적이다.

비유하자면 이렇다. Dense 모델(모든 파라미터가 매 토큰마다 다 도는 모델)이 26명 전원이 매번 회의에 들어오는 조직이라면, MoE는 안건마다 관련 전문가 8명(원문 기준 layer당 8 active experts)만 불러 모으는 구조다. 나머지는 메모리에 대기만 하고 연산은 안 한다. CPU는 GPU만큼 병렬 연산이 세지 않으니, 매 토큰마다 도는 실제 연산량이 줄어드는 MoE 구조가 CPU에겐 큰 선물이다.

진짜 병목은 연산이 아니라 메모리 대역폭

여기가 CPU 추론의 핵심이다. LLM 디코딩(토큰 하나씩 뽑는 과정)은 대부분 연산 성능(FLOPS)이 아니라 메모리 대역폭에 묶인다(memory-bandwidth-bound). 원문 저자도 fused 커널을 못 써서 matmul을 두 번 나눠 돌리게 됐지만 "이 CPU는 어차피 메모리 대역폭에 묶여 있어서 손해 본 게 없다"고 명시했다.

왜 그런가. 토큰 하나 생성하려면 활성화된 가중치(Q8_0면 파라미터당 약 1바이트)를 전부 메모리에서 읽어와야 한다. 4B 활성 파라미터면 대략 4GB를 매 토큰마다 RAM에서 CPU로 긁어와야 한다는 뜻이다. DDR3 메모리 대역폭이 실효 40~50GB/s 수준이라 치면, 산술적으로 초당 10토큰 언저리가 물리적 상한선이 된다. 저자가 5.2 tok/s를 얻은 게 이 대역폭 벽을 감안하면 납득이 간다.

실무에서 이걸 기억해야 하는 이유. CPU 추론 튜닝할 때 "코어 수를 늘리면 빨라지겠지"라고 생각하기 쉬운데, 대역폭에 묶인 워크로드는 코어를 아무리 늘려도 메모리 컨트롤러가 못 따라와서 어느 지점부터는 스레드를 늘려도 속도가 안 오르거나 오히려 캐시 경합으로 느려진다. 물리 코어 수보다 메모리 채널 수와 대역폭이 더 중요하다.

3. 실무 관점: 세팅, 트레이드오프, 흔한 함정

llama.cpp / ollama 기본 세팅

먼저 AVX2가 있는 평범한(비교적 최신) CPU라면 굳이 원문의 고생을 따라할 필요 없다. Ollama나 llama.cpp 최신 빌드를 그대로 쓰면 된다. 가장 흔한 진입 경로는 Ollama다.

# Ollama 설치 (Linux)
curl -fsSL https://ollama.com/install.sh | sh

# CPU 정보 먼저 확인 - AVX2 지원 여부가 갈림길
lscpu | grep -o 'avx[0-9a-z_]*' | sort -u

출력이 이렇게 나오면 최신 최적화 커널을 쓸 수 있는 세대다.

avx
avx2
avx512f
avx512_vnni

반대로 원문 저자의 박스처럼 이렇게만 나오면 얘기가 완전히 달라진다.

avx

avx2가 안 보이고 avx만 있으면 Ivy Bridge(2013) 혹은 그 이전 세대다. 이 경우 대부분의 최신 추론 엔진 빌드가 런타임에 죽거나 아예 컴파일이 안 된다. 원문의 핵심 고생이 정확히 이 지점이다.

llama.cpp를 직접 빌드해서 스레드를 조절하려면 이런 식이다. (모델 경로와 파일명은 각자 환경에 맞게)

# llama.cpp 빌드 (AVX2 있는 일반적인 서버 기준)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j$(nproc)

# 실행: 물리 코어 수에 맞춰 스레드 지정
./build/bin/llama-cli \
  -m ./models/gemma-model-Q8_0.gguf \
  -p "온프레미스 서버 재활용 아이디어 3가지" \
  -t 20 \
  -c 4096

여기서 -t 20이 스레드 수다. 흔한 함정 하나: -t를 논리 코어(하이퍼스레딩 포함) 전부에 맞추면 오히려 느려지는 경우가 많다. 물리 코어 수부터 맞춰보고, 거기서 하나씩 조절하며 tok/s를 실측하는 게 정석이다. 앞서 말했듯 대역폭 병목이라 코어 다 갈아넣는다고 안 빨라진다.

양자화(Quantization): Q4 vs Q8 트레이드오프

원문은 Q8_0으로 돌렸다. 여기서 실무자가 알아야 할 트레이드오프를 정리한다. (아래 원리는 일반적으로 통용되는 내용이고, 원문에 없는 구체 벤치마크 수치는 지어내지 않았다.)

• Q8_0: 파라미터당 약 8비트(1바이트). 품질 손실이 거의 없다시피 하지만 메모리를 많이 먹고, 매 토큰마다 읽어야 할 데이터가 크다 → 대역폭 병목 환경에선 속도가 상대적으로 느려진다.
• Q4_K_M 등 4비트 계열: 파라미터당 약 4비트. 메모리 사용량과 대역폭 부담이 절반 수준으로 줄어 같은 하드웨어에서 디코딩 속도가 더 나올 여지가 크다. 대신 품질(특히 정밀한 추론, 코드 생성)에서 미세한 손실이 생길 수 있다.

대역폭에 묶인 CPU 환경에서는 "읽어야 할 바이트 수 = 속도"에 직결되기 때문에, Q8에서 Q4로 내리면 속도 이득이 GPU 환경보다 더 체감된다. 다만 원문 저자가 Q8_0을 쓴 이유가 있을 수 있다 — AVX1 폴백 경로에서 특정 양자화 포맷만 검증됐거나, 4비트 K-quant 계열이 해당 하드웨어의 스칼라 폴백에서 제대로 도는지 별도 확인이 필요하다. Q4로 바꿔 돌릴 땐 반드시 출력 품질을 눈으로 검증하고 나서 프로덕션에 올려라.

흔한 함정: AVX2 없는 하드웨어의 조용한 오작동

원문에서 가장 무서운 대목이 이거다. 빌드 자체가 죽으면 차라리 낫다. 진짜 문제는 빌드도 되고 실행도 되는데 출력이 조용히 쓰레기가 나오는 경우다.

저자의 경우 GGML_USE_IQK_MULMAT를 끄고 빌드했는데, 그래프 빌더는 여전히 MOE_FUSED_UP_GATE 같은 fused 연산을 뱉는데 dispatcher의 switch문엔 해당 op에 대한 case가 없어서 default로 빠졌고, 그 결과 모든 expert FFN의 결과 텐서가 계산되지 않고 메모리 쓰레기값으로 남았다. 30 layer × 8 active experts = 매 forward pass마다 약 240개 텐서가 초기화 안 된 버퍼값이었다는 것.

증상이 특히 교활하다. NaN도 안 뜨고, 크래시도 안 나고, temperature 0에서 결정적(deterministic)으로 나오는데 결과물이 이런 식이다:

# 증상: 유창해 보이는 다국어 gibberish
# 태국어, 한국어, 안 쓰는 sentinel 토큰, 영어 조각이
# 262K vocabulary 전체에 균일하게 흩뿌려짐
Prompt: What is the capital of France?
Output: สวัสดี 국가  the の paris ที่ 답 ▁▁ करता...

이게 왜 무서우냐. 크래시가 나면 "뭔가 잘못됐네"하고 바로 알지만, 그럴싸한 텍스트가 나오면 세팅이 잘 된 줄 착각하기 쉽다. 저자는 sampling 직전 raw logits를 찍어서 첫 토큰의 mean logit이 0 근처여야 하는데 +16으로 튀어 있고 vocabulary의 약 80%가 양수 logit인 걸 보고 "residual stream의 큰 덩어리가 초기화 안 된 메모리(작은 양수 float들)"라고 진단했다.

실무 교훈: 비표준 하드웨어에서 추론 엔진을 돌릴 땐 반드시 "정답을 아는 프롬프트"로 sanity check를 먼저 해라. "2 + 2는?", "한국의 수도는?" 같은 걸로 정상적인 답이 나오는지부터 확인하고, 그 다음 실제 워크로드를 태워야 한다. 크래시 안 났다고 정상이라 믿으면 안 된다.

또 하나의 함정: --run-time-repack

원문이 명시적으로 경고하는 지점. --run-time-repack 플래그는 시작할 때 양자화 가중치를 Q8_0_R8이라는 AVX2 전용 인터리브 레이아웃으로 재배열한다. AVX1 CPU에서 이걸 켜면 위와 똑같은 gibberish가 다시 나온다. AVX2 없는 박스에서 돌릴 거면 이 플래그를 빼야 한다. (AVX2 있는 서버라면 오히려 켜서 이득 보는 옵션이니 무조건 빼라는 얘기는 아니다.)

대안

• 그냥 최신 CPU 서버를 쓴다: Haswell(2014, v3) 이상이면 AVX2/FMA3가 있어서 이 고생을 안 해도 된다. 사내에 놀고 있는 v3~v4 세대 Xeon이 있다면 그걸 먼저 노려라. 패치 없이 Ollama 바로 돌아간다.
• MoE 모델을 우선 고른다: Dense 26B를 CPU에서 돌리면 A4B MoE보다 훨씬 느리다. CPU 서빙 계획이면 애초에 MoE 계열 모델을 선택하는 게 전략적으로 맞다.
• 배치/비동기 워크로드로 한정: 5 tok/s는 사람이 읽는 속도지 대화형 실시간 서비스엔 부족하다. 야간 배치 요약, 로그 분류, 문서 태깅 같은 지연 시간이 관대한 작업에 붙이는 게 현실적이다.

4. 정리: 한 줄 요약과 적용 대상

한 줄 요약: MoE 모델과 메모리 대역폭 특성 덕분에 GPU 없는 구형 Xeon에서도 26B LLM을 읽는 속도(약 5 tok/s)로 돌릴 수 있지만, AVX2 없는 세대는 엔진 패치와 조용한 오작동 검증이라는 대가가 따른다.

이럴 때 써라:

• 사무실/데이터센터에 놀고 있는 구형 서버가 있고, 유료 API가 다운됐을 때의 로컬 폴백이나 비용 민감한 야간 배치 추론이 필요한 경우
• 토큰당 과금이 부담스럽고 지연 시간에 관대한 대량 텍스트 처리(분류, 요약, 태깅) 워크로드
• 데이터를 외부로 못 내보내는 규제 환경에서 저비용 온프레미스 추론이 필요한 경우

이럴 땐 쓰지 마라:

• 실시간 대화형 챗봇처럼 응답 속도가 UX인 서비스 (5 tok/s는 답답하다)
• 가진 서버가 Haswell 이전 세대인데 C++ 커널 디버깅까지 감당할 팀이 없는 경우 — 이땐 그냥 GPU 인스턴스 빌리거나 최신 CPU 서버 쓰는 게 인건비 대비 싸다

가장 중요한 건 원문 저자가 던진 메시지다. "AI를 잘한다"는 게 구독료 내는 걸 뜻하는 시대에, 진짜 레버리지는 남이 안 만들어준 문제에 모델을 겨눌 줄 알고, 나온 답이 진짜 맞는지 판별할 줄 아는 것이라는 점. 이번 사례에서도 실제 커널 패치는 Claude가 짰지만, 실험을 설계하고 "logits mean이 +16이면 이상하다"를 아는 건 사람의 몫이었다. 인프라 하는 우리한테 딱 필요한 감각이다.

참고 자료

• 원문: Running Gemma 4 26B at 5 tokens/sec on a 13-year-old Xeon with no GPU (Neomind Labs)
• ik_llama.cpp (ikawrakow의 llama.cpp fork)
• 원문에서 언급한 패치 PR #2138 (작성 시점 기준 리뷰 대기 중)
• llama.cpp 본체 저장소
• Ollama (CPU 추론 가장 쉬운 진입점)