FitLLM

FitLLM Engine

FitLLM は、アーキテクチャを考慮したメモリ計算を使用して、ローカル LLM が GPU または Apple Silicon Mac に収まるかを確認する、オープンソースの依存関係ゼロのエンジンです。

公開中：https://fitllm.run · バイリンガル · 無料 · 広告なし · ログイン不要

オープンエンジン： fitllm-engine（MIT · npm fitllm-engine · npx fitllm）

依存関係はありません。読みやすいファイル 1 つ：engine.js。適合性ベクトルテスト済み。MIT。

インストール

# self-contained binary — no Node required
curl -fsSL https://fitllm.run/install.sh | sh

# Homebrew (tap) — the trust line is required for any third-party tap
brew tap click6067-ship-it/fitllm
brew trust click6067-ship-it/fitllm
brew install fitllm

# Windows (Scoop)
scoop install https://raw.githubusercontent.com/click6067-ship-it/fitllm-engine/master/packaging/fitllm.json

# already have Node? nothing to install
npx fitllm "Gemma 4 12b" --gpu "RTX 4090"

macOS（arm64/x64）、Linux（x64/arm64、glibc および musl）、Windows x64 向けのバイナリは、各ファイルの隣に .sha256 を付けて、すべてのリリースに添付されています。install.sh はチェックサムを検証し、一致しない場合は何もインストールしません。

埋もれさせず、率直に述べておきたいことが 2 つあります。各バイナリには JavaScript ランタイムが組み込まれているため、60～94 MB あります。これは同等の Rust や Go のツールよりはるかに大きく、エンジンを別の言語に移植しないための代償です。また、これは Homebrew の tap（click6067-ship-it/homebrew-fitllm）であり、homebrew-core ではありません。core が個人開発プロジェクトに求める基準は、225 stars／90 forks／90 watchers ですが、このプロジェクトはまだ満たしていません。

クイックスタート

npx fitllm "Gemma 4 12b" --gpu "RTX 4090"     # one line, exit 0 fits / 1 won't — run before you download
npx fitllm --top --gpu 4090                    # what can this hardware run?
npx fitllm --top --detect --json               # detect every supported local GPU; agent-ready JSON
npx fitllm Qwen/Qwen3-32B --detect --json      # public Hugging Face ID or URL; unsupported configs fail closed
npx fitllm "Gemma 4 12b" --detect --json --why # include architecture, evidence, assumptions, and exact memory inputs
npx fitllm scan                                # what you already downloaded — does it fit this machine?
npm install fitllm-engine                      # use the same engine as a library (see Usage)

fitllm scan — 手元にあるものから始める

モデル名を入力する代わりに、ディスク上にすでにあるモデルを読み取ります。

$ fitllm scan
Hardware: RTX 4090 (24GB) · quant Q4_K_M · ctx 8,192

ollama (3)
  ✓ FITS  qwen3:0.6b  →  Qwen3-0.6B
          1.2 GB used, 22.8 GB free  (on disk: 0.5 GB · Q4_K_M)
  ?       some-finetune:latest  —  not in the catalog, no verdict  (on disk: 6.7 GB · Q5_K_M)

Ollama はループバック API 経由で、LM Studio は lms ls --json 経由で読み取ります。どちらも読み取り専用です。ダウンロード、読み込み、設定の書き込みは行わず、情報が外部に送信されることもありません。ループバック以外の OLLAMA_HOST は問い合わせず、拒否します。

カタログにないモデルについては、推定値を表示しません。ランタイムが報告したサイズと量子化情報のみを表示します。似た名前のモデルから推測すると、別のモデルの数値を提示することになり、何も表示しないより悪いためです。

検証状況を率直に述べます。Ollama の経路は、CI で実際の Ollama インストールに対してエンドツーエンドでテストされています（verify-install-paths.yml）。LM Studio の経路はフィクスチャによるテストのみです。この README を書いた環境には LM Studio がないため、実際の CLI に対しては実行されていません。

リモート MCP サーバー

Streamable HTTP MCP クライアントを https://fitllm.run/api/mcp に接続します。

{
  "mcpServers": {
    "fitllm": {
      "url": "https://fitllm.run/api/mcp"
    }
  }
}

ツール

• check_llm_fit — 1 つのモデルが GPU、マルチ GPU 構成、または Mac に収まるかを確認し、判定、メモリ内訳、収まらない場合の対処法を返します。
• what_fits_on_hardware — 指定した GPU、マルチ GPU 構成、または Mac に収まる、対応済みローカルモデルを順位付けして表示します。
• list_supported — 適合チェッカーが受け付ける、組み込みのモデル名とハードウェア名を一覧表示します。

サーバーは読み取り専用で、ステートレスであり、認証は不要です。

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 --json          # detect hardware + what fits, for people or agents
npx fitllm "Gemma 4 12b" --detect         # one verdict on this machine

--detect はすべての nvidia-smi アダプターを読み取り、arm64 macOS では Apple Silicon のユニファイドメモリを使用し、Windows／WSL PowerShell 経由でカタログに完全一致する GPU 名を解決できます。Win32_VideoController.AdapterRAM、シリアル番号、PNP ID、環境変数の全一覧は使用しません。Intel のみ、判定が曖昧、または未対応のアダプターが見つかった場合は、近い GPU のメモリを流用せず、終了コード 2 で停止します。

