ollama怎么删除本地模型

磁盘告急、想腾空间的时候，很多人只会在 Ollama 里敲一句删除命令，结果发现盘还是满的、列表里还挂着、显存也没释放。这篇不聊该不该本地跑模型，只讲一件事：怎么把不要的模型彻底清干净，同时别把还要用的那个删了。

磁盘告急、想腾空间的时候，很多人只会在 Ollama 里敲一句删除命令，结果发现盘还是满的、列表里还挂着、显存也没释放。这篇不聊该不该本地跑模型，只讲一件事：怎么把不要的模型彻底清干净，同时别把还要用的那个删了。

删除这件事看着简单，坑都藏在细节里：同名不同标签的两个条目、换过存储路径之后的新旧两份权重、删了文件但服务还在跑着占显存、共享机器上别人还在用。下面按动手顺序拆开讲，每一步都给出可以立刻验证的动作。

动手删之前，先把三件事确认清楚

上来就敲命令是最容易出事的做法。先花两分钟弄清你面对的是哪一类模型，很多「删不掉」「删了没用」的问题，根子都在这一步没分清。

• 先分清你要删的是哪一类：命令行拉下来的模型、自己用 Modelfile 建的衍生模型、还是从别处导入的 GGUF 文件，三类清理方式不一样
• 用列表命令把当前本地模型过一遍，注意名字里的仓库前缀和标签后缀，同一系列不同标签就是两个独立条目，删错一个就得重新下载
• 看一眼模型存储目录还剩多少空间，确认目标是腾容量还是单纯觉得列表乱，两种情况处理顺序不同

删除命令怎么写，以及它到底删了什么

删除子命令的写法本身不复杂，关键是模型名要写得和列表里显示的一致。很多人的习惯是只写一个短名字，结果要么报「找不到」，要么删掉了名字相近的另一个。写全名、带标签，是最省事的做法。

1. 确认名字先跑一次列表命令，把要删的那一条名字原样复制出来，不要凭记忆敲。
2. 确认没被引用检查有没有正在跑的对话界面、本地知识库或编程助手插件挂着它，占用的先停掉。
3. 执行删除用删除子命令加完整模型名执行。是否支持一次删多个、标签能不能省略，按你自己版本的输出行为来确认，别照抄别人的命令。
4. 立刻复核删完马上再跑一次列表，看到那条确实不在了再继续下一步，别一次删一批。

要记住的是，这个操作没有回收站。本地删掉之后，模型文件就没了，想再用只能重新拉一遍整个权重。所以对「只是想临时挪个地方、之后还要用」的情况，删除是错误的选择，正确做法是去改模型存储路径的环境变量，把目录整体挪到大盘上。

# 看当前有哪些模型
# ollama list

# 删除指定模型（名字用列表里显示的原样写法）
# ollama rm <模型名>:<标签>

# 删完立刻复核
# ollama list

命令报错、删不掉时按这个顺序排查

删除失败的报错信息往往很短，光看那一行猜不出来。按下面这个顺序走一遍，基本能定位到具体原因，不要一上来就重装。

还有一个容易忽略的情况：你在图形界面或插件里点的「移除」，有时候只是从那个界面的列表里摘掉，并没有真正调用删除命令。遇到「界面里没了、命令行列表里还有」，回到终端再删一次就能对上。

删完之后盘还是满的，残留在哪

命令行删除清掉的是模型登记和权重文件，但日志、缓存、导入过程中的临时文件、Modelfile 记录可能都还在。这些文件加起来不一定小，尤其是在反复拉取、导入过的机器上。

• 先查存储路径的环境变量指向哪里，换过路径的机器最常见的情况是新旧两处各留了一份
• 到那个目录下按修改时间和体积排序，看还剩什么大文件，别只盯着模型权重那一类
• Windows、Linux、macOS 的默认位置和迁移方式各不相同，跨系统照抄路径基本会扑空

如果你是导入的 GGUF，要注意原始文件很可能就不在模型存储目录里，而是你当初放它的地方。删掉 Ollama 里的条目，那个文件会原样躺在磁盘上。清理的时候把这两处都过一遍，才算真的腾出空间。

磁盘清了，显存和内存为什么没跟着放

模型文件从磁盘删掉，不等于它已经从显存里卸载。已经加载起来的实例会继续占着，直到你显式停掉对应进程或重启服务。很多人看到任务管理器里显存还满着，就以为删除没生效，其实是两回事。

验证方法是分开看：文件层面用列表命令确认条目确实没了，运行层面去系统里看显存和内存占用，再看服务的当前运行状态。两边都干净了，才算这一步收工。

至于常驻内存和用完卸载之间的取舍，那是另一个话题，跟删除命令没有关系。想调这块的策略，可以到 /tools/speed-test 里看当时的实测数据，再决定要不要让模型常驻。

什么情况下不该删，而是该迁移或换策略

有一种情况删了最亏：模型还要用，只是系统盘快满了。这时候删掉再重新拉一遍，等于用一次完整下载换几天的空间，纯属绕远路。正确动作是把模型存储目录改到大容量盘，然后做一次迁移，把已有文件搬过去。

多人共用一台机器时，删之前一定要跟其他人对齐。别人第二天打开对话界面发现模型没了，排查起来会花很久，而且很难想到是被清理掉的。团队里最好约定一个清理窗口，把要删的清单提前发出来。

• 模型还要用、只是盘告急：改存储路径加迁移，不要删
• 多人共用的机器：先同步清单，确认无人依赖后再动手
• 不确定谁在用：宁可先停服务观察几天，也不要直接删
• 只是想复现一套干净环境：把当前清单记录留档，再按单条删除

一份可以照着做的清理清单

把前面几节的动作串成一条流程，照着走一遍就行。核心原则是「一次只动一个、每步都验证」，这样出问题时能立刻定位到是哪一步的事。

1. 列清单跑列表命令，把要处理的名字原样记下来，同时记下模型存储目录的位置和剩余容量。
2. 区分删和迁还要用的走迁移，确定不要的才进删除流程，两类分开处理，别混在一起做。
3. 停掉引用关掉对话界面、知识库、编辑器插件里挂着该模型的任务，必要时重启服务。
4. 执行删除按完整模型名删单个条目，删完立刻用列表命令复核。
5. 查残留到存储目录看还剩什么，重点盯旧路径、导入的原始文件和日志缓存。
6. 确认显存看系统显存和内存占用，确认已释放，再回到磁盘容量和应用可用性两个指标上验收。

如果你在纠结「这台机器上到底该留哪些模型」，不要只看名字和体积，去 /rankings 核对当时的对比数据；如果你更关心各家接口的价格变化，可以到 /price-watch 看追踪记录，判断把哪些负载放在本地、哪些走接口更划算。