24GB跑32B模型4-bit量化后理论显存约14.9GB、实测首token 1.2秒、生成45 tok/s，但这是“刚好卡进去”还是“留有余量”，32B在4090上到底是可用还是勉强？

摘要

32B 参数模型以 4-bit 权重（约 4.5 bit/参数含量化元数据）落盘，理论权重占用约 14.9GB，在 24GB 的 RTX 4090 上看似“刚好卡进去”。但推理显存从来不是单一权重项：KV Cache 随上下文线性增长、CUDA context 与框架运行时存在固定开销、prefill 阶段激活峰值与 CUDA Graph 预留会进一步抬升水位。本文以“显存预算的确定性边界”为贯穿主线，逐项拆解权重、KV Cache、激活、碎片与框架开销，给出可复现的核算公式与配置路径；结合公开基准与社区实测数据，分析首 token 1.2 秒、解码 45 tok/s 的合理性边界与归因；并讨论在长上下文、并发批处理、多模态扩展等条件下该配置从“可用”滑向“勉强”的临界点。结论是：在 4K 上下文、单请求、无并发的推理场景下，32B 4-bit 在 4090 上属于“可用但余量有限”；一旦上下文超过 8K 或引入并发，即进入“勉强”区间，需要以 KV Cache 量化、分页注意力或分层卸载换取确定性。

一、问题的提出：一个数字背后的三个未知量

“32B 模型 4-bit 量化后权重约 14.9GB，24GB 显存能跑”——这句话在技术社区流传甚广，但它把三个性质完全不同的量压缩成了一个数字。第一个量是静态权重占用，由参数量与量化位宽决定，可精确计算；第二个量是动态运行时占用，包括 KV Cache、激活峰值、CUDA context、内存分配器碎片，随上下文长度、批大小、框架实现而变；第三个量是性能余量，即系统在接近显存上限时是否仍能维持稳定吞吐，而非触发 OOM 或频繁换页。三者混为一谈，就会得出“能跑”与“跑得好”之间的巨大认知落差。

本文的分析主线由此确立：显存预算的确定性边界。所谓确定性边界，是指在给定模型、量化方案、推理框架与请求形态下，能够以公式或实测标定的方式，预先判断系统在何种条件下仍处于安全区、在何种条件下必然越界。这条主线贯穿全文——从逐项核算，到性能归因，再到临界线判定与工程路径，最终回答一个工程问题：32B 4-bit 在 4090 上，是“可用”还是“勉强”。

需要先界定几个概念。4-bit 量化通常指权重以 4 位整数存储，但实际显存占用并非严格的 0.5 字节/参数。主流方案如 GPTQ、AWQ、GGUF 的 Q4_K_M 均附带量化元数据（scale、zero-point、分组索引），实际比特率在 4.2–4.8 bit/参数之间浮动。以 32B 参数、4.5 bit/参数计，权重约 18GB；若以 4.25 bit 计，约 17GB；而“14.9GB”对应的比特率约为 3.73 bit/参数，更接近 Q4_0 或部分 4-bit 无分组方案的理论下限。这一差异本身就是一个需要澄清的起点。

本文评述：社区中“14.9GB”这一数字的流行，反映的是一种“权重中心主义”的显存观——把推理显存等同于模型文件大小。这种简化在 7B 以下模型上误差尚可接受，但在 32B 量级、长上下文场景下，KV Cache 与运行时开销足以让预算表失衡 30% 以上。工程判断必须从“文件多大”转向“水位多高”。

二、显存预算的逐项核算：从 14.9GB 到真实水位

2.1 权重项：比特率决定一切

权重的显存占用可写为 W = P × b / 8，其中 P 为参数量（32×10⁹），b 为有效比特率。不同量化方案的有效比特率差异显著：

可见，“14.9GB”对应约 3.73 bit/参数，低于主流 4-bit 方案的实际比特率。若采用 Q4_K_M，权重即达 18GB，留给 KV Cache 与运行时开销的空间仅 6GB 左右。这一修正直接改变结论的量级：不是“14.9GB 对 24GB，余量 9GB”，而是“18GB 对 24GB，余量 6GB”。本文评述：比特率的精确标定是显存预算的第一步，任何以“4-bit = 0.5 字节/参数”估算的做法都会系统性低估 6%–12%，在 32B 量级上即 1–2GB 的误差，足以决定长上下文能否开启。

