ローカルLLMモデル比較：同じ質問を6モデルに投げてみた【2026年版】

2026年7月16日

ふだん、RTX 3090とRTX 3060の2枚挿し環境でローカルLLM（大規模言語モデル）を動かしています。Ollamaで使えるモデルが増え続けるなか、「結局どれを使えばいいのか」が分かりにくくなってきました。

2026年4月現在、ローカルLLMの主要ファミリーはQwen3系（Alibaba Cloud）、Gemma4系（Google DeepMind）、Llama系（Meta）、Phi系（Microsoft）、Mistral系（Mistral AI）と多岐にわたります。パラメータ数（AIの規模を表す数値。数字が大きいほど賢くなりやすい）やライセンス、得意分野がそれぞれ異なり、用途に応じた選び方が必要です。

本記事では、そのなかからOllamaで手軽に動かせる6モデルに絞り、同じ質問を投げて速度・日本語品質・要約力・コード生成能力を比較しました。

結論としては、日常使いならgemma4が最速かつ日本語が自然。本格的な推論にはqwen3:14bがバランス最良です。思考型モデル（qwen3.5系）は設定を間違えると回答が出ないという落とし穴もありました。

※ この記事の実測値は2026年4月時点のものです。

テスト環境

今回のテストに使用した環境は以下のとおりです。

GPUの詳細スペックはGPU全機種スペック一覧にまとめています。Ollamaの導入方法はOllama導入ガイドを参照してください。

比較対象の6モデル

今回比較したのは以下の6モデルです。

※分類は今回のテストでの挙動ベースです。qwen3系とgemma4（E4B・実効4B）は思考のオン/オフを切り替えられるハイブリッド型ですが、今回は思考なしの即答動作だったため「通常型」としています。

「思考型（Reasoning Model）」とは、回答を出す前に内部で推論プロセスを実行するモデルのことです。人間が「考えてから答える」ように、モデルも思考ステップを踏んでから結論を出します。精度は上がりますが、その分の時間とトークン（AIが文章を扱うときの最小単位。単語や文字のかたまり）を消費するという代償があります。通常型と思考型の違いは、このあとのテストで具体的に見ていきます。

テスト1: 日本語生成「日本の四季について100文字で」

まずは基本的な日本語生成能力のテストです。全モデルに同じプロンプト「日本の四季について100文字で説明してください」を投げました。

qwen3:8b — 121.7 tok/s

最速の121.7 tok/s（1秒あたりに生成するトークンの数。大きいほど速い）。ただし「四季分明」「雪国」など、中国語的な語彙が混ざっています。日本語として読めるが、やや硬い印象です。

qwen3:14b — 48.6 tok/s

8Bと比べて速度は半分以下ですが、日本語がきれいにまとまっています。簡潔すぎるきらいはあるものの、正確で自然な文章です。

qwen3.5:9b — 45.8 tok/s

これが今回最大の発見です。qwen3.5:9bは思考型モデルのため、回答の前に内部推論を行います。今回の設定では最大トークン数（num_predict）が4096だったため、思考だけでトークンを使い切ってしまい、肝心の回答が出力されませんでした。詳しくは後述の「思考型モデルの罠」で解説します。

qwen3.5:27b — 25.4 tok/s

27Bモデルでも同じ問題が発生。モデルサイズが大きくても、思考型の制約は同じです。

gemma4 — 114.0 tok/s

E4B（実効4B）で114.0 tok/sという高速ながら、文学的で情緒のある日本語を生成しています。「桜が舞い散ります」「雪化粧の静けさ」など、人間が書いたような表現です。Google DeepMindの日本語チューニングの質の高さを感じます。

gemma4:26b — 95.0 tok/s

26Bの思考型モデルですが、gemma4:26bは思考を2035トークンで完了させ、きちんと回答を出力しました。qwen3.5系との大きな違いです。日本語も正確で読みやすく、速度も95.0 tok/sと十分高速です。

