見出し画像

爆速でLLMを動かしたい。ココ最近の推論エンジンの進化が早すぎるから一回まとめよう/Hipfire/AMD最適化Rust推論エンジン/MTPLX/ネイティブMTP推論/TPU×Dflashで3倍速い/Gemma4MTPモデル

ゆいまる‐IT界隈以外でAIを使いまくる2005年生まれ

最近ローカルLLMでの開発が上手いこと進まない。

なんせ遅い。
8T/sで動かす時が多いし、ミニPCが何度も異常を起こしてる
運用が下手すぎるのもあるけど、現実的じゃないのかなとしょげしょげ中。

で、なんとかならんかと。色々調べるわけですよ
すると希望を感じる話題がこんもり。
特に最近の推論エンジン関係を調べてみると凄い話ばっかり。

一回まとめときたい。

llama.cppもMTPに対応したらしいし、違うタイミングでllama.cppも整理したい。今回は以下の奴。

  • Hipfire　AMD最適化のRust推論エンジン

  • MTPLX　ネイティブMTP推論

  • TPU×Dflashで3倍速いぞ

  • Gemma4のMTPどらふたーモデル


AMD RDNA GPUに最適化された推論エンジン「hipfire」：その実力と導入メリット

1. 概要：Rustで構築された次世代のRDNAネイティブ推論エンジン

AMD RDNAアーキテクチャを採用したGPU（RadeonシリーズやRyzen APU）は、高い計算密度を備えながらも、LLM（大規模言語モデル）の推論環境においてはその真価を十分に発揮しきれない現状がありました。

汎用的な推論エンジンではデータセンター向けのCDNAアーキテクチャが優先され、コンシューマー向けハードウェアが「二級市民」として扱われることが多いためでした。

この構造的課題に対し、RDNAへの完全最適化を掲げて開発されたのが「hipfire」。

hipfireの設計思想における最大の特徴は、Rust言語とHIP（Heterogeneous-compute Interface for Portability）による徹底的なネイティブ実装にあります。

特筆すべきは、推論のクリティカルパスにPythonを一切介さない「No Python in the hot path」を実現している点。さらに実行時にROCmのユーザースペース・スタックを要求しないため、ドライバ周りの複雑な依存関係に悩まされることなく、単一のバイナリ（Single binary）で動作。

対応ハードウェアはRDNA1から最新のRDNA4（Navi 48 / 9070 XTを含む）まで多岐にわたり、コンシューマー用GPUからプロフェッショナル向け、さらにはモバイル環境のAPUまで幅広くサポート。

事前ビルドされたカーネルの提供に加え、JIT（Just-In-Time）コンパイル機能を備えることで、多様なハードウェア構成において常に最適なパフォーマンスを引き出します。

2. 性能：7900 XTXで実証された圧倒的な処理能力

推論エンジンの評価において、スループット（トークン/秒）は最も重要な指標の一つ。RDNA3世代のフラッグシップであるRadeon RX 7900 XTX (gfx1100) を用いたテストでは、hipfireのアーキテクチャがいかに効率的であるかが実証されています。

なお、本プロジェクトはDavide Ciffa氏によるLucebox DFlashの研究成果から強い影響を受けており、ベンチマーク手法においてもその厳格なプロトコルを継承しています。

最新リリース（v0.1.9-alpha.1）における、7900 XTX（デフォルト設定：asym3 KV、FlashAttention自動選択）のデコード速度は以下の通り。

  • Qwen 3.5 0.8B：391 tokens/sec（プリフィル・ピーク：7383 tokens/sec）

  • Qwen 3.5 4B：180 tokens/sec（プリフィル・ピーク：2487 tokens/sec）

  • Qwen 3.5 9B：132 tokens/sec（プリフィル・ピーク：1663 tokens/sec）

  • Qwen 3.5 27B：47 tokens/sec（プリフィル・ピーク：478 tokens/sec）

さらに、hipfireは「DFlash」による投機的デコード（Speculative decoding）に加え、最新のアップデートで「PFlash」による投機的プリフィル（Speculative prefill）の実装も進めています。

