ollama on mac - part 2 - 公開模型全覽與選型指南

大多數人第一次用 Ollama:直接 ollama pull 最大的那個模型,結果風扇狂轉、記憶體爆掉、每個 token 都要等半天。

資深工程師的做法:先看硬體能承受多大、再看任務需要什麼能力、最後用量化把尺寸壓進記憶體。

選對「尺寸 + 量化 + 任務」的 8B 模型,體感往往勝過硬撐一個跑不動的 70B。

Part 1 我們裝好了 Ollama,也跑起了第一個本地模型。這一篇要解決的是所有人接下來立刻會撞到的問題:模型這麼多,到底該選哪一個?

Ollama 官方模型庫裡有數十個家族、上百個 tag,尺寸從 1B 到 70B+、量化從 Q4 到 fp16、能力從純文字到多模態、從對話到推理。如果沒有一套選型框架,你只會反覆下載、反覆刪除,浪費頻寬也浪費時間。

這篇文章的目標,是給你一套可重複使用的選型心智模型,讓你面對任何新模型都能三秒鐘判斷「這個能不能在我的 Mac 上跑、值不值得跑」。

一、選型心智模型:硬體 → 任務 → 量化

在打開 ollama.com/search 之前,先在腦中建立一個三層漏斗。順序不能顛倒:硬體決定你的「上限」,任務決定你的「方向」,量化幫你在上限內「塞進最大的模型」。

                    ┌──────────────────────────────┐
   第一層           │  1. 硬體 (Hardware)           │
   決定「上限」      │  你的 Mac 有多少 RAM?         │
                    │  → 決定模型參數量的天花板       │
                    └───────────────┬──────────────┘
                                    │  篩掉所有跑不動的尺寸
                                    ▼
                    ┌──────────────────────────────┐
   第二層           │  2. 任務 (Task)               │
   決定「方向」      │  對話?寫程式?看圖?推理?RAG? │
                    │  → 決定模型家族與變體           │
                    └───────────────┬──────────────┘
                                    │  篩出 2-3 個候選家族
                                    ▼
                    ┌──────────────────────────────┐
   第三層           │  3. 量化 (Quantization)       │
   「塞進上限」      │  Q4 / Q5 / Q6 / Q8 / fp16     │
                    │  → 在 RAM 上限內選最大尺寸      │
                    └───────────────┬──────────────┘
                                    ▼
                          最終選定的 model:tag

為什麼是這個順序?

• 硬體先行:再好的模型,RAM 不夠就是跑不動(或狂用 swap 慢到不能用)。與其下載完才發現跑不動,不如一開始就用 RAM 篩掉不可能的選項。這對齊了 Part 1 提到的 RAM 規則。
• 任務其次:硬體上限內,不同任務有不同的「最適家族」。寫程式該用 coder 模型,看圖該用 vision 模型,硬套通用對話模型只會事倍功半。
• 量化最後:確定家族與尺寸後,量化是最後的微調旋鈕——它讓你在固定 RAM 內,決定要「更大但更粗」還是「更小但更精」。

記住這句話:一個跑得順的 8B,永遠贏過一個卡成幻燈片的 70B。 接下來三個章節,我們就照這個漏斗一層層拆解。

一張圖看懂完整決策樹

把三層漏斗展開成實際操作時的決策樹,你會更有感覺:

                        「我要選一個模型」
                               │
                ┌──────────────┴──────────────┐
                ▼                              ▼
         RAM ≤ 8GB?                        RAM ≥ 16GB?
                │                              │
       主力 3B 級                    ┌─────────┴─────────┐
    (llama3.2:3b /                   ▼                   ▼
     gemma3:4b)                  任務是什麼?          RAM ≥ 32GB?
                          ┌──────────┼──────────┐        │
                          ▼          ▼          ▼    可上 14B–32B
                       對話       寫程式      推理    (qwen3:32b /
                    qwen3:8b  qwen2.5-coder deepseek-r1  gemma3:27b)
                    llama3.1    :7b/:14b     :7b/:14b
                       │                                  │
                       └──────────────┬───────────────────┘
                                      ▼
                            RAM 還有餘裕?
                          ┌─────────┴─────────┐
                          ▼                   ▼
                    升量化 Q5/Q6/Q8      維持預設 Q4_K_M
                    (品質更好)           (最省、最通用)

