1. 先说结论GPU 云平台不等于“只选一家”也不等于“每家都买一堆”这几年凡是把 AI 训练、大模型推理、图形渲染真正跑上生产环境的团队基本都经历过同一个场景单一 GPU 云平台在算力紧张的时候大幅度限制你下单你说加 100 张卡售前告诉你“当前可用资源不足需要排队”然后就再也没有下文。所以说GPU 云平台这件事“只选一家”听起来省心实际上是把命脉交给了对方。但这句话绝对不等于让你盲目上四五家平台每家用一点最后账单、网络、权限、镜像、数据管理全乱套。我见过最夸张的团队同时开了六家云账号训练任务散得到处都是明明同一条数据的副本就要同步六份日志在六个控制台里查故障定位一次半天起步。这种“多云”不是策略是灾难。真正可落地的做法是把 GPU 云平台拆成三种角色来规划主平台、弹性池、容灾池。主平台负责日常稳定算力弹性池负责突发需求容灾池负责万一主平台出大事之后的兜底。三者各司其职既不用把“鸡蛋放一个篮子”又不会把“篮子”多到拎不过来。这篇文章我会把三种角色是什么、怎么选、怎么配、怎么用以及我在实际落地中踩过的坑一次性讲清楚。如果你正好在为公司做 GPU 算力规划或者已经买了机器但觉得成本、稳定性、扩容体验都不太对劲这篇文章应该能帮你少走不少弯路。1.1 为什么 GPU 云比传统云更逼迫企业做多平台规划很多人不理解为什么以前做普通 Web 服务双云部署都算奢侈到了 GPU 业务反而必须提前想“多家备选”。这里面的核心原因是GPU 资源在云平台上属于高度紧缺型资源。传统 CPU 云服务器你随便开几十台都不是问题厂商的库存通常能覆盖。但 GPU 不一样A100、H100、L40S 这类热门型号几乎每一家平台都是周期性地缺货。高峰期你点“创建实例”界面直接灰掉或者提示资源不足这是非常普遍的情况。更麻烦的是即使显示“有货”也可能给不了你足够的配额。比如默认配额只允许你同时持有 4 张卡你想跑一个需要 8 卡的任务第一件事不是考虑价格而是先提工单申请配额这个过程通常要一两天。还有一个容易被忽略的因素GPU 云平台的维护窗口和故障影响范围。训练任务动辄跑几天甚至几周如果平台在半夜做了一次网络变更或者存储热迁移出了问题整个训练集群可能直接中断。这种中断靠你本地的重试脚本是解决不了的。我经历过一次某平台控制台自身故障所有实例无法操作API 也不稳定整整四五个小时只能干等。从那次之后我彻底明白了为什么 GPU 算力一定要注意兜底方案。更现实的一点是价格。GPU 云平台的计费策略和市场供需关系强相关。有些平台为了借“稀缺”来回收成本高峰期涨价、低峰期狂发折扣券波动很大。如果你把所有算力都绑在一家遇到对方调价、改计费规则、取消某种实例规格你几乎没有议价和腾挪的空间。而有三层角色之后至少弹性部分和容灾部分可以把这部分压力释放掉。1.2 主平台、弹性池、容灾池各自的角色定位先给一个最直白的类比。主平台是你自己买下的房子弹性池是你在外面签好的酒店协议容灾池是藏在后备箱里的帐篷。平时你住房子出差住协议酒店真发生地震回不了家你起码还能搭帐篷应急过渡。换成技术语言来说主平台承载企业大部分 GPU 工作负载的常驻平台通常是买包年包月/专用实例或者和厂商签了 Minium 用量承诺。它的核心指标是稳定、可控、服务响应快。弹性池在算力需求出现短期峰值时临时从其他平台租用 GPU 资源。用完就释放核心指标是启动速度快、供给充足、按量计费价格合理。容灾池保证主平台不可用时关键业务能以一个最小的规模继续跑起来。它平时可能只保留极少量的“保底实例”或者完全不保有实例但镜像、数据、权限体系都已经做好随时拉起全套环境的准备。这三个角色不是三套完全割裂的集群而是可以共用一个调度入口的“算力后端”。后面我会详细讲到如何用 Kubernetes 这类调度平台把三层资源统一纳管。总的原则是区分角色是为了让采购、架构、SRE 团队都清楚每一份算力花在了什么目的上而不是简单粗暴地开一堆账号。2. 主平台选型先把“长期住”的地方定明白主平台是整个 GPU 资源体系里最重要的一层因为它承载的是“天天要跑的日常任务”。选主平台时大家最容易犯的错误是把全部注意力放在 GPU 型号和跑分对比上而忽略了其他更致命的问题。举个例子。两家平台都有 H800单卡规格也都一样但第一家的实例网络默认是普通 10G第二家支持 RDMA 和超高速互联。你买个 8 卡实例带宽差距会导致多卡训练通信效率天差地别同样的模型在一家平台能跑 90% 的 GPU 利用率在另一家可能只有 50%。这不是 GPU 本身的问题而是平台网络结构的问题。2.1 主平台选型时要重点看的四张“底牌”第一张底牌是配额和供给能力。不要只信售前口头承诺把“能开多少张卡”写进合同或者至少留个书面确认。我遇到过实际案例销售说“你要 64 张我们肯定能满足”结果项目上线两周后对方运维说“机房扩容延迟只能先给 32 张”。没有书面凭证这种问题理都没处理。第二张底牌是实例间的互联架构。单机多卡优先看 NVLink 和 NVSwitch 是否完整多机分布式训练则要看节点间网络是不是 RDMA有没有单独的集群网络隔离。很多平台所谓的“高带宽”只是单机带宽跨机通信烂得一塌糊涂。第三张底牌是存储配套。GPU 算力跑起来之后数据读取就是最大的瓶颈之一。你得确认平台提供的共享文件存储是不是高性能并行文件系统容量能不能弹性扩展IOPS 能不能跟上。如果存储是普通的网络盘你就算拿到最顶级的 GPU训练时数据加载也会让你卡到怀疑人生。第四张底牌是服务与故障响应能力。GPU 服务出问题时你没有时间等 24 小时工单。尽量选择有大客户支撑团队、有电话或在线急响应的平台。我在选型时一般会故意在下班时间提一个高优先级工单看对方多久有人回应这比看任何广告都真实。2.2 计费模型与用量承诺的博弈主平台的采购常见三种方式按需、包年包月、专属物理机。按需最大的优势是灵活但单价最贵适合不确定用量的短期项目。包年包月是主平台最常见的形态价格便宜一般能比按需便宜 20%-50%适合长期稳定运行的生产集群。专属物理机则是直接独占一台服务器性能和隔离性最好适合对数据安全、驱动版本、内核参数有强要求的团队但成本和运维压力也最大。这里我建议一个基线思路日常稳定负载的 70% 放在包年包月实例上预留 20% 的余量应对小波动剩下 10% 留给弹性池去抢。不要贪便宜把 100% 的负载全部包年因为你一定会遇到业务收敛、模型重构、平台调度停摆的情况包年太多到后来就是浪费。另外要特别注意账单治理。企业用 GPU 平台经常出现“技术团队随手开卡月底财务一看账单翻倍”。主平台上一定要做好配额、标签、项目级别的预算控制让每一张卡都归属到具体的部门和业务线。这也是为什么我强调主平台要稳定统一因为只有算力入口收敛成本核算才能收敛。3. 弹性池设计高峰来了能借高峰走了能还弹性池的定位是“承接突发”它的设计思路和主平台截然不同。主平台追求“长期住得舒服”弹性池追求“短租随叫随到”。这部分的挑战不是“有没有 GPU”而是“你怎么让业务能随时随地利用一个临时出现的大规模算力”。3.1 弹性池的核心前提应用必须无状态化我先说一个我踩了很久的坑。早期我们做弹性扩容其实是把训练镜像直接搬过去以为只要平台有卡就行。结果发现任务跑起来之后频繁失败查了半天原因是应用内部把中间结果写在本地磁盘实例一释放数据就没了。弹性池的算力是“借来的”随时可能被回收所以你的训练和推理任务必须满足一个硬条件所有业务状态都在外部比如对象存储、分布式文件系统、数据库里。本地磁盘只允许放临时缓存绝不能放唯一副本。具体来说训练任务要做 checkpoint。每个 epoch 或者固定步数把模型权重、优化器状态保存到外部存储。推理服务要做到无状态实例前端可以随时杀掉一个 pod新的 pod 从镜像拉起之后直接从共享存储加载模型并正常服务。如果你现在的工作负载做不到这两点先用内部项目改造一轮再考虑上弹性池不然投入产出比很难看。3.2 弹性池的“双通道”扩容方式弹性池的扩容路径一般分两种。第一种是主平台内部的弹性扩容。比如你在主平台上已经买了 100 卡包年资源高峰期发现不够立刻在同一个平台再开 50 张按量卡。这种方式的好处是网络、存储、账号体系完全复用了主平台扩容过程成本低、速度快。缺点是如果主平台本身资源也紧张按量卡同样可能开不出来。第二种是跨平台弹性调度。主平台资源不够时把一部分任务调度到另外一家 GPU 云平台。这种方式是容灾池的日常版能真正解决“主平台没货”的死局但复杂度上升需要处理跨平台网络打通、镜像仓库同步、数据同步、统一调度、多云成本核算等问题。在工程上我倾向于把第一通道作为默认第二通道作为兜底。平时弹性需求不大的团队先做好主平台内弹性足够了。只有经历过“主平台自身资源告罄”的团队才值得为跨平台弹性投入额外成本。3.3 弹性池要不要用“竞价实例”很多 GPU 云平台会提供价格更低的竞价型/抢占型实例像某些平台的“闲置实例”或“竞价实例”价格可能只有按量的 3-5 折但平台有权利在资源紧张时随时回收。这种实例非常适合弹性池的某些场景但一定要分清任务类型。我总结的经验是可以跑短时推理波峰、数据处理、超参数搜索、批量渲染、可容错的重试型任务以及 checkpoiont 完善的低优先级训练。不能跑关键生产推理、主链路的长期训练。除非你把容错机制设计得极其完善比如每 5 分钟自动 checkpoint断点自动恢复否则千万别让核心任务跑在随时可能被回收的实例上。另外很多团队一开始觉得“便宜就是好”但忽略了一个隐形成本竞价实例的调度不稳定任务频繁中断会浪费数据加载和初始化时间。如果你每个任务 init 要花 20 分钟任务本身只要跑 30 分钟那用竞价实例简直是灾难。务必按“有效 GPU 时长”来计算成本而不是看标注的每小时价格。3.4 弹性池的成本归属与回收纪律弹性池最容易失控的是成本。按量实例开起来毫无感觉跑一个晚上可能就烧掉几万块。我的习惯是给弹性池单独建一个账号或者单独的主机标签所有弹性资源必须打上用户、项目、目的三类标签。每天手动或通过脚本拉取账单超过设定预算后非核心任务自动暂停。回收纪律更重要。弹性池的关键词是“用完即撤”。很多团队开了一堆弹性实例任务跑完了没人释放白白烧钱。我建议为弹性池里的每个任务模块都加上自动释放逻辑比如训练脚本跑完自动调用 API 删除实例。宁可后续再重新启动也不要养着“僵尸 GPU”。4. 容灾池不是“冷备份”是一片真正能接管的土地容灾池是企业最容易忽略的一层。很多团队觉得“厂商承诺高可用不就行了干嘛还自己准备一套”。但 GPU 云平台的故障有时不是你能靠 SLA 解决的。厂商的高可用一般是指“服务配置级别的高可用”不是“你无限制调度的免死金牌”。平台层面如果出了大规模故障你只需要知道一件事你自己准备的那套容灾方案才是真正靠得住的。4.1 先定义容灾目标你是要“保住账”还是“保住体验”在搭容灾池之前必须和业务对清楚一个指标不同业务的恢复时间目标RTO和恢复点目标RPO是多少。比如对于 AI 训练任务最理想的是故障发生后 1 小时内能在容灾池重新拉起训练RPO 控制在最近一次 checkpoint 的位置损失不超过几十分钟算力。对于在线推理服务则要求 RTO 尽量在 5-10 分钟内因为推理挂了直接影响线上产品。对于数据处理任务可能 4 小时恢复也能接受。容灾池的规模完全可以按照“保底运行”来设计不需要做到和主平台同等规模。比如主平台有 128 卡日常负载容灾池只需要保证 32 卡先把最重要的模型和核心服务跑起来。这样容灾成本才不会变成第二个主平台。4.2 容灾池的数据和镜像同步才是真正的重活容灾池能不能快速接管通常不取决于你有没有账号而取决于镜像和数据是不是已经提前在容灾侧备好。镜像层面把常用的训练镜像、推理镜像、数据处理镜像全部推送到容灾平台的镜像仓库里。这个动作一定要自动化每次主平台的镜像有更新就触发一次跨平台同步。如果容灾平台用的是同一套基础设施可能支持跨区域复制如果完全跨厂商那就用符合 OCI 标准的工具做镜像迁移。总之别等到故障发生的那一刻再现场 push 镜像那个速度大概率让你怀疑人生。数据层面的同步策略我一般分三层第一层模型文件和长期数据集用低频增量同步每天或者数小时同步一次。第二层频繁更新的训练数据和 checkpoint用对象存储跨区域复制至少做到分钟级延迟。第三层数据库和元数据需要做主从复制或者定期选主确保一致性。容灾侧不要只存“全部数据的最新快照”还要保存最近几个时间点的版本防止主平台的数据因为误删、损坏而污染容灾池。我见过一个事故主平台存储上某个数据集目录被脚本误删了之后自动同步机制触发容灾池里的“唯一干净副本”也被覆盖了。从那以后我把同步机制全部加上了“只新增不删除”的软删除保护容灾副本至少保留 3 个历史版本。4.3 容灾演练不能停留在文档里很多团队做了容灾池但一年也不演练一次真到了用的时候才发现容灾平台没配额、DNS 解析没切过来、密钥没同步、模型文件同步失败、某平台账号欠费被冻结。这种“纸上容灾”还不如不做它只会给你一个虚假的安全感。我的建议是每季度至少做一次“最小规模接管演练”。具体做法是把核心推理服务和一个小型训练任务在容灾平台上完整跑通一次记录从“宣布故障”到“业务恢复”的总时长。第一次演练大部分团队都会发现一大堆问题。比如跨平台网络打通后路由不生效、容灾平台的 Kubernetes 版本差了太多导致编排文件不兼容、GPU 驱动版本不一致导致算子验证失败。这些东西只有真正跑过才能发现。演练还有个附带价值让容灾池的资源也经常“晒晒太阳”避免闲置实例因为平台升级、网络策略变更逐渐失联。容灾池既不能完全不保有实例也不能只在灾难时才想起来去用。我建议让一小部分非核心但真实的任务常驻容灾平台运行既能实现业务混跑又能持续验证整条链路。5. 把三层算力纳入同一个调度入口Kubernetes 和它周围的事主平台、弹性池、容灾池如果各自为政那只是“三个割裂的云账号”谈不上策略。真正有价值的状态是业务研发层只面对一个调度入口底层有三层资源在背后支撑。这里最容易落地的方案是 Kubernetes。很多团队已经在主平台跑了 K8s 集群那就可以把弹性池和容灾池的节点用“混合节点池”的方式纳管进来或者用 Kubernetes 联邦/多集群管理器做统一调度。5.1 单集群多节点池 vs 多集群联邦先说单集群多节点池。如果你的主平台和弹性池网络二层可达、或者通过内网打通可以在同一个 K8s 集群里定义多个节点池主节点池对应包年实例弹性节点池对应按量实例容灾节点池对应保底实例。然后给不同工作负载配置 nodeSelector 和资源配额就能实现基础的能力区分。这种方式的好处是架构简单workload 不用改K8s 原生调度器直接搞定。缺点是本地依赖比较强一旦主集群的 K8s 控制面挂掉整个调度也会瘫痪。所以单集群方案只适合弹性池容灾池建议独立集群。多集群联邦则是指两个或多个 K8s 集群协同工作通常是由上层的调度平台控制。常见的做法主平台一套集群容灾平台一套集群上层通过调度组件把工作负载分发到两个集群里同时维护统一的配置和应用发布。容灾池平时可以只跑极小规模的“哨兵任务”一旦主集群失联调度平台立刻把状态切到容灾集群。对于大多数企业我的建议是弹性池走单集群扩展容灾池走独立集群。不要一上来就搞多集群联邦那是大厂和平台型团队玩的普通团队很难驾驭配置和故障域。5.2 业务调度层面要做的几个必选动作无论你选哪种架构有三件事是必须做的。第一给工作负载打优先级。把任务分成 critical核心在线推理、normal常规训练、batch可容忍延迟的批处理三级。容灾状态下调度器优先保证 critical 级工作负载拿到算力normal 级等待batch 级直接暂停。第二设置好资源配额和限制。如果你不设 limit容器内的进程会把一张卡的多卡显存直接占满调度器也会因为资源竞争频繁驱逐任务。K8s 上建议使用 extended resource 来管理 GPU 卡数并且结合 device plugin 判断显存使用配好 limit 比依赖本地的监控告警重要得多。第三监控、日志、告警全链路打通。跨平台之后最怕的就是“日志散落一地”。无论你在主平台、弹性池还是容灾池所有任务日志都要统一汇聚到一个日志平台所有指标都要有统一的 Prometheus/Grafana。否则一旦故障切换你连“到底跑没跑起来”都不知道。5.3 网络打通最容易被低估的环节跨平台联调的时候网络问题占所有故障的一半以上。如果你是同一家云平台的多个区域那相对好办一般有内网互通能力。但如果是不同云平台之间打通网络常见方案是建立对等连接或使用带加密通道的网络隧道网关。这里我不展开讲某家具体产品只提醒几个要点安全组和防火墙规则必须双向放通尤其是 Kubernetes 的 API Server 端口、节点间通信端口。网络要求低时延跨地域通信一定会有较高延迟不适合多机做分布式训练。同一区域的多个云平台打通延迟相对可控。域名解析要考虑故障切换。容灾场景下你不可能让客户端手动改 IP。务必提前做好全局负载均衡或者 DNS 切换策略并且搞清 TTL 能设多短。6. 常见问题与排查技巧实录讲了这么多理论这里分享一些我在真实落地上踩过或看别人踩过的坑。都是很细节、很烦人的问题但解决之后整个体系会顺滑一大截。6.1 典型问题速查表症状可能原因快速排查和处理方式容灾池拉起实例后应用启动报找不到 GPU镜像里的驱动和容器运行时与该平台 GPU 型号不匹配用官方基础镜像重新 build 一次或使用带全驱动的地图镜像不要拿主平台的“热镜像”直接跨平台用弹性任务经常被杀日志显示“阻断”部分平台对按量实例有使用时长或资源竞争限制确认平台对实例类型的回收策略加上自动 checkpoint 与失败重试机制避免单点失效跨平台数据同步不完整日志只有主副本对象存储事件触发器没配置好或同步脚本使用了增量时间点滚动错误检查每个 Bucket 的事件通知用“本地文件校验 对比清单”做每日对账容灾池 K8s 集群起不来容灾平台的 CNI 网络插件或安全组未放通必要端口先跑通单节点测试集群确认 CNI、kubelet、API Server 的端口全部可达多卡训练在弹性池效率很低实例间 RDMA/高速网络不可用检查实例类型是否支持 RDMA如不支持用纯数据并行并开启梯度压缩也能缓解一部分账单超支不清楚哪些资源在跑弹性池和容灾池没有做标签隔离和预算告警给每个云账号按项目打标签设置预算阈值超过 80% 自动通知超过 100% 任务自动暂停6.2 几个我亲测有效的细节镜像仓库一定要有访问凭证的版本管理。跨平台环境里很多小团队直接用一个长期 token 拉取镜像密钥一旦泄露所有平台的镜像都被拉走。我建议为每个平台单独设置访问凭证并且 90 天轮换一次。所有平台的账号密码、AccessKey、证书等必须放到统一的密钥管理系统里严禁在配置文件里写明文。这个道理大家都懂但我在帮别人做容灾评审时至少三次看到有人的配置仓库里直接写着云平台密钥真的替他们捏把汗。另一个细节是 GPU 云平台的实例名称和标签规范。跨平台后如果实例名是“k8s-xhdj2-abc”这种随机串故障定位会非常痛苦。建议统一命名规范比如“env-prod-project-task-node-AZ”至少保证从名字能看出属于哪个池、哪个项目。6.3 容灾演练时的常见障碍容灾演练时最大的一个障碍是“主平台意外恢复”。很多团队模拟故障时本来只想切一部分流量结果主平台某台旧实例还在提供服务两个平台同时写数据库数据一致性直接出问题。所以在演练前一定要强制关闭主平台的业务入口比如先摘掉负载均衡流量再停 K8s 工作负载确认全部停完后才在容灾池拉起副本。还有一个障碍是冷启动时间。容灾池如果平时不保有任何实例临时创建 32 卡集群可能要等平台调度 30 分钟以上。如果你的 RTO 要求低于这个时长就必须长期保有至少一个最小规模的备用集群哪怕成本高一点也值。容灾这件事预算和时间目标永远是在打架的决策层提前要把这个预期明确下来。7. 最后分享几条实际的落地建议做了这么多 GPU 云平台的多池规划之后我最大的体感是这套东西并不是一个“一次性项目”而是一个持续迭代的运营体系。选型、采购、架构、演练、账单治理每一环都要有负责人。如果你所在的公司刚开始做这件事我的建议是从最小闭环开始第一先不要一上来就铺三个池。先把主平台稳住确定好日常负载的 80% 场景。第二步在主平台内的弹性扩容跑顺。第三步再引入容灾池从最关键的推理服务开始做备援。第四步等团队精力富余了再考虑真正的跨平台弹性调度。一开始就全面铺开很容易因为运维能力跟不上而翻车。第二无论怎么规划都要保证“多云能力”掌握在自己手里。所谓能力不是“开了账号”而是“知道数据怎么同步、任务怎么调度、实例怎么快速拉起”。建议每个平台至少有一位同事熟悉其控制台、API、计费规则和常见故障排查路径。这样可以避免团队被单一平台的商务条款绑架。第三预算上不要把容灾池当作“纯消耗”。容灾池平时可以承接一部分低优先级任务比如数据清洗、离线评测、小型训练这样闲置资源也能产生价值。我见过有团队把容灾池节点直接当开发测试环境用既降低了边际成本也让容灾链路由“三个月测一次”变成了“每天都在被使用”。最后如果你现在还在犹豫要不要做这些规划那我建议你把平台“资源不足”的严重级别看得更高一些。GPU 不同于普通服务器稀缺决定了它不能简单用“高可用”三个字来兜底。给自己留出第二、第三个可用资源入口无论是从成本、稳定性还是商务谈判空间来看都一定不是浪费。
