エージェントのツール待ちでGPUが遊ぶなら、復帰タイミングまで見てスケジューリングすればよいはずです。 TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving 🔎 概要 LLM推論とツール実行を繰り返すエージェント向けに、ツールの復帰時刻とKVキャッシュ再利用を合わせて評価し、受け入れるセッションを組合せ最適化で決めるスケジューラです。 ⚠️ 解決する課題 ・既存のスケジューラはツール復帰のタイミングを直接使わない ・セッション単位の貪欲な判断で、容量を奪い合う別の組合せを塞いでしまう 🛠 方法論 ・セッションごとに「減衰するキャッシュ価値（半減期10秒）」「ツール復帰の準備完了」「トークン数」の3つを順に比較 ・容量状態の動的計画法で、待機セッションの選択とノード割当を同時に決定 ・DPは非同期ワーカーで走り、適用前に実際の状態と照合。オーバーヘッドは実行時間の0.12%未満 📊 実験結果 ・DeepSeek-V4 Flash、SWE-Lite、64ワーカーで、最良ベースライン比で遅延最大26.8%減、TTFT最大36.3%減、デコード最大29.5%増 ・DPをBFDに替えると、デコードは1417.97から1233.72 tok/sへ低下 ・一方、AutomationBenchの128ワーカーではTTFTが悪化するなど、全条件で勝つわけではありません #LLMServing# #AIAgents#

61億リクエスト・9,174モデル・1年間の非サンプリング本番トレースでLLMサービングの実態を解明——LLM基盤の設計者なら必読の論文です。 A Year in LLM Serving: Workload Evolution, Caching and Load-Balancing 🔍 概要 Chutesの本番環境から1年間（2025年4月〜2026年4月）のリクエストレベルトレースを収集。61.2億リクエスト・31.5万ユーザー・9,174モデルという規模で、LLMサービングの実態を初めて包括的に可視化しました。 ⚠️ 解決する課題 既存研究は短期間・サンプリング済み・単一モデルという制約を抱えていました。本論文はその空白を埋め、プレフィックスキャッシュの再利用・ルーティング・負荷分散を実データで検証します。 🔬 主要な発見 ・ワークロードは非定常: リクエスト数と実際のコストは別のトレンドで変化する（短期観測では容量計画が不正確になる） ・出力トークンは短縮傾向: 年初の数百トークンから年末は100以下へ下降 ・キャッシュ再利用の 99% は前回リクエストから 15分以内に到着（80% は 0.1秒以内） ・LRU は多くの場合に複雑アルゴリズムと同等以上、ARC は中間サイズで大幅劣化 ・Cache-first ルーティングはラウンドロビン・ロードファーストを大幅に上回り、負荷不均衡は 5〜7% 以内に収まる ・Sticky ルーティングは最高ヒット率だが負荷不均衡が桁違いに大きく非現実的 📊 実験結果 100K トークンの MiniMax-M2.5 リクエストは約27GB のKV状態を占有し、インスタンス間転送には約20.4GB が必要。ルーティングの変動がKV複製を招き、キャッシュ局所性と負荷分散は本質的なトレードオフを持ちます。Cache-first は局所性を保ちつつ、単一ターンセッションが多いという性質のため負荷不均衡が抑制されます。 #LLM# #MLシステム#

💾 TL;DR: 別ノードのGPUが計算したKVキャッシュを、CXLメモリ経由でそのまま使い回して最大36.6倍高速化。SeagateがKubernetesネイティブな共有CXLメモリの仕組みを提案しました。 タイトル: Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving URL: 📌 ポイント 🧩 Kubernetes DRAドライバでCXLリージョンをスケジュール可能なリソース化 🗂 Redis等の外部調整なし、リージョン内蔵のスロットディレクトリでKV管理 🚀 32Kトークンのプレフィックスでクロスノード再利用が再計算比36.6倍高速 🎯 ヒット率は95.4〜99.5%を達成 ⚖️ クロスノードと同一ノードの遅延差はわずか1〜4% 🐢 同一ノードのGPU VRAMキャッシュと比べると1.15〜1.70倍のペナルティあり 🔧 実測帯域は5.8GB/sでファブリック上限27GB/sの一部、ゼロコピーDMAに伸びしろ 複数GPUノードでプレフィックスを使い回したいときの、地味だけど効く実用的な選択肢だと思います。 #LLM推論# #Kubernetes#