- 近两年，Windows 11 的月度累积更新体积正快速上涨。最新数据显示，更新目录中的累积更新常规包已频繁超过4GB，甚至在部分情况下接近5GB；解压后的体积可能接近9GB。更关键的是，实际设备下载量往往远低于目录标注，但对企业端的存储、分发和运维成本影响极大。本文将梳理更新体积膨胀的根本原因、AI 组件对更新的贡献、以及企业与普通用户的应对策略。

1) 现象与趋势概览

- 现象描述：从 2024 年中期到 2026 年，Windows 11 更新体积经历了显著增长，2025 年 5 月的累积更新解压后体积接近9GB，目录包却约4GB；实际下载量通常远小于目录显示，因为更新在传递优化、快速更新等机制作用下只拉取实际需要的差量内容。

- 趋势要点：2024 年的更新体积多在 300MB 左右，到了 2026 年已跃升至 5GB 的区间，增长速度远超初期预期。

- 背景暗示：AI 相关组件的打包（语义搜索、Onyx 运行时、设备端推理等）是重要原因之一，但并非全部。

2) 为什么体积会持续增大？核心机制解析

- 更新模型与打包方式：

- 过去的“小型独立补丁”逐步被替换为累积更新（LCU），每月的更新包包含自上次基线以来的所有变更，导致包体积变大。

- 微软曾尝试通过“检查点累积更新”设定新基线，后续仅打包自该基线以来的变更；该策略在理论上应减小下载量，但在实际运行中，随着新的组件与变体加入，体积膨胀趋势并未根本扭转。

- AI 与组件叠加：语义搜索、AI 运行时、浏览器相关子系统等以 MSIX 载荷形式被合并进更新包，即使终端用户并不使用这些功能，更新包中仍包含相应组件。

- 企业分发角度的影响：WSUS、Configuration Manager、分发点等都需要存储、分发同一完整安装包，哪怕终端只需要其中极少一部分，企业端的存储与带宽成本被放大。

3) 具体数据与关键点

- 目录大小与实际下载：4GB 目录包在实际设备下载时常为1.5–2GB，原因在于动态适配与差量传输。

- 解压后的体积：5月更新解压后近9GB，包含大量新的 MSIX 有效载荷（如 PSTokenizer、文字识别会话、Onyx 运行时等）。

- 文件数量与结构：单次更新包内包含数万文件（如数万项文件、MSIX 有效载荷等），其中 msedge.dll 等仍然是体积大头。

- 企业存储成本的变化：自 2024 年中期以来，企业层面的年度存储成本从约 11GB 增加到 52GB，若有多个分发点，年度总量和月度更新数据将呈现倍数级增长。

4) AI 组件到底在那里？如何影响更新

- 機制洞察：AI 相关的语义搜索、设备端运行时等组件在更新包中被打包，尽管部分设备不需要这些功能，仍会被拉取或在安装时解压加载。

- 可选性与分发：从技术角度讲，AI 组件理论上应可通过可选下载或按需分发来降低实际下载量，但当前更新流程仍以主更新包为主线，使得总体体积偏大。

5) 实际如何查看“真实下载量”

- 查看路径：设置 > Windows 更新 > 高级选项 > 传递优化 > 活动监视器，可以看到实际从微软服务器和同侪节点下载的数据量。

- 日志与排错：事件查看器中的 Windows 更新日志，可通过 PowerShell 运行 Get-WindowsUpdateLog 生成更易读的日志文件，帮助判断实际下载量与目录显示的差异。

- 小结：AI 相关组件、打包策略、分发架构共同作用，导致更新包体积不断增大；企业成本与存储压力随之上升，家庭用户的实际下载量可能远低于目录数字，但仍需关注长期趋势。