
在分享微調相關主題時,我最常聽到的一句話是:「我手邊只有一台 MacBook,沒有 RTX 4090,微調是不是與我無緣?」
答案是:完全不是。
這個誤解來自於把「微調」與「從頭訓練」混為一談。從頭訓練一個基座模型確實需要大量算力,但我們要做的是 LoRA 微調 —— 只更新約 0.1% 的參數,需要的資源少了一個數量級。
不過,即使算力門檻降低了,還有第二個障礙:工作流的摩擦。
傳統上使用 Colab 的方式是打開瀏覽器、貼上程式碼、手動點擊執行、等待、再手動下載權重。這個流程在「跑一次實驗」時還能接受,但當您需要反覆迭代(改資料、改超參數、重訓、再評測)時,每一輪都要在瀏覽器與編輯器之間切換,摩擦會累積成相當可觀的時間成本。
Google 在 2026 年推出了官方的 Colab CLI,正是為了解決這個問題。它讓我們可以直接在本地終端機驅動雲端 GPU:開機、安裝套件、執行本地腳本、取回權重、關機,全部用指令完成。
以下的內容,將會先把顯存需求算清楚,接著說明 Colab CLI 的完整用法,並建立一條可重複執行的雲端訓練管線。
在挑選硬體之前,先理解顯存到底花在哪裡。這個計算會讓您能自行判斷任何模型、任何配置的資源需求。
訓練時的顯存主要由四個部分組成:

以 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 CLI 支援的加速器包括 T4、L4、G4、A100、H100,以及 TPU(v5e1、v6e1)。以常見規格對照:

本系列建議選 L4。 24GB 對 4B 模型的 LoRA 微調有充足餘裕,可以把 batch size 開大、序列長度拉長,而且消耗的運算單元遠低於 A100。
若您想訓練更大的模型(如 Gemma 4 12B),可以改用 QLoRA(4-bit 量化)把權重壓到約 6GB,L4 依然跑得動 —— 代價是量化帶來的精度損失,這一點在系列後期討論部署時會再提到。

Colab CLI 的定位是「把 Colab 的 VM 當成一台可以用指令操作的遠端機器」。它提供的能力包括:
.py、.ipynb,或從 stdin 管線輸入colab run 會開機、執行、取回輸出、自動關機uv 安裝套件平台限制: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)。
以下依用途分類。實際使用時,colab <command> --help 可以查看每個指令的完整選項。




現在把這些指令組合成一條可重複執行的管線。
# 開一個名為 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
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 都能直接讀取。
colab exec -s trainer -f train_sft.py
這裡有一個相當方便的設計:colab exec -f 會在本地讀取檔案內容、傳送到遠端 kernel 執行 —— 您不需要先手動上傳腳本。這意味著可以在本地編輯器修改程式碼,存檔後直接重跑,迭代速度接近本地開發。
訓練過程的輸出會即時回傳到終端機,可以直接看到 loss 曲線的數值變化。
這裡有個一定會踩到的預設值:
--timeout只有 30 秒。colab exec與colab run都一樣,而 LoRA 訓練動輒一兩個小時,不調的話一定被中斷。抓寬一點:colab exec -s trainer -f train_sft.py --timeout 14400 # 四小時
# 下載 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。
Colab CLI 提供兩種工作模式,適用場景不同。
就是上面示範的流程 —— colab new 開機後保持連線,反覆執行、修改、再執行。
優點:套件只需安裝一次,資料只需上傳一次,迭代速度快。
適用:正在調參、除錯,需要反覆嘗試的階段。
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 防止意外斷線,但它不會幫您判斷「是不是該關機了」。
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 續訓。
Colab Pro 採用運算單元(compute units)計費,不同 GPU 的消耗速率差異相當大。A100 的消耗速度是 L4 的數倍,而對 4B 模型的 LoRA 微調來說,A100 帶來的速度提升往往不值得那個價差。
colab status 可以查看當前 session 的資源狀態,colab pay 則會開啟訂閱管理頁面。
colab repl 與 colab console 需要本地 TTY。若在自動化腳本或 CI 中執行,記得用管線輸入以觸發非互動模式:
echo "print(1)" | colab repl
Session token 與中繼資料存放在 ~/.config/colab-cli/sessions.json,全域設定則在 ~/.config/colab-cli/settings.json。若需要隔離不同專案的 session,可以用全域選項 --config 指定不同路徑。
如果您對 Day 3–4 的 MCP 主題有印象,這裡有一個值得注意的呼應。
Google 同時提供了 Colab MCP Server —— 它讓 AI Agent 能夠透過 MCP 協定操作 Colab 環境。換句話說,前面幾天我們建立的 MCP 概念,同樣適用於「讓 Agent 幫你跑訓練」這個場景。
這不在本系列的範圍內,但它說明了一件事:MCP 正在成為 AI 工具鏈的通用介面,而不只是「讓模型查資料庫」的技術。
雲端 GPU 與 CLI 工具鏈的成熟,讓「為特定任務微調專屬模型」這件事的硬體門檻大幅降低。真正的成本已經不在顯卡,而在資料準備與評測體系的建立 —— 也就是我們前面十七天所做的事。
總結來說,今天有三個重點值得帶走:
colab exec -f 讓迭代速度接近本地開發: 它在本地讀取檔案內容並傳送到遠端執行,不需要預先上傳。搭配常駐 session 使用,可以在本地編輯器修改後直接重跑。/content 底下的檔案會隨 runtime 回收而消失。這是雲端訓練最容易造成整輪白費的失誤,而它完全可以用一行設定避免。明天處理訓練前的最後把關 —— Prompt Template 的取捨與 Sanity Check。其中的過擬合測試只需要幾分鐘,卻能提前攔下五類會讓數小時訓練白費的錯誤。

SFTConfig 的 checkpoint 相關設定查證日期:2026-08-24
大家好,我是 Simon 劉育維,是一位 AI 領域解決方案專家,目前也擔任 Google Cloud AI 領域開發者專家 (GDE),期待能夠幫助企業導入人工智慧相關技術解決問題。如果這篇文章對您有幫助,歡迎在我的 Linkedin 上留言提供意見,並與我一起討論有關人工智慧的主題,期待能夠對大家有所幫助!
我的個人部落格資訊:https://medium.com/@simon3458