# 通用计算核心与张量核心能力评测方法详解

一、评测概述：为什么这两类核心需要被”评测”而不是被”背诵”

关于通用计算核心与张量核心的区别，网上流传的说法大多停留在一句话结论：”前者算标量，后者算矩阵，后者更快。”这个结论方向没错，但对工程决策几乎没有指导价值。原因有三：

第一，硬件代际差异远大于核心类型差异。新一代加速卡上的通用计算核心，其吞吐能力可能超过上一代专用核心；跨代际、跨数据类型比较两类核心，得出的结论几乎没有意义。

第二，两类核心的”快”是有条件成立的。张量核心的优势建立在矩阵形状、数据布局、数据类型与访存路径都匹配的前提下；条件不满足时，其利用率会迅速衰减，实际表现可能不如通用计算核心串行执行。

第三，真实业务负载是混合的。一个典型的推理或训练步骤里，同时存在逐元素运算、归约、归一化、激活函数、注意力掩码、通信与访存，通用计算核心与张量核心必须协同工作。评测的目标不是判定”谁更强”，而是刻画”在何种条件下、以何种代价、谁承担哪一部分工作”。

因此本文把这件事当作一次架构能力评测来组织：先明确评测对象与评测问题，再设计维度、搭建基线、控制变量，最后给出条件化的解读结论。

本文适合谁读：负责模型部署与推理优化的开发者、需要为训练或推理集群选型的架构师、负责容量规划与成本评估的技术负责人、以及需要在既有算力资源上挖掘性能余量的运维与算法工程团队。

需要事先声明的一点：本文不提供任何绝对化排名或具体数值结论。所有性能判断都必须由读者在自己的负载、自己的环境、自己的数据规模上实测得到；本文提供的是评测框架与解读方法。

二、评测对象说明：把两类核心放回架构层级里看

要评测清楚两类核心，必须先还原它们在硬件中的层级关系。以某代数据中心级加速卡为例，其架构可以概括为三层：

第一层：加速卡（整卡）。整卡由上百个流式多处理器单元（下文简称 SM 单元）构成。整卡的并行能力是 SM 数量的近似线性函数，但能否兑现为实际吞吐，取决于 SM 的占用率、显存带宽以及任务提交方式。

第二层：SM 单元。这是硬件调度的核心单元，内部被划分为若干个相互独立的处理分区（子单元）。每个分区内部既有通用计算核心，也有张量核心。以某代架构为例，单个分区的计算核心配置大致如下（数量用于说明比例结构，不代表所有架构）：

核心类型	单个处理分区典型配置	主要面向的数据类型	典型承担的工作
通用计算核心 A 组	16 个	FP32	常规浮点运算、逐元素运算、部分归约
通用计算核心 B 组	16 个	INT32 / 通用整数与地址运算	索引计算、掩码、整数分支密集逻辑
通用计算核心 C 组	8 个	FP64	科学计算、需要双精度精度的场景
张量核心	1 个	FP16 / BF16 / TF32 类混合精度、INT8 等	矩阵乘加、卷积、注意力中的乘加主干

同一分区还配有：线程束调度单元（负责指令级调度与延迟隐藏）、访存单元（负责数据加载与结果写回）、特殊函数单元（负责三角函数、指数、平方根等非线性运算），以及寄存器文件、一级缓存与共享内存等片内高速存储。

这个层级关系给出了本次评测的第一条重要结论：通用计算核心与张量核心不是竞争关系，而是同一条流水线上下游的分工关系。张量核心只能高效处理成块的乘加运算，它的输入需要由通用计算核心完成预处理（布局变换、缩放、掩码生成），它的输出也需要由通用计算核心完成后处理（激活、归一化、类型转换）。评测任何一方的性能，都必须把这条流水线的协作开销计入。

架构示意图（文字化表达）

加速卡
└── SM 单元 ×N
    ├── 处理分区 ×4
    │   ├── 通用计算核心组（FP32 / INT32 / FP64）
    │   ├── 张量核心 ×1        ← 矩阵乘加专用
    │   ├── 线程束调度单元
    │   ├── 访存单元 LDST
    │   └── 特殊函数单元 SFU
    ├── 寄存器文件
    ├── 一级缓存 / 共享内存
    └── 与全局显存、片间互联的连接路径

三、评测目标：本文要回答的六个问题

为避免指标堆砌，本次评测先把问题收敛为六条，每条对应一类可观测现象：

