3.1 模型获取与存储
3.1 模型获取与存储
本节摘要：模型从下载到可运行，要经过 registry 拉取、blob 落盘、manifest 登记三步。本节讲清存储目录的真实形态（为什么"一个模型"其实是许多 blob 的组合）、断点续传与离线迁移的做法、标签与别名的组织方式，以及删除模型时磁盘空间何时才真正归还。
一条 pull 命令背后发生了什么
ollama pull llama3.1:8b 执行时，Ollama 先向模型仓库（registry.ollama.ai）解析 llama3.1 这个名字，取回它的 manifest——一份 JSON 清单，列出了组成该模型的全部层：每一层是一个 blob，用 SHA-256 摘要做文件名。然后客户端逐层下载，凡是本地 blobs 目录里已存在相同摘要的文件就直接跳过。这就是为什么把 llama3.1:8b 升级到 llama3.1:8b-instruct-q8_0 时，共享的词表层不会重下——不同模型复用相同 blob，是 Ollama 省流量的核心机制。
# 拉取指定量化版本 ollama pull llama3.1:8b-instruct-q4_K_M # 不带 tag 时默认拉 latest ollama pull qwen2.5 # 查看拉取进度与层复用情况（已存在的层会秒过） ollama pull deepseek-r1:7b
下载支持断点续传：Ctrl+C 打断后再执行同一条命令，会从已完成的层继续，而不是清零重来。没有进度条死掉的"卡住"多数是网络到 registry 的链路问题，可以设置 HTTPS_PROXY 代理环境变量后重试。
blobs 与 manifests：存储目录的真实形态
模型文件不在安装目录，而在用户目录下：macOS 是 ~/.ollama/models，Linux 同样是 ~/.ollama/models（服务以 systemd 运行时也可能是 /usr/share/ollama/.ollama/models），Windows 是 C:\Users\<你>\.ollama\models。想换到大盘，设置 OLLAMA_MODELS 环境变量即可，例如 Windows 下 setx OLLAMA_MODELS D:\ollama_models 后重启服务。
目录里只有两个子目录。blobs/ 存放实际数据文件，名字形如 sha256-4e5dbc...，一个文件可能是权重、词表，也可能是提示词模板或许可证文本。manifests/ 按仓库域名/模型名/tag 的层级存放清单文件，每个 tag 一个 JSON，里面引用若干 blob 摘要。所谓"一个模型"，本质是"一份清单 + 一堆可复用的块"。
# 观察目录结构 ls ~/.ollama/models/blobs | head cat ~/.ollama/models/manifests/registry.ollama.ai/library/llama3.1/8b-instruct-q4_K_M # JSON 里的 layers[].digest 与 blobs/ 下的文件名一一对应 # 看看谁在吃磁盘 du -sh ~/.ollama/models/blobs
理解这个结构，离线迁移就很简单：把整个 models 目录打包复制到目标机器的相同位置（或 OLLAMA_MODELS 指向的位置），启动服务后 ollama list 直接可见，全程无需联网。内网部署、实验室共享一台跳板机，都靠这一招。
查看、别名与删除
ollama list 列出本机全部模型及各自占用；ollama show 深挖单个模型的结构信息，包括上下文长度、嵌入维度、量化类型、系统提示词和许可协议：
ollama show qwen2.5:7b # 概要：参数量、量化、上下文窗口 ollama show qwen2.5:7b --modelfile # 反推它的 Modelfile（下一节的主角） ollama show llama3.1 --parameters # 模型的默认采样参数
ollama cp 建立别名，不复制任何 blob——新旧两个名字指向同一份清单，常用于给基座模型起一个项目专属名字再另行定制：
ollama cp llama3.1:8b myproj/base ollama list
删除分两档。ollama rm <名字> 移除的是 manifest（标签），只有当某个 blob 不再被任何标签引用时，对应的磁盘文件才会被一并清掉；被其他模型共享的层会保留。所以删掉一个大模型后磁盘空间"没有完全释放"通常不是 bug，而是那些 blob 还被别的变体引用着：
ollama rm myproj/base # 删标签；独占的 blob 同步回收 ollama list # 核对 df -h ~ # 确认磁盘归还情况
模型从哪来：官方库之外的路径
官方 library 是第一选择，但不是唯一。Ollama 的 registry 支持社区命名空间（如 ollama pull acyclic/xxx），也兼容 Docker 风格镜像名的解析。更常见的两条补充路径：
其一，直接引用 Hugging Face 上的 GGUF。在 Modelfile 的 FROM 里写本地 GGUF 路径，配合第 3.2 节的自定义流程就能把社区量化版本纳入 Ollama 管理。其二，从 safetensors 原始权重自行转换：用 llama.cpp 的 convert_hf_to_gguf.py 先转成 F16 GGUF，再用 llama-quantize 压到目标位数：
git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp pip install -r requirements.txt # 第一步：Hugging Face 权重 -> 未量化 GGUF python convert_hf_to_gguf.py ./Qwen2.5-7B --outfile qwen2.5-7b-f16.gguf # 第二步：量化到 Q4_K_M ./llama-quantize qwen2.5-7b-f16.gguf qwen2.5-7b-q4km.gguf Q4_K_M # 第三步：交给 Ollama printf 'FROM ./qwen2.5-7b-q4km.gguf' > Modelfile ollama create qwen2.5:7b-local -f Modelfile
存储相关的三个实操提醒
第一，移动 OLLAMA_MODELS 之后务必重启服务，运行中的 server 不会感知环境变量变化。第二，Windows 上一块盘放不下多套大模型时，用目录联接（mklink /J）把 blobs 指向大盘比改环境变量更隐蔽，但要记得记录在部署文档里，否则换人维护时找不到模型去向。第三，定期用 ollama list 对照磁盘占用，删掉试验性 tag——blob 复用机制意味着"下载时省流量，堆积时占真金白银的磁盘"，几十个试过一次就忘的量化变体，轻松吃掉半块盘。
模型拿进来之后，下一步是把它改造成贴合业务的形态：换系统提示词、调参数、挂知识文件——这正是 Modelfile 的舞台，下一节展开。