뮤즈 글리머 30B: 24GB로 돌리는 로컬 에이전트

effidev·2026년 8월 11일

Muse Glimmer는 무엇이고 왜 지금 화제인가

2026년 8월 10일, Meta Superintelligence Labs가 30B급 오픈웨이트 모델 Muse Glimmer를 공개했다(Meta 공식 발표). 가중치는 Apache License 2.0으로 배포된다. Llama 계열에서 익숙했던 월간 활성 사용자 수 제한이나 파생 모델 네이밍 요구 같은 커뮤니티 라이선스 조항은 공식 모델 카드에서 확인되지 않는다. 실무 관점에서 이 한 줄이 이번 릴리스에서 가장 큰 변화다. 다만 모델 카드에는 Apache 2.0과 별개로 Usage Policy 링크가 걸려 있고, 그 본문이 어떤 구속력을 갖는지는 확인하지 못했다. 사내 도입을 검토한다면 법무 검토 대상으로 남겨두는 편이 안전하다.

발표된 스펙을 한 줄로 요약하면

30B라는 숫자는 마케팅 표기이고 실제 총 파라미터는 약 29.6B다. dense 구조라 추론 시 전량이 활성화된다. 최근 유행한 MoE 소형 모델들과는 메모리·연산 프로파일이 다르다는 뜻이므로, 벤치마크 점수만 보고 같은 급으로 묶으면 안 된다.

“always-on local agent workflows”에 최적화됐다는 말의 의미

Meta가 이 모델에 붙인 포지셔닝은 범용 채팅이 아니라 상시 구동되는 로컬 에이전트다. 발표 블로그는 “분 단위로 응답하거나 다음 단계를 계획하는 에이전트는 실제 작업 흐름을 끊는다”고 쓰면서, 지연시간·메모리 풋프린트·툴콜 신뢰성·실패 복구를 설계 목표로 명시한다. 특히 실패 복구는 “툴 호출이 실패하거나 예상치 못한 결과를 반환하면 멈추지 않고 원인을 진단해 재시도하도록 학습됐다”고 서술되어 있다. 상시 루프에서 한 번의 툴 실패로 전체가 죽는 문제를 학습 목표로 끌어올린 것이다.

메모리 쪽은 더 구체적이다. 풀 프리시전으로는 55GB가 넘어 소비자 GPU에 들어가지 않지만, 약 4비트 수준으로 압축하면 언어 모델이 20GB 미만으로 줄고, KV 캐시를 포함한 전체 셋업이 24GB 또는 32GB 범위에 들어가도록 맞췄다고 밝혔다. 여기에 DFlash라는 블록 단위 speculative decoding을 얹어 RTX 5090에서 74.9 tok/s를 233.4 tok/s로 끌어올린 수치를 공개했다. 자세한 수치와 하드웨어별 조건은 뒤에서 다시 다룬다.

Muse Spark에서 증류된 파생 모델이라는 계보

Glimmer는 처음부터 독립적으로 학습된 모델이 아니다. 더 큰 교사 모델 Muse Spark로부터 logit distillation으로 사전학습됐고, 이후 롱컨텍스트·에이전트 중심 데이터로 mid-training을, supervised fine-tuning과 on-policy distillation, 강화학습으로 post-training을 거쳤다고 Meta 블로그는 설명한다. 다만 교사 모델인 Muse Spark 자체의 스펙과 공개 여부는 발표되지 않았다. 학습 토큰 수와 데이터셋 규모 역시 어느 1차 출처에도 수치로 제시되어 있지 않다.

커뮤니티 반응이 컸다는 관찰과, 실제로 검증 가능한 근거

공개 직후 Hacker News 상위 노출과 로컬 LLM 커뮤니티의 반응이 크게 관찰됐다. 다만 이는 커뮤니티 정황에 대한 관찰이지 Meta가 발표한 내용이 아니며, 1차 출처로 검증한 사실도 아니다. 반응의 크기 자체보다 검증 가능한 근거를 보는 편이 낫다. 첫째, 라이선스가 Apache 2.0이다. 둘째, 24GB VRAM을 타깃으로 명시한 K-Quant-17GB 변형이 공식 배포 구성에 포함돼 있다. 셋째, 에이전트·툴콜 벤치마크인 MCP Atlas에서 75.5로 Gemma4-31B(54.2), Qwen3.6-27B(62.5)와 격차가 크다. 이 세 가지가 겹치면 “상업적으로 써도 되고, 손에 있는 장비에 올라가며, 에이전트 용도로 쓸 만하다”가 동시에 성립한다.

