把 CUDA Toolkit 13.4 装在 Windows on Arm

这次 13.4 版本最实用的变动就是终于给 Windows on Arm 提供了原生支持，之前在 Arm 架构的 Windows 设备上跑 CUDA 基本上得靠 Linux 子系统（WSL2）中转，现在可以直接在宿主机上开发了。如果你手里有类似 Snapdragon X Elite 这种芯片的笔记本，或者在折腾 Arm 版本的 Windows Server，这个更新能省掉不少配置环境的时间。

在 Windows on Arm 上部署 CUDA 13.4 怎么操作

这次更新把原本在 Linux Arm 平台跑通的 CUDA 能力搬到了 Windows 上。实际操作时，你不能直接用之前的 x64 安装包，必须去 NVIDIA 官网下载专门标注为 Arm64 的 13.4 版本安装程序。

安装过程中的关键点：
1. 驱动匹配：必须先升级到最新的 Arm 架构显卡驱动，否则安装包在检测环境时会直接报错 NVIDIA Installer cannot continue。
2. 环境变量：安装完后，检查 CUDA_PATH 是否指向了 C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.4。如果路径里出现了 x86_64 字样，说明你装错版本了。
3. 验证命令：打开 PowerShell，运行 nvcc --version。如果输出显示 release 13.4, V13.4.xxx 且没有弹出兼容性警告，才算真正跑通。

共享 GPU 控制权在实际开发中有什么用

除了 Arm 支持，13.4 增强了对共享 GPU 的控制。在公司环境下，这其实解决了个很头疼的问题：多人共用一台高性能工作站时，显存被某个同事的僵尸进程占满，导致其他人跑不起来。

以前我们只能用 nvidia-smi 强杀进程，现在可以通过更细粒度的控制来限制单个任务的资源占用。虽然具体到 API 层面需要结合驱动设置，但在实际开发中，这意味着我们可以给不同的模型推理任务划分「硬隔离」的显存区间，避免因为 OOM（Out of Memory）导致整个服务崩溃。

避坑指南和实际体感

虽然原生支持了，但目前在 Windows on Arm 上跑 CUDA 依然有几个潜在问题：

• 库兼容性：虽然 Toolkit 升级了，但很多第三方 Python 库（比如某些旧版本的 PyTorch 插件）可能还没更新 Arm64 的二进制包。如果你在 pip install 时遇到 no matching distribution found，大概率还是得回退到 WSL2 方案。
• 耗时与成本：在 Arm 笔记本上编译一个小规模的 CUDA Kernel，速度比在 x86 机器上慢大约 15%-20%，这主要是编译器在 Arm 架构下的优化还不到位。
• 性能波动：在低功耗模式下，GPU 的调用频率不稳定，建议在进行性能基准测试时，务必把 Windows 电源模式调到「最佳性能」。

如果你的工作流极度依赖原生 Windows 环境（比如要调用特定的 Windows API），那么 13.4 的 Arm 支持是救星；但如果你只是想跑个 Stable Diffusion 或 Llama 3，目前 WSL2 依然是最稳的选择，因为生态链的迁移需要时间，不能指望一个 Toolkit 版本就解决所有依赖问题。