本記事は 8/15 のモデル公開当日に4軸の実測を行い、8/16 の追補測定（c=64・MTP c=1・vLLM側MTP・スロット充填率検証）まで完了しました。

TL;DR

公開当日（8/15 0:00 JST）の Qwen3.8-27B（dense 28B・Apache 2.0）を DGX Spark (GB10) で実測し、速度・日本語・コーディング・マルチモーダルの4軸を同日中に完了した
速度はバックエンドと設定で5倍変わる。llama.cpp Q4_K_M 素で c=32 43 tok/s、MTP 投機デコードで 50、vLLM + NVFP4（ネイティブカーネル）で 185、vLLM + NVFP4 + MTP で 231 tok/s。カーネル統制済みの dense 対 dense でも Gemma4-31B を 1.35〜1.50倍上回る
投機デコードの優位幅はどちらのランタイムでも c とともに縮む — llama.cpp では c=32 の +14.6% が c=64 で −3.5% に逆転（記事が公開していた「c≈39 で交差」予測の方向を実測で確認）。vLLM は c=32 でも +24.8% を維持。品質は落ちない（JamC-QA 300問 A/B で差 0.0pt）。そして意外な発見: c=1 が投機の一番おいしい点ではなかった（llama.cpp 実測 +29%止まり — 重いドラフタのプリフィル税が原因）
モデルの性格は明確: 日本語知識（JamC-QA）は 53.44% で比較群最下位、コーディング（Aider Polyglot）は 47.6% で前世代 MoE 首位と同等圏（8B 小さい dense で）、VLM の構造化出力は parse rate 100%。知識を削り、作業能力に振った — 公式の agentic 路線と実測が一致する

結論の早見表

知りたいこと	答え	詳細
GB10 で一番速く動かすには？	vLLM + NVFP4 + MTP（c=32 で 231 tok/s）	§3-3
llama.cpp で使うなら？	MTP 有効化（c=8〜32 で +15〜67%）と、-np を想定並列数に合わせること（過大設定で3倍損する）	§3-2, §3-6
日本語の知識質問に使える？	弱い。比較群6モデルの最下位（53.4%）	§5
コーディングエージェント用途は？	強い。前世代 MoE 首位と同等圏（47.6%）、挽回力は上位	§6
画像・構造化出力は？	JSON / PPE とも parse rate 100%	§7
MoE から乗り換えるべき？	知識用途なら No。agentic 用途なら検討に値する	§5-§7

1. Qwen3.8-27B とは

一言でいえば、知識を削って作業能力に振った dense ハイブリッド VLM である — 4軸の実測を終えた本記事の結論だ。以下、そのモデルの素性から順に見ていく。

8月3日に Qwen3.8-Max（2.4T MoE、API のみ）が発表され、open weights は「約1週間で」と予告された。実際には Max 級の重み（Qwen3.8-2.4T-A95B）が8月13日に先行し、本命の 27B は ModelScope 公式ページのカウントダウンどおり 8月15日 0:00 JST に公開された。Apache 2.0。Qwen3.6 世代では MoE (35B-A3B) と dense (27B) が並走していたが、ローカルコミュニティが実際に回し続けたのは 27B dense のほうだった。カウントダウンまで用意された今回の 27B の扱いは、その選好を Alibaba 側が認識している証左だろう。

中身は Qwen3.5/3.6 系のアーキテクチャを継いだ dense 28B のハイブリッドで、64層のうちフルアテンションは16層、残り48層は Gated DeltaNet（線形アテンション）。KV cache は通常の dense の約1/4 で済む。ネイティブ VLM（画像+動画）、native context 262,144。そして本記事の主役の一つである MTP（multi-token prediction）ヘッドを学習済みで持つ。

MTP ヘッドの配布のされ方が面白い。llama.cpp 向けの GGUF は、本体（Q4_K_M、17.67GB）・画像エンコーダ（mmproj）・MTP ヘッド（mtp-*.gguf、約3.0GB）の3ファイル構成で、公開当日に ggml-org から揃った。MTP ヘッドは本体に埋め込まれておらず、投機デコード用のドラフトモデルとして起動時に別ファイルで渡す方式だ（後述の起動引数を参照）。使わなければダウンロードも不要、という割り切りである。

公式モデルカードは Qwen3.6-27B 比で Terminal-Bench 2.1 63.4→73.0、OSWorld-Verified 63.9→84.3 などの大幅な改善を掲げる。ただしこれらは全てベンダー自身の測定であり、一部は自社設計ベンチや修正版タスクセットを含む。本記事はそれを検証するものではなく、いつも通り「実ハードで走らせたら実際に何が起きるか」を測る。

2. 前提の整理

dense と MoE、そしてハイブリッド