這張圖就是本篇的濃縮版——後面每一章都是在把某個分支講清楚。建議看完全文後回頭再看一次這張圖。

二、模型家族全覽:六大主流開源家族

先建立地圖。截至 2026 年中,Ollama 上真正值得你認識的開源家族有六個。每個家族都有自己的性格與擅長領域。

各家族速寫

• Meta Llama(llama3.1 / llama3.2 / llama3.3):通用能力的「基準線」,生態最成熟,教學文件與整合範例最多。llama3.2 有 1B/3B 的小尺寸適合輕量裝置;llama3.3:70b 則是接近旗艦級的通用大模型。支援 tools。授權為 Llama Community License(有月活用戶上限條款,個人與多數商用無虞,但超大型服務需留意)。

• Alibaba Qwen(qwen3 / qwen2.5 / qwen2.5-coder / qwen3-embedding):2025-2026 開源界的性價比之王,中文能力特別強,尺寸選項最齊全(0.6B 到 32B+)。qwen3 支援 tools 且內建「think mode」可切換推理。qwen2.5-coder 是本地寫程式的首選之一。多數採 Apache 2.0,商用友善。

• Google Gemma(gemma3):輕量高效,同尺寸下品質扎實,gemma3 提供 1B/4B/12B/27B 且部分尺寸支援 vision。適合資源有限但要求輸出品質的場景。授權為 Gemma Terms(相對寬鬆但有使用政策)。

• Mistral(mistral / mistral-nemo / mixtral / mistral-small):歐洲團隊,mistral:7b 是經典的高效通用模型,mixtral 是 MoE 架構(推理時只啟動部分參數),mistral-nemo 上下文較長。支援 tools。多數為 Apache 2.0,商用最無痛。

• Microsoft Phi(phi4):「小而精」路線,用高品質資料訓練出超越尺寸的表現,phi4 約 14B 卻在推理與程式上表現亮眼。適合中階 Mac。MIT 授權,極度商用友善。

• DeepSeek(deepseek-r1 / deepseek-v3):deepseek-r1 是開源推理模型的代表,會「先思考再回答」,數學與邏輯題表現突出,有 1.5B/7B/8B/14B/32B/70B 等蒸餾版本可選;deepseek-v3 是超大通用模型(本地通常跑不動,見第九章雲端方案)。

家族對照表

授權提醒:如果你要做商用產品,Apache 2.0 / MIT(Qwen、Mistral、Phi)最安心;Llama 與 Gemma 各有自己的授權條款,個人與中小型商用多半沒問題,但大型服務上線前務必讀清楚原始授權文字。本文的授權說明僅供入門參考,不構成法律意見。

該從哪個家族入門?

如果你完全沒有頭緒,這裡是我給不同人的一句話建議:

• 一般台灣使用者(需要中文) → 從 Qwen 開始(qwen3:8b)。中文最強、選項最齊、授權最寬鬆,幾乎是萬用起手式。
• 英文為主、想跟教學/整合範例對齊 → Llama(llama3.1:8b)。網路上絕大多數 tutorial 都用 Llama,遇到問題最好查。
• 8GB 小機器 / 追求輕量 → Gemma(gemma3:4b)或 Llama(llama3.2:3b)。
• 要接商用產品、怕授權麻煩 → Mistral / Phi(Apache 2.0 / MIT)。
• 主要拿來解數學、寫演算法、需要推理 → DeepSeek(deepseek-r1)。

別一次全裝。 先挑一個主力家族用熟,理解它的脾氣(輸出風格、速度、context 行為),再依需求增加專用模型(coder、vision、embedding)。廣度不等於效率,一個你摸透的 8B 比五個你沒用過的模型有價值得多。

