VRAM 7.1GBの8Bが21.9GBの33Bに勝ち、日本語では真逆になった——llm-jp-4 thinking 3兄弟を2つのベンチで叩いた

コーディングと日本カルチャーなどの評価のため、日本語の賢さや正確さは測れていません。

こんにちは、くーるぜろです。

国立情報学研究所（NII）の LLM-jp が出している国産LLM `llm-jp-4` に、2026年8月18日、33Bという最大サイズが追加されました。本検証を回したのが8月25日なので、公開からちょうど1週間の新顔です。既存の 8B（dense）と 32B-A3B（MoE）と合わせて、thinking版が3つ揃った。同じチームが同じコーパスで作った3兄弟が横並びで手に入る機会はそう多くありません。

そこで全部 Q4_K_M に揃えて、いつもの `llmbench` 60タスク（コーディング、英語）と、日本語ネットカルチャー24問の2本にかけました。狙いは単純で、「大きいほうが強い」がどこまで成り立つかを見ることです。

結果は、成り立ちませんでした。というより、ベンチを変えたら序列が丸ごとひっくり返りました。

• コーディングベンチ: 8B が Combined 68.8 でトップ。33B が 65.2 で最下位

• 日本語ネットカルチャー: 33B が 58.3% で圧勝。8B は 29.2% で最下位

VRAM 7.1GB のモデルが 21.9GB のモデルに勝ち、別のベンチでは同じ2機種が真逆に並ぶ。しかも公式モデルカードの公称値（MT-Bench JA）は、BF16でも Q4_K_M でも 33B がトップです。公称値どおりに 33B が首位に立ったのは日本語文化ベンチだけで、コーディングベンチでは最下位に沈みました。

以下、全部の数字を出します。

先に結論

• llmbench 60問（en, 各5runs）: 8B が Combined 68.8 で1位、32B-A3B 67.7、33B 65.2。Resolved では 8B と 32B-A3B が 71.7%（43/60）で同率、33B だけ 68.3%（41/60）で一段下

• 日本語ネットカルチャー 24問（ja, 各3runs）: 33B が 58.3%（14/24）で圧勝、32B-A3B 37.5%、8B 29.2%。8B と 33B の差はちょうど2倍

• 33Bの日本語での強さは「知識量」ではない。 cul_knowledge は 32B-A3B と同じ 9/12。差がついたのは制約付き生成（3/6 対 0/6）と穴埋め（2/6 対 0/6）、つまり指示への追従力

• 33B は patch parse失敗が6件と3機種で突出（8B=2件、32B-A3B=4件）。実装力ではなく出力フォーマットの追従で損をしている（自信度: MODERATE）

• upstream の llama.cpp では全く動かなかった。 llm-jp 公式 fork をビルドして初めて動いた。これは公式モデルカードの注意書きどおり

• コーディング用途で他モデルと並べると、Qwen3.8-27B-Unleashed Q6_K の 95.0%、Ornith-1.5-35B-A3B Q5_K_M の 90.0% に対して llm-jp-4 は 71.7%。明確に一段下（条件差の留保あり）

• 日本語24問ベンチが測っているのはネットスラング・ミームの記憶量だけで、日本語の一般運用能力ではありません。 ここは誤読されると困るので、独立した見出しを立てて書きます

llm-jp-4 という3兄弟の素性

すべて公式モデルカード・公式リリースからの引用です（確度: HIGH）。

アーキテクチャの比較です。

細かいところですが、「A3B」を名乗っているのに活性化パラメータは 3.0B ではなく 3.83B です。3.0Bだと思って速度やVRAMを見積もると2割ぶんずれます。

もうひとつ目を引くのが日本語比率。コーパス総計19.5兆のうち日本語は約7,000億トークン、全体の約3.6%程度です。「国産LLM」という看板から想像するより、ずっと英語寄りのデータで学習されている。これは後半の結果を読むときに効いてきます。

公称ベンチ値（モデルカード掲載値）

ここは筆者の実測ではありません。 公式モデルカードに載っている値の再掲で、実測表とは混ぜません。

まず注意点として、モデルカードにあるのは llm-jp-judge の4指標だけです。llm-jp-eval・JHumanEval・HumanEval・GPQA・MATH・AIME といった数値は公開されていません。コーディング性能の公称値は存在しないので、この記事で扱うコーディングスコアは全部筆者の実測です。

評価者 gpt-5.4-2026-03-05、3回推論の平均。Q4_K_M（medium effort）版の公式スコアが公式GGUFリポジトリに載っているので、そちらを引きます（筆者の検証も Q4_K_M なので条件が近い）。

