vLLM显存预分配：gpu-memory-utilization参数实战解析

在本地部署大模型时，vLLM 和 llama.cpp 的显存管理策略差异，往往是新手踩坑的第一站。一个来自 YouTube 的实操讲解直接点出了关键：vLLM 会在加载模型之前就预分配好显存，而 llama.cpp 是按需申请。这个设计差异，直接决定了 --gpu-memory-utilization 这个参数为什么必须认真对待。

预分配机制：vLLM 与 llama.cpp 的根本分歧

据该 YouTube 视频的讲解，llama.cpp 采用按需分配策略，用到多少显存就申请多少；vLLM 则相反，在真正开始 serve 模型之前，就把计划占用的显存空间一次性划走。这意味着 --gpu-memory-utilization 不是"上限"，而是"预留量"——你给多少，vLLM 就会把多少拿走。

视频作者特别强调："it's going to take whatever you specify here"。这句话是理解该参数的核心。很多人误以为这是一个弹性阈值，实际它更像是一次性锁定的显存预算。理解这一点，才能避免"模型明明不大、显存却被吃满"的困惑。

PagedAttention 与显存预分配的关系

vLLM 之所以采用预分配策略，与其核心推理加速技术 PagedAttention 密切相关。PagedAttention 借鉴了操作系统虚拟内存的分页思想，将 KV cache 切分成固定大小的块（block），并通过块表管理这些块的物理位置。这种设计让 KV cache 不再需要连续的大块显存，从而大幅降低显存碎片。但与此同时，vLLM 的调度器需要在启动时就掌握可用的显存总量，以便为后续请求规划块分配。因此在 serve 之前按 --gpu-memory-utilization 一次性划走显存，实际上是在为 PagedAttention 的块管理提供确定的预算边界——如果启动时显存不足，后续再动态申请会引入不可控的延迟和失败风险。

这个参数到底在算什么

--gpu-memory-utilization 需要填入一个比例值，表示 vLLM 被允许使用的显存份额。这笔预算并非只服务于模型权重本身，视频中明确提到，它同时要覆盖 KV cache 所需的空间，而 KV cache 的大小又与上下文长度直接挂钩。

换句话说，这个比例是在为"模型 + 上下文缓存"整体买单。作者提到自己使用的是共享内存较大的设备（视频中描述为一台具备 128 GB 共享内存的设备）。这类设备显存池很大，但如果跑的是小模型，把比例开得太高纯属浪费，还会挤占其他进程的生存空间。

KV cache 为什么与上下文长度挂钩

KV cache（Key-Value 缓存）是自回归生成中的一种空间换时间优化：模型在生成每个 token 时，需要用到之前所有 token 的 Key 和 Value 向量，若不缓存就要反复重算，计算量随序列长度平方增长。缓存下来后，每个 token 对应的 KV 向量都要常驻显存，其大小约等于 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 数据类型字节数。对 7B 级别的模型，单条 8192 token 的序列就可能占用数 GB 显存。这正是文中强调比例要覆盖“模型 + KV cache”的原因，也是缩短上下文能直接释放显存空间的技术根据。

比例怎么定：给多给少都有代价

作者给出的原则很朴素：不能给太少，否则模型跑不起来；也不能无脑给满，因为没必要的占用会白白浪费资源。他在视频中给出的参考是——在小显存场景下，一半左右的比例可以接受；换到性能更强的设备上，完全可以往下调到更低的比例，让出空间给系统或其他任务。

这个建议背后的逻辑是显存预算与硬件规格要匹配。同一套参数搬到不同机器上，效果可能天差地别。视频里作者能在自己的设备上跑通，靠的不是某个万能数值，而是根据实际显存容量反推出来的比例。

配套手段：用上下文长度换显存空间

当显存预算被压低后，KV cache 的可用空间随之收紧，此时最直接的调节杠杆就是上下文长度。视频中作者为了把模型塞进设定好的显存比例里，缩短了上下文窗口，并通过 --max-model-len 参数将其设为 8192（同样是 2 的幂次）。

这一步很关键：降低显存占用比例和缩短上下文长度，往往是需要成对出现的操作。只调比例不调上下文，可能出现模型加载成功但长序列推理失败的情况；只调上下文不调比例，则显存预留依旧偏高。作者在演示中把两者结合起来，才完成了在自己设备上的部署。

--max-model-len 与长度的 2 的幂次

--max-model-len 指定的是 vLLM 允许处理的最大序列长度（含输入与输出 token 总数），它同时决定了 KV cache 的分配上限。推理框架通常要求或建议该值取 2 的幂次（如 4096、8192、16384），因为注意力计算和块管理在 2 的幂次长度上更容易对齐，能减少显存浪费和边界处理开销。设置时需要注意，该值不应超过模型本身训练时支持的最大上下文长度，否则位置编码可能失效；同时它也不是越大越好，超过实际业务所需的长上下文会白白占用 KV cache 预算，与压低显存比例的目标相冲突。

实践建议

从这段讲解可以归纳出几条可复用的经验。先确认硬件实际显存容量，再决定比例，不要照搬他人的数值；把模型权重和 KV cache 当作一个整体来估算预算；如果显存吃紧，优先缩短 --max-model-len 而不是把比例压到模型跑不动的程度。作者最后也提醒，参数设置的目标是"够用且不浪费"，而不是追求某个固定百分比。

对于刚接触 vLLM 的开发者，理解预分配这一前提，比记住具体数字更重要——因为硬件在变，唯一不变的是"给多少就拿走多少"这条规则。