MoE 是什麼?為什麼 mixtral:8x7b 不是 7B

順帶澄清一個常見誤解。mixtral:8x7b 是 MoE(Mixture of Experts,混合專家) 架構:它有 8 個「專家」子網路,每次推理只啟動其中 2 個。

   一般 Dense 模型 (7B)          MoE 模型 (mixtral 8x7b)
   ┌──────────────┐             ┌───┬───┬───┬───┐
   │  全部 7B 參數 │             │ E1│ E2│ E3│ E4│  共約 47B 參數
   │  每次全用     │             ├───┼───┼───┼───┤  (要全部載入記憶體!)
   └──────────────┘             │ E5│ E6│ E7│ E8│
                                └───┴───┴───┴───┘
   RAM ≈ 5GB                    每次只啟動 2 個專家
   推理:用全部參數              → 速度接近 ~13B
                                → 但 RAM 要裝全部 ≈ 26GB+

重點取捨:MoE 的推理速度接近小模型(只算被啟動的專家),但記憶體佔用接近它的總參數量(所有專家都得載入 RAM)。所以 mixtral:8x7b 雖然名字有「7b」,實際需要約 26GB+ RAM——別被名字騙了,pull 前一定先 ollama show 或看模型頁的實際大小。

三、讀懂模型名稱與 tag

Ollama 的模型命名有固定文法,看懂了就能從名稱直接判斷一半的資訊。

                    qwen2.5-coder : 7b-instruct-q4_K_M
                    └─────┬─────┘   │  └───┬───┘ └──┬──┘
                        家族+版本    尺寸  變體      量化後綴
                     (family)     (size)(variant)(quantization)

拆解各部位:

• <family>(家族與版本):llama3.2、qwen3、gemma3。數字通常是世代版本,越新越好。qwen2.5-coder 這種帶後綴的是「專門化變體」(此處是程式專用)。

• <size>(尺寸):3b、7b、8b、14b、70b,單位是 billion(十億參數)。這是決定 RAM 需求的最重要數字,見第四章。

• :latest(預設 tag):如果你只打 ollama pull llama3.2 不加 tag,拉的是 :latest。注意 :latest 不一定是最大或最新尺寸,通常是官方選的「代表尺寸」(常是中小尺寸的 Q4 版)。生產環境建議永遠明確指定 tag,例如 qwen3:8b,避免不同機器拉到不同東西。

• 量化後綴(q4_K_M、q8_0、fp16):不加後綴時,Ollama 預設給你 Q4_K_M(4-bit,平衡型)。想要更高品質可明確指定,例如 llama3.1:8b-instruct-q8_0。詳見第五章。

• instruct vs base:

  • instruct(指令微調版):經過對話/指令訓練,你問它答,這是你 99% 情況該用的版本。Ollama 預設 tag 幾乎都是 instruct。
  • base(基礎版):只做過預訓練的「文字接龍機」,不會乖乖回答問題,適合再訓練或特殊研究用途。新手請避開。

一個實用習慣:pull 之前先在名稱上做判斷。 看到 deepseek-r1:1.5b 你就知道這是個推理小模型、約需 1-2GB RAM、預設 Q4;看到 mixtral:8x7b 你就知道這是 MoE 大模型、記憶體需求遠超「7B」的字面。

四、參數量 (B) 與硬體:模型大小 → RAM → 適合的 Mac

這是選型漏斗的第一層,也是最硬的約束。參數量直接決定模型載入時要吃掉多少 RAM。

粗估公式(Q4_K_M 量化下):

所需 RAM ≈ 參數量(B) × 約 0.6–0.75 GB  +  context/系統 overhead(約 1–2 GB)

例如 8B 模型:8 × 0.7 ≈ 5.6GB + overhead ≈ 實際佔用約 5–6 GB。

