Muse Glimmer

Muse Glimmer

Muse Glimmer는 멀티모달 reasoning 모델이에요. Muse Glimmer는 네 가지 형식으로 서빙할 수 있어요: BF16 체크포인트(MuseGlimmerForConditionalGeneration), 벤더 GGUF 파일 세트, 즉시 서빙 가능한 NVFP4 + MXFP8 체크포인트, 그리고 Apple Silicon용 MLX 리팩 세 개.

출처: 문서

본문

1. Model Introduction

Muse Glimmer는 멀티모달 reasoning 모델이에요. Muse Glimmer는 네 가지 형식으로 서빙할 수 있어요:

  • BF16 체크포인트(MuseGlimmerForConditionalGeneration).
  • 벤더 GGUF 파일 세트.
  • 즉시 서빙 가능한 NVFP4 + MXFP8 체크포인트.
  • Apple Silicon용 MLX 리팩 세 개.
Form Source Notes
BF16 meta-models/Muse-Glimmer-30B 이미지 입력 지원.
GGUF Q4_K_M meta-models/Muse-Glimmer-30B-GGUF 텍스트 전용. 이 경로는 최적화되지 않음. SGLang이 시작 시 경고를 표시.
NVFP4 RadixArk/Muse-Glimmer-NVFP4 텍스트 전용. 즉시 서빙 가능, 변환 불필요.
MLX Q4 RadixArk/Muse-Glimmer-q4-MLX 텍스트 전용. Apple Silicon (MLX backend). gs128과 같은 서빙 레시피, 측정 라운드 없음. §3.4 참조.
MLX Q4_K_M (gs128) RadixArk/Muse-Glimmer-q4km-gs128-MLX 텍스트 전용. Apple Silicon (MLX backend). 벤더 GGUF의 정확한 양자화 코드를 MLX 형식으로 유지. 측정된 MLX 아티팩트. §3.4 참조.
MLX Q4_K (dynamic) RadixArk/Muse-Glimmer-q4k-dynamic-MLX 텍스트 전용. Apple Silicon (MLX backend). gs128과 같은 서빙 레시피, 측정 라운드 없음. §3.4 참조.

리소스: Muse-Glimmer-30B (BF16) · Muse-Glimmer-30B-assistant (DFlash draft) · Muse-Glimmer-30B-GGUF · Muse-Glimmer-NVFP4 · MLX · q4 · q4km-gs128 · q4k-dynamic.

2. Configuration Tips

GGUF 형식은 텍스트 전용이에요. SGLang에는 mmproj 경로가 없어요. 비전 GGUF 파일은 사용할 수 없어요. 멀티모달 입력에는 BF16 체크포인트를 사용하세요.

NVFP4 체크포인트. RadixArk/Muse-Glimmer-NVFP4는 즉시 서빙 가능한 NVFP4 + MXFP8 체크포인트예요. 변환 불필요 — --model-path를 바로 가리키세요.

DFlash 드래프트. meta-models/Muse-Glimmer-30B-assistant는 벤더의 네이티브 드래프트 export이며 직접 서빙돼요. 변환 불필요.

GGUF 타깃 모델과 DFlash--speculative-draft-load-format auto가 필요해요. 이 플래그가 없으면 드래프트 모델이 타깃 모델의 gguf 로드 형식을 사용해요. 로더가 드래프트 디렉터리를 거부해요.

Apple Silicon은 GGUF 파일이 아닌 MLX 체크포인트를 사용해요. MLX 백엔드에는 GGUF 경로가 없어요. SGLANG_USE_MLX=1로 세 RadixArk/Muse-Glimmer-*-MLX 아티팩트 중 하나를 서빙하세요(명령 패널의 Apple Silicon 셀 참조). 세 개 모두 같은 플래그를 받으며, q4km-gs128이 측정 라운드가 있는 것이에요. --disable-radix-cache를 유지하세요 — sliding-window 레이어의 windowed KV 저장에 필요하며 — SGLANG_MLX_CACHE_LIMIT_GB=8을 설정해 동시 로드에서 MLX 버퍼 캐시가 풋프린트를 키우지 않게 하세요. 스페큘레이티브 디코딩은 MLX 백엔드에서 사용할 수 없어요.

3. Advanced Usage

3.1 Reasoning

Muse Glimmer는 기본으로 muse reasoning parser를 활성화해요. 이 parser는 reasoning 텍스트를 최종 답과 분리해요.