CLI を使う理由は？ 「実行できるか？」という疑問は、ollama pull の直前にターミナルで生まれます。インストールもタブ切り替えも不要で、VRAM を自分で把握している必要もなく、--detect で 実際の ハードウェアを読み取ります。終了コード 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; }

ダウンロード経路にガードを組み込む

CLI の終了コードの仕様は、モデルランタイムと直接連携します。ダウンロードまたは起動は、判定が FITS または TIGHT の場合にのみ実行されます。無効な入力は終了コード 2 で停止します。

npx fitllm "Gemma 4 12b" --detect && ollama pull gemma4:12b
npx fitllm "Llama-3.1-8B-Instruct" --detect && llama-cli -m ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

CI では、リポジトリの複合 Action を使用します。シークレットは不要で、--json --why の結果全体が steps.preflight.outputs.result として返されます。

permissions:
  contents: read
steps:
  - name: Check model memory before download
    id: preflight
    uses: click6067-ship-it/[email protected]
    with:
      model: Gemma 4 12b
      gpu: RTX 4090
      ctx: '8192'

gpu または mac のいずれか一方だけを設定してください。この Action は CLI の仕様を維持します。終了コード 0 は適合／ぎりぎりで適合、1 は適合しない、2 はリクエストが無効であることを意味します。入力は環境変数を介して GitHub の式評価境界を越え、Bash の引数配列として Node に渡されます。

エージェントは、何もアップロードせずに型付きの測定値を収集できます。

npx fitllm measure "Qwen 3.6 27B" --detect --measured 15.3 --kind system_total_peak --unit GiB --runtime "llama.cpp b6400"

このコマンドは条件を検証し、候補の JSON オブジェクトと、入力済みの GitHub Issue URL を出力します。送信は引き続き人が行います。

Ollama を使っている場合、自分で測定する必要はありません。読み込み済みモデルの常駐サイズは、Ollama がすでに報告しています。

ollama run qwen3:0.6b        # in one shell
npx fitllm measure --from-ollama   # in another

これはループバック経由で GET /api/ps と GET /api/version を読み取ります。読み取り専用であり、読み込み、読み込み解除、プル、変更は一切行わず、何も送信しません。候補と Issue へのリンクが表示されるので、送信するかどうかは自分で判断できます。

検証する内容と、検証しない内容。 数値は idle_resident です。モデルを読み込み、アイドル状態にしたときの VRAM 内の重みと KV の常駐量を表します。生成中のピークメモリではないため、予測の一部を検証するものであり、すべてを検証するわけではありません。その点は候補にも明記されています。

判定を拒否する場合。 size_vram が size と異なる場合、またはゼロの場合、候補は生成されません。Ollama のドキュメントでは、これらのフィールドの値が異なる場合の意味は定義されておらず、部分的な常駐はこのエンジンでは意図的にモデル化していません。誰も解釈できない数値を示すくらいなら、数値を示さないほうがよいためです。カタログにないモデルもスキップされます。予測がないため、比較対象がありません。公開されている Hugging Face ID（org/model）は、制限付きの config／index リーダーで取得され、parseHfConfig() がアーキテクチャに対応している場合にのみ受け付けられます。

これは FitLLM のオープンな計算コアです。計算式を公開しているので、監査できます。

LLM に「Qwen 3.6 は自分の GPU で動きますか？」と尋ねると、学習データの期限時点で知っているアーキテクチャにパターンマッチし、たいていは 無理です と答えます。カタログベースの計算ツールは、新しいリリースへの対応が遅れます。CLI、API、MCP は、公式設定に固定した厳選カタログを使用します。Web 計算ツールでは、貼り付けられた Hugging Face ID の公式 config.json をリアルタイムで調べることもできるため、対応アーキテクチャなら、リリース初日から利用できます。単純な式では誤判定しやすいハイブリッド／スライディングウィンドウ／MoE 構造も対象です。

Apple Silicon のユニファイドメモリ（M1–M6、Pro／Max／Ultra — 最大 512GB の Mac Studio）、NVIDIA GPU（RTX 20／30／40／50、ワークステーション向け RTX 6000 Ada／RTX PRO Blackwell 2000–6000、データセンター向け A100／H100／H200／B200）、NVIDIA GB10 ユニファイドメモリシステム（DGX Spark 128GB、および同じ仕様の ASUS／Dell／HP／Lenovo／MSI／Acer／GIGABYTE 製システム — パートナー製品名は容量を含む正式名称でのみ解決されます。例：ASUS Ascent GX10 128GB。--count を使用した 2×／4× クラスターの接続に対応）、AMD Radeon（RX 7000／9000、PRO W7900）、**マルチ GPU プリセット（2×3090、2×4090、4×3090）**に対応しています。GGUF の Q ティア重み量子化と KV キャッシュ量子化は、別々に扱われます。ハードウェア項目には engine.js 内に値ごとの参照 URL が記載されています。新しい項目には、独立したソースが 2 件以上必要です（CONTRIBUTING）。

---

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

ほぼすべての「この LLM を実行できるか？」計算ツールは、教科書どおりの式で KV キャッシュを推定します。

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

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

