llmfit

新機能: コミュニティリーダーボード — 実際のユーザーから集まった実環境のパフォーマンスデータを閲覧できます。b を押すと、自分のものに限らず、あらゆる GPU の実測 tok/s、TTFT、VRAM を確認できます。H で 27 種類以上のハードウェアプリセット（RTX 5090 から Apple M1 まで）から選び、購入や自作の前に実数値を比較しましょう。

数百のモデルとプロバイダー。自分のハードウェアで動くものを見つけるコマンドはひとつ。

LLM モデルをシステムの RAM、CPU、GPU に合わせて最適化するターミナルツールです。ハードウェアを検出し、各モデルを品質・速度・適合度・コンテキストの各観点でスコアリングして、あなたのマシンで実際に快適に動くものを教えてくれます。

インタラクティブな TUI（デフォルト）と従来型の CLI モードを備えています。マルチ GPU 構成、MoE アーキテクチャ、動的な量子化選択、速度推定、ローカルランタイムプロバイダー（Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio）に対応しています。

新機能: コミュニティリーダーボード（b） — 同じハードウェアを使う他のユーザーから集まった実環境の tok/s、TTFT、VRAM 使用量を確認できます。localmaxxing.com を利用し、推定パフォーマンスと実測パフォーマンスの差を埋めます。

その他: ダウンロードマネージャー（D）、詳細設定（A）、ハードウェアシミュレーション — D を押すとダウンロードの管理、履歴の閲覧、モデルの削除、ダウンロードディレクトリの設定ができます。A を押すと TPS 効率、実行モード係数、スコアリングの重みを調整できます。S を押すと別のハードウェアをシミュレーションできます。

姉妹プロジェクト:

• sympozium — Kubernetes でエージェントを管理。
• llmserve — ローカル LLM モデルをサーブするためのシンプルな TUI。モデルを選び、バックエンドを選び、サーブする。
• llama-panel — ローカルの llama-server インスタンスを管理するネイティブ macOS アプリ。

インストール

Windows

scoop install llmfit

Scoop がインストールされていない場合は、Scoop インストールガイドに従ってください。

macOS / Linux

Homebrew

ビルド済みバイナリ（推奨。すべての macOS/Linux バージョンで動作）:

brew install AlexsJones/llmfit/llmfit

または homebrew-core の formula から。bottle がない macOS バージョンではソースからビルドされます:

brew install llmfit

MacPorts

port install llmfit

クイックインストール

curl -fsSL https://llmfit.axjns.dev/install.sh | sh

GitHub から最新リリースのバイナリをダウンロードし、/usr/local/bin（sudo がない場合は ~/.local/bin）にインストールします。

sudo なしで ~/.local/bin にインストール:

curl -fsSL https://llmfit.axjns.dev/install.sh | sh -s -- --local

uv / pip

llmfit をインストールまたは更新するには:

uv tool install -U llmfit

インストールせずに実行するには:

uvx llmfit

pip や uv などのツールを使って、通常の方法で llmfit を Python パッケージとしてインストールすることもできます。

Docker / Podman

docker run ghcr.io/alexsjones/llmfit

これは llmfit recommend コマンドの JSON を出力します。この JSON は jq でさらにクエリできます。

podman run ghcr.io/alexsjones/llmfit recommend --use-case coding | jq '.models[].name'

ソースから

git clone https://github.com/AlexsJones/llmfit.git
cd llmfit
cargo build --release
# バイナリは target/release/llmfit にあります

使い方

TUI（デフォルト）

llmfit

インタラクティブなターミナル UI を起動します。システムスペック（CPU、RAM、GPU 名、VRAM、バックエンド）が上部に表示されます。モデルは複合スコア順に並んだスクロール可能なテーブルに一覧表示されます。各行には、モデルのスコア、推定 tok/s、あなたのハードウェアに最適な量子化、実行モード、メモリ使用量、ユースケースカテゴリが表示されます。

Vim 風モード

TUI は左下のステータスバーに表示される Vim 由来のモードを使用します。現在のモードによって、どのキーが有効かが決まります。

Normal モード

デフォルトのモードです。移動、検索、フィルタリング、ビューの表示を行います。上の表のすべてのキーがここで適用されます。

Visual モード（v）

一括比較のために連続したモデルの範囲を選択します。v を押して現在の行を起点に固定し、j/k または矢印キーで移動して選択範囲を広げます。選択された行はハイライトされます。

マルチ比較ビューは、行が属性（Score、tok/s、Fit、Mem%、Params、Mode、Context、Quant など）、列がモデルとなるテーブルを表示します。最良の値はハイライトされます。画面に収まらないほど多くのモデルを選択した場合は、h/l または矢印キーで横スクロールできます。

Select モード（V）

