游戏AI超算中心资源调度：训练推理混合部署架构实战

开场先抛个问题：你有没有想过，《王者荣耀》里那个随时能陪你打一局的AI托管队友、吃鸡类游戏里几十个NPC同时做出合理决策、以及新版本上线前需要跑几千局对战模拟的强化学习训练，背后到底需要多大的算力？如果只是单纯堆机器，那资源利用率低到你怀疑人生；但要是只做资源分配，游戏AI的实时性和训练任务的高吞吐又互相打架。这正是超算中心AI资源调度要解决的核心问题，也是架构师真正体现价值的战场。

这篇文章不聊虚的，就围绕腾讯超算中心这类大规模GPU集群，讲讲架构师到底怎么设计一套资源调度体系，让它既能扛住游戏AI训练的高强度计算，又能满足在线推理的毫秒级延迟。适合正在做AI基础设施、想要理解大规模调度系统设计思路、或者准备系统架构师方向学习的同学，看完能直接带走一套可落地的方案框架。

1. 游戏AI的算力需求，和传统云计算根本是两回事

1.1 训练、推理、仿真，三类任务混在一张集群里

很多人对游戏AI的理解就是“让电脑控制一个角色跟你打”，但实际上游戏AI的落地场景远比这个复杂。以腾讯超算中心承接的游戏AI应用为例，大致可以分为三类。

第一类是离线训练任务，典型代表是强化学习。游戏AI要走通“感知-决策-行动”闭环，通常需要大量的环境交互数据。比如一个格斗游戏里的AI对手，需要经历数千万局对战才能学会合理的走位和连招。这类任务的特点是：单任务跑得时间长（动不动几天几夜）、对GPU算力要求高（经常需要多卡并行）、重视吞吐量而不是单个请求的延迟。

第二类是在线推理服务。比如游戏中实时匹配的AI托管、语音对话NPC、或者根据玩家操作实时调整难度的动态对手。这类任务对延迟极度敏感，玩家按下按键之后，AI必须在几十毫秒内给出决策，否则游戏体验就毁了。推理服务的特点是：流量波动大、容忍不了冷启动、需要常驻一定数量的资源池。

第三类是仿真评估，这个容易被忽略但很关键。游戏版本更新前，AI模型必须先在新版本环境下跑几千局模拟测试，验证胜率、平衡性、BUG率。这类任务介于训练和推理之间，要求不高但量极大，而且通常是周期性的，往往集中在版本发布前那一周。

问题来了：这三类任务如果各自建一套独立的集群，成本高到没法接受。训练集群在非高峰期大量闲置，推理集群又要预留峰值冗余。所以架构师必须考虑“混合部署”，也就是训练、推理、仿真共用一个超算资源池。但这又带来了新的矛盾，训练任务想要大块的GPU时间片，推理任务却要求随时能抢到资源，两者在调度层面天然互斥。

1.2 为什么不能直接用现成的调度器

我刚接触这个场景的时候，第一个想法是直接用开源的调度框架。但深入看下来，通用调度器在游戏AI场景里几乎都要做深度改造，根源在于游戏AI任务有几个特殊属性。

一是任务拓扑复杂。强化学习的训练任务通常不是一个单一的Pod，而是“一组学习者+一组推理者+一组环境模拟器”的协同工作。学习者负责梯度计算，推理者负责实时决策，环境模拟器跑游戏逻辑产生状态转移。这三者在运行过程中需要高频通信，延迟稍微高一点，训练效率就断崖式下跌。通用调度器默认的“单一Pod调度”模型根本不适用。

二是资源需求动态变化。一个训练任务在刚开始的时候，环境模拟器只需要少量算力，因为模型还在随机探索阶段。但训练中期，模型复杂度和经验池数据量上来之后，模拟器的负载会成倍增长。静态分配资源的做法要么前期浪费，要么中期不够用。

三是优先级需要动态调整。游戏在线推理服务有严格的SLA，但训练任务也不见得是越低越好。比如一个即将上线的新玩法，它的验证训练任务可能比某些老游戏的日常推理更重要。这就存在一种“反向优先级”的场景，不能简单地一刀切“在线优先于离线”。

