現場実装の クムビーバー です。評価レポートを厚くする前に、速さの期待をどう検証するかを揃えます。
この回の答え
先読みはいつも速いわけではありません。方式・圧縮・作業負荷を混ぜず、受理率と品質をセットで見ます。外部の大幅な倍増報告をそのまま期待しません。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| 投機的デコーディング | 下書きを先に作り、本モデルが OK した分だけ採用する速さの道具 |
| k | 下書きで何トークン先まで提案するか。大きいほど当たり外れも大きい |
| 受理率（acceptance） | 提案のうち本モデルが OK した割合。低いと捨て作業が増えて遅くなる |
| MTP | 本モデル側に近い自己投機の方式。起動設定で試しやすい本線候補 |
| MoE | 専門家が複数いるモデル構造。step コスト増で投機利得が削られやすいことがある |
| vacuous（空判定） | 検定が実質データ不足なのに PASS に見える状態 |
速い生成は、いつも得なのか
コーディング支援では「もう少し速く補完してほしい」という要望がよく出ます。そこで候補になるのが 投機的デコーディング（speculative decoding） や MTP 系の仕組みです。vLLM でも extra_args 経由で試せる領域として挙がります。
ただし、現場で大事なのはオンオフではありません。
- いつ効くか
- いつ効かないか
- 品質（特にコードとツール呼び出し）を壊さないか
- どの種類のコーディングで測ったか
- どの量子化・どの k で測ったか
この回は、実装者が検証前に持つべき見取り図です。
何が起きているか
ざっくりした流れは次です。
- Draft側が、先にトークン候補を速く作る
- **Target側（本モデル）**が、その候補を検証する
- 合意できたトークンだけが受理され、出力になる
うまくいくと、本モデルだけで一歩ずつ進むよりトークン生成が速く感じられます。うまくいかないと、下書きを捨てるコストが勝って期待外れになります。
手法候補（名前を揃える）
「投機」も一枚岩ではありません。コーディング検証で並びうる候補は、ざっくり次です（製品名より 方式の型 で比較します）。
| 方式 | ひとことで | コーディング比較での扱い |
|---|---|---|
| MTP | 本モデル側に近い自己投機。起動設定で試しやすい | まず基準線と並べやすい本線候補。効くかはエンジン実装・量子化・k 依存 |
| DSpark | 特定モデル系列向けの専用投機ビルド系統 | その系列で本番相当を見るときの候補。他モデルへそのまま横展開しない |
| DFlash | draft／専用経路を伴う投機系統のひとつ | 候補に挙げる。draft 準備と実測が揃ってから採用判断 |
| EAGLE / EAGLE-3 | 公開 draft 等を使う系統（エンジンによっては TRT-LLM 経路） | 方式比較の列として残す。エンジンとセットで見る |
| Medusa 等 | 複数ヘッド系の投機 | 地図上の周辺候補。実測が薄いときは「未検証」とラベルする |
比較表では 方式名 + エンジン + モデル系列 + 量子化 + k をセットで固定します。「投機オン」だけでは、DSpark と MTP を同じセルに混ぜてしまうのと同じです。
認識齟齬になりやすい点（最新検証より）
社内検証で、次の混同が実害になりました。
| 混同 | 起きること | 正しい切り方 |
|---|---|---|
| 「NVFP4+MTP がダメ＝MTP がダメ」 | FP8 上の MTP までまとめて捨てる | 量子化形式を分けて測る |
| 「外部で +100% 超＝自環境でも同じ」 | 期待値が膨らみ、本番適用が雑になる | 自環境の基準線・受理率・step コストを先に測る。MoE では利得が削られやすい |
| 「品質ゲート PASS＝全部見ている」 | McNemar 等が vacuous なのに通った気になる | どの検定が実データで動いたかを確認する |
| 「コードで効いた＝創作でも効く」 | 汎用サーブにそのまま載せる | workload を分ける。構造的コードと散文で効きが逆転することがある |
| 「受理率が悪い＝チェックポイント欠陥」 | 候補を捨てる | draft loader の完全性を先に疑う。起動成功でも重みが無言スキップされ得る |
| 「再起動したら直った／戻った」 | 偶然に見える | bind-mount 等の override が 再作成で無言脱落することがある |
社内では、ある MoE 本番候補について FP8 + MTP（小さな k） は品質ゲートを通したうえで本番適用し、生成速度は十数%前後の改善を確認しました。一方で、外部で語られる大幅な倍増は同条件では再現しませんでした。また、別経路の NVFP4 + MTP は品質退行や起動・安定性の問題で不採用、というように 同じ「MTP」でも量子化と k で別物です。
さらに、専用 draft 経路では 共有 expert など一部テンソルを無言で読み飛ばす実装漏れがあり、起動は成功し出力も正しいのに 受理率だけ悪化した事例があります。速度退行をチェックポイントの欠陥と決めつける前に、loader の完全性とパッチ／override の適用状態を確認します。修正後は受理・純 decode が基準線相当に戻ることもあり、「遅い候補」と「壊れた draft 経路」は別問題です。
ポイント
投機の採否は「方式名」ではなく、量子化・k・workload・品質ゲートのセットで決めます。
コーディング検証は段階で拾う
「コーディング用途」と一口に言っても、検証対象は分かれます。
| 段階 | 現場イメージ | 検証で拾うもの（例） | 投機で特に見る失敗 |
|---|---|---|---|
| 関数レベル | IDE補完、短い関数生成 | pass@1（HumanEval+ / MBPP+ 等）、構文・実行エラー | 構文崩れ、テスト落ち、受理は高いが正しさが落ちる |
| リポジトリレベル | Issue 修正、複数ファイル変更 | 解決率、変更精度、破壊的変更・無関係差分 | 長い出力で受理低下、差分が荒れる |
| エージェントレベル | ツール実行・多段タスク | tool 選択／引数、完遂率、ループ率 | tool_call 崩れ、パーサ不一致、回復失敗 |
| 周辺スライス（別枠） | テスト生成、セキュリティ診断など | 用途固有スイートの合否 | 関数 pass@1 と相関しない劣化 |
ピックアップのルールは単純です。
- 比較表の行に 段階ラベル を付ける
- 投機なし基準線と投機ありを、同じ段階・同じスイート版・同じ量子化で並べる
- 段階をまたいだ「総合で速い」は作らない
関数レベルで効いた設定を、エージェント本線へそのままコピーしない方が安全です。
投機比較で見る指標セット
| 観点 | なぜ重要か | 見るもの |
|---|---|---|
| 受理 | 速さの実効値 | 受理率、Mean Accepted Length（MAL）など |
| 実効速度 | 体感と集約 | 実効トークン毎秒、必要なら最初のトークンまでの時間／完了まで |
| 品質保持 | 速さの前提条件 | 段階ごとの品質指標（QualityRetention の考え方） |
| ばらつき | 体感の不安定さ | p95、失敗率、finish_reason |
| ゲート健全性 | 誤った PASS | 検定が vacuous でないか、サンプル単位の補完の要否 |
速さだけ見て採用すると、「たまに速いがたまに壊れる」補完になり、開発体験が悪化します。
検証の最小手順
- 対象のコーディング段階を1つ決める（例: 関数レベル）
- 投機なし基準線を
run_idで残す（量子化も固定） - 投機ありを1軸だけ有効化して、同じ段階のスイートを回す
- 受理・実効吞吐・品質内訳を並べる
- 品質が落ちたら本線候補から外す（速度が良くても）
- ゲートが vacuous ならサンプル単位で補完してから採否を決める
- 別段階へ広げるなら、表を分けてやり直す
チェックリスト（投機を試す前）
- [ ] コーディング段階（関数 / リポジトリ / エージェント）を決めたか
- [ ] 投機なし基準線の run_id があるか（量子化・エンジン込み）
- [ ] その段階の品質内訳を見る準備があるか
- [ ] 受理率（または同等指標）を記録できるか
- [ ] 品質低下時に本線へ載せないルールがあるか
- [ ] 補完用途とエージェント用途を混ぜていないか
- [ ] 外部の大幅加速報告を、自環境の期待値に直輸入していないか
- [ ] 低受理時に draft loader / パッチ適用 / override 脱落を疑ったか
- [ ] コンテナ再作成後も専用 override が載っているか確認手段があるか
効く条件・効かない条件
投機が効きやすいのは、出力が比較的予測しやすい領域です。次が分岐する指示や厳密なフォーマット要求では、受理が落ちやすいことがあります。エンジン実装（検証の重さ）でも向きが変わるので、「ハードが同じなら効く」とは限りません。
コーディング現場での実践ルールは次です。
- まず投機なしの基準線を残す
- 段階を固定した品質スイートで見る
- 受理率と実効吞吐をセットで記録する
- 品質が落ちたら速度が良くても本線に載せない
- k や量子化を変えたら、別の試合としてやり直す
ポイント
投機はブースターであって、門番（品質スモーク）の代替ではありません。採否は コーディング段階ごと に決めます。
つまずいたこと
投機デコーディングを入れるとデモが映えます。そのぶん、効く条件を確認せず本番相当に載せようとして品質が揺れた経験があります。
困ったのは速度の喜びが強く、失敗ケース（長い出力、ツール呼び出し、温度）の観測が後回しになったことです。速さは条件付きの道具だと腹落ちするまで、余計なプロファイルが増えました。外部の派手な数字をそのまま期待すると、社内の地味な十数%改善まで「失敗」に見えてしまうのも、同じ系統のつまずきです。
この回の要点
- 手法候補（MTP / DSpark / DFlash / EAGLE 等）は方式・エンジン・モデル系列・量子化・k で分ける
- コーディング検証は関数 / リポジトリ / エージェントに分けて拾う
- 投機比較は同じ段階・同じスイート・同じ量子化で基準線と並べる
- 低受理はチェックポイント欠陥の前に draft loader の完全性を疑う
- 外部の大幅加速を、自環境の MoE 本番にそのまま期待しない
- 速さは条件付きの道具。品質が落ちたら本線に載せない
投機の検証手順は公開できますが、外部報告の加速倍率を自環境の本番値としては使いません。品質付きの実機比較は、再計測と匿名化が済んだものから載せます。
次は「速さの測り方：何を、どの順で、どう読むか」です。投機をオンにしたときの基本メトリクスセットへ接続します。
よくある質問
投機的デコーディングは常に得ですか？
いいえ。ドラフトの外れが多いと検証コストが勝ち、体感が悪化することがあります。条件付きの速さです。
コーディング用途はどう分けて測りますか？
関数単位→リポジトリ単位→エージェント（ツール連続）です。段階を混ぜると失敗原因が読めません。
手法名（MTP / EAGLE など）だけで選んでよいですか？
いいえ。エンジン対応・workload・品質ゲートを揃えてから比較します。
外部で「投機で倍以上」と聞いたら本番に載せますか？
いいえ。モデル構造（例: MoE）や量子化形式が違うと利得の桁が変わります。自環境の baseline と品質ゲートが先です。
受理率だけ急に悪くなったらチェックポイント不良ですか？
いいえ。ドラフト用の重みが無言で読み飛ばされていることがあります。起動は成功し出力も正しいのに、受理だけ悪化する型です。
