倉庫已完善，模型下載與怎樣才能讓地端 AI 跑起來的實作

Day 3 規劃了集中模型庫的架構，Day 4 把每個運算節點都掛上了 /mnt/models。今天處理三個讓這座倉庫真正能長期運作的問題，模型怎麼進到這個環境中（下載工具與流程）?、誰有存取它的權限（多主機權限設計）?、以及檔案多了或時間久時該怎麼才能不亂 （版本管理）?。

這三件事在單機環境都是小事，放到多主機共用的網路環境，每一個環節都值得認真規劃好一次，而在坊間，這是 AI 基礎設施架構工程的一環。

AI 開放模型下載工具的選擇

下載前先說明一下， AI 開放模型指的是，一個 LLM 大語言模型的權重檔案是開放下載的，但不代表開源。開放權重（Open Weight）與開源（Open Source）在 AI 市場中是不同的事。即使廠商將權重檔案開放大家下載，但也不代表它符合嚴格的開源定義。
兩者的關鍵差異是，開放權重讓人們可下載已訓練好的模型檔案，能夠在自己的電腦或伺服器上執行與微調，但不一定有公開訓練程式碼、訓練資料集或資料過濾方式。
開源則必須符合開放原始碼促進組織 OSI 的標準，除了有開放模型權重檔案可下載，還要公開完整的原始碼、訓練架構、工具以及資料處理細節，允許人們完全透明地檢視與修改。

不但如此，下載前需要注意不同模型還會有不同的限制使用授權限制，比方說你要免費用的話，有商業使用人數、每年營業額的上限規定，你公司很大就得支付費用，不可以當免費仔。

另一個資料與架構上的風險是，非真正開源的模型，因為你拿不到完整的訓練資料，你很難完全排除版權爭議或資安隱患。

好，前面講了太多話了，很抱歉，下面是更重要的重點，模型有分成 HF 下載區、llama.cpp 下載區、Ollama 下載區、Github 下載區、原廠下載區等不同的地方可以下載模型，這是我權稱的而已，實際上可以交流模型的地方很多，包括 reddit 上都有很多熱心的社群朋友們在分享心得和想法，但為何要提到下面這些下載方式呢 ?

主要就是一般人一開始接觸 AI 模型下載，會不太知道要下載那些檔案，有主要模型檔案、次要模型檔案、投機模型、草稿模型、文字編碼器、圖像模型等等，所以會需要軟體工具來幫我們下載，是比較方便或更好管理外，另一個關鍵採用原因是它比較不會下錯檔案，可以把完整的檔案包下好給你，屆時你不要的東西再刪掉，所以放 NAS 上是一個比較不擔心浪費空間的方式。

畢竟，你會做實驗，會幾種不同的模型檔案做下載，是需要管理和確保下載回來的模型是正確且安全的，以下是我首推的模型下載工具和平台，著名的 Hugging Face。

Hugging Face 模型：用官方 CLI，指定 local-dir

Hugging Face 的模型下載，我用官方的 hf CLI 搭配 local-dir 模式就非常方便，下面以下載最近熱門的 Qwen 3.8 27B 模型為例：

pip install -U huggingface_hub
hf download Qwen/Qwen3.8-27B --local-dir /mnt/models/huggingface/Qwen3.8-27B

這裡有一個 NFS 環境的重要眉角可以記起來。HF 的預設快取機制是把檔案存進 ~/.cache/huggingface 的雜湊目錄，再用符號連結組出模型目錄。這套設計在本機碟沒問題，但是放到 NFS 上就需要調整一下。原因是不同主機的快取彼此獨立，等於每台都重複下載，而符號連結在跨主機掛載時也容易踩到解析問題，所以這時候指定 --local-dir 直接把完整檔案落在目標目錄，模型目錄就是一個乾淨、自包含、任何主機掛載都能直接用的資料夾。

下載工作的部分，我固定都在其中一台機器上執行，其他節點只讀。原因下一節講權限時會清楚。

GGUF 模型：認來源，驗雜湊

llama.cpp 用的 GGUF 檔多半來自社群量化，同一顆模型會有多個量化者的版本。我的原則有二。第一，優先選模型官方自己發布的 GGUF，其次才是長期經營、信譽良好的量化者。第二，下載完固定跑一次雜湊驗證：

sha256sum qwen3.8-27b-q4_k_m.gguf

比對發布頁提供的檢查碼。模型檔案動輒十幾 GB，走網路搬運出現損壞不是都市傳說，載入時才發現壞檔，浪費的是 GPU 時間與除錯耐性。

下載速度

依據你辦公室或家裡的網路速度，從 Hugging Face 直接下載到 NFS 模型庫，Qwen3.8-27B 完整權重需要的時間從幾分鐘到幾十分鐘不等，瓶頸在對外頻寬而非 NFS，模型庫的寫入路徑不需要極致效能，讀取路徑才需要。

誰能存取? 多主機的權限設計

在 ISO 實務中，最小權限原則是一個老生常談，而假設你有多台主機要共用同一個 NFS 目錄，權限沒設計好會出現兩種災難，其一是某台機器上的程式誤刪或覆寫了模型檔，其二是每台主機的 UID 對不齊，A 主機寫入的檔案 B 主機讀不了。

我在這台與其他類似環境的設計概念原則是「一寫多讀」：

寫入端只有一個。 模型下載與整理固定在一台管理節點上做，其他所有運算節點對模型庫都是唯讀掛載。QNAP 端的 NFS 權限設定可以針對不同來源 IP 給不同權限，把運算節點的 IP 設為唯讀，管理節點的 IP 才有讀寫。運算節點端的 fstab 也同步把掛載選項從 rw 改為 ro，雙重保險：

【NAS IP】:/share/models  /mnt/models  nfs4  ro,noatime,rsize=1048576,nconnect=8,hard,_netdev  0  0

推論程式本來就不該有修改模型權重的理由，唯讀掛載等於把「不小心」這個風險類別整個關掉。這個習慣來自平常處理資安相關事務的職業病，最小權限原則不是只用在人身上，機器與程式也適用。

UID 對齊問題，我們們可以在 NAS 的 NFS 設定中用 squash 解。各主機的使用者 UID 天生不會一致，與其逐台對齊，不如在 QNAP 的 NFS 設定裡使用 squash 選項，把所有客戶端請求映射為同一個身分存取。搭配唯讀掛載，運算節點根本不需要寫入身分，問題直接消失。

檔案多了或放久了怎麼管理才會不亂呢? 版本管理的土法煉鋼

模型庫最容易搞砸的方式是這樣的，三個月後目錄裡躺著 model-final、model-final2、model-new-test 三個資料夾，沒有人記得差在哪，如果你要上版本管理工具，可能設定又會比較麻煩，但也不能都沒管理。我個人建議其中一種簡單的做法，可以不依賴任何額外工具，主要就是我們得先養成三個習慣即可。

習慣一，目錄名就是完整版本資訊。模型家族、參數量、版本或日期、量化格式，全部進目錄名：

/share/models/gguf/
├── qwen3.8-27b-q4_k_m/
├── qwen3.8-27b-q8_0/
└── deepseek-v4-flash-0731-q4_k_m/

習慣二，每個模型目錄放一份 MANIFEST。 一個純文字檔，記錄來源網址、下載日期、sha256、授權條款、以及當初為什麼下載它。花三十秒寫，省去你未來花三十分鐘或更多時間去考古：

source: https://huggingface.co/Qwen/Qwen3.8-27B
date: 2026-08-18
sha256: <檢查碼>
license: Apache-2.0
note: 262K 上下文，第三週實測主角

習慣三，用途透過符號連結表達，不搬檔案。例如 ComfyUI 需要特定目錄結構，我不複製模型檔過去，而是在 ComfyUI 的模型目錄建立指向模型庫的連結，或直接用 extra_model_paths.yaml 把路徑指過來。一份權重，多處引用，這樣一來，我們順便連磁碟空間與版本一致性都能夠同時兼顧。

授權條款欄位

這邊我想特別再說一下授權，像是 Apache 2.0 與 MIT 這類屬於開放原始碼的寬鬆授權，大家可以放心商用，但市場上許多熱門模型走的是自訂授權，對商業使用、再散布或衍生模型有額外條件。公司和你自己想要進行 地端 AI 部署，並不代表授權問題消失，請務必把 license 記進 MANIFEST，未來要拿去做商業專案時，你第一時間就知道哪些能用，那些不適合拿來用。這部強烈建議要做是因為，你如果這時不做，之後因為專案要做給客戶，需要確認一些細節，公司法務要來處理授權問題時，你得要花更多時間來搞這些事情喔。

這座倉庫繼續完善的風貌

到今天為止，模型庫的完整規則已經就位：目錄結構分來源三層，寫入單點，讀取多點唯讀，每個模型有身分證，熱門模型在 Spark 本機留快取。用 tree 看一眼目前的全貌：

tree -L 2 /mnt/models

明天預告

倉庫就緒，明天開始把貨拉出來用。Day 6 進入推論引擎總覽：llama.cpp、vLLM、TensorRT-LLM 與 Ollama 各自的定位、適用場景與取捨，為接下來要做的實務安裝、推論、橫向實測等公 做，建立一個可信任和大致概念的基礎。

我們 Day 6 見囉。

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜Day 4|開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理