AI芯片吞吐压测与性能调优实战 - 第1节

一、压测基础：什么是AI芯片吞吐压测？

大家好，我是老K。做AI芯片验证这行十几年了，今天咱们聊聊吞吐压测。

吞吐压测，说白了就是——把芯片往死里怼，看它到底能扛多少活。不是跑一个模型看它能不能跑通，而是让它满负荷运转，测出它的极限在哪里。

我刚开始做这行时，有个项目流片回来，单模型跑得飞快，大家都很高兴。结果一上多路视频流，芯片直接卡死。为什么？因为没做吞吐压测。从那以后，我把吞吐压测列入了必做清单。

1.1 吞吐压测 vs 功能验证

这两个概念容易混淆。我简单区分一下：

  • 功能验证：测芯片能不能做这件事。比如ResNet-50能不能跑出正确结果。
  • 吞吐压测：测芯片能做多快、能做多少。比如1秒钟能跑多少张图。

你想想看，功能验证过了，不代表芯片就能用。客户要的是“每秒处理1000张图”，你只能跑500张，那功能再正确也没用。

1.2 压测的核心逻辑

吞吐压测的底层逻辑其实很简单：

吞吐量 = 单位时间内完成的任务数

但实际落地时，要考虑的因素就多了。我画了张图，帮你理清思路：

AI芯片吞吐压测 TOPS 算力天花板 FPS 实际处理速度 Batch Size 并行粒度 性能基线 达标/不达标 瓶颈定位 计算/带宽/调度 极限摸底 最大负载能力 三个指标互相影响，压测时要综合考虑

这张图我画了好几次才满意。它表达了一个核心观点：TOPS、FPS、Batch Size 三者是联动的，不能只看一个。

二、核心指标详解

2.1 TOPS——算力的“马力”

TOPS（Tera Operations Per Second），每秒万亿次操作。这个指标衡量的是芯片的理论峰值算力。

举个例子：一块芯片标称 100 TOPS，意思是它理论上每秒能执行 100 万亿次运算。但注意，这是理论值。

⚠️ 避坑提醒： 我曾经见过一个项目，芯片标称 200 TOPS，实际跑模型只能用到 60 TOPS。为什么？因为 TOPS 通常是在特定精度（如 INT8）和特定运算（如乘加）下测的，实际模型有各种 overhead。

TOPS 的计算公式：

TOPS = 频率(GHz) × MAC数量 × 2 × 精度系数

精度系数：
  FP32 → 1
  FP16 → 2  
  INT8 → 4

嗯，这里要注意：不同精度下的 TOPS 差别很大。厂商宣传时通常会挑最大的那个数。

2.2 FPS——用户真正关心的

FPS（Frames Per Second），每秒处理帧数。这是用户能直接感知的指标。

我习惯把 FPS 叫做“落地指标”。TOPS 再高，FPS 上不去，客户就不买账。

FPS 受很多因素影响：

  • 模型大小（参数量）
  • 输入分辨率
  • 数据搬运开销
  • 后处理时间
💡 个人经验： 我做过一个对比测试，同样的芯片跑 YOLOv5s 能到 120 FPS，跑 YOLOv5x 只有 30 FPS。模型大了 4 倍，FPS 掉了 4 倍。所以压测时一定要指定模型。

2.3 Batch Size——并行度的调节阀

Batch Size 就是一次喂给芯片多少张图一起算。

为什么要有 Batch Size？因为芯片的算力是并行的。一张图可能用不满所有计算单元，多张图一起算就能提高利用率。

但 Batch Size 不是越大越好：

Batch Size 优点 缺点
1 延迟最低 算力利用率低
4~8 平衡点 需要调优
32+ 吞吐量高 延迟大，内存压力大

我曾经踩过一个坑：把 Batch Size 设到 64，结果芯片内存爆了，直接报 OOM。后来发现芯片的片上内存只有 8MB，根本装不下那么大 batch 的中间结果。

三、压测目标设定

3.1 目标从哪里来？

压测目标不是拍脑袋定的。我一般从三个维度来定：

  1. 产品需求：客户要求 1080P 视频流至少 30 FPS
  2. 竞品对标：友商芯片跑同样的模型能到 80 FPS
  3. 理论极限：根据 TOPS 和模型计算量估算上限
目标设定公式：
压测目标 = min(产品需求 × 1.2, 理论极限 × 0.8)

为什么要留余量？因为芯片量产后有工艺偏差，温度高了性能会掉。我见过太多项目卡在 99% 的达标线上，最后量产时温度一上来就跪了。

3.2 不同场景的目标差异

不同应用场景，关注点不一样：

  • 云端推理：追求高吞吐，Batch Size 可以大，延迟要求宽松
  • 边缘计算：平衡吞吐和延迟，Batch Size 通常 1~4
  • 自动驾驶：低延迟优先，FPS 要求高，但 Batch Size 只能为 1

我做过一个车载项目，客户要求端到端延迟小于 30ms。我们压测时发现，Batch Size 设为 2 时吞吐量翻倍，但延迟到了 45ms。最后只能牺牲吞吐保延迟。

3.3 压测的“黄金三角”

我个人总结了一个“黄金三角”原则：

压测三要素：
1. 固定模型（比如 ResNet-50, INT8）
2. 固定输入（比如 224x224 RGB）
3. 固定精度（比如 INT8）

然后只变 Batch Size，看 FPS 变化曲线

为什么要固定？因为变量太多你根本不知道瓶颈在哪。我见过有人压测时换了模型又换精度，最后数据一团糟，根本没法分析。

💡 我的习惯： 先固定所有参数，跑一个 baseline。然后每次只改一个变量，记录数据。这样定位问题最快。

四、实战：一次完整的压测流程

最后，我分享一个实际压测的流程，你感受一下：

  1. 准备阶段：选好模型（ResNet-50），确定精度（INT8），写好压测脚本
  2. 基线测试：Batch Size=1，跑 1000 轮，记录 FPS 和延迟
  3. 梯度加压：Batch Size 从 1, 2, 4, 8, 16 逐步增加，每个配置跑 500 轮
  4. 数据记录：记录每个配置下的 FPS、延迟、芯片温度、功耗
  5. 瓶颈分析：看 FPS 是否线性增长？如果不是，瓶颈在哪？

我记得有一次压测，Batch Size 从 1 到 4 时 FPS 几乎线性增长，但到 8 时增长明显变缓。一查，发现是 DDR 带宽打满了。这就是典型的“带宽瓶颈”。

⚠️ 重要提醒： 压测时一定要监控芯片温度。温度过高会导致降频，FPS 会断崖式下跌。我建议压测超过 5 分钟时，每 10 秒记录一次温度。

好了，这一章就到这里。吞吐压测的核心就是搞清楚 TOPS、FPS、Batch Size 这三个指标的关系，然后根据实际场景设定合理的目标。下一章我们会聊具体的压测工具和脚本怎么写。

可可精品资料库
← 上一章 📖 返回目录 下一章 →