메타 뮤즈 글리머 30B 공개 - 로컬에서 돌리는 Apache 2.0 오픈 웨이트 모델

며칠 전 메타가 새 모델을 공개했다는 소식을 봤습니다. 이름은 뮤즈 글리머(Muse Glimmer)였어요.

처음 눈에 들어온 건 30B와 Apache 2.0 조합이었습니다. 요즘 최상위 모델은 성능이 좋아도 집에서 돌리기에는 너무 크고, 작은 로컬 모델은 에이전트로 오래 일시키면 금방 한계가 드러나잖아요.

“30B라면 24GB 그래픽카드 한 장에 진짜 들어가겠는데?”

뮤즈 글리머는 2026년 8월 10일 공개된 약 300억 파라미터의 오픈 웨이트 모델입니다. 일반 채팅보다 로컬 에이전트, 도구 호출, 코딩, 실패 복구 같은 긴 작업에 초점을 맞췄고, 4비트 양자화 모델은 24GB 또는 32GB 메모리 환경을 목표로 합니다.

공식 자료와 모델 카드를 읽고 공개 직후 사용자 후기도 함께 살펴봤습니다. 24GB 그래픽카드 한 장에 30B 모델과 긴 컨텍스트를 넣겠다는 목표가 실제 사례에서도 확인됐고, Apache 2.0 공개에 대한 반응도 컸습니다.

먼저 핵심부터 정리하면

1. 뮤즈 글리머는 약 296억 파라미터의 밀집형 멀티모달 모델입니다. 약 18억 파라미터의 이미지 인코더와 13만 1,072토큰 이상의 컨텍스트를 지원합니다.
2. 메타는 기존 Llama 전용 라이선스 대신 상업적 이용과 수정, 재배포가 가능한 Apache 2.0을 선택했습니다.
3. 공식 17GB 양자화 모델은 24GB VRAM을 목표로 합니다. 공개 직후에도 24GB 그래픽카드 한 장에서 긴 컨텍스트와 DFlash를 함께 사용한 사례가 올라왔습니다.
4. DFlash는 공식 측정에서 생성 속도를 최대 3.1배 높였습니다. 도구 호출과 DFlash를 함께 쓰는 초기 설정은 아직 정리되는 중입니다.

오픈 웨이트로 돌아온 메타

메타는 뮤즈 글리머를 Apache 2.0으로 공개했습니다. 기존 Llama 시리즈의 전용 라이선스 대신 널리 쓰이는 오픈소스 라이선스를 선택했어요. 가중치를 내려받아 상업적으로 사용하고, 수정하고, 재배포하기가 단순해졌습니다.

공개된 항목은 BF16 가중치, 두 종류의 4비트 양자화 가중치, DFlash 보조 모델, 비전 인코더입니다. 학습 데이터 전체와 학습 과정을 재현할 자료는 공개 목록에 없습니다.

뮤즈 글리머는 Apache 2.0으로 가중치와 로컬 실행 구성요소를 공개한 모델입니다.

커뮤니티에서는 이를 메타가 오픈 웨이트 생태계로 돌아온 신호로 받아들였습니다.

뮤즈 글리머 30B는 어떤 모델인가요?

뮤즈 글리머의 언어 모델 본체는 밀집형 인과 트랜스포머입니다. 일부 전문가만 활성화하는 MoE와 달리 전체 모델이 연산에 참여하며, 이미지 입력을 처리하는 약 18억 파라미터의 비전 인코더가 함께 붙어 있습니다.

뮤즈 글리머는 일반 챗봇보다 에이전트 작업에 초점을 맞춘 모델입니다. 메타가 공식 자료에서 강조한 기능은 여러 단계의 계획, 정확한 함수 호출, 도구 실패 후 재시도, 긴 작업 유지, 이미지와 문서 해석입니다.

학습에는 더 큰 교사 모델인 뮤즈 스파크(Muse Spark)의 출력을 이용한 로짓 증류가 들어갔습니다. 사전 학습 뒤에는 긴 컨텍스트와 에이전트 데이터로 중간 학습을 진행하고, 지도 미세 조정과 강화학습, 온폴리시 증류를 섞어 후처리했습니다.

메타는 범용 채팅보다 도구를 여러 번 호출하고 실패를 복구하는 로컬 에이전트 작업에 학습 초점을 맞췄습니다.

30B와 24GB 조합이 중요한 이유

7B와 14B 모델은 적은 메모리로 실행할 수 있고, 12GB 그래픽카드에 들어가는 양자화 모델도 많습니다. 저장소를 읽고 도구를 여러 번 호출하는 긴 작업에서는 더 큰 모델이 필요할 때가 있습니다.

