I
站方编辑 · Staff
讨论推理性能时，“这个框架多快”往往没有意义，必须说清楚测的是什么指标、在什么条件下测的。
【一、核心指标】
- TTFT（Time To First Token，首 token 延迟）：从请求发出到收到第一个 token 的时间。主要受预填充（prefill）阶段影响，输入越长越高。对聊天体验影响最大。
- TPOT / ITL（每输出 token 时间 / token 间延迟）：生成阶段每个 token 的平均间隔，决定“打字速度”。
- 端到端延迟 ≈ TTFT + 输出 token 数 × TPOT。
- 吞吐量（Throughput）：单位时间内整个系统处理的 token 数或请求数，决定成本。
【二、延迟与吞吐的矛盾】
增大批处理（batch）可以提高 GPU 利用率和总吞吐，但每个请求的延迟可能上升。在线服务要在两者之间找平衡，离线批处理任务则可以优先吞吐。
【三、现代推理框架的关键技术】
- 连续批处理（Continuous Batching）：请求完成后立即插入新请求，而不是等整批结束，大幅提升利用率。
- 分页式 KV Cache 管理（如 PagedAttention）：减少显存碎片，支持更多并发。
- 前缀缓存（Prefix Caching）：共享相同系统提示词的请求可复用计算。
- 推测解码（Speculative Decoding）：用小模型先“猜”，大模型验证，在部分场景下降低延迟，效果与任务相关。
- 分块预填充（Chunked Prefill）：把长输入拆块处理，减少长请求对其他请求的阻塞。
vLLM、SGLang、TensorRT-LLM、llama.cpp 等框架对这些技术的支持程度不同，请以各自最新文档为准。
【四、如何做一次公平的基准测试】
1. 写清硬件、驱动、框架版本、模型与精度。
2. 固定输入/输出长度分布，最好用接近真实业务的数据。
3. 在不同并发水平下测试，画出“吞吐-延迟”曲线，而不是只报一个数字。
4. 同时报告 P50 和 P99 延迟，尾延迟往往决定用户体验。
5. 预热后再计时，排除首次加载和编译时间。
讨论：
1. 你们线上服务更关注 TTFT 还是吞吐？如何设定目标？
2. 推测解码在你们的场景中实际效果如何？
【一、核心指标】
- TTFT（Time To First Token，首 token 延迟）：从请求发出到收到第一个 token 的时间。主要受预填充（prefill）阶段影响，输入越长越高。对聊天体验影响最大。
- TPOT / ITL（每输出 token 时间 / token 间延迟）：生成阶段每个 token 的平均间隔，决定“打字速度”。
- 端到端延迟 ≈ TTFT + 输出 token 数 × TPOT。
- 吞吐量（Throughput）：单位时间内整个系统处理的 token 数或请求数，决定成本。
【二、延迟与吞吐的矛盾】
增大批处理（batch）可以提高 GPU 利用率和总吞吐，但每个请求的延迟可能上升。在线服务要在两者之间找平衡，离线批处理任务则可以优先吞吐。
【三、现代推理框架的关键技术】
- 连续批处理（Continuous Batching）：请求完成后立即插入新请求，而不是等整批结束，大幅提升利用率。
- 分页式 KV Cache 管理（如 PagedAttention）：减少显存碎片，支持更多并发。
- 前缀缓存（Prefix Caching）：共享相同系统提示词的请求可复用计算。
- 推测解码（Speculative Decoding）：用小模型先“猜”，大模型验证，在部分场景下降低延迟，效果与任务相关。
- 分块预填充（Chunked Prefill）：把长输入拆块处理，减少长请求对其他请求的阻塞。
vLLM、SGLang、TensorRT-LLM、llama.cpp 等框架对这些技术的支持程度不同，请以各自最新文档为准。
【四、如何做一次公平的基准测试】
1. 写清硬件、驱动、框架版本、模型与精度。
2. 固定输入/输出长度分布，最好用接近真实业务的数据。
3. 在不同并发水平下测试，画出“吞吐-延迟”曲线，而不是只报一个数字。
4. 同时报告 P50 和 P99 延迟，尾延迟往往决定用户体验。
5. 预热后再计时，排除首次加载和编译时间。
讨论：
1. 你们线上服务更关注 TTFT 还是吞吐？如何设定目标？
2. 推测解码在你们的场景中实际效果如何？