本地跑大模型入门：量化、GGUF 与显存估算

把大模型跑在自己的机器上，动机通常就三类：数据不能出内网、长期调用的 API 成本压不下来、离线环境也要能用。这三条里任何一条成立，本地推理就值得认真考虑。

本地部署的技术门槛比调 API 高不少，但核心知识并不杂，主要就是三块：量化（把模型压小）、格式（把模型装进推理引擎）、显存预算（判断跑不跑得动）。把这三块理清楚，剩下的就是体力活。

一、量化：用精度换空间和速度

模型权重默认是浮点数。常见精度档位大致是这样：

量化（quantization）本质上是把高精度的权重映射到低精度的表示上。这个过程必然引入误差，问题只在于误差是否影响最终任务。

关于质量，几条工程经验：

• INT8 通常是很稳的折中。多数通用任务（对话、摘要、分类）几乎察觉不出差别。
• INT4 要看任务。日常闲聊、文案生成影响不大；复杂推理、代码生成、长链逻辑题的退化会更明显。
• 同一档位下，量化方法也分很多种（对称/非对称、分组大小、是否保留部分高精度层），不同方法的质量差异可以很大，不能只看”INT4″三个字。
• 量化对速度的影响不总是正向。理论上更小的权重意味着更少的内存带宽压力，但低精度运算需要硬件和内核支持，实际吞吐取决于推理引擎的实现质量。

选档位的实用做法：拿你业务里的真实样本各跑一遍 FP16 基线和量化版本，对比通过率。别拿通用跑分代替自己的任务分布。

还有一个常被忽略的点：量化的收益不是全局均匀的。注意力层、FFN 层对精度的敏感度不同，有些方案会对敏感层保留更高的精度，其余层激进压缩。这类混合精度策略能以很小的体积代价挽回一部分质量，代价是文件结构复杂、引擎支持度不一。看到”同为 INT4 效果差异大”的讨论，多半是这层差异在起作用。

二、GGUF：本地推理的”通用容器”

GGUF 是一种模型文件格式，常见于本地推理生态。它把模型权重、分词器配置、超参数等打包进单个文件，并且内置了量化后的权重表示，方便在消费级硬件上直接加载。

格式的核心价值在于互操作性：一份 GGUF 文件，可以在多个支持它的推理引擎上跑，不必为每个引擎单独导出。文件名里通常带量化标识，方便用户辨认：

model-7b-q4_k_m.gguf
        │    │    └── 量化方案细节（K-quant 的一种，M 表示中等档位）
        │    └─────── 4-bit 量化
        └──────────── 参数规模

除了 GGUF，生态里还有其他常见的权重/交换格式（比如 safetensors 一类的安全张量格式、各家引擎自有的导出格式）。选择时的判断标准是：你的推理引擎支持什么、部署环境是否允许加载未校验的二进制、是否需要跨框架迁移。GGUF 的优势在于本地单机场景下”拿来就跑”的便利性。

三、显存估算：一条粗略公式

判断一台机器能不能跑某个模型，先用这条公式做量级估算：

权重占用 ≈ 参数量(亿) × 每参数字节数
KV cache ≈ 2 × 层数 × 隐藏维 × 上下文长度 × batch × 每元素字节数
总需求   ≈ 权重 + KV cache + 运行时开销(约 10%~20%)

举个数量级的例子：一个 70 亿参数的模型，INT4 量化后每参数约 0.5 字节，权重占用约 3.5 GB；FP16 则约 14 GB。这只是权重，KV cache 会随着上下文长度线性增长，长上下文场景下 KV cache 甚至可能超过权重本身。

再补两个直觉：

• 参数量比上下文长度更”硬”。权重是固定开销，KV cache 可以通过限上下文、减 batch 来压。
• 统一内存架构（CPU/GPU 共享内存的机器）下估算方式不同，系统内存就是显存预算，跑超大模型的可能性取决于总内存大小和带宽。

实际部署前，用推理引擎加载试跑一次、观察真实占用，比任何公式都准。公式的价值是提前排除”明显跑不动”的选项。

四、CPU 还是 GPU：取舍逻辑

GPU 推理的优势是并行算力和显存带宽，生成速度（token/s）通常高出一个量级以上。适合：有连续请求、需要低延迟、上下文较长的场景。

CPU 推理的优势是零额外硬件成本、部署简单，笔记本也能跑。适合：离线工具、低频调用、对延迟不敏感的批处理。INT4 量化的中小模型在现代 CPU 上跑出可用的交互速度是完全现实的。

混合方案也常见：权重放内存、部分层放 GPU，或者 GPU 跑短上下文、CPU 跑离线批量。判断指标就一个：你的场景需要多少 token/s，机器实测能给多少。低于可用线就换硬件或换模型规模，高于可用线就别过度投资。

五、常见推理框架的定位

本地方案里，推理框架大致分几类定位（客观描述，不做排名）：

• 通用本地引擎：面向消费级硬件，支持多种量化格式，开箱即用，社区生态大。适合个人开发者和中小团队快速验证。
• 高吞吐服务框架：面向生产环境，支持连续批处理（continuous batching）、PagedAttention 一类的显存管理，追求并发下的吞吐。适合对外提供推理服务。
• 跨平台推理库：覆盖从服务器到移动端的多种后端，强调部署灵活性。适合需要在异构设备上统一推理栈的团队。
• 云端托管平台：不完全算”本地”，但和本地部署共享同一套量化/显存知识，模型权重仍在你的账号和区域下。适合想控制数据边界但不想自建集群的场景。

选型的三个问题：目标硬件是什么、并发量有多大、是否需要持续在线。三个问题的答案基本能框定选型范围，剩下的细节差异（内核优化程度、对新模型的支持速度、运维复杂度）留到 POC 阶段实测比较。

六、落地路径

一条务实的路径是：

1. 先小后大。先用小模型（比如 7B 级别）把整条调用链路、业务逻辑跑通，再考虑换更大的模型。很多场景里小模型 + 好提示词已经够用。
2. 先 INT8 后 INT4。INT8 起步验证质量，确认任务能接受再压到 INT4 榨取更多空间。
3. 压测要模拟真实输入。短提示词的吞吐数字好看，真实业务里长文档 + 长上下文的吞吐可能差几倍。
4. 留出降级路径。本地模型的输出质量不如预期时，能否回退到其他方案？把这个开关提前设计好。

本地跑模型不是为了”证明能跑”，而是为了在数据边界、成本、延迟这三者之间找到适合自己的平衡点。量化是空间，格式是载体，显存预算是约束——理解了这三件，本地推理的技术决策基本就清晰了。