vllm部署deepseek-r1

用 Ollama 试推理模型很省事，但真要做多人并发的接口，很多人会转向 vLLM。麻烦通常不是「装不上」，而是权重加载报错、显存不够、参数不知道改哪个、起来之后吞吐还不如预期。这篇按上线顺序走一遍：先定硬件与权重形态，再起服务，最后给出一个从日志到参数的排查顺序，顺带说明什么情况下你其实不该用 vLLM。

用 Ollama 试推理模型确实省事，一条命令拉下来就能聊。但真要做成多人并发的接口，很多人会转向 vLLM，因为它在批量调度和显存利用上更适合长驻服务。麻烦通常不是「装不上」，而是权重加载报错、显存不够、参数不知道改哪个、起来之后吞吐还不如预期。这篇按上线顺序走一遍：先定硬件与权重形态，再起服务，最后给出排查顺序，顺带说明什么情况下你其实不该用 vLLM。

先提醒一句：下面涉及具体数字的地方都不写死，因为你手上的卡、量化档位、上下文长度不同，结论会差很多。参数含义和折算去站内工具页对照，价格和型号资料到模型库核对，别照抄别人的配置单。

动手前先确认三件事：权重、显存、并发预期

权重形态是第一道坎。先分清你拿到的是原始权重、量化权重还是别人转过的格式，vLLM 对权重格式和分词器文件有明确要求，缺配置文件或分词器时加载阶段就会挂，而且报错信息往往不直接指向根因。下载完先列一遍目录，确认配置、分词器、权重文件都在，再谈启动。

原始权重

未量化的完整权重，精度高但显存占用最大，适合显存充裕且要最好效果的场景

量化权重

用低比特表示权重，显存占用明显下降，代价是效果和兼容性要自己验证

转换过的格式

第三方转出的格式，优先确认来源和完整性，否则加载失败很难定位

• 显存按参数量加量化档位估，单卡放不下就要提前决定张量并行还是换量化，别启动失败才想这件事；具体型号怎么折算去 /models/deploy 按你手上的卡算一遍
• 先写下你要的并发数和可接受的首字延迟，这两个数决定后面所有参数值，没有它调参就是瞎调；参考基线可以到 /tools/speed-test 量一个
• 确认服务是内网自用还是对外提供，这决定监听地址怎么设、要不要加一层网关，暴露范围的判断参考 /safety

起服务的顺序：先把单卡跑通，再加并行和参数

第一步只用最简参数起服务，能出结果再谈优化。很多人一上来就把显存占用比例、最大上下文、并行度全堆上去，结果启动失败，连是哪个参数导致的分不清。参数含义先对照 /tools 里的换算工具理解，不要照抄别人的配置单。

1. 最简参数起服务只指定模型路径和必要项，发一条最短请求确认能出结果，验证方式是看返回内容是否正常而不是只看进程活着
2. 逐项加参数依次加显存占用比例、最大上下文长度、并行度，每加一项跑一次短请求，出问题立刻知道是哪一项引起的
3. 设监听地址对外提供接口时按内网需要设置监听地址和端口，别默认暴露到公网，暴露范围与风险判断参考 /safety
4. 量基线再压测并发和长度上限别一次拉满，先按 /tools/speed-test 量一个基线，再决定往上加的幅度

排查顺序：从加载失败到跑起来慢，一类一类排

出问题别乱改参数，按阶段分类排效率最高。加载阶段的问题和运行阶段的问题根因完全不同，混在一起改只会把能用的配置也改坏。下面按从启动到运行、从报错到变慢的顺序给一个排查路径。

• 加载阶段报错：先查权重完整性和版本匹配，再查显存是否被别的进程占着，最后才怀疑驱动和框架版本
• 能起但请求报错：先确认客户端发的字段和服务端预期结构是否一致，再用最短请求复现，排除是请求内容触发的问题
• 跑得慢：先分清是卡在排队还是卡在生成，前者调并发与批处理相关参数，后者看量化档位和上下文长度
• 显存随请求增长直到爆掉：通常是长上下文加高并发叠出来的，压一压最大长度观察是否还复现，通用思路见 /tools/quality-monitor

排查时每改一个变量就复测一次，并且记录改动，否则改到最后自己都不记得初始配置是什么。如果是多人共用一台机器，先确认没有别人同时在跑任务抢显存。

什么情况下别用 vLLM

vLLM 不是所有场景的最优解。它的优势在多人并发和长驻服务，代价是部署链条更长、有版本升级和参数调整的维护量。如果你的场景不匹配，硬上只会多花时间。

评估维护人力比评估性能更重要，一个跑得飞快但没人管得动的服务，最后往往是被关掉的那个。