ローカルLLMを試そうとして、最初の壁にぶつかった経験はないでしょうか。
Ollamaのモデル一覧を眺めて「とりあえずこれでいいか」とダウンロードを始め、40GBが落ちてくるのを待ち、いざ起動したら out of memory で即死——そういう体験談、あちこちで見かけます。
llmfit はその「モデル選定の壁」を1コマンドで崩してくれるツールです。
インストールから実行・出力の読み方まで手を動かしながら説明するので、読み終わったあとには「自分のマシンで動くモデルの候補リスト」を自力で出せるようになっているはずです。
ローカルLLMのモデル選定、なぜ最初の一歩でつまずくのか
ローカルLLMの導入で最初につまずく理由は、「試すコストが異様に高い」という構造的な問題にあります。
クラウドのAPIなら、モデルを変えるのは設定値を1行書き換えるだけです。
でもローカルは違います。
モデルを変えるたびに数GB〜数十GBのダウンロードが走り、動かなければその時間がまるごと無駄になります。
問題をもう少し掘り下げると、変数が3つ絡み合っているのが厄介です。
VRAM（またはRAM）の容量・モデルのパラメータ数・量子化レベル の3つです。
たとえば8Bモデルを量子化なし（FP16）で動かすと、重みだけで約16GBのメモリが必要になります。
16GBのVRAMがあっても、それだけでほぼ埋まってしまいます。
さらにやっかいなのが量子化バリアントの多さです。
同じ「Llama 3.1 8B」というモデルでも、Q4_K_M・Q4_K_S・Q5_K_M・Q8_0 など複数のバリアントが存在します。
Q4_K_M は「4bit量子化・K-quants方式・Mediumサイズ」という意味で、数字が小さいほど軽くなる代わりに品質が少し落ちます。
どれを選べばいいかは自分のマシンのスペックと用途によって変わるので、「とりあえず試してみるしかない」という非効率なループに陥りやすいんですよね。
公式ドキュメントに書いてある「最低要件」も、快適に動かすための要件とはかなり乖離があります。
「最低8GB」と書いてあっても、実際には推論速度が0.3トークン/秒しか出なくて実用にならない、というケースは珍しくありません。
この情報ギャップを埋めるのが、次に紹介する llmfit の役割です。
llmfitが何をするツールか
llmfit を一言で表すなら、「自分のマシンで何が動くかを1コマンドで答えてくれるツール」です。
GitHubのREADMEによると、497モデル・133プロバイダーを対象に、あなたのマシンのハードウェアスペックと照合してスコアリングしてくれます。
リリース以来21,300以上のGitHubスターを集めており、ローカルAIエコシステムの中でも急速に広まっているツールです。
主な機能をまとめると次のとおりです。
- ハードウェア自動検出：RAM・VRAM・CPUを起動時に自動で読み取る
- 497モデル × 133プロバイダーとの照合：Meta Llama・Mistral・Qwen・Phi・Gemma・DeepSeekなど主要ファミリーを網羅
- 4軸スコアで出力：quality・speed・fit・context の4つの観点で各モデルを評価
- 複数ランタイムに対応：Ollama・llama.cpp・MLX・LM Studio・Docker Model Runnerなどに対応
「動く／動かない」の二択ではなく、実用上の快適さまで含めた判定 を出してくれるのがポイントです。
単純にメモリに収まるかどうかだけでなく、推論速度の見積もりやコンテキスト長の扱いまで含めてスコアリングするので、「一応動くけど遅すぎて使えない」という状況を事前に避けやすくなります。
OllamaやLM Studioとの関係も整理しておきます。
llmfit はあくまで 選定ツール であり、モデルを実際に動かすランタイムではありません。
「どのモデルを選ぶか」を決めるのが llmfit で、「実際に動かす」のはOllamaやLM Studioの仕事です。
Rust製なのでバイナリ単体で動き、依存関係のインストールが不要で起動も速いという実用上の利点もあります。
インストールから初回実行まで
インストール経路は2つあります。
Rustのツールチェーンが入っている環境なら cargo 経由が手軽です。
Rustを入れたくない場合は、GitHubのリリースページからプラットフォーム別のバイナリを直接取得できます。
# cargo 経由でインストール
cargo install llmfit
# または GitHub Releases からバイナリを取得（macOS arm64 の例）
curl -L https://github.com/AlexsJones/llmfit/releases/latest/download/llmfit-aarch64-apple-darwin -o llmfit
chmod +x llmfit
sudo mv llmfit /usr/local/bin/
インストールできたら、まず TUI モードで起動してみましょう。
デフォルトの起動コマンドは引数なしの llmfit です。
# インタラクティブな TUI モードで起動（デフォルト）
llmfit
# CLI モードで起動（出力をパイプやスクリプトに渡したいとき）
llmfit --cli
起動すると、まずハードウェア検出が自動で走ります。
RAMの総量・空き容量、GPUのVRAM、CPUのコア数といった情報が読み取られ、その結果をもとにモデルリストのスコアリングが始まります。
TUIモードはキーボードで絞り込みや並び替えができるインタラクティブな画面で、ざっと全体を眺めたいときに向いています。
一方、CLIモードはスコア一覧をテキストで出力するので、grep で絞り込んだり、CI/CDパイプラインに組み込んだりするときに便利です。
どちらのモードも、出力の内容は同じです。
出力の読み方と、モデルを選ぶときの判断軸
llmfit の出力には、各モデルに対して quality・speed・fit・context の4つのスコアが付きます。
それぞれ何を意味するのか、実務上どれを優先すべきかを整理します。
quality は、量子化によって失われた精度の度合いを示します。
Q8_0 のように高ビットの量子化ほどスコアが高く、Q4_K_S のように低ビットになるほど下がります。
コーディング補助や論理的な推論を求めるなら、quality スコアはある程度高いものを選んだほうが結果が安定します。
speed は、自分のハードウェアでどれくらいの推論速度が期待できるかの見積もりです。
リアルタイムに近い応答が欲しいチャット用途や、補完ツールとして使いたい場合は speed を重視します。
fit は、モデルのメモリ要件と自分のマシンのスペックがどれだけ合っているかを示します。
スコアが高いほど「余裕を持って動く」状態に近く、低いほどギリギリか厳しい状態です。
fit が低いモデルは、一応動いても他のアプリとメモリを取り合って不安定になりやすいです。
context は、そのモデルが扱えるコンテキスト長と、自分の環境でどれだけのコンテキストを実際に活用できるかの指標です。
長文の要約や大きなコードベースを一度に渡したい用途では、context スコアが高いモデルを選ぶ理由になります。
同一モデルに量子化違いで複数の候補が並ぶ場合、迷ったら Q4_K_M を基準に考えるのが実用的 です。
Q4_K_M は品質と軽さのバランスが取れており、ローカルLLMコミュニティでも広く使われているバリアントです。
メモリに余裕があれば Q8_0 を試してみる価値はありますが、Q4_K_M と Q8_0 の体感差は用途によっては気にならないレベルのことも多いです。
ひとつ正直に書いておきます。
llmfit のスコアはあくまで 推定値 であり、動作保証ではありません。
fit スコアが高くても、実際に動かしてみると遅い場合があります。
推論速度はVRAMだけでなく、ストレージのI/O速度やCPUのメモリ帯域幅にも依存するからです。
モデルをVRAMに載せ切れず、一部をRAMやストレージからストリーミングする状況になると、スコアの予測と実際の速度がかなりずれることがあります。
llmfit の出力は「試す候補を絞り込む地図」として使うのが正しい距離感です。
llmfitで選んだモデルをOllamaで動かす
llmfit で候補が絞れたら、あとは実際に動かすだけです。
Ollama を使う場合、llmfit の出力に表示されるモデル名をそのまま ollama pull に渡せます。
# llmfit の出力に表示されたモデル名を確認する（CLI モードの例）
llmfit --cli | grep -i "qwen"
# 候補のモデルを Ollama で取得する
ollama pull qwen3:8b
# そのまま起動して動作確認
ollama run qwen3:8b
Ollama のモデル名は「ファミリー名:パラメータ数」の形式が基本です。
llmfit の出力に表示されるモデル名と完全に一致しない場合は、Ollama の公式モデルライブラリで検索して対応するタグを確認します。
量子化を明示したい場合は、たとえば qwen3:8b-q4_K_M のようにタグで指定できます。
# 量子化バリアントを明示して取得する例
ollama pull qwen3:8b-q4_K_M
ollama run qwen3:8b-q4_K_M
LM Studio を使う場合は、llmfit で確認したモデル名を LM Studio の検索窓に入力するだけです。
Hugging Face 上のモデルが一覧で出てくるので、量子化バリアントを選んでダウンロードできます。
llmfit はあくまで「入口の地図」です。
実際に動かしてみて、自分のマシンでの速度・応答品質を自分の目で確かめるのが次のステップです。
「スコアは悪くないのに思ったより遅い」「逆に予想以上に快適だった」という発見は、実際に動かしてみないと分かりません。
まず候補を1〜2個に絞り込んで、短いプロンプトで速度感を確かめる——その最初の一歩を踏み出しやすくするのが、llmfit の一番の価値だと思っています。
株式会社ホコサキは、山口県宇部を拠点にAI活用支援・業務システム開発・DX推進に取り組んでいます。
ローカルLLMの導入検討から実務への組み込みまで、エンジニア目線で一緒に考えます。
ご相談は お問い合わせページ からどうぞ。