テスト1まとめ

テスト2: 要約力「技術文書を3行にまとめさせる」

次に、OllamaのGPU設定に関する英語の技術解説文（約800字）を各モデルに渡し、「3行で要約してください」と指示しました。原文は英語ですが、日本語での要約を求めています。

原文（要旨）

OllamaのGPUオフロード設定に関する説明文です。CUDA/ROCm/Metalの検出、VRAM不足時のCPUフォールバック、環境変数OLLAMA_NUM_GPUによる手動指定、複数GPU環境での挙動などが記述されています。

各モデルの要約結果

qwen3:8b（121.7 tok/s）

正確で簡潔。3行という指示も守っています。ただし「フォールバック」など技術用語をそのまま使っており、初心者には少し不親切です。

qwen3:14b（48.6 tok/s）

14Bの余裕が出ています。「フォールバック」を「切り替わります」に言い換えるなど、読みやすさへの配慮が見られます。情報の欠落もありません。

qwen3.5:9b / qwen3.5:27b

num_predictを4096のまま実行したため、テスト1と同じ問題が再現しました。要約のような短い回答でも、思考プロセスが長いと出力に到達しません。

gemma4（114.0 tok/s）

情報の正確性、日本語の自然さ、簡潔さのすべてが高水準です。「並列処理」という補足も的確で、元の英語文書の意図を正しく汲み取っています。

gemma4:26b（95.0 tok/s）

最も詳細な要約。「レイヤーを各GPUに分散配置」という正確な技術的説明が入っています。思考型の精度が活きた結果です。

テスト2まとめ

要約タスクでもgemma4系の安定感が目立ちます。qwen3:14bも実用十分ですが、gemma4は8Bでほぼ同等の品質を出せる点で効率に優れます。

テスト3: コード生成「Pythonでフィボナッチ数列」

「Pythonでフィボナッチ数列を再帰で実装してください。docstringとコメント付きで」と全モデルに投げました。

各モデルの生成結果

qwen3:8b（121.7 tok/s）

def fibonacci(n):
    """Return the n-th Fibonacci number using recursion."""
    if n <= 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fibonacci(n - 1) + fibonacci(n - 2)

正しく動作するコードです。docstringは英語。コメントはありません。必要最小限の実装で、指示の「コメント付き」は無視されています。

qwen3:14b（48.6 tok/s）

def fibonacci(n: int) -> int:
    """
    フィボナッチ数列のn番目の値を再帰で計算する。

    Args:
        n: 0以上の整数

    Returns:
        n番目のフィボナッチ数
    """
    # ベースケース: 0番目は0、1番目は1
    if n <= 0:
        return 0
    elif n == 1:
        return 1

    # 再帰ケース: F(n) = F(n-1) + F(n-2)
    return fibonacci(n - 1) + fibonacci(n - 2)

型ヒント付き、日本語docstring、コメントも適切。指示をすべて満たしています。14Bの精度が活きた結果です。

qwen3.5:9b / qwen3.5:27b

num_predictを8192に引き上げて再実行しました。

# qwen3.5:9b の出力（num_predict=8192で実行）
def fibonacci(n: int) -> int:
    """
    再帰的にフィボナッチ数列のn番目の値を求める。

    時間計算量: O(2^n) - 指数的。大きなnには非推奨。
    メモ化(functools.lru_cache)の使用を推奨。

    Args:
        n: 非負の整数
    Returns:
        int: n番目のフィボナッチ数
    """
    if n < 0:
        raise ValueError("nは非負の整数である必要があります")
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)

num_predictを8192に設定したことで、きちんと回答が出力されました。計算量の注記やエラーハンドリングまで含む丁寧な実装です。思考型モデルの精度がコード品質に反映されています。qwen3.5:27bもほぼ同等の品質で、さらにメモ化版の実装例も追記していました。

gemma4（114.0 tok/s）

