模型下載 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 CMD 暫時設定範例：

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 物件儲存地址：

`1`	`wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a`

從日誌裡可以看到幾個關鍵資訊：

registry.ollama.ai 回傳了 307 Temporary Redirect
最終下載地址落在 *.r2.cloudflarestorage.com
真正承載大檔案傳輸的，實際上是後面的物件儲存網域

這一步很重要，因為它說明如果你的代理或分流規則只覆蓋了 registry.ollama.ai，但沒有處理 *.r2.cloudflarestorage.com，那下載仍然可能很慢，甚至反覆中斷。

下面是一次實際抓到的跳轉日誌：

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]

調整網路設定

確認真實下載鏈路之後，排查方向就會清晰很多。

如果你正在使用代理、分流或自訂 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 用戶端本身，而在實際的大檔案下載鏈路。

一個更實用的排查順序

如果你也遇到類似問題，可以按這個順序來：

先執行一次 ollama pull 或 ollama run，確認問題是否穩定重現。
再用 wget 或 curl -L 測一個 blob 位址，確認是否跳轉到 *.r2.cloudflarestorage.com。
最後只針對真實下載網域調整代理或分流，再重新測試速度和穩定性。

這樣做的好處是，每一步都在驗證一個明確假設，不需要盲目試錯。

結論

ollama pull 下載慢，很多時候並不是因為 registry.ollama.ai 無法存取，而是因為真正承載大檔案下載的 Cloudflare R2 鏈路不夠穩定。

所以更有效的做法不是反覆重試，而是先把真實下載鏈路找出來，再針對實際流量落點做優化。