「ローカルLLMを始めてみたい。でも、自分のPCで結局どのモデルが動くのか分からない」——これはローカルLLMに触れる誰もが最初にぶつかる壁です。llmfit は、この「動く／動かない問題」をターミナルで1コマンドで解決するRust製のOSSツールです。GPU・VRAM・RAMを自動検出し、数百のモデルの中から「今のあなたのマシンで快適に動くもの」をスコア付きで一覧表示します。★29,000超（2026年7月時点で29,380）を集め、ローカルLLM界隈で一気に注目を浴びました。
この記事では、AlexsJones/llmfit が具体的に何をするのか、判定ロジックの中身、Ollama・LM Studioなどランタイムとの使い分け、そしてマシン別のおすすめの動かし方までを、公式リポジトリと実際の動作をもとに解説します。
ローカルLLMを動かす前提知識（オープンウェイト・ランタイム・VRAM要件）の全体像は ローカルLLMを動かす方法｜2026年6月最新オープンウェイト・ランタイム・VRAM要件まで総まとめ にまとめています。本記事はその「最初にどのモデルを選ぶか」を解決するツールの解説です。
この記事のポイント
・llmfitは「判定ツール」：モデルを実行するのではなく、GPU/VRAM/RAMを検出して「今のPCで動くローカルLLM」を quality・speed・fit・context の4軸でスコア化し一覧表示する
・1コマンドで完結：brew install llmfit で入れて llmfit と打つだけ。数百モデルが Fit=Perfect / Good / Too Tight と推定tok/sで並ぶ
・役割分担が肝：llmfitで「何を入れるか」を決め、実行はOllama・LM Studioなどのランタイムに任せる。両者は競合ではなく前工程と後工程の関係
llmfitを一言でいえば「ローカルLLM版のフィッティングルーム」です。服屋で「このサイズはあなたに合う／きつい」を試着で判断するように、llmfitは「このモデルはあなたのマシンで快適に動く／ぎりぎり／無理」を、ハードウェアの実測値から判定します。
従来、ローカルLLMを始める人は次のような手作業を強いられていました。動かしたいモデルのパラメータ数を調べ、量子化した場合のファイルサイズを見積もり、自分のGPUのVRAMと突き合わせ、KVキャッシュの分も足りるか電卓を叩く——。しかもモデルは毎週のように増えるため、この照合作業に終わりがありません。llmfitはこの一連の計算を自動化して数秒に圧縮します。
特徴を整理すると次の4点になります。
・ハードウェア自動検出：GPU・VRAM・RAM・CPUコア数・バックエンド（Metal / CUDA など）を起動時に読み取る
・数百モデル×量子化の総当たり評価：同じモデルでもQ4_K_M・AWQ・GPTQなど量子化違いを別々に評価し、あなたのマシンに最適な量子化を提示する
・推定tok/sつきの現実的な判定：ただ「入る／入らない」ではなく、GPU実行・CPUオフロード・CPU-onlyそれぞれの推定速度まで出す
・インタラクティブTUI：検索・並び替え・フィルタ・詳細表示を矢印キーだけで操作できる
MITライセンス、Rust製（コードの約81%がRust）の単一バイナリで、依存も軽量。2026年2月に公開され、v1.1.2（2026年7月10日）まで活発に更新が続いています。
llmfitとは：ローカルLLMの「動く/動かない」を判定するRust製CLI
llmfitのGitHubリポジトリの説明文は「Hundreds of models & providers. One command to find what runs on your hardware.（数百のモデルとプロバイダ。あなたのハードで何が動くかを見つける、たった1つのコマンド）」です。この一文にツールの本質が凝縮されています。
ここで重要なのは、llmfitがモデルを実行しないという点です。ローカルLLMのツールというと、Ollamaのようにモデルをダウンロードして推論を回すものを想像しがちですが、llmfitはその一歩手前——「そもそも何を入れるべきか」を決める工程を担います。実行は既存のランタイム（Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio）に委ねる設計です。
GPU / VRAM / RAM / CPU / backend] --> B[モデルDB照合
数百モデル × 量子化バリエーション] B --> C[4軸スコアリング
quality / speed / fit / context] C --> D[ランキング表示
Fit: Perfect / Good / Too Tight + tok/s] D --> E[llmfit plan
最小/推奨ハード・実行パス・アップグレード提案] D --> F[選定完了 → Ollama等のランタイムで実行]
上の流れが示すように、llmfitは「検出 → 照合 → 採点 → 提示」というパイプラインで動きます。ユーザーがやることは最初にコマンドを1つ打つだけで、あとはTUIの中で検索やフィルタをかけながら、自分の用途（Coding / Chat / General）に合った1本を絞り込んでいきます。
なぜこのツールが★29,000超を集めたのか。理由は、ローカルLLMの「入口の摩擦」を的確に潰したからです。ローカルLLMのランタイムは充実してきた一方で、「何を動かすべきか」の判断は依然として個々人の勘と手計算に委ねられていました。特にモデルの量子化とメモリ要件の関係は初心者にとって鬼門で、ここで挫折する人が後を絶ちません。llmfitはこの判断を機械化し、「まず動くものを見つけて成功体験を得る」までの距離を劇的に縮めました。
なお、TUIのモデル一覧には「In」という列があり、Ollamaなど各ランタイムにすでに導入済みのモデルを示すマーカー（OL / L / O など）が付きます。これにより「手元に入っているモデルの中で最良はどれか」も一目で分かります。ローカルLLMのランタイム選び自体に迷っているなら、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が立ち上がります。画面上部にはあなたのマシンのスペック（CPU、RAM、GPU）が表示され、その下に数百のモデルがスコア順で並びます。
主要なカラムの意味は次のとおりです。
・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（メモリ不足で非現実的）の3段階
・Use Case：得意用途（Coding / Chat / General）
TUIの操作はキーボードだけで完結します。/ で検索、s で並び替え、f でFitフィルタ、t でテーマ切替、Enter でモデル詳細、p で後述のPlan（実行計画）表示。たとえば / を押して「llama 8b」と入力すると、Llama系8Bのモデルだけが絞り込まれます。
検索だけでなく、画面上部のフィルタバーで候補を機械的に絞り込めます。Provider（提供元）、Use Case（Coding / Chat / General）、Caps（機能）、Sort（並び替え軸）、Fit（適合度）、Avail（導入済みかどうか）、Theme（配色）といった軸が用意されており、たとえば「Fit=Good以上」「Use Case=Coding」「Availは導入済みのみ」と重ねれば、”今すぐ使えて、コーディングに向いていて、快適に動く”モデルだけが残ります。数百件のリストを、自分の条件に合う数件まで数秒で削り込めるわけです。矢印キーとjk（Vim風の上下移動）で一覧をたどり、Enter で個別モデルの詳細——想定される品質特性、必要メモリの内訳、対応コンテキスト長——を確認できます。
llmfitが優れているのは、この「絞り込み」が単なる文字列フィルタではなく、あなたのマシンの実測スペックを常に前提にしている点です。同じ「Qwen3-Coder-30B」でも、64GBメモリのマシンでは Fit=Good と出るモデルが、16GBのマシンでは Too Tight と赤く表示される。表示されるすべての数字が「あなたの環境での値」であるため、他人のベンチマークやSNSの体験談を鵜呑みにする必要がありません。
CLIとして非対話で使うこともでき、スクリプトやCI/CDに組み込めます。
# ランキング表を非対話で出力
llmfit fit
# トップ候補をJSONで取得（他ツールへの受け渡しに便利）
llmfit recommend --json
# 特定モデルの詳細分析（推定の前提も表示）
llmfit info "Qwen/Qwen3-Coder-30B"
# 自分のマシンの実測tok/sをベンチマーク
llmfit bench
# ハードウェア検出レポート
llmfit doctor
llmfit recommend --json はトップの推奨モデルを機械可読な形で返すため、「起動時に最適なモデルを自動で選んでpullする」といった自動化にも使えます。ローカルLLMの選定を人力の勘からデータ駆動に置き換えられる点が、単なる一覧ツールを超えた価値です。
判定ロジックの中身：VRAM・RAM・量子化・メモリ帯域
llmfitの判定は勘や固定の閾値ではなく、メモリ帯域モデルに基づいた推定です。推定値はランタイムでの実測サンプリングとコミュニティの計測データに裏打ちされており、各推定には入力値と仮定が紐づいています。llmfit info "<model>" を実行すると、その推定がどの前提から導かれたかを確認できます——ブラックボックスにしていない点が信頼性を支えています。
判定の骨格を理解するうえで欠かせないのが、必要メモリの見積もり式です。ざっくり言えば次の関係で決まります。
パラメータ数 × 量子化ビット + KVキャッシュ] Q --> V{VRAMに収まるか?} V -->|Yes| G[GPU実行
Fit = Perfect / Good・高速] V -->|No| O{VRAM + RAM に収まるか?} O -->|Yes| P[CPUオフロード
Fit = Marginal・低速だが動く] O -->|No| X[Too Tight
量子化を下げる or 小型モデルへ]
ポイントは3つあります。
・量子化がメモリを決める：同じ30Bモデルでも、FP16なら約60GB必要でも、Q4量子化なら約17GB前後まで下がる。llmfitが量子化違いを別々に評価するのは、この「量子化を1段下げれば動く」という現実解を提示するため
・VRAMに載るかで速度が段違い：モデル全体がGPUのVRAMに収まればGPUフル実行で高速。収まらない分をRAM/CPUに逃がす「オフロード」になると、メモリ帯域がボトルネックになり速度が大きく落ちる
・KVキャッシュを忘れない：長いコンテキストを使うほどKVキャッシュがメモリを食う。llmfitがCtx（コンテキスト長）を軸に持つのはこのため。「モデル本体は載るがコンテキストを伸ばすと溢れる」ケースを見逃さない
この判定を最も具体的に体感できるのが、p キーで開くPlan（実行計画）ビューです。特定モデルについて「最小ハード」「推奨ハード」「実行パスごとの速度」「アップグレード提案」を一枚にまとめて示します。
このPlanビューが優れているのは、「動く／動かない」の二値ではなく連続的な選択肢を示す点です。GPUに載りきらなくても「CPUオフロードなら tps=18.6 で動く」「CPU-onlyでも tps=10.0 は出る」と現実的な逃げ道を提示し、さらに「あとVRAMをどれだけ足せばFitがGoodやPerfectに上がるか」という買い増しの費用対効果まで見えます。新しいGPUを買うべきか、量子化を1段落として今のマシンで妥協するか——この意思決定をデータで支えてくれます。
判定を左右するもう一つの要素がモデルのアーキテクチャです。TUIのMode列に「MoE」と表示されるモデル（Mixture of Experts）は、総パラメータ数が大きくても推論時に一部の専門家（expert）だけが活性化するため、見かけの規模のわりにメモリ効率が良くなります。実際、llmfitの一覧では80Bクラスのモデルでも Mem% が20〜45%程度に収まっているものが少なくありません。「パラメータ数が大きい＝動かない」と早合点せず、Mem%とFitの実際の値を見るべきなのは、このMoEの存在があるからです。llmfitはMoEと通常の密（dense）モデルを区別して見積もるため、こうした「大きいのに軽い」モデルを取りこぼしません。
同様に、バックエンド（実行基盤）の検出も判定の前提になります。llmfitはCUDA（NVIDIA GPU）、Metal／MLX（Apple Silicon）、CPUといった基盤を検出し、それぞれで実現できる速度やメモリの使い方を織り込みます。同じモデル・同じ量子化でも、CUDAでフルGPU実行する場合と、Apple Siliconのユニファイドメモリで動かす場合、CPUだけで動かす場合では現実的な速度がまったく変わります。llmfitがGPU・CPUオフロード・CPU-onlyという3つの実行パスを別々に評価するのは、この基盤ごとの違いを1つの数字に潰さず、ユーザーが自分の環境に即して選べるようにするためです。
なお、この推定はあくまで推定です。最終確認には llmfit bench で自分のマシンの実測tok/sを測り、推定値を裏取りするのが確実です。推定で候補を数本に絞り、実測で最終決定する、という二段構えが実践的なワークフローになります。
Ollama・LM Studio・GPT4Allとllmfitの使い分け
ローカルLLMのツールを調べると、Ollama・LM Studio・GPT4Allといった名前が必ず出てきます。「llmfitはこれらとどう違うのか、どれを使えばいいのか」と混乱しがちですが、答えはシンプルです——llmfitはこれらと競合しません。前工程を担当します。
Ollama・LM Studio・GPT4Allはいずれもモデルを実際に実行するランタイム／アプリです。一方llmfitは、それらで動かす前に「何を動かすべきか」を決める診断ツール。役割の階層が違うため、実運用ではllmfitで選定 → ランタイムで実行、と併用するのが正解です。
| ツール | 役割 | 主な形態 | 何をするか | llmfitとの関係 |
|---|---|---|---|---|
| llmfit | 診断・選定 | CLI / TUI（Rust） | ハードを検出し、数百モデルをFitスコアで順位付け | 本記事の主役。実行はしない |
| Ollama | 実行ランタイム | CLI + サーバ | ollama run でモデルをpullして推論。API互換サーバも内蔵 |
llmfitが「動く」と判定したモデルをここで実行 |
| LM Studio | 実行ランタイム | GUIアプリ | モデル検索・DL・チャット・ローカルAPIをGUIで完結 | 初心者向けの実行先。llmfitの判定を反映して選ぶ |
| GPT4All | 実行ランタイム | GUIアプリ | 軽量モデル中心にオフラインで手軽に動かす | 非力なマシンでの実行先候補 |
つまり、迷ったときの判断はこうなります。
・「自分のPCで何が動くか知りたい」→ llmfit：ハードとモデルの照合が目的ならこれ一択
・「ターミナルやAPIでモデルを回したい」→ Ollama：開発者向け。llmfitの「In」列でOllama導入済みモデルも見える
・「GUIで手軽にチャットしたい」→ LM Studio / GPT4All：非エンジニアや、まずは試したい人向け
重要なのは、これらを二者択一で考えないことです。llmfitで「Qwen3-Coder-30BのQ4_K_MならこのマシンでFit=Good、tok/s=71」と分かったら、その結論を持ってOllamaで ollama run する——この流れが、ローカルLLMを最短で立ち上げる王道です。ランタイム側の設計や量子化の詳細に踏み込みたい場合は、プライベートAIプラットフォームを解説した ClaraVerse：LLMローカル実行対応のプライバシー重視プライベートAIプラットフォーム完全ガイド も合わせて読むと、選定から実行・UIまでの全体像がつながります。
一方で、llmfitが不要なケースも正直に押さえておきましょう。すでに使うモデルが完全に決まっていて、そのモデルが自分のマシンで快適に動くと分かっているなら、llmfitを毎回起動する必要はありません。llmfitが最も輝くのは、「選択肢が多すぎて決められない」局面と「マシンを買い替える／増設する前の見積もり」の2つです。前者では数百のモデルを自分の環境基準で瞬時にランク付けし、後者ではPlanビューのアップグレード提案が、投資判断の根拠になります。逆に言えば、モデルが1つに固定された定常運用ではランタイムだけで十分——この線引きを理解しておくと、ツールを増やしすぎずに済みます。llmfitはあくまで「意思決定を速くする道具」であって、常駐させるサービスではないのです。
マシン別・動かせるローカル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なし）：7B〜8Bの Q4量子化が実用の上限。llmfitで Fit=Good 以上、かつ Use Case が用途に合うモデルを選ぶ。CPU-onlyの推定tok/sを必ず確認する
・12〜16GB VRAM：8B〜14Bを快適にGPU実行できる帯。コーディング用途なら Qwen2.5-Coder 系や同等モデルがこのレンジで強い
・24GB VRAM：30BクラスやMoE（Mixture of Experts）モデルが視野に入る。MoEは総パラメータが大きくても実効的なメモリ効率が良く、llmfitの表でも Mem% が低めに出ることがある
・Apple Silicon 大容量ユニファイドメモリ：VRAMとRAMの区別がなく、メモリ帯域も広いため、70B級の大型モデルまで現実的。MLXバックエンドも活用できる
Apple SiliconはローカルLLMにおいて独特の強みを持ちます。GPUとCPUがメモリを共有する「ユニファイドメモリ」により、通常はVRAM不足で諦める大型モデルも、128GBといった大容量構成なら丸ごと載せられます。llmfitはMetal／MLXバックエンドも検出対象にしているため、Macユーザーは自分のマシンの真の実力を正しく把握できます。
ここで、llmfitのQuant列に並ぶ量子化の記号の読み方も押さえておくと選定が速くなります。Q4_K_M や Q5_K_M はGGUF形式の量子化で、数字がビット数の目安（4bit / 5bit）、K_M は品質を保つ改良版であることを示します。Q8 に近いほど品質は元のモデルに近づきますがメモリを食い、Q4 あたりが「品質とメモリのバランスが良い実用ライン」として広く使われます。一方 AWQ-4 や GPTQ はGPU実行に最適化された量子化方式で、対応ランタイム（vLLMなど）で速度が出やすい特徴があります。llmfitは同じモデルのこれらの量子化バリエーションを別々の行として並べるため、「品質重視でQ5、メモリがきついならQ4、GPUで速度を出すならAWQ」といった選択を、Score・Mem%・tok/sの実数を見ながら比較できます。量子化方式そのものの仕組み（GGUF・AWQ・GPTQの違い）を深掘りしたい場合は、冒頭で挙げたローカルLLMの総まとめ記事が土台になります。
逆に注意したいのが、量子化を過度に下げてまで大きなモデルを載せようとすることです。Q2など極端な低ビット量子化はメモリこそ節約できますが、出力品質が目に見えて劣化します。llmfitのScoreはquality軸も含むため、「メモリには載るがqualityが落ちる」選択には総合スコアが下がる形で警告が働きます。大きくて劣化したモデルより、少し小さくて素直に動くモデル——この原則を数値で裏付けてくれるのがllmfitの実用的な価値です。
導入手順と実運用のコツ
最後に、llmfitを日々のローカルLLM運用に組み込むための実践的な流れをまとめます。
ステップ1：まず現状を把握する。 インストール後、llmfit doctor でハードウェア検出が正しく行われているかを確認します。GPUやVRAMが正しく認識されていないと判定がずれるため、最初にここを見ておきます。
# ハードウェア検出が正しいか確認
llmfit doctor
# 問題なければTUIを起動して全体を眺める
llmfit
ステップ2：用途で絞る。 TUIで / を押し、用途に合うモデルを検索します。コーディング補助が目的なら Use Case が Coding のモデル、汎用チャットなら Chat/General を中心に、Fit=Good 以上のものから候補を挙げます。s で Score や tok/s に並び替えると、「速いが小さい」「遅いが賢い」のトレードオフが見えます。
ステップ3：Planで裏取りする。 気になったモデルで p を押してPlanビューを開き、GPU/CPUオフロード/CPU-onlyの推定tpsと、最小・推奨ハードを確認します。「今はCPUオフロードでも動く。VRAMを8GB足せばGPUフルでPerfectになる」といった判断がここでできます。
ステップ4：実測で確定する。 最有力候補を llmfit bench で実測し、推定tok/sと実測を突き合わせます。推定と実測が大きく乖離する場合は、他プロセスのメモリ使用や電源設定（省電力モード）を疑います。llmfitはこのベンチマークやコミュニティの計測データを推定モデルの改善に活かす設計になっており、多くのユーザーの実測が集まるほど、初期表示の推定精度も上がっていきます。つまり llmfit bench を回すことは、自分のマシンの確認であると同時に、ツール全体の判定精度を底上げする貢献にもなります。ローカルLLMの実行環境は機種・OS・ドライバのバージョンで細かく挙動が変わるため、こうした実測ベースの補正はカタログスペックだけの見積もりよりずっと現実に即した数字を返してくれます。
ステップ5：ランタイムで動かす。 確定したモデルを、Ollamaなら ollama run <model>、LM StudioならGUIからDLして実行します。llmfitの「In」列でランタイム導入状況が見えるので、二重DLも避けられます。
運用上のコツをいくつか挙げます。
・モデルは増え続ける前提で、定期的に llmfit を再実行する：新しい高効率モデルが出れば、同じマシンでもより良い選択肢が現れる
・recommend --json を自動化に使う：起動スクリプトでトップ推奨を取得し、環境変数やconfigに反映すれば、チーム内でマシンごとに最適なモデルを自動選択できる
・購入前の相談相手にする：新しいGPUやMacを検討しているなら、想定スペックで動くモデルを事前に把握でき、オーバースペック／スペック不足の買い物を避けられる
・推定を鵜呑みにせず実測を添える：特に人に薦めるときは、llmfit bench の実測値を根拠にする
llmfitは派手なツールではありません。しかし、ローカルLLMという「試すまでのハードルが高い領域」で、最初の一歩の摩擦を的確に取り除く道具です。「動くか分からないから試さない」という最大の機会損失を、1コマンドで「これが動く」に変えてくれる——その一点において、★29,000という評価は納得のいくものです。ローカルLLMをこれから始める人も、すでに動かしている人も、手元に1本入れておいて損のないツールと言えます。
まとめ
llmfitは、GPU・VRAM・RAMを自動検出して「今のあなたのマシンで動くローカルLLM」を1コマンドで判定するRust製OSSです。モデルを実行するランタイムではなく、その前工程である「何を動かすべきか」の選定を担い、数百のモデルを quality・speed・fit・context の4軸でスコア化して Fit=Perfect / Good / Too Tight と推定tok/sで一覧表示します。
核心は、量子化とメモリ要件の面倒な照合を機械化し、「動く／動かない」の二値ではなく「GPUなら高速、CPUオフロードなら低速でも動く、あとVRAMを足せばこう改善する」という連続的な選択肢を提示する点にあります。Ollama・LM Studio・GPT4Allといったランタイムとは競合せず、llmfitで選定 → ランタイムで実行、と併用するのが実運用の王道です。
brew install llmfit（またはscoop / curl / uv / docker）で導入し、llmfit で全体を眺め、p のPlanで裏取りし、llmfit bench で実測する——この流れで、ローカルLLMの「最初のモデル選び」はもう手計算に悩む作業ではなくなります。
参照ソース
- 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日）を含むリリース履歴。バージョン・更新頻度の確認
