【Inkubus開発日記】同じ35B級なのにQwen3.5はGemma4の3.5倍速い? dense vs MoE を実測で深掘り(v2.8 メンバー先行版つき)

私は Inkubus という、ローカル LLM(Ollama)で小説を書かせるツールを作って note で販売しています。ローカルで動くので検閲がなく、エロも含めて自由な題材の小説を、夜のあいだに何十本も書かせられるのが売りです。いまは次のバージョン(v3 系)に向けて、生成速度のベンチマーク機能を開発しているところです。

今日はその開発中に見つけた、妙な数字の話をします。同じくらいのサイズのモデルなのに、生成速度が3.5倍違う。結論だけ先に言うと、犯人は「dense と MoE」というモデル構造の違いでした。

ローカル LLM を使っていて「このモデル、サイズのわりに妙に速いな(遅いな)」と感じたことがあれば、たぶんこれが正体です。

記事の後半に、Inkubus v2.8 のベンチマーク機能の紹介と、メンバーシップ向けの先行版配布があります。本文は全部無料で読めます。

きっかけ: ベンチマーク画面の妙な数字

作っているのは、ジョブ画面で「ビデオカード × モデル」の生成速度を比較する画面です。自分の生成履歴から実測値を集計して横棒グラフにするだけの、シンプルな作り。

で、RTX 5090 で走らせた履歴を並べたら、こうなりました。

• gemma4:31b(QAT) … 66.1 tok/s(トークン/秒)

• qwen3.5:35b … 230.7 tok/s

• qwen3.6:35b … 233.4 tok/s

Qwen のほうが3.5倍速い。

おかしくないですか。gemma4 は 31B、Qwen は 35B。パラメータ数はむしろ Qwen のほうが大きいのに、速度は圧勝しています。同じ GPU、同じ Ollama、同じ量子化レベル(Q4)です。

最初は「API の呼び方の違いかな」と疑いました。Qwen は thinking(思考モード)を持っているので、そのへんの差かなと。この予想、半分だけ当たっていたのですが、それは後半で。

種明かし: Qwen 35B は「実は3Bで動いている」

調べていくと、答えはモデルの構造にありました。

gemma4:31b は dense(デンス)と呼ばれる構造で、1トークン生成するたびに 31B のパラメータが全部計算に参加します。名前どおりのサイズで動く、昔ながらのモデル。

一方 qwen3.5:35b は MoE(Mixture of Experts)という構造でした。モデルの中に「エキスパート」と呼ばれる小さな部品がたくさん入っていて、トークンごとに「今回はこの部品とこの部品だけ使う」と少数を選んで動かします。総パラメータは 35B ですが、1トークンあたり実際に動くのは約 3B だけ。

つまりこの比較、「31B vs 35B」に見えて、実態は「31B vs 3B」の勝負だったわけです。そりゃ速い。

なぜ「動くパラメータが少ない=速い」のか

ローカル LLM の生成速度は、ほぼ「1トークンごとに VRAM から読む重みの量 ÷ メモリ帯域」で決まります。計算そのものより、重みを読む時間がボトルネックなんですね。

dense 31B は Q4 量子化で毎トークン約 18GB を読みます。MoE の実効 3B なら約 2GB。読む量が9分の1なら、3〜4倍速いのはむしろ物理として順当です。

ただし、いいことばかりではありません。使わないエキスパートも VRAM には全部載せておく必要があるので、メモリは総パラメータ分(22GB)食います。「VRAM は 35B 並みに食うのに、速度と賢さは小さいモデル寄り」。MoE はそういうトレードオフの生き物です。

モデル名からは見分けられない、という罠

ここが今日いちばん言いたいところなのですが、この違い、Ollama のモデル名からは読み取れません。

qwen3.5:35b という公式タグには MoE の気配がゼロです。私が気づけたのは、たまたま別で試していた派生モデルの名前に Qwen3.5-35B-A3B と書いてあったから。この A3B が「Active 3B(実効3B)」の意味で、MoE の実効パラメータを表す流儀です。

しかも「gemma は dense、Qwen は MoE」という単純な話でもありません。逆のペアが普通に存在します。

• gemma4:26b … 実は MoE(総 25.2B・実効 3.8B。正体は 26b-a4b)

• qwen3.6:27b … こちらは dense

同じファミリーの中に dense と MoE が混ざっていて、タグ名は総パラメータしか教えてくれない。「B 数が近いから同格」という感覚は、もう当てにならなくなっています。

見分け方

確実なのは ollama show です。

ollama show qwen3.5:35b

これで architecture の欄を見ると、qwen35moe と出ます。moe と書いてあれば確定。gemma4:31b なら gemma4 とだけ出ます。