DFlashは、特にコード生成のような特定のタスクにおいて劇的な加速をもたらします。Qwen 3.5 27Bを用いたHumanEvalベンチマークでは、通常の自己回帰（Autoregressive）生成と比較して約4.45倍となる「218 tokens/sec」のピーク性能を記録。

ただし、DFlashの高速化の恩恵は「ジャンル依存（genre-conditional）」であることには注意が必要。

コード生成等の予測しやすいシーケンスでは圧倒的ですが、タスクの性質によって加速率は変動。こうした現実的な性能特性を誠実に開示することも、エンジニアリングにおける信頼性の証と言える。

3. 他モデルとの性能比：既存ソリューションに対する優位性

既存のデファクトスタンダードであるOllama（llama.cpp + ROCm）と比較すると、hipfireの構造的な優位性はさらに明確に。

汎用スタックがAMD Instinct MIシリーズ等のエンタープライズ向けカードを主軸に設計されているのに対し、hipfireはRDNAのハードウェア特性を直接叩く実装を採用しているためです。

Qwen 3.5シリーズにおける「vs ollama Q4_K_M」のデコード速度比較では、以下の倍率を記録。

  • Qwen 3.5 0.8B：Ollama比 2.10倍

  • Qwen 3.5 4B：Ollama比 1.78倍

  • Qwen 3.5 9B：Ollama比 1.71倍

この圧倒的な効率性を支えているのが、低レイヤーにおける独自の数学的・建築的アプローチ。具体的には、MQ4/HF4といった独自の量子化デザイン、非対称（asym）KVキャッシュ、そしてFWHT（Fast Walsh-Hadamard Transform）数学を用いた演算最適化などが組み込まれています。

これらのRDNA専用の最適化パスこそが、汎用エンジンでは到達不可能なパフォーマンスを生み出す源泉となっています。

4. どんな悩みを解決するか：RDNAユーザーの「痛み」への回答

多くのAMD GPUユーザーにとって、最大の障壁は「環境構築の複雑さ」と「サポートの格差」でした。ROCmのインストール手順は難解で、PythonやPyTorchの特定バージョンへの依存による環境の肥大化・競合は、開発者の生産性を著しく低下させてきました。

hipfireは、以下の戦略的なアプローチによって、これらの「痛み」を直接的に解消。

  • ランタイム依存の排除：実行パスからPythonを排除し、シングルバイナリで動作するため、ライブラリの競合や環境汚染のリスクがありません。

  • ROCm管理コストの低減：実行時に複雑なROCmユーザースペース・スタックを必要としない設計は、ポータビリティとメンテナンス性を飛躍的に高めます。

  • ハードウェアの再評価：データセンター向けカードの「お下がり」ではない、RDNA専用のカーネル（MMQ自動ディスパッチ等）を提供することで、手元のRadeonやAPUを強力なAIワークステーションへと変貌させます。

これにより、ユーザーはインフラストラクチャのトラブルシューティングから解放され、モデルの活用やアプリケーションの実装という本来の目的へ集中することが可能に。

5. 活用方法：導入から実践的な運用まで

プロフェッショナルな現場での運用を想定し、hipfireは既存のワークフローへ容易に統合できるよう設計されています。

  • 簡潔な導入：Linux（ROCm 6+）環境では、単一バイナリの配置で即座に運用を開始できます。Windows環境についても、ソースからのビルド手順が整備されています。

  • 直感的なTUI：hipfire chatコマンドにより、対話型のターミナルユーザーインターフェースが利用可能です。Ollamaライクな直感的な操作感で、モデルの検証が迅速に行えます。

  • APIによる拡張：OpenAI互換のHTTP API（SERVE.md）を提供しているため、既存のLLM連携アプリケーションのバックエンドを、設定変更のみでhipfireに差し替えることができます。

  • 柔軟な量子化：hipfire quantizeサブコマンドを使用することで、Hugging FaceやSafetensors、GGUF形式の既存モデルを、RDNAに最適化されたMQ4/HF4フォーマット等へ変換し、性能を最大化することが可能。

このように、導入の容易さと高度なカスタマイズ性が両立されており、ローカル開発から小規模なサーバー運用まで幅広く対応します。

6. まとめ：RDNA GPUの可能性を最大限に引き出すために

hipfireは、AMD RDNAアーキテクチャの潜在能力を余すことなく引き出すために生まれた、極めて純度の高い推論エンジン。

