Muse Glimmer: 로컬 멀티모달 추론을 위한 Meta의 30B 오픈소스 모델

최근 한 동료가 필자에게 프로덕션 환경에서 사용할 수 있는 엔터프라이즈급 멀티모달 모델을 온전히 로컬 하드웨어에서 구동하려면 무엇이 필요한지 물었습니다. API 키도 없고, 호출 속도 제한(rate limit)도 없으며, 사내 데이터를 외부로 단 한 바이트도 내보내지 않는 환경을 전제로 말입니다. 단순한 장난감(toy) 수준이 아니라 이미지를 읽고 분석하며, 단계별로 추론하고, 네이티브하게 도구를 호출할 수 있으면서도 단일 GPU에 완벽히 적재되는 모델을 원했습니다.

이번 달을 기점으로, 그 질문에 대한 답은 바로 Muse Glimmer입니다.

Muse Glimmer의 실체: 어떤 모델인가

Muse Glimmer는 Meta가 공개한 300억 파라미터(30B) 규모의 오픈소스 멀티모달 모델입니다. 전문가 혼합(MoE, Mixture-of-Experts) 구조가 아닌 밀집(dense) 디코더 전용(decoder-only) 아키텍처를 취하고 있으며, 내장형 비전 인코더(vision encoder)를 탑재하고 있습니다. 텍스트와 이미지를 동시에 입력받아 텍스트 출력을 생성하며, 사용자에게 최종 응답을 제공하기 전에 내부의 비공개 사고의 연쇄(private chain-of-thought)를 거쳐 문제를 단계별로 심층 추론합니다.

이 모델은 처음부터 사전 학습(scratch training)된 것이 아니라, Meta의 더 거대한 독점(proprietary) 멀티모달 모델인 Muse Spark로부터 지식 증류(distillation)를 거쳐 개발되었습니다. 이러한 증류 과정은 매우 중요한 의미를 지닙니다. 대형 모델이 가진 뛰어난 추론 품질을 단일 GPU에서도 충분히 서빙할 수 있는 30B 크기 안에 온전히 압축해 냈기 때문입니다.

가중치(weights)는 완전한 Apache 2.0 라이선스로 배포됩니다. 연구 전용(research-only) 라이선스도 아니고, 승인 기반 접근(gated access)도 없으며, “추후 검토 후 승인하겠다”는 식의 제한도 없습니다. 자유롭게 다운로드하고, 즉시 구동하며, 추론 파이프라인 전체를 온전히 소유할 수 있습니다.

아키텍처: 내부 동작 원리

┌─────────────────────────────────────────────────────────┐   
│                   MUSE GLIMMER 30B                      │   
│                                                         │   
│  ┌──────────────────┐    ┌───────────────────────────┐  │   
│  │  Vision Encoder  │    │  Text Decoder             │  │ 
│  │  (built-in)      │───▶│  (dense, decoder-only)    │  │ 
│  └──────────────────┘    │  128K context window      │  │ 
│         ▲                │  GQA: 2 KV heads          │  │ 
│    ┌────┴────┐           │  Sliding-window attn      │  │
│    │  Image  │           │  (3/4 layers)             │  │
│    │  Input  │           └───────────────────────────┘  │   
│    └─────────┘                                          │   
└─────────────────────────────────────────────────────────┘

Muse Glimmer를 로컬 환경에서 현실적으로 서빙할 수 있게 만든 세 가지 핵심 아키텍처 설계가 있습니다.

2개의 KV 헤드를 적용한 그룹 쿼리 어텐션(Grouped-Query Attention, GQA). 모델 파라미터 크기 대비 KV 캐시(KV cache) 사용량이 매우 작게 유지됩니다. 덕분에 24GB VRAM을 가진 단일 그래픽 카드에서도 128K(131,072 토큰)에 달하는 방대한 컨텍스트를 현실적으로 운용할 수 있습니다.
전체 레이어의 3/4에 적용된 슬라이딩 윈도우 어텐션(Sliding-Window Attention). 전체 레이어 중 1/4만이 전체 길이의 어텐션 캐시를 유지하고, 나머지 3/4 레이어는 로컬 윈도우(local window)만을 활용합니다. 이는 메모리 절감 측면에서 엄청난 이점을 가져옵니다.
별도 프로젝터를 갖춘 통합 비전 인코더(Integrated Vision Encoder). 입력된 이미지는 비전 인코더를 거친 뒤, 비전 프로젝터(mmproj)를 통해 모델의 토큰 공간으로 투영(projection)되며, 텍스트 디코더는 이를 일반 텍스트 토큰과 동일한 방식으로 함께 처리합니다. 별도의 CLIP 모델을 따로 관리하고 로드할 필요가 없습니다.

