前言：我們歷經了硬體堪用到軟體搭配終於逐漸成熟的階段

兩年前，如果有人說要在自己家裡或公司機房跑一個能實際工作的大型語言模型，其實滿多人的第一反應是「跑得動嗎」。今天這個問題已經過時了，量化技術讓很多人的家用電腦只要有 NVIDIA RTX 系列 16GB VRAM 以上的顯示卡也能跑較小的地端 AI，中小型企業要用地端 AI 在經費不夠，記憶體大漲與伺服器變貴的情況下，也有小型 AI 工作站、買夠好的顯示卡可以做地端 AI。
2026 年我們碰到的問題變成該怎麼跑比較好 ? 該選哪個模型、哪個推論引擎、哪種量化格式，以及怎麼把這一切整合成一套可以長期維運的基礎架構呢。

促成這個轉變的力量來自兩端。我想說的特別是模型端這邊，開放權重模型在這一年密集爆發，從 Qwen3.x 系列到 Meta 的 Muse Glimmer，從通用聊天模型走向 Agent 專用模型，而且授權條款越來越友善，Apache 2.0 成為主流選擇，企業可以直接商用、微調與再散布。至於 Kimi K3、DeepSeek V4 Pro、Qwen 3.8 Max 等超大參數的地端模型也開放下載了，較適合研究機構、大型企業和雲端業者在資料中心部署用，中小型公司大概沒這個財力和設備能部署那種要吃大量記憶體的模型。

硬體端這邊呢，128GB 統一記憶體等級的裝置把「跑 70B 甚至 120B 模型」從資料中心拉到了桌面，NVIDIA DGX Spark、Apple M 系列與 AMD Ryzen AI Max+ 都在這個市場上有開發者和公司採用。

對台灣的企業 IT 與資安團隊來說，這件事的意義很實際喔，導入 AI 不再必然等於把內部資料送上雲端。合約文件、客戶個資、內部知識庫，這些受個資法與合規要求約束的資料，現在大家都有了留在地端，資料不出境的選項。

這個系列要做的，已經是我的日常實踐，逐步把這個選項從概念變成一套有興趣的人都可以照著做的架構。

接下來三十天，我會以自己實際在跑的環境為基礎，完整走一遍地端 AI 部署的全流程。

所有的效能資料都會是第一手實測，設定檔也會做說明。

本系列的主角硬體

先讓大家認識接下來三十天會反覆出現的角色。

NVIDIA DGX Spark（GB10）：本系列的運算核心。GB10 Superchip 整合 Blackwell GPU 與 Grace CPU，最大特點是 128GB 統一記憶體，讓 GPU 可以直接定址完整記憶體空間。這代表 70B 模型的 BF16 全精度推論、120B 模型的量化推論、甚至 QLoRA 微調，都能在這台桌面裝置上完成。它的限制也很明確，記憶體頻寬是瓶頸，這會在後面的實測中出現，我們會誠實面對這件事。

QNAP NAS：儲存與模型庫中樞。動輒數十 GB 起跳的模型權重不適合散落在各台機器的本機碟，本系列參考網路上熱門的 NAS 選項，採用 QNAP NFS 跑 ZFS RAID 的集中模型庫架構，所有運算節點掛載同一份模型目錄，版本管理與快取策略會有專文說明。NAS 上另配有一張 NVIDIA RTX 顯示卡，會在特定場景客串演出。

10GbE 網路：串起以上兩者的要角。從 NFS 掛載讀取模型權重時，網路頻寬直接決定模型載入時間，這也是很多人第一次做集中模型庫時踩到的坑。

Proxmox VE 叢集：支援角色。部分周邊服務與實驗環境會跑在虛擬化平台上，讓主力機器專注於推論與訓練負載。

桌機與筆電：我的工作用機器包括 Mac Air M5 24GB 統一記憶體、Intel 12th i5 處理器的桌機 128GB DRAM + NVIDIA RTX 5060 Ti 16GB，也能夠參與到地端 AI 運算的環節中。

先把幾個 AI 名詞講清楚，後面三十天會一直遇到它們

在正式進入地端 AI 的硬體、模型與部署之前，我想先把這個系列會反覆出現的幾個名詞講清楚。因為現在許多關於 AI 的論文或報導文章裡充滿了各種與 AI 相關技術的英文縮寫，如果第一次接觸，很容易看到 LLM、推論、量化、Agent、KV Cache、vLLM、BF16、FP8 一路看到懷疑人生。其實不用把它們想得太複雜，先掌握每個名詞在整套系統裡「負責什麼工作」就夠了。

