ollama 卸载 deepseek-r1

磁盘告警、模型列表越堆越长，想把不再用的 R1 从 Ollama 里清掉，结果删完发现空间没回来，或者列表里还留着一个同名条目。这篇不聊哪个模型更强，只解决「怎么删干净」：删之前要确认哪些东西在占位，删的时候按什么顺序执行，删完怎么验证真的没了，以及几种删不动的常见原因。

磁盘告警、模型列表越堆越长，想把不再用的 R1 从 Ollama 里清掉，结果删完发现空间没回来，或者列表里还留着一个同名条目。这种情况太常见了，问题基本不在删除命令本身，而在删之前没搞清楚「谁在占位」、删之后没验证「到底删没删掉」。

这篇不聊哪个模型更强，只解决「怎么删干净」：删之前确认哪些东西在占位，删的时候按什么顺序执行，删完怎么验证真的没了，以及几种删不动的常见原因和排查顺序。跟着走一遍，基本能覆盖大部分场景。

删之前先搞清：占空间的到底是什么

很多人一上来就敲删除命令，删完发现磁盘空间没变化，就开始怀疑命令没用。其实 Ollama 里一个模型条目背后通常不是一个文件，而是分层 blob 加上一份清单文件。你看到的模型体积，是这些层加起来的总和，但实际占用的磁盘块可能因为共享层的关系和显示数字不一样。删之前先确认占用来自哪一层，比直接删重要得多。

blob 层

模型权重被切成若干层存储，多个模型可能共用底层，删单个模型不一定释放全部空间

清单文件

记录这个模型由哪些层组成、标签是什么，清单不删列表里就还能看到条目

下载临时文件

拉取中断或失败留下的残片，体积不大但会占位置，容易在清点磁盘时被忽略

• 用列表类命令看当前装了哪些模型、各自体积多大，别凭印象猜哪个最大
• 确认目标模型是不是被别的工具或配置文件引用，记下引用位置，删完要回头改
• 看看到底是模型权重占地方，还是运行日志、临时下载残留占地方，两者清理方式完全不同

列清单与定位文件：把要删的对象找准

Ollama 的模型名称带标签，同一个名字可能有多个标签指向不同体积的版本。如果你只按前缀匹配就下手，很可能删掉的是另一个标签的条目，真正想删的那个还留着。先把完整名称和标签找出来，复制下来，再执行删除。

定位文件路径这一步不用太精确，但至少要确认你的模型目录在哪个盘、日志和临时目录是不是和模型目录分开的。有些系统上这两者不在同一个位置，只看一个地方会漏掉不少占用。具体路径查你系统上的 Ollama 配置，或者到站内的工具目录里找对应的排查说明对照一下。

• 先列出模型清单，确认完整名称和标签，复制而不是手打
• 查一遍实际存储路径，确认模型目录和日志目录分别在哪
• 分别看权重目录和日志目录的大小，判断清理重点
• 把可能引用该模型名的配置文件记下来，删完逐一检查

删除动作的推荐顺序

删除顺序搞反了，最常见的后果就是命令报错或者只删掉一半。正确的做法是先让模型不再被任何进程占用，再执行删除，最后确认命令返回结果。下面按顺序拆开讲。

1. 停掉正在使用该模型的服务客户端、编辑器插件、本地知识库服务，凡是可能正在加载模型的都先关掉。模型在被占用时删除容易失败，或者只删掉清单但 blob 还锁着。
2. 按完整名称加标签删除单个模型用列表里复制来的全名执行删除，不要顺手批量清空。误删了要重新下载，网络和等待成本都不小。
3. 确认删除命令的返回结果有报错就把原文记下来再往下走，常见的有名称找不到、被占用、权限不足几类，对应不同的处理方式。
4. 关闭并重启一次 Ollama 服务让服务重新加载模型清单，避免列表里还挂着已经删掉的条目。

验证：怎么确认真的释放了空间

删完不验证，等于没删。验证分两步：先看列表，再看磁盘。列表确认条目没了，磁盘确认空间回来了。两步都对不上，说明还有残留要处理。

• 再看一遍模型清单，确认目标条目已经不在了，同名不同标签的要单独确认
• 对照删除前后的磁盘可用空间，看变化量是否和模型体积大致对得上
• 如果空间变化对不上，先查有没有残留进程占着文件句柄，再查有没有硬链接或其他副本
• 顺手看一眼日志目录有没有同步变小，有些运行日志会跟着模型一起清理

如果你的机器上还跑着其他依赖磁盘的服务，删除前后的空间对比要尽量在安静的时间段做，减少其他写入带来的干扰。具体多大的模型对应多大的空间变化，可以到站内的模型资料库页面看当时的记录，别凭记忆估算。

删不干净时的残留清理思路

模型删了、列表也空了，但磁盘空间还是没回来，这就是残留问题。残留一般分三类：调用方还开着、缓存清单没清、手动副本还在。按这个顺序排查，基本能找到原因。

手动删目录属于最后手段。删之前一定确认没有别的模型共用同一批 blob，否则会把其他模型一起弄坏。共用关系不好判断的话，宁可不手动删，改用重新拉取的方式覆盖。

• 优先关掉所有调用方：客户端、编辑器插件、本地知识库服务、写死在配置里的模型名
• 再清缓存的清单文件和下载临时文件，这类残留体积不大但会让列表看着没删干净
• 手动删目录之前，确认没有别的模型共用同一批 blob
• 清理完重启一次服务，再重新验证列表和磁盘空间

常见删不动的几种原因和排查顺序

删不动基本就三种表现：提示找不到模型、提示被占用、删完空间没变。每种对应不同的排查方向，按下面的顺序试，别一上来就重启或者格式化。

提示找不到模型

多半是名称或标签写错了。回清单里复制全名，注意大小写和标签符号。R1 这类模型通常有多个标签指向不同体积的版本，只写名字不写标签可能匹配不到。

提示被占用

按「停服务→关客户端→重启服务」的顺序试一遍。还不行就查是谁拿着文件句柄。不同系统查句柄的命令不一样，具体命令可以到站内工具目录里找对应的系统排查页。

删完空间没变

按「有无残留进程→有无其他副本→文件系统回收延迟」的顺序查。最后一种情况重启一次通常就恢复了，不要一上来就做格式化这类不可逆操作。

# 通用排查顺序示意，具体命令按你的系统替换；ollama list  # 先看清单确认条目状态；ollama rm 完整名称:标签  # 单条删除；ollama list  # 删除后复查清单；# 查进程占用与磁盘空间，确认残留再动手

删之前值得停一下的两个判断

不是所有「暂时不用」的模型都值得删。删掉意味着以后要用还得重新下载，网络和等待成本要算进去。磁盘实在紧张才值得动手。另外，如果是想换量化版本或者换同类模型，先把新模型跑通再删旧的，避免中间出现没有可用模型可调的空窗。

• 如果只是暂时不用，权衡重新下载的时间和流量成本，磁盘不紧张就别急着删
• 如果是换量化版本，先让新模型能正常跑通，确认可用后再删旧的
• 团队共用一台机器时，删之前跟其他人对一下，别删掉别人正在用的条目
• 删之前可以到站内的价格追踪页面看看同类模型的调用成本，决定是自托管还是走 API 更划算

判断标准其实很简单：删掉之后如果你还需要这个能力，恢复成本能不能接受。能接受就删，不能接受就先留着，或者换一个体积更小的版本先顶着。