用 vLLM 跑 Qwen，卡住的地方往往不是装不上，而是装上了不知道参数怎么给：显存不够、并发上不去、长上下文一加就崩、输出乱码或中途断流。这篇按实际部署顺序给一套配方思路——先确认模型与权重格式能不能被当前版本吃下，再定显存与并发的档位，然后才是调参和排查。所有涉及具体数值的地方，都以你机器上实测和你所用版本的实际行为为准，别照抄别人的截图。
用 vLLM 跑 Qwen，卡住的地方通常不是装不上，而是装上了不知道参数怎么给：显存不够、并发上不去、长上下文一加就崩、输出乱码或中途断流。这篇按实际部署顺序给一套配方思路——先确认模型与权重格式能不能被当前版本吃下，再定显存与并发的档位，然后才是调参和排查。
有个前提说在前面：所有涉及具体数值的地方，都以你机器上实测和你所用版本的实际行为为准，别照抄别人的截图。下面每一步都给出判断标准和验证动作，照着做一遍，你就能摸到自己环境的那条线。
开跑之前的四项核对
先跑一次最小加载，别一上来就挂并发。很多人省掉这一步，结果报错信息里混着并发、显存、格式三件事，根本分不清是哪出的问题。最小加载能通过，说明权重、分词器、chat template 这三样基本齐了，后面才谈得上调优。
- 核对权重加载用最小命令加载目标 Qwen 权重，只看能不能起来。权重格式、分词器文件、chat template 三样缺一样都会在起服务时才报错；打不开就先换更小的模型或更低的量化档位验证环境。
- 核对上下文与量化说明看模型卡里的上下文长度和量化说明，反推你要留多少显存给 KV cache。这一步决定后面的并发上限，不要边跑边试。
- 写清目标是单路低延迟对话，还是多路批量吞吐？两种目标的参数方向相反，先写下来再调，否则调着调着就自相矛盾。
- 准备固定请求准备一份固定提示词、固定长度的请求，后面所有调参都拿它前后对比。没有基准，任何改动都说不清是好是坏。
显存、上下文与并发怎么配
顺序是：先算权重占地，再看剩余显存能放多少 KV cache。上下文越长、并发越高，KV cache 吃掉的显存增长越快，通常先撞它、再撞权重。所以显存不够时，优先考虑降上下文、降并发、加量化，而不是硬调批处理参数——硬调只会把报错推后。
| 现象 | 先看什么 | 调整方向 |
|---|---|---|
| 一启动就显存不足 | 权重占地 + 上下文预算 | 降量化档位、降上下文长度 |
| 单路能跑，多路就崩 | KV cache 余量 | 先降并发，再评估要不要降上下文 |
| 并发越高总吞吐反而越低 | 是否压过拐点 | 逐档回退，找自己机器上的拐点 |
| 长输入必崩、短输入正常 | 最长输入的预算 | 按真实业务最长输入设上下文，留余量 |
- 不要一次把上下文拉到模型上限，按真实业务里最长的输入来设，留出余量比压满上限稳。
- 并发不是越大越好：生成速度会先升后降，压过拐点后每路都变慢，用固定请求逐档加压找拐点。
- 加量化是省显存最直接的一招，但要在能接受输出质量的前提下再上。
- 显存账要按最坏情况算：同一时刻所有并发都跑到最长输入，这才是峰值。
调参顺序：一次只动一个旋钮
按这个顺序动：加载能不能过 → 单请求能不能出完整结果 → 单请求速度是否可接受 → 多路并发是否稳定。跳步会出现找不到原因的现象，比如并发不稳其实是单请求就没跑干净。
- 加载类参数
- 决定模型能不能起来，改错了直接报错，优先级最高。
- 吞吐与缓存类参数
- 影响并发和显存占用，每次只改一项，用固定请求前后对比。
- 采样参数
- 温度、top_p、重复惩罚只影响输出质量，不影响显存和吞吐，别和上面两类混在一起调。
输出中途断流、结尾截断，先查输出长度上限与上下文总预算，再怀疑采样参数。很多时候不是模型不会说，是预算被前面吃完了，后面没位置写。涉及吞吐与缓存的参数改动，每次只改一项；改两项以上就说不清是谁的功劳。
出问题时的排查顺序
先分清是哪一类错：加载阶段报错（权重、版本、格式）、启动阶段报错（显存、端口、驱动）、运行阶段报错（显存溢出、超长、断流），三类的处理方向完全不同。分错类，越查越乱。
- 定位阶段看报错发生在加载、启动还是运行阶段，先把范围缩到三分之一。
- 换小验证加载类问题优先换更小的模型或更低的量化档位验证环境是否通，能跑通说明是资源问题不是版本问题。
- 看趋势运行中显存缓慢上涨、越跑越慢，多半是长请求或并发堆积，先降并发观察趋势，别急着改模型。
- 读日志关注报错那一行往上两三行，真正的诱因常在前面；单独看最后一行容易误判。
能把问题归到哪一类，比急着改参数更有用。
什么情况下这套配方不适用
这套配方假设你有一张能装下目标模型的卡，且目标是稳定服务。下面几种情况，调参不是主线，换路子更划算。
- 只有一张消费级卡、想跑远超显存的大模型：与其反复调参，不如换更小的模型或量化档位，或者看看别的推理框架是否更合适。
- 单用户、偶尔问几句的本地场景：常驻显存与启动成本可能不划算，先确认你的使用频率撑得起。
- 需要频繁改模型、试很多个权重：先解决模型管理，而不是把调参当主线；每次换模型都要重新走一遍前面的核对。
想横向比较不同框架或托管方案在你这类负载下的表现，可以到站内的对比与测速页面看当时的数字，别拿别人的截图当结论。
下一步把你的实际显存、上下文和并发档位带到站内模型资料库与测速页面核对，再决定要不要换框架或加量化。→常见问题
vLLM 跑 Qwen 加载就报错，先查什么？
按这个顺序：一是当前 vLLM 版本与权重格式是否匹配，二是分词器和 chat template 文件是否齐全，三是显存是否够加载（不够会直接失败）。先拿一个小模型或低量化档位跑通，能通说明环境没问题，问题在资源或权重本身；不通再查版本与安装方式。
上下文拉长就崩，是不是只能换大卡？
不一定。上下文变长主要吃 KV cache，先降并发、再考虑降低单次上下文，往往能救回来。真正需要换卡的情况是：短上下文单请求都跑不动，或者你确实需要同时支持很多路长上下文请求。判断依据用你自己机器上的实测，别照搬别人的配置表。
采样参数会不会影响速度和显存？
基本不影响显存和吞吐，主要影响输出质量和长度。温度、top_p 这类参数调的是「怎么选下一个词」；显存和并发由模型规模、量化、上下文、并发数决定。调优时把这两类分开动，否则没法归因。
