一句话定义
gpu_memory_utilization（显存利用率上限）是推理框架里的一个配置参数，用来规定“这个服务进程最多可以占用这张显卡上多大比例的显存”，常见默认值在 0.9 上下（具体以官方文档为准）。
它设置的是“预留”，与“用量”无关
可以把它想象成在酒店里包场：你包下整个 9 层楼，并不代表 9 层楼的房间都住满了人。包下的楼层数就是“预留”，实际入住人数就是“水位”。
推理框架（比如 vLLM 这类）启动时会先按这个比例，把一大块显存圈下来，专门留给 KV cache（键值缓存，也就是对话上下文在显存里的“手稿”）。之所以要提前圈定，是为了避免运行过程中反复向驱动申请显存，因为那样既慢，又容易产生碎片。圈完之后，池子内部实际装了多少 token，则是一个随请求量涨落的动态水位。
所以 nvidia-smi 显示“只剩一点点”是正常的
监控工具看到的是“已分配”（allocated/reserved），而不是“正在使用”。预留池里空着，也会被算成已占用。一个健康的推理服务长期显示 90% 以上的显存占用，是设计如此，并不等于马上要 OOM（显存溢出）。真正该盯的是池内的水位：KV cache 使用率、请求排队长度、有没有触发抢占（preemption），也就是把已有请求踢出去重算。
三个常被混为一谈的指标
| 指标 | 含义 | 由谁决定 |
|---|---|---|
| 显存已分配 | 进程向驱动申请的显存，包含给 KV cache 预留的空位 | gpu_memory_utilization 决定上限 |
| 显存实际水位 | 预留池里真正装了上下文的部分 | 并发数、上下文长度 |
| GPU 利用率 | 计算单元忙不忙（nvidia-smi 的 GPU-Util） | 与显存占用基本无关 |
最后一行最容易被误读：GPU-Util 高不代表显存吃紧，显存吃紧也不代表算力在忙。
调整这个数的取舍
调高：KV cache 池更大，能支持更长的上下文和更高的并发，但留给其他进程（另一个模型、监控 agent、训练任务）的空间变小，容易被挤到 OOM。
调低：在共享卡上给其他任务留出空间，代价是并发吞吐下降；调得过低时，甚至启动就会报“显存不足以支撑设定的最大上下文长度”。
实践中的粗略经验：独占整卡留 5%~10% 余量；共享卡按实际分配给它的额度来计算；使用张量并行时，这个比例对每张卡分别生效，而不是整机一个总数。调整之前，先查看官方文档里关于最大上下文长度和 KV cache 的说明，再动手。