ただし、ひとつ注意。moe と出なくても dense とは限りません。実は gemma4:26b(MoE)の architecture は gemma4 のままです。名前に moe を入れるのは Qwen 側の流儀でした。怪しいときは Ollama の API で詳細を見ます。

curl http://localhost:11434/api/show -d '{"model":"gemma4:26b-a4b-it-qat"}'

MoE なら model_info の中に expert_count(エキスパートの数)が入っています。gemma4:26b で実際に叩くと expert_count = 128、expert_used_count = 8。128 個のエキスパートのうち毎トークン 8 個を使う、という中身がここで確定します。

もうひとつ、embedding length も手がかりになります。Qwen 35B は 2048 で、dense の 31B(5376)よりずっと細い。35B もあるのにこの細さは dense ではあり得ない数字なので、それだけでも見分けの材料になります。

あとは身も蓋もない方法ですが、速度から逆算するのも有効です。dense 35B が RTX 5090 で 233 tok/s は物理的に出ません。サイズのわりに速すぎたら MoE を疑う。

もうひとつの罠: thinking トークン

冒頭で「予想が半分当たっていた」と書いた件です。ここは事実と推定を分けて書きます。

まず仕様の事実。Ollama の公式ドキュメントに「thinking(回答前の思考)は、対応モデルでは CLI・API とも既定で有効」と明記されています。思考の中身は本文(content)とは別のフィールド(thinking)で返る仕様なので、画面や保存された小説には出てきません。

https://docs.ollama.com/capabilities/thinking

次に手元での実測。think を指定せずに、ローカルの Ollama へ短い質問を直接投げてみます。

curl http://localhost:11434/api/chat -d '{
  "model": "gemma4:26b-a4b-it-qat",
  "stream": false,
  "messages": [{"role":"user","content":"日本の夏の季語を3つ、それぞれ一文の説明つきで教えてください。"}]
}'

返ってきた message の抜粋がこれです。

"message": {
  "role": "assistant",
  "thinking": "* Topic: Summer kigo (season words in haiku) in Japan.
              * Quantity: 3 kigo. …(このあと2,000字続く)",
  "content": "日本の夏の季語を3つご紹介します。1. 蝉(せみ)…(85字)"
}

Qwen 系だけでなく gemma4 も、content(本文)とは別に thinking を返してきました。85字の答えのために、裏で2,000字も考えている。しかも思考は英語です。31b(dense)でも同じことを確認しました。thinking は Qwen 固有の機能ではなく、手元のモデルはどれも既定でオンでした。

そして本題。生成トークン数(eval_count)に対する本文の文字数の比率を取ると、モデルの性格がはっきり出ました。

• gemma4:31b(dense) … ほぼ 1.0(1トークン ≒ 1文字)

• gemma4:26b(MoE) … 0.55〜0.62

• qwen3.5 / 3.6 系 … 0.35〜0.55

本文にならなかったトークンの正体が思考分、というのが私の解釈です(eval_count に思考が含まれるかは公式に明記がないので推定)。gemma4:31b は執筆中ほぼ考えず、Qwen 系はトークンの半分以上を思考に使っている。GPU は本当に 233 tok/s で回っているけれど、その大半は読者に届きません。「小説が書き上がる速度」の字/秒で測り直すと、gemma4:31b(QAT)60.0 に対して qwen3.5:35b は 70.9。3.5倍あった差が、1.2倍まで縮みました。

Inkubus のベンチ画面に tok/s と字/秒の2モードを付けたのは、この両方を見たかったからです。

罠は3つめもある: 書く前の時間は速くならない

字/秒が縮む理由は、実は thinking だけではありませんでした。字/秒の分母は「1本できあがるまでの時間全部」で、モデルを VRAM に読み込む時間と、入力(原作や指示)を読む時間が入っています。tok/s が測るのは「トークンを吐いている時間」だけ。そしてこの準備の時間は、出力がいくら速くなっても縮みません。

MoE は、書くのは小型モデル並みに速いのに、準備は大型モデルのまま。書くのが速くなるほど、準備の時間が割合で目立ってきます。実測だと、gemma4:26b(MoE)は同じ tok/s なのに、モデル読み込みを含む1本目が字/秒 50、2本目が 104 と2倍違いました。dense の 31B は 53 → 57 でほぼ動きません。準備の秒数自体はどちらも大差なくて、効くのは「書く時間との比率」です。

なので「MoE は3.5倍速いから、一晩で3.5倍書ける」とはなりません。手元でベンチを取るなら、1本目は捨てて2本目以降で。Inkubus のベンチ画面にも、字/秒には読み込みの時間が含まれる旨の注釈を入れました。

追試: dense 同士でぶつけてみた

ここまでの話が本当なら、dense 同士で比べれば 3.5 倍の差は消えるはずです。ちょうど Qwen3.5 には 27B の dense 版があるので、同じ RTX 5090・同じ条件でぶつけてみました。

