iT邦幫忙

2026 iThome 鐵人賽

DAY 8
0
AI Engineering

從 MCP 到專屬 Agentic 模型:30 天走完一條可評測、可微調、可自架的 AI Agent 模型與服務製作流程系列 第 18

[ Model Fine-Tuning ] Day 18 — Google Colab Pro 與 Colab CLI 工具鏈實戰:低成本跑通雲端訓練

  • 分享至 

  • xImage
  •  

Day 18 今日地圖:今天在整條閉環的位置、承接與產出

I. 前言:硬體不該是微調的門檻

在分享微調相關主題時,我最常聽到的一句話是:「我手邊只有一台 MacBook,沒有 RTX 4090,微調是不是與我無緣?」

答案是:完全不是。

這個誤解來自於把「微調」與「從頭訓練」混為一談。從頭訓練一個基座模型確實需要大量算力,但我們要做的是 LoRA 微調 —— 只更新約 0.1% 的參數,需要的資源少了一個數量級。

不過,即使算力門檻降低了,還有第二個障礙:工作流的摩擦

傳統上使用 Colab 的方式是打開瀏覽器、貼上程式碼、手動點擊執行、等待、再手動下載權重。這個流程在「跑一次實驗」時還能接受,但當您需要反覆迭代(改資料、改超參數、重訓、再評測)時,每一輪都要在瀏覽器與編輯器之間切換,摩擦會累積成相當可觀的時間成本。

Google 在 2026 年推出了官方的 Colab CLI,正是為了解決這個問題。它讓我們可以直接在本地終端機驅動雲端 GPU:開機、安裝套件、執行本地腳本、取回權重、關機,全部用指令完成。

以下的內容,將會先把顯存需求算清楚,接著說明 Colab CLI 的完整用法,並建立一條可重複執行的雲端訓練管線。

II. 先算清楚:微調到底需要多少顯存

在挑選硬體之前,先理解顯存到底花在哪裡。這個計算會讓您能自行判斷任何模型、任何配置的資源需求。

訓練時的顯存主要由四個部分組成:

表格:項目、說明、Full FT、LoRA

Gemma 4 E4B(有效 4B 參數) 為例,用 bf16 精度計算:

模型權重:4B × 2 bytes                    ≈ 8 GB

Full Fine-Tuning:
  梯度      4B × 2 bytes                  ≈ 8 GB
  優化器    4B × 2 × 4 bytes(fp32)      ≈ 32 GB
  小計                                     ≈ 48 GB + 啟動值

LoRA(r=16,約 0.1% 參數):
  梯度      4M × 2 bytes                  ≈ 0.008 GB
  優化器    4M × 2 × 4 bytes              ≈ 0.032 GB
  小計                                     ≈ 8 GB + 啟動值

差距的關鍵不在模型權重,而在優化器狀態。 AdamW 為每個可訓練參數保存兩份 fp32 狀態,這一項在 Full FT 中就佔了 32GB —— 而 LoRA 因為凍結了基座,這一項幾乎歸零。

加上啟動值(依 max_length=2048、batch size 2 估算約 4–6GB),LoRA 微調 4B 模型的實際需求大約在 12–16GB

對照 Colab 提供的 GPU

Colab CLI 支援的加速器包括 T4、L4、G4、A100、H100,以及 TPU(v5e1、v6e1)。以常見規格對照:

表格:GPU、顯存、適用情境

本系列建議選 L4。 24GB 對 4B 模型的 LoRA 微調有充足餘裕,可以把 batch size 開大、序列長度拉長,而且消耗的運算單元遠低於 A100。

若您想訓練更大的模型(如 Gemma 4 12B),可以改用 QLoRA(4-bit 量化)把權重壓到約 6GB,L4 依然跑得動 —— 代價是量化帶來的精度損失,這一點在系列後期討論部署時會再提到。

III. Google 官方 Colab CLI

Google Colab Pro + Colab CLI 雲端微調管線架構

Colab CLI 的定位是「把 Colab 的 VM 當成一台可以用指令操作的遠端機器」。它提供的能力包括:

  • 即時開機:幾秒內配置 CPU、GPU 或 TPU runtime
  • 執行本地程式碼:直接跑本地的 .py.ipynb,或從 stdin 管線輸入
  • 一次性任務colab run 會開機、執行、取回輸出、自動關機
  • 自動 keep-alive:背景常駐程式防止 VM 因閒置而被回收,不需要開著瀏覽器分頁
  • 檔案操作:上傳、下載、列出、刪除、就地編輯遠端檔案
  • 工作區整合:掛載 Google Drive、認證 GCP、用 uv 安裝套件
  • 記錄匯出:把 session 歷史輸出成 Notebook、Markdown 或 JSONL