from openai import OpenAI

client = OpenAI(base_url="http://localhost:30000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="meta-models/Muse-Glimmer-30B",
    messages=[{"role": "user", "content": "What is 15% of 240?"}],
)
msg = resp.choices[0].message
print("Reasoning:", getattr(msg, "reasoning_content", None))
print("Answer:", msg.content)

3.2 Tool Calling

Muse Glimmer는 기본으로 muse tool-call parser를 활성화해요. 이 parser는 message.tool_calls에 구조화된 tool call을 보내요.

3.3 Multimodal

BF16 체크포인트는 이미지 입력을 지원해요. 기본은 텍스트 전용이에요. 전환하려면 위 명령 패널에서 Modality를 선택하세요.

Text only--language-model-only를 추가해요. 이 플래그는 비전 타워를 끕니다. SGLang은 비전 가중치를 빌드하거나 로드하지 않아요. 이는 KV cache용 메모리를 확보해 줘요. SGLang은 이 모드에서 이미지 요청을 거부해요.

Image + text를 선택하면 이미지 입력이 켜져요.

NVFP4, GGUF, MLX 아티팩트는 텍스트 전용이에요. Modality 옵션은 GGUF나 MLX에는 나타나지 않으며, NVFP4는 Text only만 제공해요.

3.4 Apple Silicon (MLX)

MLX 백엔드는 Apple Silicon Mac(48 GB 이상 통합 메모리)에서 세 가지 Muse Glimmer 아티팩트를 서빙해요. 세 개 모두 텍스트 전용이에요 — MLX 백엔드에는 비전 경로가 없고 — 세 개 모두 같은 플래그를 받으므로 명령 패널에서 하나를 선택하세요:

  • RadixArk/Muse-Glimmer-q4-MLX — 아직 측정 라운드 없음.
  • RadixArk/Muse-Glimmer-q4km-gs128-MLX — 벤더의 Q4_K_M (gs128) GGUF의 무손실 리팩: 모든 가중치가 GGUF의 정확한 양자화 코드를 유지하며, 그룹 스케일은 MLX affine bf16(≤2⁻⁸ 상대 반올림)로 다시 표현돼요. 아래 숫자는 이 아티팩트용이에요.
  • RadixArk/Muse-Glimmer-q4k-dynamic-MLX — 아직 측정 라운드 없음.

속도-대-정확도 축을 따라 선택하세요: 풋프린트와 예상 정확도는 q4q4km-gs128q4k-dynamic 순으로 커지고, 디코드 속도는 반대로 움직여요. Apple Silicon에서의 디코드는 메모리 대역폭 바운드라 더 작은 아티팩트가 토큰당 더 적은 가중치 바이트를 읽어요 — 초당 더 많은 토큰, 그리고 KV cache용으로 더 많은 통합 메모리가 남아요. 가장 작은 머신에서 가장 빠른 응답을 원하면 q4, BF16에 가장 가깝게 유지하려면 q4k-dynamic, 중간을 원하면 q4km-gs128을 택하세요 — 세 개 중 측정 라운드가 있는 유일한 것이기도 해요.

이 표는 gs128 체크포인트의 정확도를 보여주며, 벤더 llama.cpp 포크가 같은 머신에서 소스 GGUF를 참조로 서빙해요. GSM8K: 200 문제, no-thinking 채팅 템플릿, temperature 0, 최대 2048 새 토큰. CIMemories: 1 프로필, 전체 콤보, 단일 시도, DeepSeek-R1-0528 judge.

Benchmark SGLang MLX llama.cpp (same GGUF)
GSM8K (200q, no-thinking, greedy) 0.970 0.970
CIMemories — violation rate (lower is better) 0.00% 8.27%
CIMemories — coverage (higher is better) 76.0% 68.4%

CIMemories는 비결정적 judge가 있는 단일 시도 벤치마크예요; 그 행의 SGLang-vs-llama.cpp 차이는 런타임 효과가 아니라 실행 노이즈로 취급하세요. GSM8K 평등은 정확해요.

M5 Pro(64 GB)의 gs128 디코드 처리량, 1k-in/1k-out greedy: batch 1에서 15.3 tok/s, batch 8에서 52.6 tok/s 집계로 상승 — 같은 GGUF 코드에서 batch size 1보다 큰 모든 배치에서 llama.cpp보다 앞서요.