こんにちは、ローカル LLM 選びで毎回モデル名の海におぼれていたアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！

間違っていたら 優しく 教えてください！

TL;DR

whichllm は 「自分の GPU / CPU / RAM で実際に実用的に動くローカル LLM」 を、HuggingFace の最新候補から自動でランキングしてくれる CLI です。
「VRAM に入る最大モデル」ではなく、ベンチマーク score・推定 tok/s・quant（量子化形式）・fit type（Full GPU / Partial / CPU） をまとめて評価してくれるのがポイント。
私の RTX 4060 Ti 16GB / Ryzen 7 8700G / RAM 61.6GB で実際に回したら、通常用途は Qwen3.6-27B Q3_K_M、coding は Qwen3-Coder-30B-A3B が Full GPU で現実的という結果になりました。
70B 級は Q4_K_M で約 44.2GB 必要で、家庭用 24GB / 32GB クラスでは足りず 48GB クラス（例: L40S）が最低ライン と表示されました。
Windows + PowerShell では UTF-8 化（PYTHONUTF8=1 ほか） だけ事前にやっておくと、Rich の罫線で文字化けせずに済みます。

⚠️ 表示される tok/s や score はあくまで whichllm の 推定/ランキング値 です。実測値ではない点を踏まえて、購入判断や検証の 初速を上げる材料 として使うのがおすすめです。

ℹ️ 記事中のモデル名（Qwen3.6-27B や Qwen3-Coder 30B-A3B など）は whichllm が集約している HuggingFace 候補のうち、私の環境でトップに来たものを抜粋しています。whichllm の表示名と HuggingFace 上のリポジトリ名が完全一致しないケースもあるので、実際にダウンロードするときは Qwen/... などのオーガナイゼーション名から探すのが安全です。

なんで whichllm？「結局どれ動くの問題」を 1 コマンドで殴る

ローカル LLM、楽しいんですけど、毎回こうなりませんか？

HuggingFace で新モデルを見つけてワクワクする
VRAM 計算機を叩く
GGUF の Q3_K_M と Q4_K_M どっち？（なお Q3_K_M / Q4_K_M は 量子化形式。数字が小さいほど VRAM は軽いが品質は落ちる）で 10 分悩む
「で、結局自分のマシンで何が気持ちよく動くんだっけ…？」

whichllm（作者は @Andyyyy64 さん）は、ここを 「ハード自動検出 → モデルランキング → 必要 VRAM 試算」まで一発 でやってくれる OSS の CLI です。

私がいいなと思ったのはこの 3 点。

ベンチ score と推定速度を同時に出す: ただ「フィットするか」だけじゃない。「フィットするけど遅すぎる」モデルは自動で落とせます。
--gpu で買う前のシミュレーションができる: 「RTX 5090 買ったら何が動く？」「2x RTX 4090 だったら？」を実機なしで試せる。
plan / upgrade サブコマンドが便利: 「Llama 3 70B 動かすには何 GB 必要？」「4090 → 5090 で何が変わる？」が即答できる。

公式 README 曰く、たとえば RTX 4090 環境では Qwen3-32B がフィットするにもかかわらず Qwen3.6-27B が #1 として推されます。「サイズが入る = 最良」ではないことを、ベンチ score でちゃんと殴ってくれるんですよ～！

セットアップ：uv で 1 分（Windows / RTX 4060 Ti 16GB）

私はワークスペース配下に普通に clone して、Astral 製の高速パッケージマネージャ uv で仮想環境を作りました。Mac / Linux でも手順は同じです（文字化け話は Windows 限定なので、次の章は飛ばして OK）。

# 任意のフォルダで
git clone https://github.com/Andyyyy64/whichllm.git
cd whichllm

# uv で .venv セットアップ（dev 依存も一緒に入れる）
uv sync --dev

# 動作確認（.venv 内で whichllm を走らせる）
uv run whichllm --help

⚠️ README は uv sync --dev 表記、新しい uv では uv sync --group dev（pyproject.toml の [dependency-groups] を参照）も使えます。どちらでも OK。

💡 ボタン 1 発のお試しなら uvx whichllm@latest でもいけます。こちらはインストール不要で常に最新が走るので、買い替え検討時の「とりあえず叩いてみる」用にはこっちの方が手軽です。

検出された環境はこんな感じでした。

項目	値
GPU	NVIDIA GeForce RTX 4060 Ti 16GB
iGPU	AMD Radeon 780M Graphics
CPU	AMD Ryzen 7 8700G
RAM	約 61.6GB
OS	Windows 11
CUDA	13.1