列ベースのアクションです。V（shift-v）を押して Select モードに入り、h/l または矢印キーで列ヘッダー間を移動します。アクティブな列は視覚的にハイライトされます。Enter または Space を押すと、その列の現在のアクションが実行されます。

Select モードでも行のナビゲーションは引き続き機能するため、アクションを適用しながらその効果を確認できます: j/k、矢印キー、Ctrl-U、Ctrl-D、PageUp、PageDown、Home、End。Esc を押すと Normal モードに戻ります。

TUI Plan モード（p）

Plan モードは通常の適合分析を反転させます。「何が自分のハードウェアに収まるか?」ではなく、「このモデル構成にはどんなハードウェアが必要か?」を推定します。

選択した行で p を押し、次のように操作します:

Plan モードは以下の推定値を表示します:

• 最小および推奨の VRAM/RAM/CPU コア数
• 実行可能な実行パス（GPU、CPU オフロード、CPU のみ）
• より良い適合目標に到達するためのアップグレード差分

ハードウェアシミュレーション（S）

S を押すとハードウェアシミュレーションのポップアップが開きます。RAM、VRAM、CPU コア数を上書きして、別のターゲットハードウェアでどのモデルが収まるかを確認できます。すべてのモデルスコア、適合レベル、速度推定は、シミュレーションされたスペックに対して即座に再計算されます。

シミュレーションが有効なときは、システムバーとステータスバーに SIM バッジが表示されます。リセットするまで、モデルテーブル全体がシミュレーションされたハードウェアを反映します。

詳細設定（A）

A を押すと詳細設定のポップアップが開きます。このパネルでは、TPS 推定、実行モードのペナルティ、複合スコアリングの背後にあるパラメータを調整できます。これは特定のモデル（例: Qwen3 30B）で tok/s が過大評価されていたissue #449に対応するものです。

すべての変更は即座に適用され、モデルテーブルが再計算されます。Esc で確定して閉じるか、Ctrl-R でデフォルトにリセットします。

ダウンロードマネージャー（D）

D を押すとダウンロードマネージャービューが開きます。このフルスクリーンビューはメインのモデルテーブルに置き換わり、3 つのセクションを提供します:

• Active Download — 進行中の現在のダウンロードを、プログレスバー、モデル名、ステータスメッセージとともに表示します。
• Config — GGUF モデルディレクトリを表示（および編集可能）します。設定したパスはセッションをまたいで永続化されます。
• History — 過去のダウンロードのナビゲート可能なリスト（新しい順）を、モデル名、プロバイダー、ステータス、日付とともに表示します。失敗したダウンロードは履歴から削除でき、成功したダウンロードはプロバイダーから削除できます。

Tab / Shift-Tab でセクション間のフォーカスを切り替えます。

失敗したダウンロード（例: 404 エラー）の場合、x は履歴からエントリを削除します。成功したダウンロードの場合は、プロバイダーからモデルを削除します（Ollama と llama.cpp でサポート）。

コミュニティリーダーボード（b）

b を押すとコミュニティリーダーボードビューが開きます。llmfit の理論的な速度推定だけに頼るのではなく、このビューでは同じハードウェアを使う他のユーザーから集まった実環境のパフォーマンスデータ — 実測の tok/s、最初のトークンまでの時間、ピーク VRAM 使用量 — を表示します。

データはコミュニティのベンチマークデータベースである localmaxxing.com から取得されます。ビューを開くと、llmfit はあなたのハードウェア（GPU モデル、VRAM ティア、Apple Silicon チップファミリー、OS）を自動検出し、一致する結果をクエリします。

H を押すとハードウェアピッカーが開きます。これは 27 種類の人気 GPU とチップ（RTX 5090 から CPU のみまで、加えて Apple Silicon M1–M4 バリアント、AMD RX/MI シリーズ、NVIDIA データセンターカード）のスクロール可能なリストです。1 つ選ぶと、たとえそれが自分の使っているものでなくても、そのハードウェアのベンチマークを即座に読み込めます。「My Hardware (auto-detect)」を選ぶと自分のシステムに戻ります。

API キーの設定

公開ベンチマークは認証なしで利用できます。フルアクセスには localmaxxing.com の API キーを指定します:

# 環境変数経由（推奨）
export LOCALMAXXING_API_KEY="bhk_your_key_here"
llmfit

# または CLI フラグ経由
llmfit --api-key "bhk_your_key_here"

推論ベンチ（I）

I（大文字）を押すと推論ベンチビューが開きます。これはローカルで実行中のプロバイダー — Ollama、vLLM、MLX — に対してライブの推論ベンチマークを実行し、実際の推論リクエストで最初のトークンまでの時間（TTFT）、毎秒トークン数（TPS）、総レイテンシを測定します。

