何が起きたか
arXivは2026-09-23、走行推論向けの計算割り当て手法「SlackDrive」を掲載した。論文は、実行済みフォワードの遅延からオンラインで計算状態を推定し、次の制御ステップに使う計算予算を推論前に決める枠組みを提案している。評価はNAVSIM v2とDriveDreamer-Policyで行い、厳しい遅延条件下でlatency-constrained EPDMSが最良比較手法を21.7%上回った。
詳細
論文は、まず小さな離散的な予算集合について遅延と計画効用を1回だけプロファイルし、その後は完了したフォワードの情報を使ってオンラインで計算状態を見積もる設計としている。これにより、許容遅延の枠内に収まると予測される中で最も効用の高い予算を選ぶという。 著者は、既存の高速化がトークン数、層数、サンプリング回数を事前に減らす方式に寄っており、共有オンボード計算資源上で残る実行時の変動を十分に使えていないと説明している。SlackDriveは、既存のプロファイリングや資源スケジューリングを補完しつつ、駆動バックボーンとその計算アクチュエータは維持するとしている。
Key Facts
| SlackDriveは、実行済みの遅延を再利用して各制御ステップの計算予算を推論前に選ぶ pre-inference compute allocator である。 | [1] |
| 論文は、small discrete budget set を一度だけプロファイルし、完了した forwards からオンラインで計算状態を推定する設計を採る。 | [1] |
| 評価環境は NAVSIM v2 と DriveDreamer-Policy である。 | [1] |
| 厳しい遅延条件下で、latency-constrained EPDMS は strongest baseline に対して 21.7% 改善した。 | [1] |
| full-budget model と preconfigured token-pruning baselines は、runtime contention 下で admissible latency envelope を超えた。 | [1] |
本紙の見方
SlackDriveの新しさは、走行推論の高速化を「事前に軽くする」発想から、直前に観測した遅延を使って「その制御ステップに許される計算量を選び直す」発想へずらした点にある。著者自身が述べる通り、既存法はトークン数や層数、サンプリング回数をあらかじめ削るが、SlackDriveは実行後の遅延を手掛かりに計算状態を推定し、許容遅延の枠内で使える予算を選択する。ここでは、モデル自体を置き換えるのではなく、モデルの前段にある予算決定層を差し込む構造が核であり、計算資源の使い方を制御ループに取り込んでいる点が本質だとみられる。 本紙の関連記事はないため、過去報道との接続はできないが、論文の記述だけでも論点は明確である。NAVSIM v2とDriveDreamer-Policyという組み合わせで21.7%改善が示された一方、フル予算モデルと事前設定のtoken-pruningは実行時競合下で遅延制約を破った。つまり、固定的な削減ではなく、実行時の残余スラックを読む能力が差別化要因になっている。これは、オンボード計算が共有資源である限り、モデル精度だけでなく「いつ、どれだけ回すか」を決める制御が性能を左右することを示す。 業界構造への含意としては、焦点がモデルの圧縮率からスケジューリング粒度へ移る。小さな離散予算集合を一度プロファイルし、その後は実行済みフォワードから状態を読むという設計は、計算量の最適化を静的設定ではなく運行時制御の問題に変える。これにより、同じバックボーンでも遅延制約の厳しい場面では別の予算を選ぶ必要が出るため、評価指標は平均性能だけでなく遅延制約下の安定性に寄る。未確定の論点は、実車系のオンボード環境で同じ選択規則がどこまで再現するか、予算集合の離散化がどの程度細かく必要か、DriveDreamer-Policy以外のworld-actionモデルへ一般化できるかである。
なぜ重要か
走行支援や自動運転では、推論の精度だけでなく制御周期内に収まるかが前提になる。SlackDriveは、arXiv論文の主張として、実行時の遅延を使って次の計算予算を決めるため、固定の軽量化よりも遅延制約に合わせた運用を組みやすい可能性がある。 一方で、効果はNAVSIM v2とDriveDreamer-Policyでの結果に限られている。実車搭載で同じ遅延分布が得られるか、他のモデルや車載計算機で同様に機能するかは、発表内容だけではまだ判断できない。