BF16版でも 33B の MT-Bench JA は 8.00 なので、Q4_K_M でもほぼ劣化していないと公式データ自身が言っています。参考までに、BF16版の表には GPT-4o が MT-Bench JA 7.29、Qwen3-8B が 7.14 という比較対象も並んでいます（こちらはBF16表の数字で、上のQ4_K_M表とは別の表です）。

序列はこうなります。

• Q4_K_M（上の表）: 33B 8.02 > 8B 7.57 > 32B-A3B 7.51

• BF16: 33B 8.00 > 32B-A3B 7.82 > 8B 7.54

精度をどちらに揃えても、公称値では 33B がトップです。 2位と3位は入れ替わるので、そこは断定しません。頭に入れておいてほしいのは「公称では33Bが一番上」という1点だけで、筆者のコーディングベンチはこれを再現しませんでした。

本家 llama.cpp では動かなかった

先に実用情報を書いておきます。これから試す人がいちばん引っかかるところです。

upstream（ggml-org/llama.cpp）では、llm-jp-4 は全く動きませんでした。 筆者の実測です。ビルド済みの本家バイナリに公式GGUFを食わせても、チャットのパースが通らない。

公式モデルカードにはこう書いてあります。

この注意書きは額面どおり本当でした。トークナイザ処理の修正が upstream に取り込まれていないためです。

• fork: https://github.com/llm-jp/llama.cpp

• これを別ディレクトリでビルドして、そのバイナリで起動する

• 実行時に `--jinja` が必須

筆者の環境では `/home/zephel01/llm/apps/llama-llmjp/build/bin/llama-server` として本家とは別に置いています。既存の llama.cpp を上書きする必要はないので、fork を並べて置くのがおすすめです。

「試そうとしたけど本家で動かなかったので諦めた」という人がそれなりにいるはずで、その人たちに向けて一行で言うと、モデルが悪いのではなく fork が要るだけです。

検証環境

• 実行環境: llama.cpp（CUDAビルド）／ llm-jp 公式 fork

• ハードウェア: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S（32コア）／ メモリ 31.0GB

• GPU: NVIDIA RTX 3090（24.0GB）+ NVIDIA RTX 5090（31.8GB）の2枚に分割ロード／ driver 610.43.02 / CUDA 13.3

• OS: Linux 7.0.0-29-generic x86_64 / Python 3.12.3

• 量子化: 全モデル Q4_K_M（公式GGUF）／ GPUオフロード `-ngl 99` ／ コンテキスト長 8,192 tok ／ 並列スロット 4

• タスク数（第1段）: 60問（easy 5 / medium 5 / hard 10 / expert 12 / frontier 8 / architect 20）、Issue言語 en、各タスク5回

• タスク数（第2段）: 24問（cul_knowledge 12 / cul_completion 6 / cul_generation 6）、Issue言語 ja、各タスク3回

• サンプリング: temperature 0.35 / top_p 0.95 / top_k 20 / min_p 0.0 / seed 42（固定） / max_tokens 49152

• 評価軸: Resolved率 / 成功率（平均）/ pass@k / Quality / Combined / usability

• tok/s の測定条件: 並列スロット4で走らせたときの、各タスクの中央値。単発実行時の1ストリーム速度ではありません

起動コマンドはこれです。

./build/bin/llama-server --model <model>.gguf --jinja --reasoning-format none -ngl 99 -c 8192 --port 8085

サンプリングについて、先に正直に書いておきます。llm-jp公式は推奨サンプリング値を公開していません。 モデルカード、`generation_config.json`、cookbook、GGUF README のいずれにも記載がない、というのを確認しました。なので上の値は筆者が横断比較用に使っている固定条件であって、公式推奨と一致するとは書けません。参考として、第三者のハンズオン記事（bluecore.net）は temp 0.7 / top_p 0.95 / top_k 20 / min_p 0.0 を使っていて、top_p と top_k は筆者と一致、temperature だけ違います。

もうひとつ、seed を 42 で固定しているので、5runs / 3runs の各試行が完全に独立かというと疑いが残ります。ここは後半の「誠実な留保」でもう一度触れます。

llmbench の定義も再掲しておきます。

• SWE-Bench風の自作ベンチ。バグレポート＋ソースをLLMに渡し、patch適用 → 隠しpytest（LLMには非公開）で resolved 判定

• Combined = 成功率 ×（0.5 + 0.5 × Quality/100）× 100（動かないコードは0点）

• Quality は lint密度 + 保守性指標 + 別LLMレビューの重み付き合成

