FitLLM Engine

Live: https://fitllm.run · Zweisprachig · Kostenlos · Keine Werbung · Kein Login

Offene Engine: fitllm-engine (MIT · npm fitllm-engine · npx fitllm)

Null Abhängigkeiten. Eine lesbare Datei: engine.js. Konformitäts-Vektor-getestet. 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

Warum ein CLI? Die Frage „Läuft es?“ entsteht im Terminal – eine Zeile vor ollama pull. Keine Installation, kein Tab-Wechsel, und es liest deine tatsächliche Hardware mit --detect, statt dich zu bitten, deinen VRAM zu kennen. Exit-Code 0/1 macht es zu einem Vorab-Download-Schutz:

# 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; }

Dies ist der offene Berechnungskern von FitLLM. Die Mathematik ist offen, damit du sie prüfen kannst.

Frag ein LLM „Passt Qwen 3.6 auf meine GPU?“ und es matcht auf eine Architektur aus seinem Trainingsstand – und sagt normalerweise nein. Katalogbasierte Rechner hinken neuen Veröffentlichungen hinterher. FitLLM liest das offizielle config.json jedes Modells live, daher ist es bei Day-one-Releases und bei den Hybrid-/Sliding-Window-/MoE-Architekturen richtig, die naive Formeln falsch berechnen.

Abgedeckt werden Apple Silicon Unified Memory (M1–M5, Pro/Max/Ultra – bis zum 512GB Mac Studio), NVIDIA GPUs (RTX 20/30/40/50, Workstation RTX 6000 Ada / RTX PRO 6000, Rechenzentrum A100/H100/H200/B200), AMD Radeon (RX 7000/9000, PRO W7900) und Multi-GPU-Voreinstellungen (2×3090, 2×4090, 4×3090) – wobei die GGUF-Q-Stufen-Gewichtsquantisierung getrennt von der KV-Cache-Quantisierung gehalten wird. Jede Hardware-Zahl ist gegen ≥2 unabhängige Quellen kreuzverifiziert (Quell-URLs pro Wert in engine.js eingebettet).

Warum die meisten LLM-Speicherrechner falsch liegen

Fast jeder Rechner für „Kann ich dieses LLM ausführen?“ schätzt den KV-Cache mit der Lehrbuchformel:

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

Das setzt voraus, dass jede Schicht einen Full-Context-KV-Cache mit einer einheitlichen Head-Form behält. Gültig für Llama-1/2 – falsch für die meisten Modelle von 2025–2026:

Ein 11×-Fehler kippt das Urteil: Ein naiver Rechner sagt, Gemma 4 31B passt nicht in 64 GB bei langem Kontext, obwohl es bequem passt.

Die fünf Dinge, die sie ignorieren

1. Sliding-Window-Aufmerksamkeit (Gemma 2/3/4, gpt-oss): Die meisten Schichten behalten nur die letzten N Token, daher hört ihr KV auf zu wachsen. Nur die globalen Schichten skalieren mit dem vollen Kontext.

2. Hybride / lineare Aufmerksamkeit (Qwen 3.6 / 3.8, viele Modelle von 2026): Lineare-Aufmerksamkeits-Schichten verwenden einen rekurrenten Zustand fester Größe, keinen wachsenden KV-Cache. Dieser Zustand wird ebenfalls als eigene Komponente modelliert (linearState) – er ist pro Sequenz konstant, bläht also die Kontextkurve nie auf.

3. MLA – Multi-head Latent Attention (GLM-5.2, GLM-4.7-Flash, DeepSeek-Familie): Der Cache ist ein einzelnes Low-Rank-Latent (kv_lora_rank + RoPE-Dimensionen), das über alle Heads geteilt wird – Pro-Head-Formeln wie „2 × Heads × head_dim“ überschätzen um eine Größenordnung. Verifiziert gegen das DeepSeek-V2-Papier (arXiv:2405.04434) und den offiziellen DeepSeek-V3-Inferenzcode.

