「ローカルLLMを始めてみたい。でも、自分のPCで結局どのモデルが動くのか分からない」——ローカルLLMに触れる誰もが最初にぶつかる壁です。llmfit は、この「動く/動かない問題」をターミナルの1コマンドで解決するRust製のOSSです。GPU・VRAM・RAMを自動検出し、数百のモデルから「今のあなたのマシンで快適に動くもの」をスコア付きで一覧表示します。★は34,972(2026-09-07時点)。

ONE COMMANDllmfitがやること

モデルを動かす前に何を入れるべきかを決める

  1. ハードを検出

    GPU・VRAM・RAM・CPU・バックエンド

  2. モデルDBと照合

    数百モデル × 量子化違い

  3. 4軸で採点

    quality・speed・fit・context

  4. 一覧で提示

    Fit と推定 tok/s。実行は Ollama 等へ

出典: AlexsJones/llmfit README(2026-09-07時点、v1.1.14)

30秒でわかるllmfit

  • ・モデルを実行するのではなく、ハードを検出して「今のPCで動くローカルLLM」を判定する診断ツール
  • ・brew install llmfit で入れて llmfit と打つだけ。数百モデルが Fit=Perfect / Good / Too Tight と推定tok/sで並ぶ
  • ・p キーのPlanビューで、GPU・CPUオフロード・CPU-onlyの推定速度と「あと何GB足せば上がるか」まで分かる
  • ・llmfitで「何を入れるか」を決め、実行はOllama・LM Studioに任せる。前工程と後工程の関係
  • ・MIT・Rust製(コードの約81%)の単一バイナリ。v1.1.14(2026-09-03)まで活発に更新
llmfitのTUIデモ:ハードウェアを検出し、数百のモデルをFitスコア順に並べて表示する様子
llmfit を起動すると、CPU・RAM・GPUを検出したうえで、数百のモデルを Fit と推定tok/sで一覧表示する(出典: AlexsJones/llmfit README デモ)。

LLMの仕組みやローカル実行・量子化の全体像は LLMとは?仕組み・主要モデル比較・ローカル実行・量子化を一気にまとめる2026年版 にまとめています。本記事はその中の「最初にどのモデルを選ぶか」を解決するツールの解説です。

llmfitとは:ローカルLLMの「動く/動かない」を判定するRust製CLI

GitHubの説明文は「Hundreds of models & providers. One command to find what runs on your hardware.」。llmfitはモデルを実行しません。Ollamaのように推論を回すのではなく、その一歩手前の「そもそも何を入れるべきか」を決める工程を担い、実行は既存のランタイム(Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio)に委ねます。

従来は、動かしたいモデルのパラメータ数を調べ、量子化後のサイズを見積もり、GPUのVRAMと突き合わせ、KVキャッシュの分も足りるか電卓を叩く必要がありました。モデルは毎週のように増えるので、この照合に終わりがありません。llmfitはこれを自動化し、同じモデルでもQ4_K_M・AWQ・GPTQなど量子化違いを別々に評価して、GPU実行・CPUオフロード・CPU-onlyそれぞれの推定速度まで出します。いわば「ローカルLLM版のフィッティングルーム」です。

TUIのモデル一覧には「In」列があり、Ollamaなど各ランタイムにすでに導入済みのモデルにマーカー(OL / L / O など)が付くので、手元のモデルの中で最良はどれかも分かります。ランタイム別の使い勝手は Ollama 0.24でOpenAI Codex CLIがローカルLLMで動く も参考になります。

1コマンドで自分のマシンを判定してみる

# macOS / Linux(Homebrew)
brew install llmfit

# Windows(Scoop)
scoop install llmfit

# ワンライナー(公式インストーラ)
curl -fsSL https://llmfit.axjns.dev/install.sh | sh

# Python環境(uv / pip)
uv tool install -U llmfit

# Docker
docker run ghcr.io/alexsjones/llmfit

引数なしで llmfit と打つとTUIが立ち上がり、上部にマシンのスペック、その下に数百のモデルがスコア順で並びます。

llmfitのメイン画面。CPU・RAM・GPUのヘッダの下に、Score・tok/s・Quant・Mem%・Ctx・FitなどのカラムでモデルがFitスコア順に並ぶ
メイン画面。上部にハード情報(Intel Core Ultra 7 165H / RAM 46.1GB avail / GPU)、下部に493モデルが並ぶ。
カラム 意味
Score quality / speed / fit / context を統合した0〜100の総合スコア
tok/s あなたのマシンでの推定トークン生成速度
Quant 推奨される量子化(Q4_K_M / AWQ-4 / GPTQ など)
Mode 実行モード(GPU / MoE など)
Mem % 必要メモリが利用可能メモリに占める割合。100%超は赤字
Ctx 扱えるコンテキスト長(262k / 131k など)
Fit Perfect(余裕あり)/Good(快適)/Too Tight(メモリ不足で非現実的)
Use Case 得意用途(Coding / Chat / General)