• usability: 🟢自律（レビューほぼ不要）/ 🟡補助（レビュー前提なら任せられる）/ 🔴不可

• GitHub: `zephel01/swe-bench`（MIT）。stdlib-only で再現可能

第1段: llmbench 60タスク × 5runs（コーディング）

英語のバグ修正・実装タスク60問を、各5回ずつ回しました。300実行×3モデルです。

結論: 総合1位は 8B。VRAM 7.1GB のモデルが 21.9GB の 33B を Combined で 3.6pt 上回り、公称値でトップだった 33B がこのベンチでは最下位に落ちた。

数字の読み方をいくつか。

Resolved は 8B と 32B-A3B が同率 71.7%（43/60）。 完全に並んでいます。Combined で 8B が上に出たのは、成功率（73.3% 対 71.7%）と pass@k（83.3% 対 80.0%）で微差を積んだからで、Quality だけ見れば 32B-A3B のほうが上（89.0 対 87.6）です。この 1.1pt 差で「8Bのほうが賢い」とは言いません。

言えるのは、**「パラメータ数が4倍あっても、このベンチでは1問も多く解けていない」**という事実のほうです。

33B は 41/60 で2問ぶん下。 3.4pt 差なので単独で見れば誤差に近い。ただし成功率・pass@k・Combined の3指標すべてで一貫して最下位なので、「たまたま下振れした」とも言いにくい。落ち方に理由がありそうなので、次のセクションで分解します。

pass@k（5回中1回でも成功）と Resolved の差も見どころ。8B は 83.3% 対 71.7% で 11.6pt の開きがあり、「1回は解けるが安定しない」問題が7問ぶんある計算です。1回成功と安定して解けるは別物で、その差がいちばん大きく出たのが 8B でした。

8Bが33Bに勝った、をどう読むか

33B の失敗19件を理由別に割ると、こうなります。

`patch parse失敗` は、実装の是非以前の問題です。ハーネスが指定した file ブロック形式でパッチが出てこないので、テストを走らせるところまで行けない。中身が正しかろうが間違っていようが、0点になります。

33B だけがここで6件。8B の3倍です。

裏返すと、`tests failed`（＝ちゃんとパッチは出したが、隠しpytestが通らなかった）は 33B が7件で3機種中いちばん少ない。つまり、33B は「実装を試みた問題」に限れば取りこぼしが少なく、そもそも土俵に上がれなかった回数が多いという構図です。

この読み方が正しければ、33B のコーディングスコアが低い主因は実装力ではなく出力フォーマットへの追従力ということになります（自信度: MODERATE）。断定しないのは、6件対2件という差が試行のばらつきの幅を超えているかを、この1回の検証では切り分けられないからです。

ややこしいのは、日本語ベンチのほうで 33B が制約付き生成（文字数・行数・必須語の指定）で唯一まともに点を取ったモデルだったこと。指示追従が一律に弱いなら、そこも落ちるはずです。日本語の細かい指示には追従できるのに、英語のパッチ出力フォーマットでは崩れる。 この切り分けは今回のデータからはできないので、次の宿題にします。

Quality は 33B と 32B-A3B が 89.0 で並び、8B は 87.6。解けたコードの綺麗さでは、大きいモデルがきちんと上に出ています。「解ける数」と「書くコードの質」が別方向を向いた例です。

難易度別: どの帯で差がついたか

60問を難易度tierに割ります。

きれいに割れませんでした。帯ごとに勝者が違います。

• hard（10問）で 8B が 8/10 と抜けた。 32B-A3B は 5/10 で、ここだけで3問差。8B が総合1位になった直接の原因はこの帯です

• frontier（8問）は逆に 8B が 3/8 で最下位。 hard で勝ち、frontier で負ける。難易度が上がるほど強い/弱いという単調な関係になっていません

• easy を落としたのは 8B だけ（4/5）、medium を落としたのは 33B だけ（4/5）。上位帯を解くモデルが下位帯を落とすのは、この連載ではおなじみの光景です

• architect 20問は 12 / 13 / 11 と横並び。 60問中の3分の1を占める最大の帯がほぼ同点なので、ここでは序列がつきませんでした

frontier 8問で最高が 5/8 というのはかなり厳しい数字です。Qwen3.8-27B や Ornith-1.5-35B を叩いたときと比べると、上位帯の壁が明確に厚い。

第2段: 日本語ネットカルチャー 24問 × 3runs

ここからベンチを変えます。日本語のネットスラング・ミーム知識を問う自作24問を、各3回ずつ。

