vllm recipe

看 vLLM 官方 recipe 最容易卡在两点：一是几十个参数不知道哪些跟你有关，二是照抄一份配置到自己机器上跑不起来。这篇不解释原理，只做一件事——把常见负载分成几类场景，每类告诉你要盯的参数、要改的开关、改完怎么验证。参数具体数值不建议照抄，按你的卡型和模型到站内部署测算页面现算。

看 vLLM 官方 recipe 最容易卡在两点：一是参数表几十项，不知道哪些跟你有关；二是照抄一份配置到自己机器上跑不起来，回头还不知道错在哪。这篇不解释调度原理，只做一件事——把常见负载分成几类场景，每类告诉你要盯的参数、要改的开关、改完怎么验证。

有个前提先说清楚：recipe 里给的具体数值别照抄，那是别人卡型和模型下的结果。按你自己的硬件和模型，到 /tools/speed-test 或者站内的部署测算页面现算一遍更靠谱。下面所有「调到多少」都以你自己测出来的基线为准。

先看 recipe 交代了哪些前提，别急着抄命令

官方 recipe 通常会在开头或注释里交代三件事：硬件档位、模型规模、量化格式。这三件缺一件，等于你换了一个场景，后面的参数都要重新判断。看到一份 recipe 的第一反应不是复制命令，而是核对这三条跟自己环境的差距有多大。

先说清楚什么情况下这套分法不适用：如果你跑的是多模态或者带特殊采样逻辑的模型，recipe 里有些参数是模型实现强绑定的，这类就别按上面的分类硬拆，老老实实跟着官方那份走，只改硬件相关的部分。

• 先核对硬件档位、模型规模、量化格式这三条，差距大就整份重新判断；
• 把参数按硬件、负载、模型三类分开，只改前两类，第三类别碰；
• 遇到报错先别乱试，去站内词典把参数含义对一遍；
• 一份 recipe 只当参考模板，不当可直接执行的命令

把负载对到场景：长文本、高并发、单卡、多卡

判断自己属于哪类场景，看的是业务的真实特征，不是你以为的特征。举个例子，一家 5 人小团队做文档问答，请求不多但每篇文档很长，这就是典型长上下文场景，跟高并发一点关系没有。先把这个定下来，再去找对应的参数区。

单卡场景最常见的错误是装不下还在调参数。装不下的正路只有两条：换量化档位，或者拆到多卡。硬调参数最多让服务勉强起来，请求一上量就崩，反而更难排查。多卡场景反过来，参数没配错却跑得很慢，先去查卡间通信和切分方式，别怀疑模型本身。

套用顺序：从能起来，到跑得快

很多人一上来就追求最优配置，结果服务起不来，连验证的机会都没有。正确的顺序是先让服务能起、能返回一条结果，这一步所有参数保持默认，只改必须改的硬件相关项。

1. 第一步：能起来只改跟硬件强绑的参数，其余默认。验证标准是服务启动成功、发一条最短请求能拿到正常返回。
2. 第二步：压一条真实请求用你业务里真实长度的提示词，看首字延迟和显存占用落在什么区间。这一步只记录，不调参。
3. 第三步：加并发找拐点逐步加并发，观察质量下滑和排队变长从哪个点开始。把并发上限定在拐点之前，不要贴着拐点跑。
4. 第四步：一次只改一处每轮只动一个维度并记录改动和结果。同时改两处以上，出问题分不清是谁的锅，等于白改。

这里要提醒一句：并发拐点不是固定值，跟你的卡型、模型、提示词长度都有关，今天测出来的拐点过段时间可能要重测。别把它当永久参数写死在配置文件里。

改完怎么验证，不行怎么退

验证方法要统一：用同一批提示词在改动前后各跑一遍，只比三项——首字延迟、总耗时、显存峰值。比的时候注意排除网络因素，接口层延迟基线可以先用站内测速工具跑一次，别把网络抖动算到配置头上。

• 同一批提示词，改动前后各跑一遍，固定三项指标对比；
• 先用站内测速工具拿到接口层基线，排除网络干扰；
• 报错先分「加载阶段还是推理阶段」，加载阶段看权重与显存，推理阶段看并发与上下文；
• 保留一份能跑通的旧配置，改坏直接回退；
• 不在坏配置上继续叠参数，越叠越乱

什么情况下不该急着回退：如果只是指标没到预期但服务稳定，那属于调优范畴，可以继续小步试。只有当服务起不来、返回明显异常、或者延迟翻倍以上，才走回退流程。分清楚「不好用」和「坏了」，能省不少来回折腾的时间。

配置不是一次调好的，是每次改一个变量、留一份能跑通的旧版本，慢慢逼近的。