我第一次真的跑到 python train_lora.py，不是死在顯卡，也不是死在程式碼。

是先死在 Hugging Face 的 gated repo。

那一刻我才第一次真的懂，本地微調不是「模型 + 資料 + 訓練」這麼直線的故事。
在你碰到 loss 之前，前面其實還有一整條不太浪漫、但會卡死人的東西：

  • 環境
  • 權限
  • 下載
  • 檔案格式
  • 工具分工
  • 最後要怎麼回到 Ollama

你以為自己在訓模型。
其實你先是在跟工具鏈談判。

本地 LLM 微調與部署的工具鏈分工圖

我一開始把事情想得太乾淨

那時候我腦中那套流程非常單純：

有模型。
有資料。
寫腳本。
跑。

後來真的動手，第一個撞上的不是 learning rate，也不是 LoRA 的 target modules。
而是更前面的東西：

  • 我到底有沒有權限拿到底模？
  • 這個專案的套件版本會不會把另一個專案搞壞？
  • 我要用哪個庫載模型？
  • 哪個庫掛 LoRA？
  • 哪個庫負責 SFT？
  • 最後產物又要怎麼帶回 Ollama？

這些問題看起來不像模型本身。
但它們其實決定了你有沒有機會碰到模型本身。

先講最無聊、也最該先做的：隔離環境

如果你只是偶爾跑一下別人的 notebook，系統 Python 亂裝幾個套件，短期內也許不會立刻出事。

但只要你真的打算開始做本地微調實驗，隔離環境幾乎就是第一步。

理由很現實：
你不想讓一個專案的依賴，把另一個專案默默弄死。

A 專案可能吃這個版本的 transformers。
B 專案又需要另一版 trl。
你今天把 peft 升了，明天另一個資料夾裡原本好好的腳本可能就不跑了。

venv 沒有什麼浪漫。
它只是替每個專案開一個自己的實驗箱。

我後來特別喜歡把 .venv 直接建在專案資料夾裡，也是因為這樣最不容易搞混。
你一進去就知道：

  • 這個專案的環境在哪
  • 這個專案的依賴長什麼樣
  • 要重建、要刪掉、要備份時，邊界也清楚

這種事很無聊。
也正因為它無聊，大家才特別容易跳過。
然後後面每一步都在還債。

第二個現實：你登入了，不代表你拿到了模型

我第一次真的撞牆，就是撞在這裡。

很多人一開始會把 Hugging Face 想成模型下載站。
這個理解不算錯，但太淺。

它當然是模型、資料集、檔案和生態入口。
可是一旦模型作者開了 gated access，事情就不是「登入後直接抓」那麼簡單。你會需要送 access request，而且批准是綁在個人帳號上，不是你想像的「我登入了就算拿到」。

這也是為什麼你明明已經登入 Hugging Face，
還是可能在 from_pretrained() 那一步直接撞 403。

這件事聽起來很行政。
但它會直接改變你的訓練節奏。

因為你的腳本也許完全沒問題，資料也準備好了，
但如果底模根本還在等審核，你連起跑線都還沒摸到。

本地不等於脫離授權

模型在你本地跑，
不等於
你就和授權條件沒關係了。

像 Llama 3.1 這類模型，本地下載、本地微調、本地使用，仍然是在原始授權框架裡。
所以我後來越來越覺得，把「能不能先合法拿到模型」這件事搞定，不是在拖戲。
那本來就是開工的一部分。

工具真的很多，但它們不是同一種很多

等你把環境和權限這兩堵牆過掉，下一個最值得先搞清楚的，不是怎麼調 learning rate。
而是：

我手上這些工具，到底誰負責什麼？

我後來最有感的一件事是，很多新手的混亂其實不是因為工具太多，而是因為工具太多又太容易被講得像同一類。

所以我現在比較願意把它們拆成幾個角色。

Hugging Face Hub：倉庫和入口站

這一層很像倉庫。

它負責：

  • 模型託管
  • 檔案下載
  • 權限申請
  • 模型卡與授權資訊
  • 生態整合入口

它不直接幫你訓練。
但沒有它，很多開源工作流根本連模型都拿不到。

Transformers：和模型直接對話的通用工具箱

