ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

「ローカルLLMを動かす環境は用意できたが、モデルが多すぎてどれを選べばいいのか分からない」
「Llama・Mistral・Gemma・Phi-4の違いが曖昧なまま選び、VRAM不足でクラッシュさせてしまった」

この記事では、Ollamaで扱う主要モデル（Llama3.3・Mistral・Gemma 3／4・Phi-4）の特徴とUbuntuでの動作要件、用途別の使い分けと切り替えコマンドを現役講師の視点で解説します。

ローカルLLMのモデル選びで失敗しやすい理由

ローカルLLMの導入で最初につまずくのが、実はインストールではなく「モデル選定」です。Ollamaの公式ライブラリには数十種類のモデルが並んでおり、名前を見ただけでは何が自分の用途に合うのか判断がつきません。

あるシステム開発会社の情シス担当者から聞いた話ですが、「とりあえず一番賢そうな大きいモデルを入れよう」と最上位モデルを選んだ結果、手元のGPUのVRAMに収まらずクラッシュを連発し、結局CPUで動かして実用に耐えない速度になってしまったそうです。これはモデル選定でよくある典型的な失敗です。

ローカルLLMのモデル選びで失敗しやすい原因は、大きく次の3点に整理できます。

・VRAM容量を無視した選定：モデルのパラメータ規模に対してGPUのVRAMが足りないと、メモリ不足（OOM）でクラッシュするか、CPUにオフロードされて極端に遅くなります
・用途とモデルの不一致：コード生成が得意なモデル、日本語が得意なモデルなど、モデルには得意領域があります。万能の1つを探すより用途で選ぶのが現実的です
・量子化の概念を知らない：同じモデルでも量子化（軽量化）の度合いで必要VRAMが大きく変わります。これを知らないと「動かせるはずのモデル」を諦めてしまいます

逆に言えば、この3点さえ押さえれば、モデル選定は驚くほどシンプルになります。基本方針は「搭載GPUのVRAM容量に収まる範囲で、用途に合った最大のモデルを選ぶ」こと、これに尽きます。本記事ではこの考え方を、主要モデルの具体的な特徴とコマンドに落とし込んでいきます。

主要モデルの特徴とUbuntu環境での動作要件

まずは主要なローカルLLMを、Ollamaで扱う前提で1つずつ見ていきます。動作確認環境は Ubuntu Server 24.04 LTS（NVIDIA GPU搭載・ドライバ導入済み）です。

なお、OllamaそのもののインストールやUbuntu Serverへの導入手順は本記事では扱いません。環境構築がまだの方は、先にセットアップを済ませてから読み進めてください。

・Ollamaのインストール手順はこちら（Ubuntu ServerでローカルLLMを構築する方法）

以下のモデル名のうち、ollama pull で指定するタグ（llama3.3 等）はOllama公式ライブラリの一般的な名称です。最新のタグ名やバリエーションは公式ライブラリで変わる場合があるため、実際に取得する際は ollama pull 実行時のメッセージや公式サイトで確認してください。

Llama3.3（Meta）

Metaが公開する代表的なオープンウェイトモデルです。本記事が基準とするLlama3.3は70Bパラメータ規模で、複雑な推論や長文処理を高い精度でこなします。汎用性が高く、品質重視の用途で第一候補になるモデルです。

一方で規模が大きいぶん、必要VRAMも大きくなります。4bit量子化前提でも約40GB以上が目安となるため、動かすにはハイエンドGPUか複数GPU構成が現実的です。
日本語にも対応しますが、日本語に特化したモデルではないため、用途によっては後述のGemma系のほうが自然な場合もあります。

Mistral・Mixtral

フランスのMistral AIが公開するモデル群です。Mistral（7B）は軽量ながらバランスが良く、コード補助や文章生成に広く使える定番モデルです。約4～6GB程度のVRAMから動かせるため、ミドルレンジのGPUでも快適に動作します。

Mixtralは複数の小さなモデルを組み合わせるMoE（Mixture of Experts）構成の上位版で、Mistral単体より高い精度を狙えますが、そのぶん必要VRAMも増えます。まずはMistral（7B）から試すのがおすすめです。