dense: 毎トークン全パラメータを読む。GB10（帯域 273GB/s）では重み読み出しが律速になり、27〜31B の Q4_K_M で c=1 ≈ 10 tok/s 帯に張り付く
MoE: トークンごとに一部の expert だけ読む。Gemma4-26B-A4B なら active 4B で、c=1 から 50 tok/s 超
Qwen3.8 のハイブリッド: dense だが、大半の層を線形アテンションにして KV cache を削った構成

速度だけ見れば MoE の圧勝に見えるが、dense には理由がある。第一にパラメータ効率 — 当ラボの JamC-QA 実測では Gemma4-31B dense (61.28%) > Gemma4-26B-A4B MoE (58.08%) > Qwen3.6-35B-A3B MoE (55.26%) と、速度の序列と品質の序列がきれいに逆だった。第二に挙動の安定性 — ルーターを持たない一枚岩なので量子化や微調整が素直に効く。第三に batching との相性 — dense の遅さは重み読み出し律速なので、並列化すれば重み読みを複数リクエストで按分でき、伸び代が大きい。

そして第四が本記事の主題で、dense の弱点（c=1 の遅さ）は投機デコードで埋められる。Qwen3.8 のハイブリッド構成は「KV の重さは線形アテンションで削り、c=1 の遅さは MTP で削る」という、dense の欠点潰しパッケージとして読める。

投機デコードとは

LLM の生成が遅い根本原因は、1トークン出すたびにモデル全体の重みをメモリから読むことにある。投機デコード（speculative decoding）はこれを緩和する仕組みで、軽い「ドラフタ」が数トークン先まで一気に下書きし、本体が1回のまとめ読みでそれを検証する。下書きが合っていた分だけまとめて採用できるので、本体の重み読み出し回数が減り、生成が速くなる。

重要な性質が2つある。(1) 本体が全トークンを検証するので、出力の品質は原理的に落ちない（下書きが外れたら捨てて本体の答えを使うだけ）。(2) その代わり、外れた下書きの計算は無駄になる。**下書きがどれだけ当たるか（受理率）**が効率を左右する。

Qwen3.8 の MTP ヘッドは、この「ドラフタ」を本体と一緒に学習させたものだ。後付けの汎用ドラフタより当たりやすいことが期待できる。なお、かつて投機デコードといえば専用フォークやパッチの世界だったが、現在の llama.cpp は --spec-type フラグで標準サポートする（draft-mtp / draft-dflash など）。ドラフトモデルのファイルを -md で渡し、方式をフラグで選ぶだけだ。

比較の相手 — 直前に測った Muse Glimmer 30B + DFlash

当ラボでは本測定の直前に、Meta Superintelligence Labs の Muse Glimmer 30B（29.6B dense VLM）を同じ環境で測定している（この測定は別途記事化予定）。このモデルには DFlash という投機デコード用ドラフタがある。ブロック拡散という方式で16トークンを一括生成する5層の軽量モデルで、MTP とは対照的に「軽いが、当たりにくい」性格を持つ。実測の受理率は 14.9% しかなかったが、ドラフタ自体が軽いため c=1 では 2.27倍の高速化が出た。一方、同時実行数を上げていくと c=16〜24 で効果が消え、c=32 では有効化しないほうが 1.65倍速かった。

つまり手元には「同じ llama.cpp の同じ投機機構に、性格の正反対なドラフタを挿した2例」が揃ったことになる。重いが当たる MTP（受理率 48.1%）と、軽いが外れる DFlash（14.9%）。この対比が §4 の柱だ。

測定方法 — 「c」とは何か

速度測定は当ラボ標準の方式4: サーバ（llama-server または vLLM）を vllm bench serve クライアントで叩く。どの経路もクライアント・プロンプト集合（ShareGPT、200問）・num-prompts を完全に揃えることで、ランタイム間の数値を直接比較できる。

c（同時実行数）は「誰の視点か」を決める。c=1 は一人で対話するときの体感速度。c=8〜16 は社内数人 + エージェント数本がぶら下がる部門サーバ。c=32 は本格的なサーバ運用。自分の用途がどの c に当たるかを意識して表を読んでほしい。指標は3つ: 集約 output tok/s（全体の処理能力）、TTFT（最初のトークンまでの待ち時間）、TPOT（トークンとトークンの間隔 = 1リクエストの体感速度）。

測定条件は以下で固定した。

項目	値
ハード	DGX Spark GB10、128GB unified、273GB/s
llama.cpp 系列	b10423 (commit a94d563ed)、CUDA / Q4_K_M（ggml-org、17.67GB）+ MTP Q8_0（2.95GB）
llama.cpp 起動	`-ngl 99 -fa on -c 32768 --parallel 32 --jinja --reasoning off`
MTP 有効時の追加	`-md mtp-Qwen3.8-27B-Q8_0.gguf --spec-type draft-mtp`（draft 数はデフォルト）
vLLM 系列	`eugr/spark-vllm:latest`（vLLM 0.27.2rc1.dev、2026-08-14 ビルド）+ `unsloth/Qwen3.8-27B-NVFP4`（22GB）、追加引数なし、投機なし
thinking	無効（`--reasoning off`）。Qwen3.8 は既定で thinking ON・reasoning_effort=xhigh なので、明示的に切らないと出力トークンが爆発し比較にならない
クライアント	`vllm bench serve` / ShareGPT_V3 200 prompts（全経路共通）

