游戏AI资源调度：从GPU混部到弹性伸缩的架构实践

你可能也会有同感：一聊到“AI资源调度”，很多文章都在讲弹性伸缩、调度算法、优先级抢占这些词，但真正落到游戏AI场景里，满不是那么回事。我最早接触这块，就是在做游戏AI平台的后台架构，当时面对的是很直接的问题：同一批GPU，白天要保证在线AI推理的延迟，晚上又要被强化学习训练任务吃满；节假日活动一开，几小时内要额外拉出几百卡；而旁边还有传统的游戏服务器资源在动态扩容抢机器。你要是不把调度这件事从底层理清楚，后面全是互相“打架”的保障。

我写这篇文章，不是来讲概念，而是想还原一个架构师在腾讯超算中心这类大规模AI算力平台上，接到“支持游戏AI应用”这个命题时，脑子里到底是怎么拆解、怎么设计、怎么落地，以及过程中踩到过哪些坑。无论你是做云原生基础设施、AI训练平台，还是游戏后台的研发，这里面的思路应该都能直接用上。

1. 游戏AI的真实负载特征，和“通用AI任务”根本不是一回事

很多做通用AI平台的朋友第一次接触游戏AI负载，第一反应都是“不就是训练+推理嘛，有什么不一样”。但真把负载监控拉出来，尤其是在游戏AI场景里，你会发现它的特征和通用AI任务完全不同。搞不清楚这个，后面的调度设计就是纸上谈兵。

1.1 训练侧：强化学习的算力胃口没有上限

游戏AI的训练，多半是强化学习（RL）路线，特别是MOBA、FPS这类对抗型游戏里的Bot，往往采用self-play的方式。什么意思？就是AI自己和自己打，边打边学。一局游戏几十个AI角色，每个角色都有独立的策略网络。为了产出高质量的行为数据，你需要同时开上万局游戏模拟，每个模拟环境要消耗CPU做物理碰撞、游戏逻辑，还要用GPU做神经网络的推理和训练更新。

这个负载特征就是：算力需求没有天花板，对资源是“多多益善”的。你给它100张卡，它就开1万局；给它500张卡，它就开5万局。所以训练任务在调度器里如果策略不当，会把整个集群的可用资源迅速吃干抹净。另一个特点是，这类任务通常生命周期极长，一个实验跑十几个小时甚至数天都是常态。一旦中间被中断，如果没有checkpoint机制，之前所有的环境模拟、经验样本全部清零，直接白干。

1.2 推理侧：游戏AI的低延迟约束比互联网后端更苛刻

游戏里的在线AI推理，和你在后端常见的推荐系统推理还不一样。推荐系统的p99延迟做到几百毫秒，用户基本无感；但游戏AI是嵌入在实时对战逻辑里的，玩家操作A技能的一瞬间，AI立刻要有反应，我们内部对这类决策推理的约束普遍在几十毫秒级别，有些场景甚至要求p99在20ms以内。

并且游戏AI的推理QPS不是均匀的。玩家在线率跟着作息走，白天是高峰，凌晨会落到谷底；一旦周末或节假日，玩家数量直接翻倍。这就导致在线推理服务的资源水位设计要么按峰值预留，造成浪费；要么动态扩缩容，但对调度器的响应速度和稳妥性要求极高。还有一个细节：游戏AI推理往往不止一种模型。有策略决策的小模型，也有做事后分析的行为判别模型，还有近两年越来越常见的NPC对话、游戏内文案生成这类大模型推理。不同模型对GPU显存、算力、带宽的需求差异非常大，混合部署时资源分配很头疼。

1.3 潮汐效应：游戏运营节奏把资源波动放大了一个量级

互联网业务一般都讲“流量峰值”，但游戏业务有更剧烈的“运营节奏”。新英雄上线、新版本发布、节日庆典、周末活动，这些时间点在线人数会呈脉冲式暴涨。每个运营活动可能都需要大量额外算力去做AI人机的行为调整、平衡性验证，甚至上线后大量玩家同一时间触发AI对战，推理请求直接翻倍。

我在架构层面把这种节奏叫做“可预期的突发”：它不像故障那样随机，但如果你没有提前做好资源预留和弹性能力，突发的时候在线推理会抖动，训练任务会被挤掉，接着就是一堆游戏体验投诉。所以游戏AI的资源调度，不能只做“当前负载的实时调度”，必须结合“业务日历”做预策、预编排。

一句话总结：游戏AI的资源调度本质是三种负载的博弈——高饥饿度的离线训练、高敏感度的在线推理、强周期性的游戏业务扩容。架构师在设计之前，必须先接受这个现实，而不是套用通用调度框架的默认参数。

2. 架构师要先把“资源”这件事讲清楚：调度模型设计

调度模型听起来很虚，但它决定了后续所有策略的落点。我做这类平台时习惯先定义清楚“资源”在不同层次的长相，否则你跟游戏项目组说“可以给AI推理分配资源”，他们不知道这个资源是GPU卡、容器实例，还是集群Quota，后面需求对接、成本核算全乱套。

2.1 从物理GPU到可调度资源的三层抽象

对于AI资源调度，我倾向把资源分成三层：

第一层是物理资源，也就是机房里的GPU服务器。型号可能是A100、H800、4090等不同规格，它们之间算力、显存、互联带宽差异很大。物理资源层需要考虑的是怎么对上层隐藏异构细节，让业务不关心跑在哪一类卡上，同时又能通过标签暴露必要的差异，比如大显存任务优先调度到大显存节点。

第二层是资源池，也可以理解成逻辑集群。比如按业务线划分：MOBA游戏AI池、开放世界NPC池、基础模型训练池等。资源池的好处是容量隔离，一个池子被打满不会拖垮另一个。但资源池不能做得太碎，否则碎片化导致整体利用率上不去。架构师要做的是找到“隔离粒度”和“共享效率”之间的平衡点。

第三层是可调度对象，具体到任务上，就是Kubernetes里的Pod/Job，再加上对GPU资源规格的定义。这里有个关键点：游戏AI任务对资源规格的要求很不标准。有的强化学习任务只需要一小块GPU做训练，但对CPU要求极高（因为跑大量游戏模拟）；有的是纯推理服务，对GPU算力要求高，CPU要求低。所以我们的资源规格不能只按“几核几G几卡”来定义，还要考虑GPU类型、显存、CPU与GPU的比例。

2.2 用层次配额体系管住“抢资源”的根因

如果没有配额，任何调度器都挡不住一个“吃不够”的训练任务把在线推理资源挤爆。所以我会在资源池之上再建立一套配额体系。这套体系的层级按照公司组织架构来切：

• 公司/集团层：总算力大盘，可以设置安全水位，避免某个BG无限制消耗；
• 业务线/项目层：比如某个游戏工作室、AI平台产品线，各自有配额上限；
• 子项目/应用层：比如某个游戏AI人机项目、NPC对话项目，在这一层做细粒度控制。

每一层配额都包含CPU、内存、GPU卡数、GPU显存、带宽等维度。调度器在接收任务时，先判断该任务属于哪个配额，再判断池子当前水位，双重校验通过才允许创建。这样即便同一个业务线下“训练大户”和“在线AI推理服务”也在互相抢资源，配额能先确保大家不在一个量级上失衡。

配额体系的落地可以跟Kubernetes的ResourceQuota对接，但游戏AI场景往往需要更细的GPU切分。比如一块GPU卡能不能切成几个份额，不同推理任务共享同一块卡。这时候配额的定义单位就不能是“卡”，而应该是“GPU算力单元”和“显存MB”。我们在内部实际上是把GPU抽象成类似“逻辑算力份额”的单位，再绑定显存上限，才解决了按卡分配导致的浪费问题。

2.3 一张表格看懂不同游戏AI任务的资源画像

