大版本更新当晚，最先出问题的通常是下载速度，而不是服务器。几十GB的补丁同时压向数百万台设备，运营团队关心的是带宽和CDN是否扛得住；做碳核算的人关心的是另一件事：这些流量对应多少电、多少碳。后者比前者难得多，因为传输链条上没有一块“游戏更新专用”的电表。
先拆链条：一次下载经过哪几段设备
一个补丁从构建完成到落在玩家硬盘上，大致经过：源站存储与打包服务器，CDN 的边缘节点和缓存服务器，运营商的骨干与城域网络，接入网（光纤、移动基站或家用宽带），家里的路由器，最后是玩家的主机、PC 或手机。每一段都有电力消耗，但归属方式不同：源站与 CDN 如果是租用的服务，属于 Scope 3 的购买服务；运营商网络同样在价值链上；玩家设备和路由器的用电，是否计入取决于企业边界。这个划分方法与《一款游戏的碳足迹到底从哪算起？》里讲的边界思路一致，只是把范围缩小到“分发”这一环。
常被忽略的一段是终端。下载一个几十GB的补丁，玩家的设备往往要开机数十分钟到数小时，期间的整机功耗（包含屏幕如果没关、主机的待机下载状态、路由器）可能比传输链条上分摊到的那部分电更明显。所以，只盯着“网络每GB多少度”，会把注意力放错地方。
“每GB多少度”为什么这么难定
最常见的估算做法是：补丁体积乘以下载次数得到总流量，再乘以一个网络能耗强度（kWh/GB），最后乘以电力排放因子。问题出在中间那个系数上。
Aslan 等人 2018 年在《Journal of Industrial Ecology》上综述了 2000—2015 年的 14 项研究，发现各研究给出的数值可以从每 GB 一百多度到千分之几度不等，跨度极大；原因包括：是否把数据中心和终端纳入、是否使用了过时的设备功耗数据、网络利用率假设差异很大（文中提到 15% 到 100% 的范围）、PUE 和网络跳数的假设不同。他们的结论是，方法本身不一定是主要问题，关键在于系统边界、参考年份和是否反映真实的利用率，同时估计值大约每两年下降一半，并给出对 2015 年约每 GB 0.06 kWh 的估算。
随后 Coroama 在 2021 年为瑞士联邦能源署做的报告指出，若把其中较低的每 GB 数值直接乘以全球流量，得到的总能耗比另外几组自上而下的估算低一个数量级，说明“强度”和“总量”两类文献之间是不自洽的。2024 年 Guennebaud 与 Bugeau、以及 Mytton 各自发表文章，共同的论点是：网络设备在几乎没有流量时也有大量基础功耗，能耗并不随数据量线性增长，因此用单一的每 GB 数值去评估“多传一个补丁多耗多少电”，本质上是把平均值当成了边际值。
2026 年 8 月一份评估视频游戏整体排放的 arXiv 预印本，在分发环节采用了约每 GB 20 Wh 的假设，同时声明其他环节（如多人服务器、手机游戏）存在缺口。这个例子说明：连专门做游戏行业估算的研究，也只能选一个假设并公开写明，而不是宣称“真值”。
一个模拟示例：同一个补丁，三种系数
假设某款虚构游戏发布 30 GB 的完整更新包，首周有 200 万台设备下载。总流量为 6000 万 GB。如果按每 GB 0.005 kWh、0.02 kWh、0.06 kWh 三种假设估算，网络侧电量分别约 30 万、120 万、360 万 kWh；按 0.4 kg CO2/kWh 的假设折算，碳排约为 120 吨、480 吨、1440 吨。同一个补丁，结果相差十几倍，这不是计算错误，而是系数选择的差异。
再看两个会改变结果的因素。其一，如果改成差分更新，补丁体积只有 3 GB，流量与上面所有数字一起降到十分之一，这是几乎不依赖系数争议的可靠减排，因为“少传”在任何一种模型里都成立。其二，CDN 缓存命中率越高，请求越多在离玩家更近的边缘节点完成，长距离骨干传输的比例越低；反过来，冷门地区命中率低，回源次数增加，边缘节点利用率也可能偏低。这两项在系数上看不出来，却真实影响实际耗电。
哪些结论可以下，哪些不能下
基于上面的分歧，可以相对稳妥地说的有：补丁体积越小、下载重复次数越少，分发环节的能耗与碳排就越低；差分更新、压缩、断点续传、预下载后本地分享，方向上都有效；下载期间玩家设备的运行时间是一项独立的、可以被估算的排放来源。
不能下的结论包括：不能因为某一个每 GB 数值看起来“很小”，就断言更新包碳排可以忽略；也不能把某次更新的“总碳排”当成实测数据发布，因为链路中的绝大部分设备并没有被计量；更不能把“把下载安排在电网碳强度低的时段”当作必然有效的减排手段，因为网络设备的基础功耗基本恒定，玩家侧才是时段变化更明显的部分，而预下载通常又要遵守玩家的体验期待。
补丁之外：被下载“拖长”的设备待机时间
如果只能优先核实一项数据，更值得先看玩家设备在下载期间的状态。假设一台主机为了下载补丁被玩家放着过夜，即便传输链条的电耗被系数放大到最高，设备本身十个小时的待机与下载功耗也未必更少；相反，如果补丁很小、几分钟下完，这部分可以忽略。也就是说，同样是“少传一点”，它的收益有两处：网络侧少传，终端侧少等。
另一个容易被忽视的细节是重复下载：因为下载失败重来、多设备各自下载同一份内容、玩家卸载后又重装，实际流量常常高于“发布补丁体积乘以活跃用户数”的理论值。有 CDN 日志时，应当用日志中的实际字节数，而不是理论值；没有日志时，则要在估算中留出一个重复系数，并把这个系数的来源写清楚。
九游会怎么处理：区间、分项和标注
在九游会碳足迹AI里，更新与分发被单独放成一个项目模块。输入是补丁体积、发布时间窗口、按地区的下载量、CDN 服务方提供的流量与命中数据（如果能拿到）、玩家设备类型的抽样比例；输出是分项估算：源站与 CDN、网络传输、玩家设备下载期间用电，并附上使用的每 GB 假设区间与来源年份。当数据缺失时，界面会标注“估算”与“缺口”，而不是自动补一个看起来合理的数字。
这套流程的意义，主要在于让运营团队能比较“方案”而不是宣称“绝对值”：例如全量包与差分包、集中发布与分区域分批发布、是否启用夜间预下载，各自对流量和终端待机时间的影响。更多关于同一项目里玩家侧排放的核算，可以参考《一小时游戏到底排放多少碳？》；直播场景下流量更持续，估算方式有相似之处，也有编码与并发观看的差异，见《一场电竞直播的能源消耗发生在哪里？》。
九游会目前做不到的是：获得运营商网络的实际逐设备功耗，或在没有 CDN 服务方数据的情况下还原真实路径。遇到这种情况，只能给出区间，并把假设写进报告。硬件制造的隐含碳同样是一块难以忽略的背景，读者可以对照《只算游戏运行够不够？》一起看。
