Win11月度更新体积已飙升至5GB！两年间膨胀16倍：AI仅需承担部分责任

4月29日消息，经Windows Latest深入调查发现，Windows 11的月度累积更新文件大小，已从2024年时的约300MB增长到2026年的5GB，解压后的容量则更接近9GB。

其中AI功能确实贡献了部分增量，但更新机制本身的设计才是体积持续膨胀的根本原因。

AI组件：3GB的增量从何而来

2025年5月的累积更新是一个关键转折点，该月更新包体积从此前的约1.3GB骤增至4.4GB，解压体积从6.5GB跳升至近9GB。

WindowsLatest通过解包分析发现，此次更新的增量主要源于数十个之前未出现过的MSIX组件，这些组件均与语义搜索和本地AI推理有关，因此这大约3GB的增量基本可归结为AI组件的添加。

这里存在一个关键细节，这些AI组件最初仅为Copilot+ PC设计，随着支持范围扩展到Intel和AMD平台，更多版本被塞进同一个更新包。

Windows Update的适用性检查机制会在下载前对硬件配置进行检测，只获取系统真正需要的部分。在一台没有NPU的虚拟机上进行测试，原本4GB以上的目录包实际只下载了大约1.7GB，语义搜索组件没有被获取。

也就是说，AI组件被打包进了更新，但大量用户的电脑根本不会安装它们。

技术上，这些AI模型和语义搜索组件完全可以通过Microsoft Store或按需下载单独分发，与月度累积更新解耦，微软目前尚未这样做。

累积更新机制：体积膨胀的真正根源

Windows 11采用最新累积更新（LCU）模式，每月发布的安全更新会涵盖当月的修复内容以及所有过往的修复，即便你的电脑仅需一个小补丁，更新包依旧包含了能将任何系统升级至该版本所需的全部变更内容。

这种模式从可靠性角度是干净的，安装最新更新即可确保系统完全更新，即使跳过了之前的更新。但副作用是更新包只会越来越大，永远不会缩小。

微软曾在Windows 11 24H2版本中引入检查点累积更新机制，以此尝试解决该问题。其核心思路是通过定期创建新的系统基线，使得后续的月度更新只需包含从上一个检查点之后产生的变更内容，进而达到减小更新体积的目的。

2024年9月设立首个检查点后，到2025年4月的更新体积确实维持在相对较小的水平，但2025年5月的更新体积突然增加了两倍（即变为原来的三倍），从那以后到现在已经过去一年多，却没有再建立新的检查点，微软此前承诺的体积优化效果正在慢慢减弱。

企业端：成本暴涨4倍

对于家庭用户，实际下载量远小于目录包体积，多数人不会注意到4-5GB这个数字，但企业环境没有这种灵活性。

WSUS每个月都会下载完整的累积更新，Configuration Manager会把完整的安装包分发到各个分发点，离线服务工具则将完整的MSU包注入到系统镜像里。不管是哪种场景，都得用到完整包，哪怕单个终端实际只用到其中很小一部分内容。

WindowsLatest测算，每个架构每个分发点的年度更新存储成本已从2024年的约11GB飙升至2026年的52GB，增幅超过4倍。

一个拥有5个分发点的组织，每年每个架构仅更新文件就占用超过250GB磁盘空间，且这还不包括定期清理的节省。

与苹果的对比

macOS增量更新通常在1-3GB范围内，大型版本跳跃才出现更大体积，主要是因为硬件版本远少于Windows。

苹果同样没有固定的月度更新时间表，更新会在准备就绪后发布，在变更打包方式方面具备更大的灵活性；而Windows则更优先考虑兼容性、可预测性，以及在极为庞大的硬件与软件配置组合中的部署能力。

WindowsLatest分析指出，Windows更新体积较大的原因在于其设计初衷是要适配各种配置以及不同的企业使用场景，尽管微软一直在努力压缩更新包的大小，但更新包的体积还是在持续增加。