結論: 33B が 58.3% で圧勝。8B の 29.2% とはちょうど2倍の開きで、コーディングベンチの序列が完全に裏返った。

表の見方をひとつ補足します。Quality が3機種とも 100.0 なのは、このベンチが正誤の二値判定だからです。コードの綺麗さを測る余地がないので、Quality係数が常に 1.0 になり、結果として Combined = 成功率 になります。llmbench のような Quality での差別化はここでは起きません。

もうひとつ細かい点。32B-A3B だけ、成功率（40.3%）が Resolved（37.5%）を上回っています。 3回のうち一部だけ通る問題があるということで、pass@k も 45.8% と Resolved から 8.3pt 開いている。3機種の中でいちばん run 間のばらつきが大きい（3runsなので幅の見積もりとしては心もとない。自信度: MODERATE）。

カテゴリ別に割ると、33B の勝因がはっきり出ます。

知識問題では 32B-A3B と 33B が 9/12 で同点です。 33B が余分に取った5問は、全部 completion（2問）と generation（3問）から来ている。

つまり、33B が日本語ベンチで勝った理由は「ネットミームをよく知っているから」ではありません。 知識量では 32B-A3B と互角。差がついたのは、「140字以内で」「3行で」「この語を必ず含めて」という制約を守りながら書けるかどうかでした。

そして裏を返すと、制約付き生成は3機種そろって鬼門です。8B が 0/6、32B-A3B が 0/6。33B の 3/6 が唯一「半分は書けている」水準で、あとの2機種は全滅。知識を持っていても、要求された形で出せない。第1段の patch parse失敗と同じ話が、言語を変えて出てきています。

序列が真逆になった

2つのベンチを並べます。

1位と3位が入れ替わっています。 しかも中間の 32B-A3B は両方とも2位（またはResolved同率1位）で動かない。両端だけがひっくり返った形です。

公称値と突き合わせると、こうなります。

• 公称 MT-Bench JA（Q4_K_M）: 33B 8.02 > 8B 7.57 > 32B-A3B 7.51

• 筆者の日本語ベンチ: 33B > 32B-A3B > 8B ← 33Bがトップという点は一致

• 筆者のコーディングベンチ: 8B > 32B-A3B > 33B ← 公称値と逆

公称値どおり 33B が首位に立ったのは日本語側だけで、コーディング側は再現しませんでした。これは驚くことではなくて、モデルカードにコーディング性能の公称値がそもそも存在しないからです。llm-jp-judge の4指標（MT-Bench JA/EN、AnswerCarefully、llm-jp-instructions）は、コード生成を測る指標ではない。

言い換えると、このモデルシリーズは公式が測っていない土俵で使うと、公式が示した序列は当てにならない。それだけの話です。ベンチが1本しかないときに「このモデルはこの順で強い」と結論を書くのは危ない、という実例が取れました。

このベンチが測っていないもの（重要な留保）

ここは強調して書きます。誤読されると記事の意味が反転するところです。

第2段で使った24問は、ネットスラングとミームの知識に限定したベンチです。淫夢語録、2ちゃんねる用語、なんJ語、空耳、ゲームの有名台詞。それだけです。

この24問は、以下を一切測っていません。

• 読解（長文を読んで質問に答える）

• 要約

• 敬語・ビジネス文書の作成

• 翻訳

• 事実に基づく日本語QA

• 日本の法令・制度・地名などの知識

つまり、「llm-jp-4-33B は日本語が得意」という結論をこの記事の第2段から引き出すことはできません。 ここで測れたのは「日本語ネット文化の記憶量と、その文脈で制約を守って書けるか」だけです。

llm-jp-4 は日本語対応を看板にしたモデルですし、公称の MT-Bench JA も高い。でもそれを裏付けたのは公式のスコアであって、筆者の24問ではありません。 筆者が測ったのは、日本語能力のうち相当に偏った一部分です。

逆に、この偏りがあるからこそ見えたこともあります。ネットミーム知識は学習コーパスの「日本語 約7,000億トークン（全体の3.6%）」の中でもさらに周縁にある情報です。そこで 8B が 7/24 しか取れず 33B が 14/24 取れたのは、モデルサイズを上げたときに真っ先に増えるのが「薄く広い知識」だという教科書どおりの現象が、素直に出たと読めます（自信度: MODERATE）。

一般的な日本語運用能力の比較は、別のベンチを組んで別記事でやります。

失敗の分解

英語側の内訳は前掲（tests failed / patch parse失敗 / flaky）のとおりです。日本語側はこうなりました。

日本語側で目を引くのは制約違反の列です。8B が6件、32B-A3B が5件に対して 33B は2件。ここが 33B の勝ち分そのままです。

