这次我们来看一个 vLLM Serving 调优实验在 H100 平台上通过调整配置项把 p95 TTFT 和 ITL 都干过了 baseline。如果你正在做 LLM 推理服务压测或者准备把 vLLM 接入自己的业务这篇文章可以直接收藏。先说结论TTFT 和 ITL 是衡量大模型在线服务体验最核心的两个指标而它们并不只取决于 GPU 型号。同样的 H100、同样的模型权重vLLM 服务端的调度参数、显存分配策略、是否启用 CUDA Graph、并发队列深度都会显著影响 p95 表现。本文会从指标含义讲起然后给出 vLLM 在 H100 上的部署方式、baseline 构建方法、config 调优思路、接口调用示例和一套可复用的压测验证流程。vLLM 是目前最主流的开源 LLM 推理服务框架之一由加州大学伯克利分校团队开源核心优势是 PagedAttention 显存管理和 Continuous Batching 连续批处理。它能把离散的 KV Cache 分页管理提高显存利用率同时在不打断已生成请求的前提下动态插入新请求。对于生产环境来说vLLM 提供 OpenAI 兼容的 HTTP API可以比较平滑地接入已有业务。如果你正准备做类似实验建议先把这几点搞清楚你的服务是追求首字延迟还是整体吞吐你的请求是短文本多并发的在线场景还是长文本少并发的离线场景这两类场景对 config 的要求完全不同。下面进入正题。1. vLLM Serving 核心能力速览先给一张规格表快速判断这个框架和这次实验的适用范围。能力项说明项目类型开源 LLM 推理服务框架核心机制PagedAttention、Continuous Batching、CUDA Graph、Prefix Caching主要功能模型加载、并发推理、流式输出、OpenAI 兼容 API、离线批量推理推荐硬件NVIDIA H100 等高性能 GPU也可在 A100、L40S、4090 等显卡上运行支持平台Linux 为主Windows 支持有限需按版本确认启动方式Python CLI、Python 脚本内嵌、Docker 部署接口能力OpenAI 兼容/v1/chat/completions、/v1/completions接口批量任务支持离线 Batch 推理和在线并发请求性能指标TTFT、ITL、TPOT、吞吐量、显存占用、利用率适合场景在线聊天服务、RAG 检索问答、LLM API 网关、批量文本生成从实验标题看H100 只是硬件底座真正的胜负手是 config。后面会逐个拆解哪些配置项会影响 p95 TTFT 和 ITL。2. TTFT 与 ITL两个关键指标的实验背景2.1 TTFT首 Token 延迟TTFT 全称 Time To First Token指从客户端发出请求到收到第一个 token 的时间。用户输入完内容后最直观的感受就是“多久开始出字”所以 TTFT 是聊天机器人、智能客服这类交互场景的第一体验指标。p95 TTFT 表示 95 分位首 token 延迟。为什么实验用 p95 而不是平均值因为在线服务的体验差往往来自尾部请求。平均延迟低不代表每个用户都快只要有一小部分请求因为排队、调度抖动、长 prompt 处理而变慢就会拉高 p95。对生产环境来说p95 TTFT 是比 mean TTFT 更靠谱的稳定性指标。影响 TTFT 的主要因素包括Prefill 阶段的计算量输入 prompt 越长prefill 耗时越大。请求排队情况并发请求过多新请求要等前面的请求释放批处理槽位。显存中 KV Cache 的可用空间显存不足时PagedAttention 可能拒绝新请求或触发抢占。调度策略vLLM 的调度器决定什么时候把新请求加入批处理。2.2 ITLToken 间延迟ITL 全称 Inter-Token Latency指模型生成过程中相邻两个 token 之间的时间间隔。它反映的是“出字速度”也就是流式输出时每秒钟能吐出多少 token。ITL 越低生成越连贯用户在流式接口上感受越流畅。工程上可以看到两个相近指标TPOTTime Per Output Token单个输出 token 的平均耗时。ITL两个 token 之间的实际间隔。二者在流式输出场景下基本等效。实验标题把 ITL 和 p95 TTFT 并列说明这次调优既要照顾首字响应又要保证整体生成速度。影响 ITL 的主要因素包括Decode 阶段的批处理大小并发越高每个请求分到的 GPU 算力越少ITL 可能增大。是否使用 CUDA GraphCUDA Graph 可以减少 kernel launch 开销提升小 batch 场景下的 decode 速度。模型长度、输出长度长序列生成时 KV Cache 更大访存压力更高。显存带宽H100 的 HBM 带宽接近 3.35TB/s但多请求共享时仍有竞争。2.3 指标之间的取舍TTFT 和 ITL 存在天然的 trade-off。如果为了让 p95 TTFT 更低而一味把并发限制收紧每次只处理少数请求那 GPU 利用率下降单请求 ITL 可能更好但整体吞吐量上不去。反过来如果为了吞吐把批处理规模拉满prefill 阶段的大批量计算可能让后面排队的新请求 TTFT 飙升。所以实验标题里“config beats the baseline on p95 TTFT,ITL”的真正含义是在某个并发和流量模型下找到一组配置让两个指标同时优于默认配置而不是无脑压榨某一个指标。3. 实验环境准备与 vLLM 部署3.1 硬件环境H100 是目前大模型推理的顶级选择之一。常见配置是 80GB HBM3 显存支持 FP8、BF16 等精度。如果你的服务器没有 H100A100 80GB、H800、L40S 甚至 4090 也可以做类似实验只是绝对数值不同调优思路是一样的。需要注意显存大小直接决定能加载多大的模型、能留多少空间给 KV Cache。例如加载 70B 级别模型用 BF16 精度权重就要占用约 140GB单张 H100 跑不动一般会配合张量并行或量化方案。实际能跑多大的模型需要看权重格式、上下文长度和并发规模建议先按常规配置估算再在小参数下实测验证。3.2 软件环境推荐环境操作系统Ubuntu 22.04 / 24.04GPU 驱动CUDA 12.1 或更高版本Python3.10 或 3.11PyTorchvLLM 通常锁定对应版本安装时会自动解析vLLM最新稳定版或指定版本安装前先检查显卡驱动nvidia-smi输出里有驱动版本和 CUDA 版本号确认 GPU 能被识别。之后创建虚拟环境并安装 vLLMpython -m venv vllm_env source vllm_env/bin/activate pip install --upgrade pip pip install vllm如果网络较慢可以换成国内 PyPI 镜像pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple3.3 Docker 部署可选vLLM 官方也提供 Docker 镜像。生产环境推荐 Docker 方式因为依赖隔离更彻底也方便在 GPU 服务器之间迁移。镜像名和 tag 需要在官方仓库确认一般形如vllm/vllm-openai。docker pull vllm/vllm-openai:latest docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model 模型路径注意区分本地 PyPI 安装方式更灵活Docker 方式更适合发布和部署二选一即可不需要同时配两套。4. Baseline 服务搭建与压测方法4.1 用默认配置启动 Baseline实验的第一步是搭建 baseline。定义 baseline 为“用 vLLM 最朴素的启动参数启动服务不做任何调优”。这样后续所有优化效果才有对照。假设模型已经下载到本地使用一个 70B 级别的大型模型进行测试用 4 张 H100 做张量并行python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-70b启动后终端会出现服务的监听地址和模型加载信息。用以下命令确认服务正常curl http://127.0.0.1:8000/v1/models返回结果包含模型名称和元信息说明服务已经就绪。这时如果把参数全默认就是 baseline。4.2 压测前的请求设计在线 LLM 服务的请求模式很重要。做 TTFT 和 ITL 实验时需要设计几组不同特征的请求短 prompt 短输出模拟简单问答例如 prompt 长度 100 token 以内。长 prompt 短输出模拟 RAG 场景先给模型一大段资料再要求总结。短 prompt 长输出模拟文章生成、代码生成。混合请求以上三种按比例混合。每组请求数建议在 100 到 500 条之间太少了测不出 p95 的稳定性太多了浪费时间。4.3 手写一个指标采集脚本vLLM 的 OpenAI 兼容接口可以直接用requests请求。写一个 Python 脚本记录每次请求的 TTFT 和 ITLimport json import time import requests url http://127.0.0.1:8000/v1/completions payload { model: qwen-70b, prompt: 介绍一下杭州西湖的景点特色。, max_tokens: 500, temperature: 0.7, stream: True } # 记录从发出请求到收到第一个 token 的时间 start time.perf_counter() first_token_time None token_timestamps [] with requests.post(url, jsonpayload, streamTrue, timeout300) as resp: for line in resp.iter_lines(): if not line: continue line line.decode(utf-8) if not line.startswith(data:): continue now time.perf_counter() if first_token_time is None: first_token_time now ttft now - start token_timestamps.append(now) else: token_timestamps.append(now) itl_list [ token_timestamps[i 1] - token_timestamps[i] for i in range(len(token_timestamps) - 1) ] avg_itl sum(itl_list) / len(itl_list) if itl_list else 0 print(fTTFT {ttft:.4f}s) print(f平均 ITL {avg_itl:.4f}s) print(fITL p95 {sorted(itl_list)[int(len(itl_list) * 0.95) - 1]:.4f}s)这个脚本可以单测也可以在外面套一层循环做并发。如果要更严谨的压测推荐使用 Locust、wrk、vegeta 这类工具或者用 vLLM 仓库自带的benchmark_serving.py脚本。4.4 用 vLLM 自带压测脚本vLLM 仓库中通常带有一组 benchmark 脚本用于测量吞吐和延迟。这是比较标准的方式可以在启动服务后在另一台机器或另一个终端运行python benchmarks/benchmark_serving.py \ --backend vllm \ --model qwen-70b \ --tokenizer /data/models/qwen-70b \ --dataset-path ./sampled_requests.json \ --request-rate 10 \ --num-prompts 200 \ --port 8000注意脚本的位置和参数可能随版本变化用之前先看一下仓库里的 README 或脚本帮助信息。5. config 调优从 Baseline 到优化配置这部分是实验的核心。在 H100 上vLLM 有多个配置项会影响 p95 TTFT 和 ITL。下面按影响程度逐个梳理。5.1 gpu-memory-utilization显存利用率上限vLLM 默认把 GPU 显存的 90% 用于模型权重和 KV Cache。如果你的场景是长 prompt 多并发可以把上限调低防止显存不足导致请求被拒绝--gpu-memory-utilization 0.95不过别盲目拉高。显存利用率过高时KV Cache 空间增大能同时处理的序列更多但当请求队列变大后prefill 阶段占用的算力和显存会增加p95 TTFT 可能恶化。从材料看L20 双卡运行、qwen3.5 9b 爆显存等问题多半也是显存分配策略没调好。建议在 0.85 到 0.95 之间做小范围扫描。5.2 max-num-seqs并发序列上限这个参数直接决定 vLLM 在 decode 阶段最多同时处理多少个序列。默认值通常是 256。调大后吞吐量可能上升但单请求的 ITL 会恶化调小后每个请求能分到更多 GPU 资源ITL 更稳但 GPU 利用率可能下降。针对 p95 TTFT 的调优通常先从减小max-num-seqs开始。如果并发请求数少过大的队列上限并不会让第一个 token 更早出现反而可能让调度器积压请求。--max-num-seqs 128最后用多少取决于你的真实并发模型。建议基于压测时观察到的请求量和排队情况来定。5.3 enforce-eager是否启用 CUDA Graph这是一个常见的调优入口也是热词中出现频率很高的问题--enforce-eager到底有什么影响vLLM 默认会为模型捕获 CUDA Graph把一组 kernel launch 固化下来减少 CPU 调用 GPU 的开销。好处是 decode 阶段更快ITL 更低坏处是首次捕获时耗时较长且会占用额外显存。--enforce-eager表示禁用 CUDA Graph每次推理都走常规的 eager 执行方式。--enforce-eager开启--enforce-eager的效果通常是显存占用降低、启动时间变短但 ITL 可能变差。如果你的实验发现 p95 TTFT 偏高而 GPU 显存接近上限可以试着开--enforce-eager并调整gpu-memory-utilization对比 ITL 变化。不过 vLLM 较新版本里 CUDA Graph 已经是核心优化之一默认开启的收益通常大于开销。建议在同一个模型、同一批压测请求下分别测试开关两种状态优先保留效果更好的配置。5.4 max-model-len最大序列长度--max-model-len控制模型支持的最大上下文长度。如果把长度设得过大比如 32K那么 KV Cache 预分配会被推高能并发的序列数量减少如果设小能处理更长上下文的场景就不能用。--max-model-len 16384如果你的 prompt 长度集中在 2K 以内没必要把 max-model-len 设置成 32K。过大的序列长度会挤占 KV Cache 空间影响 p95 TTFT。5.5 chunked-prefill分块预填充vLLM 支持把长的 prefill 请求拆成小块穿插到 decode 请求中执行。这样做可以减少长 prompt 请求对后续短请求的阻塞对 p95 TTFT 非常有效。--enable-chunked-prefill如果你在实验中发现“长 prompt 请求把一批短请求堵住了”chunked prefill 是第一个要试的开关。它会略微增加调度复杂度但通常能让长尾延迟明显下降。5.6 调度策略与 Prefix CachevLLM 的调度器支持不同的排序策略整体影响请求到达后多久能进入批处理。若选择了不合适的调度策略在并发到达时会看到不稳定的 p95。另外如果你的场景有大量重复系统提示词或共享上下文前缀建议开启前缀缓存--enable-prefix-caching开启后相同前缀的 KV Cache 可以复用prefill 时间明显下降TTFT 会更稳定。这对 RAG、Agent 类固定 system prompt 场景非常关键。5.7 一套可参考的优化配置综合上面实验思路给出一个相较 baseline 更可能改善 p95 TTFT 和 ITL 的启动命令python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-70b \ --gpu-memory-utilization 0.92 \ --max-num-seqs 128 \ --max-model-len 16384 \ --enable-chunked-prefill \ --enable-prefix-caching这个配置不一定在每个场景都是最优解但它代表了一个完整的调优方向。最终参数需要在你的流量模型下做小步扫描。配置项Baseline 值优化方向影响指标gpu-memory-utilization默认 0.900.85~0.95 扫描显存余量、并发容量、TTFTmax-num-seqs默认 256按并发模型调小ITL、吞吐enforce-eager默认关闭 CUDA Graph 优化对比开关效果ITL、显存、启动时间max-model-len默认大值按实际上下文收紧KV Cache 容量、TTFTenable-chunked-prefill默认关闭开启长 prompt 场景 p95 TTFTenable-prefix-caching默认关闭相同前缀场景开启TTFT、prefill 耗时注意上面表格中的参数值是 vLLM 的常见示例值具体以你的 vLLM 版本和模型为准。调优时不要一次改多个参数否则区分不出是谁的贡献。6. 功能测试与效果验证6.1 单请求验证确认服务正常先用单个请求验证优化后的配置没有破坏基本功能curl http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d { model: qwen-70b, prompt: 用一句话解释什么是KV Cache。, max_tokens: 100, temperature: 0.4 }正常返回包含choices、usage等字段。这一步重点是确认模型加载正常、可以生成文本。6.2 并发压测对比 p95 TTFT 和 ITL重点来了。用同一组请求数据分别对 baseline 服务和优化后的服务做压测。具体做法先启动 baseline 服务跑一组压测记录 p95 TTFT 和平均 ITL。停止服务用优化配置重新启动。等模型加载完成再跑同一组压测。对比两份结果。判断标准p95 TTFT 有明显下降说明调度和 prefill 优化生效。平均 ITL 没有显著变差说明没有为了首字延迟牺牲生成速度。如果 p95 TTFT 下降但平均 ITL 明显上涨说明配置太激进并发能力被压得太低。如果两个指标同时优于 baseline就验证了标题里的结论。6.3 长 prompt 与短 prompt 分别观察长 prompt 场景下重点看 chunked-prefill 是否减少了请求间的互相阻塞。短 prompt 场景下重点看 max-num-seqs 对 ITL 的影响。建议在压测结果中按请求类型分组分别统计 p95 TTFT 和平均 ITL而不是只看总体平均值否则长请求和短请求的差异会被互相掩盖。6.4 连续压测观察稳定性在线服务还会遇到流量抖动。在压测脚本里设置一个持续 3 到 5 分钟的固定请求速率观察每 10 秒的 p95 TTFT 是否波动。如果出现某段时间 p95 突然飙升需要看是不是显存碎片、CUDA Graph 内存膨胀或后端队列堆积导致。vLLM 启动时可以挂载 metrics 监控把指标接到 Prometheus 或直接看日志。7. 接口 API 与批量任务7.1 OpenAI 兼容接口vLLM 启动后默认提供 OpenAI 兼容接口这是接入成本最低的方式。聊天的标准路径是curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-70b, messages: [ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 请举例说明vLLM的Continuous Batching机制。} ], max_tokens: 300, temperature: 0.6 }流式输出时加上stream: true服务端会以 SSE 格式逐 token 返回。前端可以像 ChatGPT 那样打字机效果展示。7.2 批量任务离线推理除了在线 APIvLLM 还支持离线批处理。你可以在 Python 脚本里直接构造LLM实例一次处理多段文本from vllm import LLM, SamplingParams llm LLM( model/data/models/qwen-70b, tensor_parallel_size4, gpu_memory_utilization0.92, max_model_len16384, enable_prefix_cachingTrue ) sampling_params SamplingParams( temperature0.6, max_tokens500 ) prompts [ 总结这份会议纪要..., 写一个Python函数实现快速排序。, 解释RAG的工作原理。 ] outputs llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text)离线批量任务适合不要求实时性的场景比如批量文档分析、离线报告生成、数据清洗。运行前要确认输入文本数量和长度避免一次性请求过多导致显存溢出。7.3 并发调用示例在线服务接入业务时通常用异步并发调用。下面是一个用concurrent.futures做并发请求的模板import concurrent.futures import requests import json url http://127.0.0.1:8000/v1/completions headers {Content-Type: application/json} def call_once(prompt): payload { model: qwen-70b, prompt: prompt, max_tokens: 200, temperature: 0.7 } resp requests.post(url, jsonpayload, headersheaders, timeout120) return resp.json() prompts [f写一段关于主题{i}的短文 for i in range(20)] with concurrent.futures.ThreadPoolExecutor(max_workers8) as executor: results list(executor.map(call_once, prompts)) print(json.dumps(results[0], ensure_asciiFalse, indent2))多线程并发数是客户端视角实际服务端的max-num-seqs才是真正决定同时处理多少请求的参数。客户端并发率超过服务端处理能力后只会增加排队不会让吞吐继续增长。8. 资源占用与性能观察8.1 显存占用观察用nvidia-smi实时查看多卡显存分布watch -n 1 nvidia-smi关注每个 GPU 的显存使用率、温度、功率和利用率。vLLM 会把一部分显存预留给 KV Cache启动后显存占用不是立刻打满而是在第一个请求进来后逐步分配。8.2 vLLM Metrics 与日志vLLM 支持输出 Prometheus metrics。启动时加上相关参数或通过nginx反代暴露metrics端点。常见观察项包括请求数量、排队的请求数量。正在处理的序列数量。显存中 KV Cache 的使用量。平均 TTFT 和 ITL。拒绝的请求数量。这些指标能帮助你判断 p95 TTFT 变差是因为排队还是因为显存不足还是因为单请求推理本身变慢。8.3 性能观察建议观察性能时不要只看 GPU 利用率。如果 GPU 利用率很低但 TTFT 很高问题可能在 CPU 侧的 tokenizer、调度器或网络层。如果 GPU 利用率很高但 ITL 很高问题可能在 decode 批处理过大或显存带宽不足。调优时要结合指标定位而不是盲目改参数。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动报显存不足模型权重超过显存容量nvidia-smi查看显存换更小模型或降低精度使用量化、张量并行、降低 gpu-memory-utilizationqwen 等模型加载后爆显存max-model-len 过大KV Cache 预留过多查看启动日志中 KV Cache 大小调小 max-model-len 或降低并发上限p95 TTFT 偏高且不稳定长 prompt 请求阻塞短请求开启 chunked-prefill 对比测试启用--enable-chunked-prefill.enforce-eager后生成变慢禁用了 CUDA Graph对比开关前后 ITL优先保留默认 CUDA GraphvLLM 在 Windows 上装不上依赖的 CUDA 组件在 Windows 下支持有限查看官方支持矩阵使用 WSL2、Docker 或 Linux 环境L20 上双卡无法并行推理张量并行需要满足显存和总线条件检查驱动、总线、模型大小确认多卡通信正常或减小张量并行数API 调用返回 404模型名或接口路径不对请求/v1/models确认模型名修改--served-model-name或请求中的 model 字段批量任务卡住输入列表中有超过 max-model-len 的文本检查每个输入的长度先做文本截断或拆分端口冲突8000 端口被占用lsof -i:8000或netstat -tlnp换端口或结束占用进程还有一些热词中提到的现象值得注意qwen3.6 35b a3b 的 TTFT 比较高这类情况很可能不是 vLLM 配置问题而是模型本身 structure 导致 prefill 计算量较大。建议先确认同模型在不同框架下的 TTFT 对比。vLLM 可以在 Windows 10 中使用吗这个问题要看版本。vLLM 核心依赖 PyTorch CUDA 生态Windows 支持一直相对保守更稳妥的做法是使用 WSL2 或 Linux 容器。vLLM 不支持在昇腾 910b 上启动 embedding 和 reranker 模型这类情况通常涉及自定义模型实现需要确认该模型架构是否被 vLLM 支持必要时改用 API 网关或专用推理后端。10. 最佳实践与使用建议先跑小参数测试再上生产配置。第一次启动尽量选一个小模型、低并发确认链路通了再切换到正式模型。保留一组最小可运行配置。我在实验时会把 baseline 的命令写成一个脚本文件任何一次调优失败都可以快速回滚。# baseline.sh python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 127.0.0.1 \ --port 8000模型文件、输入数据、压测结果、日志分目录管理。建议这样组织~/vllm_experiment/ ├── models/ ├── prompts/ │ ├── short_query.jsonl │ ├── long_doc.jsonl │ └── mixed.jsonl ├── logs/ ├── results/ │ ├── baseline_20240101.json │ └── optimized_20240101.json └── scripts/ ├── start_baseline.sh ├── start_optimized.sh └── run_benchmark.py批量任务必须加日志和失败重试。离线推理跑几十万条文本时总会有几条因为网络、显存抖动或超时而失败。建议记录每一条的请求 ID 和状态失败的任务重新入队。接口服务要限制访问范围。vLLM 默认监听地址如果你设成了0.0.0.0意味着局域网内所有机器都能访问。生产环境建议通过防火墙或反向代理控制访问权限必要时加 API Key。涉及模型权重、训练数据、用户 prompt 的隐私边界。部署前要确认模型权重来源是否允许商用或二次分发输入数据是否包含个人信息。涉及人脸、声音、版权素材时必须先确认授权。压测时不要使用真实用户数据用脱敏后的测试数据集。发布或商用前做效果复核。p95 TTFT 和 ITL 是服务性能指标但输出质量同样重要。调优配置后要人工复核一批生成结果确认没有因为配置改动导致采样参数异常或输出截断。11. 总结与下一步这次 vLLM Serving 实验最值得尝试的点就是验证“同一块 H100配置不同性能表现可以差很多”。p95 TTFT 和 ITL 不是单纯由 GPU 决定的vLLM 的显存利用率、并发序列上限、CUDA Graph、chunked prefill、prefix cache 都会影响最终的服务体验。最先应该验证的功能是baseline 服务能不能正常启动并返回结果。压测脚本能不能正确采集 TTFT 和 ITL。用优化配置跑完后p95 TTFT 和平均 ITL 是否同时改善。最容易踩的坑是一次改太多参数出了问题不知道是谁导致的。所以每次只改一个配置跑完记录结果再改下一个。后续可以继续扩展的方向把压测数据接入 Prometheus 和 Grafana做长期监控对比 sglang 和 vLLM 在相同模型下的 p95 差距在 8 卡 H100 上测试更大的模型并行把调优后的配置封装成容器镜像方便在不同服务器间复用。如果你正在做 LLM 服务的性能优化可以先拿手边的模型跑一组 baseline记录下当前的 p95 TTFT 和 ITL再按文章里的调优方向逐个扫描配置。建议收藏备用等你有新 GPU 或者新模型上线时再把这套方法拿出来验证一遍。 H100上vLLM Serving调优：p95 TTFT与ITL双指标优化实践
这次我们来看一个 vLLM Serving 调优实验在 H100 平台上通过调整配置项把 p95 TTFT 和 ITL 都干过了 baseline。如果你正在做 LLM 推理服务压测或者准备把 vLLM 接入自己的业务这篇文章可以直接收藏。先说结论TTFT 和 ITL 是衡量大模型在线服务体验最核心的两个指标而它们并不只取决于 GPU 型号。同样的 H100、同样的模型权重vLLM 服务端的调度参数、显存分配策略、是否启用 CUDA Graph、并发队列深度都会显著影响 p95 表现。本文会从指标含义讲起然后给出 vLLM 在 H100 上的部署方式、baseline 构建方法、config 调优思路、接口调用示例和一套可复用的压测验证流程。vLLM 是目前最主流的开源 LLM 推理服务框架之一由加州大学伯克利分校团队开源核心优势是 PagedAttention 显存管理和 Continuous Batching 连续批处理。它能把离散的 KV Cache 分页管理提高显存利用率同时在不打断已生成请求的前提下动态插入新请求。对于生产环境来说vLLM 提供 OpenAI 兼容的 HTTP API可以比较平滑地接入已有业务。如果你正准备做类似实验建议先把这几点搞清楚你的服务是追求首字延迟还是整体吞吐你的请求是短文本多并发的在线场景还是长文本少并发的离线场景这两类场景对 config 的要求完全不同。下面进入正题。1. vLLM Serving 核心能力速览先给一张规格表快速判断这个框架和这次实验的适用范围。能力项说明项目类型开源 LLM 推理服务框架核心机制PagedAttention、Continuous Batching、CUDA Graph、Prefix Caching主要功能模型加载、并发推理、流式输出、OpenAI 兼容 API、离线批量推理推荐硬件NVIDIA H100 等高性能 GPU也可在 A100、L40S、4090 等显卡上运行支持平台Linux 为主Windows 支持有限需按版本确认启动方式Python CLI、Python 脚本内嵌、Docker 部署接口能力OpenAI 兼容/v1/chat/completions、/v1/completions接口批量任务支持离线 Batch 推理和在线并发请求性能指标TTFT、ITL、TPOT、吞吐量、显存占用、利用率适合场景在线聊天服务、RAG 检索问答、LLM API 网关、批量文本生成从实验标题看H100 只是硬件底座真正的胜负手是 config。后面会逐个拆解哪些配置项会影响 p95 TTFT 和 ITL。2. TTFT 与 ITL两个关键指标的实验背景2.1 TTFT首 Token 延迟TTFT 全称 Time To First Token指从客户端发出请求到收到第一个 token 的时间。用户输入完内容后最直观的感受就是“多久开始出字”所以 TTFT 是聊天机器人、智能客服这类交互场景的第一体验指标。p95 TTFT 表示 95 分位首 token 延迟。为什么实验用 p95 而不是平均值因为在线服务的体验差往往来自尾部请求。平均延迟低不代表每个用户都快只要有一小部分请求因为排队、调度抖动、长 prompt 处理而变慢就会拉高 p95。对生产环境来说p95 TTFT 是比 mean TTFT 更靠谱的稳定性指标。影响 TTFT 的主要因素包括Prefill 阶段的计算量输入 prompt 越长prefill 耗时越大。请求排队情况并发请求过多新请求要等前面的请求释放批处理槽位。显存中 KV Cache 的可用空间显存不足时PagedAttention 可能拒绝新请求或触发抢占。调度策略vLLM 的调度器决定什么时候把新请求加入批处理。2.2 ITLToken 间延迟ITL 全称 Inter-Token Latency指模型生成过程中相邻两个 token 之间的时间间隔。它反映的是“出字速度”也就是流式输出时每秒钟能吐出多少 token。ITL 越低生成越连贯用户在流式接口上感受越流畅。工程上可以看到两个相近指标TPOTTime Per Output Token单个输出 token 的平均耗时。ITL两个 token 之间的实际间隔。二者在流式输出场景下基本等效。实验标题把 ITL 和 p95 TTFT 并列说明这次调优既要照顾首字响应又要保证整体生成速度。影响 ITL 的主要因素包括Decode 阶段的批处理大小并发越高每个请求分到的 GPU 算力越少ITL 可能增大。是否使用 CUDA GraphCUDA Graph 可以减少 kernel launch 开销提升小 batch 场景下的 decode 速度。模型长度、输出长度长序列生成时 KV Cache 更大访存压力更高。显存带宽H100 的 HBM 带宽接近 3.35TB/s但多请求共享时仍有竞争。2.3 指标之间的取舍TTFT 和 ITL 存在天然的 trade-off。如果为了让 p95 TTFT 更低而一味把并发限制收紧每次只处理少数请求那 GPU 利用率下降单请求 ITL 可能更好但整体吞吐量上不去。反过来如果为了吞吐把批处理规模拉满prefill 阶段的大批量计算可能让后面排队的新请求 TTFT 飙升。所以实验标题里“config beats the baseline on p95 TTFT,ITL”的真正含义是在某个并发和流量模型下找到一组配置让两个指标同时优于默认配置而不是无脑压榨某一个指标。3. 实验环境准备与 vLLM 部署3.1 硬件环境H100 是目前大模型推理的顶级选择之一。常见配置是 80GB HBM3 显存支持 FP8、BF16 等精度。如果你的服务器没有 H100A100 80GB、H800、L40S 甚至 4090 也可以做类似实验只是绝对数值不同调优思路是一样的。需要注意显存大小直接决定能加载多大的模型、能留多少空间给 KV Cache。例如加载 70B 级别模型用 BF16 精度权重就要占用约 140GB单张 H100 跑不动一般会配合张量并行或量化方案。实际能跑多大的模型需要看权重格式、上下文长度和并发规模建议先按常规配置估算再在小参数下实测验证。3.2 软件环境推荐环境操作系统Ubuntu 22.04 / 24.04GPU 驱动CUDA 12.1 或更高版本Python3.10 或 3.11PyTorchvLLM 通常锁定对应版本安装时会自动解析vLLM最新稳定版或指定版本安装前先检查显卡驱动nvidia-smi输出里有驱动版本和 CUDA 版本号确认 GPU 能被识别。之后创建虚拟环境并安装 vLLMpython -m venv vllm_env source vllm_env/bin/activate pip install --upgrade pip pip install vllm如果网络较慢可以换成国内 PyPI 镜像pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple3.3 Docker 部署可选vLLM 官方也提供 Docker 镜像。生产环境推荐 Docker 方式因为依赖隔离更彻底也方便在 GPU 服务器之间迁移。镜像名和 tag 需要在官方仓库确认一般形如vllm/vllm-openai。docker pull vllm/vllm-openai:latest docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model 模型路径注意区分本地 PyPI 安装方式更灵活Docker 方式更适合发布和部署二选一即可不需要同时配两套。4. Baseline 服务搭建与压测方法4.1 用默认配置启动 Baseline实验的第一步是搭建 baseline。定义 baseline 为“用 vLLM 最朴素的启动参数启动服务不做任何调优”。这样后续所有优化效果才有对照。假设模型已经下载到本地使用一个 70B 级别的大型模型进行测试用 4 张 H100 做张量并行python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-70b启动后终端会出现服务的监听地址和模型加载信息。用以下命令确认服务正常curl http://127.0.0.1:8000/v1/models返回结果包含模型名称和元信息说明服务已经就绪。这时如果把参数全默认就是 baseline。4.2 压测前的请求设计在线 LLM 服务的请求模式很重要。做 TTFT 和 ITL 实验时需要设计几组不同特征的请求短 prompt 短输出模拟简单问答例如 prompt 长度 100 token 以内。长 prompt 短输出模拟 RAG 场景先给模型一大段资料再要求总结。短 prompt 长输出模拟文章生成、代码生成。混合请求以上三种按比例混合。每组请求数建议在 100 到 500 条之间太少了测不出 p95 的稳定性太多了浪费时间。4.3 手写一个指标采集脚本vLLM 的 OpenAI 兼容接口可以直接用requests请求。写一个 Python 脚本记录每次请求的 TTFT 和 ITLimport json import time import requests url http://127.0.0.1:8000/v1/completions payload { model: qwen-70b, prompt: 介绍一下杭州西湖的景点特色。, max_tokens: 500, temperature: 0.7, stream: True } # 记录从发出请求到收到第一个 token 的时间 start time.perf_counter() first_token_time None token_timestamps [] with requests.post(url, jsonpayload, streamTrue, timeout300) as resp: for line in resp.iter_lines(): if not line: continue line line.decode(utf-8) if not line.startswith(data:): continue now time.perf_counter() if first_token_time is None: first_token_time now ttft now - start token_timestamps.append(now) else: token_timestamps.append(now) itl_list [ token_timestamps[i 1] - token_timestamps[i] for i in range(len(token_timestamps) - 1) ] avg_itl sum(itl_list) / len(itl_list) if itl_list else 0 print(fTTFT {ttft:.4f}s) print(f平均 ITL {avg_itl:.4f}s) print(fITL p95 {sorted(itl_list)[int(len(itl_list) * 0.95) - 1]:.4f}s)这个脚本可以单测也可以在外面套一层循环做并发。如果要更严谨的压测推荐使用 Locust、wrk、vegeta 这类工具或者用 vLLM 仓库自带的benchmark_serving.py脚本。4.4 用 vLLM 自带压测脚本vLLM 仓库中通常带有一组 benchmark 脚本用于测量吞吐和延迟。这是比较标准的方式可以在启动服务后在另一台机器或另一个终端运行python benchmarks/benchmark_serving.py \ --backend vllm \ --model qwen-70b \ --tokenizer /data/models/qwen-70b \ --dataset-path ./sampled_requests.json \ --request-rate 10 \ --num-prompts 200 \ --port 8000注意脚本的位置和参数可能随版本变化用之前先看一下仓库里的 README 或脚本帮助信息。5. config 调优从 Baseline 到优化配置这部分是实验的核心。在 H100 上vLLM 有多个配置项会影响 p95 TTFT 和 ITL。下面按影响程度逐个梳理。5.1 gpu-memory-utilization显存利用率上限vLLM 默认把 GPU 显存的 90% 用于模型权重和 KV Cache。如果你的场景是长 prompt 多并发可以把上限调低防止显存不足导致请求被拒绝--gpu-memory-utilization 0.95不过别盲目拉高。显存利用率过高时KV Cache 空间增大能同时处理的序列更多但当请求队列变大后prefill 阶段占用的算力和显存会增加p95 TTFT 可能恶化。从材料看L20 双卡运行、qwen3.5 9b 爆显存等问题多半也是显存分配策略没调好。建议在 0.85 到 0.95 之间做小范围扫描。5.2 max-num-seqs并发序列上限这个参数直接决定 vLLM 在 decode 阶段最多同时处理多少个序列。默认值通常是 256。调大后吞吐量可能上升但单请求的 ITL 会恶化调小后每个请求能分到更多 GPU 资源ITL 更稳但 GPU 利用率可能下降。针对 p95 TTFT 的调优通常先从减小max-num-seqs开始。如果并发请求数少过大的队列上限并不会让第一个 token 更早出现反而可能让调度器积压请求。--max-num-seqs 128最后用多少取决于你的真实并发模型。建议基于压测时观察到的请求量和排队情况来定。5.3 enforce-eager是否启用 CUDA Graph这是一个常见的调优入口也是热词中出现频率很高的问题--enforce-eager到底有什么影响vLLM 默认会为模型捕获 CUDA Graph把一组 kernel launch 固化下来减少 CPU 调用 GPU 的开销。好处是 decode 阶段更快ITL 更低坏处是首次捕获时耗时较长且会占用额外显存。--enforce-eager表示禁用 CUDA Graph每次推理都走常规的 eager 执行方式。--enforce-eager开启--enforce-eager的效果通常是显存占用降低、启动时间变短但 ITL 可能变差。如果你的实验发现 p95 TTFT 偏高而 GPU 显存接近上限可以试着开--enforce-eager并调整gpu-memory-utilization对比 ITL 变化。不过 vLLM 较新版本里 CUDA Graph 已经是核心优化之一默认开启的收益通常大于开销。建议在同一个模型、同一批压测请求下分别测试开关两种状态优先保留效果更好的配置。5.4 max-model-len最大序列长度--max-model-len控制模型支持的最大上下文长度。如果把长度设得过大比如 32K那么 KV Cache 预分配会被推高能并发的序列数量减少如果设小能处理更长上下文的场景就不能用。--max-model-len 16384如果你的 prompt 长度集中在 2K 以内没必要把 max-model-len 设置成 32K。过大的序列长度会挤占 KV Cache 空间影响 p95 TTFT。5.5 chunked-prefill分块预填充vLLM 支持把长的 prefill 请求拆成小块穿插到 decode 请求中执行。这样做可以减少长 prompt 请求对后续短请求的阻塞对 p95 TTFT 非常有效。--enable-chunked-prefill如果你在实验中发现“长 prompt 请求把一批短请求堵住了”chunked prefill 是第一个要试的开关。它会略微增加调度复杂度但通常能让长尾延迟明显下降。5.6 调度策略与 Prefix CachevLLM 的调度器支持不同的排序策略整体影响请求到达后多久能进入批处理。若选择了不合适的调度策略在并发到达时会看到不稳定的 p95。另外如果你的场景有大量重复系统提示词或共享上下文前缀建议开启前缀缓存--enable-prefix-caching开启后相同前缀的 KV Cache 可以复用prefill 时间明显下降TTFT 会更稳定。这对 RAG、Agent 类固定 system prompt 场景非常关键。5.7 一套可参考的优化配置综合上面实验思路给出一个相较 baseline 更可能改善 p95 TTFT 和 ITL 的启动命令python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-70b \ --gpu-memory-utilization 0.92 \ --max-num-seqs 128 \ --max-model-len 16384 \ --enable-chunked-prefill \ --enable-prefix-caching这个配置不一定在每个场景都是最优解但它代表了一个完整的调优方向。最终参数需要在你的流量模型下做小步扫描。配置项Baseline 值优化方向影响指标gpu-memory-utilization默认 0.900.85~0.95 扫描显存余量、并发容量、TTFTmax-num-seqs默认 256按并发模型调小ITL、吞吐enforce-eager默认关闭 CUDA Graph 优化对比开关效果ITL、显存、启动时间max-model-len默认大值按实际上下文收紧KV Cache 容量、TTFTenable-chunked-prefill默认关闭开启长 prompt 场景 p95 TTFTenable-prefix-caching默认关闭相同前缀场景开启TTFT、prefill 耗时注意上面表格中的参数值是 vLLM 的常见示例值具体以你的 vLLM 版本和模型为准。调优时不要一次改多个参数否则区分不出是谁的贡献。6. 功能测试与效果验证6.1 单请求验证确认服务正常先用单个请求验证优化后的配置没有破坏基本功能curl http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d { model: qwen-70b, prompt: 用一句话解释什么是KV Cache。, max_tokens: 100, temperature: 0.4 }正常返回包含choices、usage等字段。这一步重点是确认模型加载正常、可以生成文本。6.2 并发压测对比 p95 TTFT 和 ITL重点来了。用同一组请求数据分别对 baseline 服务和优化后的服务做压测。具体做法先启动 baseline 服务跑一组压测记录 p95 TTFT 和平均 ITL。停止服务用优化配置重新启动。等模型加载完成再跑同一组压测。对比两份结果。判断标准p95 TTFT 有明显下降说明调度和 prefill 优化生效。平均 ITL 没有显著变差说明没有为了首字延迟牺牲生成速度。如果 p95 TTFT 下降但平均 ITL 明显上涨说明配置太激进并发能力被压得太低。如果两个指标同时优于 baseline就验证了标题里的结论。6.3 长 prompt 与短 prompt 分别观察长 prompt 场景下重点看 chunked-prefill 是否减少了请求间的互相阻塞。短 prompt 场景下重点看 max-num-seqs 对 ITL 的影响。建议在压测结果中按请求类型分组分别统计 p95 TTFT 和平均 ITL而不是只看总体平均值否则长请求和短请求的差异会被互相掩盖。6.4 连续压测观察稳定性在线服务还会遇到流量抖动。在压测脚本里设置一个持续 3 到 5 分钟的固定请求速率观察每 10 秒的 p95 TTFT 是否波动。如果出现某段时间 p95 突然飙升需要看是不是显存碎片、CUDA Graph 内存膨胀或后端队列堆积导致。vLLM 启动时可以挂载 metrics 监控把指标接到 Prometheus 或直接看日志。7. 接口 API 与批量任务7.1 OpenAI 兼容接口vLLM 启动后默认提供 OpenAI 兼容接口这是接入成本最低的方式。聊天的标准路径是curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen-70b, messages: [ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 请举例说明vLLM的Continuous Batching机制。} ], max_tokens: 300, temperature: 0.6 }流式输出时加上stream: true服务端会以 SSE 格式逐 token 返回。前端可以像 ChatGPT 那样打字机效果展示。7.2 批量任务离线推理除了在线 APIvLLM 还支持离线批处理。你可以在 Python 脚本里直接构造LLM实例一次处理多段文本from vllm import LLM, SamplingParams llm LLM( model/data/models/qwen-70b, tensor_parallel_size4, gpu_memory_utilization0.92, max_model_len16384, enable_prefix_cachingTrue ) sampling_params SamplingParams( temperature0.6, max_tokens500 ) prompts [ 总结这份会议纪要..., 写一个Python函数实现快速排序。, 解释RAG的工作原理。 ] outputs llm.generate(prompts, sampling_params) for output in outputs: print(output.outputs[0].text)离线批量任务适合不要求实时性的场景比如批量文档分析、离线报告生成、数据清洗。运行前要确认输入文本数量和长度避免一次性请求过多导致显存溢出。7.3 并发调用示例在线服务接入业务时通常用异步并发调用。下面是一个用concurrent.futures做并发请求的模板import concurrent.futures import requests import json url http://127.0.0.1:8000/v1/completions headers {Content-Type: application/json} def call_once(prompt): payload { model: qwen-70b, prompt: prompt, max_tokens: 200, temperature: 0.7 } resp requests.post(url, jsonpayload, headersheaders, timeout120) return resp.json() prompts [f写一段关于主题{i}的短文 for i in range(20)] with concurrent.futures.ThreadPoolExecutor(max_workers8) as executor: results list(executor.map(call_once, prompts)) print(json.dumps(results[0], ensure_asciiFalse, indent2))多线程并发数是客户端视角实际服务端的max-num-seqs才是真正决定同时处理多少请求的参数。客户端并发率超过服务端处理能力后只会增加排队不会让吞吐继续增长。8. 资源占用与性能观察8.1 显存占用观察用nvidia-smi实时查看多卡显存分布watch -n 1 nvidia-smi关注每个 GPU 的显存使用率、温度、功率和利用率。vLLM 会把一部分显存预留给 KV Cache启动后显存占用不是立刻打满而是在第一个请求进来后逐步分配。8.2 vLLM Metrics 与日志vLLM 支持输出 Prometheus metrics。启动时加上相关参数或通过nginx反代暴露metrics端点。常见观察项包括请求数量、排队的请求数量。正在处理的序列数量。显存中 KV Cache 的使用量。平均 TTFT 和 ITL。拒绝的请求数量。这些指标能帮助你判断 p95 TTFT 变差是因为排队还是因为显存不足还是因为单请求推理本身变慢。8.3 性能观察建议观察性能时不要只看 GPU 利用率。如果 GPU 利用率很低但 TTFT 很高问题可能在 CPU 侧的 tokenizer、调度器或网络层。如果 GPU 利用率很高但 ITL 很高问题可能在 decode 批处理过大或显存带宽不足。调优时要结合指标定位而不是盲目改参数。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动报显存不足模型权重超过显存容量nvidia-smi查看显存换更小模型或降低精度使用量化、张量并行、降低 gpu-memory-utilizationqwen 等模型加载后爆显存max-model-len 过大KV Cache 预留过多查看启动日志中 KV Cache 大小调小 max-model-len 或降低并发上限p95 TTFT 偏高且不稳定长 prompt 请求阻塞短请求开启 chunked-prefill 对比测试启用--enable-chunked-prefill.enforce-eager后生成变慢禁用了 CUDA Graph对比开关前后 ITL优先保留默认 CUDA GraphvLLM 在 Windows 上装不上依赖的 CUDA 组件在 Windows 下支持有限查看官方支持矩阵使用 WSL2、Docker 或 Linux 环境L20 上双卡无法并行推理张量并行需要满足显存和总线条件检查驱动、总线、模型大小确认多卡通信正常或减小张量并行数API 调用返回 404模型名或接口路径不对请求/v1/models确认模型名修改--served-model-name或请求中的 model 字段批量任务卡住输入列表中有超过 max-model-len 的文本检查每个输入的长度先做文本截断或拆分端口冲突8000 端口被占用lsof -i:8000或netstat -tlnp换端口或结束占用进程还有一些热词中提到的现象值得注意qwen3.6 35b a3b 的 TTFT 比较高这类情况很可能不是 vLLM 配置问题而是模型本身 structure 导致 prefill 计算量较大。建议先确认同模型在不同框架下的 TTFT 对比。vLLM 可以在 Windows 10 中使用吗这个问题要看版本。vLLM 核心依赖 PyTorch CUDA 生态Windows 支持一直相对保守更稳妥的做法是使用 WSL2 或 Linux 容器。vLLM 不支持在昇腾 910b 上启动 embedding 和 reranker 模型这类情况通常涉及自定义模型实现需要确认该模型架构是否被 vLLM 支持必要时改用 API 网关或专用推理后端。10. 最佳实践与使用建议先跑小参数测试再上生产配置。第一次启动尽量选一个小模型、低并发确认链路通了再切换到正式模型。保留一组最小可运行配置。我在实验时会把 baseline 的命令写成一个脚本文件任何一次调优失败都可以快速回滚。# baseline.sh python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen-70b \ --tensor-parallel-size 4 \ --host 127.0.0.1 \ --port 8000模型文件、输入数据、压测结果、日志分目录管理。建议这样组织~/vllm_experiment/ ├── models/ ├── prompts/ │ ├── short_query.jsonl │ ├── long_doc.jsonl │ └── mixed.jsonl ├── logs/ ├── results/ │ ├── baseline_20240101.json │ └── optimized_20240101.json └── scripts/ ├── start_baseline.sh ├── start_optimized.sh └── run_benchmark.py批量任务必须加日志和失败重试。离线推理跑几十万条文本时总会有几条因为网络、显存抖动或超时而失败。建议记录每一条的请求 ID 和状态失败的任务重新入队。接口服务要限制访问范围。vLLM 默认监听地址如果你设成了0.0.0.0意味着局域网内所有机器都能访问。生产环境建议通过防火墙或反向代理控制访问权限必要时加 API Key。涉及模型权重、训练数据、用户 prompt 的隐私边界。部署前要确认模型权重来源是否允许商用或二次分发输入数据是否包含个人信息。涉及人脸、声音、版权素材时必须先确认授权。压测时不要使用真实用户数据用脱敏后的测试数据集。发布或商用前做效果复核。p95 TTFT 和 ITL 是服务性能指标但输出质量同样重要。调优配置后要人工复核一批生成结果确认没有因为配置改动导致采样参数异常或输出截断。11. 总结与下一步这次 vLLM Serving 实验最值得尝试的点就是验证“同一块 H100配置不同性能表现可以差很多”。p95 TTFT 和 ITL 不是单纯由 GPU 决定的vLLM 的显存利用率、并发序列上限、CUDA Graph、chunked prefill、prefix cache 都会影响最终的服务体验。最先应该验证的功能是baseline 服务能不能正常启动并返回结果。压测脚本能不能正确采集 TTFT 和 ITL。用优化配置跑完后p95 TTFT 和平均 ITL 是否同时改善。最容易踩的坑是一次改太多参数出了问题不知道是谁导致的。所以每次只改一个配置跑完记录结果再改下一个。后续可以继续扩展的方向把压测数据接入 Prometheus 和 Grafana做长期监控对比 sglang 和 vLLM 在相同模型下的 p95 差距在 8 卡 H100 上测试更大的模型并行把调优后的配置封装成容器镜像方便在不同服务器间复用。如果你正在做 LLM 服务的性能优化可以先拿手边的模型跑一组 baseline记录下当前的 p95 TTFT 和 ITL再按文章里的调优方向逐个扫描配置。建议收藏备用等你有新 GPU 或者新模型上线时再把这套方法拿出来验证一遍。