Windows で踏みやすい落とし穴 2 つ

ここは記事として残しておきたかった部分です。Mac / Linux の記事だと出てこないけど、Windows + PowerShell だと そこそこ確実に踏む やつ。

① `cp932` で Rich が UnicodeEncodeError になる

whichllm は出力に Rich を使っています。
PowerShell の既定エンコーディング cp932 だと、罫線や記号で UnicodeEncodeError を出して止まることがあります。

実行前にこれだけ流しておけば OK。

$env:PYTHONUTF8 = '1'
$env:PYTHONIOENCODING = 'utf-8'
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

ターミナル単位で固定したい場合は、.vscode/settings.json の terminal.integrated.env.windows に書いておくと毎回有効になります。

{
  "python.defaultInterpreterPath": "${workspaceFolder}\\.venv\\Scripts\\python.exe",
  "terminal.integrated.env.windows": {
    "PYTHONUTF8": "1",
    "PYTHONIOENCODING": "utf-8"
  }
}

② symlink を使うテストが `WinError 1314` で 3 件落ちる

uv run pytest を走らせると、tests/test_asahi_detection.py まわりで Path.symlink_to が WinError 1314: クライアントは要求された特権を保有していません で落ちました。

これは 依存不備ではなく Windows の symlink 権限 の問題で、

Windows の 開発者モードを ON にする、または
管理者権限のシェルで実行する

のどちらかで通ります。本体の CLI 動作には影響しないので、私は dev mode ON のまま使っています。

実行結果 ①：通常用途と coding 用途で「顔が変わる」

ここからが本番。whichllm を引数なしで叩くと、検出した自分のマシン向けに上位候補を出してくれます。私の RTX 4060 Ti 16GB 環境では、Full GPU 限定・速度 usable 以上で次のような結果になりました。

# 通常用途
uv run whichllm --fit full-gpu --speed usable --top 8

# coding 特化（--profile coding で絞り込み）
uv run whichllm --profile coding --fit full-gpu --speed usable --top 5

通常用途のトップは Qwen/Qwen3.6-27B の Q3_K_M、coding 用途のトップは Qwen/Qwen3-Coder-30B-A3B-Instruct の Q3_K_M。並べるとこう。

用途	トップ候補	quant	必要 VRAM	推定速度	score
通常	`Qwen/Qwen3.6-27B`	Q3_K_M	約 14.7GB	約 11.8 tok/s	85.6
coding	`Qwen/Qwen3-Coder-30B-A3B-Instruct`	Q3_K_M	約 13.8GB	約 109.7 tok/s	79.2

ℹ️ 通常用途の値は flow / map の図でも同じです。coding 行の score 79.2 と -Instruct 接尾は、図には載らない実機 whichllm 出力から取りました。--profile coding を付けて手元で叩くと再現できます。

面白いのはこの 2 点。

16GB VRAM に収まる範囲だけ見ても、通常 27B 級・coding 30B (MoE) 級が現実ライン に乗ってきている。一年前は「16GB で 27B Full GPU」なんて発想なかったので、quant の進化を素直に体感しました。
パッと見「coding の方が 10 倍速いの？」と思いますが、これは Qwen3-Coder-30B-A3B が MoE (Mixture of Experts) で active params が少ない から。whichllm は 速度を active params、品質を total params で見るとドキュメントに明記されていて、整合性が気持ちよくとれています。

📚 参考: whichllm README の "See it" 節

Note #3: a MoE model at 102 t/s — speed is ranked on active params, quality on total.

実行結果 ②：70B 級と GPU upgrade を `plan` / `upgrade` で見る

「結局 70B 級ってどこから現実なん？」を 1 行で出せるのが plan サブコマンド。

uv run whichllm plan "llama 3 70b"

結果は meta-llama/Llama-3.3-70B-Instruct Q4_K_M で必要 VRAM 約 44.2GB。Full GPU で載せるための最低ラインとして 48GB クラス（例: L40S） が示され、RTX 4090（24GB）・RTX 5090（32GB）は partial offload 扱い（一部 CPU/RAM に逃がす）になります。

そのまま upgrade で 4060 Ti → 4070 Ti SUPER → 4090 → 5090 を比較してみます。

uv run whichllm upgrade "RTX 4070 Ti SUPER" "RTX 4090" "RTX 5090" --top 1

同じ Qwen3.6-27B を回したときに、quant と推定 tok/s がどう変わるかが横並びで出ます。