比較対象（Muse Glimmer 30B、Qwen3.6-35B-A3B、Gemma4-26B-A4B）は全て同一ビルド・同一条件の実測値。なお4月の記事で Qwen3.6-27B dense 等を llama-bench で測っているが、あれは理論上限側の値であり、実プロンプトのスイープとは系列が異なるため本記事の表には混ぜない。

3. 速度 — バックエンドと設定で3系列を測る

Qwen3.8-27B を GB10 で動かす経路は、本記事の測定範囲で3つある: (a) llama.cpp Q4_K_M（素）、(b) 同 + MTP 投機デコード、(c) vLLM + NVFP4。結論を先に図で示す — 同じモデル・同じハード・同じプロンプトでも、バックエンドと設定で最大5.3倍違う。

3-1. llama.cpp（素）— dense hybrid のスケーリング

c	MTPなし (tok/s)	TTFT (ms)	TPOT (ms)
1	9.38	2953.7	93.1
8	10.88	6846.3	698.4
16	17.05	7479.2	875.1
32	43.48	7008.0	581.8

（成功 198〜200/200。TTFT が全体に重いのは --parallel 32 固定で立てた測定条件によるもので、モデル素の初速ではない点に注意）

3つ読み取れる。

(1) c=1 は 9.38 tok/s — GB10 の dense の相場どおり。 Gemma4-31B (10.41)、Qwen3.6-27B (10〜12) と同じ帯にいる。KV cache が1/4というハイブリッドの利点は、重み読み出しが律速の c=1 では現れない。妥当性の傍証として、RTX 3090（帯域 936GB/s、GB10 の3.4倍）でのコミュニティ実測が約28 tok/s であり、帯域比とよく整合する。

(2) c=32 で 43.48 — 4.6倍のスケーリング。 llama.cpp 同士で比べると MoE 勢（c=32 で 159 tok/s 帯）には遠く及ばない。なお本記事の初版では c=16→32 の伸びの加速を「dense hybrid は頭打ちが来ない」というモデルの性質として書いたが、追補測定の結果、この加速の主因はモデルではなく llama.cpp のスロット充填率（後述 §3-6）と判明したため、その解釈は撤回する。

(3) c=8 が伸びない — 追補測定で原因が判明した。 10.88 と、c=1 (9.38) からほとんど増えていない。同じ現象は4月に Gemma4-26B-A4B（MoE）でも観測しており、当初「llama.cpp 固有の癖、原因未解明」として記録した。追補測定 §3-6 で、この平坦の主因はサーバのスロット充填率（c ÷ -np）であることを突き止めた。-np 8 のサーバなら同じ c=8 が 37.50 tok/s（3.4倍）出る。

3-2. + MTP — 測定した全域で速度が向上

c	MTPなし	MTPあり	向上率
1	9.38	12.14	+29.4%（追補。§4 参照）
8	10.88	18.14	+66.7%
16	17.05	27.35	+60.4%
32	43.48	49.82	+14.6%

受理率 — 下書きの的中率 — は平均 48.1% だった（600リクエストのサーバログ全数集計。ただしリクエストごとのばらつきは 0〜100% と大きい）。つまり MTP ヘッドの先読みは、およそ半分当たる。DFlash の 14.9% の3倍以上だ。

「品質は原理的に落ちない」という §2 の理屈も実測で確認した。JamC-QA 300問で MTP あり/なしを比較したところ、両方とも 52.0% で差は 0.0pt（§5）。速度は上がり、品質は変わらない。

3-1 で見た「c=8 で並列化しても処理量が増えない」問題にも効いている。MTP なしでは 10.88 に沈む c=8 が、MTP ありでは 18.14 まで改善し、c=8 でも並列化の意味が出てくる。DFlash が c=16〜24 で効果を失ったのに対し MTP は c=32 でも +14.6% を保った — この違いの意味は §4 で掘る。

3-3. vLLM + NVFP4 — ネイティブカーネルが動いた

GB10（SM 12.1）には FP4 のネイティブ演算がなく、当ラボの過去2件（Gemma4-31B / Gemma4-26B-A4B）では NVFP4 モデルが Marlin W4A16 フォールバック（実質 4bit 重み × 16bit 演算）に落ちていた。「GB10 で NVFP4 と名乗るものは W4A16 である」が当ラボの経験則だった。