モデル	単純な式で見落とされる点	単純計算の KV	FitLLM の KV	誤差
Gemma 4 31B @131K、8-bit	60 レイヤーのうち 50 レイヤーはスライディングウィンドウ方式（直近 1024 トークンのみ保持）で、10 のグローバルレイヤーは異なるヘッド形状（16 × 256 ではなく、KV ヘッド 4 個 × 512）を使用	~60 GB	~5.4 GB	11×
Qwen 3.6 27B @131K、8-bit	64 レイヤーのうち 48 レイヤーは線形アテンション（Gated DeltaNet）で、増加する KV キャッシュはありません	~16 GB	~4 GB	4×
Qwen 3.8 27B @256K、F16 KV	同じ構造で、最新世代です。KV を保持するのは 64 レイヤーのうち 16 レイヤーのみです	64.0 GiB	16.0 GiB	4×
GLM-4.7-Flash @128K、bf16	MLA：K/V は 1 つの共有潜在表現（512+64 次元）に圧縮され、ヘッドごとの K と V ではなく、一度だけキャッシュされます	~117 GB	~6.6 GB	17.8×
DeepSeek-V4.1-Flash-1017 @1M、bf16	圧縮スパースアテンション：40 レイヤーのうちキャッシュを保持するのは 4 レイヤーのみ（そのうち 3 レイヤーでは 2 トークンにつき 1 エントリー）。残りの 36 レイヤーは 128 トークンのウィンドウを保持して再利用します	80.0 GiB	3.6 GiB	22×
通常の密なモデル（Llama、Mistral など）	見落としなし — 標準的なトランスフォーマーです	同じ	同じ	1× ✅

11 倍の誤差で結論が逆転します。単純な計算ツールは、長いコンテキストでは Gemma 4 31B は 64 GB に収まらないと判断しますが、実際には十分に収まります。

見落とされている6つの点

1. スライディングウィンドウアテンション（Gemma 2/3/4、gpt-oss）：ほとんどのレイヤーは直近の N トークンのみを保持するため、KV キャッシュは増加し続けません。フルコンテキストに応じて拡大するのはグローバルレイヤーのみです。
2. ハイブリッド／線形アテンション（Qwen 3.6 / 3.8、2026年の多くのモデル）：線形アテンションレイヤーは、増加する KV キャッシュではなく、固定サイズの再帰状態を使用します。この状態も独立したコンポーネント（linearState）としてモデル化されています。シーケンスごとに一定なので、コンテキスト曲線を膨らませることはありません。
3. MLA — マルチヘッド潜在アテンション（GLM-5.2、GLM-5.3、GLM-4.7-Flash、DeepSeek-V2/V3 ファミリー）：キャッシュは、すべてのヘッドで共有される単一の低ランク潜在表現（kv_lora_rank + RoPE 次元）です。ヘッドごとの「2 × heads × head_dim」式では、1桁過大に見積もってしまいます。DeepSeek-V2 論文（arXiv:2405.04434）および公式 DeepSeek-V3 推論コードと照合済みです。
4. 異種ヘッド次元 + MoE：グローバルレイヤーでは、異なる head_dim を使用できます（Gemma 4：512 対 256）。MoE では、トークンごとに有効化されるエキスパートは少数でも、すべてのエキスパートがメモリに保持されます。
5. PLE — レイヤーごとの埋め込み（Gemma 4 e2b/e4b）：固定された llama.cpp/GGUF のパスでは、per_layer_token_embd 入力レイヤーのテンソルがアクセラレーターのメモリではなく、CPU／ホストバッファーに割り当てられます。そのため、検証済みの Gemma 4 e2b/e4b エントリーでは、PLE 以外の重みのみが VRAM の使用量に算入されます。5.1B パラメーターすべてを GPU 使用量に算入すると、e2b の常駐重みを約 1.9 倍過大に見積もり、小規模カードの判定が逆転します。この差し引きは条件付きであり、その配置のみに基づいています。テンソルに必要なホストメモリは GPU 判定の予算に含まれません。また、PLE テンソルをアクセラレーターに読み込むランタイム（たとえば vLLM）では、この推定は成り立たず、未検証のファミリーではすべての重みが常駐するものとして扱われます。Apple Silicon のユニファイドメモリでは、重み全体が算入されます。前提条件の詳細と、参照している固定ソースは構造上の前提条件に記載されています。Gemma 4 GGUF の直接測定結果があれば、issue #7 で歓迎します。
6. 圧縮スパースアテンション（DeepSeek-V4-Flash / V4-Pro、V4.1-Flash）：各レイヤーで共有される512次元の KV ヘッド1つ、全レイヤーでの128トークンのスライディングウィンドウ、圧縮キャッシュ（compress_ratio トークンごとに1エントリー）、さらに KV を圧縮するレイヤーにのみ置かれるインデクサーキーを使用します。V4.1 では、6つ以上のレイヤー間で1つのキャッシュを共有します（CSA2）。エンジンは、DeepSeek の参照推論コードが割り当てるキャッシュバッファーに加えて、上限のあるインデクサーのプリフィルワークスペースも計上します。V4.1 のトークンあたり1,600個のキャッシュ済み要素は、DeepSeek の技術レポートに記載された890バイト／トークンです（DeepSeek の FP4 形式を適用した場合）。公式のレイアウトと異なる構成は、フェイルクローズ方式で処理されます。

このエンジンはレイヤータイプごとに個別にモデル化しており、公式 HuggingFace の config.json ファイルと照合済みです。

計算内容

Total = Parameters (quantization-adjusted)
      + KV cache (per layer kind: sliding / global / linear / dense)
      + Runtime overhead (quant metadata + KV block padding + activations + fixed)
      + OS reserve (macOS base on Apple Silicon · DGX OS share on GB10 · driver/display reserve on discrete GPUs)

