Ollama v0.40.9-rc0：WoA 支持切换至正式版 CUDA 工具包

Ollama 发布了 v0.40.9-rc0 预发布版本，核心变更只有一条——CI 流水线从预发布版 CUDA Toolkit 切换到已正式发布的版本，以支撑 Windows on Arm（WoA）平台。提交信息（#19185）由 dhiltgen 于 10 月 21 日打上标签，并附带了 GitHub 验证签名。

变更内容：一次“去预发布化”的 CI 调整

从提交说明看，这次改动的动机相当直接：团队此前仍在 WoA 构建中使用预发布版本的 CUDA Toolkit，而下载站点不稳定（flaky），导致 CI 构建的可靠性受影响。作者的原话是“We were still using a pre-release, and the download site is flaky, so lets get current on the latest CUDA Toolkit for WoA support.”

换句话说，这不是一次功能新增，而是一次基础设施层面的“对齐”——把依赖从不确定的预发布通道挪到正式发布通道。对于每天要跑大量构建的 CI 系统来说，依赖源的稳定性往往比版本新旧更关键。

CI（持续集成）流水线指的是代码提交后自动触发构建、测试与打包的自动化系统。对 Ollama 这类需要为多个平台（Windows、Linux、macOS，以及 x86 与 Arm 等架构）产出二进制的项目而言，CI 每次运行都要拉取编译器、CUDA Toolkit、驱动等外部依赖。这些依赖通常从厂商的下载站点获取，一旦站点限流、路径变更或临时不可用，构建就会失败。因此 CI 的可靠性高度依赖外部依赖源的稳定性，团队往往会优先选择正式发布通道而非预发布通道。

为什么 WoA 的 CUDA 支持值得单独发一个 RC

Windows on Arm 在本地 AI 推理场景中的存在感正在上升，但它的软件栈成熟度长期落后于 x86 + NVIDIA 的组合。CUDA Toolkit 在 WoA 上的可用版本、下载渠道和发布节奏，都会直接影响推理框架能否稳定地产出可用的二进制包。

把 CI 切换到正式发布的 CTK，意味着后续 WoA 构建可以依赖一个有版本承诺、下载链路相对稳定的工具链。对下游用户而言，这减少的是“构建失败但原因不明”的隐性成本；对维护者而言，则是把一类偶发故障从流水线中移除。

CUDA Toolkit（CTK）是 NVIDIA 提供的 GPU 计算开发套件，包含编译器（nvcc）、运行时库、性能分析工具与数学库等组件。在 Ollama 的语境中，它决定了项目能否编译出启用 GPU 加速的二进制包。CTK 的版本发布分为预发布（pre-release，如 alpha/beta/rc）与正式发布（GA）两类，前者行为可能随时调整、下载地址也未必长期稳定。Windows on Arm 长期以来并非 CUDA 的一等公民，其对应 CTK 的可用版本和分发节奏都晚于 x86，因此 WoA 构建对工具链版本的选择尤为敏感。

预发布依赖的风险模式

预发布版本的工具链通常有两个问题：一是下载站点可能随时调整路径或限流，二是行为可能在正式发布前发生变化。CI 对这种不确定性尤其敏感——一次下载失败就可能让整个版本的构建红灯，而排查成本往往被低估。

这次提交没有引入新特性，也没有修改运行时逻辑，价值集中在“让构建可重复”。从工程实践角度看，这类改动通常不会出现在 release notes 的显眼位置，但对发布节奏的稳定性有实际贡献。

“让构建可重复”（reproducible build）是软件工程中的一项基本要求：在相同源码与相同依赖版本下，任意时间、任意机器上都应产出行为一致的构建结果。预发布依赖会破坏这一性质——即使源码未变，工具链行为或下载可用性的变化也可能导致构建结果不同。将依赖固定到正式发布版本，本质上是在缩小构建环境中的变量，使失败更容易归因，也让发布节奏更可预测。Ollama 用 rc 版本发布这一改动，说明维护者认为它对下游构建的影响足以单独走一次候选发布流程。

版本定位与后续观察

v0.40.9-rc0 是候选发布版本，标签页面列出了两个资产，说明它已经进入可分发状态。由于变更仅涉及 CI 配置，普通用户在日常使用中不会感知到差异；真正的影响会体现在后续 WoA 相关构建的失败率上。

值得关注的后续信号包括：正式版 v0.40.9 是否沿用同一 CTK 版本、WoA 构建产物是否出现在常规发布渠道，以及下载站点不稳定的问题是否在其他平台的 CI 中同样存在。如果后者成立，类似的“去预发布化”调整可能还会出现在更多构建环节。