프롬프팅 모델: ATEM 및 추론 강도(Reasoning Strength)

Muse Glimmer의 프롬프팅 포맷은 대다수 오픈소스 모델보다 훨씬 더 체계적으로 구조화되어 있습니다. 명시적인 역할 식별자(role marker), 턴 구분자(turn separator), 그리고 비공개 추론(private reasoning)과 사용자 노출 출력을 분리하는 수신자(recipient) 지정 시스템을 사용합니다.

턴(Turn) 동작 방식

to=user — 일반적인 응답 (기본값)
to=self — 내부적인 비공개 사고의 연쇄(Chain-of-Thought) 추론
to=<tool_name> — 지정된 이름의 도구를 향한 도구 호출(tool call)

모델은 기본적으로 추론을 수행하도록 설계되어 있습니다. 사용자에게 답변을 내놓기 전에, 먼저 내부 생각 과정을 담은 to=self 턴을 작성한 다음, 최종 답변을 담은 to=user 턴을 출력합니다. 이는 선택 사항이 아니며, 프롬프트 포맷 자체에 내장되어 있습니다.

추론 강도 (Reasoning Strength)

모델이 얼마나 깊이 있게 추론할지는 다음 네 가지 레벨로 제어할 수 있습니다:

레벨	동작 방식
`low`	최소한의 추론, 더 빠른 응답
`medium`	균형 잡힌 추론
`high`	기본값. 철저하고 심층적인 추론.
`xhigh`	최대 추론 심도

이 설정은 서버 전역 단위로 지정하거나 요청별로 지정할 수 있습니다:

prompt = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True,
    reasoning_strength="medium"
)

llama.cpp에서는 서버 전역 제어를 위해 --chat-template-kwargs '{"reasoning_strength":"low"}' 플래그를 사용하거나, 요청마다 chat_template_kwargs를 페이로드에 전달하면 됩니다.

가장 중요한 주의 사항: 추론 토큰도 max_tokens 제한에 포함되어 차감됩니다. max_tokens를 너무 작게 잡으면, 모델이 생각을 정리하던 도중에 토큰이 소진되어 finish_reason: "length"와 함께 빈 내용(empty content)을 반환하게 됩니다. 따라서 추론 중심의 워크로드에는 충분한 토큰 여유 공간(headroom)을 반드시 확보해 주어야 합니다.

도구 호출 (Tool Calling)

Muse Glimmer는 도구 호출을 위해 ATEM이라는 네이티브 포맷을 사용합니다. 일반적인 OpenAI 스타일의 함수 스키마(function schema)를 전달하면, 모델은 assistant to=<tool_name> 턴 내에서 ATEM 블록을 출력합니다:

<|start|>assistant to=get_weather<|message|><atem:function_calls>
<atem:invoke name="get_weather">
<atem:parameter name="city">Tokyo</atem:parameter>
</atem:invoke>
</atem:function_calls><|eot|>

한 턴당 하나의 도구 호출만 허용되며, 병렬 도구 호출(parallel tool calling)은 지원되지 않습니다. vLLM이나 llama.cpp 같은 OpenAI 호환 엔드포인트 뒤에서 서빙하는 경우, 서버가 ATEM 문법을 자동으로 파싱하여 JSON 응답의 표준 tool_calls 필드로 변환해 줍니다. 따라서 개발자가 ATEM 문법을 직접 다룰 필요는 없습니다.

양자화: 단일 GPU에서 구동하기

Muse Glimmer는 사전 양자화(pre-quantized)된 GGUF 체크포인트를 공식 제공합니다. 사용자가 직접 포맷을 변환할 필요가 없습니다.

