公開2026.04.06更新2026.10.13 94 人が閲覧（直近 30 日） LLM・RAG

LLM-jp-4とは？8B・32B-A3B・33Bと4.1の違い・性能・使い方【2026年10月】

LLM-jp-4は、国立情報学研究所（NII）の大規模言語モデル研究開発センター（LLMC）が開発する国産オープンLLMのシリーズです。2026年4月3日の8B・32B-A3B公開に続き、8月に33B、9月に画像を扱えるLLM-jp-4-VL 9Bと事後学習を改良したLLM-jp-4.1が出ており、4月時点の情報だけでは選び方を誤ります。この記事では、2026年10月13日時点の公開モデルと選び方、4と4.1の違い、Transformers・vLLM・llama.cppでの使い方、商用利用の条件を、NIIの発表とHugging Faceのモデルカード、手元での実行結果をもとに整理します。

まとめ：LLM-jp-4シリーズの要点（2026年10月時点）

いま新しく使うなら、LLM-jp-4.1のthinkingモデルが出発点です。4.1はツール呼び出しに初めて対応し、安全性と日本語の質問応答のスコアが上がりました。サイズは、手元のGPU1枚で試すなら8B、多段のツール呼び出しや精度を重視するなら33B、同じメモリで速度を取るなら32B-A3B（MoE）です。日本語MT-Benchは4の32B-A3Bが7.82、33Bが8.00でGPT-4o（7.29）を上回りますが、4.1では回答を短くした影響とみられる横ばいか微減です。ライセンスはすべてApache License 2.0で商用利用できる一方、モデルカードは「本番サービスでの直接利用は想定していない」と明記しています。

LLM-jp-4の開発元と公開の経緯

NII・LLMCとLLM-jpコミュニティの開発体制

開発しているのは、NIIのLLMCが主宰する研究開発コミュニティ「LLM-jp」です。NIIの2026年4月3日の発表によると、2026年3月31日時点で大学・企業などから2,600名以上が参加し、計算資源は産業技術総合研究所のABCI 3.0、資金は文部科学省の補助金事業「生成AIモデルの透明性・信頼性の確保に向けた研究開発拠点形成」です。既存モデルの重みを借りず、事前学習からすべて国内でやり直す「フルスクラッチ学習」で作られています。

LLM-jp-13Bから4.1までの公開履歴

LLM-jpの最初の成果は2023年10月20日に公開した130億パラメータの「LLM-jp-13B」で、LLM-jp-4は第4世代にあたります。2026年の公開は次のとおりです。

公開日	公開物
2026-04-03	LLM-jp-4 8B・32B-A3B（base／thinking、8Bはinstructも）
2026-06-24	thinkingモデルのGGUF量子化版
2026-08-18	LLM-jp-4 33B（base／thinking）
2026-09-01	LLM-jp-4-VL 9B（画像入力対応）
2026-09-28	LLM-jp-4.1（8B・32B-A3B・33Bのthinking）
2026-10-02	ELYZA-Thinking-1.0（ELYZAによる派生）

日付はLLM-jpのニュース一覧によります。

モデル一覧と8B・32B-A3B・33Bの選び方

パラメータ数と構成はHugging Faceのモデルカード、ファイルサイズは公式GGUFリポジトリの実ファイルです。文脈長は3モデルとも65,536トークンです。

モデル	構成	総パラメータ	推論時	層	BF16	Q4_K_M
8B	Dense（Llama系）	約86億	約86億	32	17.2GB	5.5GB
32B-A3B	MoE（Qwen3 MoE）	約321億	約38億	32	64.3GB	21.5GB
33B	Dense（Llama系）	約332億	約332億	64	66.4GB	20.4GB

表のBF16・Q4_K_Mは4.1のGGUFファイルの大きさで、実行時はこれに文脈分のKVキャッシュが加わります。

8B（Dense）と32B-A3B（MoE）の設計差