首先是 LLM（Large Language Model，大型語言模型）。簡單說，它就是負責理解與生成文字的 AI 模型，例如 Qwen、DeepSeek、Llama、Mistral 等。模型本身可以想成一個非常龐大的「數學系統」，裡面有大量參數，也就是大家常看到的 7B、14B、32B、70B、120B。這裡的 B 是 Billion，代表十億個參數。參數越多通常代表模型容量越大，但「參數越多就一定越聰明」並不是絕對成立，模型架構、訓練資料、訓練方法、推論設定與實際任務都會影響最後結果。因此這個系列後面不會單純追求「最大的模型」，而是會反覆討論一個更實際的問題：這個模型對你的工作到底值不值得？

接著是 模型權重（Model Weights）。大家下載的幾十 GB、甚至上百 GB 模型檔，本質上就是模型目前學習到的參數內容。模型架構比較像「大腦的結構」，權重則比較像「大腦裡已經學會的東西」。實際部署時，真正需要放進記憶體的是這些權重，所以模型檔案有多大，會直接影響你的硬體需求。也因此，本系列會一直談到模型放在 NAS、模型從 NFS 載入、模型載入時間，以及模型能不能同時留在記憶體裡。

訓練（Training）、微調（Fine-tuning） 與 推論（Inference） 也必須分開。訓練是讓模型從大量資料中學習，本質上是建立或大幅改變模型能力的過程，微調則是在既有模型上，用特定資料讓它更適合某一種任務、語言或使用方式，推論則是我們平常真正「使用 AI」的階段，也就是把問題丟給已經訓練好的模型，讓它產生答案。一般企業導入地端 AI 時，絕大多數需求其實不是從零訓練模型，而是下載既有模型，進行推論，必要時再做微調。所以後面的系列主力其實會放在推論與部署，到了 Day 25、Day 26 才會進一步進入 Unsloth 微調、模型合併、轉檔、量化與重新上線。

另外一個很容易混淆的詞是 開放權重模型（Open-weight Model）。它不完全等同於「開源 AI」。開放權重通常代表模型訓練完成後的權重可以取得與下載，但模型的訓練資料、完整訓練流程、資料管線或其他元件不一定全部公開。因此看到「Open Model」或「Open-weight」，不能直接理解成所有東西都完全開放。對企業而言，真正重要的還包括模型授權條款能不能商用、能不能修改、能不能再散布，以及是否存在額外限制。這也是為什麼本系列在模型選擇時，不會只看排行榜與 benchmark，而會把授權、部署條件、硬體需求與實際任務一起納入。

再來是 Token（權杖／詞元）。大型語言模型並不是直接用「一個中文字、一個英文單字」這種方式理解文字，而是先把輸入切成模型可以處理的 token。token 是模型進行計算與預測的基本單位。大家看到的「每秒 30 tokens」、「每秒 70 tokens」，講的就是模型生成速度，而上下文長度像 32K、128K、256K，指的則是模型一次可以處理的 token 數量。這也是為什麼後面在談模型效能時，我會使用 tokens/s、首 token 延遲、長上下文效能等指標，而不是只寫一句「這台很快」。

Context Window（上下文視窗） 則可以理解成模型一次能夠「放在桌面上一起閱讀」的資訊量。例如 32K、128K、262K 都是在描述模型可處理的上下文規模。但上下文越長，不代表實際執行成本完全沒有增加。模型需要保存與處理更多上下文資訊，因此會占用更多記憶體，這時就會碰到另一個重要名詞：KV Cache。KV Cache 可以理解為模型在處理對話或長文件時，將已經計算過的一部分中間結果保留下來，避免每生成一個新 token 都從頭重算。對長上下文與 Agent 工作負載而言，KV Cache 可能會吃掉非常可觀的記憶體，因此後面比較不同模型時，我們不只看模型權重大小，也會討論每個 token 到底需要多少 KV 記憶體。

接下來是整個地端部署最常遇到的 VRAM、系統記憶體與統一記憶體。傳統 NVIDIA 顯示卡的 VRAM 是 GPU 自己的高速記憶體，模型要在 GPU 上運算，通常需要把模型權重以及推論過程需要的資料放進 VRAM。這也是為什麼一張 16GB 顯示卡能不能跑某個模型，常常第一個問題就是「模型塞不塞得進 16GB」。而像 DGX Spark、Apple Silicon 或部分 AMD 平台採用的 Unified Memory（統一記憶體），則是 CPU 與 GPU 共同使用同一個大型記憶體空間。它最大的優勢就是「容量大、CPU 與 GPU 不需要各自準備一份完整資料」，因此像 128GB 統一記憶體的平台，可以把原本需要資料中心等級記憶體的模型帶到桌面環境。不過統一記憶體並不代表「記憶體大就一定快」，記憶體頻寬、資料搬移、CPU/GPU 協同以及軟體支援都會影響實際效能，這正是 Day 2 後面會深入拆解的問題。

