TensorCast 是什麼？把模型權重與 KV Cache 納入同一套可程式化管理層

TensorCast 是北京大學、階躍星辰（StepFun）與北京郵電大學提出的「Tensor-as-a-Service」（TaaS）層，也就是一套分散式、可程式化的張量生命週期管理系統。它不只負責儲存張量，而是統一管理張量的識別、位置、所有權、搬移、轉換、共享與實體化，並將這些工作與產生或消費張量的計算邏輯分離。1

簡單來說，TensorCast 想在 AI 推理基礎設施中補上一個長期缺少的中間層：讓模型權重、KV Cache 和其他中間狀態不再被分別綁定於特定推理引擎、網路路徑或儲存後端，而是由一套共同的管理介面處理。

為什麼需要 TensorCast？

大型語言模型服務所管理的資料，早已不只是固定的模型權重。多輪對話會持續產生並更新 KV Cache，推理流程也會產生各種中間張量。這些狀態可能分散在不同節點、GPU、CPU 記憶體或儲存介質中，而且會隨著負載變化而搬移、複製或重新實體化。1

傳統架構通常把相關功能分散在多個元件內：

• 模型權重由載入器或儲存系統管理；
• KV Cache 由推理引擎與專用快取後端處理；
• 請求路由由排程器負責；
• 節點之間的資料移動則依賴特定網路與傳輸機制。

這種「各自最佳化」的做法雖然能針對單一元件提升效能，卻讓跨元件策略變得難以實作。例如，若要根據 KV Cache 所在位置進行路由、重用已載入的模型權重，或把相關狀態放在同一節點，往往需要同時修改請求路由器、推理引擎、快取後端與底層資料傳輸邏輯。1

TensorCast 的出發點，是把張量生命週期視為一項獨立的系統能力：應用程式只需描述希望如何處理張量狀態，執行階段則負責在叢集資源之間完成放置、搬移、轉換與實體化。1

TensorCast 的核心設計

1. 把張量設為「一等物件」

在 TensorCast 中，張量具有明確的識別、所有權、位置與生命週期語意。推理引擎可以引用某個模型權重、KV Cache 區塊或中間狀態，而不必在程式邏輯中寫死它目前位於哪個節點、哪張 GPU，或採用何種儲存形式。1

這讓「要使用哪個張量」與「張量目前放在哪裡」得以分開處理，系統也能更容易因應動態負載改變資料位置。

2. 以可組合原語描述管理策略

TensorCast 將張量搬移、轉換、預取、複製與實體化等操作抽象成可組合的生命週期原語。開發者可以透過 API 組合出符合工作負載的策略，而不是每次推出新的最佳化方法，都要修改底層基礎設施。1

這種設計也區分了「政策」與「機制」：政策由開發者透過 TensorCast API 撰寫；分散式執行、資料查找與傳輸則由執行階段處理，無須同步改動底層推理引擎。1

3. 分離控制平面與資料平面

TensorCast 的 Global Store（GS）主要保存叢集與張量的中繼資料，例如 Worker 或節點狀態、張量位置、所有權和排程資訊。真正的張量資料傳輸則由 Workers 執行。1

換句話說，Global Store 負責「協調」，而不是承載所有張量內容。這種控制平面與資料平面的分工，可避免 Global Store 因為直接處理大量資料流而成為傳輸瓶頸。1

4. 針對不同張量狀態採用不同中繼資料策略

對於數量較少、變化相對穩定的物件，例如模型權重，TensorCast 可以集中在 Global Store 中追蹤。至於數量龐大且高度動態的 KV Cache，則採用分片方式管理，由負責該分片的 Worker 維護所有權與一致性，並透過租約（lease）和 fencing token 等機制降低並行操作造成的衝突。1

5. 盡量減少不必要的資料複製

在本機，Worker 可透過 CUDA IPC 分享 GPU 記憶體，也可透過本機 memfd handle 暴露 CPU 記憶體。若資料位於遠端，TensorCast 支援透過 RDMA 直接寫入目的地，讓資料在可行時走 GPU 對 GPU 或本機共享路徑，減少額外拷貝。6

KV Cache 搬移為何變得更簡單？

在傳統推理服務中，若一個多輪對話工作階段因負載不均，需要從一個推理實例搬到另一個實例，通常必須協調修改請求路由器、推理引擎內部的 KV Cache 實作，以及快取或網路後端。

在 TensorCast 架構下，管理策略可以直接識別該工作階段對應的 KV 張量物件，要求系統在目的地 Worker 完成放置或實體化，再將後續請求導向該 Worker。查找張量、傳輸資料和綁定記憶體等工作，則由生命週期執行階段負責。1

這並不代表 KV Cache 搬移不需要成本，而是搬移政策只需在張量生命週期層實作一次，不必分別嵌入多個彼此緊密耦合的元件。如此一來，根據快取位置路由、重用模型權重，或將相關狀態配置在同一處等跨元件策略，就更容易進行原型設計與部署。1

實驗結果透露了什麼？

研究團隊將 TensorCast 整合至 vLLM 與 SGLang，並測試模型權重實體化、權重同步、KV Cache 管理及可程式化請求路由等情境。1

論文報告的重點包括：

• 在 KV Cache 效能方面，TensorCast 的表現可與專用 KV Cache 系統 Mooncake 相比，同時保留跨多個系統元件撰寫管理策略的彈性。1
• 啟動 Qwen3-235B-A22B 模型實例時，TensorCast 最高比常見分散式檔案系統快 228.6 倍。該模型總參數量為 2,350 億，啟動時啟用 220 億個參數。12
• 在高並發、多輪 Agent 工作負載中，研究團隊報告稱，可程式化的 TensorCast 策略最高將中央値首字延遲（time-to-first-token，TTFT）降低 93.2%。1

這些結果顯示，TensorCast 可能為彈性、具狀態的 AI 基礎設施提供一種不同的設計方向：模型快速啟動、根據快取位置進行路由與搬移，以及跨服務重用張量狀態，都可以被視為可程式化的系統政策，而不必各自成為某個框架的專用最佳化功能。

不過，上述數字是研究預印本所報告的實驗結果，仍需要獨立重現與大規模生產環境驗證。TensorCast 的真正意義，現階段更接近一個可能重整 AI 推理軟體堆疊的架構提案，而不是已經全面取代現有方案的成熟標準。1