所以架构师真正要做的工作，不是把开源组件装起来配个参数，而是要重新设计一套符合游戏AI业务模型的资源抽象和调度策略。这也是这篇文章想重点展开的地方。

2. 架构设计：从物理资源到AI任务的用户视角抽象

2.1 分层设计：控制面、调度面、数据面各自管什么

在腾讯超算中心这类场景里，AI资源调度的架构通常会分成三个层面：控制面（Control Plane）、调度面（Scheduler Plane）和数据面（Data Plane）。这个分层不是为了追潮流，而是为了解决一个很实际的问题：不同角色对“资源”的理解完全不同。

集群管理员关心的是物理GPU、节点利用率、电费成本；调度器关心的是每个任务需要多少算力、什么时间运行、依赖什么数据；AI工程师关心的则是“我能不能申请到4张A100跑一个大模型训练”。一套健全的调度系统，必须把这三层抽象打通，让上层业务不用关心底层物理细节，让下层物理资源能被灵活切分。

具体来说，控制面负责两件事：一是资源配额和权限管理，二是跨集群的全局视图。比如某个游戏项目组申请了“最多128卡GPU”的配额，控制面要确保他们不能超用，但允许他们在配额范围内灵活调度。调度面负责单集群内的任务编排，决定“这个GPU上此刻应该跑什么”，是真正的调度核心。数据面则负责具体的资源状态采集、任务生命周期管理、GPU监控数据上报。

三层分离之后有个明显的好处：调度策略可以单独升级而不影响业务侧的使用方式。我见过有些团队把调度逻辑全部塞在任务提交的API里，结果每次调优都要业务方跟着改造，维护成本极高。分层设计之后，AI工程师只需要面对一个统一的任务提交接口，背后调度逻辑怎么演进他们完全无感。

2.2 核心问题清单：架构师在动手前先要回答这七个问题

在画架构图之前，我习惯先把问题清单列出来。这七个问题决定了一套调度系统的骨架：

第一，资源的最小粒度是什么？是整卡GPU、显存切片、还是算力份额？游戏AI训练通常需要整卡甚至多卡，推理则经常需要小份额。

第二，任务的排队策略是什么？是单纯先来先服务，还是需要按照优先级、业务线、预计运行时长做多维度的综合排序？

第三，如何定义“资源不够”？是GPU数量不够、显存不够、还是节点间的网络带宽不够？游戏AI恰恰会因为最后一公里的拓扑问题导致整体训练变慢。

第四，任务失败之后怎么处理？自动重启还是有状态恢复？强化学习的checkpoint动辄几个GB，频繁失败恢复的代价极高。

第五，资源碎片问题怎么解决？一台8卡的节点上，如果某个任务只占了1卡，剩下的7卡又不够下一个任务用，就产生了“卡碎片”浪费。

第六，如何平衡多租户之间的公平性？多个游戏项目共用一个集群，谁也不能饿死谁。

第七，实时推理和离线训练之间如何抢占和释放资源？这可能是最难回答的一个问题。

这些问题看起来是技术问题，但每个背后都牵扯到成本、效率和业务SLA的权衡。架构师的价值就在于，面对这些互相矛盾的目标时，能给出一个清晰且可落地的取舍方案，而不是试图做一个什么都优化的完美系统。

3. 资源抽象与调度策略：让训练和推理在同一张GPU上和平共处

3.1 可抢占资源池与弹性伸缩：用超卖率换吞吐

在线推理和离线训练混部的核心矛盾在于：推理服务要求资源“随要随有”，训练任务又希望能充分利用碎片时段。如果给推理服务预留太多固定资源，空闲时段就是纯浪费；预留太少，流量高峰时期又必然被杀。

业界一个比较成熟的解法是“可抢占资源池”。具体思路是：训练任务使用低优先级抢占式配额，正常运行时可以占用一大块GPU资源；一旦在线推理服务的扩容请求到达，抢占机制会先通知训练任务触发checkpoint保存，再回收资源给推理服务。训练任务被抢占之后排队等待，等推理流量回落，再恢复训练。