そして両ベンチを重ねると、同じ弱点が言語をまたいで出ているのが分かります。

• 英語コーディング: 「file ブロック形式で出せ」→ 落ちる（patch parse失敗）

• 日本語生成: 「140字以内・必須語を含めて出せ」→ 落ちる（制約違反）

llm-jp-4 の3機種に共通する最大のロスは、知識でも実装力でもなく「指定された形で出す」ところです。ただし内訳を見ると、33B は日本語側の制約違反が最少（2件）なのに英語側の patch parse失敗が最多（6件）で、言語によって崩れ方が逆になっている。単一の「フォーマット追従力」という説明では収まりません（自信度: LOW）。

ほかに2点、細かい記録を残しておきます。

• 拒否（refused）は全モデル・全ベンチで0件。 ネットミームという題材なので拒否が出るかと思いましたが、一度も出ませんでした。日本語ベンチの c24（初心者向けに 114514 を解説する＝拒否耐性を見る問題）を 8B と 32B-A3B が落としているのも、拒否ではなく要件未達です

• 打ち切り（truncated）は 8B_ja が3件、33B_en が1件、あとは0件。 8B が日本語側で3回だけ生成を打ち切られています。コンテキスト 8,192 の中で thinking が伸びた可能性はありますが、この検証からは特定できません（自信度: LOW）

鬼門の系譜

このシリーズの定番、全機種が揃って落とした問題です。

llmbench 60問（en）の共通鬼門 8件

architect が4件、frontier が2件。t044・t046・t059 は過去記事でも常連で、Ox Alpha Free（2026-08-23記事）も t044・t046 を落としています。イベント再生の二重計上、DIコンテナのライフタイム管理、浮動小数点の累積誤差——設計の一貫性を最後まで保つ種類の問題が、規模やベンダを問わず落ちます。

機種別の独自失敗も見ておきます。

• 8Bだけが落とした（5件）: t002 / t039 / t040 / t056 / t058

• 32B-A3Bだけが落とした（7件）: t012 / t015 / t017 / t025 / t032 / t037 / t045

• 33Bだけが落とした（9件）: t006 / t016 / t018 / t030 / t038 / t041 / t050 / t054 / t057

33B の独自失敗9件が最多で、しかも t057（CSV方言パーサ）が入っているのが目を引きました。t057 は Qwen3.8-27B-Unleashed が3量子化そろって空出力で落とし、Ox Alpha Free では「中身は正しいのにファイル名の規約を守れず弾かれた」という、この連載の分水嶺タスクです。

ただし 33B の t057 の失敗理由は `tests failed` でした。パッチは出したうえで隠しpytestに落ちている。つまり過去2記事の「黙る」「規約で弾かれる」とは別の落ち方です。同じ壁に見えて中身が違う可能性があるので、系譜として並べるのはここまでにしておきます（自信度: LOW）。

日本語24問の共通鬼門 10件

c01 / c08 / c11 / c13 / c14 / c15 / c17 / c21 / c22 / c23

24問中10問が全滅です。傾向がはっきり出ています。

• c01（114514の語呂合わせ）・c14（114514の読み下し）・c15（810が指す語）: 数字を語に読み下す変換。全滅。ただし c04（1919810の語呂合わせ）は3機種とも正解しています。同じ系統なのに片方だけ落ちるのは面白い

• c08（香具師の意味）・c11（オンドゥル語）・c17（オンドゥル語の翻訳）: 表記の崩しを元に戻す問題。全滅

• c13（「いいよ！____！」の穴埋め）: 定型句の穴埋め。全滅

• c21・c22・c23（なんJ風実況、語録で日常をネタに、2ch風スレッド）: 制約付き生成。全滅

c21〜c23 が3機種そろって落ちているのが「制約付き生成が弱い」の実体です。33B ですら c19 / c20 / c24 の3問しか取れていない。逆に 33B だけが解けた4問は c18 / c19 / c20 / c24 で、全部 completion か generation。ここでも 33B の優位が知識ではなく生成側にあると確認できます。

3機種そろって正解したのは c02（野獣先輩）、c04（1919810）、c05（真夏の夜の淫夢）、c06（こ↑こ↓）、c07（ぬるぽへの定型レス）、c12（そんな装備で大丈夫か？）。有名度が高く、テキストとして頻出する語は 8B でも取れています。

usability: 実際どれくらい任せられるか

スコアではなく「任せられるか」で分けた表です。🟢自律＝レビューほぼ不要、🟡補助＝レビュー前提なら任せられる、🔴不可＝任せられない。

