推理成为新中心、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 真正进入生产环境之后，原来的基础设施能力还远远不够。 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 运行时需要执行代码