异构推理能力评测：GPU与NPU协同到底能带来什么

随着端侧与边缘侧AI推理需求增长，单一计算单元已经难以在吞吐、延迟、功耗和成本之间取得平衡。越来越多的高性能计算平台开始同时集成GPU与NPU两类加速资源。GPU擅长大规模并行计算和复杂算子执行，NPU则在特定矩阵运算、卷积类负载和能效比上具有潜力。问题在于，当二者同时参与推理时，性能是否一定提升？协同方式如何设计？哪些场景真正受益？这些问题不能靠主观判断，而需要通过结构化评测来回答。

本文将以一类集成GPU与NPU的计算平台为评测对象，围绕同一个模型、同一套量化权重、同一个推理入口，比较三种计算资源组合：仅GPU执行、GPU加NPU切片协作、GPU加NPU双bank协作。评测重点不是某个品牌或某个具体产品，而是梳理一套可复用的异构推理评估方法。

一、评测对象与背景说明

本次评测对象是“异构加速推理链路”。它包含几个关键组成部分：

1. 计算平台：同时具备GPU与NPU的集成计算环境；
2. 模型与量化：同一模型权重采用同一套低比特量化方案；
3. 推理实现：使用同一推理入口和统一调用方式；
4. 协作模式：GPU单独执行、NPU切片协作、NPU双bank协作。

评测目标不是验证某个硬件参数，而是回答一个更通用的问题：在给定模型、量化和调用方式不变的情况下，引入NPU协作是否能够改善推理效率，以及这种改善与瓶颈出现在哪个环节。这个目标对开发者和技术负责人更有参考价值，因为它直接关联到是否需要为异构调度投入额外开发成本。

二、评测目标：我们到底要验证什么

在开始测试前，需要明确本次评测要回答的问题。评测目标应尽量具体，避免“看看性能好不好”这类模糊表述。本文设定以下五个评测问题：

1. 不同计算资源组合下，推理任务的处理能力是否存在稳定差异；
2. NPU加入后，各计算单元之间的任务划分是否合理；
3. 不同协作模式对首包延迟、持续吞吐和尾部延迟是否产生不同影响；
4. 相同模型与量化条件下，资源组合变化是否影响输出一致性；
5. 是否可以通过观测资源占用和调度行为，判断当前瓶颈在计算、显存带宽还是调度开销。

这五个问题分别对应功能正确性、性能表现、稳定性、一致性和可观测性。它们构成了后续所有测试的基础。

三、评测维度设计

评测维度需要覆盖异构推理链路的完整生命周期，而不只是跑一轮压测。建议从以下七个维度展开：

3.1 功能正确性

首先验证不同资源组合下，推理输出是否保持一致。功能正确性是性能对比的前提。如果NPU协作导致输出结果漂移，即使吞吐提升也没有意义。验证方式包括：

• 固定同一组输入样本；
• 对比GPU单独执行与NPU协作执行的输出张量差异；
• 检查是否存在量化溢出、算子降级或精度损失放大的情况；
• 对多步推理任务，检查前序输出是否影响后续调度路径。

3.2 性能表现

性能是本次评测的核心维度。可以从三个指标观察：

• 首包延迟：从提交请求到返回第一段有效结果的时间；
• 持续吞吐：单位时间内完成的推理请求数或生成token数；
• 尾部延迟：高并发或长时间运行下，较慢请求的延迟分布。

性能表现必须结合计算资源利用率一起解读。仅看吞吐容易忽略资源浪费或调度失衡。

3.3 资源占用与调度效率

异构推理的关键不是“NPU有没有被用上”，而是“用上之后是否减少了整体瓶颈”。需要观测：

• GPU计算单元占用率；
• NPU计算单元占用率；
• 显存与片上缓存占用情况；
• 数据在GPU与NPU之间的拷贝耗时；
• 调度器等待时间。

如果NPU协作虽然降低了GPU占用，但引入了大量数据搬运开销，整体收益可能被抵消。

3.4 稳定性

稳定性测试重点观察长时间运行和异常输入下的表现。包括：

• 连续运行是否出现性能衰减；
• 是否存在显存碎片化或缓存污染；
• 异常输入是否导致资源释放失败；
• 长时间负载后，NPU任务是否出现排队或饿死现象。