• gemma4:31b(dense) … 65 tok/s

• qwen3.5:27b(dense) … 73 tok/s

ほぼ互角。27B のほうが少し小さい分だけ速い、という物理どおりの並びです。3.5倍の差はきれいに消えました。あの差はメーカーの腕前ではなく、構造(MoE)の差だったと確認できたことになります。

ファミリーの中で dense と MoE を比べても、同じ絵になります。qwen3.5 は 27b → 35b(MoE)で 73 → 229 と 3.1 倍。gemma4 は 31b → 26b(MoE)で 65 → 195 と 3.0 倍。どちらの家でも「MoE 化でおよそ3倍」でした。

もうひとつ、意外な発見もありました。字/秒(実際に小説ができあがる速度)で見ると、この qwen3.5:27b が今回測った中で最下位だったんです(30〜38 字/秒)。dense の遅さに、Qwen の思考の多さが重なった結果です。「じゃあ dense 版の Qwen なら実効も速いだろう」とはならない。構造と思考量は、別々の性格として効いてくるわけです。

品質のほうも、同じ物差しで見ておきました。ちょうど直前の記事で、5つのモデルに同じ作品案・同じ条件で官能長編を書かせて、日本語の品質を比べたばかりでした。

その同じ作品案を dense 版 Qwen にも書かせてみました。結果は 35B(MoE)とほぼ同じ弱点の並びでした。「〜のだ」語尾が3割、段落の字下げはゼロ、地の文に中国語の癖が漏れる(「微微と動いていた」、極めつけは「私は永遠にあなた们的奴隷です」)。章見出しの形式ミスに加えて、最終段落に「次章では彼女の弱みがさらに深く利用されていく様子が描かれるだろう」というメタな予告文まで出ました。英語の混入がゼロで文量が多いのは良い点ですが、総合では 35B と同格です。

1本ずつの比較なので傾向値ですが、切り分けとしては十分でした。速度の差は構造(dense か MoE か)で決まり、日本語の品質はファミリー(何をどれだけ学習したか)で決まる。別々の軸です。

で、どっちがいいのか

速度だけなら MoE の勝ちです。ただ、私の用途(日本語の長編小説を書かせる)だと話は単純ではありませんでした。さっき品質のところで書いたとおり、同一条件で比べると gemma4:31b(QAT)が頭ひとつ抜けていて、Qwen 系は癖が目立つ。同じ VRAM を使うなら、賢さは dense に分がある。これも「実効 3B vs 31B」と考えれば納得がいきます。

なので今のところ、私の中の整理はこうです。

• 同じ VRAM で比べると … MoE が速く、dense が賢い

• 同じ速度で比べると … MoE の対戦相手は一回り小さい dense(35B-A3B なら 12B あたり)

• 速い・賢い・VRAM 軽い … 3つ同時には取れない

どれを優先するかは用途次第。私は小説の品質を最優先にしたいので、遅くても gemma4:31b の QAT 版が主力です。ベンチで遅い順ソートを既定にしたのも「遅い=重い=たいてい賢い」ので、重要なモデルが上に来るからでした。

QAT 版に行き着いた経緯は、以前の文字化け検証の記事に書いています。

そもそも、なぜ MoE が増えているのか

ここからは少し引いた話を。

Transformer の元の形は dense です。GPT-3 も Llama も、少し前まで主要なモデルはほぼ全部 dense でした。一方 MoE のアイデア自体はかなり古くて、元をたどると 1991 年の論文「Adaptive Mixtures of Local Experts」(Jacobs・Jordan・Nowlan・Hinton)まで遡ります。これを現代の巨大ニューラルネットに持ち込んだのが 2017 年の Sparsely-Gated MoE(Shazeer ら)、Transformer に組み込んで一気にスケールさせたのが Google の Switch Transformer、そしてオープンなモデルとして広く使われるきっかけになったのが 2023 年末の Mixtral 8x7B です。つまり dense が本流で、MoE は後から実用化された効率化の仕掛け、という順番です。

それがいま、大きいモデルほど MoE が標準になりつつあります。理由は経済です。学習も推論も、コストはほぼ実効パラメータに比例します。MoE は賢さの容量(総パラメータ)を増やしながら1トークンあたりの計算費を抑えられるので、クラウドで大量のリクエストをさばく側から見ると圧倒的に得なんですね。

Qwen3.5 の家系図が、この流れをそのままなぞっています。

• 0.8B / 2B / 4B / 9B / 27B … dense

• 35B-A3B / 122B-A10B / 397B-A17B … 全部 MoE

27B が dense の最終形で、そこから上は MoE しか作らない。そういう設計方針です。

