llm-jp-4-33b-thinkingに触れてみる

llm-jp-4というモデルを再び取り上げる

以前、llm-jp-4のアーキテクチャという記事やアーキテクチャの違いで何が変わるのか？などで紹介したこともあって、これからちゃんと調べよと思いますなどと言いながら、気づいたら結構長い時間がたってたので、この記事を書くことにしました。なんと、新しくllm-jp-4-33bなんぞも出てるではないですか。今回はその辺りも含めて改めての紹介にしたいと思います。

llm-jp-4モデルシリーズ

llm-jpが提供するモデルの最新世代である llm-jp-4ですが、以下のモデルが存在します。

llm-jp-4-33b-thinking
llm-jp-4-32b-a3b-thinking
llm-jp-4-8b-thinking

従来のモデルと比較して長いコンテキストに対応しており、その長さは64kとなっていて、ついにここまで長くなったかという印象であるとともに、世界のモデルと比較するとやっぱり少ない印象があります。

また、今回からThinkingと書かれてるように、Reasoning処理を行うモデルになりました。

アーキテクチャは、Denseタイプのモデルである 8b, 33bモデルはLLaMa-2をベースにしており、MoEタイプのモデルである32b-a3bモデルはQwen3のアーキテクチャをベースにしているようでした。

図 1 llm-jp-4-8b/33b-thinkingのアーキテクチャ

2026年4月にリリースされた8b,32b-a3bモデルは32層構造、8月にリリースされた33bモデルは64層構造です。

学習方法

学習過程は以下のように定義されているそうで、64kのコンテキストを処理できるようにしているのは以下の中間学習の段階であるとのこと。その後SFT/DPOの中で比較的長い文字列長のデータも見受けられましたので、そこで学習が行われているのだろうと考えられます。

図 2 llm-jp-4-8b/32b-a3b-thinkingの学習過程

事前学習・中間学習については以下のように長さ・学習率設定を変更させながら実行しているとのことで、その説明図を引用して以下示します。

図 3 llm-jp-4-8b-think リポジトリから引用

推論させてみる

llama.cpp で動かしてみる

