🗂️ GPU 容量规划
1. 显存账：一张卡的四个住户
| 组成 | 规模 | 随什么变化 | 规划要点 |
|---|---|---|---|
| 模型权重 | 参数数 × 位宽 | 固定（选定模型+量化后） | 第一约束：27B BF16≈54G / FP8≈27G / INT4≈14G |
| KV Cache | 2 × n_layers × n_kv_heads × head_dim × 位宽 × seq_len × 并发数 | 随 max-model-len 与并发数线性增长 | 长上下文的头号变量，见下节 |
| 激活/中间张量 | batch × seq × hidden | 随并发与序列长 | 通常 1-3GB，长 prefill 峰值高 |
| CUDA 上下文 + 碎片 | 1-2GB/卡 | 基本固定 | 预留，别把显存按 100% 规划 |
📌 工程法则：
可用KV显存 = 显存总量 × gpu-memory-utilization − 权重 − 激活预留(2G) − 上下文预留(1.5G)，再 ÷ 每 token KV 大小 = 可承载总 token 数。2. KV Cache 估算（示例）
以 27B 级稠密模型（GQA，等效 KV 头 8、hidden 4096、80 层）BF16 为例，每 token KV ≈ 2 × 8 × 512 × 2B × 80 ≈ 1.31MB/token（GQA 压缩后；MHA 架构约为其 4-8 倍）：
| max-model-len | 单请求 KV 峰值 | 24G 卡（权重 14G，剩 ~8G）可支撑并发 |
|---|---|---|
| 8K | ≈10.5MB | ~700 请求（实际受 max-num-seqs 与算力先限） |
| 32K | ≈42MB | ~180 |
| 128K | ≈168MB | ~45 |
| 153K（≈176K 场景） | ≈200MB | ~40（单卡 INT4 权重的理论值，实际按实测校准） |
结论直观：上下文长度翻 4 倍，同硬件并发容量砍 3/4。"支持 176K"和"176K 下还能多少并发"是两个问题——容量规划必须同时回答。
3. 规划方法：从业务到卡数
- 需求：峰值并发 C、典型/最大上下文 L_typ / L_max、SLO（TTFT/TPOT P95）。
- 算单卡能力：按上节公式 + 实测拐点（vLLM 压测）得到单卡（或单 TP 组）在 SLO 下的 Goodput G。
- 定数量：N = ⌈C / G⌉，再按 20-30% 冗余向上取整（发布期灰度、故障摘除、流量突增）。
- 长尾隔离：长上下文请求（>64K）建议独立实例池（max-model-len 大、并发低），避免与短请求互挤——短请求池 max-model-len 可收到 32K 提升 4 倍密度。
- 验证：按设计点 80% 负载持续 30 分钟，显存/延迟/错误率无漂移即通过（容量验收 = 性能测试的一种）。
4. 部署形态选择
| 形态 | 适用 | 测试关注 |
|---|---|---|
| 单机多卡 TP | 单实例需放下大模型（27B BF16 双卡 TP=2） | 卡间 NVLink/PCIe 带宽 → TPOT 通信开销；单卡故障=整实例挂（无冗余） |
| 多实例水平扩展 + LB | 吞吐扩展（生产推荐） | 实例间负载不均（KV 分布不均）、摘除后的流量再平衡时间、跨实例会话亲和 |
| 消费级卡集群（24G×N） | 预算受限/内网环境（无数据中心卡采购） | 无 ECC（长期运行位翻转→推理结果偶发异常，需周期健康检查）、无原生 FP8（选 INT4 路线）、显存碎片更敏感 |
| 推理云/托管 | 弹性峰值 | 冷启动（实例拉起 30s-数分钟）计入容量、网络 RTT 进 TTFT |
⚠️ 消费级卡的测试红线：长时间满载（≥2h 高温高载）跑稳定性专项，观察显存 ECC 错误计数（nvidia-smi -q -d ECC）、算力降频（时钟频率曲线）与输出异常率——数据中心卡的验收标准不能直接套用。