重要提醒:Mac 是**統一記憶體(Unified Memory)**架構,GPU 與 CPU 共用同一塊 RAM。你不能把整台機器的 RAM 全給模型——系統、瀏覽器、其他 App 都要吃。實務上請預留至少 8GB 給系統與應用,剩下的才是模型能用的空間。

模型大小 → RAM → Mac 對照表(Q4_K_M)

* 速度為 Apple Silicon 上的約略範圍,實際受晶片型號(M1/M2/M3/M4)、context 長度、量化等級影響很大,僅供相對比較。

選型口訣(對齊 Part 1 的 RAM 規則):

• 8GB Mac → 主力 3B,偶爾 7B(關掉其他 App)。
• 16GB Mac → 7B–8B 是甜蜜點,12B 可用,別碰 32B。這是最多人的配置。
• 24–32GB Mac → 舒適跑 14B,可挑戰 27B–32B。
• 64GB+ Mac → 才適合認真跑 70B。

如果你不確定自己的 Mac 該選什麼:16GB 就從 qwen3:8b 或 llama3.1:8b 開始,幾乎不會錯。

別忘了 context 也吃 RAM

上面的估算是「模型權重」的部分,但實際跑起來還有一塊常被忽略的開銷:KV cache(鍵值快取)。你每次對話累積的 context(輸入 + 生成的 token)都要存在記憶體裡,context 開越大、對話越長,這塊就越大。

   實際記憶體佔用 = 模型權重 + KV cache + 系統/框架 overhead
                    └───┬───┘   └───┬───┘   └──────┬──────┘
                  由參數量與量化   由 context      約 1–2 GB
                     決定(固定)   長度決定(浮動)

一個經驗法則:context 每加大一倍,KV cache 大致跟著加大一倍。 如果你把 num_ctx 從預設的 4096 調到 32768(Part 3 會教),長對話下額外 RAM 可能多出好幾 GB。所以「模型剛好塞得下」和「模型 + 長 context 塞得下」是兩回事——在 16GB Mac 上跑 8B 沒問題,但同時開超長 context 就可能開始用 swap 變慢。 選尺寸時請預留這塊緩衝。

實測你的機器:跑起來看 CPU/GPU 分配

想確認模型是不是「完全塞進記憶體、由 GPU 跑」,可以在模型執行時另開一個終端機查:

1ollama ps

1NAME        ID              SIZE      PROCESSOR    UNTIL
2qwen3:8b    500a1f067a9f    6.5 GB    100% GPU     4 minutes from now

PROCESSOR 顯示 100% GPU 是最理想的——代表整個模型都在 GPU(統一記憶體)裡跑,速度最快。如果出現 50% CPU / 50% GPU 之類的分配,代表模型太大、部分被迫用 CPU 跑(offload),速度會明顯下降——這就是「該換小一號模型或降量化」的訊號。

五、量化 (Quantization) 深入淺出

這是選型漏斗的第三層,也是最多人似懂非懂的地方。搞懂量化,你就能在同一塊 RAM 裡榨出最好的模型。

什麼是量化?

模型的「參數」本質上是一大堆數字(權重)。原始訓練出來的權重通常是 16-bit 浮點數(fp16),每個參數佔 2 bytes。量化就是把這些數字用更少的位元來近似表示——例如壓成 4-bit,每個參數只佔 0.5 byte。

   fp16 (原始, 16-bit)          Q4_K_M (量化, ~4-bit)
   每參數 2 bytes                每參數 ~0.5 byte

   ┌────────────────────┐       ┌──────┐
   │ 0.7182  -0.3391    │       │ 0.72 │   體積縮小約 4 倍
   │ 0.1057   0.9923    │  ───▶ │-0.34 │   ────────────▶
   │ -0.4460  0.2255    │       │ 0.11 │   速度變快
   │  ...(高精度)...    │       │(近似)│   品質略降
   └────────────────────┘       └──────┘

   8B 模型 ≈ 16GB              8B 模型 ≈ 5GB