で、面白いのはここからなのですが、ローカルだけは事情が逆なんです。クラウドの制約は計算費、ローカルユーザーの制約は VRAM。MoE は使わないエキスパートも VRAM に全部載せるので、ローカルでは MoE の弱点(メモリ効率の悪さ)が直撃します。クラウドの都合で MoE 化が進むほど、「同じ VRAM に載せるなら dense のほうが賢い」というローカル民の事情とのねじれが広がっていく。

今後、大型帯は MoE しか出ないファミリーが増えていくはずです。そうなるほど「タグの B 数だけ見て比べる」は通用しなくなります。

早見: モデルが MoE かどうかを見分ける

最後に、今日の話をチェックリストにしておきます。

1. 名前に A3B / a4b / 8x7B があれば MoE(A◯B = 実効◯B)

2. ollama show で architecture に moe とあれば確定(無くても dense とは限らない。API の /api/show に expert_count があれば MoE)

3. embedding length がサイズのわりに細ければ怪しい

4. サイズのわりに速すぎたら MoE を疑う(dense 30B 級が 200 tok/s は出ない)

5. tok/s と「本文の文字数/秒」は別物。思考の多いモデルは後者が大きく落ちる

実測の裏取りとしては、Hugging Face 公式リポジトリの議論も参考にしました。RTX 5090 + vLLM で 194〜197 tok/s という報告があり、手元の実測(223〜233 tok/s、Ollama/Q4_K_M)と同じ水準です。

https://huggingface.co/Qwen/Qwen3.5-35B-A3B-GPTQ-Int4/discussions/3

Inkubus v2.8: 新機能ベンチマークの紹介

今回の実測に使ったのが、Inkubus v2.8 のベンチマーク機能です。ジョブ画面に「ベンチマーク」タブが増えていて、正式版 v3.0 にもこのまま入る予定です。

• 接続先(ビデオカード)× モデルの生成速度を、自分の生成履歴から集計して横棒で比較します

• 表示は tok/s(実測)と字/秒の2モード。この記事で書いた「罠」は、この2つの数字の差をどう読むかという話でもありました。tok/sはOllama APIから返却される実値を入れているので正確性が高いです。

• モデル比較と GPU 比較で軸を切り替えられます。同じモデルを GPU 横断で並べると、こうなります

綺麗にカードの性能差が出ているのがわかります。さすが5090最強伝説

• セクションごとに「画像を保存」で、そのままブログに貼れる誌面風の PNG を書き出せます

またブログなどに載せやすいように不要なモデルを消して画像出力できます

これがデフォルト

Gemma4-31bでいくつかかぶっている、Qwebの規制解除もかぶってるので消す

ベンチマークのために、接続先ラベルを一括で変更できる（表記揺れを直せる）ようにしてます。runPodなど複数のGPUを使いこなすプロ向け

この機能が入った開発中スナップショット(v2.8)を、この記事の最後でメンバーシップ向けに試験配布します。導入を考えている方向けに、先に注意点を書いておきます。

• v2.7 を使っている方は、いまのフォルダに zip を上書き展開すれば OK です。データ(server/data と server/output)はそのまま引き継がれます。心配な方は先にバックアップを

• 動作要件は Node 24 以降です

• ベンチマークは生成履歴から集計するので、導入直後は行が少なく見えます。使うほど増えます

• 正確な tok/s(実測)が出るのは、実測値の記録が始まった v2.7 以降に生成した作品だけです。それより前の作品は実測値を持っていないので、tok/s モードの集計には入りません(字/秒モードには文字数換算で入ります)

v2.8 の位置づけ

今回の v2.8 は、いずれ出す正式版 v3.0 の先行バージョンです。今後も機能がまとまったタイミングで、v2.8.x や v2.9.x といった先行版をメンバーシップ限定でいくつか出していくつもりです(あくまで予定で、次がいきなり v3.0 になる可能性もあります)。正式版の v3.0 は、これまでどおり単品の販売記事として個別に販売する予定です。

なので、使い分けはこうなります。

• メンバーシップの方 … ベンチマークや、今後出てくる新機能を先に試したい場合は、ダウンロードして使ってください。「v3.0 で機能がたまってからでいいや」という方は、そのときまで待っていただいて大丈夫です

• メンバーシップでない方 … v3.0 の正式リリースまでお待ちください。もし開発の途中も見てみたくなったら、メンバーシップに入っていただけるとありがたいです

ここで少しだけ、メンバーシップの説明を。「AI活用実践ラボ」という月額のメンバーシップをやっていて、開発の途中経過や検証の裏側を、限定記事でいちばん近くから見られる場所にしています。今回の先行版はその特典の新しい試みで、加入中の方はこの記事の限定部分からダウンロードできます。

Inkubus 本体(現行版 v2.7)は、こちらの販売記事から買い切りで購入できます。まずはツール本体から、という方はこちらへ。

で、ここからはメンバーシップ向けの特典です。

メンバー限定: 先行版のダウンロード