Was ich durch Beiträge zu llm-d gelernt habe, einem produktiven Inferenz-Router

Die meisten Texte über LLM-Infrastruktur handeln vom Modell. Sehr wenige handeln von der Schicht davor.

Genau dort lebt produktive Inferenz. Anfragen kommen an, werden eingereiht, priorisiert und an ein GPU-Backend geroutet, das vielleicht schon ausgelastet ist. Das Modell ist der einfache Teil. Die Entscheidung, welche Anfrage in welcher Reihenfolge und unter welchem Speicherbudget bedient wird, ist der schwere Teil.

In den letzten zwei Monaten habe ich zu llm-d beigetragen, der Inferenz-Routing-Schicht, die von Ingenieuren von Red Hat, IBM und Google gepflegt wird. Das habe ich dabei gelernt.

Was llm-d ist

llm-d ist ein intelligenter Load Balancer für LLM-Inferenz auf Kubernetes.

Es sitzt zwischen Nutzern und den GPU-Servern, die Modelle wie vLLM ausführen. Für jede eingehende Anfrage entscheidet es, welches Backend sie bearbeiten soll, basierend auf Faktoren wie GPU-Speicherdruck und gecachten Prefixes. Es hat eine Flow-Control-Schicht, die Anfragen einreiht und priorisiert, wobei jede Prioritätsstufe ein Band mit eigenem Speicherbudget bekommt.

Das ist kein Demo. Es ist die Art von Komponente, die entscheidet, ob ein Inferenz-Cluster unter Last innerhalb des SLA bleibt.

Der Beitrag, der mir am meisten beigebracht hat

Das Flow-Control-System weist jeder Anfrage eine numerische Priorität zu. Positiv bedeutet wichtig. Negativ bedeutet verzichtbar.

Wenn Traffic auf einer Prioritätsstufe ankommt, die nicht vorkonfiguriert war, erstellt das System spontan ein Band über eine einzige Default-Vorlage. Das Problem: Es gab keine Möglichkeit, negativer Priorität ein kleineres Speicherbudget zu geben als positiver. Beide teilten sich denselben Default.

Man konnte also einen ganz gewöhnlichen operativen Wunsch nicht ausdrücken:

Normaler Traffic bekommt 1GB Queue-Budget. Verzichtbarer Traffic bekommt null und wird abgewiesen, sobald das System unter Druck steht.

Ich habe eine zweite Vorlage hinzugefügt, DefaultNegativePriorityBand, die nur beim dynamischen Provisionieren von Bändern für Priorität unter null verwendet wird. Wenn sie nicht gesetzt ist, bleibt das Verhalten unverändert, der Change ist also rückwärtskompatibel. Die Runtime wählt die Vorlage nach dem Vorzeichen der Priorität.

Die Code-Änderung ist klein. Interessant war alles drumherum: die nutzerseitige API-Config, die interne Config mit Validierung und Deep-Copy, die Runtime-Provisionierungslogik und neun Tests für Konstruktion, API-Übersetzung, Clone-Isolation und dynamische Provisionierung für positive, negative und Fallback-Fälle.

Genau dieses Verhältnis ist die Lektion. In produktiver Infrastruktur ist die Drei-Zeilen-Verhaltensänderung der einfache Teil. Die API-Fläche, die Validierung, die Rückwärtskompatibilitäts-Garantie und die Tests sind die Arbeit.

Auch die unglamourösen PRs zählen

Nicht jeder Beitrag ist ein Feature.

Einer meiner ersten gemergten PRs war ein CI/CD-Hardening-Durchlauf: eine veränderliche Action-Referenz auf einen Commit-SHA gepinnt, Least-Privilege-Permission-Blöcke zu neun Workflows hinzugefügt, ein Timeout für einen Test-Job ergänzt, der sonst einen Runner sechs Stunden halten könnte, Concurrency-Gruppen hinzugefügt, damit neue Pushes veraltete Runs abbrechen, und Abhängigkeits-Schwachstellenprüfung ergänzt.

Nichts davon ändert, was der Router tut. Alles davon ändert, ob das Projekt sicher und günstig zu betreiben ist. Supply-Chain-Sicherheit und CI-Kosten sind Produktionsthemen, auch wenn sie im Produkt unsichtbar sind.

Wie produktive Inferenz-Infrastruktur wirklich aussieht

Drei Dinge sind mir von innen aufgefallen.

Erstens: Die Prioritäts- und Speicherbudget-Logik ist das Produkt. Die Routing-Entscheidung ist der Ort, an dem Latenz und Kosten gewonnen oder verloren werden, nicht der Modellaufruf selbst.

Zweitens: Rückwärtskompatibilität ist heilig. Jede Änderung muss annehmen, dass ein Operator das alte Verhalten bereits produktiv betreibt. Neue Felder defaulten auf das vorherige Verhalten. Das Recht, Defaults zu ändern, verdient man sich langsam.

Drittens: Die Testsuite ist die Spezifikation. Reviewer bewerten das Feature nicht über die Beschreibung. Sie lesen die Tests, um zu verstehen, was man tatsächlich garantiert hat.

Warum ich das mache

Ich baue beruflich produktive Plattform- und Observability-Infrastruktur. Beiträge zu llm-d sind mein Weg, speziell an der Inferenz-Schicht zu arbeiten, in einer echten Codebasis, von der echte Operatoren abhängen, statt in einem Spielzeug.

Die gemergten PRs sind öffentlich: das Flow-Control-Prioritätsband-Feature, der CI-Hardening-Durchlauf und ein zweiter CI-Reliability-Durchlauf, mit weiteren offenen in llm-d-kv-cache und llm-d-benchmark.

Das Modell bekommt die Aufmerksamkeit. Die Routing-Schicht entscheidet, ob das System echten Traffic übersteht.