파일명	파일 크기	용도
`muse-glimmer-30B-kquant-17gb.gguf`	16.8 GB	고정 K-양자화(Fixed K-quant). 기본 권장 체크포인트.
`muse-glimmer-30B-kquant-dynamic.gguf`	19.7 GB	동적 K-양자화(Dynamic K-quant). 더 높은 출력 품질.
`mmproj-kquant.gguf`	1.4 GB	비전 프로젝터 (이미지 처리에 필수)
`dflash-kquant.gguf`	1.6 GB	DFlash 드래프트 모델 (선택 사항)

VRAM 예산 산정

비전 프로젝터와 전체 131,072 토큰 컨텍스트를 모두 적재한 K-Quant-17GB 체크포인트는 약 19 GiB의 VRAM을 차지합니다:

구성 요소	VRAM
텍스트 모델 (Text model)	15.6 GiB
비전 프로젝터 (Vision projector)	1.3 GiB
KV 캐시 + 연산 버퍼	2.1 GiB
총합	19.0 GiB

이는 24GB VRAM을 갖춘 GPU(예: RTX 3090, 4090 등)에 넉넉한 여유 공간을 남기며 안정적으로 적재됩니다. GQA와 슬라이딩 윈도우 어텐션 구조 덕분에 전체 레이어의 1/4만이 전체 길이 캐시를 유지하므로, 대용량 컨텍스트에서도 KV 캐시 크기가 매우 작게 유지됩니다.

투기적 디코딩을 위해 DFlash 드래프터를 함께 올려도 약 20.5 GiB 수준으로, 여전히 단일 24GB 카드 안에서 여유 있게 구동됩니다.

투기적 디코딩: DFlash

DFlash는 Muse Glimmer에 적용된 블록 확산(block-diffusion) 기반 투기적 디코딩(speculative decoding) 기법입니다. 소형 드래프트 모델이 다음 토큰 시퀀스를 한 번에 제안하면, 타깃 모델이 이를 일괄 병렬 검증합니다. 단 한 번의 검증 스텝마다 복수의 토큰이 한꺼번에 확정(accept)됩니다.

이 방식은 단일 요청 지연 시간(single-request latency)이 전체 처리 속도를 좌우하는 긴 추론 과정(reasoning traces)에서 탁월한 가속 효과를 발휘합니다. 드래프트 모델의 GGUF 크기는 1.6 GB에 불과합니다.

# llama.cpp with DFlash
./build/bin/llama-server \
  -m muse-glimmer-30B-kquant-17gb.gguf \
  -md dflash-kquant.gguf \
  --spec-type draft-dflash \
  -ngld 99 --spec-draft-n-max 4 \
  ... # other flags

서버 구동 시 [spec] failed to measure draft model memory라는 경고가 출력될 수 있으나, 이는 무해한 경고입니다. 드래프트 모델은 정상적으로 메모리에 로드되어 서빙을 수행합니다.

배포: 4가지 서빙 런타임

런타임	최적의 사용 사례	지원 하드웨어	비고
vLLM	대규모 프로덕션 서빙, 고처리량(Throughput) 환경	NVIDIA GPU	OpenAI 호환 HTTP 엔드포인트
SGLang	다중 동시 접속 사용자 서빙	NVIDIA, Apple Silicon	OpenAI 호환 HTTP 엔드포인트
llama.cpp	로컬 단일 머신 및 CPU/GPU 혼합 환경	CPU, NVIDIA/AMD, Metal	HTTP 서버 및 CLI 지원
ExecuTorch	AOT(Ahead-of-Time) 컴파일, 엣지 기기 배포	CUDA, Apple Silicon	드래프트 모델 포함 단일 바이너리/프로그램

llama.cpp: 전체 설정 가이드

Muse Glimmer 지원은 llama.cpp 릴리스 b10353부터 공식적으로 포함되었습니다. 구버전 빌드에서는 unknown model architecture: 'muse-glimmer' 오류가 발생하며 체크포인트 로드가 거부됩니다.

