FP16在缺乏原生INT4加速的消费级卡上“仍然是交互式工作负载更稳健的选择”，当社区默认推荐4-bit而硬件本身并不擅长4-bit时，用户到底该跟着社区走还是跟着硬件能力走？

一、问题的提出：社区共识与硬件事实的错位

打开任何一个本地大模型社区，4-bit 量化几乎被写成默认答案：GGUF 的 Q4_K_M、AWQ 的 4-bit、GPTQ 的 4-bit，教程第一句往往是“先下 4-bit 版本，显存够用”。这套建议在显存紧张的消费级显卡上确实救过很多人，但它隐含了一个很少被追问的前提——硬件擅长执行 4-bit 计算。事实并非如此。截至 2025 年，NVIDIA 消费级 GeForce RTX 40 系与 AMD Radeon RX 7000 系的 Tensor Core / Matrix Core 原生支持的数据类型集中在 FP16、BF16、TF32、INT8，INT4 并不在原生矩阵乘指令集之内（NVIDIA Ada Lovelace 架构白皮书，2022；AMD RDNA 3 架构白皮书，2022）。

这意味着，当你加载一个 4-bit 权重模型时，GPU 实际执行的是“取 4-bit 权重 → 反量化成 FP16 → 用 FP16 Tensor Core 做矩阵乘”这条链路。省下的是显存与显存带宽，付出的是一次额外的反量化运算和随之而来的内核复杂度。本文的核心论点由此展开：量化的收益必须与硬件的原生能力对齐，脱离硬件谈 bit 数是一种工程上的偷懒。社区推荐 4-bit 的合理性建立在“显存是瓶颈”这一普遍现实上，但当显存足够、负载是交互式低并发时，这条建议的收益结构会发生反转。

“更小的 bit 数”不等于“更快的推理”。在缺乏原生 INT4 算力的设备上，前者是存储事实，后者是内核实现问题，两者之间隔着一整条反量化流水线。

需要先厘清本文讨论的边界。所谓“消费级卡”，指单卡显存 8–24 GB、无 NVLink、面向单机单用户或小团队共享的 GPU，典型代表为 RTX 4090（24 GB）、RTX 4080 SUPER（16 GB）、RTX 4060 Ti 16 GB、RX 7900 XTX（24 GB）。所谓“交互式工作负载”，指以对话、代码补全、检索增强问答为代表的场景，特征为批大小 1–4、提示长度数百 token、解码阶段逐 token 流式输出、对首 token 延迟（TTFT）与每 token 延迟（TPOT）敏感。这两类对象的交集，正是社区建议与硬件能力冲突最尖锐的地带。

本文评述：社区建议的形成有其路径依赖——早期 llama.cpp 在 CPU 与低端 GPU 上以 4-bit 起家，量化是让模型“跑起来”的唯一手段，久而久之“能跑”被误读为“最优”。笔者认为，随着 16 GB 以上显存卡价格下探、FP8 内核逐步成熟，这套默认建议到了需要分场景重写的时候。下文将沿着“收益来源拆解 → 开销建模 → 精度核算 → 实测方法 → 选型矩阵”的顺序逐层展开。

二、量化收益的物理来源：显存、带宽与算力三分

2.1 三类收益的独立性

把“量化能加速”当成一个整体判断，是多数误区的起点。量化对推理的影响可以拆成三个物理上相互独立的通道：显存占用（决定模型能否加载、KV Cache 能开多大）、显存带宽（决定解码阶段每 token 需要搬运多少字节）、计算吞吐（决定矩阵乘单元每秒能做多少次乘加）。三者对应不同的硬件瓶颈，收益也完全不同。

显存占用的收益是确定的、无条件的。一个 70 亿参数模型，FP16 权重约 14 GB，INT4 权重约 3.5 GB（含量化常数与分组缩放因子，实际约 3.8–4.2 GB，视 group size 而定）。这项收益与硬件架构无关，纯粹是信息熵压缩的结果。显存带宽的收益在解码阶段几乎线性兑现：自回归解码是典型的内存受限（memory-bound）过程，每生成一个 token 都要把全部权重从 HBM 读一遍，权重位宽减半，理论带宽需求就减半。计算吞吐的收益则是有条件的——只有当硬件存在原生低位宽乘加单元时才会兑现，否则要先付出反量化成本。