4. Heterogene Head-Dimensionen + MoE: Globale Schichten können ein anderes head_dim verwenden (Gemma 4: 512 vs. 256). MoE hält jeden Experten im Speicher, aktiviert aber nur wenige pro Token.

5. PLE – Per-Layer Embeddings (Gemma 4 e2b/e4b): llama.cpp hält den per_layer_token_embd-Tensor standardmäßig im System-RAM, unabhängig von -ngl (das Erzwingen auf CUDA führt bei K-Quant-GGUFs zu Abstürzen; nur Nicht-K-Quants können sich anmelden – ggml-org/llama.cpp#14430), daher benötigen nur die Nicht-PLE-Gewichte VRAM. Wenn man alle 5,1B Parameter gegen eine GPU zählt, überschätzt man die residenten Gewichte von e2b um ~1,9× und kippt Urteile für kleine Karten. Auf Apple Silicon ist System-RAM ist Beschleuniger-Speicher, daher bleiben die Gesamtparameter dort korrekt. (Einschränkungen: vLLM lädt PLE vollständig auf die GPU – die GPU-Mathematik dieser Engine ist am Standardverhalten von GGUF/llama.cpp verankert, aus dem ihre Quantisierungsstufen stammen; die Residenzmessungen stammen vom E-Series-PLE-Stack, und eine direkte Messung an einem Gemma-4-GGUF ist in Issue #7 willkommen.)

Diese Engine modelliert jeden Schichttyp separat, verifiziert gegen offizielle HuggingFace-config.json-Dateien.

Related MCP server: VisualAI MCP Server

Was sie berechnet

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)

Plus eine parseHfConfig()-Funktion, die jede HuggingFace-Konfiguration in die obige Modellform umwandelt. (Keine Token/s-Vorhersage – bewusst: Geschwindigkeit hängt von Laufzeit/Backend ab, was ein statisches Modell nicht ehrlich behaupten kann. Fit ist eine verifizierbare Behauptung; Geschwindigkeit nicht.)

Verwendung

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);

Verifizierung

• Architekturwerte gegen offizielle HuggingFace-config.json geprüft.

• Gemma 4 31B Full-Context-KV reproduziert 20,78 GiB, was der veröffentlichten Architekturanalyse entspricht. Reproduziere es von Hand:

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

• Kalibrierung: Qwen 3.6 35B-A3B @128K, 8-bit ≈ 54 GB (entspricht echten lokalen Läufen).

• MLA-Kosten pro Token: GLM-4.7-Flash = (512 + 64) × 2 B × 47 Schichten = 54.144 B/Token – durch Konformitätsvektoren festgelegt.

Alle Zahlen sind Schätzungen – der tatsächliche Verbrauch variiert mit der Laufzeit (MLX/Ollama/llama.cpp), dem Betriebssystemzustand und dem Quantisierungsschema.

Konformitätsvektoren

vectors/fit-vectors-v1.json fixiert 16 sprachneutrale Testvektoren (exakte KV-Bytes, Kosten pro Token, Fit-Urteile), die von Hand aus offiziellen config.json-Werten abgeleitet wurden – z. B. „Gemma 4 31B bei 262.144 Kontext, bf16 = exakt 22.313.697.280 Bytes“. Jede Implementierung in jeder Sprache ist konform, wenn jeder Vektor besteht – führe unsere mit node vectors/run.mjs aus.

Warum das wichtig ist: Die Formeln sind leicht zu kopieren; ein verifizierter Lösungsschlüssel nicht. Wenn du diese Engine nach Python, Rust oder Go portierst, wirst du kein unzuverlässiger Fork – bestehe die Vektoren und du bist eine konforme Implementierung desselben Standards. Portiere die Engine, behalte die Vektoren.

Der Fit-Zensus – jedes Modell × jedes Gerät, eine Wahrheitstabelle