Rustによるネイティブ実装、DFlash/PFlashといった最新実行技術、そしてRDNA4（Navi 48）までを見据えた継続的なアップデートにより、Radeonユーザーにとっての標準的選択肢となり得る実力を備えています。

現在、プロジェクトは v0.1.9-alpha.1 という段階にあり、さらなる最適化と機能拡張が進められています。AMDのGPUを所有しててもっと高速・安定した、そして依存関係に縛られない推論環境を求めるすべての開発者・エンジニアにとって、hipfireは今すぐ試すべき最も有力なツールなのかも。

次はMacユーザーがうらやまになる話。つかいてー。

Apple Siliconの限界を超える：ネイティブMTP推論「MTPLX」の全貌

1. はじめに：MTPLXが切り拓くローカルLLMの新たな地平

Apple Silicon（Mシリーズチップ）の統合メモリ（Unified Memory）アーキテクチャは、パーソナルコンピューティングにおけるAI推論の常識を塗り替えました。しかしLLM実用化においては常に速度と精度、そして「メモリ消費量」のジレンマに直面しやすい。

特に、推論を加速させるための「スペキュラティブ・デコーディング（投機的デコーディング）」では、別途ドラフトモデルを用意する必要があり、それが貴重なRAMを圧迫するという矛盾を抱えていました。

このトレードオフを根本から破壊するのが、ネイティブMTP推論エンジン「MTPLX」。

MTPLXは、Apple Siliconのポテンシャルを極限まで引き出すために設計されたMLXネイティブな実装であり、外部モデルを一切必要としない「Native MTP」という革新的なアプローチを採用。

この技術の戦略的意義

RAM消費を抑えることで、本来ならドラフトモデルに割かれるはずだったメモリ領域を、より高精度な量子化ビット数や、より大規模なターゲットモデル（例えば14Bモデルの代わりに27Bモデルを載せるなど）に充てることが可能になります。計算資源を賢く、かつ最大限に活用する――MTPLXはローカルAI環境の新たな標準を提示しているのです。

2. MTPLXの概要：外部ドラフトモデルを不要にする革新

MTPLXの核心は、その名の通り「Native MTP（Multi-Token Prediction）」にあります。従来の高速化手法とは一線を画す、その内部構造を深掘りしましょう。

外部モデル不要のメカニズム

MTPLXは、Qwen3.6-27Bなどの最新モデルに組み込まれている「MTPヘッド」をドラフトモデルとして直接利用。ターゲットモデル自身のパーツを使用するため、追加のRAM消費はゼロ。これはメモリ効率において圧倒的な優位性をもたらします。

エンジニアを唸らせるカーネルレベルの最適化

MTPLXは単なるMLXのラッパーではありません。独自の「MLXソースフォーク（mlx-mtplx-0.31.2-qmm）」をベースに、Metalカーネルレベルでのチューニングが施されています。

  • Small-M qmv retuning: 通常のMLXはバッチサイズが大きい場合に最適化されていますが、スペキュラティブ・デコーディングの検証フェーズ（M=3..6程度）では性能が頭打ちになります。MTPLXでは、この「Small-M」領域の量子化マトリックス・ベクトル演算（qmv）を再調整し、4-simdgroup構成やループアンロールの最適化を行うことで、検証速度を劇的に向上。

  • linear-gdn-from-conv-tape: 検証時の状態復元を高速化するため、ドラフト時の状態を「イノベーション・テープ」として記録し、ロールバック時に決定論的に再現する専用カーネルを実装しています。

  • GraphBank: コンパイル済みの検証グラフをキャッシュすることで、Pythonのディスパッチ・オーバーヘッドを排除。コミット時間をわずか0.073ms（検証時間の約1/1000以下）にまで抑え込んでいます。

数学的な厳密さの担保

高速化のために精度を犠牲にすることはもうしなくて良さそう。

Leviathan & Chen (2023) の研究に基づき、確率比受理（probability-ratio acceptance）と残差補正（residual correction: (p - q)+）を忠実に実装。さらに、BF16でのアンダーフローを防ぐため、p/q比の計算にはfp32を採用。