def fibonacci(n: int) -> int:
    """フィボナッチ数列のn番目の値を再帰的に計算します。

    Args:
        n: 計算したいフィボナッチ数列の位置（0始まり）

    Returns:
        n番目のフィボナッチ数
    """
    # 基底条件
    if n <= 0:
        return 0
    if n == 1:
        return 1

    # 再帰呼び出し
    return fibonacci(n - 1) + fibonacci(n - 2)

型ヒント、日本語docstring、コメントと、指示をすべて満たしています。114.0 tok/sでこの品質は優秀です。

gemma4:26b（95.0 tok/s）

def fibonacci(n: int) -> int:
    """フィボナッチ数列のn番目の値を再帰で計算する。

    フィボナッチ数列: 0, 1, 1, 2, 3, 5, 8, 13, 21, ...
    F(0) = 0, F(1) = 1, F(n) = F(n-1) + F(n-2)

    注意: 単純な再帰はO(2^n)の計算量。n > 35程度で
    体感できるほど遅くなります。実用にはメモ化を推奨。

    Args:
        n: 非負の整数（フィボナッチ数列のインデックス）

    Returns:
        n番目のフィボナッチ数

    Raises:
        ValueError: nが負の場合
    """
    if n < 0:
        raise ValueError(f"nは非負の整数を指定してください（入力: {n}）")
    if n <= 1:
        return n

    # F(n) = F(n-1) + F(n-2)
    return fibonacci(n - 1) + fibonacci(n - 2)

全モデル中で最も完成度が高い出力です。数列の具体例、計算量の注記、エラーハンドリング、f-stringを使ったエラーメッセージまで含まれています。

テスト3まとめ

コード生成では思考型モデルの精度が活きます。ただし、qwen3.5系はnum_predictの調整が前提です。設定なしで使える点を含めると、gemma4:26bが最も実用的です。

モデルファミリー別の特徴比較

3つのテスト結果を踏まえて、モデルファミリー別の特徴をヒートマップにまとめました。

Qwen3系は速度に強みがあり、特に8Bは全モデル最速です。一方、日本語の自然さではGemma4系が一貫して高品質です。思考型モデルはQwen3.5系・Gemma4:26bともに精度は高いものの、Qwen3.5系はnum_predictの調整が必須という大きな差があります。

速度比較

テスト1での各モデルの生成速度を比較します。

qwen3:8bが最速ですが、gemma4も114.0 tok/sとほぼ同水準です。体感ではどちらも「瞬時に返ってくる」レベルで、差を感じることはありません。

gemma4:26bの95.0 tok/sは26Bモデルとしては異例の速さです。RTX 3090のメモリ帯域（936 GB/s）をうまく活かしている印象です。

一方、qwen3.5系は思考プロセスが入る分、実効速度がさらに遅くなります。25.4 tok/s（qwen3.5:27b）は体感で「少し待つ」程度ですが、思考トークンの消費時間を含めると実際の待ち時間はもっと長くなります。

思考型モデルの罠：num_predictの設定ミスで回答が出ない

今回のテストで最も重要な発見がこれです。

qwen3.5系の思考型モデルは、num_predictの上限が低めだと回答が出力されない場合があります。

仕組みを説明します。思考型モデルは回答を出す前に、内部で「推論チェーン」を実行します。この推論チェーンも通常のトークンとしてカウントされます。

今回のテストでは、1回の応答で出力できる最大トークン数（num_predict）を、コンテキスト長の既定値に合わせて4096に設定していました。qwen3.5:9bとqwen3.5:27bは、「日本の四季について100文字で」という簡単な質問でも、思考プロセスだけで4096トークンを使い切ってしまいました。

具体的には次のとおりです。

解決策は、num_predictを大きくすることです。

# Modelfileで設定する場合
PARAMETER num_predict 8192

