見出し画像

16GBノートPCの部門別最強LLMはどれか — 蒸留・9B級モデルガチンコ比較(2026年7月版)

zephel01

前回の記事「16GBのノートPCでも、Claude Code + ローカルLLMは本気で使える — CodeRouterでTool Callが安定するまで(2026年7月版)」では、Qwen2.5-coder:7b/1.5b、Qwen3.5:9b、phi4-mini、gemma4:26b-a4b、llama3.2:3b/3.1:8bといった「定番どころ」を一通り触って、CodeRouter経由でTool Callを安定させるところまでを書きました。

今回はその続編です。テーマを絞って、**蒸留モデル・9B級を中心にした「用途別部門ランキング」**をやります。「結局どれを16GBに入れればいいのか」という問いに対して、コーディング・Tool Call・日本語・超軽量・推論数学の5部門に分けて、筆者の実測ベンチと世間の報告を切り分けながら並べていきます。

先に結論の性格を書いておくと、この記事の数値には二種類あります。

  • 筆者の実測ベンチ由来のデータ: 自作のllmbench(40タスク/60タスク)を、RTX5090 32GB環境で回した結果です。一次データなので数値はそのまま信用してよいですが、「RTX5090で測っている」という前提条件は必ず頭に入れてください。

  • Web調査由来の情報: 公式ベンチマークやコミュニティの報告です。確度をHIGH/MODERATEで明記します。断定はしません。

この区別を曖昧にしたまま「〜が最強」と書くのは無責任なので、以降も「筆者の実測では」「〜という報告があります」という言い回しを徹底します。

1. 前提: 16GBノートPCの現実

本題に入る前に、「16GB」という数字が実際どれだけ厳しいかを確認しておきます。

localaimasterによるM2 Air 16GB実機での実測(確度MODERATE-HIGH)によれば、OSやアプリが常駐した状態での実効利用可能メモリは約6〜8GBしかありません。つまり「16GB積んでいるから16GBのモデルが動く」という単純計算は成立せず、量子化モデルのファイルサイズ+KVキャッシュ+OS分の余裕を見て、実質6〜8GBに収める必要があります。

さらに見落とされがちなのがKVキャッシュです。同じ報告では、7B・Q4量子化のモデルで1kトークンあたり約0.5GBのKVキャッシュが必要になるとされています。Claude Codeのようなツールでnum_ctxを32kまで伸ばすと、それだけで数GB持っていかれる計算になり、これが16GB実機で最も多い失敗パターン(メモリスワップによる速度崩壊)の原因になっています。

参考までに、同じM2 Air環境での実測速度例(確度MODERATE-HIGH)は以下の通りです。

  • Llama3.2 3B: 32 tok/s

  • Phi-4 mini: 26.5 tok/s

  • Qwen2.5-Coder 7B: 11 tok/s

  • DeepSeek-R1-Distill-Qwen-7B: 10.7 tok/s

また、llama.cppでTool Callを使う場合は`--jinja`フラグが必須という報告もあります。前回記事でCodeRouterのTool Call不安定問題を扱いましたが、こうした細かいフラグの有無だけで挙動が変わるのがローカルLLM運用の面倒なところです。

なお、本記事で紹介する筆者の実測データはRTX5090 32GB環境で取得したものです。モデルが16GBに収まるかどうかの目安(量子化サイズ)は環境に依存しませんが、速度(tok/s)は16GB実機よりかなり高く出ている点に注意してください。この点は記事末尾でも改めて注意書きします。

2. 蒸留モデルとは(簡単に)

蒸留(Distillation)とは、大型モデル(教師モデル)の出力や推論過程を小型モデル(生徒モデル)に学習させることで、小さいサイズでも教師に近い性能を狙う手法です。今回扱うモデルには大きく2系統あります。

  • 推論トレース蒸留系: DeepSeek-R1のような大型推論モデルの思考過程(Chain of Thought)を7B級に移植するタイプ。数学・論理推論に強く出る傾向がありますが、Tool Callのような「決まったフォーマットで出力する」タスクとは相性が悪いことがあります。

  • エージェント特化ポストトレーニング系: gemma-4-12B-coder-fable5のように、コーディングエージェントの実行トレースを使ってファインチューニングするタイプ。コーディングやTool Callの実務精度を狙って作られています。

同じ「蒸留」でも狙っている性質がまったく違うので、「蒸留モデル=数学に強い」と一括りにはできません。この後の部門別ランキングで、その違いがそのまま順位に出てきます。

3. 部門別ランキング

部門1: コーディング部門(筆者の実測ベース)