Gemma 3（Google）

GoogleのオープンモデルがGemmaです。Gemma 3は軽量で扱いやすく、約8GB以上のVRAMから動作する一方で、日本語の応答も実用的なレベルにあります。汎用的な社内アシスタントや、まず手元で試してみたいという場面に向いています。
軽量モデルから始めて精度を確認したい場合、最初の選択肢として有力です。

Gemma 4（Google）

Gemma 4はGemma 3の上位にあたるモデルで、より高い精度が必要な業務向けの選択肢です。そのぶん必要VRAMも大きくなり、4bit量子化前提でも約16GB以上が目安となります。

Gemma 3で精度が物足りないと感じた場合に、段階的に切り替える先として位置づけると分かりやすいでしょう。
なお、Gemmaシリーズはバージョンによって ollama pull で指定するタグ名が異なります。取得時にエラーが出る場合は、Ollama公式ライブラリで正確なタグ名を確認してください。

Phi-4（Microsoft）

Microsoftが公開する小規模・高効率モデルです。Phi-4は14Bパラメータ規模ながら、要約や定型処理などのタスクで規模以上の性能を発揮します。約8GB以上のVRAMから動作し、低スペックGPUでも実用的に使える点が大きな強みです。
軽量・高速に倒したい場面や、GPUのVRAMが限られている環境での第一候補になります。

VRAM早見表（4bit量子化前提の概算）

ここまでの主要モデルを、必要VRAMの目安でまとめます。数値は4bit量子化前後の概算で、量子化度・コンテキスト長・実装により実値は前後します。あくまで選定の目安としてご覧ください。

モデル	目安VRAM	向いている用途
Mistral（7B）	約4～6GB～	バランス型。コード補助や文章生成に広く使える
Phi-4（14B）	約8GB～	軽量・高速。要約や定型処理、低スペックGPU向け
Gemma 3	約8GB～	軽量で日本語も実用的。汎用的な社内アシスタント
Gemma 4	約16GB～	Gemma 3の上位。より高い精度が必要な業務向け
Llama3.3（70B）	約40GB～	高精度。複雑な推論や長文処理、品質重視の用途

VRAMが不足するモデルを無理に動かすと、CPUにオフロードされて極端に遅くなります。まずは手持ちGPUのVRAMに収まる軽量モデルで試し、精度が足りなければ上位モデルへ段階的に切り替えるのが現実的です。

用途別の使い分け指針と切り替えコマンド

モデルの特徴が分かったら、次は「どの用途にどのモデルを使うか」です。Ollamaならモデルの切り替えは ollama run モデル名 を変えるだけなので、複数のモデルを取得しておき、用途に応じて使い分けるのが効率的です。

まず、取得済みモデルの一覧は ollama list で確認できます。
出力例です。複数モデルを取得しておけば、用途ごとに即座に切り替えられます。

チャット・QA系

社内の問い合わせ対応や汎用的なアシスタント用途では、軽量で応答が速く、日本語も実用的なGemma 3が扱いやすい選択肢です。VRAMに余裕があり精度を上げたい場合はGemma 4やLlama3.3に切り替えます。

コード生成・レビュー

コードの生成やレビューでは、バランス型で軽快なMistralが使いやすく、要約や定型的なコード整形ならPhi-4も有力です。より複雑なロジックの設計や長いコードの読解が必要な場面では、精度の高いLlama3.3が向いています。

日本語文書処理

日本語の文書要約や校正など、日本語の自然さが重視される用途ではGemma 3／Gemma 4が扱いやすい傾向にあります。VRAMが許せばGemma 4で精度を上げ、軽量に処理したい場面ではGemma 3を選ぶ、という段階的な使い分けが現実的です。

ただし日本語の得手不得手はモデルのバージョンや用途で変わります。重要な業務に使う前に、自社の実データで複数モデルの応答を見比べて選ぶことを強くおすすめします。

「ollama pull」後にモデルがロードされない・OOMになる場合

モデルを取得して ollama run したものの、応答が返らない・途中でクラッシュする、といったトラブルは多くがVRAM不足（OOM／Out Of Memory）に起因します。順番に切り分ければ確実に解決できます。

