Ollama本地模型卸载与残留清理：三平台模型仓库、进程和配置全解析

1. 卸载 Ollama 前先搞清：它到底在系统里撒了多少东西

Ollama 本地模型卸载这件事，我见过太多人栽在同一个地方：卸载程序点完、重启，打开磁盘一看，可用空间几乎没变。原因不是卸载失败，而是从一开始就搞错了对象——Ollama 桌面端和命令行工具加起来可能只有几百兆，真正占地方的模型仓库却单独住在另一个目录里，官方卸载入口通常根本不碰它。所以这篇内容我想按“先认账、再动手、最后验证”的顺序讲，把 Windows、macOS、Linux 三个平台上的清理路子都走一遍，包括哪些目录必须删、哪些进程必须先停、哪些残留会在你重装的时候突然跳出来捣乱。

适合谁看？如果你只是想把某个跑不动的模型删掉腾点空间，第 2 章就够了；如果你打算彻底清空重装、或者机器要交接给别人，那第 3 到第 5 章按平台各挑一节照着做；如果你已经删过一轮但发现端口还被占着、磁盘空间没回来，直接跳到第 6 章，那里专门收拾这类“删了个寂寞”的现场。我自己在几台不同配置的机器上反复折腾过这件事，踩过的坑比官方文档里写的多得多，下面尽量把每一步的意图和边界都交代清楚，而不是甩一串命令让你复制粘贴。

1.1 三类残留：程序本体、模型仓库、运行时配置

Ollama 在系统里留下的东西，粗暴点可以分成三堆。程序本体是最显眼的那堆——Windows 上的安装目录和托盘进程、macOS 上的/Applications/Ollama.app、Linux 上的/usr/local/bin/ollama可执行文件和 systemd 单元文件，这些东西在“应用列表”或者包管理器里能看到，卸载器主要处理的就是这一块。模型仓库是真正吃盘的那堆，一个 7B 级别的量化模型大概 4 GB 起，13B 的七八个 GB，更大的模型单个就能顶掉半块盘，它住在用户主目录或者/usr/share底下，跟程序本体完全分离。运行时配置是最隐蔽的那堆：环境变量、日志文件、偏好设置 plist、注册表项、安装脚本自建的ollama系统用户，单个都不大，但它们决定着你重装之后服务会不会起不来、端口会不会冲突。

把这三层分清楚之后，很多看起来莫名其妙的现象就有解释了。比如有人在 Windows 上卸载完发现C:\Users\自己\.ollama还有 60 GB，那不是卸载器偷懒，而是设计上模型数据就归用户自己管；比如有人在 Linux 上删了二进制文件，重启之后systemctl status ollama还能看到服务，那是单元文件还在/etc/systemd/system里躺着。我一般会建议先用十分钟把这三层的实际位置和体积摸清楚，再决定是“轻量清理”还是“连根拔起”，因为这两种操作的风险和步骤差别挺大的，混着做容易把自己坑进去。

1.2 三平台默认路径速查表

不同平台、不同安装方式的路径差异不小，尤其是 Linux 上“服务模式”和“手动运行”两种情况完全不同。下面这张表是我自己整理的默认值，你对着查一遍基本能定位到九成以上的残留。注意表格里的<用户名>要替换成你自己的账户名，%USERPROFILE%这类写法在 Windows 资源管理器地址栏里可以直接用。

这张表里最容易被忽略的是 Linux 那一列的分叉。用官方一键脚本安装的时候，脚本会创建一个叫ollama的系统用户，把模型目录划到/usr/share/ollama/.ollama，然后用 systemd 以这个用户的身份跑服务。这时候你在自己账户下执行ollama list可能什么都看不到，因为两个账户看的是两个不同的模型目录。我一开始也被这个搞懵过，明明刚拉下来的模型，换个终端就“消失”了，后来才反应过来是权限和HOME的问题。

1.3 先量体积再动手，别做无用功

动手之前先量一下体积，这一步能帮你判断到底值不值得折腾。Windows 上在资源管理器里右键属性就行，或者用 PowerShell 跑一段统计；macOS 和 Linux 用du更直接：

# macOS / Linux：看看模型仓库到底多大 du -sh ~/.ollama/models 2>/dev/null du -sh /usr/share/ollama/.ollama/models 2>/dev/null

# Windows PowerShell：统计模型目录大小 $p = "$env:USERPROFILE\.ollama\models" if (Test-Path $p) { "{0:N2} GB" -f ((Get-ChildItem $p -Recurse -File | Measure-Object Length -Sum).Sum / 1GB) }

