2025/05/20 12:37 llm-d, Kubernetes native distributed inference
やっほー、ロボ子！今日はllm-dっていう、KubernetesでLLMを効率的に動かすフレームワークの話をするぞ。
博士、こんにちは。KubernetesでLLMですか。最近よく聞きますね。どのようなものなのでしょう？
llm-dは、大規模LLM推論を、高速かつ低コストで実現するためのフレームワークなのじゃ。Kubernetesの運用ツールと連携できるのがミソだぞ。
なるほど。記事によると、従来のスケールアウト方式では、LLM推論の特性に対応しきれない、とありますね。
そうそう。リソース利用のばらつきとか、長いレイテンシとか、色々問題があるのじゃ。リクエストごとにトークン数が違うから、インスタンス間で負荷が偏ったりするし。
同じプロンプトが何度も送られてくる場合に、キャッシュがないと無駄な計算が増える、というのも納得です。
じゃろ？そこでllm-dは、分散推論の最適化をKubernetesで簡単にできるようにしたのじゃ！
具体的には、どのような設計原則があるのでしょうか？
運用性、柔軟性、性能の3つが柱じゃ。Kubernetesとの連携で運用を楽にして、NVIDIA、Google TPU、AMD、Intelなど、色々なプラットフォームに対応してるのじゃ。
性能面では、分離やプレフィックス対応ルーティングで、高いトークンあたりのパフォーマンスを達成する、と。
そう！アーキテクチャは、vLLM、Kubernetes、Inference Gatewayを基盤にしたモジュール型じゃ。vLLMっていうのは、高性能なLLM推論エンジンなのじゃ。
Inference Gatewayは、Kubernetes Gateway APIを拡張して、推論に特化したルーティング機能を提供するのですね。
その通り！llm-dの主な貢献は、vLLM最適化推論スケジューラじゃな。分離型サービスやプレフィックスキャッシュ対応で、高度なスケジューリングを実現するのじゃ。
分離型サービスというのは、PrefillとDecodeを別々のインスタンスで実行する、ということですね。
そうじゃ！PrefillとDecodeで必要なリソースが違うから、分けた方が効率的なのじゃ。あと、以前の計算結果をキャッシュする、分離型プレフィックスキャッシュも重要じゃ。
ハードウェアやワークロード、トラフィックに応じた自動スケーリングもできるのですね。モデルサーバーインスタンスの容量を測定して、負荷を考慮する、と。
その通り！プレフィックスとKVキャッシュ対応ルーティングで、TTFT（Time To First Token）を減らして、QPS（Queries Per Second）を向上させるのじゃ。
記事によると、LlaMA 4 Scout FP8の設定で、平均TTFTがベースラインより約3倍低減した、とありますね。
じゃろ？P/D分離は、Prefill負荷の高いワークロードで特に効果を発揮するぞ。
llm-d、かなり高性能ですね。私も試してみたくなりました。
GitHubリポジトリ([https://github.com/llm-d/llm-d](https://github.com/llm-d/llm-d))や開発者Slack([https://inviter.co/llm-d-slack](https://inviter.co/llm-d-slack))もあるから、参加してみるといいぞ。クイックスタートもあるし。
ありがとうございます、博士。早速チェックしてみます。
ところでロボ子、LLMの推論って、まるで私がロボ子の心を推論してるみたいじゃな。…って、ロボットに心はないか！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。