現場実装の クムビーバー です。評価レポートを厚くする前に、速さの期待をどう検証するかを揃えます。
速い生成は、いつも得なのか
コーディング支援では「もう少し速く補完してほしい」という要望がよく出ます。そこで候補になるのが 投機的デコーディング（speculative decoding） や MTP 系の仕組みです。vLLM でも extra_args 経由で試せる領域として挙がります。
ただし、現場で大事なのはオンオフではありません。
- いつ効くか
- いつ効かないか
- 品質（特にコードとツール呼び出し）を壊さないか
- どの種類のコーディングで測ったか
この回は、実装者が検証前に持つべき見取り図です。
何が起きているか
ざっくりした流れは次です。
- Draft側が、先にトークン候補を速く作る
- **Target側（本モデル）**が、その候補を検証する
- 合意できたトークンだけが受理され、出力になる
うまくいくと、本モデルだけで一歩ずつ進むよりトークン生成が速く感じられます。うまくいかないと、下書きを捨てるコストが勝って期待外れになります。
手法候補（名前を揃える）
「投機」も一枚岩ではありません。コーディング検証で並びうる候補は、ざっくり次です（製品名より 方式の型 で比較します）。
| 方式 | ひとことで | コーディング比較での扱い |
|---|---|---|
| MTP | 本モデル側に近い自己投機。起動設定で試しやすい | まず baseline と並べやすい本線候補。効くかはエンジン実装依存 |
| DSpark | 特定モデル系列向けの専用投機ビルド系統 | その系列で本番相当を見るときの候補。他モデルへそのまま横展開しない |
| DFlash | draft/専用経路を伴う投機系統のひとつ | 候補に挙げる。draft 準備と実測が揃ってから採用判断 |
| EAGLE / EAGLE-3 | 公開 draft 等を使う系統（エンジンによっては TRT-LLM 経路） | 方式比較の列として残す。エンジンとセットで見る |
| Medusa 等 | 複数ヘッド系の投機 | 地図上の周辺候補。実測が薄いときは「未検証」とラベルする |
比較表では 方式名 + エンジン + モデル系列 をセットで固定します。「投機オン」だけでは、DSpark と MTP を同じセルに混ぜてしまうのと同じです。コーディング用途でも、関数レベルで効いた方式がエージェント段階で効くとは限りません。
コーディング検証は段階で拾う
「コーディング用途」と一口に言っても、検証対象は分かれます。投機の採否をこの段階を混ぜたまま決めると、会議が壊れます。
| 段階 | 現場イメージ | 検証で拾うもの（例） | 投機で特に見る失敗 |
|---|---|---|---|
| 関数レベル | IDE補完、短い関数生成 | pass@1（HumanEval+ / MBPP+ 等）、構文・実行エラー | 構文崩れ、テスト落ち、受理は高いが正しさが落ちる |
| リポジトリレベル | Issue 修正、複数ファイル変更 | 解決率、変更精度、破壊的変更・無関係差分 | 長い出力で受理低下、差分が荒れる |
| エージェントレベル | ツール実行・多段タスク | tool 選択/引数、完遂率、ループ率 | tool_call 崩れ、パーサ不一致、回復失敗 |
| 周辺スライス（別枠） | テスト生成、セキュリティ診断など | 用途固有スイートの合否 | 関数 pass@1 と相関しない劣化 |
ピックアップのルールは単純です。
- 比較表の行に 段階ラベル を付ける（関数 / リポジトリ / エージェント）
- 投機なし baseline と投機ありを、同じ段階・同じスイート版で並べる
- 段階をまたいだ「総合で速い」は作らない（必要なら段階ごとに列を分ける）
関数レベルで効いた設定を、エージェント本線へそのままコピーしない方が安全です。
投機比較で見る指標セット
| 観点 | なぜ重要か | 見るもの |
|---|---|---|
| 受理 | 速さの実効値 | acceptance rate、Mean Accepted Length（MAL）など |
| 実効速度 | 体感と集約 | 実効 tok/s、必要なら TTFT/E2E |
| 品質保持 | 速さの前提条件 | 段階ごとの品質指標（QualityRetention の考え方） |
| ばらつき | 体感の不安定さ | p95、失敗率、finish_reason |
速さだけ見て採用すると、「たまに速いがたまに壊れる」補完になり、開発体験が悪化します。
検証の最小手順
- 対象のコーディング段階を1つ決める（例: 関数レベル）
- 投機なし baseline を
run_idで残す - 投機ありを1軸だけ有効化して、同じ段階のスイートを回す
- 受理・実効吞吐・品質内訳を並べる
- 品質が落ちたら本線候補から外す（速度が良くても）
- 別段階（リポジトリ / エージェント）へ広げるなら、表を分けてやり直す
チェックリスト（投機を試す前）
- [ ] コーディング段階（関数 / リポジトリ / エージェント）を決めたか
- [ ] 投機なし baseline の run_id があるか
- [ ] その段階の品質内訳（関数なら pass 系、エージェントなら tool_call 等）を見る準備があるか
- [ ] 受理率（または同等指標）を記録できるか
- [ ] 品質低下時に本線へ載せないルールがあるか
- [ ] 補完用途とエージェント用途を混ぜていないか
効く条件・効かない条件
投機が効きやすいのは、出力が比較的予測しやすい領域です。逆に、次が分岐する指示や厳密なフォーマット要求では、受理が落ちやすいことがあります。エンジン実装（verify の重さ）でも向きが変わるので、「ハードが同じなら効く」とは限りません。
コーディング現場での実践ルールは次です。
- まず投機なしの baseline を残す
- 段階を固定した品質スイートで見る
- 受理率と実効吞吐をセットで記録する
- 品質が落ちたら速度が良くても本線に載せない
ポイント
投機はブースターであって、門番（品質スモーク）の代替ではありません。採否は コーディング段階ごと に決めます。
つまずいたこと
投機デコーディングを入れるとデモが映えます。そのぶん、効く条件を確認せず本番相当に載せようとして品質が揺れた経験があります。
困ったのは速度の喜びが強く、失敗ケース（長い出力、ツール呼び出し、温度）の観測が後回しになったことです。速さは条件付きの道具だと腹落ちするまで、余計なプロファイルが増えました。
この回の要点
- 手法候補（MTP / DSpark / DFlash / EAGLE 等）は方式・エンジン・モデル系列で分ける
- コーディング検証は関数 / リポジトリ / エージェントに分けて拾う
- 投機比較は同じ段階・同じスイートで baseline と並べる
- 速さは条件付きの道具。品質が落ちたら本線に載せない
いま公開しているのは評価の型です。実機ベンチの数字は、再計測と匿名化が済んだものから順に足します。合格ラインや用途別プロファイルの未確定は残っています。
次は「性能評価プレイブック：何を、どの順で、どう読むか」へ進みます。いまのメモを1行残してから読むと、連載の筋がつながりやすくなります。
よくある質問
投機的デコーディングは常に得ですか？
いいえ。ドラフトの外れが多いと検証コストが勝ち、体感が悪化することがあります。条件付きの速さです。
コーディング用途はどう分けて測りますか？
関数単位→リポジトリ単位→エージェント（ツール連続）です。段階を混ぜると失敗原因が読めません。
手法名（MTP / EAGLE など）だけで選んでよいですか？
いいえ。エンジン対応・workload・品質ゲートを揃えてから比較します。
