从符号到物理：AI算法与计算硬件的底层协同性能优化实践

我这一年里反复被同一个问题击中同样的深度学习模型在 GPU 上跑得飞快换到端侧 NPU 上延迟翻了几倍而这两块硬件明明算力差距没那么大。刚开始我以为是框架问题后来深入到指令集、访存、算子和数据排布才意识到自己一直活在某层符号系统里——算法是一堆漂亮的数学符号硬件是一个充满时序、带宽、热功耗的物理世界夹在两者之间的是编译器、算子库、微架构和半导体工艺的层层翻译。这个翻译过程做得干净性能就是跃迁做得粗糙再好的算法也像给超跑装了限速器。我想了很久怎么描述这种感受后来找到一句话从符号到物理是 AI 算法与计算硬件在同一场底层协同跃迁中的双向奔赴。这篇文章就想把我在这条链路里的观察、踩坑和一些实操经验整理出来既写给算法工程师也写给做硬件和做编译器的人——大家平时各忙各的但最精彩的性能故事恰恰发生在两边的交界处。1. 符号世界与物理现实之间的翻译税算法复杂度不等于实际速度1.1 复杂度分析漏掉的东西常数项、访存和并行度读大学的时候算法课讲排序分析完冒泡排序是 O(n²)、快排是 O(n log n)所有人就默认快排更好。毕业做了几年 AI 算法我发现自己被这种符号化思维骗过好多次。一个 O(n) 的算子可能因为它的内存访问模式极为散乱在 CPU 上被缓存未命中拖成乌龟一个 O(n²) 的简单双循环反而因为纯顺序访问和硬件预取完美契合跑出远超理论预期的效果。这种 符号复杂度 与 物理表现 的偏差我后来称之为翻译税。算法表达的是计算逻辑的整洁符号系统但硬件执行的是物理过程数据要从 DRAM 搬到缓存寄存器要按周期吞吐流水线要应对分支跳转带来的冲刷缓存要配合空间局部性和时间局部性。时间复杂度只刻画了计算量的增长趋势却完全不感知这些物理机制。一个很典型的例子就是排序算法在真实硬件上的表现阈值。对小数组插入排序经常赢过快排因为它的内存访问完全顺序化分支预测命中率高CPU 的乱序执行和缓存预取让它如鱼得水。等到数组大到缓存装不下快排的分治访问模式才会体现优势。符号上更快的算法在物理世界里不一定更快这就是翻译税的正反两面。对于 AI 深度学习算法来说翻译税更明显。一个卷积算子理论上 FLOPs 可以算得清清楚楚但硬件执行时最贵的往往不是乘法器干活的那几个周期而是数据在多层存储之间搬来搬去的等待。我遇到过一款自研 NPU峰值算力标得不错一跑大通道数的卷积就露馅——因为片上缓存太小每次都要去外部 DDR 反复搬运中间结果算力利用率直接掉到两成以下。后来优化数据排布策略把输入切块做得更贴合缓存容量利用率才拉到六成。这整个过程中算法的数学形式一点没变变的只是数据在物理存储里怎么摆。1.2 从指令集到微架构软件感受不到的硬件性格算法工程师眼中的同一个算子在不同硬件上对应的是完全不同的指令序列和电路行为。拿矩阵乘法来说在 x86 CPU 上编译器会把它自动向量化用 AVX 指令集的 FMA 指令一个时钟周期完成多次乘加在 GPU 上它可能被映射成大量线程的 SIMT 执行每个线程算输出矩阵的一个 tile而在 NPU 上它可能根本没被翻译成指令而是被配置成脉动阵列里一层层流过的数据。同一个数学符号三种物理实现中间隔着指令集架构、微架构设计和编译器后端的层层关卡。指令集是软硬件之间一份相对稳定的契约但契约之下的微架构实现各有性格。同样是支持 SIMD 指令的 CPU不同厂商对乱序窗口大小、访存队列深度、缓存延迟的取舍完全不同导致同一段向量化代码在不同计算硬件上的表现可能差出两三倍。我做过一个算子专项优化在 Intel 平台上用数据对齐和显式预取把延迟砍掉 40%同样的代码丢到某 ARM 平台上几乎没变化——对方编译器里那些指令的调度策略差异太大我的优化假设在它的物理结构上根本不成立。这种时候我就深刻体会到算法符号世界里的优化如果不对准硬件的物理结构就是自嗨。后来我养成了一个习惯每接触一个新的计算平台先看它的微架构白皮书搞清楚缓存层级、带宽数字、指令吞吐再回去看自己的代码和算子实现。符号到物理中间这层架构语义才是翻译的关键语法。2. 让一段矩阵乘法真正烧起来从数学公式到片上物理过程2.1 卷积、全连接的本质是乘加运算的物理搬运深度学习中绝大多数计算拆到底都是乘加。一个全连接层就是矩阵乘法一个卷积层本质是更复杂的乘加叠加。做算法的人通常关注 FLOPs——每秒浮点运算次数但实际跑起来决定延迟的往往是带宽、并行度和数据复用。这里的核心概念是计算强度arithmetic intensity也就是单位字节数据搬运对应多少次浮点运算。一个成功的算子实现要做的就是无限逼近目标硬件的 roofline 模型所允许的性能上限。Roofline 这个模型我在做算子优化时才真正理解它的价值把算法本身的计算强度画出来再把硬件能提供的算力带宽比画出来两条线的交点就是再多优化也不会超过这个数的物理天花板。举个例子一个 1024×1024 的矩阵乘输出矩阵里每个元素要做 1024 次乘加总计算量约 20 亿次浮点运算。这个数在符号层面很简单。但物理层面呢如果初版实现把三个矩阵全部丢在 DRAM 里每个输出元素都要三次读入、一次写回那么访存量暴涨到几十 GB。就算 DRAM 带宽再高也会被访存拖死。优化的思路通常是用分块tiling把矩阵切成适合 L2 缓存的小块让数据在片上缓存里反复复用把对 DRAM 的访问压到最低。这一步不改任何数学逻辑只改数据的物理流动性能就能翻好几倍。2.2 访存墙和片上存储AI 计算的真正瓶颈所有 AI 芯片设计者都在面对两面墙访存墙和功耗墙。所谓访存墙就是算力增长的斜率远高于外部存储带宽增长的斜率。芯片内部乘法器堆得再多数据喂不进来算力也只能闲置。功耗墙则更直接高性能计算意味着高功耗而功耗最终以热量形式散发物理上散不走就限制频率和电压。所以我做算子性能分析的时候第一件事永远是看 profiling性能分析结果里的访存指标cache miss rate 高不高、HBM/AXI 带宽占用到没到顶。很多时候算法本身没有任何问题纯粹是数据排布或者算子分块策略没适配硬件的存储层级导致计算单元在空等数据。这就像战场上的炮兵炮弹数据在后方仓库DRAM前方炮管计算单元再快传送带总线不够粗就白搭。硬件工程师在 RTL 层面解决的问题其实就是怎么让这条传送带更宽、更短、更智能。一位做 FPGA 加速的朋友跟我聊过他用 Verilog 写卷积加速器时最费心的是设计片上 SRAM 的双缓冲当前一块数据在计算阵列里烧的时候下一块数据同步从 DRAM 预取到片上计算和搬运重叠起来流水线才转得动。这个双缓冲的思路反过来也影响了我做算法部署时的选择——想办法让数据生产者与数据消费者重叠而不是一板一眼地同步等待。符号世界的并行在物理世界就是流水线重叠和资源复用。3. 算法为物理让路的三个典型动作量化、剪枝、稀疏化落地指南3.1 量化用离散的位宽装连续的精度我之前跑模型优化项目最喜欢也最怕的就是量化。喜欢是因为收益立竿见影怕是因为精度掉起来毫无规律。量化的思路很简单也很物理把 FP32 的 32 位浮点表示压成 INT8、INT4甚至更低。位宽降了乘法器面积变小功耗降低访存带宽占用减半计算单元吞吐翻倍。这一点可以从芯片物理层面理解一个 32 位浮点乘法器和 8 位整数乘法器在版图上面积差将近一个量级算同样的乘加功耗和延迟自然差出一截。所以用 INT8 推理延迟减半不是算法变聪明了是物理世界变得更省力了。但量化在算法层面对的难题是浮点数的连续区间要映射到一个有限离散符号集里。这需要校准——统计每一层激活值的分布选择合理的缩放因子scale和零点zero point。我踩过的最典型的坑是激活值里存在少量极大异常值导致量化区间被拉得很宽绝大多数数据的有效精度反而被压缩模型精度暴跌。后来我学会了用 KL 散度或者百分比截断法做校准先跑一批校准数据统计激活值的直方图寻找一个能让量化前后信息损失最小的阈值把异常值直接裁掉。这个思路属于典型的算法向物理让步精度不是越高越好而是分布合理才最好。另一个实操心得是训练时量化QAT和训练后量化PTQ的选择。PTQ 快但对权重分布敏感尤其是小模型经常在校准后精度动辄掉几个点QAT 能把量化误差作为伪噪声带进训练过程模型自己学会抵抗精度恢复效果好得多。过程慢一些但务求稳定。做部署的同事应该都有印象量化方案选错模型上线后出现偶发的个别样本输出异常排查起来最痛苦。3.2 剪枝与结构化约束想让硬件真正加速就得先遵其规矩很多人以为把模型里多余的权重置零就是剪枝其实那只是符号层面的剪枝。真正要让硬件提速必须考虑物理层面的数据结构。非结构化剪枝自由度最高——权重矩阵里任意位置都可以置零精度保持得好。但这种稀疏模式落到硬件上计算公式变成要么用一个稀疏矩阵的索引结构去访存权重结果非连续访问要么干脆跳过零值但每一个跳过的分支判断都要在计算流水线里加判断带来额外开销。我在 GPU 上试过非结构化稀疏精度确实保住了但推理速度不升反降就是因为稀疏索引的访存模式完全打破了原来的缓存友好顺序。硬件需要的是结构化剪枝。比如 Channel Pruning通道剪枝或者 Block Pruning块剪枝把整块通道或规则块一次性剪掉。这样稀疏后的矩阵仍然是规整的形状访存连续计算单元无需处理不规则跳转。代价是精度损失略大需要用重训练来恢复。这里有个算法搜索的空间剪哪些通道、每层剪多少、哪些层适合剪厚一点本质是一个组合优化问题。这类搜索适合用启发式算法去做。我在组件选择时常用贪心算法做基线每层按权重范数排序优先剪掉范数小的通道简单有效。想再精细一些可以用模拟退火或者粒子群算法在层间剪枝比例的空间里搜索——把精度作为目标函数把模型大小/延迟作为约束这类符号层面的搜索算法在解决问题时输出结果却要落在物理世界的真实延迟上。这又是符号与物理的一次握手。3.3 稀疏化的硬件支持现状为什么大家都说稀疏却很少有人真正用起来稀疏计算被说了很多年但我在实际工程里真正把稀疏化的收益吃满的机会屈指可数。原因很现实通用硬件对稀疏的支持一直很有限。NVIDIA 从 Ampere 架构开始支持 2:4 结构化稀疏也就是每四个权重里至少两个为零硬件可以直接跳过一半的计算。这是个聪明的折中因为 2:4 模式是规则的硬件可以用固定逻辑加速不需要复杂的索引查找。但要想达到这个模式训练时就需要特殊的稀疏掩码约束实际操作门槛并不低。NPU 这边更麻烦。有的芯片厂商在硬件里做了稀疏感知的存储格式和计算单元但配套编译器通常不太成熟有的厂商直接不开放硬件稀疏接口软件上硬塞稀疏权重反而更慢。所以我给团队的指导意见一直是如果硬件链路模型转换、算子库、编译器明确支持结构化稀疏就认真考虑如果支持度含糊宁可在量化和模型裁剪上多花功夫也别把时间耗在花哨的稀疏实现上。4. 硬件开始向算法站队Transformer与大模型时代的新计算范式4.1 为什么 Transformer 逼着所有人重新思考硬件我早年做 CNN 模型部署时各类芯片的优化套路已经比较成熟卷积网络算子结构相对规整为它定制加速器的硬件方案很多。但 Transformer 出现之后情况变了——自注意力机制的基础矩阵乘法、Softmax、LayerNorm 这类算子对访存极度敏感。以自注意力里的 QKV 计算和 Softmax 为例计算 FLOPs 未必很高但它们要读取一个序列长度的中间状态访存开销大。序列一长中间矩阵就大带宽瓶颈立刻显现。因此出现了 FlashAttention 这类算子它通过分块tiling把注意力计算过程重新组织让中间结果尽量留在片上 SRAM避免频繁与 HBM 交互。这不是改变模型的数学定义而是在算法实现层面向物理硬件特性靠拢——把算子的算术强度提高了访存压力骤降。我曾经在一张大模型推理任务上直接换上 FlashAttention 的实现不做任何模型改动decode 阶段的并发提升了一大截。那一刻我非常确信在符号层面看起来完全等价的算子实现因为物理访存模式不同工程表现可以天差地别。Transformer 把整个生态都拉到了访存至上的语境里这也解释了为什么新一代 AI 芯片把片上 SRAM 容量和大带宽当成关键卖点。4.2 GPU、NPU、端侧芯片不同物理结构决定了算法能怎么跑硬件世界远不是算力越高就越强这么简单。GPU 的物理结构是大规模 SIMT 线程并行依赖缓存与大量线程切换来掩盖访存延迟适合训练阶段的超大矩阵吞吐NPU 则更多是专用数据流架构数据在脉动阵列里流水式地流动计算效率高、能效比好适合推理阶段相对固定的模型结构CPU 偏重控制流与通用性在传统服务端做预处理、后处理和轻量模型推理时依旧不可替代。这也是算法工程师在做部署选型时常陷入的困惑为什么同样的主干网络在一款算力只有 GPU 十分之一的 NPU 上推理速度和 GPU 差距远没有算力差距那么大原因就在于 NPU 的物理数据流与算子结构更契合把算力用在了刀刃上。反过来如果你把模型里的算子设计成某个 NPU 完全不适配的形式比如大量动态 shape、复杂数据依赖的循环那再高的硬件峰值也就是画饼。大模型和 AI Agent 的兴起又提出了一个 GPU 之外的问题实时性和功耗。AI Agent 这类应用里模型要高频地推理、决策可能跑在云端也可能跑在端侧边缘设备上对单次推理延迟和能效比极度敏感。这倒逼硬件从极致算力堆料转向算法-硬件联合设计。比如有些端侧芯片直接为 Transformer 的算子定制计算单元在保持较低功耗的同时完成实时推理任务让 Agent 的响应延迟降到可用的水平。算法形态在变硬件就在变双方在底层互相塑造。5. 一线协同开发手记从 RTL 到算子库到应用的踩坑与心得5.1 我经历的一次算子性能优化全过程具体说说一个我印象深刻的 case。某个视觉模型里有一个 3×3 卷积算子在端侧 NPU 上性能特别差profile 显示 NPU 的利用率只有 15%。我第一反应是算子分块参数没调好于是尝试各种 tiling 尺寸没什么用。后来把问题抛给芯片厂商的 FAE他们让我们检查数据排布。我这才意识到模型从 PyTorch 导出 ONNX 再转 NPU 模型时默认的 tensor 布局可能被转换成了 NCHW而这款 NPU 的原生数据排布是 NHWC。NHWC 下通道维在最后卷积计算时同一个位置的输入通道数据在内存里是连续的向量化加载和乘法累加都高效NCHW 下则需要频繁做通道维的跨步访问访存效率暴跌。然后我重新设计了数据排布转换加了一个自定义算子把网络输入直接转成 NHWC避免中间反复排列整个瓶颈就消失了。这件事教给我的不是 NHWC 比 NCHW 好而是每个硬件都有自己偏爱的物理存储姿势算法工程师不能只把数据当成符号张量来操作还得知道它在 DRAM 里的字节流动路线。所有 AI 框架的 tensor 抽象、自动微分本质都是符号系统的便利而性能永远只发生在物理层。5.2 编译器、算子库与 RTL 语言Verilog的协作分工搞深度学习系统的人都知道算法要落到硬件中间要过三层关卡编译器把高级算子翻译成指令或配置流算子库针对热点算子做手工调优而 RTL硬件描述语言比如 Verilog则把这些语义落实到真正的门电路之上。这三层不是各自割裂的。我现在做系统设计经常要同时跟三拨人打交道写 Verilog 的同事告诉我某个计算单元一次能搬多少数据、多长时间能出一组结果编译器团队告诉我某个融合算子在指令调度时能不能覆盖访存的空闲周期我自己则要从算法层判断ROI 到底该花在写一个融合 kernel 上还是换个算子结构更划算。这里我要给做算法的新人一个建议不要觉得 Verilog 或者汇编这些东西离你很远。你要做的不是会写 RTL而是能读懂硬件行为模型知道你在算法层写出的那个均匀规整的循环在硬件流水线里是什么样。我见过太多算法工程师在框架层堆各种小技巧反而忽略了最该看的算子实现细节。反过来只懂硬件不懂算法也不行因为你不知道哪些精度损失可以接受、哪些权重结构可以被压缩就无法为硬件留出优化空间。5.3 建立符号-物理协同思维的几个具体实践文章最后我把自己这几年用下来比较有效的几个实操习惯列出来供大家参考拿到一个新的推理平台或者新硬件先选一个典型算子做 roofline 分析。把算子的计算强度画出来再对照硬件手册里的峰值算力和带宽看瓶颈在 compute-bound 还是 memory-bound。别急着调参先找准物理瓶颈。做量化或者剪枝之前一定先准备一个有代表性的校准集和评估集。我吃过亏训练集上评估量化模型精度看着还行一到真实业务数据上就崩。数据分布不一样符号层面的统计规律就失效了。在用手工优化算子之前先查一遍编译器自动优化后的性能基线。很多情况下编译器已经做得很好了手工优化半天收益不大真正值得手工优化的往往是编译器不认识、但硬件很适合的融合模式。模型结构设计阶段就要考虑部署硬件的算子支持范围。比如某个非线性激活函数在目标 NPU 上实现代价大那在算法设计时换成硬件友好的近似形式比后期裁剪更省事。这是把协同前置到算法设计的第一步。过滤器类专业部署项目多留出性能调优时间。我曾经在项目排期里只估了模型训练和转换的时间结果卡在算子适配和性能调优上多花了两周。从符号到物理真正决定上线节奏的往往就是这段翻译过程啊。踩过几次坑之后我越来越觉得从符号到物理不只是这篇文章的标题更是做 AI 底层技术的人的一种必备视角。算法决定的是事情在数学上能做硬件决定的是事情在物理上能不能跑得快、跑得省、跑得稳。两者之间那一整层编译器、算子库、微架构和 RTL 实现才是把符号世界的优雅翻译成物理世界效率的关键。希望这篇文章能给正在这个交界处挣扎的同行一点参考别让那些看不见的翻译税把你绕晕。