GGUF の重みが公開ファイルのサイズを下回ることはありません。 GGUF のティア（Q4_K_M … F16）は単一のビット幅ではなく、テンソルごとのレシピです。llama-quantize は一部のテンソルをより高い型のまま保持します（出力型のままの共有埋め込みや、行数が 256 の倍数でないため Q5_0/Q8_0 にフォールバックする行など）。また、公開元ごとに独自の上書き設定があります。ggml-org は Qwen3.5/3.6 ファミリーの attention テンソルと linear-attention テンソルを、Q4_K_M でも Q8_0 に保ちます。bartowski は attention の型を上げ、MTP レイヤーを同梱します。poolside は Laguna S Q4_K_M の 8 つの expert レイヤーを BF16 に保ちます。そのため、同じティア名でも公開元によって最大 15％の差が生じます（Qwen3.6-27B Q4_K_M：15.40 / 16.74 / 17.77 GiB）。unsloth、bartowski、ggml-org、lmstudio-community、mradermacher、またはモデルの公式組織による同名ファイルのうち最大のものがティア平均より 1％を超えて大きい場合、そのファイルサイズで重みを計上します（engine.js の各値の横にある ggufFileBytes、repository@revision）。それ以外の参照ファイルはすべて推定値の 1％以内です。2026 年 10 月の調査では、カタログ内の 22 モデル（61 のモデル・ティアの組み合わせ）で該当する行が見つかりました。たとえば、Nex-N2.5-Pro Q5_K_M は 263.5 → 284.6 GiB、Gemma 4 31B Q4_K_M は 17.49 → 18.25 GiB、Qwen3-0.6B は（ほとんどの GGUF で共有 lm_head が別個に格納されるため）+27～33％です。この下限が適用されるのは該当するティアのみで、Apple MLX のビット幅には適用されません。また、Gemma 4 PLE モデルの GPU 常駐部分にも適用されません（per_layer_token_embd テンソルはホスト側に残り、それ以外のテンソルはすべての参照ファイルで推定値を下回ります）。Hugging Face チェックポイントが行ごとの下限を引き継ぐのは、その行とテンソルリストが完全に一致する場合のみです。

ユニファイドメモリ（GB10 / DGX Spark）。 専用 VRAM はありません。DGX OS、CPU プロセス、GPU が 128 GB の LPDDR5x プールを共有するため、Mac の場合と同様、ディスクリートカード用の環境プリセットを使わず、OS とランタイムが共有するメモリを同じプールから差し引きます。予約分は、出典またはラベルのある 3 つの部分からなります。OS が認識できないメモリ（128 − 121.69 GiB の MemTotal。これは DGX OS 7.6 の CUDA total と一致します）、アイドル状態の DGX OS が使用する約 5 GiB（MemTotal − MemAvailable）、Apple の場合と同じランタイム用の 2 GiB（GB10 の実測値ではなく、エンジンによる推定値）で、合計 13.31 GiB です。共有プールには Mac と同様の 20％のヘッドルームを設けます。1 台では、GGUF の重みをファイルサイズで計上します。2.21.4 以降、ディスクリート GPU と Mac の場合に加算される 12％の重みオーバーヘッドは適用しません。公開されている GB10 の割り当てログにそのような割合は見られないためです（公開ログにおける GB10 クラスの計算値と実測値）。Gemma 4 PLE はここでは一切差し引きません（ホストバッファーも同じプールを使用します）。また、GB10 システムを他の GPU と組み合わせてプールすることはできません（安全側に倒して失敗させます）。各値の出典 URL は engine.js にあります。

GB10 クラスター（2× / 4× DGX Spark）。 複数の同一 GB10 ユニットを 1 つのモデル用に合算できるのは、ConnectX-7 経由で分散ランタイムがモデルをユニット間に分割する場合のみです。NVIDIA は、vLLM と Ray、TensorRT-LLM とユニット数に等しい tensor parallel を使用する構成を、2 台では QSFP ケーブルで直接接続し、4 台では RoCE スイッチを介して接続する方法で説明しています（2026 年 4 月時点の DGX OS）。npx fitllm <model> --gpu "DGX Spark 128GB" --count 2（または --gpu "2× DGX Spark 128GB"）では、各ユニット固有の予約分とアクティベーションバッファーを計上します。また、モデルの KV ヘッド数がユニット数より少ない場合、MLA latent cache を使用する場合、または DeepSeek の compressed cache を使用する場合は、KV キャッシュを複製されるものとして計上します（vLLM / TensorRT-LLM の tensor-parallel の動作。レイヤー分割なら必要量は減ります）。3 台（リング構成）、4 台を超える構成、または他の GPU との混在では、安全側に倒して失敗させます。NVIDIA の「2 台で最大 405B」は重みのみの FP4 の数値です。この計算ツールは、指定されたコンテキスト長での結果を返します。

さらに、検証済みかつモデル化済みの Hugging Face アーキテクチャファミリーの設定を、上記のモデル形状に変換する parseHfConfig() もあります。未対応の構造では推測値を返さず、安全側に倒して失敗します。（トークン/秒の予測はありません。静的モデルでは正直に断言できないほど、速度はランタイムやバックエンドに左右されるためです。適合性は検証可能な主張ですが、速度はそうではありません。）

構造上の前提