平台限制:Colab CLI 目前只支援 Linux 與 macOS,尚未支援 Windows。若您使用 Windows,可以透過 WSL2 執行。

安裝

# 建議用 uv 安裝(速度快,且會建立隔離環境)
uv tool install google-colab-cli

# 或使用 pip
pip install google-colab-cli

需要 Python 3.12 以上

第一次連線

# 1. 開一個 CPU runtime 測試連線
colab new

# 2. 執行一段程式碼確認能通
echo "print('Hello from Google Colab!')" | colab exec

# 3. 關閉並釋放資源
colab stop

當只有一個 session 在執行時,可以省略 -s, --session 參數,CLI 會自動判斷。

第一次執行會需要進行 OAuth 認證。認證策略可以用 --auth 切換(預設為 oauth2,也支援 adc)。

IV. 指令全覽

以下依用途分類。實際使用時,colab <command> --help 可以查看每個指令的完整選項。

Session 管理

表格:指令、說明

程式執行

表格:指令、說明

檔案操作

表格:指令、說明

自動化與工具

表格:指令、說明

V. 建立訓練工作流

現在把這些指令組合成一條可重複執行的管線。

步驟 1:開機並安裝環境

# 開一個名為 trainer 的 L4 GPU session
colab new -s trainer --gpu L4

# 確認硬體規格
colab status -s trainer

# 安裝訓練依賴(Colab CLI 會用 uv 加速)
colab install -s trainer trl peft transformers datasets accelerate bitsandbytes

colab install 內部使用 uv,安裝速度比 pip 快上不少。若您有 requirements.txt,也可以用 -r 指定:

colab install -s trainer -r requirements.txt

步驟 2:上傳訓練資料

Day 16 準備好的 JSONL 需要傳到 VM 上:

colab upload -s trainer ./data/train_v1.jsonl /content/data/train_v1.jsonl
colab upload -s trainer ./data/valid_v1.jsonl /content/data/valid_v1.jsonl

若資料量較大,建議改走 Google Drive

colab drivemount -s trainer

掛載後,Drive 中的檔案會出現在 /content/drive/MyDrive/ 底下。這種方式的好處是資料只需要上傳一次,之後每次開新 VM 都能直接讀取。

步驟 3:執行訓練腳本

colab exec -s trainer -f train_sft.py

這裡有一個相當方便的設計colab exec -f 會在本地讀取檔案內容、傳送到遠端 kernel 執行 —— 您不需要先手動上傳腳本。這意味著可以在本地編輯器修改程式碼,存檔後直接重跑,迭代速度接近本地開發。

訓練過程的輸出會即時回傳到終端機,可以直接看到 loss 曲線的數值變化。

這裡有個一定會踩到的預設值:--timeout 只有 30 秒。 colab execcolab run 都一樣,而 LoRA 訓練動輒一兩個小時,不調的話一定被中斷。抓寬一點:

colab exec -s trainer -f train_sft.py --timeout 14400   # 四小時

步驟 4:取回權重並關機

# 下載 LoRA adapter
colab download -s trainer /content/out/leave-copilot-v1/adapter_model.safetensors ./models/
colab download -s trainer /content/out/leave-copilot-v1/adapter_config.json ./models/

# 匯出這次 session 的完整記錄,留作實驗紀錄
colab log -s trainer -o experiments/run_v1.md

# 關機釋放資源
colab stop -s trainer

colab log 這個指令值得特別推薦。 之後討論二次訓練決策時,會需要回顧「這一輪到底改了什麼、結果如何」,而這份自動產生的記錄比事後憑記憶重建可靠得多。它支援輸出成 .ipynb.md.txt.jsonl

VI. 兩種模式:常駐 Session 與一次性任務

Colab CLI 提供兩種工作模式,適用場景不同。

模式 A:常駐 session(適合開發迭代)

就是上面示範的流程 —— colab new 開機後保持連線,反覆執行、修改、再執行。

優點:套件只需安裝一次,資料只需上傳一次,迭代速度快。
適用:正在調參、除錯,需要反覆嘗試的階段。

模式 B:colab run 一次性任務(適合正式訓練)

colab run --gpu L4 --timeout 14400 train_sft.py --epochs 3 --lr 1e-4

這一個指令會完成:配置全新 VM → 執行本地腳本(並轉發參數)→ 取回輸出檔案 → 自動釋放 runtime

優點:不會忘記關機,運算單元不會白白消耗。
適用:設定已經確定、要跑正式訓練的階段。

若希望任務結束後保留 VM 以便檢查,可以加上 --keep

實務建議:開發階段用模式 A,正式訓練用模式 B。我看過太多人在調參階段忘了關機,隔天才發現運算單元被閒置的 VM 吃光 —— 雖然 CLI 有 keep-alive daemon 防止意外斷線,但它不會幫您判斷「是不是該關機了」。

