whichllm

whichllm 一見難しいローカル AI の質問に答えます。どのモデルと量子化が、この特定のコンピューターで最高の有用な品質を提供する可能性がありますか? GPU、CPU、RAM、ストレージを検出し、現在の Hugging Face 候補を収集し、ランタイムの適合性と生成速度を推定し、それらの制約をベンチマークの証拠と組み合わせます。結果はランク付けされた開始点であり、最初のモデルがすべてのプロンプトに対して最適であることを保証するものではありません。

whichllm の違い

基本的なモデル ピッカーは、VRAM に収まるパラメータの数を尋ねます。 whichllm は、これを 1 つの制約のみとして扱います。そのドキュメントでは、人気のある、最近変更され、厳選されたモデルを Hugging Face から取得するパイプラインについて説明しています。関連するリポジトリをモデル ファミリーにグループ化します。利用可能な量子化を評価します。重み、KV キャッシュ、アクティベーション、フレームワークのオーバーヘッドを推定します。フル GPU、部分オフロード、または CPU の適合性をチェックします。次に、正規化されたベンチマーク証拠を使用して候補をランク付けします。

実行可能な最大のファイルが自動的に最適な選択になるわけではないため、これは重要です。新しい 27B モデルは古い 32B モデルよりも優れたパフォーマンスを発揮する可能性があり、専門家が混在したモデルは総パラメーター数が示すよりも速く生成でき、技術的に適合するモデルでもデスクトップ、コンテキスト キャッシュ、またはランタイムのヘッドルームが少なすぎる可能性があります。 whichllm は、これらのトレードオフを 1 つの「推奨」バッジで隠すのではなく、コントロールを公開します。

クイックスタートとより安全な最初のコマンド

uvx whichllm@最新

# 保守的な最初のパス: 完全な GPU 適合、使用可能な速度、1 GB のヘッドルーム
uvx whichllm@latest --gpu-only --speed used --vram-headroom 1GB

# 購入前にハードウェアをシミュレートする
uvx whichllm@最新 --gpu "RTX 4090"

# アップグレード候補を比較する
uvx whichllm@最新アップグレード「RTX 4090」「RTX 5090」「H100」

デフォルトのランキングは意図的に野心的であり、ニアエッジ VRAM フィットや部分的な RAM オフロードが含まれる場合があります。プロジェクトのセーファーピック コマンドは、予測可能な応答性を重視するユーザーにとって、より優れた初期フィルターです。別のランタイムがまだメモリ不足を報告している場合は、推定値が間違っていると仮定するのではなく、ヘッドルームを増やす、要求されたコンテキストを短くする、より小さい量子化を選択する、またはバックグラウンドの VRAM の使用状況を検査してください。

レコメンデーションパイプラインの仕組み

証拠ラベルを読む

whichllm は、LiveBench、Artificial Analysis、Aider などの現在のソースを、Open LLM Leaderboard v2 や Chatbot Arena カバレッジなどの古い凍結ソースとマージします。スコアは正規化され、古い証拠はモデルの系統によって降格されるため、古いスコアが黙って新しい世代を上回ることはありません。これは便利ですが、マージされたベンチマークは依然として他の人のタスクの組み合わせを表します。

また、候補者のパラメータ数がそのファミリー参照から大きく乖離している場合、プロジェクトは一部の疑わしい継承を拒否します。これにより、小さなドラフト ヘッドがはるかに大きなベースのベンチマークを借用するなどのエラーが軽減されますが、自動化された命名およびメタデータ パイプラインではすべての異常なフォークを識別することはできません。

フィット、コンテキスト、量子化は結合されています

モデルの重みはメモリ使用の始まりにすぎません。コンテキストが長くなると、KV キャッシュの需要が増加します。同時リクエストは実行時の状態を倍増します。ビジョン入力と大規模なバッチによりプレッシャーが加わります。デスクトップ ディスプレイのワークロードは VRAM を消費します。また、フレームワークの割り当てによりメモリが断片化される可能性があります。 4K コンテキストに対して生成された推奨事項は、同じ量子化が 64K コンテキストまたは複数のユーザーにサービスを提供するという証拠ではありません。

量子化により 2 番目のトレードオフが生じます。通常、ビット数が少ないと重みメモリが減り、スループットが向上する可能性がありますが、品質の低下はアーキテクチャ、タスク、量子化器間で均一ではありません。 whichllm はランキングの一部として量子化ペナルティを適用しますが、ユーザーは、実行する予定のプロンプトに対して、少なくとも 2 つの隣接するバリアント (多くの場合、保守的な中程度の量子化と小規模なフォールバック) を比較する必要があります。

実践的なローカルモデル選択ワークフロー

