大语言模型部署实战：FP16、INT8、4bit 量化怎么选？吞吐、精度与显存的真实权衡

前面几篇，我们已经把这条主线推进到了微调阶段：

Transformer 为什么能成为大模型基础架构
预训练到底在学什么
SFT、RLHF、DPO 这类对齐训练怎么串起来
长上下文是怎么做出来的
temperature、top-k、top-p、repeat penalty 这类推理参数怎么调
LoRA、QLoRA、全参微调分别适合什么场景

接下来，就该进入真正决定"能不能跑起来"的部署问题了。

因为很多团队第一次把大模型从论文、Demo、Notebook 搬到真实环境时，最先撞上的通常不是 prompt，也不是算法，而是一个非常现实的问题：

显存不够。

你会发现很多事情都绕不过它：

7B 模型到底能不能在单卡上跑？
13B、32B、70B 模型分别大概要多少显存？
为什么有些模型 FP16 跑不动，换成 4bit 却能跑？
INT8、4bit、GPTQ、AWQ、GGUF、bitsandbytes 到底该怎么选？
量化以后为什么有时省了显存，却不一定更快？
真实服务里到底该优先保吞吐、保精度，还是先保能上线？

这篇文章，我想把大模型部署里最关键的一条线讲透：

量化不是"压缩一下模型"这么简单，而是在显存、精度、延迟、吞吐、兼容性之间做工程取舍。

我们重点讲 7 件事：

为什么量化是大模型部署的核心杠杆
FP16、BF16、INT8、4bit 分别意味着什么
GPTQ、AWQ、GGUF、bitsandbytes 这些路线到底差在哪
为什么"更低 bit"不一定代表"更快"
KV Cache、batch、上下文长度为什么会把显存再次吃爆
单机、本地、API 服务三类场景下怎么选量化方案
如何做吞吐、延迟、精度的真实评估，而不是只看参数表

如果你正准备把模型放到：

本地开发机
消费级 GPU 服务器
推理服务集群
Ollama / vLLM / SGLang / llama.cpp 这类框架

这篇会比"背几个量化名词"更有用。

一、先说结论：量化首先解决的是"能不能部署"，其次才是"跑得有多漂亮"

很多人第一次接触量化时，会天然把它理解成：

模型压小一点
显存省一点
速度快一点

这当然没错，但还不够准确。

更实用的理解应该是：

量化是把原本无法部署的模型，拉回到可部署区间的第一把工程杠杆。

因为真实环境里，部署约束通常不是"理论最优"，而是下面这些：

你手里只有 24GB、48GB 或 80GB 显卡
你还得留出 KV Cache、batch、并发和框架开销
你不能只让它跑一次，而是要稳定处理请求
你不只是要出结果，还要控制 TTFT、tokens/s、吞吐和成本

所以工程上第一问通常不是：

哪种精度最先进？

而是：

在我的硬件和目标 SLA 下，模型到底以什么格式最合适。

如果一个 14B 模型用 FP16 根本装不下，那你讨论它 FP16 精度有多好，其实没有意义。

二、先把几个核心概念踩稳：权重、激活、KV Cache 不是一回事

很多人刚学部署时，会把"模型显存"理解成一个静态数字。

这很容易误判。

因为推理时显存通常至少分成三块：

1）模型权重（Weights）

也就是参数本身。

这是量化最直接作用的部分。

比如：

FP16：每个参数约 2 字节
INT8：每个参数约 1 字节
4bit：每个参数约 0.5 字节

粗略估算：

7B 模型，FP16 权重大约 14GB
7B 模型，INT8 权重大约 7GB
7B 模型，4bit 权重大约 3.5GB

但这只是非常粗糙的理论值，真实还要加上：

scale / zero-point 等量化元数据
框架开销
内存碎片
tensor parallel / runtime buffer

2）激活（Activations）

推理时激活开销通常比训练小很多，但在大 batch 或某些框架实现里也不能完全忽略。

3）KV Cache

这才是很多人上线后真正被打懵的地方。

因为生成式推理不是只把模型加载进来就完了，模型还要给每个请求保存注意力历史，也就是 KV Cache。

KV Cache 的占用和这些因素强相关：

层数
hidden size
attention heads
context length
batch size / 并发数
精度格式

所以经常会出现一种情况：

模型本体放得下，但一旦 batch 稍微变大、上下文拉长、并发一上来，显存还是爆。

这也是为什么部署讨论不能只盯着"模型多大"，还要盯着"运行时多重"。

三、FP16、BF16、INT8、4bit 到底分别是什么？

先把这些常见格式讲清楚。

1）FP16

FP16 是半精度浮点，部署里最经典的一种格式。

它的特点是：

精度高于低 bit 量化
框架兼容性普遍较好
很多 GPU 对 FP16 推理有成熟加速
显存占用大约是参数量 × 2 字节