1. 分工边界在哪里：在什么算子类型、什么矩阵尺寸下，计算时间主要由张量核心决定，什么情况下由通用计算核心或访存路径决定。
2. 专用核心的实际收益是多少：在同等条件下，走张量核心路径相比纯通用计算核心路径，可获得多少倍的计算时间缩减；该倍率如何随形状、数据类型、批大小变化。
3. 数据类型与精度的取舍：混合精度在带来吞吐提升的同时，对数值精度、收敛行为、结果一致性带来什么影响。
4. 利用率与占用率问题：张量核心”存在”不等于”被用满”，如何测量其实际利用率并定位瓶颈。
5. 稀疏加速的适用条件：结构化稀疏在理论上可将有效算力提升到稠密情况的两倍，但需要满足哪些权重与激活条件，实际业务能否兑现。
6. 端到端收益的真实性：单算子加速能否传导到业务级吞吐与延迟，是否被访存、通信或框架调度开销吃掉。

四、评测维度设计

评测维度	可观测指标（均为定性/相对量，需自测）	验证方式	解读要点
功能完整性	是否支持所需数据类型组合；是否覆盖目标算子	逐项算子功能验证	不被支持的精度组合会导致路径回退到通用核心
计算有效性	计算时间占端到端时间的比例；峰值算力的达成率	微基准 + 性能剖析	达成率长期偏低说明形状或布局不匹配
性能表现	吞吐、时延分布、加速比	固定形状与批大小的多次重复测量	需区分计算受限与访存受限
数值准确性	与高精度参考结果的偏差、收敛曲线差异	参考实现对比、固定随机种子复跑	精度权衡必须落到业务指标上判断
稳定性	长时运行下的性能漂移、异常输入下的行为	长时间连续负载、边界输入注入	关注点是从冷启动到稳态的收敛过程
资源效率	显存占用、缓存命中率、带宽利用率	剖析工具与监控指标	三类资源常呈此消彼长关系
易用性与兼容性	框架版本适配、算子回退行为、编译选项复杂度	环境矩阵验证	回退是静默发生还是可观测，影响很大
可观测性	是否能看到两类核心的占用与瓶颈定位信息	剖析输出核对	无法观测就无法优化
成本结构	单位吞吐的资源占用、闲置率、弹性伸缩适配	资源账单与利用率统计口径核算	专用核心利用率不足会直接推高单位成本

五、评测环境与前提

硬件与驱动前提：在同一台物理机、同一张加速卡、同一驱动与运行时版本下完成全部对比；关闭可能引入频率波动的省电策略，或明确记录其开启状态。

软件栈前提：深度学习框架版本、算子库版本、编译与图优化选项需完全固定。这一项经常被忽视，但算子选择策略的版本差异足以改变结论。

负载前提：矩阵形状、数据类型、批大小、序列长度、卷积核尺寸必须作为显式变量列出，禁止用”默认配置”笼统描述。

评测边界：本文讨论的评测仅覆盖单卡计算路径的表现刻画，不涉及多卡通信优化、集群调度与存储 I/O 的联合调优；后者需要独立的评测设计。

六、评测方法：从微基准到端到端的四层验证

第一层：建立功能基线。 用最小规模的矩阵乘加验证两类核心路径均可用、结果正确，作为后续对比的信任基础。

第二层：微基准扫参。 这是本次评测的核心手段。对同一组乘加问题，分别在通用计算核心路径与张量核心路径下测量，并沿三个方向扫描：

• 矩阵尺寸扫描：从小到大覆盖，寻找加速比由负转正并趋于稳定的临界尺寸。小矩阵下张量核心往往无法体现优势，因为启动开销与访存占比过高。
• 数据类型扫描：逐类型对比，观察不同精度组合下的相对表现。
• 批大小扫描：观察批大小增加时张量核心利用率的饱和点。

示意性测试框架伪代码（不含任何特定厂商接口）：

问题集合 = [ (M,N,K) 的笛卡尔组合，M=N=K 从小到大幅递增 ]
精度集合 = [ 双精度, 单精度, 混合精度A, 半精度, 低比特定点 ]
对每个 (形状, 精度, 执行路径) 组合:
    预热若干轮，剔除首次编译与缓存冷启动影响
    重复测量 K 轮，记录每轮耗时
    取中位数与分位数，计算相对基线路径的加速比
    同时采集: 计算时间占比 / 访存时间占比 / 专用核心利用率 / 显存占用
输出: 加速比随形状与精度变化的曲线，标注临界尺寸与饱和点

第三层：瓶颈归因。 对每个测试点，判断其属于哪一类受限：

• 若专用核心利用率低而访存带宽接近饱和，说明是访存受限，此时提高专用核心规格不会带来提升，应转向数据布局、算子融合或提升复用率。
• 若专用核心利用率高且计算时间占主导，说明是计算受限，这是专用核心收益最大的区间。
• 若通用计算核心占比高（大量逐元素与归约算子），说明存在算子碎片化问题，融合是关键优化方向。

第四层：端到端验证。 取一个真实模型的完整前向（推理）或一个训练迭代，对比开启与关闭专用核心路径的端到端吞吐与时延分布。此层结论优先级最高，因为微基准收益常被框架调度与访存开销抵消。

