TensorCastとは？ 大規模言語モデルのテンソル管理を変える「TaaS」構想

TensorCastは、北京大学、AI企業のStepFun、北京郵電大学が提案する、分散型のテンソル管理レイヤーです。位置づけとしては、テンソルをサービスとして扱う 「Tensor-as-a-Service（TaaS）」 の実装にあたります。1

テンソルとは、AIモデルが扱う数値データのまとまりです。大規模言語モデル（LLM）の運用では、モデル本体の重みだけでなく、会話履歴を保持するKV Cacheや各種の中間状態も、複数のGPU・ノード・ストレージにまたがって管理しなければなりません。

TensorCastの狙いは、こうしたテンソル状態の「どこに置くか」「どう運ぶか」「誰が所有するか」「どの形式で使うか」を、テンソルを生成・利用する計算処理から切り離すことです。これにより、重みローダー、KV Cacheシステム、ネットワーク転送、ストレージバックエンドに分散していた管理機能を、共通のプログラム可能な仕組みとして扱えるようにします。1

なぜTensorCastが必要なのか

LLMの推論基盤では、モデル重みは比較的長く保持される一方、KV Cacheはリクエストや会話の進行に応じて頻繁に生成・移動・破棄されます。さらに、推論や学習の途中で生じる中間状態も、必要に応じて別の計算資源へ渡さなければなりません。

従来は、これらの管理を推論エンジン、スケジューラー、通信層、分散ファイルシステムなどが個別に担うケースが一般的でした。そのため、たとえば「KV Cacheの場所を考慮してリクエストを振り分ける」「既存のモデル重みを別の推論インスタンスで再利用する」といった、複数コンポーネントにまたがる最適化を実装するには、複数のシステムを同時に変更する必要があります。1

TensorCastは、ここにテンソルのライフサイクルを専門に扱う抽象化レイヤーが欠けていると考えます。アプリケーションや開発者は「このテンソルを移動する」「先読みする」「複製する」「宛先で利用可能にする」といった方針を記述し、実際の配置やデータ移動はランタイムに任せる設計です。1

一般的なオブジェクトストレージがデータを中身を意識しない単一のオブジェクトとして扱うのに対し、TensorCastはテンソルの状態や利用先を管理対象にします。また、主にタスクの実行順を管理する計算中心のフレームワークとも異なり、テンソルそのもののライフサイクルを中心に据えています。1

TensorCastの主な設計

テンソルを「第一級オブジェクト」として扱う

TensorCastでは、テンソルに明示的な識別子、所有者、配置、ライフサイクルの意味を持たせます。推論エンジンは、モデル重みやKV Cacheのブロックを参照する際に、それがどのノードやGPU、記憶媒体にあるかを直接意識せずに済みます。1

ライフサイクル操作を組み合わせる

データの移動、変換、先読み、複製、実体化といった操作を、用途に応じて組み合わせられます。新しい最適化を試すたびに、推論エンジンやストレージの低レベル実装を大幅に書き換えるのではなく、TensorCastのAPIを使って管理ポリシーを組み立てる考え方です。1

ポリシーと実行メカニズムを分離する

開発者が記述するのは、テンソルをどう管理したいかというポリシーです。分散環境での実行、データの探索、転送、配置先でのメモリ結合などはランタイムが担当します。これにより、基盤の実行エンジンを変更せずに、テンソル管理の方針を試しやすくなります。1

制御プレーンとデータプレーンを分ける

TensorCastの Global Store（GS） は、ワーカーやノードの状態、テンソルの所在、所有権、スケジューリング情報などのメタデータを管理します。一方、実際のテンソルデータを転送するのはWorkerです。

GSはデータ本体を運ばず、調整役に徹します。これにより、中央の管理サービスが大容量テンソルの転送ボトルネックになることを避けます。1

また、モデル重みのように比較的静的で数の少ないデータはGSで集中管理し、KV Cacheのように数が多く変化も激しい状態はシャーディングします。各シャードの拠点となるWorkerが、リースやフェンシングトークンを用いて所有権と整合性を管理する構成です。1

コピーを減らしてテンソルを実体化する

Worker側のレプリカは、GPUメモリをCUDA IPC、CPUメモリをローカルのmemfdハンドルで公開できます。遠隔のデータソースからはRDMAによる直接書き込みにも対応し、不要な中間コピーを抑えます。利用可能な環境では、GPU間や同一ノード内での共有経路も使えます。

KV Cacheの移行がどう簡単になるのか

多ターンの会話では、ユーザーのセッションと、その会話に対応するKV Cacheを同じ推論インスタンスで使い続けることが重要です。しかし、負荷分散などの理由でセッションを別のインスタンスへ移す場合、従来の構成では、リクエストルーター、推論エンジン内部のKV Cache実装、キャッシュやネットワークのバックエンドを連携させて変更する必要がありました。1

TensorCastでは、セッションに紐づくKVテンソルを特定し、移行先Workerへの配置や実体化を要求し、その後のリクエストを移行先へ向ける、というポリシーをテンソル管理レイヤーで記述できます。テンソルの検索、転送、メモリへの結合はランタイムが処理します。1

もちろん、データ移行そのもののコストがゼロになるわけではありません。重要なのは、同じ移行方針を複数の密結合したコンポーネントに重複実装せず、テンソルのライフサイクル管理として一度表現できる点です。キャッシュの局所性を考慮したルーティング、重みの再利用、関連する状態の同一ノードへの配置といった横断的な最適化を、試作・導入しやすくします。1

評価で示された性能

研究チームはTensorCastを、LLM推論基盤として広く使われる vLLM と SGLang に統合し、モデル重みの実体化、重みの同期、KV Cache管理、プログラム可能なリクエストルーティングを評価しました。1

報告された主な結果は次のとおりです。

• KV Cacheの性能は、専用KV CacheシステムであるMooncakeと競合できる水準だったとされています。その一方で、TensorCastは複数コンポーネントにまたがる管理ポリシーを実装できる柔軟性を備えます。1
• 2350億個の総パラメーターと、実際に活性化される220億個のパラメーターを持つQwen3-235B-A22Bでは、モデルインスタンスの起動が一般的な分散ファイルシステムより最大228.6倍速かったと論文で報告されています。12
• 高並列の多ターン・エージェント処理では、プログラム可能なTensorCastポリシーにより、最初のトークンが返るまでの時間であるTTFT（Time to First Token）の中央値が最大93.2%低下しました。1

これらの結果は、モデルの迅速な起動、KV Cacheの場所を考慮したルーティングや移行、テンソル状態の再利用を、個別のフレームワーク向け最適化ではなく、プログラム可能な基盤ポリシーとして扱える可能性を示しています。特に、状態を持つLLMサービスや、負荷に応じて推論インスタンスを増減させる弾力的なAIインフラにとって、設計上の選択肢を広げる提案です。1

ただし、これらは研究プレプリントにおける著者らの実験結果です。TensorCastが実運用でどの程度の効果を発揮するかについては、第三者による再現実験や、本番規模の環境での検証が今後必要になります。1