단, 모든 종목에서 앞선 것은 아니다. 공개된 7개 벤치마크 중 4개에서 1위이고 SWE-Bench Verified와 MMMU Pro는 Qwen3.6-27B가, GPQA Diamond는 Gemma4-31B가 더 높다. 이 부분은 벤치마크 섹션에서 표로 따져본다.

이 글에서는 아키텍처와 스펙, 공개 벤치마크 7종의 실제 승패, 양자화 구성별 메모리 요구량, 실행 방법을 차례로 정리한다. 그리고 1차 출처에 없는 항목, 특히 구세대 24GB 카드에서의 실제 속도처럼 “돌 것 같지만 확인되지 않은” 부분을 명시적으로 구분한다.

스펙을 뜯어보면 무엇이 특이한가

30B급인데 왜 MoE가 아니라 dense인가

Meta 공식 모델 카드가 밝힌 총 파라미터는 약 29.6B다. 발표 블로그의 “30-billion-parameter model”은 반올림 표기이고, 구조는 Dense Causal Transformer에 Perception Encoder가 붙은 형태다. MoE가 아니고, dense이므로 토큰마다 29.6B가 전부 활성화된다.

같은 체급의 최근 오픈웨이트가 대체로 MoE로 가는 흐름을 생각하면 이 선택은 눈에 띈다. MoE는 토큰당 활성 파라미터만 줄여 연산을 아끼지만, 라우팅이 어느 전문가를 부를지 미리 알 수 없으니 가중치는 전량 메모리에 상주해야 한다. VRAM은 결국 총 파라미터 기준으로 잡히므로 MoE의 이득은 주로 연산량 쪽이다. 로컬 단일 GPU가 전제라면 병목은 연산보다 메모리이니, 그 이득이 상대적으로 덜 매력적이다. Meta는 발표 블로그에서 4비트 근사 양자화로 언어 모델을 20GB 미만까지 줄여 24GB·32GB 소비자 GPU 안에 넣는 것을 목표로 했다고만 밝혔고, dense를 택한 이유 자체는 설명하지 않았다. 아래 해석은 어디까지나 스펙에서 읽히는 정황이다.

아키텍처 세부 스펙 표

출처는 모두 P3 모델 카드이며, 컨텍스트 표기만 공식 문서에서 “128K tokens by default; longer contexts supported”로 달리 적혀 있다.

Local·Local·Local·Global 반복과 sliding window 2048이 뭘 바꾸나

주목할 지점은 KV 쪽이다. 첫째, GQA의 Q:KV 비율이 32:2로 16:1이다. KV 캐시는 KV 헤드 수에 비례하므로, 같은 레이어 수·같은 head dim이라면 MHA 대비 캐시가 16분의 1이다. 둘째, 전체 52레이어 중 어텐션 패턴이 local 3 + global 1로 반복된다. 이 패턴이 끝까지 그대로 간다면 글로벌 레이어는 13개, 나머지 39개는 sliding window 2048로 동작한다는 계산이 나온다(레이어 배치 세부는 모델 카드가 패턴만 명시했다).

일반적인 트랜스포머 원리로 보면, 전역 레이어의 KV 캐시는 컨텍스트 길이에 선형으로 커지지만 sliding window 레이어는 윈도 크기에서 상한이 걸린다. 128K를 채워도 로컬 레이어 39개는 2048 토큰 분량만 들고 있으면 된다는 뜻이다. 상시 구동에서 세션이 길어질 때 늘어나는 쪽은 가중치가 아니라 KV 캐시이므로, 24GB 안에 여유를 남기려면 이 증가율을 잡는 것이 관건이다. 다만 이 인과를 Meta가 명시한 적은 없다. 블로그는 24/32GB 봉투 안에 KV 캐시 포함 전체를 넣는 것이 목표라고 했을 뿐, 그 수단으로 어텐션 패턴을 지목하지는 않았다. RoPE θ = 500,000을 local 레이어에만 적용하는 구성 역시 근거는 적혀 있지 않다.

