sakananote: GCP with gemma4 實驗小記

GCP with gemma4 實驗小記

環境:

GCP GCE (e2-custom-4-8192 / g2-standard-4 Spot)
GCP Cloud Run with L4 GPU (Serverless)
Ollama 0.32.14 / vLLM / Docker
Cline CLI 3.0.55

最近想測測看8GB 記憶體的筆電, 如果因成本或是資料考量可以跑哪些落地的模型？主要測試模型為 Google Gemma 4 (2B / E2B) 模型, 模型的資訊可以參考

https://ai.google.dev/gemma/docs/core?hl=zh-tw

想知道不同算力的表現以及環境極限，另外接上 ollama 與 Cline CLI 進行任務流暢度測試。

測試的環境為以下 3 個

GCE 純 CPU ( e2-custom-4-8192 )
GCE L4 GPU ( g2-standard-4 Spot )
Cloud Run with L4 GPU

Cline CLI

GitHub https://github.com/cline/cline
也可以參考之前的文章

Ollama

官網 https://ollama.com

1. GCE without GPU：純 CPU 模擬 8GB 記憶體極限與階梯壓測

為了模擬本機 M3 筆電環境承受力，在 GCP 台灣機房 (`asia-east1-c`) 開一台 4 vCPU / 8GB RAM 的純 CPU Spot 實例來精準模擬 8GB 筆電的物理極限，每小時成本只要約 NT$ 1.1 元：

# 建立台灣區 4 vCPU + 8GB RAM 純 CPU 模擬機 (Spot)
gcloud compute instances create gemma4-cpu-sim \
    --zone=asia-east1-c \
    --custom-cpu=4 \
    --custom-memory=8192MB \
    --provisioning-model=SPOT \
    --image-family=ubuntu-2204-lts \
    --image-project=ubuntu-os-cloud \
    --boot-disk-size=50GB \
    --boot-disk-type=pd-balanced

接下來透過自寫的測試腳本進行 512 到 32k tokens 的階梯式 Context 壓力測試，實測數據如下：

📊 測試一：Gemma 2B (INT4, 1.6 GB) 階梯實測數據（安全綠燈）

Context 長度	首字延遲 (TTFT)	解碼速度 (TPS)	實體 RAM 峰值	CPU 使用率	測試狀態
512 tokens	32.14 秒	7.49 tps	2,802.8 MB	53.7%	✅ 通過
1,024 tokens	49.92 秒	6.61 tps	2,872.4 MB	52.5%	✅ 通過
2,048 tokens	85.26 秒	5.54 tps	3,002.9 MB	57.5%	✅ 通過
4,096 tokens	102.63 秒 (1.7分)	5.77 tps	3,041.0 MB	63.4%	✅ 通過
8,192 tokens	211.48 秒 (3.5分)	4.35 tps	3,455.0 MB	60.0%	✅ 通過
16,384 tokens	1.16 秒 (窗口滾動)	4.32 tps	3,500.6 MB	52.5%	✅ 通過
32,768 tokens	1.34 秒 (窗口滾動)	4.28 tps	3,528.5 MB	52.5%	✅ 通過

💥 測試二：Gemma 4 E2B (7.2 GB 完整版) 8GB 記憶體物理極限實測（超載紅燈）

Context 長度	首字延遲 (TTFT)	實體 RAM 峰值	Load Average	測試狀態	崩潰原因分析
512 tokens	> 600 秒 (超時)	7,922.0 MB (96.7%)	36.42 (嚴重超載)	❌ TIMEOUT	7.2GB 塞滿 8GB RAM，引發 Memory Thrashing，CPU 癱瘓
1,024 tokens	> 600 秒 (超時)	7,931.2 MB (96.8%)	33.12 (嚴重超載)	❌ TIMEOUT	實體記憶體徹底枯竭 (< 100MB)，Kernel 反覆回收記憶體超時

純 CPU 邊界結論：

2B INT4 量化版：記憶體佔用落在 2.8 ~ 3.5 GB，全流程 0 MB Swap，容量極度安全。但純 CPU 的 Prefill（首字延遲）是最大軟肋，8k context 光等第一個字就要等 3.5 分鐘。
7.2GB 未量化大模型：直接把 8GB 記憶體吃光，系統狂換頁崩潰。8GB 設備千萬別越級挑戰 7GB 以上的大模型。
Modelfile 注入 Tool Calling：透過自訂 Modelfile 宣告 {{ range .Tools }} 可以解除 Ollama 官方標籤的門禁限制；但 2B 模型純靠 Prompt 注入時，容易受原廠 Safety RLHF 誤觸發，指令調用時會吐出「我是語言模型不能執行指令」的防護回答 :)

感想: 在這個狀態下 gemma4 2b 是可以運作的, 但是因為規格的關係, 使用者體驗與速度是遠遠不及格

2. GCE with GPU：G2 專用實例 + NVIDIA L4 (24GB) 滿血版實測

接下來想要知道架構提升於體驗上的差異, 使用專用機型 g2-standard-4 , 內建 1 張 24GB L4 GPU + 4 vCPU + 16GB RAM，不用也不需要手動外掛。開啟 Spot 模式每小時僅約 NT$ 8~11 元：

# 建立 GCE L4 GPU Spot 滿血實例 (台灣彰化機房)
gcloud compute instances create gemma4-l4-server \
    --zone=asia-east1-c \
    --machine-type=g2-standard-4 \
    --provisioning-model=SPOT \
    --image-family=common-cu129-ubuntu-2204-nvidia-580 \
    --image-project=deeplearning-platform-release \
    --boot-disk-size=150GB

