尧图网站建设 
完整实战3 步跑通开源大模型性能压测从 QPS 到吞吐指标一次讲清【免费下载链接】self-llm《开源大模型食用指南》针对中国宝宝量身打造的基于Linux环境快速微调全参数/Lora、部署国内外开源大模型LLM/多模态大模型MLLM教程项目地址: https://gitcode.com/GitHub_Trending/se/self-llm刚拉完一个 7B 模型老板开口就是在 A100 上能扛多少 QPS首 token 延迟多少你打开终端发现除了pip install一无所知。这篇文章就是帮你把大模型性能压测这件事跑通的用 20 分钟时间在单卡 GPU 上完成一次标准吞吐量测试拿到可以直接写进汇报的数据。适用环境是 Linux NVIDIA 显卡24G 显存起步即可测 7B 级模型仓库里 Qwen2、Qwen2.5 等目录都自带压测脚本跟着做即可。不同开源大模型在 MMLU、Codeforces 等基准上的成绩对比这类跑分和本文要做的性能压测是两回事压测工具怎么选benchmark 脚本还是 EvalScope先说结论多数情况下vLLM 自带的benchmark_throughput.py就够了只有当你需要压测已经对外提供 OpenAI 兼容接口的服务、或要做标准化报告时才上 EvalScope。候选工具适用场景安装复杂度核心指标是否支持多模态vLLMbenchmark_throughput.py离线压测直接测模型文件装好 vLLM 即可仓库已带脚本吞吐tokens/s、请求速率req/s不支持EvalScopeperf对在线服务OpenAI API压测、出标准报告需额外安装参数较多吞吐、首 token 延迟TTFT、生成延迟支持HuggingFace Transformers 基线对比 vLLM 提升幅度已随环境装好同上仅作对照不支持建议你先只用前两个vLLM 脚本看模型本身上限EvalScope 看服务实际表现两者数据一起交差最有说服力。pip install vllm0.6.1.post2 # 仓库脚本适配的 vLLM 版本版本过新可能报参数错误 pip install evalscope[perf] -U # 只有需要压在线服务时才装最小可运行示例一条命令测出吞吐仓库里每个模型目录都放好了脚本以 Qwen2.5 为例直接使用压测脚本# 进入模型目录后执行参数含义见行内注释 python benchmark_throughput.py \ --model /path/to/Qwen2.5-7B-Instruct \ # 本地模型路径 --backend vllm \ # 推理后端换成 hf 可测 Transformers 基线 --input-len 64 \ # 每条请求的输入 token 数 --output-len 128 \ # 每条请求的输出 token 数 --num-prompts 25 \ # 测试请求总数建议 ≥20 --seed 2024 \ # 固定随机种子保证结果可复现 --dtype float16 \ # 计算精度 --max-model-len 512 # 单条序列上限防止 KV Cache 爆显存跑完后会打印一行类似这样的结果Throughput: 9.14 requests/s, 1754.43 tokens/s几个核心指标的含义指标含义怎么读requests/s每秒完成多少条完整请求换算 QPS 直接用它tokens/s每秒生成多少 token含输入输出衡量生成速度越大越好req 耗时 1/(requests/s)单条请求平均耗时配合 input/output 长度换算首 token 延迟⚠️ 最容易踩的坑--max-model-len和--num-prompts设太大7B 模型在 24G 卡上也会 OOM。显存不够时先降num-prompts再降max-model-len不要第一时间动精度。进阶调参找拐点、批量验证、留底拿到第一次结果后真正有价值的是扫参数找拐点扫并发把--num-prompts从 25 依次加大到 50、100、200vLLM 会内部批处理观察 tokens/s 何时不再增长——那就是你这套硬件 模型的吞吐上限再加请求只会堆积延迟。扫序列长度真实业务是什么长度就测什么长度。--input-len 64 / --output-len 128适合短对话RAG 场景建议改成input 1024 / output 512两者测出的吞吐差距可能有 2-3 倍。跑对照同一命令把--backend vllm换成hf并加--hf-max-batch-size 25就能算出 vLLM 相比 Transformers 的提升百分比这个数字放在汇报里非常加分。批量验证时建议用循环把不同参数组合的结果重定向落盘例如for out_len in 128 256 512; do python benchmark_throughput.py --model $MODEL --backend vllm \ --input-len 64 --output-len $out_len --num-prompts 50 \ --seed 2024 --dtype float16 --max-model-len 1024 \ | tee result_output_${out_len}.txt # 结果留底方便复看 done每个组合至少跑 3 次取均值单次结果受显存碎片和调度影响波动不小另外用nvidia-smi确认测试时显卡是独占状态AutoDL 租卡前记得先跑一遍看显存是否为 0 占用。测试机硬件概况4 张 A100-40GB写报告时务必附上 CPU/内存/显卡型号排障速查四个高频问题一行解决CUDA out of memory→ 降--num-prompts和--max-model-len或加--gpu-memory-utilization 0.85ValueError: max_model_len或参数不识别 → vLLM 版本与脚本不匹配装回 0.6.1.post2吞吐比预期低一半以上 → 用nvidia-smi查是否有其他进程占卡或误用了 fp32 精度同一命令两次结果差 20% 以上 → 冷启动影响先空跑一次预热再正式测EvalScope 报连接拒绝 → 先curl服务地址确认可达再检查--parallel是否超过服务并发上限现在你可以把吞吐量、请求速率和硬件配置整理成一张表直接贴给老板了。脚本和完整参数说明在Qwen2.5 vLLM 部署调用文档的推理速度测试一节Qwen2、GLM-4 等目录下的同名文档流程一致换模型路径即可复用。【免费下载链接】self-llm《开源大模型食用指南》针对中国宝宝量身打造的基于Linux环境快速微调全参数/Lora、部署国内外开源大模型LLM/多模态大模型MLLM教程项目地址: https://gitcode.com/GitHub_Trending/se/self-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 完整实战：3 步跑通开源大模型性能压测，从 QPS 到吞吐指标一次讲清
完整实战3 步跑通开源大模型性能压测从 QPS 到吞吐指标一次讲清【免费下载链接】self-llm《开源大模型食用指南》针对中国宝宝量身打造的基于Linux环境快速微调全参数/Lora、部署国内外开源大模型LLM/多模态大模型MLLM教程项目地址: https://gitcode.com/GitHub_Trending/se/self-llm刚拉完一个 7B 模型老板开口就是在 A100 上能扛多少 QPS首 token 延迟多少你打开终端发现除了pip install一无所知。这篇文章就是帮你把大模型性能压测这件事跑通的用 20 分钟时间在单卡 GPU 上完成一次标准吞吐量测试拿到可以直接写进汇报的数据。适用环境是 Linux NVIDIA 显卡24G 显存起步即可测 7B 级模型仓库里 Qwen2、Qwen2.5 等目录都自带压测脚本跟着做即可。不同开源大模型在 MMLU、Codeforces 等基准上的成绩对比这类跑分和本文要做的性能压测是两回事压测工具怎么选benchmark 脚本还是 EvalScope先说结论多数情况下vLLM 自带的benchmark_throughput.py就够了只有当你需要压测已经对外提供 OpenAI 兼容接口的服务、或要做标准化报告时才上 EvalScope。候选工具适用场景安装复杂度核心指标是否支持多模态vLLMbenchmark_throughput.py离线压测直接测模型文件装好 vLLM 即可仓库已带脚本吞吐tokens/s、请求速率req/s不支持EvalScopeperf对在线服务OpenAI API压测、出标准报告需额外安装参数较多吞吐、首 token 延迟TTFT、生成延迟支持HuggingFace Transformers 基线对比 vLLM 提升幅度已随环境装好同上仅作对照不支持建议你先只用前两个vLLM 脚本看模型本身上限EvalScope 看服务实际表现两者数据一起交差最有说服力。pip install vllm0.6.1.post2 # 仓库脚本适配的 vLLM 版本版本过新可能报参数错误 pip install evalscope[perf] -U # 只有需要压在线服务时才装最小可运行示例一条命令测出吞吐仓库里每个模型目录都放好了脚本以 Qwen2.5 为例直接使用压测脚本# 进入模型目录后执行参数含义见行内注释 python benchmark_throughput.py \ --model /path/to/Qwen2.5-7B-Instruct \ # 本地模型路径 --backend vllm \ # 推理后端换成 hf 可测 Transformers 基线 --input-len 64 \ # 每条请求的输入 token 数 --output-len 128 \ # 每条请求的输出 token 数 --num-prompts 25 \ # 测试请求总数建议 ≥20 --seed 2024 \ # 固定随机种子保证结果可复现 --dtype float16 \ # 计算精度 --max-model-len 512 # 单条序列上限防止 KV Cache 爆显存跑完后会打印一行类似这样的结果Throughput: 9.14 requests/s, 1754.43 tokens/s几个核心指标的含义指标含义怎么读requests/s每秒完成多少条完整请求换算 QPS 直接用它tokens/s每秒生成多少 token含输入输出衡量生成速度越大越好req 耗时 1/(requests/s)单条请求平均耗时配合 input/output 长度换算首 token 延迟⚠️ 最容易踩的坑--max-model-len和--num-prompts设太大7B 模型在 24G 卡上也会 OOM。显存不够时先降num-prompts再降max-model-len不要第一时间动精度。进阶调参找拐点、批量验证、留底拿到第一次结果后真正有价值的是扫参数找拐点扫并发把--num-prompts从 25 依次加大到 50、100、200vLLM 会内部批处理观察 tokens/s 何时不再增长——那就是你这套硬件 模型的吞吐上限再加请求只会堆积延迟。扫序列长度真实业务是什么长度就测什么长度。--input-len 64 / --output-len 128适合短对话RAG 场景建议改成input 1024 / output 512两者测出的吞吐差距可能有 2-3 倍。跑对照同一命令把--backend vllm换成hf并加--hf-max-batch-size 25就能算出 vLLM 相比 Transformers 的提升百分比这个数字放在汇报里非常加分。批量验证时建议用循环把不同参数组合的结果重定向落盘例如for out_len in 128 256 512; do python benchmark_throughput.py --model $MODEL --backend vllm \ --input-len 64 --output-len $out_len --num-prompts 50 \ --seed 2024 --dtype float16 --max-model-len 1024 \ | tee result_output_${out_len}.txt # 结果留底方便复看 done每个组合至少跑 3 次取均值单次结果受显存碎片和调度影响波动不小另外用nvidia-smi确认测试时显卡是独占状态AutoDL 租卡前记得先跑一遍看显存是否为 0 占用。测试机硬件概况4 张 A100-40GB写报告时务必附上 CPU/内存/显卡型号排障速查四个高频问题一行解决CUDA out of memory→ 降--num-prompts和--max-model-len或加--gpu-memory-utilization 0.85ValueError: max_model_len或参数不识别 → vLLM 版本与脚本不匹配装回 0.6.1.post2吞吐比预期低一半以上 → 用nvidia-smi查是否有其他进程占卡或误用了 fp32 精度同一命令两次结果差 20% 以上 → 冷启动影响先空跑一次预热再正式测EvalScope 报连接拒绝 → 先curl服务地址确认可达再检查--parallel是否超过服务并发上限现在你可以把吞吐量、请求速率和硬件配置整理成一张表直接贴给老板了。脚本和完整参数说明在Qwen2.5 vLLM 部署调用文档的推理速度测试一节Qwen2、GLM-4 等目录下的同名文档流程一致换模型路径即可复用。【免费下载链接】self-llm《开源大模型食用指南》针对中国宝宝量身打造的基于Linux环境快速微调全参数/Lora、部署国内外开源大模型LLM/多模态大模型MLLM教程项目地址: https://gitcode.com/GitHub_Trending/se/self-llm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考