这两个命令跑完你心里就有数了。如果模型目录只有几百兆，那多半是你压根没用过几个模型，清理的重点应该放在程序本体和残留配置上；如果是几十上百 GB，那模型仓库就是主战场，程序本体反而不重要。我遇到过一位同事，为了腾空间把 Ollama 卸载了三次、重装了三次，最后发现占地方的是一个他早就忘了的 70B 模型，从头到尾就没进过~/.ollama这个目录看一眼。所以别急着敲删除命令，先看清楚账本，这个习惯能省掉很多返工。

2. “卸载了但硬盘没变空”——模型仓库才是真正的大头

这一章讲的是最常见的一种误解：把“卸载应用”和“删除模型”当成同一件事。实际上在 Ollama 的设计里，这两者是完全解耦的，应用可以随时卸掉重装，模型文件原地不动；模型也可以单独删掉，应用照常运行。理解这个解耦关系，你才知道自己在删什么、删完之后会失去什么。

2.1ollama rm和应用卸载是两件事

ollama rm <模型名>是模型层面的删除命令，它只影响模型仓库，不碰程序本体，也不影响服务运行。应用卸载则是程序层面的操作，走的是各平台的常规卸载路径。这两个动作互不替代，很多人只做了其中一个就以为完事了。举个典型场景：你想彻底清空，正确顺序应该是先用ollama list看清楚有哪些模型，逐个ollama rm掉，再卸载应用、再清残留目录。反过来先卸载应用的话，命令行入口没了，你反而失去了用ollama list盘点模型的手段，只能靠手工翻目录，容易漏。

# 先盘点，再逐个删除 ollama list ollama rm llama3:8b ollama rm qwen2:7b

还有一个细节值得说：如果模型正在被加载着（比如你刚跑完一次对话，模型还在显存里热着），某些版本上ollama rm会失败或者表现得很奇怪。稳妥的做法是先ollama ps看一眼有没有活跃模型，有的话用ollama stop <模型名>停掉，再删。这个命令不是所有版本都有，如果你的版本不支持，最简单的办法是把服务停掉再删，反正马上就卸载了，也不差这一步。

2.2 blobs 与 manifests 的分层结构

打开模型目录你会看到两个子目录：blobs和manifests。manifests里存的是一层层的清单文件，记录某个模型标签对应哪些层；blobs里存的是实际的权重数据，文件名是一串哈希值，没有扩展名。这种设计的好处是层去重——两个模型如果共享同一套基础层，磁盘上只存一份。所以你经常能看到“删了一个模型，空间只回收了一半”的情况，那不是没删干净，而是另一个模型还在引用同一批 blob。

这也解释了一个反直觉的现象：手工进blobs目录按大小排序、把最大的几个文件删掉，看起来立竿见影，实际上会把还在用的模型弄坏，因为 manifest 还指着那些哈希。我不建议任何人手工动blobs里面的东西，除非你已经决定整个models目录都不要了。真要精细管理，用ollama rm，让它自己判断哪些 blob 没有引用之后再清理，这样才安全。

2.3 只想瘦身不想卸载的做法

不是所有人都需要彻底卸载。如果你的目标只是“腾出空间但还想继续用”，那完全没必要走完整卸载流程，删几个不常用的模型就够了。我的习惯是保留一到两个日常主力模型，其余全部清掉，需要的时候再拉。判断标准很简单：过去两周没调用过的模型，基本可以删，反正重新拉取的时间成本远小于磁盘一直告急带来的麻烦。

还有一个折中方案是改模型目录的位置。通过环境变量OLLAMA_MODELS可以把模型仓库指到大容量磁盘上，系统盘就能空出来。这个做法在 Windows 上特别实用，因为很多人系统盘是固态但容量小，仓库盘是机械但容量大。具体怎么设，Windows 在系统属性里的用户环境变量加一条，macOS 和 Linux 在 shell 配置文件里export OLLAMA_MODELS=/your/path，然后重启服务生效。注意改之前先停服务、把旧目录整体搬过去，直接改环境变量而不搬数据的话，服务会以为你一个模型都没有。

3. Windows：从托盘图标到注册表项的逐层清理

Windows 上的清理体验是最碎的一个平台，因为它没有 systemd 那种统一的服务管理，进程、安装目录、用户数据、注册表项分散在四个地方。但好处是每一步都比较直观，照着做不容易出错。下面按“停进程 → 走卸载 → 清残留”的顺序来。

