エージェントのツール待ちで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システム#

🚀 FastAPIを「最初のエンドポイント」から「本番でスケールするAIシステム」まで一気通貫で学べる電子書籍です。LLM/RAG serving まで踏み込み、各章末に面接問題が付くのが実用的です。 タイトル: FastAPI for AI Engineers: From First Endpoint to Production-Scale AI Systems URL: 🚀 概要 PythonでMLモデルやLLM/RAGを本番運用するAIエンジニア向けの実践書（初版・2026年、AI Engineering Insider）。全10章・計100問の面接問題に加え、実在の障害事例やコストモデルのコラムが織り込まれています。 ❓ 解決する課題 ・モデルは作れても、本番でスケールするAPIとして安全に配信するのは別スキル ・LLM/RAGの serving はストリーミング・ガードレール・コスト管理など固有の難しさがある 本書はFastAPIを「AI/MLの事実上の serving レイヤー」として体系化します。 💡 構成と扱う技術 ・基礎：ASGI/WSGI、Uvicorn、OpenAPI、Pydantic v2によるスキーマ分離と検証 ・実装：冪等性、適切なステータスコード、ページネーション、Router→Service→Repositoryのクリーンアーキテクチャ ・DB/セキュリティ：SQLAlchemy/SQLModel/Alembic、N+1、プールサイジング、JWT、BOLA対策、OWASP API Top 10 ・非同期：「イベントループを絶対にブロックしない」、def vs async defの使い分け、httpxのリトライ/サーキットブレーカー 🎯 核心（第9章 AI/RAG/LLM） ・lifespanで重みを一度だけロード、CPU推論はスレッドにオフロード ・LLMゲートウェイで認証・プロンプト・ガードレール・コスト計測を集約、SSEでトークンを逐次配信 ・埋め込み＋ベクトルDB（pgvectorから開始）でRAGを構築し、出力はPydanticで検証→失敗なら差し戻して再試行 ・max_tokensを「支出上限」として型で強制 📊 注目ポイント ・実在の障害（Netflix、Stripe、GitLab、Optus、Air Canada）から学ぶ実践志向 ・第10章はGunicorn+Uvicorn、K8sのliveness/readiness、可観測性の3本柱（p99 vs p50）、SLOベースのアラートまでカバー #FastAPI# #AIエンジニアリング#

TL;DR トークン単位でモデルを切り替えるルーティングは理論上おいしいのに、既存のサービング基盤に載せると遅くなる。その構造的な問題を専用ランタイムで解いた論文です。NeurIPS 2026採択。 タイトル: TokenRouter: Efficient Serving System for Token-Level LLM Routing URL: ポイント 🎯 R2Rは32Bの品質を保ちながら32Bに送るのは全トークンの5%。クエリ単位だと約40%で、細かい粒度の旨味は大きいです 🧱 ところがvLLMやSGLangは全リクエストがステップ同期する前提。遅いモデルを毎ステップ待ち、切り替えのたびにバッチが断片化します ✍️ 開発者はroute・send・receiveの3関数で「1リクエストがどう流れるか」だけ書き、非同期化はランタイムが担当します 🔀 モデルごとに独立したサブサーバを立て、クライアント・デコーディング・モデル間の3ループを分離。KVキャッシュを保ったまま受け渡します ⏳ 到着即実行ではなく閾値までバッファしてから起動。待ちすぎるとSLMが飢えるので、最適値を離散時間マルコフ連鎖から解析的に導きます 📈 15通りのアルゴリズム×ワークロードすべてで改善し、スループットは2.01〜64.15倍 🧪 出力を2,048から8,192トークンに伸ばしても性能が横ばい。標準実装はここでスループットの58〜85%を失います ただし効果の幅は広く、Co-LLMとR-Stitchでは32B単体のほうが速いままです。常に勝てる銀の弾丸ではない点は押さえておきたいところです。 #LLM# #推論基盤#

💾 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#