操作はキーボードだけで、/ で検索、s で並び替え、f でFitフィルタ、Enter でモデル詳細、p でPlan表示。上部のフィルタバーで Provider・Use Case・Fit・Avail(導入済みか)を重ねれば、「今すぐ使えて、コーディングに向いていて、快適に動く」モデルだけが残ります。「llama 8b」で検索すると13/493件に絞られ、最下段の GPTQ量子化のモデルは Mem 162% で赤字の「Too Tight」になりました。

表示される数字はすべてあなたの環境での値です。同じ「Qwen3-Coder-30B」でも、64GBのマシンでは Fit=Good、16GBでは Too Tight と出ます。非対話のCLIとしても使え、スクリプトやCI/CDに組み込めます。

llmfit fit                              # ランキング表を非対話で出力
llmfit recommend --json                 # トップ候補をJSONで取得
llmfit info "Qwen/Qwen3-Coder-30B"      # 特定モデルの詳細(推定の前提も表示)
llmfit bench                            # 自分のマシンの実測tok/s
llmfit doctor                           # ハードウェア検出レポート

判定ロジックの中身:VRAM・RAM・量子化・メモリ帯域

判定は固定の閾値ではなくメモリ帯域モデルに基づく推定で、ランタイムでの実測サンプリングとコミュニティの計測データに裏打ちされています。llmfit info "<model>" で、その推定がどの前提から導かれたかを確認できます。

WILL IT FIT判定の骨格

どこに収まるかで、速度と Fit が決まる

必要メモリ = パラメータ数 × 量子化ビット + KVキャッシュ

  • VRAMVRAM に収まる Perfect / Good・高速GPUフル実行
  • +RAMRAMまで使う 低速だが動くCPUオフロード
  • ×収まらない 量子化を下げるか小型へToo Tight
出典: AlexsJones/llmfit README の判定ロジック(メモリ帯域モデル)。推定は llmfit info で前提を確認できる

・量子化がメモリを決める:同じ30Bでも、FP16なら約60GB、Q4量子化なら約17GB前後。量子化違いを別々に評価するのは「1段下げれば動く」という現実解を示すため
・VRAMに載るかで速度が段違い:収まらない分をRAM/CPUに逃がすオフロードでは、メモリ帯域がボトルネックになり速度が大きく落ちる
・KVキャッシュを忘れない:長いコンテキストほどメモリを食う。Ctxを軸に持つのは「本体は載るがコンテキストを伸ばすと溢れる」を見逃さないため

p キーのPlanビューは、特定モデルの最小ハード・推奨ハード・実行パスごとの速度・アップグレード提案を1枚にまとめます。

llmfitのPlanビュー。NousResearch/Hermes-3-Llama-3.1-8Bについて最小ハード・推奨ハード・GPU/CPUオフロード/CPU-onlyの実行パスと推定tps・アップグレード提案が表示されている
Planビュー(Hermes-3-Llama-3.1-8Bの例)。最小ハードはVRAM 5.2GB / RAM 8GB / CPU 4コア。

GPUに載りきらなくても「CPUオフロードなら tps=18.6」「CPU-onlyでも tps=10.0」と逃げ道を示し、「あとVRAMをどれだけ足せばFitが上がるか」という買い増しの費用対効果まで見えます。新しいGPUを買うか、量子化を落として今のマシンで妥協するかをデータで決められます。

Mode列に「MoE」と出るモデルは、推論時に一部の expert だけが活性化するので、見かけの規模のわりにメモリ効率が良く、80Bクラスでも Mem% が20〜45%程度に収まるものが少なくありません。バックエンドもCUDA・Metal/MLX・CPUを検出して織り込みます。推定はあくまで推定なので、候補を数本に絞ったら llmfit bench の実測で決めるのが確実です。

Ollama・LM Studio・GPT4Allとllmfitの使い分け

WHICH TOOL使い分け

llmfitは前工程。実行はランタイムに任せる

やりたいこと

使うもの

やりたいこと: 自分のPCで何が動くか知りたい

使うもの: llmfit(診断・選定)

やりたいこと: ターミナルやAPIでモデルを回したい

使うもの: Ollama

やりたいこと: GUIで手軽にチャットしたい

使うもの: LM Studio / GPT4All

当サイトの整理。各ツールの役割は本文の比較表を参照
ツール 役割 主な形態 何をするか llmfitとの関係
llmfit 診断・選定 CLI / TUI(Rust) ハードを検出し、数百モデルをFitスコアで順位付け 本記事の主役。実行はしない
Ollama 実行ランタイム CLI + サーバ ollama run でモデルをpullして推論。API互換サーバも内蔵 llmfitが「動く」と判定したモデルをここで実行
LM Studio 実行ランタイム GUIアプリ モデル検索・DL・チャット・ローカルAPIをGUIで完結 初心者向けの実行先。llmfitの判定を反映して選ぶ
GPT4All 実行ランタイム GUIアプリ 軽量モデル中心にオフラインで手軽に動かす 非力なマシンでの実行先候補