3.1 先停进程，否则第一步就卡住

Ollama 在 Windows 上通常有两个进程：一个是后台服务ollama.exe，负责监听 11434 端口；一个是托盘界面ollama app.exe。只要服务在跑，%USERPROFILE%\.ollama目录下的某些文件就会被句柄占用，你删除的时候会弹“文件正在使用中”。所以第一步永远是停进程，而不是直接去删目录。

最稳的方式是走托盘图标右键退出，这样两个进程都会优雅关闭。如果托盘图标已经找不到了（比如你之前手贱删了安装目录但进程还在），那就用任务管理器，在“详细信息”标签页里找ollama.exe和ollama app.exe，右键结束任务。命令行党可以用：

Get-Process ollama, "ollama app" -ErrorAction SilentlyContinue | Stop-Process -Force

停完之后验证一下端口有没有释放：

netstat -ano | findstr :11434

如果还有输出，说明有别的进程占着这个端口，或者服务被注册成了开机自启又被拉起来了。这种情况下先看一下任务计划程序里有没有 Ollama 相关的条目，有的话禁用掉再继续。

3.2 走正规卸载流程与它的盲区

正规卸载走“设置 → 应用 → 已安装的应用”，找到 Ollama 点卸载；或者直接在开始菜单里找卸载快捷方式。这一步会删掉%LOCALAPPDATA%\Programs\Ollama下的程序文件、清理掉大部分注册表卸载项，速度很快，通常十几秒就完事。

但它的盲区非常明确：不会碰%USERPROFILE%\.ollama。这个目录里装着模型仓库、SSH 密钥、日志，卸载器一概不管。所以走完正规流程之后，磁盘空间大概率一点没变，这不是失败，这是设计如此。另外有些版本会在%LOCALAPPDATA%\Ollama下留日志文件，也不会被清掉。我见过有人卸载完发现“已安装的应用”列表里 Ollama 消失了，就以为大功告成，结果半年后重装，打开一看模型全在，还占着几十 GB。

3.3 手工清残留：目录、环境变量、注册表

正规卸载之后，剩下的活就是手工收尾。按下面的顺序来，每一步做完再进下一步，出问题好定位。

第一步删模型和配置目录。先确认没有 Ollama 进程在跑，然后直接删整个.ollama文件夹：

Remove-Item -Recurse -Force "$env:USERPROFILE\.ollama" Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Ollama" -ErrorAction SilentlyContinue

第二步检查环境变量。如果你之前设过OLLAMA_MODELS、OLLAMA_HOST、OLLAMA_KEEP_ALIVE这类变量，卸载程序一般不会帮你清。这些变量留着本身不占空间，但会在你重装之后立刻生效，导致新装的服务指向一个已经不存在的模型目录，表现出来就是“装好了但一个模型都没有”。在“系统属性 → 高级 → 环境变量”里，把用户变量和系统变量里所有OLLAMA_开头的条目都删掉。

第三步看注册表。正常卸载会清掉HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Ollama，但偶尔会有残留。按 Win+R 输入regedit，定位到这个路径看一眼，有就删。只删这一个键，不要顺手去清别的 Ollama 相关项，注册表这东西误删的代价太大，收益却很小。

4. macOS：应用图标拖进废纸篓只是开始

macOS 上卸载 Ollama 看起来最简单——打开访达，把 Ollama 从应用程序里拖到废纸篓，清空。但这么做只删掉了 app 包本体，命令行工具、模型仓库、登录项、偏好设置全都还在。如果你之后打算重装，会发现菜单栏图标回来了、模型也还在，好像从来没卸载过。

4.1/Applications之外的三处藏身处

除了/Applications/Ollama.app，还有三个地方需要检查。第一处是~/.ollama，模型仓库和密钥都在这里，这是占用空间最大的部分，删掉它才算真正腾出空间。第二处是~/Library下的偏好设置和保存状态，路径大致是~/Library/Preferences/com.electron.ollama.plist和~/Library/Saved Application State/com.electron.ollama.savedState，名字里带 electron 是因为桌面端是 Electron 打包的，不同版本前缀可能略有差异，用ls ~/Library/Preferences | grep -i ollama找一下更靠谱。