2.2 KV Cache：随上下文线性增长的“隐形税”

KV Cache 的占用公式为 KV = 2 × L × H_kv × d_head × S × B × b_kv / 8，其中 L 为层数，H_kv 为 KV 头数（GQA 下小于注意力头数），d_head 为头维度，S 为序列长度，B 为批大小，b_kv 为 KV 精度比特率。以典型 32B 模型（如 Qwen2.5-32B、Yi-32B 量级）为例，L≈64，H_kv≈8（GQA），d_head≈128，FP16 KV 下每 token 每层约 2×8×128×2 字节 = 4KB，64 层即 256KB/token。4K 上下文约 1GB，8K 约 2GB，32K 约 8GB。

这一增长是线性的、不可压缩的（除非量化 KV 或采用分页/稀疏注意力）。在 18GB 权重 + 2GB 运行时开销的基线下，4K 上下文总水位约 21GB，尚在 24GB 内；8K 上下文即达 22GB，逼近上限；32K 上下文则必然越界。本文评述：KV Cache 是“刚好卡进去”叙事的最大漏洞——它把显存预算从静态问题变成了随请求形态变化的动态问题。判断“可用”还是“勉强”，本质上是在判断“在目标上下文长度下，KV Cache 是否仍落在余量之内”。

2.3 运行时开销：被低估的固定项与碎片项

CUDA context 在 4090 上通常占用 300–600MB，取决于驱动版本与是否启用 CUDA Graph。推理框架（vLLM、llama.cpp、TensorRT-LLM、ExLlamaV2）的运行时开销差异明显：vLLM 的 PagedAttention 需要预分配 KV 块表，llama.cpp 的 mmap 加载会保留文件映射页，TensorRT-LLM 的 engine 包含额外 workspace。激活峰值在 prefill 阶段最高，与批大小和序列长度相关，通常 0.5–1.5GB。分配器碎片在长时间运行、变长请求下会累积，PyTorch 的 caching allocator 虽能复用，但峰值水位仍会抬升 5%–10%。

这些项单独看都不大，合计却可达 2–3GB，恰好是“14.9GB 叙事”中被忽略的部分。本文评述：工程上应以“实测峰值显存”而非“理论权重”作为预算基准，并在部署前用 nvidia-smi -l 1 或框架内置的显存监控做压力标定。可参考 NVIDIA 官方关于 CUDA 内存管理的文档（CUDA C++ Programming Guide）与 PyTorch 显存管理说明（PyTorch CUDA semantics）。

三、性能归因：1.2 秒首 token 与 45 tok/s 是否可信

3.1 首 token 延迟：prefill 的计算与访存双重约束

首 token 延迟（TTFT）由 prefill 阶段决定，其计算量约为 2 × P × S FLOPs（S 为输入长度）。以 32B 参数、1K 输入计，约 6.4×10¹³ FLOPs。4090 的 FP16 稠密算力约 165 TFLOPS（Tensor Core，稀疏翻倍），理论下限约 0.39 秒；但 4-bit 量化权重在解码时需反量化，实际有效算力受限于访存带宽（约 1TB/s）与反量化开销。1.2 秒的 TTFT 对应约 53 TFLOPS 的有效利用率，处于合理区间——尤其当输入包含较长 system prompt 或 RAG 上下文时。

本文评述：TTFT 的瓶颈在 prefill 阶段主要是计算，但 4-bit 权重的反量化会引入额外指令开销，使得有效算力低于标称值。若框架支持 W4A16（权重 4-bit、激活 16-bit）且反量化融合进 GEMM，效率较高；若反量化在 kernel 外单独执行，TTFT 可能劣化 20%–40%。因此 1.2 秒这一数字的可信度，高度依赖具体框架与 kernel 实现。

3.2 解码吞吐：访存带宽是硬约束

解码阶段每生成一个 token，需读取全部权重一次（自回归特性）。32B 4-bit 权重约 18GB，4090 显存带宽约 1008GB/s，理论解码上限约 1008 / 18 ≈ 56 tok/s。实测 45 tok/s 对应带宽利用率约 80%，属于优秀水平。这一归因是自洽的：45 tok/s 不是算力瓶颈，而是带宽瓶颈，且已接近该硬件的物理上限。

本文评述：这一数字同时揭示了一个重要边界——解码吞吐几乎不随上下文长度显著下降（KV Cache 读取量相对权重读取量较小），但会随批大小提升而摊薄。单请求 45 tok/s 与批大小 4 时总吞吐 120 tok/s 并不矛盾，后者以单请求延迟换总吞吐。工程上若追求交互体验，45 tok/s 已足够流畅；若追求服务吞吐，应转向批处理与连续批处理（continuous batching）。可参考 vLLM 官方文档中关于 PagedAttention 与连续批处理的说明（vLLM Documentation）。

四、可用还是勉强：三条临界线与判定矩阵

判断“可用”还是“勉强”，不能凭感觉，而应设定可量化的临界线。本文提出三条：显存临界线（峰值水位 / 总显存 ≤ 90%，留 10% 给碎片与突发）、延迟临界线（TTFT ≤ 2 秒，解码 ≥ 30 tok/s，低于此交互体验明显劣化）、稳定性临界线（连续 100 次变长请求无 OOM、无显著吞吐衰减）。三条线同时满足为“可用”，任一越界为“勉强”。

按此框架，4K 上下文、单请求、Q4_K_M 配置下：显存水位约 21.6GB，占比 90%，恰在临界线上；TTFT 1.2 秒、解码 45 tok/s，满足延迟线；稳定性需实测验证，但余量仅 2.4GB，变长请求下碎片累积有越界风险。结论是“可用，但余量有限”。8K 上下文下显存水位约 22.6GB，占比 94%，越界；32K 下必然 OOM。本文评述：所谓“刚好卡进去”，精确地说，是“在 4K 上下文、单请求、特定量化方案下刚好落在临界线上”。任何一项条件放宽，都滑向“勉强”。

五、工程路径：可复现的部署步骤与调参清单

路径一：llama.cpp + GGUF Q4_K_M，适合单机快速验证。步骤：① 从 Hugging Face 获取对应模型的 GGUF 量化文件；② 以 -ngl 99 全量卸载至 GPU，-c 4096 设定上下文，-ctk q8_0 -ctv q8_0 量化 KV Cache 以释放余量；③ 用 nvidia-smi 监控峰值，逐步提升上下文至 OOM 前一点，记录安全上限。llama.cpp 官方仓库提供了完整的编译与量化教程（llama.cpp GitHub）。

路径二：vLLM + GPTQ/AWQ，适合服务化与批处理。步骤：① 安装匹配 CUDA 版本的 vLLM；② 以 --quantization gptq --max-model-len 4096 --gpu-memory-utilization 0.92 启动，注意 gpu-memory-utilization 不宜设满，留 8% 余量；③ 启用 --enable-prefix-caching 复用 system prompt 的 KV；④ 以 --max-num-seqs 控制并发，避免 KV 块耗尽。本文评述：vLLM 的 PagedAttention 将 KV 分块管理，碎片更少，但块表本身有开销；在 24GB 卡上，gpu-memory-utilization 设为 0.90–0.92 是经验安全区。

路径三：ExLlamaV2 / TensorRT-LLM，适合追求极致吞吐。ExLlamaV2 的 EXL2 量化支持可变比特率（如 4.0–4.5 bpw），可在精度与显存间细调；TensorRT-LLM 需编译 engine，对固定形状优化明显，但变长请求需预留 workspace。可参考 TensorRT-LLM 官方示例（TensorRT-LLM GitHub）与 ExLlamaV2 文档（ExLlamaV2 GitHub）。

调参清单（按优先级）：① 量化方案选 Q4_K_M 或 GPTQ group 128，避免无分组 Q4_0 的精度塌陷；② KV Cache 量化为 q8_0，可省约 50% KV 显存，代价是轻微精度损失；③ 上下文按实际需求设定，不要盲目开 32K；④ 关闭不必要的 CUDA Graph 预留或调小 workspace；⑤ 监控峰值显存，以 90% 为红线；⑥ 变长请求场景下定期重启进程，清理碎片。本文评述：这些步骤的共同逻辑是“把不确定性转化为可测量的余量”，而非追求纸面参数的最大化。

六、前沿预判：量化、KV 压缩与异构卸载的演进方向

