AI云算力采购到GPU集群落地：规划、部署与利用率优化

AI 云公司的融资消息经常和 GPU 芯片采购绑定在一起。最近，AI 云服务商 Lambda 传出获得约 10 亿美元债务融资的消息，资金用途是采购更多 AI 芯片。从商业新闻视角看，这是资本层面扩充算力储备；从工程视角看，这相当于启动了一个周期以季度计算的硬件扩容项目。芯片到货只是第一步，真正的工作量在算力规划、集群部署、网络调优、调度平台、多租户隔离和成本回收上。

这篇内容不讨论融资结构和公司估值，而是以这则新闻为背景，拆解 AI 云服务商拿到钱买芯片之后，工程团队通常要经历哪些环节：为什么要做算力规划、GPU 怎么选型、集群落地要解决哪些问题、算力利用率如何度量和提升、面向客户的云服务怎么交付，以及上线后遇到问题从哪里排查。如果你正在搭建自己的 GPU 训练环境，或者参与 AI 云平台的建设，下面的思路可以复用。

1. 算力采购从来不是财务动作，而是基础设施工程的前置条件

很多人看到“采购芯片”时会默认这是一件花钱就能解决的事。实际上，AI 云公司采购芯片的逻辑和普通企业买服务器完全不同。它要采购的不是几台机器，而是一个能在未来若干个月内持续提供稳定算力的业务底座。芯片从下单到变成客户可用的 GPU 实例，中间要经过一整条工程链路。

1.1 训练和推理对算力的消耗逻辑不一样

先明确一个基础问题：AI 云上的算力到底被拿去做什么。绝大多数业务可以分成两类：模型训练和模型推理。

训练任务的特点是长时间运行、海量矩阵计算、多卡并行和数据频繁交换。训练大模型时，梯度同步和通信开销往往决定多卡扩展的最终效率。推理任务则完全不同，它追求的是低时延、高吞吐、高并发，需要处理动态请求，还要在显存中维护 KV cache 来加速解码。同一个 GPU 型号，在训练和推理场景中的表现可能差异很大。

如果只按“买更多卡”来规划，很容易出现一种情况：训练卡不够，推理卡又大量空闲，或者反过来。在实际工程里，采购之前必须先把负载类型拆分清楚。

1.2 交付周期决定了必须提前采购

AI 云业务里有一个经常被低估的因素：交付周期。高端 AI 芯片从下单、排产、发货到最终上架，整个周期通常按季度计算，而不是按天计算。这意味着如果业务预计六个月后需要 1000 张卡，那么现在就必须完成需求评估并下单。等业务排期确认后再采购，往往已经错过了可交付时间。

这也是 AI 云公司频繁融资买芯片的直接原因之一。先储备算力，再等客户任务进来，虽然短期会承担芯片空置的成本，但总比客户来了没有算力可用要好得多。从工程角度看，算力规划本质上是在“未来需求预测”和“当前库存成本”之间做平衡。

1.3 债务融资带来的利用率压力

债务融资和股权融资的区别在于，债务融资需要在未来按期偿还利息，这意味着资金是有使用成本的。如果芯片采购回来之后长期处于低利用率状态，每一分钟空转都会形成账面亏损。

所以工程团队必须把几个指标当成核心 KPI：

• GPU 平均利用率。
• 可交付算力占总物理算力的比例。
• 从下单到客户可用的交付周期。
• 单位 token 或单位卡时的成本。

有效算力不等于物理算力。可以用一个简单公式表示：

有效算力 = 物理算力 × 可用率 × 利用率

物理算力是买来的理论值，可用率取决于故障、维护、升级占用的时间，利用率取决于调度效率和业务负载是否填满。大多数 AI 云团队的改进空间都不在第一步，而在后面两步。

2. 买卡前先做算力规划：从业务需求推导 GPU 数量

“买多少卡”不是一个拍脑袋决定的问题。虽然最终数量会受到预算和供应周期影响，但工程上要先从业务需求推导出基准数量，再按余量系数调整。

2.1 先用推理场景估算 GPU 数量

推理场景的算力需求相对直观：每天的请求量乘上每个请求的平均输出 token 数，再除以每张卡每秒能处理的 token 数，就能得到一个粗略的 GPU 数量。关键是每张卡的吞吐不能凭感觉写，最好来自压测数据。

下面给出一个最小可运行的估算脚本，场景假设是一个在线服务每天处理 1000 万次请求，每次请求平均生成 800 个 token，单卡目标吞吐为 4000 token/s，预留 30% 余量：

# inference_capacity.py # 场景假设，实际参数按业务模型调整 total_requests_per_day = 10_000_000 # 每天请求数 avg_tokens_per_request = 800 # 每次请求平均输出 token 数 target_tps_per_gpu = 4000 # 单卡吞吐目标，来自压测 reserve_ratio = 0.3 # 预留 30% 余量 availability = 0.95 # 系统可用率 total_tokens_per_day = total_requests_per_day * avg_tokens_per_request effective_seconds = 24 * 3600 * availability required_tps = total_tokens_per_day / effective_seconds gpu_count_no_reserve = required_tps / target_tps_per_gpu gpu_count = gpu_count_no_reserve / (1 - reserve_ratio) print(f"每天总 token 数: {total_tokens_per_day / 1_000_000:.2f} 百万") print(f"每天有效运行秒数: {effective_seconds:.0f}") print(f"每秒需求吞吐量: {required_tps:.0f} token/s") print(f"GPU 数量（未预留）: {gpu_count_no_reserve:.1f}") print(f"GPU 数量（含预留）: {gpu_count:.1f}")

运行输出大致如下：

每天总 token 数: 8000.00 百万 每天有效运行秒数: 82080 每秒需求吞吐量: 97466 token/s GPU 数量（未预留）: 24.4 GPU 数量（含预留）: 34.8

如果单卡吞吐不是 4000 token/s，而是 10000 token/s，所需 GPU 数量会大幅下降。这说明在购买之前，先花时间做一次真实的模型压测是非常值得的。生产环境还需要考虑动态批处理、KV cache 优化、多副本切换等因素，上述数字只适合做数量级判断。

2.2 训练场景按模型规模和数据量估算

训练场景的估算链路更长。一个简化公式是：

GPU 卡时数 ≈ 数据总量（token）× 训练轮数 ÷（单卡吞吐 × 有效利用率）

例如有一份 100 亿 token 的数据集，需要训练 1 轮，单卡吞吐为 12000 token/s，有效利用率只有 0.4，那么需要的卡时数为：

total_tokens = 10_000_000_000 throughput_per_gpu = 12000 # token/s utilization = 0.4 seconds_per_gpu_hour = 3600 # 单卡每秒有效处理量 effective_throughput = throughput_per_gpu * utilization gpu_hours = total_tokens / (effective_throughput * seconds_per_gpu_hour) print(f"预估 GPU 卡时数: {gpu_hours:.0f}")

输出结果大约是 579 卡时。如果使用 16 卡并行训练，理想情况下需要约 36 小时。实际多卡训练还有通信开销、同步开销和故障重启开销，建议在结果上再乘以一个并行效率系数，例如 0.7 到 0.9。不同模型结构、序列长度、批量大小也会影响估算精度，这个公式只适合做早期的资源规划。

2.3 GPU 选型维度要对照业务场景

确定数量之后，下一个问题是选什么型号。GPU 选型不能只对比单卡价格，需要把几个核心维度放在一起看。

实际项目里，训练节点和推理节点往往需要不同配置。训练节点更看重多卡互联带宽，推理节点更看重显存容量和单卡吞吐。开发测试环境可以使用较低规格的卡，但要保证显存足够放下目标模型的最小版本，否则开发环境根本跑不起来。

这里要提醒一点：不要只按价格做选型。买卡时省下来的钱，很可能在电费、网络搭建和排障时间里加倍花出去。供应链紧张时还要确认交付周期，不能只看性能参数。

3. 芯片到货后的集群落地：网络、存储、调度、能源四条主线

芯片到货之后，集群不会自动工作。从一批 GPU 卡到稳定的算力服务，通常要解决网络、存储、调度和能源四类问题。

3.1 网络：多卡训练的可扩展性瓶颈

GPU 集群里最容易出问题的环节就是网络。多节点训练需要频繁做梯度同步，数据量极大。如果网络带宽不足或时延过高，就会出现“加更多的卡，训练反而变慢”的现象。