架构师跟不同项目组沟通时，最怕的就是大家说的资源是同一个词、想的却是不同含义。下面这是我常用的一个梳理模板，把游戏AI里最常见的几类任务画像说清楚：

这个表格不是摆设，它可以直接换算成调度策略。例如“RL训练任务”优先级设为中，意味着当在线推理扩容需要GPU时，调度器可以优先把训练任务挂起或者迁移；“数据预处理”优先级低，意味着它可以接受被抢占，但前提是任务本身做好断点续跑。

做架构设计时，很大一部分工作就是在抽象“资源”和推动各团队对齐“资源画像”。这里多说一句：不要跳过这一步直接做调度算法，否则后续任何一个策略都说不清楚为什么这么定，也没办法跟别人讲明白排队的依据。

3. 混部与隔离：在线推理、离线训练、游戏服务共存的调度策略

纯做在线推理的集群和纯做离线训练的集群，技术上各有一套成熟玩法，并不难。难的是“混部”，也就是把在线推理、离线训练、甚至传统游戏服务（比如战斗服务器、网关）放在同一个资源池里调度。混部是腾讯超算中心这类场景提升资源利用率的核心手段，但它也是无数线上故障的来源。

3.1 调度器中节点级隔离是怎么做的

混部首先要区分“共享的程度”。我们不可能让在线推理和离线训练共享同一个GPU卡，因为RL训练任务一旦把SM占满，推理延迟立刻产生毛刺。所以节点级隔离是最基本的：一台物理机上,要么做主资源给在线推理，要么给离线训练，要么按比例混部，但混部的时候必须通过调度器打标签，保证在线推理Pod和离线训练Pod不会落在同一张GPU卡上。

但CPU和内存可以做更细粒度的混部。游戏AI训练任务的CPU模拟环境，和在线推理服务的CPU消耗，往往在时间上互补。比如推理服务白天高负载，模拟任务可以推迟到夜间；夜间推理压力低，就放行更多模拟任务。具体做法是给节点定义两类CPU资源池，或者用内核QoS（比如cgroup的cpu.shares、cpu.cfs_quota）来控制不同Pod的CPU抢占优先级。

在Kubernetes里，这通常通过自定义调度器和扩展节点资源来实现。我们当时给每个节点打上了允许混部的标签（比如“allow-co-locate=true”），调度器检查Pod类型和目标节点标签，不匹配就直接拒绝调度。规则简单，但很可靠。千万不要指望把调度逻辑压到组件内部黑盒处理——出了问题你排查会很痛苦。

3.2 在线推理与离线训练混部时的公平性算法

节点级隔离只是让两者不会物理上揍成一团，但离线训练任务可能占满集群所有空闲资源，在线推理需要扩容时却等不到资源。这时需要一个公平性调度算法来决定资源分配的顺序和比例。

通用调度里经常提到DRF（主导资源公平性），但我们实践下来，游戏AI场景不能只看CPU或GPU这种单维资源，要把在线推理的SLA因素引进来。我给一个简化版的做法：每个在线推理服务标注一个“保障级别”，比如金牌保障（线上核心对战AI）、银牌保障（NPC对话）、铜牌保障（可延迟的分析任务）。调度器每30秒对金牌服务的副本数进行健康检查，如果发现整体副本数低于目标水位，立即启动“驱逐低优先级任务+扩容”流程。

驱逐不是随机杀。要根据反向调度算法，找出那些当前运行成本最高、但优先级又最低的任务（比如数据预处理Pod），优雅退出并留出资源。这里有个重要的点是：被动驱逐一定得配合任务的自动重启和checkpoint机制，否则你把别人的任务杀了，别人的实验白跑，项目组立刻会对混部失去信任。

3.3 干扰检测与自动驱逐：看似简单、实则最难的一环

上一步的“驱逐低优先级任务”听起来很顺理成章，实际做的时候最大的拦路虎是：你怎么判断在线推理SLA正在被影响？如果等到p99延迟已经飙到不可接受才去驱逐，玩家体验已经受损了。

