本地部署大模型显存不够怎么办：量化、上下文、并发和换模型

本地部署大模型时，最常见的报错就是显存不够。很多新手会先怀疑安装错了，但真实原因通常更朴素：模型太大、精度太高、上下文太长、并发太多、KV cache 占用太高，或者推理框架参数不适合当前显卡。解决显存问题，不是只加一个参数，而是先判断显存花在了哪里。

本文是待复核草稿。基础部署可以看 本地大模型部署入门，vLLM 部署可以看 vLLM 部署新手指南。

适合谁

适合用 Ollama、vLLM、Text Generation Inference、llama.cpp 或其他框架跑本地模型的人。你可能遇到 CUDA OOM、加载模型失败、推理速度很慢或并发一高就崩。

也适合给客户做私有化部署评估的人。客户常问“这张显卡能不能跑某个模型”，你需要解释模型大小、量化、上下文和并发都会影响答案。

不适合谁

不适合只想用一个固定参数解决所有显存问题的人。不同模型、框架、显卡和任务差异很大。

也不适合把 CPU offload 当作万能方案的人。把部分数据放到 CPU 可能让模型勉强跑起来，但延迟和吞吐可能明显变差。

先看模型大小

模型参数越多，占用显存通常越高。同样是 7B、14B、32B、70B，精度不同显存差异也很大。FP16、INT8、INT4、AWQ、GPTQ、GGUF 等格式不能简单类比，要看框架是否支持。

如果显存只有 8GB 或 12GB，不要一开始就追大模型。先选小模型、量化模型或云端 API，把任务跑通，再评估是否需要更大模型。

量化能减少占用

vLLM 等推理框架支持多种量化方案。量化可以降低模型权重显存占用，但可能带来质量、速度或兼容性差异。不是每种量化都适合每张显卡，也不是每种模型都有现成量化版本。

量化前要明确目标：是为了能加载、为了更高并发，还是为了降低成本。目标不同，选择也不同。

上下文和 KV cache

显存不只被模型权重占用。上下文长度越长，KV cache 占用越高。很多人把上下文长度设得很大，但实际任务只需要几千 token，结果显存被浪费。

如果是 RAG 或 Agent，应尽量只传必要上下文。不要把完整文档、完整历史和所有工具结果都塞进模型。上下文管理本身就是部署优化的一部分。

并发和批处理

一个人测试能跑，不代表多人同时用也能跑。并发请求会增加显存和排队压力。vLLM 这类框架可以通过批处理提高吞吐，但也需要合适参数和足够显存。

如果服务面向真实用户，要测试单用户、多人并发、长输入、长输出和峰值请求，而不是只跑一句“你好”。

常见错误

第一个错误是只看模型参数，不看上下文长度。长上下文可能让小模型也占很多显存。

第二个错误是下载了模型，但框架不支持对应量化格式。模型文件能下载，不代表当前推理框架能高效运行。

第三个错误是追求“最大模型”。很多业务场景更需要稳定、低延迟、可维护，而不是参数最多。

交付检查

本地模型部署交付时，最好给客户一张显存和性能记录表。表里至少包括模型名称、量化格式、推理框架、显卡型号、上下文长度、并发数、平均延迟、首 token 时间、显存峰值和失败率。没有这些记录，只说“能跑”，后续很难评估扩容。

如果客户希望私有化部署，还要说明当前配置适合什么场景。例如适合内部知识库问答、适合低并发摘要、适合测试原型，还是适合生产客服。不同场景对速度、稳定性和并发要求不同，不应该只用一次成功运行来判断。

风险提醒

显存优化可能影响输出质量、速度和稳定性。量化、offload、上下文裁剪和并发调参都要通过真实任务测试。

私有化部署还涉及数据安全、日志、运维、监控和硬件成本。不要只按显卡价格评估整体成本。

具体步骤

第一步，记录模型名称、参数量、精度和框架。第二步，查看显卡显存和驱动环境。第三步，降低上下文长度做基线测试。第四步，尝试合适量化版本。第五步，测试并发和长输出。第六步，记录显存、延迟和失败率。需要排查表，可以从 工具导航 下载或联系人工协助评估。

免责声明

本文只用于本地模型部署排查学习，不构成硬件采购或生产容量承诺。正式部署前，应基于实际模型、数据和并发做压力测试。