これにより、Temperature > 0 の設定下でも、ターゲットモデル本来の確率分布を100%再現（max_diff = 0.0）することを保証。

3. 驚異の性能：M5 Maxで証明された2倍以上の加速

MTPLXが叩き出す数字は、Apple Silicon上での推論の限界を押し広げます。

現在公開されている「Youssofal/Qwen3.6-27B-MTPLX-Optimized-Speed」を用いたベンチマークでは、標準的な自己回帰（AR）推論と比較して、約2.24倍の加速を達成。

M5 Max（メモリ帯域幅 614 GB/s）環境における実測値では、通常の推論が約28.156 tok/sであるのに対し、MTPLX（MTP-D3設定）では約63.056 tok/sに到達。

ここで特筆すべきは、この「2.24倍」という加速倍率が、ハードウェアのスペックに関わらず一定の乗数として機能する（multiplier is hardware-independent）という点。

メモリ帯域の異なるM2、M3、M4といった各世代のチップにおいても、それぞれのベースラインから約2.2倍のジャンプアップが期待できます。絶対的な速度（TPS）はデバイスの帯域に依存しますが、MTPLXがもたらす「効率の向上分」は全てのMacユーザーに等しく提供。

4. 他モデル・従来手法との性能比：正確性と効率の比較

MTPLXの立ち位置を、既存の代表的な手法と比較して整理。

  • 標準的AR推論（llama.cpp / mlx-lm）: これらは1トークンずつ順番に生成する「逐次処理」。対してMTPLXは、MTPヘッドでK個のトークンを予測し、ターゲットモデルで一括検証する「並列処理」を行うため、TPSにおいて圧倒的な差が生まれます。

  • DFlash等の手法比較: 既存の多くの高速化ツールは、Temperature > 0 において「greedy-argmax（最も確率の高いものを選ぶ）」という簡易的な手法を採るため、本来のモデルの回答傾向が崩れる「分布のドリフト」が避けられません。MTPLXは数学的補正により、この問題を完全に克服。

  • 外部ドラフト方式との比較: 先述の通り、追加モデルをロードしないためRAM消費はゼロ。

単に「速い」だけでなく「正確で、かつメモリ効率が良い」。この三位一体の実現こそが、開発者がMTPLXを信頼して自身のワークフローに組み込める最大の理由。

5. MTPLXが解決する実務上の悩み

ローカルLLMを実務で使う際、MTPLXの具体的回答。

  • レスポンスの遅さによる集中力の途切れ: 2.2倍以上の加速は、もはや「待ち時間」を感じさせないレベル。特にClineやClaude CodeといったAIコーディング支援ツールにおいて、低遅延なレスポンスは開発リズムを劇的に改善。

  • ハードウェアへの負荷と安定性: 「ThermalForge」機能により、Macのファン制御（100%固定など）が可能。また、万が一プロセスがクラッシュしても、独立したウォッチドッグ（監視役）が即座にファンをオート設定に戻します。さらに15分間のアイドル状態でファンを自動停止させるなど、実運用におけるハードウェア保護にも配慮。

  • 「プレビューの誠実さ」という信頼: MTPLXは、現在のv0.1において「コールドパス（短時間のバースト）」では2.24倍を達成している一方、ファンなしでの持続的なスループットにはまだ改善の余地があることを率直に公開しています。この技術的な透明性は、プロフェッショナルなユーザーにとって非常に信頼に値する。

6. 活用方法：シームレスな統合と導入ステップ

MTPLXの導入は驚くほどスムーズ。高度なカーネル最適化を内包しながらも、ユーザーが複雑な設定に悩まされることはありません。

インストールとセットアップ

HomebrewやPyPI（0.1.0rc3）から簡単に導入でき、初回起動時にはインタラクティブなウィザードが、最適なモデルの選定や環境構築をガイドします。HuggingFaceやLM Studio、LM Cacheなどの既存モデルフォルダをスキャンし、MTP対応状況を4段階（Verified / Arch-compatible / etc.）で自動分類する機能も備えています。

エコシステムとの連携

