国産LLM「LLM-jp-4」をメインPCで動かしてみた！GGUF変換失敗→まさかの逆転劇【検証編】

こんにちは！YaroTechです。

昨日の予告編で紹介した、GPT-4o超えの国産LLM「LLM-jp-4」。今日はいよいよメインPC（RTX 3050 / RAM 128GB）で実際に動かしてみました！

……のですが、最初のGGUF変換でいきなり壁にぶつかり、Plan Bに切り替え、最終的にはパラメータ数4倍の32Bモデルが8Bモデルの6.5倍速く動くという逆転劇が待っていました。

今日は「挑戦→失敗→発見」のリアルな検証記録をお届けします。

※見出し画像のプロンプトは一番下におまけで公開中！

🖥️ 実行環境

$$\begin{array}{|l|l|} \hline \text{項目} & \text{内容} \\ \hline \text{検証PC} & \text{メインPC（デスクトップ）} \\ \hline \text{CPU} & \text{Intel Core i9-12900T（16コア24スレッド）} \\ \hline \text{RAM} & \text{128GB} \\ \hline \text{GPU} & \text{NVIDIA GeForce RTX 3050（8GB VRAM）} \\ \hline \text{CUDA} & \text{13.1} \\ \hline \text{OS} & \text{Windows 11 Pro} \\ \hline \text{Python} & \text{3.12.10} \\ \hline \text{推論エンジン} & \text{Transformers / llama.cpp (b8683)} \\ \hline \text{担当AI} & \text{クロ助（Claude Desktop）} \\ \hline \end{array}$$

🎯 この記事で得られること

• LLM-jp-4をGGUF変換しようとしたら何が起きるか（失敗のリアル）

• 8Bモデルと32B-A3B（MoE）の実測速度と品質

• 「パラメータ数4倍なのに6.5倍速い」逆転現象の理由

• ラズパイのモデルとの比較で見える国産LLMの実力

• thinkingモデルの思考過程の面白さ

💥 Step 1：Plan A — GGUF変換に挑戦→撃沈！

予告編で紹介した「自力GGUF変換」から始めました。D:\AIToolsにllama.cppのビルド済みバイナリ（CUDA 13版）とソースコードを準備し、HuggingFaceからLLM-jp-4 8B-thinkingモデル（約17GB）をダウンロード。

いざ変換！

python convert_hf_to_gguf.py D:\AITools\models\llm-jp-4-8b-thinking --outtype bf16

結果：エラー。

NotImplementedError: BPE pre-tokenizer was not recognized
- update get_vocab_base_pre()

LLM-jp-4は独自のUnigramバイトフォールバック型トークナイザーを使っており、llama.cppの変換スクリプトがまだ対応していないのです。

これは「モデルが悪い」のではなく「ツールが追いついていない」だけ。公開からわずか4日なので、llama.cpp側の対応は時間の問題でしょう。

🐢 Step 2：Plan B — Transformersで8Bを直接実行

GGUF変換がダメなら、HuggingFace公式のTransformersライブラリで直接動かします。RAM 128GBあるので、bf16（16bit）のまま丸ごとメモリに載せられるのがメインPCの強みです。

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.bfloat16,
    device_map="cpu",
    trust_remote_code=True,
)

モデル読み込み：0.4秒。メモリ使用量：28GB/128GB（22%）。

ラズパイシリーズと同じ3問テストを実行しました。

$$\begin{array}{|l|l|l|l|l|} \hline \text{問} & \text{プロンプト} & \text{時間} & \text{速度} & \text{品質} \\ \hline \text{1} & \text{AIの歴史を200字で説明} & \text{144秒} & \text{1.8 tok/s} & \text{✅ 正確な年表（1943→2020年代）} \\ \hline \text{2} & \text{PythonでFizzBuzz} & \text{145秒} & \text{1.8 tok/s} & \text{✅ docstring付き正しいコード} \\ \hline \text{3} & \text{りんご3個みかん5個を2人で} & \text{146秒} & \text{1.8 tok/s} & \text{✅ 8÷2=4個ずつ＋配分例} \\ \hline \end{array}$$

CPU使用率96-98%（全コアフル稼働）、GPU使用率7-12%（ほぼ不使用）。

回答品質は文句なし。 ラズパイのllama3.2:1bが「ポテンフェuter」「ラブリー（リトルライフル）」といったハルシネーションだらけだったのに対して、LLM-jp-4 8Bは正確で構造的な回答を返してきます。

ただし速度が1.8 tok/s。1問あたり約2.5分かかるのは実用的とは言いがたい。これはCPU推論のため仕方ありません。

🔍 面白い発見：thinkingモデルの思考過程

LLM-jp-4 8B-thinkingは名前の通り「思考するモデル」です。回答の前に `analysis...` として英語で思考してから日本語で回答するという興味深い動作をします。

例えば問3「りんご3個みかん5個を2人で均等に分けるには？」では：

日本語の質問を英語に翻訳して思考し、配分パターンを検討してから、最終的に日本語で回答を出力しています。

🚀 Step 3：32B-A3B — GGUF版で逆転劇！

ここで朗報。32B-A3Bの方はmmngaさんがGGUF版を公開済みでした！

huggingface-cli download mmnga-o/llm-jp-4-32b-a3b-thinking-gguf
  --include "llm-jp-4-32b-a3b-thinking-Q4_K_M.gguf"

21.4GBのQ4_K_M量子化版をダウンロードし、llama.cppのllama-serverで起動。ブラウザから日本語でチャットできます。

llama-server.exe -m llm-jp-4-32b-a3b-thinking-Q4_K_M.gguf
  -c 4096 --gpu-layers 10 --host 127.0.0.1 --port 8080

結果は衝撃的でした。

