Wer lokale KI ausprobieren will, steht irgendwann vor einer ziemlich banalen Frage: Welches Modell läuft eigentlich auf meinem Rechner? Die Auswahl an Open-Source-LLMs ist mittlerweile riesig, und bei Größe, Quantisierung und Speicherbedarf unterscheiden sich die Kandidaten teils erheblich. Wer sich da durch Modellkarten und Gigabytes an GGUF-Dateien wühlt, ist einen Abend beschäftigt.
llmfit nimmt euch diese Recherche ab. Das Open-Source-Tool liest die vorhandene Hardware aus und stellt sie einer Datenbank mit Sprachmodellen gegenüber. Heraus kommt eine ziemlich konkrete Antwort darauf, was auf der eigenen Maschine überhaupt sinnvoll laufen kann.
Welche Modelle passen zu meiner Hardware?
Nach dem Start erfasst llmfit zunächst die eigene Hardware: Prozessor, Arbeitsspeicher, Grafikkarte und verfügbarer VRAM. Anschließend stellt das Programm die vorhandenen Ressourcen den unterstützten Modellen gegenüber und sortiert die Liste nach einem Score.

Praktisch ist das vor allem deshalb, weil nicht nur die reine Modellgröße zählt. Ein Modell kann theoretisch in den vorhandenen Speicher passen und in der Praxis trotzdem quälend langsam laufen. llmfit schätzt deshalb ab, wie gut ein Modell zur Hardware passt und welche Geschwindigkeit beziehungsweise welcher Speicherbedarf zu erwarten ist.
Wie sehr sich das je nach Rechner unterscheidet, sieht man schon an zwei Geräten aus meinem Fundus. Auf dem Notebook mit dedizierter GTX 1050 sind die 4 GByte VRAM die harte Grenze. Auf einem Rechner mit Iris-Xe-Grafik teilen sich Prozessor und Grafikeinheit dagegen denselben Speicher – plötzlich steht fast überall „Perfect“.

