speculative decodingを負荷に応じて切り替えるadaptive運用

revision_id: EA-759-RESEARCH-20261027-R1 evidence_as_of: 2026-10-27 JST status: RESEARCH_COMPLETE / INDEPENDENT_REVIEW_PENDING

投機的デコードは、draft側が提案した複数トークンをtargetモデルが検証し、採用できる範囲をまとめて進める方式です。adaptive運用では、draftの長さ、検証する量、投機を使う経路などを、受理されやすさと計算資源の混雑に応じて調整します。常時有効にすれば必ず高速になるという前提を置かず、利用者の待ち時間と提供可能な処理量の両方を評価します。

同じモデルでも、短い対話、長い生成、コード、検索後の回答などで受理される長さが変わり得ます。また、同時実行が増えるとdraftと検証がtargetの処理資源を消費し、低負荷で有利だった設定が不利になることがあります。したがって、平均受理率だけを見て一つのdraft長を全時間帯へ固定する運用は十分ではありません。

vLLMのAdaptive Verification資料[S1]は、各要求・位置の受理見込みと、起動時に測定するコストモデルを用い、ステップごとの検証量を配分する方式を説明しています。既定では無効で、attention backendやCUDA graph、LoRA、pipeline parallelism等に適用制約があります。機能名だけを見てすべての構成で使えると判断しません。

Dynamic Speculative Decoding資料[S2]は、同時実行数の区間ごとにdraft数Kを指定する方式を説明します。K=0の区間も設けられます。確認した資料にはdata parallelismとの非互換と、無効化時に静的設定へ戻る条件があります。これはS1のオンライン推定・検証予算配分と同一の方式ではなく、版やrunnerの条件もそろえて比較する必要があります。

Per-Request Acceptance Metrics資料[S3]は、要求ごとのdraft受理数や検証回数を取得する機能を説明していますが、experimentalで、既定は収集なし、複数sequence要求やstreamingでは取得条件があります。以下は、この確認事実を基にした運用設計の提案です。資料の性能説明を当方の実測結果として採用していません。

第一の制御対象はdraft生成量です。多く提案すれば検証機会は増えますが、不採用が多ければ余分な計算になります。第二は生成されたdraftのうち検証する範囲です。第三は、投機あり・なしの別poolへ要求を振り分ける経路です。モデルを軽量版へ置き換えるroutingは、targetを保ったデコード最適化とは別の品質変更なので分けて扱います。

制御の粒度も、要求開始時、decode step、配備設定変更で異なります。設定変更に再起動が必要な場合、秒単位の負荷変動に合わせてプロセスを再起動する設計は適しません。実行中要求の扱いを確認し、未対応のhot switchingを想定しないようにします。異なる方式を併用する場合も、どちらが最終的なKや予算を決めるかを明示します。

draft受理率は、提案したdraftトークンのうち採用された割合です。一方、検証ステップ当たりの進行量は、採用draft数とステップ数の関係を見ます。vLLMの確認資料ではbonus tokenを含む平均長と、含まないdraft受理数を区別しています[S3]。分母をそろえず、受理率と平均進行量を同じ指標として比較しません。

受理率が高くても、draft生成、検証、通信、同期の費用が大きければ速くならない場合があります。反対に、受理率だけが下がっても、他の要因で全体の応答が改善する場合があります。判断にはTTFT、token間遅延またはTPOT、完了時間、SLOを満たす処理量、GPU時間・費用を組み合わせます。メトリックごとに計測点と定義を記録します。

集約値では要求の違いを隠しやすいため、入力長、出力長、業務種別、同時実行帯で分けます。要求ごとの比率の単純平均と、全draft数を分母にした比率は一致しないことがあります。投機を使わなかった要求、キャンセル、失敗、指標が返らなかった要求の件数も残し、都合のよい成功要求だけの評価にしません。

比較する構成は、投機なし、静的な複数K、同時実行帯別のK、対応するadaptive verificationとします。targetとtokenizer、sampling条件、精度、context、ハードウェア、並列化、実行基盤の版をそろえます。draftモデルを変える場合は、その変更を別の実験要因として記録します。

負荷は一定到着率だけでなく、段階的な増減、短いburst、長い生成が残る時間帯、入力長の偏りを含めます。warmup、グラフ取得、起動時profiling、cacheの温冷条件を区別します。リクエスト完了に合わせて次を送る試験だけでは、遅くなった時に入力負荷自体が下がり、過負荷が隠れることがあります。到着を制御する試験も使い、queueを含む待ち時間を観測します。