$$\begin{array}{|l|l|l|l|l|l|} \hline \text{問} & \text{プロンプト} & \text{時間} & \text{トークン} & \text{速度} & \text{品質} \\ \hline \text{1} & \text{AIの歴史を200字で} & \text{2分4秒} & \text{1427} & \text{11.44 tok/s} & \text{✅ 正確＋文字数カウント} \\ \hline \text{2} & \text{PythonでFizzBuzz} & \text{44秒} & \text{570} & \text{12.71 tok/s} & \text{✅ コード＋説明表＋応用例} \\ \hline \text{3} & \text{りんご3個みかん5個} & \text{46秒} & \text{542} & \text{11.57 tok/s} & \text{✅ 表形式配分＋代替案} \\ \hline \end{array}$$

8Bの約6.5倍速い！ しかも品質も上。

🤔 なぜ32Bが8Bより速いのか？

一見矛盾していますが、理由は明確です。

① 推論エンジンの違い

$$\begin{array}{|l|l|l|} \hline \text{} & \text{8B} & \text{32B-A3B} \\ \hline \text{エンジン} & \text{Transformers (Python)} & \text{llama.cpp (C++)} \\ \hline \text{形式} & \text{safetensors (bf16)} & \text{GGUF (Q4＿K＿M)} \\ \hline \text{GPU活用} & \text{ほぼなし（7％）} & \text{一部レイヤーをGPU（gpu-layers 10）} \\ \hline \end{array}$$

Transformersは汎用性が高い反面、推論速度の最適化ではllama.cppに大きく劣ります。llama.cppはC++で書かれた推論特化エンジンで、量子化モデルの高速処理に最適化されています。

② MoE（Mixture of Experts）の威力

32B-A3Bは総パラメータ320億ですが、推論時にアクティブなのは約38億（3.8B）だけ。128個の「専門家」のうち最適な8個だけが動くので、320億の知識量を持ちながら38億の計算コストで済むのです。

③ 量子化の恩恵

Q4_K_M量子化により、モデルサイズが64GB→21.4GBに圧縮。メモリに載りやすく、データ転送も速くなります。

📊 全モデル比較（同一3問テスト）

$$\begin{array}{|l|l|l|l|l|l|l|} \hline \text{モデル} & \text{PC} & \text{エンジン} & \text{速度} & \text{日本語} & \text{コード} & \text{推論} \\ \hline \text{LLM-jp-4 32B-A3B} & \text{メインPC} & \text{llama.cpp GGUF} & \text{11.4 tok/s} & \text{✅✅} & \text{✅✅} & \text{✅✅} \\ \hline \text{LLM-jp-4 8B} & \text{メインPC} & \text{Transformers bf16} & \text{1.8 tok/s} & \text{✅} & \text{✅} & \text{✅} \\ \hline \text{llama3.2:1b} & \text{ラズパイ} & \text{Ollama} & \text{~0.5 tok/s} & \text{△} & \text{✅} & \text{△} \\ \hline \text{tinyllama} & \text{ラズパイ} & \text{Ollama} & \text{~0.3 tok/s} & \text{✕} & \text{✕} & \text{✕} \\ \hline \text{qwen2:0.5b} & \text{ラズパイ} & \text{Ollama} & \text{~0.5 tok/s} & \text{△} & \text{△} & \text{✕} \\ \hline \end{array}$$

ラズパイとの差は歴然。国産LLMがこのレベルに到達していることに感動します。

🔗 関連記事

• GPT-4o超えの国産LLM爆誕！「LLM-jp-4」を明日メインPCで試します【予告編】

• ラズパイで始めるローカルAI #04｜2GBのPi 4でAIは喋れるか？Ollamaインストール＆実測レポート

• NPU 93%フル稼働！でもCPU+GPUのほうが速い!?【検証編】

📝 まとめ

• GGUF自力変換はトークナイザー非対応で失敗（llama.cpp側の対応待ち）

• 8B Transformers CPU推論は品質◎だが1.8 tok/sで遅い

• 32B-A3B GGUF版（mmnga氏）+ llama.cppで11.4 tok/sを達成

• パラメータ数4倍の32Bが8Bの6.5倍速いという逆転現象

• 国産LLMの日本語品質はラズパイで試した海外モデルとは次元が違う

🚀 次回予告

llama.cppのサーバーUIにはMCPサーバー接続機能もあることが判明しました。次回はこの32B-A3Bモデルを活用した応用検証か、Ollama対応が来たときの再チャレンジをお届けする予定です。お楽しみに！

🎨 おまけ：見出し画像作成プロンプト

今日の見出し画像のベースはジミー（Gemini）に下記プロンプトで作成。

柔らかな照明で撮影された超現実的でプロフェッショナルな写真を作成してください。
下記条件のnote見出し画像をサイズは横長で作成してください。サイズは必ず横長で作成してください。

テーマ：国産LLM「LLM-jp-4」検証編 — GGUF変換失敗→逆転劇
雰囲気：テクノロジーの挑戦と発見、ドラマチック
要素：
- 左側にエラーメッセージ風の赤い警告表示（GGUF変換失敗）
- 中央に大きな矢印で「→」転換を表現
- 右側にllama.cppのチャットUI画面（成功・緑色）
- 背景は濃紺→赤→緑のグラデーション（失敗→成功の転換）
- 「32B > 8B !?」のテキストを目立つように配置
- 速度数値「1.8 → 11.4 tok/s」を対比表示

Step 7: 下部中央寄りに「YaroTech」のロゴを12ptで控えめに配置
Step 8: 全体のバランスを確認して完成

#国産LLM #LLMjp4 #ローカルLLM #llamacpp #GGUF #Transformers #MoE #NII #オープンソース #YaroTech