推理成为新中心、Agent 把生产级问题提前：AI Infra 的边界正在被重写

过去几年，AI 行业最受关注的问题往往集中在模型本身：参数还能做多大，训练需要多少 GPU，新模型又刷新了哪些 Benchmark。但当越来越多企业真的开始把 AI 放进生产系统，问题就变了：GPU 不再只有一种，模型训练和推理之间的边界越来越模糊，推理系统需要同时处理 KV Cache、Prefill、Decode 等不同负载，Agent 又开始主动产生大量并行、难以预测的请求。过去十多年，云计算和云原生社区一直在努力把基础设施做得更标准、更统一，AI 却重新把大量差异带回了系统。

这也是今年 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 最明显的一个变化：CNCF、OpenInfra 与 PyTorch 三个过去分处不同技术层的开源社区，第一次在同一场行业大会中同台。 这不只是一次活动层面的合并，而更接近企业实际部署 AI 时使用开源技术的方式：模型、编排和底层基础设施，本来就很难彼此独立。几个社区也因此开始更直接地处理同一套生产系统里的接口、协同和边界问题。

在 Keynote 结束后的媒体发布会上，OpenInfra 基金会总经理 Thierry Carrez（阚雷）、CNCF 执行总监 &Linux 基金会云与基础设施执行总监 Jonathan Bryce（傅兰石）、PyTorch 基金会执行总监 Mark Collier（柯理怀），以及 CNCF 首席技术官 &Linux 基金会云与基础设施 CTO Chris Aniszczyk，与 InfoQ 等媒体展开了进一步交流。他们都在反复强调同一件事：AI 真正进入生产环境之后，原来的基础设施能力还远远不够。

Thierry Carrez 直接表示：“无基础设施，不 AI。”（原话：There is no AI without infrastructure.） 模型、推理服务、Agent，最后都要落到计算、加速器、网络和存储上运行。但 AI 带来的基础设施要求，和传统云工作负载已经明显不同。一方面，GPU 和各种加速器越来越多样，企业需要把异构资源组织成统一资源池；另一方面，GPU 本身价格高昂，利用率不能像普通服务器一样“够用就行”，而是需要尽可能压榨到接近满负载。与此同时，Agent 的出现又把隔离和控制问题推到了更前面。

Jonathan Bryce 提到，云计算过去十几二十年的一个核心方向，是尽量把环境标准化，再通过 API 动态访问资源，但 AI 正在重新把异构性带回基础设施。为了充分释放 AI 系统的性能，企业会使用定制硬件、定制 Kernel；从芯片一直到 Agent，各层之间的联系也变得更紧密，没有一个单独的开源项目能够覆盖从芯片到 Agent 的整条技术链路。这种变化甚至已经深入到单个 AI 请求内部。一个 AI 负载可能需要把不同任务交给不同类型的硬件：KV Cache 可以放在内存，也可能卸载到高速存储；Prefill 和 Decode 阶段的资源特征也不同。基础设施面对的已经不只是“把一个 Pod 调度到一块 GPU 上”，而是要理解请求内部不同阶段的资源需求，再决定这些任务该落在哪种计算、存储和网络资源上。

第二个变化来自 Agent。传统互联网服务的大量请求由人触发：点击、输入、提交表单，行为模式相对可预测；Agent 则可以自己拆任务、调用工具、并行发起请求，工作负载的形态完全不同。Jonathan 认为，Agent 正在产生并行度更高、资源需求呈指数级增长的工作负载。这会直接影响过去围绕人类访问模式设计的路由、缓存、容量规划乃至安全策略。

Jonathan 还援引了一个他近期看到的 Wikipedia 案例：Agent 带来的页面访问约占 35%，但资源密集型使用超过 60%。其中一个原因就是 Agent 不会像人类一样遵循相对可预测的访问路径，过去围绕固定路径设计的路由和缓存策略因此更容易失效。

AI 给基础设施带来的变化，已经远远超过“服务器里多装几块 GPU”。

推理并不是云原生社区刚刚开始接触的 AI 工作负载。Jonathan 提到，大规模模型训练其实早已大量运行在 Kubernetes 等云原生基础设施上；现在推理之所以被单独推到前台，是因为它正在成为增长最快的 AI 工作负载，同时也需要大量过去没有被充分解决的专项工程能力。

过去，训练和推理通常是两段相对独立的流程。模型团队先花几个月训练模型，完成后再交给平台工程团队做部署、扩容和推理服务，这套流程的周期现在正在明显缩短。Mark Collier 表示，硬件架构、模型架构和推理软件几乎每天都在变化，如果硬件不断多样化，软件又针对每一种芯片分别演化，很快就会陷入碎片化。PyTorch Foundation 更希望看到的是一个共享的软件层：上层保持统一接口，底层能够适配不同的加速器和后端实现。

他们给出的长期目标很直接：任何模型都能在任何芯片、任何云上训练和服务，并连接到任何 Agent。

为此，PyTorch 需要设计能够适配不同后端实现的接口，也要让不同加速器厂商直接参与上游代码贡献。Mark 还提到，PyTorch 已经建立了大规模的持续集成（CI）测试体系，长期目标是让每一次代码提交，都能在不同加速器上完成验证。

