理解大模型推理一体机的性能参数

在输出大模型推理一体机的参数时,往往只注意Decode 和 TTFT,实际上并不够。

需要关注更多的参数:

TTFT(Time To First Token)
Prefill吞吐
Decode TPOT (Time Per Output Token) 
单并发 tokens/s
多并发 tokens/s
batch size
input length
output length
KV Cache占用
显存/内存带宽利用率

下面我们详细的理解一下,这些参数的含义:

1. TTFT

含义

TTFT = Time To First Token

中文可以叫:

首 token 延迟 / 首字延迟 / 首包时延

它表示:

从用户提交请求,到系统返回第一个输出 token 的时间

它包含哪些时间?

通常包括:

请求排队时间
输入文本 tokenizer 时间
Prefill 计算时间
KV Cache 构建时间
第一个 token 的采样时间
服务端返回流式输出的时间

可以理解成:

TTFT ≈ 排队时间 + 输入处理时间 + Prefill时间 + 第一个Decode时间 + 网络返回时间

为什么重要?

TTFT 决定用户的第一感觉。

例如:

TTFT用户感觉
< 1 秒反应很快
1~3 秒可以接受
3~5 秒有等待感
> 8 秒明显觉得卡

对于一体机宣传,可以写:

TTFT @ 1K input tokens
TTFT @ 4K input tokens

不要只写一个 TTFT,必须说明输入长度。


TTFT 受什么影响?

主要受这些因素影响:

因素影响
input length 越长TTFT 越高
batch size 越大单请求 TTFT 可能增加
Prefill 算力越强TTFT 越低
tokenizer 慢TTFT 增加
请求排队TTFT 增加
RAG 检索如果算进去,TTFT 会增加
是否 warm-up冷启动 TTFT 会明显变高

注意:TTFT实际上并不简单的是Prefill的处理速度。

2. Prefill 吞吐

含义

Prefill 吞吐指:

模型处理输入 tokens 的速度

通常单位是:

tokens/s

计算方式大致是:

Prefill吞吐 = 输入 tokens 数量 / Prefill耗时

如果是 batch prefill,则是:

Prefill吞吐 = 所有请求输入 tokens 总数 / Prefill总耗时

举例

假设输入长度是 4096 tokens,Prefill 用了 2 秒:

Prefill吞吐 = 4096 / 2 = 2048 tokens/s

它反映什么?

Prefill 吞吐主要反映:

一体机处理长 prompt 的能力
RAG 长上下文处理能力
文档问答输入阶段能力
首 token 延迟能力

Prefill 吞吐越高,长 prompt 场景下 TTFT 越低。


它主要受什么影响?

因素影响
GPU 算力很重要
Tensor Core 利用率很重要
input length越长计算越多
batch size合理增大 batch 可提高吞吐
模型参数量参数越大越慢
精度FP16、BF16、FP8、INT8、INT4差异明显
attention 实现FlashAttention 等会影响性能

3. Decode TPOT

含义

TPOT = Time Per Output Token

中文可以叫:

每输出 token 延迟

它表示:

Decode 阶段生成每个 token 平均需要多长时间

单位通常是:

ms/token

举例

如果 TPOT = 50 ms/token,表示:

每 50 ms 生成 1 个 token

那么单用户输出速度约为:

1000 / 50 = 20 tokens/s

TPOT 和 tokens/s 的关系

单并发 tokens/s ≈ 1000 / TPOT(ms)

例如:

TPOT单并发速度
100 ms/token10 tokens/s
50 ms/token20 tokens/s
25 ms/token40 tokens/s
10 ms/token100 tokens/s

为什么 TPOT 重要?

TPOT 决定输出是否流畅。

TTFT 决定:

多久开始说话

TPOT 决定:

说话速度快不快

TPOT 主要受什么影响?

因素影响
显存带宽Decode 阶段很关键
KV Cache 长度上下文越长,读取越多
batch size增大 batch 可提高总吞吐,但单请求延迟可能变差
模型参数量越大越慢
量化精度INT4/INT8 可降低带宽压力
KV Cache 优化PagedAttention、KV压缩等有帮助
多并发调度调度策略会影响 TPOT

4. 单并发 tokens/s

含义

单并发 tokens/s 指:

只有一个用户请求时,模型每秒能输出多少 token

它主要反映:

单用户体验
交互流畅度
Decode速度

例如一体机单并发大约:

14 tokens/s

