Meta의 새로운 300억 파라미터 Muse Glimmer는 MacBook Pro M2 Pro에서 30억 파라미터 Llama 3.2보다 56배 느리게 작동하며, 이는 대부분의 로컬 에이전트 워크플로우를 구동하는 빠르고 반복적인 호출에는 이 모델을 사용하기 부적합하게 만듭니다.
로컬 에이전트에게 속도가 중요한 이유
로컬 에이전트 루프는 분당 수십 번, 때로는 수백 번의 모델 호출을 실행합니다. 각 호출은 지연 시간(latency)을 추가하며, 누적된 지연은 응답성을 심각하게 저하시킬 수 있습니다. 따라서 개발자들은 정확도를 충족하는 가장 작은 모델을 고수하며, 문제가 진정으로 깊은 추론을 필요로 할 때만 더 큰 모델로 교체합니다. Meta는 Muse Glimmer를 이러한 루프를 위해 구축된 "thinking" 모델로 마케팅하며, 온디바이스(on-device)의 이점을 희생하지 않으면서도 더 풍부한 추론을 약속했습니다.
벤치마크 설정
32GB RAM을 탑재한 MacBook Pro M2 Pro에서 테스트를 진행했으며, 세 가지 대표적인 작업을 측정했습니다:
- Context re-read speed – 모델이 이미 본 프롬프트를 얼마나 빨리 처리하는지 측정.
- Constrained JSON extraction – 도구 호출 전 흔히 수행되는 단계로, 자유 형식의 텍스트에서 구조화된 데이터를 추출.
- Tool calling – 올바른 형식의 함수 호출 생성.
세 가지 모델을 비교했습니다:
| 모델 | 프롬프트 속도 (tok/s) | 생성 속도 (tok/s) | JSON 성공률 (5회 시도) | 호출당 시간 |
|---|---|---|---|---|
| Llama 3.2 3B | 702.9 | 56.7 | 5/5 | 0.6s |
| Qwen 3 14B | 161.8 | 14.6 | 5/5 | 16.1s |
| Muse Glimmer 30B | 56.7 | 7.1 | 5/5 | 33.4s |
세 모델 모두 정확도 목표를 달성하여 모든 시도에서 동일한 JSON 출력을 제공했습니다. 3B 모델은 전체 파이프라인을 1초 미만으로 완료한 반면, 30B 모델은 30초 이상이 소요되었습니다.
수치가 의미하는 것
56배의 속도 저하는 CPU 사용량과 실제 소요 시간(wall-clock time)을 직접적으로 증가시키며, 이는 결과적으로 에너지 소비를 급증시키고 단일 기기가 유지할 수 있는 동시 에이전트 수를 제한합니다. "thinking" 모드를 꺼도 Muse Glimmer는 숙고를 위해 계속해서 추가 토큰을 소모했으며, 이는 지연 시간이 선택적 기능이 아니라 아키텍처 자체에 내장되어 있음을 시사합니다.
"내 일정 가져오기"나 "새 이메일 요약하기"와 같이 즉각적으로 반응해야 하는 챗봇, 개인 비서 또는 자율 스크립트를 구축하는 개발자에게 Llama 3.2의 0.6초 지연 시간은 인간이 수용 가능한 범위 내에 있습니다. 반면 Muse Glimmer의 33초 대기 시간은 눈에 띄게 길며, 실제 서비스 환경(production)에서는 수용하기 어려울 가능성이 높습니다.
Muse Glimmer가 여전히 역할을 할 수 있는 분야
이번 벤치마크는 짧고 결정론적인 작업에 집중했습니다. Muse Glimmer는 생성된 추가 토큰을 통해 정답을 내리기 전 여러 해결 경로를 탐색할 수 있는 개방형 추론(open-ended reasoning) 분야에서 빛을 발합니다. 복잡한 코드 합성, 다단계 계획 수립 또는 모호한 사용자 의도 해석과 같이 미묘한 판단이 필요한 시나리오에서는, 이 심층 모델이 대기 시간을 감수할 만큼 더 높은 품질의 결과물을 만들어낼 수 있습니다.
비용 고려 사항
30B 모델을 로컬에서 실행하면 3B 모델보다 더 많은 GPU 메모리와 전력을 소비합니다. 노트북급 기기에서는 처리량(throughput)이 느려지면 CPU가 유휴 상태로 머무는 시간도 길어져, 일괄 요청(batch of requests)의 전체 실행 시간이 늘어납니다. 클라우드 비용과 비교하는 팀에게는 트레이드오프가 극명해집니다. 느린 로컬 모델은 더 큰 호스팅 모델에 대한 빠른 API 호출보다 추론당 비용이 더 많이 들 수 있습니다.
향후 주목할 점
Meta는 Muse Glimmer에 대한 상세한 성능 튜닝 가이드를 아직 공개하지 않았습니다. 향후 펌웨어나 드라이버 업데이트를 통해 속도 격차를 줄일 수 있으며, 특히 모델의 추론 능력을 유지하면서 양자화(quantization)나 가지치기(pruning)가 가능하다면 더욱 그렇습니다. 여러 호출을 배치 처리하거나 중간 프롬프트를 캐싱하는 커뮤니티 주도 툴킷 또한 특정 워크로드의 지연 시간을 완화할 수 있습니다.
개발자는 다음 사항을 모니터링해야 합니다:
- Quantization breakthroughs – 낮은 정밀도의 연산을 통해 초당 토큰 생성률(token-per-second)을 높일 수 있습니다.
- Hybrid pipelines – 일상적인 추출에는 작은 모델을 사용하고, 신뢰도 임계값을 충족하지 못할 때만 Muse Glimmer로 전환합니다.
- Hardware shifts – 최신 Apple 실리콘은 30B 가중치 행렬을 더 효율적으로 처리할 수 있습니다.
요약
Muse Glimmer는 30B 모델이 약속하는 깊이를 제공하지만, 현재의 소비자용 하드웨어에서는 대부분의 로컬 에이전트를 구동하는 고빈도 루프를 처리하기에 너무 느립니다. 온디바이스 모델을 외부 API처럼 다루십시오. 정확도 요구 사항을 충족하는 가장 작은 모델로 시작하고, 추가적인 추론 능력이 진정으로 필요한 작업에만 고성능 모델을 아껴두십시오. Meta가 속도 격차를 줄이기 전까지는, 일상적인 추출, 포맷팅, 간단한 도구 호출에는 3B Llama 3.2가 여전히 실용적인 선택이며, Muse Glimmer는 가끔 발생하는 심층 사고 과제를 위한 상위 단계로 남을 것입니다.