ところが今回、新しいイメージ（eugr/spark-vllm:latest、vLLM 0.27.2rc1.dev、2026-08-14 ビルド）で unsloth/Qwen3.8-27B-NVFP4 を起動したところ、起動ログに Using FlashInferCutlassNvFp4LinearKernel for NVFP4 GEMM — フォールバックではなくネイティブ NVFP4 カーネルが選択された。ソフトウェアの進化が、ハードの経験則を覆した形である。

c	output tok/s	TTFT (ms)	TPOT (ms)
8	74.18	386.1	101.5
16	123.72	493.7	116.5
32	185.28	920.7	149.3

（全点 200/200 成功。この表は投機なしの数字である）

追補測定で vLLM 側の MTP も有効化した（--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'、k=1）。

c	投機なし	MTP ON (k=1)	向上率
8	74.18	102.19	+37.8%
16	123.72	165.99	+34.2%
32	185.28	231.19	+24.8%

投機なしの 185 の上にさらに積めて、最速経路は c=32 で 231 tok/s — llama.cpp 素の 5.3倍になった。受理率（位置0）は 60〜79% と llama.cpp 側（48〜56%）より高い。

c=32 で 185.28 tok/s — llama.cpp 系列の 3.7倍。TPOT は 149.3ms と llama.cpp の同点（582〜729ms）の 1/4 で、集約処理量だけでなく1リクエストの応答体感でも別世界だ。3-1 の「c=8 死に地帯」もこの経路には存在しない（74.18 と素直に伸びる）。

ただし誠実に言えば、この 3.7倍にはランタイム差・量子化差（Q4_K_M vs NVFP4）・カーネル実装差が重畳しており、どの要因が何割かの分解はできていない。llama.cpp が CUDA 汎用カーネル、vLLM が Blackwell 最適化カーネルを使っている可能性が高い、という以上のことは現時点では言えない。

なお同系統の先行例として、GB10 同等機での vLLM + NVFP4 + MTP の実測が 8/14 に公開されている（gitcommit90/qwen38-27b-dgx-spark、単ストリーム 18.4〜24.5 tok/s、--max-num-seqs 4 で集約 66.5）。本測定はこれと独立に、投機なし・高並列側を埋めた形になる。

3-4. dense 対 dense — カーネルを統制して比べる

vLLM 経路の速さが分かったところで、「では dense として Qwen3.8 は速いのか」を統制して確かめた。比較相手は Gemma4-31B（通常の dense、31B）の NVFP4。当ラボには Marlin フォールバック時代のフルスイープ（c=1/16/32 = 6.92/48.25/143.01）があったが、カーネル実装が違うと比較にならないため、同一の新イメージで再測定した。

c	Gemma4-31B NVFP4（ネイティブ）	Qwen3.8-27B NVFP4（ネイティブ）	比
8	49.50	74.18	1.50x
16	88.53	123.72	1.40x
32	137.21	185.28	1.35x

ランタイム・量子化・カーネル・クライアントを揃えた上で、Qwen3.8 は通常 dense の Gemma4-31B を全点で 1.35〜1.50倍上回った。パラメータが 3B 小さいことを考えても、64層中48層を線形アテンションにしたハイブリッド構成の効率が、vLLM 経路でははっきり数字に出る。

副産物も一つ。Gemma4-31B の新旧比較（ネイティブ vs Marlin）は c=16 で 1.83倍速い一方、c=32 ではわずかに遅い（137.21 vs 143.01）という非対称な結果になった。中間並列域ではネイティブカーネルが大きく勝つが、飽和域では拮抗する — 要因は未確定であり、現象として記録しておく。

3-5. どのバックエンド・設定を選ぶか

最速が欲しい: vLLM + NVFP4。c=32 で 185 tok/s、TPOT も最良。ただし vLLM 0.27 系の新しいイメージが前提
llama.cpp の資産・手軽さを優先: MTP を必ず有効に。全域で +15〜67%、品質劣化なし。ただし c=4〜8 の死に地帯と、高並列での TPOT 増（§4）に注意
MoE との比較: llama.cpp 同士なら MoE 勢が依然速い（159 tok/s 帯）。ただし vLLM 経路の 185 はそれを上回っており、「dense は遅い」という相場観は経路次第で覆る

3-6. 追補: llama.cpp の性能は「スロット充填率」で決まる

追補測定で最も実用価値の高い発見はこれかもしれない。きっかけは c=64 測定の準備中の事故だった — -np 64 で立てたサーバに c=32 を流したところ、14.29 tok/s しか出なかった（同じ c=32 でも -np 32 サーバなら 42.84）。サーバの器を倍にしただけで3倍遅くなったのである。ところが同じ -np 64 サーバに c=64 を流すと 37.57 まで回復した。

ここから「性能を決めるのは c の絶対値ではなく、**スロット充填率（c ÷ -np）**ではないか」という仮説が立つ。最小検証として -np 8 のサーバで c=8 を測ったところ — 37.50 tok/s。①で 10.88 だった c=8 が、3.4倍（+244.6%）になった。