所以混部集群一定要有非常细粒度的“干扰检测”系统。我们当时在每台GPU节点上部署了监控agent，周期采集的指标包括：

• GPU利用率（SM占用率）、显存带宽利用率；
• 内存带宽、内存延迟；
• CPU调度延迟（runqueue深度）；
• 关键在线服务的p99/p95延迟。

然后通过一套规则判断是否“有干扰”。比如GPU SM利用率连续3分钟超过90%，同时在线服务p99延迟环比上升超过30%，就判定为干扰事件。触发干扰事件后，调度器自动将最可能造成干扰的离线任务驱逐到其它节点。

这个机制单看逻辑不复杂，真正难的是漏判和误判的平衡。漏判意味着在线SLA受损你没有反应；误判意味着离线任务频繁被杀、利用率上不去。我建议先通过小流量压测，把干扰阈值标定好，不要用一套默认参数跑全部节点。另外，监控采集周期必须足够密，30秒一次是底线，对GPU卡级的指标最好5～10秒一次。

4. 弹性伸缩与潮汐调度：活动档期与训练任务动态博弈

弹性伸缩在所有调度系统里都是重点，但在游戏AI上，“潮汐调度”是更有价值的命题。因为游戏业务的负载高峰是有明确时间预兆的——版本更新、大活动、法定假期，这些你都能提前预知，完全可以做得比“事后扩容”更优雅。

4.1 业务级的潮汐特征如何转化为调度触发条件

第一步是把“活动档期”翻译成调度器能理解的“扩容计划”。我们建了一个业务日历服务，游戏运营部门提前把活动计划录入，系统根据历史的玩家在线数据、AI请求量趋势自动生成扩容建议。例如，周五晚上8点有“全服人机对战活动”，系统建议提前1小时把在线AI推理服务副本数从200提升到600，提前30分钟加载新模型版本，活动结束后延迟1小时再缩容。

这个建议会推送到调度平台，经过架构侧确认后自动执行，不需要人工去集群里敲命令。你要注意，扩容不只是“多创建几个Pod”这么简单。游戏AI推理服务启动时需要加载模型文件、初始化显存、做预热请求，整个过程可能要好几分钟。活动开始前半小时才开始扩容，已经算极限操作了，所以我们普遍是提前1小时甚至更早。

4.2 弹性伸缩的两种路径：资源池伸缩与任务自身伸缩

我在这里要特别说一下：弹性伸缩有两种完全不同的落地方式，很多团队只做了第一种。

第一种是“资源池伸缩”，面向的是任务数量和实例数量。比如在线推理服务从200个副本扩到600个副本，本质是调度器在资源池里多创建400个Pod。这种伸缩的价值在于承担突发在线流量，但对训练任务没有太大帮助——你不能把一个训练任务简单地“多加几个副本”来加速，因为强化学习训练是高度状态化的分布式任务。

第二种是“任务自身伸缩”，面向的是分布式训练任务的规模变化。像Horovod Elastic、PyTorch Elastic这类框架，允许在训练过程中动态调整Worker数量。当一个集群高峰期资源紧张，训练任务自动收缩Worker数；到了低峰期资源充足，自动扩展Worker数，甚至临时抢机器来缩短训练时间。这种弹性调度更高级，但对框架和任务代码是有入侵要求的，不是所有项目组都能配合改造。

我给的建议是：如果你的游戏AI训练任务还是“写死世界大小”的传统方式，先别急着上第二种弹性调度，把在线推理的资源池伸缩做扎实，再去逐步推进训练框架的弹性改造。不要把调度架构的复杂度一次性拉满。

4.3 基于成本与SLA的优先级抢占机制

潮汐调度的核心，最终都会落到“资源不够时谁来让路”的优先级抢占机制上。我们内部把优先级分成了四档：