同一個 8B 模型,fp16 要約 16GB(16GB Mac 根本裝不下),Q4 只要約 5GB(輕鬆跑)。這就是為什麼幾乎所有人在本地跑的都是量化模型。

量化等級對照表

* 相對於 fp16 的大小,約略值。

大小 vs 速度 vs 品質的三角

                   品質 (Quality)
                       ▲
                       │  fp16
                       │  Q8_0
                       │   Q6_K
                       │    Q5_K_M
                       │      Q4_K_M  ◀── 甜蜜點:品質夠、體積小、速度快
                       │
        小體積+快 ◀────┴────▶ 大體積+慢
        (低位元)              (高位元)

三者無法兼得:位元越低 → 越小越快、但品質略降;位元越高 → 品質越好、但越大越慢。

該選哪個量化?

• 預設就用 Q4_K_M(不加後綴 Ollama 給你的就是這個)。對 95% 的使用者、95% 的任務,Q4_K_M 的品質損失小到你幾乎察覺不到,而省下的 RAM 讓你能跑大一號的模型。
• RAM 有餘、對品質敏感(如寫程式、正式文件) → 升到 Q5_K_M 或 Q6_K。
• 要接近原始品質、RAM 很充足 → Q8_0(near-lossless),但體積是 Q4 的近 2 倍。
• 除非做研究或再訓練,一般不需要 fp16——它幾乎不會帶來人類可感知的品質提升,卻讓體積與延遲爆炸。

關鍵洞見:與其用 Q8 跑一個小模型,通常不如用 Q4 跑大一號的模型。 例如同樣約 10GB RAM,gemma3:12b-q4 的整體能力通常勝過 gemma3:4b-q8。尺寸的收益,往往大於量化精度的收益。

K_M、K_S 這些後綴是什麼?

你可能看過 Q4_K_M、Q4_K_S、Q4_0 這些變體。快速解讀:

• _K:代表 “K-quant”,較新的量化方法,同位元下品質比舊的 _0 / _1 好。優先選 _K 系列。
• _M / _S / _L:Medium / Small / Large,指的是「混合精度的比例」。同樣是 4-bit 家族,_M(Medium)在部分關鍵層用較高精度,品質比 _S(Small)好一點、體積稍大。
• 建議:直接用 Q4_K_M 就對了,它是社群公認的「品質/體積最佳平衡點」,也是 Ollama 的預設。除非你很清楚自己在做什麼,不需要去挑 _S / _L。

量化不是「越高越划算」——收益遞減

一個容易被忽略的事實:量化精度的品質提升是遞減的。

   品質提升幅度(相對於前一級)
   Q4 → Q5 : ▓▓▓▓▓▓ 有感
   Q5 → Q6 : ▓▓▓    小幅
   Q6 → Q8 : ▓▓     很小
   Q8 → fp16: ▓     人類幾乎無感,但體積翻倍

從 Q4 升到 Q5 你可能還感覺得到差異,但從 Q8 升到 fp16,品質提升微乎其微,體積和延遲卻近乎翻倍。這就是為什麼「日常本地推理沒人在跑 fp16」——投入產出比太差。把省下的記憶體拿去換更大的尺寸,幾乎總是更划算。

六、依「任務」選模型

這是選型漏斗的第二層。硬體篩掉不可能的尺寸後,用任務決定家族與變體。

任務 → 模型推薦對照表

各任務要點

• 一般對話:別想太多,qwen3:8b 或 llama3.1:8b 就是最穩的起手式。小機器退而求其次用 gemma3:4b,品質相對於尺寸很不錯。

• 寫程式:一定要用 coder 專用模型。qwen2.5-coder 系列針對程式碼與 fill-in-the-middle 訓練,同尺寸下寫程式能力遠勝通用模型。RAM 夠就上 14b。

• 看圖(vision):這類模型能接受圖片輸入。llava 是經典入門,qwen2.5-vl 與 llama3.2-vision 較新較強。注意 vision 模型 RAM 需求通常比同尺寸純文字模型略高。

