TensorCast係咩？一層將大模型張量管理重新整合的可編程基礎設施

TensorCast可以理解為一層建基於「Tensor-as-a-Service」（TaaS）概念的張量管理系統。它是一個分佈式、可編程的基礎設施層，專門處理張量狀態的身份、位置、搬移、轉換、共享和實體化，而不再將這些工作綁死在產生或使用張量的計算引擎內。1

簡單講，模型權重、KV Cache，以及推理過程產生的中間狀態，都可以被視為具備明確身份和生命週期的「張量物件」。應用程式只需要描述希望這些狀態如何使用，TensorCast的runtime就會在集群內決定如何尋找、放置、搬運及載入相關數據。1

點解需要TensorCast？

現時的大模型服務不只要處理模型權重。多輪對話會產生不斷變化的KV Cache，而推理和其他工作流程亦會產生各類中間張量狀態。傳統做法通常將這些工作分散到不同組件：

• 推理引擎管理模型及KV Cache；
• 請求調度器決定流量去邊個實例；
• 網絡層負責跨節點傳送數據；
• 儲存系統負責保存及載入模型權重或其他狀態。

問題在於，各組件往往各自重新實作張量的定位、搬移、複製和載入邏輯。當開發者想同時考慮KV Cache locality、模型權重重用、請求路由和跨節點遷移時，就要改動多個互相耦合的系統，開發和維護成本都會增加。1

TensorCast提出的方向，是將「張量生命週期管理」視為大模型基礎設施中缺少的一層。它有別於一般將數據視為不透明檔案或blob的object store，也有別於主要負責安排計算任務的compute-centric framework；TensorCast的中心對象，是張量狀態本身的整個生命週期。1

TensorCast的核心設計

1. 張量成為一等公民物件

在TensorCast中，每個張量都有清晰的身份、擁有者、所在位置及生命週期語義。推理引擎可以引用某個模型權重、KV Cache block或中間狀態，而毋須自行記住它目前位於哪一個節點、哪張GPU，或者以甚麼形式儲存。1

2. 將管理操作組合成可編程策略

TensorCast把搬移、轉換、預取、複製及實體化等操作，抽象成可以組合的lifecycle primitives。開發者可以按照工作負載需要編寫管理策略，而不必每次推出新優化時，都直接修改底層網絡、儲存或推理系統。1

這亦代表「策略」和「執行機制」可以分開：開發者透過TensorCast API描述政策，runtime則負責在分佈式環境執行數據定位和搬移，底層推理引擎不一定要作出相應改動。1

3. Global Store與Workers分工

TensorCast把整個架構分成控制平面和數據平面：

• Global Store（GS）：保存集群元數據，例如Worker或節點狀態、張量位置、擁有權及調度資訊；
• Workers：實際執行張量數據的搬移、載入及相關操作。

GS主要負責協調，而不是承載大量張量payload。這樣可以避免所有數據流量都經過GS，減低它變成傳輸瓶頸的風險。1

4. 按張量特性管理metadata

對於數量較少而且相對穩定的物件，例如模型權重，可以由GS集中追蹤。至於數量龐大、變化頻密的KV Cache，則採用分片方式管理，由負責某個shard的Worker維持擁有權和一致性，並透過lease及fencing token處理狀態更新。1

5. 以較少複製完成實體化

在Worker一側，GPU記憶體可以透過CUDA IPC對外提供共享，CPU記憶體則可以透過本機memfd handle使用。當來源位於遠端時，TensorCast亦支援RDMA direct write，直接將數據寫入目的地可用的記憶體範圍。這些方式有助減少中間副本，並在條件許可時使用GPU-to-GPU或本機共享路徑。6

點解KV Cache遷移會容易啲？

以多輪對話為例，一個用戶session可能因為負載不平均，需要連同已有的KV Cache，由一個推理實例搬到另一個實例。

傳統架構通常要同時協調請求router、推理引擎內部的KV Cache實作，以及cache或網絡後端。TensorCast的做法則可以由一個管理策略識別該session對應的KV tensor objects，要求系統在目的地Worker進行放置和實體化，再將之後的請求導向新的實例；查找、傳送和記憶體綁定就由生命週期runtime處理。1

當然，這不代表遷移完全沒有成本。真正的優勢是，遷移政策只需要在張量生命週期這一層表達一次，而毋須在多個互相緊扣的組件中分別重做。這使到按照cache locality進行路由、重用模型權重，或者將相關狀態放在同一位置等跨組件優化，更容易作原型和部署。1

實驗結果反映甚麼？

研究團隊將TensorCast整合到vLLM和SGLang，並測試模型權重實體化、權重同步、KV Cache管理及可編程請求路由等場景。1

論文報告指，TensorCast的KV Cache表現可與專門的KV Cache系統Mooncake競爭，同時保留跨多個組件制定管理策略的彈性。1

在啟動Qwen3-235B-A22B實例的測試中，該模型總共有2,350億個參數，當中有220億個參數會被啟用；論文稱TensorCast的啟動速度最高比常見分佈式檔案系統快228.6倍。12

另外，在高並發、多輪對話的Agent工作負載中，研究團隊報告指，一項可編程TensorCast策略可令median time-to-first-token（TTFT，即收到首個token所需的時間）最高降低93.2%。1

對AI基礎設施有咩意義？

如果相關結果能在更大規模和生產環境中重現，TensorCast的價值不只在於令某一項傳輸更快，而是將模型啟動、KV Cache重用、cache-aware路由及狀態遷移，統一變成可以編寫和組合的系統政策。

對需要彈性擴縮、長對話和多步Agent工作流程的AI服務而言，這種設計有機會減少不同基礎設施組件之間的重複工作，亦令新的跨組件優化更快試驗。不過，上述數字是研究預印本所報告的實驗結果，仍然需要獨立重現，以及在生產規模下作進一步驗證。1