设想一位运营同事在工作台里输入：“今晚新版本上线，华东区要不要提前多开一些服务器？顺便看看这样会多出多少碳排。”这一句话看起来是一个问题，实际上包含了至少四种完全不同的计算：听懂“华东”“今晚”“新版本”指的是哪个项目、哪个区域、哪个时间段；预测这几个小时会有多少玩家上线；在容量、延迟和成本约束下算出实例数量；再把新增的用电量折算成碳排。
如果全部交给一个聊天模型，它会给出一段语气笃定、格式漂亮的回答，里面的数字却可能是“听起来合理”的产物，而不是从预测和计量数据里算出来的。九游会AI大模型的思路是反过来：大模型只负责它擅长的语言理解与解释，需要算数的部分交给专门的模型，需要下指令的部分交给带约束的优化器，再由人或规则层确认。这篇文章说明这套分工是怎么划的，以及每一层可能出什么问题。
一句话被拆成四份工作
先看四类模型各自的输入和输出。下表是九游会当前的设计取向，用来说明分工，并不代表某个已上线系统的实测表现。
| 角色 | 擅长什么 | 输入 | 输出 | 不该做什么 |
|---|---|---|---|---|
| 语言模型（LLM） | 理解问题、补全上下文、解释结果 | 运营人员的自然语言、项目配置 | 结构化的任务描述与说明文字 | 自己编数字、直接下调度指令 |
| 负载预测模型 | 估计未来几十分钟到几小时的玩家并发 | 历史在线人数、地区、星期、版本与活动日程 | 并发区间（含不确定范围） | 决定开多少台机器 |
| 优化模型 | 在约束下求最优分配 | 预测区间、实例容量、启动时间、延迟上限、成本 | 候选分配方案 | 解读业务含义 |
| 能源与碳排模型 | 把功率、电量换算成成本和碳排 | 功率与电量数据、区域电价、碳强度 | kWh、gCO2 的估算与区间 | 预测玩家行为 |
这样分的好处很朴素：每个模型都能单独评估。预测模型可以用历史数据回测误差；优化器的输出可以检查是否违反约束；碳排模型可以对照计量数据核对。聊天模型的一句“我认为需要多开20%”没有办法这样核对。
大模型的位置：翻译官，不是决策者
在这套设计里，LLM 的第一项工作是把模糊的问题变成明确的任务。“华东”可能对应项目里配置的某个服务器区域，也可能是玩家地区；“今晚”要落到具体时区和时间窗口；“多开一些”要转换成“在延迟与容量约束下确定实例数量”。如果项目里缺少必要配置，它应该反问，而不是猜。
第二项工作是解释。预测模型给出的是区间，优化器给出的是方案，能源模型给出的是估算范围，大模型把这些结果整理成运营人员能读懂的说明，并标出假设。比如“这个方案的前提是热备实例可以在几分钟内接入”，这类前提要写出来，而不是被流畅的措辞盖过去。
需要明确一点：大模型在优化建模上会出错。近期有研究专门拆解了大模型在把问题写成优化模型时出现的各类错误，比如漏掉约束、搞错变量含义。所以九游会的设计取向是让它输出结构化的任务描述，由固定的模板和校验逻辑把描述转成优化器的输入，而不是让它随手写一段求解代码去执行。
预测模型的误差怎么传到后面
负载预测是整条链的起点，也是最容易被忽略的误差来源。玩家并发预测不是一个数，而是一个带范围的估计。具体的预测方法可以参考《晚上玩家多就一定要多开服务器吗》一文，这里只强调它与下游的接口：预测模型必须把区间和置信程度一起传出去，优化器才知道该为高端情形留多少缓冲。
如果只传一个平均值，优化器会给出一个“刚刚好”的方案，遇到突发就卡顿；如果传的区间过宽，优化器会保守地多开实例，节能空间就被吃掉。预测模型什么时候会错？新版本首日、突发的社交媒体热度、临时的赛事直播、跨区域的登录故障导致玩家集中迁移，这些在历史数据里样本很少，模型的区间应当变宽，或者直接标注“外推，低置信”。
优化器：把“想要”变成“可行”
优化模型拿到预测区间后，要同时满足多组约束：实时对战服务器的延迟上限、各区域的实例容量、实例冷启动所需时间、成本预算，还有可选的能耗或碳排目标。它给出的是一个数学意义上的最优方案，而不是唯一答案；同样的输入，改一下权重（更看重成本还是更看重碳排），方案会不同。这类多目标权衡在游戏数据中心为什么不能只追求最低PUE里有更细的讨论。
需要强调的是，优化器只在你告诉它的约束内工作。如果“某区域不允许缩容到低于某个热备水平”没有被写进约束，它就可能给出一个数学上漂亮、运维上危险的方案。所以约束清单是九游会设计里最需要人来维护的部分，也是每次事故复盘后最应该回头补充的部分。
能源与碳排模型：单独算，单独标注不确定性
能耗与碳排不是同一件事。一个方案的耗电量（kWh）多少，取决于实例数量、服务器功率曲线、利用率与冷却；碳排则要再乘上对应时段和区域的电网排放因子，还要区分平均排放因子和边际排放因子。少耗电不等于少碳，多耗电也可能因为低碳电力占比高而排放更低。这层区分放在能源模型里做，就是为了不被大模型的一句“这样更环保”带偏。
能源模型的输出必须带来源和口径：功率是采集值还是估算值，电量是哪个时间窗口的积分，排放因子取自哪个区域、哪种口径。运营人员看到的“新增约多少kWh、约多少gCO2”应该是一个区间，加上一句“估算，未与电费账单对账”。这些输入从何而来，可以对照绿色游戏大模型到底需要读什么逐项检查。
模型之间意见不一致时怎么办
多模型协作的好处之一，是它们的结论可以互相对照。比如碳排模型认为把某批可延迟的日志分析挪到深夜更低碳，但优化器发现深夜那个区域的容量已被资产处理任务占满；或者预测模型给出的区间与最近十分钟的实际曲线明显偏离。九游会的设计里，这类冲突不由某个模型“投票”，而是被显式抛给规则层和运营人员：哪一条约束冲突了、涉及哪些数据、各自的建议是什么。
另一种常见情形是某个模型不可用或数据缺失，比如电网碳强度数据源暂时断了。此时碳排模型应当说明“使用最近一次可用数据，可能已过时”，而不是悄悄用一个默认值。系统在降级运行时要让人看得出来，这比“永不出错”更现实。
为什么不能让聊天模型直接执行
把这一节单独写出来，是因为它最容易在“方便”的名义下被突破。让聊天模型直接调用调度接口，会同时引入几类风险：输出不确定、同一问题两次回答可能不同；提示词里被混入的恶意或错误内容可能改变行为；没有独立的约束校验；出问题后难以复现和审计。因此，九游会的设计取向是让大模型只能产出“建议”，由后面的优化与校验环节转成方案，再经过模拟和确认才可能执行。这三层怎么衔接，在AI能不能自动管理游戏数据中心里专门展开。
整个流程的上下游关系，也可以放到九游会官网的绿色游戏工作流里对照：预测、区域选择、调度、能耗、碳强度、碳排计算、异常分析，每一步各有输入输出，多模型协作只是让每一步由更合适的模型来承担。
这套分工目前做不到的事
- 不能保证预测在突发事件下依然准确，只能保证不确定性被标出来。
- 不能替代运维人员对业务风险的判断，例如赛事期间是否愿意为稳定性牺牲一些能耗。
- 不能用一个统一指标概括“绿色”，节能、成本、延迟与碳排之间需要显式权衡。
- 不能在缺少数据接入的项目里凭空给出结论；缺什么就说缺什么。
多模型协作并不是把系统做得更复杂而已，而是把“谁负责什么、谁能被审查”写清楚。对基础设施来说，可解释和可回退，比一次看起来聪明的回答更值钱。九游会大模型今后的改进重点，也在于把每个环节的假设与边界做得更透明，而不是让对话显得更像人。