这里有两个关键参数需要架构师仔细调优。

一个是超卖率（oversubscription ratio）。定义是“允许调度出去的资源总量/实际物理资源总量”。假设集群有100卡GPU，超卖率设为1.2，则调度器最多可以给任务分配120卡“名义资源”。超卖率太高，抢占了谁都跑不动，系统颠簸；太低，混部的收益不明显。以我的经验，游戏AI场景建议从1.15开始压测，根据任务的平均实际GPU利用率逐步上调，最高不建议超过1.3。

另一个是抢占策略。是“批量抢占”还是“渐进抢占”？批量抢占的效率高，把所有低优先级任务一次性清理掉，但代价是训练任务集体中断，恢复成本极高。渐进策略每次只回收一个节点的资源，回收效率平滑，但面对突发的推理流量洪峰可能来不及。实际生产环境往往需要折中：流量突增比例小于20%时用渐进，超过则直接触发批量抢占。

3.2 成本与性能的平衡：GPU碎片整理与拓扑亲和性

用久了你会发现，调度问题的本质根本不是“给任务找位置”，而是“在有限资源下实现全局最优排列”。GPU碎片问题是典型的例子。

比如一个节点有8张卡，某个训练任务需要4张卡，调度器只找到两个节点各有3张空卡，由于任务需要4卡，这两个节点都无法满足，于是这6张卡全部空闲。这就是“卡碎片”造成的利用率损失。应对方案有两种：一是任务规格弹性化，把4卡任务动态调整为“3+1”的组合，跨节点做并行训练；二是主动碎片整理，通过迁移任务把小碎片合并成大块连续空间。前者的实现成本低，但需要训练框架本身支持弹性规格；后者对调度器的复杂度要求高，迁移过程中还要保证任务不中断。

拓扑亲和性则是游戏AI性能优化的另一大隐藏点。多卡训练任务对GPU间通信带宽极强依赖，如果两张卡分别位于两个不同节点上，通信要走网络交换机，延迟可能是同节点NVLink的几十倍。调度器在做任务放置时，必须优先考虑“同节点内连续卡位”，其次考虑“同机柜”“同交换机”。如果盲目用开源调度器的默认策略，只关注资源量而不关注拓扑，训练效率可能直接打五折。

这里我给一个参考的调度策略优先级排序：GPU拓扑亲和性 > 节点的负载均衡 > 任务优先级 > 资源碎片率。把拓扑亲和性放在第一位，对游戏AI训练类任务几乎总是最优解。

4. 实操落地：任务调度核心模块的设计与关键参数

4.1 调度器模块拆解：队列、优先级、抢占，各司其职

架构师在落地一套调度系统时，第一件事不是写代码，而是先画清楚调度器内部模块的职责边界。就超算中心的AI资源调度而言，调度器至少需要包含四个核心模块。

队列管理模块负责维护多个优先级队列。游戏AI场景通常建议至少三条队列：高优先级队列给在线推理和紧急验证，普通队列给日常训练，低优先级队列给批量仿真和探索型任务。每条队列配独立的权重，防止某个项目把资源全部占满。

任务调度模块负责具体的“资源匹配”动作。它综合任务的资源规格、拓扑需求、预估运行时间，从集群当前空闲资源里选出最优放置位置。这个过程需要实时访问节点资源状态和GPU拓扑信息。

抢占决策模块负责动态回收资源。它持续监控各队列的等待时间和在线推理服务的SLA指标，一旦发现推理服务出现排队或延迟超阈值，就触发抢占流程。这个模块的核心逻辑不是“谁优先级高就抢谁”，而是“抢最低成本的任务”——比如优先抢占还没跑出有效结果的仿真任务，其次是checkpoint节奏良好的训练任务。

弹性伸缩模块负责配合云原生能力动态调整推理服务的副本数。它和抢占模块是互相配合的关系：先扩缩容，还不够再抢占，尽量减少对离线训练的影响。