70B급 밀집형 모델은 메모리 요구량이 크게 올라갑니다. 양자화해도 24GB 그래픽카드 한 장에 모델과 긴 컨텍스트를 모두 넣기 어렵고, CPU로 많이 넘기면 생성 속도가 떨어집니다.

30B 전후는 4비트 양자화로 24GB 그래픽카드 한 장을 목표로 할 수 있는 중간 크기입니다.

메타는 모델 본체와 KV 캐시, 이미지 인코더, DFlash 보조 모델을 한 장치에 함께 넣는 구성을 처음부터 목표로 잡았습니다.

공식 양자화 모델은 24GB를 목표로 합니다

메타가 공개한 메모리 기준은 다음과 같습니다.

• BF16 전체 정밀도는 55GB 이상이 필요하고, 목표 하드웨어는 64GB VRAM입니다.
• K-Quant-Dynamic은 32GB VRAM을 목표로 하며, 메타가 측정한 15개 벤치마크 평균 성능 저하는 0.2%입니다.
• K-Quant-17GB는 24GB VRAM을 목표로 하며, 같은 기준의 평균 성능 저하는 1.0%입니다.

17GB는 가중치 파일 크기입니다. 실제 추론에는 긴 대화와 문서를 기억할 KV 캐시, 이미지 인코더, DFlash 보조 모델, 런타임 작업 공간도 들어갑니다.

12GB나 16GB 그래픽카드에서는 일부 가중치를 시스템 메모리에 남겨야 합니다. 실행 자체는 가능해도 속도 손실이 커질 수 있어 공식 목표는 24GB로 잡혀 있습니다.

DFlash는 30B의 속도를 끌어올리는 보조 모델입니다

뮤즈 글리머에는 DFlash 기반의 작은 초안 모델이 함께 제공됩니다. 일반 언어 모델이 한 번에 한 토큰씩 만드는 대신, DFlash가 16개 토큰 블록을 먼저 제안하고 본 모델이 병렬로 검증합니다.

본 모델이 최종 토큰을 검증하고, 초안이 잘 맞는 구간에서만 계산을 줄입니다. 출력 품질을 유지하면서 생성 속도를 높이는 구조예요.

메타의 공식 측정에서는 RTX 5090에서 3.1배, 애플 실리콘에서 1.5~1.8배 빨라졌습니다.

모두 배치 크기 1과 그리디 디코딩으로 측정한 메타의 공식 결과입니다. 다른 양자화나 샘플링 설정, 긴 프롬프트에서는 속도가 달라질 수 있어요.

한 개발자는 M4 Pro에서 8비트 모델을 기본 8.2토큰/초로 실행했고, DFlash를 적용했을 때 내용에 따라 18~26토큰/초를 기록했습니다. 댓글에서는 4비트 초안 모델의 수용률까지 기록해야 정확히 비교할 수 있다는 지적이 나왔습니다.

공식 벤치마크에서는 에이전트 작업이 강합니다

메타는 뮤즈 글리머를 같은 크기의 Gemma 4 31B, Qwen 3.6 27B와 비교했습니다. 일부 대표 항목만 옮기면 이렇습니다.

MCP Atlas와 DeepSearch QA, SWE-Bench Pro에서는 뮤즈 글리머가 앞섭니다. 반면 SWE-Bench Verified, TerminalBench, OSWorld, SkillsBench는 Qwen이 더 높아요.

검색과 도구 호출을 함께 쓰는 에이전트 작업에서는 강점을 보였습니다. 하지만 SWE-Bench Verified, TerminalBench, OSWorld, SkillsBench에서는 Qwen이 더 높았습니다.

이 표는 메타가 공개한 결과입니다. 모델마다 사고 모드와 실행 하네스가 다르고, 독립 재현 결과는 아직 적습니다.

공개 직후 사용자 반응은 어땠나요?

첫 반응은 성능보다 메타의 복귀였습니다

r/LocalLLaMA의 공식 공개 글은 1,700점대 추천과 360개가 넘는 댓글을 받았습니다. 가장 많은 추천을 받은 댓글은 “메타가 돌아와서 반갑다. 더 공개해 달라"는 내용이었어요.

r/unsloth에서도 “메타가 오픈 웨이트를 포기한 줄 알았다"는 반응이 나왔습니다. 모델 점수보다 Apache 2.0 공개와 메타의 복귀를 먼저 반긴 셈입니다.

RTX 3090 한 장에 들어간다는 후기는 확인됐습니다

가장 구체적인 글 중 하나는 RTX 3090 테스트였습니다. 공식 GGUF의 Q4_K_XL 모델과 DFlash, 이미지 프로젝터를 함께 올리고 긴 컨텍스트를 사용해도 24GB 안에 들어간다는 내용이었어요.