3.5 可观测性

异构调度比单设备执行更难调试。评测时需检查是否具备以下能力：

• 各计算单元的独立利用率指标；
• 任务级延迟拆分，区分计算耗时与拷贝耗时；
• 推理请求的调度轨迹；
• 错误码与异常路径的可追踪性。

如果无法观测到任务在哪一个环节被阻塞，后续优化将非常困难。

3.6 兼容性与易用性

评测还要关注接入成本。包括：

• 是否需要修改模型结构或推理代码；
• 是否需要在不同协作模式间切换时重新编译；
• 是否支持动态批处理；
• 配置项是否足够清晰，避免误用导致性能下降。

3.7 成本收益比

最后需要将性能收益与开发、维护成本放在一起判断。引入NPU协作意味着更复杂的调度逻辑和更多故障排查点。如果收益有限，维持单设备执行可能是更合理的选择。

四、评测环境与前提条件

为了保证结果可复现，测试前需要明确以下前提条件：

4.1 固定变量

• 模型版本与权重文件保持一致；
• 量化方案保持一致，包括量化位宽、分组大小和是否启用辅助精度；
• 推理入口保持一致，避免不同实现框架引入差异；
• 输入样本与生成参数保持一致，例如上下文长度、生成长度、采样策略；
• 运行环境保持一致，包括驱动版本、运行时库、内存频率、功耗策略和散热条件。

4.2 测试边界

本次评测只比较同一推理入口下的三种资源组合，不涉及跨框架、跨量化方案或跨模型结构的横向对比。结论不能外推到所有模型和所有硬件平台。

五、评测方法设计

5.1 基线建立

首先运行GPU单独执行模式，作为性能基线。基线需要记录：

• 单请求首包延迟；
• 并发请求下的吞吐曲线；
• GPU计算单元占用率；
• 显存带宽使用情况；
• 端到端平均延迟与P95延迟。

基线数据用于后续对比，因此应重复运行多次并记录波动范围。

5.2 对比测试组

在基线稳定后，分别启用NPU切片协作和NPU双bank协作。测试时保持输入样本、并发数和生成长度不变，只改变资源组合方式。

对比测试需要关注三个问题：

• 性能是否发生方向性变化；
• 资源占用是否从单点瓶颈转向多点均衡；
• 是否出现新的瓶颈，例如数据拷贝、调度排队或缓存冲突。

5.3 分层验证流程

建议按以下顺序分层验证：

1. 功能正确性验证：跑小样本对比输出；
2. 单请求延迟测试：观察首包延迟变化；
3. 并发吞吐测试：逐步提高并发数，观察吞吐拐点；
4. 长稳测试：连续运行，观察性能衰减和资源异常；
5. 异常输入测试：输入超长、空输入、特殊符号等样本，验证容错能力；
6. 资源监控分析：结合各计算单元利用率判断瓶颈位置。

5.4 通用监测指标

测试过程中应记录以下通用指标，不依赖特定工具：

• 计算单元平均利用率；
• 计算单元峰值利用率；
• 显存或共享内存占用；
• 数据搬运耗时占比；
• 任务排队等待耗时；
• 请求错误率；
• 输出一致性偏差。

这些指标可通过系统级监控接口或推理运行时暴露的通用统计信息获取。

六、结果解读方法

评测结果不能只看一个最终分数，而要从多个信号中综合判断。

6.1 功能一致性判断

如果NPU协作模式输出与GPU单独执行完全一致，说明该模型在该量化方案下对异构执行具备较好的算子一致性。如果存在微小偏差，需要判断偏差是否在可接受范围内，并确认是否由量化舍入顺序变化导致。若偏差明显，则说明当前模型或量化方式不适宜直接启用NPU协作。

6.2 性能差异解读

如果NPU协作后吞吐提升但首包延迟增加，可能意味着任务调度引入了额外启动开销。这种模式更适合离线批量推理，而不适合交互式低延迟场景。如果NPU协作后吞吐没有提升，但GPU占用率下降，可能说明当前瓶颈不在GPU计算，而在显存带宽、数据拷贝或调度效率。此时应重点观察数据搬运耗时占比。

