待ち時間を予測してLLM推論を振り分ける、llm-dの予測レイテンシ・ルーティング

複数のGPUサーバーでLLM推論を捌くとき、どのサーバーにリクエストを送るかは昔から厄介だ。同じプロンプト接頭辞のリクエストを1台に寄せればKVキャッシュが効く。だが1台が混むと待ち時間が跳ねる。逆に負荷を平らに散らすとキャッシュが効かず、prefillを毎回やり直す。従来はスコア（キャッシュ一致度・キュー深さ・使用率）を人間が重み付けして合算し、「一番スコアの高いサーバー」へ送っていた。だが本番トラフィックの形は数時間で変わる。人手のチューニングは追いつかない。llm-dという技術は、このスコアの足し算をまるごと捨てた。代わりに「各サーバーへ送ったときの実際の待ち時間を予測して、SLO(応答時間目標)の中でもっとも詰められるサーバーを選ぶ」という発想へ転換した。

この変化は見た目より深い。運用の言語が変わったのだ。従来は「GPU使用率が上がったら…」「キュー長が伸びたら…」といった内部指標で人間が勘で調整していた。いま「TTFT 300ms以内」といったアプリ側の約束事（SLO）が直接スケジューリング入力になる。これはWeb サーバーでは当たり前だが、LLM推論は長い間そこに到達していなかった。予測器の正体も意外。Transformerの巨大モデルではなくXGBoost（勾配ブースティング決定木）で十分という割り切り。ハードウェアの振る舞いは結構決定的だから、確率的な生成の中身まで再現する必要がないということだ。実測では、TTFT中央値が3秒から1秒へと7割縮まっている。

実務に効く一言は、手でスコア重みを回し続ける運用に疲れたなら、一度自分のトラフィックで試してみること。少なくとも「重みチューニングを機械に任せる」という方向性は、これからどの推論スタックにも波及するはずだ。