第三处是命令行二进制。用 app 安装的时候，通常会在/usr/local/bin/ollama放一个软链接或者实际的可执行文件。你把这个文件删掉，终端里的ollama命令才会真正失效。如果只删 app 不删这个，终端里敲ollama还能用，容易让人误以为没卸载干净，其实是两套东西没打通。

# 逐项确认再删除 ls -lh /usr/local/bin/ollama ls -d ~/.ollama ls ~/Library/Preferences | grep -i ollama

4.2 CLI 二进制与登录项的处理

登录项这一块经常被漏掉。Ollama 桌面端默认会把自己加进登录项，开机自动启动、常驻菜单栏。如果你只是把 app 拖进废纸篓，登录项里那条记录可能还在，下次开机系统会尝试启动一个已经不存在的程序，虽然不会报错，但会在系统日志里留下噪音。清理方式是在“系统设置 → 通用 → 登录项”里找到 Ollama 移除掉。

命令行二进制的删除要稍微谨慎一点，因为/usr/local/bin是共用目录，别手滑删错东西。先ls -l /usr/local/bin/ollama看一眼它到底是个软链接还是实体文件，如果是软链接指向 app 包内部，那 app 删掉之后它就是个断链，直接删掉没影响；如果是独立安装的实体文件，那说明你之前可能用别的方式装过，删之前想清楚还有没有别的东西依赖它。我一般会先mv到一个临时目录观察几天，确认没问题再彻底删，这个习惯救过我两次。

4.3 验证端口与进程是否干净

macOS 上验证是否清理干净，主要看三件事：进程、端口、路径。进程用pgrep -fl ollama，端口用lsof -i :11434，路径就是把前面提到的几个目录挨个ls一遍，确认都不存在了。三个检查都通过，基本可以认为清理完成。

pgrep -fl ollama lsof -nP -i :11434

有一点要注意：macOS 的lsof有时候会因为你没有权限而看不到某些进程的端口占用，加sudo再看一次更保险。如果端口还被占着但pgrep找不到进程，那多半是别的程序碰巧用了 11434，这种情况就别硬删了，先确认清楚是谁在用。

5. Linux：systemd 服务、ollama 用户与/usr/share的连带清理

Linux 上的情况最复杂，因为官方安装脚本做的事情比另外两个平台多得多：它不只是解压一个二进制文件，而是创建系统用户、建目录、写 systemd 单元、启动服务，一整套下来改动面挺大。所以卸载也得反过来一步步拆，顺序错了会遇到各种“删不掉”“删了又回来”的情况。

5.1 停服务、禁自启、删单元文件

第一步永远是停服务并禁止开机自启，否则你删了单元文件，systemd 下次开机还会从缓存里找它，或者在你daemon-reload之前继续认为服务存在。

sudo systemctl stop ollama sudo systemctl disable ollama sudo systemctl status ollama # 确认已经 inactive

确认停掉之后再删单元文件，然后让 systemd 重新加载配置：

sudo rm /etc/systemd/system/ollama.service sudo systemctl daemon-reload sudo systemctl reset-failed

reset-failed这一步很多人会漏。当你手动删掉一个服务的单元文件之后，systemd 内部可能还留着这个服务的失败状态记录，导致你后面执行某些操作时看到莫名其妙的报错。跑一下这个命令清掉状态，后面会干净很多。

5.2 模型目录的归属问题：服务用户与当前用户的区别

Linux 上最容易踩的坑就是这个：模型到底存在哪，取决于你用哪种方式跑的 Ollama。官方脚本装的服务模式下，模型在/usr/share/ollama/.ollama/models，属主是系统用户ollama；如果你是自己下载二进制手动ollama serve跑的，模型在~/.ollama/models，属主是你自己。两个目录可能同时存在，两个都可能有好几 GB。

所以清理之前先两个都查一遍，别只删了一个就以为完事：

sudo du -sh /usr/share/ollama/.ollama 2>/dev/null du -sh ~/.ollama 2>/dev/null

查清楚之后，服务目录整个删掉。注意/usr/share/ollama这个目录是安装脚本创建的，专门给服务用，整体删除没有副作用。但如果你的机器上有别的服务也用这个路径下的东西（可能性很低），删之前扫一眼里面有没有非.ollama的内容。

sudo rm -rf /usr/share/ollama rm -rf ~/.ollama

5.3 收尾：用户、用户组、二进制与环境变量

