
企业 AI 容量规划:如何确定本地基础设施的规模
本地 AI 基础设施规模调整的分步技术指南。涵盖计算、存储、网络和电力需求,包含规模调整工作表和常见规划错误。
本地 AI 中最昂贵的错误是 购买错误的硬件。规模过大意味着数十万美元的闲置计算资源。规模不足意味着性能瓶颈,从而破坏了本地部署的商业论证。与云端不同,你无法通过配置更改来调整 GPU 集群的大小——你需要等待8-16周的硬件交付周期。
本指南介绍了结构化的容量规划流程:盘点工作负载、计算资源需求、考虑存储和网络,以及规划增长。目标是提出具体的、有依据的硬件建议——而不是含糊的"买一些 GPU"。
步骤1:盘点你的 AI 工作负载
在选择任何硬件之前,建立将在本地基础设施上运行的每个 AI 工作负载的完整清单。这包括今天运行的工作负载(即使它们在云端)和未来18个月内计划的工作负载。
对于每个工作负载,记录:
| 字段 | 示例值 | 重要性 |
|---|---|---|
| 工作负载名称 | 客户支持聊天机器人 | 识别 |
| 类型 | 推理 | 决定 GPU 利用率模式 |
| 模型 | Llama 3.1 14B(Q4量化) | 决定 VRAM 和计算需求 |
| 每日请求数 | 50,000次查询 | 决定吞吐量需求 |
| 峰值 QPS | 每秒15次查询 | 决定并发 GPU 实例数 |
| 平均输入 Token 数 | 800 tokens | 影响延迟和吞吐量 |
| 平均输出 Token 数 | 400 tokens | 影响延迟和吞吐量 |
| 延迟要求 | 首个 token 少于3秒 | 决定所需 GPU 类别 |
| 数据敏感性 | 高(包含客户 PII) | 确认本地部署需求 |
| 可用性要求 | 99.9%(每年8.7小时停机) | 决定冗余需求 |
| 增长预测 | 12个月内翻倍 | 决定余量 |
将此清单构建为电子表格。它将成为所有后续规模决策的基础。
**常见遗漏:**组织盘点了主要工作负载,但忘记了支持性工作负载。基于 RAG 的聊天机器人不仅需要推理计算——还需要:
- 文档摄入的 Embedding 生成(运行在 GPU 上)
- 检索的重排序模型(运行在 GPU 上)
- 向量数据库(运行在 CPU 上,需要快速存储)
- 文档处理管道(混合 CPU/GPU)
每一项都消耗需要规划的资源。
步骤2:计算资源需求
VRAM 规模
VRAM(GPU 显存)通常是约束瓶颈。模型必须能装入 VRAM 才能运行——没有优雅降级,只有加载失败。
按规模和量化级别的模型 VRAM 需求:
| 模型大小 | FP16(无量化) | INT8 | INT4 (GPTQ/AWQ) |
|---|---|---|---|
| 7B 参数 | ~14 GB | ~7 GB | ~4 GB |
| 14B 参数 | ~28 GB | ~14 GB | ~8 GB |
| 32B 参数 | ~64 GB | ~32 GB | ~18 GB |
| 70B 参数 | ~140 GB | ~70 GB | ~35 GB |
这些数字仅代表模型权重。推理时,你还需要 VRAM 用于:
- **KV 缓存:**随上下文长度和批量大小扩展。对于一个14B模型,8K上下文、8个并发请求,需增加约4-8GB。
- **激活内存:**通常1-3GB,取决于批量大小。
- **框架开销:**PyTorch、vLLM 或 TensorRT-LLM 各自增加1-2GB的基础内存。
**经验法则:**在模型权重大小之外预留30-40%的 VRAM 余量。一个需要8GB权重存储的14B INT4模型应规划11-12GB的总 VRAM 使用量。
吞吐量规模
计算你需要多少 GPU 实例来满足目标每秒查询数(QPS):
-
测量单实例吞吐量。 对于L40S上的14B INT4模型,预计每个 GPU 约70-110 tokens/秒。平均输出400个 token,大约每个 GPU 0.17-0.28请求/秒。
-
计算所需实例。 如果你的峰值 QPS 是15,每个 GPU 处理0.2请求/秒:15/0.2=75个 GPU?不——这个计算是针对顺序生成的。使用批处理推理(vLLM、TensorRT-LLM),单个 GPU 可以服务4-8个并发请求,每个请求的吞吐量下降最小。实际容量:14B模型每个 GPU 1-2请求/秒(有批处理)。
-
增加余量。 目标在峰值时 GPU 利用率60-80%,而不是100%。在100%利用率下,任何流量峰值都会导致延迟恶化。对于上面的例子:15 QPS / 每GPU 1.5 QPS / 0.7利用率目标 = ~14个 GPU。
GPU 利用率目标
不要规划100%的 GPU 利用率。原因如下:
| 目标利用率 | 含义 |
|---|---|
| 90-100% | 无余量。任何峰值 = 延迟恶化或请求丢失。 |
| 70-80% | 健康的生产目标。能处理正常流量波动。 |
| 50-60% | 保守。适用于有严格 SLA 的关键工作负载。 |
| 低于50% | 可能过度配置。考虑更小的硬件或整合工作负载。 |
利用率还取决于工作负载模式。面向客户的聊天机器人有高峰时段(上午9点到下午5点),即使峰值达到70-80%,平均利用率也只有30-40%。全天候运行的内部文档处理管道可以持续维持70-80%。
步骤3:存储需求
GPU 计算得到了所有关注,但存储规划是容量规划中最常出错的地方。
存储类别
模型权重
每个模型版本需要存储。一个14B FP16模型约28GB。如果保留5个版本(当前版本+4个回滚版本),每个模型140GB。乘以你服务的模型数量。
训练数据集
如果你在本地微调,训练数据需要快速存储。大小差异很大:
- 文本微调数据集:典型1GB-50GB
- RAG 文档语料库:10GB-1TB+
- 图像/多模态数据集:100GB-10TB+
模型检查点
微调期间,检查点会定期保存。一个14B模型的完整检查点约28GB。如果在5,000步训练中每500步保存一次,那就是10个检查点 x 28GB = 每次训练运行280GB。如果不清理,检查点会快速累积。
向量数据库
RAG 工作负载需要向量存储。粗略估算:100万个文档片段,1,536维嵌入,大约需要6GB向量存储,加上可能翻倍或三倍于原始大小的元数据和索引。
审计日志和遥测
每个推理请求和响应都应该被记录以满足合规和监控需求。单个请求/响应对平均2-5KB。每天50,000个请求,大约100-250MB/天,或36-91GB/年。数量不大,但会累积,如果需要实时审计能力,必须放在快速、可靠的存储上。
存储规模工作表
| 存储类别 | 计算 | 示例 |
|---|---|---|
| 模型权重 | 模型数 x 版本数 x 大小 | 3模型 x 5版本 x 28GB = 420GB |
| 训练数据集 | 所有数据集之和 | 50GB + 200GB = 250GB |
| 检查点 | 每月运行数 x 检查点数 x 大小 | 4次运行 x 10 x 28GB = 1,120GB |