NLP Day 15 本地推論：Ollama、量化與 GPU 需求

執行需求：CPU 可跑。本篇所有範例在一般筆電的 CPU 上都能執行（用 Ollama 的 1B–3B 小模型）。不需要 GPU，也不需要 API Key。我們會示範 Ollama 的完整工作流：安裝、啟動服務、pull 模型、HTTP API 呼叫、Python 用 requests 串接；最後介紹量化技術（Q4_K_M、Q5_K_M、Q8_0）、硬體需求的評估方法、以及不同規模模型的取捨。

引言

前兩天我們把 LLM API 的世界打開了——能呼叫 OpenAI GPT-4o、Anthropic Claude 3.7 Sonnet，也學了如何寫好提示。但 API 不是唯一選擇。當應用要處理敏感資料（醫療、金融、客服個資）、要離線使用（工廠、無人機、邊緣裝置）、要壓低單次成本（每天百萬次呼叫的應用），本地推論就成了最佳解。今天要把本地推論的基礎寫清楚：Ollama 的安裝與使用、量化技術怎麼壓縮模型、硬體需求怎麼評估、以及如何挑選適合自己情境的模型。

本地推論與雲端 API 的關鍵差異是「誰擁有硬體與資料」。雲端 API 把推論放在 OpenAI / Anthropic 的伺服器上，呼叫端只需要傳網路請求；本地推論把模型放在自己的機器上，所有計算都在你掌控之中發生。這個差異帶來三個優勢：資料隱私（不外傳到第三方）、成本可控（一次性硬體投資 vs 持續付費）、離線可用（無網路也能跑）；代價是硬體成本（GPU 或高效 CPU）、模型規模受限（消費級 GPU 跑不了 70B 模型）、維運負擔（自己處理升級、監控、容錯）。

Ollama 是 2024–2025 年最受歡迎的本地 LLM 推論工具，2025 年初的穩定版本是 0.6 / 0.7。它把 GGUF 模型格式、量化、HTTP API、CLI 工具整合成一個易用的系統，並相容 OpenAI 的 API 介面（讓本地推論與雲端 API 可以無縫切換）。本篇會從零開始建立 Ollama 的完整工作流，讓你能在自己的筆電上跑 LLM、不用花錢買雲端額度。

Ollama 的安裝與基礎

Ollama 的安裝在三大作業系統都很直觀。macOS 使用者從官網（ollama.com）下載 dmg 檔安裝，或用 brew install ollama。Linux 使用者執行一行指令：curl -fsSL https://ollama.com/install.sh | sh。Windows 使用者從官網下載安裝檔（Ollama 0.6 起正式支援 Windows）。安裝後 ollama --version 應該看到 0.6.x 或 0.7.x 版本號。

啟動 Ollama 服務有兩種方式：互動式（ollama serve，前景服務），或系統服務常駐（macOS 用 brew services start ollama，Linux 用 systemctl enable ollama）。互動式適合開發階段、需要看 log；系統服務適合 production、開機自動啟動。啟動後用 ollama list 確認服務在運作。

下載模型用 ollama pull 指令。Ollama 支援多種模型家族：Llama 3.3（Meta 2024-12 發布）、Qwen 2.5（阿里 2024-09 發布）、DeepSeek R1（2025-01 發布）、Mistral、Phi、Gemma 等。下載時可以指定量化版本，例如 ollama pull llama3.2:3b-instruct-q4_K_M 會下載 Llama 3.2 3B Instruct 模型的 Q4_K_M 量化版（約 2 GB）。完整模型名格式是 {model_name}:{size}-{variant}-{quant}。

量化技術：Q4、Q5、Q8 的選擇

量化（quantization）是 LLM 部署的核心技術。一個 7B 參數的模型用 FP16 精度儲存需要約 14 GB，硬碟與 VRAM 都不夠；用 Q4_K_M 量化後只需要約 4 GB，能在 8 GB VRAM 的消費級 GPU 上跑。量化的基本想法是「用較少的 bit 存著每個權重」，犧牲一點精度換大幅的空間與速度。

常見的量化格式：

