llmfit: Modellkatalog gegen RAM, CPU und VRAM der eigenen Maschine rechnen

llmfit: vier Dimensionen statt Datenblatt-Vergleich

Die Repository-Beschreibung von AlexsJones/llmfit fasst den Zweck knapp zusammen: Das Werkzeug prüft die lokale Hardware gegen die Anforderungen von Modellen und empfiehlt Modelle sowie Provider, die in den verfügbaren Speicher und die vorhandene Rechenleistung passen. Der Anspruch in der README klingt größer, nämlich hunderte Modelle und Provider mit einem einzigen Befehl zu filtern.

Das Ergebnis ist eine Bewertung in vier Dimensionen. llmfit bewertet nach der Beschreibung im Dokument Speicherpassung, geschätzte Geschwindigkeit, Qualität und Kontext und kombiniert diese Angaben zu einer Rangfolge. Modelle, die auf der vorliegenden Maschine nicht lauffähig sind, landen am Ende der Liste statt irgendwo dazwischen. Damit beantwortet das Werkzeug eine Frage, die Modellübersichten auf Hugging Face offenlassen, nämlich welche Variante konkret in den eigenen Speicher passt.

Zum Projektstand: Im Material sind 34438 Sterne, 2153 Forks und 64 offene Issues eingetragen, als Sprache Rust, als Standardbranch main und als neueste Version v1.1.12 vom 28. August 2026. Die Versionsfolge v1.1.10, v1.1.11 und v1.1.12 innerhalb von knapp zwei Wochen deutet auf einen dichten Release-Takt hin.

llmfit fit, recommend --json, info, bench und doctor

Ohne Argument startet llmfit eine interaktive Terminal-Oberfläche, die oben die erkannte Hardware zeigt und darunter die bewerteten Modelle. Für Skripte, Agenten und klassische Terminalausgabe gibt es Unterbefehle. llmfit fit liefert eine Tabelle aller Modelle, sortiert nach Passung. llmfit recommend --json gibt die besten Treffer als JSON aus, was sich für die Weiterverarbeitung anbietet.

Zwei Unterbefehle sind für die Bewertung der Zahlen selbst gedacht. llmfit info gefolgt vom Modellnamen zeigt die Analyse eines einzelnen Modells, die Grundlage der Schätzung und die Befehle, mit denen sich die Annahmen auf der eigenen Maschine nachprüfen lassen. llmfit doctor erzeugt einen Bericht zur Hardware-Erkennung, der README zufolge für Fehlermeldungen gedacht ist.

Neu ist der Unterbefehl llmfit bench. Er misst reale Werte, also Tokens pro Sekunde und Zeit bis zum ersten Token, gegen einen laufenden Provider. Damit lässt sich die Schätzung des Werkzeugs mit der Wirklichkeit abgleichen, was die README ausdrücklich als Zweck nennt. Wer wissen will, wie verlässlich eine Empfehlung ist, findet hier den schnellsten Weg zur Antwort.

Von brew install bis cargo build --release: sechs Wege zur Installation

Für Windows nennt die README zuerst scoop install llmfit. Unter macOS und Linux führt der empfohlene Weg über ein eigenes Tap: brew install AlexsJones/llmfit/llmfit liefert ein vorkompiliertes Binary. Wer die Formel aus dem Homebrew-Kern nutzt, schreibt brew install llmfit, wobei auf macOS-Versionen ohne Bottle aus dem Quellcode gebaut wird. MacPorts-Nutzer schreiben port install llmfit.

Daneben gibt es ein Installationsskript, aufgerufen mit curl -fsSL https://llmfit.axjns.dev/install.sh | sh. Es lädt das aktuelle Release-Binary und legt es in /usr/local/bin ab, oder in ~/.local/bin, wenn keine sudo-Rechte vorliegen; wer das erzwingen will, hängt --local an. Als Python-Paket lässt sich das Werkzeug mit uv tool install -U llmfit installieren und mit uvx llmfit ohne Installation ausführen.

