先说结论：70B × 4 bit ÷ 8 ≈ 35GB。这只是理论上的权重体积。单张 32GB 显卡连权重都放不下，更没有空间留给 KV Cache 和推理框架。
所以，“32GB 机器跑 70B”其实是两件事。全 GPU 加载普通 4-bit 模型，基本行不通；允许 CPU 和系统内存参与，GGUF 分层卸载可以尝试，但速度和上下文余量都要让步。
这里不列固定的 tokens/s，也不写一个漂亮的精度损失百分比。当前素材没有完整的模型版本、推理后端、上下文设置和运行日志，把估算写成实测，反而容易误导。
先算显存，不要先装框架
运行大模型时，占用可以粗略写成：
总占用 ≈ 模型权重 + KV Cache + 推理框架及系统开销
AtomGit 开源社区 2026 年 6 月的文章给出的估算是，推理框架和系统预留通常还要增加 10%–20%。这个比例不是每台机器都一样，但不影响 32GB 场景的判断：仅 4-bit 权重就约 35GB，已经超过显存容量。
| 路线 | 70B 理论权重 | 单张 32GB 显卡 |
|---|---|---|
| FP16 | 约 140GB | 无法完整加载 |
| INT8 / SmoothQuant | 约 70GB | 无法完整加载 |
| 4-bit AWQ / GPTQ | 约 35GB | 权重本身已超出容量 |
| GGUF，4-bit 或更低 | 取决于量化级别 | 可把部分层留在系统内存 |
KV Cache 还会随着上下文长度、批量和并发增加。即使模型能在短提示词下启动，也可能在长文本生成时出现 CUDA out of memory。RTX 5090 的型号再新，只要可用显存是 32GB，这笔账就不会变。
AWQ、GPTQ 与 GGUF，不是同一种解法
知乎的本地部署算力指南把 AWQ、GPTQ 归为 4-bit GPU 量化路线，把 SmoothQuant 归为适合 A100、H100 的 8-bit 路线，同时列出了 llama.cpp 使用的 GGUF 格式。
AWQ 和 GPTQ 更适合总显存足够、推理后端也有对应算子支持的环境。它们能压缩权重，却不会让约 35GB 的权重自动缩进 32GB。device_map=auto 负责设备放置，也不能改变模型的实际体积。
GGUF 解决问题的方式不同。llama.cpp 可以通过 --n-gpu-layers 控制放进 GPU 的层数，其余权重留在系统内存：
llama-cli -m /path/model.gguf --n-gpu-layers <层数> -c <上下文长度>
实际部署时，可以先用较低的 GPU 层数确认模型能稳定加载，再逐步增加。遇到 OOM，优先降低 GPU 层数、上下文长度或并发，而不是把 Swap 当成显存。Swap 只能缓解系统内存压力，不能增加 GPU 显存。
需要说明的是，GGUF 没有把模型变小到凭空消失。它只是允许权重在 GPU 和系统内存之间重新分配。卸载比例越高，CPU 和内存访问对推理速度的影响通常越明显，因此不能脱离硬件配置承诺固定速度。
能跑量化成品，不等于本机量得动
70B 模型的 FP16 权重理论上约为 140GB。把它转成 4-bit 时，量化工具仍要读取原始权重，并占用额外的内存和工作空间。因此，一台能够通过 GGUF 卸载运行 70B 的机器，未必也能在本地完成 AWQ 量化。
如果准备使用 AutoAWQ，先确认三件事：
- 模型架构是否被当前 AutoAWQ 版本支持；
- 导出的格式是否能被目标推理后端加载；
- 校准数据是否接近实际任务。
校准集不要只图方便。如果模型主要用来写 Python，校准样本中就应该包含 Python 代码，而不是只放 WikiText 一类通用文本。量化完成后，再用同一组业务提示词对比原模型与量化模型。MMLU 可以参考，但不能代替代码、问答或长文本任务的实际回归。
本机资源不足时，更省事的做法是直接使用来源可信的量化成品，或者在内存更充足的环境里完成量化，再拿回 32GB 机器部署。
KV Cache 会在运行时追上来
权重量化和 KV Cache 精度是两项独立设置。加载了 4-bit 权重，不代表 KV Cache 也自动变成 4-bit。
部分推理框架支持低精度 KV Cache，可以减少长上下文占用，但要先确认模型和后端是否兼容。不要写成“生成到某个固定 token 数就一定崩”，因为阈值还受上下文、批量、并发、缓存精度和框架实现影响。
比较稳妥的顺序是：先用保守的上下文和并发启动，记录峰值显存，再逐步提高。这样能分清 OOM 到底发生在模型加载阶段，还是被 KV Cache 慢慢吃掉了余量。
别只测“能启动”
一份可复现的部署记录，至少应写清这些信息：
| 要记录的项目 | 用途 |
|---|---|
| 模型名称与具体版本 | 避免同名模型混淆 |
| AWQ、GPTQ 或 GGUF 量化格式 | 判断后端和算子差异 |
| GPU、显存与系统内存 | 解释是否依赖卸载 |
--n-gpu-layers、上下文与并发 |
还原显存占用条件 |
| 峰值显存、首字延迟与生成速度 | 区分“能跑”和“好用” |
| 固定业务提示词的输出结果 | 检查量化后的任务表现 |
数值计算、长文本问答和代码生成都值得单独留样本。不要用一次成功启动替代质量验证，也不要直接照搬其他机器上的速度和精度数字。
32GB 机器怎么选
如果必须运行 70B，优先考虑 GGUF 与 llama.cpp，把一部分层放到系统内存。更低比特的 EXL2 或 GGUF 量化也能继续压缩权重，但模型表现和后端支持需要逐项验证，不能只看文件大小。
如果更在意响应速度和上下文空间，32B 往往更合适。32B 模型做 4-bit 后，理论权重约 16GB，比 70B 的约 35GB 留出的余量大得多。什么值得买的硬件门槛梳理也把 14B–32B 视为消费级配置更容易驾驭的区间。
如果目标是让 70B 的 AWQ 或 GPTQ 模型尽量留在 GPU，就需要更大的总显存或多卡，而不是继续在单张 32GB 显卡上挤空间。
32GB 可以成为 70B 的部署落点，但通常要依赖 CPU/GPU 混合推理；它不是 70B 普通 4-bit 模型的全 GPU 容量。先把约 35GB 的权重算清楚，大部分 OOM 就不再是谜。
