我第一次真的跑到 python train_lora.py，不是死在顯卡，也不是死在程式碼。
是先死在 Hugging Face 的 gated repo。
那一刻我才第一次真的懂，本地微調不是「模型 + 資料 + 訓練」這麼直線的故事。
在你碰到 loss 之前，前面其實還有一整條不太浪漫、但會卡死人的東西：
- 環境
- 權限
- 下載
- 檔案格式
- 工具分工
- 最後要怎麼回到 Ollama
你以為自己在訓模型。
其實你先是在跟工具鏈談判。
我一開始把事情想得太乾淨
那時候我腦中那套流程非常單純：
有模型。
有資料。
寫腳本。
跑。
後來真的動手，第一個撞上的不是 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，到底差在哪？
它們分別在改模型的哪一層？
而我前面其實做的是什麼？
那就是下一篇。