Für Container-Umgebungen nennt die README docker run ghcr.io/alexsjones/llmfit, was die JSON-Ausgabe von llmfit recommend liefert. Ein Beispiel kombiniert das mit podman und jq: podman run ghcr.io/alexsjones/llmfit recommend --use-case coding | jq '.models[].name'. Die Terminal-Oberfläche im Container verlangt die globale Option --tui. Aus dem Quellcode heraus genügen git clone, ein Wechsel in das Verzeichnis und cargo build --release, das Ergebnis liegt danach unter target/release/llmfit.

sysinfo, nvidia-smi, system_profiler: was llmfit erkennt

Die Erkennung beginnt mit Arbeitsspeicher und Prozessorkernen über die sysinfo-Bibliothek. Danach sucht llmfit nach Beschleunigern: NVIDIA über nvidia-smi, AMD über rocm-smi, Intel Arc über sysfs oder lspci, Apple Silicon über system_profiler und Ascend über npu-smi. Auf Apple Silicon entspricht der VRAM-Wert dem System-RAM, weil dort ein gemeinsamer Speicher vorliegt.

Die Plattformliste umfasst Linux, macOS mit Apple Silicon und Intel sowie Windows. Unter Windows werden RAM und CPU erkannt, für NVIDIA-GPUs wird ebenfalls nvidia-smi vorausgesetzt. In Android-Umgebungen wie Termux mit PRoot funktioniert die automatische GPU-Erkennung nicht; dort bleiben manuelle Überschreibungen über --memory, --ram und --cpu-cores. Dieselben Schalter helfen, wenn die automatische Erkennung auf anderen Systemen danebenliegt.

Zu den Modellen selbst rechnet das Werkzeug den Speicherbedarf aus Parameterzahl und Quantisierungsstufe und wählt die höchste Stufe, die in den verfügbaren Speicher passt. Bei Mixture-of-Experts-Architekturen wird berücksichtigt, dass pro Token nur ein Teil der Experten aktiv ist, wodurch der effektive VRAM-Bedarf deutlich unter dem liegt, was die Gesamtparameterzahl erwarten ließe.

Speicherbandbreite mal 0,55: woher die tok/s-Schätzung kommt

Die Geschwindigkeitsschätzung von llmfit beruht auf einem Speicherbandbreiten-Modell. Die Formel teilt die Bandbreite in Gigabyte pro Sekunde durch die Modellgröße in Gigabyte und multipliziert das Ergebnis mit einem Wirkungsfaktor, der standardmäßig bei 0,55 liegt und im erweiterten Konfigurationsbereich angepasst werden kann. Für die Bandbreite greift eine Nachschlagetabelle mit rund 80 Grafikkarten; wird eine Karte nicht erkannt, tritt ein backend-spezifischer Festwert an ihre Stelle.

Wichtig ist der Umgang mit diesen Zahlen, den die README selbst betont: Jede Schätzung bringt ihre Eingangsgrößen mit, und llmfit info zeigt, was eine Zahl annimmt und wie sie sich auf der eigenen Maschine nachprüfen lässt. Das ist die ehrliche Antwort auf ein Grundproblem solcher Werkzeuge, denn eine Schätzung aus Datenblättern kann die Realität nur annähern.

Genau hier setzt die Neuerung der jüngeren Versionen an. Über den Benchmark-Pfad lassen sich gemessene Werte an das Projekt zurückgeben, und zwar aus der Terminal-Oberfläche heraus, ohne gh-Kommandozeilenwerkzeug und ohne Konto bei einem Dritten. Jeder Lauf wird zuerst lokal gespeichert, eigene Messungen ersetzen die Schätzwerte in der Tabelle, und eingereichte Ergebnisse erscheinen mit der nächsten Version. Wer identische Hardware betreibt, sieht danach gemessene Werte, bevor er selbst misst.

llmfit serve, das Dashboard auf 0.0.0.0:8787 und Multi-GPU