GPU	VRAM	quant	Quality	推定 tok/s	一言
RTX 4060 Ti（Current）	16GB	Q3_K_M	85.6	12	Baseline / 今でも実用圏
RTX 4070 Ti SUPER	16GB	Q3_K_M	88.3 (+2.7)	28 (+16)	速度改善が主役
RTX 4090	24GB	Q5_K_M	92.4 (+6.7)	27	量子化品質が上がる
RTX 5090	32GB	Q6_K	94.3 (+8.7)	40 (+28)	品質も速度も明確に伸びる

4090 で 量子化が一段上がって品質が伸び、5090 で 品質と速度の両方が伸びる、という方向性がはっきり見えるのが好きです。「とりあえず最新を買う」ではなく、手元のモデルを基準に何が改善するか をシミュレーションできるのは、買い替え判断としてかなり強い。

⚠️ ここで出る数値は whichllm の推定/シミュレーション で、実機ベンチではありません。比較は同一 CPU / RAM 前提です。購入判断の "初速" を上げる材料として読むのが安全。

whichllm のスコアリング、ざっくり中身を読んでみた

「結局なんで 32B より 27B が上位なん？」が気になって、src/whichllm/ を覗いてみました。フォルダ構成は次のような感じ。

src/whichllm/
├── cli.py        # Typer ベースの CLI
├── constants.py
├── engine/       # スコアリング / ランキングロジック
├── hardware/     # GPU / CPU / RAM 検出
├── models/       # HuggingFace のモデル候補集約
├── data/
└── output/       # Rich を使った表示

ざっくり読むと、ランキングは

hardware/ で実マシン（あるいは --gpu で指定された仮想マシン）の VRAM / RAM / GPU 数を確定
models/ で候補モデル × quant の組を列挙し、各組の必要 VRAM を試算
engine/ で「fit type（Full GPU / Partial / CPU）」「推定 tok/s」「ベンチ score」を組み合わせて総合スコアにする
表示時に --speed や --fit でフィルタする

という流れになっています。
だから「サイズが大きい = 高 score」じゃなく、新世代モデルや高品質 quant が上位に来るんですね。
ここ、自前で計算機を作るとめちゃくちゃ面倒なので、CLI 一発で済むのは本当に偉い。

VS Code から使いやすくする：ローカル task に登録

毎回ターミナルでフラグを思い出すのも辛いので、ワークスペース直下に小さな task を仕込んでおきました。

// .vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "whichllm: hardware",
      "type": "shell",
      "command": "uv",
      "args": ["run", "whichllm", "hardware"],
    },
    {
      "label": "whichllm: top models",
      "type": "shell",
      "command": "uv",
      "args": [
        "run",
        "whichllm",
        "--fit",
        "full-gpu",
        "--speed",
        "usable",
        "--top",
        "8",
      ],
    },
    {
      "label": "whichllm: coding models",
      "type": "shell",
      "command": "uv",
      "args": [
        "run",
        "whichllm",
        "--profile",
        "coding",
        "--fit",
        "full-gpu",
        "--speed",
        "usable",
        "--top",
        "5",
      ],
    },
    {
      "label": "whichllm: plan llama 3 70b",
      "type": "shell",
      "command": "uv",
      "args": ["run", "whichllm", "plan", "llama 3 70b"],
    },
  ],
}

ここに UTF-8 環境変数を効かせるため、.vscode/settings.json も合わせて入れておくと、Rich の罫線が壊れずに表示されます。

💡 この .vscode/ は upstream リポジトリの .gitignore 対象なので、ローカル専用設定として残しておけます。fork せずに使えるのは地味にうれしい。

触ってみてのまとめ

ローカル LLM の世界、モデルも quant もハードも動きが速くて、半年前の感覚で選ぶと普通に外します。
whichllm を触ってよかったのは、「動く / 動かない」だけでなく「気持ちよく動くか」までを 1 コマンドで返してくれる こと。

私の RTX 4060 Ti 16GB という、お手頃 GPU の枠で見ても

通常用途で 27B 級、coding で 30B (MoE) 級まで Full GPU に乗る
70B 級は素直に CPU offload するか、48GB 級の GPU を見るしかない

という現実ラインがはっきり見えました。
これ、買い替え検討にも、案件で「ローカル LLM どこまで現実？」って聞かれたときの初速にも、めちゃくちゃ効きます。

次は whichllm run で実際に 7B / 14B クラスを引っ張ってきて、推定 tok/s と実測 tok/s の差 を計ってみたいなと思っています。やったら別記事でまとめますね～！

参考