llmbench 60問（en）

日本語ネット文化 24問（ja）

コーディング側は 3機種とも 🟢自律が 55〜62% で、5〜6割は投げっぱなしにできるが、3割前後は何をやっても通らないという形。🟡補助が 10〜13% しかないのが特徴で、中間がほとんどありません。通るか通らないかがはっきり分かれる。

日本語側は 8B の 🔴不可 71% がきつい。4問に3問は使えないので、この用途で 8B を選ぶ理由はありません。33B でも 🔴不可 42% です。

速度とVRAM

32B-A3B が最速で ~244.6 tok/s、33B が ~49.4 tok/s。約5倍の開きです。60問を1周する実時間で言うと、4.0分 対 24.6分。実際は5runsなので、この差が5倍になって効いてきます。

ここで毎回書いているtok/s の読み方3点セットを挟みます。

1. MTP（投機的デコード）搭載モデルは構造的に速い数字が出る。 賢さの証明ではありません

2. MoE は活性化パラメータが小さいので速い。 32B-A3B は総パラメータ 32B でも、実際に読み出しているのは 3.83B 分だけです。~244.6 tok/s は「32Bが速い」のではなく「実質3.83Bだから速い」

3. dense標準版は素直に遅い。 33B の ~49.4 tok/s は、64層・hidden 5,120 を全部通しているぶんの正直な数字です。遅い＝劣っている、ではありません

そして今回いちばん効く注意書きがこれです。

筆者の環境は RTX 3090 + RTX 5090 の2枚に分割ロードしていて、しかも並列スロット4で走らせています。 8B が GPU0 3.4GB + GPU1 3.7GB、32B-A3B が 9.2 + 12.5GB、33B が 9.5 + 12.4GB。2枚に分けている以上、単体GPUでの測定値と同一視できません。 並列4での値なので、1本だけ流したときの体感速度とも一致しません。 特に dense の 33B は層をまたぐ通信が効くはずで、単体の 32GB カードに全部載せたらこの数字より速い可能性があります。33B の ~49.4 tok/s を「このモデルの速度」として持ち帰らないでください。

VRAM だけ見ると、8B の 7.1GB は 8GBカードに載るサイズです。GGUFファイル自体は 5.30GB（5,304,882,240 bytes）。8GB VRAM で Resolved 71.7% を出しているという事実は、次の横断比較で効いてきます。

他モデルと並べるとどこにいるか

同じ llmbench 60問（en）で過去に測ったモデルと並べます。

条件差の留保を先に。 同じ llmbench 60問（en）ですが、サンプリング設定と実行時期が違います。Qwen3.8-27B-Unleashed（2026-08-22記事）は公式推奨サンプリングで回していて、llm-jp-4 は公式推奨が存在しないため筆者の固定条件です。Ornith-1.5（2026-08-20記事）もサンプリング条件に留保が付いています。厳密な同条件比較ではありません。

その上で、正直に書きます。

コーディング用途では、llm-jp-4 は明確に一段下です。

• トップの Qwen3.8-27B-Unleashed Q6_K が 95.0% なのに対し、llm-jp-4 の最良は 71.7%。23.3pt の差

• 同じ MoE の Ornith-1.5-35B-A3B Q5_K_M が 90.0%、llm-jp-4-32B-A3B が 71.7%。18.3pt の差。tok/s はどちらも ~245 でほぼ同じなので、同じ速度帯で 18pt 負けている

• VRAM 8GB級の直接比較が痛い。Ornith-1.5-9B Q5_K_M（8.1GB）が 83.3% に対して llm-jp-4-8B（7.1GB）が 71.7%。同じ量子化に揃えた Ornith-1.5-9B Q4_K_M（7.5GB）が 70.0% なので、Q4_K_M 同士なら 1.7pt 上（＝ほぼ互角）

最後の点だけ、少し 8B に有利に読めます。Q4_K_M で揃えれば 8GB級では互角。ただし 1.7pt は1問ぶんなので、±3pt級の差では優劣を断定しないという連載のルールどおり、互角と書くのが限界です。

そして忘れてはいけないのが、この比較は全部コーディングベンチの話だということ。llm-jp-4 は公式がコーディング性能を公称していないモデルで、**コード学習量はコーパス19.5兆のうち約2,000億トークン（約1%）**です。コード特化モデルと殴り合わせて負けたからといって、モデルとして劣っているという話にはなりません。土俵が違います。

日本語文脈での第三者評価も置いておきます（確度: MODERATE、いずれも筆者の一次検証ではありません）。