量化（Quantization） 則是讓大型模型更容易落地的另一個關鍵技術。最簡單的理解方式，就是把模型參數從比較高精度的數字格式，轉換成比較低位元的表示方式，藉此大幅降低模型占用的記憶體與頻寬需求。例如大家常看到的 FP16、BF16、FP8、INT8、INT4、FP4 等格式，本質上就是不同的數值表示方式。量化之後，模型通常會變得更省記憶體、也可能更快，但代價是可能犧牲部分精度，尤其是不同模型、不同語言與不同工作負載的敏感程度不一樣。因此「4-bit 一定比 8-bit 好」完全不是正確的觀念。Day 12 會專門把量化格式拆開來比較，也會進一步討論為什麼同樣寫著 4-bit，實際上可能是完全不同的技術與結果。

推論引擎（Inference Engine） 是「負責把模型真正跑起來的軟體」。模型檔本身不是一個完整的服務，你不能單純把一個幾十 GB 的模型檔丟進電腦，就期待它自己開始工作。推論引擎會負責模型載入、記憶體管理、GPU 計算、batch、KV Cache、量化支援以及 API 服務等工作。本系列會實際比較 llama.cpp、vLLM、TensorRT-LLM、Ollama 等不同工具，也會談到 DS4、Unsloth 在整體工作流程裡扮演什麼角色。它們不是完全相同層級的產品，因此不能只用「誰最快」來決定該用誰，而要看你是做單機聊天、API 服務、多人並發、模型微調，還是 Agent。

這裡再補一個很重要的名詞： API（Application Programming Interface） 。API 可以把它想成 AI 模型的「服務入口」。當模型透過 API 提供服務後，其他程式、網站、Agent 或企業系統就不需要直接理解模型內部怎麼運作，只要按照 API 規格把問題送進去，再接收模型輸出即可。這也是為什麼本系列後面會建立 OpenAI 相容 API 層。所謂「OpenAI 相容」，不是說我們真的在使用 OpenAI 的模型，而是讓地端模型提供類似的 API 格式，讓既有的工具可以比較容易接上自己的本地模型。這一步很重要，因為當 AI 從「我在自己的電腦上聊天」變成「公司裡有很多系統需要呼叫 AI」，API 就從方便的功能變成基礎架構的一部分。

然後就會進入這幾年最熱門的 Agent（AI Agent） 。Chatbot 通常是「你問一題，它答一題」，Agent 則更接近「給它一個目標，它自己拆解工作、使用工具、讀取資料、執行指令，再根據結果繼續下一步」。例如讓 Agent 讀 GitHub issue、修改程式、執行測試、檢查結果，再決定下一步怎麼做。Agent 因此不是單純換一個更大的語言模型，而是一整套「模型＋工具＋記憶＋工作流程＋權限控制」的系統。這也是為什麼 Day 19 開始，本系列的焦點會從單純的模型推論，逐漸轉向 Agent framework、Harness、多 Agent 協作與端點控制。

Harness 可以把它理解成 Agent 的「工作框架」。模型本身只負責推理與生成內容，但如果要真的讓 AI 操作 Shell、Git、檔案、瀏覽器、API 或其他工具，就需要另一層軟體把這些能力接起來。Harness 通常會處理工具呼叫、上下文管理、工作流程、錯誤處理與人工確認等問題。所以後面看到 DeepSeek Harness、OpenCode、Qwen Code、herdr 等名稱時，不要把它們全部當成「模型」，它們可能是模型上面的代理執行環境，扮演的是完全不同的角色。

最後是 RAG（Retrieval-Augmented Generation，檢索增強生成）。它的概念是不要要求模型把所有企業知識都「背」進參數裡，而是在使用者提問時，先從企業自己的文件、資料庫或知識庫找到相關內容，再把這些內容交給模型回答。換句話說，模型負責理解與生成，RAG 負責把「對的資料」找出來。這對企業地端 AI 非常重要，因為很多公司真正需要的不是一顆什麼都知道的超大模型，而是一顆能夠安全讀取「自己的文件、自己的規範、自己的知識庫」的模型。

把這些名詞串起來，其實就可以得到一個很簡單的地端 AI 架構：模型是大腦，模型權重是大腦裡的知識，GPU／NPU／CPU 是計算資源，VRAM 或統一記憶體是工作空間，推論引擎負責把模型跑起來，API 負責把能力提供給其他程式，RAG 負責把企業自己的資料找進來，Agent 負責把模型從「回答問題」變成「完成工作」，而 Harness 與權限控制則負責管理 Agent 到底可以做什麼。

所以這三十天真正要研究的，從來不只是「哪一顆 AI 模型最強」。我們要看的其實是一整條鏈：硬體能不能承受、模型選得對不對、量化是否合理、推論引擎是否適合你的用途、API 是否能提供服務、Agent 是否能穩定工作、資料是否能安全留在地端，以及最後這套系統能不能維運、監控、更新與稽核。 這也是為什麼本系列會從 GB10、10GbE、NFS 一路談到 llama.cpp、vLLM、TensorRT-LLM，再一路走到 Agent、Harness、ComfyUI 與模型微調。

因為真正的地端 AI，從來不是把一個模型「跑起來」就結束了，而是把模型變成一套可以長期使用的 IT 基礎架構才算是落地。

為什麼是地端，而不只是本機呢?

這裡先定義一個貫穿全系列的觀念。很多地端 AI 的教學停在在自己電腦上跑起來，但一套能進入企業環境的地端 AI 架構，要處理的事情不少呢，比方說模型權重要放哪裡、多台機器怎麼共用、服務掛了誰知道、電費划不划算、稽核的時候拿什麼出來給人看等等。

本機能跑是部署地端 AI 的起點，而可維運、可複製、可稽核是我們的終點。這個系列的每一篇，都會盡量同時照顧這兩個層次，提供能執行的指令，也說明這些選擇在我在實作架構中的理由。

OpenModel Selector｜AI 開放模型選擇決策與硬體搭配矩陣
OpenModel Selector｜AI 開放模型選擇決策與硬體搭配矩陣專案連結
繁中 Agent 考卷專案連結

明天預告

Day 2 我們從運算核心開始，深度解析 DGX Spark 與 GB10 架構：統一記憶體到底解決了什麼問題、它與傳統獨立顯卡的 VRAM 有什麼本質差異、以及規格表上那個「1 PFLOPS」數字該怎麼正確解讀。

我們明天見囉。

Day 1｜為什麼 2026 年是地端 AI 部署元年：系列規劃與硬體總覽
Day 2｜DGX Spark GB10 深度解析：128GB 統一記憶體到底解決了什麼問題
Day 3｜網路與儲存規劃：10GbE 骨幹、雙 Spark 直連與 NFS 集中模型庫
Day 4｜開箱之後：DGX OS 初始環境建置與 CUDA、Docker 生態確認
Day 5｜NFS 模型庫實戰：下載工具、權限設計與版本管理
Day 6｜llama.cpp、vLLM、TensorRT-LLM 、Ollama、DS4 與 Unsloth 的定位與取捨
Day 7｜第一個模型上線：gpt-oss-120b 從模型庫到 API 的完整流程
Day 8｜llama.cpp 實測：先定量尺與 SOP
Day 9｜vLLM 實測：官方容器、同時處理吞吐曲線，與剛出爐的新模型 Ornith 1.5
Day 10｜TensorRT-LLM 實測：我花了一個下午，跟它的預設值搏感情
Day 11｜地端 AI 三大推論引擎綜合評測，同場加映神秘嘉賓
Day 12｜量化格式解析：「4-bit」兩個字，古今多少事 ? 都付笑談中
Day 13｜Perplexity 把整套 Agent 搬上 DGX Spark：地端元年的官方背書
Day 14｜Qwen3.8-27B 與 Flash-Next 加碼實測：地端模型世代對決與落地評估
Day 15｜Ornith 1.5 實測：為 AI agent 而生的 35B-A3B
Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型
Day 17｜ds4 深度解析：Redis 之父只為一種模型造了一個引擎
Day 18｜OpenAI 相容 API 層：地端 AI 多模型常駐好助手
Day 19｜地端 agent 框架總覽：它們到底對你的端點做了什麼呢?
Day 20｜DeepSeek Harness 實戰：21 萬顆星的外掛式 harness 接上地端
Day 21｜herdr 是地端 AI 同時跑多個 AI agent 的最佳解
Day 22｜語意錨點對上 prefix cache，FreeToken VS vLLM，以及三個關於統一記憶體的教訓
Day 23｜ComfyUI 部署與 NFS 模型庫整合：把集中管理的哲學帶進生圖世界
Day 24｜MiniMax-H3 地端影片生成：h3-ui 與四步蒸餾版的三段對決
Day 25｜Unsloth 微調實戰：教一款模型用繁體中文思考，並遵守台灣的編輯規範
Day 26｜微調的最後一哩路：合併、轉檔、量化、上線
Day 27｜雙 DGX Spark GB10 合體與分工合作的部署與實測