如果 Hub 是倉庫，Transformers 比較像裝卸系統。

它負責：

  • 載 model
  • 載 tokenizer
  • 推理
  • 基本訓練介面
  • 很多你後面會一直用到的通用 API

它不是模型本身。
它比較像你和模型互動的標準工具箱。

PEFT：我不想整顆重訓，只想局部動刀

PEFT 這個名字其實就已經把它的任務講得很清楚了。
Parameter-Efficient Fine-Tuning。

它的工作很單純：當你不想全量打開所有權重，只想用 LoRA 這種省一點的方式改模型，它就會開始變得很重要。

TRL：把訓練方法這一層拆出來做

我後來比較能接受的理解是，TRL 比較像在處理「你到底要用哪種 post-training 方法」。

像：

  • SFTTrainer
  • DPOTrainer

這種東西的價值，不是它發明模型。
而是它把某些常見訓練方法包成比較清楚的任務型 trainer，讓你不用每次都自己拼底層流程。

Datasets：很多看起來像模型錯，其實是資料錯

模型怎麼載是一回事，資料怎麼讀、怎麼切、怎麼映射成訓練格式，是另一條完整的工程線。

這也是為什麼 Datasets 看起來很不像主角，
但很多真正會讓你卡住的錯，最後都會長得像：

  • 格式不對
  • 欄位不對
  • 轉換不對
  • 映射不對

Ollama：不是最先開工的地方，而是最後把東西接回可用狀態的地方

Ollama 很好用。
但它最強的地方，不是訓練，而是：

  • 本地跑模型
  • 管模型
  • 透過 Modelfile 做包裝
  • 匯入量化或 merge 後的權重
  • 把訓練成果變成真的能用的東西

所以在我現在的腦中，整條路線其實分成兩半：

前半段，你大多在 Hugging Face / Transformers / PEFT / TRL 那邊處理「模型怎麼被改」。
後半段，你再回到 Ollama，處理「模型怎麼被用」。

為什麼不是直接在 Ollama 裡把一切做完

Ollama 擅長的是：

  • 跑
  • 管
  • 包裝
  • 匯入
  • 部署

不是：

  • 掛 LoRA
  • 跑 SFTTrainer
  • 跑 DPOTrainer
  • 處理 preference data
  • 做比較細的 post-training 流程

所以比較穩的路通常還是：
先在 HF 生態裡訓練，
再把 artifact 帶回 Ollama。

tokenizer 在這條鏈上，是輸入協議，不是小配角

tokenizer 當然會把文字切成 token。
但對 chat model 來說，它同時也在幫你把對話組裝成模型真的熟悉的格式。

所以它不只是切字器。
它比較像輸入協議的一部分。

這也是為什麼你一旦在 tokenizer / chat template 這一層弄錯，事情常常不是直接報錯，而是模型開始默默變怪。

真正會花時間的，不是名詞，而是邊界

回頭看，我花掉的時間很多都不是在理解名詞本身。
而是在修邊界。

像是：

  • 我以為登入了就等於拿到模型
  • 我以為 Ollama 就是整套本地 LLM 生態
  • 我以為 Transformers、TRL、PEFT 差不多
  • 我以為資料只是餵進去而已

這些不是小誤差。
它們是一開始就會讓你整條路線歪掉的誤判。

反過來說，不是每個人都需要把整條鏈走完

如果你的目標只是：

  • 保住原版 Llama 3.1 的底子
  • 語氣更直接
  • 少一點空話
  • 更像技術助理
  • 又還不想碰權重

那你根本不一定要一開始就跑進 Transformers + PEFT + TRL 這條深水區。

你可能停在：

  • Ollama
  • Modelfile
  • 幾組 few-shot
  • 一點 runtime 參數調整

就已經很夠。

我最後最想留下的一句話

如果只留一句，我會留這句：

你以為自己在訓模型，實際上你先是在跟工具鏈談判。

把這些邊界先切乾淨，不會讓你立刻變強。
但它會讓你少掉很多本來就不必花的時間。

下一篇才開始真的談訓練方法

LoRA、SFT、DPO、full fine-tune，到底差在哪？
它們分別在改模型的哪一層？
而我前面其實做的是什麼？

那就是下一篇。