Alle paar Monate habe ich versucht, ein lokales Sprachmodell auf eigener Hardware laufen zu lassen. Die Motivation war jedes Mal dieselbe: ich will meine Prompts nicht an einen Anbieter geben, den ich nicht kontrollieren kann, ich will nicht pro Token für Dinge zahlen, die ich noch iteriere, und mich interessiert ehrlich, was die offenen Modelle auf der Hardware können, die ich ohnehin schon habe. Die Absicht war immer real. Die Umsetzung weniger.
Jeder Versuch hatte dieselbe Form. Pick eine Runtime (llama.cpp, Ollama, text-generation-webui, vLLM, such dir was aus). Pick eine Modelldatei, dann pick eine Quantisierung (Q4_K_M, Q5_K_S, IQ3_XXS und ein Dutzend weiterer Namen, die einen Unterschied implizieren, den du angeblich schon kennen solltest). Finde ein GGUF, das ohne Konto herunterladbar ist. Lies drei Blogposts, um herauszufinden, welche Flags für deine Hardware zählen. Stelle fest, dass das Binary, das du vor ein paar Wochen gebaut hast, schon zwei Versionen veraltet ist. Fang nochmal an. Nachdem ich diese Schleife ein paar Mal durchlaufen und im Wesentlichen jedes Mal dasselbe Glue-Skript geschrieben hatte, habe ich gestoppt und es ordentlich gemacht.
Das Ergebnis ist hydra-llm. Es ist ein kleines CLI plus ein optionales KDE-Plasma-6-Widget. Darunter liegt einfach llama.cpp in Docker, mit einem kuratierten Katalog community-quantisierter GGUF-Dateien (Bartowski, lmstudio-community, mradermacher), die ohne Hugging-Face-Konto laden. Das CLI macht die vier Dinge, die ich am Prompt tatsächlich tue: list-online, download, chat und api. Das Plasma-Widget ergänzt einen glanceable-Status für Leute, die – wie ich – das Panel ständig sichtbar haben.
Ich war unsicher, ob das überhaupt einen Wrapper rechtfertigt. Ollama existiert. llama.cpp existiert. text-generation-webui existiert. Die Antwort ist, dass keiner davon die genauen Reibungen abdeckt, die mich gestoppt haben. Ollama versteckt zu viel und macht es mühsam, ein bestimmtes GGUF zu nutzen, das mich interessiert. llama.cpp ist nackt, sodass jedes Setup eine Übung in Flag-Recherche ist. text-generation-webui geht in die andere Richtung – grafisch, schwer, nicht das, was ich für ein Skript will. Ich wollte einen dünnen Layer, der genau das tut, was ich vom Terminal aus tue, und den Rest aus dem Weg lässt.
Die größte Reibung war, dass ich nicht im Voraus weiß, was meine Hardware aushält. Welche Quantisierung sollte ich für ein 14B-Modell auf 16GB VRAM nehmen? ist die Sorte Frage, deren Antwort ich jedes Mal auseinanderziehen musste. hydra-llm hat ein Konzept von Hardware-Tiers – Low, Medium, High, Beast – mit sinnvollen Defaults für jedes. Du musst dich nicht zwischen Q4_K_M und IQ3_XXS entscheiden; du sagst dem Tool, in welchem Tier du bist, und es wählt eine Quantisierung, die in deinen VRAM passt und nicht furchtbar aussieht. Das ist nicht clever, aber es ist die Reibung, die mich gestoppt hat.
Die Tiers sind explizit konservativ. Eine Tier-Wahl könnte dir nicht das schnellste Modell geben, das du theoretisch laufen lassen könntest, aber sie wird kein Modell wählen, das auf deiner Maschine bricht. Wenn du clever sein willst, sind die Defaults überschreibbar. Wenn du nicht clever sein willst, läuft es einfach.
Die Konfiguration ist in drei flachen Schichten. Es gibt einen Default in der Binary, eine system-weite Datei in /etc und eine Per-User-Datei unter ~/.config. Per-User überschreibt System-weit, was den Default überschreibt. Es gibt keine Includes, keine Vererbung, kein Schema. Das war Absicht: das Letzte, was ich in einem CLI für lokale LLMs will, ist eine Konfigurations-DSL, die einen Tag braucht, bis man sie versteht.
Drei Schichten ist genau die Anzahl, die alle Wege abdeckt, die mich Konfigurationen tatsächlich überschreiben sehen lässt: ich teste etwas Maschinen-spezifisches, das System-Admin hat seine eigenen Constraints, oder die Distribution liefert sinnvolle Defaults. Mehr Schichten wäre Architektur um der Architektur willen.
Das Plasma-Widget zeigt, ob ein Modell läuft, welches Modell läuft, und wie viel VRAM/RAM es belegt. Klick öffnet einen Chat. Rechtsklick switcht das Modell. Es gibt kein Settings-Panel; das Widget liest dieselbe Per-User-Konfiguration wie das CLI. Wenn du das Widget nicht willst, installier es nicht. Das CLI ist self-contained.
hydra-llm sendet nichts an irgendeinen Server außer dem Modell-Download und einer optionalen Versionsprüfung, die per Flag deaktivierbar ist. Es gibt keine Telemetrie. Wenn du im Flugzeug oder hinter einem Air-Gap arbeitest, läuft alles, was bereits heruntergeladen wurde, weiter. Das ist der Grund, weshalb ich überhaupt lokal betreibe.
Die ehrliche Erkenntnis aus diesem Projekt ist, dass die meisten "Friction"-Probleme, an denen ich mit lokalen LLMs gescheitert bin, nichts mit Modellqualität zu tun hatten. Sie hatten mit Defaults zu tun, mit Hardware-Awareness, mit ständig nachziehenden Build-Schritten und mit einem Konfigurations-Format, das ich vergessen hatte, sobald ich aufstand. Wenn du diese Reibungen einsammelst und an einer Stelle löst, wird die Erfahrung von "interessant, aber ich werde es nicht jeden Tag laufen lassen" zu "ich nutze es seit Monaten und schaue nicht hin".