模型越来越强之后，Infra 将被 AI 接管？

模型的架构正在以超出工具链进化速度的方式膨胀，与此同时，国产算力的崛起让异构管理从可选项变成了必答题。那么，推理工程核心挑战如何破局？AI Infra 下一阶段技术演进方向在哪里？近日，InfoQ《极客有约》X AICon 直播栏目特别邀请华为 AI 开源生态总监黄之鹏担任主持人，和 Inferact vLLM committer 莫梓峰、范式智能（第四范式）系统研发专家杨守仁一起，在 AICon全球人工智能开发与应用大会2026 深圳站 即将召开之际，共同探讨 AI 基础设施从“可用”走向“高效可规模化”的关键路径。部分精彩观点如下：龙虾、Hermes 等 agent 开源项目，本质上就是把 CPU 的时钟借过来，让 Agent 有一个时间概念，但大模型本身还是没有时间概念。软件工程屎山这个事情是所有人逃不开的，但现在可能确实有可能会逆转，软件不用越做越麻烦，模型的能力在越来越强。代码现在没有那么值钱了，可能我们做的事情就是站在一个更高阶的 SRE 的角度：定义好 SLA、SLO、成本预算，剩下交给模型，那个时候做 Infra 可能会轻松一点。在 8 月 21-22 日将于深圳举办的 AICon全球人工智能开发与应用大会2026 深圳站上，我们特别设置了【AI Infra、推理工程与异构计算】专题。该专题将聚焦大模型推理架构、异构算力协同、推理性能优化、模型服务化、AI 集群调度、AI 原生基础设施以及下一代 AI 数据中心等方向的关键技术演进与产业实践查看大会日程解锁更多精彩内容：https://aicon.infoq.cn/2026/shenzhen/track以下内容基于直播速记整理，经 InfoQ 删减。完整直播回放可查看：https://www.infoq.cn/video/bN06GZ6lWP9tc5qVPOkyAI Infra 的挑战黄之鹏：做 Infra 的同学都知道圈内有个笑话——“算法爷”，反正苦一苦 Infra，什么算法都能出来。各位认为，做 AI Infra 的挑战有哪些？莫梓峰：现在 AI Infra 最大的挑战是模型架构越来越复杂、越来越多样化了。以前做 LLaMA 无非就是一个 dense model，transformer 加 MLP 就搞定了。后来 DeepSeek 出了 MoE，V1、V2 做 MoE，V3 开始又搞了个 index。到了 V4，我们花了快大半年去适配，因为它那个架构搞得特别复杂，尤其是 transformer 里 compress 那部分，光是 kernel 就写了几个月。至少 transformer 跟 MoE 这块是越来越复杂了。而且我主要还是做多模态的。多模态的趋势也是越来越倾向全模态。两年前我刚开始做多模态的时候，LLaVA 只有图片输入，到后面千问三模态就能接收音频、视频、图片三种输入了。到了今年，Cosmos V 出来了，直接变成全模态——什么模态进来我都能收，还能输出所有模态，图片、视频，甚至机器人机械臂的 action 都能输出。这种全模态模型不仅是 AR 模型了，已经变成 AR 加 DiT，甚至还有各种奇奇怪怪的模型进来辅助。挑战越来越大。我们当时就说，这些有多模态输出的模型都别放在 VLM 这个仓里了，干脆开个新仓，所以就有了 VLM Omni。现在不只是架构复杂，整个模型的流水线都开始复杂化了。杨守仁：我没有涉及推理那么细节的层面，但多模态的工作负载类型非常多样，不单单是 AR 这一种，我更关注的是工作负载跟算力的调度。现在业界比较大的挑战是，随着国内国产算力规模和行业的发展，核心痛点就是异构算力的管理。可能大家比较关注的是 NVIDIA GPU 和昇腾 NPU，但我们范式这边的客户还有寒武纪、昆仑芯、天数、沐曦等各种卡，每家都不太一样。举个非常简单的例子：有一家国产厂的 GPU，在某个 shape 下把一个 tensor 丢过去，输出就是错的。只有那个 shape 有问题，我们最后是通过 offload 到 CPU 的方式绕过去了。所以在异构上我们遇到的第一个大挑战就是一致性——NVIDIA 上有标准的 kernel，国产卡上的 kernel 能不能保证大部分情况下一致？另外随着集群规模变大，客户不只会有 NVIDIA 的卡，至少还要有两家，比如昇腾加 NV 再加一个其他的。业务类型上，以前是把传统的东西往国产卡上迁，最近两年开始把小模型也往国产卡上迁，这里面的适配和管理都是难点。整个集群的效率上，怎么把这些异构的都弄起来，是我们现在面临比较大的挑战。多模态推理攻坚战黄之鹏：梓峰，最近 VLM 刚发了一篇关于千问 Omni 适配的博客，看起来花了很多心思，尤其是对异步处理和多模态输入这块。能不能先就着这篇博客讲一下这个工作？莫梓峰：千问 3 有三个部分：AR 部分、把 AR 的文字输出转成 hidden states 的部分、再把 hidden states 转到 codec wave 里输出音频的部分。AR 需要 KV cache，但其他部分需求完全不一样，每个部分有不同的最优方案。当时我们把每种方案都配了一遍，因为不可能 AR 在跑的时候剩下两个闲着，或者剩下两个在跑的时候 AR 就不接收输入了。所以我们设计 VLM Omni 这个框架的时候，假设每一部分都要充分解耦，不能当作一个简单的流水线。既能在 codec wave 输出的同时做异步调度。第一版框架重构了好几次，最后做到了一定的优化。但目前还有大概 20% 的空间没打满，profile 的时候还有一些 gap，主要是传 P2P 的时候有通信 bubble，有些通信部分还没消化得很好。黄之鹏：VLM Omni 这种方式已经走出了一条比较成熟的路吗？莫梓峰：现在这种“主打 AR，其余剥离出来”的设计其实挺好的。Cosmos-3 出来的时候我们就发现，因为我们把 diffusion 跟 Omni 放在一起了，接入 diffusion 模型就做得非常顺畅。假设 diffusion 一个仓、Omni 一个仓、action 和 VLA 又一个仓，面对 Cosmos V 这种全模态模型，我们要四处开战，战线会拉得很长，还有各种适配问题。我们选择把其他的剥离出来、只保留 VLLM 做 AR，已经有一些技术债了。每次 VLLM 更新版本，Omni 这边也要跟着刷新各种接口，每一次可能要改几千行代码。我们后来接了一些 agent 来做这种比较机械化的任务，拿 agent 刷一遍就完事，但确实也很费 token。黄之鹏：现在各种机型实在太多，好多开发者都是调 agent 提 PR，给社区 reviewer 带来的负担很大。你觉得 agent 带来的影响是利大于弊还是弊大于利？莫梓峰：利大于弊。当时我们搭框架的时候用了不少 agent 来起草雏形，如果纯靠人手写，迭代速度会非常慢。但整个开源社区治理上，agent 带来的最大问题是很多人提 PR，agent 写完以后他不看。description 也是 agent 写的，打开一看几十行几百行，看完就没耐心了。再一看代码，agent 也没写干净，debug 完剩下的东西就留在那里。黄之鹏：那你们一般怎么处理？现在头部开源社区的 PR 提交量都是指数级在涨。莫梓峰：留个通信邮箱，如果你是活人，就用工作邮箱或者学校邮箱发个邮件，证明你是活人，我们就优先看活人的。我自己的实践是，先提几个初始评论，有的秒回、有的隔几分钟回，一眼是机器人的，要么直接 close，要么如果内容有道理而且没什么问题，我就顺手帮他修了。黄之鹏：你们战斗力还是比较强，有些社区已经不堪其烦了。莫梓峰：确实有点。之前我看到有个机器人十分钟直接刷了四十多条，看都不看直接 close。黄之鹏：你怎么看 encoder free 架构对多模态推理的影响？莫梓峰：我们三年前就有一个 encoder free 的模型了，Fuyu-8B，那是最早的。这种模型对 AR 调度其实比较友好，因为没有 encoder 那一块了，不用调度 encoder，直接一个 MLP 一个线性层投过去就完事了，没什么 overhead。真正问题比较大的是像 Gemma-4 那种，有个奇奇怪怪的 attention mask。encoder free 本身问题应该不会很大。黄之鹏：会不会造成 KV cache 成倍增加？在 cache 管理上会带来挑战吗？莫梓峰：至少我之前跑的时候，KV cache 跟普通的 LLaVA 架构没太大区别。但如果像 Gemma-4 那样对图片部分做双向注意力，KV cache 就会变得非常麻烦。尤其是它每一层有些层的 hidden size 特别大、head size 特别大，中间又夹杂几个不同的 head size，那真是 KV cache 管理灾难。如果只是 encoder free 的话问题不大，主要还是看 attention 怎么实现的。异构计算为什么又重要了？黄之鹏：现在的 K8s 异构现状是什么样的？能给大家介绍一下 HAMi 这个项目吗？杨守仁：做异构如果还是老版本 K8s，基本就是 Device Plugin 那套。DRA 我是从进入到 beta 之后才关注的，之前 API 太复杂，开发门槛太高。我们也考虑过 CRD，但每家都得自己维护，成本扛不住。HAMi 最早从 GPU 虚拟化切入，专注于显存和算力共享，通过 scheduler 扩展让用户用多个 resource name 描述一块 GPU 的资源配置。社区实现了一个跟 device plugin 通信的独立协议，最早是支持 NVIDIA 的设备，后来开始