星期六, 8月 22, 2026

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

Ollama


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 峰值 Swap 佔用 CPU 使用率 測試狀態
512 tokens 32.14 秒 7.49 tps 2,802.8 MB 0.0 MB 53.7% ✅ 通過
1,024 tokens 49.92 秒 6.61 tps 2,872.4 MB 0.0 MB 52.5% ✅ 通過
2,048 tokens 85.26 秒 5.54 tps 3,002.9 MB 0.0 MB 57.5% ✅ 通過
4,096 tokens 102.63 秒 (1.7分) 5.77 tps 3,041.0 MB 0.0 MB 63.4% ✅ 通過
8,192 tokens 211.48 秒 (3.5分) 4.35 tps 3,455.0 MB 0.0 MB 60.0% ✅ 通過
16,384 tokens 1.16 秒 (窗口滾動) 4.32 tps 3,500.6 MB 0.0 MB 52.5% ✅ 通過
32,768 tokens 1.34 秒 (窗口滾動) 4.28 tps 3,528.5 MB 0.0 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 :)


星期六, 8月 15, 2026

2026 Google IO China 小記


2026 Google IO China 小記


今年有幸因為 GDE 的關係, 獲邀參加 Google IO China 研討會


首先要先謝謝 Google Eric ShangKuan  (  https://www.linkedin.com/in/ericsk/ ) , Yuying Tsai ( https://www.linkedin.com/in/yuying-tsai/  ) 以及所有項目組的夥伴組織活動與規劃.


這次的研討會主要是 4 天的行程, 亞洲的 GDG 與 GDE 都會共同參加與交流


第一天晚上是 Community Welcome Dinner


首先是很開心收到項目組安排的禮物



  • 研討會有 Dress code 個人覺得很好, 可以很快的識別與交流


晚上由接駁車接送到 其昌栈码头



在船上舉行歡迎晚宴與互動



採取 Buffet 的方式, 既可以交流互動也可以滿足 211 餐盤需求


上次去上海應該是 14 年前, 去內蒙當志願者, 但是那個時候沒有機會好好看黃浦江, 感謝 Google 可以讓我多解鎖一個成就


第二天與第三天 正式參加 Google IO China 


首先是 Keynote



這邊我覺得很棒的地方是所有的位置都有即時翻譯的耳機, 可以在外賓英文演說的時候使用中文聽講, 如我大家有興趣也可以從剛剛的會議首頁還觀察回放, 我覺得即時翻譯的部分很有品質


議程的部分 https://ioconnectchina.googlecnapps.cn/sessions/ 

  • 8/12 是 AI 與 Chrome

    • 這一天我主要聚焦在 Gemma 的相關議程, 也看得出 Google 在 Gemma 於不同設備, 例如 眼鏡或是端點裝置有了很多的案例與投入, 以及 Cloud Run / GKE 結合 Gemma 的相關案例與資訊, 這個部分吸引了我對於這方面的投入.

    • 另外我覺得有一個很棒的點是有社會公益案例分享, 這個方向放到正式商業議程內, 我在台灣的研討會還真的沒有太大的印象, 我有去參訪華南理工大學 (https://www.scut.edu.cn/new/ ) 的攤位, 詢問有關於他們設計的線上教育平台, 使用 Gemma 來進行教育輔助, 也有把相關程式碼放到 Github 上面, 覺得很棒

  • 8/13 是 Android 與 Cloud 

    • 這一天當然是聚焦在 Cloud 議程上

    • Ankur Kotwal 一開始以即時英文翻中文的語音介面, 給大家很深刻的印象, 介紹相關的技術以及使用 Agents CLI ( https://github.com/google/agents-cli ) 即時打造剛剛的翻譯語音介面 讓大家對 agents cli 這個工具的學習與使用更有興趣

    • 另外也提到 Google Skills ( https://www.skills.google/ )來串 workshop 與相關研習及介紹

    • 史洁 的 超级个体 到 AI 原生组织 的 Level 1 ~ Level 5 區分與 Policy 控管與演進也進一步把 AI 治理想法讓參與的會眾了解, 為何要採取企業的方案而不是各自單打獨鬥


工作坊的部分 ( https://ioconnectchina.googlecnapps.cn/workshops/ )

  • 一樣包涵 4 個面向 ( AI / Chrome / Android / Cloud ), 採取登記制與現場候補機制

  • 我有候補排上 从开发到生产,全面体验 Agent Platform 中的 Agent CLI

    • 使用 Google Skills 的 Lab 課程讓參與的學員體驗 agents cli 安裝與應用實作, 透過 Kahoot 與學員互動及增加相關知識亮點


開發者沙龍的部分 ( https://ioconnectchina.googlecnapps.cn/meetups/ ) 



接下來聊聊其他的


首先是攤位的部分



  • Gemini 奇趣影棚 可以讓參展人快速得到不同面向的照片,增加參與感以及感受 Gemini 的功能



也有不同面向的攤位, 如同剛剛說的社會公益 / 藝術攤位


以及不同面向的 Google 攤位


現場有很多地方都有小冰櫃, 也是小亮點


午餐飯盒真的也是管飽, 裡面竟然還有三杯雞 :)


第四天也是最後一天是 GDE Summit , 地點在 Google 上海辦公室




最後再次感謝 Google 的邀約與所有項目組的辛苦付出


也很開心可以有這個機會與大家交流





References