Chinese-LLaMA-Alpaca 評価: LoRA重みで中国語LLaMAを組み立てる構成とその限界

このリポジトリが埋めようとした穴は中国語のトークナイザ効率

原版LLaMAの語彙は中国語を細かく分割するため、同じ中国語文を符号化するとトークン数が膨らむ。トークン数はそのまま計算量とコンテキスト消費に効いてくるので、中国語話者にとってこれは実用上の障害だった。本プロジェクトは原版LLaMAの語彙に中国語トークンを追加し、中国語コーパスで二次事前学習を行った重みを公開している。対象読者は、中国語のテキスト生成や指示応答をローカル環境で試したいエンジニア、および中国語向けの語彙拡張と指令精調の実装を読みたい研究者である。技術報告として Cui, Yang, and Yao の Efficient and Effective Text Encoding for Chinese LLaMA and Alpaca が arXiv に置かれている。

配布物はLoRA重みであり、単体では推論できない

README のユーザー必須事項は明快である。Facebook 公式の LLaMA は商用利用を禁じており、公式に重みが公開されていない。そのため本リポジトリが配布するのは LoRA 重みで、README はこれを原版LLaMAに当てる「パッチ」と説明している。つまり利用者は原版LLaMAを別途入手し、マージ手順を経て初めて完全な重みを得る。ここは見落としやすい。Hugging Face からモデルを1つ取得すれば動く類のプロジェクトではなく、依存関係が上流のライセンスに直結する。公開されているモデルは 7B、13B、33B の各サイズに、基礎版、Plus版、Pro版の系列が用意されている。

語彙拡張と二次事前学習、そのあとに指令精調が乗る

モデルは2系統に分かれる。中文LLaMAは従来型の CLM で学習した基座モデル、中文Alpacaはその上に中国語の指令データで精調をかけたモデルである。README の対比表によれば、語彙サイズは中文LLaMAが 49953、中文Alpacaが 49953+1 で、末尾の1トークンは pad token である。入力の扱いも異なる。中文Alpacaは所定のテンプレートに沿った入力が必要で、HF の推論スクリプト scripts/inference/inference_hf.py では起動時に --with_prompt を付ける。中文LLaMA側はテンプレートを必要としない。この違いは後段のランタイム選択にも波及する。llama.cpp では中文LLaMAに -p で上文を渡し、中文Alpacaは -ins で指示理解とチャットのモードに入る。text-generation-webui では中文LLaMAは chat モードに向かず、中文Alpacaは --cpu を付ければGPUなしで動く。LlamaChat はモデル読み込み時に LLaMA か Alpaca かを選ぶ。用途がテキスト続写なら基座、問答や多輪対話ならAlpaca、という切り分けが README の推奨である。

動かすまでの手順はマージ、量子化、ランタイム選択の3段

流れは README の内容導引に沿う。まずモデルを取得し、次に「合并模型」の節の手順で LoRA を原版LLaMAに統合して完全な重みを再構成する。この工程を飛ばすと LoRA 単体では動かない。次に「本地推理与快速部署」の節で量子化を行い、個人PCのCPUまたはGPUで実行する。ランタイムは transformers、llama.cpp、text-generation-webui、LlamaChat、LangChain、privateGPT が README で挙げられている。スクリプトは scripts/inference/ 配下にあり、HF 経由なら inference_hf.py、Web UI なら gradio_demo.py を使う。gradio_demo.py はAlpacaモデルの位置を指定するだけで多輪対話に対応する。コンテキスト長については、llama.cpp で 8K context をモデル改変なしに扱う方法がディスカッションで共有され、transformers 側で 4K 超を扱うコードが PR#705 として提示されている。ここは本体に取り込まれた設定ではなく、参照先の議論とPRである点に注意したい。

33BとPro版は個人PCの前提を超えやすい

README はノートPCのCPU/GPUでローカルに体験できると書いているが、これは7B級を想定した表現と読むのが妥当である。公開系列には 33B も含まれ、Plus-33B は v5.0 で追加された。量子化しても33BをCPUで快適に回すのは別の難易度になる。加えて、配布形式そのものが制約である。原版LLaMAの重みを正規に入手できなければ、このプロジェクトは始まらない。ライセンス上、原版LLaMAは商用利用が禁止されており、本リポジトリの Apache-2.0 はあくまで本リポジトリのコードとLoRA重みに掛かる表示であって、上流の制約を打ち消すものではない。ここは法的助言ではなく、README が明示している事実の整理である。商用を前提とするなら、上流の条件と自組織の利用形態を別途確認する必要がある。また、このリポジトリ自体は現在も更新されているが、README のニュース欄は三代目プロジェクトへの移行を全一期・二期ユーザーに勧めており、二代目への移行も告知済みである。新規に作るシステムの土台として選ぶなら、この点は無視できない。

後継プロジェクトとの違いはベースモデルの世代

同じ著者による Chinese-LLaMA-Alpaca-2 と Chinese-LLaMA-Alpaca-3 が存在する。違いは土台とするベースモデルの世代である。本リポジトリは原版LLaMAを土台にし、二代目は Llama-2、三代目は Llama-3 を土台にする。語彙拡張と中国語での二次事前学習、その上での指令精調という設計方針は系列を通じて共通しており、変わるのはベースモデルと、それに伴う公開モデルの構成である。したがって、本リポジトリを選ぶ理由は「LLaMA世代の重みとLoRAマージ手順が必要」という点に絞られる。中国語モデルの推論品質そのものを求めるなら、README 自身が三代目を推している以上、そちらを先に見るのが順当である。逆に、LoRA のマージ工程や語彙拡張の実装を教材として読みたい場合、本リポジトリは手順が文章として整理されている。

採用前に確認する4つの項目

第一に、原版LLaMAの重みをどの経路で用意するか。ここが決まらない限り他の検討は無意味である。第二に、マージと量子化に使うスクリプトが要求する transformers などの依存バージョン。README のモデル一覧は世代ごとに構成が異なるため、選んだモデル系列に対応する手順を「合并模型」の節で確認する。第三に、推論ランタイム。CPUのみなら llama.cpp か text-generation-webui の --cpu、GPUがあるなら transformers 経由で inference_hf.py に --with_prompt を付ける、という分岐になる。第四に、コンテキスト長の扱い。8K が必要なら llama.cpp 側の議論を、4K 超を transformers で扱うなら PR#705 を参照する。これらはすべて README とその参照先に書かれている範囲で確認できる。逆に、これら4点を確認せずに重みだけ取得しても、LoRA は単体で推論できないという最初の壁で止まる。

編集部の結論

採用を検討すべきなのは、原版LLaMAの重みを自ら用意でき、7Bから33BのLoRAをマージしてローカルCPUで中国語モデルを動かしたい場合、あるいは中国語語彙拡張の実装を読む目的がある場合である。逆に、重みの入手やライセンス条件をクリアできない、あるいは推論品質を第一に求めるなら、このリポジトリは適さない。README のニュース欄は三代目プロジェクトへの移行を勧めており、二代目への移行も告知されている。着手前に確認すべきは、原版LLaMAの入手経路、マージ用スクリプトが要求する transformers のバージョン、そして推論に使うランタイムが llama.cpp か transformers かという3点である。

公式情報源

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