Llama-3 中文增量預訓練：Chinese-LLaMA-Alpaca-3 的三個 Instruct 版本該選哪個

這個專案要解的不是「中文能力不足」，而是「中文語料缺口」

Meta 釋出的 Llama-3 本身是多語言模型，中文並非完全不會，問題出在語料配比。這個專案的做法是用約 120GB 無標註中文通用語料對原版 Meta-Llama-3-8B 做增量預訓練，得到 Llama-3-Chinese-8B 基座，再往上疊指令精調。它服務的對象很明確：手上只有單張消費級 GPU 或一台能跑量化模型的工作站，需要一個中文問答品質可接受、又能自己接手繼續訓練的 8B 模型。

值得注意的是它延續了前兩期的定位。README 把一期、二期、三期並列，第三期的差異是換到 Llama-3 架構。如果你的既有流程是圍繞 Chinese-LLaMA-2 建的，這裡的遷移成本主要不在模型，而在詞表和指令模板，後面會說明。

詞表不擴充是一個有實驗支撐的取捨

Llama-3 把詞表從 32K 擴到 128,256，並改用 BPE。多數中文適配專案會選擇擴充詞表以提升中文編碼效率，這個專案反其道而行。README 給的理由是初步實驗發現 Llama-3 原版詞表在維基百科資料上的編碼效率約為中文 LLaMA-2 擴充詞表的 95%，差距不足以支撐擴充詞表帶來的成本。作者另外引用 Cui and Yao, 2024 關於中文 Mixtral 的結論作為依據。

不擴充詞表的直接好處是模型可以直接吃原版 Llama-3 生態的 tokenizer 與工具鏈，不需要在推理端處理自訂詞表。代價是中文 token 序列會略長於擴充詞表的方案，等效上下文變短。對 8K 窗口的模型來說，這個損耗不是零。README 沒有給出這個損耗的具體數字，只給了編碼效率的相對比例，實際影響要自己用目標語料量一遍。

GQA 與 8K 窗口：架構紅利與它的邊界

Llama-3 在 8B 這個規模就套用了分組查詢注意力（GQA），這個機制在 Llama-2 只用在較大參數量版本。GQA 讓多個 query head 共用同一組 key/value head，推論時 KV cache 佔用下降，長序列或高併發場景的顯存壓力會小一些。對本地部署來說這是實質幫助，因為 8B 模型量化後的主要瓶頸往往就是 KV cache。

上下文窗口從二期的 4K 提升到 8K。README 明講使用者可以自己用 PI、NTK、YaRN 等方法往外擴，但這是使用者要做的額外工作，不是模型自帶的能力。如果你的場景是長文件問答或整份合約分析，8K 會是硬約束，而且要注意 GQA 帶來的顯存節省不會改變窗口長度本身。

Instruct 三個版本的差別在訓練路徑，不在模型大小

v1、v2、v3 都是 8B，差別在怎麼練出來的。v1 是兩階段：先做 120G 中文語料預訓練，再上 500 萬條指令資料精調。v2 跳過預訓練，直接在原版 Meta-Llama-3-8B-Instruct 上用同樣的 500 萬條指令資料精調。v3 走的是模型融合路線，把 inst-v1、inst-v2 與 inst-meta 融合，再用約 5K 條指令資料做少量精調。

這三條路徑的風險不同。v2 依賴 Meta 原版 Instruct 的既有能力，中文適配的深度取決於那 500 萬條資料；v1 有完整的中文增量預訓練階段，但少了 Meta 在 Instruct 階段的對齊工作；v3 用融合把兩者接起來。README 的建議是無明確偏好時優先選 v3，理由是下游任務表現較好。這是一個合理的預設，但如果你的任務分布和通用評測差很遠，三個版本都值得各跑一次小樣本對比，而不是直接照建議走。

跑起來：從 transformers 到 llama.cpp 的實際路徑

README 列出的支援生態包含 transformers、llama.cpp、text-generation-webui、vLLM 與 Ollama。專案另外提供了在個人電腦 CPU 或 GPU 上做量化與部署的教學，這條路線是給沒有伺服器的人用的。

