ハクソク

世界を動かす技術を、日本語で。

システムのRAM、CPU、GPUに最適化されたLLMモデル

85日前原文(github.com)

概要

llmfit は、数百種類のLLMモデルやプロバイダーに対応し、 1コマンドで自分のPCに最適なモデルを選定 できるターミナルツール。 ハードウェア自動検出 と 多次元スコアリング により、品質・速度・適合性・文脈長でモデルを比較。 TUI（対話型UI） と CLI（コマンドライン） モードを搭載し、 GPU/CPU/メモリ構成 に応じて動作可能なモデルを案内。 MoEアーキテクチャ や 動的量子化、 マルチGPU、 ローカル実行環境 もサポート。 インストールや利用方法も クロスプラットフォーム で簡単。

llmfitの概要・特徴

  • 数百種類のLLMモデル・プロバイダー を一括管理
  • 1コマンド で自分のハードウェアに適したモデルを自動判定
  • CPU・RAM・GPU・VRAM を自動検出、モデルごとに 品質・速度・適合性・文脈長 でスコアリング
  • TUI（対話型UI） と CLI（コマンドライン） の2モードを搭載
  • マルチGPU構成、 MoE（Mixture-of-Experts）、 動的量子化、 ローカル実行プロバイダー （Ollama, llama.cpp, MLX）に対応
  • sympozium （Kubernetesエージェント管理）の姉妹プロジェクト

インストール方法

  • macOS/Linux高速インストール
    • curl -fsSL https://llmfit.axjns.dev/install.sh | sh 最新バイナリ をGitHubからダウンロードし、/usr/local/bin（または~/.local/bin）に配置
    • Homebrew 対応：brew install llmfit
  • Windows
    • Cargo 推奨：cargo install llmfit
    • Rust未導入の場合 はrustupでRust導入後にCargo利用
  • ソースからビルド
    • git clone https://github.com/AlexsJones/llmfit.git
    • cd llmfit
    • cargo build --release

TUI（対話型UI）利用方法

  • llmfitコマンドで TUI起動
    • CPU/RAM/GPU/VRAM/バックエンド が画面上部に表示
    • モデル一覧は スコア順 にスクロール表示
    • 各行に スコア・推定トークン速度・最適量子化・実行モード・メモリ利用量・用途 を表示
  • 主なキーバインド
    • 上下/j/k：モデル間移動
    • /：検索モード
    • f：適合性フィルタ切替（All, Runnable, Perfect, Good, Marginal）
    • a：利用可否フィルタ（All, GGUF Avail, Installed）
    • s：ソートカラム切替
    • t：カラーテーマ切替（6種、設定保存）
    • p：選択モデルの Planモード （必要ハードウェア逆算）
    • d：モデルダウンロード
    • q：終了

Planモード

  • モデルごとに必要ハードウェアを逆算
    • 文脈長・量子化・目標トークン速度を入力し、 最小/推奨VRAM・RAM・CPUコア数 を推定
    • 実行パスごとの可否（GPU、CPUオフロード、CPUのみ）やアップグレード差分も表示

テーマ

  • tキーで 6種類のカラーテーマ を切替可能
    • Default, Dracula, Solarized, Nord, Monokai, Gruvbox

CLIモード利用例

  • llmfit --cli：全モデルをテーブル表示
  • llmfit fit --perfect -n 5：完全適合モデル上位5件
  • llmfit system：システムスペック表示
  • llmfit list：全モデル一覧
  • llmfit search "llama 8b"：名前・プロバイダー・サイズで検索
  • llmfit info "Mistral-7B"：モデル詳細
  • llmfit recommend --json --limit 5：推奨モデル（JSON）
  • llmfit plan "Qwen/Qwen3-4B-MLX-4bit" --context 8192：特定構成の必要ハードウェア推定

VRAM・文脈長オーバーライド

  • GPU VRAM自動検出失敗時 は--memoryで手動指定
    • 例：llmfit --memory=32G
  • メモリ見積もり用文脈長制限 は--max-contextで指定
    • 例：llmfit --max-context 4096 --cli

JSON出力

  • すべてのサブコマンドで--json指定可能
    • 機械可読なハードウェア・推奨・プラン情報を出力

仕組み・内部ロジック

  • ハードウェア検出
    • RAM/CPUコア数/GPU（NVIDIA, AMD, Intel Arc, Apple Silicon, Ascend）を自動取得
    • マルチGPU はVRAM合算、バックエンドも自動判定（CUDA, Metal, ROCm, SYCL, CPU ARM/x86, Ascend）
  • モデルデータベース
    • HuggingFace API から数百モデルを自動取得し、ビルド時に埋め込み
    • パラメータ数・量子化階層ごとに メモリ要件計算
    • MoE はアクティブエキスパート分のみVRAM計算
  • 動的量子化
    • Q8_0→Q2_K の階層で、ハードウェアに最適な量子化を自動選択
    • フル文脈長で収まらない場合は半分で再試行
  • 多次元スコアリング
    • 品質・速度・適合性・文脈長 の4軸で0–100点評価
    • 用途別（General, Coding, Reasoning, Chat, Multimodal, Embedding）で重み付け変更
    • 実行不可なモデルは常に最下位
  • 速度推定
    • GPUメモリ帯域幅 に基づき推定（80種以上のGPUに対応）
    • 未対応GPUはバックエンドごとの定数で推定
  • 適合性分析
    • 実行モード （GPU, MoE, CPU+GPU, CPU）ごとに適合レベル（Perfect, Good, Marginal, Too Tight）を判定