本文评述：这张表解释了为什么“4-bit 更快”的体验在某些机器上成立、在另一些机器上不成立——它取决于你的负载落在哪个通道上。长上下文、大模型、显存吃紧时，带宽与显存通道主导，4-bit 明显占优；短提示、小模型、显存富余时，计算与内核开销主导，4-bit 的优势被反量化成本侵蚀。把这三条通道分开算账，是本文后续所有分析的方法论基础。

2.2 为什么消费级卡没有原生 INT4

数据中心卡与消费级卡在低位宽支持上的分野不是偶然。NVIDIA H100 的 Tensor Core 支持 FP8 并可通过 Hopper 的 DPX 指令处理 INT4/INT8 混合精度，AMD MI300 系列亦提供 FP8 与 INT8 矩阵指令；而 GeForce 系列的定位是图形与通用计算，INT4 的典型用武之地（推荐系统嵌入、超低精度推理）在消费场景需求薄弱，芯片面积与功耗预算被优先分配给光追单元与 FP16/FP8 吞吐。RDNA 3 的 AI 加速器提供 INT8 与 FP16 的 WMMA 指令，INT4 同样缺席。

更关键的是软件栈。cuBLAS 与 cuDNN 在消费级卡上并不暴露 INT4 GEMM 路径，PyTorch 的 torch.int4 相关算子长期处于实验状态，实际部署依赖 bitsandbytes、AutoGPTQ、llama.cpp 等第三方内核，这些内核在消费级卡上的实现质量参差不齐。换言之，即便硬件有零星支持，缺乏成熟的高性能内核也等于没有。这一点在实测中会以“4-bit 模型吞吐反而不如 FP16”的形式暴露出来。

三、反量化开销模型与 Roofline 定位

3.1 一个可计算的反量化开销模型

设权重矩阵为 W ∈ R^{M×K}，激活为 X ∈ R^{N×K}，输出 Y = XWᵀ ∈ R^{N×M}。INT4 分组量化（group size g）下，每个权重元素 w 由 4-bit 整数 q 与组缩放因子 s、零点 z 还原：w ≈ s·(q − z)。反量化的核心成本在于：必须先把 q 展开成 FP16 才能送入 Tensor Core，展开过程涉及位运算、类型转换与缩放乘加。

# 反量化开销的简化估算（模拟数据，用于量级判断）
# 以 7B 模型、单层线性层 M=K=4096 为例
M = K = 4096
g = 128                      # group size
num_groups = K // g
# 每个权重元素的反量化操作数（位解包 + 类型转换 + 缩放乘加）
ops_per_elem = 4             # 经验值，视内核实现 2~6 不等
dequant_ops = M * K * ops_per_elem
# FP16 Tensor Core 一次 MMA 可完成 16x8x16 的乘加
mma_macs = 16 * 8 * 16
mma_ops = 2 * mma_macs       # 乘加计 2 次运算
fp16_ops = M * K * 2         # 该层 FP16 矩阵乘的运算量（每输出元素 K 次乘加）
print(f"反量化操作量 / FP16 矩阵乘操作量 ≈ {dequant_ops / fp16_ops:.2f}")

按上述经验参数，反量化操作量约为 FP16 矩阵乘运算量的 2 倍——注意这是“操作数”而非“时间”，因为反量化是标量/向量运算，FP16 矩阵乘由 Tensor Core 以极高并行度完成，两者单位时间吞吐相差一到两个数量级。真实内核中，反量化通常与矩阵乘融合（fused dequant-GEMM），把开销摊薄，但摊薄程度取决于批大小 N：N 越大，同一份反量化后的权重被复用越多，摊销越充分；N=1 时，反量化几乎无法摊销。