自作llmbench 40タスクの結果です。すべてRTX5090環境での実測になります。

  • 1位: gemma-4-12B-coder-fable5(Q6) — 92.5%
    Fable5×Composer2.5蒸留の12Bモデル。Q4で6.87GB/Q6で9.11GBというサイズながら、Q6で92.5%というスコアは今回比較した中で頭一つ抜けていました。速度はQ4 133 tok/s、Q6 111 tok/s。筆者の体感でも「ruffが常にクリーンで、雑な実装が返ってこない」という安定感があり、12B安定枠の基準モデルとして使っています。
    → https://huggingface.co/yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF

  • 2位: Ornith-1.0-9B(Q6) — 90%
    Gemma4/Qwen3.5系をベースにagentic特化を公称したポストトレーニングモデル。Q4 5.63GB/Q6 7.36GBで、Q4でも87.5%というスコアを出しており、9B級としては頭ひとつ抜けた完成度でした。速度はQ4で200 tok/sと軽快です。
    → https://huggingface.co/deepreinforce-ai/Ornith-1.0-9B-GGUF

  • 3位: Qwythos-9B(MTP, Q8) — 85%
    Qwen3.5-9BにClaude Mythos/Fableトレース500Mでファインチューンした蒸留系モデル。標準Q4で82.5%、MTP(Q8)構成で85%まで伸びます。Q4 5.3GB/Q8 8.9GBで、MTP構成では253〜295 tok/sという速度も出ました。1Mコンテキスト・vision対応という汎用性の高さも特徴です。
    → https://huggingface.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF

  • 次点: MaralGPT-Mythos-9B — 77.5%
    Qwen3.5-9B系のuncensoredモデル。Q4 5.63GBで200 tok/s。特筆すべきは「量子化しても品質が落ちずQ4がスイートスポット」という点で、CodeRouter経由でも速度劣化がありませんでした(この点は筆者がCodeRouter経由で実測済みです)。
    → https://huggingface.co/MaralGPT/MaralGPT-Mythos-9B-2606-GGUF

一方で、以下の2モデルは正直に「圏外」と書きます。

  • VibeThinker-3B: Qwen2.5-Coder-3B系。5回実行したpass@1の平均は38%でした。1回だけ実行すると55%も出ることがありますが、これは「たまたま当たった」だけで、ブレ幅が大きすぎて実用の目安にはできません。単体では実用閾値未満と判断しています。

  • Grug-12B: gemma-4-12B-it系の省トークンFTモデル。40タスクの通しスコアは45%止まりですが、pass@k(複数回試行のいずれかが正解)では87.5%まで跳ね上がります。つまり「当たれば強いが毎回ブレる」flakyなモデルで、1回勝負のエージェント用途には向きません。

ちなみに27B級のdenseモデル(Qwopus3.6-27B等、40タスク100%を記録した王者格も含む)も試しましたが、Q4でも15.4〜21GBが必要で、16GB環境では実用は困難です。今回の検証を踏まえると、16GBの現実的な上限は12Bクラスというのが筆者の結論です。

部門2: Tool Call部門(Web調査ベース+前記事の知見)

こちらは筆者が体系的に実測したわけではなく、公式ベンチマークやコミュニティ報告をベースにした序列です。

  • 1位: Qwen3-4B-Instruct-2507
    BFCL-v3(Berkeley Function-Calling Leaderboard)で71.2%というスコアが報告されており、これはsub-7B級では首位級とされています(一次確認済み・確度HIGH)。Q4で約3GBという軽さもあり、Apache 2.0ライセンス、262kコンテキスト対応。Tool Call特化用途では最有力候補です。
    → https://huggingface.co/unsloth/Qwen3-4B-Instruct-2507-GGUF

  • 2位: IBM Granite 4.1 8B
    IBMが公式にTool Call専用設計として謳っているモデルで、約5GB。安定したTool Callが報告されています(IBM公式情報)。ただしHumanEval 87.2%という数値は二次情報であり、確度はMODERATEとしておきます。
    → https://huggingface.co/unsloth/granite-4.1-8b-GGUF

  • 3位: Qwen3-8B
    Q4で約5.5GB。Hermes形式でのTool Callが安定しているという報告があります(確度MODERATE)。ライセンスはApache 2.0とされています(確度MODERATE)。
    → https://huggingface.co/Qwen/Qwen3-8B-GGUF

注意点として、DeepSeek-R1-Distill系のモデルはTool Call非対応、または`tool_calls`が空配列で返ってくるといった不安定な報告があり、Claude Codeのようなエージェント連携用途には向きません。また前記事で扱ったgemma3系についても同様にTool Call面での課題を確認済みです。