Dabei berücksichtigt das Programm auch unterschiedliche Quantisierungen. Gerade bei lokal betriebenen Modellen landet man schnell bei Begriffen wie Q4, Q5 oder Q8. Vereinfacht gesagt wird dabei die Genauigkeit der Modellgewichte reduziert, um Speicherplatz und Rechenleistung zu sparen. Dafür muss man je nach Stufe gewisse Einbußen bei der Qualität in Kauf nehmen.
Relevant ist das vor allem bei GGUF-Modellen, die bei lokaler Inferenz häufig zum Einsatz kommen. llmfit bezieht die verschiedenen Quantisierungsstufen in seine Bewertung ein und kann dadurch auch Modelle vergleichen, die in mehreren Varianten vorliegen.
Wer sich unter Linux bisher mit Werkzeugen wie Inxi einen Überblick über die eigene Hardware verschafft hat, kennt das Prinzip bereits. llmfit geht allerdings einen Schritt weiter und setzt die ermittelten Daten direkt in Beziehung zu möglichen KI-Modellen.
Installation unter Arch Linux
Unter Arch Linux liegt uv direkt in den offiziellen Paketquellen. Die Installation ist damit erfreulich unspektakulär:
sudo pacman -S uv
Anschließend lässt sich llmfit mit uv als Tool installieren:
uv tool install -U llmfit
Danach steht llmfit direkt als Kommando zur Verfügung.
Wer das Programm zunächst nur ausprobieren möchte, kann alternativ uvx verwenden. Dabei wird llmfit ausgeführt, ohne es dauerhaft als Tool zu installieren:
uvx llmfit
Damit ist unter Arch Linux also kein zusätzlicher Installer für uv notwendig.
Installation unter Ubuntu
Unter Ubuntu ist der Weg etwas anders. Hier lässt sich uv je nach Ubuntu-Version und verwendeten Paketquellen nicht einfach über apt installieren. Der von den uv-Entwicklern bereitgestellte Installer ist daher eine unkomplizierte Möglichkeit.
Mit curl geht das so:
curl -LsSf https://astral.sh/uv/install.sh | sh
Alternativ lässt sich das Installationsskript mit wget herunterladen und ausführen:
wget -qO- https://astral.sh/uv/install.sh | sh
Danach solltet ihr zunächst prüfen, ob uv verfügbar ist:
uv --version
Anschließend funktioniert die Installation von llmfit genauso wie unter Arch Linux:
uv tool install -U llmfit
Zum Ausprobieren ohne dauerhafte Installation steht auch unter Ubuntu uvx zur Verfügung:
uvx llmfit
Wer uv nicht verwenden möchte, kann alternativ die fertigen Binärdateien aus den GitHub Releases von llmfit herunterladen.
llmfit wieder loswerden
Falls euch das Werkzeug doch nicht überzeugt: Der Weg zurück ist kurz, hat unter Arch aber einen Haken. Das Tool selbst verschwindet mit
uv tool uninstall llmfit
und ob noch etwas übrig ist, verrät
uv tool list
Wer llmfit nur mit uvx ausprobiert hat, hat ohnehin nie etwas dauerhaft installiert. Die heruntergeladenen Pakete liegen dann trotzdem im Cache von uv. Den leert ihr mit
uv cache clean
Und jetzt zum Haken: Wer uv über die Paketverwaltung installiert hat, ist versucht, einfach
sudo pacman -Rns uv
zu tippen. Pacman räumt dabei aber nur das eigene Paket ab. Was uv selbst im Heimatverzeichnis angelegt hat, kennt die Paketverwaltung nicht – und ohne uv lässt sich uv tool uninstall auch nicht mehr aufrufen. Deinstalliert also erst das Tool und dann uv, nicht umgekehrt.
Wo die Reste liegen, zeigen euch
uv tool dir
uv cache dir
Üblicherweise sind das ~/.local/share/uv/tools und ~/.cache/uv. Ist uv schon weg und llmfit noch da, bleibt nur das Aufräumen von Hand:
rm -r ~/.local/share/uv
Vorsicht dabei: Damit fliegen alle mit uv installierten Tools und die von uv verwalteten Python-Versionen mit raus, nicht nur llmfit.
Unter Ubuntu, wo uv über das Installationsskript kommt, gibt es kein uv self uninstall. Dort räumt ihr nach dem uv tool uninstall die beiden Startprogramme selbst weg:
rm ~/.local/bin/uv ~/.local/bin/uvx
Die TUI ist mehr als eine einfache Modellliste
Die Terminal-Oberfläche ist für mich einer der interessanteren Teile von llmfit. Statt nur eine Liste auszugeben, kann man sich durch die Ergebnisse bewegen, suchen und zu jedem Modell weitere Informationen abrufen.
Mit / sucht ihr nach einem bestimmten Modell, die Pfeiltasten beziehungsweise j und k dienen zur Navigation, und h öffnet die Hilfe. Bei knapp 10.000 Einträgen in der Liste ist die Suche tatsächlich kein Luxus.

Interessant sind außerdem die integrierten Benchmark-Funktionen. Mit b lassen sich Community-Benchmarks aufrufen, während I einen Inference-Benchmark mit der eigenen Hardware startet. Damit wird aus einer reinen Schätzung langsam eine Messung mit echten Werten.
Das erinnert ein wenig an klassische Systemwerkzeuge. Wer beispielsweise Mission Center unter GNOME nutzt, bekommt dort CPU, RAM, GPU und weitere Ressourcen grafisch präsentiert. llmfit schaut dagegen gezielt auf die Frage, was sich mit diesen Ressourcen an lokaler KI anfangen lässt.
Schätzwerte statt Marketing-Versprechen
Natürlich sollte man die Angaben von llmfit nicht mit einem echten Benchmark verwechseln. Eine theoretische Berechnung kann nur abschätzen, wie schnell ein bestimmtes Modell auf einer bestimmten Hardware laufen könnte.
Ganz nett ist in dem Zusammenhang die Hardware-Simulation. Damit dreht man testweise an RAM, VRAM und Kernanzahl und sieht, wie sich die Bewertung verschiebt. Wer mit dem Gedanken an einen Speicherriegel oder eine neue Grafikkarte spielt, bekommt so zumindest eine Hausnummer.