같은 글의 한 사용자는 256K 컨텍스트에서 23.6GB VRAM, 초당 54토큰 생성을 기록했다고 공유했습니다. 이미지 인식용 프로젝터 일부를 CPU로 넘긴 설정이지만, 메타가 제시한 24GB 목표와 맞는 결과입니다.

다른 사용자는 F16 KV 캐시가 131K 컨텍스트에서 약 1.8GiB라고 측정했습니다. Qwen 3.6 27B나 Gemma 4 31B보다 긴 컨텍스트를 24GB에 넣기 편하다는 반응도 이어졌고요.

에이전트 작업은 초반치고 괜찮다는 평가가 나왔습니다

M5 Pro에서 로컬 서버와 Hermes Agent를 연결한 사용자는 DFlash를 포함해 약 24GB 메모리를 사용했고, 약 22토큰/초를 기록했다고 밝혔습니다. 도구 호출이 제대로 작동했고, 생성한 코딩 프로젝트도 실제로 실행됐다고 했어요.

r/unsloth의 다른 사용자는 Q4 양자화 모델로 약 1만 토큰을 10분 55초 동안 생성해 15.2토큰/초를 기록했습니다. 단일 HTML 파일로 단순한 마인크래프트 게임을 첫 시도에 실행 가능한 상태로 만들었다는 후기도 남겼습니다.

다만 평가가 모두 한쪽으로 기울지는 않았습니다. 하루 동안 Qwen 3.6 27B와 비교한 사용자는 OpenCode 에이전트에서는 뮤즈 글리머가 더 효율적으로 작업을 끝냈지만, 대부분의 순수 코딩 작업에서는 오히려 약하다고 평가했습니다.

초기 실행 환경은 아직 정리되는 중입니다

출시 당일부터 공식 GGUF가 제공됐지만, 환경에 따라 실행 결과와 설정 방법이 달랐습니다.

이 모델의 도구 호출 형식에는 채널 구분과 ATEM 태그가 들어갑니다. 모델 구조와 함께 추론 파서와 도구 호출 형식을 지원해야 합니다.

DFlash도 공개 초기에는 별도 수정이 필요한 사례가 있었습니다.

모델 공개 다음 날부터 여러 프로젝트에 모델 구조와 도구 호출 지원을 추가하는 PR이 올라왔습니다.

이런 사람에게 잘 맞습니다

• RTX 3090, RTX 4090, RTX 5090처럼 24GB 그래픽카드가 있다
• 맥의 통합 메모리로 30B급 로컬 모델을 돌리고 싶다
• 개인 파일과 작업 기록을 클라우드로 보내지 않는 에이전트가 필요하다
• Hermes Agent, OpenClaw, OpenCode처럼 도구 호출이 중요한 하네스를 쓴다
• Apache 2.0 모델을 제품이나 연구에 활용하고 싶다
• 7B·14B보다 큰 밀집형 모델을 로컬에서 돌리고 싶다

반대로 이런 경우에는 아직 애매합니다

• 설치 직후 모든 환경에서 같은 도구 호출 결과가 필요하다
• 가장 높은 순수 코딩 성공률만 원한다
• 공식 벤치마크보다 장기간의 독립 검증을 더 중요하게 본다
• 최신 실행 환경과 모델 전용 설정을 직접 맞추고 싶지 않다

정리하면

뮤즈 글리머는 약 300억 파라미터의 밀집형 모델입니다. 공식 17GB 양자화 가중치는 24GB 그래픽카드 한 장을 목표로 하고, 라이선스는 Apache 2.0입니다.

24GB 로컬 머신에서 에이전트 작업을 돌리기 위해 만든 30B 오픈 웨이트 모델입니다.

공개 직후 사례에서도 긴 컨텍스트와 DFlash를 24GB 안에 넣는 구성이 확인됐습니다. 검색과 도구 호출을 포함한 에이전트 작업은 강점으로 보였지만, 순수 코딩 품질은 평가가 갈렸고요.

제가 이 모델에서 눈여겨본 건 최고 점수보다 30B, 24GB 목표, Apache 2.0이라는 조합입니다. 메타가 다시 로컬 에이전트 쪽에 선택지를 내놓았다는 점도 반가웠습니다.

순수 코딩 품질과 장기 안정성은 더 지켜봐야 합니다. 공개된 지 며칠밖에 지나지 않았으니까요.

참고 자료

• 메타 뮤즈 글리머 공식 발표
• 뮤즈 글리머 30B 공식 모델 카드
• 뮤즈 글리머 공식 평가 방법론
• r/LocalLLaMA 공식 공개 글과 반응
• RTX 3090 한 장에서 실행한 사용자 후기
• Hermes Agent와 로컬 코딩 테스트 후기
• Qwen 3.6 27B와 비교한 초기 사용자 후기