Paddler: LLM-Lastverteilung mit zwei Komponenten und llama.cpp im Kern
Open-source LLM/VLM load balancer and serving platform for self-hosting LLMs (and VLMs) at scale 🏓🦙 Alternative to projects like llm-d, Docker Model Runner, etc but with less moving parts and simple deployments built around ggml ecosystem. Runs on CPU and GPU.
Auf einen Blick
- Was ist das?
- Paddler verteilt Inferenzanfragen auf eigene Hardware, ohne Kubernetes und ohne externen Modell-Anbieter. Der Balancer und die Agents sind getrennte Prozesse, die Slots halten Kontext und KV-Cache selbst.
- Für wen ist es gedacht?
- Wer LLM-Inferenz auf eigener Hardware betreiben will und dafür keine Kubernetes-Kontrollebene aufsetzen möchte, findet in Paddler einen Balancer und Agents, die als einzelne Binary ausgeliefert werden. Wer bereits vLLM mit PagedAttention und kontinuierlichem Batching im Einsatz hat, sollte vor einem Wechsel prüfen, ob Paddlers Slot-Modell mit eigener Kontext- und KV-Cache-Verwaltung den eigenen Durchsatz erreicht.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 16. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Lücke Paddler schließt
Wer ein Modell selbst hostet, steht vor einer Aufgabe, die nichts mit dem Modell zu tun hat: Anfragen müssen auf mehrere Maschinen verteilt werden, und zwar so, dass jede Maschine ihre eigene Kontextverwaltung behält. Genau hier setzt Paddler an. Das Projekt bezeichnet sich als LLM-Load-Balancer und Serving-Plattform und nennt als Zielgruppe Product-Teams, DevOps- und LLMOps-Teams sowie Organisationen mit hohen Compliance- und Datenschutzanforderungen, etwa im medizinischen oder finanziellen Bereich. Ein weiteres Motiv steht im ersten Absatz des README: planbare Kosten statt Pro-Token-Abrechnung.
Die Abgrenzung zu llm-d und Docker Model Runner formuliert das Repository selbst, und zwar über den Umfang: weniger bewegliche Teile, einfache Deployments, verwurzelt im ggml-Ökosystem. Das ist keine technische Aussage über Durchsatz oder Latenz, sondern eine über die Anzahl der Komponenten, die ein Betriebsteam verstehen muss. Ob dieser Tausch aufgeht, hängt davon ab, was man bereits betreibt.
Balancer, Agents, Slots: die drei Ebenen
Paddler kennt laut README genau zwei deploybare Komponenten. Der balancer verteilt eingehende Anfragen und stellt drei Dienste bereit: den Inferenzdienst, den Anwendungen für Token und Embeddings ansprechen, den Managementdienst für die interne Steuerung des Verbunds und ein Web-Admin-Panel zur Ansicht und zum Testen. Die agents laufen üblicherweise auf getrennten Instanzen und reichen Anfragen an slots weiter. Die slots erzeugen Token und Embeddings.
Der interessante Teil ist die letzte Ebene. Paddler nutzt eine eingebaute llama.cpp-Engine, implementiert die Slots aber selbst, und diese Slots verwalten eigenen Kontext und eigenen KV-Cache. Das ist die eigentliche Architekturentscheidung: Der Balancer verteilt nicht zwischen gleichartigen Arbeitern, die einen gemeinsamen Zustand teilen, sondern zwischen Einheiten mit eigenem Gedächtnis. Wer schon einmal mit llama.cpp-Servern gearbeitet hat, kennt die Konsequenz: Ein Slot mit belegtem Kontext kann eine neue Anfrage nicht einfach übernehmen, ohne den alten Zustand zu verdrängen.
Agents lassen sich laut README dynamisch hinzufügen, was die Anbindung an Autoscaling-Werkzeuge ermöglichen soll. Zusammen mit dem Request-Buffering, das im README als Voraussetzung für das Skalieren von null Hosts genannt wird, ergibt sich ein Bild: Der Balancer muss Anfragen halten können, während Agents starten. Wie diese Pufferung begrenzt ist und was passiert, wenn sie vollläuft, steht im README nicht. Das ist eine offene Flanke, die man in der Dokumentation prüfen sollte, bevor man auf Skalierung von null setzt.
Inbetriebnahme in zwei Befehlen
Paddler wird als einzelne Binary ausgeliefert. Man bezieht sie laut README entweder aus den GitHub-Releases oder baut sie selbst; die angegebene MSRV ist 1.88.0. Die gesamte Funktionalität liegt hinter dem Kommando paddler, und paddler --help listet die verfügbaren Unterbefehle auf.
Der Balancer startet so:
paddler balancer --inference-addr 127.0.0.1:8061 --management-addr 127.0.0.1:8060 --web-admin-panel-addr 127.0.0.1:8062
Der Schalter --web-admin-panel-addr ist optional. Ohne ihn läuft der Balancer weiter, man verliert nur die Browseransicht. Ein Agent mit vier Slots startet so:
paddler agent --management-addr 127.0.0.1:8060 --slots 4
Beide Beispiele stammen aus dem README. Bemerkenswert ist, dass der Agent nur die Management-Adresse des Balancers kennt. Es gibt keine Konfigurationsdatei, keinen Service-Discovery-Schritt und keinen Registrierungscode. Die Slot-Anzahl ist ein reiner Zähler, keine Angabe zur Hardware. Wie viele Slots sinnvoll sind, hängt von Speicher und Modellgröße ab, und dazu macht das README keine Vorgabe. Die Modellkonfiguration läuft laut README über das Web-Admin-Panel, in dem man Modelle hinzufügt und aktualisiert sowie Chat-Template und Inferenzparameter anpasst. Wer den Balancer ohne --web-admin-panel-addr startet, muss diesen Weg über die API gehen.
Was die Einzelbinary nicht löst
Die Reduktion auf zwei Komponenten hat einen Preis, den das README nicht benennt. Die Slots verwalten eigenen Kontext und KV-Cache; daraus folgt, dass der Speicherbedarf pro Agent mit der Anzahl der Slots und der Kontextlänge wächst. Ein Agent mit vielen Slots auf einer Maschine mit wenig VRAM ist keine gute Idee, aber das README nennt keine Formel und keine Warnung. Wer die Slot-Anzahl setzt, muss selbst wissen, was das Modell an KV-Cache pro Kontext kostet.
Ein zweiter Punkt betrifft die Modellverwaltung. Dynamic model swapping steht in der Feature-Liste, und das Web-Admin-Panel erlaubt das Hinzufügen und Aktualisieren von Modellen. Ob ein laufender Slot ein Modell im Betrieb wechseln kann oder ob dafür der Agent neu gestartet werden muss, geht aus dem Material nicht hervor. Wer Modelle häufig wechselt, sollte das vor dem Produktiveinsatz klären.
Schließlich die Frage der Anbindung. Paddler ist kein OpenAI-kompatibler Proxy, der beliebige Backends zusammenfasst. Die Inferenz läuft über die eingebaute llama.cpp-Engine. Wer Modelle einsetzt, die llama.cpp nicht laden kann, für den ist Paddler das falsche Werkzeug, unabhängig davon, wie gut der Balancer passt.
Der Unterschied zu vLLM
Der naheliegende Vergleich ist vLLM. Beide Projekte verteilen Inferenzarbeit auf mehrere Slots oder Worker, aber sie lösen unterschiedliche Probleme. vLLM ist in erster Linie eine Inferenz-Engine mit PagedAttention und kontinuierlichem Batching, die den Speicher für den KV-Cache in Blöcke aufteilt und dadurch viele gleichzeitige Sequenzen auf einer GPU unterbringt. Paddler baut auf llama.cpp auf und implementiert die Slots selbst, mit eigenem Kontext und eigenem KV-Cache. Das README beschreibt keine PagedAttention und kein kontinuierliches Batching.
Daraus folgt eine andere Arbeitsteilung. vLLM optimiert den Durchsatz innerhalb einer Maschine. Paddler optimiert die Verteilung über mehrere Maschinen und übernimmt die Modellverwaltung gleich mit. Wer eine einzelne große GPU möglichst auslasten will, ist bei vLLM besser aufgehoben. Wer mehrere Rechner mit unterschiedlicher Hardware zu einem Verbund zusammenfassen will, findet bei Paddler die passendere Form, weil der Agent als eigener Prozess auf jeder Maschine läuft und die Slot-Anzahl pro Agent gesetzt wird.
Das Desktop-Anwendungsbeispiel im README macht diese Ausrichtung deutlich: ein Balancer im Serverrack, ein Kollege mit einer RTX 5090, der sich ad hoc als Agent anschließt, wenn er seine Rechenleistung nicht braucht. Dieses Szenario ist mit einer Engine, die auf eine GPU optimiert ist, nicht abbildbar.
Desktop-App, KI-Code und der Stand der Dinge
Paddler existiert in zwei Formen: als Kommandozeilenwerkzeug für Infrastruktur und als Desktop-Anwendung für Fälle, in denen man mehrere Laptops und PCs zu einem lokalen Cluster verbinden will, ohne ein Terminal zu öffnen. Die Desktop-App trägt im README die Kennzeichnung beta. Beide Formen lassen sich mischen, wie das Beispiel mit dem Balancer im Rack und dem ad hoc angeschlossenen Agent zeigt. Für die Desktop-Variante verweist das README auf einen eigenen Dokumentationsabschnitt.
Bemerkenswert ist der Abschnitt zur Frage, ob KI-generierter Code akzeptiert wird. Die Antwort lautet: Der gesamte Code ist menschlich geprüft, der größte Teil handgeschrieben. Als erfolgreiche KI-Einsätze nennt das README den HTTP-Client, der an die Kernbibliothek anbindet, und ein Integrationstest-Harness, mit dem bestehende Tests zusammengeführt wurden. Das ist eine ungewöhnlich konkrete Angabe über den eigenen Entwicklungsprozess und gleichzeitig eine Einschränkung: Der Text ist an dieser Stelle abgeschnitten, der vollständige Umfang der KI-Nutzung bleibt offen.
Die letzten Releases liegen zeitlich eng beieinander: v4.0.1, dann v4.1.0-rc1, dann v4.1.0 mit dem Zusatz OpenCode support. Ein Release-Kandidat vor der stabilen Version deutet auf ein Projekt mit laufender Entwicklung, nicht auf einen eingefrorenen Stand.
Lizenz, Wartung und was zu prüfen bleibt
Paddler steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Änderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Sie enthält eine ausdrückliche Patentgewährung. Das ist eine Einordnung, keine Rechtsberatung; wer Paddler in ein Produkt einbettet, sollte die Bedingungen mit der eigenen Rechtsabteilung klären, insbesondere die Frage, was als Änderung kenntlich zu machen ist.
Zum Wartungsaufwand lässt sich aus dem Material nur begrenzt etwas sagen. Das Repository ist nicht archiviert, die letzte Aktualisierung liegt bei Juli 2026, und die Versionsnummer steht bei 4.x. Es gibt einen Discord-Server, ein neu gestartetes Subreddit und einen Vortrag auf der FOSDEM 2026 mit dem Titel From Infrastructure to Production: A Year of Self-Hosted LLMs. Diese Angaben belegen Aktivität, aber nicht, wie viele Personen dahinterstehen oder wie lange.
Für den Betrieb relevant ist die Upgrade-Frage. Bei zwei Komponenten und einer Binary ist ein Update technisch ein Austausch der Datei und ein Neustart. Ob ein laufender Verbund einen Versionssprung ohne Unterbrechung übersteht, ob also ein neuer Balancer mit alten Agents spricht, steht im README nicht. Wer Paddler produktiv einsetzt, sollte die Management-Schnittstelle zwischen Balancer und Agents als die kritische Stelle behandeln und vor jedem Upgrade prüfen, ob beide Seiten dieselbe Protokollversion sprechen.
Redaktionelles Fazit
Wer LLM-Inferenz auf eigener Hardware betreiben will und dafür keine Kubernetes-Kontrollebene aufsetzen möchte, findet in Paddler einen Balancer und Agents, die als einzelne Binary ausgeliefert werden. Wer bereits vLLM mit PagedAttention und kontinuierlichem Batching im Einsatz hat, sollte vor einem Wechsel prüfen, ob Paddlers Slot-Modell mit eigener Kontext- und KV-Cache-Verwaltung den eigenen Durchsatz erreicht. Zuerst zu klären ist, ob die Dokumentation unter paddler.intentee.com die eigenen Anforderungen an Autoscaling und Metriken abdeckt, denn das README verweist für Details nur auf diese Seiten.
Community-Notizen