vllm 部署deepseek v4 flash

你手里有卡、有模型权重，想用 vLLM 把 DeepSeek V4 Flash 起成一个能对外扛并发的推理服务，结果卡在第一步：装哪个版本、权重从哪来、并行度怎么设、起来之后用什么证明它是真在跑而不是假装在线。这篇按部署工程师的实际顺序给一份可照做的清单，参数只讲怎么定不写死数字，具体规格和价格到站内对应页面核对。

你手里有卡、有模型权重，想用 vLLM 把 DeepSeek V4 Flash 起成一个能对外扛并发的推理服务。真动手时最卡人的不是模型本身，而是第一步：装哪个版本、权重从哪来、并行度切几份、起来之后拿什么证明它是真在跑而不是进程假装在线。这篇按部署工程师的实际顺序给一份可照做的清单。

全文只讲「怎么判断、按什么顺序做」，参数一律不写死数字——具体支持的模型清单、显存测算、接口延迟基线，都到站内对应页面按当时的数字核对。这样你换硬件、换量化档位时，这套判断逻辑还能继续用。

起服务之前：环境与权重先对齐

vLLM 迭代很快，新模型权重经常要求较新的主版本或专门的适配分支，版本对不上会在加载阶段直接抛错，而不是跑起来之后才发现。所以第一步不是写启动命令，而是把「权重格式 ↔ vLLM 版本 ↔ CUDA 驱动」这三者对到同一代上。支持哪些模型、哪个版本开始支持，去 vLLM 自己的发布说明核对，别照抄半年前的教程。

• 权重来源固定一处：要么用官方发布的原始权重，要么用社区已经转换好的格式，混着来最容易在加载时校验失败
• 下载前先看目标盘剩余空间够不够放下整个权重目录，不够就换挂载点，别下到一半中断
• 环境按「干净容器 + 固定版本」起步，先在容器里把一套能跑通的组合冻住，再谈多机多卡
• 本机裸装踩环境冲突的代价，通常远高于多花几分钟写个 Dockerfile

并行与显存参数怎么定，不靠猜

并行度的起点是显存测算，而不是「卡多就多切几份」。对着模型参数量、量化档位和单卡显存，先得出「一张卡装不下、需要几张」这个结论，再决定张量并行切几份。切多了卡间通信吃掉吞吐，切少了直接 OOM。显存和卡数的对应关系，可以到站内部署测算页按当时的模型规格算一遍。

张量并行是把单层切到多卡、降低单卡显存压力但通信频繁，适合卡在同一台机器内；跨机扩容时再引入流水并行，否则跨机通信会成为瓶颈。判断依据很简单：卡是否在同一节点内。量化档位是显存与质量之间的取舍，低位量化省显存、能塞进更少的卡，但对输出质量的影响因任务而异——要做长上下文或对细节敏感的任务，先在测试集上对比量化前后再决定。

有一种情况上面这套不适用：显存看着够、但并发一上来就崩。这多半不是并行度的问题，而是 KV 缓存和并发上限的关系没算清，应该回到并发与显存测算那条线重新估，而不是继续调并行参数。

起服务与验收：怎么证明它真的在跑

1. 组织启动命令按「模型路径 + 并行参数 + 端口 + 显存占用比例」四块来写；显存占用比例别一上来拉满，留出余量给并发时的 KV 缓存
2. 确认进程活着看进程有没有反复重启、日志里有没有权重加载失败或算子不支持的报错，这一步没过就别往下走
3. 打通单次请求用一个简单请求验证接口，确认返回的是正常文本，不是截断、乱码或空响应
4. 连续多请求压一压看延迟是否稳定；抖动很大说明并发或显存配置有问题，回到上一节重新估
5. 量出基线再上生产把延迟和吞吐记下来当参照，后续排查变慢才有对比。测速可以直接用站内的接口测速工具

还有一种情况要注意：如果服务前面挂了网关或中转，你看到的延迟不全是推理本身的开销。定位问题时先把链路分段，别把网关的耗时算到 vLLM 头上。想对比「直连 vs 经中转」的差别，可以顺手在站内中转站目录里挑一两家做对照实验。

起不来或跑不稳，按这个顺序查

排查最忌讳东一榔头西一棒槌。下面这个顺序是从「最常见、最容易验证」排到「最不常见、验证成本最高」，按它走能少绕很多路。

第一顺位永远是版本匹配，日志里通常有明确的算子或格式关键词。第二顺位区分 OOM 发生在哪个阶段：加载阶段 OOM 是权重放不下，推理阶段 OOM 是并发和缓存超了，两者要改的参数完全不同。第三顺位才轮到硬件适配——非主流加速卡或国产卡需要专门的适配分支，能不能跑取决于适配版本覆盖到的算子范围，别拿标准版的报错去套适配分支的问题。第四顺位才是模型本身：前面三条都排干净了还出问题，重新校验一遍文件哈希，比反复调参更快。