模型 / 資料集
liguodongiot/llm-action avatar
liguodongiot/llm-action

llm-action:把大模型訓練與推理的實作路徑整理成一份可對照的索引

本项目旨在分享大模型相关技术原理以及实战经验(大模型工程化、大模型应用落地)

25,054 個 Star2,846 個 ForkHTMLApache-2.0

秒懂

它是什麼?
這個倉庫本身不是框架,而是一份圍繞 LLM 訓練、推理、壓縮與部署的教程索引,主體語言是 HTML,授權 Apache-2.0。它的價值取決於你是否願意沿著它給出的外部文章與配套程式碼走完整條路。
適合誰用?
如果你需要一條從 LLaMA 全量微調、LoRA、QLoRA 到 GPTQ 量化與推理壓測的現成路線,並且能接受主要內容以知乎專欄文章形式存在,這個倉庫可以當作起點索引;如果你的團隊要的是可 pin 版本的依賴、CI 可重現的構建,或是對延遲與吞吐的實測數字,它不合適,因為倉庫內沒有發佈版本,主體是 HTML 與教程連結。動手前先確認三件事:目標模型與倉庫表格中列出的參數量級是否一致、對應子目錄下的程式碼是否仍在維護、以及外部文章所述的硬體前提(例如 QLoRA 條目提到的 48G 顯存)是否與你手上的卡相符。
可以商用嗎?
可以。Apache-2.0 是寬鬆授權:你可以使用、修改並販售以它為基礎的軟體,只需保留著作權與授權聲明。
還在維護嗎?
有在維護。儲存庫最近一次提交在 58 天前。
用什麼語言寫的?
主要是 HTML(依據 GitHub 的語言統計)。

以上回答依據專案的 GitHub 資料(最近同步於 2026年9月15日)與我們的分析,不構成法律意見。

開源專案深度解析

它解決的是找路徑的問題,不是提供一個可安裝的套件

把大模型從預訓練一路做到線上服務,中間會經過微調、對齊、量化、推理優化、壓測這幾個階段,每一段都有各自的工具與論文。llm-action 的做法是把這些階段拆成目錄條目,再為每個條目掛上一篇文章與一份配套程式碼。README 的目錄從 LLM训练 展開到 LLM训练实战、LLM微调技术原理、LLM微调实战、LLM分布式训练并行技术,往下還有 LLM推理、LLM压缩、LLM测评、LLMOps 等分支。

它服務的對象因此很明確:已經知道自己要微調某個開源模型、但還不確定該用 LoRA 還是 QLoRA、該不該動詞表、分散式要選哪種並行策略的人。倉庫把選項並排放在表格裡,讀者自己比對。反過來說,如果你的問題是「這個 API 怎麼呼叫」,這裡不會有答案,因為它不是函式庫。

表格是主體:模型、方法、參數量與配套程式碼的對照

README 的核心是一張訓練實戰表。欄位固定為 LLM、預訓練或 SFT 或 RLHF 的方法、參數規模、教程連結、程式碼連結。以 LLaMA 為例,同一欄位下並列了 QLoRA 與 GaLore 兩條路:QLoRA 條目標注 7B 與 65B,教程標題寫明基於 LLaMA-65B 微調僅需 48G 顯存;GaLore 條目覆蓋 60M 與 7B,教程標題提到用一張 4090 消費級顯卡預訓練 LLaMA-7B。

這種排法讓記憶體預算成為選型的入口,而不是先選框架。ChatGLM 則同時出現 LoRA 與 full fine-tuning 或 P-Tuning v2 兩列,對應到 llm-train/chatglm-lora 與 llm-train/chatglm 兩個不同目錄。要注意的是表格中並非每一列都有程式碼,BELLE、Vicuna、MiniGPT-4 幾列的程式碼欄位是 N/A,只有文章可讀。這是選型時必須先看清的落差。

配套程式碼的目錄結構與可執行入口

從 README 給出的連結可以看出倉庫的實體佈局:訓練相關內容放在 llm-train 之下,每個方法一個子目錄,例如 llm-train/alpaca、llm-train/alpaca-lora、llm-train/chatglm-lora、llm-train/chatglm、llm-train/deepspeedchat、llm-train/chinese-llama-alpaca、llm-train/qlora。GaLore 條目指向的是單一檔案 llm-train/galore/torchrun_main.py,而不是整個目錄,這意味著它示範的是啟動方式而非完整專案骨架。

檔名本身透露了執行模型:torchrun_main.py 說明該範例以 torchrun 作為分散式啟動器。除此之外,README 沒有給出安裝指令、依賴清單或設定檔鍵名,這些內容需要進到各子目錄或對應文章裡才看得到。因此「怎麼跑起來」在這個倉庫裡不是一句 pip install 能回答的問題,而是每個子目錄各自成立。

