模型训完之后：华为云 AI 推理链路上的四个硬约束

很多团队第一次把大模型接进业务，都会遇到同一个落差：训练阶段耗的是预算，推理阶段耗的是耐心。

模型在测试集上跑得挺好，一上线，延迟、并发、账单三样东西同时失控。问题通常不在模型本身，而在推理这条链路。

一、推理不是 “小号的训练”

训练是一次性的大计算，目标是吞吐和集群利用率；推理是持续性的小计算，目标变成单次延迟和单位成本。

这两件事对硬件的要求几乎相反。训练阶段，卡越多越好、互联越快越好，因为要同时吞吐海量梯度；推理希望单卡装得下更多，每次算得更省，因为要压住每个请求的等待时间。

所以，“训练集群很强” 从来不能推出 “推理更便宜”。同一个集群的优化目标，换到推理场景，很多时候是反向的。

二、第一个约束：精度决定显存，显存决定能装多少

模型参数是死的，显存是活的。

一个 70B 模型，FP16 精度下光权重就接近 140GB，再叠加 KV Cache，单卡基本放不下。降低精度是最直接的手段。昇腾这条线上，华为云给出的能力是支持 FP8 与 FP4，并明确提到可以满足 DeepSeek V4 Flash 这类新模型的量化部署需求。

按字节算，FP8 相对 FP16 大约省一半显存，FP4 再省一半。这个账很诱人。

但量化不是免费的。精度降下去，输出质量、长尾任务的稳定性会有折损，而且折损往往不在测试集上出现，而是在真实业务的长尾请求里才暴露出来。所以 “能不能量化” 和 “量化之后还能不能用” 是两个完全不同的问题。

有意思的是工具链的顺序。ModelArts Studio 把量化放在训练之后、评测之前 —— 这个顺序是对的：先量化，再评测，而不是先上线，再发现效果掉了。

三、第二个约束：互联带宽决定你能不能把模型切开

单卡装不下，就要切。张量并行、流水并行，本质都是把矩阵拆到多张卡上，每一步计算完再同步。

同步靠通信，通信靠带宽。

华为云 ECS 产品页给出的口径是：自研通信协议下，UB 卡间互联双向带宽最高可达 1.6 T。这个数字的意义不在 “快”，而在于切分策略的选择空间 —— 模型切得越细，通信越频繁，带宽不够就会把算力空转掉。推理集群里最常见的瓶颈，往往不是算力不够，而是互联撑不住切分。

再往上一层是组网形态。CloudMatrix 超节点这类设计，想解决的问题是把多机多卡做成逻辑上的一个大节点，降低跨机通信的开销。对普通业务，这一层离得比较远；但它决定了 “万亿参数级的模型能不能在云上跑起来” 这件事本身是否成立。

四、第三个约束：调度决定你的账单

同样的卡，跑同样多的请求，调度方式不同，成本能差出好几倍。

核心是批处理。把多个请求拼成一个 batch 一起算，能显著提高硬件利用率；但拼得越多，单个请求的排队时间越长。这就是延迟和吞吐之间始终存在的取舍。

这也是 MaaS 真正的价值所在 —— 很多人以为它只是 “帮你调了个 API”，其实它做的是把这个取舍调整得当：请求排队、动态批处理、超时控制、多实例负载均衡，这些工程细节被平台接管，用户按 token 付费。

代价也很明确：你失去了对调度策略的控制权。当业务对首 token 延迟有极端要求，或者长文本请求需要单独排队时，标准策略未必够用。

自建推理服务，价值正好相反。你可以为一个具体业务定制策略，业界常见的做法是把 prefill 和 decode 分开部署，各自优化。代价是这套工程能力和人力，得自己出。

五、第四个约束：成本必须用两种口径算

MaaS 的账单很直观：token 数 × 单价。自建的账单很隐蔽：卡时 × 卡数，而真正的成本还要再除以利用率。

一个高频错误，是拿 “token 单价” 直接对比 “卡时价格”。这两者不可比。

更合理的对比是：在高峰请求量下，自建集群的实际利用率能到多少。如果只跑到 30%，那单位 token 的真实成本要乘以三倍还多，这个数通常比 “单价” 更能说明问题。

所以判断标准不是 “哪个更便宜”，而是 “你的负载曲线平不平”。曲线平稳、请求量大、对数据出域有硬约束，自建更划算；曲线波动大、请求量还小、想先验证效果，服务化更划算。

六、三个常见的误读

第一种，“参数越大效果越好”。推理成本随参数规模近似线性上涨，效果却是边际递减的。不少业务场景里，一个小参数的模型做领域微调，比通用大模型更合适，也更便宜。

第二种，“昇腾只能跑盘古”。MaaS 里预置了 DeepSeek R1/V3、Qwen3 系列、GLM-5.3，ModelArts 侧支持的模型在百款量级。硬件自研和模型锁死，是两件事，不能混为一谈。

第三种，“首 token 快就等于整体快”。首 token 主要吃 prefill 阶段，而长输出场景里真正占时间的是 decode，逐个 token 往外吐。只测首 token 延迟来评估推理性能，容易得出乐观结论。

七、选型前先问四个问题

第一，模型能不能放进单卡？放不下，就先看互联带宽和切分方案，而不是先看算力规格。

第二，延迟要求落在哪一段？首 token 吃 prefill，整段响应吃 decode，两者的优化方向并不一样。

第三，负载曲线平不平？平稳的曲线适合自建，抖动的曲线适合服务化。

第四，数据能不能出域？不能，那私有化部署不是可选项，而是前提。

八、写在最后

推理这条链路，难的不是把模型跑起来，而是把它跑得便宜、跑得稳。算力、精度、互联、调度，四段各有取舍，没有一段能单独解决全部问题。

所以选型时，先不要问 “哪家 token 更便宜”。先问清楚自己卡在哪一段 —— 是显存不够，是带宽不够，是调度不够，还是账单算错了。

这几个问题一旦有明确答案，方案基本也就定下来了。