VRAM不足クラッシュの確認コマンド（nvidia-smi・ログ）

まず nvidia-smi でGPUのVRAM使用状況を確認します。推論を実行した瞬間にVRAMが上限近くまで張り付くなら、そのモデルは手持ちGPUには大きすぎる可能性が高いです。
出力例です。Memory-Usage の値が総量に近づいているほど余裕がありません。
次に、Ollamaのサービスログを確認します。OOMが起きている場合、ログに out of memory やメモリ確保失敗の記録が残ります。
ログに out of memory 相当のメッセージや、GPUからCPUへフォールバックした旨の記録があれば、そのモデルはVRAMに収まっていません。次の量子化モデルへの切り替えを検討します。

量子化モデル（-q4_0・-q8_0）への切り替え方

量子化（quantization）とは、モデルの重みデータをより少ないビット数で表現してファイルサイズとVRAM消費を抑える技術です。たとえば16bitを4bitに落とせば、単純計算で重みのメモリ使用量は約4分の1になります。精度はわずかに下がりますが、多くの実務用途では十分実用的です。

Ollamaでは、モデル名のバリエーションタグとして量子化版（例 7b-instruct-q4_0）を指定することで、軽い版を取得できます。代表的なサフィックスは -q4_0（4bit）と -q8_0（8bit）です。-q4_0 のほうがVRAM消費は小さく、-q8_0 は精度寄りです。
注意点として、すべてのモデルにすべての量子化タグが用意されているわけではありません。-q4_0 等を指定して取得できない場合は、そのモデルで提供されている量子化バリエーションをOllama公式ライブラリで確認してください。

それでもVRAMに収まらない場合は、モデル自体を一つ小さいものに変えるのが確実です。たとえばLlama3.3（70B）で動かないなら、Gemma 3やMistralといった軽量モデルへ切り替えれば、同じGPUでも安定して動作します。「無理に大きいモデルを動かす」より「用途に足りる軽いモデルを選ぶ」ほうが、結果的に実用的なケースは多いものです。

本記事のまとめ｜モデル選定チェックリスト（2026年版）

本記事のモデル情報は2026年6月時点のものです。ローカルLLMは進化が速いため、最新モデルやタグ名は各モデルの公式ドキュメントとOllama公式ライブラリも合わせてご確認ください。

ローカルLLMのモデル選定は、次の早見表の流れで進めれば失敗しにくくなります。

判断ポイント	コマンド／目安	選定の指針
搭載VRAMの確認	nvidia-smi	右側の総量が選べるモデルの上限を決める
軽量から試す	ollama pull mistral	まずMistralやGemma 3・Phi-4で動作確認
用途で切り替え	ollama run gemma3	チャットはGemma系、コードはMistral/Llama
精度を上げる	ollama run llama3.3	VRAMに余裕があればGemma 4・Llama3.3へ
OOM時の確認	journalctl -u ollama -n 50 --no-pager	out of memoryならVRAM超過を疑う
量子化で軽量化	ollama pull mistral:7b-instruct-q4_0	-q4_0でVRAM消費を下げ、-q8_0は精度寄り
取得済み一覧	ollama list	複数取得し用途で切り替えるのが効率的

モデル選定の基本は「VRAMに収まる範囲で、用途に合った最大のモデルを選ぶ」ことに尽きます。最初から最上位モデルを狙うのではなく、軽量モデルで動作と用途適合を確認し、必要に応じて段階的に上位モデルや量子化版へ切り替えていく。この進め方を押さえておけば、モデルが多すぎて選べないという悩みは解消できるはずです。
ローカルLLMの導入を社内で検討している方向けの記事もあります。あわせて参考にしてください。

・社内でChatGPTが使えない時のローカルLLM代替策（情シス担当者向け）

---

• 次のページへ：Ubuntu ServerでGPUを使ってローカルLLMを動かす方法｜nvidia-smi・CUDA・ドライバ導入で挫折しない手順
• 前のページへ：Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
• この記事の属するカテゴリ：ローカルLLMへ戻る