要注意的是訓練方式。基座模型與 Instruct 模型都採 LoRA 加上全量 embedding 與 lm-head 的訓練方式。這意味著如果你拿到的是 LoRA 權重，推論前必須先與基座合併，不能直接把 LoRA adapter 丟給沒載入基座的推理服務。合併腳本與指令在專案的預訓練、指令精調章節中，實際參數請以 repository 內的腳本為準，README 本身沒有把完整的命令列貼出來。

第二個必查項是指令模板。README 明確寫出 Llama-3-Instruct 使用全新模板，與 Llama-2-chat 不相容，使用時應遵循官方模板。基座模型不需要模板，Instruct 模型需要。用錯模板的症狀是模型照樣生成文字，但指令遵循品質下降，這種錯誤不會報錯，只會讓你把模型能力低估一截。

訓練資料的授權邊界比程式碼授權更需要先看

repository 的程式碼是 Apache-2.0，但模型權重不是。這些模型是從 Meta Llama 3 衍生的，所以 Meta Llama 3 社群授權的條款會疊加上來，包括使用範圍與標示要求。README 沒有在這裡展開法律細節，實際採用前應該直接讀 Meta 的授權原文，而不是假設 Apache-2.0 就等於可以任意商用。

專案另外開源了 alpaca_zh_51k、stem_zh_instruction 與 ruozhiba_gpt4（4o/4T）三份指令精調資料。資料集的來源與再散布條件各自不同，把它們混進自己的訓練流程前，要分別確認每份資料的授權，不能只看 repository 層級的 Apache-2.0 標籤。

什麼情況下這個專案是錯的工具

最明顯的錯配是長上下文。8K 原生窗口，要更長得自己套 PI、NTK 或 YaRN，而且擴展後的品質 README 沒有給出保證。如果你的核心需求是處理幾十頁的中文文件，這個專案不是起點。

第二個錯配是參數量。整個第三期只開源 8B 規模的模型，沒有更大的版本。需要更強中文推理能力的場景，8B 量化後的天花板就在那裡，換更小的量化精度救不回來。

第三個是模板相容性。任何既有系統如果寫死了 Llama-2-chat 的 prompt 格式，接上這個模型需要改動 prompt 組裝層，這不是換個模型路徑就能解決的事。

作為對照，Qwen 系列走的是從頭設計中文詞表與預訓練配比的路線，不是對既有英文模型做增量適配。差別在於 Qwen 的中文能力來自原生訓練，而這個專案的中文能力來自 120GB 語料的後天補強，後者的上限受基座模型的表徵能力限制。反過來說，如果你的既有工具鏈是圍繞 Llama 生態建的，選這個專案的整合成本明顯低於換到 Qwen。

維護成本與版本演進的節奏

從發布紀錄看，v1.0 在 2024 年 4 月 30 日、v1.1 在 5 月 7 日、v2.0 在 5 月 8 日、v3.0 在 5 月 30 日，一個月內出了四個版本。這種節奏對採用者意味著兩件事：一是早期版本的評估結論會很快過期，二是升級到新版本需要重新跑一次你自己的評測，因為訓練路徑改了，行為分布也會跟著改。

repository 最近一次推送時間是 2026 年 4 月，距離 v3.0 發布已有一段時間，期間沒有新的模型版本發布。這代表目前的模型集合是穩定的，也代表它停留在 Llama-3 世代，後續 Meta 若推出新架構，這個專案是否跟進要看後續動作。對已經上線的系統來說，穩定是好事；對還在選型的團隊來說，要意識到你選的是一個已經定型的世代。

編輯結論

如果你要的是能直接用中文問答的 8B 模型，選 Llama-3-Chinese-8B-Instruct-v3，它的訓練路徑是 inst-v1、inst-v2 與 inst-meta 的模型融合後再以約 5K 條指令精調，README 也建議無明確偏好時優先使用；需要文本續寫或自己接下游訓練，才選基座版 Llama-3-Chinese-8B。不要把它當成長上下文工具，原生窗口是 8K，要更長得自己套 PI、NTK 或 YaRN。採用前先確認兩件事：你的推理框架是否套用了 Llama-3-Instruct 模板（它與 Llama-2-chat 不相容），以及你是否接受 Meta Llama 3 社群授權與 Apache-2.0 疊加後的義務。

官方來源

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ymcui/Chinese-LLaMA-Alpaca-3 on GitHub