멀티모달과 컨텍스트는 실제로 어디까지 되나

입력은 텍스트와 이미지, 출력은 텍스트다. 비전 인코더는 약 1.8B ViT-G/14로 50레이어, width 1536, patch 14이고 이미지 한 장당 시각 토큰이 최대 4,096개다. 128K 컨텍스트를 기준으로 하면 이미지 한 장이 컨텍스트의 약 3%를 먹는다는 뜻이라, 스크린샷 여러 장을 물리는 에이전트 루프에서는 이 예산을 계산에 넣어야 한다. 참고로 비전 인코더 1.8B가 29.6B에 포함된 값인지 별도인지는 어떤 1차 출처에도 없다. 미확인이다.

학습 토큰 수는 공개되지 않았다

지식 컷오프는 2026년 1월 4일, 학습 데이터는 100개 이상 언어를 포함한다고 모델 카드에 적혀 있다. 그런데 학습 토큰 수와 데이터셋 규모는 블로그, 개발자 모델 페이지, 모델 카드, 공식 문서 어디에도 없다. 데이터 서술은 “공개 데이터, 제3자 제공 데이터, Meta 제품·서비스 정보를 외부 벤더 네트워크와 Meta 인력이 큐레이션했다”는 정성적 문장에서 끝난다. 학습 방법으로 더 큰 교사 모델 Muse Spark로부터의 logit distillation, 롱컨텍스트·에이전트 중심 mid-training, SFT와 on-policy distillation, RL이 언급되지만 여기에도 수치는 붙어 있지 않다.

토큰 수가 없으면 같은 체급 모델과 학습량 대비 효율을 비교할 근거가 없다. 벤치마크 점수만 놓고 “데이터 효율이 좋다”고 말할 수 없다는 뜻이니, 스펙을 평가할 때 이 공백은 그대로 공백으로 두는 편이 맞다.

벤치마크는 실제로 무엇을 말하나

비교 대상부터 짚고 가야 한다. Meta가 표에 올린 상대는 프론티어 폐쇄형 모델이 아니라 Gemma4-31B와 Qwen3.6-27B, 같은 로컬급 오픈웨이트 두 모델이다. 아래 수치는 Meta 공식 HF 모델 카드 기준이고, 그중 MCP Atlas·SWE-Bench Pro·SWE-Bench Verified·AIME 2026 네 항목은 개발자 사이트 모델 페이지에서도 같은 값으로 교차 확인된다.

7개 중 4개다 — “경쟁 모델을 이긴다”는 총평은 어디까지 맞나

Meta 발표 블로그는 두 경쟁 모델을 앞선다는 취지로 결과를 요약한다. 그런데 공개된 표를 그대로 세면 1위는 7개 중 4개이고, 3개는 진다. SWE-Bench Verified와 MMMU Pro는 Qwen3.6-27B가, GPQA Diamond는 Gemma4-31B가 더 높다.

역전 폭 자체는 1~2점대라 “밀린다”고 말할 정도는 아니다. 다만 실무 판단은 총평이 아니라 이 표를 보고 해야 한다. 순수 지식 QA(GPQA Diamond)나 정형화된 이슈 해결(SWE-Bench Verified)이 워크로드의 중심이라면 이 모델이 자동으로 최선은 아니다. AIME 2026(94.7 vs 94.1)과 Charxiv Reasoning(78.8 vs 78.4)의 1위도 소수점 차이라 사실상 동급으로 읽는 편이 안전하다.

MCP Atlas만 격차가 두 자릿수인 이유

7개 중 유일하게 성격이 다른 종목이 MCP Atlas다. 75.5로, 2위 Qwen3.6-27B(62.5) 대비 +13.0, Gemma4-31B(54.2) 대비 +21.3이다. 다른 종목이 대개 1~2점 안에서 붙는 것과 대비된다.