• 推理 / 數學:deepseek-r1 會輸出一段「思考過程」再給答案,解數學、邏輯、多步驟推理特別準,但代價是速度慢、token 多(它要「想」)。日常閒聊用它反而囉嗦。qwen3 的 think mode 是可切換的折衷方案。

• RAG(做知識庫檢索):這裡要用的是 embedding 模型,它不做對話,只把文字轉成向量供相似度搜尋。nomic-embed-text 又小又快是首選。注意:RAG 系統通常是「embedding 模型負責檢索 + 對話模型負責回答」兩個模型搭配使用。

• 中文:qwen 系列是首選,中文語感與用詞明顯優於西方團隊的模型。gemma3 次之。

推理模型 vs 一般模型:輸出差在哪?

用一個具體例子感受「推理模型」的不同。同樣問一題邏輯題,deepseek-r1 會先輸出一段思考過程(通常包在 <think>...</think> 裡),再給結論:

 1$ ollama run deepseek-r1:7b "3 個工人 3 天蓋 3 面牆,9 個工人 9 天蓋幾面牆?"
 2
 3<think>
 4先算單位產能。3 個工人 3 天蓋 3 面牆,
 5所以 1 個工人 1 天蓋 3 / (3×3) = 1/3 面牆。
 69 個工人 9 天 = 9 × 9 × (1/3) = 27 面牆。
 7要小心這題的陷阱:不是直覺的 9 面。
 8</think>
 9
10答案是 27 面牆。關鍵在於先求出「單一工人單日產能 = 1/3 面」,
11再乘上 9 個工人 × 9 天。

這段「思考」是它準確度高的來源,但代價是:生成的 token 多出好幾倍、速度更慢、也更囉嗦。所以推理模型適合數學/邏輯/規劃,拿來閒聊反而是浪費。選對任務,才能發揮模型的長處。

一個典型「三模型工作組」

選型提醒:一台 Mac 上可以同時裝多個模型,依任務切換。 對多數開發者,我推薦一組實用的「三模型工作組」:

三個加起來磁碟約 10GB、記憶體不會同時全開,16GB Mac 就能勝任。如何同時服務多個模型(而不是每次切換都重載)會在 Part 5 詳談。

七、實作:pull、比較、切換與清理

理論講完,來動手。以下指令與輸出示意可直接照做。

7.1 拉模型(pull)

 1# 拉一個對話主力(不加 tag 會拿 :latest,建議明確指定尺寸)
 2ollama pull qwen3:8b
 3
 4# 拉一個 coder 模型
 5ollama pull qwen2.5-coder:7b
 6
 7# 明確指定量化(想要更高品質)
 8ollama pull llama3.1:8b-instruct-q8_0
 9
10# 拉一個 embedding 模型(做 RAG 用)
11ollama pull nomic-embed-text

拉取過程會顯示分層下載進度:

1pulling manifest
2pulling 8eeb52dfb3bb... 100% ▕██████████████████▏ 4.9 GB
3pulling 62fbfd9ed093... 100% ▕██████████████████▏  182 B
4pulling f02dd72bb242... 100% ▕██████████████████▏   59 B
5verifying sha256 digest
6writing manifest
7success

層共享(layer dedupe):Ollama 用 manifest + layers 管理模型,相同的層會在不同模型間共用。所以你拉第二個同家族模型時,可能會發現某些層瞬間完成——因為它已經存在磁碟上了。

7.2 看能力與 context 長度(ollama show)

這是選型時最該養成的習慣。 ollama show 直接告訴你這個模型的參數量、context 長度、量化與能力:

1ollama show qwen3:8b

 1  Model
 2    architecture        qwen3
 3    parameters          8.2B
 4    context length      40960
 5    embedding length    4096
 6    quantization        Q4_K_M
 7
 8  Capabilities
 9    completion
10    tools
11    thinking
12
13  Parameters
14    temperature      0.6
15    top_k            20
16    top_p            0.95
17
18  License
19    Apache License 2.0

