本地跑模型跑久了，硬盘里会攒下一堆下载过、试过、早就不用的模型，占着几十上百 GB 你自己都不知道。这篇不聊怎么选模型，只解决三件事：怎么把本地模型列清楚、怎么判断哪些该删、删的步骤和删完怎么验证。
本地跑模型跑久了，硬盘里会攒下一堆下载过、试过、早就不用的模型，占着几十上百 GB 你自己都不知道。这篇不聊怎么选模型、不比较哪个模型更聪明，只解决三件事：怎么把本地模型列清楚、怎么判断哪些该删、删的步骤和删完怎么验证。把这三件事按顺序走一遍，通常十几分钟就能腾出可观的空间。
下面每一步都给可执行的动作和判断标准，同时会说明什么情况下不适用。比如多人共用的机器、或者模型目录被改过位置的机器，处理顺序要调整，我会在对应小节点出来。具体数字别凭印象，列一遍就知道。
先搞清模型是怎么把硬盘吃掉的
动手之前先建立一个概念：每个模型在本地都是一份完整的权重文件，不是薄薄的配置。你拉了三个不同参数规模、或者同一个模型不同量化档位，那就是三份独立文件，彼此不共用。理解这一点，后面判断谁占地方、删了能腾出多少，才不会算错。
- 同名的不同 tag（不同量化档、不同参数规模）算不同模型，各自占一份空间
- 同一个系列的大小版本之间不共享权重，留两个就是两份体积
- 模型文件默认放在固定的模型目录里，删模型和删目录是两件事，别搞混
- 列表里显示的大小只是权重文件本身，运行时的显存占用是另一笔账
查询：把本地模型列全的三个动作
查本地模型的第一步是列一遍，别凭记忆。列表命令会给出名字、tag、大小、更新时间，这是后面所有判断的数据基础。先把这一屏结果拿全，再谈删谁。
- 列一遍本地的模型用 ollama 的列表命令看名字、tag、大小、更新时间，确认自己装了什么，不要靠回想。
- 对可疑条目查元信息名字看着像但不确定是不是同一个时，用 show 类命令看量化档、参数规模、模板等信息，别只看名字判断重复。
- 分区占用和显存列表里的大小只是权重体积，运行时显存占用要另算。需要对照口径时，到 /models 页面核对当时的资料。
ollama list
ollama show <模型名>:<tag>如果你不确定列表里某个 tag 对应什么量化档、参数规模，就把它的名字完整抄下来，到站内的模型资料库对照看。什么时候不适用：只要你能通过 show 命令确认它就是你要删的那个，就不必再查外部资料。
想知道文件到底躺在哪，先查路径再动手
很多人以为模型一定躺在安装目录下面，实际上模型目录可以被环境变量改写过。你要是改过存储位置，历史模型可能散在两个目录里，只查一边就会漏。所以顺序是：先确认当前生效的路径，再算占用，最后决定删谁。
| 判断项 | 怎么确认 | 不适用的情况 |
|---|---|---|
| 当前模型目录 | 查当前生效的环境变量与默认路径，别按安装路径猜 | 从没改过环境变量的机器，直接用默认路径即可 |
| 历史残留目录 | 回忆是否改过存储位置，改过就两边都看一眼 | 新装机、从没迁移过存储的，通常只有一个目录 |
| 实际占用 | 在确认到的目录里看大小，跟列表结果交叉比对 | 只删一个模型做小整理时，可以跳过这一步 |
路径相关的细节站内有专文，这里只给判断顺序：先确认路径，再算占用，再决定删谁。想对一下当前盘的整体容量和趋势，可以到 /tools/speed-test 这类工具页面看站内提供的检查入口，具体数字以你本机实测为准。
判断哪些该删：四条可执行标准
到了决定删谁这一步，最容易犯的错是只看名字眼熟就删。下面四条标准可以一起用，按优先级从高到低执行，拿不准的放最后处理。
- 近期没用过加体积大：用更新时间和大小时一起筛，两个条件都满足的优先删
- 同族重复：同一系列不同尺寸、不同量化档，各留一个常用档位就够
- 被依赖的别急着删：有些模型是从别的模型派生出来的，删父级会让派生模型不可用，删前先确认依赖
- 不确定就先别删：留着只占硬盘，删错了要重新下载，时间和流量成本更高
第三条要展开说一下：报错提示不能删基础模型，往往就是它被别的模型引用了。这种情况的判断顺序是，先看是谁引用它，再决定是删掉引用方，还是保留父级。什么时候不适用：如果你本来就是想彻底清空这一族，那就先把派生模型全删掉，再删父级。
删除的执行顺序与常见报错
删除本身是一条命令，但顺序错了会出各种怪问题。按下面顺序走，能避开大部分坑。批量整理时更要先停下来做清单，别边看边删。
- 先停占用停掉正在用这个模型的服务或会话。模型被占用时删除可能直接失败，也可能表面成功但实际没清干净。
- 带 tag 删除按名字删时名字要带 tag。只写主干名可能匹配不到你想删的那个，尤其同一系列装了多个档位时。
- 处理基础模型报错报错说不能删基础模型，说明它是被引用的底层。先删引用它的派生模型，或者保留父级不动。
- 重新列一遍确认删完用列表命令再看一遍，确认条目没了，再去目录里看占用有没有真的下降。
ollama rm <模型名>:<tag>
ollama list有人会问，能不能直接去模型目录里删文件？不建议。手工删目录和用命令删模型是两件事，容易留下元数据对不上的状态。路径那节只是让你知道东西在哪、算得清占用，真正的删除动作还是走命令。
删完怎么验证，以及剩下的怎么收尾
删完不验证，等于没删。最简单的验证是拿删除前后的列表条目数对照：删了几个，列表就少几条。如果条目少了但磁盘占用没降，那多半是两种情况之一，别急着怀疑命令有问题。
| 现象 | 可能原因 | 下一步动作 |
|---|---|---|
| 列表少了但空间没降 | 删的是另一个 tag，或文件在另一个模型目录里 | 确认 tag 是否写对，并检查所有可能的模型目录 |
| 命令报不能删 | 该模型被别的模型引用为底层 | 先删派生模型，或保留父级 |
| 删除后模型还在列表 | 有服务占用导致没清干净 | 停掉占用进程，重新删一次并再列一遍 |
批量整理时，建议先做一个「名字—大小—路径」的清单再动手，而不是一边看一边删。清单能让你删完随时核对，也方便多人协作时提前对齐要删哪些。至于该不该按体积排序优先清理，可以到 /price-watch 看看站内的价格与体积追踪口径，具体数字以你本地实测为准。
让它别再攒回来：日常习惯
清理一次不难，难的是别再攒回来。养成几个小习惯，下次就不会又面对一屏认不出的模型。这些习惯不涉及具体数字，只涉及动作。
- 拉模型前先列一遍，确认没有同族重复再拉
- 试完就删的临时模型单独记一笔，避免过一阵子忘了它是什么
- 把模型目录放在容量可控的盘上，定期看一眼大小变化趋势
- 多人共用时，拉和删都在同一个地方留个记录，减少互相踩脚
- 换模型前先想清楚旧的那个是留还是删，别默认都留着
什么时候不适用：如果你的机器空间非常宽裕、模型数量也不多，那定期检查的频率可以放低，不必每次拉新模型都走一遍完整流程，但至少每换一代常用模型时清一次。
下一步把本地模型列一遍，对照站内资料库确认每个 tag 的用途，再按本文的判断标准做一次清理；不确定的条目先留着，别一次删太狠。→常见问题
列表里名字差不多，我怎么知道是同一个还是两个？
看名字后面的 tag。同名不同 tag 在 ollama 里是两个独立模型，各占一份空间。拿不准就用 show 类命令看它的量化档和参数规模，参数规模或量化档不一样，就是两个东西，删一个不影响另一个。
删了模型，磁盘空间没变，怎么回事？
常见两种：一是你删的 tag 和占空间的那个不是同一个；二是这个安装改过模型存储位置，历史模型留在旧目录里，命令管不到那一份。先去确认当前生效的模型目录，再按目录去核对文件。
提示不能删除基础模型，是不是就删不掉了？
不是删不掉，是顺序问题。这个模型被别的模型引用着，先处理引用它的那些，或者干脆留着这个底层不动，只清掉自己拉的其他版本。硬删底层会让依赖它的模型一起失效，重新下载更费时间。
删之前需要先停服务吗？
建议停掉正在加载它的会话。模型被占用时，删除可能出现报错，也可能命令返回成功但文件没真正释放。稳妥顺序是：停会话或服务 → 删 → 重新列表确认 → 看目录占用。
想批量清一遍，最稳的做法是什么？
别边看边删。先列出所有模型，把名字、tag、大小、更新时间抄成一张清单，再按「大且久未用」「同族重复」两条标准圈出候选，逐个确认不是别人的依赖项，最后才动手删。清单留着，下次清的时候能对照。