이 편차는 모델의 정체성과 맞아떨어진다. Meta는 mid-training을 롱컨텍스트·에이전트 중심 데이터로 잡았고, post-training에서 스키마 기반 툴 호출과 실패 복구(툴 호출이 실패하면 멈추지 않고 원인을 진단해 재시도)를 명시적 학습 목표로 걸었다고 서술한다. 툴콜 벤치마크에서만 두 자릿수 격차가 나는 것은 그 학습 설계가 반영된 결과로 보는 편이 자연스럽다. 뒤집어 말하면 이 모델의 실질적 우위는 “30B급에서 가장 똑똑하다”가 아니라 “툴을 붙여 돌리는 루프에서 가장 덜 깨진다”에 가깝다. 단발 질의응답 용도로 교체를 검토 중이라면 기대치를 낮춰 잡아야 한다.

공개되지 않은 수치는 무엇인가

두 가지가 비어 있다. 첫째, 블로그는 평가 범주를 “agentic, coding, multimodal, safety, and reasoning”으로 서술하지만 safety 벤치마크의 개별 수치는 어느 1차 출처에도 없다. 범주 언급만 있고 표에는 등장하지 않는다. 안전성 요건이 있는 서비스에 투입할 계획이면 공개 수치로는 근거를 만들 수 없고, 자체 평가가 필요하다.

둘째, GPT·Claude·Gemini 등 프론티어 폐쇄형 모델과의 비교 수치도 공개되지 않았다. 비교군이 로컬급 두 모델로 한정돼 있으므로, 이 표에서 “API 모델을 대체할 수 있다”는 결론은 나오지 않는다. 이 표가 답해주는 질문은 하나다. 24~32GB 안에서 돌릴 오픈웨이트 후보 셋 중 무엇을 고를 것인가.

내 GPU에서 정말 돌아갈까 — VRAM과 양자화

Meta가 공식으로 인정한 VRAM 구간은 세 가지다

Meta 공식 모델 카드는 양자화 구성과 타깃 하드웨어, 품질 저하를 표로 못 박아 뒀다.

발표 블로그의 설명도 같은 방향이다. 가중치를 약 4비트로 압축해 언어모델을 20GB 미만으로 줄였고, 24GB 또는 32GB 봉투 안에 전체 셋업이 들어가게 설계했다고 밝힌다(research.meta.ai). 32GB에서 24GB로 내려가면 저하율은 0.2%에서 1.0%로 다섯 배가 된다. 공짜는 아니라는 뜻이다.

55GB인가 64GB인가 — 숫자가 두 개인 이유

풀 프리시전 메모리는 출처마다 다르게 적혀 있다. 블로그는 “over 55 GB of memory — far more than any consumer GPU offers”라고 쓰고, 모델 카드 표는 같은 BF16을 64GB VRAM으로 적는다. Unsloth의 BF16 GGUF 실파일은 55.7GB다.

55GB대는 가중치 자체의 크기이고 64GB는 KV 캐시까지 감안한 권장 하드웨어로 읽는 것이 자연스럽다. 다만 이 관계를 명시적으로 설명한 1차 출처는 없다. 어디까지나 독해이지 Meta의 서술이 아니다. 실무에서 장비를 사거나 인스턴스를 잡을 때는 64GB를 기준으로 두는 편이 안전하다.

서드파티 GGUF 파일 크기 표

Unsloth GGUF 배포판의 실제 파일 크기는 다음과 같다.

이 표는 Meta 공식 배포가 아니다. Meta가 이름을 붙여 공개한 양자화 변형은 BF16, K-Quant-Dynamic, K-Quant-17GB 세 가지뿐이고, Meta가 GGUF·AWQ·NVFP4 체크포인트를 직접 배포하는지는 확인되지 않았다. 위 크기는 Unsloth가 자기 배포물에 대해 밝힌 값으로만 유효하다.

실행 명령은 마지막 절에 정리했다.

“RTX 3090에서 돌아간다”는 말은 검증된 사실인가

아니다. 이 섹션에서 가장 중요한 대목이다.

커뮤니티에서는 3090이면 충분하다는 이야기가 돈다. 그런데 1차 출처 어디에도 RTX 3090이라는 문자열이 없다. Meta가 실제로 테스트했다고 밝힌 하드웨어는 MacBook M4-Max, M5-Max, NVIDIA RTX 5090 셋뿐이다. NVIDIA 기술 블로그가 다루는 것도 RTX 5090, DGX Spark, DGX Station, Jetson이며 구세대 카드는 아예 언급하지 않는다.

