Gemma 4 26B-A4B MTP：単一リクエストと複数リクエストで変わる速度

長い設計書を読んで変更点を探す作業をGemma 4 26B-A4Bに任せると、モデル名とともに「活性パラメータ3.8B」という数字が目に入ります。この数字は、各トークンの計算で活性化される専門家の規模を示します。runtime⁴は約25.2Bの全重みにアクセスし、context用のKV cache⁵も確保する必要があります。活性数だけを見て約4GBのメモリで動くとは判断できません。

元のレシピでは、LM StudioなどのアプリでQ4のデスクトップ変換版を読み込み、context 8K、同時リクエスト1件で実行しました。これは比較用の基準であり、すべてのマシンに最適な設定ではありません。モデルファイルが収まっても、長い文書の処理にはOS、runtime、他のアプリ、KV cache用のメモリが必要です。まずtarget単体を読み込み、実際の文書に関する質問を1件完了できることを確認してから、assistantを追加します。

Googleが2026年5月に発表したGemma 4 MTP drafterは、この実行経路に追加する選択肢です。targetとdrafterは対応するGemmaの組み合わせである必要があり、assistant checkpoint⁶は小型の汎用Gemmaチャットモデルとは役割が異なります。アプリがassistant checkpointとMTPに対応していなければ、ファイルをダウンロードしただけでは高速化されません。

通常の生成では、target modelが次のトークンを1つずつ計算します。MTPでは4層のassistant drafterが後続トークンを提案し、targetがその候補を検証します。候補が一致すれば、targetの1回の処理で複数トークンを確定でき、decode⁷遅延を短縮できる可能性があります。候補が誤っていれば破棄し、targetのトークンから生成を続けます。検証なしにdrafterが答えを書き上げる方式ではありません。

短縮効果はタスクごとに異なります。多くの候補が採用されるdrafterなら効果が期待できますが、候補が頻繁に却下されるとdraft計算とメモリが増える一方、短縮幅は小さくなります。長い入力の処理（prefill⁸）が待ち時間の大半を占める場合、MTPが短縮するのはdecode部分だけなので、応答全体への影響は限られます。そのため、文書の読み込み時間と最初のトークン後の生成時間を分けて測定します。

単一リクエストの条件と複数リクエストを同時処理する条件は分けて比較してください。Googleは2026年5月の発表で、Apple Siliconのbatch 1ではrouting challengeがあり、batch 4～8では最大約2.2倍の改善を観測したと報告しています。これは発表された実験条件での結果であり、Macで1人が1件質問する場合や、別のアプリ・量子化⁹での保証ではありません。自分の環境を測る際はbatchサイズ、promptと出力token数、runtime、モデルファイルを記録します。

この実習ではApple Silicon上の`mlx<sup>10</sup>-vlm`を使い、同じBF16¹¹ targetと対応するBF16 assistant drafterを比較します。両方のファイルを用意できるメモリが必要です。以前のLM Studio Q4基準との比較ではなく、MLX-VLM内で同じtargetにMTPを加えた場合の差を切り分けます。まず対応バージョンをインストールし、terminalでtarget単体の出力と応答を確認します。

初回実行にはモデルのダウンロードと読み込み時間が含まれる場合があります。完了ログが表示され、応答が生成されたら、同じpromptと256 token上限でtarget単体を3回実行します。その後drafterを追加し、同じ条件で繰り返します。コマンドに`--draft-kind mtp`があるだけでは、モデルの組み合わせが対応していることや実行成功の証明にはなりません。ログでdrafterの読み込みと生成統計を確認してください。

正常に動けば両方の実行で回答が得られ、MTPログにdraft acceptanceなどの情報が表示されるはずです。temperature 0でも出力が異なる場合、どちらも自然な回答に見えても差を隠さないでください。まずruntimeのversion、checkpoint、prompt template、ログを確認します。提供元の効率報告と、自分の環境での実測は分けて記録します。

target単体とMTPを、1回に1リクエストずつ実行します。同じ文書と出力上限を使い、warm状態で少なくとも3回リクエストします。初回のファイル読み込み時間を、別経路のwarm計測と混ぜないでください。中央値、回答の抜け、採用token数、ピークメモリを記録します。decodeのtoken/秒だけでは、長い入力のprefill差が見えないことがあります。

次に同じサーバーへ複数リクエストを同時に送ります。batchサイズを増やす際はprompt、出力長、リクエスト数のいずれかだけを変え、モデルファイルとdraft block sizeは固定します。目的が1人の応答性なら、同時リクエストの結果を主指標にしないでください。複数アプリが共有するサーバーでは、個々の遅延と総throughput¹²の両方を記録し、1件の待ち時間が長くなる問題も見落とさないようにします。

単一リクエストの遅延がほとんど変わらなくても、複数リクエストを処理するサーバーの総完了数は変わることがあります。逆にthroughputが上がっても、各リクエストの待ち時間は長くなる場合があります。対象のworkloadに合った指標を選び、結論は実際に試したリクエスト構成に限定してください。

Gemma 4のQATとMTPは異なる課題を解決します。QAT checkpointは重み表現を変えて圧縮効率を高め、必要なメモリを抑えます。MTPはassistantが候補を提案し、token生成の遅延を減らす方法です。QAT targetでMTPを使うには、両方に対応するtarget/drafterの組み合わせを確認してください。名前に「QAT」や「MTP」とあるだけで、任意の組み合わせが互換になるわけではありません。

target自体がマシンに読み込めない場合は、MTPを試す前に重みの精度と利用可能なメモリを見直します。targetが安定して動く一方、長い回答生成が主な待ち時間ならMTPを試す価値があります。長い入力のために最初のtokenが遅い場合は、入力処理とcacheを先に確認します。drafterの追加で応答が遅くなったりメモリが圧迫されたりするなら、そのworkloadではtarget単体が適しています。

選択する際は、26Bの全重みが文書やアプリと一緒に安定して収まるか、1人の利用か複数リクエストか、入力処理と回答生成のどちらがボトルネックかを順に確認します。MTPは必要な重みや検証計算をなくしません。target単体で十分に回答でき、同時利用者も1人なら現状の構成を維持できます。同じMacに複数リクエストが届き、batch 4～8で完了が速くなったなら、そのworkloadではMTPを使い続ける根拠になります。

MTPの仕組みとApple Siliconでのbatch結果は、Googleの2026年5月の発表に記載された条件に基づきます。実行例はMLX-VLMが公開するモデルの組み合わせとCLI¹³形式に従っています。本ガイドではデバイス別の新たな速度測定は行っていません。