從這一屏你就知道:8.2B 參數(約 5–6GB RAM)、支援 tools 與 thinking(可做工具呼叫與推理)、原生 context 高達 40960 tokens、Apache 2.0 授權(商用安心)。注意:雖然原生支援 40K context,Ollama 執行時預設常只開 4096——如何調高 num_ctx 會在 Part 3 講。

7.3 看磁碟佔用(ollama list)

1ollama list

1NAME                        ID              SIZE      MODIFIED
2qwen3:8b                    500a1f067a9f    5.2 GB    2 hours ago
3qwen2.5-coder:7b            2b0496514337    4.7 GB    3 hours ago
4llama3.1:8b-instruct-q8_0   8f2a3c1d4e5b    8.5 GB    1 day ago
5nomic-embed-text            0a109f422b47    274 MB    1 day ago
6gemma3:4b                   c0494fe00251    3.3 GB    5 days ago

注意 embedding 模型 nomic-embed-text 只有 274MB——因為它本來就是小模型。也注意 q8_0 版的 llama 佔 8.5GB,比 Q4 版明顯大。

7.4 切換與比較模型

切換模型不需要任何設定,ollama run 指定不同名稱即可:

1# 用對話模型
2ollama run qwen3:8b "用一句話解釋量化"
3
4# 換 coder 模型寫程式
5ollama run qwen2.5-coder:7b "寫一個 Python 函式判斷質數"
6
7# 用推理模型解數學(注意它會先輸出思考過程)
8ollama run deepseek-r1:7b "一個水池進水管 3 小時注滿,出水管 5 小時放空,同時開需要多久?"

7.5 清理磁碟(ollama rm)

模型很吃磁碟,實驗完該清就清:

1# 刪掉不再用的模型,釋放磁碟空間
2ollama rm gemma3:4b

1deleted 'gemma3:4b'

提示:因為層共享,刪掉一個模型時,只有「不被其他模型引用的層」會真正被釋放。刪完可再跑 ollama list 確認 SIZE 變化。

7.6 實戰:同一問題比較兩個模型

選型最實在的方法,就是拿你真正的任務去比。與其看跑分,不如用自己的問題各問一次:

1# 用小模型
2ollama run gemma3:4b "把這句話翻成正式英文:這批貨延遲了,我們深感抱歉"
3
4# 用中模型
5ollama run qwen3:8b "把這句話翻成正式英文:這批貨延遲了,我們深感抱歉"

觀察三件事:(1) 品質——輸出是否到位、有無錯誤;(2) 速度——體感是否可接受(可加 --verbose 看 tokens/sec);(3) 記憶體——另開終端跑 ollama ps 看有沒有 offload 到 CPU。

加上 --verbose 可以看到量化的效能數據:

1ollama run qwen3:8b --verbose "用一句話總結量化的目的"

1量化的目的是用更少的位元近似模型權重,以更小的體積與更快的速度換取極小的品質損失。
2
3total duration:       2.104s
4load duration:        31.5ms
5prompt eval count:    18 token(s)
6eval count:           41 token(s)
7eval rate:            33.62 tokens/s

eval rate(生成速度)是最直覺的體感指標。 約 20+ tokens/s 讀起來就很順,低於 10 就會覺得在等。用這個數字客觀比較不同尺寸/量化在你機器上的實際表現,比任何網路上的評測都準。

八、為什麼選 X 不選 Y:決策表

選型的精髓在「取捨」。以下四組是最常遇到的抉擇,每組都附上「什麼情況該反過來選 Y」的 flip 條件。

決策表

額外一組值得記住的原則:

「大尺寸 Q4」vs「小尺寸 Q8」:在相同 RAM 預算下,優先選大尺寸的 Q4(如 gemma3:12b-q4 > gemma3:4b-q8)。尺寸帶來的能力提升,通常大於量化精度的提升。反過來的例外:當你在做需要極高數值精度的任務(某些程式/數學),且尺寸差距不大時,高量化才值得。

九、太大跑不動怎麼辦?