一部の判定は、アーティファクトまたはランタイムの経路に関する構造上の前提が成り立つ場合にのみ有効です。エンジンは、計算で使用する正規化済みモデルフィールドから有効な前提を導き出し、該当する結果に { id, statement } の配列である structuralAssumptions として付与します。通常の GQA モデルなど、影響を受けない結果にはこのキーが付かないため、従来の JSON 形式は変わりません。CLI はテキストモードでは有効な前提をそれぞれ premise [id]: の行として出力し、--json では配列を含めます（--top --json では各行にも含めます）。--why と複合 Action も同じ配列を引き継ぎます。ランタイムセレクターも、信頼度スコアも、速度に関する主張もありません。前提が示すのはメモリ計算の前提条件であり、モデルの実行速度ではありません。

• mla-compressed-latent-cache — KV メモリは、圧縮潜在表現を使う MLA アーティファクトまたはモードを前提としています。従来型の非 MLA GGUF、または明示的に非圧縮のモードでは、この推定は無効になります。出典：DeepSeek-V3 inference model.py · llama.cpp convert_hf_to_gguf.py · llama.cpp llama-kv-cache.cpp。
• ple-llamacpp-non-gpu-residency — GPU の重みメモリから、検証済みの Gemma 4 PLE テンソルが除外されているのは、固定された llama.cpp/GGUF の経路で、per_layer_token_embd 入力層テンソルがアクセラレーターのメモリではなく CPU／ホストバッファーに割り当てられるためです。ここではそのホストメモリを予算に含めておらず、PLE をアクセラレーターに読み込むランタイムではこの推定は無効になります。出典：Gemma 4 E2B config.json（テキスト本体の model_type は正確に gemma4_text）· 固定バージョンの llama.cpp 8b4b3558f1459c13e4aa38d5c94d306a00dc6acd：入力層のデバイス割り当て · PER_LAYER_TOKEN_EMBD を入力層テンソルとして扱う実装 · Gemma 4 の構築 · ローダーヘッダー · ローダーの実装。この推論が適用されるのは、カタログ項目 Gemma 4 e2b と Gemma 4 e4b（pleOffloadVerified: true）に限られます。また、解析済み設定のテキスト本体が正確に gemma4_text であり、かつプロファイル全体（レイヤー数、hidden_size、intermediate_size、両方の PLE 次元）が、チェックポイントと設定自身の密な本体が整合する固定版の公式 E2B／E4B 設定と一致する場合に限られます。他のファミリーに見た目が似たフィールドがある場合、次元またはレイヤー数が変更されている場合、あるいはチェックポイントに不整合がある場合は、重み全体が GPU 上に常駐するため、未検証の設定によって「収まる」という判定に変わることはありません。
• native-fp4-expert-weights — リリース時に専門家重みを FP4 で提供するモデル（gpt-oss-20b / 120b は MXFP4、DeepSeek-V4-Flash / V4-Pro / V4.1-Flash-1017）に付与されます。値は 4 ビット E2M1 で、32 個の値ごとに E8M0 スケールが 1 つ付くため、4.25 ビットです。重み精度が 4.25 ビットを超える場合、これらのテンソルは配布時のサイズで計上し、選択した精度ティアに応じて変わるのはその他の重みのみです。これは、GGUF にネイティブの MXFP4 型があり、公開 GGUF ではどのティアでもこれらの重みがそのまま保持されるためです。モデルの公開 GGUF ファイルが判明している場合（gpt-oss）、重みは選択したティアの最大ファイルサイズを下回らないように計上されます。gpt-oss-120b Q4_K_M は 58.53 GiB、Q8_0 は 59.03 GiB、F16 は 60.88 GiB です。これに対し、リリース版は 60.77 GiB です（ティアの平均は 66.55 / 115.59 / 217.56 GiB）。F16 ファイルがリリース版を 0.18% 上回るのは、GGUF でバイアスとノルムが F32 で保存されるためです。同じティアの公開ファイルが判明していない場合（DeepSeek-V4、およびカタログ項目とテンソル単位で一致しない Hugging Face チェックポイント）、重みはリリース済みチェックポイント自体（および F16 の場合は F32 コピー分として 0.25%）を下回らないように計上されます。専門家重みを 8 ビットまたは 16 ビットに再展開するビルド（MLX の 8 ビットビルドは 115.6 GiB）は、精度を高めずにサイズだけが大きくなるため、この計算には含まれません。4.25 ビット未満（Mac 4-bit）では、専門家重みも選択した精度に従います。FP8（E4M3）の重みはこの分類に含まれません。GGUF には FP8 型がないため、Q8_0 と BF16 の GGUF では再エンコードされ、各ティアのサイズは公開ファイルとすでに一致しています（GLM-5.3 Q8_0 は 746.3 GiB、BF16 は 1,404.4 GiB、FP8 リリース版は 703.7 GiB）。出典：ggml GGML_TYPE_MXFP4 · 量子化済みテンソルをそのまま保持する llama-quantize · unsloth/gpt-oss-120b-GGUF のファイルサイズ · ggml-org/gpt-oss-120b-GGUF · bartowski/openai_gpt-oss-120b-GGUF · openai/gpt-oss-120b リリース版 · unsloth/DeepSeek-V4-Flash-GGUF · unsloth/GLM-5.3-GGUF。
• deepseek-compressed-sparse-kv — KV メモリは、DeepSeek のリファレンス推論コードのキャッシュバッファーに従います。すべてのレイヤーでスライディングウィンドウキャッシュを使い、自身の KV を圧縮するレイヤーに限り、圧縮キャッシュとインデクサーキーを使用します。選択した KV 精度（16 ビットの場合、リファレンスコードの bf16 バッファー）で計上し、圧縮器の fp32 状態、V4.1 の Engram トークン履歴、512 MiB のインデクサー事前入力ワークスペース（vLLM の既定値 VLLM_SPARSE_INDEXER_MAX_LOGITS_MB）を含めます。リンクされた各 GB10 ユニットで全量を計上します。リファレンスの generate.py のようにプロンプト全体を事前入力する場合（インデクサーのスコアテンソルはプロンプト × コンテキストに応じて増大します）、また、非圧縮 KV をキャッシュするランタイムでは、より多くのメモリが必要ですが、ここではモデル化していません。V4.1 の 196.6B Engram テーブルは、重みの量子化方式にかかわらず、FP8 ストレージ（スケール込みで 8.25 ビット）を下回らないように計上します。ビジョンタワーと MTP／DSpark のドラフト重みは、常駐重みとして計上します。出典：DeepSeek-V4-Flash inference model.py · DeepSeek-V4.1-Flash-1017 inference model.py · engram.py · DeepSeek-V4.1-Flash 技術レポート（グローバル KV はトークンあたり 890 bytes） · vLLM DeepSeek V4 ブログ（V4-Pro の 1M コンテキストで bf16 KV は 9.62 GiB） · vLLM envs.py（インデクサーのロジット予算） · vLLM のインデクサー事前入力のチャンク化。
• mtp-ordinary-generation — KV メモリは、通常の非投機的生成を前提としています。MTP のドラフトコンテキストは含まれません。出典：llama.cpp llama-hparams.cpp · llama.cpp llama-model.cpp · llama.cpp convert_hf_to_gguf.py · vLLM qwen3_next_mtp.py。
• gb10-cluster-tensor-parallel — 2×／4× GB10 の判定に付与されます。複数ユニットにまたがって 1 つのモデルを分割するランタイム（Ray を使った vLLM または TensorRT-LLM、テンソル並列数 = ユニット数）でのみ、ユニットのメモリを合算できます。Ollama と LM Studio は 1 ユニットを使用します。ユニットごとの予約領域、アクティベーションバッファー、テンソル並列時の KV 複製は計上しますが、ネットワーク／NCCL バッファーと不均等な分割は計上しません。出典：NVIDIA DGX Spark クラスタリング · NVIDIA：最大 4 ノード（2026-03-16） · NVIDIA vLLM プレイブック · vLLM のデコード時コンテキスト並列処理 — MLA KV は TP ランクごとに複製 · TensorRT-LLM の並列化戦略 · ServeTheHome の GB10 クラスタ。
• gb10-cluster-tensor-parallel-incompatible — モデルのアテンション、KV、または線形アテンションのヘッド数がユニット間で割り切れない場合に付与されます（vLLM／TensorRT-LLM はそのテンソル並列サイズを拒否します）。判定は no となり、クラスタで動作するとは主張しません。出典：vLLM llama.py のヘッド数の割り切れに関するアサーション。
• gb10-unified-memory-reserve — すべての GB10（DGX Spark クラス）の判定に付与されます。予約領域では、DGX OS から認識できないメモリ、アイドル時の DGX OS 使用量、2 GiB のランタイム用余裕分を差し引きます。1 ユニットの場合、GGUF の重みはファイルサイズのまま計上し、追加の割合は加えません。さらに、KV キャッシュの 15% と、コンテキスト長に応じたアクティベーションの余裕分を計上します。この値は、フラッシュアテンションを有効にした llama.cpp／Ollama の実行で調整しています（どちらも既定で --flash-attn auto を使用：llama.cpp common.h · Ollama llama_server.go）。フラッシュアテンションを無効にした場合（その場合、llama.cpp はアテンションスコア全体を保持します）や vLLM（CUDA グラフ、事前割り当てされた KV プール）では、より多くのメモリが必要になりますが、予算には含めていません。他の実行中アプリケーション、ファイルページキャッシュ、llama-server のホスト側プロンプトキャッシュ（--cache-ram、既定で 8 GiB）、コンテキストチェックポイントも予算に含めていません。また、重みは一度だけ常駐すると仮定しています（読み込み時に mmap のページキャッシュコピーを保持するローダーでは、重みサイズ分のメモリがさらに必要になることがあります）。出典：NVIDIA DGX Spark 移植ガイド — 固定の GPU 割り当てなし · NVIDIA DGX Spark 既知の問題 — nvidia-smi のメモリが「Not Supported」と表示される問題、ページキャッシュのフラッシュ · MemTotal／CUDA 合計の測定：bloomery #13 · NVIDIA 開発者フォーラム · Back2Gaming · アイドル時の使用量：AAIF · Techno Tim。 常駐範囲。 SSD/NVMe ストリーミング、エキスパートのページング、スワップ、一般的な CPU/RAM オフロードは、通常の FitLLM の適合判定の対象外です。開示されている構造上の例外は、ストレージのページングではなく配置に関する事実です。検証済みの Gemma 4 e2b/e4b エントリーでは、固定された llama.cpp/GGUF の経路により、この入力層テンソルはアクセラレーターのメモリではなく CPU/ホストバッファーに決定論的に割り当てられるため、ディスクリート GPU の判定では層ごとの埋め込み（PLE）テンソルを除外します（前提 ple-llamacpp-non-gpu-residency は判定とともに表示されます）。このホスト/システムメモリはディスクリート GPU の判定では予算に含まれません。PLE をアクセラレーターに読み込むランタイムでは PLE の推定値が無効になります。また、Apple のユニファイドメモリ、および GB10（DGX Spark）のユニファイドメモリでは、重み全体を引き続き計上します。

