llama-cookbook：從 llama-recipes 改名之後，它還剩下什麼
Welcome to the Llama Cookbook! This is your go to guide for Building with Llama: Getting started with Inference, Fine-Tuning, RAG. We also show you how to solve end to end problems using Llama model family and using them on various provider services
秒懂
- 它是什麼？
- Meta 官方把 llama-recipes 更名為 llama-cookbook，並在 2025 年初做了一次倉庫重構。這篇文章說明它的實際內容、可執行的部分與被移出的部分，以及什麼情況下你該改看別的方案。
- 適合誰用？
- 如果你要的是 Llama 官方範例的索引，用來對照 Llama API、Llama 4 Scout 的長上下文或 Maverick 的端到端案例，這個倉庫可以直接看。如果你的目標是拿到一套可長期維護的微調程式庫，請先確認 src/ 底下的內容是否仍是你需要的版本，因為 README 明確指出倉庫已重構，舊路徑對應的是 archive-main 快照分支。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 119 天前。
- 用什麼語言寫的？
- 主要是 Jupyter Notebook（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
llama-recipes 改名成 llama-cookbook 之後，問題換了一個
這個倉庫原本叫 llama-recipes，README 的 FAQ 直接寫明「We recently renamed llama-recipes to llama-cookbook」。改名本身不是重點，重點是它同時做了一次倉庫重構，而重構把原本以程式庫為中心的結構，改成以範例與教學為中心的結構。README 的 Repository Structure 列出四個目錄：3p-integrations 放各家 Llama 供應商的入門範例與端到端案例，end-to-end-use-cases 放跨領域的完整應用，getting-started 放 inference、finetuning 與 RAG 的參考範例，src 則是「Contains the src for the original llama-recipes library along with some FAQs for fine-tuning」。
所以它現在解決的問題，不是「提供一套微調框架」，而是「提供一份官方認可的入口索引」。倉庫主要語言是 Jupyter Notebook，這件事本身就在說明定位：多數內容是可以逐格執行的示範，不是拿來當依賴安裝的套件。對於正在評估 Llama 生態、想知道官方推薦哪條路徑的工程師，這個定位是有用的。對於已經有一套訓練流程、只想找一個穩定 API 的人，這個定位反而是干擾。
還有一個容易忽略的訊號：README 上方掛的是 Llama API 的 waitlist 與文件連結，最新章節列的是 Llama 4 的 recipes。倉庫的重心明顯往託管 API 與新模型傾斜，本地端微調的原始碼被收進 src 而不是放在最上層。這個取捨值得在採用前先看清楚。
倉庫的四個目錄各自負責什麼
getting-started 目錄底下分成 inference、finetuning 與 RAG 三條線，README 的說法是「Reference for inferencing, fine-tuning and RAG examples」。這一層是參考用的，適合拿來確認某個模型要用什麼載入方式、某個推論後端要怎麼接。
end-to-end-use-cases 是完整應用，README 舉的例子包括用 Llama 4 Maverick 分析研究論文（research_paper_analyzer）、從一本書生成角色心智圖（book-character-mindmap），以及把 Llama API 接進 WhatsApp 的機器人。這些案例的價值在於它們展示了從輸入到輸出的整條鏈路，而不是單一 API 呼叫。
3p-integrations 放的是第三方供應商的範例。README 沒有列出清單，只說「Getting Started Recipes and End to End Use-Cases from various Llama providers」。這代表同一個任務在不同供應商上可能有不同寫法，這個目錄就是拿來對照的。實際有哪些供應商，需要自己進目錄看，README 沒有給。
src 目錄是原本 llama-recipes 的程式碼，加上微調的 FAQ 文件，README 指向 src/docs/ 作為 Fine-Tuning FAQ 的位置。如果你過去用過 llama-recipes 的訓練腳本，這裡是它現在的落腳處。
重構留下的斷層：archive-main 與失效路徑
README 的 FAQ 有一條問答直接處理這個問題：「Q: Some links are broken/folders are missing」，回答是「We recently did a refactor of the repo, archive-main is a snapshot branch from before the refactor」。同一段說明在 Repository Structure 下方又出現一次。官方在同一個 README 裡重複講這件事，說明斷鏈的規模不小。
對使用者的實際影響是：你在搜尋引擎或舊文章裡找到的路徑，很可能只存在於 archive-main 分支，而不在 main 上。反過來說，如果你現在 clone main 分支，某些舊教學引用的檔案會直接找不到。這不是 bug，是重構的結果，但排查起來會花時間，因為錯誤訊息通常只是 404 或路徑不存在。
比較穩的做法是先確認你要的東西屬於哪一類。如果你要的是最新模型與 API 的範例，看 main。如果你要的是重構前那套以 llama-recipes 為名的程式庫與教學，去 archive-main。兩邊的內容不對等，不要假設 main 是 archive-main 的超集。
這個斷層也反映在版本節奏上。倉庫的最新 release 是 v0.0.5，時間是 2025 年 1 月 22 日，前一版 v0.0.4.post1 是 2024 年 9 月 26 日。版本號還停在 0.0.x，而倉庫在 2026 年 5 月仍有推送。也就是說，程式碼層面的版本化與範例層面的更新是兩個不同步的節奏，release 標籤不一定涵蓋最新的 notebook 內容。
實際跑起來需要哪些步驟
README 沒有提供安裝指令，也沒有列出相依套件清單，這一點必須先講清楚。它給的是目錄連結與 notebook 路徑，實際的安裝步驟在各自的 notebook 或子目錄裡。所以「照著 README 一行一行做」這件事在這裡不成立。
可以從 README 確認的具體入口有幾個。Llama API 的入門 notebook 路徑是 getting-started/build_with_llama_api.ipynb，Llama 4 Scout 的 5M 長上下文範例在 getting-started/build_with_llama_4.ipynb。端到端案例各自有 README，例如 end-to-end-use-cases/whatsapp_llama_4_bot/README.md、end-to-end-use-cases/research_paper_analyzer/README.md、end-to-end-use-cases/book-character-mindmap/README.md。微調相關的常見問題集中在 src/docs/。
Llama API 目前是 waitlist 狀態，README 上方掛的是 join_waitlist 連結。這意味著 build_with_llama_api.ipynb 這條路徑在你取得存取權之前無法完整走完，這是流程上的前置條件，不是技術問題。
授權部分要注意的是，倉庫本身的 LICENSE 是 MIT，但 README 的 License 段落指向的是另一組文件：每個模型版本各自有一份 LICENSE 與一份 USE_POLICY，分別放在 llama-models 倉庫的 models/llama4、llama3_3、llama3_2、llama3_1、llama3、llama2 底下。倉庫的 MIT 授權與模型的授權是兩件事，不要把前者套用到後者。具體條款請自行閱讀原文，這裡不提供法律判斷。
Notebook 為主的倉庫，維護成本落在誰身上
以 Jupyter Notebook 為主要語言的倉庫，有一個結構性的維護問題：notebook 不容易做版本 diff，也不容易寫自動化測試。當底層模型 API 或推論框架改版，受影響的是散落在各目錄的儲存格，而不是一個集中的介面層。這個倉庫的規模讓這個問題被放大。
從 release 節奏可以看出一些線索。v0.0.4 到 v0.0.4.post1 相隔一天，這種 post 版本通常對應小幅修正。v0.0.4.post1 到 v0.0.5 相隔約四個月。而倉庫在 2026 年 5 月仍有推送，時間點遠晚於最後一次 release。這表示如果你要追蹤最新內容，看 release 標籤不夠，得看 main 分支的提交。
對採用者的實際成本是：你不能只鎖一個版本號就假設內容穩定。如果你把某個 notebook 的做法抄進正式流程，你繼承的是那個時間點的做法，而它的相依套件版本、模型呼叫方式、甚至路徑都可能在下一次重構時改變。倉庫沒有提供相容性承諾，README 也沒有這類說明。
另一個成本是選擇成本。倉庫同時涵蓋本地推論、託管 API、多家第三方供應商與多個模型世代。要從中挑出適合自己的一條路，需要先讀懂目錄結構與各案例的前置條件，這部分的工作量不低。
什麼情況下不該用它：與微調框架的差異
如果你的需求是「用一份設定檔描述訓練任務、重複執行、納入 CI」，這個倉庫不是為此設計的。它的微調程式碼在 src 底下，但整個倉庫的組織方式以範例為主。相比之下，像 Hugging Face 的 transformers 搭配 peft 或 trl 這類路線，提供的是可安裝的套件與穩定的 Python API，訓練邏輯由你撰寫，框架負責模型載入、適配器注入與訓練迴圈。兩者的差異在於責任歸屬：llama-cookbook 給你一份可參考的實作，你需要自己把它變成可維護的流程；套件型的框架給你介面，你需要自己寫業務邏輯。
另一個替代方向是直接用 vLLM 這類推論伺服器。倉庫的 topics 裡確實有 vllm，getting-started/inference 底下應該有對應範例，但 README 沒有展開說明。如果你的問題只在推論吞吐與部署，而不是「該怎麼開始用 Llama」，那麼直接讀 vLLM 自己的文件會比從這個倉庫繞一圈更直接。
還有一個情況要避開：把這個倉庫當成模型授權的權威來源。README 的 License 段落是一組指向 llama-models 倉庫的外部連結，各模型版本的條款不同，且附有 Acceptable Use Policy。要判斷商用條件，應該直接讀對應版本的那兩份文件。
判斷這個倉庫對你有沒有用的三個檢查點
第一個檢查點是你要的東西在不在 main 分支。README 明確說過重構造成連結失效與資料夾缺失，並指向 archive-main 作為重構前的快照。所以在你投入時間之前，先用你要找的關鍵字確認它在哪個分支上，這一步能省下不少來回。
第二個檢查點是 Llama API 的存取狀態。README 最新章節的第一條就是 Llama API 的入門，而該服務目前掛的是 waitlist。如果你的評估重點是這條路徑，先確認你拿得到存取權，否則你只能看 notebook 的內容而無法執行。
第三個檢查點是模型版本與授權的對應。倉庫涵蓋 Llama 2 到 Llama 4 多個世代，每個世代在 llama-models 倉庫裡各有一份 LICENSE 與 USE_POLICY。你的目標模型是哪一代，就讀哪一份，不要用倉庫本身的 MIT 授權推論模型的商用條件。
這三個檢查點都通過之後，這個倉庫的價值就很明確：它是一份官方維護的入口，讓你在同一個地方看到推論、微調、RAG 與端到端案例的官方推薦做法。它的價值在於索引與範例的權威性，不在於提供一套可以長期依賴的程式庫介面。把這個定位記住，用起來就不會錯位。
編輯結論
如果你要的是 Llama 官方範例的索引，用來對照 Llama API、Llama 4 Scout 的長上下文或 Maverick 的端到端案例，這個倉庫可以直接看。如果你的目標是拿到一套可長期維護的微調程式庫，請先確認 src/ 底下的內容是否仍是你需要的版本，因為 README 明確指出倉庫已重構，舊路徑對應的是 archive-main 快照分支。動手前先確認三件事：你要的 notebook 在 main 分支的哪個目錄、你引用的路徑是否只存在於 archive-main、以及你要用的模型版本對應哪一份 LICENSE 與 USE_POLICY。這三項確認完，再決定要不要把它的程式碼放進你的流程。
社群筆記