llmfitで「Qwen3-Coder-30BのQ4_K_MならこのマシンでFit=Good、tok/s=71」と分かったら、その結論を持ってOllamaで ollama run する——これが最短の立ち上げ方です。選定から実行・UIまでの全体像は ClaraVerse:LLMローカル実行対応のプライバシー重視プライベートAIプラットフォーム完全ガイド も合わせて読むとつながります。

一方、使うモデルが決まっていて快適に動くと分かっているなら、llmfitを毎回起動する必要はありません。llmfitが効くのは「選択肢が多すぎて決められない」局面と「マシンを買い替える・増設する前の見積もり」の2つで、常駐させるサービスではなく意思決定を速くする道具です。

マシン別・動かせるローカルLLMの目安

実際の可否はモデル・量子化・コンテキスト長で変わるので、必ず自分の環境で llmfit を実行して確認してください。以下は出発点の地図です。

マシン例 メモリ構成 狙えるモデル規模の目安 現実的な使い方
一般的なノートPC(GPUなし) RAM 16GB 7B〜8B(Q4量子化) CPU実行で軽いChat/要約。tok/sは一桁後半〜十数
ゲーミングPC VRAM 12GB 8B〜14B(Q4〜Q5) GPUフル実行で快適。コーディング補助も実用域
ハイエンドGPU VRAM 24GB 14B〜32B(Q4)/MoE系 30BクラスやMoEモデルまで。tok/s70前後も狙える
Apple Silicon(統合メモリ) ユニファイド128GB(M2/M3系) 70B級〜大型MoE メモリ帯域を活かし大型モデルも実用速度で

16GB RAM(GPUなし)では、Fit=Good 以上かつ用途に合うモデルを選び、CPU-onlyの推定tok/sを必ず見ます。12〜16GB VRAMならコーディング用途で Qwen2.5-Coder 系がこのレンジで強く、Apple Siliconは VRAMとRAMの区別が無いユニファイドメモリなので、大容量構成なら大型モデルも丸ごと載り、MLXバックエンドも使えます。

Quant列の Q4_K_M や Q5_K_M はGGUF形式の量子化で、数字がビット数の目安、K_M は品質を保つ改良版です。Q4 あたりが品質とメモリのバランスが良い実用ラインで、AWQ-4 や GPTQ はGPU実行向けの方式です。Q2など極端な低ビットはメモリこそ節約できますが出力品質が目に見えて落ち、Scoreのquality軸が下がる形で警告されます。大きくて劣化したモデルより、少し小さくて素直に動くモデル。

llmfitの導入手順と実運用のコツ

# ハードウェア検出が正しいか確認
llmfit doctor

# 問題なければTUIを起動して全体を眺める
llmfit

・ステップ1:llmfit doctor でGPUやVRAMが正しく認識されているか確かめる。ずれていると判定もずれる
・ステップ2:TUIで / を押し、用途(Coding / Chat / General)と Fit=Good 以上で候補を挙げる。s で並び替えると「速いが小さい」「遅いが賢い」が見える
・ステップ3:p のPlanでGPU/CPUオフロード/CPU-onlyの推定tpsと最小・推奨ハードを確認する
・ステップ4:最有力候補を llmfit bench で実測し、推定と大きく乖離するなら他プロセスのメモリ使用や省電力設定を疑う
・ステップ5:Ollamaなら ollama run <model>、LM StudioならGUIでDLして実行する。「In」列で二重DLも避けられる

新しい高効率モデルが出れば同じマシンでも選択肢が変わるので、llmfit は定期的に再実行します。recommend --json を起動スクリプトに組み込めば、チーム内でマシンごとに最適なモデルを自動で選べます。新しいGPUやMacを検討しているなら、購入前に動くモデルを把握しておけばスペックの過不足を避けられます。人に薦めるときは、推定ではなく llmfit bench の実測値を根拠にしてください。

参照ソース

  • AlexsJones/llmfit(GitHubリポジトリ) — 本体リポジトリ。説明文「Hundreds of models & providers. One command to find what runs on your hardware.」、スター数、対応プロバイダ(Ollama / llama.cpp / MLX / Docker Model Runner / LM Studio)、Rust実装・MITライセンスの一次情報
  • llmfit README(GitHub raw) — インストール手順(brew / scoop / curl / uv / docker)、fit / recommend --json / info / bench / doctor などサブコマンド、メモリ帯域モデルによる判定ロジックの説明、デモGIFの出典
  • llmfit Releases(GitHub) — v1.1.2(2026年7月10日)〜v1.1.14(2026-09-03)のリリース履歴。バージョン・更新頻度の確認