8BはLlama 2アーキテクチャのDenseモデルで、Q4_K_Mなら5.5GBに収まり、GPUの無いノートPCでも動きます。32B-A3BはQwen3 MoEアーキテクチャで、128個のエキスパートのうち8個だけを1トークンごとに使います。1トークンあたりの計算は約38億パラメータ分で済み、同規模のDenseモデル（33B）より計算量を抑えられます。一方、メモリには約321億パラメータ全体を載せる必要があり、GPUメモリに全体が収まる環境でこそ計算量の少なさが速度に表れます。

33B（約332億のDense）を選ぶ場面

33Bは8月に追加されたDenseモデルで、公開時の発表では、日本語MT-Bench・英語MT-Bench・AnswerCarefully・llm-jp-instructionsの4つすべてで、それまでのLLM-jp-4 thinkingモデルを上回りました。4.1の評価で差がはっきり出たのは多段のツール呼び出しで、BFCLのmulti turnとτ²-benchのretail・telecomで、8B・32B-A3Bより33Bのスコアが大きく伸びています。BFCLのsingle turn（ツールを1回呼ぶ課題）では33Bに明確な優位は無く、8Bと32B-A3Bもほぼ同等でした。ツールを1回呼ぶ程度なら8Bか32B-A3Bから試し、エージェントのように何手も続けて外部ツールを呼ぶ用途なら33Bを選びます。

base・instruct・thinkingの違い（instructは8Bだけ）

baseは事前学習と中間学習だけを終えたモデルで、追加学習の土台に使います。thinkingは回答の前に推論過程を出力するモデルで、SFT（教師ありファインチューニング）とDPO（直接選好最適化）で事後学習されています。instructは8Bにしかなく、モデルカードによるとSFTのみでDPOをかけていません。32B-A3Bと33Bにinstructは無く、4.1もthinkingだけです。推論を短くしたいときは、モデルを替えるのではなく後述のreasoning_effortをlowにします。

LLM-jp-4.1とは：4からの変更点と選び分け

LLM-jp-4.1は2026年9月28日に公開された、LLM-jp-4の事後学習の改良版です。事前学習はやり直しておらず、8B・32B-A3B・33Bのthinkingモデルと、そのGGUF版が出ています。

STEM強化・ツール呼び出し・回答の簡潔化

NIIの公開告知が挙げる改良は3つです。1つ目はSTEM分野で、4でも使っていたSFTデータのうちSTEM系のnemotron_post_v2_stemを約6倍、数学系のnemotron_post_v3_mathを約15倍に増やし、科学系などのサブセットも追加しました。2つ目はツール呼び出しへの対応で、LLM-jpとして初めて外部の関数やAPIを呼べるようになりました。3つ目は回答の簡潔化です。4には聞かれていないことまで書く傾向があり、技術ブログによれば「SFTとDPOの違いは？」への最終回答は4の約1/5の長さになりました。SFTの総学習量は約35Bトークンで、4の約3倍です。

llm-jp-judgeのスコア比較（4と4.1）

評価者はGPT-5.4（gpt-5.4-2026-03-05）、reasoning_effortはmediumです。

モデル	MT-Bench日本語	MT-Bench英語	AnswerCarefully	llm-jp-instructions
4 8B	7.54	7.79	3.69	3.54
4.1 8B	7.58	7.67	3.92	3.67
4 32B-A3B	7.82	7.86	3.70	3.61
4.1 32B-A3B	7.69	7.85	3.91	3.79
4 33B	8.00	8.24	3.79	3.79
4.1 33B	7.76	7.98	4.08	3.83
GPT-4o	7.29	7.69	4.00	4.07
gpt-oss-20b	7.33	7.85	3.55	3.16

MT-Benchは情報量の多い回答ほど高く採点されやすく、NIIは回答の簡潔化がスコアに影響した可能性を挙げています。スコアが頭打ちになりつつあることも踏まえ、4.1からMT-Benchは補助指標の扱いです。代わりに上がったのが、日本語の安全性を測るAnswerCarefullyと、人手で作った質問応答のllm-jp-instructionsです。後者の内訳では、情報量は減り正確性が上がっています。

4のまま使う場面と4.1へ移る場面