VII. 實務上會遇到的問題

1. Checkpoint 一定要寫到 Drive

Colab 的 VM 是暫時性的,一旦 runtime 被回收,/content 底下的檔案就全部消失。訓練跑到一半斷線而沒有保存 checkpoint,等於整輪白費。

正確做法是在訓練腳本裡把 output_dir 指向掛載的 Drive:

from trl import SFTConfig

args = SFTConfig(
    output_dir="/content/drive/MyDrive/leave-copilot/out/v1",  # ★ 寫到 Drive
    save_strategy="steps",
    save_steps=50,
    save_total_limit=3,     # 只留最近三個,避免佔滿空間
)

這樣即使連線中斷,最近的 checkpoint 也已經安全保存,重新開機後可以用 resume_from_checkpoint 續訓。

2. 運算單元的消耗速度

Colab Pro 採用運算單元(compute units)計費,不同 GPU 的消耗速率差異相當大。A100 的消耗速度是 L4 的數倍,而對 4B 模型的 LoRA 微調來說,A100 帶來的速度提升往往不值得那個價差

colab status 可以查看當前 session 的資源狀態,colab pay 則會開啟訂閱管理頁面。

3. 互動式指令需要 TTY

colab replcolab console 需要本地 TTY。若在自動化腳本或 CI 中執行,記得用管線輸入以觸發非互動模式:

echo "print(1)" | colab repl

4. 設定檔位置

Session token 與中繼資料存放在 ~/.config/colab-cli/sessions.json,全域設定則在 ~/.config/colab-cli/settings.json。若需要隔離不同專案的 session,可以用全域選項 --config 指定不同路徑。

VIII. 一個延伸方向:Colab MCP Server

如果您對 Day 3–4 的 MCP 主題有印象,這裡有一個值得注意的呼應。

Google 同時提供了 Colab MCP Server —— 它讓 AI Agent 能夠透過 MCP 協定操作 Colab 環境。換句話說,前面幾天我們建立的 MCP 概念,同樣適用於「讓 Agent 幫你跑訓練」這個場景。

這不在本系列的範圍內,但它說明了一件事:MCP 正在成為 AI 工具鏈的通用介面,而不只是「讓模型查資料庫」的技術。

IX. 結語

雲端 GPU 與 CLI 工具鏈的成熟,讓「為特定任務微調專屬模型」這件事的硬體門檻大幅降低。真正的成本已經不在顯卡,而在資料準備與評測體系的建立 —— 也就是我們前面十七天所做的事。

總結來說,今天有三個重點值得帶走:

  • 顯存的差距主要來自優化器狀態,而非模型權重: AdamW 為每個可訓練參數保存兩份 fp32 狀態,這在 Full FT 中就佔了 32GB。LoRA 凍結基座之後這一項幾乎歸零,讓 4B 模型的微調從 48GB 降到 12–16GB。理解這個結構,就能自行估算任何模型的資源需求。
  • colab exec -f 讓迭代速度接近本地開發: 它在本地讀取檔案內容並傳送到遠端執行,不需要預先上傳。搭配常駐 session 使用,可以在本地編輯器修改後直接重跑。
  • Checkpoint 一定要寫到掛載的 Drive: Colab 的 VM 是暫時性的,/content 底下的檔案會隨 runtime 回收而消失。這是雲端訓練最容易造成整輪白費的失誤,而它完全可以用一行設定避免。

明天處理訓練前的最後把關 —— Prompt Template 的取捨與 Sanity Check。其中的過擬合測試只需要幾分鐘,卻能提前攔下五類會讓數小時訓練白費的錯誤。

Day 18 Cheat Sheet:指令、參數與容易踩的地方


參考來源

查證日期:2026-08-24


I am Simon

大家好,我是 Simon 劉育維,是一位 AI 領域解決方案專家,目前也擔任 Google Cloud AI 領域開發者專家 (GDE),期待能夠幫助企業導入人工智慧相關技術解決問題。如果這篇文章對您有幫助,歡迎在我的 Linkedin 上留言提供意見,並與我一起討論有關人工智慧的主題,期待能夠對大家有所幫助!

我的個人部落格資訊:https://medium.com/@simon3458


上一篇
[ Model Fine-Tuning ] Day 17 — 開源基座模型選型與 Loss Mask 原理:不懲罰環境輸出
下一篇
[ Model Fine-Tuning ] Day 19 — Prompt Template 取捨與訓練前 Sanity Check:先跑通再放大
系列文
從 MCP 到專屬 Agentic 模型:30 天走完一條可評測、可微調、可自架的 AI Agent 模型與服務製作流程30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言