KubeCon CloudNativeCon Japan 2026 参加レポート
先日、横浜で開催された「KubeCon CloudNativeCon Japan 2026」に参加してきました。
様々なセッションがあった中で、個人的に一番気になったのが、セルフホストのLLM（大規模言語モデル）のインフラ基盤に関するテーマでした。
普段LLMは利用するだけで内部のインフラがどのようなアーキテクチャなのか興味があったのと、そこにどのような工夫があるのか知りたかったためです。
普段はアプリケーション寄りの開発をすることが多いのですが、今回は「KVキャッシュ」というキーワードを中心に、別々のセッションの内容が見事にリンクしていて面白かったので、備忘録も兼ねてまとめたいと思います。
そもそも「KVキャッシュ」とは？
各セッションで当たり前のように出てきた「KVキャッシュ」ですが、ざっくり言うと「LLMが文章を生成するときに、過去の計算結果をメモリ（VRAM）に覚えさせておいて、計算を高速化するための仕組み」です。
LLMは1単語ずつ文章を作りますが、これがないと毎回「最初の文字から全部計算し直し」になってしまい使い物になりません。ただ、このKVキャッシュ、「ユーザーとの会話（コンテキスト）が長くなればなるほど、ものすごい勢いでGPUのメモリを食いつぶす」という厄介な性質を持っています。
以下参考
https://zenn.dev/sre_holdings/articles/f15290860986ad
1. Agenticワークロードで悲鳴をあげるインフラ
> セッション: How to Evolve Your LLM Self-Hosting Platform: A Practical Guide to Adopting Advanced Optimizations
LINEヤフー（LY Corporation）さんのセッションでは、AIエージェントが自律的に動く「Agenticワークロード」において、インフラがいかに過酷な状況にあるかが語られていました。
エージェントが裏側で何往復もループ処理を行うため、トラフィックがスパイクしやすく、さらに文脈が長くなることでVRAM（特にKVキャッシュ）へのプレッシャーが跳ね上がるとのこと。
解決策としての「ルーティング」と「P/D分離」
この課題に対して、かなりアグレッシブな最適化手法が紹介されていました。
- **KV Cache Aware Routing:**
「システムプロンプト」のような共通の前提知識を持つリクエストを、すでにそのキャッシュを持っているPod（サーバー）に狙い撃ちでルーティングする手法。キャッシュを使い回せるので、初回レスポンスが早くなりGPU効率も上がるそうです。
- **P/D Disaggregation（PrefillとDecodeの分離）:**
推論プロセスを、最初の重い計算（Prefill）と、その後の1文字ずつの生成（Decode）に分け、「それぞれ専用のGPUプールに分離（Disaggregation）してしまう」という力技とも言える手法。同じGPUでやるとリソースを食い合うから物理的に分けよう、という発想。
※画像は発表時のスライド
2. P/D分離が引き起こす、新たな「ネットワークの壁」
> セッション: Project Lightning Talk: Longhorn: What's New & What's Next for Cloud Native Persistent Storage
別のネットワーク関連のセッションを聞いてまた気づきがありました。
計算（Prefill）と生成（Decode）のサーバーを物理的に分けるということは、「Prefill側で作ったGB（ギガバイト）クラスの超巨大なKVキャッシュを、ネットワーク越しにDecode側へ転送しなければならない」ということです。
つまり、GPUのボトルネックを解消した結果、今度はネットワークが最大のボトルネックになってしまいます。
- **PD KV Transfer:** キャッシュの転送遅延がそのまま推論の遅さ（スループット低下）に直結する。
- 経路のストレージ帯域が詰まったら、迂回ルート（DualPath KV Offload）などを駆使しないといけない。
これを解決するためには、スケールアウト時のネットワークトラフィックを細かく監視（Observability）する必要があるとのこと。先に聞いたセッションの裏側にこんなトレードオフがあるのかと、インフラ全体のトレードオフの難しさを感じました。
※画像は発表時のスライド
おわりに
LLM特有のインフラ課題（特にKVキャッシュ周りの攻防）は私が普段触れている領域とは違う特色があり新鮮で、学びが多かったです。
ただ新しい技術を使うだけでなく、「どこがボトルネックになるのか」「それをどう回避するのか」というインフラエンジニアの方々の工夫を知れたのは、今後の設計を考える上ですごくプラスになりました。引き続き、クラウドネイティブとAIの進化にキャッチアップしていきたいと思います。