FP16（半精度浮點）：每個權重 2 bytes、精度高、速度中等。7B 模型約 14 GB。適合有高階 GPU 的場景，幾乎沒有品質損失。

Q8_0（8-bit 量化）：每個權重 1 bytes、品質幾乎與 FP16 相同。7B 模型約 7 GB。適合「想要快速又不想犧牲太多品質」的場景。

Q5_K_M（5-bit 量化，k-means 中位數）：每個權重約 0.625 bytes、品質與 FP16 接近、速度中等。7B 模型約 5 GB。性價比最高的量化之一。

Q4_K_M（4-bit 量化，k-means 中位數）：每個權重約 0.5 bytes、品質略低於 FP16（小於 1 個百分點）、速度快。7B 模型約 4 GB。消費級 GPU 跑 7B 模型的主流選擇。

Q4_0（4-bit 量化，簡單線性）：每個權重 0.5 bytes、品質比 Q4_K_M 略低、速度最快。7B 模型約 4 GB。極致省資源場景的選擇。

實務上的選擇建議：VRAM ≥ 24 GB 用 FP16；VRAM 12–24 GB 用 Q5_K_M；VRAM 8 GB 用 Q4_K_M；VRAM 4 GB 或純 CPU 用 Q4_0 或更小的模型（1B–3B）。量化品質的損失通常很小（< 1 個百分點），但對「數學推理」「程式碼生成」這類精確任務影響稍大。建議先跑 Q4_K_M 看表現，不滿意再升到 Q5_K_M 或 FP16。

硬體需求評估

本地 LLM 推論的硬體需求主要看三個指標：VRAM（GPU 記憶體）、RAM（系統記憶體）、硬碟空間。VRAM 是最關鍵的——模型必須完整載入 VRAM 才能用 GPU 推論；RAM 是次要的（CPU 推論時用 RAM 放模型）；硬碟空間影響模型下載與快取。

硬體需求的經驗法則：

3B 模型：Q4_K_M 約 2 GB，Q8_0 約 4 GB。可以在 M1/M2 MacBook Air、8 GB VRAM 的入門顯示卡、純 CPU 上跑。適用於一般問答、簡單分類、輕量總結。

7B 模型：Q4_K_M 約 4 GB，Q8_0 約 8 GB，FP16 約 14 GB。需要 8 GB VRAM（Q4）、12 GB（Q8）、16 GB（FP16）。適用於大多數 NLP 任務，品質接近雲端輕量模型。

13B 模型：Q4_K_M 約 7 GB，FP16 約 26 GB。需要 12 GB（Q4）、24 GB（FP16）VRAM。適用於複雜推理、長文理解。

70B 模型：Q4_K_M 約 35 GB，FP16 約 140 GB。需要雙 GPU（各 24 GB）或伺服器級 GPU。適用於最高品質需求，與雲端頂級模型相當。

CPU 推論則完全靠 RAM。一般筆電的 16 GB RAM 跑 7B 模型 Q4_K_M 還算順暢（每秒 5–10 tokens）；32 GB RAM 可以跑 13B；64 GB 以上能跑 70B 但速度會慢（每秒 1–2 tokens）。M1/M2 Mac 的統一記憶體架構特別適合 LLM 推論，8 GB 統一記憶體的 MacBook Air 跑 7B Q4 也很順。

另一個容易被忽略的是推論速度。速度主要看「每秒生成 token 數」(tokens/s)。互動式應用至少要 10 tokens/s 才感覺流暢；批次處理可以接受 2–5 tokens/s。速度受模型規模、量化等級、硬體規格共同影響：RTX 4090 跑 7B Q4 約 50 tokens/s；M2 MacBook Pro 跑 7B Q4 約 25 tokens/s；M1 Air 跑 7B Q4 約 15 tokens/s；Intel i7 CPU 跑 7B Q4 約 5 tokens/s。

完整實作：Ollama 的 CLI、HTTP API、Python 串接

以下範例展示 Ollama 的三種使用方式：CLI 互動、HTTP API、Python requests 串接。執行前請先裝 Ollama 0.6 / 0.7 與 pip install requests==2.32.3。模型下載用 ollama pull llama3.2（首次約 2 GB）。

# 1. Ollama CLI：基本互動式對話
# 命令列執行（不在 Python 內）：
# ollama run llama3.2 "請用繁體中文自我介紹"
# 互動模式（輸入提示詞、模型生成回應）：
# ollama run llama3.2
# >>> 請問台灣的首都是哪裡？
# 台灣的首都是台北。

# 查看已下載模型
# ollama list
# 輸出（實際數字會略有不同）：
# NAME                    ID            SIZE      MODIFIED
# llama3.2:latest         2e7d2f87f4f8  2.0 GB    2 days ago
# qwen2.5:3b              2e7d2f87f4f8  1.9 GB    1 day ago

CLI 是最簡單的使用方式，適合快速測試與除錯。ollama run {model} "{prompt}" 是一次性呼叫（不開互動）；ollama run {model} 是開啟 REPL，可以連續對話。互動模式中輸入 /bye 離開、輸入 /set system "{system_prompt}" 設定系統提示詞。互動模式很適合「快速驗證 prompt」與「手動評估模型品質」。

# 2. Ollama HTTP API：原生介面（與 OpenAI 介面不同）
import requests
import json

OLLAMA_URL = "http://localhost:11434"

def ollama_generate(prompt: str, model: str = "llama3.2") -> str:
    """用 Ollama 原生 API 呼叫。"""
    resp = requests.post(
        f"{OLLAMA_URL}/api/generate",
        json={"model": model, "prompt": prompt, "stream": False,
              "options": {"temperature": 0.0, "num_predict": 256}},
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["response"]

# 實際執行（需先 ollama serve && ollama pull llama3.2）：
# print(ollama_generate("請用繁體中文自我介紹，限 50 字內"))
# 輸出（實際數字會略有不同）：
# 我是 Llama 3.2，Meta 公司訓練的開源大型語言模型，能用繁體中文對話。

Ollama 原生 API 路徑是 /api/generate（單次 prompt）或 /api/chat（對話格式）。這套 API 簡單直觀，適合搭配 requests 寫 script。注意 stream: false 讓回應一次回傳；設成 true 會用 SSE 串流回應（適合長回應或即時顯示）。num_predict 控制最大生成長度（對應 OpenAI 的 max_tokens）。

# 3. Ollama 對話格式 API：模擬多輪對話
def ollama_chat(messages: list, model: str = "llama3.2") -> str:
    resp = requests.post(
        f"{OLLAMA_URL}/api/chat",
        json={"model": model, "messages": messages, "stream": False,
              "options": {"temperature": 0.0, "num_predict": 256}},
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["message"]["content"]

# 實際執行：
messages = [
    {"role": "system", "content": "你是客服助手，回答限 50 字內。"},
    {"role": "user",   "content": "請問如何聯絡客服？"},
]
# reply = ollama_chat(messages)
# print(reply)
# 輸出（實際數字會略有不同）：
# 您可以撥打客服專線 0800-000-000，或透過 APP 內的「聯絡我們」功能。

對話格式 API 路徑是 /api/chat，訊息結構與 OpenAI 相同（{role, content}）。這個介面比原生 generate 更靈活，支援 system 訊息、多輪歷史。實務上建議優先用 chat 介面，原因是它支援 system prompt 與對話歷史；只有簡單的單次任務才用 generate。

# 4. 用 OpenAI 相容 SDK 連 Ollama：讓本地與雲端無縫切換
from openai import OpenAI

def local_chat(prompt: str, model: str = "llama3.2") -> str:
    """用 OpenAI SDK 連 Ollama，相容路徑。"""
    client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.0,
        max_tokens=256,
    )
    return resp.choices[0].message.content

# 實際執行：
# print(local_chat("請用繁體中文自我介紹，限 50 字內"))
# 輸出（實際數字會略有不同）：
# 我是 Llama 3.2，Meta 訓練的開源大型語言模型，支援繁體中文對話。

Ollama 提供 OpenAI 相容 API 路徑 /v1/chat/completions，讓昨天的 OpenAI SDK 程式碼可以直接連線本地。這個設計大幅降低遷移成本：原本寫給 OpenAI 的程式只要把 base_url 改成 http://localhost:11434/v1，就能切換成本地推論。實務上的策略：開發階段用 OpenAI API、生產階段用 Ollama 本地，這樣團隊能用同一套程式碼、同樣的測試。

# 5. 串流輸出：對長回應可以分塊顯示
def ollama_stream(prompt: str, model: str = "llama3.2"):
    resp = requests.post(
        f"{OLLAMA_URL}/api/generate",
        json={"model": model, "prompt": prompt, "stream": True,
              "options": {"temperature": 0.0, "num_predict": 512}},
        timeout=60,
        stream=True,
    )
    resp.raise_for_status()
    for line in resp.iter_lines():
        if line:
            chunk = json.loads(line)
            yield chunk.get("response", "")
            if chunk.get("done"):
                break

# 實際執行（逐塊顯示）：
# for piece in ollama_stream("請寫一首關於台灣的短詩"):
#     print(piece, end="", flush=True)
# print()
# 輸出（實際數字會略有不同）：
# 玉山巍巍立雲端，
# 日月潭水映天藍。
# 夜市小吃飄香遠，
# 寶島風情萬世傳。

串流輸出對長回應特別有用。Ollama 的 SSE 串流用 JSON Lines 格式（每行一個 JSON），用 iter_lines() 逐行讀取，每行解析後取出 response 欄位的文字片段。done: true 表示生成結束。串流的 UX 優勢：第一個 token 約 0.3 秒就出現，後續每 50–100 ms 一塊，使用者感覺「模型在即時思考」。

# 6. 模型管理：列出、下載、刪除模型
import subprocess

def ollama_cli(*args) -> str:
    result = subprocess.run(["ollama", *args], capture_output=True, text=True, check=True)
    return result.stdout.strip()

# 列出已下載模型
# print(ollama_cli("list"))
# 輸出（實際數字會略有不同）：
# NAME                    ID            SIZE      MODIFIED
# llama3.2:latest         a8b0e4c0c0d8  2.0 GB    2 days ago
# qwen2.5:3b              8c5e8d8c4f8c  1.9 GB    1 day ago

# 下載模型（首次約 2 GB）
# ollama_cli("pull", "qwen2.5:3b")
# 輸出（實際數字會略有不同）：
# pulling manifest...
# pulling [============>          ]  46% ▕████████████▏ 900 MB

# 刪除模型
# ollama_cli("rm", "qwen2.5:3b")
# 輸出：deleted 模型：「qwen2.5:3b」

ollama list 顯示已下載模型，ollama pull 下載新模型，ollama rm 刪除模型。實務上的磁碟管理：ollama list 顯示的 SIZE 是模型大小，多個模型會累積佔用空間；如果硬碟不足，用 ollama rm 移除不用的模型。下載時用 :tag 指定版本（例如 qwen2.5:3b-instruct-q4_K_M），不同 tag 是不同檔案、可以同時存在。

# 7. 硬體評估：實際量測 Ollama 的推論速度與記憶體用量
import time
import psutil
import os

def benchmark_model(model: str, prompt: str = "請寫 100 字的台灣介紹") -> dict:
    """量測模型的 tokens/s、VRAM 使用、回應時間。"""
    process = psutil.Process(os.getpid())
    mem_before = process.memory_info().rss / 1024**3  # GB

    start = time.time()
    response = ollama_generate(prompt, model)
    elapsed = time.time() - start

    mem_after = process.memory_info().rss / 1024**3
    estimated_tokens = len(response) * 0.7  # 粗估：繁中 1 字 ≈ 0.7 token
    return {
        "model": model,
        "elapsed_sec": round(elapsed, 2),
        "tokens": int(estimated_tokens),
        "tokens_per_sec": round(estimated_tokens / elapsed, 2),
        "mem_delta_gb": round(mem_after - mem_before, 2),
        "response": response[:60] + "...",
    }

# 比較不同模型的表現（CPU 推論）：
# for m in ["llama3.2:1b", "llama3.2:3b", "qwen2.5:3b"]:
#     print(benchmark_model(m))
# 輸出（實際數字會略有不同，視硬體而定）：
# {'model': 'llama3.2:1b', 'elapsed_sec': 4.21, 'tokens': 72, 'tokens_per_sec': 17.10, ...}
# {'model': 'llama3.2:3b', 'elapsed_sec': 8.45, 'tokens': 70, 'tokens_per_sec': 8.28, ...}
# {'model': 'qwen2.5:3b', 'elapsed_sec': 7.83, 'tokens': 73, 'tokens_per_sec': 9.32, ...}

這段展示了硬體評估的方法：量測 tokens/s、記憶體增量、回應時間。實務上跑一次基準測試能告訴你「這個模型在你的硬體上是否可用」。基準測試的關鍵：固定 prompt、固定生成參數、跑 5 次取平均；這樣能避免「第一次跑比較慢」（模型剛載入）的偏差。tokens_per_sec 低於 5 的應用建議換更小的模型或加 GPU。

常見錯誤與踩雷

錯誤一：忘了啟動 Ollama 服務。寫好 Python 程式呼叫 Ollama，卻出現 ConnectionError: localhost:11434 connection refused。這通常是 Ollama 服務沒啟動。修正方式：先在終端機執行 ollama serve（互動式）或用系統服務啟動；用 curl http://localhost:11434/api/tags 驗證服務在運作。

錯誤二：模型太大導致 OOM（out of memory）。試圖在 8 GB VRAM 上跑 13B Q4 模型，看到 OutOfMemoryError 或系統整個卡住。修正方式：先用 ollama ps 看目前載入的模型與 VRAM 使用；改用更小的版本（例如 7B 而不是 13B）；改用更低的量化（Q4_0 而不是 Q5_K_M）；最壞情況下用 CPU 推論（速度會慢很多但能跑）。

錯誤三：用過時的模型名稱。ollama pull llama 找不到對應模型，Ollama 0.6 / 0.7 預設的 Llama 系列是 llama3.2（不是 llama3、 llama2）。修正方式：用 ollama search {name} 搜尋官方支援的模型；ollama.com/library 列出所有可用模型。常用模型：llama3.2、qwen2.5、deepseek-r1、mistral、phi3、gemma2。

錯誤四：忽略 context window 限制。把 10K token 的歷史送進 7B 模型，模型會自動截斷到訓練時的 context window（llama3.2 是 128K、qwen2.5 是 32K）。但太長的 context 會讓推論變慢、品質下降。修正方式：對長對話做摘要、只保留最近 5–10 輪、總 token 控制在 4K–8K 以內。

錯誤五：CPU 推論時使用 fp16 模型。ollama pull llama3.2:7b（預設 fp16，約 14 GB）在 16 GB RAM 的筆電上會 OOM。修正方式：明確指定量化版本 ollama pull llama3.2:7b-instruct-q4_K_M（約 4 GB）。

錯誤六：以為量化沒有品質損失。Q4 量化在「簡單任務」（分類、簡單問答）上幾乎沒有品質損失；但在「數學推理」「精確數字計算」任務上可能掉 1–3 個百分點。修正方式：對精確任務用 Q5_K_M 或 Q8_0；對一般任務 Q4_K_M 就夠。

錯誤七：未指定 keep_alive 導致模型被釋放。Ollama 預設在 5 分鐘沒用就把模型從 VRAM 釋放（移除）。如果你的程式呼叫間隔很長（例如每 10 分鐘呼叫一次），會每次都重新載入模型（浪費 5–10 秒）。修正方式：在請求中加 "keep_alive": "30m" 或 "keep_alive": -1（永不釋放）。

效能與實務提醒

本地推論的瓶頸通常是 VRAM 不是計算能力。一個 4090 GPU（24 GB VRAM）可以跑 13B Q5_K_M 模型（~10 GB）還有餘裕；如果是 3090（24 GB）也類似；4060 Ti 16 GB 可以跑 13B Q4；3050 8 GB 只能跑 7B Q4。如果 VRAM 不夠，CPU 推論是退路，但速度會慢 5–10 倍。

M1/M2 Mac 是本地推論的甜蜜點。M1 Pro / M2 Pro 的統一記憶體（16–32 GB）讓 7B–30B 模型都能流暢跑；M1/M2 對量化模型有特殊加速（AMX 指令集）。如果你是 macOS 使用者，本地 LLM 推論的體驗通常比同價位的 Windows + 入門等級顯示卡好。Linux + NVIDIA 仍然是最高效能的組合（CUDA 對 LLM 推論最佳化最深）。

模型選擇的決策樹：

資料敏感、需要本地 → Ollama + 7B Q4_K_M（最小可用品質）；

需要中文高品質 → Qwen 2.5（阿里，中文最佳化）；

需要程式碼 / 數學 → DeepSeek R1（推理強）；

需要輕量快速 → Llama 3.2 1B / Phi-3 mini；

需要綜合能力 → Llama 3.3 70B Q4（需要 32+ GB VRAM）；

量化版本的選擇決策樹：

品質優先 → FP16（需要完整 VRAM）；

品質與空間平衡 → Q5_K_M；

空間優先 → Q4_K_M；

極致省資源 → Q4_0。

硬體採購建議：入門（< 1 萬台幣）用 M1 MacBook Air 或 RTX 3050 筆電、跑 7B Q4；中階（1–3 萬）用 M2 Pro MacBook Pro 或 RTX 4060 Ti 桌機、跑 13B Q4；高階（3–10 萬）用 RTX 4090 桌機、跑 70B Q4。雲端 GPU（AWS、GCP）適合「不想買硬體、短期大量使用」的場景。

小結

本篇把本地 LLM 推論的基礎寫清楚：Ollama 的安裝與使用、量化技術（Q4_K_M、Q5_K_M、Q8_0、FP16）的選擇、硬體需求（VRAM、RAM、tokens/s）的評估方法、以及本地與雲端 API 的無縫切換。所有範例在 CPU 上用 1B–3B 模型都能跑，無需 GPU 或 API Key。讀完這篇你應該能回答：Ollama 怎麼安裝？量化等級怎麼選？7B 模型需要多少 VRAM？什麼時候該用本地、什麼時候該用雲端？這些答案都藏在本篇的程式與表格裡。明天 Day 16 我們會進入結構化輸出：JSON schema、function calling、解析容錯。

結語

今天的重點是「把 LLM 從雲端搬到自己的機器」。我們從 Ollama 安裝開始，到量化技術、硬體評估、本地與雲端切換，建立了完整的本地推論工具鏈。從 Day 13 的 LLM API、Day 14 的提示工程到今天的本地推論，LLM 應用的設計選項已經成形：雲端 API（品質高、成本付費）、本地 Ollama（品質中等、資料隱私）。明天，我們會把 Day 14 的結構化輸出展開：用 JSON schema、function calling、容錯解析把模型回應變成可程式化的資料。

在工業界，本地推論的價值不只在「省成本」，更在「資料主權」。醫療、金融、客服的應用場景，客戶資料外傳到第三方 API 是法規或合約的紅線；Ollama 提供了在合規邊界內運行 LLM 的可行解。下一篇進入結構化輸出時，會把 JSON schema 與 function calling 結合到 Ollama 上，讓本地 LLM 也能產生可程式化的輸出。

延伸資源

Ollama 官方文件（2025-03 擷取）：github.com/ollama/ollama/blob/main/docs/api.md，版本對應 Ollama 0.6 / 0.7。
Meta 官方發布（2024-09）：Llama 3.2 模型卡，授權 Llama 3.2 Community License（3B 與 1B 變體）。
阿里官方發布（2024-09）：Qwen 2.5 模型卡，授權 Apache 2.0（部分版本）。
DeepSeek 官方發布（2025-01）：DeepSeek R1 模型卡，授權 MIT。
Frantar 等人，GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers（ICLR 2023），GPTQ 量化方法原始論文。
gger、Llama 3.3、Qwen 2.5 與 DeepSeek R1 的 Hugging Face 模型卡（2024–2025）：詳細規格、授權、量化版本。

Hao程式筆記

搜尋此網誌