コミュニティリーダーボード（他のユーザーから集めたクラウドソースのデータを表示）とは異なり、推論ベンチはあなたの実際のハードウェアであなたの実際のモデルを測定します。

TUI での使い方

結果は ~/.config/llmfit/bench-cache.json にキャッシュされ、次回以降は即座に読み込まれます。

CLI での使い方

# プロバイダーを自動検出してベンチマーク
llmfit bench

# 実行中のすべてのプロバイダーで検出されたすべてのモデルをベンチマーク
llmfit bench --all

# Ollama 経由で特定のモデルをベンチマーク
llmfit bench --provider ollama llama3.2

# エンドポイント URL を上書き
llmfit bench --provider ollama --url http://my-server:11434 llama3.2

# vLLM エンドポイントを上書き
llmfit bench --provider vllm --url http://localhost:8000

# JSON として出力（スクリプト用）
llmfit bench --json

# 品質ベンチマークを実行（ルーティング用のロールベーススコアリング）
llmfit bench --quality

# ルーティングマトリックスを出力
llmfit bench --quality --routing

環境変数

テーマ

t を押すと 10 種類の組み込みカラーテーマを切り替えられます。選択は ~/.config/llmfit/theme に自動保存され、次回起動時に復元されます。

Web ダッシュボード

llmfit を非 JSON モードで実行すると、0.0.0.0:8787 でバックグラウンドの Web ダッシュボードが自動的に起動します。同じネットワーク上の任意のブラウザで開けます:

http://<your-machine-ip>:8787

ホストやポートは環境変数で上書きできます:

LLMFIT_DASHBOARD_HOST=0.0.0.0 LLMFIT_DASHBOARD_PORT=9000 llmfit

自動起動するダッシュボードを無効にするには、--no-dashboard を渡します:

llmfit --no-dashboard

CLI モード

--cli または任意のサブコマンドを使うと、従来型のテーブル出力が得られます:

# 適合度でランク付けされたすべてのモデルのテーブル
llmfit --cli

# 完全に適合するモデルのみ、上位 5 件
llmfit fit --perfect -n 5

# 検出されたシステムスペックを表示
llmfit system

# データベース内のすべてのモデルを一覧表示
llmfit list

# 名前、プロバイダー、サイズで検索
llmfit search "llama 8b"

# 単一モデルの詳細ビュー
llmfit info "Mistral-7B"

# 上位 5 件の推奨（JSON、エージェント/スクリプト消費用）
llmfit recommend --json --limit 5

# ユースケースでフィルタリングした推奨
llmfit recommend --json --use-case coding --limit 3

# 特定のランタイムを強制（Apple Silicon での自動 MLX 選択をバイパス）
llmfit recommend --force-runtime llamacpp
llmfit recommend --force-runtime llamacpp --use-case coding --limit 3

# 特定のモデル構成に必要なハードウェアをプラン
llmfit plan "Qwen/Qwen3-4B-MLX-4bit" --context 8192
llmfit plan "Qwen/Qwen3-4B-MLX-4bit" --context 8192 --quant mlx-4bit
llmfit plan "Qwen/Qwen3-4B-MLX-4bit" --context 8192 --target-tps 25 --json

# ノードレベルの REST API として実行（クラスタースケジューラー / アグリゲーター用）
llmfit serve --host 0.0.0.0 --port 8787

REST API（llmfit serve）

llmfit serve は、TUI/CLI で使われるのと同じ適合度/スコアリングデータを公開する HTTP API を起動します。これにはノードのフィルタリングや上位モデルの選択も含まれます。

# 生存確認
curl http://localhost:8787/health

# ノードのハードウェア情報
curl http://localhost:8787/api/v1/system

# フィルター付きの完全な適合リスト
curl "http://localhost:8787/api/v1/models?min_fit=marginal&runtime=llamacpp&sort=score&limit=20"

# 主要なスケジューリングエンドポイント: このノードで実行可能な上位モデル
curl "http://localhost:8787/api/v1/models/top?limit=5&min_fit=good&use_case=coding"

# モデル名/プロバイダーのテキストで検索
curl "http://localhost:8787/api/v1/models/Mistral?runtime=any"

models/models/top でサポートされるクエリパラメータ:

• limit（または n）: 返される行の最大数
• perfect: true|false（true で完全適合のみを強制）
• min_fit: perfect|good|marginal|too_tight
• runtime: any|mlx|llamacpp
• use_case: general|coding|reasoning|chat|multimodal|embedding
• provider: プロバイダーのテキストフィルター（部分文字列）
• search: 名前/プロバイダー/サイズ/ユースケースにわたる自由テキストフィルター
• sort: score|tps|params|mem|ctx|date|use_case
• include_too_tight: 実行不可能な行を含める（/top ではデフォルト false、/models では true）
• max_context: メモリ推定のためのリクエストごとのコンテキスト上限
• force_runtime: mlx|llamacpp|vllm — 分析中の自動ランタイム選択を上書き

