模型的架构正在以超出工具链进化速度的方式膨胀，与此同时，国产算力的崛起让异构管理从可选项变成了必答题。那么，推理工程核心挑战如何破局？AI Infra 下一阶段技术演进方向在哪里？
近日，InfoQ《极客有约》X AICon 直播栏目特别邀请华为 AI 开源生态总监黄之鹏担任主持人，和Inferact vLLM committer 莫梓峰、范式智能（第四范式）系统研发专家杨守仁一起，在 AICon全球人工智能开发与应用大会（https://aicon.infoq.cn/2026/shanghai/track）2026 深圳站 即将召开之际，共同探讨 AI 基础设施从“可用”走向“高效可规模化”的关键路径。
部分精彩观点如下：
- 龙虾、Hermes 等 agent 开源项目，本质上就是把 CPU 的时钟借过来，让 Agent 有一个时间概念，但大模型本身还是没有时间概念。
- 软件工程屎山这个事情是所有人逃不开的，但现在可能确实有可能会逆转，软件不用越做越麻烦，模型的能力在越来越强。
- 代码现在没有那么值钱了，可能我们做的事情就是站在一个更高阶的 SRE 的角度：定义好 SLA、SLO、成本预算，剩下交给模型，那个时候做 Infra 可能会轻松一点。
以下内容基于直播速记整理，经 InfoQ 删减。
AI 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，甚至还有各种奇奇怪怪的模型进来辅助。挑战越来越大。我们当时就说，这些有多模态输出的模型都别放在 vLLM 这个仓里了，干脆开个新仓，所以就有了 vLLM Omni。现在不只是架构复杂，整个模型的流水线都开始复杂化了。
杨守仁：我没有涉及推理那么细节的层面，但多模态的工作负载类型非常多样，不单单是 AR 这一种，我更关注的是工作负载跟算力的调度。现在业界比较大的挑战是，随着国内国产算力规模和行业的发展，核心痛点就是异构算力的管理。可能大家比较关注的是 NVIDIA GPU 和昇腾 NPU，但我们范式这边的客户还有寒武纪、昆仑芯、天数、沐曦等各种卡，每家都不太一样。
举个非常简单的例子：有一家国产厂的 GPU，在某个 shape 下把一个 tensor 丢过去，输出就是错的。只有那个 shape 有问题，我们最后是通过 offload 到 CPU 的方式绕过去了。所以在异构上我们遇到的第一个大挑战就是一致性——NVIDIA 上有标准的 kernel，国产卡上的 kernel 能不能保证大部分情况下一致？另外随着集群规模变大，客户不只会有 NVIDIA 的卡，至少还要有两家，比如昇腾加 NV 再加一个其他的。业务类型上，以前是把传统的东西往国产卡上迁，最近两年开始把小模型也往国产卡上迁，这里面的适配和管理都是难点。整个集群的效率上，怎么把这些异构的都弄起来，是我们现在面临比较大的挑战。
多模态推理攻坚战
黄之鹏：梓峰，最近 vLLM 刚发了一篇关于千问 Omni 适配的博客，看起来花了很多心思，尤其是对异步处理和多模态输入这块。能不能先就着这篇博客讲一下这个工作？
莫梓峰：千问 3 有三个部分：AR 部分、把 AR 的文字输出转成 hidden states 的部分、再把 hidden states 转到 codec wave 里输出音频的部分。AR 需要 KV cache，但其他部分需求完全不一样，每个部分有不同的最优方案。当时我们把每种方案都配了一遍，因为不可能 AR 在跑的时候剩下两个闲着，或者剩下两个在跑的时候 AR 就不接收输入了。所以我们设计 vLLM Omni 这个框架的时候，假设每一部分都要充分解耦，不能当作一个简单的流水线。既能在 codec wave 输出的同时做异步调度。第一版框架重构了好几次，最后做到了一定的优化。但目前还有大概 20% 的空间没打满，profile 的时候还有一些 gap，主要是传 P2P 的时候有通信 bubble，有些通信部分还没消化得很好。
黄之鹏：vLLMOmni 这种方式已经走出了一条比较成熟的路吗？
莫梓峰：现在这种“主打 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 的设备，后来开始做国产设备的支持，并且和 Volcano 有这不错的联动。有一个厂商发接入 HAMi 的协议效果不错，也主动进来参与到社区中了，但是 HAMi 整个没脱离 device plugin 的体系。
DRA 在是去年下半年的时候进入到 GA 阶段的，不过我们在 GA 之前就已经开发 NVIDIA 的 DRA driver 了。说实话，DRA 表达能力没想象中那么好，高阶特性就靠 ResourceClaim 中 attribute 的 key-value 和 capacity 来描述。今年三月 KubeCon 跟 NVIDIA 的 Kevin Klues、Intel 的 Patrick 有一些沟通，他们的想法是借助 feature gates 一点点往里面加特性，先保持简单易用然后再增加高阶的功能，这是我特别认同的一点。想起来之前在范式建设用于大模型训练的集群时用的无损 IB 网络，但是当时 IB 插件只能把资源描述出来，想做 IB 和 GPU 的绑定调度比较麻烦，最后只能但是放弃 Kubernetes 了。
但现在不一样了，各个 driver 一联动，调度器就能把 device 属性统一考虑进来，实现类似拓扑感知调度等多功能都方便了不少，但是更高阶的动态能力还不行。在 HAMi 社区有飞利浦的工程师提 issue 问过，想做到设备被 PCI passthrough 到虚拟机的时候不做共享，没有 passthrough 就能共享，这种灵活的需求可能用 CRD 就很好实现，因为可以自定义排他状态，但 DRA 目前很难，因为调度器不知道底层分配策略的特性。所以现在 DRA 算是解决了 device plugin 的一些限制，但是更加高级的功能还需时间慢慢往前走。
黄之鹏：我们当时想推的方案是做统一的 CRD controller，不同加速器按规定的 metadata 上报能力，让调度器充分感知。当时我们说“让异构硬件作为第一公民”，但做过 K8s 的都知道这很难。带外做 CRD 有它的问题，in-tree 的好处是好用，不会劝退初学者，而且合入 GA 的特性质量有保证。缺点就是我们这种厂商觉得，等了一年又一年，好多东西就是一直用不起来。
杨守仁：现在 DRA 的新特性其实有不少的，但是这些特性 stable 的很少，很多都在 Alpha 阶段。然后面临一个恶性循环的困境：新特性加入的得越多，大家越不敢在生产上测试和使用；但是测试和使用的的越少，反馈就越少；反馈越少，到 Beta 到 Stable 就越慢；越慢就越没人敢用。
黄之鹏：这不只是 K8s 的问题，所有开源项目引入新硬件都会这样。以前做 RDMA 都跑在 TCP 上面，很鬼畜。后来我们做了一个开源小项目叫 TransferQ，算是帮忙解决了一下这块的问题。
黄之鹏：大模型的训练和推理任务，基本上就是一个固定池子，不太涉及调度行为，而且 Ray 这一层的存在多少会把 K8s 屏蔽掉。对于梓峰他们来说，日常可能根本不会跟 K8s 打交道，管什么寒武纪跟华为的卡怎么一起调度，这对他们来说更头疼了，你怎么看这个挑战？
杨守仁：业务不复杂跑 Ray 挺好，不用管底层设备分配和任务的并行方案的对应关系。今年 KubeCon EU 上能感受到 Kubernetes 社区的一些焦虑吧，担心 Kubernets 错过 AI Workload 一波浪潮，Cloud Native Infra 接不住 AI Workload 的需求。HAMi 在今年获得了不少曝光的资源，我个人认为很大程度上就是想弥合 Kubernetes 在 AI Workload 中对于设备管理的 gap。
另外，集群规模不大的时候，很多算法同学压根不用 K8s，几个节点一套 ssh 脚本就把任务跑起来了。大模型要考虑的是 NUMA 节点、PCI root 跨不跨，集群一旦大了，异构管理的问题才会真正冒出来。第一个头疼的就是碎片化，大模型 PD 分离的比例换一个模型未必最优，小模型像 Qwen3.6 27B 塞进去更会加剧碎片化，然后再加上波峰波谷一弹一缩，集群资源的碎片化就更严重。K8s 这套模型得配合 LWS、Volcano、Koordinator 这样的调度器才容易 work 好，但这需要集群先到了一定规模。
另一个明显变化是国产卡变多了，昇腾、寒武纪的用户量很大，客户至少要面对两到三种卡的调度，哪些能一起跑、模型怎么从 NVIDIA 的设备上迁过去，都得琢磨。PD 分离在实际部署里，国产卡通信明显不如 NV 丝滑，你得自己去设部署策略，节点网络跟节点本身有时还不匹配，优化起来特别费劲。vLLM 对 NVIDIA 设备的支持是最好的，体验丝滑，但对昇腾、天数、沐曦是支持到什么程度我们并不是很了解，加上有一些项目是厂商自己维护的，哪个模型用哪个版本效果性能最好我们也不是很了解。这些问题全凑在一起，做异构就是一大坑，精力全搭进去都未必够。不过最后绕一圈，很可能还是得回到 K8s 上，用别的方法反而更费劲。
黄之鹏：站在 K8s 这一层 Infra 的角度，守仁你会觉得 vLLM、HCL 这些框架在变得复杂臃肿吗？
杨守仁：从部署的角度来说肯定是更复杂了。原来大家不用 PD 分离或者分布式 KV cache 这种架构，就是节点拉大一点，靠 TP 和 PP 组成多个 DP 并在一起跑。但现在一旦做 PD 分离，prefill 节点怎么弄，decode 节点怎么拼？今天又听到多模态的 stage 还不一样。我在想，现在的 stage 是一个容器里多个 process 之间传递，那未来 stage 会不会也要动态扩缩容？如果是的话，这个管理复杂度就更难了，底下的 Infra 没有办法感知到这个复杂度或者计算特性。
我之前和研究一个做视频生成的同学合作过，视频那块要做音视频处理，也很吃 GPU，但它消耗的是 GPU 里的编解码器资源，但是问题是它们也会用显存，混合使用有可能会爆显存，如何隔离就又是一个新的问题。如果再把多模态引进来，Infra 的工作负载感知就更麻烦了。国产卡的编解码器性能行不行，甚至有没有都是个问题。把整个系统组合在一起的时候，我目前不希望见到这种东西。我希望像 Omni 这样能先处理好，我不用再去考虑帮它做水平方向的 scale。一旦这种跟底层调度结合在一起，需要面对的问题复杂性会非常高。
黄之鹏：我做异构出身，以前一度觉得异构越来越不重要了，大家都奔着同质化大集群去。但最近感觉异构又活回来了，主要两个原因：一个是后训练 RL，它的异构异步属性最近在特别增强；第二个是 agent。
Agent 说白了就是个人写的前端软件去调模型能力。大模型出现本来是奔着终结所有人类 heuristic 的东西去的，结果 agent 这种前端火起来了。我的答案很简单：大模型处理不了时间数据，没有时间概念，这跟训练过程有关。你想做 coding 或者任何工程类任务，就必须得有一个时间概念。现在那些龙虾、Hermes 之类的 agent 开源项目，本质就是把 CPU 的时钟借过来，让 agent 有时间感，但大模型本体还是没有时间。
这对我们做异构算是个好场景，除了刚才说的 RL 和 agent，还有一个就是多模态，涉及大量 codec 处理。
莫梓峰：多模态 RL 确实有人在做了，像 Vivo 前段时间也开了个 Vivo Omni，专门做多模态输入输出的 RL。这种 RL 比纯文本的 RL 更麻烦，因为你要传多模态的 embedding，要传一帧 state，通信量比传统的 text RL 大很多。从异步的角度看，异步通信的需求是非常大的，优化的瓶颈放大效应会更加严重。再加上本身多模态模型也是 multi-stage 的，异步叠加异步，太地狱了。
黄之鹏：这种场景下对异构的需求会越来越多吗？比如让 CPU 帮着预处理、异步处理掉很多其他任务。
莫梓峰：是。甚至之前我接到 IO 那边的反馈，说现在反而出现了 CPU 瓶颈。因为 CPU 在进程之间互相传东西，传输量太大了，GPU 反而跑不满。他们有个需求是把 processor 处理好的图片直接塞进去，跳过 processor 这一步，不然 processor 引入的 CPU 瓶颈太严重了。
杨守仁：Agent 这块，公司内部更多是各自在用，大规模服务端场景暂时还不多。但我能看到一个趋势：agent 对存储的压力上升很明显，产生的数据量特别大，共享存储的读写压力一下就上来了，因为任务什么时候读写你根本控制不住。
还有一个问题是，现在起 Claude Code，单台服务器能起的量很有限。大家有时用 ACP 模式，扩很多 sub agent，sub agent 再去调 Claude Code 写代码，可能内存一下就不够用了。这种情况下我们担心的是，随着工作进程变多，很多内存其实浪费在可以复用的地方，像 JavaScript 这种 runtime 本来就挺大的。再加上每个 process 要跑在安全的 sandbox 里，sandbox 的开销叠上运行时开销，能不能撑起大规模使用是个大问题。几十 G 或几百 G 的云服务器上，有限的 Claude Code 数量撑不住太大用量。我们认识从范式出去创业的同学，用量一上来服务器就 OOM。可能两条路：要么有更好的 runtime 解决这个问题，要么 sandbox 设计上能把 overhead 降得更低。反正我现在还没有很好的答案。
黄之鹏：一开始大家可能也没想到，瓶颈又转回 CPU 这边了。
展望未来
黄之鹏：到 2030 年，AI Infra 会变成什么样？
莫梓峰：未来一年都很难预测。模型进化太快了，说不定哪天又来一个新的模型，搬出个奇奇怪怪的东西，但我感觉软件进一步简化的概率更高一点。
黄之鹏：软件工程屎山这个事情是所有人逃不开的，但现在可能确实有可能会逆转，软件不用越做越麻烦，模型的能力在越来越强。
杨守仁： Infra 迟早要被 AI 接管。Infra 的课题没多复杂，就是细节多，这些细节模型要是学会了，可能比我们做得更好，而且很多地方其实是我们过度设计了。前几年大家反思微服务，发现大部分公司根本用不到那个级别，你不是谷歌，没那么多机房和业务，小业务一个主备 Nginx 加一套高可用数据库就非常能打了，为了追求稳定和鲁棒性加了一堆东西。模型能力够的话，可能很快就能收敛到你当前规模下的甜点。之前 Fable 5 可以使用的时候，有同学说它解决 CI/CD 慢的问题，一个晚上下来性能直接提了 10 倍，就因为好多细节他们没配好，第二天一看监控，整个 CI/CD 系统优化的过程中非常稳定，没有中断。
所以监控还是得自己搞，但 Infra 的操作和实现，按模型的迭代速度，可能以后真不需要我们了，它甚至能给出一个更好、更贴近当前规模的高性价比方案。如果模型和 token 成本降得足够低，方案迁移的成本也会很低，代码现在没那么值钱了。我们将来可能就是站在一个更高阶的 SRE 视角：定好 SLA、SLO、成本预算，剩下交给模型，那时候做 Infra 可能就轻松多了。
黄之鹏：你觉得做 Infra 的不会被取代，但是层次会更高？
杨守仁：可能从实现慢慢走向规划和设计，去理解业务。但是之前朋友给我说 Fable 5 优化他们的 CI/CD 的时候，我还是有点慌的，特别是他跟我说一个晚上就给他优化好了。因为之前我帮他们评估的时候，也觉得创业公司没那么大精力投在基建上。像 HAMi 社区，我们现在也非常困扰基建，因为面临异构场景，我们没有那么多卡和机器能实时测。一个用户提上来针对某款设备的修改，到底 OK 不 OK，我们心里没底，可能就在发版前找个地方测一下。我们之前跟 TiDB 的同学交流过，他们的单元测试 case 完善程度比我们好很多，所以他们能说过就能达到能合并的水平，我们还没做到这个级别。短期内，像我们这种开源项目，能通过一致性测试把质量拉到一个非常高的 bar，可能是个非常有挑战性的事情。特别是有很多开源项目，起步的时候还没大模型，纯靠人工写的 case，完全不能覆盖今天的需求。
黄之鹏：“即抛型软件”和高度个人定制化的软件以后会越来越多吗？还是说大多数人还是需要平台型软件？
莫梓峰：我觉得肯定还是要平台型的。就拿 vLLM 举例，一开始就是个配置 transformer 的 demo，越到后面缝合了越来越多技术。即抛式的你要缝合这么多东西，其实很困难，就算你的 agent 再强。尤其开源基础框架还有社区各个成员的 agent 帮着优化，总有可取之处，你起码可以抄。哪怕你即抛式的，也能从开源生态里去抄。有开源实现，你还能再省掉几个 token 钱。生态的力量是很强的。
杨守仁：我觉得大型开源项目可能会变成一个更像脚手架的工具。它的迭代很快，agent 也会跟着往前走，要达成某个目标，路径就非常短了。而且开源项目还有一个非常好的点：模型的训练数据。像 vLLM 这种社区，很多 PR 的整个流程都已经被收入训练流程了，agent 可能很知道你的 review 风格是什么。
莫梓峰：甚至有人专门来问我们哪些 PR 值得收集。
杨守仁：这本来就是个非常重要的事。所以就会有一个效应：模型对这种大型开源项目的亲和度、适配性会非常好。工具也会收敛，因为用的人多，大家在后训练阶段一定会强化对这个工具的使用能力。小众工具慢慢就没人用了，模型对它的调用会越来越差，特别是 API 不符合直觉的情况下，泛化不出这个能力。越好的项目越容易集中，模型在前训练和后训练阶段都会把它作为重要参考去强化。这就变成了一个脚手架，我在 vLLM 上做一些简单的 hack 去适配我的场景，很轻松，模型很快能发现去哪改、怎么改更符合作者的品味，改完之后甚至更容易回馈到社区。这是一个明显的正向循环，自我强化的过程，马太效应很明显的。
开源的力量
黄之鹏：开源软件、平台型软件作为脚手架和基石还是很重要，还有没有觉得做开源比做闭源更有优势的地方？
莫梓峰：据我所知，很多企业以前是魔改 vLLM 的。但 vLLM 迭代速度太快了，他们发现闭门造轮子不如开源出去，反而说不定还有人帮忙维护。这就倒逼那些闭源的也开源出来了，像滚雪球一样。
杨守仁：我们站的角度可能不一样。HAMi 社区背后有很多个厂商——范式、密瓜、睿思、道客等等。我们做开源的逻辑是，大家比较认可以开源为基础的商业模式。第一点是中立，用户不担心被某一家厂商锁死，厂商也知道在这里贡献不会被另一家话语权更大的踢掉。商业模式能跑起来。第二点是抢占标准，我这套标准大家用的多，就成为事实上的标准。再结合大模型时代，用的人越多、改的人越多、贡献的越多。
但偏 Infra 的开源项目最大的挑战是怎么保证所有 case 都能覆盖好，交付的质量要能让人信任。vLLM 在这一点上非常值得我们学习。你交付的产品质量如果不行，虽然用的人多，但每个版本都差一些，别人就会想另起炉灶。所以我觉得最大的难点：一是让大家相信这个社区是开放的、能 work 得很好；二是交付的软件质量是可信任的；三是长期愿景是大家都认可的共识。
观众：AI Infra 的定义是什么？
莫梓峰：你要支持整个 AI Agent 能跑起来的所有部分，其实都能归入 AI Infra，广义上来说。从细到算子，大到集群调度，都算其中一环。缺一不可，就像建房子打地基。
杨守仁：承载这个 workload 需要用到的所有组件，包括软件和硬件，合在一起就是 AI Infra。
黄之鹏：大模型时代所有最不光鲜、最苦的部分，就是 AI Infra。
观众：Infra 在异构硬件平台上运行过程中，发现硬件某些关键算子不支持时，怎么处理？
杨守仁：搞不定先找厂商，问新版本有没有做。之前碰过一个真不支持的，运气好在靠后的层，直接 offload 到 CPU 上跑了，如果是中间层频繁来回切的就没办法了。开源项目的话可以自己手撸算子，现在模型写 kernel 很强，像 Triton 自己改改效果还行，训练够用了。推理要像梓峰那样极致压榨的，就得把 profiling 跑一遍，让模型在 loop 里不停试，只要你愿意烧 token 的钱，总能优化到不错。补算子的维护成本确实有，但大开源项目你去提 issue，可能有人接，甚至有硬件厂商驻场的人帮你弄。最难的是改完之后验证，不说性能，先说一致性，非常费劲。我们之前验出一个 bug，特定 batch size 和 shape 下偶发出错，同学一个一个 batch size 试上去才发现中间有一段就是不行。如果是精度问题，暂时比较无解，我也没有很好的实践。
莫梓峰：一致性测试覆盖 corner case，只能出现一个补一个，像补洞那样。也有用 agent 去扫的，但效率不一定能抓住，毕竟 corner case 本来就很难复现。除非你发现偶发的精度丢失，就只能让 agent 跑几十次去扫，用不同 concurrency 去各种组合扫。像我之前做 video 用 GPU decode，只有异步的时候 concurrency 开到 16 以上才开始报 OOM 或者非法内存访问，那只能靠 agent 慢慢扫。