npx fitllm "GLM-4.7-Flash" --gpu "RTX 4090"          # text adds:  premise [mla-compressed-latent-cache]: KV memory assumes …
npx fitllm "GLM-4.7-Flash" --gpu "RTX 4090" --json   # adds "structuralAssumptions": [{ "id": "…", "statement": "…" }]
npx fitllm "Llama-3.1-8B-Instruct" --gpu "RTX 4090" --json   # plain GQA: no structuralAssumptions key at all

使用方法

// from npm:  npm install fitllm-engine
import { simulate, structuralAssumptions, LOCAL_MODELS, GPUS, gpuDevice, parseHfConfig } from 'fitllm-engine';
// …or vendored single-file:
// import { simulate, structuralAssumptions, LOCAL_MODELS, GPUS, gpuDevice, 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, ... }

// affected results carry the active structural premises; plain GQA results have no such key:
const gpu = gpuDevice(GPUS.find((g) => g.name === 'RTX 4090'));
const mla = simulate(LOCAL_MODELS.find((m) => m.name === 'GLM-4.7-Flash'), gpu, 8192, { weightBpw: 4.8944, kvBits: 16 });
mla.structuralAssumptions; // → [{ id: 'mla-compressed-latent-cache', statement: '…' }]
structuralAssumptions(model, gpu); // → [] for an unaffected model (pure; same inputs as the calculation)

