Tensormesh、KVキャッシュの再利用でLLM推論コストを削減するプラットフォームを発表

AIアシスタントは、長い文書を受け取るたびに、回答を始める前にその内容を処理する必要がある。同じ文書や指示、会話履歴が再び登場すると、その処理の多くが繰り返される可能性がある。企業規模で運用する場合、この繰り返しによって、有用な作業が増えないまま高価なGPUの処理能力が消費されることがある。

Tensormeshは、2026年10月14日に発表したTensormesh Platformで、この課題の解決を目指している。オープンソースのLMCacheプロジェクトを生み出したチームを擁する同社は、自社インフラで大規模言語モデルを提供する組織向けに、キー・バリューキャッシュ（KVキャッシュ）を管理するエンタープライズ向けレイヤーを提供する。

このプラットフォームは、GPUメモリ、CPUメモリ、ストレージにまたがって、再利用可能な推論状態を管理する。目的は明快だ。GPU群で繰り返す必要のあるプロンプト処理を減らすとともに、キャッシュされた状態の保持、共有、監視方法を運用担当者が制御できるようにする。

KVキャッシュが重要な理由

LLM推論には、重要な段階が2つある。プリフィルでは、モデルが入力プロンプトを処理する。デコードでは、応答をトークンごとに生成する。KVキャッシュには、処理済みトークンをモデルが参照できるようにする、中間的なアテンション関連の状態が保持される。そのため、すべてを最初から再計算する必要がない。

入力コンテキストが繰り返される場合、リクエスト間でその状態を再利用することで、プリフィルの処理を減らせる。たとえば、サポートアシスタントは、何百もの異なる質問に答えるために、同じ製品マニュアルを参照することがある。エージェントは、変化するタスクに取り組む際、同じ指示やツールを繰り返し含める場合がある。

これは、完成した回答をキャッシュすることとは異なる。システムは、共有コンテキストに関連する計算を再利用しながら、新しい質問に対する新たな応答を生成できる。

vLLMの自動プレフィックスキャッシュのドキュメントでは、同じ文書に関するクエリの繰り返しや複数ターンの会話における、この仕組みのメリットが説明されている。また、重要な制約も示されている。プレフィックスキャッシュが高速化するのはプロンプト処理であり、新たな出力トークンの生成ではない。長い回答が中心のワークロードや、入力の大部分が毎回異なるワークロードでは、効果が小さくなる可能性がある。

企業の導入担当者にとって重要なのは、実際のワークロードのうち、再利用可能なコンテキストがどの程度を占めるのか、そして、そのコンテキストを再計算するよりも速く、低コストで取り出せるのかという点だ。

キャッシュを管理型インフラへ

Tensormeshの発表では、セキュリティ、可観測性、レジリエンス、ポリシー管理、マルチテナンシーという5つの運用上の優先事項が挙げられている。これらは、キャッシュデータの保護、パフォーマンスの追跡、障害からの復旧、保持と削除の制御、共有インフラ上でのチームや顧客の分離といった、実務上の課題に対応するものだ。

同社はさらに、キャッシュエントリーの固定、検索、移動、圧縮、消去を行うコントローラーAPIについても説明している。これにより、キャッシュのライフサイクル管理は明確な運用上の課題となり、個々の推論プロセスに全面的に委ねられることはない。

基盤となるLMCacheプロジェクトは、キャッシュ管理をサービングエンジンから切り離し、複数のストレージ階層にまたがる退避と取得に対応する。同プロジェクトのドキュメントでは、リクエスト、セッション、エンジンインスタンス間での再利用が説明されており、ストレージと転送のバックエンドをプラグインで追加できる。

エンタープライズ向けプラットフォームは、この基盤を発展させたものだ。インストールガイドによると、Kubernetesオペレーターがキャッシュエンジンのコンポーネントを管理し、キャッシュサーバーはGPUノード上に、クラスター全体を調整するコーディネーターは別途配置される。デプロイにはHelmを利用でき、運用にはウェブインターフェースとコマンドラインツールが使える。

GPUメモリが限られたリソースであるため、このアーキテクチャは重要だ。再利用できる可能性のあるプロンプトをすべてGPUメモリに保持すれば、ほかの推論処理に必要なメモリと競合する。すぐには必要性の低い状態をホストメモリやストレージに移せば、保持できる量を増やせる一方、取得にはそれ自体の帯域幅とレイテンシのコストが伴う。

同一のプロンプトプレフィックスを超えた再利用

プレフィックスキャッシュは、2つのプロンプトが同じトークン列で始まる場合に効果を発揮する。一方、検索拡張生成（RAG）では、より難しい場合がある。アプリケーションが関連文書を検索しても、それらの文書の順序が異なったり、その前に続くテキストが異なったりすることがあるためだ。

同じ文書を使う、仮想的な2つのリクエストを考えてみよう。一方は文書Aの後に文書Bを含み、もう一方は文書Bの後に文書Aを含む。どちらにも再利用可能な内容が含まれているが、冒頭で共通する部分は短いかもしれない。