結果は平均速度だけでなく、p95/p99の待ち時間、SLO逸脱、失敗、再試行、資源量を含めます。少数の長い要求を速くしたために多数の短い要求が遅くなっていないかも確認します。どの負荷帯で改善し、どの帯で悪化したかを示し、一つの最大高速化率を全用途に一般化しません。

外部の制御器を設ける場合は、観測窓、最低サンプル数、切替条件、保持時間、変更上限を定めます。上げる閾値と下げる閾値を分けるなど、境界付近で設定が往復しない設計が考えられます。これは運用上の提案であり、すべてのvLLM内蔵方式に同じ外部制御器が必要という意味ではありません。

測定が欠落した場合は、受理率0と見なさず、最後に検証した安全な設定へ戻すなどの明示した処理を使います。負荷、draft長、replica数を同時に変更すると原因を判別しにくくなります。自動スケーラーとの責任範囲を分け、片方の変更をもう片方の観測窓へ記録します。

投機を抑えることで処理費用が下がっても、それだけでqueueが解消するとは限りません。すでに容量が不足していれば、admission control、要求長の制限、追加容量などの対策が必要です。逆にreplicaを増やして同時実行が下がると、以前不利だった投機が有利になる可能性があります。単独最適化の結果を固定せず、全体のSLOで確認します。

高速化の方式がtarget分布を保つことを意図していても、採用した実装・sampling・量子化・構造化出力等の組合せが正しく動くことは別途確認します。通常出力、停止条件、長い生成、構造化出力、streaming、キャンセル等の回帰試験を用意します。確率的出力の比較で、文字列の完全一致だけを唯一の正しさ判定にしません。

fallbackには、同じtargetを投機なしで実行する経路、制限した静的設定などを選べます。ただし再送によって外部ツールの副作用を二重実行しないよう、生成と実行の責任を分けます。互換性のない設定が黙って無効化される製品では、設定ファイルの値だけでなく起動ログと実効動作を確認します。

停止条件は、性能の悪化、SLO超過、出力条件の不一致、エラー増加、観測不能などから定めます。切り戻した設定、対象要求、影響時間を記録し、失敗したadaptive方式を無限に再有効化しないようにします。十分な比較ができない業務では、検証済みの静的設定を維持する判断も妥当です。

• 対象配備のrelease/commit、draft/target、GPU、sampling、LoRA、parallelism、runner、実効メトリック、最適Kや制御閾値は未確認です。
• 本RUNでのGPU推論、負荷試験、受理指標取得、hot switching、品質・sampling整合性、費用比較はすべてNOT_RUNです。性能改善率は算出していません。
• latestのAdaptive VerificationとstableのDynamic SDは、確認時点の資料をそれぞれ参照しています。同じreleaseで併用可能、同じ制約、と断定しません。採用時は一つのrelease/commitへそろえて再確認します。
• SAFE_WORDINGは「負荷帯と受理特性ごとに、適用可能な投機量・検証量を比較し、SLOと費用で選ぶ」です。「高い受理率なら必ず高速」「adaptiveなら全負荷で最適」「K=0ならdraftモデルの全費用が消える」とは表現しません。

[S1] vLLM, Adaptive Verification, https://docs.vllm.ai/en/latest/features/speculative_decoding/adaptive_verification/ 。2026-10-27 JST確認。方式、Support、Requirements and limitations。動的な検証配分と適用条件の根拠です。

[S2] vLLM, Dynamic Speculative Decoding, https://docs.vllm.ai/en/stable/features/speculative_decoding/dynamic_speculative_decoding/ 。同日確認。batch size別K、Limitations。S1とは別方式として使用しました。

[S3] vLLM, Per-Request Acceptance Metrics, https://docs.vllm.ai/en/latest/features/speculative_decoding/acceptance_metrics/ 。同日確認。experimental、Enabling、Response Format、Streaming、aggregateとの対応。指標の分母と取得条件の根拠です。

統合台帳EA_MASTER!760の正規topicを維持しました。原案Google Doc 1_9XrDkXlopnx39HlRa1YDO8yRvOEBXup2vvY6senU7s、EA-759見出しt.0:250948に残る基礎調査済みの申告と未検証URLを出発点に、今回一次資料を取得しました。改訂台帳の正式改訂、SOURCE_EA_RELATIONの接続行、実作業中の対象claimは確認されませんでした。原案にある掘り下げ先の親EAは未確定のため、推測して関係を登録していません。