關鍵要點
使用 Ollama 在本地運行 Gemma 4 耗時不到 5 分鐘:安裝 Ollama,執行一個指令,您就能在自己的硬體上運行一個功能完備的 AI 模型,且享有零 API 成本、數據零外流,以及 Apache 2.0 協議下的零使用限制。E2B 模型可以在任何筆記型電腦上運行。26B MoE 模型可容納於單張 RTX 4090,並提供足以媲美其活動參數數量 10 倍的模型品質。
本地運行 Gemma 4:完整指南
為什麼要在本地運行 Gemma 4?
在深入瞭解設定之前,以下是為什麼在 2026 年本地推論至關重要的原因:
- 隱私 — 您的數據永遠不會離開您的機器。不會將提示詞發送到外部伺服器。這對於專有代碼、法律文件、醫療數據或任何敏感資訊都至關重要。
- 成本 — 在一次性硬體投資之後,每 token 成本為零。與 API 定價相比,重度使用者每月可節省數百美元。
- 延遲 — 無需網路來回傳輸。E2B 和 E4B 模型在現代硬體上的響應時間僅需幾毫秒。
- 可靠性 — 沒有 API 速率限制、沒有停機,也沒有供應商的政策變更。您的模型始終可用。
- 自定義 — 在 Apache 2.0 協議下自由地進行微調、量化和修改模型。
- 離線存取 — 下載模型後,無需網路連線即可運作。
Gemma 4 特別適合本地部署,因為 Google 專門為邊緣和裝置端使用設計了較小的模型。E2B 和 E4B 模型並非事後才想到的產物 —— 它們是針對本地硬體限制進行優化的頂級模型。
前置條件
各模型的硬體需求
| 模型 | 最小 RAM | 建議 VRAM | 僅限 CPU 是否可行? | 磁碟空間 |
|---|---|---|---|---|
| E2B (4-bit) | 5 GB | 4 GB | 是 | ~1.5 GB |
| E4B (4-bit) | 5 GB | 4 GB | 是 | ~2.8 GB |
| E4B (FP16) | 9 GB | 9 GB | 慢 | ~9 GB |
| 26B MoE (4-bit) | 18 GB | 16 GB | 非常慢 | ~15 GB |
| 26B MoE (FP16) | 52 GB | 48 GB | 否 | ~52 GB |
| 31B Dense (4-bit) | 20 GB | 18 GB | 非常慢 | ~18 GB |
| 31B Dense (FP16) | 62 GB | 48 GB+ | 否 | ~62 GB |
關鍵要點:如果您擁有一台 2022 年以後製造的筆記型電腦,就可以運行 E2B 或 E4B。如果您擁有 RTX 4090 (24GB VRAM) 或配備 32GB+ RAM 的 Apple M-series Mac,則可以運行 4-bit 量化版本的 26B MoE 或 31B Dense。
軟體需求
- 作業系統:macOS, Linux, 或 Windows
- Ollama:版本 0.6+ (從 ollama.com 下載)
- GPU 驅動程式 (選填):NVIDIA GPU 需安裝 NVIDIA CUDA 12+,Apple Silicon 無需額外驅動程式
步驟 1:安裝 Ollama
macOS
從 ollama.com/download 下載或使用 Homebrew:
brew install ollama
Linux
一行安裝腳本:
curl -fsSL https://ollama.com/install.sh | sh
Windows
從 ollama.com/download 下載安裝程式並運行。Ollama 在 Windows 上以背景服務形式運行。
驗證安裝
ollama --version
您應該會看到 ollama version 0.6.x 或更高版本。如果您看到版本號,則表示 Ollama 已正確安裝。
步驟 2:拉取 Gemma 4 模型
選擇符合您硬體的模型:
適用於筆記型電腦和輕量工作負載
# 最小的模型 — 可在任何現代筆記型電腦上運行 (5GB RAM)
ollama pull gemma4:e2b
# 具有更廣泛能力的小型模型 (5-9GB RAM)
ollama pull gemma4:e4b
適用於配備獨立 GPU 的桌上型電腦
# 最佳效率 — 以 3.8B 活動參數提供旗艦級品質 (18GB RAM)
ollama pull gemma4:26b-moe
# 最高品質 — 完整的 31B 參數 (20GB RAM)
ollama pull gemma4:31b
指定量化版本
預設情況下,Ollama 會拉取各模型建議的量化版本 (通常為 Q4_K_M,以兼顧品質與大小)。您可以指定不同的量化版本:
# 品質更高,體積更大
ollama pull gemma4:31b-q5_K_M
# 體積更小,品質略低
ollama pull gemma4:31b-q3_K_M
# 全精度 (需要更多 RAM)
ollama pull gemma4:31b-fp16
下載將根據您的網路連接速度耗時幾分鐘。模型大小從 ~1.5GB (E2B 4-bit) 到 ~62GB (31B FP16) 不等。
步驟 3:運行 Gemma 4
互動式對話
ollama run gemma4:e4b
這將開啟一個互動式對話視窗。輸入您的提示詞並按下 Enter:
>>> What are the key differences between REST and GraphQL APIs?
模型將直接在您的終端機中回應。輸入 /bye 即可退出。
單次提示 (非互動式)
echo "Explain the Builder design pattern in Python with an example" | ollama run gemma4:26b-moe
附帶思考模式
Gemma 4 支援針對複雜任務的可配置思考模式。透過添加系統提示來啟用它:
ollama run gemma4:31b --system "Think step by step before answering. Show your reasoning process."
對於數學、邏輯和複雜分析任務,思考模式可顯著提高回答品質。模型在產生最終回應之前,會產生 4,000+ 個 tokens 的內部推理過程。
步驟 4:使用本地 API
Ollama 在 localhost:11434 上公開了一個與 OpenAI API 格式相容的 REST API。這意味著任何支援 OpenAI API 的工具或函式庫都可以透過簡單的 URL 更改來連接到您的本地 Gemma 4。
使用 curl 測試 API
curl http://localhost:11434/api/generate -d '{
"model": "gemma4:26b-moe",
"prompt": "Write a Python function to parse CSV files with error handling",
"stream": false
}'
OpenAI 相容端點
curl http://localhost:11434/v1/chat/completions -d '{
"model": "gemma4:26b-moe",
"messages": [
{"role": "user", "content": "Explain async/await in JavaScript"}
]
}'
步驟 5:整合至您的應用程式
Python
import requests
def ask_gemma(prompt, model="gemma4:26b-moe"):
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": model,
"prompt": prompt,
"stream": False
}
)
return response.json()["response"]
# 使用方法
answer = ask_gemma("What is the time complexity of merge sort?")
print(answer)
Python 使用 OpenAI SDK
from openai import OpenAI
# 指向本地 Ollama 而非 OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama" # Ollama 不需要真實的 API key
)
response = client.chat.completions.create(
model="gemma4:26b-moe",
messages=[
{"role": "system", "content": "You are a helpful coding assistant."},
{"role": "user", "content": "Write a React hook for debounced search"}
]
)
print(response.choices[0].message.content)
Node.js / TypeScript
const response = await fetch("http://localhost:11434/v1/chat/completions", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
model: "gemma4:26b-moe",
messages: [
{ role: "user", content: "Explain the Observer pattern with a TypeScript example" }
]
})
});
const data = await response.json();
console.log(data.choices[0].message.content);
使用 LangChain
from langchain_community.llms import Ollama
llm = Ollama(model="gemma4:26b-moe")
response = llm.invoke("Summarize the key principles of clean architecture")
print(response)
使用 LlamaIndex
from llama_index.llms.ollama import Ollama
llm = Ollama(model="gemma4:26b-moe", request_timeout=120.0)
response = llm.complete("What are the SOLID principles in software engineering?")
print(response)
量化選項說明
量化透過使用較低精度的數字來表示模型權重,從而減少模型大小和記憶體使用量。其權衡在於品質與資源消耗之間:
| 量化 | 每個權重的位元數 | 品質影響 | 節省記憶體 | 最適合 |
|---|---|---|---|---|
| FP16 | 16 bits | 無 (完整品質) | 基準 | 配備充足 VRAM 的伺服器 |
| Q8_0 | 8 bits | 可忽略 | ~50% | 高品質本地推論 |
| Q6_K | 6 bits | 極微小 | ~62% | 重視品質的本地使用 |
| Q5_K_M | 5 bits | 微小 | ~69% | 良好的平衡 |
| Q4_K_M | 4 bits | 小 | ~75% | 建議預設值 |
| Q3_K_M | 3 bits | 中等 | ~81% | 硬體受限的情況 |
| Q2_K | 2 bits | 顯著 | ~87% | 極端受限的情況 |
Q4_K_M 是大多數使用者的最佳平衡點。 與 FP16 的品質差異非常小,以至於大多數任務產生的結果難以區分,而 75% 的記憶體節省則決定了是「需要伺服器」還是「能在筆記型電腦上運行」。
選擇正確的量化
針對 Gemma 4 E2B/E4B:使用預設值 (Q4_K_M)。這些模型本身已經足夠小,更高的量化程度不會顯著改變使用者體驗。
針對 Gemma 4 26B MoE:Q4_K_M 可容納於 18GB RAM 中,這在 RTX 4090 的 24GB VRAM 範圍內,且留有 KV cache 的空間。如果您有 48GB+ VRAM (A6000, 雙 GPU),則可以考慮使用 Q8_0 以獲得略好的品質。
針對 Gemma 4 31B Dense:20GB 的 Q4_K_M 在 RTX 4090 上運行時餘裕較窄。Q5_K_M 會產生稍微好一點的結果,但需要約 24GB,會耗盡所有可用的 VRAM。如果您有 32GB+ VRAM (RTX 5090, A6000),則 Q6_K 或 Q8_0 值得升級。
效能調優
GPU 卸載
當 VRAM 可用時,Ollama 會自動將模型層卸載到 GPU。如果只有部分模型能放入 VRAM,Ollama 會在 GPU 和 CPU 之間進行分配。您可以控制此行為:
# 強制將所有層載入 GPU (如果 VRAM 不足則會失敗)
OLLAMA_NUM_GPU=999 ollama run gemma4:26b-moe
# 強制僅使用 CPU (用於測試)
OLLAMA_NUM_GPU=0 ollama run gemma4:e4b
上下文窗口配置
預設情況下,為了提高效率,Ollama 使用 2048 個 tokens 的上下文窗口。要利用 Gemma 4 完整的上下文能力:
# 將上下文窗口設置為 32K tokens
ollama run gemma4:26b-moe --num-ctx 32768
# 將上下文窗口設置為 128K tokens (需要更多 RAM)
ollama run gemma4:26b-moe --num-ctx 131072
重要提示:較大的上下文窗口會為 KV cache 消耗更多 RAM。在 31B 模型上使用 128K 上下文窗口可能需要在模型權重之外額外增加 8-16GB 的 RAM。建議從 32K 開始,僅在您的使用場景需要時才增加。
並行請求
Ollama 支援同時處理多個請求:
# 允許最多 4 個並行請求
OLLAMA_NUM_PARALLEL=4 ollama serve
每個並行請求都會為其 KV cache 增加記憶體開銷。在運行 Q4_K_M 版 26B MoE (~18GB) 的 24GB GPU 上,您大約有 6GB 的餘裕 —— 足以處理 2-3 個具有短上下文的並行請求。
保持活躍設定
預設情況下,Ollama 在最後一次請求後會將模型保留在記憶體中 5 分鐘。您可以根據您的使用場景調整此設定:
# 將模型保留在記憶體中 1 小時
OLLAMA_KEEP_ALIVE=3600 ollama serve
# 永久保留模型在記憶體中
OLLAMA_KEEP_ALIVE=-1 ollama serve
# 每個請求後立即卸載 (節省記憶體)
OLLAMA_KEEP_ALIVE=0 ollama serve
NVIDIA RTX 優化
NVIDIA 已為 RTX GPU 發布了 優化版的 Gemma 4。這些優化包括:
- 針對 Gemma 4 注意力機制的 自定義 CUDA 核心
- 整合 TensorRT-LLM 以實現更快的推論
- 支援 Flash Attention,減少長上下文推論時的記憶體使用
- 優化的 KV cache 管理 以獲得更好的吞吐量
安裝 NVIDIA 優化版 Gemma 4
如果您擁有 RTX 4000 或 5000 系列 GPU:
# 檢查您的 GPU
nvidia-smi
# 拉取 NVIDIA 優化版本 (如果 Ollama 中可用)
ollama pull gemma4:31b-nvidia
或者,直接使用 NVIDIA AI Workbench 或 TensorRT-LLM 以獲得最大效能。與標準 Ollama 版本相比,NVIDIA 優化版本在 RTX GPU 上的推論速度可提升 30-50%。
真實效能基準測試
在常見硬體配置上的測量結果:
每秒 Token 數 (產生速度)
| 模型 | RTX 4090 (24GB) | RTX 3090 (24GB) | M3 Max (36GB) | 僅限 CPU (32GB) |
|---|---|---|---|---|
| E2B (Q4) | ~150 tok/s | ~120 tok/s | ~100 tok/s | ~30 tok/s |
| E4B (Q4) | ~100 tok/s | ~80 tok/s | ~70 tok/s | ~15 tok/s |
| 26B MoE (Q4) | ~40 tok/s | ~30 tok/s | ~25 tok/s | ~3 tok/s |
| 31B Dense (Q4) | ~30 tok/s | ~20 tok/s | ~20 tok/s | ~2 tok/s |
背景參考:人類閱讀速度約為每秒 4-5 個 tokens。任何產生速度超過 10 tok/s 的模型在互動式使用中都會感到「即時」。E2B 和 E4B 模型快到幾乎可以在任何硬體上進行即時串流傳輸。
首個 Token 產生時間 (延遲)
| 模型 | RTX 4090 | M3 Max | 僅限 CPU |
|---|---|---|---|
| E2B | <100ms | <200ms | <500ms |
| E4B | <200ms | <300ms | ~1s |
| 26B MoE | ~500ms | ~1s | ~5s |
| 31B Dense | ~800ms | ~1.5s | ~8s |
對於互動式應用程式,首個 token 的產生時間比整體產生速度更重要。E2B 和 E4B 模型即使在 CPU 上也能幾乎立即開始產生,是即時對話介面的理想選擇。
常見使用場景
本地編碼助手
將 Gemma 4 用作私人的編碼助手,絕不將您的代碼發送到外部伺服器:
ollama run gemma4:26b-moe --system "You are an expert software engineer. When given code, analyze it for bugs, suggest improvements, and explain your reasoning. Be concise and practical."
將其與支援 Ollama 作為後端的 VS Code 擴充功能(如 Continue 或 Twinny)配對使用。
文件分析
在本地處理敏感文件:
echo "Analyze this contract clause and identify potential risks: [paste clause]" | ollama run gemma4:31b
憑藉 256K 的上下文,31B 模型可以處理長達 ~750 頁的文件 —— 足以應對大多數合約、研究論文和技術文件。
本地 RAG (檢索增強生成)
將 Gemma 4 與本地向量資料庫結合,構建完全私人的 RAG 系統:
from langchain_community.llms import Ollama
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import Chroma
# 使用 Gemma 4 進行嵌入和產生
embeddings = OllamaEmbeddings(model="gemma4:e4b")
llm = Ollama(model="gemma4:26b-moe")
# 從您的文件中建立向量存儲
vectorstore = Chroma.from_documents(documents, embeddings)
# 使用 RAG 進行查詢
retriever = vectorstore.as_retriever()
docs = retriever.get_relevant_documents("What is our refund policy?")
context = "\n".join([doc.page_content for doc in docs])
response = llm.invoke(f"Based on this context:\n{context}\n\nAnswer: What is our refund policy?")
在應用程式中構建 AI 功能
對於正在構建具有 AI 功能應用程式的開發者,透過 Ollama API 在本地運行 Gemma 4 是實現工作原型最快的路徑。OpenAI 相容的 API 意味著您可以在開發期間使用本地的 Gemma 4,並在準備好擴展時切換到雲端 API,而無需更改應用程式代碼。
像 ZBuild 這樣的平台可以處理應用程式基礎架構 —— 前端、後端、身份驗證、資料庫 —— 而您則專注於 AI 整合層。在開發期間將應用程式的 AI 端點指向 localhost:11434,並在準備好規模化時更換為雲端端點。
疑難排解
「記憶體不足 (Out of memory)」錯誤
如果您看到記憶體錯誤:
- 嘗試較小的量化版本:
ollama pull gemma4:31b-q3_K_M - 減少上下文窗口:
--num-ctx 4096 - 關閉其他佔用 GPU 的應用程式
- 切換到較小的模型:26B MoE 在較低的記憶體成本下提供了接近 31B 的品質
產生速度慢
如果產生速度低於預期:
- 檢查 GPU 使用率:
nvidia-smi(應該顯示高 GPU 使用率) - 確保模型完全放入 VRAM 中 —— 部分 CPU 卸載會顯著降低速度
- 減少
--num-ctx以釋放 VRAM 用於計算 - 檢查是否有其他程序正在使用 GPU
找不到模型
如果 ollama run gemma4:26b-moe 失敗:
# 列出可用模型
ollama list
# 搜尋 Gemma 4 模型
ollama search gemma4
# 拉取特定模型
ollama pull gemma4:26b-moe
API 連線被拒絕
如果應用程式無法連接到 localhost:11434:
# 檢查 Ollama 是否正在運行
ollama list
# 手動啟動 Ollama 伺服器
ollama serve
# 檢查埠號
curl http://localhost:11434/api/tags
模型選擇決策樹
使用此流程快速選擇正確的模型:
您是否有配備 16GB+ VRAM 的獨立 GPU?
- 是 → 您想要最高品質還是最高效率?
- 最高品質 →
gemma4:31b(Q4_K_M, 需要 20GB) - 最高效率 →
gemma4:26b-moe(Q4_K_M, 需要 18GB)
- 最高品質 →
- 否 → 您是否有 8GB+ RAM?
- 是 →
gemma4:e4b(Q4_K_M, 品質較好) - 否 →
gemma4:e2b(Q4_K_M, 可在 5GB 上運行)
- 是 →
對於大多數擁有現代桌機或電競電腦的開發者:從 gemma4:26b-moe 開始。它在整個 Gemma 4 系列中提供了最佳的品質資源比。
您可以構建什麼
隨著 Gemma 4 在本地運行,您擁有了一個零成本的 AI 後端,可用於:
- 具有完整對話隱私的 對話應用程式
- 可在專有代碼庫上運作的 代碼分析工具
- 用於敏感數據的 文件處理流水線
- 可離線工作的 本地 AI 助手
- 在投入雲端 API 成本之前的 原型 AI 功能
- 用於特定領域任務的 微調模型 (Apache 2.0 允許自由進行此操作)
Apache 2.0 許可協議意味著您構建的一切都屬於您 —— 沒有使用限制、沒有利潤分成、不需要批准。在本地運行它,在您的伺服器上部署它,將其嵌入到您的產品中。這才是真正的開放 AI。