Back to blog
    企业 AI 容量规划:如何确定本地基础设施的规模
    capacity-planningon-premiseenterprise-aiai-infrastructuregpusegment:enterprise

    企业 AI 容量规划:如何确定本地基础设施的规模

    本地 AI 基础设施规模调整的分步技术指南。涵盖计算、存储、网络和电力需求,包含规模调整工作表和常见规划错误。

    EErtas Team·

    本地 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(无量化)INT8INT4 (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):

    1. 测量单实例吞吐量。 对于L40S上的14B INT4模型,预计每个 GPU 约70-110 tokens/秒。平均输出400个 token,大约每个 GPU 0.17-0.28请求/秒。

    2. 计算所需实例。 如果你的峰值 QPS 是15,每个 GPU 处理0.2请求/秒:15/0.2=75个 GPU?不——这个计算是针对顺序生成的。使用批处理推理(vLLM、TensorRT-LLM),单个 GPU 可以服务4-8个并发请求,每个请求的吞吐量下降最小。实际容量:14B模型每个 GPU 1-2请求/秒(有批处理)。

    3. 增加余量。 目标在峰值时 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
    向量数据库片段数 x 嵌入大小 x 3(开销)2M x 6KB x 3 = 36GB
    审计日志每日请求数 x 大小 x 保留天数50K x 3KB x 365天 = 55GB
    总计~1.9TB
    含50%余量~2.8TB

    使用 NVMe SSD 存储模型权重和活跃训练数据——机械硬盘跟不上 GPU 数据加载速度。典型配置是每台 GPU 服务器配2-4TB NVMe 存储,加上用于归档存储(旧检查点、历史审计日志)的更大 NAS 或 SAN。

    步骤4:网络需求

    网络规划取决于你是运行多节点训练还是仅推理工作负载。

    多节点训练

    如果你要跨多台服务器训练或微调模型(分布式训练),需要节点间的高速互连。训练期间的 GPU 通信是持续且对延迟敏感的。

    • **InfiniBand HDR (200 Gb/s) 或 NDR (400 Gb/s):**多节点 GPU 训练的标准。每台服务器需要一个 InfiniBand HCA,还需要 InfiniBand 交换机。成本:每台服务器 $5,000-$15,000 + 交换机 $10,000-$30,000。
    • **RoCE(RDMA over Converged Ethernet):**使用具有 RDMA 功能的标准以太网网卡的更便宜替代方案。对于大多数工作负载,性能是 InfiniBand 的80-90%。成本:使用现有网络交换机时每台服务器 $2,000-$5,000。

    仅推理

    如果你只运行推理(无分布式训练),标准网络就足够了:

    • **25 GbE:**对于大多数推理工作负载足够。处理模型加载和客户端请求/响应流量不会有瓶颈。
    • **100 GbE:**在频繁传输大数据集或使用大上下文窗口服务非常高 QPS 时有用。

    标准1 GbE 对模型加载太慢(通过1 GbE 加载28GB模型需要约4分钟——对于故障转移场景来说不可接受)。

    客户端带宽

    计算推理服务服务客户端所需的带宽:

    • 平均响应:400 tokens x ~4字节/token = 每次响应1.6KB
    • 在15 QPS 时:24KB/秒——可忽略不计
    • 但逐 token 流式响应增加了连接开销:如果服务实时聊天界面,计划100-500个并发 WebSocket 连接

    客户端带宽很少成为瓶颈,但连接数可能成为。确保你的推理服务器(或前端负载均衡器)配置了足够的并发连接。

    步骤5:电力和制冷

    这是在纸面上看起来很好的本地项目失败的步骤。

    电力需求

    配置GPU 功率系统总功率所需电路
    4x RTX 4090 工作站1,800W~2,500W1x 20A 208V
    8x L40S 服务器2,800W~4,000W1x 30A 208V
    8x A100 服务器3,200W~4,500W1x 30A 208V
    8x H100 服务器5,600W~8,000W2x 30A 208V 或 1x 60A

    购买硬件之前,请与设施团队确认:

    1. 可用电力容量在你的服务器机房/数据中心。许多企业服务器机房是为每机架2-5kW的 CPU 服务器设计的,而不是每机架8-15kW的 GPU 服务器。
    2. **电路可用性。**单台8xH100服务器可能需要自己的专用电路。
    3. **UPS 容量。**你的不间断电源必须能处理 GPU 负载加安全关机的运行时间。

    制冷需求

    GPU 产生的热量与其功耗成正比。每瓦 GPU 功率大约需要0.3-0.5瓦的制冷能量(取决于 PUE——电力使用效率)。

    配置热量输出制冷方法
    4x RTX 4090~2.5kW标准机房空调足够
    8x L40S~4kW建议使用列间制冷
    8x H100~8kW需要列间制冷或后门热交换器
    16x H100(2台服务器)~16kW可能需要液冷或专用制冷基础设施

    如果你的服务器机房制冷能力已满,添加 GPU 服务器可能需要 HVAC 升级,花费 $20,000-$100,000+。在决定购买硬件之前检查制冷容量。

    规模调整工作表

    将所有内容汇总到一个规模表中:

    工作负载模型量化QPSVRAM/实例所需 GPUGPU 类型存储
    客户聊天机器人14BINT41512 GB14L40S50GB 模型
    文档处理7BINT456 GB4L40S200GB 语料库
    Embedding 生成0.3BFP16502 GB2L40S共享
    重排序0.4BFP16502 GB2L40S共享
    每月微调14BFP16N/A80 GB(训练)4A100 或 L40S1.5TB 检查点
    总计26 GPU~2TB NVMe

    在此示例中,分布在3-4台服务器上的26个 L40S GPU 可以处理推理工作负载,微调工作负载可以在非高峰时段共享相同硬件或在专用4-GPU 服务器上运行。

    **总估计成本:**4台 8-GPU L40S 服务器 x $79,000 = $316,000,加上存储、网络和支持基础设施:总计约 $380,000-$420,000。

    常见容量规划错误

    错误1:在 L40S 就够用的情况下购买 H100

    H100 是目前最好的 GPU,但价格是 L40S 硬件的4倍。如果你的工作负载以推理为主,模型低于30B参数,L40S 以25%的成本提供80-90%的实际性能。H100 的优势——HBM3带宽、NVLink、MIG——在大模型训练和多租户推理中最重要。如果你不做这些,你就在为不会使用的能力付费。

    错误2:存储规模不足

    模型检查点是最常见的存储意外。单次微调运行可以生成200-500GB的检查点。预算2TB NVMe 以为"存储充足"的组织,在开始微调实验后几周内就会发现空间用完。预算比初始计算建议的多2-3倍的存储。

    错误3:忽视电力和制冷约束

    硬件到货、上架,然后跳闸。或者服务器机房温度在几小时内升至35°C。在购买硬件之前——而不是之后——始终与设施团队确认电力和制冷容量。

    错误4:未规划多模型服务

    大多数组织从一个模型开始,但很快扩展到服务不同用例的3-5个模型。如果你按单个模型的规模来规划基础设施,6个月内就会用完容量。至少规划初始模型数量的2-3倍。

    错误5:按平均值而非峰值规划

    一个平均5 QPS 但工作时间峰值20 QPS 的工作负载需要按20 QPS(带余量)来规划。按平均值规划意味着在使用量最重要的时段性能下降。

    错误6:忘记冗余

    如果你恰好有足够的 GPU 来服务工作负载,丢失一个 GPU 就意味着服务降级。对于可用性要求99.9%以上的工作负载,规划 N+1 冗余——至少每台服务器一个备用 GPU,或一台备用服务器在维护或故障期间可以承担负载。

    规划时间:18-24个月

    GPU 集群不是可以轻易扩展的。向现有服务器添加 GPU 可能不可行(取决于机箱),添加新服务器需要采购、上架、布线和配置,从决策到生产需要2-4个月。

    根据18-24个月的预计增长来确定初始部署规模。在第一年有20%的过剩容量比在第8个月面临容量紧缺同时等待硬件采购要好。

    但是,不要试图预测超过24个月的需求。AI 硬件格局变化迅速——两年后你会购买的 GPU 可能现在还不存在,而且工作负载模式会随着组织的 AI 使用成熟而变化。

    规划你能看到的。为你看不到的留出余量。

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading