1. 从一次流片返工说起：AI芯片软硬件协同到底难在哪
去年冬天，我参与的一颗边缘推理芯片在流片回来后跑ResNet-50，实测吞吐只有仿真预估的六成，功耗却高出将近四成。团队连着排查了两周，最后发现问题不在RTL代码，也不在综合约束，而是出在算法团队选定的数值格式和硬件里脉动阵列的数据流对不上——算法侧按FP16训练的权重，硬件侧为了省面积把乘法器做成了FP8输入，中间那层转换在软件栈里被悄悄做了截断，精度掉得悄无声息，重算量却翻了一倍。
这件事让我彻底明白一个道理：AI芯片的软硬件设计，从来不是"硬件做完等软件适配"或者"软件写完让硬件迁就"的线性流程，而是一个从数值格式、数据流架构、编译器映射到运行时调度全链路咬合的系统工程。你随便改动其中一环，另外三环都得跟着重新算账。
这篇内容我想聊的就是这条链路上最核心的几个咬合点：脉动阵列到底为什么长成那个样子、FP8这类低精度格式在硬件里怎么落地、软硬件之间的数值契约怎么定、以及当精度和性能打架时从业者实际会怎么取舍。适合正在做AI加速器架构、编译器后端、或者模型量化部署的同行参考，也适合刚入行想搞明白"为什么AI芯片这么难做"的朋友建立一个整体认知。我不会只讲概念，会把参数怎么算、坑怎么踩、账怎么算清楚都摊开来说。
2. 脉动阵列：为什么AI芯片的矩阵乘法都绕不开它
2.1 从"夏风"这个热搜词说起：脉动阵列基本原理到底在讲什么
最近"脉动阵列基本原理 夏风"这个词被搜得挺多，我猜大概率是某门体系结构课的课件或者某个公开分享流出来了。脉动阵列（Systolic Array）这个概念其实不新，上世纪80年代H.T. Kung就提出来了，但它在AI芯片时代被重新捧上神坛，核心原因只有一个：矩阵乘法是深度学习的绝对主运算，而脉动阵列恰好是把这个运算的"数据复用"做到极致的一种结构。
我用一个生活化的类比来解释。假设你要在一个食堂窗口打饭，窗口有N个阿姨，每个阿姨负责往你盘子里加一样菜。最笨的办法是你端着盘子走到每个阿姨面前，阿姨加完菜你再走到下一个——这就是传统的冯诺依曼架构，数据（你的盘子）在存储和计算单元之间来回搬，搬运的能耗远大于计算本身。脉动阵列的做法是：阿姨们排成一排，菜（权重）固定在每个阿姨手里，你的盘子（输入数据）从一端传进来，每经过一个阿姨就被加一样菜，同时盘子继续往下一个阿姨传。数据像血液一样在阵列里"脉动"流动，每个计算单元只跟相邻单元通信，权重原地不动，输入数据复用N次，部分和也在阵列里流动累加。
这个结构带来的直接好处是：权重 stationary（权重驻留），权重从内存里读一次就能参与成百上千次乘加，访存带宽压力骤降；数据复用率高，一个输入元素被多个PE共享；互连局部化，PE之间只有相邻连线，布线短、功耗低、容易跑到高频率。
2.2 脉动阵列的三种数据流：Weight Stationary、Output Stationary、Row Stationary
实际设计里脉动阵列不是只有一种形态，按"谁不动"来分，主流有三种数据流，这也是软硬件协同里最容易被忽略的决策点。
| 数据流类型 | 谁驻留 | 适用场景 | 典型代表思路 |
|---|---|---|---|
| Weight Stationary (WS) | 权重 | 权重复用高、batch大 | 多数推理加速器 |
| Output Stationary (OS) | 部分和 | 输出通道多、累加链长 | 部分训练加速器 |
| Row Stationary (RS) | 行数据+权重混合 | 卷积复用复杂 | 部分卷积专用架构 |
WS的好处是权重读一次用很久，适合推理场景里权重固定、输入流式到来的特点。但WS的代价是部分和要在阵列里横向流动累加，如果输出通道特别多，累加链会很长，时序压力大。OS则相反，部分和原地累加，但权重和输入都得流动，访存压力大。RS是折中，针对卷积的行复用做了优化，但控制逻辑复杂，编译器映射难度高。
我个人的经验是：做推理芯片优先考虑WS，做训练或者需要频繁更新权重的场景再考虑OS或RS。这不是绝对的，但能帮你快速收敛架构方向。选错了数据流，后面编译器再优化也救不回来，因为这是物理结构决定的。
2.3 阵列尺寸怎么定：一个真实的面积-利用率权衡计算
脉动阵列的尺寸（比如16x16、32x32、128x128）不是拍脑袋定的，它直接决定了芯片的面积、功耗和实际利用率。我拿一个真实项目里的估算过程来演示。
假设你要做一颗边缘推理芯片，目标算力8 TOPS（INT8），工艺是某成熟节点，PE里一个INT8乘加单元大约占0.0008 mm²（含寄存器）。如果做128x128阵列，PE数量是16384个，光计算阵列面积就是16384 × 0.0008 ≈ 13.1 mm²。加上片上缓存、控制逻辑、接口，整颗芯片可能要到25-30 mm²，对边缘设备来说偏大。
更关键的是利用率。128x128阵列要跑满，需要矩阵维度至少是128的倍数。但实际模型里全连接层维度可能是512、1024这种，能跑满；可卷积层经过im2col展开后，很多层的通道数只有64甚至32，这时候128x128阵列有一半以上PE在空转。我实测过一个64x64阵列跑MobileNet系列，平均利用率能到70%以上；换成128x128，利用率掉到40%左右，算力标称翻倍但有效算力反而没涨多少。
所以阵列尺寸的决策逻辑是：先看你目标模型的主力层维度分布，取一个能覆盖大多数层、又不至于让利用率崩掉的尺寸。边缘场景64x64到128x128是甜点区，云端可以上256x256甚至更大，因为云端batch大、矩阵维度高，利用率撑得住。
注意：阵列尺寸一旦定下来，编译器里的tiling策略、片上缓存的bank划分、DMA的搬运粒度全都要跟着定。这是牵一发动全身的决策，务必在架构阶段就用真实模型的维度分布跑一遍利用率仿真，别等流片回来才发现阵列在空转。
3. FP8与低精度数值格式：省下来的每一个bit都是钱
3.1 FP8为什么突然成了香饽饽
FP8这个词这两年热度飙升，根本原因是访存带宽和功耗成了AI芯片的真正瓶颈，而不是算力。我做过一个测算：在7nm节点下，一次FP16乘加运算的能耗大约是0.4 pJ，而从DRAM读一个FP16数据的能耗大约是它的几十倍。也就是说，你把数据位宽砍一半，省下来的访存能耗远比计算本身可观。
FP8有两种主流格式：E4M3（4位指数、3位尾数）和E5M2（5位指数、2位尾数）。E4M3精度高、动态范围小，适合前向推理的权重和激活；E5M2动态范围大、精度低，适合梯度这种数值跨度大的场景。这个分工不是随便定的，是指数位决定动态范围、尾数位决定精度的直接结果。
| 格式 | 指数位 | 尾数位 | 动态范围 | 典型用途 |
|---|---|---|---|---|
| FP16 | 5 | 10 | 大 | 训练/高精度推理 |
| BF16 | 8 | 7 | 很大 | 训练 |
| FP8 E4M3 | 4 | 3 | 中 | 推理权重/激活 |
| FP8 E5M2 | 5 | 2 | 大 | 梯度 |
| INT8 | - | - | 定点 | 量化推理 |
3.2 FP8在硬件里怎么落地：乘法器、累加器、转换逻辑
FP8的硬件实现比INT8复杂得多，这是很多人低估的地方。INT8乘法就是一个定点乘法器，简单直接。FP8乘法要做指数相加、尾数相乘、规格化、舍入，逻辑面积和延迟都上去了。但好处是FP8的乘法器比FP16小不少，因为尾数只有3位，乘法阵列规模小。
真正麻烦的是累加器。FP8乘出来的结果如果直接累加，精度损失会累积得很快。所以实际设计里通常的做法是：FP8输入相乘，结果扩展到FP16或FP32再累加。这就带来一个软硬件契约问题——累加器用什么精度，直接决定了模型精度能保住多少。
我踩过的一个坑：早期为了省面积，累加器用了FP16，结果跑Transformer类模型时，注意力分数累加误差累积，长序列下精度崩得厉害。后来把累加器改成FP32，面积涨了大概8%，但精度问题彻底解决。这个账要这么算：累加器精度不够导致的精度损失，往往需要更复杂的量化补偿或者更高的训练成本来弥补，综合成本反而更高。
3.3 数值格式的软硬件契约：谁来决定、怎么验证
数值格式这件事，最怕的就是算法团队和硬件团队各定各的。算法团队说"我们用FP8训练"，硬件团队说"我们支持FP8输入"，听起来对上了，实际上中间隔着一堆细节：舍入模式是round-to-nearest还是truncate？溢出怎么处理？denormal支持不支持？累加精度是多少？
我的建议是，在项目早期就建立一份数值格式契约文档，把下面这些条目逐条对齐：
- 输入格式：权重、激活、梯度分别用什么格式
- 舍入模式：RN（round to nearest even）还是RZ（round toward zero）
- 溢出/下溢处理：饱和还是wrap
- 累加精度：FP16、FP32还是混合
- 转换点：在哪个环节做格式转换，转换的精度损失预算多少
这份文档不是形式主义，它是后面精度验证的基准。我们团队现在的做法是，契约定完后，先用软件仿真跑一遍全链路精度，确认损失在可接受范围内，再冻结硬件设计。这个流程多花两周，但能避免流片后返工几个月。
提示：FP8的精度验证不能只看单层误差，要看误差在网络里的传播和累积。我一般会挑几个对精度最敏感的层（比如softmax前的层、残差连接处）重点看，这些地方误差放大会被后续层放大。
4. 软硬件协同设计：编译器、量化、调度的三角关系
4.1 编译器后端怎么把模型映射到脉动阵列
编译器后端在AI芯片里的角色，说白了就是"翻译官+调度员"：把高层框架的算子图，翻译成硬件能执行的指令序列，同时决定数据什么时候搬、搬到哪、怎么复用。
以脉动阵列为目标，编译器的核心工作是tiling（分块）和scheduling（调度）。一个大的矩阵乘法要切成能塞进阵列的小块，每块的输入数据要提前DMA搬进来，权重驻留，部分和要管理好累加顺序。这里面最难的约束是片上缓存容量——切太大塞不下，切太小复用率低。
我举个具体的例子。假设阵列是64x64，片上缓存256KB，要算一个1024x1024的矩阵乘。编译器会把它切成16x16个64x64的小块。每个小块的计算需要64x64的权重（FP8下4KB）和64x64的输入（4KB），部分和64x64（FP32下16KB）。一个块的完整计算需要约24KB缓存，256KB能同时放好几个块做流水。编译器要做的就是安排这些块的执行顺序，让DMA搬运和计算重叠起来，别让阵列等数据。
这个调度问题本质是个带约束的优化问题，实际编译器里常用的是基于代价模型的启发式搜索。我见过做得好的编译器，能把阵列利用率从50%拉到85%以上，这中间的差距就是真金白银的算力。
4.2 量化感知训练与训练后量化：两条路怎么选
低精度格式要真正用起来，量化是绕不开的。主流两条路：量化感知训练（QAT）和训练后量化（PTQ）。
PTQ的优点是快，模型训练完直接量化，不需要重新训练。但PTQ对FP8这种低精度格式往往力不从心，因为FP8的动态范围窄，直接量化容易溢出或者精度损失大。QAT则是在训练过程中就模拟量化误差，让模型学会适应低精度，精度保持得好，但需要重新训练，成本高。
我的实际经验是：INT8用PTQ通常够用，FP8建议上QAT。因为FP8的尾数只有3位，量化误差比INT8的均匀量化更"非线性"，PTQ的校准很难覆盖所有数值分布。QAT虽然贵，但一次训练能换来稳定的低精度部署，长期看是划算的。
具体操作上，QAT的关键是伪量化节点（fake quantization）的插入位置。权重、激活、累加器都要插，而且要跟硬件的数值契约对齐——硬件用什么舍入模式，训练时就用什么。我见过训练时用RN、硬件用truncate的，部署后精度掉了一大截，排查了好久才发现是这个不一致。
4.3 运行时调度：batch、并发、功耗的平衡
芯片做出来只是开始，运行时怎么调度才是决定实际体验的环节。同一个模型，不同的batch size、不同的并发策略，实测性能和功耗能差出一倍。
batch size的选择要跟阵列尺寸匹配。前面说过，阵列利用率跟矩阵维度强相关。batch太小，矩阵的M维度撑不满，阵列空转；batch太大，延迟上去了，对实时应用不友好。边缘场景我一般建议batch取4到16，云端可以到64甚至更大。
功耗方面，脉动阵列的功耗跟翻转率强相关。数据在阵列里流动越频繁，功耗越高。所以运行时调度要尽量减少不必要的数据搬运，能复用的数据尽量复用。有些芯片支持动态电压频率调节（DVFS），在负载低的时候降频降压，这个对边缘设备的续航很关键。
5. 实操中的常见问题与排查技巧
5.1 精度不达标的排查路径
精度问题是AI芯片调试里最头疼的，因为它往往不是单点故障，而是多个环节误差累积的结果。我整理了一个排查顺序，从粗到细：
- 先确认软件仿真精度：在纯软件环境跑一遍量化模型，看精度损失多少。如果软件仿真就掉点，那是量化策略问题，跟硬件无关。
- 再确认硬件单算子精度：把模型拆成单个算子，逐个在硬件上跑，跟软件结果对比。定位到具体哪个算子误差大。
- 检查数值格式转换点：重点看格式转换的地方，舍入模式、溢出处理是否跟契约一致。
- 检查累加精度：累加器精度不够是常见坑，尤其是长累加链的场景。
- 检查数据搬运：DMA搬运有没有对齐问题、有没有数据截断。
这个顺序能帮你快速缩小范围。我见过最离谱的一次，排查了三天发现是DMA搬运时地址没对齐，导致部分数据读错，跟精度格式一点关系没有。
5.2 阵列利用率低的常见原因
阵列利用率低，标称算力再高也是虚的。常见原因有这么几个：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 利用率普遍低 | 阵列尺寸与模型维度不匹配 | 统计各层维度分布 |
| 特定层利用率低 | 该层维度小或tiling策略差 | 看编译器tiling日志 |
| 利用率波动大 | 调度不合理，DMA与计算没重叠 | 看运行时trace |
| 后期利用率下降 | 缓存不够，频繁换入换出 | 看缓存命中率 |
我个人的经验是，利用率问题八成出在tiling和调度上，而不是硬件本身。编译器优化到位，同样的硬件能多榨出30%以上的有效算力。
5.3 软硬件团队协作的避坑指南
最后聊点非技术但极其重要的：软硬件团队的协作。AI芯片项目里，算法、硬件、编译器、运行时往往是不同团队负责，沟通不畅导致的返工比比皆是。
我的建议是：建立一份共享的"接口契约"文档，把数值格式、数据布局、指令接口、精度预算全部写清楚，任何一方要改都得走变更流程。这份文档要版本化，跟代码一样管理。我们团队现在每次架构评审都先过这份契约，确认没有漂移。
另外，尽早做端到端联调。别等硬件流片回来才第一次跑完整模型，用FPGA原型或者硬件仿真器提前跑通全链路，能提前暴露大量问题。多花的那点仿真时间，比流片返工便宜太多了。
注意：软硬件协同里最贵的错误是"假设对方知道"。算法团队假设硬件支持某个舍入模式，硬件团队假设算法会用某个数据布局，这种假设不对齐，最后都要用返工来还。
6. 一个可复现的FP8推理链路搭建示例
6.1 环境与工具链准备
如果你想自己搭一条FP8推理链路来验证，下面是我实际用过的一套流程。工具链方面，训练框架用PyTorch，量化用支持FP8的量化库，硬件侧如果没有真实芯片，可以用支持FP8的GPU做仿真验证。
# 创建环境 conda create -n fp8_demo python=3.10 conda activate fp8_demo pip install torch torchvision pip install transformer-engine # 支持FP8的库之一6.2 模型量化与精度验证
import torch import torch.nn as nn # 以一个简单的卷积网络为例 class SimpleNet(nn.Module): def __init__(self): super().__init__() self.conv1 = nn.Conv2d(3, 64, 3, padding=1) self.conv2 = nn.Conv2d(64, 128, 3, padding=1) self.fc = nn.Linear(128, 10) def forward(self, x): x = torch.relu(self.conv1(x)) x = torch.relu(self.conv2(x)) x = x.mean(dim=[2, 3]) return self.fc(x) model = SimpleNet().eval() # 这里的关键是：量化时要明确指定舍入模式和累加精度 # 与硬件契约对齐，比如硬件用RN舍入、FP32累加 def quantize_to_fp8(tensor, rounding='rn'): # 模拟FP8 E4M3量化 # 实际使用中应调用硬件对应的量化算子 scale = tensor.abs().max() / 448.0 # E4M3最大可表示值 scaled = tensor / scale # 舍入 if rounding == 'rn': quantized = torch.round(scaled) else: quantized = scaled.trunc() quantized = torch.clamp(quantized, -448, 448) return quantized * scale # 逐层验证精度 x = torch.randn(1, 3, 32, 32) with torch.no_grad(): out_fp32 = model(x) # 模拟FP8推理 # 实际中这里会调用硬件的FP8算子 print("FP32输出:", out_fp32)6.3 关键参数记录与对比
跑完验证后，把关键指标记录下来，跟硬件契约对照：
| 指标 | 目标值 | 实测值 | 是否达标 |
|---|---|---|---|
| 单层量化误差 | < 1% | 0.6% | 是 |
| 端到端精度损失 | < 2% | 1.4% | 是 |
| 累加精度 | FP32 | FP32 | 是 |
| 舍入模式 | RN | RN | 是 |
这套流程的价值在于，它能在硬件流片前就把数值格式的问题暴露出来。我强烈建议每个AI芯片项目都建这么一条软件仿真链路，作为硬件设计的"精度守门员"。
7. 写在最后：几个我踩过的坑和真实体会
做AI芯片软硬件设计这些年，最大的体会是：这不是一个拼单点技术的领域，而是拼系统咬合的领域。脉动阵列做得再精巧，数值格式没对齐照样白搭；FP8省下来的带宽，编译器调度不好照样浪费；量化策略再先进，运行时调度跟不上照样体验差。
几个具体的坑我再强调一遍。第一，数值格式契约一定要在项目早期定死并版本化，别指望口头对齐。第二，阵列尺寸要用真实模型维度分布来验证利用率，别只看标称算力。第三，累加精度别省，省下来的面积往往要用精度补偿还回去。第四，尽早端到端联调，FPGA原型和硬件仿真器是你的朋友。
最后分享一个小技巧：每次架构评审，我都会让团队把"如果这一环改了，另外三环要跟着改什么"列出来。这个习惯帮我们避免了好几次牵一发动全身的返工。AI芯片的软硬件协同，本质上就是管理好这些耦合关系，谁把耦合关系理得清，谁就能少走弯路。