同一台服务器内的 GPU 可以通过 NVLink 等高速互联方式通信，跨服务器的通信则需要依赖 RDMA 网络。常用方案包括 InfiniBand 和 RoCE，RoCE 可以复用以太网基础设施，但需要做流控、无损网络配置，否则丢包会直接拖慢训练。

检查网络状态时，可以使用以下命令：

ibstat # 查看 InfiniBand 设备状态 ibstatus # 查看端口速率和链路状态 ethtool -S eth0 | grep rdma # 查看以太网 RDMA 计数

如果任务里配置了 RDMA 而实际物理机没有启用，训练进程会退回普通 TCP 通信，性能会明显下降。很多多机训练变慢的问题，最终都定位到网络协议栈配置不一致，而不是 GPU 本身。

3.2 存储：数据集、权重、日志的读写路径

存储是容易在设计阶段被忽略的问题。GPU 计算速度再快，如果训练数据从磁盘读到内存再传到显存的链路太慢，GPU 就会一直等待。

常见的缓解方式包括：

• 把热数据集放到本地 NVMe 磁盘，减少网络读取。
• 使用共享文件系统保存权重和日志，方便多节点读写。
• 对高频读取的小文件做多级缓存，避免每次重复访问对象存储。

一个参考目录结构如下：

/data/train # 训练数据集 /data/cache # 预取和缓存数据 /checkpoints # 模型权重保存 /logs # 训练日志

如果训练任务大量使用随机读取，建议评估是否需要更快的存储；如果只是顺序读取整个数据集，使用本地磁盘加简单的预取队列就能解决问题。

3.3 调度层：容器平台与批处理任务的分工

AI 云平台通常需要同时支持两类任务：面向在线服务的容器实例，以及面向离线训练的批处理任务。常用的组合是 Kubernetes 负责容器编排，Slurm 或 PBS 负责高性能批处理调度。

在 Kubernetes 场景中，要让调度器感知 GPU 资源，需要安装 NVIDIA Device Plugin。安装完成后，Pod 可以在资源限制中声明 GPU 数量，调度器才会把 Pod 绑到有空闲 GPU 的节点上。

apiVersion: apps/v1 kind: Deployment metadata: name: inference-server spec: replicas: 3 template: metadata: labels: app: inference-server spec: containers: - name: inference image: registry.example.com/llm-server:1.0.0 resources: limits: nvidia.com/gpu: "1" ports: - containerPort: 8000

需要注意，limits.nvidia.com/gpu的值必须为整数，Device Plugin 不支持分数 GPU。如果需要把一张卡切分给多个小任务使用，要通过 MIG 等底层能力配合额外配置完成，而不是直接在 limits 里写小数。

3.4 能源和散热：IT 之外还必须规划的物理条件

在实际机房建设中，导致 GPU 集群延期上线的常见原因不是网络配置，而是电力不够。一张高功率 GPU 的功耗动辄数百瓦，一台 8 卡 GPU 服务器整机功耗可能达到 4 千瓦以上。普通的 8 千瓦机柜只能放一两台，高密度部署时还要考虑液冷或增强散热方案。

所以在规划集群时，应该提前确认：

• 机柜功率上限是多少。
• 是否需要液冷机柜。
• 供电线路是否足够。
• 空调或冷却系统能否带走对应热量。

忽略能源约束的后果是：芯片到货后发现机房放不下，只能临时扩容电力，整个项目延期几个月。

4. 利用率是算力资产生命线：度量、瓶颈与优化

芯片采购完成、集群部署上线后，真正的运营工作才刚刚开始。对 AI 云公司来说，GPU 利用率直接决定成本回收速度。没有利用率指标的算力集群，等于在黑暗中经营。

4.1 先用指标说话：nvidia-smi 与 DCGM

查看单卡状态最常用的命令是nvidia-smi：

nvidia-smi # 按 CSV 格式输出指定指标 nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,power.draw --format=csv

nvidia-smi适合快速手动检查，但在长期监控场景中需要更系统的方案。DCGM 是 NVIDIA 提供的数据中心 GPU 管理工具，可以采集 GPU 利用率、显存使用、功耗、温度、NVLink 错误计数等指标，通常配合 Prometheus 作为监控数据源。

生产环境至少应该监控以下指标：

• GPU 利用率。
• 显存占用率。
• 功耗。
• 温度。
• NVLink 或 RDMA 的丢包和错误计数。
• GPU 各类异常事件。