# 체크포인트 다운로드
pip install -U huggingface_hub
hf download meta-models/Muse-Glimmer-30B-GGUF --local-dir ./muse-glimmer \
  --include "muse-glimmer-30B-kquant-17gb.gguf" \
  --include "mmproj-kquant.gguf"

# 서버 시작
./build/bin/llama-server \
  -m ./muse-glimmer/muse-glimmer-30B-kquant-17gb.gguf \
  --mmproj ./muse-glimmer/mmproj-kquant.gguf \
  -a muse-glimmer \
  -ngl 99 -c 131072 -np 1 \
  --host 127.0.0.1 --port 8080 --api-key <your-key> \
  --jinja \
  --chat-template-kwargs '{"reasoning_strength":"low"}'

핵심 플래그 분석

플래그	중요한 이유
`--jinja`	GGUF 파일 내부에 임베딩된 Muse Glimmer 템플릿을 활성화합니다. 이 플래그가 없으면 도구 호출과 추론 분리 기능이 완전히 동작하지 않습니다.
`-a muse-glimmer`	API 엔드포인트에서 사용할 모델 이름을 설정합니다. 지정하지 않으면 체크포인트 파일의 전체 경로가 모델 식별자로 노출됩니다.
`-np N`	동시 처리 슬롯(slot) 개수를 지정합니다. 전체 컨텍스트가 N개로 분할됩니다. 예를 들어 `-c 131072`에 `-np 4`를 주면 슬롯당 32,768 토큰이 할당됩니다.
`-ngl 99`	모든 레이어를 GPU VRAM으로 오프로드합니다.
`--chat-template-kwargs`	서버 전역에 적용할 `reasoning_strength`를 설정합니다. 기본값은 `high`입니다.

슬롯당 컨텍스트(Context Per Slot): 조용한 장애의 주범

이것은 실제 운영 환경에서 가장 주의해야 할 핵심 세부 사항입니다. 단일 텍스트 생성의 실질적 한도를 결정하는 것은 전체 컨텍스트 크기인 -c가 아니라 각 슬롯에 할당된 n_ctx_slot입니다. 이 설정을 잘못 구성하면 아무런 에러 로그도 없이 조용히 실패(silent failure)합니다. 슬롯 공간이 부족해지면 모델은 에러를 던지는 대신 아무런 응답도 생성하지 않고 종료됩니다. 그 결과 배치 작업이나 벤치마크 평가 시 지표가 급격히 떨어지지만 원인을 파악할 디버깅 단서는 전혀 남지 않게 됩니다.

Muse Glimmer는 매우 길고 정교하게 추론을 전개합니다. 단 한 번의 추론 생성만으로도 32,768 토큰 가까이 도달할 수 있습니다. 따라서 슬롯 크기를 축소하지 않으면서 동시성을 확보하려면 전체 컨텍스트를 그에 맞게 확장해야 합니다:

-c 524288 -np 4        # 슬롯당 131,072 토큰 확보, 4-way 동시 처리

오래된 메타데이터 수정 (Stale Metadata Fix)

서버 구동 시 exceeds the training context ... - capping 경고가 출력된다면, GGUF 파일 내부의 context_length 메타데이터가 구버전 수치로 기록되어 있는 경우입니다. 다음 스크립트로 메타데이터를 직접 수정할 수 있습니다:

python gguf-py/gguf/scripts/gguf_set_metadata.py <model>.gguf muse-glimmer.context_length 131072

서버 없이 CLI 환경에서 직접 실행하기

# 텍스트 전용
./build/bin/llama-cli -m model.gguf -ngl 99 -c 32768 --jinja -st

# 이미지 포함
./build/bin/llama-mtmd-cli -m model.gguf --mmproj mmproj.gguf \
  -ngl 99 -c 32768 --jinja --image photo.png -p "Describe this image."

-st는 단일 턴(single-turn, 한 번 답변하고 즉시 종료) 모드입니다. 두 CLI 모두 --jinja 플래그가 필수입니다. 두 CLI 도구 모두 모델의 생각 과정(thinking trace)을 인라인 콘솔에 실시간으로 출력합니다. --reasoning-format 옵션은 오직 서버 모드의 JSON 응답에서만 생각과 본문을 분리해 줍니다.

주의해야 할 함정 (What to Avoid)

채팅 템플릿을 수동으로 조합하지 마십시오. 반드시 apply_chat_template 함수를 사용해야 합니다. Muse Glimmer의 포맷에는 템플릿이 내부적으로 처리해야 하는 고유한 세부 규칙들이 포함되어 있습니다.
이미지 처리에 AutoTokenizer를 사용하지 마십시오. 반드시 AutoProcessor를 사용해야 합니다. 텍스트 토큰화뿐만 아니라 이미지 전처리 및 특수 토큰 매핑을 함께 전담합니다.
추론 시 add_generation_prompt=False로 두지 마십시오. 모델이 생성을 개시하기 위한 역할 전환 신호(cue)를 반드시 주어야 합니다.
max_tokens를 촉박하게 제한하지 마십시오. 비공개 사고 과정(reasoning trace)만으로도 수천 토큰이 소모될 수 있습니다. 생각 도중에 토큰 상한에 걸리면 빈 결과값(empty output)만 반환됩니다.
llama.cpp에서 --chat-template-file을 별도로 지정하지 마십시오. 업스트림 공식 템플릿 파일이 따로 존재하지 않습니다. --jinja 플래그를 사용하면 GGUF 자체에 내장된 템플릿을 자동으로 읽어오며, 이것이 ATEM 파서와 정상적으로 연결되는 유일한 경로입니다.
llama.cpp에서 reasoning_effort 옵션을 사용하지 마십시오. 해당 옵션은 구현되어 있지 않습니다. 대신 chat_template_kwargs.reasoning_strength를 전달해야 합니다.
추론 과정을 완전히 끌 수 있다고 가정하지 마십시오. 템플릿 구조상 생각 채널(thinking channel)은 무조건 열립니다. 비활성화는 불가능하며, reasoning_strength: low가 설정할 수 있는 최소 수준입니다.
n_ctx_slot을 간과하지 마십시오. 슬롯 크기가 너무 작으면 생성 결과가 아무런 경고도 없이 통째로 삼켜집니다.

출시 파트너 생태계

Muse Glimmer는 AMD, Arm, Dell, Fireworks AI, Hugging Face, Intel, llama.cpp, LM Studio, NVIDIA, Ollama, OpenRouter, SGLang/RadixArk, Together AI, Unsloth, vLLM/Inferact 등 업계 전반의 전폭적인 지원과 함께 출시되었습니다. 특정 벤더나 단일 서빙 스택에 얽매이지 않고 즉시 다양한 플랫폼에 통합할 수 있는 매우 폭넓은 생태계를 갖추고 있습니다.

결론 및 요약 (The Bottom Line)

Muse Glimmer는 오픈소스 LLM 생태계가 성숙해진 이래 오랫동안 비어 있던 가장 결정적인 빈자리를 채워줍니다. 강력한 다단계 추론 능력, 완전한 개방형 가중치(open weights), 그리고 로컬 배포를 완벽히 지원하는 최초의 진정한 멀티모달 모델입니다. 30B 파라미터는 실무적으로 최적의 스위트 스팟(sweet spot)입니다. 고난도 복합 추론을 수행할 만큼 충분히 강력하면서도, 양자화를 거치면 단일 소비자용 하드웨어(24GB GPU)에도 완벽히 들어맞는 크기입니다.

이미지 이해, 도구 호출, 그리고 사고의 연쇄(CoT) 추론이 모두 필요하면서도, 기업의 보안 정책상 데이터가 절대 로컬 인프라를 벗어나서는 안 되는 에이전트 워크플로우를 운영하고 있다면 Muse Glimmer는 가장 먼저 검토해야 할 최우선 모델입니다.

K-Quant GGUF 체크포인트, DFlash 투기적 디코딩, 그리고 llama.cpp의 성숙한 서빙 인프라가 결합되어, 단 1시간 이내에 백지상태에서 완전한 로컬 멀티모달 추론 서버를 가동할 수 있습니다. API 키도, 클라우드 의존성도, 사외로 유출되는 데이터도 전혀 필요 없습니다.

[[Muse Glimmer - Meta Open-Source 30B Multimodal Model]]

GxPChat