FitLLM エンジン

ライブ: https://fitllm.run · バイリンガル · 無料 · 広告なし · ログイン不要

オープンエンジン: fitllm-engine (MIT · npm fitllm-engine · npx fitllm)

依存関係ゼロ。読みやすい単一ファイル: engine.js。適合性ベクターでテスト済み。MIT。

npx fitllm "GLM-4.7-Flash" --gpu 4090     # ✓ FITS — 21.9/24 GB, free 2.1 GB
npx fitllm "gpt-oss-120b" --mac 64        # ✗ WON'T FIT → what to change to make it fit
npx fitllm "Qwen 3.6 35B" --gpu "5090 + 3090"   # multi-GPU rig — VRAM pools (56GB), even mixed cards
npx fitllm --top --detect                 # what CAN this machine run? — best quant per model
npx fitllm --detect                       # reads this machine's real hardware

なぜCLIなのか? 「実行できるか?」という問いはターミナルで生まれます — ollama pull の1行前です。インストール不要、タブ切り替え不要、そして --detect を使えばVRAMを知っている必要はなく、実際のハードウェアを読み取ります。終了コード0/1により、ダウンロード前のガードとして機能します:

# in your model-pull script — stop BEFORE the 40 GB download:
npx fitllm "gpt-oss-120b" --detect || { echo "won't fit — aborting pull"; exit 1; }

これはFitLLMのオープンな計算コアです。計算式がオープンなので、監査できます。

「Qwen 3.6 は私のGPUに収まりますか?」とLLMに尋ねると、学習カットオフ時点のアーキテクチャにパターンマッチングし、通常はノーと答えます。カタログベースの計算機は新リリースに遅れを取ります。FitLLMは各モデルの公式 config.json をライブで読み取るため、リリース初日や、単純な計算式では間違えるハイブリッド / スライディングウィンドウ / MoE アーキテクチャでも正確です。

Apple Silicon ユニファイドメモリ (M1–M5、Pro/Max/Ultra — 512GB Mac Studio まで)、NVIDIA GPU (RTX 20/30/40/50、ワークステーション RTX 6000 Ada / RTX PRO 6000、データセンター A100/H100/H200/B200)、AMD Radeon (RX 7000/9000、PRO W7900)、マルチGPUプリセット (2×3090、2×4090、4×3090) をカバー — GGUF Q階層の重み量子化はKVキャッシュ量子化とは別に扱います。すべてのハードウェア数値は2つ以上の独立したソースと相互検証されています (ソースURLは engine.js 内の各値に埋め込まれています)。

ほとんどのLLMメモリ計算機が間違っている理由

ほぼすべての「このLLMを実行できますか?」計算機は、教科書的な式でKVキャッシュを推定します:

KV ≈ 2 × num_layers × num_kv_heads × head_dim × context_length × bytes

これはすべての層が均一なヘッド形状でフルコンテキストのKVキャッシュを保持することを前提としています。Llama-1/2 には当てはまりますが、2025〜2026年のほとんどのモデルでは間違いです:

11倍の誤差は判定を覆します: 単純な計算機は Gemma 4 31B が64GBで長いコンテキストでは収まらないと言いますが、実際は余裕で収まります。

彼らが無視する5つのこと

1. スライディングウィンドウアテンション (Gemma 2/3/4、gpt-oss): ほとんどの層は最後のNトークンのみを保持するため、KVは成長しません。グローバル層のみがフルコンテキストに応じてスケールします。

2. ハイブリッド / 線形アテンション (Qwen 3.6 / 3.8、多くの2026年モデル): 線形アテンション層は固定サイズのリカレント状態を使用し、成長するKVキャッシュはありません。その状態も独自のコンポーネント (linearState) としてモデル化されます — シーケンスごとに定数なので、コンテキスト曲線を膨らませることはありません。

3. MLA — マルチヘッド潜在アテンション (GLM-5.2、GLM-4.7-Flash、DeepSeek ファミリー): キャッシュは全ヘッドで共有される単一の低ランク潜在変数 (kv_lora_rank + RoPE次元) です — ヘッドごとの「2 × heads × head_dim」式は桁違いに過大評価します。DeepSeek-V2 論文 (arXiv:2405.04434) と公式 DeepSeek-V3 推論コードで検証済み。