Neben Terminal-Oberfläche und Kommandozeile beschreibt die Dokumentation einen Server-Modus. llmfit serve startet eine REST-Schnittstelle, die dieselben Passungs- und Bewertungsdaten liefert und sich für Cluster-Scheduler oder eigene Skripte anbietet. Zusätzlich läuft beim Start von llmfit ein Web-Dashboard im Hintergrund, das auf 0.0.0.0:8787 lauscht und aus jedem Browser im selben Netz erreichbar ist.

Diese Bindung an alle Schnittstellen ist der Punkt, den man vor dem Einsatz in einem fremden Netz bedenken sollte. Wer das Dashboard nicht braucht, sollte die Freigabe im eigenen Netz einschränken, statt die Voreinstellung stehen zu lassen.

Zu den Fähigkeiten jenseits der Einzelfallprüfung zählen Mehr-GPU-Systeme, die dynamische Auswahl der Quantisierung, die Geschwindigkeitsschätzung und lokale Laufzeit-Provider. Genannt werden Ollama, llama.cpp, MLX, Docker Model Runner und LM Studio. Als Schwesterprojekte führt die README sympozium für Agenten in Kubernetes, llmserve als Oberfläche zum Bereitstellen lokaler Modelle und llama-panel als native macOS-Anwendung für llama-server-Instanzen.

llm-checker als Alternative: echte Läufe ohne MoE-Unterscheidung

Die README benennt selbst eine Alternative, was bei Projekten dieser Art nicht selbstverständlich ist. llm-checker ist ein Kommandozeilenwerkzeug in Node.js mit Ollama-Anbindung, das Modelle herunterlädt und direkt auf der eigenen Hardware misst, statt aus Kenndaten zu schätzen. Der Ansatz ist damit praktischer, wenn Ollama ohnehin installiert ist und reale Werte gebraucht werden.

Der Unterschied liegt in der Methode und hat eine Grenze, die die README offen benennt: llm-checker unterscheidet keine Mixture-of-Experts-Architekturen, behandelt also alle Modelle als dicht. Bei Modellen wie Mixtral oder DeepSeek-V3 spiegeln die Speicherabschätzungen deshalb die Gesamtparameterzahl statt der kleineren aktiven Teilmenge. llmfit rechnet hier anders und berücksichtigt die aktiven Experten, was bei diesen Architekturen zu deutlich anderen Speicherwerten führt.

Verteilung und Vertrauen sind zwei weitere Punkte. llmfit steht unter MIT, Copyright Alex Jones, und wird über crates.io sowie Paketmanager verteilt; Windows-Binaries sind über SignPath.io mit einem Zertifikat der SignPath Foundation signiert, und die Signierung läuft automatisch in .github/workflows/release.yml. Nach Angaben der Dokumentation überträgt das Werkzeug keine Daten, solange nicht ausdrücklich Funktionen wie Modell-Downloads, Provider-Abfragen oder die Community-Rangliste genutzt werden. Wer den Quellcode mitbauen will, führt vor einem Beitrag cargo fmt aus, weil die meisten CI-Fehler von nicht formatiertem Code herrühren.

Redaktionelles Fazit

llmfit lohnt sich für alle, die vor dem Herunterladen eines Modells wissen wollen, welche Quantisierung auf der eigenen Maschine überhaupt in Frage kommt, und die eine Rangliste statt einzelner Datenblätter suchen. Weniger geeignet ist es für Umgebungen ohne verlässliche Hardware-Erkennung, etwa Termux mit PRoot, wo nur manuelle Überschreibungen mit --memory und --ram helfen, und für alle, die gemessene statt geschätzter Werte brauchen und keinen Benchmark mit llmfit bench fahren wollen. Wer einsteigt, installiert über brew install AlexsJones/llmfit/llmfit oder uv tool install -U llmfit, schaut mit llmfit doctor nach, was überhaupt erkannt wurde, und prüft mit llmfit info eines der vorgeschlagenen Modelle, bevor Speicherplatz für einen Download eingeplant wird.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes