快速上手 vLLM 性能基准测试5 个关键指标带你从选型到调优【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 是 LLM 高吞吐推理引擎但快不快、快在哪不能靠感觉。本文带你用内置的vllm bench工具完成第一轮基准测试看懂 TTFT、TPOT 等关键指标并给出一套上线前的检查清单。你会不会也遇到这几种情况新版本不敢直接上vLLM 迭代很快你想确认这次升级对你的模型是提升还是回退但手上没有可复现的数字。压测结果虚高同样的服务你测的吞吐比同事测的高出一截最后发现是前缀缓存命中把结果抬高了。P99 延迟偶发飙高平均延迟看着还行但一到流量高峰就有请求明显变慢你说不清是显存不够还是调度策略问题。这三种情况的共同解法都一样用统一的数据集、统一的参数跑基准拿数字对比而不是凭直觉。为什么 vLLM 的性能值得你花时间验证vLLM 的几个核心机制直接决定了你该看哪些数字分页 KV cachePagedAttentionKV cache 被切成固定大小的块按需分配不再为每个请求预留整段显存。 这对你意味着什么显存浪费变小同样的卡能塞下更多并发请求所以最大并发数才是衡量容量该看的量而不是理论峰值。连续批处理不同请求动态拼进同一个 batch长短请求互相填坑。 这对你意味着什么吞吐对流量形态很敏感用恒定的均匀流量测出来的结果不能代表突发流量下的真实表现。chunked prefill分块预填充长 prompt 的预填充被切成小块和 decode 请求混排避免一条长请求卡住整批。 这对你意味着什么max_num_batched_tokens这个参数同时影响 TTFT 和 ITL是延迟调优的第一旋钮。10 分钟跑起来最小可用路径不需要额外装压测框架vLLM 自带基准工具。最短路径是三步装包、起服务、压测。pip install vllm vllm serve 你的模型然后用vllm bench serve打流量。不想准备数据集时可以用内置的随机数据集固定长度、结果可复现vllm bench serve \ --model 你的模型 \ --dataset-name random \ --num-prompts 100跑完会输出一整份报告成功请求数、总耗时、TTFT / TPOT / ITL 的均值、中位数和 P99。实测下来把这份报告存档就成了你后面所有调优动作的对照组。如果你手头有 ShareGPT 之类的真实对话数据把--dataset-name换成对应数据集即可想先看数据长什么样加上--plot-dataset-stats会生成输入/输出 token 分布图先确认压测数据和生产流量像不像先看哪几个数字按用途分组看指标报告里指标不少建议按我要干什么分三组看别全背用途关键指标怎么看选型 / 容量规划输出 token 吞吐tok/s、请求吞吐req/s同数据集同参数下横向比具体数值以实测为准调优TTFTP99、TPOT / ITL长 prompt 场景盯 TTFT流式体验盯 ITL排障preemption 计数、KV cache 可用 token 数出现抢占说明显存余量不足几个容易踩坑的点TTFT vs TPOT 不是一回事TTFT 是从发请求到收到第一个 token受 prompt 长度影响大TPOT 是首 token 之后每个 token 的平均耗时反映稳态生成速度。用户抱怨开头慢查前者抱怨越打越卡查后者。同一台服务重复压测会虚高上一轮跑完前缀还留在缓存里第二轮吞吐会被抬高。要复现干净结果就换随机种子、重启服务或用 sweep 模式每次跑之间自动重置缓存。P99 比均值值钱均值正常、P99 拉胯通常意味着有少数请求被抢占或排队了这类问题只看平均数永远发现不了。换个玩法模拟真实流量和批量扫参数按流量形态压测。vllm bench serve支持三个参数组合出不同压测形态--request-rate请求到达速率、--burstiness波动程度、--max-concurrency并发上限。三种最常用的组合场景参数组合目的最大吞吐速率不限 设并发上限模拟网关限流下的真实容量上限真实基线速率 5~20 burstiness1.0自然泊松流量做基线对比稳定性压测burstiness0.1~0.5 高速率突发流量下看系统会不会雪崩批量扫参数别再手改配置重跑。vllm bench sweep serve可以对一组配置自动依次压测每次运行之间重置服务缓存结果可以直接对比——这正好解决改一个参数要重启重测半天的痛点。参数和输出目录的写法可以参考 官方基准文档。上生产前必查清单启动日志里的 KV cache token 总量除以你的单请求最大长度得到的理论最大并发 ≥ 预期并发的 1.5 倍压测期间日志没有 preemption 告警有则提高gpu_memory_utilization或调小max_num_seqs压测数据集的输入/输出长度分布和线上真实流量在同一量级用--plot-dataset-stats看一眼对比测试时每次之间都重置了缓存或更换了随机种子Prometheus 指标已接上至少能看 preemption 计数和 token 吞吐建议的动作今天就用固定随机数据集跑一轮把 TTFT P99、TPOT P99、输出吞吐三个数记下来存档之后再改任何配置或升级版本都重跑同一套命令做对比。有对照组你的每一次调优才算数。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 快速上手 vLLM 性能基准测试：5 个关键指标带你从选型到调优
快速上手 vLLM 性能基准测试5 个关键指标带你从选型到调优【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllmvLLM 是 LLM 高吞吐推理引擎但快不快、快在哪不能靠感觉。本文带你用内置的vllm bench工具完成第一轮基准测试看懂 TTFT、TPOT 等关键指标并给出一套上线前的检查清单。你会不会也遇到这几种情况新版本不敢直接上vLLM 迭代很快你想确认这次升级对你的模型是提升还是回退但手上没有可复现的数字。压测结果虚高同样的服务你测的吞吐比同事测的高出一截最后发现是前缀缓存命中把结果抬高了。P99 延迟偶发飙高平均延迟看着还行但一到流量高峰就有请求明显变慢你说不清是显存不够还是调度策略问题。这三种情况的共同解法都一样用统一的数据集、统一的参数跑基准拿数字对比而不是凭直觉。为什么 vLLM 的性能值得你花时间验证vLLM 的几个核心机制直接决定了你该看哪些数字分页 KV cachePagedAttentionKV cache 被切成固定大小的块按需分配不再为每个请求预留整段显存。 这对你意味着什么显存浪费变小同样的卡能塞下更多并发请求所以最大并发数才是衡量容量该看的量而不是理论峰值。连续批处理不同请求动态拼进同一个 batch长短请求互相填坑。 这对你意味着什么吞吐对流量形态很敏感用恒定的均匀流量测出来的结果不能代表突发流量下的真实表现。chunked prefill分块预填充长 prompt 的预填充被切成小块和 decode 请求混排避免一条长请求卡住整批。 这对你意味着什么max_num_batched_tokens这个参数同时影响 TTFT 和 ITL是延迟调优的第一旋钮。10 分钟跑起来最小可用路径不需要额外装压测框架vLLM 自带基准工具。最短路径是三步装包、起服务、压测。pip install vllm vllm serve 你的模型然后用vllm bench serve打流量。不想准备数据集时可以用内置的随机数据集固定长度、结果可复现vllm bench serve \ --model 你的模型 \ --dataset-name random \ --num-prompts 100跑完会输出一整份报告成功请求数、总耗时、TTFT / TPOT / ITL 的均值、中位数和 P99。实测下来把这份报告存档就成了你后面所有调优动作的对照组。如果你手头有 ShareGPT 之类的真实对话数据把--dataset-name换成对应数据集即可想先看数据长什么样加上--plot-dataset-stats会生成输入/输出 token 分布图先确认压测数据和生产流量像不像先看哪几个数字按用途分组看指标报告里指标不少建议按我要干什么分三组看别全背用途关键指标怎么看选型 / 容量规划输出 token 吞吐tok/s、请求吞吐req/s同数据集同参数下横向比具体数值以实测为准调优TTFTP99、TPOT / ITL长 prompt 场景盯 TTFT流式体验盯 ITL排障preemption 计数、KV cache 可用 token 数出现抢占说明显存余量不足几个容易踩坑的点TTFT vs TPOT 不是一回事TTFT 是从发请求到收到第一个 token受 prompt 长度影响大TPOT 是首 token 之后每个 token 的平均耗时反映稳态生成速度。用户抱怨开头慢查前者抱怨越打越卡查后者。同一台服务重复压测会虚高上一轮跑完前缀还留在缓存里第二轮吞吐会被抬高。要复现干净结果就换随机种子、重启服务或用 sweep 模式每次跑之间自动重置缓存。P99 比均值值钱均值正常、P99 拉胯通常意味着有少数请求被抢占或排队了这类问题只看平均数永远发现不了。换个玩法模拟真实流量和批量扫参数按流量形态压测。vllm bench serve支持三个参数组合出不同压测形态--request-rate请求到达速率、--burstiness波动程度、--max-concurrency并发上限。三种最常用的组合场景参数组合目的最大吞吐速率不限 设并发上限模拟网关限流下的真实容量上限真实基线速率 5~20 burstiness1.0自然泊松流量做基线对比稳定性压测burstiness0.1~0.5 高速率突发流量下看系统会不会雪崩批量扫参数别再手改配置重跑。vllm bench sweep serve可以对一组配置自动依次压测每次运行之间重置服务缓存结果可以直接对比——这正好解决改一个参数要重启重测半天的痛点。参数和输出目录的写法可以参考 官方基准文档。上生产前必查清单启动日志里的 KV cache token 总量除以你的单请求最大长度得到的理论最大并发 ≥ 预期并发的 1.5 倍压测期间日志没有 preemption 告警有则提高gpu_memory_utilization或调小max_num_seqs压测数据集的输入/输出长度分布和线上真实流量在同一量级用--plot-dataset-stats看一眼对比测试时每次之间都重置了缓存或更换了随机种子Prometheus 指标已接上至少能看 preemption 计数和 token 吞吐建议的动作今天就用固定随机数据集跑一轮把 TTFT P99、TPOT P99、输出吞吐三个数记下来存档之后再改任何配置或升级版本都重跑同一套命令做对比。有对照组你的每一次调优才算数。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考