ARTICLE / 00208 章節

本地 AI 不只是下載模型：從 Hugging Face、Ollama 到 llama.cpp。

從 Hugging Face 下載模型，經過 Ollama 的低門檻入口，再深入 llama.cpp、GGUF、VRAM 與 Context，記錄我怎麼把本地 AI 接到真正的工作。

Local AI
量化
環境

我並不是每次都從 Ollama 拿模型。很多時候我會直接在 Hugging Face 找到模型或 GGUF 檔案，再決定用哪個 runtime；Ollama 的價值是把下載、管理和本機 API 做得容易，適合先跨過第一個門檻。

等我開始在意量化格式、Context、顯卡記憶體和實際執行方式，研究就往 llama.cpp 和 GGUF 走。這時候模型來源、檔案格式、runtime 和上層 Agent 要分開看，不能把『模型能跑』當成『工作能完成』。

我的主要環境是 Windows 桌機、RTX 3080 Ti、64GB RAM 與 SSD。研究 Qwen3.8-27B 這類模型時，我會一起看權重大小、KV cache、Context 與其他程式留下的空間；SSD 只改善檔案和 cache 的讀寫，不會替顯卡增加 VRAM。

設定簡單之後，才看得到下一個問題。概念圖

01
準備
把模型準備好
02
執行
讀寫與工具
03
確認
工作能否繼續

一開始我很容易只看模型檔案大小。壓小之後看起來接近 VRAM 容量，就覺得應該能用了。但執行時還有 KV cache、工作空間和暫存，Windows 與其他程式也要用顯卡。

Agent 會累積檔案、差異、工具說明和終端機輸出。Context 變長、session 變多，我遇過記憶體慢慢上升、桌面卡頓，嚴重時還有 driver reset 和 Windows freeze。這些是我的環境裡發生的事，不是每個配置都會如此。

現在我會留 headroom，不把規格能開的 Context 一次開滿。先確定一個工作能穩定結束，再增加長度或同時工作的數量，對我比較實際。

Weights、KV cache、執行空間要分開算。概念圖

步驟	權重	Context	餘裕
模型本體	包含	不含	不含
KV cache 預算	不含	包含	不含
執行環境與其他程式	不含	不含	包含

Q4_K_M、Q8 和 IQ 系列，是我研究 GGUF 時常遇到的選項。我原本很直覺地照 bit 數排高低，後來才開始看格式、runtime 支援和實際還剩多少記憶體。

IQ3 這類比較小的版本很吸引我，因為大的模型似乎終於靠近手上的硬體。但省下權重空間之後，Agent 還是要讀很長的 Context。不能把下載檔比較小，直接當成長時間工作比較穩。

我會把 llama.cpp / GGUF 當作研究的基準，再比較不同組合。這不是已完成的量化排名；下一輪想固定任務，看看哪一個是真的改完、測完，而不只是回答得順。

容量: 權重與剩餘空間
支援: runtime 能否使用
完成: 能否完成同一任務

後來研究到 AWQ、GPTQ 和 QAT，我才發現「量化」不是只看一個 4-bit 標籤。不同方法處理量化誤差的方式不同，最後還要看格式是否被目標 runtime 支援。

我也會直接比較 Hugging Face 上的原始權重與 GGUF。Unsloth 的 Qwen3.8-27B-GGUF 是一個很具體的例子：它提供已經量化好的 Qwen3.8-27B 檔案，讓我可以把注意力放在檔案大小、可用記憶體和執行方式，而不是把『量化』只當成理論名詞。

這不代表我把 Unsloth 當成一個獨立 Harness，或聲稱自己完成了訓練與性能排名。對我來說，它更像是取得與比較量化模型的一條路；下載之後，仍要交給 llama.cpp、vLLM 或其他推理環境，才知道它是否適合手上的工作。

方法: AWQ / GPTQ / QAT
數值格式: FP8 / NVFP4
執行: 確認 runtime 與 GPU

Prefill 是讀進提示和 Context，Decode 是接著生成。TTFT 則是開始到第一個 token 出現的等待。對我來說，只看到輸出後很快還不夠，前面等很久，也會打斷工作的節奏。

Agent 每次讀檔、跑工具之後，還要把新的內容帶回下一步。下一輪我想分開記載入、讀入、第一個輸出與生成速度，再看 Context 變長後的等待。不把這些不同階段合成一個 tokens/s。

載入、Prefill、TTFT、Decode 分開記。概念圖

01
載入
模型準備
02
Prefill
讀入提示與 Context
03
Decode
記錄 TTFT 與生成

NInfer 讓我注意特定模型、硬體和 runtime 配合的路線；Strata 則讓我去想，模型放不進 GPU 時，整台電腦的資源能怎麼分工。我的興趣從挑模型，慢慢走到推理環境怎麼安排。

這兩條是研究方向，不能拿專案展示的速度當成我這台 Windows 桌機的成果。部署工具也要跟著硬體調整；我會在 Ollama、llama.cpp / GGUF、LM Studio、vLLM 等路線之間比較啟動、API、Context、工具呼叫與穩定性。這些是研究中的配置，不是同一套已完成的部署。

研究方向和自己測出的結果分開。概念圖

NInfer

研究特定配置的執行

Strata

研究整台電腦的分工

我想固定同一個 repository、task 和 test，再換模型、量化、runtime 或 harness。一次只動一個主要條件，比把幾個完全不同的環境放一起看更容易知道差在哪。這是接下來的測試計畫。

除了時間和記憶體，我還想看工具呼叫對不對、改了什麼、測試有沒有真的跑、需不需要人工救援。最後結果能不能用，比模型產生多少文字更接近我每天的需求。

從說話速度，回到工作的結果。概念圖

01
固定
repo、task、test
02
觀察
時間、資源、工具
03
確認
結果是否可用

我現在用四個位置整理本地 AI：先是模型檔案，再是把模型跑起來的 runtime；需要讓其他程式呼叫時，才加上 API 或服務；最後才是 Harness，負責讀專案、叫工具、維持 Context、處理權限，並把結果帶回驗收。這些是工作流程裡不同的角色，不是同一張產品排行榜。

我的模型來源不只一個。Hugging Face 適合直接找原始權重或 GGUF；Ollama 是比較容易開始的下載、管理與本機 API 入口；llama.cpp 讓我深入研究 GGUF、量化和 GPU 執行；vLLM 則比較像面向服務與吞吐的推理引擎。llama.cpp 自己也能提供 server API，所以「服務」是部署時的角色，不是一定要另外裝一個產品。

OpenCode 和 Codex 是我真正拿來做事的主力。Pi、DeepSeek Harness、MiniMax Code 等則是我用來研究設計差異的工具；我會看它們怎麼接模型、怎麼處理 Context 與工具，但不把測試性的接觸寫成日常工作經驗。

MODEL: 模型權重本身
RUNTIME: llama.cpp、GGUF、推理
SERVICE: Ollama、vLLM、API
HARNESS: Context、工具與驗收

本地 AI 不只是下載模型：從 Hugging Face、Ollama 到 llama.cpp。

Ollama 是入口，但模型不只從這裡來。

檔案放得下，還不代表可以放心跑。

Q4、Q8、IQ，得回到同一個工作看。

AWQ、GPTQ、QAT，不是名字越多越厲害。

不是只看輸出多快，也看多久才開始。

研究到 NInfer、Strata，問題又往下一層走。

下一步，拿同一個任務一路做到結束。

把模型、Runtime、服務與 Harness 分開。