全観測点を充填率で並べ直すと（上図）、np や c の絶対値によらず、充填率 50% の2点どうし・100% の3点どうしがそれぞれ近い水準に収まる。関係は線形ではなく、満杯に近づくほど急に効率が上がる凸型・閾値的な形をしている。§3-1 で「原因未解明」としていた c=8 平坦（充填率 25%）も、4月に別モデルで見た同じ現象も、これで説明がつく。

実用則として一行にまとめる: llama.cpp の -np は「余裕を持って大きめ」に取ってはいけない。想定並列数に合わせること。過大な -np は同じ負荷で3倍の性能を捨てる。

（機構の内部的な説明 — なぜ空きスロットが継続バッチングを阻害するのか — は llama.cpp のスケジューラ実装の問題であり本記事の範囲を超える。現象と対処を報告するに留める）

4. 考察 — 投機デコードはどこまで効くのか

Muse Glimmer + DFlash の測定でクロスオーバー（有効→逆効果の境目）を見つけたとき、「低並列では余っていた演算資源が高並列で埋まり、下書きの生成・検証が本体の仕事と取り合いになる」という仮説を立てた。今回、この構造が2つのドラフタ × 2つのランタイムの計4系列すべてで再現した。図Cのとおり、優位幅はどの系列でも c とともに単調に縮む。縮むこと自体は実装のバグや偶然ではなく、投機デコードという手法の性質である。

交差の実測 — 予測は方向として当たった

本記事の初版は、llama.cpp 系列の3点外挿から「c≈39 前後で優位幅がゼロになる」と予測していた。追補測定の c=64 で答え合わせをした結果: OFF 37.57 / ON 36.27 — ON が 3.5% 劣位に転じ、交差の発生を実測で確認した。c=32（+14.6%）と c=64（−3.5%）の間で交差しており、予測の方向は正しかった。ただし c=64 は -np 64 という別条件（§3-6）での測定のため、交差点が正確に 39 付近かまでは断定できない。

興味深いのは受理率が交差の原因ではなかったことだ。c=64 での受理率は 50.06% と、c=8〜32 の 48.1% からほぼ動いていない。下書きは同じ精度で当たり続けているのに、優位は消える — 効いているのは受理率の低下ではなく、高並列でドラフト分の演算が純粋なコストとして本体と取り合いになることである。当初の仮説どおりだった。

一方 vLLM 系列は同じ縮小トレンド（+37.8 → +24.8%）を示しながら、c=32 ではまだ大きくプラスに留まる。縮む構造は共通、縮む速さは実装と受理率で変わる — これが4系列を並べた結論だ。

c=1 の意外 — 「一番おいしい点」ではなかった

もう一つ、直感に反する結果が出た。単一ストリーム（c=1）は他リクエストとの競合がなく、投機デコードが最も効くはずの条件である。実測は +29.4%（9.38 → 12.14）止まり — c=8 の +66.7% より小さい。

内訳を見ると原因が分かる。TPOT は 93.1 → 50.3ms と 1.85倍速くなっている（投機の狙いどおり）。ところが TTFT が 2953.7 → 6339.6ms と 2.15倍悪化し、稼ぎを食い潰した。3.0GB の MTP ドラフタが本体と並んでプロンプトを処理する初動コストが、c=1 では他リクエストに償却されず丸ごと露出する — 重いドラフタの「プリフィル税」である。受理率は c=1 が 56.2% と全点で最良なのに優位幅は最小、という逆説もこれで説明がつく。

DFlash（5層・軽量）が c=1 で 2.27倍出たことと合わせると、前版で書いた原則がより正確になる:

低並列域での伸びはドラフタの軽さが決め（軽さにはプリフィルコストを含む）、効果が続く範囲の広さは受理率が決める。

実用上の帰結: 対話用途（c=1、体感 = TPOT）なら MTP は入れる価値がある（トークンは1.85倍速く流れる）。ただし長いプロンプトを一発投げる用途では初動が倍近く遅くなることは知っておくべきだ。

c=32 の TPOT 逆転（集約は ON 勝ち、応答は OFF 勝ち）は前版のとおりで、c 依存で起きる。バッチ処理中心なら c=32 でも MTP あり、対話の応答速度重視なら c=16 あたりで切る、という GB10 での運用指針も変わらない。

なお --spec-draft-n-max はデフォルト値のまま（llama.cpp: 3、vLLM: k=1）であり、投機パラメータの探索はどちらの系列でも行っていない。詰めればまだ上がある可能性は残る。

5. 日本語知識 — JamC-QA で測る

使ったのは JamC-QA（SB Intuitions 構築）— 日本固有の知識（文化・風習など）を問う4択ベンチマークで、全2,309問。JCQ など従来の日本語ベンチが上位モデルで飽和して差が出なくなったため、当ラボでは新規モデル評価の主軸をこれに置いている。