推理的重要性也在快速上升。过去一年，vLLM 的贡献者数量增长了超过 180%。Mark 观察到，训练和推理正在被更紧密地连在一起，模型迭代周期也从几个月甚至一年，压缩到以天计算。Mark 在上午的 Keynote 分享中提到了一个具体案例：MiniMax 的开放模型发布后，48 小时内就出现了 ComfyUI 集成；与此同时，AMD 也针对 MiniMax 的一款开放模型，结合 vLLM 在新的硬件架构上进行优化，不到 19 天将性能提升了 11 倍。这说明，在算力资源越来越紧张的情况下，性能提升并不只来自新一代芯片，软件栈本身仍然有很大的优化空间。

Mark 将这类问题概括为 协同问题（coordination problem）：芯片在变，模型架构在变，推理引擎也在变，关键在于这些层之间能否更快完成信息传递和适配。 这也意味着，基础设施的角色正在发生变化。过去它更多负责把已经确定的应用稳定运行起来；现在，它开始更深地参与到模型迭代、性能优化以及训练和推理之间的反馈循环中。

如果说异构算力和大规模推理主要带来的是性能和效率问题，Agent 则把一批过去更偏应用层的问题，提前推到了基础设施层。原因在于，Agent 和传统服务的运行方式本身就不一样。传统服务大多接收一个请求，再返回一个相对可预测的结果，基础设施更关心服务是否可用、错误率是否可接受；Agent 接收到的却往往是一个目标，它会自己拆解任务、调用模型和工具、访问外部系统，甚至决定下一步该做什么。到了这个阶段，基础设施要回答的问题也从“服务有没有正常运行”，进一步变成“这个 Agent 的行为是不是正确的”。

这种变化一旦放大到生产规模，问题会更明显。Agent 运行时需要执行代码、与外部工具和系统交互、维护状态，并且可能在共享基础设施上同时产生数以百万计的任务。过去很多围绕微服务建立起来的调度、安全和资源控制机制，面对的都是相对明确、可预期的工作负载；Agent 的执行路径却会随着任务动态变化，这也让安全、调度和资源控制同时变得更复杂。

隔离因此被推到了一个更核心的位置。Thierry Carrez 特别提到，Agent 工作负载需要更严格的隔离和约束，企业必须避免 Agent 逃出预定边界，去执行原本没有授权它做的事情。蚂蚁集团就是一个例子，它使用 Kata Containers 的轻量级虚拟机能力为 Agent 工作负载提供更底层的隔离。Thierry 还提到，隔离能力影响的不只是安全本身，也关系到企业愿不愿意把更多内部数据开放给 AI：如果企业无法确认数据和执行过程始终处于自己的控制范围内，就很难真正把核心数据和业务系统交给 Agent。

这也让 Agent Sandbox 开始变成一个越来越独立的基础设施问题。Kata Containers 社区在过去一年里已经看到大量团队在构建 Agent Sandbox 或类似服务，并围绕启动速度、隔离能力和资源开销做性能比较。Kata Containers 4.0 也把此前在阿里、蚂蚁等企业内部使用的一套 Rust VMM 架构进一步推向上游。原本主要服务于云原生隔离的技术，正在因为 Agent 的出现获得一批新的使用场景。

但 Agent 带来的问题还不只发生在“运行时”。上午 Keynote 中一场关于 Agent Infra 的分享还提到了另一个问题：Agent 的执行进程可能很短，但它在执行过程中获得过的权限、修改过的状态、对其他系统产生的影响，可能长期保留下来。这种工作负载被概括为“短生命周期进程，长期存在后果”。 和传统云原生应用相比，基础设施不能只管理一个进程什么时候启动、什么时候退出，还要持续追踪它在整个执行过程中“做过什么”。

因此，Agent Infra 需要处理的不只是模型调用和沙箱。其关键能力可以概括为：每一次 Agent 行动都要能够追溯到明确的授权主体，访问需要由策略控制，系统不仅要观察延迟和错误，还要能追踪 Agent 的决策过程、工具调用和执行结果，最后还要把这些结果持续送回评估循环。对于传统服务来说，可观测性更多是在判断“系统有没有正常运行”；到了 Agent，基础设施还需要进一步回答“它为什么这样做，以及这样做是不是符合预期”。

围绕这些问题，Agent Infra 的底层生态正在快速生长。Keynote 上展示的一份生态观察中，用户注意力目前仍然更多集中在 Coding Agent、个人助手等上层应用，但真正快速增长的区域之一已经转向 Runtime、沙箱执行、可观测性和评估等基础设施层。相比更成熟的 Model Infra，Agent Infra 明显更年轻，很多项目都是最近一两年才出现。

但这并不意味着企业需要为 Agent 重新造一套完全独立的基础设施。很多云原生时代已经验证过的方法仍然可以复用，但 Agent 需要新的运行边界。对企业来说，接下来的问题也不再只是如何“运行一个 Agent”，而是如何长期管理它的权限、行为、状态和后果，最终能够可控地运营一批可以自主行动的 Agent。