1. まず仕事を書きます。 チャット、コーディング、抽出、ビジョン、多言語作業または数学を指定します。ターゲットコンテキスト。許容可能な遅延。データをオフラインにしておく必要があるかどうか。
2. マシンを記録します。 正確な GPU とメモリ、利用可能な RAM、オペレーティング システム、ドライバー/バックエンド、空きディスク、バックグラウンド GPU の使用状況をキャプチャします。
3. 保守的な候補リストを作成します。 から始める --GPU のみ --速度は使用可能 --vram-headroom 1GB。使用する --プロフィール, --コンテキストの長さ そして --quant 実際のワークロードに合わせて。
4. 自信を検査します。 スコアが近い場合は、直接証拠または変形証拠を優先します。スナップショットの日付、推定速度マーカー、部分オフロードの警告に注意してください。
5. 3人の候補者を立てます。 最上位の推奨事項、隣接するモデルまたは量子化、およびより小さい高速ベースラインをテストします。 1 つの結果だけでは、コストと品質のフロンティアを明らかにすることはできません。
6. プライベート評価セットを使用します。 代表的なプロンプト、特殊なケース、拒否の予想、必要な言語、構造化された出力スキーマ、および長いコンテキストの取得を含めます。
7. 補正後に計測します。 成功した回答、人による修正時間、1 秒あたりのトークン、最初のトークンの待ち時間、ピーク メモリ、ロード時間、関連するエネルギーを追跡します。
8. デプロイメントを凍結します。 正確なリポジトリ、リビジョン、ファイル名、量子化、ランタイム、コンテキスト設定、およびプロンプト テンプレートを保存します。モデル名だけでは再現できません。

デフォルトランキングを超えた便利なコマンド

whichllm が誤解を招く可能性がある箇所

• 推定速度はマシンのベンチマークではありません。 バックエンドのバージョン、クロック、温度制限、プロンプト処理、オフロード構成によってパフォーマンスが変化する可能性があります。
• 総合的な品質により、タスクの失敗が隠されます。 一般スコアが高いからといって、言語、コードベース、検索コーパス、JSON の信頼性や安全性ポリシーを予測できない場合があります。
• リポジトリのメタデータは不完全である可能性があります。 パラメーター数、基本モデルのリンク、ライセンス、変換品質は、Hugging Face に統一的に文書化されていません。
• ライブソースは失敗したり形状が変化したりする可能性があります。 このツールはデータをキャッシュし、厳選されたスナップショットにフォールバックできます。表示される新鮮さと自信を常に読んでください。
• ダウンロードはサプライチェーンのアクションです。 モデルまたは Python アーティファクトを実行する前に、リポジトリの所有権、ファイル、リモート コードの要件、ライセンス、ハッシュを確認してください。
• 1 ユーザーの適合性は処理能力ではありません。 同時実行、バッチ処理、コンテキストの増大、稼働時間の要件には、実際の負荷テストが必要です。

代替案とその方が優れている場合

決定スコアカード

候補ごとに、タスクの合格率、修正分、最初のトークンのレイテンシー、1 秒あたりの生成トークン、ピーク VRAM/RAM、ロード時間、使用されたコンテキスト、構造化出力の有効性、ライセンス、モデルの出所、および証拠のグレードを記録します。テスト前にメトリクスに重みを付けます。コーディング チームはプライベート リポジトリの精度と JSON/ツールの信頼性を優先する場合がありますが、ラップトップ アシスタントはメモリのヘッドルーム、バッテリー、対話速度を優先する場合があります。

よくある質問

whichllm は、推奨事項をリクエストしたときにモデルをダウンロードしますか?

ランキング フローでは、すべての候補をダウンロードするのではなく、モデルのメタデータをフェッチしてキャッシュします。の 走る ワークフローは選択したモデルをダウンロードして起動できるため、使用する前にディスク容量、リポジトリの信頼性、実行時の依存関係を確認してください。

1 位の結果は適合することが保証されていますか?

すべての実行時構成を保証できる推定ツールはありません。余裕を残し、検出されたハードウェアとコンテキストを確認してから、正確なファイルとバックエンドをテストします。予測可能性が重要な場合は、フル GPU と速度フィルターを使用します。

GPUの選択に役立ちますか?

はい。 GPUシミュレーション、 計画 そして アップグレード 候補のハードウェアを比較できます。出力を計画の証拠として扱い、価格、電力、シャーシ、ドライバー、実際のベンチマークの制約を個別に確認します。

Apple Silicon および CPU のみのシステムをサポートしますか?

このプロジェクトでは、Apple Silicon、NVIDIA、AMD、Intel、および CPU の検出について文書化しています。 Apple Silicon および CPU のみのランキングは、実行時の安定性のために GGUF に制限されています。実際のパフォーマンスは、チップ、メモリ帯域幅、バックエンドのビルドによって異なります。

結果を自動化に使用できますか?

はい。 JSON 出力には、モデル ID、適合、推定メモリ、速度のメタデータが含まれます。ライブモデルインベントリとベンチマークデータによって上位の結果が変わる可能性があるため、バージョンを固定し、検証を追加します。

whichllm 自体がモデルランナーですか?

その主な価値は選択と計画です。の 走る コマンドは分離環境を作成し、サポートされているランタイムを呼び出すことができますが、進行中のデプロイには Ollama、llama.cpp、またはサービング スタックなどの専用ツールの方が適している場合があります。

公式情報源

• whichllm 公式 GitHub リポジトリと README
• 公式アーキテクチャとデータパイプラインのドキュメント
• 公式採点ドキュメント
• 公式ハードウェア検出とシミュレーションに関するドキュメント
• 公式の実行とコードスニペットのワークフロー
• 公式リポジトリの MIT ライセンス
• Hugging Face モデル カタログはライブ候補発見に使用されます

最終レビュー日は 2026 年 7 月 25 日です。モデル インベントリ、ベンチマーク スナップショット、ランタイム互換性、およびハードウェア価格が変更されます。決定する前に、現在の CLI を再実行し、正確なモデル アーティファクトを検証してください。