• 日本語トークナイザの効率が高いという報告。bluecore.net が28万件規模で検証し、Qwen3.5比で 70.6%のケースで少ないトークン数、計約1,500万トークンの削減になったとしています。同じ記事は「存在しない参考URLをハルシネーションする」弱点も併せて報告 — https://www.bluecore.net/archives/762

• note/おーら氏の20問検証（LM Studio）では、Qwen3系が実在しない商品名を捏造するのに対し LLM-jp-4 は実在する日本の固有名詞・難読地名で明確に優位。「ベンチスコアは低くても国内業務では実用的」という評価 — https://note.com/ai_0049/n/n4f569be9ed8b （※量子化条件が不揃いで厳密比較ではありません）

トークナイザ効率が高いというのは、同じ内容を少ないトークンで扱える＝実質的なコンテキスト長で得をするということです。今回は測っていません（末尾の「次の宿題」に入れました）。

誠実な留保

この記事の数字を持ち帰る前に読んでほしい5点です。

1. サンプリングが公式推奨ではありません。 llm-jp公式は推奨値を公開していません（モデルカード・generation_config.json・cookbook・GGUF README を確認済み）。本検証の temp 0.35 / top_p 0.95 / top_k 20 / min_p 0.0 は、筆者が横断比較のために使っている固定条件です。公式推奨で回せばスコアが変わる可能性があります。 さらに seed を 42 で固定しているので、5runs / 3runs の各試行の独立性にも疑いが残ります。「5回まわしたから安定した推定値」と言い切るには弱い。

2. 日本語24問はネットミーム限定のベンチです。 読解・要約・敬語・翻訳・ビジネス文書は測っていません。大事なので再掲します。

3. 8B と 32B-A3B は Resolved 同率 71.7%。 Combined の 1.1pt 差で優劣を断定しません。±3pt級の差は運の範囲として扱います。33B との 3.4pt 差も単独では誤差に近い。3指標が一貫して同じ向きだったので言及していますが、断定はしていません。

4. RTX 3090 + RTX 5090 の2枚に分割ロードしています。 tok/s を単体GPUの測定値と同一視できません。特に dense の 33B は不利側に振れている可能性があります。

5. reasoning_effort を明示指定していません。 thinking版には low / medium / high の3段階がありますが、本検証は `--reasoning-format none` で既定のまま回しました（medium相当と推定）。公式GGUFカードには 「high は medium からほぼ改善しない」という記載がありますが、low / medium / high の切り分けは本検証ではやっていません。宿題です。

で、どれを選ぶか

用途別に1行ずつ言い切ります。

• 日本語のネット文化・口語・くだけた生成を扱いたいなら 33B。 58.3% 対 29.2% は誤差ではありません。ただし ~49.4 tok/s と VRAM 21.9GB を払う覚悟が要ります

• コーディングに使いたいなら、llm-jp-4 は選ばない。 同じVRAM帯に 90% 級のモデルがいます。llm-jp-4 の 71.7% を選ぶ理由がコーディング用途にはありません

• 8GB VRAM で日本語も少し混ざる雑用をやらせたいなら 8B。 Q4_K_M で 7.1GB、コーディング 71.7% は 8GB級として妥当な水準。ただし日本語のくだけた生成は 🔴不可 71% なので期待しない

• 32B-A3B は「速い33B」ではありません。 tok/s は ~244.6 と 5倍速いですが、日本語では 33B に 20.8pt 負ける。速度が最優先で、日本語ミーム知識が要らないときの選択肢です

• VRAM が 22GB あって迷うなら 33B。 コーディングで 32B-A3B に負ける幅（Combined 2.5pt）より、日本語で勝つ幅（20.8pt）のほうがずっと大きい

Apache 2.0 で商用利用可、スクラッチ学習の国産モデルという価値は、スコア表には出てきません。研究用途や、日本語コーパスの素性が追える必要がある案件では、スコアだけで判断すべきではないと思います。モデルカード自身が「early stages of our research and development」「人間の意図・安全性への調整は未実施」と書いている段階のモデルです。

教訓

• ベンチ1本で序列を書くと事故る。 同じ3兄弟が、ベンチを変えただけで1位と3位を入れ替えました。公称値ですら、測っていない土俵では当てになりません

• パラメータ数は解決力の保証にならない。 VRAM 7.1GB の 8B が 21.9GB の 33B に Combined で勝ちました。ただしこれは「8Bのほうが賢い」ではなく「このベンチでは差が出なかった／別の要因で 33B が損をした」と読むべきです