API の動作をローカルで検証:

# サーバーを自動的に起動し、エンドポイント/スキーマ/フィルターのアサーションを実行
python3 scripts/test_api.py --spawn

# またはすでに実行中のサーバーをテスト
python3 scripts/test_api.py --base-url http://127.0.0.1:8787

ハードウェアの上書き

ハードウェアの自動検出は一部のシステム（例: 壊れた nvidia-smi、VM、パススルー構成）で失敗することがあります。また、別のターゲットハードウェアに対してモデルの適合度を評価したい場合もあるでしょう。--memory、--ram、--cpu-cores を使って検出された値を上書きできます:

# GPU VRAM を上書き
llmfit --memory=32G

# システム RAM を上書き
llmfit --ram=128G

# CPU コア数を上書き
llmfit --cpu-cores=16

# 上書きを組み合わせてターゲットハードウェアをシミュレーション
llmfit --memory=24G --ram=64G --cpu-cores=8 fit
llmfit --memory=24G --ram=64G system --json

# すべてのモードで動作: TUI、CLI、サブコマンド
llmfit --memory=24G --cli
llmfit --memory=24G fit --perfect -n 5
llmfit --ram=64G recommend --json

--memory と --ram で使える接尾辞: G/GB/GiB（ギガバイト）、M/MB/MiB（メガバイト）、T/TB/TiB（テラバイト）。大文字小文字は区別されません。GPU が検出されなかった場合、--memory は合成 GPU エントリを作成し、モデルが GPU 推論用にスコアリングされるようにします。統合メモリシステム（Apple Silicon）では、--ram は VRAM も更新します。VRAM を独立して上書きするには --memory を使ってください。

推定用のコンテキスト長の上限

--max-context を使うと、メモリ推定に使用するコンテキスト長を上限で制限できます（各モデルが公称する最大コンテキストは変更しません）:

# 4K コンテキストでメモリ適合度を推定
llmfit --max-context 4096 --cli

# サブコマンドで動作
llmfit --max-context 8192 fit --perfect -n 5
llmfit --max-context 16384 recommend --json --limit 5

--max-context が設定されていない場合、llmfit は利用可能であれば OLLAMA_CONTEXT_LENGTH を使用します。

JSON 出力

任意のサブコマンドに --json を追加すると、機械可読な出力が得られます:

llmfit --json system     # ハードウェアスペックを JSON で
llmfit --json fit -n 10  # 上位 10 件の適合を JSON で
llmfit recommend --json  # 上位 5 件の推奨（recommend では JSON がデフォルト）
llmfit plan "Qwen/Qwen2.5-Coder-0.5B-Instruct" --context 8192 --json

plan の JSON には以下の安定したフィールドが含まれます:

• リクエスト（context、quantization、target_tps）
• 推定された最小/推奨ハードウェア
• パスごとの実行可能性（gpu、cpu_offload、cpu_only）
• アップグレード差分

仕組み

1. ハードウェア検出 -- sysinfo で合計/利用可能 RAM を読み取り、CPU コアを数え、GPU を探索します:

   • NVIDIA -- nvidia-smi によるマルチ GPU サポート。検出されたすべての GPU の VRAM を集約します。レポートが失敗した場合は GPU モデル名から VRAM を推定してフォールバックします。
   • AMD -- rocm-smi で検出。
   • Intel Arc -- ディスクリート VRAM は sysfs 経由、統合は lspci 経由。
   • Apple Silicon -- system_profiler 経由の統合メモリ。VRAM = システム RAM。
   • Ascend -- npu-smi で検出。
   • バックエンド検出 -- 速度推定のために、アクセラレーションバックエンド（CUDA、Metal、ROCm、SYCL、CPU ARM、CPU x86、Ascend）を自動的に識別します。

2. モデルデータベース -- HuggingFace API から取得した数百のモデルを data/hf_models.json に保存し、コンパイル時に埋め込みます。メモリ要件は、量子化階層（Q8_0 から Q2_K まで）にわたるパラメータ数から計算されます。VRAM は GPU 推論の主要な制約であり、システム RAM は CPU のみの実行のフォールバックです。

   MoE サポート -- Mixture-of-Experts アーキテクチャを持つモデル（Mixtral、DeepSeek-V2/V3）は自動的に検出されます。トークンごとにアクティブになるのはエキスパートの一部のみなので、実効 VRAM 要件は総パラメータ数が示すよりもはるかに低くなります。例えば、Mixtral 8x7B は総パラメータ 46.7B ですが、トークンごとにアクティブになるのは約 12.9B のみで、エキスパートオフロードにより VRAM が 23.9 GB から約 6.6 GB に削減されます。