量化方向，4-bit 已趋成熟，2–3-bit 的可行性仍在验证。GPTQ、AWQ 之后，QuIP#、AQLM、QTIP 等方案在更低比特率上探索，但 32B 模型在 3-bit 以下的精度损失对推理任务是否可接受，尚无统一定论。本文评述：比特率的下降不是免费的，每降 1 bit，权重显存省约 4GB，但精度风险非线性上升；在 4090 这类消费级卡上，4-bit 仍是精度与显存的帕累托前沿。

KV 压缩方向，分页注意力（PagedAttention）、KV 量化、稀疏/滑窗注意力、跨层 KV 共享（如 YOCO 类结构）均在推进。KV 量化到 4-bit 可将 8K 上下文的 KV 从 2GB 压到 0.5GB，直接改变临界线。异构卸载方向，将部分层或 KV 放在 CPU 内存、通过 PCIe 按需换入，可突破显存上限，但 PCIe 带宽（约 32GB/s）远低于显存带宽，吞吐会显著下降。本文评述：卸载是“能跑”的兜底手段，不是“跑得好”的方案；在 4090 上，卸载一层约增 0.3GB 显存余量，却可能损失 10%–20% 吞吐，需按场景权衡。

更长远看，MoE 架构以稀疏激活降低单 token 计算量，但对显存的要求并未同比例下降（全部专家仍需驻留或换入）。本文评述：对 24GB 卡而言，稠密 32B 4-bit 已是“刚好卡进去”的极限形态；若要真正“留有余量”，要么降参数规模（如 14B–24B），要么等硬件显存提升，要么依赖 KV 压缩与量化的进一步成熟。可关注 Hugging Face 的量化模型库（Hugging Face GPTQ Models）与相关基准榜单。

七、结论

回到最初的问题：32B 4-bit 在 4090 上是“刚好卡进去”还是“留有余量”？以确定性边界的视角看，答案是分层的。在 4K 上下文、单请求、Q4_K_M 或 GPTQ group 128 配置下，显存水位约 21.6GB，占比 90%，处于“可用但余量有限”的状态；首 token 1.2 秒、解码 45 tok/s 的性能数据在带宽与算力归因上自洽，可信。一旦上下文升至 8K 或引入并发，水位越过 90% 红线，进入“勉强”区间；32K 上下文则不可行。所谓“14.9GB”是比特率下限的乐观估计，实际应以 17–18GB 权重为预算基准。

工程上的可操作结论是：把“能否跑”转化为“在目标上下文与并发下，峰值显存是否 ≤ 90%”。若满足，则可用；若不满足，优先用 KV 量化、前缀缓存、上下文裁剪换取余量，而非寄望于“理论显存”的乐观数字。32B 在 4090 上不是不能用，而是必须带着预算表用——这正是“确定性边界”方法论的价值所在。

主要参考文献

1. Frantar E, Ashkboos S, Hoefler T, Alistarh D. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR 2023. arXiv:2210.17323.
2. Lin J, Tang J, Tang H, et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys 2024. arXiv:2306.00978.
3. Kwon W, Li Z, Zhuang S, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023. arXiv:2309.06180.
4. Dettmers T, Pagnoni A, Holtzman A, Zettlemoyer L. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023. arXiv:2305.14314.
5. Ainslie J, Lee J, de Jong Z, et al. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints. EMNLP 2023. arXiv:2305.13245.
6. Xiao G, Tian Y, Chen B, et al. Efficient Streaming Language Models with Attention Sinks. ICLR 2024. arXiv:2309.17453.
7. Hooper C, Kim S, Mohammadzadeh H, et al. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization. NeurIPS 2024. arXiv:2401.18079.
8. Tseng A, Chee J, Sun Q, et al. QuIP#: Even Better LLM Quantization with Hadamard Incoherence and Lattice Codebooks. ICML 2024. arXiv:2402.04396.
9. Egiazarian V, Panferov A, Kuznedelev D, et al. Extreme Compression of Large Language Models via Additive Quantization. ICML 2024. arXiv:2401.06118.

说明：文中显存核算示例为基于公开模型配置（层数、KV 头数、头维度）与量化比特率的模拟整合数据，非单一实测来源；性能数据（TTFT 1.2s、45 tok/s）引自用户提供的实测场景，归因分析基于带宽与算力模型推算。数据集方面，本文未使用需预处理的自建数据集；引用的量化模型权重来自 Hugging Face 公开仓库，加载时按框架默认分词与配置处理。