モデルデータベース管理

  • 自動更新 はmake update-modelsまたは./scripts/update_models.sh
  • 手動更新 はpython3 scripts/scrape_hf_models.py後、cargo build --release
  • GGUFダウンロード元 も自動付与（unsloth, bartowski等）

プロジェクト構成

  • src/main.rs：CLI引数・TUI起動
  • hardware.rs：ハードウェア検出
  • models.rs：モデルDB・量子化階層・自動選択
  • fit.rs：スコアリング・速度推定・MoEオフロード
  • providers.rs：ランタイムプロバイダー管理

llmfit は、複雑なLLMモデル選定・実行を 一元化・自動化 する強力なツール。 手軽な導入・豊富なUI・詳細な分析機能 で、LLM運用の最適化を実現。

Hackerたちの意見

いいアイデアだけど、モデルがちょっと古い感じだね。僕のM4 MacBook Pro（メモリ128GB）に対して、qwen 2.5やstarcoder 2を完璧なマッチとして勧めてる。

Claudeは、システムスペックを入力すれば、結構いいおすすめをしてくれるよ。

└

このプロンプトを使ったら、すでにインストールしているモデルともう一つを提案されたんだ。これが「最新」の答えかどうかはわからないけど。 > このコンピュータで実行できる最高のローカルLLMは何ですか？ Ollama（これが好き）とLM Studioを持っているけど、他のもインストールするつもり。コスパが良ければね。RAMなどを調べるためにbashコマンドを使って。ツールコールができるモデルがいいな。

なんでダウンロードして実行しないといけないの？ドロップダウンで自分の機材スペックを提出するだけでわかるようにできないの？

これ、めっちゃクールで役立つけど、ウェブサイトだったらいいのにな。実行ファイルを動かすのはちょっと面倒だよね。ウェブサイトでできることなのに。（ちょっとした機能を除けば、Corsairを有効にしても、ブラウザからインストールされたモデルを確認できるし。）でも、楽しそうな個人プロジェクトだね。

└

似たようなことをやってるこのウェブサイト、ずっと好きだったな。https://apxml.com/tools/vram-calculator

└

Huggingfaceにはそれが組み込まれてるよ。

└

最近、これに関するウェブサイトを見つけたんだけど、ちょっと見てみる価値あるかも。 https://whatmodelscanirun.com

└

LLMモデルのコミュニティ運営のデータベースで、トークン/秒の設定詳細が載ってるウェブサイトがあるよ。 https://inferbench.com/

└

これがウェブサイトだったらいいのに。実行可能ファイルを動かすのは好きじゃないな、ウェブサイトで完璧にできることなのに。ツールはハードウェア検出に依存してるからね。 https://github.com/AlexsJones/llmfit?tab=readme-ov-file#how-... から：どうやって動くか ハードウェア検出 -- sysinfoを使って合計/使用可能なRAMを読み取り、CPUコアをカウントし、GPUを探る。NVIDIA -- nvidia-smiを使ってマルチGPUサポート。検出されたすべてのGPUのVRAMを集計。報告が失敗したらGPUモデル名からVRAMを推定。AMD -- rocm-smiで検出。Intel Arc -- sysfs経由で離散VRAM、lspci経由で統合。Apple Silicon -- system_profiler経由で統合メモリ。VRAM = システムRAM。Ascend -- npu-smiで検出。バックエンド検出 -- スピード推定のために加速バックエンド（CUDA、Metal、ROCm、SYCL、CPU ARM、CPU x86、Ascend）を自動的に特定。だから、JavaScriptを実行するウェブサイトはブラウザのサンドボックスに制限されていて、合計システムRAMや正確なGPUの数などの低レベルの詳細を見ることができないんだ。このアイデアをウェブサイトだけにして、JavaScriptの制限を回避するには、別のワークフローが必要になるよ。例えば、macOSのシステムレポートを実行して.spdファイルを生成するか、Linuxのinxiを実行してハードウェアデバイスのレポートを生成して、それをウェブサイトにアップロードして「LLMの最適フィット」を導き出すとか。でも、そのOSレポートファイルには、GitHubツールが集める詳細が欠けているかもしれない。別の方法としては、ユーザーが手動で組み合わせを選ぶハードウェアオプションがたくさんあるウェブサイトを作ることだね。便利さは劣るけど、ユーザーが実際には持っていないハードウェアの「もしも」シナリオを考えることができる利点があるからね。（はっきり言っておくけど、この特定のGitHubツールを推奨してるわけじゃないよ。ただ、LLMfitウェブサイトには技術的な制限があるって指摘してるだけ。）

