3、硬件选型与资源评估：如何根据模型规模选择GPU、CPU、内存与存储

大模型部署的硬件选型，本质上是一个“以模型为中心、以业务指标为边界”的约束求解过程。模型参数量、精度格式、序列长度、并发请求数、目标延迟与吞吐量，共同决定了GPU的显存容量、显存带宽、算力规模，以及CPU、内存和存储的配套规格。选型错误往往不是“性能不够”，而是“成本失控”或“资源错配”——例如为低并发离线任务购买了昂贵的高带宽GPU，或为高并发在线服务配置了显存足够但带宽不足的显卡。本章将建立一套从模型规模推导硬件规格的系统方法，并给出可落地的评估流程与实战案例。

3.1 核心原理：从模型参数到硬件规格的映射关系

大模型部署的硬件需求，首先取决于模型权重在显存中的驻留方式。以参数量为 P（单位：十亿，B）的模型为例，若采用 FP16 精度（每参数 2 字节），则模型权重本身需要 2P GB 显存。例如 7B 模型 FP16 权重约需 14GB，70B 模型则需约 140GB。若采用 INT8 量化（每参数 1 字节），权重占用减半；INT4 量化（每参数 0.5 字节）则进一步减至 1/4。但量化会带来精度损失，需结合任务验证。

除权重外，KV Cache 是推理过程中动态增长的显存消耗。对于自回归生成模型，每个请求的 KV Cache 大小约为：2 × 层数 × 头维度 × 序列长度 × 精度字节。以 7B 模型（32 层、40 头、头维度 128）为例，单请求生成 2048 token 时，FP16 下 KV Cache 约占用 2 × 32 × 40 × 128 × 2048 × 2 ≈ 1.34GB。并发 16 个请求时，仅 KV Cache 就需要约 21GB。因此，并发数越高、序列越长，KV Cache 的显存开销越大，这往往是显存规划中最容易被低估的部分。

显存带宽决定了模型权重的读取速度。推理时，每个 token 的生成都需要将全部模型权重从显存读取到计算单元。因此，理论最小延迟 ≈ 权重大小 ÷ 显存带宽。例如 A100 80GB 的显存带宽为 2TB/s，读取 14GB 权重约需 7ms；而 H100 的 3.35TB/s 带宽可将同样读取时间缩短至约 4.2ms。对于批量推理，带宽需求随并发数线性增长。

算力（FLOPS）则决定了矩阵乘法的执行速度。Transformer 推理的每次前向传播需要约 2 × P × N 次浮点运算（P 为参数量，N 为序列长度）。以 7B 模型生成 2048 token 为例，总计算量约为 2 × 7e9 × 2048 ≈ 2.87e13 FLOPs。A100 的 FP16 算力为 312 TFLOPS，理论计算时间约 0.09ms，远小于带宽瓶颈的 7ms。这说明单请求推理时，显存带宽是主要瓶颈；高并发时，算力才逐渐成为约束。

3.2 判断方法：五步完成硬件规格推导

以下流程将模型规模与业务指标转化为具体的硬件参数，适用于绝大多数大模型推理场景。

1. 确定模型精度与权重大小：明确部署精度（FP16/BF16/INT8/INT4），计算权重显存占用。若使用量化，需评估精度损失是否在业务容忍范围内。
2. 估算 KV Cache 与激活值：根据最大序列长度、并发数、模型层数等参数计算动态显存。激活值通常为权重的 10%-30%，取决于批大小。
3. 计算总显存需求：将权重、KV Cache、激活值相加，并乘以 1.2 的安全系数。选择显存容量大于该值的 GPU 型号。
4. 评估带宽与算力：根据目标 QPS 计算所需带宽（权重大小 × QPS）和算力（2 × P × 序列长度 × QPS）。对比候选 GPU 的规格参数。
5. 验证延迟与吞吐量：使用真实模型和压测工具（如 vLLM、TGI、TensorRT-LLM）进行基准测试，确认 P95 延迟和最大 QPS 是否达标。

3.3 案例拆解：70B 模型在线服务的硬件选型实战

某金融科技公司需要部署一个 70B 参数的对话模型，用于智能客服系统。业务要求：P95 延迟不超过 2 秒，峰值吞吐量 50 QPS，最大输入+输出序列长度为 2048 token。初始方案采用 4×A100 80GB 进行张量并行，但成本过高。我们重新进行资源评估。

第一步：显存计算。70B 模型 FP16 权重需 140GB。KV Cache 估算：假设模型为 80 层、64 头、头维度 128，单请求 KV Cache = 2 × 80 × 64 × 128 × 2048 × 2 ≈ 5.37GB。若并发 16 个请求，KV Cache 约 86GB。激活值按权重的 15% 估算约 21GB。总显存需求 = 140 + 86 + 21 = 247GB，乘以 1.2 安全系数后约 296GB。4×A100 80GB 总显存 320GB，勉强满足。

第二步：带宽验证。目标 50 QPS，权重 140GB，所需带宽 = 140GB × 50 = 7TB/s。单张 A100 带宽 2TB/s，4 卡并行时理论聚合带宽 8TB/s，但实际并行通信开销会降低效率。若改用 8×A100 80GB，聚合带宽 16TB/s，余量更充足。

第三步：算力验证。总计算量 = 2 × 70e9 × 2048 × 50 ≈ 1.43e16 FLOPs。4×A100 的 FP16 聚合算力为 1.25 PFLOPS，理论计算时间约 11.4ms，远小于延迟预算，算力不是瓶颈。

第四步：优化与调整。为降低成本，尝试 INT8 量化。权重降至 70GB，KV Cache 降至 43GB（INT8），总显存约 140GB，2×A100 80GB 即可满足。但量化后模型精度在金融术语理解上下降了 2.3%，经业务评估可接受。最终方案采用 2×A100 80GB + INT8 量化，硬件成本降低约 50%。

第五步：压测验证。使用 vLLM 部署，设置最大并发 32，压测结果显示 P95 延迟 1.6 秒，峰值吞吐 62 QPS，满足业务目标。同时观察到 GPU 显存利用率约 85%，带宽利用率约 78%，留有合理余量。

3.4 CPU、内存与存储的配套选型

GPU 是核心，但 CPU、内存和存储的配置同样影响整体性能。CPU 负责数据预处理、请求调度、Tokenization 和去词表等操作。对于 7B-13B 模型，16 核 CPU 足够；70B 模型建议 32 核以上，主频 3.0GHz 以上，并确保 PCIe 通道数满足多卡通信需求（如 4 卡需至少 64 条 PCIe 4.0 通道）。

内存容量需满足：模型权重（CPU 侧副本）+ 运行时数据 + 操作系统开销。通常为 GPU 显存的 1.5-2 倍。例如 2×A100 80GB 的配置，建议内存 256GB-512GB。内存频率建议 DDR5-4800 以上，双通道或四通道配置，以提升 CPU-GPU 数据搬运效率。

存储方面，模型加载速度直接影响冷启动时间。70B 模型 FP16 权重约 140GB，NVMe SSD 读取速度约 3.5GB/s，加载约需 40 秒；SATA SSD 约 500MB/s，需 280 秒。对于需要频繁重启或弹性伸缩的场景，必须使用 NVMe SSD。同时，检查点保存和日志写入也需要足够的 IOPS 和带宽。

3.5 延迟与吞吐量的评估方法

延迟与吞吐量是相互制约的指标。提高并发数（Batch Size）可以提升吞吐量，但会增加单请求延迟。评估时需明确：延迟目标通常以 P95 或 P99 为准，而非平均值，因为长尾延迟直接影响用户体验。

评估流程如下：

1. 单请求延迟基准：使用 1 个并发请求，测量首 token 延迟（TTFT）和每 token 生成延迟（TPOT）。TTFT 主要受权重读取时间影响，TPOT 受带宽和算力共同影响。
2. 并发扩展测试：逐步增加并发数（如 1、4、8、16、32），记录 P95 延迟和 QPS。绘制延迟-吞吐量曲线，找到拐点。
3. 资源利用率监控：使用 nvidia-smi、DCGM 等工具监控 GPU 利用率、显存占用、带宽利用率。若 GPU 利用率低于 70%，检查是否存在 CPU 瓶颈或通信瓶颈。
4. 调优迭代：根据压测结果调整批大小、精度、并行策略（张量并行/流水线并行）、KV Cache 复用策略等。

硬件选型不是一次性工作，而是需要随着模型迭代、业务增长和量化技术进步持续优化的过程。建议在部署初期预留 20%-30% 的显存和带宽余量，以应对模型微调、序列长度增加或并发峰值波动。同时，建立压测基线，每次变更硬件或模型后重新评估，确保资源投入与业务价值匹配。