Genau deshalb sind die mittlerweile integrierten Benchmarks interessant. llmfit kann ein Modell herunterladen, es über einen unterstützten Runtime-Provider starten und anschließend die tatsächliche Geschwindigkeit auf der eigenen Hardware messen. Die Ergebnisse werden lokal gespeichert.
Wer möchte, kann seine Messwerte anschließend über
llmfit bench --share
mit der Community teilen. Die Ergebnisse werden dabei als GitHub Pull Request eingereicht. Auf diese Weise entsteht nach und nach eine Datenbasis aus echten Messungen und nicht nur aus theoretischen Berechnungen.
Gerade bei lokaler KI finde ich diesen Ansatz sinnvoll. Denn die Angabe „passt in den VRAM“ sagt noch nicht besonders viel darüber aus, ob man mit dem Modell tatsächlich vernünftig arbeiten kann.
Auch als Kommandozeilenwerkzeug nutzbar
Wer mit einer TUI wenig anfangen kann, muss llmfit nicht interaktiv bedienen. Das Programm lässt sich auch komplett über die Kommandozeile verwenden.
Zum Beispiel liefert
llmfit recommend
eine Empfehlung für die vorhandene Hardware. Mit
llmfit recommend --json
lassen sich die Ergebnisse als JSON ausgeben. Das ist natürlich deutlich interessanter, wenn ihr llmfit in eigene Skripte oder andere Werkzeuge einbauen wollt.
Auch ein Webinterface beziehungsweise eine API lässt sich starten:
llmfit serve --host 0.0.0.0 --port 8787
Für Container gibt es außerdem ein fertiges Image:
ghcr.io/alexsjones/llmfit
Damit läuft llmfit beispielsweise auch auf einem Server oder in einer bestehenden Docker-Umgebung. Wer seine Container regelmäßig aktuell hält, kennt das Spiel vielleicht schon von Dockcheck.
Und womit läuft das Modell dann?
Eine Unterscheidung solltet ihr dabei im Hinterkopf behalten: llmfit ist selbst keine KI-Runtime. Das Programm hilft bei Auswahl und Bewertung eines Modells, die eigentliche Inferenz erledigen andere Werkzeuge.

Unterstützt werden unter anderem Ollama, llama.cpp, MLX, Docker Model Runner und LM Studio. Dadurch kann llmfit beispielsweise ein Modell über einen vorhandenen Ollama- oder llama.cpp-Stack benchmarken.
Für Linux ist Ollama sicherlich eine der einfacheren Möglichkeiten, lokale Modelle zum Laufen zu bekommen. Wer mehr Kontrolle über die eigentliche Inferenz haben möchte, landet dagegen schnell bei llama.cpp. Beide Projekte verfolgen etwas unterschiedliche Ansätze, lassen sich aber gut mit dem Hardware-Check von llmfit kombinieren.
Interessant für lokale KI
llmfit schließt für mich eine Lücke zwischen „Ich möchte lokale KI ausprobieren“ und „Ich muss mich erst einmal durch die Hardwareanforderungen von dutzenden Modellen arbeiten“. Das ist deutlich hilfreicher als eine allgemeine Liste der „besten“ lokalen Modelle. Denn am Ende zählt nicht, welches Modell auf irgendeinem Testsystem gut abschneidet, sondern welches auf eurer Hardware mit eurem Anwendungsfall vernünftig funktioniert.
Die Schätzungen ersetzen natürlich keinen eigenen Test. Genau dafür sind die integrierten Benchmarks da, und die will ich mir als Nächstes vornehmen: eigene Messungen auf verschiedenen Geräten, und dann der Abgleich, wie gut die Vorhersagen von llmfit mit der Realität zusammenpassen.
Gerade für Entwickler dürfte das Werkzeug interessant sein. Wer einen lokalen KI-Assistenten zum Programmieren einsetzen möchte, findet zuerst heraus, welche Modelle zur vorhandenen Hardware passen, und experimentiert anschließend mit den tatsächlich erreichbaren Geschwindigkeiten.
Weitere Informationen, die aktuelle Dokumentation und den Quellcode findet ihr auf GitHub.






Schreibe einen Kommentar