• P0：线上核心AI推理服务（不可抢占，预留资源）
• P1：重要但不紧急的训练实验（可以缩容，但不能被杀）
• P2：普通离线训练作业（可以被抢占，需自动恢复）
• P3：数据预处理、批量分析等临时任务（随时可被杀，无需恢复）

调度器怎么做抢占？举个例子，当一个P0在线推理服务在活动前需要扩容200个Pod，但资源池里只有150个空闲位置，剩余50个需要从P2/P3任务中抢。调度器先选P3任务杀，因为它本身是可有可无的批处理，没有checkpoint都不要紧；还不够，再对P2任务的Worker数量做缩容，而不是直接杀死整个Job。这个“缩容而非杀”的细节很重要，它能在保证在线SLA的同时，尽可能保留训练产出。

抢占的前提是任务本身必须能感知“资源变化”。因此我们强制要求P2任务必须支持缩容，P3任务可以不支持。这不是技术上做不到，而是业务成本和收益要匹配。

5. 配额、成本、SLA：资源治理的架构师视角

调度器做得再好，如果资源配额和成本核算一塌糊涂，这个平台也会在运维层面崩掉。资源治理的核心不是“限制”，而是让每个游戏AI项目组都用舒服，同时整体大盘还能稳定增长。

5.1 从“每个人都能用”到“申请-审批-计量-反馈”

早期我们经历过纯共享集群的乱象：任何项目组都能提交任务，GPU经常被某个实验占满，别人线上推理扩容要排队。后来反思发现，问题出在“资源没有归属感”。于是我们设计了一套规范：

1. 每个游戏AI项目必须注册自己需要的最大资源量、资源类型、使用时间段；
2. 通过配额审批后，项目组只能在配额范围内提交任务；
3. 平台对每个任务的资源使用量做计量，按卡时、GB显存时计价；
4. 每周给项目组发送资源使用报告，展示使用率、浪费率、排队时长变化。

这套流程跑起来之后，项目组对资源的态度立刻变了。以前是无脑申请大规格任务，反正不吃自己的配额；现在因为成本要摊到项目组自己的账本上，大家主动开始做模型量化、数据优化、任务合并，利用率自然就上来了。

做架构师，很多时候你不是在解决“技术”问题，而是在用技术和流程共同解决的问题。配额体系就是典型的“半技术半管理”产物，一定要让规则透明，反馈闭环，否则项目组只会觉得你在搞限制。

5.2 成本归属与账单拆分：让游戏项目组对算力消耗有感知

成本归属这件事，直接影响游戏AI应用能不能规模化。我在设计计量模块的时候，把成本分成了几个维度：

• 资源规格成本：按Pod申请的CPU/内存/GPU规格小时计费；
• 实际使用成本：按监控到的真实CPU/GPU利用率计费，两者取较大值，防止有人申请了资源不跑满；
• 附加成本：镜像存储、数据集缓存、网络带宽等；
• 抢占补偿：被抢占的任务自动获得“免单”或者下个周期优先级提升。

比较重要的一点是：计量要细化到应用（App）维度。项目组内部可能有多个AI应用，每个应用资源消耗不一样，只有细化到App级别，项目组才能知道是哪一个子模块在烧钱，才好做针对性的优化。不要只做到业务线汇总，那种账单没有指导意义。

5.3 调度SLA的量化指标与复盘机制

再好的调度器也需要用SLA来度量。建议游戏AI资源调度平台必须曝光的关键指标有以下几个：

这些指标每周甚至每天要做一次复盘。我特别关注的是“P0任务是否有排队记录”，只要有，就说明在线推理的资源预留策略有问题，必须当周解决。不要等到玩家投诉延迟了才去反查。

SLA复盘最有价值的时刻，是大活动结束后的第二天。把调度日志、扩容记录、实际负载三条线放在一起对比，你很快就能知道是预测不准、扩得太晚，还是准备过度。经过几次大活动的复盘和调优，潮汐调度模型会越来越稳。