OpenAI APIおよびAnthropic APIと互換性のあるサーバー機能を搭載しているため、既存のフロントエンドをそのまま活用できます。

  • Open WebUI: ブラウザベースの洗練されたUIでチャットが可能。

  • Cline / Claude Code: 低遅延なバックエンドとして、AIエージェントによるコーディングを劇的に加速。

  • 内蔵チャットUI: リアルタイムのTPS表示やMTPのオン/オフ切り替え、コードコピー機能など、ローカル利用に特化した機能が揃っています。

7. まとめ：Apple Siliconで極限の推論体験を

MTPLXは、Apple Silicon上でのLLM実行における「精度」「効率」「互換性」を極限まで追求した、まさにエンジニアのための推論エンジン。

外部モデルを排除し、モデル自身が持つMTPの潜在能力を「Small-M qmv retuning」や「GraphBank」といった高度な技術で解き放つアプローチは、ローカルAIの未来を明確に示しています。ずるい

現在はv0.1のプレビュー段階ですが、既にその実力はベンチマークが証明する通り。次期アップデートであるv0.2では、持続的なスループットのさらなる改善が予定されています。

Macという強力なハードウェアを所有しているなら、そのポテンシャルを眠らせておく手はありません。MTPLXをバックエンドに差し替え、2.2倍以上に加速されたストレスフリーな感じ、うらやますぎる。

そんな中、TPU使ったらDflashも凄いぞって話も。

DFlashのGoogle TPUへの移植：大規模言語モデル推論の革新的高速化

推論高速化アルゴリズム「DFlash」をGoogle TPU（Tensor Processing Unit）へ移植した際の主要な成果、技術的課題、および推論アーキテクチャに与える影響をまとめた。

UCサンディエゴの研究者とGoogleのチームにより、DFlashがVLLMフレームワーク内のGoogle TPUに統合され、従来の投機的デコーディング手法を大幅に上回る性能が確認。

主な成果として、数学やプログラミングなどの論理的推論タスクにおいて最大5.72倍、全体平均で約3倍の高速化が報告されている。

技術面では、TPUのメモリ帯域幅がボトルネックとなる特性を突いた「検証コストの固定化」という重要な洞察が得られており、今後の推論最適化の焦点を計算量からドラフトモデルの精度向上へとシフトさせる可能性を示唆している。

DFlashの基本メカニズム

DFlashは「投機的デコーディング（Speculative Decoding）」の一種であり、以下のプロセスを通じて推論を高速化。

  • 逐次生成の回避: 標準的な言語モデルは1トークンずつ生成を行うが、DFlashは「ドラフトモデル」と呼ばれる軽量ヘルパーモデルを使用。

  • 一括予測: ドラフトモデルはメインモデルの内部の隠れ状態（Hidden States）を分析し、次の16トークンを1回のフォワードパスで一括予測。

  • 一括検証: メインモデルはこれら16個の予測トークンを一度に検証する。予測の多くが正解であれば、通常1トークンの生成にかかる時間で最大16トークン分の処理を完了。

TPUにおけるパフォーマンス実績

Google TPU上での検証では、既存の最適化手法である「Eagle 3」を凌駕する数値が記録されている。

ベンチマーク比較

指標 / タスク
従来手法 (Eagle 3 / Baseline)　DFlash　改善率 / 速度
一般的なスピードアップ
1.3倍 (Eagle 3)　2.29倍　約1.76倍 (対Eagle 3)
数学タスク (MATH 500)
9.84 ms/token　4.08 ms/token　2.4倍以上
コーディング (MBPP)
9.81 ms/token　3.48 ms/token　約2.8倍
数学タスク等
Qwen 2.5 (7B) 平均　-　3.13倍　　-
Qwen 2.5 (7B) ピーク時　-　5.72倍

タスク特性による差異

  • 高予測タスク（数学・コード）: 構造的な推論パターンが存在するため、ドラフトモデルの予測精度が高まり、最大の恩恵を受ける。

  • チャット・自由記述: 予測のランダム性が高いため改善幅は緩やかになるが、依然として有意な高速化を実現している。

技術的課題と解決策

DFlashをGoogle TPUおよびVLLM環境に適合させるにあたり、以下の主要な課題が克服された。

1. アテンション・アーキテクチャの互換性