└

つい最近、Hugging Faceがこれをできるって知ったんだ。ハードウェアを手動で入力しなきゃいけないけど。今って、みんなが何を使ってローカルモデルを動かしてるかも知らずに実行してる状態なの？

僕がやってるのは、ClaudeかCodexにOllamaでモデルを実行させて、いくつかのタスクを順番にテストして出力を評価すること。30分後にはフィットするモデルが見つかるよ。壊れたモデルもテストしてくれた。

└

プロンプトを共有してくれませんか？

LLMについてあまり詳しくない僕だけど、これにはワクワクしてる。システムリソースとコンテキストの関連性、例えばN量のコンテキストにどれくらいのメモリが必要かを理解するのに苦労してる。最近は、ローカルモデルを使ってコーディングエージェントを試してるんだけど、Geminiが空くのを待つのに疲れちゃって、サーバーでプロンプトを処理するための計算時間を確保するのが90年代の大学生みたいに感じる。Mistralのバイブを試したけど、小さなプロジェクト（1k行にも満たないけど、複数のファイルやヘッダーがある）で簡単にコンテキストが足りなくなっちゃった。16kくらいで最大サポートに設定したけど、それが遅くしてるのかどうかわからなかった（プロンプトが終わるのに10分くらいかかったし、『このCコードベースをC++に書き換えて』っていう内容だった）。

これは素晴らしいプロジェクトだね。参考までに、必要なのはLLMのサイズとメモリ量、帯域幅だけで、これが合うかどうかがわかるんだ。トークン/秒の計算も簡単で、式はこうなるよ：llm_size = パラメータ数 * パラメータのサイズ。だから、32Bモデルを4ビットで使うには、最低でも16GBのRAMが必要だね。それから、tok_per_s = メモリ帯域幅 / llm_sizeを計算するんだ。RTX3090は960GB/sだから、32Bモデル（16GBのVRAM）は960/16 = 60 tok/sを出すことになるよ。MoEの場合、速度は主にアクティブなパラメータの数によって決まるから、LLMの総サイズではないんだ。いくつかの詳細を考慮して、これらの数字に10%のマージンを加えておくといいよ。でも、大体そんな感じ。RAMの使用量はコンテキストウィンドウのサイズが大きくなると増えるよ。

└

RAMの使用量はコンテキストウィンドウのサイズが大きくなると増えるよ。KVキャッシュは生成されたトークンごとに書き込みが限られているから、かなりスワップ可能なんだ（推論ではトークンごとにllm_active_size分の書き込みが必要だから、スケールで考えるとそれは多すぎる！）。だから、RAMを節約しながらも、かなり良いパフォーマンスで長いコンテキストをサポートできるかもしれないよ。特にMoEエキスパートのモデルパラメータをロードするためにmmapを使っていることを確認してね。最初に十分なRAMがあればパフォーマンスに悪影響はないし、その後は非常に限られた初期コストでスケールアップできるからね（メモリ帯域幅の一部をはるかに低いストレージ帯域幅に置き換えるだけだから）。

これは視覚的に素晴らしいけど、試してみたら「Qwen 3.5はこのマシンでは実行できません」って言われたんだ。今はバックグラウンドでコーディングしてるのに。だから、こういうツールの真の価値が何なのかわからないな、最初の印象を得るくらいしかないかも。あと、unslothがカスタム調整を提供しているおかげで、元々「元に戻せない」とされていたモデルが実行可能になってるけど、それはツールには載ってないんだ。厳しく言うつもりはないけど、ちゃんとやるのは本当に難しいことだよね。そして、似たようなツールが多い中で、ここでのメンテナは、モデルが次々と出てきて追いつけなくなることに苦労することになるだろうね。

発表おめでとう！例えば、Ollamaユーザーには役立つね。それに、LM Studioにはインターフェースにヒントが組み込まれてるよ。

これでおそらく85%くらいのケースをカバーできてると思うけど、もっと良くできるかも。例えば、いくつかのAMDのiGPUはROCmに対応してないから、Vulkanサポートに頼ることになる。そういう場合、ドライバーの引数を渡して、ドライバーがシステムRAMを使ってVRAMを拡張したり、「正しい」VRAMの量を指定したりできることもあるよ。（iGPUでは、システムRAMとVRAMは物理的に同じものだからね）この場合、どれだけのシステムRAMを譲るか慎重に選んで、両者のバランスを取る必要があるよ（片方でOOMを避けるため、もう片方でVRAMが少なすぎないように）。これをやれば、通常は読み込めないモデルも選べるようになるよ。特にレイヤーオフロードや量子化されたMoEウェイトと組み合わせると便利だね。