6. 落地过程中踩过的坑和一些经验沉淀

前面讲的都是设计和策略，下面这部分才是真正花时间磨出来的经验。有些坑是文档里不会写的，遇到一次能让你排查半宿。

6.1 排队机制设计不好，再好的调度器也会被“饿死”

第一次上线时，我们用的排队策略很简单：FIFO（先进先出）。结果一个项目组提交了一万个数据预处理小任务，排在所有人前面，后面的训练任务和在线推理扩容全部被堵死。后来引入了“期限公平”排队，按项目的配额权重和任务优先级综合排序，才把问题解决。

更麻烦的是“饿死”问题：一个P2训练任务永远被后来的P0任务抢占，导致它连续几天都没跑起来。这个问题的解法是要有一个“年龄”机制，任务排队或者被抢占的时间越长，它的有效优先级会逐步提升，直到最终能获得资源。批处理系统里叫aging，在AI调度上一样适用，而且很管用。

6.2 GPU共享的显存与算力切分：不能只分显存

做推理服务混部的时候，我们最开始用显存去切分GPU（比如一块80GB的卡切成4个20GB的份额），以为占了显存就不互相影响。结果线上发现两个推理服务跑在同一块卡上时，其中一个的p99延迟能翻倍。原因是显存隔离不解决算力争抢，GPU的SM、内存带宽、L2缓存都是共用的。

正确的做法是用支持算力隔离的GPU虚拟化方案，或者退而求其次，让调度器保证同一物理GPU上只跑同一优先级的推理服务，并且给每个服务设定GPU利用率上限。你可以借助NVIDIA的MPS、MIG等机制做硬件级隔离（视GPU型号而定），但要注意兼容性问题，现在的卡和驱动版本差异比较大。

6.3 数据集缓存与调度脱节导致“任务等数据”的尴尬

还有一个特别容易被忽略的问题：训练任务启动时要去拉数据集/模型文件。如果任务被调度到一台没有缓存数据的GPU节点，而数据在另一个节点的本地磁盘或者远端存储里，冷加载可能耗时几十分钟。我们遇到过不少次：资源明明已经分配好，但Pod卡在数据拉取阶段，GPU空转率极高。

解决思路是，调度器在做节点选择时要考量的不仅是计算资源，还要看“数据亲和性”。比如给每个节点打上数据集缓存标签，调度时优先选择缓存了所需数据集的节点；如果不行，选择与缓存节点网络延迟最小的节点。有些团队会用P2P数据分发（类似容器镜像分发技术）来加速冷节点加载，效果也很好。

6.4 沉淀下来比较实用的几条原则

最后分享几条我个人在多次踩坑之后沉淀下来的原则：

• 调度器和业务SLA要联动，不能只做计算资源调度。 至少要让调度器知道每个服务的目标副本数和可容忍的延迟水位，调度才有意义。

• 先做可观测，再做自动化。 没有完整的监控和链路追踪之前，任何自动调度策略都要谨慎上，否则排障成本比你省下的资源成本高得多。

• 小步快跑，用游戏AI单个场景驱动调度演进。 不要试图一上来就做一个覆盖所有场景的万能调度系统。先在一个人机对战AI场景里跑通训练+推理的资源混部，再逐步扩展到NPC对话、内容生成等场景，这样迭代速度最快。

• 架构师要站在“资源使用者”角度设计配额和自助流程。 游戏AI算法工程师不是Kubernetes专家，你要让他们可以用简单的配置（比如填写资源规格和优先级）就能提交模型训练任务，而不是学习你的调度器自定义字段。

我在落地这套体系的过程中，最深的感受是：调度器永远是“技术+业务+流程”三者的结合体，单一维度做得再漂亮，都很难在游戏AI这种复杂场景里真正扛住生产压力。尤其是和游戏项目组对资源画像、对SLA口径、对成本归属反复碰撞之后，你会发现超算中心里的每一块GPU，背后都是活生生的业务诉求在推着架构往前走。