4.2 关键配置参数：一份可以直接抄的调度参数模板

下面给出一份我整理过的调度参数模板，适配目标为“8卡A100节点，共32节点，GPU总数256卡”的中等规模超算集群，可用于游戏AI训练和在线推理混合部署。读者可以根据自家集群规模按比例缩放。

其中训练任务保存checkpoint间隔这个参数很容易被忽略，但实际上对抢占式调度的体验影响巨大。间隔太长，训练任务被抢占后回滚损失大；太短，checkpoint本身的写入会占用不少IO带宽和GPU时间。我实测下来，5分钟是一个比较稳的折中点，模型状态文件在3~5GB级别时，checkpoint写入的开销控制在总训练时间的2%以内。

4.3 训练任务状态机设计：从提交到结束的完整生命周期

调度系统的鲁棒性，很大程度上取决于任务状态机的设计是否完善。一个游戏AI训练任务从提交到最终结束，至少要经历以下几个状态：Pending、Scheduled、Running、Suspending、Suspended、Resuming、Succeeded、Failed。其中Suspending和Suspended就是为抢占场景专门设计的。

任务提交后进入Pending状态，调度器根据当前资源情况决定是否满足启动条件。一旦满足，进入Scheduled状态并启动容器。正常运行时是Running状态。如果抢占决策模块介入，任务先进入Suspending——这个状态很关键，它给任务一个“grace period”来保存模型权重、上传checkpoint、通知训练框架暂停。这个窗口期通常建议设为30到60秒，太短来不及保存，太长抢占等于没生效。保存完成后，任务进入Suspended状态，但容器不一定销毁，可能只是释放GPU资源，保留内存中的部分数据以加快恢复速度。当资源重购之后，任务走Resuming流程，加载checkpoint继续训练。

这个状态机的设计可以保证“抢占”不是杀掉任务，而是“暂停-恢复”。相比重启任务要重新加载环境和数据，暂停恢复的开销通常只有前者的十分之一。

5. 游戏AI特有的场景化调度：什么情况下需要特殊处理

5.1 强化学习训练场景：多角色的协同调度难题

前面提到，强化学习训练任务由学习者、推理者和环境模拟器三部分构成。这三部分对资源的需求特征差异很大，必须分开调度。

环境模拟器是典型的CPU密集型任务，跑的是游戏引擎逻辑，几乎不用GPU，但对CPU核心数和内存带宽敏感。推理者是低延迟GPU服务，需要小批次、高频率的推理，典型规格是1卡GPU配2到4个CPU核。学习者是大规模GPU任务，负责梯度聚合和参数更新，通常需要4到8张卡并行。这就带来一个问题：三者之间需要高频通信，不能简单地各自分派到集群的不同角落。

架构师需要把三者抽象成一个“任务组”（Pod Group），调度时确保组内成员分布在相近的节点上，避免跨机柜通信。同时，组内成员的数量和规格允许动态调整。比如环境模拟器负载升高时，可以单独扩容模拟器数量而不影响学习者和推理者。我见过一些团队在做这种调度时，直接把三者当成一个整体容器启动，结果模拟器成为瓶颈，整体吞吐反而上不去。

5.2 在线推理场景：如何应对游戏热更和活动流量

游戏AI在线推理的一个显著特征是和运营活动强相关。新赛季开启、限定活动上线、周末晚间高峰，推理服务的流量经常是平时的3到5倍。如果调度系统不能提前预判这种流量，就只能被动响应，导致部分玩家在高峰期体验到AI反应变慢甚至卡顿。

架构师可以考虑两个方案。第一个是“活动日历驱动扩容”，在运营活动排期确定后，提前在调度系统里录入扩容计划，让推理服务在活动开始前半小时就完成扩容。第二个是“指标驱动的阈值自愈”，监控推理服务的平均延迟和排队长度，一旦超过P99延迟阈值，自动触发扩容。第一个方案治本，第二个方案兜底。