// a config from a modeled Hugging Face architecture family:
const m = parseHfConfig('Qwen/Qwen3-32B', configJson, totalSizeBytes);

検証

リポジトリーのチェックアウトから、npm run benchmark:accuracy（または -- --json を追加）を実行して、型付きの実測値と予測値の台帳を再計算します。固定された推定器の差分検証は npm run benchmark:differential で実行します。別途ダウンロードした公式 llmfit リリース成果物から、切り詰めていないソース出力を再取得するには、次を実行します。

npm run benchmark:capture:llmfit -- --binary /path/to/llmfit --artifact /path/to/llmfit-v1.1.12-x86_64-unknown-linux-gnu.tar.gz

差分検証には architecture_differential_not_runtime_accuracy というラベルが付いています。これは推定器が GQA、スライディングウィンドウアテンション、MLA をどのように扱うかを示すものであり、ランタイムの計測結果を示す証拠ではありません。方法論、競合製品の入力形式、チェックサム、事前に定めた中止条件については、benchmarks/README.md を参照してください。現在の証拠では、比較精度の主張に必要な基準を満たしていません。

• アーキテクチャの値は、公式の 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

• MLA のトークンあたりのコスト：GLM-4.7-Flash = (512 + 64) × 2 B × 47 層 = 54,144 B/token — 適合性ベクトルで固定されています。

GB10（DGX Spark クラス）：公開ログにおける計算値と実測値

確認日：2026-10-20。ログ値は、実行時の下限値（allocation_floor）で、各行ごとに算出しています。Qwen の行では、モデル読み込み時にランタイムが列挙したバッファーの合計（重み、KV キャッシュ、再帰状態、計算用、出力用）です。同じログに記載されたビジョンエンコーダーの CPU 計算バッファー 248 MiB、エンコーダー自体の重み、CUDA コンテキスト、および使用に応じて増加するキャッシュは含まれていません。Gemma の行では、プロセスごとの nvidia-smi の値で、CUDA コンテキストは含みますが、ホストメモリは含みません。計算値は、重み + KV キャッシュ + 再帰状態 + ランタイムバッファーで、13.3 GiB の GB10 予約分（OS から認識できない 6.3 GiB、アイドル時の DGX OS が約 5 GiB、ランタイムの割り当て 2 GiB）を除外しています。生ログのハッシュと検証内容を含む各データは fixtures/measured.json にあり、test/gb10-measured.test.mjs では、計算値がすべての下限値を上回ること、および重みがログのモデルバッファーの値から 3% 以内であることを検証しています。

実測環境 · 日付 · 出典	モデル · ランタイム · 設定	ログ値（下限）	2.21.3（予約分を除く）	2.21.4（予約分を除く）
ASUS Ascent GX10 · 2026-06-07 · ollama#16610（ログ添付）	Qwen3.6-35B-A3B BF16 GGUF · Ollama 経由の llama-server 0.30.6 · ctx 65,536 · KV q8_0 · flash-attn	66.84 GiB	75.76（+13.4%）	67.94（+1.6%）
同じマシンとログ	同上 · ctx 102,400	67.42 GiB	77.27（+14.6%）	69.45（+3.0%）
同じマシン、Ollama 0.24.0 のログ ¹	Qwen3.6-35B-A3B Q8_0 · Ollama 独自エンジン · ctx 102,400 · KV q8_0	40.3 GiB	43.05（+6.8%）	38.89（−3.5%）
DGX Spark · 2026-04-09 · NVIDIA フォーラム 366162	Gemma 4 31B F16 GGUF · llama-server（ソースビルド） · ctx 65,536 · KV q8_0 · flash-attn	62.60 GiB（nvidia-smi）	69.34（+10.8%）	62.48（−0.2%）