測定条件: nothink / dev スプリット 3-shot / sbintuitions JamC-QA v1.0 test スプリット 2,309問 / 4択一致判定（LLM-judge 不使用）。MTP は有効のまま測定した — その正当性は先に 300問の A/B で確認している（MTP あり 52.0% / なし 52.0%、差 0.0pt。投機デコードは本体が全トークンを検証するため品質が落ちない、という §2 の理屈どおりの結果）。parse 失敗は 0%。

モデル	構成	JamC-QA
DeepSeek-V4-Flash-0731	MoE・3bit単機	63.92%
Gemma4-31B	dense	61.28%
Nemotron 3 Super 120B	dense	59.33%
Gemma4-26B-A4B	MoE	58.08%
Qwen3.6-35B-A3B	MoE	55.26%
Qwen3.8-27B	dense hybrid	53.44% (1234/2309)

（比較5モデルは 2026-08-01〜02 に同一ハーネス・同一条件で測定。品質値はビルドに依存しないため併記している）

比較群の最下位である。 前世代 MoE の Qwen3.6-35B-A3B (55.26%) にも 1.82pt 届かない。§2 で述べた「dense は速度で負けるが品質で勝つ」という当ラボの過去傾向 — Gemma4 世代では dense 31B (61.28%) が MoE 26B-A4B (58.08%) を明確に上回っていた — を、Qwen3.8 は破ったことになる。

どう解釈するか。JamC-QA が測るのは日本固有知識の保有量であり、いわば「暗記の厚み」に近い。一方、公式モデルカードが押し出すのは Terminal-Bench 73.0、OSWorld 84.3 といったエージェント作業能力だ。この世代は、パラメータ予算を知識の詰め込みから作業能力へ振り直した — という仮説がここで立つ。それなら日本語知識の後退と公式主張は矛盾しない。この仮説を検証するのが次章のコーディング測定である。

運用メモを一つ。JamC-QA 実行中にサーバのプロンプトキャッシュ蓄積による極端な遅延（数分/問）が発生し、サーバ再起動で解消した。速度測定と品質測定を同一サーバプロセスで続けて回す場合は、軸の切り替えごとにサーバを再起動するのが安全である。

6. コーディング — Aider Polyglot で測る

前章で Qwen3.8-27B は日本語知識の比較群最下位に沈んだ。では、このモデルは何が得意なのか。前章で立てた仮説 — パラメータ予算を知識の詰め込みから作業能力へ振り直したのではないか — を検証するのが本章である。

Aider Polyglot は何を測るベンチマークか

「コーディング性能」と一言で括られがちだが、Aider Polyglot が測っているものは HumanEval のような単発コード生成とはかなり違う。Exercism 由来の 225題を C++ / Go / Java / JavaScript / Python / Rust の6言語で解くベンチマークで、構成要素を分解するとこうなる。

既存ファイルへの diff 編集。コードを白紙から丸ごと生成するのではなく、渡されたファイルに対して差分編集を所定フォーマットどおりに出力しなければならない。フォーマットを1文字でも外せばその試行は無効 — つまり指示追従の厳密さと、既存コードを壊さず触る編集能力が最初の関門になる
6言語。Python の暗記量では通用しない。言語をまたぐ一般化能力が要る
テストフィードバックループ（2 tries）。1回目が失敗すると、テストのエラー出力を渡されて2回目の修正機会を得る。エラーメッセージを読解し、原因を特定し、修正する往復動作 — コードエージェントが実務でやっている作業そのもの

つまりこれは「プログラミング知識のクイズ」ではなく、エージェントとしてコードを直せるかの実技試験である。速度や知識とはまったく別の能力軸を測っている。当ラボが HumanEval+ 系（evalplus）を引退させてこちらを採用しているのも、現世代モデルには前者が易しすぎて 0.92〜0.95 に団子になり、差が出ないからだ。

結果 — 8B 小さい dense が、前世代 MoE 首位に 2.2pt 差

モデル	quant	ノード構成	rate_1	rate_2	挽回幅
Qwen3-Coder-480B	UD-Q3_K_XL	2ノード	30.7%	57.3%	+26.6pt
Qwen3.6-35B-A3B	MXFP4_MOE	1ノード	24.0%	49.8%	+25.8pt
Qwen3.8-27B	Q4_K_M	1ノード	15.6%	47.6%	+32.0pt
Gemma4-31B	Q4_K_M	1ノード	9.3%	43.1%	+33.8pt
GLM-5.2	UD-IQ1_M	2ノード	11.6%	43.1%	+31.5pt
MiniMax-M3	UD-Q3_K_XL	2ノード	17.3%	40.0%	+22.7pt