它适合：

你显存足够
你优先保守稳定
你不想引入太多量化误差
你要做 benchmark 或高保真基线

2）BF16

BF16 本质上也是 16 bit，但指数位更多，数值稳定性通常比 FP16 更好。

在现代训练和推理框架里，BF16 很常见，尤其在支持良好的 GPU 上。

部署视角下，它和 FP16 的核心共同点是：

都属于"高精度、显存开销相对大"的方案。

3）INT8

INT8 就是 8 位整数表示。

它的直觉很简单：

参数占用大约减半
往往比 16bit 更省显存
精度损失通常比 4bit 更温和

它常常是一个很好的中间地带：

既想省资源
又不想承受太激进的精度下降
希望保留较强兼容性和稳定性

4）4bit

4bit 是现在开源部署里非常热门的一档。

因为它经常能把原本"根本跑不动"的模型，拉进消费级显卡可运行区间。

它的价值非常现实：

同样显存下能装更大的模型
本地部署门槛大幅下降
对 7B、14B、32B 这类模型特别有用

但要记住：

4bit 的收益首先是"装得下"，不是自动保证"更快、更稳、更准"。

四、为什么更低 bit 不一定更快？

这是很多人最容易误解的地方。

直觉上你会觉得：

模型更小了
数据搬运更少了
所以速度一定更快

但真实情况没有这么简单。

因为推理速度不仅取决于权重大小，还取决于：

量化/反量化开销
Kernel 是否优化成熟
GPU 对该精度格式支持得好不好
框架是否为该格式做了高效实现
当前瓶颈是算力、带宽还是调度开销

所以工程上常见三种情况：

1）低 bit 同时更省显存，也更快

这通常发生在：

模型原本受限于显存带宽
量化 kernel 做得不错
硬件支持较好
请求规模比较适合当前框架

2）低 bit 更省显存，但速度提升有限

这其实很常见。

因为你只是把"能不能跑"问题解决了，但吞吐仍然受：

KV Cache
调度开销
decode 阶段串行性
框架实现效率

限制。

3）低 bit 省了显存，反而未必更快

尤其在某些 CPU、本地推理或不成熟实现里，过多的反量化和格式转换会吃掉收益。

所以别把量化简单理解成"bit 越低越快"。

更准确的理解是：

低 bit 提供的是更高的部署弹性，而速度收益取决于具体硬件和推理栈。

五、GPTQ、AWQ、GGUF、bitsandbytes 这些路线到底差在哪？

这里不追求把每个论文细节都展开，而是从工程角度讲你最需要知道的区别。

1）bitsandbytes

这是很多人接触 8bit / 4bit 量化的第一站。

它的特点是：

和 Hugging Face 生态结合紧
加载方便
适合快速实验和开发验证
常用于 QLoRA、低门槛本地部署

适合场景：

你想快速试一个模型能不能跑
你主要在 Python / Transformers 生态工作
你更看重开发便利，而不是极限推理性能

2）GPTQ

GPTQ 是一类典型的后训练量化（PTQ）路线。

它的目标是：

在不重新训练模型的情况下，把权重量化到更低 bit，同时尽量减少精度损失。

适合场景：

你已经有训练好的模型
想把它变成适合推理部署的低 bit 版本
更关注离线量化后的部署产物

3）AWQ

AWQ 也是目前非常主流的后训练量化路线之一。

它强调对重要权重进行更有针对性的保护，因此在不少模型和任务上有不错的精度保持表现。

工程上很多人喜欢它，是因为它在"精度---速度---部署性"之间比较平衡。

适合场景：

你要上线 GPU 推理服务
你希望 4bit 量化后尽量少掉点
你希望配合 vLLM / SGLang / TensorRT-LLM 等更成熟服务栈

4）GGUF

GGUF 更多是 llama.cpp 体系下非常常见的模型分发格式。

它的价值不只是量化，而是：

方便本地推理
CPU / Apple Silicon / 小型设备支持好
各种量化档位丰富
对桌面端、自托管、轻量本地使用特别友好

适合场景：

Mac 本地跑模型
CPU 推理
不追求大规模服务化，而是追求便捷部署

所以你可以先这样理解：

bitsandbytes：开发验证友好
GPTQ：经典离线后训练量化路线
AWQ：部署实战里很常见的高性价比 4bit 方案
GGUF：本地化、跨硬件、轻量部署很强

六、量化选型不能只看权重，还要把 KV Cache 一起算进去

这是部署里特别容易踩坑的一点。

很多人估算显存时，只会算：

模型参数量 × bit 数

然后发现理论上够，实际一跑还是 OOM。

为什么？

因为真实推理里，尤其长上下文和高并发场景下，KV Cache 经常会成为第二大显存消耗源。

一个实用判断

如果你的场景是：

