KubeCon China 2026：CNCF、OpenInfra 与 PyTorch 首次同台，AI Infra 边界被重写

今年 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 最明显的变化，是 CNCF、OpenInfra 与 PyTorch 三个过去分处不同技术层的开源社区第一次在同一场行业大会中同台。在 Keynote 结束后的媒体发布会上，OpenInfra 基金会总经理 Thierry Carrez、CNCF 执行总监 Jonathan Bryce、PyTorch 基金会执行总监 Mark Collier 以及 CNCF 首席技术官 Chris Aniszczyk 反复强调同一件事：AI 真正进入生产环境之后，原来的基础设施能力还远远不够。

这更像是对企业实际部署方式的追赶。Jonathan Bryce 说，没有人只运行 PyTorch，也没有人只运行 Kubernetes；真实企业环境本来就是把多个开源项目组合起来构建系统。Chris Aniszczyk 的表述更直接：单独一个项目做不到，单独一个基金会也做不到。

需要区分的是，这目前并不是一个新的统一组织、联合标准或固定合作机制。按 Jonathan 的说法，未来协作会同时发生在社区互通、标准对接和项目共建几个层面，例如 MCP、A2A 等跨社区协作，以及 vLLM 与 llm-d 这类位于不同社区交界处的项目衔接。三个社区正从“各自发展、生产环境里再被用户拼起来”，逐渐走向更早讨论彼此的接口与协同。

Thierry Carrez 的判断是“无基础设施，不 AI”。模型、推理服务、Agent 最终都要落到计算、加速器、网络和存储上运行，但 AI 带来的要求与传统云工作负载明显不同：GPU 和各种加速器越来越多样，企业需要把异构资源组织成统一资源池；GPU 价格高昂，利用率不能“够用就行”，而要尽可能压榨到接近满负载。

Jonathan Bryce 提到，云计算过去十几二十年的核心方向是尽量把环境标准化，再通过 API 动态访问资源，但 AI 正在重新把异构性带回基础设施。为了释放性能，企业会使用定制硬件、定制 Kernel，从芯片一直到 Agent 各层联系更紧密，没有一个单独的开源项目能覆盖整条技术链路。

这种变化已经深入到单个 AI 请求内部。一个负载可能需要把不同任务交给不同类型硬件：KV Cache 可以放在内存，也可能卸载到高速存储；Prefill 和 Decode 阶段的资源特征也不同。基础设施面对的不再只是“把一个 Pod 调度到一块 GPU 上”，而是要理解请求内部不同阶段的资源需求，再决定任务落在哪种计算、存储和网络资源上。

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

训练与推理的边界正在模糊。Mark Collier 表示，硬件架构、模型架构和推理软件几乎每天都在变化，如果软件针对每种芯片分别演化，很快就会碎片化。PyTorch 基金会希望看到一个共享软件层：上层保持统一接口，底层适配不同加速器和后端，长期目标是任何模型都能在任何芯片、任何云上训练和服务，并连接到任何 Agent。

Mark 给出的两个数字说明了软件栈的优化空间：过去一年 vLLM 的贡献者数量增长超过 180%；MiniMax 的开放模型发布后 48 小时内出现 ComfyUI 集成，AMD 结合 vLLM 在新硬件架构上不到 19 天将性能提升 11 倍。他把这类问题概括为协同问题——芯片、模型架构、推理引擎都在变，关键在于这些层之间能否更快完成信息传递和适配。

Agent 与传统服务的运行方式不同：传统服务接收请求、返回相对可预测的结果，基础设施更关心可用性和错误率；Agent 接收的是一个目标，会自己拆解任务、调用模型和工具、访问外部系统。Jonathan Bryce 认为，Agent 正在产生并行度更高、资源需求呈指数级增长的工作负载，这会直接影响围绕人类访问模式设计的路由、缓存、容量规划乃至安全策略。他援引的一个 Wikipedia 案例称，Agent 带来的页面访问约占 35%，但资源密集型使用超过 60%。

隔离因此被推到更核心的位置。Thierry Carrez 提到，Agent 工作负载需要更严格的隔离和约束，企业必须避免 Agent 逃出预定边界去执行未授权操作；蚂蚁集团使用 Kata Containers 的轻量级虚拟机能力为 Agent 工作负载提供更底层隔离。隔离能力也影响企业是否愿意把更多内部数据开放给 AI。Kata Containers 社区过去一年看到大量团队在构建 Agent Sandbox 或类似服务，Kata Containers 4.0 也把此前在阿里、蚂蚁等企业内部使用的 Rust VMM 架构进一步推向上游。

Agent 的问题还不只发生在运行时。Keynote 中一场关于 Agent Infra 的分享提到，Agent 的执行进程可能很短，但过程中获得的权限、修改的状态、对其他系统产生的影响可能长期保留，被概括为“短生命周期进程，长期存在后果”。因此基础设施不能只管理进程何时启动、何时退出，还要持续追踪它做过什么：每一次行动可追溯到明确授权主体，访问由策略控制，系统不仅要观察延迟和错误，还要追踪决策过程、工具调用和执行结果，并送回评估循环。Keynote 展示的生态观察称，用户注意力仍集中在 Coding Agent、个人助手等上层应用，但快速增长的区域之一已转向 Runtime、沙箱执行、可观测性和评估等基础设施层。

Jonathan Bryce 表示，过去负责通用计算和应用系统的平台工程团队，现在开始越来越多地接手 AI，既包括企业自己的模型训练，也包括开放权重模型的部署和运行。他接触过的一些企业里，AI 团队资源充足、推进很快，但进入生产环境后很快碰到可用性、可靠性、扩展性和安全问题，因此一些企业开始让 AI 团队与平台、运维团队更紧密协作。

在他看来，一项工作负载刚出现时可以很新、很兴奋，但企业最终要依赖它，前提是它必须变得“稳定而无聊”。这也是 AI 基础设施正在经历的变化：过去几年行业更关心“这个模型能不能跑起来”，接下来要解决的是一批没那么性感却直接决定企业敢不敢长期依赖的问题——利用率、延迟、成本、扩展、安全、隔离、可观测性、可靠性。

模型仍在高速变化，硬件远没有收敛，Agent 更处在很早期阶段，但企业不会因为工作负载足够新就降低对生产系统的要求。AI 的竞争正在从单个模型能力继续往系统层扩散：当 AI 还只是 Demo 时，模型几乎决定一切；当 AI 真正进入生产环境，模型只是系统的开始。