在输出大模型推理一体机的参数时,往往只注意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/token | 10 tokens/s |
| 50 ms/token | 20 tokens/s |
| 25 ms/token | 40 tokens/s |
| 10 ms/token | 100 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/LPDDR | CPU侧调度、数据准备、模型offload |
| PCIe带宽 | CPU-GPU/FPGA通信 | 多设备数据搬运 |
| FPGA板载内存带宽 | FPGA DDR/HBM | FPGA加速模块性能 |
对于 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的速度,等待的时长,都会有影响)

85

被折叠的 条评论
为什么被折叠?



