![[日本LLM] LLM-jp-3-8x1.8bのイメージ](https://saratna.com/wp-content/uploads/post-1413-featured.webp)
これ、LLM-jpでも変な名前なんです。
LLM-jpはV3からV3.1そして最近V4になりました。
8x13B ≠ 104Bを毎token計算
8個のexpert全部を毎回動かすわけではありません。
8 expert中 2 expertだけをactivateするため、
- 重み全体：約73B
- 1 tokenあたりのactivated parameter：約22B
となります。
したがって計算量を抑えつつ、大容量モデルを持てる設計です。
ただし、
VRAM/RAMには基本的に73B分の重みを保持する必要がある
ので、「22Bだから22B Dense並みのメモリでいい」という意味ではありません。
意味わかります？
llm-jp-3-8x1.8b は、一言でいうと **「8人の専門家を抱えていて、文章を1トークン生成するたびに、その中から2人だけを選んで働かせる日本語MoEモデル」**です。
名前から「1.8B × 8 = 14.4Bモデル」と思いやすいのですが、実際はそうではありません。公式値は 総パラメータ約9.27B、1トークン当たり実際に使われるパラメータ約2.92B です。Hugging Face
まず、普通の1.8Bとの違い
普通のDenseモデルを会社に例えると、
社員1.8B人がいて、毎回ほぼ全員が仕事をする
ような構造です。
8x1.8b はMoE（Mixture of Experts）なので、
社内に8つの専門部署がある
↓
入力された内容を見てルーターが判断
↓
そのトークンに適した2部署だけを選ぶ
↓
その2部署を通して次のトークンを計算
となります。
イメージはこうです。
「徳川家康について説明して」
│
▼
Router
│
┌──────┴──────┐
▼ ▼
Expert 2 Expert 6
│ │
└──────┬──────┘
▼
次のtokenそして次のtokenでは、
Router
↓
Expert 1 + Expert 6のように、別のExpertが選ばれる可能性があります。
公式configでも、
- Expert総数：8
- 1 tokenで使用：2
- 24 layers
- hidden size：2048
- Attention heads：16
- Context：4096
となっています。アーキテクチャ自体はTransformers上では MixtralForCausalLM として実装されています。Hugging Face
「8×1.8B」という名前が少し紛らわしい
ここが最重要です。
実際の数字はこうなっています。
| 項目 | llm-jp-3-8×1.8b |
|---|---|
| 総パラメータ | 9.266B |
| 1 tokenでActive | 2.924B |
| Expert | 8 |
| 同時使用Expert | 2 |
| Context | 4096 |
| Layers | 24 |
ですから、
14.4Bモデルではありません。
また、
「1.8Bモデルが8個完全に入っている」
という理解も正確ではありません。
Attention、Embeddingなど共有する部分があり、主にTransformerのFFN部分がExpert化されています。
その結果、
モデルとして保持する情報量
約 9.3B
なのに、
1 tokenを処理するときの実計算
約 2.9B
という面白い構造になっています。
何がうれしいのか？
ここがMoEを使う最大の理由です。
Dense 9Bなら、
毎token
約9Bを計算します。
8×1.8Bなら、
モデル全体
約9.3B
しかし毎token
約2.9BだけActiveになります。
つまり狙いとしては、
「約9Bのモデル容量・知識を持ちながら、3B級に近い演算量で生成する」
ということです。
もちろん実際の速度が完全に3B Denseと同じになるわけではありません。Expert routingやメモリアクセスなどMoE特有のオーバーヘッドがあります。
ただしRAMは3B分では済まない
ここは非常によく誤解されます。
計算するのが2.9Bだからといって、
「3BモデルだからQ4なら2GBぐらい」
とはなりません。
8 Expert全部のweightをメモリ上に保持する必要があります。
元のBF16モデルファイルは約 18.5GBあります。Hugging Face
Q4量子化すると理論上のweightだけなら、
9.27B × 4bit
≈ 4.63GB
ですが、実際のGGUFでは量子化metadataや一部高精度tensorなどがあるので、これより増えます。
したがってイメージとしては、
RAM消費：9Bモデル級
演算量：3Bモデル級
です。
これがMoEです。
学習データはかなり大きい
このモデルは 約2.1兆tokensを見ています。Hugging Face
しかも内訳を見るとかなり面白く、
日本語だけでおよそ、
- Common Crawl：762.8B
- WARP/PDF：237.3B
- Wikipedia等
合計約 1兆tokens
あります。
英語も約1兆tokens、さらにCodeが114.1Bほど入っています。Hugging Face
なので、
かなり日本語比率の高いFoundation Model
です。
これはQwenなどの多言語モデルとは少し性格が違うところです。
では性能は何B相当なのか？
これが面白いところです。
同じLLM-jp-3のDenseモデル、
llm-jp-3-7.2b
と比較してみます。
公式 llm-jp-eval では、
| Base model | Score |
|---|---|
| 7.2B Dense | 0.455 |
| 8×1.8B MoE | 0.454 |
ほぼ同じです。Hugging Face
これはかなり面白い結果です。
つまり、
1 tokenあたり約2.9Bしか動かしていないのに、7.2B Denseとほぼ同程度の日本語ベンチマーク性能
を出しています。
これこそMoEのメリットです。
ただしチャット性能では7.2Bに少し負ける
Instruction版で比較すると、
Japanese MT-Bench：
| モデル | Score |
|---|---|
| 8×1.8B instruct3 | 5.52 |
| 7.2B instruct3 | 5.79 |
| 8x13B instruct3 | 6.58 |
となります。Hugging Face
つまり、
8×1.8B ≒ 7.2B Dense
とは言っても、常に同等というわけではありません。
特に複雑な会話やreasoningでは、Dense 7.2Bの方が少し強い傾向があります。
そして今見ている llm-jp-3-8x1.8b はBaseモデル
これも重要です。
名前が
llm-jp-3-8x1.8b
だけなら、これは事前学習済みBaseモデルです。
普通のChatGPTのように、
質問 → 丁寧に回答
するよう特化されているわけではありません。
チャット用途なら、
llm-jp-3-8x1.8b-instruct2
または
llm-jp-3-8x1.8b-instruct3
があります。
特に instruct3 はSFT後さらにDPOを行っています。
安全性評価でも、
- instruct2：Violation 7.56%
- instruct3：Violation 2.20%
まで改善しています。Hugging Face
図にするとこう
llm-jp-3-8x1.8b
│
┌──────────┴──────────┐
│ │
共通部分 MoE部分
Attentionなど 8 Experts
│
┌─ E1
├─ E2
├─ E3
├─ E4
├─ E5
├─ E6
├─ E7
└─ E8
tokenごとに
Router
│
8個から2個選択
│
┌────┴────┐
▼ ▼
E3 E7
│ │
└────┬────┘
▼
次の処理かなり乱暴に一言で表すなら
私はこのモデルを、
「約9Bの頭脳を持っているが、毎回約3Bだけ使って考える日本語LLM」
と説明します。
これが一番イメージに近いです。
そして面白いのは、公式評価ではその約3B分の計算で7.2B Denseとほぼ同じBase性能を達成していることです。Hugging Face
なので、LLM-jp-3の中ではかなり実験的にも面白いモデルです。
特にローカルLLMという観点では、次に見るべきなのは 「3.7B Dense vs 7.2B Dense vs 8×1.8B MoE」をQ4にした場合、RAM量・生成速度・日本語性能がどう違うのかです。ここを比較すると、8×1.8Bをわざわざ使う価値があるのかがかなり明確になります。
これを４ビットと５ビットで量子化してあります。
ダウンロード
https://u.pcloud.link/publink/show?code=kZ0aC5JZ2pFJbdiuJOHD1plQt02CFHxJaFIy
ここに二つ入ってます。私のWindowsでは動きました。
コメント