你可能已经在别处把 vLLM 跑起来了，现在要换成 Kimi K3，结果卡在权重能不能被识别、上下文和显存怎么配、并发一上来就 OOM。这篇不给一份抄了就能跑的固定命令，而是给一套组配方的思路：先确认模型与权重的兼容口径，再按显存反推张量并行和上下文上限，最后按报错类别往下查。每一步该去哪里核对当时的数字，都标了站内路径。
你可能已经在别处把 vLLM 跑起来了，手里也有一份能跑通的启动脚本，现在只是把模型换掉、换成 Kimi K3，结果第一步就卡住：权重目录放进去，框架认不认、tokenizer 对不对得上、上下文能开到多长、并发一上来就 OOM。这篇不给一份抄了就能跑的固定命令，那种东西换个环境就废。这篇给的是一套组配方的思路：先确认模型和权重的兼容口径，再按显存反推张量并行和上下文上限，最后按报错类别往下查。
配方里所有需要填数字的地方，这里都不写死。不同卡的显存不一样、不同时间的权重版本也不一样，写死的数字第二天就过期，还容易误导你。每处该核对的地方都标了站内路径，动手前先去那几个页面把当下的口径对一遍，比照抄别人的命令省事得多。
一份「配方」到底由哪几块组成
很多人把「配方」理解成一条启动命令，其实那条命令只是最后一步的产物。真正要准备好的是四件事，缺一件都跑不顺：模型权重和 tokenizer 从哪来、框架版本与后端内核怎么配、起服务时哪些参数必须显式指定、跑起来之后用什么方式验收。这四块里任何一块没对齐，表现出来都像是「跑不起来」，但排查方向完全不同。
| 组成部分 | 要确认什么 | 去哪核对 |
|---|---|---|
| 权重与 tokenizer | 架构是否被当前框架支持、分片是否完整、tokenizer 是否与权重同源 | 到 /ai-dict/category/tech 把架构和权重格式的名词对一遍 |
| 官方规格 | 上下文口径、支持的输入输出形态、是否有多模态分支 | 到 /official-api/providers/moonshotai 看基准页面的当时描述 |
| 启动参数 | 并行度、显存占用比例、上下文上限、批处理上限 | 到 /models/deploy 用测算工具过一遍再定 |
| 验收方式 | 短输入、长输入、并发、异常输入各跑一遍 | 参考 /tools/speed-test 的量化思路自建基线 |
先把官方规格页看一遍再动手，是因为本地要开多大的上下文，取决于业务真正需要多长，而不是取决于模型理论上能开多长。你按理论上限去配，显存就会被 KV cache 吃光。反过来，业务最长输入其实很短，却按上限配，纯属浪费。
参数调整的正确顺序：先显存，再上下文，最后并发
调参最容易犯的错是三个变量一起改，然后不知道是哪个起了作用。正确的顺序是固定的：先把显存账算清楚，再定上下文长度，最后才碰并发。这三步是有依赖关系的，前面没定死，后面调的数值都是浮的。顺序反了，你会一直在 OOM 和吞吐不达标之间来回横跳。
- 第一步，算显存账把权重占用、量化档位带来的压缩、KV cache 三块分开估，加总之后再留出运行时开销。参数量和显存的对应关系到 /models/deploy 用测算工具过一遍，别用别人的经验值套自己的卡。
- 第二步，定上下文上限从业务真正需要的最长输入倒推 max_model_len，不要一上来拉满。超长上下文带来的代价和溢出后的表现，在 /context-limit-overflow-fix-guide 里有对照案例，先读再定。
- 第三步，才调并发相关参数张量并行度与可用卡数、显存占用比例与批处理上限是联动的。调大并行度不一定提升吞吐，有时反而因为通信开销下降。具体口径到 /inference 看同款模型的实测记录，比拍脑袋靠谱。
- 每次只改一个变量改完立刻记下延迟和吞吐，用 /tools/speed-test 的方式先量出基线。否则你分不清是参数变好了，还是当时机器恰好空闲。
这套顺序也有不适用的时候。如果你的卡非常充裕、显存根本不是瓶颈，那第一步可以快速跳过，重点放在上下文和并发的取值上。反过来，如果卡很紧，第三步的并发就不要指望调优，直接按能跑起来的最小值配，把稳定性放第一位。
起不来的时候，按这个顺序排查
报错信息五花八门，但落到部署阶段无非三类：加载期、启动期、运行期。先判断报错落在哪一类，再往下查，比逐行读日志快得多。三类问题的典型特征和优先怀疑方向，下面这张表可以直接当排查入口用。
| 阶段 | 典型表现 | 优先怀疑与去向 |
|---|---|---|
| 加载期 | 报错发生在服务监听端口之前，涉及权重文件、分片、tokenizer | 权重格式与框架版本是否匹配，参考 /vllm-deepseek-weight-compat 的判断逻辑，方法可迁移 |
| 启动期 | 端口占用、显存不足、并行度与可用卡数对不上 | 先确认卡数和并行度一致，再到 /compute/gpus 核对卡的实际规格 |
| 运行期 | 服务起来了，请求一多或输入一长就崩 | 先降上下文和并发，再考虑量化档位，档位取舍边界见 /quantization-tier-choice |
加载期的问题优先怀疑权重与框架版本的匹配，这类问题换环境换版本都可能出现，排查逻辑是通用的，不必只盯着 Kimi 这一个模型。运行期 OOM 的处理顺序要克制：先降上下文和并发这两个可逆参数，再考虑动量化档位。盲目往下压精度，换来的是质量下降，而且很难回退判断到底是不是精度引起的。
上线前的验收清单和回退准备
服务能起来、能回一句话，不等于可以交出去用。验收要覆盖的是会真实发生的输入形态，而不是你顺手测的那一句「你好」。同时，验收之外还要留一条退路：上一版能跑的权重和参数配置放着别删，出问题时能快速切回去，而不是原地调参。
- 短输入：确认基本链路通，延迟在可接受范围；
- 接近上下文上限的长输入：这是最容易暴露 KV cache 配置问题的一项，必须有；
- 连续高并发：持续压一段时间，看显存是否缓慢上涨、响应是否劣化；
- 异常输入：空串、超长、特殊字符，确认不会把服务打挂；
- 记录台账：模型版本、框架版本、关键参数、实测吞吐各记一行，模型版本命名规则见 /model-name-version-suffix；
- 准备回退：上一版权重和参数配置保留，切回动作要事先演练过，别等到出事才第一次操作。
这套验收也不是所有场景都必须全套。内部工具、没有可用性要求的场景可以省掉并发压测那几项，但长输入这一项建议无论如何都跑一遍，因为它是配置问题最常见的暴露口。省掉哪一项，取决于出问题时能容忍多久的服务中断，这个尺度自己拿捏。
下一步把你现在的卡数和上下文需求带到 /models/deploy 过一遍测算，再回 /inference 对照同款模型的实测口径，配方基本就能定下来了。→常见问题
Kimi K3 能不能直接用现成的 vLLM 命令跑起来？
不一定。能不能跑取决于当前 vLLM 版本是否已经支持该模型的架构和权重格式。建议先去 /models 和 /official-api/providers/moonshotai 核对模型规格，再到 vLLM 的官方文档确认支持范围。如果还没支持，通常需要等上游更新或自己改适配层，硬跑大概率报加载错误。
上下文开多大合适，是不是越大越好？
不是。上下文直接吃 KV cache 显存，开得越大留给并发的显存越少。正确做法是从业务里真实的最长输入倒推一个值，再留一点余量。显存和上下文的换算关系可以到 /models/deploy 用测算工具算，别凭感觉拉满。
调参调不动了，怎么判断是参数问题还是机器不够？
先量基线：固定输入长度和并发数，用 /tools/speed-test 的方式记录延迟和吞吐，再每次只改一个参数复测。如果单请求就慢，偏机器和量化档位的问题；如果单请求正常、并发一上来就崩，偏并发和显存配置的问题。分开看才能定位。
