Ripple、CPUの期限に応じてGPU推論を制御するスケジューラーを提案

何が起きたか

論文「Ripple: Deadline-Aware CPU-GPU Sharing for Embodied Inference」が2026-10-31にarXivで公開された。提案方式は、CPUタスクの締め切り余裕からGPU推論に許容するメモリー量を定め、両者の干渉を調整する。DGX Spark上で4種類のロボット向けCPUタスク構成とLLM/VLM推論を評価し、論文は、評価した方式のうちRippleのみがCPUの期限超過率2%以下の目標とVLMの期限を一貫して満たし、ベストエフォートのLLMスループットを保ったとしている。

詳細

Rippleは推論を一時停止可能なレイヤー単位に分割し、各CPUジョブの締め切り余裕をGPUメモリーバイト数の予算に変換する。重複しているCPUジョブすべての予算内で推論処理を許可し、CPUの完了状況を受けたオンライン更新で干渉の変化を追跡する。推論の進行を保つため、締め切りを考慮した実行ペース調整と、SMフットプリントの縮小も用いる。 実装にはSGLangエンジンへのフックと中央スケジューラーを使った。対象のDGX Sparkは、論文によるとGPUメモリー帯域のカウンターと直接的な帯域制御機能を公開していない。

Key Facts

本紙の見方

この研究の主眼はGPUを高速化することではなく、GPUメモリーへのアクセスがCPUの知覚・制御タスクを妨げる状況で、期限を守りながら推論を進める調停方式にある。とくにDGX Sparkでは帯域カウンターも直接の帯域制御も利用できないと論文は説明する。Rippleは帯域をハードウェア側で計測・制限するのではなく、モデルから見積もった推論のメモリー量とCPUジョブの完了フィードバックを使い、推論処理の受け入れ量を決める。ここが方式上の特徴であり、性能値だけでなく、利用できる制御信号が限られた環境で何を代替指標にできるかを示す研究と位置づけられる。 構成上は、CPUジョブごとの締め切り余裕をバイト予算に変換し、同時に走るジョブの予算を満たす範囲で推論を許可する。さらにオンライン更新で干渉の変化を追い、推論をレイヤー単位で止めたり再開したりする。したがって、CPUタスクの期限保証とLLM/VLMの処理継続を別々に扱うのではなく、共有資源であるGPUメモリーへの負荷を介して同じスケジューラー内で調整する設計である。期限を優先する場面では推論側の進行を抑える必要があるが、論文の要約はその調整量やスループットへの影響を数値では示していない。 ロボットシステムへの含意は、制御・知覚のCPU処理と大規模モデル推論を同じエッジ機器で併用するとき、平均処理速度だけでは評価できず、CPU側の期限超過とVLM側の期限を併せて見る必要がある点にある。論文は4種類のロボット向けCPUタスク構成で評価したとしており、単一のCPU負荷だけを対象とした結果ではない。一方、実験結果が示すのはDGX Sparkと記載されたタスク構成・期限条件の範囲であり、異なるGPU、ロボットの実機運用、より多様なタスクへ同じ達成度が及ぶとは結論できない。次に確認すべきなのは、各タスクの期限やモデル・実行条件、比較対象、LLMスループットの変化量、実機での動作と安全性である。これらが明らかにならなければ、期限保証と推論性能の両立を別の機器や運用条件に適用できるかは判断しにくい。

なぜ重要か

論文の評価では、GPUメモリー帯域を直接制御できないDGX Spark上でも、CPU期限超過率2%以下の目標とVLMの期限を満たしながらLLMスループットを保ったとしている。ロボットの知覚・制御とLLM/VLM推論を同じ機器で動かす設計では、推論処理の量をCPUタスクの締め切りに応じて調整するという具体的な選択肢になるが、適用範囲は論文で評価した条件に限って捉える必要がある。