大模型算力指标与推理吞吐评测
大模型算力指标与推理吞吐评测
讨论大模型部署性能时，常同时出现 FLOPS（硬件算力）和 tokens/s（推理吞吐）两类数字，二者相关但不可混用。本文从 FLOPs / FLOPS 的概念与硬件意义、吞吐评测常用指标与测法、以及 纸面算力与实测速度为何对不上 三个维度做综述，面向选型、压测与横向对比前的口径统一，非厂商 benchmark 复现手册。
参考与延伸阅读：
- MLPerf Inference：https://mlcommons.org/en/inference-datacenter/
- vLLM 文档：https://docs.vllm.ai/
目录
- 1. FLOPs 与 FLOPS：先分清两个词
- 2. 大模型里的 FLOPs 怎么理解
- 3. 硬件 FLOPS 的意义与局限
- 4. 同显存下能否只比 FLOPS
- 5. 推理吞吐的核心指标
- 6. Prefill 与 Decode 的分段测法
- 7. 单流与并发压测
- 8. 常用评测工具与报告规范
- 9. FLOPS 与 tokens/s 的关系
- 10. 小结
- 11. 参考与来源
1. FLOPs 与 FLOPS：先分清两个词
| 术语 | 全称 | 含义 | 典型单位 |
|---|---|---|---|
| FLOPs | Floating Point Operations | 完成一次计算所需的 浮点运算次数 | GFLOPs、TFLOPs（每次任务） |
| FLOPS | Floating Point Operations Per Second | 硬件每秒可执行的 浮点运算次数（算力） | TFLOPS、PFLOPS（每秒） |
1
2
3
FLOPs → 这次推理「要算多少」（工作量）
FLOPS → 这块芯片「每秒能算多少」（峰值马力）
粗算耗时 ≈ FLOPs ÷ 有效 FLOPS（实际还受访存、带宽、软件影响）
口语中二者常被混用；技术文档与横向对比时建议严格区分：s 小写多指次数，S 大写多指每秒。
2. 大模型里的 FLOPs 怎么理解
FLOPs 描述的是 计算复杂度，不是线上吞吐。对 Transformer 解码（生成 1 个新 token），粗算思路为：
1
总 FLOPs ≈ 各层 Attention FLOPs + 各层 FFN/MoE FLOPs + LM Head 等
矩阵乘 Y = X @ W 的常用近似：
1
FLOPs ≈ 2 × M × N × K
（X 为 M×K，W 为 K×N；一次乘加计 2 次浮点运算。）
2.1 稠密模型粗算（每 token、每层量级）
设 L 为层数，d 为 hidden size，d_ff 为 FFN 中间维，s 为当前序列长度：
| 模块 | 粗算 FLOPs（每 token 每层） |
|---|---|
| QKV 投影 + 输出投影 | ~8 × d² |
| Attention（与序列长度相关） | ~4 × s × d |
| FFN（SwiGLU 等） | ~12 × d × d_ff 或 ~24 × d²（当 d_ff≈4d） |
解码阶段常用经验式（极粗，仅作量级）：
1
FLOPs per token ≈ 2 × Active Params
2.2 MoE 模型的 FLOPs
MoE 的 FFN 只计算 被激活的专家：
1
FFN_FLOPs_MoE ≈ Top-K × 单个 Expert 的 FLOPs
例如 Qwen3-30B-A3B：总参数 ~30B，激活 ~3B——FLOPs 按 ~3B 估算，显存按 ~30B 规划。
3. 硬件 FLOPS 的意义与局限
硬件规格中的 TFLOPS / PFLOPS 指芯片在特定精度下的 理论峰值算力。
| 对硬件的意义 | 说明 |
|---|---|
| 算力天花板 | 标明矩阵乘等计算密集型任务的理论上限 |
| 训练 / 大 batch 参考 | 大 batch 训练更可能吃满算力 |
| 不是实际速度 | LLM 推理常见 5%～30% 的峰值利用率 |
1
2
FLOPS ≈ 发动机最大马力（纸面参数）
tokens/s ≈ 实际路况车速（还看带宽、软件、负载）
3.1 是否越高越好？
在同精度、同运算类型、且任务为算力瓶颈时，FLOPS 越高通常越好——但不能单独作为「谁更厉害」的依据：
| 因素 | 为何不能只看 FLOPS |
|---|---|
| 精度口径 | FP16、BF16、FP8、INT8 的峰值不可直接横比 |
| 显存带宽 | Decode 常是 带宽瓶颈，算力闲置 |
| 软件栈 | Kernel、框架是否针对硬件优化 |
| 负载类型 | Prefill / Decode、batch、MoE、长上下文瓶颈不同 |
| 功耗与散热 | 峰值能否持续，还是短时 boost |
4. 同显存下能否只比 FLOPS
不能。 同显存容量下，N 卡标称 FLOPS 高于昇腾，只说明纸面算力峰值可能更高，不等于大模型场景一定更快。
4.1 LLM 解码常卡在带宽而非 FLOPS
解码阶段需 反复读取权重；算力够用但权重读不过来时，FLOPS 再高也难以转化为更高 tokens/s。
同显存选型应一并看：
| 指标 | 意义 |
|---|---|
| 显存容量 | 能放多大模型、多长 KV Cache |
| 显存带宽 | 解码吞吐往往更敏感 |
| 目标精度下的有效算力 | INT8 / FP8 等是否成熟 |
| 框架适配 | vLLM、TensorRT-LLM、MindIE 等是否吃满硬件 |
| 同模型实测 | tokens/s、TTFT、P99 延迟 |
4.2 厂商数字口径
| 情况 | 说明 |
|---|---|
| N 卡 | 常标 Tensor Core 在 FP16 / BF16 / FP8 下的峰值 TFLOPS |
| 昇腾 | 除 FLOPS 外常标 INT8 TOPS 等，测试条件需对齐 |
| 跨厂商对比 | 精度、是否稀疏、单卡还是整机，须在同一口径下比较 |
更稳妥的结论：FLOPS 决定「算得多快」的上限；大模型很多场景先卡在「读得多快」和「软件吃不吃满」。
5. 推理吞吐的核心指标
「每秒输出多少 token」是最常被引用的吞吐指标，但规范评测通常会 成套上报：
| 指标 | 英文 | 含义 | 典型用途 |
|---|---|---|---|
| 输出吞吐 | Output tokens/s | 每秒生成的 新 token 数 | 最常引用的生成速度 |
| 首 token 延迟 | TTFT | 从发请求到收到第一个输出 token | 对话响应是否「跟手」 |
| 逐 token 延迟 | ITL | 相邻两个输出 token 的时间间隔 | 流式输出是否卡顿 |
| 端到端延迟 | E2E Latency | 整段回复完成总耗时 | 用户总等待时间 |
| 并发吞吐 | Aggregate tokens/s | 多路请求下的总 output tokens/s | 线上服务能力 |
关系概览：
1
2
3
Prefill（处理 prompt） → 首 token（TTFT）
Decode（逐 token 生成） → output tokens/s、ITL
E2E ≈ TTFT + (输出 token 数 - 1) × 平均 ITL
未注明口径的 tokens/s 往往指 Decode 阶段的 output tokens/s；对比时务必确认。
6. Prefill 与 Decode 的分段测法
| 阶段 | 在做什么 | 速度特征 | 常用指标 |
|---|---|---|---|
| Prefill | 一次性处理整段 prompt，构建 KV Cache | 与 输入长度 强相关 | input tokens/s、TTFT |
| Decode | 每次生成 1 个新 token | 与 输出长度 相关 | output tokens/s、ITL |
同一张卡：
- 短 prompt、长输出 → 整体表现更接近 decode 吞吐
- 超长 prompt、短输出 → TTFT / prefill 更关键
规范测评应 分阶段报告，或 固定 input / output 长度 后一并说明。
6.1 单流 Decode 吞吐（常见测法）
1
2
3
4
5
6
7
1. 预热（warmup）若干次
2. 固定 prompt，请求生成 N 个新 token（如 512）
3. 记录首 token 时间 → TTFT
4. 记录首 token 至末 token 时间 T_decode
5. output tokens/s ≈ (N - 1) / T_decode
（具体分子是否含首 token 须在报告中写明）
6. 多次运行取 median / mean
7. 单流与并发压测
单请求 tokens/s 高，不代表线上服务能力强。
| 场景 | 测法 | 关注点 |
|---|---|---|
| 单流 | batch=1，一路生成 | Decode tokens/s、TTFT |
| 固定并发 | 同时 C 个请求 | Aggregate tokens/s、mean / P99 TTFT |
| 持续压测 | 请求不断涌入至平台期 | 饱和吞吐、排队情况 |
并发报法示例：
1
2
3
并发 32，input=1024，output=128
→ aggregate output tokens/s = 8500
→ mean TTFT = 120 ms，P99 TTFT = 280 ms
Aggregate tokens/s = 所有并发流产生的 token 总数 ÷ 墙钟时间，通常 高于 单流 tokens/s。
8. 常用评测工具与报告规范
| 工具 / 基准 | 说明 |
|---|---|
| vLLM benchmark | bench throughput / latency，服务化场景常用 |
| TensorRT-LLM benchmarks | 可分 prefill / decode 报告 |
| llama.cpp | 本地轻量测 prompt 与生成速度 |
| MLPerf Inference | 工业界标准化基准，条件严格 |
| 厂商推理套件 | 如 MindIE 等，需对齐版本与模型适配状态 |
8.1 报告建议写清的字段
1
2
3
4
5
6
7
8
9
10
11
12
模型：Qwen3-30B-A3B，W8A8
硬件：1× 某型号 GPU / NPU
框架：vLLM 0.x / MindIE 1.x
精度：INT8 / FP16
输入长度：1024 tokens（固定）
输出长度：128 tokens（固定）
Batch：1（单流） / 32（并发）
指标：
- TTFT：85 ms（mean）
- Decode：42 output tokens/s（单流）
- Aggregate：2100 output tokens/s（并发 32）
预热：10 次；正式：5 次取 median
缺少 input / output 长度、batch、精度、框架 时，数字难以横向比较。
8.2 常见误区
| 误区 | 实际情况 |
|---|---|
| 只比 tokens/s，不看 TTFT | 首字慢，体验仍差 |
| 极短输出（如 16 token）标榜高吞吐 | 多测到启动开销，不代表长回复 |
| 单流很高、并发很差 | 线上应看 aggregate 与 P99 |
| Prefill 与 Decode 混报 | 应分阶段或固定 IO 长度 |
| 不同框架直接比 | continuous batching、kernel 差异大 |
9. FLOPS 与 tokens/s 的关系
1
2
理论 tokens/s 上限 ≈ 有效 FLOPS ÷ 每 token 所需 FLOPs
实际 tokens/s << 理论值
瓶颈常见于：
| 瓶颈 | 说明 |
|---|---|
| 显存带宽 | Decode 反复读权重 |
| KV Cache | 上下文越长，读写越多 |
| 框架开销 | Python、调度、通信 |
| MoE 路由 | 专家分布与 All-to-All 通信 |
实用对照：
| 关心什么 | 优先看什么 |
|---|---|
| 算力天花板 | 硬件 FLOPS（同精度口径） |
| 能不能放下模型 | 显存容量 |
| 对话跟不跟手 | TTFT、ITL |
| 线上能扛多少量 | 并发 aggregate tokens/s、P99 |
| 真实表现 | 同模型同条件下的实测，而非纸面 FLOPS |
与 MoE 选型口诀一致：显存看 Total，速度看 Active（FLOPs），能力介于两者之间；最终仍以实测 tokens/s 为准。
10. 小结
| 要点 | 结论 |
|---|---|
| FLOPs vs FLOPS | 前者是运算 次数（工作量），后者是每秒 算力（峰值） |
| 硬件 FLOPS | 理论算力上限；越高在同精度下通常越好，但不是唯一指标 |
| 同显存比卡 | 不能只看 FLOPS；带宽、框架、实测 tokens/s 更关键 |
| 吞吐核心指标 | output tokens/s、TTFT、ITL；并发看 aggregate 与 P99 |
| 测法要点 | 固定模型 / 精度 / IO 长度 / batch；预热；分 Prefill 与 Decode |
| FLOPS 与实测 | 理论上限由 FLOPS 与每 token FLOPs 决定；实际远低于峰值，以压测为准 |
11. 参考与来源
- MLCommons, MLPerf Inference：https://mlcommons.org/en/inference-datacenter/
- vLLM Documentation：https://docs.vllm.ai/
- NVIDIA TensorRT-LLM：https://github.com/NVIDIA/TensorRT-LLM/tree/main/benchmarks