LLM-jpの公式テキストモデルを新しく導入するなら4.1を選びます。LLM-jpでツール呼び出しに対応するのは4.1だけで、安全性と正確性のスコアも4.1が上です。ただし技術ブログによると、4.1の公開版は自己紹介を「LLM-jp-4」に書き換えた学習の副作用で、LLM-jpとOpenAIの知識を混同する例が増えています（改訂版か次期版で修正予定）。他社の製品や組織を扱う業務では、この混同を受け入れ評価の項目に入れてください。4のまま残してよいのは、MT-Benchで測るような長く詳しい文章生成をすでに4で検証済みの場合と、4.0のinstructやbaseを前提に追加学習を組んでいる場合です。公式のcookbookは4.1が4.0と後方互換だとしており、Python側はモデルIDを差し替えるだけで移れます。ただしGGUFは別で、4.0のGGUFはllama.cppで4.1用の解析器を選ぶ宣言を持たないため、llama.cppで動かすなら4.1のGGUFを使います。

性能評価：GPT-4o超えの意味と弱点

日本語MT-Benchの「GPT-4o超え」が成り立つ範囲

4月の発表にある「GPT-4o超え」は、日本語・英語MT-Benchのスコアに限った話です。上の表のとおり、llm-jp-instructionsではすべてのLLM-jpモデルがGPT-4o（4.07）を下回り、AnswerCarefullyでGPT-4o（4.00）を超えたのは4.1の33B（4.08）だけです。評価者が以前のgpt-4oからGPT-5.4に変わったため、LLM-jp-3系列の公表スコアとは直接比べられない点もモデルカードに注記されています。ベンチマークの見方はLLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】で整理しています。

swallow-evaluation-instructで見える数学・科学・コードの差

4.1では高難度タスクを集めたswallow-evaluation-instructの結果も公開されました。全サイズで4より平均が上がり、33Bは平均でgpt-oss-120bとほぼ同等、Olmo-3.1-32B-ThinkやQwen3-32Bを上回りました。一方でQwen3.8-27BやGemma-4-31B-itには差が残り、NII自身がAIMEやGPQAなどの数学・科学と、コード生成を課題に挙げています。日本語の業務文書を扱う用途と、競技数学やコーディングの性能が要る用途とでは、評価を分けて考えるべきです。

学習データとトークナイザー

LLM-jp Corpus v4.1と事前学習の量

事前学習コーパスは約19.5兆トークンで、内訳は日本語約7,000億、英語約17.8兆、中国語・韓国語約8,500億、コード約2,000億トークンです。そこから約10.5兆トークンを事前学習に、合成データを加えた約1.2兆トークンを中間学習に使い、合計は約11.7兆トークンです。学習データにはOSAID（オープンソースAIの定義）に配慮して第三者も入手できるデータを選び、事前学習と中間学習のコーパス、4.1のSFT・DPOデータまで公開しています。ただしライセンス上、一部は非公開と明記されています。

日本語のトークン数をQwen3・gpt-ossと比べた実測

トークナイザーはllm-jp-tokenizer v4.0から変換した語彙196,608のUnigram byte-fallback方式です。同じ日本語の文章を、Qwen3とgpt-ossのトークナイザーと並べて数えました（2026年10月13日、各モデルのtokenizer.jsonをHugging Face tokenizers 0.22.2で読み込み）。

文章	LLM-jp-4.1	Qwen3-8B	gpt-oss-20b
NII発表文（日本語637字）	321	450	460
4.1技術ブログ（日本語734字）	336	438	484
モデルカード（英語942字）	214	210	209

今回の日本語2例では、Qwen3より23〜29%、gpt-ossより30〜31%少ないトークンで表せました。英語はほぼ同じです。この2例の比率（1.30〜1.44倍）がそのまま当てはまるなら、同じ65,536トークンの文脈により多くの日本語を入れられます。計測は特殊トークンを含めず、発表文はルビの読み仮名と注番号を除いた本文で数えました。トークナイザーの方式の違いはトークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】で解説しています。

使い方：Transformers・vLLM・llama.cppで動かす