공식이 말하는 것은 “24GB VRAM을 타깃으로 한 K-Quant-17GB 변형이 존재한다”까지다. 특정 GPU 모델명은 없다. 3090이 24GB니까 용량 조건은 충족한다 — 여기까지는 산수다. 하지만 그 산수에서 “구동 검증됨”으로 넘어가는 구간은 출처가 아니라 유추다.

속도는 더 조심해야 한다. DFlash speculative decoding 수치는 Blackwell과 Apple Silicon에서만 측정됐다(자세한 표는 다음 절에 있다). RTX 5090의 3.1배는 5세대 텐서 코어를 갖춘 Blackwell에서 나온 값이다. Ampere 세대에서 같은 배수가 재현되는지는 측정된 바가 없다. 3090을 갖고 있는 독자에게 정확한 표현은 이것이다. 될 가능성은 있으나 공식 보증은 아니고, 특히 속도는 미지수다. 돌려보고 알려주는 것은 각자의 몫이다.

24 / 32 / 64GB, 각 구간에서 무엇을 고르나

선택 기준은 단순하다. 상시 구동하는 에이전트 루프를 돌릴 거라면 32GB 구간의 K-Quant-Dynamic이 균형점이다. 0.2% 저하는 실사용에서 체감하기 어려운 수준인 반면, 24GB로 내려가면 저하가 다섯 배가 되고 128K 컨텍스트를 쓸 여유도 함께 줄어든다. 24GB 카드 한 장으로 버텨야 한다면 컨텍스트 길이를 먼저 줄이고 reasoning strength를 low나 medium으로 낮춰 지연시간을 확보하는 편이 낫다. 64GB 이상을 확보할 수 있다면 양자화 고민 자체를 건너뛰면 된다.

“always-on 로컬 에이전트 최적화”는 구체적으로 무슨 뜻인가

Meta 발표 블로그와 HF 모델 카드를 놓고 보면 이 문구에 걸린 실체는 다섯 축이다. 지연시간, 메모리 풋프린트, 툴콜 신뢰성, 실패 복구, 그리고 추론 강도 제어다.

첫째는 지연시간이다. Meta는 “로컬 에이전트는 반응이 빠르게 느껴질 만큼 충분히 빨라야 쓸모가 있다”고 쓰고, “응답이나 다음 단계 계획에 몇 분씩 걸리는 에이전트는 실제 업무의 흐름을 끊는다”고 덧붙인다. 이를 위해 넣은 것이 DFlash speculative decoding이다. 드래프터가 토큰을 하나씩이 아니라 블록 단위로 통째로 생성하고, 본 모델이 그 블록을 병렬로 검증한다. 공개된 실측치는 다음과 같다.

채팅에서 초당 토큰 수는 체감 편의의 문제지만 에이전트 루프에서는 성격이 다르다. 요청 하나가 계획 수립 → 툴 호출 → 결과 해석 → 재계획으로 디코딩을 여러 번 반복하므로, 1회 생성 지연이 루프 횟수만큼 곱해진다. 사용자는 한 번 기다리는 게 아니라 N번 기다린다. 다만 가속 폭은 하드웨어별로 1.5~3.1배로 갈리니 따로 잡는 편이 맞다.

둘째는 메모리다. 풀 프리시전으로는 55GB가 넘어 어떤 소비자용 GPU에도 들어가지 않는다. 4bit 근사 양자화로 언어 모델을 20GB 미만으로 줄인 이유가 여기 있고, Meta가 겨냥한 목표는 24GB 또는 32GB 범위 안에서 KV 캐시를 포함한 셋업 전체가 돌아가는 것이다. 상시 구동이라는 말이 여기서 성립한다. 매 요청마다 모델을 올렸다 내리면 로딩 시간이 지연에 그대로 얹히므로 프로세스는 계속 메모리에 상주해야 하고, 그러려면 가중치와 KV 캐시가 카드 한 장 용량 안에 동시에 들어가야 한다.