长文档问答
RAG 回答时塞很多上下文
高并发 API 服务
多轮会话长期保留上下文

那你要优先关注的，不只是模型量化档位，还包括：

max model len
max num seqs / batch size
prefill 长度
decode 阶段并发
KV Cache 精度与分页管理

也就是说：

量化解决的是静态模型占用，而 KV Cache 决定的是动态服务容量。

如果你忽略第二件事，部署就很容易在上线后翻车。

七、单机、本地和服务化三类场景，到底怎么选？

我给你一个更接近真实工程的选择框架。

1）本地个人使用 / 开发验证

目标通常是：

先跑起来
成本低
不追求极限吞吐

推荐思路：

Mac / CPU / 轻量设备：优先看 GGUF
单卡实验：可以优先试 bitsandbytes 4bit / 8bit
如果只是 prompt 调试和功能验证，先别追求最复杂的服务栈

这时最重要的是：

让模型进可用区，而不是一次性把架构做满。

2）团队内网服务 / 小规模 API

目标通常是：

可被多人调用
有一定并发
稳定比极限参数更重要

推荐思路：

7B / 14B 模型：INT8 或 4bit 都值得评估
如果对精度敏感，先拿 FP16/BF16 做基线，再比较 AWQ / GPTQ
使用 vLLM / SGLang 这类更适合服务化的推理框架
重点监控 TTFT、tokens/s、OOM、上下文长度和并发退化

3）生产级高并发服务

目标通常是：

尽可能高吞吐
可预测延迟
稳定 SLA
成本可控

这时量化选择不能只看"能不能跑"，而要看：

特定框架对该量化格式支持是否成熟
continuous batching 能否吃满吞吐
tensor parallel / pipeline parallel 如何协同
精度下降是否影响真实业务指标
故障恢复、热加载、灰度切换是否方便

换句话说，上线服务看的是整条推理链，而不是单个量化标签。

八、如何评估"量化到底值不值"？别只看主观感觉

这部分特别关键。

很多团队测量化时，只问一句：

好像没差太多？

这不够。

你至少应该从四个维度评估。

1）显存占用

记录：

模型加载后显存
首 token 前显存
长上下文下显存
高并发时峰值显存

2）延迟

重点看：

TTFT（Time To First Token）
单请求总时延
不同输入长度下的变化

3）吞吐

重点看：

tokens/s
batch 增长后的吞吐变化
并发数上升后的退化曲线

4）精度 / 业务效果

不要只看一句"感觉回答还行"。

应该至少准备：

通用 benchmark 的小样本回归测试
你的真实业务样例集
幻觉率、格式遵循、召回命中、代码可执行性等任务指标

因为很多量化方案在闲聊上看不出差异，但在：

数学推理
结构化抽取
严格格式输出
OCR / 文档理解
多轮工具调用

这些任务上会更容易暴露误差。

九、几个实用的参数与工程建议

最后给你一组更偏落地的经验判断。

1）先用高精度格式建立基线

如果硬件允许，先跑一版 FP16 / BF16 基线。

这样你后面评估 INT8、4bit 时，才知道掉点和收益来自哪里。

2）别只盯着模型权重，记得给 KV Cache 留预算

尤其是长上下文和多并发服务。

很多 OOM 不是发生在"加载模型那一刻"，而是发生在"请求多起来之后"。

3）量化越激进，越要做真实业务回归

不要只拿通用问答测。

如果你的业务是：

RAG
文档抽取
代码生成
表格理解
多模态问答

那就用这些真实任务去回归。

4）如果目标是服务化，不要只看模型文件格式，要看整个推理框架的支持度

同样一个 4bit 模型，在不同框架上的：

吞吐
稳定性
并发支持
上下文能力

可能差别非常大。

5）"最优量化方案"通常不是固定的，而是和模型、硬件、任务三者绑定

没有一种格式能在所有情况下都赢。

工程上要避免问：

"4bit 是不是一定最好？"

更应该问：

"在我这个模型、硬件、任务组合下，哪种方案最合适？"

最后总结一下

今天这篇，你可以把核心记成下面几句。

1）量化首先解决的是部署可行性

很多时候不是"跑得更优"，而是先让模型进入"能上线、能承载请求"的区间。

2）FP16 / BF16 更保守，INT8 是中间地带，4bit 最擅长压缩显存

但 bit 越低，不代表自动越快、越稳。

3）GPTQ、AWQ、GGUF、bitsandbytes 不是简单替代关系，而是针对不同推理栈和场景的路线选择

开发验证、GPU 服务、本地推理，各自最优解往往不同。

4）部署评估一定要同时看：显存、延迟、吞吐、业务效果

只看模型能不能加载，远远不够。

5）真正影响上线成败的，不只是权重量化，还有 KV Cache、上下文长度、batch 和框架实现

这几件事经常比"参数 bit 数"更决定真实容量。