（全モデル n=225 完走。pass_rate_2 = 2回以内に全テスト通過。比較5モデルは 2026-07〜08 に同一ハーネス・同一設定で測定。品質指標のため実行機差の影響は小さいが、実行機は全て GB10 級ノード（DGX Spark および同等 OEM 機）であり、区別すべき条件は 1ノードか 2ノード RPC 連結かである。Qwen3.8 のみサーバ 8並列で実行 — pass_rate への影響は原理的に小さいが条件差として明記する）

読みどころは3つ。

(1) 順位そのものより、サイズと構成を踏まえた位置に注目してほしい。 図の並びどおり、スコアの首位は前世代 MoE の Qwen3.6-35B-A3B (49.8%) であり、Qwen3.8 (47.6%) はその 2.2pt 下にいる。n=225 の信頼区間は大きく重なるため、この 2.2pt は統計的な差とは言えない — つまり同等圏である。ここで効いてくるのが構成の違いだ: Qwen3.6 は 35B の MoE、Qwen3.8 は 8B 小さい 28B の dense で、同じ土俵に立った。同系統の dense である Gemma4-31B (43.1%) に対しては 4.5pt 上回り、こちらは点推定で明確な差がある。480B のコーディング専業機（57.3%）との差も 9.7pt まで詰まっている。

(2) 挽回幅 +32.0pt — 「直す」能力に寄っている。 rate_1 の 15.6% は正直低い。一発目の diff 編集はあまり当たらない。ところがテストのエラー出力を渡すと 47.6% まで跳ねる。この +32.0pt という挽回幅は完走モデル中で上位だ。最初から正解を書く力より、エラーを読んで修正する力に寄ったモデル — まさにエージェント運用で使われる能力プロファイルである。

(3) 前章と並べると、モデルの設計思想が見える。 日本語知識（暗記の厚み）は前世代 MoE にすら届かない最下位。コーディング実技（読んで直す往復）はその前世代 MoE と同等圏まで浮上し、dense としては群を抜いた。公式モデルカードが Terminal-Bench 73.0 / OSWorld 84.3 とエージェント作業能力ばかりを押し出していたのは、マーケティングの誇張ではなくパラメータ予算配分の正直な申告だった、というのが当ラボの読みだ。前章の仮説は支持された。

用途への含意もはっきりする。日本語の知識質問に答えさせる用途（社内 FAQ など）には向かない。コードを渡してテストが通るまで直させる用途 — つまり Claude Code 的なエージェントのローカル代替 — には、単機で載る現行モデルの中で有力な選択肢になった。§3 で見たとおり、速度も MTP または vLLM 経路で実用域に届く。

7. マルチモーダル — VLM としての実力を測る

Qwen3.8-27B はテキストモデルに画像対応を後付けしたものではなく、画像と動画をネイティブに扱う VLM として学習されている。llama.cpp では画像エンコーダ（mmproj、601MB）を --mmproj で渡すだけで有効になる。

なぜローカル VLM が重要か

マルチモーダルこそ、ローカル LLM の本丸だと当ラボは考えている。理由は単純で、画像はテキスト以上にクラウドへ送りにくいデータだからだ。工場の安全監視、防犯カメラ、帳票や身分証のスキャン — 被写体に人が写り、書類に個人情報が載る。しかも動画なら量も帯域も桁が違う。「画像を1枚ずつ API に投げる」が許されない現場は多く、そこで VLM がローカルで実用になるかどうかは、速度やコーディング以上に切実な問いになる。

3つのタスクは何を測っているか

当ラボの VLM ベンチは、実写画像8枚（展示会場5枚 + 作業現場3枚）に対する3タスク構成である。

Caption 生成（5枚）— 見えているものを自由記述で言語化する基礎体力。ただし採点が主観に寄るため、当ラボでは所要時間の参考として扱う
JSON 構造化抽出（5枚）— 画像の内容を指定スキーマの JSON で返させる。これが実務の核心だ。VLM を自動化パイプラインに組み込むとき、出力が parse できなければ後段の処理はすべて死ぬ。「賢いが形式を守れない」モデルは、デモでは映えても運用には使えない
PPE 検出（3枚）— 作業現場の写真からヘルメット・安全ベスト等の装着状況を判定させる。産業応用の代表例であると同時に、「画像内の複数の対象について、それぞれ構造化された判断を返す」複合タスクであり、単純な抽出より一段難しい

つまりここで測っているのは画像理解の賢さそのものというより、視覚情報を機械可読な形式で返し続けられるか（form-following）である。コーディング測定と同じく、エージェントとして使えるかを問う軸だ。

結果 — parse rate 100% × 2

測定条件: llama.cpp b10423（他章と同一ビルド）/ Q4_K_M + mmproj Q8_0 / -c 16384 --parallel 1 --reasoning off / ハーネスは当ラボの vlm_bench.py。

タスク	n	平均所要	parse rate
Caption 生成	5	92.8秒/枚	—（自由記述）
JSON 構造化抽出	5	17.2秒/枚	100%
PPE 検出	3	28.7秒/枚	100%

