Chinese-LLaMA-Alpaca-3 レビュー: Llama-3 に中国語を継ぎ足す3世代目の設計判断

Llama-3 の中国語化が解決しようとしている問題

Llama-3 は多言語を謳っているが、中国語の生成品質は英語に比べて落ちる。このリポジトリは、その差を追加学習で埋めることを目的にしている。対象は、中国語でチャットや執筆をさせたいが、API 経由ではなくローカルの重みとしてモデルを持ちたい開発者である。

シリーズとしては一期、二期に続く三期目にあたり、README は二期のモデルと比べて「显著性能提升」と述べている。ただしこれはプロジェクト自身の記述であり、独立した評価ではない。判断材料としては、モデルの系統と学習方法の変化を追うほうが実用的だ。

公開物は重みだけではない。事前学習スクリプト、指令精調スクリプト、そして alpaca_zh_51k、stem_zh_instruction、ruozhiba_gpt4 (4o/4T) という指令データが含まれる。モデルを配って終わりにせず、再現と追加学習の手段まで出している点が、この種のリポジトリの中では珍しい。

語表を拡張しなかったという判断

中国語モデルの定番手法は、中国語トークンを語表に追加して埋め込みを学習し直すことだ。二期の Chinese-LLaMA-2 はそうしていた。三期はそれをやらない。

理由は README に書かれている。Llama-3 は語表を 32K から 128K に拡張し、BPE に切り替えた。その結果、中国語の符号化効率が二期の拡張語表とほぼ同等になり、Wikipedia データでの計測で二期語表の約 95% に達したという。つまり拡張する動機が薄れた。加えて、中国 Mixtral での経験と実験結論（Cui and Yao, 2024）を根拠として挙げている。

この判断には副作用がある。語表を触らないということは、埋め込み層と出力層を学習し直す必要がないということで、学習コストと破損リスクは下がる。一方で、中国語の専門用語や固有名詞の分割が二期より粗くなる可能性は残る。README は効率を 95% と書くが、これは符号化効率の話であって、下流タスクの品質が同等だという主張ではない。ここは分けて読むべきだ。

Instruct 版が v1、v2、v3 に分岐した理由

同じ Instruct でも中身は別物である。README の比較表がその違いを明示している。

v1 は Meta-Llama-3-8B から出発し、まず 120GB の中国語コーパスで事前学習し、そのあと 500 万件の指令データで精調する二段構え。v2 は逆で、Meta-Llama-3-8B-Instruct に対して 500 万件の指令データを直接かける。中国語の事前学習を挟まない。v3 は v1、v2、および inst-meta をモデル融合し、その上に約 5K 件という少量の指令データで精調している。

この分岐は試行錯誤の記録である。中国語コーパスを大量に食わせると中国語は伸びるが、Llama-3-Instruct が元々持っていた対話の素性が変質しうる。v2 はその逆を狙った構成だ。v3 は融合で両方を取りに行く。README の表には中国語能力の数値として 49.3 / 51.5 などの値が並ぶが、表が途中で切れているため、v3 の対応する数値はこの資料からは確認できない。数値を採用根拠にするなら配布ページ側で確認する必要がある。

動かすまでの手順と、学習スクリプトの中身

推論は既存の Llama-3 対応ツールに乗る。README が対応を挙げているのは transformers、llama.cpp、text-generation-webui、vLLM、Ollama である。量子化して個人の PC で動かす手順も用意されている。

Instruct 版を使うときの注意点がはっきり書かれている。Llama-3-Instruct の指令テンプレートは Llama-2-chat と互換性がなく、公式のテンプレートに従う必要がある。ここを外すと出力が崩れる。基座モデルのほうはテンプレート不要で、用途はテキスト続き生成に限られる。README も「如需聊天交互，请选择Instruct版」と書いている。

学習側は v1.1 で事前学習スクリプトと指令精調スクリプトが追加された。モデル側の訓練方式は基座も Instruct も LoRA と全量の emb/lm-head という組み合わせだと表に記載されている。LoRA で全体を凍結しつつ、埋め込みと出力層だけは全量更新する。語表を拡張しなかった代わりに、この二層は中国語に適応させる必要があるという設計だ。

具体的なコマンドや設定キーは README 本文には現れず、Wiki と各リリースノートに置かれている。この資料からは起動コマンドを引用できない。

8B というサイズが効かない場面

このモデル群は 8B で、コンテキストは 8K である。二期の 4K から倍になったとはいえ、長文書の要約や複数文書をまたぐ推論では足りないことが多い。README は PI、NTK、YaRN といった手法でコンテキストを拡張できると述べるが、これはモデル側の機能ではなく外部手法の案内であって、拡張後の品質が保証されるわけではない。

より根本的な制約は規模である。中国語のタスクによっては 8B では届かない領域があり、その場合はより大きなモデルか、クラウド側の API を使う判断になる。このリポジトリは 8B という枠の中で中国語を底上げする道具であって、規模の壁を越える道具ではない。

もう一点、学習データの由来は README の範囲では件数しか分からない。alpaca_zh_51k や ruozhiba_gpt4 といったデータセット名は挙がっているが、生成元や許諾条件の説明はこの資料にはない。商用利用を検討するなら配布ページで確認する作業が先に来る。

中国 Mixtral というもう一つの選択肢

同じ作者による Chinese-Mixtral が並行して公開されている。こちらは Mixture-of-Experts を採用したモデルで、推論時に全パラメータを動かさない。総パラメータあたりの計算量を抑えられる点が、密な 8B モデルとの本質的な違いである。

どちらを選ぶかは、メモリとレイテンシのどちらに余裕があるかで決まる。Mixtral 系は重みを置くためのメモリを多く要求する一方、1 トークンあたりの計算は抑えられる。8B の密モデルは逆で、VRAM の要件は読みやすく、量子化の知見も llama.cpp 側に蓄積がある。

もう一つの違いは語表の扱いだ。Chinese-Mixtral の経験が、三期で語表を拡張しない判断の根拠として README に引用されている。つまり両者は同じ設計思想の系列にあり、対立する選択肢というより、計算資源の形に応じた振り分けになっている。

ライセンスと更新の見取り図

リポジトリのライセンスは Apache-2.0 である。ただしこれはコードとスクリプトに対する表示であって、配布されているモデルの重みは Meta の Llama-3 ライセンスの下流に位置する。学習データについても別の条件がありうる。この三層を混同すると、導入後に困る。Apache-2.0 の表示だけを見て商用利用可と判断するのは早い。個別の条件は各モデルの配布ページで確認する必要があり、ここで法的な判断を示すことはできない。

更新の面では、2024 年 4 月 19 日のプロジェクト開始から、4 月 30 日の v1.0、5 月 7 日の v1.1、5 月 8 日の v2.0、5 月 30 日の v3.0 まで、約 6 週間で 4 版を出している。ペースは速いが、これは初期の立ち上げ期の話である。リポジトリの最終 push は 2026 年 4 月 19 日となっており、リリース一覧の最新は v3.0 のままである。つまり、モデルの版は v3.0 で止まり、その後は周辺の整備や修正が続いているという読み方になる。活発に版が上がり続ける前提で追従コストを見積もるのは避けたほうがよい。

学習スクリプトを自前で回す場合のコストは、この資料からは見積もれない。120GB のコーパスと 500 万件の指令データという記述は規模の目安にはなるが、GPU 時間や必要メモリの記載は README の引用範囲にはない。

編集部の結論

中国語のチャット用途で 8B クラスのモデルを自前の環境に置きたい場合、Instruct-v3 を出発点にするのが妥当で、README も明確な好みがなければ v3 を優先するよう書いている。逆に、語表の拡張やトークナイザの改変を前提にした研究、あるいは 8B を超える規模の中国語モデルを求める用途には向かない。採用前に確認すべきは、配布ページに記載された学習データの由来と、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