北大联合阶跃星辰提出TensorCast：统一可编程管理大模型张量，推理「首字延迟」最高降低93.2%

过去几年，大模型推理系统优化的核心目标一直围绕一个问题展开：如何让 GPU 更高效地计算权重、激活、KV Cache 等高维张量？从并行策略、请求调度、显存管理到算子优化，学界业界大量优化技术不断提升模型推理效率。 然而，随着模型规模持续增长、上下文长度不断扩展，以及多轮交互 Agent 等新型应用快速兴起，大模型基础设施正在面临一个新的挑战 —— 面对海量跨系统组件流动的「张量状态」，大模型基础设施如何灵活高效地管理它们？ 例如： 大模型服务弹性扩容时，需要将 TB 级模型权重快速分发到新实例； 长上下文、多轮对话场景中，需要存储大量 GB 级 KV Cache，并在推理实例之间快速迁移、复用； 强化学习中，需要将训练节点产生的 TB 级新模型参数快速同步到大量 rollout 推理节点。 这些张量已经不再只是计算过程中的临时数据，而逐渐成为大模型系统中的核心状态。围绕每个需求，学界业界已经有了定制化的优化方案。然而，一个新的问题正在出现： 不同系统都在重复解决类似的张量管理问题，却缺少一个统一的基础抽象。 针对这一缺失的基础能力， 北京大学、阶跃星辰与北京邮电大学联合提出 TensorCast， 在计算引擎、网络与存储之间引入一个 统一、可编程的张量生命周期管理抽象层，将模型权重、KV Cache 等张量状态从具体系统中解耦出来，使不同工作负载能够复用并组合统一的张量管理能力。 TensorCast 在达到专用系统性能的同时，可灵活实现新的跨系统组件张量管理策略， 针对高并发多轮对话 Agent 场景 TTFT 最高可降低 93.2%。 论文标题：TensorCast: The Missing Tensor Management Layer in Large Language Model Infrastructure 论文地址：https://arxiv.org/pdf/2608.06007 代码地址：https://github.com/tensorcast-ai/tensorcast 项目主页：https://tensorcast.ai/ 今天的大模型基建，正在重复「造轮子」 当前的大模型基础设施中，不同任务通常配备有独立的优化系统：模型加载系统负责权重分发、KV Cache 系统负责 KV 存储和迁移、Checkpoint 系统负责模型状态保存和恢复。这些系统都取得了显著性能提升，但它们往往深度绑定具体推理 / 训练框架、网络环境和存储后端。从本质上看，这些任务实际上都涉及一组高度相似的操作： 识别（Identify）： 确定张量身份和元信息； 放置（Place）： 决定张量应该存储在哪里； 移动（Move）： 在节点之间传输张量； 转换（Transform）： 改变张量布局或并行形式； 物化（Materialize）： 将逻辑状态加载为计算可用的数据。 然而，如图 1 所示，目前这些能力通常被封装在各自独立的系统内部，形成彼此隔离的「纵向技术栈」。这种架构带来了两个核心问题： 第一，系统开发成本不断增加。 当新的优化策略出现时，开发者往往需要同时修改调度器、缓存系统、执行引擎等多个组件。例如，一个同时考虑负载均衡和 KV Cache 亲和性的推理策略，需要协调请求路由、缓存迁移和实例管理逻辑，系统开发牵一发而动全身。 第二，复杂的大模型应用越来越需要跨组件协同优化。 例如，在 Agent 多轮推理过程中，系统可能需要同时考虑：哪个实例承担请求，KV Cache 应该放在哪里，是否迁移已有上下文状态。 而传统的孤立系统难以表达这样的跨任务组合优化策略。 因此，大模型基础设施需要一个新的抽象层，用于统一管理张量状态的完整生命周期。 图片 1 当前大模型基础设施针对不同张量任务实现彼此独立的优化技术栈，开发成本增加的同时，难以表达跨任务的组合优化策略。 TensorcCast：可编程的张量管理系统 针对这一问题，北京大学团队联合阶跃星辰公司，提出 Tensor-as-a-Service（TaaS）这一新的系统抽象和对应的系统 TensorCast： 将张量生命周期管理从计算执行逻辑中解耦出来，让开发者能够像管理系统资源一样管理模型权重、KV Cache 等张量状态（如图 2）。 图片 2 Tensor-as-a-Service (TaaS) 框架：TensorCast 统一管理张量生命周期和分布式存储、传输，上层计算逻辑通过调用原语编程张量管理策略 TensorCast 主要包含两个核心理念： 1. 张量成为一等系统对象 在 TensorCast 中，张量拥有独立的系统身份和生命周期。 系统能够统一管理不同类型的张量状态，包括模型权重、KV Cache 和其他中间状态。开发者无需关心一个张量具体位于哪个节点、哪块 GPU 或哪种存储介质，TensorCast 会负责完成后续的数据定位、移动和物化。一个模型权重可以被注册到 TensorCast 中，随后新的推理实例能够直接获取对应状态，而无需重新从底层存储加载整个模型。 图片 3 TensorCast 提供一系列张量管理原语作为 API，供开发者实现张量管理策略 2. 张量生命周期变得可编程 TensorCast 将常见的张量管理操作抽象成可组合的生命周期原语（如图 3），开发者可以通过普通程序组合这些操作，实现面向具体业务需求的优化策略。以一个 KV Cache 迁移场景为例：在多轮对话 LLM 服务中，一个用户会话可能因为负载不均需要从一个推理实例连带 KV Cache 迁移到另一个实例，这在传统系统通常需要同时修改：请求调度器、KV Cache 后端和推理引擎内部逻辑。 在 TensorCast 中，这一过程可以通过一个简单的生命周期程序完成 KV 导出、迁移和恢复（图 4）。 图片 4 使用 TensorCast API 实现推理引擎实例间 KV Cache 迁移 统一的张量管理底座 为了支撑大规模 LLM 集群中的张量管理，TensorCast 设计了一套分布式运行架构，将控制逻辑与数据传输分离（图 5）。 在控制面，TensorCast 通过一个 Global Store（GS）维护整个集群的元信息，包括节点状态、张量位置以及任务调度所需的信息。GS 负责协调集群状态，但不参与实际的数据传输，避免成为性能瓶颈。 在数据面，TensorCast 部署多个 Worker 节点管理本地存储、内存和 GPU 资源，并负责执行具体的张量生命周期操作，例如张量迁移、复制、转换和加载。 不同 Worker 之间通过 RDMA、零拷贝、流水线传输等技术实现高性能 P2P 数据传输 ，使系统能够随着集群规模增长持续扩展。 在实际部署中，TensorCast 可以作为独立层接入现有的大模型推理系统。上层应用通过 TensorCast API 定义张量管理策略，下层 Worker 负责在整个集群中高效执行这些操作，从而为模型权重、KV Cache 等不同类型的张量状态提供统一管理能力。 图片 5 TensorCast 分布式框架。数据面之间数据 P2P 传输，避免控制面瓶颈。 实验验证：TensorCast 同时兼顾性能与可编程性 为了验证