模型管理：删除、复制和环境变量

[TOC] 模型越下越多，磁盘开始报警；想改默认端口没人教过；显存被占得满满的却不知道哪里出了问题。这些都是用了一阵子 Ollama 之后必然遇到的问题。这篇把模型生命周期管理和环境变量配置一次讲清楚，让你的本地环境长期保持整齐有序。这些操作都不难，但都是很实用的技能，值得收藏随时查。

模型的增删改查

先给一张速查表，把最常用的命令放在一起，后面的章节再逐条展开。

这八条命令覆盖了百分之九十九的日常操作，记住这张表基本不用再翻文档。

其中最值得多说一句的是 ollama ps。它列出的信息和 ollama list 不一样：list 是磁盘上有哪些模型，ps 是当前在显存里跑着哪些。排查一切性能问题，第一步都是 ps 看一眼，确认模型有没有意外驻留。另外一个细节，ps 会显示还在不在加载中的状态，模型加载到一半时它会先出现，等完全就绪之后占用才会稳定，观察这个过程能帮你理解加载机制。

还有一个 show 命令的用法值得一提。它不仅能看参数，还能看模型的许可证信息，企业落地前确认授权条款的时候就靠它， 不用专门跑去模型页面翻说明。随手一个命令比开浏览器翻网页快得多。

删除模型：最直接的空间回收

删模型是释放磁盘最立竿见影的动作。先 ollama list 看看都有什么，然后：

ollama rm llama3.1:8b

删之前有两点提醒。第一， rm 必须带上完整标签，只写模型名是不够的。第二，删除是不可逆的，删错了只能重新下载，几个GB 的流量就没了。养成删之前扫一眼确认的好习惯。

什么模型值得删？试过一次再没碰过的；同一个模型下了好几个量化版本只用一个的；当初脑子热下了大结果本地压根跑不动的。定期做一次这种清理，磁盘空间和心情都会好很多。

还有一个隐性的空间杀手：被更新替换掉的旧版本。有时候你 pull 了同一标签的新版本，旧版本在某些情况下仍然残留在本地。用 ollama list 只要看到名字重复出现、digest 不同但大小相近的条目，基本就是它了，清理掉能腾出不少空间。

管理磁盘空间的核心思路是按需持有。本地大模型圈子里有一个很真实的现象：模型就像游戏库，买的永远比玩的多。每过一阵子做一次减法， 不需要的果断删，把宝贵的空间留给真正高频使用的少数几个模型，这是长期保持环境健康的关键。

话说回来，删模型这事儿虽然简单， 但它背后是一种很重要的实践：本地工具需要你来维护。云端服务的空间和清理都不用你操心， 本地的好处是自由，代价就是这份自由的维护责任。接受这一点， 本地部署才玩得长久。

复制模型：给定制内容做备份

ollama cp 的名字听起来像复制文件，它主要用于复制定制模型。你花半小时调好的 Modelfile 派生模型，cp 一份做备份，怎么改都不怕改坏，随时能回滚。命令很简单：

ollama cp my-coder my-coder-backup

另一个很实际的用途是给基础模型创建变体。比如同一个 8B 模型， 你想准备一个低温度版本用于严肃问答、一个高温度版本用于创意写作，cp 出两份分别改参数， 用的时候按名字区分，比每次修改参数方便太多。

对长期在本地折腾的人来说，备份的意识比技巧更重要。慢慢积攒下来的提示词和参数都是时间换来的资产，哪天误删或者升级出错，就知道有备份是多幸运的事。

顺带一提，cp 出来的副本改名之后就是独立条目，删掉任何一个都不影响另一个。用它来做试验再合适不过：想调参数但不确定效果，先 cp 一份再改，翻车了删掉就好，一点损失都没有。这种零成本试错的安全感，是本地工具的独特红利。

环境变量：配置 Ollama 的正确姿势

Ollama 的很多行为通过环境变量控制， 这是最规范的配置方式。下面这张表列出最常用的一批。

最常改的一个是 OLLAMA_HOST，让局域网其它设备能连上来。改法在安装 Ollama：Windows、Mac 和 Linux那篇有各平台的具体步骤。