主要內容託管在知乎專欄,這是它最實際的約束

倉庫的 Homepage 指向知乎專欄,表格中幾乎每一列的教程欄位都是 zhuanlan.zhihu.com 的連結。程式碼在 GitHub,講解在外部平台,這種拆分對讀者的影響是具體的:文章無法像程式碼一樣被 pin 到某個 commit,內容更新與倉庫更新之間沒有版本對應關係。當你在半年後回頭查某個微調步驟時,你面對的是同一篇文章的當前版本,而不是你當初讀的那一版。

倉庫本身沒有檢索到任何 release。這表示沒有一個標記過的穩定快照可以引用,所有內容都隨 main 分支推進。對照之下,Apache-2.0 授權的是倉庫中的內容,README 中列出的外部文章與第三方專案(例如 DeepSpeed Chat、GaLore 的原始實作)各有自己的授權條款,不能因為倉庫是 Apache-2.0 就推定整條鏈路都可自由使用。

什麼時候它會讓你白走一趟

第一種情況是版本漂移。表格中許多模型與方法來自 2023 年前後的生態,Alpaca、Vicuna、MiniGPT-4、ChatGLM-6B 這些名稱指向的是當時的模型版本與當時的訓練腳本。若你的目標模型已經換代,教程中的詞表擴充步驟、資料格式與依賴版本不一定能直接沿用,倉庫沒有提供相容性矩陣來說明這件事。

第二種情況是你需要可重現的效能結論。倉庫有 LLM推理性能压测 與 LLM性能分析 這兩個分類,但這是文章分類,不是內建的壓測工具。README 沒有提供壓測腳本的入口,也沒有在任何地方給出可引用的延遲或吞吐數字。若你的決策依賴這類數字,必須自己跑。

第三種情況是你要的是產品級依賴。倉庫以 HTML 為主要語言,內容形態偏向教程與索引,沒有套件發佈紀錄,把它加進依賴清單沒有意義。

與同類資源的差異:索引式教程對比單一框架的文件

拿 vLLM 或 DeepSpeed 這類專案來比,差別在於責任邊界。框架的文件回答「這個框架怎麼用」,內容收斂在單一實作的 API 與設定上;llm-action 回答的是「這一類問題有哪幾種做法」,同一個訓練目標下可以同時看到 LoRA、QLoRA、P-Tuning v2、GaLore 四條路線並列,甚至同一個模型(ChatGLM)同時掛上兩種微調方式。

這個差異決定了兩者的失效方式不同。框架文件會隨版本更新而過時,但過時是可追蹤的,因為有版本號;索引式教程的過時是隱性的,某條路線可能已經被更好的做法取代,而表格仍然列著它。反過來,框架文件不會告訴你另一條路線存在,索引會。所以合理的用法是兩者搭配:用 llm-action 決定方向,用具體框架的文件決定實作細節。

維護成本與授權上的實際考量

倉庫最近一次推送時間為 2026-07-19,仍在更新,未封存。這對索引類專案是必要條件,因為它收錄的技術迭代速度快。但更新活躍本身不保證表格中每一列都同步更新,README 的結構允許新條目不斷加入,舊條目則不一定被標記為歷史內容。實際使用時,判斷某一列是否仍有效的方法只能回到該列對應的子目錄,看程式碼是否還在跟著生態調整。

授權方面,倉庫採 Apache-2.0,允許商業使用與修改,並附帶專利授權條款。這裡要注意的是它只覆蓋倉庫自身的內容。llm-train 下各子目錄的程式碼若改寫自第三方專案,原始授權可能仍然適用;README 中指向的模型權重(LLaMA 系列等)另有各自的使用條款。把倉庫內容併入產品前,需要逐個子目錄確認來源,而不是看倉庫根目錄的 LICENSE 就結束。以上是對授權文本的描述,不構成法律意見。

編輯結論

如果你需要一條從 LLaMA 全量微調、LoRA、QLoRA 到 GPTQ 量化與推理壓測的現成路線,並且能接受主要內容以知乎專欄文章形式存在,這個倉庫可以當作起點索引;如果你的團隊要的是可 pin 版本的依賴、CI 可重現的構建,或是對延遲與吞吐的實測數字,它不合適,因為倉庫內沒有發佈版本,主體是 HTML 與教程連結。動手前先確認三件事:目標模型與倉庫表格中列出的參數量級是否一致、對應子目錄下的程式碼是否仍在維護、以及外部文章所述的硬體前提(例如 QLoRA 條目提到的 48G 顯存)是否與你手上的卡相符。

官方來源

  1. Issues
  2. License: Apache-2.0
  3. liguodongiot/llm-action on GitHub
  4. Project website
  5. README
社群筆記

社群筆記