这里要注意的是比例问题。从我接触的游戏AI业务来看，推理服务扩容速度跟不上的原因很少是硬件不够，基本都是调度策略的响应太慢。比如默认的扩容检查间隔是30秒，再加上镜像拉取和容器启动时间，整体从发现流量尖峰到实际扩容完成可能要3分钟以上，这在游戏高峰期已经是灾难性的。解法是把推理服务的节点预置为“热节点”，即常驻一个极小的推理实例和准备好的镜像，扩容时只需叠加副本，不需要重新创建容器环境，扩容时长可以从分钟级压到秒级。

5.3 大模型训练与游戏内容生成的算力分配策略

游戏AI领域最近明显在往生成式方向走，比如用大模型生成关卡、NPC对话、甚至角色动作。这类大模型训练任务往往比传统强化学习更重，单任务就可能需要几十张GPU训练几周时间。如果调度策略还按常规方法处理，很容易出现一个任务把集群资源全部吃完，其他所有业务全被阻塞的情况。

针对这类任务，除了前面说的优先级队列，还需要专门设置“资源上限”的隔离机制，比如“单个任务最多可占集群总资源的40%”。超过上限后，即使资源有空闲，调度器也不允许新的大任务启动。这个限制看起来有点反直觉——毕竟“让AI先跑完不更快吗”——但实际运营中会发现，资源全被一个大任务占住的代价是，所有小任务无法推进、在线服务无法扩缩容、新版本的验证任务全部排队，最终反而拖慢整体进度。

我的建议是为大模型训练单独划分“物理隔离的资源池”，和大盘的混部池分开管理。大模型池负责长周期训练，混部池负责在线推理、仿真和短训练任务。两个池子之间允许动态借调，但借调时必须能随时中断归还。这样可以兼顾长任务的效率和其他业务的可控性，是当前实践中最稳健的配置方案。

6. 性能调优与资源利用率提升：从数据里找答案

6.1 监控指标怎么选：别盯着GPU利用率不放

很多团队在做调度优化时，习惯性只盯着GPU利用率这一个指标看。这其实是个认知陷阱。GPU利用率高，不一定代表集群在产生价值。比如某个训练任务因为数据读取太慢，GPU大部分时间在空转等数据，但调度器计算利用率时，只要GPU有活动就计入，这样看起来90%利用率，实际有效算力可能只有一半。

架构师在建设调度系统的同时，必须同步建设一套“有效利用率”监控体系。建议至少包含四个指标：算力占用率（GPU的SM忙碌比例），显存带宽利用率（实际读写量/理论峰值），通信等待占比（训练任务中等同步通信的时间比例），以及任务有效推进速度（单位时间内完成的训练步数或样本量）。

这四类指标组合起来，才能定位资源瓶颈到底在算力、显存、网络还是数据管线上。我踩过这样的坑：一开始发现集群的整体利用率很低，于是往调度器里加了各种激进策略，结果发现根因是某个数据预处理服务只有两个副本，成了全链路瓶颈。节点要增加副本，不是调度策略问题，但由于监控指标选错了，白白浪费了两周多的调优时间。

6.2 混部技术的实际收益：一组压测数据参考

混部到底能省多少钱，这是很多管理者最关心的问题。根据一个32节点集群的对照压测数据（纯离线训练模式 vs 训练推理混部模式），在同样完成既定任务量的前提下，混部模式的算力成本可以下降约30%到35%。具体数据如下：

需要提醒的是，混部带来的训练完成时间延长大约在8%左右，这是抢占和弹性调度造成的合理代价。如果业务方对训练周期极度敏感，无法容忍这8%的延后，那就得重新评估混部是否合适。没有银弹，只有取舍。

7. 问题排查与实战经验：那些文档里不会写的坑

7.1 高频问题速查表

7.2 从一次事故聊起：调度器被“饿死”的教训

有一个真实事故值得分享。某次某热门游戏的新版本AI系统压测，训练任务占用了集群80%以上资源，同时在线推理流量突然翻倍。抢占模块按设计触发，开始回收训练任务资源。但问题出在回收速度太慢，只做渐进抢占，每次回收一个节点的资源需要约30秒，而推理服务的扩容队列已经等不了那么久了，结果在线服务连续数分钟处于超载状态。