# APIリクエストで指定する場合
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3.5:9b",
  "prompt": "日本の四季について100文字で",
  "options": { "num_predict": 8192 }
}'

ただし、num_predictを大きくすると、思考型モデルは必要以上に長く考える傾向があります。VRAMに余裕があるなら8192〜16384を設定し、思考の打ち切りはモデル側に任せるのが現実的です。

一方、gemma4:26bも思考型ですが、こちらは2035トークンで思考を完了させ、きちんと回答を出力しました。 同じ思考型でも、モデルによって思考の効率に大きな差があります。この点はgemma4:26bの明確な優位点です。

テスト3のコード生成でも、num_predictを8192に上げたqwen3.5:9bはきちんと高品質なコードを出力しました。思考型モデルは「設定さえ正しければ強い」。逆に言えば、設定を間違えると全く使えないということです。

VRAM使用量とGPU選びの目安

各モデルをRTX 3090にロードした際のVRAM使用量です。

※VRAM使用量はモデルファイルサイズをもとにした概算です。実際の使用量はコンテキスト長（KVキャッシュ）や実装により増減します。

8Bクラスのモデルは5〜8GBで収まるため、RTX 3060（12GB）でも余裕を持って動かせます。2枚挿し環境なら、RTX 3060で8Bモデルをチャット用に常駐させ、RTX 3090で26〜27Bクラスの重いモデルを必要なときだけ動かす、という運用が効率的です。

26B以上のモデルはVRAM（ビデオメモリ。GPUが計算に使う作業用メモリ）17GB前後を必要とするため、RTX 3090（24GB）やRTX 4090（24GB）クラスのGPUが必須です。RTX 3060（12GB）では物理的に載りません。

GPUの選び方についてはGPU全機種スペック一覧も参考にしてください。

どのモデルを選ぶべきか

用途別のおすすめをまとめます。

迷ったらgemma4から始めてください。 114 tok/sの速度で文学的な日本語を返してくれるこのモデルは、ローカルLLM入門としても、日常使いとしても最適です。

もう少し精度が欲しくなったらqwen3:14bを試してください。速度は半分以下に下がりますが、それでも48.6 tok/sは体感で十分快適です。

推論力を求めるならgemma4:26b。思考型ながら95.0 tok/sを出し、num_predictの罠もない。RTX 3090を持っているなら積極的に試す価値があります。

ローカルLLMの導入自体がまだの方は、Ollamaの導入ガイドから始めるのがおすすめです。ローカルAIチャットボットを動かしたい方向けの記事も参考にしていただけます。

まとめ

同じ質問を6モデルに投げた結果、以下のことが分かりました。

速度面: qwen3:8b（121.7 tok/s）とgemma4（114.0 tok/s）が2トップ。8Bクラスはどちらも体感で瞬時に返ってくるレベルです。

日本語品質: gemma4が予想外の好成績。「桜が舞い散ります」「雪化粧の静けさ」など、文学的な表現を8Bモデルで生成できるのは驚きでした。

要約・コード生成: gemma4:26bが総合力で最も安定。思考型の精度を活かしつつ、設定の手間もない。qwen3:14bもバランスの良さが光ります。

思考型モデルの落とし穴: qwen3.5系はnum_predictが4096程度の上限設定では回答が出ない場合がある。gemma4:26bは同じ思考型でも問題なし。この差は大きいです。

バランス最良: qwen3:14b。速度・精度・日本語品質のすべてが高水準。メイン機として安定運用するならこのモデルです。

ローカルLLMは「どのモデルを選ぶか」で体験が大きく変わります。この記事のデータが、モデル選びの参考になれば幸いです。

検証に使用した機材

【中古】MSI GeForce RTX 3090 GAMING X TRIO 24GB

¥148,000 (2026/5/1時点)

Amazon楽天市場Yahoo!

【中古】ELSA GeForce RTX 3060 12GB

¥52,800 (2026-06-22時点)

Amazon楽天市場Yahoo!