3. 動的量子化 -- 固定の量子化を仮定する代わりに、llmfit はあなたのハードウェアに収まる最高品質の量子化を試します。Q8_0（最高品質）から Q2_K（最も圧縮）までの階層をたどり、利用可能なメモリに収まる最高品質のものを選びます。フルコンテキストで何も収まらない場合は、半分のコンテキストで再試行します。

4. 多次元スコアリング -- 各モデルは 4 つの次元（それぞれ 0〜100）でスコアリングされます:

   次元	測定するもの
   Quality	パラメータ数、モデルファミリーの評判、量子化ペナルティ、タスク整合性
   Speed	バックエンド、パラメータ、量子化に基づく推定トークン/秒
   Fit	メモリ使用効率（最適点: 利用可能メモリの 50〜80%）
   Context	ユースケースに対するコンテキストウィンドウ能力 vs ターゲット

   各次元は重み付き複合スコアに統合されます。重みはユースケースカテゴリ（General、Coding、Reasoning、Chat、Multimodal、Embedding）によって異なります。例えば、Chat は Speed を高く重み付け（0.35）し、Reasoning は Quality を高く重み付け（0.55）します。モデルは複合スコアでランク付けされ、実行不可能なモデル（Too Tight）は常に最下位になります。

5. 速度推定 -- LLM 推論におけるトークン生成はメモリ帯域幅に律速されます。各トークンは VRAM からモデルの全重みを一度読み取る必要があります。GPU モデルが認識されると、llmfit はその実際のメモリ帯域幅を使ってスループットを推定します:

   計算式: (bandwidth_GB_s / model_size_GB) × efficiency_factor

   効率係数（0.55）とモードごとの速度倍率は、詳細設定ポップアップ（TUI の A）で調整できます。デフォルト値は、カーネルオーバーヘッド、KV キャッシュの読み取り、メモリコントローラーの影響を考慮しています。このアプローチは、llama.cpp の公開ベンチマーク（Apple Silicon、NVIDIA T4）および実環境の測定値に対して検証されています。

   帯域幅ルックアップテーブルは、NVIDIA（コンシューマー + データセンター）、AMD（RDNA + CDNA）、Apple Silicon ファミリーにわたる約 80 の GPU をカバーしています。

   認識されない GPU の場合、llmfit はバックエンドごとの速度定数にフォールバックします:

   バックエンド	速度定数
   CUDA	220
   Metal	160
   ROCm	180
   SYCL	100
   CPU (ARM)	90
   CPU (x86)	70
   NPU (Ascend)	390

   フォールバック計算式: K / params_b × quant_speed_multiplier。モードごとのペナルティは詳細設定ポップアップ（TUI の A）で調整できます。

6. 適合度分析 -- 各モデルはメモリ互換性について評価されます:

   実行モード:

   • GPU -- モデルが VRAM に収まる。高速な推論。
   • MoE -- エキスパートオフロード付きの Mixture-of-Experts。アクティブなエキスパートは VRAM に、非アクティブは RAM に。
   • CPU+GPU -- VRAM が不足し、部分的な GPU オフロードでシステム RAM にあふれる。
   • CPU -- GPU なし。モデルは完全にシステム RAM に読み込まれる。

   適合レベル:

   • Perfect -- GPU で推奨メモリを満たす。GPU アクセラレーションが必要。
   • Good -- 余裕を持って収まる。MoE オフロードや CPU+GPU で達成可能な最良。
   • Marginal -- ぎりぎりの適合、または CPU のみ（CPU のみは常にここで頭打ち）。
   • Too Tight -- どこにも十分な VRAM やシステム RAM がない。

モデルデータベース

モデルリストは、HuggingFace REST API をクエリするスタンドアロンの Python スクリプト scripts/scrape_hf_models.py（標準ライブラリのみ、pip 依存なし）によって生成されます。Meta Llama、Mistral、Qwen、Google Gemma、Microsoft Phi、DeepSeek、IBM Granite、Allen Institute OLMo、xAI Grok、Cohere、BigCode、01.ai、Upstage、TII Falcon、HuggingFace、Zhipu GLM、Moonshot Kimi、Baidu ERNIE など、数百のモデルとプロバイダーを含みます。スクレイパーは、モデル設定（num_local_experts、num_experts_per_tok）と既知のアーキテクチャマッピングを通じて MoE アーキテクチャを自動検出します。

モデルカテゴリは、汎用、コーディング（CodeLlama、StarCoder2、WizardCoder、Qwen2.5-Coder、Qwen3-Coder）、推論（DeepSeek-R1、Orca-2）、マルチモーダル/ビジョン（Llama 3.2 Vision、Llama 4 Scout/Maverick、Qwen2.5-VL）、チャット、エンタープライズ（IBM Granite）、埋め込み（nomic-embed、bge）にわたります。