このllm-jp-4モデルですが、llm-jp自身がリリースしているGGUFファイルを使用する場合は、独自トークナイザ及びHarmonyを用いたパーサー等の仕組みのせいなのか、llm-jp側で修正をかけたリポジトリ(https://github.com/llm-jp/llama.cpp)から入手する必要があります。これに倣い、当方もそのllama.cppをダウンロードして実行させます。

■ソースを入手
git clone https://github.com/llm-jp/llama.cpp

■cmakeでビルド（以下は私の環境で入力したコマンドですので、参考として扱ってください）
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=”86″ \
-DCMAKE_CUDA_COMPILER=/usr/local/cuda-13/bin/nvcc

cmake –build build –config Release -j 26

■バージョン確認
version: 9376 (26b0e874a)
built with GNU 13.3.0 for Linux x86_64

実行コマンドは以下の通りとしています。

/opt/llama-llm-jp/bin/llama-server \
–model /opt/llama/models/llm-jp-4-33b-thinking-IQ3_XXS.gguf -t 20 -np 1 –prio 2 \
　–temp 0.7 –top-p 0.95 –top-k 20 –min-p 0.00 –host 0.0.0.0 –port 8052 \
　–device CUDA0,CUDA1 -mg 0 -ctv q8_0 -ctk q8_0 –fit off –no-warmup \
　–no-cache-prompt -fa on –cache-ram 0 -c 32768 –log-verbosity 4 \

今回使用したGGUFファイルは以下のリポジトリからいただいております。純正のGGUFもリリースされてはいるのですが、Q4_K_Mしかなく、当方の環境では動かせないため、こちらの3bit量子化モデルを使わせていただいております。（これもカスタマイズ版llama.cppが必要です）

mmnga-o/llm-jp-4-33b-thinking-gguf – Hugging Face

なお、現在最新の純正llama.cppを使うと以下のようなことが起きます。なので、自前でGGUF化したものでない場合は。

ログに思いきり全文が出力され、Webフロントエンドにはなにも出力されずServer Errorとして処理される（GGUF側のchat-template定義を読み取らない）
chat-templateを読み込もうとすると、そのテンプレートの中に書かれているものがそのまま出力されている（ように見える。）

メモリ消費量は非常に大きいです。これは昨今の流行とは異なりLLaMa-2をベースアーキテクチャとしているためです。念のためにQwen3.8-27Bとメモリ消費量の違いについて横に並べて確認してみました。

表 1 メモリ消費量比較

量子化レベルはいずれも Q3_K_XXSですが、コンテキストサイズはllm-jp-4側が32k、Qwen3.8側が64kとなっています。つまりは、llm-jpで最大コンテキストサイズ64kを適用するにはおよそ8GiBちょっとのVRAMが必要になりますし、そこから先のKVキャッシュの量子化を16bitに戻すと16GiB以上のVRAMが必要になるということを示しています。

KVキャッシュの容量がかさんだ原因は全ての層でGQAが構成されていること、層が厚く、64層構成されていることです。GQAは非常に高性能ですが、すべての層がGQAとなるとそれだけKVキャッシュ容量が必要であるということです。Qwen側でも計算バッファ量が大きくとられるので見た感じではあまり差がないように見えますが、コンテキスト長を広げると一気に形勢逆転します。

ただ、このこと自体はあまりモデル制作側としてはあまり問題視していないようで、それは次の段階で行うことという認識でいらっしゃる様です。確かにこの先のアーキテクチャを考えるとなるとさらに設計が必要になるわけで、計画的に進めているようですので、外野の私らが言うことではないのかなとも感じました。

まずはllama.cppのウェブインタフェースで実行すると、どうやら無事に推論できてそうです。

図 4 llama.cpp WebUIで遊ぶ

Difyを通して推論してみると、無事行えました。ちょっと熊本県南部と言うには天草と阿蘇山だけが対象になるのはさみしいな・・・とは思いつつも。ただ、Dify越しに動かす場合は残念ながらThinking区間の出力が見えません・・なぜかはわかりません。

図 5 Difyで推論させて遊ぶ

ここで気づいたのですが、私が使用しているWebappに設定している指示に対するトークン量は結構多くて、11,000 tokens ほどあります。それが見てみるとやたら少ない。

たった4,485 tokensなはずはないんですけど・・と言う所でふと気づいたのが「確かトークナイザが独自だったような」ということでした。

独自トークナイザとは？

llm-jpでは、アーキテクチャこそLLaMa-2だったりQwen3-MoEだったりを使っていますが、トークナイザは独自です。llm-jp-4のトークナイザはSentencepiece ライブラリを用いたLLaMa Tokenizerをベースとしています。ただそれを用いるわけではなく、その入力にHarmonyを使用、応答フォーマットは Harmony Response Formatを採用しているようです。

語彙の収集は独自に行っており、llm-jp-3のトークナイザと比較するとおよそ倍の196,608 語彙を収録しており、その言語は英日のみとなっているそうです。これはかなり割り切った仕様になっているとともに、その2か国語だけで196,608語彙収録しているということは、相当に多くの語彙を集中的に獲得しているわけで、各言語の表現力向上にかなり寄与するといえます。

過去に抽出したllm-jp-4のSFTデータをもとに28万件抽出したものがあるので、これを使ってllm-jp-4とQwen3.5のトークナイザそれぞれで処理したらどの程度トークンの値が変わってくるのかを調べました。

使用したデータセット一覧は以下の通りです。

データセットカテゴリ	件数
llmjp_extraction_wiki_ja_v0.1	30k
llmjp_extraction_wiki_ja_v0.2	60k
llmjp_extraction_wiki_ja_v0.3	60k
llmjp_magpie_sft_v1.0	10k
multiturn_calm3	60k
synthetic_jp_en_coding	60k
合計	280k

表 2 使用した実験用データセット

これのそれぞれのPrompt と completionのトークン量を数え、その値を合算したものをトークン量として計上しています。それぞれ計上したトークン量を横軸にケース番号、縦軸にトークン量とした散布図を作成し、これを重ね合わせて確認しました。それが下図です。

図 6 Qwen3.5トークナイザとトークン量を比較してみた（散布図）

ちょっと見づらいのですが、青い点がllm-jp-4で計測された各ケースのトークン量を示し、オレンジ色の点がQwen3.5のものになっています。青い点ばかりが並んでるわけでなく、そのうえでオレンジ色の点が浮き上がっています。これを見た時点でおそらくは全体的にQwenのほうがトークン量は多いのだろうと推察しました。

qwen3.5でのトークン量からllm-jp-4でのトークン量を引き、その値を並べて確認したのが以下の表です。

表 3 Qwen3.5トークナイザとトークン量比較をしてみた

llm-jp-4のほうが少なく済んだケースでその値が最も大きいのが 5,114トークン
qwen3.5のほうが少なく済んだケースでその値が最も大きいのが2,114トークン
llm-jp-4のほうが少なく済んでいるケースの方が多く、その比率は70.6 %
全体として、これらのプロンプトを総なめした場合、llm-jp-4のほうがおよそ15Mトークン程度の節約が見込める

という結果になりました。よりトークン数が少ないということは、トークン処理の回数が少ないことを意味しており、KVキャッシュも軽減されますし、表現も豊かになります。

今回このトークナイザの性能が向上したというのは非常に大きな意味を持つんじゃないかと思います。

出力した内容を見てみる

出力結果（九州の地盤の特徴）は以下の通り出力されました。

九州の地盤の特徴

1. 地理的背景

九州は日本列島の南西部に位置し、北緯30°前後、東経130°前後に広がる島嶼です。九州は四つの主要山系――北部山地、西部山地、南部山地、そして東部山地――と、これらの山地に挟まれた肥沃な平野部（筑紫平野、肥前平野など）から構成されています。この地形構造は、プレート境界上にあることに起因し、ユーラシアプレートとフィリピン海プレートの相互作用が地下の岩盤形成に大きく影響しています¹。

前段落では九州全体の位置と地形を概観しましたが、ここからはその地盤を構成する具体的な地質構造に移ります。

2. 主な地質構造

区分主な岩相・年代特徴
北部山地 古第三紀・新第三紀の火山岩（安山岩・閃緑岩）火山活動に伴う噴出物層が厚く、斜面は急峭
西部山地 中新世の沈積岩（砂岩・泥岩）と古生代の炭酸塩岩 海成層が広がり、地下水の浸透性が高い
南部山地 更新世の火山灰層と凝灰岩 火山噴火による堆積が頻繁で、土壌は火山性が強い
東部山地 中生代の石灰岩とページ岩 カルスト地形が点在し、洞窟や地下水脈が多数

火山性岩盤が広範囲に分布しているため、溶岩流や火砕流の痕跡が随所に見られます。一方で、炭酸塩岩が支配的な地域では、石灰岩の溶解に伴うカルスト地形が発達し、地下水の流れが独特です²。

前段落の表で示したように、九州の山地は岩相が多様であることが分かります。次は、実際に表層で見られる土壌タイプについて説明します。

3. 土壌タイプと物理的特性

火山性土壌（北部・南部山地）

主にアンモン酸塩と火山灰が混在。保水性は高く、排水性が劣る傾向があります。

農耕利用では酸性土壌が多く、石灰施用が必要です。

炭酸塩土壌（東部山地）

カルシウムが豊富で、pHは中性～弱アルカリ性。

石灰質が多く、建築資材（石灰石）の採取が盛んです。

沖積平野土壌（筑紫平野・肥前平野）

粘土質と砂質が交互に分布し、肥沃度は高いが、洪水リスクが顕著です。

粒度分布が広いため、圧密試験が重要です。

前段落で各土壌の特徴を整理しました。ここからは、地盤が受ける自然災害リスクに焦点を当てます。

4. 地震・火山リスク

地震活動

九州は南海トラフ巨大地震帯に隣接し、過去千年でM8以上の地震が数回記録されています。特に北部山地は断層帯が密集し、液状化現象が起こりやすいとされています³。

活火山

桜島、阿蘇山、霧島火山群が代表的な活火山で、噴煙・火砕流が周辺平野に影響を与える可能性があります。火山灰は土壌肥沃化に寄与する一方、排水阻害や構造物腐食のリスクも伴います。

津波

沿岸部（長崎湾、鹿児島湾）は高潮や津波に弱く、低標高の沖積平野は浸水被害が懸念されます。

前段落で自然災害リスクを列挙しましたが、最後に実務上の留意点としてまとめておきます。

5. 利用上の留意点

建築・土木

火山性土壌は圧密性能が低く、杭基礎や深掘り工法が推奨されます。

炭酸塩岩が露出する場所での基礎工事は、化学的風化を考慮した材料選定が必要です。

農業

酸性火山土壌は石灰施用とpH調整が不可欠です。

沖積平野は排水改善（排水路・ポンプ設備）を行うことで、洪水時の被害を軽減できます。

環境保全

火山灰の過剰蓄積は水質汚染につながるため、適切な除去・再利用が求められます。

カルスト地形は地下水涵養に重要であり、地下水汚染防止策が必須です。

本章では、九州の地盤が持つ多様な岩相・土壌特性と、それに伴う災害リスク、さらには実務上のポイントを体系的に整理しました。これらの情報は、建設・農業・環境管理など、あらゆる領域での意思決定に役立つでしょう。

参考文献

国土交通省国土地理院「九州地方の地質概況」(閲覧日: 2022‑10‑05)

日本地質学会「九州の炭酸塩岩帯とカルスト地形」(閲覧日: 2022‑10‑05)

防災科学技術研究所「九州の地震活動と液状化危険度マップ」(閲覧日: 2022‑10‑05)

区分	主な岩相・年代	特徴
北部山地	古第三紀・新第三紀の火山岩（安山岩・閃緑岩）	火山活動に伴う噴出物層が厚く、斜面は急峭
西部山地	中新世の沈積岩（砂岩・泥岩）と古生代の炭酸塩岩	海成層が広がり、地下水の浸透性が高い
南部山地	更新世の火山灰層と凝灰岩	火山噴火による堆積が頻繁で、土壌は火山性が強い
東部山地	中生代の石灰岩とページ岩	カルスト地形が点在し、洞窟や地下水脈が多数

ものっ凄く内容がしっかりしてますね・・。このケースに限らず、じつは内容の真贋は別として出力結果の項目やそのレベル感は必ずきっちりとまとめられていたというのが特徴としてありました。これは、llm-jp-4シリーズの特徴の一つだと思います。

今回、出力内容を見る限りほとんどすべてを自身の知識だけで推論しており、tool_callの類は全く使われてないことを確認しています。これはまだまだモデルとしては未開の地であるようで、tool_callに対しても学習したら、もっとさらに良いモデルになっていくのだろうと私は考えます。

ただ、参考文献のリンクが存在しないリンクであり、これをそのまま掲載してしまったのは残念ポイントです。

今回も、これをGPT-5.6-Lunaにチェックしてもらいました。

総評

大枠として、九州に火山地域、カルスト地域、沖積平野、活断層が分布するという説明は妥当です。

ただし、地質、土壌、地盤、災害リスクを混在させているため、分類と表現の修正が必要です。

主な修正点

地域区分：「北部山地」「西部山地」などの四区分は一般的な地質区分ではありません。方位別ではなく、火山地域、火砕流台地、山地、石灰岩地域、沖積低地に分けるほうが適切です。

岩石名：「閃緑岩」は火山岩ではなく深成岩です。「ページ岩」は「頁岩」の誤記と考えられます。

土壌成分：「アンモン酸塩」は不適切です。火山灰土では、アロフェン、イモゴライト、活性アルミニウム、腐植などを説明します。

排水性：火山灰土を一律に「排水性が悪い」とすることはできません。土壌の種類、締固め、地形、地下水位によって変化します。

石灰岩地域：九州東部全体を炭酸塩岩地域とするのは不正確です。石灰岩やカルストは局所的に分布します。

液状化：断層が多い地域ほど液状化しやすいわけではありません。地下水位の高い緩い砂地盤、埋立地、干拓地、旧河道などで発生しやすくなります。

火山灰：土壌を肥沃にする一方で、酸性やリン酸固定によって農業上の制約になる場合があります。

建築対策：火山性土壌だから杭基礎を採用するとは限りません。支持力、沈下、斜面安定、地下水位などを調査して基礎形式を決めます。

災害分類：地震、液状化、火山、洪水、高潮、津波、斜面崩壊を分けて説明してください。

参考文献：提示されたURLや文献名には確認できないものがあるため、産業技術総合研究所、気象庁、地震調査研究推進本部、国土交通省などの一次資料に置き換えるのが安全です。

修正後の中心的な説明

九州の地盤は、火山地域と火砕流台地、付加体や堆積岩からなる山地、局所的な石灰岩地域、筑紫平野や佐賀平野などの沖積低地が複雑に分布することを特徴とします。

そのため、地盤の性質や災害リスクは地域だけでなく、地形、地層、地下水位、風化状態によって大きく異なります。

記述内容の大枠は合ってるが、細かいところで不適切と言う所で、Muse Glimmerと同程度の指摘がなされていました。

こうした知識はRAGを与えることで十分改善される余地があります。そして、記述内容の区切り方などを見る限り「報告書として出すには良い」モデルなのかなと思いました。結構この辺りはモデルによって大きく分かれるところがあり、Qwenでもカチッとしたように見せかけて「あれ？」ってなるケースも多く、このようにカチッとした報告書形式でマークダウン出力は我々日本人には好印象を与えるのかなと感じています。

まとめ

今回は国内の研究者・エンジニアで構成されているllm-jpコミュニティが作り出したllm-jp-4シリーズのモデルについて取り上げてみました。

これを制作された @kodama26985649 さんが「計算資源の不足もあって去年の秋から訓練し始めてようやく公開です… 」という位には計算資源が足りないようで、一つ一つのアクションにものすごい時間をかけながら作ってらっしゃる所には本当に頭が下がります。

過日AGI福岡という勉強会に行った際、過去にWhisperのファインチューニングで色々教えてくださったわっしーさん(@kwashizzz)も、「少ない計算資源でチューニング処理を回すのは本当に時間がかかって辛い」という旨の話をされていました。実際計算資源が足りてないのはこうしたAIを取り扱うことを主としたところでも起きているんだなぁと感じています。

AI計算資源の枯渇は深刻と言いますか、2026年8月23日時点で「デスクトップパソコン人気売れ筋ランキング」になんとDGX-Sparkが1位にランクインしています。そして、そのOEM供給品であるLenovoのThinkStation PGXが衝撃の10位にランクインしています。

当初これらの価格は60万円台でしたが、発売当初は「メモリ帯域の細いNPUを載せてもしょうがないだろ」とだれも見向きしていませんでした。しかし、モデルのサイズ向上と半導体含めた様々なものの値上がりによって今や100万円を超える個体も出てくるなど、はっきり言って今のこの状況は「異常」と言わざるを得ません。どうしてそんなにボロボロ個人が買えちゃうの！？という感じです。そりゃもちろんそれ以上に法人が買い求めてるのかもしれませんが・・

その影響をllm-jpもすくなからず受けているんだろうなと実感しています。実際私も事情を何も知らずに「ハイブリッドモデルはまだなんか」的なことを言ってしまい、メンバの方やそのフォロワ～さん方から指摘されたりなどしまして、こうした計算資源の問題の深さを感じたりしました。

その中で「着実」にステップアップを踏まれているのだとしたらそれは相当に辛抱強い・粘り強いことだと思いますし、逆に焦ってしまうと地雷を踏むことになるんだろうなと。コツコツやることこそが実を結ぶというのを体現していくことを心の底から願うばかりです。