第二常改的是 OLLAMA_MODELS。系统盘空间紧张的时候， 把模型目录挪到数据盘是标准操作。Windows 上设置环境变量指向新路径，Linux 上 systemd 服务的环境变量配置里增加一行，重启服务生效。挪目录之前别忘了把旧文件搬过去， 光改配置不搬文件， 新目录是空的等于没模型可用。

OLLAMA_KEEP_ALIVE 控制模型空闲多久后从显存卸载。默认值是几分钟，个人高频使用可以调大甚至设为 -1 表示永久驻留；多人共用机器则调小一点，让模型早点卸载给别人腾地方。

OLLAMA_NUM_PARALLEL 决定服务同时处理几个请求，默认是 1。多人通过局域网共用同一台机器时，把它调到 2 到 4 能明显减少排队等待。但请注意，并发并不是越大越好：每多一个并发槽位，推理都要额外占用显存和算力，单请求的输出速度会被摊薄。个人使用建议保持默认，小团队共用再按人数往上加，同时观察响应延迟有没有明显退化。

OLLAMA_NUM_THREAD 只在没有显卡、纯 CPU 跑模型时才起作用，设置成 CPU 的物理核心数即可。超过物理核心反而会因为线程切换开销拖慢速度，核多不一定快。判断方法很简单，任务管理器或者 htop 看一眼物理核心是多少，照着填就行。有显卡的机器基本不用管这个变量，推理主要走显卡，CPU 线程数影响微乎其微。

OLLAMA_ORIGINS 平时用不到，但哪天你想让网页直接通过浏览器脚本访问本地接口，就会遇到跨域拦截。把它加上对应的来源地址就能放行。安全提醒：不要图省事设成星号对所有来源开放，局域网里尚可接受，公网环境这么做等于把服务裸奔在网络上，谁都能调用你的算力。

如果你经常需要在多个模型间来回切换， KEEP_ALIVE 调大能明显提升体验，省掉反复加载的几秒到十几秒。代价是显存被长期占用， 游戏或者其它程序要用显存的时候会打架。怎么权衡没有标准答案，看你更在乎响应速度还是显存自由。

设置方式上，Windows 用户在系统环境变量界面操作；Linux 用户用 systemctl edit ollama 写进配置；Mac 桌面版可以在 plist 或者启动参数里设置。万变不离其宗，都是给后台服务注入环境变量， 理解了这一点任何平台都会配。

再补充一个排错技巧：改完环境变量怀疑没生效，可以看服务的启动日志， 正常启动的服务会把关键配置打印出来。Windows 在应用日志里找，Linux 用 journalctl 查看， 比闷头猜来猜去快得多。

模型目录的迁移

迁移分两步：改环境变量指定新位置，然后手动把已有文件搬过去。搬之前先停掉服务，避免一边移动一边有程序在读写出错。文件量大的话复制要等一会儿，进度没有进度条，耐心等它跑完再启动服务。

迁移完别忘了验证。敲个 ollama list 看看所有模型还在不在，再 run 一次确认能正常使用。三个平台都一样的流程，没有坑。建议在磁盘空间还充裕的时候就提前规划好存储位置，等满了再迁移总是手忙脚乱。

迁移的时候有一个细节值得注意：Windows 下如果目标盘是机械硬盘，体验会明显下降。每次启动模型都要读盘，机械硬盘的寻道时间会让加载慢好几倍，长年累月用起来很折磨。迁移的目标盘务必还是固态硬盘，SATA 协议的都行，速度够快；只有纯粹的机械盘才值得担心。如果你在用高性能的电脑，通常更适合的做法是：系统盘留给系统，大容量的固态数据盘留给模型，二者兼得。

说一个反直觉的经验： 模型文件读取的时机只有启动一瞬间，运行起来之后全在显存里算，硬盘快慢只影响加载等待那几秒。所以淡定的做法是接受机械硬盘的加载速度， 反正模型加载一次能用很久。对加载速度敏感的人，当然是固态硬盘更合适。

显存长期占满的几种处理

ollama ps 一看， 模型明明没跑， 显存占用却下不来，这是新手高频困惑。原因通常有三个。

第一个，模型还没被卸载。KEEP_ALIVE 时间没到，模型按照设定在显存里待命。 这其实是好事，下次启动快；真想立刻释放就降低 KEEP_ALIVE 或者等几分钟。

第二个，多个模型排队占用。MAX_LOADED_MODELS 允许多个模型同时驻留， 它们各占各的显存加起来就很可观。检查 ps 输出，把不用的 rm 或者调小同时加载数。