本文评述：这正是交互式负载的软肋。对话场景解码阶段批大小常为 1，反量化开销无法被矩阵乘复用摊薄，4-bit 在计算通道上的劣势被放大；而预填充（prefill）阶段批大小等于提示长度，动辄数百，反量化被充分摊销，4-bit 反而可能因带宽节省而占优。一个模型在同一轮对话里，prefill 与 decode 的最优精度选择可能相反——这是很多“跑分说 4-bit 快、体感说 FP16 顺”矛盾的根源。

3.2 Roofline 视角下的落点

Roofline 模型用算术强度（arithmetic intensity，单位字节内存访问所对应的浮点运算数）判断一个内核落在内存受限区还是计算受限区。解码阶段单 token 生成时，算术强度约为 2·N（N 为批大小），N=1 时仅约 2 FLOP/Byte，远低于 RTX 4090 的拐点（约 80 FLOP/Byte，按 82.6 TFLOPS FP16 与 1008 GB/s 带宽估算）。因此解码阶段无论 FP16 还是 INT4，都落在内存受限区，理论上限由带宽决定：

# 解码阶段理论上限（模拟计算，参数取自公开规格）
BW = 1008e9          # RTX 4090 显存带宽 GB/s
params = 7e9         # 7B 模型
for bits in (16, 8, 4):
    bytes_per_param = bits / 8
    weight_bytes = params * bytes_per_param
    tps = BW / weight_bytes
    print(f"{bits}-bit 权重: 理论解码上限 ≈ {tps:.0f} tokens/s")

按此模型，7B 模型在 RTX 4090 上 FP16 理论解码上限约 72 tokens/s，INT4 约 288 tokens/s。但实测中 4-bit 往往只能跑到 100–150 tokens/s（llama.cpp 社区基准，2024），差距来自反量化与内核调度开销。FP16 实测则常能接近 60–70 tokens/s，兑现率反而更高。本文评述：兑现率（实测/理论）比绝对吞吐更能反映硬件对齐程度，FP16 在消费级卡上的高兑现率，正是“硬件擅长”的直接证据。

四、精度账本：INT4 到底损失了什么

速度之外，精度是选型的另一半。4-bit 权重量化的误差来源可分解为三块：量化舍入误差（每个权重被映射到 16 个离散值之一）、分组缩放误差（组内共享一个缩放因子，组内动态范围被压缩）、异常值（outlier）处理误差。后两者是 INT4 特有的痛点。LLM 的激活与权重中存在显著的通道级异常值，这是 SmoothQuant（Xiao 等，2023）与 LLM.int8()（Dettmers 等，2022）反复确认的现象。4-bit 权重量化对异常值更敏感，AWQ（Lin 等，2024）通过激活感知的通道缩放缓解，GPTQ（Frantar 等，2023）用二阶信息逐层补偿，但都无法完全消除。

精度损失在下游任务上的表现并不均匀。困惑度（perplexity）对 4-bit 通常只上升 2%–5%，看起来可接受；但在需要精确数值、长链推理、代码生成的任务上，退化会被放大。笔者综合公开评测（Open LLM Leaderboard 的量化模型条目、GPTQ/AWQ 原论文的消融实验）观察到一条经验规律：任务对“分布外泛化”的依赖越强，4-bit 的相对退化越明显。数学推理与代码补全恰属此类。

注：显存为权重部分估算，含量化常数；困惑度增幅为公开论文与社区评测的区间整合，非单一来源精确值，仅供量级参考。

本文评述：精度账本的关键不是“4-bit 能不能用”，而是“在你的任务上退化是否越过可接受阈值”。对话闲聊对 2%–5% 的困惑度上升几乎无感；代码补全对标识符一致性与长程依赖敏感，退化体感明显。把精度损失当作一个与任务强相关的变量，而非一个固定常数，是理性选型的前提。

五、交互式负载的特征与实测方法

5.1 交互式负载的四个特征量

要判断 FP16 与 INT4 谁更稳健，先要把“交互式”量化成可测量的指标。笔者认为至少四个特征量决定了选型：批大小（并发请求数）、提示长度分布、生成长度分布、延迟敏感度。对话场景典型值为批大小 1–4、提示 200–2000 token、生成 100–800 token、TTFT 敏感度高于 TPOT。这四个量共同决定了负载落在内存受限区还是计算受限区，也决定了反量化开销能否被摊销。