census/ enthält über 8.000 Urteile (24 Modelle inkl. Draft-Stufe × 88 GPUs/Macs × Quantisierungsstufen), berechnet von dieser Engine – als CSV/JSON, das du importieren, diagrammen oder zitieren kannst, plus eine Startmatrix („größtes Modell, das pro Gerät bequem passt“). Generiere es selbst: npm run census. Messungen aus der realen Welt landen neben Vorhersagen über fixtures/-PRs – vorhergesagt vs. gemessen, öffentlich.

Ein Fit-Badge einbetten

Zeige, ob ein Modell auf gegebener Hardware läuft – live von der Engine, eine Zeile in jeder README oder Modellkarte:

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

Parameter: model (Name, unscharf), gpu (Name, unscharf) oder ram (GB, Apple Unified Memory), optional quant (GGUF-Stufe / 4|8|16), ctx, kv. Urteilsfarbe: grün passt · gelb knapp · rot passt nicht.

Warum einbetten? Die Frage Nr. 1 unter jeder Modellkarte und jedem lokalen KI-Tutorial ist „Läuft es auf meinem Rechner?“ Das Badge beantwortet sie live von der Engine – neu berechnet, wenn sich die Daten aktualisieren, keine veraltete Behauptung, die in deiner README eingefroren ist. Wenn du Modelle veröffentlichst oder Anleitungen schreibst: Eine Zeile ersetzt einen ganzen FAQ-Absatz und reduziert die „Es hat auf meiner 8-GB-Karte einen OOM ausgelöst“-Probleme, bevor sie gemeldet werden.

Frag deinen KI-Assistenten (MCP)

Die Engine läuft als öffentlicher MCP-Server unter https://fitllm.run/api/mcp – verbinde ihn einmal und dein Assistent antwortet auf „Kann ich X auf meinem Y ausführen?“ mit der Mathematik dieser Engine, statt aus veralteten Trainingsdaten zu raten (LLMs liegen bei KV-Cache-Mathematik regelmäßig falsch – siehe die 17,8×-Tabelle oben).

• Claude (Web / Desktop / Mobil): Einstellungen → Connectors → Benutzerdefinierten Connector hinzufügen → https://fitllm.run/api/mcp einfügen

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

• Cursor / Windsurf: füge zu mcp.json hinzu → { "mcpServers": { "fitllm": { "url": "https://fitllm.run/api/mcp" } } }

• ChatGPT: Einstellungen → Apps → Erweitert → Entwicklermodus → MCP-Server hinzufügen (Plus/Pro)

Werkzeuge: check_llm_fit (Urteil + vollständige Speicheraufschlüsselung + Korrekturvorschlag – unterstützt Multi-GPU-Setups wie "RTX 5090 + RTX 3090"), what_fits_on_hardware (Rangliste für deinen Rechner), list_supported. Ressourcen: fitllm://models, fitllm://hardware, fitllm://census, fitllm://engine. Absichtlich offen: schreibgeschützt, zustandslos, keine Authentifizierung, keine Geheimnisse – jeder Aufruf ist eine reine Funktion öffentlicher Daten.

Gelistet auf: offizielles MCP-Registry (run.fitllm/fitllm) · Glama · mcp.so · Smithery

Für Agenten & Skripte – einfache HTTP-API

Kein MCP-Client? Ein GET, keine Authentifizierung, kein Schlüssel – standardmäßig JSON, Klartext für 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

Offene Daten: der vollständige Fit-Zensus (über 8.000 Urteile, CC0) unter fitllm.run/data und auf Hugging Face Datasets. Teste die Engine im Browser: HF-Space-Demo.

Prinzipien

Keine Werbung. Kein Login. Keine Affiliate-Links. Ausgabe ist nie käuflich. Fit ist eine gewinnbare, verifizierbare Behauptung; rohe tok/s nicht – daher verweigert diese Engine Geschwindigkeitsvorhersagen, statt eine Vermutung als Präzision zu verkleiden.

Hilf mit zu kalibrieren

Ein Modell ausgeführt und echten Spitzenspeicher gemessen? Melde eine Messung – das verbessert die Schätzungen für alle.

Erstellt von

yongha — GitHub. Betreibt fitllm.run.

Lizenz

MIT © click6067-ship-it