こんにちは、ローカル LLM 選びで毎回モデル名の海におぼれていたアーキテクトのやまぱんです 😅
ChatGPT や Copilot が便利すぎて、ローカル LLM は「実用というよりロマン」のままになっていませんか？私もそうでした。
ただ最近、quant（量子化形式）の進化が早すぎて、家庭用 GPU でも 27B / 30B クラスが本気で実用ラインに乗ってきた ので、改めて「自分のマシンで結局何が動くんだっけ？」を真面目に整理してみました。
その整理を 1 コマンドで殴れる OSS CLI が whichllm です。
この記事では、whichllm を RTX 4060 Ti 16GB 環境で実際に試した結果と、Windows 環境で踏みやすい落とし穴、GPU 買い替えシミュレーションまでまとめます。
Contents
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-27BQ3_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ほか） だけ事前にやっておくと、出力が文字化けせずに済む。
⚠️ 表示される
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 も合わせて入れておくと、出力が壊れずに表示されます。
💡 この
.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 の差 を計ってみたいなと思っています。やったら別記事でまとめますね。
参考
この記事の Qiita 版はこちら: ローカル LLM 選び、もう「VRAM に入る一番デカいやつ」で決めるの卒業しよ？ - whichllm を RTX 4060 Ti 16GB で測ってみた - Qiita