🦙
Metaの意地を見せたか　Muse Glimmer 30Bの実力を見てみる

Yuichi Tominaga
2026/09/04に公開
生成AIの世界で「オープンウェイトモデルの元祖」といえば、Meta社のLLaMaを思い浮かべる方も多いのではないでしょうか。ところがその後継である最新世代のLLaMa-4は、期待外れの性能から「大失敗」とまで評され、Metaはここ最近苦しい立場に置かれていました。
そんな中、2026年に入って突如登場したのが「Muse」シリーズです。中でも今回取り上げるMuse Glimmer 30Bは、ミッドレンジ帯のモデルとして登場し、ローカルLLM界隈を驚かせたのではないかと思います。
本稿では、このMuse Glimmer 30Bのアーキテクチャを読み解きつつ、実際にGPU環境で動かして、通常のテキスト推論、投機的デコード技術DFlashとの組み合わせ、そしてVision機能まで一通り検証してみます。Metaは本当に雪辱を果たせるのか、その実力を見ていきましょう。

 MetaのリリースしたモデルMuseシリーズ
 現在のOpen Weight LLMの開祖ともいえるLLaMaMeta（Meta AI）の最も象徴的な功績の一つは、LLaMaモデルをオープンウェイトとして公開したことです。

当時、GPT-3.5-Turboのような高性能なチャットモデルは存在していましたが、それらはクローズドモデルであり、一般的なローカルGPUで動作させることは不可能でした。
Metaはこうした状況を打破すべく、LLaMaを無償公開しました。

Version 1では利用規約の制約が厳しく、派生モデルであるAlpacaも商用利用に制限がありましたが、続くVersion 2で制限が大幅に緩和されました。

これにより、多くのユーザーが手軽にLLMを導入できるようになり、大きな脚光を浴びることとなりました。
特にLLaMa 2は、RoPE（Rotary Positional Embedding）[1]やGroup Query Attention (GQA)[2]といった革新的な技術を主要モデルとして初めて採用した点に大きな意義があります。


図1 LLaMa-2のアーキテクチャ
これらの構造は現在も多くのオープンウェイトモデルの標準となっており、llm-jp-4-8b-thinkingといったモデルにもその系譜が受け継がれています。[3]
しかし、LLaMa-3の成功を経て登場した後継モデル「LLaMa-4」は、期待に反する低性能から「大失敗」と評される事態に陥りました。

Metaはこの失敗を認め、研究体制の混乱や研究者の離脱を伴う、近年稀に見る大きな転落を経験しています。

 LLaMaからMuseへ2026年4月、突如MetaはMuse Sparkというモデルを発表します。
このMuse Sparkはクローズドモデルとして登場しており、当時はあまり注目されていませんでしたが、その後1.1が7月に、1.2が8月に登場しており、そのバージョンが上がるにつれて徐々にその性能の高さが知れ渡るようになってきました。
そんな中、Muse Spark 1.2の登場とともに現れたのが、今回のミッドレンジモデルである Muse Glimmer 30Bというモデルです。この登場はローカルLLM界隈を驚かせたのではないだろうかと思います。

 Muse GlimmerのアーキテクチャMuse Glimmerは現在人気のあるオープンウェイトモデルと似た、ハイブリッド構造を持っています。アーキテクチャ図を下図に示します。


図2 Muse Glimmer 30Bのアーキテクチャ構造
ざっくり見た感じ、ブロック配置の構造はQwenに近く、Google DeepmindのGemma-4に比べるとシンプルな構造と言えます。パラメータ数は29.6Bであり、アクティベーション処理にGeLUを使ったDense型のモデルです。

 アテンション構造アテンション構造はGroup Query Attentionをベースにしたハイブリッド構造をとっています。