公式の手順はllm-jp-4-cookbookにまとまっており、2026年10月7日に4.1向けに更新されています。必要な最低バージョンは、Transformers 5.0.0、vLLM 0.30.0（llm-jp-vllm 0.1.1と併用）、llama.cpp v0.6.0です。チャットテンプレートはOpenAIのHarmony形式を元にしていますが、トークナイザーが違うためopenai-harmonyライブラリではトークン化できません。

Transformers 5.0以上でthinkingモデルを動かす

cookbookの例を短くしたものです。独自のトークナイザーと応答解析器を読み込むため、trust_remote_code=Trueが必要です。これはモデルのリポジトリにあるPythonコードを実行する設定なので、llm-jpの公式リポジトリ以外では使わないでください。

# pip install "transformers>=5.0.0" torch accelerate
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "llm-jp/llm-jp-4.1-8b-thinking"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id, dtype=torch.bfloat16, device_map="auto", trust_remote_code=True
)

messages = [{"role": "user", "content": "SFTとDPOの違いを簡潔に教えてください。"}]
prompt = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True,
    reasoning_effort="medium",  # low / medium / high
)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.no_grad():
    out = model.generate(**inputs, max_new_tokens=1024,
                         do_sample=True, temperature=0.7, top_p=0.9)

response = tokenizer.decode(out[0][inputs["input_ids"].shape[1]:])
parsed = tokenizer.parse_response(response)
print(parsed["thinking"])  # 推論過程
print(parsed["content"])   # 最終回答

Transformers 5.2.0でこのチャットテンプレートを生成すると、システムメッセージに「You are LLM-jp-4」「Knowledge cutoff: 2025-12」と当日の日付が自動で入りました（4・4.1・8B instructで共通）。これは自己紹介文の既定値で、2025年12月までの出来事を知っている保証ではありません。日付に依存する質問には、RAGなどで最新情報を渡す前提で組みます。

vLLMでOpenAI互換サーバーを立てる

本番に近い形で複数リクエストをさばくならvLLMです。推論過程とツール呼び出しを分けて返すには、LLM-jpが配布するパーサーllm-jp-vllmを組み込みます。

pip install "vllm>=0.30.0" "llm-jp-vllm>=0.1.1"
vllm serve llm-jp/llm-jp-4.1-8b-thinking \
    --trust-remote-code \
    --reasoning-parser llmjp4 \
    --reasoning-parser-plugin llm_jp_vllm.llmjp4 \
    --enable-auto-tool-choice \
    --tool-call-parser llmjp4 \
    --tool-parser-plugin llm_jp_vllm.llmjp4 \
    --host 127.0.0.1 --port 8000

cookbookの動作確認環境はNVIDIA RTX 6000 Ada（48GB）です。/v1/chat/completionsにOpenAIと同じ形式で送れば、推論過程と最終回答が分かれて返ります。

llama.cppでGGUFを動かす（Ollamaの扱い）

GPUの無いPCで試すならGGUFとllama.cppです。v0.6.0（2026年10月5日リリース）で、LLM-jp-4.1用のHarmony解析器が本体に入りました。それより前の版では、モデルカードが案内するLLM-jpのフォーク版が必要でした。

# 対話（初回はHugging FaceからGGUFを取得してキャッシュ）
llama cli -hf llm-jp/llm-jp-4.1-8b-thinking-gguf:Q4_K_M

# OpenAI互換サーバー
llama serve -hf llm-jp/llm-jp-4.1-8b-thinking-gguf:Q4_K_M \
    --alias llm-jp-4.1-8b-thinking --host 127.0.0.1 --port 8080

2026年10月13日に、v0.6.0をソースからビルドし、公式のllm-jp-4.1-8b-thinking-Q4_K_M.ggufをllama serveで動かしました。GPUを使わないIntel Core i9-9880H・メモリ16GBのMacで、応答はreasoning_content（推論過程）とcontent（回答）に分かれて返り、「東京と大阪の天気を調べて」に対してはget_weatherを2件並列で呼ぶtool_callsを返しました。生成速度は1.47トークン/秒、常駐メモリは文脈8,192トークンで約5.8GBです。この速度では、即時の応答や同時利用が要る業務にはGPUが要ります。夜間の一括要約のように待てる処理なら、件数と許容時間からCPUで足りるかを見積もれます。

