本地跑大模型，最扫兴的莫过于刚加载到一半，终端蹦出一行「CUDA out of memory」，或者容器里 Pod 状态直接显示 OOMKilled 把进程杀掉。显存爆了不等于显卡不行，十有八九是量化、上下文长度、并发这几个旋钮没调好。下面按真机排障顺序过一遍。
先确认是「真 OOM」还是「假爆」
分清两类报错，方向差很远：Python 抛 CUDA out of memory，是推理时显存不够；容器里 Pod 显示 OOMKilled，是 K8s/Docker 的内存 limit 太小。前者调模型，后者调 limit，别搞反。
| 报错 | 本质 | 该调什么 |
|---|---|---|
| CUDA out of memory | 推理时显存不够 | 量化、砍上下文、降并发 |
| OOMKilled | 内存 limit 太小 | K8s/Docker memory limit |
显存都去哪了
⚡
14GB
7B 模型 BF16 权重
📊
26GB
13B 模型 BF16 权重
🔧
线性
KV Cache 随上下文增长
⏱️
+框架
CUDA 上下文/激活值开销
四步把显存压下来
1开量化
→
2砍长度
→
3降并发
→
4换引擎
# 1. transformers 4bit 量化，显存直接砍到约 1/4
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen2.5-7B", load_in_4bit=True,
quantization_config=BitsAndBytesConfig(
load_in_4bit=True, bnb_4bit_compute_dtype="bfloat16"))
# 2. vLLM 控制上下文长度，显存省约 30%
--max-model-len 4096 --gpu-memory-utilization 0.85踩坑实录
一次在双卡 A100 上部署 DeepSeek-V4，Pod 起来几十秒就被 OOMKilled。kubectl describe pod 显示 Reason: OOMKilled。我以为是显存不够，忙着换小模型，结果 df 看内存才发现 K8s 的 memory limit 只给了 64Gi，而 BF16 权重 140GB 加载时要先过 CPU 内存。把 limit 拉到 128Gi 才稳住。教训：OOMKilled 先看 limit，别急着动模型。
显存估算速查
| 参数量 | BF16 权重 | 4bit 量化后 |
|---|---|---|
| 7B | 约 14GB | 约 4GB |
| 13B | 约 26GB | 约 8GB |
| 70B | 约 140GB | 约 35GB |
常见问题
量化会不会让模型变笨？
4bit 对 7B/13B 这类小模型几乎无感，对 70B 以上精度损失才明显。日常本地助手用 4bit 性价比最高。
显存够但还报 OOM 怎么办？
查 K8s/Docker 的 memory limit，以及 /dev/shm 是否太小（容器默认 64MB），后者会触发莫名其妙的崩溃。
如果你在本地部署大模型时还遇到别的显存怪事，欢迎到 fenij.com 留言，我可以专门写一期你遇到的那类坑。
