AI vLLM 限制显存 怎样处理

想限制 vLLM 显存，我会先用 gpu_memory_utilization 设置当前实例的显存使用预算，再结合 max_model_len 和 max_num_seqs 收紧上下文与调度规模。如果需要精确指定 KV 缓存，可考虑 kv_cache_memory_bytes，但它只限定 KV 缓存，不是进程总显存上限，而且设置后会覆盖基于比例推算缓存的方式。

显存比例、KV 缓存容量与并发规模不是同一个开关。预算调小不会让模型权重自动变小，也不等于获得操作系统级的显存隔离。

vLLM 官方参数入口：https://docs.vllm.ai/en/latest/configuration/engine_args/。下面给出的是我的配置取舍建议与原创启动示例，不是一次真实机器上的体验记录；没有实测峰值、吞吐或节省比例。参数是否受支持，应以读者安装版本的帮助为准。

我会先分清要限制哪一块显存

我最不建议的起手式，是看到显存紧张就把所有“看起来省内存”的参数一起打开。权重、KV 缓存、激活与临时工作区、CUDA Graph 等运行期开销承担不同职责：减小缓存预算，不一定能解决加载权重阶段的失败；调低请求并发，也不会把已加载权重压缩掉。

我的判断顺序是先确认失败发生在哪个阶段，再选控制项。这样更容易解释“为什么改完反而启动不了”，也方便撤回单次变更。

把设备使用权和模型配置写进启动记录

先记下 GPU 型号与容量、当前其他进程占用、模型目录与权重格式、vLLM 版本和完整启动参数。设备编号只决定当前进程可见的设备，不替代平台调度授权；共享机器上应先协调资源，不终止不属于自己的进程。

如果一张卡有多个实例，不能因为每个实例都设置了较小比例，就假定它们互不干扰。比例是实例配置，不会替其他实例动态协调峰值。对确实需要强隔离的场景，我会先确认基础设施提供的隔离能力，再讨论模型参数，而不是用一个小数充当资源治理方案。

先用比例预算建立一份最小配置

以下命令假设 /srv/models/text-demo 已经是可读取、与当前硬件和 vLLM 兼容的模型目录。它不是下载地址，也不承诺任意模型都能在这组参数下启动；读者需要换成自己的获准目录。

# 先确认本地版本与参数帮助，不直接套用网上的默认值。
vllm --version
vllm serve --help
# 示例只绑定回环地址，使用设备0；数值仅作为调参起点。
CUDA_VISIBLE_DEVICES=0 vllm serve /srv/models/text-demo \
  --host 127.0.0.1 \
  --gpu-memory-utilization 0.65 \
  --max-model-len 4096 \
  --max-num-seqs 4

我会先只保留这几个直接相关的限制项。0.65 是示例比例，不是“给任何显卡留下35%可用空间”的保证；4096 和4也不是容量结论。启动日志和真实负载结果才决定这组配置是否适合该模型。正文示例不在本任务中运行。

若改用 kv_cache_memory_bytes，应在独立配置变更中明确记录每 GPU 的缓存字节预算，并从本机帮助确认单位与解析方式。它设置后会忽略 gpu_memory_utilization 对 KV 缓存大小的推算，不应同时改两个值再猜哪个生效。权重与其他运行开销仍需另留空间。

再按上下文与并发收紧请求规模

max_model_len 约束上下文容量，需同时考虑输入与生成；它不会承诺把超长输入悄悄截成业务上仍然完整的内容。我的倾向是在入口明确限制请求长度与输出预算，让用户知道支持范围，而不是让模型服务启动后才暴露限制。

max_num_seqs 限制调度序列规模，不等于请求入口的排队上限。因此还应在服务接入层规定排队、超时和并发策略，不能靠模型参数无限积压请求。减小长度和序列数可以降低内存压力，但可服务的业务范围与吞吐也可能收缩，实际代价需要测量。

如果压力来自 CUDA Graph，可对照官方节省内存文档评估 enforce_eager 或图捕获配置。我的选择会是先做单独对比，记录延迟和内存变化；不把关闭图捕获说成所有场景都更好，也不在没有硬件和模型依据时叠加量化参数。

启动失败时按阶段回退配置

加载权重就失败时，先确认模型体量与硬件是否匹配，不再一味调低比例。KV 缓存容量不足或上下文装不下时，则比较预算与所需长度；这时继续削减缓存可能把问题加重。图捕获或请求阶段失败，又是另一类定位任务。

我的回退方法是保留上一份可解释配置，每次只改变一个维度，记录错误阶段与参数差异。重启前应确认旧实例是否退出并释放自己的资源，不通过清空模型目录、随意扩大权限或结束其他用户进程来“腾空间”。若模型本身不适合这张卡，换更合适的模型或资源配置，比继续压低数字更诚实。

把结果记录成可比较的运行档案

配置进入自动启动流程后，应固定模型与版本记录，在启动失败时停止重复拉起并通知维护者。消息里写清实例、失败阶段、参数差异和回退状态，不携带访问令牌或用户提示词全文。这是运行流程建议，不是 vLLM 的自动承诺。

适合保留的比较项包括：能否完成初始化、代表性上下文能否接受、目标负载下是否出现显存错误，以及延迟和排队是否仍符合要求。没有这些记录，我不会把“进程起来了”当作限显存方案完成。本文没有实际测量，因此不提供改善数字。

把比例调低，显存一定等比例下降吗？

不应这样理解。配置预算影响引擎资源规划，模型权重与其他固定开销不会按比例缩小；启动阶段也可能因预算不足而失败。先确认限制对象，再判断观察到的数值。

显式 KV 缓存只有几 GiB，为什么总占用还更多？

因为 KV 缓存不是整个推理进程。还要计入权重与运行期开销；缓存参数不能作为总占用的审计证明，更不能据此承诺多实例安全共存。

什么人适合从这组配置开始？

适合已经有兼容模型、需要梳理单实例预算和请求规模的开发者。若需求是多租户强隔离、模型量化适配或跨卡并行，应另做专项设计。对我而言，最重要的取舍不是把比例压到最低，而是让预算、可支持请求和故障恢复都能说清楚。

参考：vLLM 引擎参数、vLLM 节省内存说明。latest 文档会更新，部署前按已安装版本核对参数支持范围。