train-llm-from-scratch：一條從原始文本走到 GRPO 的單 GPU 訓練路線

它解決的不是「訓練難」，而是「看不懂」

多數人想訓練自己的 LLM 時，會直接套用 transformers 套件，呼叫 Trainer，然後祈禱 loss 會下降。這個專案刻意反其道而行，作者在 README 開頭就表明不用 trl、不用 peft、不用 transformers，每個演算法都用純 PyTorch 手寫。它要解決的問題不是算力不足，而是理解斷層。對學生而言，每個程式區塊前面都有白話解釋，後面附上預期輸出，這是一份可以從頭讀到尾的教材。對開發者而言，指令與檔案路徑都寫清楚，可以複製貼上直接跑。對研究者而言，後訓練階段才是重點，SFT、Bradley-Terry 獎勵模型、帶 GAE 的 PPO、DPO、ORPO、KTO、GRPO，全部實作在同一個小型 Transformer 上，並用真實公開資料集訓練。這不是一個幫你省事的工具，而是一個幫你拆解黑箱的顯微鏡。

資料流：一個想法重複四次

README 用一句話總結整個旅程：把文字變成數字，預測下一個 token，然後持續改變資料與損失函數，直到模型做出我們要的行為。這條管線從 raw text 開始，經過 tokenization 變成磁碟上的 teal 色資料，再餵進 Transformer 計算 next-token loss，得到 base model。接下來 base model 進入 SFT，變成有對話能力的助理，接著訓練 Reward Model，再依序套用 PPO、DPO、最後是 GRPO，最後進行評估與聊天。這個流程的關鍵在於，每個階段都只是換資料與換損失函數，模型架構本身沒有戲劇性改變。顏色圖例也反映了這個設計：綠色是原始資料，teal 是已 tokenized 的儲存資料，藍色是處理步驟，黃色是模型或訓練步驟，橘色是強化學習與獎勵部分，紅色是損失，灰色是檢查點，紫色是最終輸出或評估。這種視覺化讓讀者一眼看出目前站在管線的哪個位置。

安裝與啟動：editable install 解決路徑地獄

安裝方式很直接，先 clone 再 pip install -e .。這個 editable 安裝會把 config、src、data_loader、ui 四個目錄放進 import path，所以不需要手動設定 PYTHONPATH，這對初學者來說是很大的解脫。如果你要下載資料與記錄實驗，需要加裝 train 的 extras，指令是 pip install -e ".[train]"，它會帶上 datasets 與 wandb。如果你想要 Streamlit 控制面板，則執行 pip install -e ".[ui]"，它會安裝 streamlit、pandas 與 altair。值得注意的是，README 提供的 GPU 記憶體表格是粗略估計，不是保證。例如 RTX 5090 的 32 GB 記憶體只標示 13M 參數已驗證，更大的設定還在測試中。這個誠實的標註值得肯定，因為多數專案會誇大支援範圍。

13M 與 2B 之間：單 GPU 的現實邊界

README 的硬體表是這個專案最實際的貢獻之一。它明確列出不同 GPU 能訓練的規模，例如 A100 40 GB 可以訓練 2B 模型，但 V100 16 GB 不行，只能到約 2B 的最大實際規模。T4 16 GB 在 Colab 或 Kaggle 免費版常見，足夠訓練 13M 模型，但無法負擔 2B。這個表格迫使讀者面對現實：單 GPU 訓練不是萬靈丹。即使你的 GPU 記憶體足夠，訓練時間仍是隱性成本。作者沒有提供具體的訓練時數，只說免費的 T4 夠跑 13M，這對想估算專案時程的人來說是一個缺口。如果你記憶體不足，預訓練腳本提供 opt-in 的旗標，例如 --amp、--grad-checkpointing、--grad-accum，可以大幅降低記憶體用量。這些旗標是實際可用的緩解手段，但 README 沒有詳細說明每種旗標的取捨，讀者需要自己實驗。

後訓練的完整菜單：從 SFT 到 GRPO