看上一個模型但你的 Mac 帶不動,有三條退路,由近而遠:

退路 1:量化降階

同一個模型,選更低位元的量化。例如 q6 跑不動就換 q4。這是損失最小的第一選擇——尺寸不變、能力保留最多,只犧牲一點點精度。

1# 從 q8 降到 q4,體積近乎減半
2ollama pull llama3.1:8b-instruct-q4_K_M

退路 2:選更小尺寸

降階量化還是不夠,就退一個尺寸級別。14B → 8B → 3B。這是能力損失較明顯但最有效的做法。 記住第六章:選對任務的小模型,往往比硬撐的大模型更實用。

1# 32B 跑不動,退到 8B
2ollama pull qwen3:8b

退路 3:用 :cloud 雲端模型

有些模型太大(如 deepseek-v3、70B+ 旗艦),本地 Mac 再怎麼量化都塞不下。Ollama 提供雲端模型選項:在名稱後加 :cloud,模型跑在 Ollama 雲端而非你的機器,但用法完全一樣。

1# 先登入(雲端模型需要帳號)
2ollama signin
3
4# 用雲端跑一個本地跑不動的大模型
5ollama run deepseek-v3:cloud "解釋 MoE 架構的優缺點"

雲端模型的定位:它讓你在本地機器上,用同一套 CLI/API 存取「跑不動的大模型」。但這已經不是純粹的「本地推理」——資料會離開你的機器,且需要網路與帳號。如果你選擇 Ollama 就是為了資料隱私或離線,雲端模型只適合當作偶爾需要旗艦能力時的補充。 本文僅簡述,細節請參考官方文件。

決策順序:先試降量化(退路 1)→ 再試降尺寸(退路 2)→ 真的需要旗艦能力才考慮雲端(退路 3)。

新手最常犯的五個選型錯誤

最後,把最容易踩的坑整理成清單,對照檢查自己:

把這張表存起來,下次要 pull 新模型前掃一眼,能省下大量反覆下載刪除的時間。

十、小結與下一篇預告

這篇我們建立了一套可重複使用的選型框架:

• 心智模型:硬體(上限)→ 任務(方向)→ 量化(塞進上限),順序不可顛倒。
• 六大家族:Llama(通用生態)、Qwen(中文/性價比)、Gemma(輕量品質)、Mistral(商用無痛)、Phi(小而精)、DeepSeek(推理)。
• 讀懂名稱:family:size-variant-quant,:latest 不一定最新,永遠用 instruct 不用 base。
• 硬體對齊:16GB Mac 的甜蜜點是 7B–8B,別硬撐 70B。
• 量化:預設 Q4_K_M 就好;RAM 有餘再升 Q5/Q6/Q8;大尺寸 Q4 通常勝過小尺寸 Q8。
• 依任務選:對話用 qwen3/llama、寫程式用 qwen2.5-coder、看圖用 vision、推理用 deepseek-r1、RAG 用 embedding。
• 實作:ollama show 看能力、ollama list 看磁碟、ollama rm 清理,:cloud 是跑不動時的補充。

最重要的一句話,再說一次:選對「尺寸 + 量化 + 任務」的模型,遠勝於盲目追求最大。

下一篇 Part 3 - REST API 與自訂 Modelfile,我們會離開命令列,學會用 REST API 把 Ollama 接進你自己的程式,並用 Modelfile 客製系統提示、參數(包含把前面提到的 num_ctx context 長度調高)、打造你專屬的模型。

系列導覽

• Part 1 — 安裝與第一個本地模型
• Part 2 — 公開模型全覽與選型指南(本篇)
• Part 3 — REST API 與自訂 Modelfile
• Part 4 — 與應用整合
• Part 5 — 工具呼叫、多模型服務與進階實踐

參考連結

• Ollama 官方文件:https://docs.ollama.com/
• 模型搜尋與瀏覽:https://ollama.com/search
• Ollama CLI 指令參考:https://docs.ollama.com/cli