Source: Dev.to

당신이 깨닫지 못하고 내리는 결정

Gemma 4를 로컬 에이전트 루프에 연결하려고 앉는다 — Claude‑Code 스타일의 도구 사용 래퍼, 장기 컨텍스트 코드 리뷰어, 오프라인 연구 보조 등. 구글은 같은 릴리즈에서 네 가지 아키텍처를 제공한다. 대회 구도가 명백한 선택을 유도한다:

• E2B와 E4B(실제 파라미터) 모델 – 휴대폰, 브라우저, Pi 5용.
• 31B dense – 온‑프레미스 작업용 기본 모델.
• 26B MoE – 효율적인 모델 — 전문가 혼합(Mixture‑of‑Experts) 변형으로 토큰당 일부 파라미터만 활성화하고 FLOP당 더 나은 품질을 주장한다.

2026년의 흔한 직관은 MoE를 잡는 것이다. 이것이 최전선 연구실들이 모두 투자하고 있는 아키텍처다. Mixtral, DeepSeek V3, Qwen3 — 생산 방향은 일방통행이다. 당신이 사용하는 규모에서 오픈 릴리즈가 MoE 옵션을 제공한다면, 대부분은 그것을 선택한다. 바로 그 선택이다.

하지만 그 선택은 대부분이 실제로 만들게 될 워크로드에 잘못된 것이다.
인터랙티브 로컬 에이전트—다중 턴 도구 사용, 코드 편집, 각 단계가 인간에게 읽히거나 다음 단계에 전달되는 장기 컨텍스트 추론 체인—에서는 31B dense가 올바른 기본값이고, 26B MoE는 오히려 잘못된 선택이다. 이유는 크기, 품질, 혹은 오픈‑웨이트 사용성 때문이 아니라, 에이전트가 평균이 아니라 꼬리(tail)에서 실패한다는 점이다. 라우팅 변동성은 꼬리에서 나타난다. 이것이 전체 논점이며, 이하에서는 수식, 메커니즘, 그리고 주말에 가지고 있는 하드웨어로 실행할 수 있는 벤치마크를 제시한다.

---

평균을 최적화하는 흔한 실수

로컬 모델 배포를 논할 때 흔히 평균을 최적화한다. 초당 토큰 수, 첫 토큰까지 평균 시간, 배치 1에서의 처리량 등은 모든 llama.cpp 벤치마크가 보고하는 수치다.

• 챗봇: 한 번의 사용자 메시지에 한 번의 답변을 내보내는 경우 평균이 괜찮다.
• 에이전트: 그렇지 않다.

예를 들어 30단계 도구 사용 루프—로컬 코드 검색, 파일 편집, 테스트 실행, 최종 요약을 수행하는 전형적인 ReAct 스타일 에이전트—를 생각해 보자. 각 단계는 생성 호출이다. 각 호출이 소프트 타임아웃(예: 화면을 보는 사람이 포기하고 Ctrl‑C를 누르는 경우)을 초과할 확률이 3%라고 하면, 루프 전체가 타임아웃을 초과할 확률은

[ 1 - (1 - 0.03)^{30} \approx 0.60 ]

즉, 3%의 단계별 꼬리가 60%의 눈에 띄는 루프 실패로 이어진다. 단계당 꼬리를 1%로 낮춰도 30단계에서 26%의 루프 수준 실패가 발생한다. 평균 지연은 훌륭할 수 있지만 사용자 경험은 깨진다. 에이전트는 꼬리‑구속 시스템이며, 이는 저지연 트레이딩, 검색 랭킹, 요청‑레벨 웹 서빙과 동일한 원리다. Jeff Dean의 “tail at scale”은 바로 이 상황을 말한다—많은 요청을 동시에 보낼 때 가장 느린 하나가 전체를 지배한다. 에이전트는 기계가 아니라 시간을 기준으로 팬아웃하지만 수학은 동일하다.

따라서 아키텍처 비교를 볼 때는

“어떤 모델이 FLOP당 정답을 더 많이 맞히는가”

가 아니라

“어떤 모델이 사용자의 인내 한도 내에서 신뢰성 있게 정답을 맞히는가”

를 기준으로 해야 한다.

---

MoE 라우팅 메커니즘

MoE의 각 전방 패스는 토큰을 소수의 전문가 집합에만 라우팅한다. 예를 들어 Mixtral 8×7B는 각 MoE 레이어당 토큰당 8명 중 상위 2명을 선택한다. DeepSeek V3는 수백 명 중 상위 K명을 선택하고, 공유 전문가와 라우팅된 전문가를 결합한다. 아키텍처 세부사항은 다르지만 라우팅 메커니즘은 동일하다. 학습된 게이팅 네트워크가 전문가 확률을 출력하고, 구현은 상위 K를 활성화한다.

이 설계에서 파생되는 몇 가지 결과가 있다—버그가 아니라 MoE가 작동하는 핵심 특징이며, 배치된 클라우드 워크로드보다 로컬 에이전트에 더 큰 영향을 미친다.

1. 활성 파라미터는 토큰마다 달라지는 분포다. 구글이 MoE를 “gemma‑4‑26B‑A4B, ‘26 B 전체, 4 B 활성’”이라고 부르는 것은 토큰 전체에 대한 기대값을 의미할 뿐, 토큰당 보장을 의미하지 않는다. 특정 전문가에 집중되는 프롬프트(예: 이색 언어의 코드, 도메인‑특화 토큰 분포)에서는 같은 전문가가 모든 레이어에서 반복적으로 호출돼 활용 핫스팟을 만든다. 레이어 전체 작업량은 동일하지만 부하 균형은 아니다. 다중 GPU 배포에서는 전문가 간 All‑Reduce가 이를 완화하지만, 단일 머신 로컬 배포에서는 토큰당 지연 변동으로 나타난다.

2. 전문가 활용도는 비균등하다. Lo 등(2024)의 “Mixture‑of‑Experts in LLMs” 연구에 따르면 라우터는 출력 노름이 큰 전문가를 선호하고, 전문가 다양성은 레이어마다 변하며 최종 레이어는 중간 레이어와 다르게 라우팅한다. 에이전트 루프에서는 한 단계의 출력이 다음 단계의 입력이 되므로, 토큰이 실제로 도달하는 전문가 집합이 크게 달라질 수 있다. 배치 서비스에서는 많은 사용자가 평균을 내지만, 단일 에이전트 루프에서는 각 사용자 자체가 배치가 된다.

3. 로드‑밸런싱 손실은 모델을 균등한 전문가 사용으로 끌어당기지만 보장을 제공하지 않는다. 훈련 시 보조 손실(Shazeer et al., 2017; Fedus et al., Switch Transformer)은 과·과소 사용된 전문가를 벌하지만, 데이터셋 수준에서의 “대략 균등”은 특정 프롬프트에서는 균등하지 않다. 보조 손실은 부드러운 사전일 뿐, 실제 라우팅은 런타임에 결정돼 꼬리를 만든다.

4. KV 캐시는 대부분 아키텍처에 독립적이지만, 그 위에 얹히는 활성화 비용은 다르다. Gemma 4에 대한 정확한 캐시 수치는 아직 없지만, 일반 원칙은 동일하다: 긴 컨텍스트에서 KV 캐시 용량은 dense와 MoE가 비슷하지만, 토큰당 활성화 비용은 차이가 난다. MoE는 토큰당 FLOP에서는 이기지만 예측 가능한 FLOP에서는 뒤처진다.

5. Dense 모델은 이러한 변동이 전혀 없다. 모든 토큰이 동일한 작업을 수행한다. 라우팅 변동성이 없으