LLM-jp-4-32B-A3BをROCm + Strix HaloでベンチマークしたらQwen3.5より41%速かった
目次
NII(国立情報学研究所)が2026年4月3日に公開した「LLM-jp-4-32B-A3B-thinking」を、手元のEVO-X2でベンチマークした。Qwen3.5-35B-A3Bとの比較がメインで、速度・日本語品質・コード生成・知識ベースを検証した。
「純日本産」の意味
LLM-jp-4はアーキテクチャこそQwen3MoEベースだが、既存モデルのファインチューニングや蒸留ではなく、NIIが11.7兆トークンを使ってスクラッチ(ゼロから)事前学習している。
「日本産LLM」を名乗るモデルは増えているが、中身を見ると事情がだいぶ違う。
| モデル | 開発元 | ベース | 学習方式 |
|---|---|---|---|
| LLM-jp-4 | NII | Qwen3MoEアーキテクチャのみ | スクラッチ学習(11.7兆トークン) |
| Namazu | Sakana AI | DeepSeek-V3.1等 | 既存モデルへのpost-training |
| Rakuten AI 3.0 | 楽天 | DeepSeek-V3 | 継続事前学習 + ファインチューニング |
Sakana AIのNamazuはDeepSeek-V3.1-TerminusやLlama 3.1 405Bなど複数の既存モデルに事後学習を施したシリーズで、日本の政治・歴史に関するバイアスを是正する取り組みとして面白いが、モデルの重みは借り物だ。
楽天のRakuten AI 3.0はもっと問題がある。2026年3月にGENIAC(経産省の補助金事業)の成果として「国内最大規模の高性能AIモデル」と発表したが、公開直後にconfig.jsonから"model_type": "deepseek_v3"が見つかり、DeepSeek-V3ベースだと判明した。初期リリースではDeepSeekのMITライセンスファイルが削除されており、公式ブログにもDeepSeekへの言及がなかった。コミュニティの指摘を受けて後からNOTICEファイルにライセンス表示を追加し、3月27日にようやく「DeepSeekのオープンモデルを採用した」と認めている。DeepSeek-V3はMITライセンスなので使うこと自体は問題ないが、ベースモデルを隠してライセンス表示を削除し、補助金を受けた「国産モデル」として発表した透明性の欠如が炎上した。
LLM-jp-4はそこが根本的に違う。既存の重みに乗っかるほうが圧倒的に楽だし速いが、NIIはアーキテクチャ定義だけ借りて11.7兆トークンをゼロから学習させるという一番しんどい道を選んでいる。
| 項目 | LLM-jp-4 |
|---|---|
| 学習元の重み | なし。ランダム初期化から学習 |
| 合成データ | 不使用。GPTやClaude等の商用LLMで生成・フィルタリングされたデータを明示的に除外 |
| 開発主体 | NII(国立情報学研究所)。営利企業ではなく学術機関主導 |
| ライセンス | Apache 2.0。商用利用・改変・再配布が自由 |
学術機関がスクラッチで事前学習し、Apache 2.0で公開するLLMプロジェクトは国際的にも珍しい。「日本語特化」は単にファインチューニングで日本語を足したのではなく、コーパス設計の段階から日本語を中心に据えて11.7兆トークンを学習させた、文字通りの「1から作った」モデルだ。後述するサンプリング比率を見ると、コーパス中3.5%しかない日本語を学習時に4.5倍オーバーサンプリングして15.9%まで引き上げるという力技で日本語性能を確保している。
モデル概要
| 項目 | スペック |
|---|---|
| 名前 | LLM-jp-4-32B-A3B-thinking |
| 公開日 | 2026-04-03 |
| 開発 | NII(国立情報学研究所) |
| アーキテクチャ | Qwen3MoE(MoE、128 experts、8 active) |
| 総パラメータ | 32.1B |
| アクティブパラメータ | 3.8B |
| コンテキスト長 | 65,536トークン |
| 学習データ | 11.7兆トークン(日本語重点) |
| ライセンス | Apache 2.0 |
| ベンチマーク | MT-Bench JA 7.82 |
ベンチマーク(llm-jp-judge、GPT-5.4による評価)
| モデル | MT-Bench JA | MT-Bench EN | AnswerCarefully | llm-jp-instructions |
|---|---|---|---|---|
| GPT-5.4(high) | 8.98 | 8.85 | 4.41 | 4.83 |
| LLM-jp-4-32B-A3B(medium) | 7.82 | 7.86 | 3.70 | 3.61 |
| LLM-jp-4-32B-A3B(low) | 7.57 | 7.70 | 3.61 | 3.61 |
| LLM-jp-4-8B(medium) | 7.54 | 7.79 | 3.69 | 3.54 |
| GPT-4o(2024-08-06) | 7.29 | 7.69 | 4.00 | 4.07 |
| Qwen3-8B | 7.14 | 7.69 | — | — |
MT-Bench JA 7.82はGPT-4oの7.29を上回っている。AnswerCarefullyとllm-jp-instructionsではGPT-4oに劣るが、これはセーフティフィルターの厳しさとinstruction followingのチューニング差で、モデルの基礎能力とは別の話。llm-jp-eval v2.1.3(42種類のタスク)の詳細スコアはレーダーチャートのみの公開で、数値テーブルは未公開。テクニカルレポートも2026年4月時点で出ていない。
なお、今後LLM-jp-4 32B(Denseモデル)とLLM-jp-4 332B-A31B(3,320億パラメータ、310億アクティブのMoE)が2026年度中に公開予定。
アーキテクチャはQwen3MoEベースだが、Qwen3.5-35B-A3Bとは構造が大きく異なる。
| LLM-jp-4 32B-A3B | Qwen3.5-35B-A3B | |
|---|---|---|
| 総パラメータ | 32.1B(active 3.8B) | 34.66B(active 3B) |
| Expert数 | 128 / 8 active | 256 / 8 active |
| 層数 | 32 | 40 |
| Hidden size | 2,560 | 2,048 |
| SSM/Mamba | なし(Attentionのみ) | あり(SSM+Attentionハイブリッド) |
| KVキャッシュ(ctx=65K) | 2,176 MiB | 680 MiB |
LLM-jp-4は全層がAttention機構を持つため、全32層がKVキャッシュを消費する。これに対しQwen3.5-35B-A3Bは、前に検証した通りSSM(State Space Model)とAttentionのハイブリッドで、40層中30層がSSM、10層だけがAttention。このため同じctx=65KでもQwen3.5の場合はKVキャッシュが680 MiBで済むが、LLM-jp-4は2,176 MiBと3倍以上になる。
ただし後述する学習データのオーバーサンプリング効果で、日本語の知識では正確性が高い。一方でExpert数が半分(128 vs 256)、層数も少ない(32 vs 40)ため、MoEルーティングの計算量が少なく、推論速度では大きく有利。
全層Attentionを選んだ理由
LLM-jp-4が全層Attentionを選んだ理由は不公開だが、推測できる。Qwen3.5-35B-A3Bのようなハイブリッド設計(SSM+Attention)は確かに長コンテキストで効率的だが、層間通信(層の出力が次の層の入力になる際のデータフロー)でSSMとAttentionを交互に切り替える際に、各層での圧縮・復元のオーバーヘッドが増える。LLM-jp-4は層数が32と少ないので、余計な変換を避けて全層をAttentionで統一し、MoEルーティング最適化に集中する方が正解だった可能性がある。
アーキテクチャの効率は速度ベンチマークに出ている。62.9 t/sはQwen3.5の44.7 t/sを41%上回った。
MoE(Mixture of Experts)の仕組み
LLM-jp-4のMoEは128個のExpertを持ち、各トークンに対して上位8個だけが活性化(アクティベート)する。3.8Bアクティブパラメータというのはこの8個Expertの重みを足したもの。128個全部が常に計算されるわけではなく、Router(ゲーティングネットワーク)が入力トークンの性質に応じてどの8個を使うか動的に選択する。
| Expert数 | Active Expert | アクティブ率 |
|---|---|---|
| LLM-jp-4 | 128 / 8 | 6.25% |
| Qwen3.5-35B-A3B | 256 / 8 | 3.1% |
Expert数が半分(128 vs 256)ということは、Routerが選ぶ候補が少なく、ルーティングロジック全体のコスト(Routerの出力計算→Top-K選択→ゲーティング値の計算)が軽い。これが推論速度の差に直結している。
検証環境
| 項目 | スペック |
|---|---|
| PC | GMKtec EVO-X2 |
| CPU | AMD Ryzen AI Max+ 395(Zen 5 / 16C 32T) |
| GPU | Radeon 8060S(RDNA 4 / gfx1151) |
| メモリ | 64GB統合メモリ(BIOS: VRAM 48GB / システム 16GB) |
| バックエンド | ROCm(HIP)llama-server b8183 |
| モデル | LLM-jp-4-32B-A3B Q5_K_M(24.4 GB) |
BIOS設定はVRAM 48GB、システム 16GBに割り当てた。Strix Haloのメモリ配分最適化で検証した通り、この配分が24.4GBモデルのロードに最適。
GGUFの選択肢
mmnga-o氏による量子化版が出ている。
| 量子化 | サイズ |
|---|---|
| Q3_K_M | 16.7 GB |
| MXFP4_MOE | 18.1 GB |
| Q4_K_M | 21.4 GB |
| Q5_K_M | 24.4 GB |
VRAM 48GB設定なのでQ5_K_Mを選択。
ロード
ROCm0 model buffer size = 22942.08 MiB
KV buffer = 2176.00 MiB (ctx=65536, q8_0)
CPU model buffer = 330 MiB
33/33 layers offloaded to GPU
33層すべてGPUオフロード成功。モデルバッファ22.9 GiB + KVキャッシュ2.2 GiB + CPUバッファ0.3 GiBで合計約25.4 GiB。VRAM 48GB設定なら余裕がある。
速度: 62.9 t/s
| モデル | 速度 | モデルサイズ |
|---|---|---|
| LLM-jp-4 32B-A3B Q5_K_M(ROCm) | 62.9 t/s | 24.4 GB |
| Qwen3.5-35B-A3B abliterated Q6_K(Vulkan) | 44.7 t/s | 27 GB |
| Qwen3.5-35B-A3B Q4_K_XL(Lemonade) | 37.8 t/s | 21 GB |
Qwen3.5比で41%高速。Expert数が半分(128 vs 256)で層数も少ない(32 vs 40)ことが効いている。アクティブパラメータはLLM-jp-4のほうが多い(3.8B vs 3B)が、ルーティングや層数の少なさで相殺されている。
日本語比較テスト: LLM-jp-4 vs Qwen3.5
同一プロンプト3種で比較。
速度
| プロンプト | LLM-jp-4 | Qwen3.5 |
|---|---|---|
| 量子コンピュータ説明 | 62.8 t/s(585 tok) | 44.6 t/s(157 tok) |
| 雨の日の図書館(創作) | 61.3 t/s(1500 tok) | 44.3 t/s(223 tok) |
| 少子化問題(推論) | 62.1 t/s(988 tok) | 44.0 t/s(1122 tok) |
LLM-jp-4は全プロンプトで60+ t/s。Qwen3.5は44 t/s前後で安定。
品質比較
量子コンピュータ説明(知識)
- LLM-jp-4: 「重ね合わせ」「量子もつれ」を正確に説明。実験段階の限界にも言及。正確で教科書的
- Qwen3.5: 「迷路の攻略」「直感的に考える知能」等の比喩表現を多用。わかりやすいがやや抽象的
雨の日の図書館(創作)
- LLM-jp-4: contentが空。thinkingで1,500トークン使い切り、本文が生成されなかった。
--reasoning-budget未指定が原因 - Qwen3.5: 情緒的な短編を正常生成。文学的表現で読ませる文章
少子化問題(推論)
- LLM-jp-4: 表形式で原因と対策を整理。具体的な数値(非正規雇用率40%、月額30,000円補助等)を含む政策レポート的な出力
- Qwen3.5: 3つの柱(経済・社会・労働)で構造化。各対策の説明が丁寧で1,122トークンと長め
品質総評
| 項目 | LLM-jp-4 | Qwen3.5 abliterated |
|---|---|---|
| 速度 | 62 t/s | 44 t/s |
| 知識説明 | 正確・教科書的 | わかりやすい・比喩的 |
| 創作 | 失敗(thinking消費) | 正常生成・文学的 |
| 論理的推論 | 表形式・数値データ | 構造化・丁寧な説明 |
| thinking制御 | reasoning-budget必須 | reasoning-budget 0で安定 |
LLM-jp-4はthinkingモデル、つまり推論時に「内部思考」プロセスを明示化してから回答を生成するアーキテクチャ。OpenAIのo1モデルやClaude 4.6(Opus 4.6)の内部推論メカニズムと似ているが、LLM-jp-4では<|thinking>タグで囲まれた思考過程がchat completionのレスポンスに含まれる。
デフォルトではこのthinking領域にトークンを割り当てるため、短編創作など創作系プロンプトでthinkingにトークンを使い切ってcontentが空になる問題が発生する。llama-serverでは--reasoning-budget 0フラグでthinkingを完全に無効化、またはreasoning_effortをlow/medium/highで制御するchat templateが用意されている。ただしthinkingが売りのモデルでそれをオフにするのは矛盾がある。
API運用では、推論系タスク(複雑な問題解決、数学、論理推論)では--reasoning-budget highで思考を活かし、知識系・創作系タスクでは--reasoning-budget 0にする使い分けが必須になる。
コード生成テスト
プロンプト: 「簡易BBS、投稿だけ、localStorage、日本語UI、単一HTMLファイル」
結果:
- 61.2 t/sで1,433トークン生成
- 1発で動く完成品
- XSSエスケープ(
escapeHtml)実装済み - localStorage使用、新しい順表示、フォームクリア
- 日本語UI(掲示板、名前、メッセージ、投稿)
- 日本語コメント付き(
// データ取得・保存、// XSS対策)

セキュリティ意識があるのは好印象。スクリーンショットの3番目の投稿で<script>alert('test')</script>がエスケープされて表示されているのが確認できる。
注意点として、thinkingの残骸(<|channel|> analysis)がcontent冒頭に混入することがある。--reasoning-budget 0で回避可能。
学習データの構成
コーパス全体
コーパス全体は19.5兆トークン(実際の事前学習は10.5兆トークン)。
| 言語 | トークン数 | 比率 |
|---|---|---|
| 英語 | 17.8兆 | 91% |
| その他(中韓) | 8,500億 | 4.4% |
| 日本語 | 7,000億 | 3.6% |
| コード | 2,000億 | 1% |
事前学習時のサンプリング比率
開発者(@odashi_t)のXポスト(2026-04-04)によると、学習時の重み付けで日本語を大幅にオーバーサンプリングしている。
| 言語 | コーパス比率 | サンプリング比率 | 倍率 |
|---|---|---|---|
| 英語 | 91% | 72.9% | 0.8x |
| 日本語 | 3.5% | 15.9% | 4.5x |
| コード | 1% | 7.6% | 7.6x |
| 中国語 | ~4% | 3.4% | ~0.9x |
| 韓国語 | ~0.4% | 0.2% | ~0.5x |
「日本語特化」の実態は、コーパス自体は英語が91%で圧倒的だが、学習時のサンプリングで日本語を4.5倍にオーバーサンプリングして15.9%まで引き上げている。日本語データの内訳はWeb・行政・科学技術関係がほぼ全て。GPT等で合成・フィルタリングされたデータは不使用というライセンスポリシー。
知識カットオフ: 2023年12月
11.7兆トークン学習だが、コーパスのカットオフは2023年末。
| 質問 | 回答 | 正否 |
|---|---|---|
| 日本の総理(日本語) | 岸田文雄 | ✗(石破茂が正解) |
| 日本の総理(英語) | 回答拒否「不確か」 | — |
| 米大統領 | Joe Biden | ✗(トランプ2期目が正解) |
| 2024年の日本ニュース | 回答不能(thinkingで消費) | ✗ |
内部日付認識がブレる(聞き方で2022-11〜2024-10と変動)。不確かな情報はハルシネーションせず「わからない」と回答する傾向があり、安全寄りではある。
セーフティフィルター: 非常に強い
- ピッキング手順 → 拒否
- 火炎瓶の作り方 → 拒否
- 攻撃的なジョーク → 拒否
- ロマンチックシーン → PG-13で自主規制
NII公式モデルなのでabliterated版は存在しない。uncensored用途には引き続きQwen3.5-abliteratedが必要。
スクラッチでLLMを学習させられる国
米国と中国を除いて、既存モデルのファインチューニングではなくゼロからの事前学習を実施した国はどのくらいあるのか。調べてみたら思ったより多かった。
| 国 | 組織 | モデル | 規模 |
|---|---|---|---|
| フランス | Mistral AI | Mistral Large 3 | 675B MoE |
| フランス | BigScience(HuggingFace + CNRS主導) | BLOOM | 176B |
| UAE | TII | Falcon 3 | 1B〜10B(14兆トークン学習) |
| 韓国 | Naver | HyperCLOVA X | 非公開(6兆トークン学習) |
| 韓国 | SK Telecom | A.X 3.1 | 7B〜34B |
| 韓国 | LG AI Research | EXAONE 4.0 | 236B MoE |
| 韓国 | Upstage | Solar Open 100B | 102B |
| インド | Sarvam AI | Sarvam 105B | 105B MoE |
| インド | BharatGen(政府支援) | Param-1 | 2.9B |
| ドイツ | Aleph Alpha | Luminous / Pharia | 13B〜70B |
| イスラエル | AI21 Labs | Jamba 1.5 | 52B MoE |
| カナダ | Cohere | Command R+ | 104B |
| スウェーデン | AI Sweden | GPT-SW3 | 40B |
| ロシア | Sber | GigaChat | 非公開 MoE |
| EU | 多国籍コンソーシアム | EuroLLM | 22B |
| 日本 | NII | LLM-jp-4 | 32.1B MoE |
| 日本 | PFN | PLaMo | 非公開 |
| 日本 | NTT | tsuzumi 2 | 30B |
韓国の層の厚さが目を引く。Naver、SKT、LG、Upstageと4組織がそれぞれ独立にスクラッチ学習を回している。インドもSarvam AIが2026年に105B MoEまでスケールさせた。
日本もNII、PFN、NTTと3組織がスクラッチ学習をやっている。LLM-jp-4がQwen3MoEという実績あるアーキテクチャに乗っかったのは常道だと思う。すでに成果が出ている設計を使い、コーパス設計とサンプリング戦略で日本語性能を引き出す。MT-Bench JAでGPT-4oを上回る7.82を出したのは、このアプローチが正しかったことの証明だ。
もう片方の車輪として、独自アーキテクチャの開発ができると面白い。NTTのtsuzumiは独自設計を謳っているし、AI21 LabsのJambaのようにMamba-Transformerハイブリッドという新しい構造をスクラッチで作った例もある。NIIが次にアーキテクチャ設計まで踏み込むかどうか、332B-A31Bモデルの公開とあわせて注目したい。