第三个，有进程异常残留。服务假死或者重复启动都会让显存被占住但看不到任务。重启服务能解决大部分情况；还不行就重启机器，简单粗暴但有效。

第四种情况最容易被误判：你其实还有别的程序在占显存。浏览器开硬件加速、视频会议软件、乃至桌面美化工具， 都会占住一到两个GB。先排除这些再怪 Ollama， 能少走弯路。养成跑模型时关掉不必要程序的习惯， 显存焦虑会缓解大半。

长期使用的一些好习惯

模型管理这件事，做一次容易， 难的是长期保持。分享几个被时间验证过的好习惯。

第一，给定制模型起稳定易记的名字。今天随手起的 my-model1， 三个月后你自己都不知道它是干嘛的。起名带上用途和基础模型， 比如 coder-qwen7b、translator-14b， 一眼就明白。第二，Modelfile 原文件在一个固定目录里归档保存， 不然重建定制模型时要从头写起。第三，每次清理磁盘的时候顺手 ollama list 审视一遍， 顺便也是复盘自己真正在用哪些模型。第四，常用配置写成文档存起来， 哪天换机器， 照着文档半小时就能恢复整套环境， 不用从头摸索。

这些习惯看着琐碎， 但都是长期主义者的经验。本地环境最大的优势就是它是你的， 你怎么打理它， 它就怎么回报你。

常见问题

删了模型磁盘空间没释放

极少数情况下是残留文件没清干净， 重启服务再试一次。也有可能是文件系统回收机制的问题， Windows 上有时候需要等一会儿空间才显示释放。如果 ollama list 里确认没了但空间少了几十GB， 检查模型目录里有没有孤儿文件， 手动清理一下即可。

环境变量设置了不生效

八成是服务没重启。环境变量是服务启动时读取的，改完必须重启服务。Windows 用户记得退出任务栏的后台程序再重新打开，Linux 用户执行 systemctl restart ollama。另外确认一下变量是设置给服务用户而不是你自己，Linux 下的服务用户是 ollama。

还有一种情况是拼写或者大小写不对， 环境变量名称是严格区分大小写的。照着文档复制最稳妥， 一个字符一个字符手敲很容易敲错， 排查半小时最后发现是少打了个字母， 这种亏很多人都吃过。

怎么同时跑两个模型

显存足够的话， MAX_LOADED_MODELS 设为 2 或者更大就行，Ollama 会自动加载多个模型响应不同请求。显存不够强行开就是部分层卸载或者直接报错， 速度和稳定性都会受影响。评估标准很简单，两个模型体积之和加上 KV 缓存，别超过显存上限。相关原理在硬件门槛：显存决定模型大小里有详细说明。

实际应用里，双模型的典型组合是一个聊天模型加一个向量模型：向量模型负责知识库的检索，聊天模型负责组织回答， 两者配合就是私有知识库问答的标准配置。具体怎么把这套组合跑起来，可以看Open-WebUI：给本地模型一个网页界面里知识库功能的用法。

删除模型时报错 model not found

明明 ollama list 里看得到这个名字， rm 却说找不到，十有八九是标签写错了。list 输出的第一列是完整的名称冒号标签格式，直接复制那一列最保险。还有一种情况是你自己拼错了大小写，模型名称对大小写敏感， llama 和 Llama 是两个不同的串。少数时候是服务索引延迟，刚 pull 完立刻删可能触发，等几秒重试就好。

怎么把整套环境搬到新机器

核心就两条：迁移模型文件，迁移环境变量配置。模型目录整个复制到新机器相同路径，或者复制过去之后用 OLLAMA_MODELS 指向新位置；环境变量照着旧机器的设置重新配一遍，重启服务生效。Modelfile 单独备份的话，定制模型需要重新 ollama create 一遍，几分钟的事。全部弄完跑一遍 ollama list 加一次对话验证，环境就算完整搬家了。

配置太多记不住怎么办

常用就那三五个， 用到再查完全行，不用全背下来。把这张速查表存起来， 需要的时候翻一翻， 比记忆可靠多了。真正高频使用的只有 OLLAMA_HOST 和 OLLAMA_MODELS，搞定这两个就能覆盖大部分场景， 其它的属于进阶调优，按需学习就好。