TensormeshはCacheBlendを使い、プロンプトの冒頭部分に限らない再利用を可能にする。LMCacheのドキュメントによると、キャッシュ済みのチャンクを再利用しながら、トークンの一部を選択的に再計算する。チャンクを取り巻くコンテキストがモデルの内部状態に影響するため、この再計算が重要となる。

EuroSys 2025で発表されたCacheBlendの研究論文では、評価対象のワークロードにおいて、KVをすべて再計算する場合と比べ、最初のトークンが出力されるまでの時間が2.2～3.3倍速く、スループットが2.8～5倍高かったと報告されている。著者らは、オープンソースの3つのモデルと4つのベンチマークデータセットを評価した。

これらは特定の条件下で得られた研究結果であり、Tensormeshをどのように導入してもコスト削減が保証されるわけではない。しかし、共有プレフィックスを超えた再利用が技術的に興味深い理由は示している。従来のプレフィックス照合では見逃される有用な計算を再利用できるためだ。

ノード間の再利用と、バージョンごとの対応状況の重要性

発表では、あるノードが別のノードからキャッシュ済みの状態を取得できる、ピアツーピアのKV転送が紹介されている。また、同社の製品資料では、プリフィルとデコードの分離について説明されている。分離によってプロンプト処理と出力生成を切り分け、異なるワーカーでそれぞれ実行できる。

これらは、推論を構成するうえで相補的な方法だ。互換性のある状態を共有すれば、別のノードで同じ処理を再計算せずに済む。処理段階を分離すれば、インフラチームは各段階の処理需要に合わせてリソースを異なる形で割り当てられる。

ただし、公開資料の間でリリース状況の説明は完全には一致していない。発表時の紹介ではノード間共有と分離が説明されている一方、9月17日付のバージョン別互換性マトリクスでは、ピアツーピア転送と分離はロードマップに掲載されている。機能ドキュメントには、プレビュー版のページも含まれている。

同じマトリクスでは、Tensormeshがテストで検証した機能と、上流でサポートされているものの、本番環境で使う前に追加テストが必要な機能が区別されている。サービングエンジンとして、vLLMとNVIDIA Dynamoは検証済み、SGLangとTensorRT-LLMはロードマップ上にあると記載されている。

そのため、幅広い互換性があるというリリース時の説明は、設計上の方向性を示すものであり、あらゆるモデルとインフラの組み合わせが検証済みであることを意味しない。チームは、導入を予定しているリリース、サービングエンジン、モデル、キャッシュモードの組み合わせを確認する必要がある。

発表時の紹介では、ROCmを介してNVIDIAまたはサポート対象のAMD Instinct GPUを使用するKubernetes上のvLLMと、ファイルシステムを基盤とするストレージが具体的に説明されている。高密度モデル向けの非プレフィックスキャッシュとSGLangへの対応は、今後の予定として紹介されている。また、キャッシュは自社ホスト型モデルと併用するものであり、任意のホスト型モデルAPIに接続できるアドオンではないことも明記されている。

効果が期待できる場面

有力な候補となるのは、共有コンテキストを繰り返し大量に処理するアプリケーションだ。たとえば、社内ナレッジアシスタント、文書分析サービス、あるいは安定した指示や参照資料を何度も利用するエージェントが挙げられる。

有効な評価方法は、実際のトラフィックを代表するデータを使い、キャッシュがない場合と温まった状態のキャッシュがある場合の動作を比較することだ。運用担当者は、初回トークン生成時間、スループット、キャッシュ取得時間、GPU使用率に加え、状態の保持にかかるメモリ、ストレージ、ネットワークのコストを測定する必要がある。

キャッシュヒット率だけでは十分な判断材料にならない。ヒット率が高くても、転送や管理のオーバーヘッドを差し引いたうえで、再利用した処理が正味のメリットをもたらす場合に限り有効だ。同様に、最初のトークンが速く生成されても、応答全体がそれに比例して速く完了するとは限らない。

特に、キャッシュされたチャンクを異なるコンテキストで組み合わせる場合は、回答品質を別途確認する必要がある。CacheBlendの選択的な再計算はこの問題への対処を目的としているが、本番環境でのテストでは、組織独自の文書、プロンプト形式、モデル構成を対象にするべきだ。

キャッシュが単一プロセスの外に広がるにつれ、データの保持期間やテナント間の分離も、より重要になる。運用上確認すべきなのは、誰がキャッシュ項目を再利用できるのか、どのくらいの期間利用可能なのか、ポリシーの変更や削除要求が保存済みの状態にどう影響するのか、といった点だ。Tensormeshが発表した管理機能は、こうした判断を制御可能にすることを目的としている。

繰り返しの処理を減らす現実的な一手

同社の発表によると、Tensormesh Platformは発表と同時に利用可能になった。その意義は、推論の状態をフリート全体で管理できるリソースとして扱い、リクエストの処理が終わった後も再利用可能な計算結果を保持する点にある。

自社でLLMインフラを運用する企業にとって、これは効率を高める具体的な手段となる。つまり、すでに実行したプロンプト処理をより多く再利用することだ。その効果は、ワークロードの反復性、キャッシュの互換性、データ移動のコストに左右される。しかし、いずれも測定可能なエンジニアリング上の課題であり、チームは自社のトラフィックを使って検証できる。