本地跑大模型时，最常见的问题之一就是显存不足。很多人看到OOM就直接换更小模型，但显存占用不只来自模型权重。长上下文、KV Cache、并发请求、图像输入和推理框架缓存都可能让一个原本能加载的模型在真实使用时突然爆显存。排查前先把占用来源拆开，会比盲目降模型更有效。同一个模型用FP16、8bit、4bit量化，占用差距非常大。先记录模型刚加载、还没有任何请求时的显存。如果空载就已经接近显卡上限，后面几乎没有上下文和缓存空间，优先考虑更低精度量化或更小模型。

长上下文会持续吃KV Cache

聊天越长，模型需要保存的键值缓存越大。模型能正常回答2K上下文，不代表32K也能稳定运行。如果刚启动正常，聊几十轮后才OOM，重点检查上下文长度和KV Cache，而不是马上怀疑模型文件。

建议固定模型与量化方式，先记录刚加载时的空载显存，再单独增加上下文长度、生成长度和并发请求。每一步仅改变一个条件，观察峰值变化，才能区分权重占满、KV Cache增长和瞬时批处理峰值。

并发会把单请求占用放大

一个用户能跑，不代表五个用户同时跑也能。每个会话都可能需要独立缓存，显存峰值会迅速上升。服务器场景要按真实并发测试，设置最大同时生成数和排队机制。

多模态模型还有图片和视觉编码开销

图片分辨率越高、一次输入图片越多，视觉编码器和中间特征都会增加占用。纯文本测试正常，实际上传图片后爆显存很常见。可以先限制输入分辨率和图片数量，再判断是否需要更大显卡。

更低精度量化虽然节省权重空间，却可能损失部分任务质量，或不被特定视觉模块支持。判断优化是否成功应同时比较实际回答效果、首字延迟和长对话稳定性，不能只看模型能否启动。

框架缓存不一定会立即释放

PyTorch、CUDA和不同推理框架会保留一部分缓存用于后续加速。任务结束后显存数字没有立刻下降，不一定代表真正泄漏。重点观察连续多轮任务后是否持续增长，以及停止请求后能否稳定在一个平台值。

先降上下文和并发，再考虑换模型

如果模型质量很重要，可以先把最大上下文从32K降到8K、并发从4降到2，看看是否稳定。很多场景不需要极长上下文。配合RAG只取真正相关的文档，也能减少上下文长度和显存压力。

记录峰值而不是只看平均值

OOM往往发生在生成开始、批处理合并或某个大请求进入时。监控显存峰值、请求长度和并发数，比只看平均利用率更有意义。本地大模型显存硬件指南可以用于前期选型；真正部署以后，还要通过真实工作负载验证余量。本地LLM显存问题最好按“权重—上下文—并发—多模态—框架缓存”顺序排查。知道显存到底花在哪里，才能选择降量化、缩上下文、排队还是升级硬件，而不是每次OOM都重新换一个模型。

如果框架预分配显存，监控显示占用较高也未必意味着泄漏。要观察多轮任务后峰值是否持续增长、停止任务后是否趋于稳定，并保存模型版本与运行参数供后续复测。

排查时最好固定一套测试：同一模型、同一量化版本、同一上下文长度，分别跑单用户和多并发，记录空载显存、首轮请求峰值和长对话后的峰值。以后换驱动、推理框架或量化方式时继续跑同一套数据。这样你会知道显存优化到底来自模型更小、KV Cache更省，还是框架释放内存更及时，而不是只凭“这次好像没爆”判断。