なお2026年に入ってからは、関数呼び出しに特化した超小型蒸留モデル(FunctionGemma 270M、Gemma 4 E2Bなど)も登場してきています。これらは二次情報ベースであり確度はMODERATEにとどまるため、今回は参考情報にとどめます。

部門3: 日本語部門(Web調査ベース)

**筆者のllmbenchは英語タスクのみで構成されているため、日本語性能は未実測です。**この部門は完全にWeb調査ベースであることを明記した上でランキングします。

  • 1位: Qwen3-Swallow-8B
    東工大系の研究グループが2026年2月に公開したモデル。約5.5GB。Swallow公式の発表(確度HIGH)によれば、2026年2月時点で同規模のオープンLLMの中で日本語タスク最高性能とされています。Apache 2.0。
    → https://huggingface.co/collections/tokyotech-llm/qwen3-swallow-v02

  • 2位: Llama-3-ELYZA-JP-8B
    「GPT-4o級」という評価がありますが、これは自社評価によるものであり確度はMODERATEです。第三者による裏取りが必要な数値として扱っています。
    → https://huggingface.co/elyza/Llama-3-ELYZA-JP-8B-GGUF

  • 3位: Sarashina3 mini/nano
    SB Intuitionsが2026年6月30日のブログで発表。蒸留+多段RLという手法概要は公開されていますが、詳細なベンチマーク数値は本記事執筆時点で未公表です。情報待ちの状態として扱います(確度MODERATE)。

日本語性能が重要な用途の方は、この部門については筆者の実測データがない点をご留意の上、一次情報(各モデルの公式発表)を追加で確認することをおすすめします。

部門4: 超軽量部門(〜4B級)

省メモリ・省電力を最優先する用途向けです。

VibeThinker-3Bはサイズこそこの部門に収まりますが、コーディング部門で見た通り精度のブレが大きく、超軽量部門としても選外としています。

部門5: 推論・数学部門

  • 1位: DeepSeek-R1-Distill-Qwen-7B
    DeepSeek-R1の推論トレースをQwen2.5-Math-7Bに蒸留したモデルで、800kサンプルで学習されています。Q4で約5.4GB。MATH-500ベンチマークで92.8%というスコアが公式に報告されており(HF公式・確度HIGH)、7B級では数学・推論に関して最強クラスと言えます。
    → https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-7B-GGUF

ただしこのモデルはTool Call非対応、または不安定という報告があり、`tool_calls`が空配列で返ってくる事例も見られます。そのため、Claude Codeのようなエージェント連携用途には不向きです。「数学の問題を解かせる」「単発でロジックを詰める」といったチャット・単発推論用途に限定して使うのが現実的な位置づけになります。

4. 総合の選び方フローチャート

ここまでの5部門を踏まえて、用途別に選び方をまとめます。

どれか一つに絞れない場合は、「エージェント用途はgemma-4-12B-coder-fable5、Tool Call特化タスクはQwen3-4B-Instruct-2507」のように、CodeRouter的な仕組みでタスクごとにモデルを切り替える運用が現実的だと考えています。この切り替え運用については前記事で扱った内容が参考になります。

5. 実測データについての注意書き

本記事の「筆者の実測」と明記したすべての数値は、自作のllmbench(40タスク/60タスク構成)をRTX5090 32GB環境で実行した結果です。

  • 量子化後のファイルサイズ(GB)は環境に依存しないため、「16GBに収まるか」の判断材料としてそのまま使えます。

  • 一方で、tok/s表記の速度はGPU性能に強く依存します。16GB搭載の実機(特にCPU推論やUMA環境のノートPC)では、本記事に記載した速度よりかなり低い値になることが見込まれます。速度の絶対値ではなく、モデル間の相対的な速度差の参考として読んでください。

  • 精度(%)についても、量子化レベル(Q4/Q6/Q8)やプロンプト構成によって変動します。特にVibeThinker-3BやGrug-12Bのように試行回数によってスコアが大きくブレるモデルがあることは、今回のベンチで改めて確認できた教訓です。「1回の結果で語らない」「量子化はQ5-Q6がスイートスポットになりやすい(ただし例外あり)」という2点は、今後もローカルLLMを評価する際の基本姿勢にしたいと考えています。

参考リンク・出典

※本記事中の「筆者の実測では」と記載した数値はすべてRTX5090 32GB環境での測定値であり、16GB搭載の実機とは速度面で差が出ます。「〜という報告があります」「確度MODERATE」等と記載した情報は二次情報を含むため、実運用の際はご自身の環境での検証をおすすめします。

いいなと思ったら応援しよう！

zephel01 サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！