• 知識量と指示追従は別の能力。 33B の日本語での勝因は知識ではありませんでした（知識問題は 32B-A3B と同点）。差がついたのは制約を守って書く力です

• 「出す形」で落とす損は、想像より大きい。 33B は patch parse失敗6件、日本語側は制約付き生成が3機種で 3/6・0/6・0/6。中身の前に形で0点になるというのが、このモデル群の最大のロス源でした

• 公式が推奨サンプリングを出していないモデルは、比較の土台が一段弱い。 数字を出す側は、そのことを明記する義務があると思っています

次の宿題

• reasoning_effort を low / medium / high で切り分ける。 公式は「high は medium からほぼ改善しない」と言っていますが、コーディングベンチでもそうなのかは未確認です

• seed を振って回し直す。 seed 42 固定のままだと 5runs の独立性が担保できません。seed を変えた5runs で pass@k がどう動くかを見たい

• 一般的な日本語能力を測るベンチを組む。 読解・要約・敬語・翻訳。今回の24問では手つかずの領域です。国産LLMの評価としては、むしろこちらが本丸

• 33B を単体GPUに載せて tok/s を測り直す。 2枚分割の ~49.4 tok/s は 33B に不利な可能性があります

• トークナイザ効率を自分で測る。 「Qwen3.5比で 70.6% のケースで少ないトークン」という第三者報告を、自分のベンチのログで検算できるはずです

• 33B の patch parse失敗6件（t014 / t016 / t018 / t033 / t034 ＋ medium の t006）の生出力を開く。 「中身はあるのに形で弾かれた」のか「本当に何も出ていない」のかで、33B の評価が変わります。t006 だけ `unknown/unsafe paths` と理由が違うのも気になっています

検証で生成したコード・テスト結果はアーカイブ済みです。「特定タスクの詳細が見たい」「自分の環境でも試したい」はコメントへどうぞ。特に、本家 llama.cpp で動かなくて諦めた人には fork の話だけでも持ち帰ってもらえたら嬉しいです。あと、reasoning_effort を high にしたら 33B のコーディングが変わったという人がいたら、ぜひ教えてください。

モデル情報

• HuggingFace（本体）

  • https://huggingface.co/llm-jp/llm-jp-4-8b-thinking

  • https://huggingface.co/llm-jp/llm-jp-4-32b-a3b-thinking

  • https://huggingface.co/llm-jp/llm-jp-4-33b-thinking

• HuggingFace（公式GGUF。サードパーティ製ではありません）

  • https://huggingface.co/llm-jp/llm-jp-4-8b-thinking-gguf

  • https://huggingface.co/llm-jp/llm-jp-4-32b-a3b-thinking-gguf

  • https://huggingface.co/llm-jp/llm-jp-4-33b-thinking-gguf （33B Q4_K_M = 20.2GB、BF16 = 66.4GB）

• llama.cpp fork（必須）: https://github.com/llm-jp/llama.cpp

• cookbook: https://github.com/llm-jp/llm-jp-4-cookbook

• 評価ツール llm-jp-judge: https://github.com/llm-jp/llm-jp-judge

• ベース: 8B = Dense 約8.59B / 32B-A3B = MoE 32.1B（活性化 3.83B・128 routed / 8 activated）/ 33B = Dense 33.2B

• ライセンス: Apache License 2.0（商用利用可）

• 推奨サンプリング: 公式は非公開（本記事は筆者の固定条件 temp 0.35 / top_p 0.95 / top_k 20 / min_p 0.0 / seed 42）

• 公式リリース: https://www.nii.ac.jp/news/release/2026/0403.html / https://www.nii.ac.jp/news/2026/0818.html / https://llm-jp.nii.ac.jp/news/20260818/

• ベンチマーク: 自作 `llmbench`（github.com/zephel01/swe-bench、MIT）

関連記事

• 2026-08-22「Qwen3.8-27B-Unleashedを量子化3段階で叩いたら、architect帯だけ壁が動いた」（本記事の横断比較データの出典。t057・t044・t046 の系譜もここ）

• 2026-08-20「Ornith-1.5-9B は Q5_K_M で 83.3%、Q6_K で 75.0%。量子化が動かしたのは「賢さ」ではなく「出力の安定性」だった（60問×5回・6ラン）」（9B/35B-A3B の横断比較データの出典）

• 2026-08-23「名前を隠したステルスモデル「Ox Alpha Free」を60問+L7で叩いたら、「解く数は平凡・書くコードは上位」という珍しいプロファイルが出た」（t044/t046/t057 の鬼門の系譜）

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #llmjp #国産LLM #MoE #NII #日本語LLM