二进制文件的位置取决于是脚本安装还是手动安装，脚本安装一般在/usr/local/bin/ollama。删之前先which ollama确认路径，别直接用rm $(which ollama)这种写法——万一which返回空，命令就变成rm后面啥也没有，运气不好会报参数错误，运气更不好的话在某些 shell 下行为很怪。老老实实两步走：

which ollama sudo rm /usr/local/bin/ollama

然后是系统用户和用户组。安装脚本创建的ollama用户如果不清掉，会一直留在/etc/passwd里，虽然不影响使用，但机器交接或者做安全审计的时候会显得很脏。删之前确认没有别的进程以这个身份在跑：

sudo pkill -u ollama sudo userdel ollama sudo groupdel ollama

如果你之前在~/.bashrc、~/.zshrc或者/etc/environment里写过OLLAMA_HOST、OLLAMA_MODELS这类变量，也要一并清掉。这一步经常被忽略，后果是重装之后新服务读到了旧配置，指向一个空目录，然后你对着ollama list一片空白发呆。

6. 删完之后：怎么确认真的干净了

清理动作做完不等于事情结束，还得验证。我见过太多“以为删干净了，结果重装之后各种诡异”的案例，绝大多数都能通过一套固定检查流程提前发现。这一章讲三件事：怎么验、空间为什么没回来、重装前还要注意什么。

6.1 端口、进程、路径三项检查

验证的核心就三项，三平台通用：端口没被占、进程没在跑、路径不存在。端口看 11434，进程看进程名里有没有 ollama，路径就是前面表格里列的那几个目录挨个确认。三项全过，基本可以认定清理完成。

最后一行那个 systemd 检查值得单独说一句。systemctl list-unit-files | grep ollama如果还有输出，说明单元文件没删干净，或者被放到了别的目录（比如/lib/systemd/system而不是/etc/systemd/system）。不同发行版的默认路径不一样，systemctl cat ollama能看到它实际加载的是哪个文件，顺着路径删就对了。

6.2 磁盘空间没回来的几种真实原因

删完之后空间没变，是最让人抓狂的情况。我总结下来大概有四种原因，按出现频率排。

第一种，进程还在跑，文件句柄没释放。Linux 上删掉一个正在被打开的大文件，目录项没了但磁盘块还占着，直到进程退出才真正回收。用lsof +L1能看到这类“已删除但仍被占用”的文件。解决办法就是找到进程杀掉，或者重启。Windows 上类似，被占用的文件删不掉会直接报错，反而好判断。

第二种，你删的根本不是那个占空间的目录。这是最典型的：以为模型在~/.ollama，实际在/usr/share/ollama，或者反过来。回到第 1 章那张表，两个路径都用du -sh量一遍，别靠猜。

第三种，回收站没清空。macOS 上把 app 拖进废纸篓之后不清空，空间是不会释放的，这个太基础但确实有人忘。Windows 上如果你不是用 Shift+Delete 删的目录，它也会进回收站。

第四种，blob 层被其他模型共享。前面讲过，层去重机制下删一个模型可能只回收一部分空间，因为另一个模型还引用着同样的层。这种情况用ollama list看看还剩几个模型就明白了，把剩下的也删掉，空间才会全部回来。

6.3 重装前的注意事项

如果你清理完是要重装，有几件事值得提前想清楚。第一，确认旧的环境变量真的清干净了，尤其是OLLAMA_MODELS，它会让新装的服务跑去找一个不存在的目录，然后你就看着空空的模型列表怀疑人生。第二，确认旧的服务用户已经删掉，Linux 上如果ollama用户还在但密码文件里记录的 home 目录已经不存在，重装脚本可能会跳创建步骤，导致权限不对。第三，想清楚模型要不要重新拉，如果你只是卸载程序但保留了模型目录，重装之后模型是可以直接用的，前提是新版本兼容旧的目录结构。

我自己的习惯是重装前先建一个空的测试目录，把OLLAMA_MODELS指过去跑一次ollama list，确认新装的服务能正常起来、能正常拉模型，再把旧模型目录搬回来。这样万一新版目录结构变了，你能第一时间发现，而不是等到几十 GB 搬完才报错。多花十分钟，省掉的可能是一下午。

最后分享一个我一直在用的小技巧：清理之前先跑一遍ollama list输出存成文本，删完之后对照一下，哪些模型是被ollama rm正常删掉的、哪些是手工删目录删掉的，一目了然。这个记录在你事后想复现某个模型配置的时候特别有用，毕竟重新拉一个 70B 模型的等待时间，可比写一行笔记长太多了。