完全なリストは MODELS.md を参照してください。

モデルデータベースはコンパイル時に埋め込まれるため、エンドユーザーは llmfit 自体をアップグレード（brew upgrade llmfit、scoop update llmfit、または新しいリリースのダウンロード）することで更新を受け取ります。以下のコマンドは、ソースからデータベースを更新するコントリビューター向けです:

モデルデータベースを更新するには:

# 自動更新（推奨）
make update-models

# またはスクリプトを直接実行
./scripts/update_models.sh

# または手動で
python3 scripts/scrape_hf_models.py
cargo build --release

スクレイパーは data/hf_models.json を書き込み、これは include_str! を介してバイナリに焼き込まれます。自動更新スクリプトは既存データをバックアップし、JSON 出力を検証し、バイナリを再ビルドします。

デフォルトでは、スクレイパーは unsloth や bartowski などのプロバイダーから既知の GGUF ダウンロードソースでモデルを補強します。結果は data/gguf_sources_cache.json にキャッシュされ（7 日間の TTL）、API 呼び出しの繰り返しを避けます。補強をスキップしてスクレイプを高速化するには --no-gguf-sources を使ってください。

プロジェクト構成

src/
  main.rs         -- CLI 引数解析、エントリポイント、TUI 起動
  hardware.rs     -- システム RAM/CPU/GPU 検出（マルチ GPU、バックエンド識別）
  models.rs       -- モデルデータベース、量子化階層、動的量子化選択
  fit.rs          -- 多次元スコアリング（Q/S/F/C）、速度推定、MoE オフロード
  providers.rs    -- ランタイムプロバイダー統合（Ollama、llama.cpp、MLX、Docker Model Runner、LM Studio）、インストール検出、pull/ダウンロード
  display.rs      -- 従来型 CLI テーブルレンダリング + JSON 出力
  tui_app.rs      -- TUI アプリケーション状態、フィルター、ナビゲーション
  tui_ui.rs       -- TUI レンダリング（ratatui）
  tui_events.rs   -- TUI キーボードイベント処理（crossterm）
data/
  hf_models.json  -- モデルデータベース（206 モデル）
skills/
  llmfit-advisor/ -- ハードウェアを考慮したモデル推奨のための OpenClaw スキル
scripts/
  scrape_hf_models.py        -- HuggingFace API スクレイパー
  update_models.sh            -- 自動データベース更新スクリプト
  install-openclaw-skill.sh   -- OpenClaw スキルをインストール
Makefile           -- ビルドとメンテナンスのコマンド

crates.io への公開

Cargo.toml にはすでに必要なメタデータ（description、license、repository）が含まれています。公開するには:

# 問題を検出するため、まずドライラン
cargo publish --dry-run

# 本番の公開（crates.io API トークンが必要）
cargo login
cargo publish

公開する前に、以下を確認してください:

• Cargo.toml のバージョンが正しいこと（リリースごとに上げる）。
• リポジトリのルートに LICENSE ファイルが存在すること。なければ作成します:

# MIT ライセンスの場合:
curl -sL https://opensource.org/license/MIT -o LICENSE
# または独自に書く。Cargo.toml は license = "MIT" を宣言しています。

• data/hf_models.json がコミットされていること。これはコンパイル時に埋め込まれ、公開される crate に含まれている必要があります。

更新を公開するには:

# バージョンを上げる
# Cargo.toml を編集: version = "0.2.0"
cargo publish

依存関係

ランタイムプロバイダー統合

llmfit は複数のローカルランタイムプロバイダーをサポートします:

• Ollama（デーモン/API ベースの pull）
• llama.cpp（Hugging Face からの直接 GGUF ダウンロード + ローカルキャッシュ検出）
• MLX（Apple Silicon / mlx-community のモデルキャッシュ + オプションのサーバー） — MLX のダウンロードは元のモデル公開者ではなく、HuggingFace の mlx-community/* リポジトリにマッピングされます
• Docker Model Runner（Docker Desktop 組み込みのモデルサービング）
• LM Studio（モデル管理 + ダウンロード用の REST API を備えたローカルモデルサーバー）

あるモデルに対して互換性のあるプロバイダーが複数利用可能な場合、TUI で d を押すとプロバイダー選択モーダルが開きます。

Ollama 統合

llmfit は Ollama と統合し、すでにインストールされているモデルを検出したり、TUI から直接新しいモデルをダウンロードしたりできます。

要件

• Ollama がインストールされ実行中であること（ollama serve または Ollama デスクトップアプリ）
• llmfit は http://localhost:11434（Ollama のデフォルト API ポート）に接続します
• 設定は不要 — Ollama が実行中なら、llmfit は自動的に検出します

リモートの Ollama インスタンス

別のマシンやポートで実行中の Ollama に接続するには、OLLAMA_HOST 環境変数を設定します:

# 特定の IP とポートの Ollama に接続
OLLAMA_HOST="http://192.168.1.100:11434" llmfit

# ホスト名経由で接続
OLLAMA_HOST="http://ollama-server:666" llmfit

# すべての TUI および CLI コマンドで動作
OLLAMA_HOST="http://192.168.1.100:11434" llmfit --cli
OLLAMA_HOST="http://192.168.1.100:11434" llmfit fit --perfect -n 5

これは以下の場合に便利です:

• あるマシンで llmfit を実行し、Ollama を別のマシンからサーブする（例: GPU サーバー + ノート PC クライアント）
• カスタムポートの Docker コンテナで実行中の Ollama に接続する
• リバースプロキシやロードバランサーの背後にある Ollama を使う

仕組み

起動時、llmfit は GET /api/tags をクエリしてインストール済みの Ollama モデルを一覧表示します。インストール済みの各モデルには、TUI の Inst 列に緑の ✓ が付きます。システムバーには Ollama: ✓ (N installed) と表示されます。

モデルで d を押すと、llmfit は POST /api/pull を Ollama に送ってダウンロードします。行はアニメーション付きのプログレスインジケーターでハイライトされ、ダウンロードの進捗がリアルタイムで表示されます。完了すると、モデルはすぐに Ollama で利用可能になります。

Ollama が実行されていない場合、Ollama 固有の操作はスキップされます。TUI は利用可能であれば llama.cpp など他のプロバイダーを引き続きサポートします。

llama.cpp 統合

llmfit は llama.cpp を、TUI と CLI の両方でランタイム/ダウンロードプロバイダーとして統合します。

要件:

• llama-cli または llama-server が PATH で利用可能であること（ランタイム検出用）
• GGUF ダウンロードのための Hugging Face へのネットワークアクセス

仕組み:

• llmfit は HF モデルを既知の GGUF リポジトリにマッピングします（ヒューリスティックなフォールバック付き）
• GGUF ファイルをローカルの llama.cpp モデルキャッシュにダウンロードします
• 一致する GGUF ファイルがローカルに存在する場合、モデルをインストール済みとしてマークします

環境変数

llama.cpp が標準外の場所にインストールされている場合は、PATH に含めることを要求せずに llmfit が見つけられるよう、LLAMA_CPP_PATH を設定してください。

Docker Model Runner 統合

llmfit は Docker Desktop 組み込みのモデルサービング機能である Docker Model Runner と統合します。

要件:

• Model Runner が有効になった Docker Desktop
• デフォルトエンドポイント: http://localhost:12434

仕組み:

• llmfit は GET /engines をクエリして Docker Model Runner で利用可能なモデルを一覧表示します
• モデルは Ollama スタイルのタグマッピングを使って HF データベースと照合されます（Docker Model Runner は ai/<tag> 命名を使用）
• TUI で d を押すと docker model pull 経由で pull します

リモートの Docker Model Runner インスタンス

別のホストやポートの Docker Model Runner に接続するには、DOCKER_MODEL_RUNNER_HOST 環境変数を設定します:

DOCKER_MODEL_RUNNER_HOST="http://192.168.1.100:12434" llmfit

LM Studio 統合

llmfit は、組み込みのモデルダウンロード機能を備えたローカルモデルサーバーである LM Studio と統合します。

要件:

• LM Studio がローカルサーバーを有効にして実行中であること
• デフォルトエンドポイント: http://127.0.0.1:1234

仕組み:

• llmfit は GET /v1/models をクエリして LM Studio で利用可能なモデルを一覧表示します
• TUI で d を押すと POST /api/v1/models/download 経由でダウンロードをトリガーします
• ダウンロードの進捗は GET /api/v1/models/download-status をポーリングして追跡されます
• LM Studio は HuggingFace のモデル名を直接受け入れるため、名前のマッピングは不要です

リモートの LM Studio インスタンス

別のホストやポートの LM Studio に接続するには、LMSTUDIO_HOST 環境変数を設定します:

LMSTUDIO_HOST="http://192.168.1.100:1234" llmfit

モデル名のマッピング

llmfit のデータベースは HuggingFace のモデル名（例: Qwen/Qwen2.5-Coder-14B-Instruct）を使いますが、Ollama は独自の命名スキーム（例: qwen2.5-coder:14b）を使います。llmfit は両者の間の正確なマッピングテーブルを維持し、インストール検出と pull が正しいモデルに解決されるようにします。各マッピングは厳密で、qwen2.5-coder:14b はベースの qwen2.5:14b ではなく Coder モデルにマッピングされます。

プラットフォームサポート

• Linux -- フルサポート。GPU 検出は nvidia-smi（NVIDIA）、rocm-smi（AMD）、sysfs/lspci（Intel Arc）、npu-smi（Ascend）経由。
• macOS (Apple Silicon) -- フルサポート。system_profiler 経由で統合メモリを検出。VRAM = システム RAM（共有プール）。モデルは Metal GPU アクセラレーション経由で実行。
• macOS (Intel) -- RAM と CPU の検出が動作。nvidia-smi が利用可能ならディスクリート GPU を検出。
• Windows -- RAM と CPU の検出が動作。インストールされていれば nvidia-smi 経由で NVIDIA GPU を検出。
• Android / Termux / PRoot -- CPU と RAM の検出は通常動作しますが、GPU の自動検出は現在サポートされていません。Adreno などのモバイル GPU は、llmfit が使うデスクトップ/サーバーの探索インターフェースからは通常見えません。

GPU サポート

自動検出が失敗したり誤った値を報告したりする場合は、--memory、--ram、--cpu-cores を使って上書きしてください（上記のハードウェアの上書きを参照）。

Android / Termux に関する注意

Termux + PRoot などの Android 構成では、llmfit は標準的な Linux 検出パス（nvidia-smi、rocm-smi、DRM/sysfs、lspci など）を通じてモバイル GPU を見ることが通常できません。そうした環境では、現在の実装では「GPU が検出されない」のが想定どおりの動作です。

それでも統合メモリのスマートフォンやタブレットで GPU スタイルの推奨が欲しい場合は、手動のメモリ上書きを使ってください:

llmfit --memory=8G fit -n 20
llmfit recommend --json --memory=8G --limit 10

これは推奨/スコアリングのみのための回避策であり、真の Android GPU ランタイム検出を提供するものではありません。

コントリビューション

コントリビューション、特に新しいモデルの追加を歓迎します。

PR を提出する前に

変更をプッシュする前に cargo fmt を実行してください。ほとんどの CI チェックの失敗は、フォーマットされていないコードが原因です:

cargo fmt

モデルの追加

1. モデルの HuggingFace リポジトリ ID（例: meta-llama/Llama-3.1-8B）を scripts/scrape_hf_models.py の TARGET_MODELS リストに追加します。
2. モデルがゲートされている場合（メタデータへのアクセスに HuggingFace 認証が必要な場合）、同じスクリプトの FALLBACKS リストにパラメータ数とコンテキスト長を含むフォールバックエントリを追加します。
3. 自動更新スクリプトを実行します:
   shCopy

   make update-models
   # または: ./scripts/update_models.sh
   

4. 更新されたモデルリストを確認します: ./target/release/llmfit list
5. 次を実行して MODELS.md を更新します: python3 << 'EOF' < scripts/...（ジェネレータースクリプトはコミット履歴を参照）
6. プルリクエストを開きます。

現在のリストは MODELS.md、アーキテクチャの詳細は AGENTS.md を参照してください。

OpenClaw 統合

llmfit は OpenClaw スキルとして提供され、エージェントがハードウェアに適したローカルモデルを推奨し、Ollama/vLLM/LM Studio プロバイダーを自動設定できるようにします。

スキルのインストール

# llmfit リポジトリから
./scripts/install-openclaw-skill.sh

# または手動で
cp -r skills/llmfit-advisor ~/.openclaw/skills/

インストールしたら、OpenClaw エージェントに次のようなことを尋ねられます:

• 「どんなローカルモデルを実行できる?」
• 「私のハードウェアに合うコーディングモデルを推奨して」
• 「私の GPU に最適なモデルで Ollama をセットアップして」

エージェントは内部で llmfit recommend --json を呼び出し、結果を解釈して、最適なモデル選択で openclaw.json を設定することを提案します。

仕組み

このスキルは OpenClaw エージェントに次のことを教えます:

1. llmfit --json system でハードウェアを検出する
2. llmfit recommend --json でランク付けされた推奨を取得する
3. HuggingFace のモデル名を Ollama/vLLM/LM Studio のタグにマッピングする
4. openclaw.json の models.providers.ollama.models を設定する

完全なスキル定義は skills/llmfit-advisor/SKILL.md を参照してください。

代替ツール

別のアプローチをお探しなら、llm-checker をチェックしてください。これは Ollama 統合を備えた Node.js 製の CLI ツールで、モデルを直接 pull してベンチマークできます。スペックから推定するのではなく、実際に Ollama 経由でハードウェア上でモデルを動かすという、より実践的なアプローチを取ります。すでに Ollama がインストールされていて実環境のパフォーマンスをテストしたい場合に適しています。ただし MoE（Mixture-of-Experts）アーキテクチャはサポートしていない点に注意してください。すべてのモデルが密（dense）として扱われるため、Mixtral や DeepSeek-V3 のようなモデルのメモリ推定値は、より小さいアクティブな部分集合ではなく総パラメータ数を反映します。

ライセンス

MIT