在 Windows 上将 Ollama 模型迁移到另一块磁盘

开发者清理发布于 2026 年 10 月 22 日更新于 2026 年 10 月 25 日约 7 分钟

要将 Ollama 下载的模型移出 C 盘，为运行 Ollama 的账户配置 OLLAMA_MODELS。移动应用本身是另一项操作。仅更改变量不会复制现有模型，因此保留旧存储，直到新存储验证通过。

本指南适用于普通的 Windows 桌面安装。服务、容器或 WSL 安装可能在不同账户或配置下运行，需要按实际运行账户和配置处理。

复制前先确认当前存储位置

Ollama 的 Windows 文档区分了应用程序文件、日志和模型数据。默认模型存储位于 %USERPROFILE%\.ollama\models 下。之前的 OLLAMA_MODELS 设置可能指向其他位置。

在新打开的 PowerShell 窗口中，检查用户级设置：

[Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")
ollama list

设置为空表示没有用户级覆盖，但不能据此断定服务或其他账户也使用默认位置。记录模型列表并检查此安装使用的文件夹。存储中包含 blobs 和 manifests；保留它们的相对结构，而不是只复制最大的文件。

先确认源目录和目标层级

复制前，先确认目标位置的可用空间和确切的源路径。以前设置过的用户环境变量、不同的 Windows 账户或第二个 Ollama 安装都可能让默认路径产生误导。记录现有变量的值，包括它原本是否不存在，这样回滚时才能恢复原始状态。

在目标位置，blobs 和 manifests 应当直接位于 OLLAMA_MODELS 所指定的文件夹内。如果变量指向 D:\AI\Ollama\models，预期的子项是 D:\AI\Ollama\models\blobs 和 D:\AI\Ollama\models\manifests。意外多出一层 models 是常见的配置错误，在重新下载任何内容前要先排除这一点。

为这次迁移使用一个专用的空目标位置。不要合并到无关的存储中，也不要以为文件名匹配就能证明内容可以互换。要为完整副本和后续使用留出足够空间；更改变量并不会让两份副本只占用一份的空间。

先复制，再切换应用

选择一个有足够可用空间且将持续可用的本地盘。例如，如果该盘存在且你的账户有写入权限，D:\AI\Ollama\models 可以作为目标。如果模型放在外接磁盘上，拔掉磁盘后就无法读取模型，授予应用管理员权限也解决不了这个问题。

完成正在进行的生成和下载，然后从系统托盘菜单退出 Ollama。
使用文件资源管理器将当前模型存储的内容复制到所选目标。保持原件完整，并在继续前解决任何复制错误。
从 Windows 搜索中打开 编辑账户的环境变量。
创建或编辑 OLLAMA_MODELS，将其设置为目标路径，然后保存。
从“开始”菜单重新启动 Ollama，并打开一个新的终端。

Ollama 的环境变量说明解释了为什么应用必须重启才能继承更改。之前打开的终端可能保留旧环境。不要在托盘应用仍在运行时仅为测试变量而创建第二个服务器。

模型文件较多时，可以用 Robocopy

如果文件资源管理器的复制能顺利完成，用它就足够了。如果文件很多，又需要留下复制日志，Windows 自带 Robocopy。下面的 PowerShell 示例假定已验证的源是默认存储，目标是新建的专用文件夹。如果安装情况不同，请替换两个路径，并在复制前退出 Ollama。

$source = "$env:USERPROFILE\.ollama\models"
$destination = "D:\AI\Ollama\models"
robocopy "$source" "$destination" /E /L /R:1 /W:1

/L 会列出计划执行的工作而不进行复制。查看输出顶部的源和目标。如果它们正确，去掉 /L 运行复制，并把日志保存在模型存储之外：

robocopy "$source" "$destination" /E /R:1 /W:1 /TEE /LOG:"$env:TEMP\ollama-model-copy.log"
$copyExitCode = $LASTEXITCODE
$copyExitCode

/E 包含子目录，而重试选项限制了失败文件的重试次数。此示例有意不镜像或移动源。不要添加 /MIR、/PURGE 或 /MOVE：保留回滚副本不需要它们的删除行为。

Robocopy 对某些非失败结果使用非零代码。代码为 8 或更大表示至少有一个复制失败。即使低于 8，也要检查摘要以及任何不匹配或多余的文件，尤其是目标位置原本不为空时。在更改变量前解决错误；模型列表成功并不能让失败的文件复制变得完整。

先验证新位置，再删除旧文件

再次运行 ollama list，并与记录的列表比较。选择一个已显示的模型，使用其确切名称发出一个小请求。如果模型缺失，停止并检查文件夹结构和设置，而不是让新的下载掩盖迁移失败。

在测试期间检查目标位置，并验证应用正在使用预期的存储。在重要工作负载成功且任何本地创建的模型已备份之前，保留旧目录。目录大小相同还不够，要实际运行需要的模型。

如果切换失败，退出 Ollama，恢复之前的变量值或移除新添加的覆盖，然后重启。未受影响的原始存储使这种恢复变得简单。

复制后还要验证模型能否使用

正在运行的服务器可能保留旧环境或已加载的模型。完成当前工作，退出托盘应用，在设置新路径后重新启动它，然后打开一个新的终端。在要求任何模型运行前，将 ollama list 与保存的清单进行比较。如果缺少必需的条目，先检查路径和 manifests 结构。

对于每个重要的本地创建的模型，在这次重新启动后测试一个小请求。只测试一个常见的下载模型不能证明自定义模型也迁移成功。确认需要的模型和日常任务都正常前，保留原目录。

如果仍不清楚服务器使用哪个目录，在 %LOCALAPPDATA%\Ollama 中围绕启动和加载检查当前的 server.log，使用官方故障排查位置。将任何报告的配置路径与预期的目标位置进行对比。仅在新打开的终端中看到的路径只描述该终端，不能证明另一个已在运行的服务器的情况。

不要为了让空目录出现模型就重新下载。这可能掩盖失败的迁移，并在 C 盘上消耗更多空间。如果证据不明确，保留两份模型文件，并在删除原目录前解决配置问题。回滚时，退出应用，恢复记录的变量，如果原本没有覆盖设置则移除新的覆盖设置，然后重新启动并验证原始模型列表。

仅删除已验证的旧模型存储

验证后，在通过文件资源管理器删除之前，检查旧的 models 目录。不要删除整个 .ollama 目录，因为它可能包含配置和其他状态。Windows 可能会永久删除太大而无法放入回收站的文件，因此阅读确认信息并保留你需要的任何备份。

移动模型文件不会释放当前模型占用的内存，也不保证生成更快。较慢的目标位置可能会使初始加载耗时更长。如果问题是内存而非 C 盘容量，检查工作负载和 Windows 内存指南。

对于其他 AI 下载，Hugging Face 有它自己的缓存配置。分别修改每个工具的存储设置，不要直接移动它们共用的父目录，以为所有应用都会自动找到新位置。