云海天狼上周一个做智能客服的哥们儿找我诉苦：GPU集群的利用率不到15%，但每月的硬件账单一点没少。他们的推理模型切了三套——意图识别、语义检索、长文档摘要，结果是小请求在GPU上排队等大请求，大请求在GPU上空转等显存。我一听他这句话就明白，他是被“云端推理必须统一用GPU推理”这个惯性思维给绑住了。云端推理里的AI模型，根本不是一种负载，异构计算才是把成本和延迟真正盘活的钥匙。
这篇内容，我从一个常年做推理服务部署的人的角度，把异构计算是怎么在云端推理里落地的、算子应该怎么分配、混合调度要防哪些坑，以及什么样的服务才值得做异构改造，全部讲透。适合正在被推理成本压着、或者准备把服务从单芯片底座迁到CPU+GPU+专用加速器混合架构的工程团队参考。
1. 为什么说“单芯片推理”先扛不住了
1.1 一个看起来正常、实际上很浪费的推理服务
很多团队的推理服务，形态高度相似：N个GPU实例，每个实例上用PyTorch或TensorRT加载同一个模型，前面挂一个负载均衡器，请求进来按轮询或者最少连接数转发。压测时挺正常，QPS达标，P99也在预算内。但拉到线上观察一周就会发现，GPU利用率图是一条“锯齿线”，峰值可能冲到80%，但大部分时间趴在10%以下。
问题出在哪？不是硬件不行，而是模型推理天然包含多种“吃力不讨好”的环节：输入要做Token化、Padding、Mask构造；请求有长有短、难度有大有小；有的query一句话就分清楚了，有的query翻遍了业务库还歧义重重。这些请求如果全走同一个重型GPU模型，等于让所有顾客都去五星级酒店排队办入住——明明有些需求在便利店就能解决。
真正合适的做法，是让不同计算特征的负载，跑到不同特性的计算芯片上。这就是云端推理中异构计算要解决的核心问题。
1.2 算力利用率为什么上不去
GPU算力利用率上不去，不外乎三类损耗：
第一类是排队损耗。在线推理服务为了保证吞吐，会给同一个批次凑足够多的请求再做Forward。一个短句子可能只要几毫秒的GPU计算，但凑batch等队列可能让它等几十毫秒。这类损耗本质上是“不同长度的请求挤在一根管道里”造成的。
第二类是核函数启动损耗。GPU上的每个小算子，从CPU下发kernel指令到GPU执行，中间有固定的启动开销。模型里大量存在的是LayerNorm、Add、Reshape这类“轻量级算子”。当batch很小、单算子计算量不高时，GPU算得再快也补不回来启动和同步的时间。
第三类是资源分配损耗。模型weights、KV Cache、激活值碎片化地占着显存。显存越大，碎片越多，实际能同时跑的并发batch反而越受限制。很多时候，你买了80GB的卡，但一个服务跑起来只能安全用60GB，剩下的被碎片占着。
这些损耗，单纯靠换更强的GPU解决不了。换个思路，把“轻量计算”和“重量计算”拆到不同芯片上，反而是性价比更高的路径。
1.3 云端推理里的“异构”到底指什么
在训练场景里，异构计算通常指多机多卡并行训练——数据并行、张量并行、流水线并行那一套。但云端推理的异构计算，含义要更宽：它指在同一套在线服务架构中，同时使用不同类型的计算资源，由调度层根据请求特征和算子特征，把计算分发到最合适的芯片上执行。
这里面至少包含三个子问题：
- 硬件异构：CPU、GPU、NPU、FPGA各自承担哪一部分负载；
- 模型异构：同一个服务里，简单请求跑小模型，复杂请求跑大模型；
- 算子异构：同一个模型的执行图里，一部分算子在GPU上，一部分算子在CPU或专用加速器上。
很多人一听到异构计算就以为要上一堆杂牌硬件，其实不是。真正的异构计算是从“负载—芯片”匹配度出发的成本优化和延迟优化。下一节，我们先把“算子该落在哪颗芯片”这件事的底层逻辑讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 异构不是堆硬件：算子落在哪儿才是真问题
2.1 负载的三个基本特征
不管什么模型，推理时都可以把计算负载拆成三类，它们在异构设计里的待遇完全不同：
计算密集类：典型代表是全连接层、卷积、多头注意力里的矩阵乘。这类算子的特点是算术强度高——每读取一个字节的数据，能做很多次浮点运算。如果让它跑在CPU上，受限于SIMD宽度和缓存带宽，利用率会很可怜；但放到GPU上，能轻松吃到几千核并行度的红利。
访存密集类：典型代表是Embedding向量查表、LayerNorm、激活函数、Softmax中的中间读写。这类算子大部分时间在等数据搬运，算数本身很少。GPU的大显存带宽对它有优势，但如果数据已经在CPU侧，再花PCIe带宽搬到GPU上，反而不划算。
控制密集类：典型代表是Tokenization、动态Padding、Mask构造、循环控制、后处理里的字符串逻辑。这类代码没法批量并行，几乎只能跑在CPU上。把它们硬搬到GPU上，只会制造一堆“小kernel满天飞”的延迟。
对云端推理服务来说，最基本的异构思路就是：让控制密集的留在CPU，让访存密集的贴近数据所在端，让计算密集的按量级决定去GPU还是专用加速器。
2.2 不同芯片的“性格”对比
为了便于选型，我把芯片的特点按推理场景做了一张表，大家可以对着自己的模型结构去套：
| 芯片类型 | 强项 | 常见瓶颈 | 典型适用推理段 |
|---|---|---|---|
| CPU | 灵活处理动态逻辑、低延迟响应小负载 | 内存带宽远低于HBM，并行核数有限 | 预处理、后处理、小模型、路由分流 |
| GPU | 大规模矩阵乘、超高显存带宽 | kernel启动开销、排队抖动、显存成本高 | Transformer主体、大batch CV/NLP |
| NPU/ASIC | 特定算子能效比极高，功耗低 | 数据格式/算子支持受限，怕动态shape | 固定结构量化模型、高吞吐专用场景 |
| FPGA | 延迟可控，可深度定制流水线 | 开发周期长、浮点资源弱 | 自定义算子、固定低延迟链路 |
这张表的核心不是告诉你“哪个更好”，而是说每类负载都有自己最舒服的芯片。异构计算的功夫，就在于尽可能让每类算子长时间待在自己舒服的区域里，而不是反复横跳。
2.3 数据搬运这笔账怎么算
选芯片的时候，年轻人最容易忽略的是数据搬运成本。很多优化方案在理论上算力节省不少，但一落地就发现延迟反而涨了——因为数据跨设备搬运的耗时，把算力节省全吃掉了。
这里给一个粗略的估算方法：假设一层算子在GPU上执行需要T_ms，如果要把这个算子的输入搬到CPU上来执行，搬运时间大约是数据量 / 总线带宽。比如PCIe 4.0 x16的单向带宽大约有30GB/s，一批32×128×768的激活数据量接近12MB，来回搬运一次就是0.8毫秒左右。算子上CPU后如果只比GPU慢不到1毫秒，整体上搬过去就是亏的。
所以工程上有一条铁律：跨越设备边界的数据，要少、要大、要整块。宁可在同一种芯片上多做一些计算，也不要为了让“计算曲线好看”而在设备之间来回倒腾数据。
2.4 模型级拆分和算子级拆分怎么选
异构拆分有两种粒度，效果差别很大。
模型级拆分是把请求分流到不同模型上。例如同一个入口，简单意图用CPU小模型，复杂语义用GPU大模型。这种拆分的优点是把异构逻辑放到路由层，对模型本身侵入小，各模型内部还是单芯片执行，调试简单。
算子级拆分是在模型计算图内部，把一部分算子绑定到CPU，另一部分绑定到GPU。优点是可以让一个大型模型利用异构算力叠加；缺点是需要图优化器配合，且跨设备通信一旦频繁，收益很容易打水漂。
我个人的建议是，第一版异构改造先做模型级拆分，等把路由准确率、资源配比、监控体系都跑顺了，再向算子级拆分延伸。除非你的服务只部署一个巨型模型，没有拆分余地。
3. 四级加速链路：模型、编译、算子、硬件层怎么协同
3.1 模型层：为异构留出干净的切分点
异构计算从模型设计阶段就开始介入了。训练时你可能不需要关心部署形态，但推理部署时，模型结构本身决定了能不能切、好不好切。
干净的操作是给模型留出“语义边界清晰的子图接口”。比如把BERT类的模型划分成三个子图：Tokenizer+Embedding、Transformer Encoder、Pooler+Classifier。前一个子图完全可以在CPU上处理，中间的大Encoder主体在GPU跑。这样设计的好处是每个子图的输入输出张量形状相对稳定，不用为了异构而反复做动态shape适配。
如果你的模型已经训练好了，再回来改结构不方便，也可以退而求其次，在模型外面包一个“适配层”。把前处理、后处理从模型Forward里剥离出来，放到CPU侧的Server代码里。这一步看起来不起眼，但能让GPU上少掉大量零碎kernel，实测对延迟和利用率都有明显改善。
3.2 编译层：让执行图自己学会“分家务”
现在主流推理引擎都支持多执行后端，也就是常说的Execution Provider / EP。ONNX Runtime里可以同时注册CPUExecutionProvider和CUDAExecutionProvider，TensorRT也有对应的Plugin机制。
原理上，推理引擎会加载模型的计算图，然后按算子支持情况做图分割：某个算子如果在GPU上有实现，就分配到GPU子图；没有的话，自动落到CPU子图。引擎会在子图之间插入数据拷贝节点，保证计算能连起来。
这里有个关键经验：别完全依赖引擎自动分割。自动分割的决策依据是“算子能不能跑”，而不是“跑在哪里更划算”。一个LayerNorm在GPU上明明也能跑，但如果你希望它留在CPU，就得在图上显式标注设备。工程做法是先用profiling工具把整个模型的算子耗时表打出来，然后手动指定十几个关键节点的设备归属，剩下的交给引擎去优化。
3.3 算子层：把计算形状做规整
算子层的核心是“规整”。不同芯片对不同张量形状的敏感度差异很大。
GPU最怕的是形状不停的跳变。一个请求seq_len是35，下一个是120，再下一个是18，GPU上的kernel每次都要重新实例化，缓存效果差得一塌糊涂。NPU更夸张，很多芯片对输入尺寸有对齐要求，比如16的倍数，否则要么拒绝执行，要么自动填充浪费算力。CPU相对温和，但单算子太小也吃不满AVX向量化。
所以算子层要做的三件事是：
- 固定最小推理单元：一个batch中的样本按长度分桶，长的进A桶，短的进B桶；
- 对不满足芯片对齐要求的维度做Padding，Padding到固定档位；
- 把网络里的动态循环和Trie结构，想尽办法改成静态张量运算。
做完这三件事，编译层和高性能kernel才能发挥出真正实力。
3.4 硬件层：驱动、专属SDK和运行时的匹配
很多人做到这层就不愿意细看了，但恰恰是硬件层最容易出“诡异问题”。同一个GPU型号，不同驱动版本对TensorRT的算子支持可能不一样；同一个模型，用厂商闭源SDK跑和自己手写kernel跑，数值都可能略有差异。
在异构架构里，CPU侧一般会用到OpenMP、AVX512、oneDNN；GPU侧用CUDA、TensorRT；NPU侧用厂商提供的CANN或类似运行时。这些库的版本之间互有依赖，又都跟推理引擎绑定。我踩过一个典型的坑：升级了CPU侧的性能库之后，有一个常用算子被打到GPU执行，但因为GPU侧缺少对应算子的高精度实现，最终走了低精度路径，上线后用户反馈结果偶尔异常。
所以在硬件层，要做三件固定动作：
- 锁版本：把驱动、加速库、推理引擎的版本组合做成固定镜像，不要跟着最新版乱升级；
- 做回归：每次升版本，都要用同一批真实请求做逐算子的输出比对；
- 记录回退：明确记录每个算子在哪类硬件上会退到低精度kernel，并纳入测试用例。
4. 实战案例：把一个线上BERT服务改造成CPU+GPU混跑
4.1 场景设定：先诊断再动手
为了讲清楚，我拿一个典型的线上文本匹配服务举例。模型是12层的BERT，部署在GPU上，主要做两件事：短query的意图分类，和长文本的语义相似度。业务流量有明显潮汐：白天高峰QPS接近1500，凌晨低谷只有几十。压测的时候GPU利用率能到60%，但线上全天平均利用率不足15%，P99延迟却有280毫秒。
这个症状本身就说明：高峰期GPU是够的，但负载结构不合理——大量短query拖着长文本一起排队，导致短query延迟被拉高，GPU缓存也被长序列显著挤占。
4.2 请求分级与模型路由
第一步，我们给线上请求打标签。从业务日志里把历史请求按两个维度分成了四类：
- 文本长度：短（小于64 token）还是长（大于256 token）；
- 语义复杂度：用一个小模型计算的一次分类置信度来粗判。
改造后的推理链路是这样的：所有请求先进一个CPU上的轻量路由器，路由器先看文本长度和业务类型。短query直接交给部署在CPU上的蒸馏小模型；长query和语义复杂度高的短query才进入GPU的大模型队列。GPU侧同一时间只处理真正需要高算力的任务，小任务不再挤占GPU的排队窗口。
路由本身的准确率也不是一开始就高的。我们用线上日志回流训练了一个轻量分类器来判断“这个query直接答比较稳，还是需要上重模型”，前两周每天人工抽检一次误判case，把误判样本加回去训练。等路由准召率达到97%以上再全量放开。
关键代码如下：
python复制def route_request(request):
if request.text_length <= 64 and request.business_type in SIMPLE_TASKS:
# CPU侧小模型足以覆盖
return "cpu_distill"
if request.semantic_score < ROUTER_THRESHOLD:
# 置信度高，短文本，CPU处理
return "cpu_distill"
return "gpu_full"
def serve(request):
route = route_request(request)
if route == "cpu_distill":
return cpu_session.run(request.tokens)
else:
# GPU侧先入动态batch队列
return gpu_batcher.submit(request.tokens)
4.3 GPU侧同步做的四件事
光做路由分流，GPU侧的“空转病”还没完全治好。我们同时在GPU侧做了四项改造。
加动态batching：GPU侧维护一个batch队列，允许请求在5毫秒窗口内凑批。由于短query已经被CPU消化掉，进入GPU队列的请求长度更接近，batch的形状更规整，显存和算力的利用率都上涨了。
做序列分桶：长文本不是无脑都往256以上的大桶里塞，而是按64、128、256、512分成四档。每个档位单独跑一个batch，避免了长短混合导致的同batch内大量Padding浪费。
开启TensorRT INT8：大模型FP16转INT8本来就有精度风险。我们先用5000条真实请求做校准集，跑完INT8后对线上输出的embedding做余弦相似度统计，跟FP16的结果比对，相似度保持在0.99以上才放量。因为只对长query走INT8，短query在CPU上还是FP32，两边精度策略互不干扰。
把前后处理彻底搬到CPU：Tokenizer、Padding、Mask、结果后处理全部移出GPU推理逻辑。GPU真正执行的只有Transformer Encoder和分类头，把GPU侧的小算子数量砍掉了将近三成。
4.4 实测数据与成本变化
改造上线后我们跑了七天完整业务周期，指标对比如下：
| 指标 | 改造前 | 改造后 |
|---|---|---|
| GPU全天平均利用率 | 14.6% | 57.2% |
| 短query P99延迟 | 280ms | 45ms |
| 长query P99延迟 | 280ms | 160ms |
| GPU实例数 | 3台T4 | 1台T4 |
| CPU服务器 | 2台16核 | 4台16核（承担路由+小模型） |
这里的核心收益不是某台设备跑得更快，而是让每一类请求的延迟都下降了，同时把GPU资源数量压缩到原来的三分之一。虽然CPU机器增加了两台，但整体年化硬件成本大约节省了50%以上，还额外获得了吞吐余量。
4.5 这个案例里最容易被复刻错误的一点
必须说清楚，这个改造之所以能成，前提是业务天然有“轻重负载并存”的特征。如果你的服务只有长文本语义匹配一种负载，没有那么多短query可以分流，那这套路由分级方案的收益会大打折扣，应该转而做算子级拆分。所以不要把这个案例当万能模板，要把它当成一个判断方法论。
5. 加速之外的五个暗礁：稳定性和可运维性
异构计算一旦上了生产环境，真正的挑战不是性能，而是稳定性和可运维性。下面这五个暗礁，我都在真实项目里碰到过，逐个说清楚。
5.1 暗礁一：“CPU免费”的错觉
很多人以为把请求放到CPU上跑，就是零成本。实际上一旦CPU模型并发上去，它会抢占CPU的缓存和内存带宽，直接影响GPU侧的前处理速度。我们在压测时发现，CPU小模型在满负载运行时，同机GPU推理服务的前处理时延从0.8毫秒飙到3.2毫秒。
解决办法是给CPU模型单独固定核数，用taskset或者容器CPU绑核，禁止它和GPU服务的前处理线程抢同一个物理核。同时给CPU侧的内存带宽预算做个硬性限制，宁可让CPU模型牺牲一点吞吐，也要保住GPU侧主链路的稳定。
5.2 暗礁二：动态Shape打穿异构链路
异构计算里最怕的是“动态Shape连锁反应”。模型被拆到多端后，只要一端产生新的shape组合，其他端就要跟着重新编译kernel。有些NPU甚至会在运行时做图编译，导致单个请求延迟从10毫秒直接飙到几秒钟。
这一类问题要靠“shape白名单”来治理。上线前把模型可能遇到的所有shape组合都列出来，只允许几个固定档位通过网关，其余的一律做Padding或者拒绝并走fallback逻辑。在推理服务里，shape的可控性比模型的理论精度重要得多。
5.3 暗礁三：跨设备传输的“隐形时间片”
模型级路由改造后，跨设备传输还不算严重。但一旦走到算子级拆分，每个batch的数据都要在设备间搬一次。如果做拆分的时候没意识到“搬运也需要占用总线”，并行调优就会陷入“CPU和GPU都在忙，但请求总延迟更高”的匪夷所思境地。
定位这个问题最有效的工具是分阶段的耗时追踪。把一个请求的生命周期拆成网络等待、CPU前处理、跨设备拷贝、GPU排队、GPU执行、CPU后处理六段，分别打点，通过trace系统拉出来看。这比在GPU上装各种性能分析器好用得多，因为它在第一时间告诉你时间到底去哪了。
5.4 暗礁四：精度口径不一致
异构的各个端因为硬件指令不同，对浮点运算的处理可能有细微差别。FP32在CPU和GPU上基本一致，但像LayerNorm这种带reduce的算子，因为并行归约顺序不同，输出差几个ulp很正常。INT8和FP16的路径差异就更大。
处理原则是：给每个异构端设定一个基准精度级别，跨端切换时强制对比输出。不需要让所有端跑完全一样的精度，但要确保端与端之间的结果差异在业务可接受范围内，并且有自动比对的任务在每次发版时跑一遍，而不是靠上线后人工排查。
5.5 暗礁五：故障切换时“异构池互相拖累”
异构架构中最容易被忽视的是故障域。单一GPU架构下，一个实例挂了，负载均衡器会把流量转发到其他GPU，行为可预期。异构架构下，如果CPU路由节点挂了，所有GPU请求会瞬间涌入，反之，如果GPU池异常，CPU小模型可能被逼着处理它扛不住的重请求。
因此，异构服务里的每个组件都要单独设置熔断阈值。CPU路由节点要能快速摘除并降级为“默认全部走GPU”，GPU队列长度超限时要能自动抛弃非关键请求或者响应降级。不要指望一个健康检查就能覆盖所有故障场景，多做几次混沌演练比看几篇架构文章都管用。
6. 上异构前先算清账：评估指标与渐进式改造路径
6.1 什么样的服务适合异构化
有没有一个判断标准？根据我自己的经验，满足下面三个信号中的至少两个，异构改造的ROI才比较好看：
| 信号 | 说明 |
|---|---|
| GPU利用率长期低于30% | 说明大量算力在空转，有值得分流出去的低价值负载 |
| 请求延迟呈现“双峰分布” | 短请求和长请求混跑，互相拖累，适合分级路由 |
| 模型形态多样 | 同时存在大模型和小模型，天然可以按芯片类型分池部署 |
反过来说，如果GPU利用率长期稳定在60%以上，延迟分布也均衡，那优先要做的不是异构，而是先做动态batching和量化，把单芯片的潜力榨干。异构计算是“单芯片已经优化不动”之后的下一步，不是起步动作。
6.2 渐进式改造四步走
异构改造最怕一步到位。我建议按四个阶段逐步推进，每个阶段都有明确的验证指标，任何一个阶段收益不达标都可以停下复盘，不至于把系统改坏。
阶段一：暖身——把预处理和后处理全部挪出GPU。这一阶段的收益几乎白拿，因为控制密集型的代码本来就该在CPU上跑。验证指标是GPU侧每秒执行的kernel数量下降比例。
阶段二：分流——引入一个轻量路由器和CPU小模型。先只切5%的流量做灰度，确认CPU小模型在不同业务类型上的准确率和延迟。验证指标是GPU利用率是否明显上升，CPU小模型的误判是否在可控范围。
阶段三：整型——给GPU侧模型做分桶和量化。因为在阶段二里GPU上剩下的大多是长query、高计算量任务，此时做TensorRT INT8或者FP16收益更大，风险也更集中。验证指标是长query的P99延迟和精度比对结果。
阶段四：拆图——如果仍有部分请求必须单次跑完一个超大型模型，再考虑算子级拆分。选模型里计算量占比超过70%的稠密层留在GPU，把Embedding、LayerNorm、Pooler这些算子固定到CPU或专用加速器上。验证指标是端到端延迟和成本是否都比单芯片方案更优。
6.3 收益账本怎么记
最后给一张我做异构改造时用来算账的简单模板，团队可以照着填：
code复制月成本 = GPU实例单价 × GPU数量
+ CPU实例单价 × CPU数量
+ 异构调度层开发/运维人力分摊
月收益 = 节省的GPU数量 × GPU单价
+ 因服务质量提升而减少的投诉/退款金额(如有)
+ 容量余量带来的业务增长收益(估算)
ROI = (月收益 - 月成本) / 月成本
需要提醒的是，异构调度层本身的复杂度也是一笔成本，至少要预留一个人月去搭路由、监控、灰度链路。团队人数小于三人、又只有一个推理服务的话，我不建议贸然上异构，先把动态batching和模型量化做透更加实际。
我个人在实际项目里体会最深的一点是：异构计算真正的价值，不是让单次推理变得更炫，而是让服务在成本和延迟之间多了一个可调节的旋钮。短期内它是成本工具，长期看，它能支撑你在同一套逻辑里容纳更多形态的模型和更多种类的请求，不会因为某一种硬件资源到达瓶颈就锁死整个业务的增长空间。如果决定尝试，先把上面说的阶段一走扎实，再谈后面的算力编排。