按显存选卡的基本逻辑
选卡先看显存容量：要同时装下权重、KV 缓存与框架开销，权重决定「跑不跑得起来」，KV 决定「能并发多少」。容量确定后再看显存带宽，它决定单请求解码速度的量级；最后看散热形态与生态支持。容量不够时有两条路：降低精度（量化）或把权重切到多张卡上并行。
容量核算速记（粗算）
容量核算速记（粗算）
# 权重的十进制口径估算（先确认 GB 与 GiB 口径一致）
7B FP16 权重 约 14 GB
7B INT4 权重 约 4 GB
13B FP16 权重 约 26 GB
70B INT4 权重 约 40 GB
# 再叠加：KV 缓存（随上下文与并发线性增长）+ 框架与工作区开销 1~3 GB
# 结论：容量 = 权重 + KV 池 + 预留，三项都要写进采购单容量档位与典型用途
| 显存档位 | 能做什么 | 约束 |
|---|---|---|
| 16 GB 级 | 7B 量化模型开发验证、嵌入与重排模型常驻 | 长上下文与大并发空间很小 |
| 24 GB 级 | 7B 至 13B 量化模型对外服务 | 高并发仍需压缩上下文长度 |
| 40 至 48 GB 级 | 中等模型高精度推理、混合部署多个小模型 | 大模型仍需量化 |
| 80 GB 级 | 大参数模型推理或长上下文服务 | 成本高，需要按业务量评估 |
| 更大容量档 | 超长上下文与高并发场景 | 采购与供电、散热配套要求高 |
选型顺序
- 第一步定模型与精度：先确定要用哪个模型、什么量化档位，权重体积才有基线
- 第二步算 KV：按目标上下文长度与并发数算出 KV 池，不要用平均长度估
- 第三步留余量：框架与工作区开销额外预留，容量按九成上限规划
- 第四步看带宽：解码速度受显存带宽约束，容量相同也要比较带宽档位
- 第五步确认生态：架构是否在框架支持矩阵内、卡间互联方式是否满足多卡方案
常见误判
| 只算权重 | 长上下文并发时 KV 可能超过权重占用 |
|---|---|
| 按满载率规划 | 缺少余量时一条长请求就能把服务打挂 |
| 忽略子型号 | 同型号不同版本容量与带宽差异明显 |
| 忽略功耗与散热 | 机房供电与风道不支持时卡上不了架 |
容量不够时的优先级：先量化（省权重），再缩短上下文上限（省 KV），最后才考虑多卡切分，因为多卡会引入通信开销与新的故障点。
口径要统一：十进制 GB 与二进制 GiB 相差约百分之七，在大模型边界机型上足以决定是否溢出。