已学完
💡 一句话解释： 不开任何网络服务，直接把几千段文字塞给本地模型，测它到底能嚼多快！
vllm bench throughput --model NousResearch/Hermes-3-Llama-3.1-8B --dataset-name sonnet --dataset-path sonnet.txt --num-prompts 10
办法：满汉全席一口气全塞满
批量塞满，测出理论上限
解决了什么：无需搭建网络服务，零开销快速测出单卡/多卡最高理论吞吐（Tokens/s）。
代价是什么：完全忽略了网络传输、排队拥堵和真实用户的流式交互体验。
已学完
💡 一句话解释： 模拟真实用户发起 HTTP 网络请求，测试在实际 API 接口下的抗压表现。
vllm bench serve --backend vllm --model Hermes-3-Llama-3.1-8B --endpoint /v1/completions --dataset-name sharegpt --num-prompts 10
烦恼：离线成绩好，上线卡成狗
实验室测速，上线露馅
办法：真实客户端兵分多路压测
真刀真枪，测出生产水准
解决了什么：真实捕捉网络传输、路由反序列化及并发排队时的真实服务负载。
代价是什么：压测客户端自身网络和 CPU 开销可能成为新的瓶颈，需要精心配置环境。
已学完
💡 一句话解释： 用户发完消息后，屏气凝神等屏幕跳出“第 1 个字”的那段等待时间。
# 关注结果中的 Mean TTFT, Median TTFT, P99 TTFT (越小越爽)
烦恼：点了发送，屏幕像死机了一样
第一个字难产，急死人
办法：分块预填充与 Chunked Prefill
秒回首字，交互极其爽滑
解决了什么：精准衡量从发起请求到预填充（Prefill）完成的首字耗时，决定了用户觉得“卡不卡”。
代价是什么：长上下文 Prompt 会剧烈推高 TTFT，需配合 Chunked Prefill 削峰填谷。
已学完
💡 一句话解释： TPOT 是除首字外吐每个字的平均速度，而 ITL 记录每个字之间有没有“忽然打嗝卡住”。
Mean TPOT: 7.91 ms | Mean ITL: 7.74 ms (ITL 抖动决定打字机流不流畅)
办法：细粒度时间片均衡吐字
如丝般顺滑，阅读超舒适
解决了什么：通过监控 P99 ITL 揪出多请求混部时的掉帧卡顿，保证流式吐字毫无阻滞。
代价是什么：为保证 ITL 平稳，可能必须牺牲部分极致批处理并行规模。
已学完
💡 一句话解释： 所有用户都共用同样的“系统提示词”或长背景，vLLM 把它记在小本本上，下次直接抄答案！
python3 benchmarks/benchmark_prefix_caching.py --model llama-2-7b-chat-hf --enable-prefix-caching --repeat-count 100
烦恼：同样 2000 字前言反复算
同一个字，算了十遍
办法：KV Cache 随身留存，即中即用
前缀秒中，直接开吐
解决了什么：命中缓存时跳过耗时的 Prefill 阶段，吞吐成倍暴涨且显著降低首字延迟。
代价是什么：压测时多次跑相同测试会虚标成“假高分”，需切换 --seed 或重置服务以排除干扰。
已学完
💡 一句话解释： 当大模型必须按照 JSON Schema、正则或语法树规范输出时，测它的约束引导到底会拖慢多少速度！
python3 benchmarks/benchmark_serving_structured_output.py --dataset json --structured-output-ratio 1.0
烦恼：戴上 JSON 紧箍咒，吐字变慢
规矩太多，步履蹒跚
办法：XGrammar 语法加速引擎保驾护航
戴着镣铐，照样跳舞
解决了什么：支持 JSON Schema、Grammar、Regex 等严格格式生成，压测评估其对吐字吞吐的影响。
代价是什么：Logits 掩码计算会消耗额外的 CPU/GPU 资源，可能轻微拉长每 token 耗时。
已学完
💡 一句话解释： 给模型扔一份整本小说的超长长文本，测试显存够不够用，以及几万字读完要花多久。
vllm bench long-doc-qa --model Qwen2.5-72B --max-model-len 32768 --repeat-mode tile
烦恼：大海捞针，显存直接爆仓
长篇大论，显卡直接吐血
办法：分块注意力调度与平铺复制
分片入腹，再长也能咽下
解决了什么：系统评估万级 Token 超长上下文下的 Prefill 算力利用率与显存驻留极限。
代价是什么：长文本 Prefill 占住 GPU 期间，其他小请求的响应会被迫推迟。
已学完
💡 一句话解释： 别总是用均匀小碎步压测，从 1 QPS 一路狂飙爬坡到 100 QPS，看它在哪一刻彻底崩溃！
vllm bench serve --request-rate 2 --ramp-up-strategy linear --ramp-up-end-request-rate 50 --ramp-up-duration 60
烦恼：匀速压测合格，突发流量瘫痪
假平稳，一冲就垮
办法：阶梯线性拉升，探明承载拐点
逐级加码，摸清底细
解决了什么：模拟生产早高峰流量线性增加过程，准确测试集群的饱和拐点与熔断阈值。
代价是什么：测试时间较长，且需要配置专门的客户端探针防止早衰退出。
已学完
💡 一句话解释： 让轻快的小助手（草稿模型）一口气瞎猜写出 5 个字，大模型只看一眼批量盖章认可！
# 评测 SPEED-Bench, Spec Bench 或 InstructCoder 投机加速比
烦恼：巨无霸大模型自己一步步推
大块头自己推，快不起来
办法：小弟狂打草稿，大哥一秒核验
小弟先写，大哥批量盖章
解决了什么：通过 SPEED-Bench 科学评测投机接受率，实现单请求吐字速度翻倍。
代价是什么：草稿模型占用额外显存，若接受率低于 50% 甚至可能反向拖慢速度。
下一站
💡 一句话解释： 当大模型要看图片、听声音、甚至自己调天气 API 查快递时，测它的全场景战斗力！
vllm bench serve --backend openai-chat --model Qwen2.5-VL-7B --dataset-name sharegpt4v
烦恼：纯文字跑分无法代表真实 AI
只考单科，难测全貌
办法：全能大联考，图文视听一网打尽
文武双全，直通生产实战
解决了什么：结合 BFCL（工具调用）与 ShareGPT4V 真实图像输入，全面覆盖多模态 Agent 性能。
代价是什么：图像编码器（ViT）开销极大，需开启 ViT CUDA Graphs 等专项优化。