意思是一个用户聊天时,平均每秒输出约 14 个 token。


怎么理解 14 tokens/s?

14 tokens/s 大约对应:

TPOT ≈ 1000 / 14 ≈ 71 ms/token

这个速度:

场景体感
普通问答基本可接受
长答案输出稍慢但可以看
代码生成可能略慢
多人并发需要看总吞吐

注意

单并发 tokens/s 不等于系统最大能力。

因为单并发下:

GPU可能没有完全吃满
batch太小
显存带宽利用不充分

所以单并发看的是用户体验,多并发看的是系统吞吐。

5. 多并发 tokens/s

含义

多并发 tokens/s 指:

多个请求同时生成时,系统整体每秒输出多少 token

通常是 aggregate throughput,也就是总吞吐。

例如:

4并发总输出 28 tokens/s

表示:

4个用户合计每秒输出28个token

平均每个用户:

28 / 4 = 7 tokens/s

多并发 tokens/s 反映什么?

它反映:

一体机服务多个用户的能力
推理引擎调度能力
batching能力
显存/内存带宽利用率

单并发和多并发的关系

理想情况下:

4并发总吞吐 > 单并发吞吐

因为多个请求可以组成 batch,提高硬件利用率。

但单用户速度可能下降:

单并发:14 tokens/s
4并发总吞吐:28 tokens/s
平均每用户:7 tokens/s

这说明系统总吞吐翻倍,但单用户速度下降一半。

这是正常现象。

6. Batch size

含义

batch size 指:

模型一次前向计算同时处理多少个请求或 token 单元

在 LLM 推理里,batch size 有几种口径:

类型含义
Prefill batch同时处理多少个输入请求
Decode batch同时给多少个请求生成下一个 token
Token batch一次计算中总 token 数
Continuous batching动态把不同请求拼在一起执行

举例

如果有 4 个用户同时请求,每个都在 decode:

decode batch size = 4

每一步 decode,模型同时为 4 个请求各生成一个 token。


Batch size 的影响

batch size优点缺点
单请求延迟低硬件利用率低
总吞吐高单请求延迟可能增加
太大吞吐高但排队严重TTFT/TPOT 变差

所以 batch size 是:

吞吐和延迟之间的平衡参数。


一体机应该怎么测?

建议测试:

batch/concurrency = 1, 2, 4, 8, 16

看:

单用户速度如何下降
系统总吞吐如何上升
TTFT是否变差
显存是否够

7. Input length

含义

input length 指:

输入 prompt 的 token 数量

例如:

512 tokens
1K tokens
2K tokens
4K tokens
8K tokens

它影响什么?

input length 主要影响:

Prefill时间
TTFT
KV Cache初始大小
显存占用
长上下文能力

输入越长:

Prefill计算越多
TTFT越高
KV Cache越大
显存占用越多

为什么宣传时要写 input length?

因为:

TTFT @ 512 tokens

和:

TTFT @ 8K tokens

完全不是一个难度。

所以性能报告必须写清楚:

TTFT P95 ≤ 3s @ input length = 1K

否则 TTFT 没有意义。

8. Output length

含义

output length 指:

模型生成的 token 数量

例如:

128 tokens
512 tokens
1024 tokens

它影响什么?

output length 主要影响:

总响应时间
Decode总耗时
KV Cache继续增长
用户等待时间

总时间大致可以理解为:

总响应时间 ≈ TTFT + TPOT × output length

例如:

TTFT = 2s
TPOT = 70ms/token
output length = 500 tokens

那么:

总响应时间 ≈ 2 + 0.07 × 500 = 37s

Output length 和 TTFT 的关系

严格说:

TTFT 与 output length 关系不大

TTFT主要由输入长度和 prefill 决定。

但是 output length 会显著影响:

总完成时间
平均吞吐
用户完整等待时间

9. KV Cache 占用

KV Cache 是什么?

Transformer 生成 token 时,每一层 attention 都需要历史 token 的 Key 和 Value。

为了避免每生成一个新 token 都重新计算历史 token,系统会缓存历史 token 的 K/V,这就是:

KV Cache

为什么 KV Cache 很重要?

因为输出越长、上下文越长、并发越多,KV Cache 越大。

KV Cache 占用大,会导致:

显存被占满
最大并发降低
最大上下文变短
Decode访问带宽增加
TPOT变差

KV Cache 大小和什么有关?

主要和这些有关:

层数
hidden size
KV heads数量
head dimension
上下文长度
batch size / 并发数
数据精度

对于常规 Transformer,可以粗略理解为:

KV Cache ∝ 层数 × 序列长度 × batch size × KV维度 × 精度字节数

举例理解

假设:

上下文越长:KV Cache越大
并发越多:KV Cache越大
精度越高:KV Cache越大

例如:

情况KV Cache
1并发,1K上下文较小
8并发,8K上下文很大
FP16 KV Cache
INT8/FP8 KV Cache

对一体机的意义

一体机要说明:

支持多大上下文
支持多少并发
显存能容纳多少 KV Cache
KV Cache是否量化
KV Cache管理方式

例如:

支持 8 并发 @ 8K context

这背后就要算 KV Cache 是否装得下。

10. 显存/内存带宽利用率

含义

显存/内存带宽利用率表示:

实际数据搬运速度占硬件理论带宽的比例

例如某 GPU 理论显存带宽:

1000 GB/s

推理时实际读写:

600 GB/s

那么带宽利用率:

60%

为什么重要?

因为 LLM Decode 很多时候是 memory-bound。

如果带宽利用率已经很高,例如:

80%~90%

那说明系统可能已经被显存带宽卡住。

这时候再增加计算 TOPS 不一定有明显提升。


显存带宽和内存带宽区别

类型位置影响
显存带宽GPU HBM/GDDR模型权重、KV Cache、激活读取
内存带宽CPU DDR/LPDDRCPU侧调度、数据准备、模型offload
PCIe带宽CPU-GPU/FPGA通信多设备数据搬运
FPGA板载内存带宽FPGA DDR/HBMFPGA加速模块性能

对于 CPU + GPU + FPGA 一体机,还要看:

CPU内存带宽
GPU显存带宽
FPGA DDR/HBM带宽
PCIe带宽
多设备之间的数据搬运开销

带宽利用率怎么用于判断瓶颈?

现象说明
GPU算力利用率低,显存带宽高memory-bound
GPU算力利用率高,显存带宽不高compute-bound
GPU和显存都不高调度、通信、batch太小或实现效率问题
PCIe带宽高CPU/GPU/FPGA之间搬运可能是瓶颈

10:所有指标间的关系

TTFT 主要看 Prefill
TPOT 主要看 Decode
Prefill吞吐看输入处理能力
Decode tokens/s 看输出能力
batch size 看并发调度能力
input length 影响 TTFT 和 KV Cache
output length 影响总响应时间
KV Cache 影响显存容量和Decode速度
带宽利用率判断是不是memory-bound

11:硬件配置的写法

推理一体机的硬件配置如何写?

性能针对的硬件配置,应该如何写?

模型:DeepSeek V3.1 / Qwen 3.6 27B
精度:FP16 / BF16 / FP8 / INT8 / INT4
硬件:CPU / GPU / FPGA / 内存 / 显存
推理框架:vLLM / TensorRT-LLM / 自研引擎
输入长度:1K / 4K / 8K
输出长度:128 / 512
并发数:1 / 4 / 8
是否流式输出:是
是否warm-up:是

然后给出指标:

TTFT P50 / P95
Prefill 吞吐 tokens/s
Decode TPOT ms/token
单并发 tokens/s
多并发总 tokens/s
显存占用
KV Cache 占用
显存带宽利用率
GPU利用率

如果要简单解释上面的指标:

指标主要回答的问题
TTFT用户多久看到第一个字?
Prefill吞吐输入 prompt 处理得快不快?
Decode TPOT每生成一个 token 要多久?
单并发 tokens/s一个用户聊天时输出速度多快?
多并发 tokens/s多个用户同时用时总吞吐多少?
batch size一次同时处理多少请求?
input length输入上下文有多长?
output length输出内容有多长?
KV Cache占用长上下文和并发会吃多少显存?
显存/内存带宽利用率当前是不是被数据搬运卡住?

12:有效并发数

另外,对于支持并发数,实际上有一些讲究。

支持 8 并发 @ input 1K / output 512 流式输出
TTFT P95 ≤ 3s
TPOT P95 ≤ 150ms/token
单用户平均输出速度 ≥ 6 tokens/s

如果要讲支持的并发数,实际上和 output 是相关的。因为output会占用资源,如果output太长,肯定会影响并发时得到的效率(比如:Decode的速度,等待的时长,都会有影响)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值