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

阅读完需：约19分钟

AI生产化正迫使模型、编排与基础设施三者深度耦合，传统云原生分层架构面临重构。CNCF、OpenInfra与PyTorch社区首次在KubeCon等联合大会上协同应对AI系统接口、协同与边界问题。行业共识是：现有基础设施能力尚未满足真实AI生产负载需求。

AI推理负载异构性倒逼基础设施重新设计

模型、调度、硬件三类开源社区开始共治同一生产系统接口

AI进入生产后，原有云原生抽象层暴露能力缺口

适合AI基础设施工程师、云原生平台架构师、MLOps工程师阅读

过去几年，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真正进入生产环境，模型只是系统的开始。