DFlashが採用する「非因果的ブロック拡散（Non-causal Block Diffusion）」は、TPUの推論で標準的に使用される「ページド・アテンション（Paged Attention）」システムと根本的に互換性がなかった。

  • 解決策: 「デュアルキャッシュ・アーキテクチャ」を導入。メインモデルは最適化されたページド・アテンションを維持しつつ、ドラフトモデルにはDFlash本来の設計を反映した独立したパスを通すことで両立。

2. 長文コンテキスト（128kトークン）への対応

長いコンテキストにおいて、ドラフトモデルのアテンション計算が二次関数的に増大し、速度が低下する問題があった。

  • 解決策: 「Flash Prefill」に似た技術を移植。4つのカスタムカーネルを実装することで、ドラフトモデルのアテンションブロックを疎（Sparse）にし、重要な部分のみを処理対象とすることで計算負荷を低減。

重要な洞察：Kflatとボトルネックの変化

本移植プロセスにおける最も重要な発見の一つが、TPUハードウェアにおける検証コストの特性である。

  • 検証コストの不変性: TPU上では、16トークンの検証を行うコストと、1024トークンの検証を行うコストがほぼ同等であることが判明。

  • メモリ帯域幅の制約: データセンター級のハードウェアにおいては、ボトルネックは「計算量」ではなく、メモリからモデルの重みをロードする「メモリ帯域幅」にある。

  • 戦略の転換: 重みを一度ロードしてしまえば、追加の計算による検証は「実質無料」となる。したがって、今後の研究の焦点は「検証ウィンドウの拡大」よりも、「ドラフトモデルがいかに正確に予測できるか（予測精度の向上）」に移るべきであることを示している。

実装の現状と今後の展望

DFlashのTPU実装は、単なる研究プロトタイプに留まらず、実用化に向けた段階にある。

  • オープンソース統合: VLLMのTPU推論リポジトリに対し、以下の3つのプルリクエストが提出されている。

    1. モデルアーキテクチャの定義

    2. エンドツーエンドのパイプライン統合

    3. テストフレームワーク

  • 主流化の加速: UCSDのZ-Labによる研究から始まり、消費者向けGPUでの動作検証を経て、現在はGoogleとの協力により大規模生産環境を支えるTPUインフラへの統合が進んでいる。

ブロック拡散を用いた投機的デコーディングは、AI推論の高速化における標準的な手法としての地位を確立しつつある。

んで、Gemma4のMTPドラフターモデルもでてきた。
このモデルは3倍速いし精度も落ちないらしい。まずは概要調べて使いたいなと思い、調べた内容を共有ですー。取り敢えずスペックだけで使用確定

Google Gemma 4 MTP Drafter モデル：技術概要とパフォーマンス

Google は、Gemma 4 モデルファミリー向けに公式の MTP (Multi-Token Prediction) ドラフターモデルをリリース。

Gemma 4 はリリース当初、その推論速度の遅さが課題として指摘されていたが、この軽量なコンパニオンモデルの導入により、出力の質を一切損なうことなく劇的な高速化が可能に。

実証テストでNvidia H100 GPU を使用した場合、MTP ドラフターの有効化によって推論速度が約 3 倍（8.8 tokens/sec から 27.4 tokens/sec）に向上することが確認。

この技術は「推論的デコード（Speculative Decoding）」に基づいており、小規模なドラフターモデルが次に来るトークンを予測し、大規模なターゲットモデルがそれを一括で検証する仕組み。

なのでMTP のメカニズム、パフォーマンスの検証結果、および類似技術である D-Flash との比較について詳述したいって話です。

1. 背景：Gemma 4 の課題と MTP の導入

Gemma 4（特に 31B モデル）のリリース後、コミュニティからは同サイズの他モデルと比較して動作が極めて遅いという不満が寄せられていた。

この低速化の主要因は従来LLMが採用している逐次生成方式

  • 従来の方式: 31B のような巨大なモデルが、すべての計算リソースを投入してトークンを 1 つずつ生成する。1 トークンごとに膨大な計算が発生するため、生成プロセス全体が停滞。

  • Google の解決策: 各 Gemma 4 バリアントに対して、軽量な「ドラフターモデル」を開発。これをメインモデルと並行して実行することで、生成プロセスのボトルネック解消。

2. MTP (Multi-Token Prediction) の動作メカニズム

