模型量化后只有 4GB 左右，显卡 24GB，为什么一开长上下文或多人并发就不够用了？原因是，模型文件大小不等于部署时的显存需求，大语言模型的推理部署也不能只看模型权重。

模型权重只是 GPU 的核心占用。模型运行时，还要为已经读过的内容保留 KV Cache，并为计算过程、部署框架留出空间。另外，训练和微调还涉及梯度、优化器状态等，也需要占用 GPU。

先建立一张显存账单

可以把推理时的 GPU 占用近似拆成四部分：

总显存需求 ≈ 模型权重 + KV Cache + 推理临时显存 + 框架及其他预留空间

这是一张规划清单，不是模型一定能启动的精确公式。不同模型架构、量化格式和部署框架，实际占用都可能不同。其中，权重主要决定启动门槛；KV Cache 决定在实际使用中长上下文和并发会消耗多少额外空间。

第一笔账：模型权重

权重占用的粗略算法是：参数量 × 每个参数的存储字节数。

例如，一个 7B（约 70 亿参数）模型若使用 BF16 权重，每个参数约占 2 字节，权重本身约为 14 GB，折合约 13 GiB。若使用 4 bit 权重量化，按每个参数半字节计算，理论下限约为 3.5 GB。

但理论下限并不是实际显存占用：量化可能需要比例因子、元数据，部分层也可能使用更高精度。显卡还要给后续推理留空间。因此，不能用"显存容量 > 模型文件大小"作为唯一判断依据。

第二笔账：KV Cache 越聊越大

模型通常逐个生成 token。生成下一个 token 时，注意力机制需要参考之前的所有 token。如果每一步都重新计算已经处理过的内容，会出现大量重复工作。

KV Cache会保存前文 token 在各注意力层产生的 Key 和 Value，供后续生成复用。它用显存换取计算效率：输入越长、输出越多，已缓存的 token 通常越多。对使用完整注意力、普通 KV 存储方式的模型，可以这样粗估：

KV Cache ≈ 2 × 层数 × KV 头数 × 每头维度 × 每个元素字节数 × 已缓存 token 数 × 并发请求数

开头的 2 分别代表 Key 和 Value。注意这里是 KV 头数，未必等于查询头数。采用分组查询注意力（GQA）等结构时，多个查询头可共享较少的 KV 头，缓存需求因此下降。

假设：某模型有 32 层、8 个 KV 头、每头 128 维，KV Cache 用 BF16 存储。那么，每缓存一个 token 约需：2 × 32 × 8 × 128 × 2 字节 = 128 KiB

一条请求累计缓存 8192 个 token，约需 1 GiB。若同时处理 8 条同样长度的独立请求，粗略合计就是 8 GiB。这还没算权重及其他运行开销。

第三笔账：计算过程和部署框架也要显存

推理时还会出现临时张量、计算工作区和框架预留。一次处理较长输入，或同时处理较多输入 token，都可能抬高显存峰值。部分服务框架还会为 KV Cache 预分配空间，所以观察到的已用显存也未必等于当前对话实际写入的缓存量。

因此，同一张显卡上的"单人短对话能启动"与"多人长文档问答能稳定服务"是两项不同的验收目标。

两个真实模型，怎么把账算到部署选择上？

案例一：DeepSeek-R1-Distill-Llama-70B。日常所说的"DeepSeek-R1-70B"，通常指这个 70B 蒸馏模型，不是 DeepSeek-R1 原版大模型。其官方模型页标注约 71B 参数、BF16 权重；配置文件给出 80 层、8 个 KV 头、每头 128 维。

先看权重：按 71B × 2 字节粗算，BF16 权重约 142 GB（约 132 GiB）。若假设采用 4 bit 权重量化，理想下限约 35.5 GB，真实量化检查点还会有额外开销。

再看缓存：假设 KV Cache 仍用 BF16，单个 token 约占 320 KiB；一条请求累计 8192 个 token，约占 2.5 GiB。若同时有 4 条这样的独立请求，KV Cache 粗估约 10 GiB。因此，4 bit 权重约 35.5 GB 绝不意味着一张 40GB 卡就能稳定承载这个 8K、4 并发场景；即使换成 48GB 卡，也必须给量化元数据、计算峰值和框架预留空间做实测。

案例二：DeepSeek-V4-Flash-0731 原版检查点。这里用官方 0731 正式版代表用户常说的"V4-Flash 满血版"。DeepSeek 的官方将它列为正式版，V4-Flash 属于混合专家模型（MoE）：DeepSeek 技术文档给出 Flash 系列约 285B 总参数、每个 token 激活约 13B，支持最高 100 万 token 的上下文。13B 是每次计算激活的参数量，不是部署时只需装入 13B 权重。

对于 0731 检查点，vLLM 的部署方案列出约 167 GB 的检查点文件，并将原版部署的最低显存预算为 200 GB。

这个模型的缓存也不能直接代入前文估算的公式。DeepSeek V4 使用混合压缩注意力，并对长上下文缓存进行压缩；官方配置还包含滑动窗口等参数。正确做法是选定具体检查点、推理框架、缓存精度和目标上下文长度，查看启动时实际分配的缓存容量，再用目标并发压测。

这两个案例揭示了不同的瓶颈：R1 蒸馏 70B 可以从权重和 GQA 缓存逐项估算；V4-Flash 虽然每次只激活部分专家，原版权重的整体驻留需求仍很大，且缓存要按其专用注意力实现评估。

如果公司有 2000 人，该按多少并发部署？

2000 名员工不等于 2000 个推理并发。有人只是打开聊天页面，有人正在阅读回答；真正占用模型服务能力的，是尚未完成的生成请求。

没有企业使用日志时，可以先做一张假设性容量表。估算式为：

峰值并发 ≈ 日活人数 × 每人每天请求数 ÷ 工作时长（秒） × 高峰系数 × 单次请求持续时间（秒）

假设每天有 30% 的员工使用，即 600 人；每人每天提问 10 次，请求分布在 8 小时内；忙时流量是平均值的 5 倍，一次回答持续 30 秒。计算结果是 2000 × 30% × 10 ÷（8 × 3600）× 5 × 30 ≈ 31 并发。若日活提升到 50%、每人每天 20 次，其余条件相同，则约为 104 并发。

因此，可把 30～100 个同时生成中的请求作为初步压测区间，从 50 并发开始测试，再根据试点数据调整。

把并发代入前面的模型案例：若 50 条 R1 蒸馏 70B 请求都各自达到 8192 token，按 BF16 缓存粗估仅 KV Cache 就约 125 GiB。这是偏保守的同长度示例，不能当作日常平均占用。实际请求长短不同，也可以分布到多个模型副本。V4-Flash 的缓存要按其专用实现测量。

四种常见办法，分别省的是哪笔账？

模型权重量化主要减少模型权重占用，给运行时腾出空间；它不会自动压缩 KV Cache。

KV Cache 量化直接改变缓存精度，可能减少缓存占用，但要确认框架与硬件支持，并评估输出质量。它与权重量化是两项独立设置。

缩短上下文或控制并发直接限制缓存需求，代价是单次可处理的内容或同时服务的请求数减少。

分页式缓存与前缀复用改善缓存分配，或让共享相同提示词前缀的请求复用已有缓存和计算结果；它们不能让每个独有 token 的存储成本消失。

选显卡时，按真实业务倒着算

先确定模型版本、权重精度和部署框架，再明确三个业务数字：最长输入多少 token、最多生成多少 token、峰值同时处理多少条请求。用模型的层数、KV 头数和缓存精度估算 KV Cache，加上权重与运行余量，最后按真实请求长度、到达率和并发量做压力测试。

模型参数量只能回答第一步。要判断显卡是否真正匹配，还得回答：它能在目标上下文长度和并发量下，稳定、及时地完成任务吗？