AI 的生产技术栈已经越来越难按照传统边界拆开：OpenInfra 负责底层计算、虚拟化、异构硬件和隔离；Kubernetes 处理工作负载编排、资源管理和平台工程；PyTorch、vLLM 等项目直接进入训练和推理。如果底层硬件变化不能被上层软件及时适配，或者推理系统的需求无法传递到调度、网络和存储层，再强的单点技术也很难把整套系统效率做上去。

真正进入生产环境后，问题开始跨越原本相对独立的技术边界：底层计算和虚拟化、Kubernetes 的资源编排，以及 PyTorch 的训练和推理，越来越需要放在同一套系统里协同考虑。

这也是为什么，这次三个过去分处不同技术层的社区会走到一起。当被问到这一变化时，Chris Aniszczyk 给出的答案很直接：单独一个项目做不到，单独一个基金会也做不到。

Jonathan 则给了一个更现实的解释：基金会现在走到一起，其实是在追赶企业真实使用开源技术的方式。

“没有人只运行 PyTorch，也没有人只运行 Kubernetes。”他说。真实企业环境里，本来就是把多个开源项目组合起来构建系统。过去基金会和社区可以按照各自技术边界发展，但用户真正部署时，这些边界从来没有那么清晰。这次把几个社区放到一起，反而更接近企业实际搭建基础设施和采用开源软件的方式。

Jonathan 认为，更关键的变化在于 AI 基础设施所处的阶段已经变了。技术早期，一个项目保持高度聚焦、快速迭代并没有问题；但当它开始被大规模采用，就必须面对真实生产环境里的各种复杂性，也必须和其他项目共同工作。

这种跨层协作已经出现在真实企业和项目里。Jonathan 提到了招商银行的案例，他们并不是只运行某一个模型或者某一个框架，而是把多个云原生开源项目组合起来，同时训练自己的模型，也使用其他开放模型构建企业内部 AI 技术栈。CNCF 中的 llm-d 则是另一个更直接的例子。vLLM 负责模型推理服务，llm-d 则把 vLLM 放进更大规模的云原生环境里运行、编排和扩展。一个偏模型服务，一个偏基础设施运营，两个项目恰好位于不同社区之间的交界处。

Jonathan 还用当下热门的 AI Factory 做了一个更具体的说明：底层需要 OpenStack 一类基础设施管理 GPU 等硬件资源，上层由 Kubernetes 承接工作负载和资源调度，再往上才是 PyTorch、vLLM 等模型和推理软件。所谓 AI Factory，本身就不是某一个项目能解决的问题，而是一整套技术栈共同工作的结果。

那么，这次三个社区坐到一起，会不会只是一次大会层面的合作？Jonathan 的回答也很明确：未来的协作不会只有一种形式，而是会同时发生在 社区互通、标准对接和项目共建 几个层面。

在标准和协议层面，他提到 MCP、A2A 等跨社区协作；在项目层面，vLLM 和 llm-d 已经体现了不同基金会之间的技术衔接；在社区层面，不同基金会也需要让原本相对分开的开发者、企业和维护者更频繁地交流。Chris 也表示，这次联合活动的效果不错，未来应该会看到更多类似合作。

不过目前并没有一个新的统一组织、联合标准或者固定合作机制。更准确地说，三个社区正在从“各自发展、生产环境里再被用户拼起来”，逐渐走向更早地讨论彼此之间的接口和协同。

随着 AI 逐步进入生产环境，很多原本高度定制的系统，也开始被纳入更标准的平台和运维体系。Jonathan 表示，过去负责通用计算和应用系统的平台工程团队，现在开始越来越多地接手 AI——既包括企业自己的模型训练，也包括开放权重模型的部署和运行。

过去一年他接触过的一些企业里，AI 团队往往资源充足、推进很快，但真正进入生产环境后，很快就会碰到 可用性、可靠性、扩展性和安全 等问题。AI 团队擅长模型和算法，却未必擅长运营大型生产系统，因此一些企业已经开始让 AI 团队与平台、运维团队更紧密地协作。

在 Jonathan 看来，一项工作负载刚出现时可以很新、很兴奋，但企业最终要依赖它，前提是它必须变得“稳定而无聊”。

这也是 AI 基础设施现在正在经历的变化。过去几年，行业更关心“这个模型能不能跑起来”；接下来要解决的是一批没那么性感、却直接决定企业敢不敢长期依赖它的问题：利用率、延迟、成本、扩展、安全、隔离、可观测性、可靠性。

模型仍然在高速变化，硬件也远没有收敛，Agent 更处在很早期的阶段，但企业不会因为工作负载足够新，就降低对生产系统的要求。AI 最终还是要像数据库、微服务和其他关键系统一样，稳定运行、持续扩展、出了问题能定位，也能控制成本。

AI 的竞争正在从单个模型能力继续往系统层扩散。真正进入生产之后，企业关心的不再只是模型有多强，而是整套系统能不能稳定运行、持续扩展、控制成本，并且足够可靠。

当 AI 还只是 Demo 时，模型几乎决定一切；当 AI 真正进入生产环境，模型只是系统的开始。