估算显卡数量
按用量与服务等级选模型，再用显存倒推卡数
买多少张显卡，要从用量和服务等级倒推：先定用量，再选模型，最后用显存算出卡数。反过来按预算先定卡，常见的结果是权重装得下，并发撑不起。这些卡是为了让模型在企业自己的机房里跑；云 API 已经够用，或用量低且起伏大时，不必走这一页，判断方法见私有部署概览。
显存的构成
KV 缓存是模型为已读内容保存的中间结果，每多一路并发、每多一个 token 的上下文，它就多占一份显存。显存估算因此分块算：
| 块 | 估法 | 随什么增长 |
|---|---|---|
| 权重 | 参数量 × 每参数字节数。16 位约 2 字节，8 位约 1 字节，4 位约 0.5 字节；量化格式另带缩放系数等开销，所以只能取「约」 | 只随模型与精度 |
| KV 缓存 | 每个 token = 2 × 层数 × KV 头数 × 头维度 × 字节数；总量 = 每个 token × 上下文长度 × 并发序列数 | 随上下文长度与并发线性增长 |
| 其他占用 | 激活值与框架开销，无统一公式 | 看引擎启动日志与压测 |
这组公式出自 NVIDIA 的推理优化文章，文章给的算例是：70 亿参数的 16 位模型，权重约 14GB；Llama 2 7B 在 4,096 上下文、批大小 1 时，KV 缓存约 2GB。文章的 KV 公式写成「注意力头数 × 头维度」。有些模型让多个查询头共用一组 KV 头，这叫分组查询注意力（GQA）：KV 头数多于一个、少于查询头数，公式里就换成实际的 KV 头数，缓存相应变小。
KV 缓存装不下时，vLLM 会抢占部分请求，空间腾出后重算；文档提醒，抢占与重算会拉长端到端延迟（vLLM 优化页）。所以 KV 缓存要在选卡时就留出预算，不能等上线后靠引擎兜。
单卡放 72B 模型的算例
下面用 Qwen2.5-72B-Instruct 的结构参数（80 层、8 个 KV 头、隐藏维度 8,192 除以 64 个注意力头得头维度 128，取自它的 config.json），放到一张 84GB 显存的卡上，结果是权重装得下，并发只有个位数。这是对「70B 级稠密模型 8 位单卡可装」这类推算的展开。8 位权重按每参数 1 字节粗算，KV 缓存按 16 位。示例，不是 SZV 的配置结论。
| 步骤 | 算式 | 结果 |
|---|---|---|
| 权重 | 72B × 1 字节 | 约 72GB |
| 每个 token 的 KV | 2 × 80 × 8 × 128 × 2 字节 | 327,680 字节 |
| 一路 8,192 token | 327,680 × 8,192 | 约 2.7GB |
| 引擎可用显存 | 84 × 0.92 | 约 77.3GB |
| 单卡余量 | 77.3 − 72 | 约 5.3GB，尚未扣 CUDA graph 与激活 |
| 并发上限 | 5.3 ÷ 2.7 | 约 2 路 |
0.92 是 vLLM 的默认显存利用率（--gpu-memory-utilization），它是单个引擎实例的份额，其余显存留给引擎之外的占用（vLLM 引擎参数）。84GB 是 NVIDIA RTX PRO 6000D 的显存，三档表也取这个值，卡数与显存合计见私有部署概览的三档表。若把模型切到两张卡上（张量并行），可用显存 168 × 0.92 ≈ 154.6GB，余量约 82.6GB，同样粗算约 31 路。卡数翻倍，并发涨到约 16 倍：权重只占一份，多出来的显存几乎全进了 KV 缓存。这也是卡数不能按「参数量 ÷ 单卡显存」倒推的原因。
稀疏模型的显存
稀疏模型的显存看总参数，算力看激活参数。MoE（混合专家）模型每个 token 只激活一部分专家，但全部专家的权重都要放在显存里。gpt-oss-120b 的模型卡写明：总参数约 117B，激活参数 5.1B，对 MoE 权重做了 MXFP4 量化，可装进单张 80GB 的卡。按每参数 0.5 字节粗算，117B 约 58GB，与「装得进 80GB」相容；若按激活参数 5.1B 算，会把显存低估二十多倍。多卡部署时，专家被分到各卡上，卡间要做 all-to-all 通信（vLLM 专家并行）。
放不下时的出路
放不下时，常见的说法是「降精度，别加卡」。质量不够时，加卡也是正当的路径。每条出路换来什么、付出什么，见下表。
| 出路 | 换来什么 | 付出什么 | 依据 |
|---|---|---|---|
| 权重量化（FP8、4 位） | FP8 把模型显存降到约一半 | 质量要用评测集复测；FP8 的 W8A8 需要算力等级 8.9 及以上，更早的架构只能用 W8A16 | vLLM FP8 |
| KV 缓存量化 | 同样显存存下更多 token | 文档称滑动窗口等注意力层对它更敏感；推荐用校准数据集估计缩放系数 | vLLM KV 缓存量化 |
| 缩上下文或降并发 | 每批需要的缓存变少 | 排队变长，业务要接受 | vLLM 优化页 |
| 换稀疏模型加量化 | 同能力档下单卡可装 | 总参数仍要常驻；能力要用评测集验证 | 上文 gpt-oss-120b 模型卡 |
| 加卡做张量并行 | 每张卡上的权重变少，KV 余量变多 | 卡间同步开销；文档提醒调大并行度可能带来过多同步 | vLLM 优化页 |
| 换更大显存的卡 | 不改拓扑 | 供货与型号更名受进出口政策影响 | 见私有部署概览的三档表 |
加卡与卡间互联
加卡的代价在卡间互联。vLLM 的并行文档给了一条顺序：模型一张卡装得下，分布式推理多半没有必要；装不下但一台机器的几张卡放得下，用张量并行；同一页还写到，机内的卡没有 NVLink 时，改用流水线并行通常吞吐更高、通信开销更小，文档举的例子是 L40S（vLLM 并行与扩展）。
RTX PRO 6000D 没有 NVLink，多卡走 PCIe。所以「一台」档 2–4 卡到底用张量并行还是流水线并行，凭卡数推不出来，要在目标并发下两种都压测。三档的卡数与显存合计见私有部署概览的三档表。
前缀缓存
前缀缓存缩短等待，不省显存：它让共享同一段开头的请求复用已算好的 KV 缓存。vLLM 文档写明，它只缩短处理请求的预填充阶段，不缩短生成阶段；输出很长、或新请求之间没有共同前缀时，它没有收益（vLLM 前缀缓存）。知识库问答的系统提示与固定资料前缀较长，可能受益，是否值得开，由压测的 TTFT 回答。
模型选型的补充维度
权重许可证、中文能力、上下文长度、工具调用、显存占用、量化与硬件，这些维度见私有部署概览。下面再补直接影响卡数与采购的项：
| 维度 | 看什么 | 判据 |
|---|---|---|
| 配套模型 | 知识库还要部署嵌入模型，通常还有重排模型，它们同样占显存与算力 | vLLM 的池化模型文档提供 /v1/embeddings、/rerank 等端点，示例都是单独启动一个池化模型。引擎参数页写明显存利用率是单个实例的份额，同一张卡上可以跑多个实例、各占一份；预算时按独立实例计显存 |
| 向量维度 | 嵌入模型的输出维度与向量库的索引上限 | 以 pgvector 为例，vector 类型索引最多 2,000 维，halfvec 最多 4,000 维（pgvector） |
| 更新与回退 | 权重只能经介质或白名单通道带入；新版本入库后要重跑评测集 | 旧版本权重与它的哈希保留到新版通过验收，见上线前安全核对的入闸检查 |
引擎比较
引擎的比较维度是：许可证、请求格式的兼容范围、量化与硬件支持、并行方式、指标与认证。其中最容易漏的是兼容范围。「兼容 OpenAI 接口」通常只是子集：Ollama 的文档写明它支持 OpenAI API 的一个子集，对话接口的 logprobs、tool_choice、n 都未支持（Ollama 兼容性）。vLLM 则在标准字段之外加了 structured_outputs 等扩展参数（vLLM 在线服务）。
做法因此是先把经营系统实际用到的请求字段列成清单，再逐个引擎核对，见私有部署的组成。认证也要单独核对：vLLM 自带的访问密钥只覆盖 /v1、/v2、/inference 等前缀，文档要求不要单靠它做访问控制。
采购前逐类核对
| 类别 | 核对什么 | 不满足的后果 |
|---|---|---|
| 卡与引擎 | 所选引擎是否支持这家厂商的卡与驱动版本；国产卡走引擎的硬件插件时，量化与并行功能是否与上文各行一致 | 选定的出路在该卡上用不了 |
| 整机与卡位 | 双宽卡的卡位数；每卡供电与散热。至少一家整机厂对每张 6000D 标 600W，各来源给出的功耗在 400–600W 之间不一，要求主机按上限供电并散热。推荐配置以报价时为准 | 卡插不满，或降频运行 |
| 卡间互联 | 有无 NVLink；PCIe 的代际与通道数 | 并行方式的选择范围缩小 |
| 存储 | 容纳权重与镜像的空间；向量库与索引的空间；日志、留痕与备份的位置；盘的冗余方式 | 换模型版本时没有空间并存新旧两版 |
| 网络 | 业务口与管理口分开；带外管理口独立；多机时机间连接方式，见网络与机房条件 | 网段无法按规划隔离 |
| 离线安装包 | 驱动、容器 GPU 运行时、镜像与权重随介质带入 | 到场后装不起来 |
| 保修 | 保修范围、部件更换方式、现场服务条款，由企业与供应商确认 | 故障时责任与时限没有依据 |
整机的供电、散热、重量与尺寸，对照网络与机房条件的场地一节。
限制与不适用
- 估算只给上下界，最终卡数要在目标并发下压测校正。
- 上文算例是粗算，没有扣激活与框架占用。
- 权重量化和 KV 缓存量化对质量的影响，这里不下结论，要用企业的评测集复测。
- 国产卡路线的显存与引擎适配另算。
- 云 API 已经够用的场景，不必走这一页。
与常见做法对照
| 常见做法 | 它省了什么 | 代价 |
|---|---|---|
| 先按预算定卡，再找模型 | 采购流程简单 | 权重装得下、并发撑不起，见上文算例 |
| 只按「参数量 × 字节数」估算 | 一眼出数 | 漏掉 KV 缓存；MoE、量化、GQA 都会改变结果 |
| 用公开榜单选模型 | 省一轮评测 | 榜单不是企业自己的资料，达线与否由评测集决定 |
| 按引擎标称的峰值吞吐定卡数 | 数字好看 | 并发拉高时每个用户等得更久，容量要取 TPOT 仍达标的那个点 |
验收时可以问的问题
- 无 NVLink 的卡上，请出示目标并发下张量并行与流水线并行两种方式的压测结果。
- 目标精度（8 位或 4 位）的权重，请用企业评测集给出相对全精度的得分。
- KV 缓存量化前后，请用评测集各测一次，并说明校准数据取自哪里。
- 请在显存预算里列出嵌入与重排模型各占多少，以及是否与对话模型同卡。
- 请出示经营系统实际用到的请求字段清单；引擎升级后，对着清单重跑一遍。
- 走国产卡路线的，请逐行核对引擎适配的量化与并行功能与上文各行是否一致。