4. 異種ヘッド次元 + MoE: グローバル層は異なる head_dim を使用できます (Gemma 4: 512 vs 256)。MoE はトークンごとに少数のエキスパートのみをアクティブにしながら、すべてのエキスパートをメモリに保持します。

5. PLE — 層ごとの埋め込み (Gemma 4 e2b/e4b): llama.cpp は per_layer_token_embd テンソルを -ngl に関係なくデフォルトでシステムRAMに保持します (CUDAに強制するとK量子GGUFでクラッシュします。非K量子のみオプトイン可能 — ggml-org/llama.cpp#14430)。したがって、非PLE重みのみがVRAMを必要とします。5.1BパラメータすべてをGPUに対して数えると、e2bの常駐重みを約1.9倍過大評価し、小型カードの判定を覆します。Apple SiliconではシステムRAMがアクセラレータメモリであるため、総パラメータはそこで正しいままです。(注意: vLLM は PLE を完全にGPUにロードします — このエンジンのGPU計算は、量子階層の由来であるデフォルトのGGUF/llama.cpp動作に固定されています。常駐測定はEシリーズPLEスタックからのもので、Gemma 4 GGUFでの直接測定は issue #7 で歓迎します。)

このエンジンは各層タイプを個別にモデル化し、公式 HuggingFace config.json に対して検証されています。

Related MCP server: VisualAI MCP Server

計算内容

Total = Parameters (quantization-adjusted)
      + KV cache (per layer kind: sliding / global / linear / dense)
      + Runtime overhead (quant metadata + KV block padding + activations + fixed)
      + macOS base (Apple Silicon unified memory)

さらに、任意の HuggingFace 設定を上記のモデル形状に変換する parseHfConfig() も含まれます。(トークン/秒の予測は意図的に含めません — 速度はランタイム/バックエンドに依存し、静的モデルが正直に主張できるものではありません。適合性は検証可能な主張ですが、速度はそうではありません。)

使用方法

import { simulate, LOCAL_MODELS, parseHfConfig } from './engine.js';

const model = LOCAL_MODELS.find((m) => m.name === 'Gemma 4 31b');
const sim = simulate(model, /*ram*/ 64, /*ctx*/ 131072, /*bits*/ 8);
// → { used, free, verdict: 'yes'|'tight'|'no', param, kv, rt, os, maxContext, ... }

// any HuggingFace model:
const m = parseHfConfig('Qwen/Qwen3-32B', configJson, totalSizeBytes);

検証

• アーキテクチャ値は公式 HuggingFace config.json と照合済み。

• Gemma 4 31B のフルコンテキストKVは 20.78 GiB を再現し、公開されている アーキテクチャ分析 と一致します。手動で再現:

global: 10 layers × 2(K,V) × 4 heads × 512 dim × 2 B × 262,144 = 21,474,836,480 B
local:  50 layers × 2(K,V) × 16 heads × 256 dim × 2 B × 1,024  =    838,860,800 B
total = 22,313,697,280 B ÷ 1024³ = 20.78 GiB

• キャリブレーション: Qwen 3.6 35B-A3B @128K、8ビット ≈ 54 GB (実際のローカル実行と一致)。

• MLA のトークンあたりコスト: GLM-4.7-Flash = (512 + 64) × 2 B × 47 層 = 54,144 B/トークン — 適合性ベクターで固定。

すべての数値は推定値です — 実際の使用状況はランタイム (MLX/Ollama/llama.cpp)、OS状態、量子化スキームによって異なります。

適合性ベクター

vectors/fit-vectors-v1.json は、公式 config.json の値から手動で導出された16の言語中立テストベクター (正確なKVバイト数、トークンあたりコスト、適合判定) を固定しています — 例: 「Gemma 4 31B、262,144コンテキスト、bf16 = 正確に22,313,697,280バイト」。すべてのベクターが合格すれば、どの言語の実装も適合します — 私たちの実装は node vectors/run.mjs で実行できます。

これが重要な理由: 計算式は簡単にコピーできますが、検証済みの解答キーはそうではありません。このエンジンをPython、Rust、Goに移植しても、信頼できないフォークにはなりません — ベクターに合格すれば、同じ標準の適合実装です。エンジンを移植し、ベクターを維持してください。

Fit Census — すべてのモデル × すべてのデバイス、単一の真理値表

census/ には、このエンジンで計算された8,000以上の判定 (ドラフト層を含む24モデル × 88 GPU/Mac × 量子階層) がCSV/JSONで含まれており、インポート、チャート化、引用が可能です。さらに、スターターマトリックス (「デバイスごとに余裕で収まる最大モデル」) も含まれます。自分で再生成: npm run census。実世界の測定値は fixtures/ のPRを通じて予測値の隣に配置されます — 予測 vs 実測、公開で。

適合バッジを埋め込む

モデルが特定のハードウェアで実行できるかどうかを、エンジンからライブで、任意のREADMEやモデルカードに1行で表示:

![fits](https://img.shields.io/endpoint?url=https%3A%2F%2Ffitllm.run%2Fapi%2Fbadge%3Fmodel%3DGLM-4.7-Flash%26gpu%3D4090)

パラメータ: model (名前、あいまい)、gpu (名前、あいまい) または ram (GB、Appleユニファイドメモリ)、オプションで quant (GGUF階層 / 4|8|16)、ctx、kv。判定色: 緑 = 適合 · 黄 = ぎりぎり · 赤 = 不適合。

なぜ埋め込むのか? すべてのモデルカードやローカルAIチュートリアルの下で最も多い質問は「私のマシンで実行できますか?」です。バッジはエンジンからライブで回答します — データが更新されると再計算され、READMEに凍結された古い主張ではありません。モデルを公開したりガイドを書いたりする場合: 1行でFAQの段落全体を置き換え、「8GBカードでOOMした」という問題が報告される前に減らせます。

AIアシスタントに尋ねる (MCP)

エンジンは公開MCPサーバーとして https://fitllm.run/api/mcp で動作します — 一度接続すれば、アシスタントは「Xを私のYで実行できますか?」という質問に、古い学習データからの推測ではなく、このエンジンの計算で答えます (LLMはKVキャッシュ計算を頻繁に間違えます — 上の17.8倍の表を参照)。

• Claude (ウェブ / デスクトップ / モバイル): 設定 → コネクタ → カスタムコネクタを追加 → https://fitllm.run/api/mcp を貼り付け

• Claude Code: claude mcp add --transport http fitllm https://fitllm.run/api/mcp

• Cursor / Windsurf: mcp.json に追加 → { "mcpServers": { "fitllm": { "url": "https://fitllm.run/api/mcp" } } }

• ChatGPT: 設定 → アプリ → 詳細 → 開発者モード → MCPサーバーを追加 (Plus/Pro)

ツール: check_llm_fit (判定 + 完全なメモリ内訳 + 修正提案 — "RTX 5090 + RTX 3090" のようなマルチGPU構成に対応)、what_fits_on_hardware (あなたのマシン向けのランキングリスト)、list_supported。リソース: fitllm://models、fitllm://hardware、fitllm://census、fitllm://engine。意図的にオープン: 読み取り専用、ステートレス、認証なし、シークレットなし — すべての呼び出しは公開データの純粋な関数です。

掲載先: 公式MCPレジストリ (run.fitllm/fitllm) · Glama · mcp.so · Smithery

エージェントとスクリプト向け — プレーンHTTP API

MCPクライアントがない場合? 1回のGET、認証なし、キーなし — デフォルトでJSON、curl用にプレーンテキスト:

curl 'https://fitllm.run/api/check?model=gemma%204%2031b&gpu=4090'
# multi-GPU rigs: gpu=5090%2B3090 · Mac: ram=64 · usage: curl https://fitllm.run/api/check

オープンデータ: 完全なFit Census (8,000以上の判定、CC0) は fitllm.run/data と Hugging Face Datasets にあります。ブラウザでエンジンを試す: HF Spaceデモ。

原則

広告なし。ログイン不要。アフィリエイトリンクなし。出力は決して販売されません。 適合性は勝ち取れる、検証可能な主張です。生のトークン/秒はそうではありません — したがって、このエンジンは推測を精度として見せかけるのではなく、速度予測を拒否します。

キャリブレーションにご協力ください

モデルを実行して実際のピークメモリを測定しましたか? 測定値を報告 — 全員の推定値が改善されます。

製作者

yongha — GitHub。 fitllm.run を支えています。

ライセンス

MIT © click6067-ship-it