辅助验证：稀疏路径。 按”每四个权重中置两个为零并压缩存储”的结构化稀疏形式改造权重后，重复第二至第四层测试。需注意：稀疏加速的前提是稀疏度达到规则化要求且模型精度损失可接受；不满足条件时，压缩与解压的额外开销可能使净收益为负。

七、结果解读：哪些现象可以支撑什么判断

观察到的现象	可支撑的判断	判断的适用边界
大矩阵、计算受限场景下专用路径加速比显著大于 1，且利用率随尺寸上升而饱和	该场景应优先走专用核心路径	仅适用于同形状同精度；改变形状需重新测量
加速比在小尺寸下小于 1	小尺寸任务应保留在通用核心路径	阈值随代际与软件栈变化，不可跨环境套用
专用核心利用率高但端到端吞吐提升有限	瓶颈在流水线其他环节（访存、通信、框架开销）	需结合剖析数据定位，不能仅凭单指标断言
混合精度下吞吐提升明显但业务指标下降	精度损失已影响结果有效性	必须落到业务可接受误差范围判断，不能只看单点误差
稀疏改造后收益远低于理论两倍	实际稀疏度或算子支持未达预期	需分别核查稀疏度分布与算子覆盖情况
长时运行中性能持续下滑	存在资源碎片、缓存抖动或热降频等稳态问题	需要更长时间的稳定性观察才能归因

核心解读原则是：任何单项指标的改善都不构成结论，必须回答”改善了多少、在什么条件下、代价是什么”。

八、适用场景分析

场景	重点关注	说明
大模型推理	计算效率、显存占用、时延分位数	需权衡批大小与首字延迟；访存常成为解码阶段瓶颈
模型训练	混合精度稳定性、数值收敛、扩展效率	精度切换需完整收敛验证，不能只看单步耗时
科学计算与仿真	双精度能力、结果一致性	专用矩阵核心覆盖有限，部分负载仍需通用双精度核心
中小批量在线服务	临界尺寸、资源利用率	单请求矩阵偏小，专用核心可能难以打满，需评估批处理策略
数据预处理与特征工程	通用整数与访存能力	以逐元素、归约、索引运算为主，专用核心参与度低
通用云上弹性业务	单位吞吐成本、弹性伸缩适配	建议按利用率而非按峰值规格评估，可参考百度智能云等平台提供的规格与监控指标口径做核算

九、风险与限制

• 样本偏差：只测少数几种形状，容易得出片面结论。形状空间的覆盖度直接决定结论的可推广性。
• 静默回退：数据类型或算子不被支持时，运行时可能自动回退到通用核心路径而不报错，导致”配置了却没生效”。
• 环境耦合：驱动、运行时、算子库任一版本变化都可能改变结论，评测报告必须记录完整版本组合。
• 测量方法误差：只测端到端墙钟时间会掩盖计算与访存的分工；缺少剖析数据时不应做归因判断。
• 长期不确定性：热降频、显存碎片、并发争抢等因素在短时间测试中难以显现。
• 成本口径风险：以峰值算力折算单位成本会系统性高估专用核心的价值，应以实际达成的吞吐折算。

十、选型与使用建议

1. 先明确负载的算子构成，再谈核心选型。若负载以逐元素与归约为主，提升通用核心规格与访存效率比增加专用核心更有意义。
2. 用临界尺寸指导批处理策略。测得的临界尺寸应写进服务配置文档，作为批大小下限的依据。
3. 把混合精度当成需要验证的变更，而非默认开启项。建立”精度切换前必须完成业务指标对比”的流程约束。
4. 建立可持续复用的评测基线。每次驱动或框架升级后重跑同一套微基准，形成趋势数据，避免每次问题都从零开始。
5. 以利用率而非规格做容量规划。在云上环境尤其应结合监控告警能力观察实际利用率，据此调整规格与实例数量。
6. 对稀疏优化保持审慎预期。先做小规模可行性验证，再决定是否投入改造。

十一、总结

通用计算核心与张量核心的区别，本质是”通用标量/向量并行执行单元”与”专用矩阵乘加执行单元”在设计目标上的分野：前者数量多、覆盖面广，承担预处理、后处理、非线性运算与索引调度；后者数量少但单点吞吐集中，只在形状、精度与访存路径匹配时兑现优势。两者由线程束调度单元统一编排，共处同一 SM 单元内，是分工协作关系而非替代关系。

本次评测的方法要点可归纳为：以微基准扫描形状与精度、以剖析数据完成瓶颈归因、以端到端测试确认收益传导、以长时间观察验证稳态表现。结论的成立条件必须随结论一并记录——跨代际、跨软件栈、跨形状的加速比数字之间不可直接比较。对工程决策而言，更有价值的产出不是”哪类核心更强”的排名，而是一套可重复执行的评测基线与明确的适用边界。