4.2 利用率低的常见原因

利用率上不去，首先不要怀疑 GPU 质量问题，绝大多数情况是周边链路出了问题。下面列出几种常见现象和排查方向。

4.3 分时复用与多租户配额的平衡

算力资源买回来后，各个团队都想独占。如果所有资源都按客户最大需求分配，大部分时间都会空闲。实际运营中通常会分池管理：

分池的意义在于隔离故障和保障服务质量。训练任务可以容忍延时，但推理服务如果被抢占会直接影响在线业务，必须通过配额和优先级从调度层面强隔离。

4.4 成本核算：一张卡一个月的真实成本

算力成本核算不能只看采购价。一张 GPU 卡在一个月内的真实成本至少包括以下部分：

假设一张卡采购价 2 万美元，按 3 年折旧，月折旧约 556 美元；如果整机平均功耗 650 瓦，每度电 0.1 美元，一个月的电费约 47 美元；再叠加机柜和网络摊销，真实成本会明显高于单卡价格本身。这里不展开具体报价，因为实际数字会因为采购合同、机房位置和规模差异很大，但计算口径可以复用。

从经营视角看，如果 GPU 平均利用率从 40% 提升到 70%，单位算力成本可以下降三成以上。这意味着利用率优化不是工程人员自嗨，而是直接关系到财务表现的经营活动。

5. 把集群能力变成云服务：三种交付形态与多租户设计

采购芯片、部署集群、提升利用率，最终目的都是把算力变成可以售卖或使用的服务。不同客户对算力的需求差异很大，交付形态通常分为三类。

5.1 裸机租用：给客户整台服务器

一部分客户需要操作系统级别的完全控制权，比如自己搭分布式文件系统、自己调整内核参数。这种场景下，云平台把整台 GPU 服务器以裸机租用的方式交付给客户。

裸机交付的技术要点包括：

• 通过网络隔离保证多租户之间的网络互不可见。
• 预装一致的 GPU 驱动和固件，避免客户重复安装。
• 提供带外管理接口，方便重启和远程管理。
• 启动时做硬件自检，避免交付有故障的卡。

裸机模式实现简单，但资源颗粒度大，客户要租只能租一整台，适合大规模训练团队。

5.2 容器级调度：面向开发者和训练任务

容器级交付是目前最主流的形态。用户提交一个包含运行环境的容器镜像，平台根据 GPU 资源余量调度到对应节点。

Kubernetes 场景下，常见做法是：

• 通过 Device Plugin 暴露 GPU 资源。
• 通过ResourceQuota限制每个租户的 GPU 总量。
• 通过PriorityClass区分在线服务和离线任务。
• 通过容器镜像仓库管理运行环境。

这里要注意，GPU Pod 不能像普通 CPU 服务一样随意漂移。GPU 节点上的驱动版本、CUDA 版本、网卡固件必须保持一致，否则同一个镜像在不同节点上表现可能完全不同。

5.3 推理托管：把模型封装成 API

对于大多数应用方来说，最好的交付形态不是给一台服务器，而是给一个 API。推理托管平台的职责是把模型服务化，自动处理流量切换、副本扩容和故障恢复。

推理托管需要关注：

• 模型打包：把模型权重、依赖库和启动脚本打成镜像。
• 服务协议：统一使用 HTTP 或 gRPC 接口，方便接入网关。
• 自动扩容：根据 GPU 利用率和请求队列长度调节副本数。
• 限流：防止突发流量打垮后端。
• 版本回滚：新模型上线异常时能快速切回旧版本。

这种形态对平台工程要求最高，但客户接入成本最低。

5.4 多租户隔离和计量

无论哪种交付形态，多租户隔离和计量都不能事后补。如果设计阶段没有考虑，后期做计费系统会非常痛苦。

至少需要从三个层面设计：

• 调度隔离：不同租户的 GPU 任务不能互相抢占关键资源。
• 网络隔离：租户之间不能互相访问内部流量。
• 计量数据：按秒采集 GPU 占用时长、token 数量、流量等数据，作为计费依据。

计量数据的准确性直接关系到云厂商收入。建议从一开始就把指标采集和账单系统打通，不要在业务上线后再手写对账脚本。

6. 上线后的常见问题与排查链路

