前幾天，我們一路看了 OpenAI、Google 與 Claude 的工作流。它們有一個共同點：大部分真正強大的模型都跑在雲端。我們把提示（Prompt）、文件或程式碼送出去，遠端的模型算完，再把結果送回來。
這種方式非常方便，你不用管 GPU、模型安裝或記憶體。但用久之後，就會慢慢發現，並不是每一件事情都需要把最強的雲端模型請出來。
例如我有一個工具，會把 YouTube 影片的逐字稿抓下來，再整理成摘要；另一個則是把學術文章翻譯成中文。這些工作會重複執行，而且我大致知道輸出應該長什麼樣子，有些錯字或不通順的地方，也不會影響我對它們的理解。因此，這個程序不需要每一次都呼叫最昂貴、推理能力最強的模型。
這時候，本機模型（Local LLM）就開始有吸引力了。
今天不打算把 Ollama 寫成安裝教學，而是回答三個問題：
我的電腦大概可以跑多大的模型？哪些工作適合留在本機？本機模型到底是在省 API 錢，還是在換一種工作方式？
如果 Hugging Face 比較像模型的大型倉庫，那 Ollama 可以先想成：
把模型下載回來，幫你在自己的電腦上跑起來的一套工具。
安裝完成之後，可以直接：
ollama run gemma4:26b
或：
ollama run qwen3.8:27b
模型就會開始在自己的電腦執行。
更重要的是，Ollama 不只能在終端機裡聊天，也能讓 Claude Code、Codex 等工具改用本機模型。這不是把 Codex 或 Claude Code 塞進 MacBook 裡，而是讓它們改去敲本機模型的門。
第一次進 Ollama Library 或 Hugging Face，很容易看到：
4B
8B
14B
27B
32B
70B
122B
然後直覺覺得：
數字越大，一定越強，那我就下載最大的。
幾分鐘後，電腦風扇和人生選擇會一起開始反省。
模型後面的 B 代表 Billion，也就是十億個參數。可以先把參數想成模型裡一大張「數字表」：模型回答問題時，會不斷拿輸入文字和這張表做數學計算。數字表越大，通常越需要記憶體；不過模型的實際大小還會受到量化與你一次放進多少文字影響，所以不存在「32GB 記憶體一定只能跑 14B」的絕對公式。少數 MoE 模型每次生成只會啟用部分參數，但載入模型時仍得考慮整體權重，不能只看「這次有幾個參數上班」。
但如果只是第一次選模型，可以先用下面這張非常粗略的表當起點：
| 模型級距 | 常見 Q4 版本大小 | 建議的整機記憶體起點 | 適合感覺 |
|---|---|---|---|
| 3–4B | 約 2–4GB | 8–16GB | 快速分類、短摘要、簡單工具 |
| 7–9B | 約 5–7GB | 16GB | 日常聊天、翻譯、資料整理 |
| 12–14B | 約 8–10GB | 16–24GB | 品質與速度較平衡 |
| 27–32B | 約 17–20GB | 32–48GB | 較好的推理、翻譯與專業工作 |
| 70B 左右 | 通常 40GB 以上 | 64–96GB 以上 | 高記憶體工作站較實際 |
這張表只能當「先去哪一區找模型」的地圖，不是硬體保證書。真正跑起來時，作業系統、一次輸入的文字長度、圖片輸入，以及你同時開著的 Chrome 那 66 個分頁都要吃記憶體。
所以「模型 20GB、RAM 48GB，因此還剩 28GB」不是精確公式。電腦的會計制度沒有那麼單純。
想查自己的電腦大概適合哪些本機模型，也可以看看 local.ai。先去登記一個屬於自己的頁面名字後，就可以偵測自己的電腦適合什麼樣的模型。
前面表格裡的「常見 Q4 版本大小」是什麼？為什麼同樣標示 27B 的模型，下載大小卻可能差很多？因為模型除了參數數量，還有一個會直接影響檔案大小與記憶體的因素：量化。
Transformer 本質上會做大量數學計算，而計算時最常用到的，就是剛才那張參數數字表。原始模型會把每個數字存得很精細，例如用 16-bit 浮點數記錄；量化（Quantization）則是用較少的位元，保存一個近似的數字。
可以把原本的 0.1374 想成記到小數點後四位；量化後可能只留下足夠接近的 0.14。單看一個數字差異很小，但模型裡有數百億個數字，全部都少用幾個位元，檔案大小和執行時需要的記憶體就會大幅下降。
所以量化不是把模型的參數刪掉，也不只是把檔案丟進 ZIP 壓縮；它是把模型拿來算數的數字，換成較省空間、精度較粗的表示法。f16、q8_0、q4_0 是常見標記：數字越低，通常越省記憶體；但每一次計算都多了一點近似，品質也越可能下降。
Ollama 官方文件給的粗略比例是：q8_0 約使用 f16 一半的記憶體，q4_0 約使用四分之一。可以把它想成圖片壓縮：適度壓縮通常看不太出來；壓得太狠，整張臉開始像 Minecraft。模型也是在找這個平衡。
對一般個人電腦而言，Q4 常常是一個務實的起點：模型比較放得下，速度也合理，品質損失未必會破壞摘要、翻譯這類可驗收的任務。不過到底 Q4、Q8 還是 MLX 格式比較適合，仍要拿自己的工作測。
無需為了追求「最高精度」下載一個模型，結果每產生一個 Token 的時間都可以去泡一杯咖啡。
以我現在的機器為例，我使用的是 Mac M4 Pro、48GB Unified Memory。
以我實際安裝的模型來看，gemma4:26b-mlx 和 qwen3.8:27b 都約 18GB。這個級距對 48GB Unified Memory 來說，通常還能留出空間給 macOS、執行模型的程式與一次輸入的內容。
但這裡很容易踩另一個坑。
Gemma 和 Qwen 的模型頁面都標示了很長的脈絡（Context）能力，Qwen3.8 27B 也支援 262K。
這不代表我應該直接把脈絡拉到 262K。
Ollama 官方也特別提醒：
脈絡長度拉得越長，需要的記憶體就越多。
所以「模型支援很長的脈絡」和「你的電腦適合每次都開到上限」是兩件不同的事情。
這又回到 Day 12、Day 13：脈絡不是越大越好。
本機模型最適合的，不一定是「最重要」的工作，而是符合下面大多數條件的工作：
符合這四點，就很值得先試本機模型。
我自己的一個例子，是 YouTube 影片摘要工具。
流程大概是：
YouTube URL
↓
取得字幕／逐字稿
↓
切分文字
↓
本機模型
↓
產生摘要、重點與時間線
↓
存成 Markdown
取得 YouTube 字幕這一步當然仍可能需要網路，但真正會反覆消耗大量 Token 的「整理逐字稿」可以留在本機。
如果一支影片有兩萬字，我只是希望整理主要論點、案例、名詞與摘要，不一定需要每次都呼叫推理能力最強的雲端模型。
另一個我自己常用的，是 學術文章翻譯。
原始 PDF 先轉成比較乾淨的 Markdown，再按照段落或章節切開，交給本機模型翻譯，同時固定一些規則：
專有名詞第一次出現保留英文
不要自行摘要
公式不要改寫
Figure / Table 編號維持原樣
引用格式不要翻譯
這類工作量大，但判斷標準清楚，翻錯了也有原文可以對。通常就是人需要休息的時候，再去做這些佔用電腦記憶體的工作就好。
如果工作內容包含尚未公開的研究資料、公司內部文件、學生作業或其他敏感資訊，本機執行還有一個很直覺的價值：
資料不一定需要送到第三方模型服務。
Ollama 可以只在本機執行；LM Studio 也可以完全離線工作，只要模型事先下載好。
但不要把「本機」自動等同於「絕對安全」：自己的程式仍可能連外，下載的軟體也可能有風險。資料留在本機，不等於它從此穿上隱形斗篷。真正的安全要看整個工作流程；至少在模型回答這一層，你有能力把資料留在自己的機器裡。
本機模型很有趣，但我不會把它變成另一種信仰。
如果我要查今天最新的政策、新聞或模型價格，本機模型沒有搜尋工具就不會突然通靈。
如果是非常複雜的程式架構、高風險專業判斷，或我需要目前最強的推理能力，我還是會直接用雲端模型。
如果任務需要超長的輸入內容、複雜的圖片與文字理解，或大量外部工具，我也會先考慮雲端產品是否已經把環境做好。
所以本機模型並不是：
ChatGPT 太貴，我自己下載一個就全部取代。
比較像公司裡有兩種人：雲端模型像外部高階顧問，本機模型則像公司自己養的固定助理。重要又困難的問題請顧問；每天整理 300 份資料，就不必每一份都打電話給顧問。主要是帳單會先有意見。
這一段是進階預告，第一次接觸本機模型可以先知道結論：資料會更新時，優先放文件給模型查；想改變模型的回答習慣時，才考慮微調。
本機模型還有另一個很吸引我的方向：
如果我的工作很特殊，能不能讓模型更習慣我的領域？
這就會碰到 Fine-tuning（微調）。
前面我們一直透過提示與脈絡告訴模型「現在該知道什麼」。Fine-tuning 是用資料更新模型的權重，讓它在某種任務或輸出風格上形成比較穩定的行為。對個人硬體而言，更常見的是 LoRA：它只訓練少量額外參數，不必重練整個模型。
重新訓練 27B 模型的所有參數，比較像決定在家煉鋼；若真的要試，通常會從 LoRA（Low-Rank Adaptation） 或 QLoRA 開始。Apple 的 MLX-LM 目前就支援在 Apple Silicon 上進行 LoRA／QLoRA 微調。
例如我的領域是地球科學，就可以整理高品質樣本，讓模型更熟悉地科專有名詞中英對照、論文翻譯寫法、研究摘要欄位與固定問答風格。
但這裡有一個很重要的界線。
如果目標是：
「讓模型知道我公司 2026 年最新 SOP。」
這通常不應該第一個想到 Fine-tuning。
因為 SOP 會更新，而且你還會希望知道答案來源。
這種知識更適合 RAG、文件檢索或直接放進脈絡。
LoRA 更適合處理：
我要模型「怎麼回答」變得比較像我要的方式。
RAG 比較像給員工最新手冊；這個系列暫不展開。
LoRA 比較像重新訓練這位員工的工作習慣。
手冊改版，不需要把員工送回訓練中心重新投胎。
今天標題寫 Ollama，只是因為它對我來說是一個很方便的入口。
本機模型的世界其實比 Ollama 大很多，但第一次不用全部研究。喜歡圖形介面的話，可以試 LM Studio；想找模型，可以去 Hugging Face。如果之後想在 Apple Silicon 上做更進階的調校，再回頭看 MLX / MLX-LM 就好。
可以先這樣想：
Hugging Face
＝ 去哪裡找模型
Ollama / LM Studio
＝ 怎麼把模型跑起來
它們之間當然有大量重疊，但對初學者先這樣分，比較容易知道自己正在解哪一個問題。
第一次看到本機模型，很容易先被「不用每個 Token 都付 API 費」吸引。但用久之後，我覺得更重要的價值其實不是省錢，而是：
控制權。
我可以決定模型放在哪裡，也可以決定什麼資料不離開電腦；代價則是模型選擇、硬體與更新，要自己多管一些。
所以我不覺得未來會變成：
本機模型 vs 雲端模型
只能選一個。
我自己比較像：
高頻、可驗收、固定流程
→ 本機
高難度、最新資訊、關鍵決策
→ 雲端
介於兩者之間
→ 先看這周雲端模型的用量還有多少，再來決定
AI 時代真正有趣的地方，可能不是找到一顆「什麼都做」的模型。
而是我們開始可以像選工具一樣，決定：
這件工作值得用多少算力？需要多少智慧？資料應該放在哪裡？
前幾天我們學的是在不同公司的工具之間切換。
到了本機模型，模型本身也開始變成可以切換的零件。
明天，我們就接著處理這個工作流程裡一直出現、但還沒有單獨拆開的東西：API Key。當我們不再只使用別人做好的聊天機器人，而是開始把模型接進自己的程式時，API Key 到底扮演什麼角色？而本機 API 又和雲端 API 有什麼不同？
iThome鐵人賽
看影片追技術