AI 云公司的融资消息经常和 GPU 芯片采购绑定在一起。最近AI 云服务商 Lambda 传出获得约 10 亿美元债务融资的消息资金用途是采购更多 AI 芯片。从商业新闻视角看这是资本层面扩充算力储备从工程视角看这相当于启动了一个周期以季度计算的硬件扩容项目。芯片到货只是第一步真正的工作量在算力规划、集群部署、网络调优、调度平台、多租户隔离和成本回收上。这篇内容不讨论融资结构和公司估值而是以这则新闻为背景拆解 AI 云服务商拿到钱买芯片之后工程团队通常要经历哪些环节为什么要做算力规划、GPU 怎么选型、集群落地要解决哪些问题、算力利用率如何度量和提升、面向客户的云服务怎么交付以及上线后遇到问题从哪里排查。如果你正在搭建自己的 GPU 训练环境或者参与 AI 云平台的建设下面的思路可以复用。1. 算力采购从来不是财务动作而是基础设施工程的前置条件很多人看到“采购芯片”时会默认这是一件花钱就能解决的事。实际上AI 云公司采购芯片的逻辑和普通企业买服务器完全不同。它要采购的不是几台机器而是一个能在未来若干个月内持续提供稳定算力的业务底座。芯片从下单到变成客户可用的 GPU 实例中间要经过一整条工程链路。1.1 训练和推理对算力的消耗逻辑不一样先明确一个基础问题AI 云上的算力到底被拿去做什么。绝大多数业务可以分成两类模型训练和模型推理。训练任务的特点是长时间运行、海量矩阵计算、多卡并行和数据频繁交换。训练大模型时梯度同步和通信开销往往决定多卡扩展的最终效率。推理任务则完全不同它追求的是低时延、高吞吐、高并发需要处理动态请求还要在显存中维护 KV cache 来加速解码。同一个 GPU 型号在训练和推理场景中的表现可能差异很大。场景关键指标算力瓶颈采购侧重大模型训练并发扩展能力、完成时间卡间通信、显存容量多卡互联带宽、高算力在线推理时延、吞吐、QPS单卡计算效率、显存带宽单卡吞吐量、显存容量开发调试交互速度、迭代效率显存容量、环境稳定性中等配置 GPU 即可数据处理IO、CPU、磁盘吞吐存储和网络不一定需要 GPU存储和 CPU 资源如果只按“买更多卡”来规划很容易出现一种情况训练卡不够推理卡又大量空闲或者反过来。在实际工程里采购之前必须先把负载类型拆分清楚。1.2 交付周期决定了必须提前采购AI 云业务里有一个经常被低估的因素交付周期。高端 AI 芯片从下单、排产、发货到最终上架整个周期通常按季度计算而不是按天计算。这意味着如果业务预计六个月后需要 1000 张卡那么现在就必须完成需求评估并下单。等业务排期确认后再采购往往已经错过了可交付时间。这也是 AI 云公司频繁融资买芯片的直接原因之一。先储备算力再等客户任务进来虽然短期会承担芯片空置的成本但总比客户来了没有算力可用要好得多。从工程角度看算力规划本质上是在“未来需求预测”和“当前库存成本”之间做平衡。1.3 债务融资带来的利用率压力债务融资和股权融资的区别在于债务融资需要在未来按期偿还利息这意味着资金是有使用成本的。如果芯片采购回来之后长期处于低利用率状态每一分钟空转都会形成账面亏损。所以工程团队必须把几个指标当成核心 KPIGPU 平均利用率。可交付算力占总物理算力的比例。从下单到客户可用的交付周期。单位 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(fGPU 数量未预留: {gpu_count_no_reserve:.1f}) print(fGPU 数量含预留: {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 选型不能只对比单卡价格需要把几个核心维度放在一起看。维度说明选择时要重点关注单卡算力FP16、BF16、FP8 等精度下的峰值算力大模型训练优先高算力显存容量决定能否放下模型、能否存放 KV cache推理优先显存训练看模型规模显存带宽影响数据在显存和计算单元间的搬运速度高吞吐推理必须关注卡间互联带宽多卡之间通信速度多机训练核心指标功耗与散热决定单个机柜能部署多少卡高密度部署时要提前确认机房电力软件生态驱动、框架兼容性、容器镜像成熟度直接影响排障成本实际项目里训练节点和推理节点往往需要不同配置。训练节点更看重多卡互联带宽推理节点更看重显存容量和单卡吞吐。开发测试环境可以使用较低规格的卡但要保证显存足够放下目标模型的最小版本否则开发环境根本跑不起来。这里要提醒一点不要只按价格做选型。买卡时省下来的钱很可能在电费、网络搭建和排障时间里加倍花出去。供应链紧张时还要确认交付周期不能只看性能参数。3. 芯片到货后的集群落地网络、存储、调度、能源四条主线芯片到货之后集群不会自动工作。从一批 GPU 卡到稳定的算力服务通常要解决网络、存储、调度和能源四类问题。3.1 网络多卡训练的可扩展性瓶颈GPU 集群里最容易出问题的环节就是网络。多节点训练需要频繁做梯度同步数据量极大。如果网络带宽不足或时延过高就会出现“加更多的卡训练反而变慢”的现象。同一台服务器内的 GPU 可以通过 NVLink 等高速互联方式通信跨服务器的通信则需要依赖 RDMA 网络。常用方案包括 InfiniBand 和 RoCERoCE 可以复用以太网基础设施但需要做流控、无损网络配置否则丢包会直接拖慢训练。检查网络状态时可以使用以下命令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-sminvidia-smi # 按 CSV 格式输出指定指标 nvidia-smi --query-gpuindex,name,utilization.gpu,memory.used,power.draw --formatcsvnvidia-smi适合快速手动检查但在长期监控场景中需要更系统的方案。DCGM 是 NVIDIA 提供的数据中心 GPU 管理工具可以采集 GPU 利用率、显存使用、功耗、温度、NVLink 错误计数等指标通常配合 Prometheus 作为监控数据源。生产环境至少应该监控以下指标GPU 利用率。显存占用率。功耗。温度。NVLink 或 RDMA 的丢包和错误计数。GPU 各类异常事件。4.2 利用率低的常见原因利用率上不去首先不要怀疑 GPU 质量问题绝大多数情况是周边链路出了问题。下面列出几种常见现象和排查方向。原因现象解决方向数据加载慢GPU 利用率周期性起伏脉冲明显数据预取、多线程读取、缓存CPU 预处理瓶颈任务运行但 GPU 只有间歇性忙碌增加 num_workers、使用数据预处理加速库多卡通信慢增加 GPU 后训练时间下降不明显检查网络和 RDMA 状态显存不足频繁显存拷贝或者 OOM降低 batch size、梯度累积、模型并行单卡计算不匹配GPU 忙但吞吐低优化算子、调整动态批处理策略4.3 分时复用与多租户配额的平衡算力资源买回来后各个团队都想独占。如果所有资源都按客户最大需求分配大部分时间都会空闲。实际运营中通常会分池管理资源池用途配额策略开发测试池调试代码、跑小数据量任务优先级低可被抢占训练池离线训练任务按队列调度限制并发推理池在线推断服务预留核心资源禁止抢占分池的意义在于隔离故障和保障服务质量。训练任务可以容忍延时但推理服务如果被抢占会直接影响在线业务必须通过配额和优先级从调度层面强隔离。4.4 成本核算一张卡一个月的真实成本算力成本核算不能只看采购价。一张 GPU 卡在一个月内的真实成本至少包括以下部分成本项目说明硬件折旧按采购价和折旧年限分摊电力成本按实际功耗和机房电费计算机柜租金按占用的 U 位或功率分摊网络成本交换机端口、带宽费用分摊运维人力和软件成本监控、排障、平台维护假设一张卡采购价 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 利用率长期低于预期。排查顺序应该是确认任务真的使用了 GPU运行nvidia-smi查看是否有 GPU 进程。检查数据加载是否成为瓶颈查看存储 IO 是否长期处于高位。查看 CPU 使用率如果 CPU 已经打满优先优化数据预处理。查看训练日志中是否有等待同步或等待数据的记录。最常见的原因是环境变量问题。比如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 一张排查总表问题现象优先检查关键命令或日志常见原因GPU 利用率为 0进程是否在 GPU 上运行nvidia-smiCUDA_VISIBLE_DEVICES 未设置程序跑在 CPU 上训练掉卡驱动版本和硬件状态dmesg、nvidia-smi -a驱动崩溃或 GPU 硬件故障多卡网络慢RDMA 连接状态ibstat、ethtool -S网络拥塞、驱动未启用 RDMA推理时延波动节点负载和调度记录kubectl describe pod资源竞争、Pod 被迁移任务持续 Pending资源和配额kubectl describe node集群无可用 GPU 或配额不足7. 从采买到运营可复用的工程清单与阶段建议最后把前面所有内容压缩成可执行的清单。如果你正在参与 AI 云或 GPU 集群项目可以按这个顺序推进。7.1 采购到上线检查清单阶段检查项交付物规划阶段明确业务负载类型、估算训练和推理算力、确认采购交付周期算力需求文档、预算模型到货阶段硬件验收、驱动安装、单卡功能测试、多卡压测硬件验收报告、性能基线部署阶段网络配置、存储挂载、调度平台搭建、监控告警接入集群环境文档、监控面板服务阶段租户配额、计费数据、SLO 定义、备份恢复预案用户服务协议、运维手册7.2 学习环境与生产环境的差异很多开发者在学习阶段用一台带单张显卡的机器跑通训练就以为生产环境只是把机器数量放大。实际差异非常大。维度学习环境生产环境规模1 到 2 张卡几十到上千张卡网络普通以太网InfiniBand、RoCE、无损网络调度手动启动任务K8s、Slurm 自动调度监控可选必须完整多租户不需要必须隔离故障处理重启即可需要自动恢复和冗余不要把学习环境的经验直接放大到生产。单机跑通到多机训练之间还隔着网络调优、数据并行、故障恢复和镜像管理一整条工程链。7.3 个人和小团队自建 GPU 环境的起步建议如果个人或小团队要自建 GPU 环境建议从最小闭环开始先准备 1 到 2 张 GPU 卡跑通驱动、CUDA、容器运行时。用 Docker 封装训练和推理环境避免重复安装依赖。跑一个小型模型训练任务记录 GPU 利用率、显存、功耗和耗时。把部署过程写成文档包括驱动版本、镜像地址和常用命令。计算真实的电费和折旧成本确认成本能否接受。不要第一轮就追求“生产级规模”先让模型能在自己环境里端到端跑起来。7.4 面向未来的扩展方向如果一个 GPU 集群已经稳定运行后续扩展方向包括多集群统一调度把不同地域的算力纳管到同一平台。异构芯片统一纳管兼容训练、推理、数据预处理等不同硬件。更细粒度的推理弹性伸缩按请求量自动调整 GPU 副本数。能耗和效率报告让客户能清楚看到自己的算力使用情况和成本。这些方向都以“算力可监控、可调度、可计量”为前提。集群管理稳定之后再逐步推进。回到开头那则新闻。债务融资带来的是资金资金买来的是芯片但芯片只有在变成高可用的算力资源之后才有持续产生营收的能力。对工程团队来说采购只是起点。算力规划、集群构建、调度交付、利用率优化、问题排查每一个环节都决定这笔投资最终是被算力折旧碾掉还是在客户侧变成稳定运行的服务。如果你是刚开始接触 GPU 集群的开发者建议先拿一两张卡跑通完整链路安装驱动、配置容器、训练小模型、记录指标。理解了这个链路之后再去看“10 亿美元买芯片”的新闻你会更关注算法之外的那一大部分工程量。
AI 云公司的融资消息经常和 GPU 芯片采购绑定在一起。最近AI 云服务商 Lambda 传出获得约 10 亿美元债务融资的消息资金用途是采购更多 AI 芯片。从商业新闻视角看这是资本层面扩充算力储备从工程视角看这相当于启动了一个周期以季度计算的硬件扩容项目。芯片到货只是第一步真正的工作量在算力规划、集群部署、网络调优、调度平台、多租户隔离和成本回收上。这篇内容不讨论融资结构和公司估值而是以这则新闻为背景拆解 AI 云服务商拿到钱买芯片之后工程团队通常要经历哪些环节为什么要做算力规划、GPU 怎么选型、集群落地要解决哪些问题、算力利用率如何度量和提升、面向客户的云服务怎么交付以及上线后遇到问题从哪里排查。如果你正在搭建自己的 GPU 训练环境或者参与 AI 云平台的建设下面的思路可以复用。1. 算力采购从来不是财务动作而是基础设施工程的前置条件很多人看到“采购芯片”时会默认这是一件花钱就能解决的事。实际上AI 云公司采购芯片的逻辑和普通企业买服务器完全不同。它要采购的不是几台机器而是一个能在未来若干个月内持续提供稳定算力的业务底座。芯片从下单到变成客户可用的 GPU 实例中间要经过一整条工程链路。1.1 训练和推理对算力的消耗逻辑不一样先明确一个基础问题AI 云上的算力到底被拿去做什么。绝大多数业务可以分成两类模型训练和模型推理。训练任务的特点是长时间运行、海量矩阵计算、多卡并行和数据频繁交换。训练大模型时梯度同步和通信开销往往决定多卡扩展的最终效率。推理任务则完全不同它追求的是低时延、高吞吐、高并发需要处理动态请求还要在显存中维护 KV cache 来加速解码。同一个 GPU 型号在训练和推理场景中的表现可能差异很大。场景关键指标算力瓶颈采购侧重大模型训练并发扩展能力、完成时间卡间通信、显存容量多卡互联带宽、高算力在线推理时延、吞吐、QPS单卡计算效率、显存带宽单卡吞吐量、显存容量开发调试交互速度、迭代效率显存容量、环境稳定性中等配置 GPU 即可数据处理IO、CPU、磁盘吞吐存储和网络不一定需要 GPU存储和 CPU 资源如果只按“买更多卡”来规划很容易出现一种情况训练卡不够推理卡又大量空闲或者反过来。在实际工程里采购之前必须先把负载类型拆分清楚。1.2 交付周期决定了必须提前采购AI 云业务里有一个经常被低估的因素交付周期。高端 AI 芯片从下单、排产、发货到最终上架整个周期通常按季度计算而不是按天计算。这意味着如果业务预计六个月后需要 1000 张卡那么现在就必须完成需求评估并下单。等业务排期确认后再采购往往已经错过了可交付时间。这也是 AI 云公司频繁融资买芯片的直接原因之一。先储备算力再等客户任务进来虽然短期会承担芯片空置的成本但总比客户来了没有算力可用要好得多。从工程角度看算力规划本质上是在“未来需求预测”和“当前库存成本”之间做平衡。1.3 债务融资带来的利用率压力债务融资和股权融资的区别在于债务融资需要在未来按期偿还利息这意味着资金是有使用成本的。如果芯片采购回来之后长期处于低利用率状态每一分钟空转都会形成账面亏损。所以工程团队必须把几个指标当成核心 KPIGPU 平均利用率。可交付算力占总物理算力的比例。从下单到客户可用的交付周期。单位 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(fGPU 数量未预留: {gpu_count_no_reserve:.1f}) print(fGPU 数量含预留: {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 选型不能只对比单卡价格需要把几个核心维度放在一起看。维度说明选择时要重点关注单卡算力FP16、BF16、FP8 等精度下的峰值算力大模型训练优先高算力显存容量决定能否放下模型、能否存放 KV cache推理优先显存训练看模型规模显存带宽影响数据在显存和计算单元间的搬运速度高吞吐推理必须关注卡间互联带宽多卡之间通信速度多机训练核心指标功耗与散热决定单个机柜能部署多少卡高密度部署时要提前确认机房电力软件生态驱动、框架兼容性、容器镜像成熟度直接影响排障成本实际项目里训练节点和推理节点往往需要不同配置。训练节点更看重多卡互联带宽推理节点更看重显存容量和单卡吞吐。开发测试环境可以使用较低规格的卡但要保证显存足够放下目标模型的最小版本否则开发环境根本跑不起来。这里要提醒一点不要只按价格做选型。买卡时省下来的钱很可能在电费、网络搭建和排障时间里加倍花出去。供应链紧张时还要确认交付周期不能只看性能参数。3. 芯片到货后的集群落地网络、存储、调度、能源四条主线芯片到货之后集群不会自动工作。从一批 GPU 卡到稳定的算力服务通常要解决网络、存储、调度和能源四类问题。3.1 网络多卡训练的可扩展性瓶颈GPU 集群里最容易出问题的环节就是网络。多节点训练需要频繁做梯度同步数据量极大。如果网络带宽不足或时延过高就会出现“加更多的卡训练反而变慢”的现象。同一台服务器内的 GPU 可以通过 NVLink 等高速互联方式通信跨服务器的通信则需要依赖 RDMA 网络。常用方案包括 InfiniBand 和 RoCERoCE 可以复用以太网基础设施但需要做流控、无损网络配置否则丢包会直接拖慢训练。检查网络状态时可以使用以下命令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-sminvidia-smi # 按 CSV 格式输出指定指标 nvidia-smi --query-gpuindex,name,utilization.gpu,memory.used,power.draw --formatcsvnvidia-smi适合快速手动检查但在长期监控场景中需要更系统的方案。DCGM 是 NVIDIA 提供的数据中心 GPU 管理工具可以采集 GPU 利用率、显存使用、功耗、温度、NVLink 错误计数等指标通常配合 Prometheus 作为监控数据源。生产环境至少应该监控以下指标GPU 利用率。显存占用率。功耗。温度。NVLink 或 RDMA 的丢包和错误计数。GPU 各类异常事件。4.2 利用率低的常见原因利用率上不去首先不要怀疑 GPU 质量问题绝大多数情况是周边链路出了问题。下面列出几种常见现象和排查方向。原因现象解决方向数据加载慢GPU 利用率周期性起伏脉冲明显数据预取、多线程读取、缓存CPU 预处理瓶颈任务运行但 GPU 只有间歇性忙碌增加 num_workers、使用数据预处理加速库多卡通信慢增加 GPU 后训练时间下降不明显检查网络和 RDMA 状态显存不足频繁显存拷贝或者 OOM降低 batch size、梯度累积、模型并行单卡计算不匹配GPU 忙但吞吐低优化算子、调整动态批处理策略4.3 分时复用与多租户配额的平衡算力资源买回来后各个团队都想独占。如果所有资源都按客户最大需求分配大部分时间都会空闲。实际运营中通常会分池管理资源池用途配额策略开发测试池调试代码、跑小数据量任务优先级低可被抢占训练池离线训练任务按队列调度限制并发推理池在线推断服务预留核心资源禁止抢占分池的意义在于隔离故障和保障服务质量。训练任务可以容忍延时但推理服务如果被抢占会直接影响在线业务必须通过配额和优先级从调度层面强隔离。4.4 成本核算一张卡一个月的真实成本算力成本核算不能只看采购价。一张 GPU 卡在一个月内的真实成本至少包括以下部分成本项目说明硬件折旧按采购价和折旧年限分摊电力成本按实际功耗和机房电费计算机柜租金按占用的 U 位或功率分摊网络成本交换机端口、带宽费用分摊运维人力和软件成本监控、排障、平台维护假设一张卡采购价 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 利用率长期低于预期。排查顺序应该是确认任务真的使用了 GPU运行nvidia-smi查看是否有 GPU 进程。检查数据加载是否成为瓶颈查看存储 IO 是否长期处于高位。查看 CPU 使用率如果 CPU 已经打满优先优化数据预处理。查看训练日志中是否有等待同步或等待数据的记录。最常见的原因是环境变量问题。比如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 一张排查总表问题现象优先检查关键命令或日志常见原因GPU 利用率为 0进程是否在 GPU 上运行nvidia-smiCUDA_VISIBLE_DEVICES 未设置程序跑在 CPU 上训练掉卡驱动版本和硬件状态dmesg、nvidia-smi -a驱动崩溃或 GPU 硬件故障多卡网络慢RDMA 连接状态ibstat、ethtool -S网络拥塞、驱动未启用 RDMA推理时延波动节点负载和调度记录kubectl describe pod资源竞争、Pod 被迁移任务持续 Pending资源和配额kubectl describe node集群无可用 GPU 或配额不足7. 从采买到运营可复用的工程清单与阶段建议最后把前面所有内容压缩成可执行的清单。如果你正在参与 AI 云或 GPU 集群项目可以按这个顺序推进。7.1 采购到上线检查清单阶段检查项交付物规划阶段明确业务负载类型、估算训练和推理算力、确认采购交付周期算力需求文档、预算模型到货阶段硬件验收、驱动安装、单卡功能测试、多卡压测硬件验收报告、性能基线部署阶段网络配置、存储挂载、调度平台搭建、监控告警接入集群环境文档、监控面板服务阶段租户配额、计费数据、SLO 定义、备份恢复预案用户服务协议、运维手册7.2 学习环境与生产环境的差异很多开发者在学习阶段用一台带单张显卡的机器跑通训练就以为生产环境只是把机器数量放大。实际差异非常大。维度学习环境生产环境规模1 到 2 张卡几十到上千张卡网络普通以太网InfiniBand、RoCE、无损网络调度手动启动任务K8s、Slurm 自动调度监控可选必须完整多租户不需要必须隔离故障处理重启即可需要自动恢复和冗余不要把学习环境的经验直接放大到生产。单机跑通到多机训练之间还隔着网络调优、数据并行、故障恢复和镜像管理一整条工程链。7.3 个人和小团队自建 GPU 环境的起步建议如果个人或小团队要自建 GPU 环境建议从最小闭环开始先准备 1 到 2 张 GPU 卡跑通驱动、CUDA、容器运行时。用 Docker 封装训练和推理环境避免重复安装依赖。跑一个小型模型训练任务记录 GPU 利用率、显存、功耗和耗时。把部署过程写成文档包括驱动版本、镜像地址和常用命令。计算真实的电费和折旧成本确认成本能否接受。不要第一轮就追求“生产级规模”先让模型能在自己环境里端到端跑起来。7.4 面向未来的扩展方向如果一个 GPU 集群已经稳定运行后续扩展方向包括多集群统一调度把不同地域的算力纳管到同一平台。异构芯片统一纳管兼容训练、推理、数据预处理等不同硬件。更细粒度的推理弹性伸缩按请求量自动调整 GPU 副本数。能耗和效率报告让客户能清楚看到自己的算力使用情况和成本。这些方向都以“算力可监控、可调度、可计量”为前提。集群管理稳定之后再逐步推进。回到开头那则新闻。债务融资带来的是资金资金买来的是芯片但芯片只有在变成高可用的算力资源之后才有持续产生营收的能力。对工程团队来说采购只是起点。算力规划、集群构建、调度交付、利用率优化、问题排查每一个环节都决定这笔投资最终是被算力折旧碾掉还是在客户侧变成稳定运行的服务。如果你是刚开始接触 GPU 集群的开发者建议先拿一两张卡跑通完整链路安装驱动、配置容器、训练小模型、记录指标。理解了这个链路之后再去看“10 亿美元买芯片”的新闻你会更关注算法之外的那一大部分工程量。