過去に同一ハーネスで測ったモデルと並べる。

モデル	JSON 抽出	PPE 検出
Gemma4-31B (dense)	100%	33.3%
Qwen3.6-35B-A3B (MoE)	100%	100%
Qwen3.8-27B (dense hybrid)	100%	100%

比較表の見どころは Gemma4-31B の行だ。単純な JSON 抽出は満点なのに、PPE 検出では3枚中2枚で出力形式が崩れた。対象が複数になり判断が複合的になると form-following が破綻する — 知識ベンチ（JamC-QA 61.28%）では首位級だったモデルの、エージェント適性の穴である。Qwen3.8 は Qwen3.6 と同様、複合タスクでも形式を守り切った。

§5 で「知識は最下位」、§6 で「コーディング実技は前世代 MoE と同等圏」と見てきたが、本章の結果はその延長線上にきれいに乗る。知識を削って作業能力に振った、という本記事の縦糸が、視覚タスクでも form-following という形で確認できたことになる。

正直な注記を2つ

llama.cpp 経路の所要時間は実用ぎりぎりである。 Caption 92.8秒/枚は、§3-1 で見た c=1 ≈ 9.4 tok/s という遅さがそのまま効いている（本測定は MTP なし・並列1）。バッチで夜間に回す用途なら問題ないが、リアルタイム性が要る用途では §3-3 の vLLM/NVFP4 経路（3.7倍速）が現実解になるだろう。

このベンチは飽和が見え始めている。 Qwen3.6 と Qwen3.8 がともに全項目 100% で、もはや新世代モデル間の差を検出できていない。Gemma4-31B の 33.3% を見つけた仕事は果たしたが、n=8 の parse rate という物差しは次の世代には効かない。当ラボでは JCQ → JamC-QA の乗り換えと同じ判断基準（差が出なくなったベンチは引退）に従い、正誤ラベル付きの画像セット拡充と正確性採点を入れた v2 を次期モデルまでに用意する予定である。現時点の結論は「form-following は満点、ただし物差しの上限に当たっている」と読んでほしい。

8. 総括

Qwen3.8-27B は、GB10 で単機運用できる agentic 特化型の dense ハイブリッド VLM である。日本語の知識を問う用途には前世代 MoE にも劣るが、コードを直させ、構造化出力をパイプラインに流す用途では、単機クラスの有力候補である。速度はバックエンドと設定の選択がすべてで、最速の vLLM + NVFP4 + MTP なら c=32 で 231 tok/s — llama.cpp 素の5倍以上になる。llama.cpp で使うなら、MTP の有効化と -np を想定並列数に合わせること（§3-6）の2つで、同じハードから数倍の性能を引き出せる。

測定として残した宿題は、投機パラメータの探索（draft 数・k の値振り）、Gemma4-31B 新旧カーネルの c=32 逆転の要因、スロット充填率問題の機構解明（llama.cpp 本体側の課題）である。これらは次のモデルの測定サイクル、あるいは llama.cpp コミュニティへの報告として持ち越す。本記事の測定はここで確定とする。

測定条件の記録

llama.cpp 系列: b10423 / commit a94d563ed / 2026-08-15 測定 / ShareGPT_V3_unfiltered_cleaned_split.json / num-prompts 200 / thinking 無効 / spec-draft パラメータはデフォルト。
vLLM 系列: eugr/spark-vllm:latest（vLLM 0.27.2rc1.dev、2026-08-14 ビルド）/ unsloth/Qwen3.8-27B-NVFP4 および Gemma4-31B NVFP4 / クライアント・データセット・num-prompts は llama.cpp 系列と同一。
追補測定（2026-08-16）: c=64 系列は -np 64 -c 65536（n_ctx_slot=1024 維持）、①とはサーバ条件が異なる別系列。ON c=1 は①の ON 系列と同一条件。vLLM MTP は --speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'。スロット充填率検証は D1: -np 8 -c 8192 / D2: -np 32 -c 32768、いずれも投機なし・200 prompts 完走。
生データ・判断ログは GitHub リポジトリに公開予定。

更新履歴

2026-08-16 16:25 JST v2.1 確定版（追補測定を反映: c=64 で交差を実測確認 / MTP c=1 のプリフィル税 / vLLM 側 MTP で最速 231 tok/s / スロット充填率の発見 §3-6 新設 / §3-1 の「頭打ちが来ない」解釈を自己訂正）
2026-08-16 04:35 JST（測定側）rev10 追補測定 A〜D 実施
2026-08-15 21:05 JST v2.0 全面再構成（時系列追記型から通常構成へ）
2026-08-15 18:25 JST v1.3 ④マルチモーダル + NVFP4 系列追記
2026-08-15 17:30 JST v1.2 ③Aider Polyglot 追記
2026-08-15 13:50 JST v1.1 ②JamC-QA 追記
2026-08-15 13:20 JST v1.0 初版（①速度軸）