SAと書いているのは**「Sliding Window Attention」**と呼ばれ、局所的なコンテキスト解析を担います。この層はスライディングウィンドウアテンション構造をとり、解析対象のコンテキスト範囲を明示的に定めることで、メモリ消費の抑制・計算コストの削減を狙います。
FAと書いているのは**「Full Attention」と呼ばれ、こちらは前段のSAの内容を取りまとめ、統括する役割を持ちます。ここは通常と同じGQAとしての動作を行います**ので、SAと比べると比較的重い処理を担うことになります。
3つのSAと1つのFAで構成されたグループが13個、合計52ブロックで構成されています。
これらが3:1の比率で構成されているのはQwen3.5以降の構造に似ていますが、じつはSA・FAそれぞれの働きを見ると役割の観点で似ているのは「局所＋全体」で構成されているGemma-4です。[4]
さらに特徴的なところとして、これらの層に対して、個別にRoPEで使われるθの値を切り替えられるようになっており、SAには50,000が、FAには0が適用されます。
Hugging Faceリポジトリにあるconfig.jsonを見てみるとこのあたりの設定が見えてきます。
{
  "architectures": [
    "MuseGlimmerForConditionalGeneration"
  ],
  "dtype": "bfloat16",
  "image_token_id": 200092,
  :
  :
  :
  "hidden_size": 6656,
  "initializer_range": 0.02,
  "intermediate_size": 19968,
  "layer_rope_theta": [
    500000.0,
    500000.0,
    500000.0,
    0,
    500000.0,
    500000.0,
    500000.0,
    0,
    500000.0,
    500000.0,
    500000.0,
    0,
    500000.0
モデリングソース上では、0になっている場合、RoPEモジュールはNoPE（つまりPositional Encoding処理をしない）と扱うことでPE処理をスキップするようになっていることが確認できました。
Hugging Faceが提供するtransformersライブラリの中の処理で以下の記述があります。
(https://github.com/huggingface/transformers/blob/main/src/transformers/models/muse_glimmer/modeling_muse_glimmer.py)
実は、ファイルとしては別に存在するmodular_muse_glimmer.pyにおいてRoPEのThetaパラメータが0の場合、このposition_embeddingsをNoneにするよう処理が書かれています。そして、実際のモデルの動作を定義するクラスの以下の箇所で、None（つまりNoPE）であればposition_embeddingsに必要な処理を行わないようif分岐が書かれています。
class MuseGlimmerTextAttention(nn.Module):
    :
    :
    def forward(
        self,
        hidden_states: torch.Tensor,
        position_embeddings: tuple[torch.Tensor, torch.Tensor] | None = None,
        attention_mask: torch.Tensor | None = None,
        past_key_values: Cache | None = None,
        **kwargs: Unpack[TransformersKwargs],
    ) -> tuple[torch.Tensor, torch.Tensor | None]:
        :
        :
        # NoPE layers receive `position_embeddings=None` from the model.
        if position_embeddings is not None:
            cos, sin = position_embeddings
            query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin)
        :
        :
完全にFAは統括役に徹する構造にし、それ以外の処理は外して分担の明確化を推し進めた構造を選んだのかなと感じました。

 Vision EncoderVisionモデルはGlimmer Visionと呼ばれているようで、大体この手のエンコーダは、広く使われているSigLIP vision transformer encoderなどが使われることが多い中で、このモデルは独自のVision Encoderを構成しています。
ブロック数**50 = 12(3SA + 1FA) + (1SA + 1FA)**で構成され、その構造は最終の部分だけ異なるものの、ほぼText Decoderと同じ構造をとります。解析結果のベクトルは1024トークン分の情報として扱われ、テキストデコーダに組み込まれる仕組みです。
この仕組みはMuse Glimmerでも紐づけられているMetaの論文「Perception Encoder: The best visual embeddings are not at the output of the network(arXiv:2504.13181v2, 2025/4/28)」で提唱されており、そこで述べられる「Perception Encoder」がベースになっているものと考えられます。
Visionエンコーダの在り方は今年に入って様々なモデルメーカーで色々な方法が試されていて、ここで述べられているような方法もあれば、Gemma-4-12b-itで述べられているような重みデータをCLIPを除いてすべてText Encoder内に封じ込める方法など様々で、単純にSigLIPベースのエンコーダーを入れるケースよりも高い分析能力を有していると言えるのかもしれません。この辺りは検証して確かめたいと思います。

 検証して動かしてみよう！今回、GPUSOROBAN「高速コンピューティング」のNVIDIA RTX A4000が搭載されたインスタンスを用いて検証しました。

 全体構成構成としては以下の通りになります。アクセスサーバとSSHトンネルを張り、そこを通りながら接続先インスタンスへアクセスします。[5] llama.cppのサービスポートは、互いの8001番ポートを介してローカルホストと中継することにします。


図3 接続構成の概要

 使用するインスタンス今回、使用するのはこちらのNVIDIA RTX A4000というGPUです。インスタンスのスペック含めて以下の通り示します。


項目
スペック情報


使用インスタンス種別
s16-1-a-standard-ubs24-v

GPU
NVIDIA RTX A4000

GPUメモリ
GDDR6 16GiB

GPUメモリ帯域幅
448.0 GB/s

演算性能FP32
19.17 TFLOPS

演算性能BF16
38.34 TFLOPS

演算性能INT8
153.4 TOPS

演算性能INT4
306.7 TOPS

vCPU
11 Core

システムメモリ
50 GiB

ストレージ
Persistent 100 GiB

CUDAバージョン
13.2

NVIDIA Driver Ver.
580

OS
Ubuntu 24.04 Server

表1 使用するインスタンスのスペック情報

 使用するモデルファイルMuse Glimmerは4bit量子化を施したモデルでも16GiBを超えてしまいます。KVキャッシュの使用量等も考慮し、今回はUnsloth Dynamic 2.0 で最適化されているモデルの2bit量子化モデルを採用しています。
Unslothからリリースされている Muse Glimmerのリポジトリサイトから、以下のファイル名のファイルをダウンロードしました。


ファイル名
容量
ファイル概要


Muse-Glimmer-30B-UD-IQ2_M.gguf
12.3 GB
UD2.0/2bit量子化モデル

mmproj-kquant.gguf
1.40 GB
量子化されたVisionエンコーダ

dflash-kquant.gguf
1.63 GB
量子化されたDflashドラフトモデル

表2 llama.cppに適用するファイル一覧
llama.cppについては、「version: 10380 (0b1bad14f)」を使用しています。
Muse Glimmerのサポートはすでに「model: Muse Glimmer Support - #26841」にて対応済みの状態でして、このバージョンはそれが含まれています。

 動作検証：通常モードではまず、モデル本体のみを使ってテキスト推論を実行させてみます。

 llama.cppによる起動コマンド以下のコマンドにてWebフロントエンドを呼び出し、検証を行っています。
今回、KVキャッシュは8bit化せずにFP16モードで実行させています。また、メモリ使用状況をチェックするため、logレベルをデフォルトの3から4に引き上げています。
build/bin/llama-server --model ./models/Muse-Glimmer-30B-UD-IQ2_M.gguf -t 12 -np 1 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 --port 8001 --host 0.0.0.0 --fit off --no-warmup --no-cache-prompt -fa on --cache-ram 0 -c 131072 --reasoning on --log-verbosity 4

 メモリ消費量メモリ消費量は以下の通りとなりました。Sliding Windowを使っていることにより、通常のGrouped Query Attentionを使っているモデルと比較すると小さいサイズで済んでいる印象です。


表3 通常モード（メインモデルのみ）におけるメモリ消費量

 出力された内容以下の質問を投げてみて、その応答内容を吟味してみます。
最近熊本地震が発生したこともあり、気になってこういう質問をいろんなモデルにして回ったりしています。
九州の地盤に関してその特徴を述べてください。
応答内容は以下の通りとなりました。ぱっと見の印象は「お、詳しいかも？」でした。
九州の地盤は、日本列島の中でも火山活動と地殻運動が最も活発な地域の一つで、
火山性堆積物と軟弱な沖積層が主体であることが最大の特徴です。

1. 地質構造的・地形的特徴
- 活火山群に囲まれた島弧：日本列島の南西端に位置し、フィリピン海プレー
  トとユーラシアプレートの境界上にある。阿蘇山、桜島、霧島連山、雲仙岳
  など日本有数の活火山が集中し、火山活動由来の地盤が広域に分布する。
- 中央構造線の走行：九州全域をほぼ東西に横断する中央構造線が存在し、
  活断層帯が非常に多い。福岡―熊本―大分に連なる活断層群があり、2016年
  熊本地震の震源となった布田川断層帯・日奈久断層帯などが代表的。
- 山地と狭窄な平野の対比：九州山地に囲まれた内陸部と、有明海・筑後平野、
  北九州、宮崎平野など沖積低地が混在する。平野部は堆積層が厚く、山地部
  は硬質な火成岩が主体。

2. 地盤材料の特徴
- 火山灰・火山噴出物層の広大な分布：阿蘇カルデラの噴出物による阿蘇火山
  灰は九州中部から北部に最大数十〜100m以上堆積。軽石、スコリア、凝灰岩
  質の火山灰は、含水比が高く圧縮性・透水性が大きく、圧密沈下しやすい地
  盤として知られる。
- 沖積層が厚く軟弱：有明海沿岸、筑紫平野、八代平野、都城盆地などの低地
  は、厚い沖積粘土層・砂層・シルト層からなる。N値が低く、支持力に乏し
  い軟弱地盤が広い。
- 火山岩・堆積岩の混在：北部九州は古生代の堆積岩、第三紀の火成岩、御船
  層群など硬質岩が基盤。南部九州は新期の火山岩類が主体で、岩質は硬いが
  風化しやすく崩壊性が強い。

3. 地盤工学的特徴
- 液状化のリスクが高い：埋立地・沿岸の沖積砂層、特に福岡の博多湾沿岸、
  長崎湾、熊本八代湾、鹿児島湾の埋立地や河口部の砂質地盤は液状化を起こ
  しやすい。2016年熊本地震でも液状化被害が多数報告された。
- 地盤の圧縮性と不同沈下：火山灰層と有機質沖積粘土の存在で、建築物の不
  同沈下や道路の陥没、液状化後の長期沈下が課題。地下水位が浅く、地下水
  の変動に敏感。
- 地盤増幅特性：火山灰層・沖積層が厚く柔らかいため、地震動が増幅されや
  すい地域が多い。特に阿蘇カルデラ周辺、筑後平野は長周期地震動の増幅が
  指摘されている。
- 埋立地・改良地が多い都市：北九州、長崎、鹿児島、佐世保など港湾都市は
  歴史的な埋立地で構成され、地盤改良が不可欠なエリアが多い。

地域別の傾向
- 北部九州（福岡・佐賀・大分北部）：筑紫平野の沖積粘土と玄界灘沿岸の埋
  立地が主体。地盤は軟弱で液状化リスク高。
- 中部九州（熊本・大分南部）：阿蘇火山灰層が厚く覆う。火山灰は締まりに
  くく沈下性が強い。
- 南部九州（宮崎・鹿児島）：活火山直下の火山砕屑物と海岸段丘の堆積物が
  混在。地盤は浅い岩盤直下の火山性土壌で、局所的に支持力が高い一方、崩
  壊・噴出物由来の不均質性が大きい。

総じて九州の地盤は「火山活動による多層不均質な堆積物＋厚い軟弱沖積層」
という特徴があり、耐震・地盤沈下・液状化対策が都市開発の主要課題となっ
ています。
GPT-5.6-Lunaを使ったDeepSearchエージェント(Powered by Dify)で評価をさせた結果は以下の通りとなりました。
九州の局所的な特徴をさも全体での様子であるかのような記述上の問題が確認されましたが、完全に内容が相違しているのは中央構造線に関するところ一点のみであり、それ以外はおよそ一括りにすることが問題であるようです。
小規模モデルなどでは、かなり的外れな回答が起きがちな中で、RAGなしでのこの回答はかなり推論力が高いほうだと思います。なにより、通常検証に使用するモデルは4bit量子化したものを用いる中、今回は2bit量子化モデルを使用していますので。
文章の大筋は妥当ですが、九州全域を一つの地盤特性で説明している点に注意
が必要です。

特に、次の記述は修正が必要です。
- 「中央構造線が九州全域を横断する」：九州における中央構造線の有無や位
  置には複数の見解があり、このように断定できません。
- 「フィリピン海プレートとユーラシアプレートの境界上にある」：九州はプ
  レート運動の影響を受けますが、単純なプレート境界上と表現するのは不正
  確です。
- 「阿蘇火山灰が九州中北部に最大100m以上堆積する」：降下火山灰、火砕流
  堆積物、再堆積物を区別しておらず、広域に一律100m以上堆積するようにも
  読めます。
- 「火山灰は圧縮性と透水性が大きい」：火山灰、軽石、火砕流堆積物では性
  質が異なるため、一括りにはできません。
- 「南部九州は火山岩が主体」：シラス、堆積岩、沖積層、海岸段丘なども広
  く分布します。
- 「港湾都市は埋立地で構成され、地盤改良が不可欠」：埋立地は一部であり、
  地盤改良の必要性は地盤条件や建物によって異なります。

一方、次の内容は概ね正しいです。
- 九州には活火山と活断層が多い。
- 有明海沿岸、筑紫平野、熊本平野などには軟弱な沖積層が分布する。
- 埋立地、旧河道、河口低地では液状化を検討する必要がある。
- 熊本地震では布田川断層帯と日奈久断層帯が活動し、液状化被害も発生した。
- 有明海沿岸では軟弱地盤による圧密沈下が問題となっている。

したがって、結論は次のようにまとめると正確です。
九州は、火山性堆積物、岩盤、沖積層、埋立地が地域ごとに異なる地盤を形成
している。火山灰や沖積層を九州全域の特徴とせず、地形と地質を地域別に区
別して、沈下、液状化、斜面崩壊、地震動増幅を評価する必要がある。

 パフォーマンス速度パフォーマンスとしては以下の通りで、およそ出力速度は22.52 tps を記録しています。やはりそれなりのサイズのモデルであるため、出力速度は9-12Bモデルと比較すると低い部類になりますが、そこまで「遅い！」というレベルの速度ではないようにも感じます。ただ、推論レベルを引き上げたりすると、回答を得るまでに少し時間を要するかもしれません。
prompt eval time =     262.18 ms /    68 tokens (    3.86 ms per token,   259.37 tokens per second)
       eval time =   82874.28 ms /  1866 tokens (   44.41 ms per token,    22.52 tokens per second)
      total time =   83136.46 ms /  1934 tokens

 動作検証：DFlashを使用する場合Muse Glimmerはリリース時点からDFlashに対応しており、Unslothのリポジトリにも専用のドラフトモデル(dflash-kquant.gguf)が用意されています。--model-draftで組み込んで、通常モードと同じ質問を投げてみました。
結果、出力速度は22.52 tpsから17.80 tpsへと低下し、トークン受け入れ率(Acceptance)も15.7%(mean_len 1.94)にとどまるという、あまり振るわない結果になりました。
この投機的デコード技術がどのような条件なら効果を発揮するのか(あるいは発揮しないのか)については、後続の検証記事で改めて掘り下げる予定です。

 動作検証：Visionを使用する場合Muse GlimmerはVisionエンコーダも備えており、Unslothのリポジトリに専用のmmprojファイルが配置されています。先のDFlash検証時にこのVisionエンコーダを組み込もうとするとOOMとなりエラー終了しましたので、今回それぞれ別のシチュエーションを作って実行することになりました。

 コマンドラインbuild/bin/llama-server --model ./models/Muse-Glimmer-30B-UD-IQ2_M.gguf -t 12 -np 1 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 --port 8000 -c 131072 --reasoning on --log-verbosity 4 --mmproj models/mmproj-kquant.gguf

 メモリ消費量メモリ消費量は以下の通りで、およそ1,336 MiB程度のメモリ上昇を確認しました。


表5 Visionエンコーダ有効化時のメモリ消費量

 質問と出力の内容通常モードの推論とは異なり、画像を添付してそれに対する質問をすることで分析能力を測ってみることにしました。
そこで、以下の画面を分析させました。先にも出ていたMuse Glimmerのモデル構造図をそのまま添付[6]し、「詳細分析し、何が書かれているかについてその詳細を述べよ」としています。


図5 Vision Encoderに読み込ませた画像
結果は以下の通りとなりました。
このスライドは「参考：MUSE GLIMMER 30Bの構造」というタイトルで、MUSE
GLIMMER 30Bというモデルアーキテクチャの仕様と全体のデータフローを図解
したものです。

【左側の仕様一覧】
- Denseタイプの29.6Bモデル
- HiddenSize：6,656（アクティベート関数:SwiGLU、次元数19,968）
- LNR：Linear Layer
- RoPE：θ値=50,000。FullAttentionには適用しないのが特徴。FAに対しては
  θを0とすることでNoPEとして不適用を指示できる構造
- Max Context：128k tokens (131,072 tokens)
- DFlashベースのDrafterあり、MTP可能

【右側の用語解説】
- SA：Sliding Attention
  - GQAベース。Sigmoid output Gate付
  - スライディングウィンドウによる局所的コンテキストの解析を担当
  - 計算コストが低く、高速動作
  - メモリ使用量が少ない
- FA：Full Attention
  - GQAベース。Sigmoid output Gate付。
  - Sliding Attentionの情報を集約・統合
  - 全体構造の維持、複雑な推論に対応する。
  - Positional Encodingを使用せず、位置的な情報はSliding Attentionにお
    任せ

【中央のブロック図の流れ】
入力文字列Input stringsがtokでトークナイズされEmbで埋め込みになる。埋
め込みにはRoPEが加算される。別系統で画像アイコンからGlimmer Visionが
入力を受け、出力は埋め込み＋RoPEの直後で加算される。

その後の言語モデル本体は全体で52ブロック構成と書かれている。
52 blocks = 4 layers x 13 groupsである。

1グループはSA→SA→SA→FAの順で並び、青色がSA、赤色がFA。
このグループが13個並列にチェーンされている。

グループの最後はLNRで正規化され、Soft Maxを経てOutput Probabilities
が出力される。

要するに、埋め込み＋Vision特徴＋RoPEを入力とし、SAを3回繰り返して局所
解析を行った後にFAで集約・統合する4層構造を13グループ×4層＝52ブロッ
ク繰り返すDense型因果モデルで、Visionエンコーダも同様のDense構成の
50ブロック、コンテキスト128k、SwiGLU、RoPEをFullAttentionでは不使用
にできる等の特徴を持つ、という構成図です。
内容としてはほぼ誤りがなく、細かいところで問題は起きてはいるものの、その分析能力は高いと判断しました。それぞれの記述が何を意味していて、どうつながっていて、FullAttention構造がNoPEとなっている点も含めてその特徴が捉えられています。

 調査：世間が見る性能値として性能情報を公開しているArtificial Analysisにて、他モデルと比べて性能がどうか、それを確認してみます。Intelligence項目をベースにグラフを整理した結果は以下の通りです。


図6 Artificial AnalysisにおけるIntelligenceグラフ（表示対象のモデルは当方でカスタマイズ）
Meta Glimmer 30Bのスコアは35となり、オープンウェイトモデルの30B前後のパラメータ量を持つモデルと比較するとかなり高い能力を有していると表示されています。私の場合、あまりコーディングタスクは行わないこともあり、コーディング特化系やエージェント特化系モデルは載せないためこの内容になっているんですが、その中においては少なくともQwen3.5、Gemma-4よりも上の性能が確保できそうだということが確認できました。
同時にびっくりしたのは、これの元になったであろう現行Meta Sparkの性能の高さです。Claude 5 Fableと大して性能差がないのは驚きです。短期的なアップデートでここまで性能を発揮していること、そして今後Meta社からこのモデルのオープンウェイト化の話題も上がってきていることから、まさに今後が楽しみと言えるでしょう。長い時間をかけて苦しんで誕生したMuseシリーズですが、果たしてMetaは雪辱を果たすことができるか、本当に楽しみです。

 まとめ本稿では、MetaがリリースしたMuse Glimmer 30Bのアーキテクチャ分析および簡易チャットによる動作確認を行い、その性能を評価しました。評価の結果、Muse Glimmer 30Bはミッドレンジモデルとして非常に有望であると判断しています。
そのアーキテクチャはここ最近リリースされているハイブリッド＝アテンションモデルの中でより性能が実証されている「局所＋統括」的な仕組みを堅実に固めつつ、それでいて統括役のAttention構造にはRoPEを適用せず、統括としての役割を無駄なくこなすという、より洗練された仕組みが組まれていることが分かりました。
加えて、Vision EncoderについてもMeta独自に開発したPerception Encoderをベースにした独自Encoderを採用しており、その性能の高さが確認されました。
このモデルのライセンスはApache 2.0であり、Tokens As A Serviceの提供を検討している開発者にとって、有力な選択肢となるのではないでしょうか。この辺りは完全にGemma-4の独壇場だったため、Google DeepMindにしてみれば新たな脅威がやってきたと考えてもよいのではないかと思われます。
並行して、Muse Spark 1.2の性能も高く評価されています。これは、LLaMa-4シリーズの汚名をそそぐ象徴的なモデルとなったことを示すものかなと私は考えます。

Metaは再びフロンティアモデルの領域で大きな影響力を持つ可能性があり、今後の動向を私自身注目しているところです。
それにしてもやっぱりもう少しVRAM容量の大きなGPUを手元に置きたいなと。現在GPUの価格は日ごとに高騰している状況ではありますが、こうしたミッドレンジモデルまでは手元で自由自在に扱えるようにしておかないと、わからないことが多すぎるのがこの領域を調査するうえで悩ましいところだなぁと日々感じ入るところです。

 参考文献Muse Glimmer 30Bリポジトリ(Hugging Face)

https://huggingface.co/meta-models/Muse-Glimmer-30B
Perception Encoder: The best visual embeddings are not at the output of the network

Daniel Bolya, Po-Yao Huang, Peize Sun, Jang Hyun Choら著

https://huggingface.co/papers/2504.13181

https://github.com/facebookresearch/perception_models
Muse Glimmer モデルコードのソース(GitHub)

https://github.com/huggingface/transformers/tree/main/src/transformers/models/muse_glimmer
llama.cpp PR26841

https://github.com/ggml-org/llama.cpp/pull/26841
Artificial Analysis

https://artificialanalysis.ai/

脚注
RoPEを最初に導入したのは、BERTに近いTransformer型の言語モデルである(RoFormer)というモデルです。(https://arxiv.org/pdf/2104.09864) ↩︎
GQAを最初に導入したのは、GQAのロジックを論文として発表したGoogle ResearchのT5-XXLです。(https://arxiv.org/abs/2305.13245) ↩︎
llm-jp-4-8b-thinkingには、その構成ファイルconfig.jsonにて、アーキテクチャが「LlamaForCausalLM」と示されており、LLaMa-2系列であることを示しています。ただし、トークナイザには独自のものを使用しています。語彙力はけた違いに向上しており、その性能はオリジナルをはるかに凌駕しています。 ↩︎
Qwenの場合、Gated Delta Networkが全域の情報を一気におさえ、Gated Attentionは全体のノイズフィルタとして情報をなめしていく構造となっており、じつはMuse Glimmerとは全く異なる構造をしていることが言えます。最近の構造を見ていると、若干の構造の差異はあれど、NVIDIAのMambaシリーズやLFMも局所情報の取得方法は異なれど、基本はMuse GlimmerやGemma-4が採用している「局所＋統括」構造のほうがトレンドとなっているようです。 ↩︎
こちらの詳細については、拙著「GPUSOROBANを使う(https://www.bluecore.net/archives/242)」を参照してください。 ↩︎
この画像は、先のページで表示させていたモデル図より前の版を使用しました。 ↩︎
項目	スペック情報
使用インスタンス種別	s16-1-a-standard-ubs24-v
GPU	NVIDIA RTX A4000
GPUメモリ	GDDR6 16GiB
GPUメモリ帯域幅	448.0 GB/s
演算性能FP32	19.17 TFLOPS
演算性能BF16	38.34 TFLOPS
演算性能INT8	153.4 TOPS
演算性能INT4	306.7 TOPS
vCPU	11 Core
システムメモリ	50 GiB
ストレージ	Persistent 100 GiB
CUDAバージョン	13.2
NVIDIA Driver Ver.	580
OS	Ubuntu 24.04 Server
ファイル名	容量	ファイル概要
Muse-Glimmer-30B-UD-IQ2_M.gguf	12.3 GB	UD2.0/2bit量子化モデル
mmproj-kquant.gguf	1.40 GB	量子化されたVisionエンコーダ
dflash-kquant.gguf	1.63 GB	量子化されたDflashドラフトモデル
株式会社ハイレゾPublication
株式会社ハイレゾの技術ブログです。国内GPUクラウド「GPUSOROBAN」の開発・運用で得た知見を中心に発信します。
MetaのリリースしたモデルMuseシリーズ

現在のOpen Weight LLMの開祖ともいえるLLaMa

LLaMaからMuseへ

Muse Glimmerのアーキテクチャ

アテンション構造

Vision Encoder

検証して動かしてみよう！

全体構成

使用するインスタンス

使用するモデルファイル

動作検証：通常モード

llama.cppによる起動コマンド

メモリ消費量

出力された内容

パフォーマンス

動作検証：DFlashを使用する場合

動作検証：Visionを使用する場合

コマンドライン

メモリ消費量

質問と出力の内容

調査：世間が見る性能値として

まとめ

参考文献

Discussion