這個專案最獨特的地方在於後訓練階段涵蓋的範圍。多數從零實作的教材只停在預訓練與文字生成，但這裡一路做到對齊與推理風格模型。SFT 是監督式微調，讓 base model 學會回答問題。接著訓練 Reward Model，採用 Bradley-Terry 模型，這是用來判斷哪個回應比較好的關鍵。然後是 DPO、ORPO、KTO，這三種是不同策略的偏好最佳化，各有各的損失函數設計。PPO 使用 GAE，這是強化學習中估計優勢函數的標準方法。最後是 GRPO，作者也稱之為 RLVR，這是近期 LLM 推理訓練的熱門方法。README 的管線圖顯示這個順序是固定的，但沒有解釋為什麼 GRPO 放在最後，也沒有比較不同方法的收斂速度或最終品質。對研究者來說，這是一個可以自行實驗的遊樂場，但對想直接複製最佳實務的人來說，缺乏引導。

評估與對話：不只是訓練，還要能聊天

管線的最後一站是評估與聊天。作者提供 evaluation 腳本，以及一個 Streamlit 控制面板，讓你能與訓練好的模型對話。這個 UI 的存在顯示專案不只是給程式設計師用的函式庫，它也考慮到想要視覺化互動的使用者。README 展示的 13M 模型輸出，文法大致正確但內容無意義，例如提到「1978 年的公園被歸還給工廠板」，這說明了小型模型的極限。這個範例很有價值，因為它誠實呈現了 13M 參數能達到的品質，避免讀者抱有不切實際的期待。若要得到流暢且有用的對話，你需要往上訓練更大的模型，這又回到硬體表的限制。所以這個 UI 與範例輸出，實際上是對讀者的一種提醒：訓練成功不等於模型聰明。

維護成本與授權：MIT 背後的自由與責任

專案以 MIT 授權釋出，這表示你可以自由使用、修改與商業化，但必須保留原始著作權聲明。授權本身沒有問題，但維護成本需要仔細考量。最後一次 push 是 2026 年 8 月，顯示作者仍有在更新，但專案沒有釋出任何版本標籤，也沒有 release notes。這對依賴此專案的人來說是一個風險，因為 API 或檔案結構可能在任何一次 commit 中變動。作者在 README 中表示正在尋找 AI 領域的 PhD 職位，這暗示專案可能隨著作者的生涯規劃而改變維護頻率。另外，所有演算法都是手寫，這代表當上游的 PyTorch 或 datasets 套件更新時，你必須自己確認程式碼是否仍然相容。沒有 transformers 的抽象層保護，相依性破裂的風險更高。若你要將此專案用於正式研究，建議固定一個 commit hash，並記錄你使用的環境版本。

替代方案：Karpathy 的 nanoGPT 與 HF 的 TRL

若要比較，最接近的替代方案是 Andrej Karpathy 的 nanoGPT，它同樣從零實作 GPT，但範圍較小，主要聚焦在預訓練，沒有涵蓋 SFT 或 RL 後訓練。nanoGPT 的程式碼更精簡，適合想快速理解 Transformer 核心的人，但你不會學到獎勵模型或 GRPO。另一端的替代方案是 Hugging Face 的 TRL 套件，它提供現成的 SFTTrainer、DPOTrainer 與 PPOTrainer，可以快速套用到任何模型，但抽象層很厚，你很難看到內部實作。train-llm-from-scratch 剛好落在兩者之間，它比 nanoGPT 更完整，比 TRL 更透明。若你的目標是寫論文或深入理解 RLHF 的每個環節，這個專案是更好的起點。若你的目標是快速建立一個聊天機器人原型，TRL 會省下大量時間，而這個專案會讓你卡在細節中。

編輯結論

這套專案適合想親手摸過每個演算法的學生、開發者與研究人員，尤其是那些不想被 trl 或 peft 抽象遮蔽細節的人。若你追求的是快速產出可部署的模型，或沒有 GPU 且不打算用 Colab 的 T4，這條路線會讓你卡在記憶體與時間的現實上。採用前應先確認你的 GPU 記憶體落在 README 的表格內，並預留足夠的硬碟空間存放 tokenized 資料與檢查點。務必先跑 13M 參數的預訓練，確認損失下降與輸出的文字品質，再往上擴充。最後，因為所有演算法都是手寫，你必須自己承擔除錯與驗證的責任，文件與範例輸出只能當作參考，不能取代你對程式碼的檢查。

官方來源

1. FareedKhan-dev/train-llm-from-scratch on GitHub
2. Issues
3. License: MIT
4. Project website
5. README