셋째는 툴콜 신뢰성이다. 블로그와 개발자 사이트 모델 페이지는 모델이 넓은 범위의 함수 호출을 다루며 긴 워크플로 전반에 걸쳐 정확한 스키마로 툴을 호출한다고 서술한다. 모델 카드도 schema-based tool invocation이 확장된 멀티턴 워크플로 전반에서 유지된다고 적고, OpenAI 호환 형식의 구조화 JSON 예제를 제공한다. 실무에서 중요한 대목은 “전반”이다. 첫 턴에 스키마를 맞추는 모델은 흔하지만, 20턴째에도 필드명과 타입을 지키는지가 에이전트를 무인으로 돌릴 수 있느냐를 가른다.

넷째는 실패 복구다. “툴 호출이 실패하거나 예상치 못한 결과를 반환하면, 모델은 멈추는 대신 오류를 진단하고 재시도하도록 학습됐다”는 문장이 블로그와 개발자 사이트에 모두 있다. 이게 상시 구동에서 결정적인 이유는 확률 누적 때문이다. 스텝 하나당 툴 실패 확률이 낮아도 수십 스텝을 도는 long-horizon 작업에서는 한 번 이상 실패할 확률이 사실상 1에 수렴한다. 사람이 지켜보는 대화형이라면 멈춰도 사용자가 다시 밀어주면 되지만, 백그라운드 상시 구동에서는 멈춤이 곧 작업 실패다.

다섯째는 추론 강도 제어다. reasoning strength를 low / medium / high / xhigh 4단계로 조절할 수 있어, 같은 모델로 지연과 품질의 균형점을 루프 성격에 맞춰 바꿀 수 있다. 자주 도는 분류·라우팅 단계는 낮게, 계획 수립이나 디버깅 단계는 높게 두는 식의 운용이 가능하다. 모델 카드가 권장하는 샘플링 값은 temperature 1.0, top-p 0.95, top-k 64다.

정직하게 덧붙이면, always-on을 검증하는 데 필요한 숫자 중 상당수는 아직 없다. TTFT, KV 캐시 오프로딩 방식, 백그라운드 상주 시 전력·메모리 프로파일, 세션 간 상태 유지 메커니즘이 1차 출처 어디에도 없다. 런타임 MCP 네이티브 지원 여부도 마찬가지다. 벤치마크 이름으로 “MCP Atlas”가 등장할 뿐 공식 문서에 런타임 지원 서술은 없다. 상시 구동의 실제 비용은 각자 재봐야 한다.

Apache 2.0이라는 선택이 갖는 무게

Llama 커뮤니티 라이선스와 무엇이 다른가

Muse Glimmer 30B는 Apache License 2.0으로 배포된다. 발표 블로그, 개발자 사이트 모델 페이지, HF 모델 카드, 공식 문서 네 곳이 모두 같은 표기를 쓴다. 모델 카드는 가중치뿐 아니라 “모든 아티팩트가 Apache 2.0으로 릴리스된다”고 명시한다.

그동안 Meta의 오픈웨이트 모델을 제품에 넣으려면 월간 활성 사용자 제한, 파생 모델 네이밍 요구 같은 조항이 붙은 Llama 커뮤니티 라이선스를 먼저 읽어야 했다. Apache 2.0에는 그런 조항이 없다. 상업적 사용·수정·재배포·파생물의 비공개 배포가 모두 허용되고, 의무는 저작권 고지와 라이선스 사본 유지, 변경 사실 표기 정도이며 특허 그랜트도 포함된다.

그래도 확인해야 할 조항: Usage Policy와 18세 미만

두 가지는 짚고 넘어가야 한다. 첫째, 모델 카드에는 “Our Usage Policy can be found here”라는 별도 링크가 있다. 이 정책의 본문 내용과 Apache 2.0 대비 실제 구속력은 확인하지 못했다. 라이선스가 Apache 2.0이라는 사실과 별개로, 사내 배포 전에 이 문서를 직접 열어 확인하는 절차는 남는다. 둘째, 모델 카드에 명시된 사용 제한이 하나 있다. “18세 미만 개인이 다운로드하거나 사용하는 것을 의도하지 않는다”는 문장이다. 미성년자 대상 서비스에 붙일 계획이라면 이 문구가 어떤 성격인지 확인이 필요하다.

