模型下载 on KnightLi的博客

llama-cli -hf 下载 Hugging Face 模型默认保存在哪里

Fri, 17 Apr 2026 14:48:04 +0800

如果你使用的是 llama-cli 直接从 Hugging Face 下载并运行模型，例如：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

这是 llama.cpp 自带的 Hugging Face 下载能力。新版 llama.cpp 会把 -hf 下载的模型放进标准 Hugging Face Hub 缓存目录。

默认缓存位置

llama-cli -hf 下载的模型缓存位置优先由 LLAMA_CACHE 环境变量控制。如果没有设置 LLAMA_CACHE，则会继续检查 Hugging Face 相关缓存变量，例如 HF_HUB_CACHE、HUGGINGFACE_HUB_CACHE 和 HF_HOME。

如果这些变量都没有设置，常见默认路径如下：

系统	默认缓存目录
Linux	`~/.cache/huggingface/hub`
macOS	`~/.cache/huggingface/hub`
Windows	`%USERPROFILE%\.cache\huggingface\hub`

在 Windows 上，%USERPROFILE% 通常对应：

`1`	`C:\Users\用户名`

所以默认缓存目录大致是：

`1`	`C:\Users\用户名\.cache\huggingface\hub`

想修改 llama-cli 的缓存目录怎么办

可以设置 LLAMA_CACHE，把模型缓存放到指定磁盘或目录。也可以按 Hugging Face 的习惯设置 HF_HOME，此时实际 Hub 缓存目录会是 $HF_HOME/hub。

Windows 临时设置示例：

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

PowerShell 临时设置示例：

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Linux / macOS 临时设置示例：

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

小结

llama-cli -hf ... 使用的是 llama.cpp 下载逻辑，但新版默认落到 Hugging Face Hub 缓存。
Linux / macOS 默认：~/.cache/huggingface/hub
Windows 默认：%USERPROFILE%\.cache\huggingface\hub
想换目录：设置 LLAMA_CACHE，或设置 HF_HOME / HF_HUB_CACHE

Windows 下 llama-cli 直连 Hugging Face 报 SSL 证书验证失败怎么办

Fri, 17 Apr 2026 14:20:29 +0800

如果你在 Windows 下运行下面这条命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

并看到类似报错：

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

通常不是 CUDA 或 llama.cpp 本身有问题，而是程序在当前环境里没有正确拿到系统证书链，导致 HTTPS 校验失败。

从报错来看，ggml-rpc.dll 和 ggml-cpu-alderlake.dll 都已经正常加载，说明运行环境本身大体可用，问题主要集中在模型下载阶段。

最省事的办法：先手动下载模型

如果你只是想尽快跑起来，本地手动下载通常最稳。

打开对应的 Hugging Face 仓库页面。
在 Files and versions 里下载需要的 .gguf 文件。
下载完成后，直接用本地文件路径运行：

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

这样可以绕过 -hf 下载阶段的 SSL 校验问题，适合先验证模型能不能正常推理。

如果还想继续用 `-hf` 自动下载

可以手动指定证书文件路径，让程序在当前会话里找到可用的 CA 证书。

cacert.pem 可以从 curl 官方维护的 CA Extract 页面获取：

页面地址：https://curl.se/docs/caextract.html
直接下载：https://curl.se/ca/cacert.pem

如果用浏览器下载，打开上面的直接下载地址后保存为 cacert.pem 即可。也可以在 PowerShell 里下载到固定目录，例如：

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

下载完成后，在命令行里设置：

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

再重新执行原命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

如果问题确实来自证书链，这种方式通常能直接解决。

llama.cpp 如何从 Hugging Face 获取 GGUF 模型

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp 可以直接配合 Hugging Face 上的 GGUF 模型使用，不一定要先手动把文件下载到本地。

如果模型仓库本身已经提供了 GGUF 文件，可以直接在命令行里使用 -hf 参数，例如：

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

默认情况下，这个参数会从 Hugging Face 下载模型。
如果你使用的是其他兼容 Hugging Face API 的模型托管服务，也可以通过环境变量 MODEL_ENDPOINT 切换下载端点。

需要注意的是，llama.cpp 只能直接使用 GGUF 格式。
如果拿到的是其他格式的模型文件，就需要先用仓库里的 convert_*.py 脚本转换成 GGUF。

Hugging Face 还提供了一些和 llama.cpp 相关的在线工具，常见用途包括：

把模型转换为 GGUF
对模型做量化，减小体积
转换 LoRA 适配器
在线编辑 GGUF 元数据
直接托管 llama.cpp 推理服务

如果只想记住一个最实用的结论：优先找已经提供 GGUF 的模型仓库，然后直接用 llama-cli -hf <user>/<model>，通常是最省事的做法。

Ollama 下载模型 pull 速度很慢的排查和解决办法

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag 在有些地区下载速度会很慢，而且过程并不稳定。

如果你遇到的是大模型下载到一半反复中断、报错 TLS handshake timeout 或 unexpected EOF，那么问题很可能不只是 registry.ollama.ai 本身，而是后续跳转到的实际下载链路。

这篇文章记录一次简单直接的排查思路：先拿到模型文件的真实下载地址，再确认最终流量落到哪里，最后只针对关键域名做网络优化。

获取模型文件的下载地址

可以借助下面这个项目，把 Ollama 模型对应的 manifest 和 blob 下载地址直接提取出来：

https://github.com/Gholamrezadar/ollama-direct-downloader

以 gemma4:latest 为例，可以提取出类似下面这些链接。

Manifest 地址

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Blob 地址

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

如果你只是想快速验证，也可以直接用 curl 下载 manifest 和 blob：

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

跳转后的真实下载地址

尝试用 wget 下载其中一个 blob，会发现请求并不是一直停留在 registry.ollama.ai，而是会继续跳转到一个 Cloudflare R2 对象存储地址：

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

从日志里可以看到几个关键信息：

registry.ollama.ai 返回了 307 Temporary Redirect
最终下载地址落在 *.r2.cloudflarestorage.com
真正承载大文件传输的，实际上是后面的对象存储域名

这一步很重要，因为它说明如果你的代理或分流规则只覆盖了 registry.ollama.ai，但没有处理 *.r2.cloudflarestorage.com，那下载仍然可能很慢，甚至反复中断。

调整网络设置

确认真实下载链路之后，排查方向就会清晰很多。

如果你正在使用代理、分流或自定义 DNS，建议优先检查下面几件事：

registry.ollama.ai 和 *.r2.cloudflarestorage.com 是否走了同一条稳定线路
代理规则是否只覆盖了前者，而漏掉了后者
当前出口是否适合持续下载数 GB 到数十 GB 的大文件

这类问题的关键并不是“能不能打开官网”，而是“跳转后的对象存储链路是否稳定、是否能长时间持续传输”。很多时候，真正需要优化的是 Cloudflare R2 这一层，而不是前面的 registry 域名。

调整前后的对比

下面是一次实际下载 gemma4:31b-it-q8_0 时的表现。

调整前，下载速度较慢，而且会在中途报错：

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

调整后，再次下载同一个模型时，速度和稳定性都有明显改善：

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

这并不意味着所有网络环境都能得到同样结果，但至少说明了一点：瓶颈很可能不在 Ollama 客户端本身，而在实际的大文件下载链路。