MTP は推論的デコード（Speculative Decoding）と呼ばれる手法を活用している。このプロセスは以下の 2 つの役割分担で構成される。

ドラフターモデルとターゲットモデルの連携

  1. Drafter Model: 非常に小さく高速なモデル。メインモデルに先んじて、次の数トークン（例：4 トークン分）を推測。

  2. Target Model: Gemma 4 31B 本語体。ドラフターモデルが行った複数の推測を、1 回のパスでまとめてチェックする。

特徴と利点

  • 同一の出力品質: 最終検証は常に大規模なターゲットモデルが行うため、ドラフターモデルを使用しても使用しない場合と出力結果は完全一致。

  • 効率的な計算: 推測が正しければ、1 回分の計算コストで複数のトークンを得ることができる。推測が外れた場合はその分を破棄してやり直すが、トータルのスループットは向上。

  • スピードの向上: ハードウェア構成にもよるがGoogle のデータでは A100 環境で最大3倍、より強力な H100 環境でも大幅な速度向上が実証。

3. パフォーマンス検証：実機による比較

Nvidia H100 (80GB VRAM) を使用した環境で、Gemma 4 31B モデルに複雑なプロンプト（病院管理システムの設計）を与えた際のパフォーマンス比較は以下の通りである。

推論速度の比較

構成　トークン生成速度　2048 トークン生成時間
MTP ドラフターなし　8.8 tokens/sec　約 232 秒（推定）
MTP ドラフターあり　27.4 tokens/sec　74 秒

リソース消費

  • VRAM 使用量: モデル本体は約 62〜63GB を消費。KV キャッシュの増大により、実行時には 63GB をわずかに下回る程度から変動。

  • モデルサイズ: 31B ターゲットモデルに対し、ドラフターモデルはわずか 939MB 程度と極めて軽量。

4. 他技術との比較：MTP vs. D-Flash

MTP と類似の高速化技術である D-Flash は、どちらも「小さなモデルで推測し、大きなモデルで検証する」という基本構造は共通しているが、推測のプロセスにおいて決定的な違いがある。

項目　MTP (Multi-Token Prediction)　D-Flash / P-Flash

推測のプロセス
逐次連鎖的: 1 つ目のトークンを予測し、それを使って 2 つ目を予測する「連鎖」方式。
一括処理: トークンのブロック全体をマスクし、1 回のフォワードパスで同時にノイズ除去（デノイズ）を行う。
パスの回数
提案するトークン数が多いほど、ドラフターモデルのパス回数が増える。
トークン数に関わらず、ドラフターのコストはほぼ一定（フラット）。
コンテキストの活用
ドラフターモデル自身の予測に基づく。
大規模モデル内部の「隠れ状態（Hidden States）」にアクセスし、より豊かな文脈を利用する。
効率性
構造が単純だが、提案数に比例して計算が増える。
受容率（Acceptance Rate）が高く、大量のトークン提案において効率的。

5. 結論

Google が提供を開始した MTP ドラフターモデルは、Gemma 4 をローカル環境やプロダクション環境で運用する上で不可欠なコンポーネント。ドラフターを導入することで、モデルの精度や品質を犠牲にすることなく、推論速度を約 3 倍に引き上げることが可能となる。

特に大量のテキスト生成を必要とするタスクにおいて、このパフォーマンス向上は極めて大きな利点となる。ローカル環境で Gemma 4 を実行する場合、ドラフターモデルを併用しない理由は事実上存在しないと言える。

つまり、使うの確定ー！

まとめ

全体的に見比べるとこんな感じ。
まずはMTPとDflash。

どっちも希望が有ってよき。
次に一覧表。3回くらいつくりなおしたー

Gemma4とTPUは合体した。別々に整理すると訳解んない表になったからです

まぁ、それぞれの会社に沿って推論エンジンが活性化されている感じ。
TPUもMacも持っていない私はミニPCでHipfireを使うしかないので、実質一択ではある。でも、他の技術を知ることでいつか応用できるかも知れないしね。

結論

ローカル、少しははやくなりそう

いいなと思ったら応援しよう！

ゆいまる‐IT界隈以外でAIを使いまくる2005年生まれ よろしければ応援お願いします♡ いただいたチップはクリエイターとしての活動費に使わせていただきます！