마지막으로 분명히 해 둔다. Meta가 왜 Llama 커뮤니티 라이선스가 아니라 Apache 2.0을 택했는지에 대한 공식 설명은 1차 출처 어디에도 없다. 발표 블로그는 “permissive Apache 2.0 license로 가중치를 오픈소싱한다”, “기초 AI 연구를 공유해 온 오랜 전통에 따라 오픈웨이트로 공개한다”고만 쓴다. Llama 시리즈와의 관계나 후속 여부, 경쟁 모델 대응 같은 전략적 동기에 대한 서술은 없다. 이유를 아는 사람은 아직 없고, 확인된 것은 라이선스 문구뿐이다.

지금 바로 써보려면

어디서 받고 무엇으로 돌리나

공식 배포처는 meta-models/Muse-Glimmer-30B이고, 문서는 dev.meta.ai/docs/muse-glimmer에 있다. Transformers에서는 멀티모달 모델 클래스로 로드한다.

from transformers import AutoProcessor, AutoModelForMultimodalLM
processor = AutoProcessor.from_pretrained("meta-models/Muse-Glimmer-30B")
model = AutoModelForMultimodalLM.from_pretrained(
    "meta-models/Muse-Glimmer-30B", device_map="auto"
)

채팅 입력은 apply_chat_template()로 role/content 구조를 만들어 넣는다.

런타임 지원 범위는 발표 시점 기준으로 넓다. Ollama, LM Studio, llama.cpp, ExecuTorch, MLX, vLLM, SGLang, NVIDIA NIM이 런치 파트너로 나열되어 있다. 로컬 데스크톱부터 서빙 스택까지 한 번에 커버된다는 뜻이다.

GGUF로 바로 띄우고 싶다면 아래 두 줄이면 된다. 다만 이 파일은 **Meta 공식 배포가 아니라 Unsloth의 서드파티 GGUF 배포판**이다. Meta가 GGUF 체크포인트를 직접 배포하는지는 확인되지 않았다.

llama serve -hf unsloth/Muse-Glimmer-30B-GGUF:UD-Q4_K_XL
ollama run hf.co/unsloth/Muse-Glimmer-30B-GGUF:UD-Q4_K_XL

Meta 공식 양자화 변형명은 BF16(full), K-Quant-Dynamic, K-Quant-17GB 세 가지다.

내 하드웨어에서는 어떤 구성으로 시작해야 하나

샘플링은 모델 카드 권장값인 temperature 1.0, top-p 0.95, top-k 64로 시작하고, reasoning strength는 low/medium/high/xhigh 네 단계 중에서 지연시간과 품질을 보며 고르면 된다.

이 모델을 지금 선택할 상황과 아직 아닌 상황

선택할 만한 경우는 분명하다. 상업 제품에 오픈웨이트 모델을 넣어야 하는데 라이선스 조건 자체를 리스크에서 지우고 싶을 때, 24~32GB 메모리 안에서 툴콜을 반복하는 로컬 에이전트를 상시로 돌려야 할 때, 텍스트와 이미지를 함께 입력으로 받아야 할 때, 네트워크가 없거나 데이터를 외부로 보낼 수 없는 환경일 때다. MCP Atlas 75.5, SWE-Bench Pro 51.2처럼 에이전트·코딩 계열 공개 수치가 비교군보다 앞서는 것도 이 용도와 맞는다.

반대로 아직 미룰 이유도 있다. 코딩 성능만 놓고 보면 SWE-Bench Verified는 Qwen3.6-27B(77.2)가, GPQA Diamond는 Gemma4-31B(85.7)가 더 높다. 전 종목 우위가 아니다. 속도 수치는 RTX 5090과 Apple M4/M5 Max에서만 측정됐고, Ampere 세대 24GB 카드(RTX 3090 등)에서의 실제 속도는 어떤 1차 출처에도 없다. 용량만 보고 “24GB니까 된다”고 판단하는 것은 추론이지 검증된 사실이 아니다. 여기에 Usage Policy 본문과 학습 토큰 수·데이터셋 규모, 런타임 MCP 프로토콜 네이티브 지원 여부가 모두 미공개다. 규제 산업이나 데이터 출처 실사가 필요한 도입이라면 이 공백들이 채워질 때까지 파일럿 수준에서 검증하는 편이 낫다.