一个常被忽略的事实是：交互式负载的延迟由 prefill 与 decode 两段拼接而成，两段的最优精度可能不同。prefill 是计算受限（批大小大、算术强度高），decode 是内存受限（批大小小、算术强度低）。若框架支持混合精度——prefill 用 FP16 保证算力兑现，decode 用 INT4 保证带宽节省——理论上可兼得。但主流推理框架（vLLM、llama.cpp）目前以整模型统一精度为主，混合精度需要额外工程改造，这构成了一个现实约束。

5.2 可复现的实测步骤

社区跑分常因测试条件不透明而失真。下面给出一套最小可复现的评测流程，读者可在自己的卡上执行，得到与自身负载对齐的结论，而不是照搬他人数字。

第一步，固定模型与量化版本。选同一基座模型的 FP16、FP8、AWQ-INT4 三个版本，确保 tokenizer 与对话模板一致，避免模板差异污染结果。

第二步，固定输入分布。准备 50 条真实业务提示，长度覆盖短（<300 token）、中（300–1000）、长（>1000）三档，生成长度统一上限 512 token，温度设为 0 保证可复现。

第三步，测量 TTFT、TPOT 与吞吐。用 vLLM 的 benchmark 脚本或 llama.cpp 的 llama-bench，每档重复 5 次取中位数，记录显存峰值。

# vLLM 吞吐与延迟基准（示例命令，参数按需调整）
python -m vllm.entrypoints.openai.api_server \
  --model ./Qwen2.5-7B-Instruct-AWQ \
  --quantization awq --dtype float16 \
  --max-model-len 8192 --gpu-memory-utilization 0.92

# 另开终端，用 benchmark_serving 压测
python benchmarks/benchmark_serving.py \
  --backend openai --model ./Qwen2.5-7B-Instruct-AWQ \
  --dataset-name sharegpt --num-prompts 50 \
  --request-rate 1 --max-concurrency 1

第四步，测量任务精度。在代码补全（HumanEval）、数学（GSM8K）、指令遵循（IFEval）三个子集上各跑一遍，记录 pass@1 与严格匹配率，与 FP16 基线做差。这一步是很多跑分缺失的，却是判断“稳健”的核心。

第五步，计算兑现率与性价比。用实测吞吐除以第三节的理论上限，得到兑现率；再用吞吐除以显存占用，得到单位显存效率。两个指标结合，才能回答“这张卡上哪个精度更划算”。

拓展阅读：vLLM 官方基准文档（docs.vllm.ai/benchmarking）、llama.cpp 的 llama-bench 说明（github.com/ggml-org/llama.cpp）、NVIDIA TensorRT-LLM 性能调优指南（nvidia.github.io/TensorRT-LLM）。

六、分场景选型矩阵与操作路径

6.1 选型矩阵

把前五节的分析收敛成一张可操作的决策表。矩阵的两个维度是“显存是否足以容纳 FP16 权重 + 目标上下文 KV Cache”与“负载是否以低并发交互为主”。

本文评述：这张矩阵最重要的信息是“FP16 的适用区间并不小”。在 24 GB 卡跑 7B 模型这一最常见的个人开发者配置下，FP16 不仅装得下，而且兑现率最高、精度无损，社区默认推 4-bit 在这里是次优解。只有当模型规模逼近显存上限，或需要长上下文挤占 KV Cache 时，INT4 的显存收益才压倒其计算与精度代价。

6.2 操作路径：从默认 4-bit 迁移到硬件对齐

对已经在用 4-bit 的读者，下面给出一个渐进式迁移路径，避免一次性推倒重来。

第 1 步，量化显存余量。用 nvidia-smi 或框架日志记录当前 4-bit 部署的显存峰值，计算“FP16 权重 + 目标上下文 KV Cache”是否装得下。装得下，进入第 2 步；装不下，维持 INT4，跳到第 4 步。

