运营人员问：“明晚新版本上线，欧洲区要不要提前扩容，顺便能不能把日志分析挪到低碳时段？”这一句话背后，模型至少要同时知道玩家会来多少、服务器现在忙不忙、机房的余量和制冷状况、当地电价与电网碳强度。任何一类缺了，回答都只能是泛泛而谈。下面按数据的来源，把九游会AI需要读取的内容分层说清楚。
玩家侧：需求从这里开始，但只需要聚合数据
核心指标是在线人数（含并发峰值与分钟级变化）、按地区和平台的分布、登录与匹配排队情况、游戏模式占比，以及运营日历——版本更新、活动、赛事直播时间、节假日。这些数据决定“未来几分钟到几小时需要多少算力”，是晚上玩家多就一定要多开服务器吗里预测问题的输入。要强调的是，能源与调度分析用的是聚合值，不需要玩家账号、聊天内容或个人行为轨迹，九游会AI的设计取向也是默认不读取这些内容。地区粒度要与后面的服务器区域、电网区域能对得上，否则碳排计算会挂错电网。
服务器侧：CPU、GPU、内存、网络与时延要一起看
只看CPU利用率不够。游戏服务器可能卡在内存、网卡带宽或单线程性能上；GPU任务（云渲染、推理、训练）要看GPU利用率、显存、功率和每任务耗时；网络要看出入带宽、丢包与往返时延，并且按玩家地区拆开看。这些指标回答的是“机器现在是真忙，还是只是开着”：利用率很低但被列为热备的实例不能随便关，利用率很高但吞吐没涨的GPU可能只是在排队。哪些实例能合并、休眠或延后，就是靠这几列判断的。
设施侧与电力侧：把千瓦时和碳排接起来
设施侧需要机房的总功率与IT功率（用来推算PUE趋势）、制冷状态、机柜进风温度，以及室外天气，因为制冷开销随气温和湿度变化。电力侧则包括分时电价、区域电网的碳强度（实时值与预测值）和可再生能源占比。碳强度要标明是平均排放因子还是边际排放因子、是过去值还是预测值、时间粒度是多少——这些差别会直接改变“哪个时段更低碳”的答案，同一局游戏放在两个地区运行，碳排放为什么可能完全不同里有对这一点的详细例子。
| 数据层 | 典型指标 | 常见粒度（示意） | 最容易出的问题 |
|---|---|---|---|
| 玩家 | 在线人数、地区、活动日历 | 分钟级 | 地区口径与服务器区域不一致；活动时间写错时区 |
| 服务器 | CPU、GPU、内存、网络、时延 | 秒到分钟级 | 指标缺失被当成0；采样间隔不同 |
| 设施 | 总功率、IT功率、制冷、温度、天气 | 分钟到小时级 | 计量点不同导致PUE算错 |
| 电力 | 电价、碳强度、可再生占比 | 小时或更细 | 平均与边际混用；预测值当实际值 |
对齐比读取更难：一个模拟示例
设某个区域的服务器功率每10秒采样一次，某15分钟内平均为240 kW，那么这15分钟的电量是240 kW乘以0.25小时，等于60 kWh。玩家人数每分钟一条，碳强度每小时一条。要算这15分钟的碳排，必须决定用哪一个小时的碳强度，跨整点的窗口还要拆开。如果直接把瞬时功率当电量相加，单位就错了；如果某几个采样点缺失，被填成0，平均功率会被拉低，模型会以为这段时间很闲。这类错误不会报错，却会让建议看上去合理。九游会的处理流程因此把单位换算、时区统一、缺失标记和采样对齐放在模型读取之前，而不是交给模型自己“理解”。
大模型读什么，预测与优化模型读什么
数字时间序列不适合直接塞进聊天式大模型。较稳妥的分工是：预测模型读时间序列，给出人数和负载的预测区间；优化模型读容量、约束与预测，计算候选分配；大模型读取这些模块的摘要和运营人员的问题，用自然语言解释、追问缺失信息。这种分工在大模型负责“看懂运营问题”，优化器负责“真正调服务器”里有展开。也就是说，九游会大模型“读”的更多是结构化的工具输出，而不是一堆原始日志。
数据的新鲜度：同一个数字，晚到十分钟就是另一个答案
不同数据的更新节奏和延迟差别很大。服务器监控通常几乎是实时的；电网碳强度往往按小时公布，而且实时值事后还可能被修订；电价有日前价格和实时价格之分；天气则是预报，不是实测。模型在做“接下来几小时怎么排”的建议时，读到的碳强度多半是预测值，预测本身有误差，越往后误差越大。所以读取数据时要同时记下“这条数据的时间戳、来源和是否为预测”，建议输出时也要带上这些信息。运营人员看到的应当是“在当前预测下，2到4点之间碳强度较低，但预测在夜间风电出力上不确定”，而不是一句干脆的“凌晨执行”。
另一类容易被忽略的延迟是数据本身的采集链路：跨区域上报时，某个区域的指标可能晚几分钟到达，模型若把“尚未到达”当成“没有负载”，会把该区域判断为空闲。九游会AI的处理思路是给每类数据设定可接受的延迟上限，超过上限就标记为过期，相关结论降级，而不是沿用旧值继续推算。
一次提问会读到什么：走一遍
回到开头那个问题。系统会先读活动日历与历史同类版本的在线人数曲线，得到欧洲区的人数预测区间；再读该区域各实例的CPU、内存、网络和冷启动耗时，估算需要提前多久、多少个实例开机；读机房的可用功率余量，确认容量足够；最后读区域电价与碳强度预测，只对日志分析这类可延迟的任务提出时间窗口。实时对战的实例数量，只会依据人数预测和延迟目标来定，不会因为碳强度更低就被挪到别处。整个过程里，每一步用了哪些数据、缺了哪些数据，都会在回答里列出来。
数据不够时，模型该怎么说
没有某一层数据时，正确的行为是降低结论的确定性，而不是补一个默认值。例如项目里没有设施侧计量，就不能推算PUE，只能给能耗的粗略范围；没有区域碳强度，就只能报告电量，不能报告碳排；预测窗口内有重大活动却没有活动日历，人数预测应标注为不可靠。九游会AI目前也无法读取没有接入的系统，不能凭空知道某台机器的真实电表读数。所以更实际的第一步，是先检查项目的数据接入范围、权限和时间区间是否覆盖了上面四层，再谈用模型给建议。任何一层缺失，建议里都应当写明“基于哪些数据、缺哪些数据”，让运营人员知道该补什么，而不是只给一个漂亮的结论。
