まずモデルファミリーを見て、次に実行可能なファイルを確認する
ローカルLLMは、Qwen、Llama、Mistral、Gemma、DeepSeek、Phi、Yiのようなブランド名だけで決まるものではありません。名前は通常モデルファミリーを指しますが、実際に実行するファイルは、instructチューニング、codingチューニング、visionバリアント、GGUF変換、またはコミュニティ公開者が作成した量子化ビルドである場合があります。同じモデルファミリーの2つのファイルでも、プロンプトテンプレート、コンテキスト長、量子化方式、ランタイム上の前提が異なるため、挙動が変わることがあります。
推薦ツールにとって有用な問いは、単に「このモデルは人気か？」ではありません。より良い問いは「このユーザーのメモリ、速度の期待値、タスクに合う実行可能なバリアントはどれか？」です。Hugging Faceでは同じモデルに対して多数のファイルが表示されることがあり、ローカルツールではその一部しか扱えない場合もあります。そのためLocal LLMでは、モデル名ひとつにすべてをまとめるのではなく、モデルの識別情報、ファイル形式、量子化、ハードウェア適合性を別々のシグナルとして扱うべきです。
パラメータ数は大まかな品質シグナルであり、完全な答えではない
パラメータ数を見ると、規模感をすばやく把握できます。1Bや3Bモデルは実行しやすく、軽量なチャット、書き換え、要約、簡単なコード説明に役立ちます。7Bや8Bモデルは、日常的により強い回答を得るための実用的な入口になることがよくあります。14Bモデルは通常より多くのメモリを必要としますが、より高い能力を感じられる場合があります。30B、70B、さらに大きいモデルは難しい推論やコーディングで大幅に優れることがありますが、高VRAM、大容量の統合メモリ、またはmulti-GPUの領域に入ります。
ただし、パラメータ数だけでは全体像は分かりません。新しい7Bモデルが、多くのタスクで古い13Bモデルを上回ることがあります。coding向けにチューニングされた7Bモデルは、より大きな汎用チャットモデルより開発用途で役立つ場合があります。MoEモデルでは総パラメータとactive parametersが異なるため、さらに複雑です。そのため推薦では、単に最大モデルを最上位に並べるのではなく、ベンチマーク品質、用途、active parameters、コンテキスト要件、メモリ適合性を組み合わせるべきです。
GGUF、safetensors、ツール対応が実際に実行できるものを決める
多くのローカルデスクトップユーザーは、llama.cppベースのツールで扱いやすく、Hugging Faceで広く入手できるため、GGUFファイルを探します。GGUFはローカル推論向けに設計された形式でモデル重みとメタデータをまとめ、Hugging FaceはGGUFファイルの閲覧とホスティングに対応しています。他のリポジトリではsafetensors重みが公開されており、Transformers、vLLM、またはローカルデスクトップ利用前の変換を想定している場合があります。どちらも正当な形式ですが、対象とするワークフローが異なります。
これはユーザーにとって重要です。モデルページが魅力的に見えても、ローカルで実行するには不便な場合があるからです。Ollama、LM Studio、llama.cpp、MLX、Transformers、vLLMは、まったく同じモデル読み込み経路を提供しているわけではありません。良い推薦結果は、ソースページへの参照を示し、そのモデルにローカル向けのファイルがあるかを表示し、すべてのHugging FaceリポジトリがノートPCで同じように簡単に実行できるかのように示すことを避けるべきです。
量子化はメモリ使用量と品質を変える
量子化はモデル重みの精度を下げることで、ファイルを小さくし、読み込みやすくします。Q8は高品質に近い一方で、より多くのメモリを使います。Q6とQ5は多くの場合、有用な中間点です。Q4は、より大きなモデルを一般向けハードウェアに収めるための一般的な入口です。Q3以下はメモリが厳しい状況で役立つことがありますが、特にコーディング、数学、ツール利用、長い回答では品質のトレードオフが目立ちやすくなります。
適切な量子化は、モデルとタスクの両方に依存します。ユーザーが高速なカジュアルチャットを求めるなら、Q4で十分な場合があります。コーディングや慎重な推論を求めるなら、Q5、Q6、Q8に追加メモリを使う価値があるかもしれません。長いコンテキストを求める場合、最小のモデルファイルだけでは不十分です。システムにはKV cacheとランタイムのオーバーヘッド用メモリも必要です。Local LLMは、選択された量子化とメモリ内訳を表示し、なぜその推薦が適合するのかをユーザーが理解できるようにするべきです。
コンテキスト長、vision、特殊なチューニングが推薦を変える
コンテキスト長はモデル固有ですが、実際に使えるコンテキストはハードウェア固有です。モデルが大きなコンテキストウィンドウをうたっていても、会話や文書が長くなるにつれてKV cacheは増えます。その追加メモリによって、モデルが完全なGPU実行から部分的なCPUオフロードに移ることがあります。RAG、コードベース分析、長文文書の読解では、かろうじて読み込める大きなモデルより、メモリに余裕のある小さめのモデルの方が適している場合があります。
専門的な能力も重要です。Visionモデルには画像エンコーダーとマルチモーダル対応が必要なため、一般スコアが高くても、text-onlyモデルを画像タスクに推薦すべきではありません。Codingモデルはroleplayモデルとは別の基準で評価する必要があります。数学や推論モデルには、より慎重な品質しきい値が必要な場合があります。したがって最良のローカルモデルは、モデル能力、ファイルバリアント、量子化、コンテキスト目標、ユーザーのハードウェアの組み合わせによって決まります。
FAQ
GGUFモデルはローカルLLMに常に優れていますか？ 常にそうではありません。GGUFはllama.cppスタイルのローカル推論では非常に便利ですが、サーバーワークフロー、学習、特殊なランタイムではsafetensorsや他の形式の方が適している場合があります。
収まる中で最大のモデルを選ぶべきですか？ 自動的にそうとは限りません。ぎりぎり収まるだけだと、速度やコンテキストの安定性が悪い場合があります。Q5またはQ6で、十分なメモリ余裕がある少し小さなモデルの方が、日常利用では快適に感じられることがあります。
なぜツールによって推薦モデルが違うのですか？ 対応する形式、量子化レベル、GPUバックエンド、コンテキスト既定値、モデルカタログが異なる場合があるからです。ツール対応も推薦の一部です。
これを読んだ後、Local LLMをどう使えばよいですか？ VRAM、RAM、オペレーティングシステム、用途、好みを入力してください。ツールはモデル名を暗記させるのではなく、現在のモデルバリアントを順位付けできます。