复盘之后我们发现，问题不在于抢占策略本身，而在于缺少“分级触发”机制。正确做法是：推理服务单副本负载超过80%时渐进抢占，一旦P99延迟超过100ms且持续30秒，立即切到批量抢占模式，一次性回收足够的候选资源。这个改动上线后，同样的压测场景下，在线服务超载时间从数分钟降到了几秒，训练任务的额外中断损失每天不到一次。

这类事故再次证明了前面说的观点：架构师在设计调度系统时，绝对不能只考虑“最理想情况下怎么跑”，一定要把“故障场景切换机制”当作核心功能来做，而且要做故障演练验证。

7.3 关于调度策略调优的几个个人心得

实际项目做多了，我越来越觉得调度策略调优有点像调音师，参数不是越多越好，关键是找到属于自己场景的那个“音准”。有几次调优经验分享给大家参考。

第一，不要一次性调整多个参数。调度系统的参数之间往往互相影响，比如调高超卖率的同时又把抢占间隔缩小了，出问题后你根本不知道是哪一步导致的。正确的做法是每次只动一个参数，跑两到三天，用监控数据验证效果后再动下一个。

第二，一定要做Chaos Testing。调度器的故障处理能力，只有通过人为制造故障才能检验。常见的演练有：随机杀掉几个训练任务、模拟单个节点掉线、强制把在线推理流量翻倍。每次演练后记录调度器的恢复时间和业务影响，持续迭代。

第三，和训练框架团队保持紧密协作。调度器再聪明，也得靠训练框架配合才能真正做好抢占和恢复。比如PyTorch的torch.distributed.elastic本身就提供了容错机制，如果你能让训练侧和调度侧统一使用这套机制，恢复成本会大幅下降。这属于跨团队协作问题，但架构师必须主动去推动。

8. 算力成本治理与可持续运营

8.1 从技术指标反推成本模型

技术人做事情容易只看技术指标，但管理者一定会问“省了多少钱”。架构师如果能把技术指标翻译成成本语言，沟通效率会大大提升。

一个简单的成本模型是：集群月成本 = GPU单价 × 运行时长 × 实际利用率系数。其中“实际利用率系数”指的是有效算力占名义算力的比例。混部调度做得越好，这个系数越接近于1。以一块A100为例，市场价格大概是每小时20到30元，如果集群从利用率60%提升到85%，一个256卡的中型集群，每月省下的成本大约是80到120万元。这个数字放到任何公司都不是小数目。

建议架构师在推进调度系统建设时，从一开始就建立成本账本，按项目、按任务类型、按队列分别统计资源消耗和费用分摊。这样不仅能让资源使用更透明，还能反过来促进业务方主动优化自己的任务，形成正向循环。

8.2 从“能跑起来”到“可持续运营”的三层演进

一套调度系统从建设到成熟，通常要经历三个阶段。第一个阶段是“能跑起来”。这个阶段解决的是核心链路打通，任务能提交、能调度、能运行，监控告警能响。很多团队做到这一步就以为大功告成，这是最大的错觉。

第二阶段是“稳定可靠”。这个阶段要做的是故障恢复、参数调优、混部比例调整，让系统在面对真实负载波动时依然稳定。这一阶段最花时间，可能需要两个季度以上的持续打磨。

第三阶段是“持续运营”。此时架构师应该把重心转向成本优化、容量规划、调度策略的自动调优，甚至引入一些智能化的手段。比如基于历史负载数据预测未来几天的资源需求，提前生成调度预案。这个阶段的核心目标是让系统具备“自愈”和“自优”能力，减少人工介入。

超算中心的AI资源调度，做成“能跑”真的不难，难的是让它在复杂的游戏AI业务场景下持续跑得又稳又省。架构师的工作不是做完一个项目就结束，而是要让这套系统成为一个能随着业务一起成长的平台。这个过程需要耐心，也需要持续在一线环境中摸爬滚打去积累经验。