**2.21.3 の誤差の原因：**重みの 12% をランタイムのオーバーヘッドとして加算していました。35B BF16 ファイルでは 7.8 GiB です。ログでは、GGUF はファイルサイズのまま読み込まれ（66,221.98 + 970.00 MiB = 65.62 GiB）、計算バッファーは llama.cpp で 0.5～0.7 GiB、Ollama 独自エンジンで 1.7 GiB と示されています。2.21.4 では、1 台の GB10 においてこの 12% を削除しています。KV の 15% のパディングと、コンテキストサイズに応じたアクティベーションの割り当ては維持しています。予約分に含まれる 2 GiB のランタイム割り当てを加えると、2.21.4 はすべての行で 1.5～6.0% 上回ります。これは下限値に含まれないメモリ分の余裕であり、それだけで誤りを意味するものではありません。

**制限事項：**2 台のマシンでの 4 回の実行で、すべて flash attention が有効です（llama.cpp と Ollama のデフォルトである --flash-attn auto）。無効にすると、llama.cpp はアテンションスコア全体を保持します。バッチサイズ 512 の 262K トークンでは、48 ヘッドのモデルで約 24 GiB となり、バッチサイズに応じて増加します。いずれのバージョンもこの分を見積もっていません。また、1 台での vLLM（CUDA グラフ、事前割り当て済み KV プール）も対象外です。使用に応じて増加するホストメモリも、どの行にも含まれていません。これには llama-server のプロンプトキャッシュ（デフォルトで最大 8 GiB）と、最大 32 個のコンテキストチェックポイントが含まれます。¹ Ollama 0.24.0 の KV キャッシュは、手計算の 2.5 倍と報告されていますが、ログに説明がありません。そのため、この行は下限値の確認のみを目的としています（community_unverified）。ディスクリート GPU、GB10 クラスター、Mac では 12% を維持しています。いずれも同等のランタイム割り当て確認がまだありません（台帳の Mac の項目は、アイドル時の常駐重みの測定値です）。同じ表は fitllm.run/data にもあります。

すべての数値は推定値です。実際の使用量はランタイム（MLX/Ollama/llama.cpp）、OS の状態、量子化方式によって異なります。

適合性ベクトル

vectors/fit-vectors-v1.json には、公式の config.json の値から手作業で導出した、言語に依存しない49個のテストベクトル（正確なKVバイト数、トークンごとのコスト、適合判定）が固定されています。たとえば、*「コンテキスト長262,144、bf16のGemma 4 31Bは、正確に22,313,697,280バイト」*です。すべてのベクトルに合格すれば、どの言語で実装しても適合します。node vectors/run.mjs でこの実装を実行できます。

これが重要な理由： 数式をコピーするのは簡単ですが、検証済みの正解集を用意するのは簡単ではありません。このエンジンをPython、Rust、Goに移植しても、信頼できないフォークになるわけではありません。ベクトルに合格すれば、同じ標準に準拠した実装となります。エンジンを移植し、ベクトルはそのまま使いましょう。

Fit Census — すべてのモデル × すべてのデバイスを網羅する、唯一の真理値表

census/ には、このエンジンで計算した13,804件の判定（ドラフト段階を含む34モデル × 104種類のGPU／Mac × 量子化レベル）が収録されています。CSV／JSON形式でインポート、グラフ化、引用できるほか、スターターマトリクス（デバイスごとに余裕をもって動作する最大のモデル）も含まれています。npm run census を実行すれば、自分で再生成できます。実環境での測定値は、fixtures/ のPRを通じて予測値と並べて掲載されます。予測値と測定値を公開しています。

適合バッジを埋め込む

特定のハードウェアでモデルが動作するかどうかを表示します。エンジンからリアルタイムで取得でき、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（GPU名、曖昧検索）または ram（GB単位、Appleのユニファイドメモリ）、任意の quant（GGUFの量子化レベル／4|8|16）、ctx、kv。判定の色：緑＝適合 · 黄＝余裕が少ない · 赤＝適合しない。

埋め込む理由： すべてのモデルカードやローカルAIチュートリアルで最もよく寄せられる質問は、*「自分のマシンで動きますか？」*です。このバッジはエンジンからリアルタイムで回答します。データが更新されると再計算されるため、READMEに古い主張が固定されることはありません。モデルを公開したりガイドを書いたりする場合、1行追加するだけでFAQの段落全体を置き換えられ、「8GBのカードでOOMになった」という問題が報告される前に防げます。

AI アシスタントに質問する（MCP）

このエンジンは、https://fitllm.run/api/mcp でパブリックなMCP サーバーとして稼働しています。一度接続すれば、アシスタントは古い学習データをもとに推測するのではなく、このエンジンの計算を使って、*「YでXを実行できますか？」*に回答します（LLMはKVキャッシュの計算を頻繁に間違えます。上記の17.8倍の表をご覧ください）。

• Claude（ウェブ／デスクトップ／モバイル）：Settings → Connectors → Add custom connector → 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：Settings → Apps → Advanced → Developer mode → 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 クライアントがなくても、GETリクエスト1回で利用できます。認証もキーも不要です。デフォルトでは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（13,804件の判定、CC0）は、fitllm.run/data と Hugging Face Datasets で公開されています。ブラウザーでエンジンをお試しください：HF Spaceデモ。

原則

広告なし。ログイン不要。アフィリエイトリンクなし。出力を販売することはありません。 適合性は検証可能で、実現できる主張ですが、実測値である tok/s はそうではありません。そのため、このエンジンは推測を精密な予測のように見せるのではなく、速度予測を行いません。

精度向上にご協力ください

モデルを実行して実際のピークメモリを測定しましたか？ 測定結果を報告する — 皆さんの推定精度向上につながります。

開発者

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

ライセンス

MIT © click6067-ship-it