第 2 步，A/B 测延迟与精度。按第五节流程，在同一批提示上对比 FP16 与 INT4 的 TTFT、TPOT 与任务精度。若 FP16 的 TPOT 不劣于 INT4 且精度更优，直接切换；若 FP16 的 TPOT 明显更差（通常发生在长上下文、KV Cache 挤占导致换页时），说明显存仍是瓶颈，维持 INT4。

第 3 步，尝试 FP8 折中。若 FP16 装不下但 INT4 精度不满意，FP8（E4M3）是中间解。Ada 架构原生支持 FP8，vLLM 与 TensorRT-LLM 均有成熟内核，显存减半而精度损失通常小于 1.5%。注意 FP8 需要模型有对应的量化检查点，或使用在线动态量化。

第 4 步，若必须用 INT4，优化内核与分组。优先选 AWQ 而非朴素 RTN，分组大小取 128（而非 32），启用融合反量化内核（bitsandbytes 的 bnb_4bit_use_double_quant 可再省约 0.4 bit/参数），并确认框架走的是融合路径而非“先反量化整层再 GEMM”的低效路径。

拓展视频：Andrej Karpathy 的“Let's reproduce GPT-2”系列中关于精度与吞吐的实操讲解（youtube.com/watch?v=l8pRSuU81PU），以及 GPU MODE 社区关于量化内核的讲座（youtube.com/@GPUMODE）。

七、对比与局限：INT4 不可替代的边界

为避免文章滑向“FP16 万能论”，必须明确 INT4 的不可替代区间。第一是显存硬约束：当模型参数量乘以 2 字节已超过可用显存时，INT4 不是优化选项而是唯一选项，此时讨论“哪个更快”没有意义。第二是高并发服务：批大小增大后反量化被充分摊销，INT4 的带宽优势转化为吞吐优势，这在单卡多用户的本地部署中真实存在。第三是端侧与边缘设备：Jetson、手机、NPU 等平台往往有原生 INT4 或混合精度支持，与消费级 dGPU 的情况相反。

局限同样要讲清楚。本文的定量结论依赖公开规格与社区基准的整合，未做跨卡的全矩阵实测，兑现率数字存在机型差异；反量化开销模型中的经验参数（每元素 4 次操作）是量级估计而非精确测量；精度退化区间来自多来源整合，具体任务需自行验证。这些局限不影响“硬件对齐”这一方法论的有效性，但提醒读者不要把他人的数字当作自己的结论。

本文评述：把 INT4 与 FP16 对立起来是另一种偷懒。二者是不同约束下的不同工具，真正需要反对的是“无条件默认 4-bit”的思维定式。工程判断的价值恰恰在于识别约束：显存约束下选 INT4，算力兑现约束下选 FP16/FP8，精度约束下二者都要让位于任务验证。

八、结论与展望：跟着硬件能力走

回到标题的问题：跟着社区走还是跟着硬件能力走？答案不是二选一，而是把社区建议当作先验、把硬件能力当作似然、用自己的实测做后验更新。社区建议告诉你“大多数人受显存约束”，硬件能力告诉你“这张卡擅长 FP16/FP8、不擅长 INT4”，你的负载特征告诉你“反量化能否被摊销”。三者结合，才能得出属于你的结论。在 24 GB 卡跑 7B 模型的交互式场景，这个结论大概率是 FP16 或 FP8；在 8 GB 卡跑 13B 模型，大概率仍是 INT4。

展望未来，硬件正在向低位宽原生支持演进。NVIDIA Blackwell 架构引入的 FP4 与 MXFP4 格式（NVIDIA Blackwell 架构技术简报，2024）在数据中心侧提供了原生 4-bit 浮点算力，MX 格式（微缩放，microscaling）以块共享指数的方式兼顾动态范围与位宽，是 INT4 的强力替代路线。若这一能力下放到消费级产品线，“4-bit 不擅长”的前提将被改写，本文的结论也需要随之更新——这正是“硬件对齐”方法论的题中之义：结论会过时，方法不会。

最后给出一条可立即执行的最小行动：打开你的推理框架日志，记录当前 4-bit 部署的显存峰值与 TPOT；若显存峰值低于卡容量的一半，就花半小时按第五节流程跑一次 FP16 对照。数据会告诉你该跟谁走。