vllm deepseek v3.1

想自己跑 DeepSeek V3.1，结果发现模型体积大、单卡放不下、并发一上来就 OOM，或者服务起来了请求却报错——这些坑基本都出在动手之前没算清楚。这篇按「先定运行形态、再定卡和并发、最后起服务」的顺序，给一份能照着走的部署路径和排查清单，价格和榜单类数字统一到站内页面核对。

想自己跑 DeepSeek V3.1，最先撞上的往往不是代码问题，而是体积和显存。单卡放不下、并发一上来就 OOM、服务起来了请求却报错，这些坑基本都在动手之前没算清楚。所以顺序建议反过来：先定运行形态，再定卡和并发，最后才起服务。

这篇给一份能照着走的部署路径和排查清单。价格、榜单、模型版本这类会变动的数字，一律不写死，统一到站内页面核对当时的数字，免得你照着过期结论配机器。

先定权重的形态，再谈跑不跑得动

很多人一上来就 pip 装 vLLM 然后直接指模型路径，结果发现加载方式和手里那份权重对不上。这一步必须先分清：你拿到的是原始高精度权重，还是社区量化过的权重，两者走的加载路径和启动参数不是一套，混着用启动参数一定报错。

• 确认权重是哪一种形态：原始权重和社区量化权重走的加载路径不一样，别用同一份启动参数硬套。
• 查当前 vLLM 版本有没有收录这个模型架构。架构没进官方支持列表时，要么改用带该架构的社区分支，要么把权重转换步骤单独跑一遍再加载。
• 许可证和商用边界先读明白。内部自用和对外提供服务的差别，去 /safety 和 /models 核对，别上线了才发现不能这么用。
• 把模型目录的实际结构打出来看一眼，确认配置文件和权重分片都在，避免路径对但文件缺。

显存和并发：按「权重 + KV 缓存」两头算

显存占用不是只有权重那一块。权重按参数量和量化档位估，KV 缓存跟上下文长度、并发数、层数挂钩，两块加起来才是真实占用。只算权重，跑起来一加并发就爆。建议上限留出余量，别把卡吃满。

单卡放不下就上张量并行。注意卡数增加不等于吞吐线性翻倍，跨卡通信会吃掉一部分收益，所以先用小并发压一遍，再决定加不加卡。另外，上下文档位、最大并发、每序列最大输出长度这三个参数要一起调，只动其中一个通常看不到效果。

1. 先估算按权重加 KV 缓存两头估一遍，得到大致需要的卡数和上下文档位。
2. 再压测从小并发起步，逐步加，记录每档的表现，确认瓶颈在显存还是算力。
3. 最后定配置把验证过的参数写死成一份配置，别每次现场调。具体数字去 /models/deploy 和 /compute/sizing 对着算，别照抄别人的配置单。

起服务：参数顺序和自检动作

启动参数改一个重启一次的代价很高，所以先把几项关键参数定下来：显存占用模式、模型路径、并行度、端口。然后写成一份能复用的启动配置，后续调参只改其中一项，方便对比。

# 示意：先用小并发起服务，验证链路
vllm serve <模型路径> --tensor-parallel-size <卡数> --port 8000
# 另开一个终端发一条短请求
curl http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"<模型名>","messages":[{"role":"user","content":"hi"}]}'

• 服务起来后先发一条短请求验证链路通不通，再逐步加并发压测，别一上来就开满。
• 容器化部署时注意权重目录的挂载路径和显存设备透传。路径错和看不到卡是两类完全不同的报错，先分清再查。
• 首 token 延迟和整体吞吐要分开看，两者优化的方向往往相反，混在一起看会越调越乱。
• 用 /tools/speed-test 先量出你这台机器的基线，再去调参，否则改了不知道有没有变好。

跑起来之后：常见报错按这个顺序查

报错别看到哪条查哪条，按固定顺序走：权重能不能加载、卡能不能被识别、显存够不够、请求能不能过、并发出不出错。从上往下走，第一个卡住的环节就是你该动手的地方，跳步容易在错的层反复折腾。

加载阶段失败

多在权重格式和架构支持上，先确认权重形态和 vLLM 版本是否收录该架构。

运行阶段失败

多在显存切分和并行度设置上，先降并发和上下文长度复现，再判断是显存边界还是请求队列问题。

并发一高就报错

先降最大并发和上下文长度，确认是显存边界还是请求堆积，别直接怪硬件。