6.3 双bank与切片协作的区别

切片协作通常将模型部分算子或部分层分配到NPU，适合串行依赖较少的模型结构。双bank协作更强调并行利用NPU内部多个计算bank，适合可同时拆分的计算负载。如果双bank没有带来明显收益，可能原因包括：

• 模型计算图不适合拆分；
• 内存带宽成为瓶颈；
• bank间同步开销抵消了并行收益；
• 当前框架调度策略未充分暴露并行度。

6.4 稳定性结果解读

如果长时间运行后性能出现下降，需要进一步定位是资源泄漏、缓存污染还是功耗限制。如果异常输入导致任务卡死，则说明异构调度在错误恢复路径上还不够健壮。这类问题在单设备模式下可能被掩盖，在异构模式下会明显放大。

七、适用场景分析

根据上述评测逻辑，不同业务场景应采用不同的评估重点。

7.1 本地单用户交互场景

重点看首包延迟和资源占用。如果NPU协作导致首包延迟上升，即使吞吐提升也不适合该场景。此时应优先保证响应速度，避免复杂调度。

7.2 批量离线推理场景

重点看持续吞吐和单位功耗下的处理能力。可以容忍首包延迟稍高，但需要关注长稳运行下的性能衰减和资源均衡。

7.3 多用户并发服务场景

重点看并发吞吐、尾部延迟和调度公平性。需要确保NPU协作不会导致部分请求长时间排队，同时关注GPU与NPU之间的数据拷贝是否成为瓶颈。

7.4 边缘部署与功耗受限场景

重点看能效比和功耗控制。NPU在部分矩阵密集型算子上的能效优势可能更明显，但前提是调度开销足够低，否则整体功耗收益会被抵消。

八、风险与限制

任何评测都存在边界，本文涉及的内容尤其需要注意以下几点：

1. 单一模型与单一量化方案下的结论不能直接推广到其他模型；
2. 不同计算平台的GPU/NPU配比、内存架构和调度策略差异很大，结果不具备普适性；
3. 测试数据规模、并发模型和生成长度会显著影响结论，需要在匹配自身业务特征的条件下重新验证；
4. 输出一致性偏差可能随输入分布变化，需扩大样本覆盖范围；
5. 长稳测试的周期和负载模式应尽量贴近生产环境，否则容易低估资源积累问题；
6. 异构推理的收益高度依赖推理运行时的调度实现，而这类实现可能随版本更新发生较大变化。

九、选型与使用建议

基于通用评测逻辑，给出以下条件化建议：

若业务对首包延迟敏感，应优先保持单设备执行，或仅在离线预测阶段引入NPU协作，避免调度开销影响交互体验。

若业务以批量处理为主，可尝试NPU切片协作，同时重点优化数据搬运路径，尽量复用缓存，减少跨设备拷贝。

若模型中存在大量可并行计算的矩阵算子，可进一步验证NPU双bank协作是否能提升吞吐，但需确认内存带宽是否成为新的瓶颈。

若当前已用GPU单独执行且性能满足业务需求，引入NPU协作的优先度应降低，避免为了使用NPU而增加系统复杂度。

若团队缺乏异构程序调试经验，建议先完善可观测性，确保能够分设备查看计算耗时、拷贝耗时和排队耗时，再决定是否推进协同优化。

十、总结

本文围绕GPU与NPU协同推理这一关键问题，构建了一套分层评测方法。评测对象不是某个品牌或单一产品，而是“同一模型与量化条件下，不同计算资源组合的推理表现”。评测维度覆盖功能正确性、性能、资源调度效率、稳定性、可观测性、易用性和成本收益比。测试方法强调基线建立、变量控制、分层验证和结果边界分析。

从通用评测角度看，NPU协作是否具备价值，取决于模型结构、量化方式、调用模式、资源架构与业务场景的共同作用。单一性能数值不足以支撑选型决策，必须结合资源瓶颈定位、稳定性表现和开发维护成本进行综合判断。对于开发者与架构师而言，更重要的是建立一套可复用的异构推理评估流程，而不是追求某一项指标的绝对高低。