Ollamaの公式ライブラリには、10月13日時点でLLM-jp-4は登録されていません。OllamaはHugging FaceのGGUFを直接読み込めますが、同梱しているllama.cppが4.1の解析器を含む版かどうかは公式の案内がないため、推論過程の分離やツール呼び出しを使うならllama.cpp v0.6.0以上を直接使うほうが確実です。GGUFと量子化の仕組みはGGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】を参照してください。

派生モデル：LLM-jp-4-VL 9BとELYZA-Thinking-1.0

LLM-jp-4-VL 9B（画像を読む視覚言語モデル）

LLM-jp-4-VL 9Bは、llm-jp-4-8b-thinkingに画像エンコーダーのSigLIP 2 So400m（約4億パラメータ）をつないだモデルで、2026年9月1日に公開されました。4月のbeta版の学習データから利用規約上の懸念があるものを除いたRefinedVisionなどで学習し直しています。ライセンスはApache License 2.0です。ただしNII自身がQwen3.5-9Bとは多くのタスクで差があると認めており、図表読み取りの精度を最優先するなら他モデルとの比較が要ります。

ELYZA-Thinking-1.0（ELYZAがllm-jp-4を追加学習した派生モデル）

ELYZAは2026年10月2日、llm-jp-4-33b-baseとllm-jp-4-32b-a3b-baseを土台に、ELYZAが中間学習と事後学習を施したELYZA-Thinking-1.0を公開しました。日本語の推論・指示追従と、日本語Wikipediaなどから合成した知識の想起を強化しており、ライセンスはApache License 2.0です。LLM-jpがbaseモデルまで公開しているからこそ、こうした派生が作れます。

商用利用の条件と導入判断

Apache License 2.0で許される範囲

LLM-jp-4・4.1・VL 9BはすべてApache License 2.0で、商用利用・改変・再配布ができ、追加の契約は要りません。配布するときは、改変の有無にかかわらずライセンス文を添付し、元の著作権・特許・帰属の表示を残します。NOTICEファイルがあればその帰属表示も引き継ぎ、改変したファイルには変更した旨を明記します。学習データの大半が公開されているので、何で学習したかを監査や顧客に説明する材料になります。ただしライセンス上の理由で非公開の部分は確認できません。

「本番での直接利用は想定外」という注記と採用を避ける場面

ライセンスとは別に、4.1のモデルカードは「研究開発用のモデルで、本番サービスでの直接利用は想定していない」と書き、4の各カードも「研究開発の初期段階で、出力を人の意図や安全面に沿うよう調整しきれていない」と明記しています。顧客に直接回答を返すチャットボットにそのまま載せるのは避け、出力の検証や禁止事項のフィルタを自前で用意できる場合に限って使うべきです。逆に、機密文書を社外に出せない社内での要約・分類・検索の下処理は、オンプレミスで完結できる利点がそのまま生きる用途です。国産モデルの選択肢はSwallowとは？Llama 3.3 Swallowの特徴・日本語性能・商用利用を解説や国産生成AI基盤モデル「PLaMo 3.0 Prime」とは｜2026年最新の性能・料金・使い分けも比べてください。社内データを使った生成AIの設計から運用までを相談したい場合は、生成AI導入支援で対応しています。

今後の予定：332B-A31B・LLM-jp-4.2・mdx-MaaS

4月の発表で予告されたMoEの「LLM-jp-4 332B-A31B」は、2026年度中の公開予定のまま、10月13日時点ではHugging Faceに出ていません。同時に予告されたDenseの大型モデルとしては、8月に約332億パラメータの33Bが公開されています。次期シリーズの「LLM-jp-4.2」は開発中で、学習データの拡充と強化学習の導入で推論とエージェント機能を伸ばす方針です。4.1のAPIとチャットは、東京大学の「mdx-MaaS」を通じて主に研究者向けに試験提供され、10月中旬から段階的に募集を始める予定です。