GPU 集群上线之后，一定会遇到问题。这里整理几条高频故障现象和对应的排查链路。

6.1 GPU 利用率上不去

现象是监控面板里 GPU 利用率长期低于预期。排查顺序应该是：

1. 确认任务真的使用了 GPU，运行nvidia-smi查看是否有 GPU 进程。
2. 检查数据加载是否成为瓶颈，查看存储 IO 是否长期处于高位。
3. 查看 CPU 使用率，如果 CPU 已经打满，优先优化数据预处理。
4. 查看训练日志中是否有等待同步或等待数据的记录。

最常见的原因是环境变量问题。比如CUDA_VISIBLE_DEVICES没有设置，程序跑在 CPU 上，GPU 自然没有负载。

6.2 多机训练掉卡或训练变慢

多机训练中最令人头疼的问题就是开始没问题，跑一段时间后某个节点掉卡，任务失败。处理步骤：

dmesg | grep -i nvrm # 查看 GPU 驱动相关的内核日志 nvidia-smi -a # 查看完整 GPU 状态 ibstat # 检查 InfiniBand 状态 erstat # 如果安装了相应工具，检查网络错误计数

常见原因包括驱动版本不一致、GPU 硬件故障、光模块或光纤链路异常。多节点环境下，建议所有节点的驱动、固件和库文件保持版本一致，避免“换一个节点就跑不起来”的问题。

6.3 推理时延波动

推理服务偶尔出现高延迟，但 CPU 和 GPU 利用率都不是特别高。这时优先检查：

• Pod 是否被重新调度到其他节点。
• 节点上是否还有其他高优先级任务抢占资源。
• 网关日志里是否有超时记录。
• 动态批处理参数是否变化。

推理服务必须预留资源并设置硬性 limits，不能和训练任务共享同一个资源池。否则训练任务一旦占满显存，推理服务就会频繁排队。

6.4 一张排查总表

7. 从采买到运营：可复用的工程清单与阶段建议

最后把前面所有内容压缩成可执行的清单。如果你正在参与 AI 云或 GPU 集群项目，可以按这个顺序推进。

7.1 采购到上线检查清单

7.2 学习环境与生产环境的差异

很多开发者在学习阶段用一台带单张显卡的机器跑通训练，就以为生产环境只是把机器数量放大。实际差异非常大。

不要把学习环境的经验直接放大到生产。单机跑通到多机训练之间，还隔着网络调优、数据并行、故障恢复和镜像管理一整条工程链。

7.3 个人和小团队自建 GPU 环境的起步建议

如果个人或小团队要自建 GPU 环境，建议从最小闭环开始：

1. 先准备 1 到 2 张 GPU 卡，跑通驱动、CUDA、容器运行时。
2. 用 Docker 封装训练和推理环境，避免重复安装依赖。
3. 跑一个小型模型训练任务，记录 GPU 利用率、显存、功耗和耗时。
4. 把部署过程写成文档，包括驱动版本、镜像地址和常用命令。
5. 计算真实的电费和折旧成本，确认成本能否接受。

不要第一轮就追求“生产级规模”，先让模型能在自己环境里端到端跑起来。

7.4 面向未来的扩展方向

如果一个 GPU 集群已经稳定运行，后续扩展方向包括：

• 多集群统一调度，把不同地域的算力纳管到同一平台。
• 异构芯片统一纳管，兼容训练、推理、数据预处理等不同硬件。
• 更细粒度的推理弹性伸缩，按请求量自动调整 GPU 副本数。
• 能耗和效率报告，让客户能清楚看到自己的算力使用情况和成本。

这些方向都以“算力可监控、可调度、可计量”为前提。集群管理稳定之后，再逐步推进。

回到开头那则新闻。债务融资带来的是资金，资金买来的是芯片，但芯片只有在变成高可用的算力资源之后，才有持续产生营收的能力。对工程团队来说，采购只是起点。算力规划、集群构建、调度交付、利用率优化、问题排查，每一个环节都决定这笔投资最终是被算力折旧碾掉，还是在客户侧变成稳定运行的服务。如果你是刚开始接触 GPU 集群的开发者，建议先拿一两张卡跑通完整链路：安装驱动、配置容器、训练小模型、记录指标。理解了这个链路之后，再去看“10 亿美元买芯片”的新闻，你会更关注算法之外的那一大部分工程量。