技術 約12分で読めます

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-4NIIQwen3MoEアーキテクチャのみスクラッチ学習(11.7兆トークン)
NamazuSakana AIDeepSeek-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 JAMT-Bench ENAnswerCarefullyllm-jp-instructions
GPT-5.4(high)8.988.854.414.83
LLM-jp-4-32B-A3B(medium)7.827.863.703.61
LLM-jp-4-32B-A3B(low)7.577.703.613.61
LLM-jp-4-8B(medium)7.547.793.693.54
GPT-4o(2024-08-06)7.297.694.004.07
Qwen3-8B7.147.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-A3BQwen3.5-35B-A3B
総パラメータ32.1B(active 3.8B)34.66B(active 3B)
Expert数128 / 8 active256 / 8 active
層数3240
Hidden size2,5602,048
SSM/Mambaなし(Attentionのみ)あり(SSM+Attentionハイブリッド)
KVキャッシュ(ctx=65K)2,176 MiB680 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-4128 / 86.25%
Qwen3.5-35B-A3B256 / 83.1%

Expert数が半分(128 vs 256)ということは、Routerが選ぶ候補が少なく、ルーティングロジック全体のコスト(Routerの出力計算→Top-K選択→ゲーティング値の計算)が軽い。これが推論速度の差に直結している。

検証環境

項目スペック
PCGMKtec EVO-X2
CPUAMD Ryzen AI Max+ 395(Zen 5 / 16C 32T)
GPURadeon 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_M16.7 GB
MXFP4_MOE18.1 GB
Q4_K_M21.4 GB
Q5_K_M24.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/s24.4 GB
Qwen3.5-35B-A3B abliterated Q6_K(Vulkan)44.7 t/s27 GB
Qwen3.5-35B-A3B Q4_K_XL(Lemonade)37.8 t/s21 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-4Qwen3.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-4Qwen3.5 abliterated
速度62 t/s44 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対策

LLM-jp-4が生成した簡易BBS

セキュリティ意識があるのは好印象。スクリーンショットの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 AIMistral Large 3675B MoE
フランスBigScience(HuggingFace + CNRS主導)BLOOM176B
UAETIIFalcon 31B〜10B(14兆トークン学習)
韓国NaverHyperCLOVA X非公開(6兆トークン学習)
韓国SK TelecomA.X 3.17B〜34B
韓国LG AI ResearchEXAONE 4.0236B MoE
韓国UpstageSolar Open 100B102B
インドSarvam AISarvam 105B105B MoE
インドBharatGen(政府支援)Param-12.9B
ドイツAleph AlphaLuminous / Pharia13B〜70B
イスラエルAI21 LabsJamba 1.552B MoE
カナダCohereCommand R+104B
スウェーデンAI SwedenGPT-SW340B
ロシアSberGigaChat非公開 MoE
EU多国籍コンソーシアムEuroLLM22B
日本NIILLM-jp-432.1B MoE
日本PFNPLaMo非公開
日本NTTtsuzumi 230B

韓国の層の厚さが目を引く。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モデルの公開とあわせて注目したい。

関連記事