載入 Gemma 4 E2B (7.2 GB) 後執行 nvidia-smi，實測結果非常驚艷：

顯存佔用僅 12.7%：模型載入後僅佔用 2,924 MiB (~2.9 GB) 顯存，剩餘高達 20.1 GB 顯存，能完整吞下 128k 超長 Context Window。
秒級極速回應：首字延遲 (TTFT) 從純 CPU 的 100 多秒驟降至 45 毫秒，生成速度達 90 ~ 120 tokens/s。
原生 Thinking 與精準 Tool Calling：完全解決了 2B 小模型的安全防護誤判問題，模型會先在內部進行思考分析需求，再精準輸出標準 tool_calls 結構。

透過 SSH 隧道轉發到本機，並啟動 Cline CLI 進行 Multi-Agent 協同測試：

# 1. 建立 SSH 本地加密隧道
gcloud compute ssh gemma4-l4-server --zone=asia-east1-c -- -N -L 11434:localhost:11434

# 2. 啟動 Cline CLI 互動 TUI 介面
cline -i

在終端機指派複雜任務（「建立 teammate 去執行 head -n 15 README.md 並回報結果」）：Lead Agent 自主調用 spawn_agent 派工，子代理執行終端指令抓取內容並彙整，最後自動呼叫 ask_question 提供互動選項，達成 100% 自主 Multi-Agent

感想: 只能說架構真的有差異, 不管是 gemma 2b / e2b 都是非常絲滑與反應迅速

3. Cloud Run with GPU：Serverless 雲原生無伺服器架構

另外一個測試是 Cloud Run with L4 GPU 不用開開關關 GCE 或是使用 ssh 轉 port, 使用 cloud run 是很好的方式, 可以使用完即關閉或是設定 instance = 0 的方式來節費或是避免誤用：

# 部署至 Cloud Run with 1x NVIDIA L4 GPU (Serverless)
gcloud beta run deploy gemma4-e2b-cloudrun \
    --image=asia-east1-docker.pkg.dev/sakana-2026-gcp/gemma-repo/gemma4-e2b:latest \
    --gpu=1 \
    --gpu-type=nvidia-l4 \
    --cpu=4 \
    --memory=16Gi \
    --min-instances=0 \
    --max-instances=1 \
    --region=asia-southeast1 \
    --no-gpu-zonal-redundancy \
    --allow-unauthenticated \
    --set-env-vars="API_KEY=my-gemma-key-2026"

Cloud Run GPU 架構核心特色：

Scale-to-Zero（閒置零費用）：沒有推論請求時自動縮容至 0 實例，運算費用為 $0.00 元。推論時按秒計費（約 $0.000324 USD / 秒）。搭配 7.2GB 映像檔儲存費（約 NT$ 23 元/月），一般日常開發每月總花費僅在 NT$ 70 ~ 450 元 區間。
原生 HTTPS 直連：直接取得 Google 官方 HTTPS 網址，Cline CLI 免開任何 SSH 背景隧道即可直連。
容器層 API Key 防護：在 Dockerfile 內建 FastAPI 認證閘道，未帶有效 Key 之請求在 0.1 秒內直接回傳 401 Unauthorized，有效防範盜連。

一鍵休眠與喚醒錢包防禦機制：

# 一鍵強制休眠 (保證 0 實例啟動，$0 元)
gcloud run services update gemma4-e2b-cloudrun --region=asia-southeast1 --max-instances=0

# 一鍵喚醒 (恢復隨叫隨用)
gcloud run services update gemma4-e2b-cloudrun --region=asia-southeast1 --max-instances=1

4. 三種架構橫向對比與環境清理

架構方案	算力規格	推論速度 (E2B)	連線方式	計費與預估成本	最佳適用情境
GCE without GPU	4 vCPU / 8GB RAM	~7.5 tps (TTFT 32~211s)	SSH Tunnel	Spot 約 NT$ 1.1 / hr	極限壓測、短 Prompt 本地輕量工具
GCE with GPU	1x NVIDIA L4 (24GB)	90~120 tps (TTFT < 50ms)	SSH Tunnel / IP 白名單	Spot 約 NT$ 8~11 / hr	長時間密集 Agent 任務、大型程式庫解析
Cloud Run with GPU ⭐	1x NVIDIA L4 (24GB)	90~120 tps (TTFT < 50ms)	原生 HTTPS 直連	按秒計費（閒置 $0 元）	日常開發隨叫隨用、行動辦公零運維首選

實驗完成後養成良好習慣銷毀雲端資源，確保帳單零殘留：

# 刪除 GCE 實例
gcloud compute instances delete gemma4-l4-server --zone=asia-east1-c --quiet

# 刪除 Cloud Run 服務
gcloud run services delete gemma4-e2b-cloudrun --region=asia-southeast1 --quiet

又前進一步 ~ enjoy it :)

sakananote

星期六, 8月 22, 2026

GCP with gemma4 實驗小記

GCP with gemma4 實驗小記

1. GCE without GPU：純 CPU 模擬 8GB 記憶體極限與階梯壓測

2. GCE with GPU：G2 專用實例 + NVIDIA L4 (24GB) 滿血版實測

3. Cloud Run with GPU：Serverless 雲原生無伺服器架構

4. 三種架構橫向對比與環境清理

沒有留言: