部署前最常被问的问题是"要什么显卡"。显存需求可以拆成三部分估算：
显存 ≈ 模型权重 + KV 缓存 + 运行开销
1. 模型权重
权重显存 ≈ 参数量 × 每个参数占用的字节数。
| 精度 | 每参数字节 | 70 亿参数 | 140 亿参数 | 320 亿参数 | 700 亿参数 |
|---|---|---|---|---|---|
| FP16 / BF16 | 2 | 约 14 GB | 约 28 GB | 约 64 GB | 约 140 GB |
| INT8 | 1 | 约 7 GB | 约 14 GB | 约 32 GB | 约 70 GB |
| INT4 | 约 0.5 | 约 4 GB | 约 7 GB | 约 16 GB | 约 35 GB |
4 位量化的实际占用通常比 0.5 字节/参数略高（部分层保留高精度），上表为下限参考。
2. KV 缓存
模型每生成或读取一个 token，都要缓存该 token 在每一层的 Key 和 Value。每个 token 的 KV 缓存为：
2（K 和 V）× 层数 × KV 头数 × 每头维度 × 每元素字节数
以一个 320 亿参数级、采用分组查询注意力（GQA）的模型典型结构为例（64 层、8 个 KV 头、每头 128 维、FP16）：
2 × 64 × 8 × 128 × 2 字节 = 262,144 字节 ≈ 0.25 MB / token
- 单个请求上下文 4,000 token：约 1 GB；
- 16 个请求同时各 4,000 token：约 16 GB。
所以并发和上下文长度往往比模型本身更吃显存。具体层数和头数请查看所选模型的配置文件（config.json）。
3. 运行开销
推理框架、激活值、显存碎片等，一般预留 10%–20%。
一个完整的例子
320 亿参数模型、INT4 量化、希望支持 8 路并发、每路 4,000 token 上下文：
| 项目 | 估算 |
|---|---|
| 权重 | 约 16–19 GB |
| KV 缓存 | 8 × 1 GB = 约 8 GB |
| 开销（15%） | 约 4 GB |
| 合计 | 约 28–31 GB |
单张 24 GB 显卡放不下，需要 32 GB 以上的显卡，或两张卡，或缩短上下文、降低并发。
速度怎么估
生成阶段每个 token 都要把权重从显存读一遍，因此单请求生成速度的上限 ≈ 显存带宽 ÷ 权重大小。例如显存带宽约 1 TB/s、权重约 16 GB 时，单请求上限约每秒 60 个 token（实际更低）。多个请求合并批处理时，总吞吐会显著高于单请求速度，这正是 vLLM 等框架的价值。
估算之后
纸面估算只能确定量级，最终要用真实问题和预期并发在目标硬件上压测一次。我们在自有环境中可以先替你跑这一步，再决定采购方案。