第一次微調完成後，我開始嘗試多音節測試。雖然單音節的結果證明模型能跑，但真正的挑戰才剛開始。
我原本都在 Google Colab 上進行微調，因為它的環境友善、幾乎不用自己設定，對初學者來說非常方便。然而，就在我準備進行第二次大規模微調時，發現 Colab 對免費資源的限制比我想像中嚴格。系統沒有再分配 GPU 資源給我，最後只能改用 CPU 跑，導致訓練效率慘不忍睹。這也讓我意識到，不能再單純依賴 Colab。
我當時的想法其實很單純，Checkpoint 放在 Google Drive，不就等於一邊訓練、一邊自動備份嗎？
結果實際跑起來才發現，訓練程式會一直寫入 Checkpoint，而同步軟體也會跟著處理這些檔案。對一般文件來說，這種同步方式很方便；但對會持續產生大型模型檔案的訓練工作來說，情況就完全不一樣了。最後我不是模型跑不動，而是先被硬碟空間逼到停機。
結果因為 Checkpoint 頻繁寫入，加上同步軟體不斷嘗試上傳大量資料，瞬間吃光了硬碟空間，導致電腦跳出「空間不足」的警告，訓練也宣告失敗。
這場清理硬碟的大工程，讓我發現「資料儲存與環境建置」本身也是訓練流程的一部分。模型能不能跑，並不只是看 GPU 夠不夠，Checkpoint 要存在哪裡、資料放在哪裡、磁碟空間夠不夠，全部都會影響實驗能不能順利完成。
在那之前，我對模型訓練的想像其實比較像「準備好資料 → 選 GPU → 按下 Train → 等結果」。但實際開始長時間訓練後，才發現真正需要處理的事情一大堆：資料放哪裡、模型存哪裡、Checkpoint 留多少、硬碟剩多少空間、電腦會不會休眠，甚至訓練期間能不能讓這台電腦正常做其他事情，都可能影響一次實驗能不能完成。
而且我一開始也沒有意識到，Checkpoint 不只是「存一個模型」。訓練過程中除了模型權重，還可能保存 optimizer、scheduler、trainer state 等訓練狀態。如果設定定期儲存，訓練跑得越久，留下來的 Checkpoint 就可能越來越多。
這段經歷也讓我開始重新整理自己到底有哪些訓練資源可以使用。當時 Colab GPU 額度用完之後，我只知道把訓練搬回自己的電腦；後來才發現，其實還有其他雲端 GPU 可以選擇。現在回頭整理這段經歷，我也順便把幾個常見的選項整理在一起。之後如果再遇到 GPU 不夠用的情況，至少不用第一時間就把自己的電腦當成訓練伺服器。
如果只是快速測試模型，Google Colab 其實已經很好用。它提供免費 GPU，但可用資源並不是固定的，GPU 不一定隨時都有，使用時間與額度也會依當下資源分配與使用情況變動，所以很適合拿來做 Notebook 實驗、快速測試模型，但不太適合把長時間訓練完全押在上面。
Kaggle Notebooks 則是另一個可以拿來訓練模型的免費 GPU 選項。官方目前提供每週約 30 個 GPU 小時的使用額度，但單次 Session 最長約 9 小時。對需要跑幾個小時的模型來說，比較有明確的使用量可以規劃，不過如果一次訓練超過 9 小時，就還是需要處理 Session 中斷的問題。
Hugging Face ZeroGPU 的定位又不太一樣。免費帳號目前每天大約只有 5 分鐘的 GPU 使用額度，因此比較適合拿來做模型 Demo、推論或非常輕量的測試。如果要拿它進行長時間的模型微調，這個額度基本上不太夠用。
Lightning AI 則比較接近於把 GPU 訓練環境放到雲端長時間跑的選擇。目前免費方案最多提供 30 Credits，官方估算使用 interruptible GPU 時，最多約可以換到 80 個 GPU 小時。不過這不是固定的 80 小時，實際能跑多久還是會依使用的 GPU 類型而有所不同；Credits 用完之後，就需要另外付費。
所以最後我做了一個非常樸素的決定：既然雲端 GPU 不給我，那就用自己的 GPU。 可以自己決定什麼時候開始、跑多久，也能完全控制訓練環境。代價則是所有事情都要自己負責，包括電力、散熱、硬體壽命，以及訓練期間電腦本身被長時間佔用的問題。對我來說，當時就是直接選了這條路。
現在回頭看，如果只是快速實驗，Colab 已經非常方便；需要比較明確的免費 GPU 訓練額度，可以考慮 Kaggle；ZeroGPU 比較適合 Demo 與推論；如果需要長時間把訓練放在雲端執行，Lightning AI 會比較接近這種需求；而本機 GPU 則是用硬體成本換取較高的自主性。
我的電腦顯卡只有 RTX 3050，一次訓練得跑快十個小時，有時甚至拉長到 16 小時。為了利用時間，我試過在睡覺時跑模型，但還得跟電腦的休眠設定鬥智。
在硬體有限的情況下，資料錯誤的代價是極其高昂的。往往只是一個標籤對齊的小失誤，就代表我浪費掉了整晚的訓練時間，第二天醒來只能面對失敗的結果，無奈地重頭來過。
隨著訓練迭代增加，我體悟到 Pipeline 往往比模型架構更決定成敗。在語音任務中，音檔與 Label 的精確對齊是核心。若資料處理階段存在偏差，即便參數調得再優，產出也會嚴重失真。因此，Debug 的重心不應僅限於 Loss Function，更應建立嚴謹的前處理驗證機制，否則再快的 GPU 資源，也只是在加速產出一個錯誤的模型。
這些技術細節讓我不得不反覆重新整理資料、重新訓練，也開始意識到，真正需要解決的問題可能不是怎麼把模型跑得更久，而是怎麼確定拿給模型的資料是對的。
接下來的幾天，我會把這些資料處理過程一個一個拆開來看，從音檔整理、標籤處理，到後來遇到的變調與 Unicode 問題，看看一份看似可以直接拿來訓練的資料，到底還藏著多少坑。我是微微，明天見！
iThome鐵人賽
看影片追技術