NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grüne Weiche mit Schild LLM ROUTING, ein Gleis teilt sich in zwei Wege

Was ist LLM Routing?

LLM Routing heißt, pro Anfrage zu entscheiden, welches Modell antwortet. Eine einfache Frage geht an ein kleines lokales Modell, eine komplexe Analyse an das große. Der Router sitzt vor den Modellen und trifft diese Entscheidung automatisch, statt sie im Code festzuschreiben.
Der Unterschied zu einem LLM Gateway ist wichtig. Das Gateway regelt den Zugang: Schlüssel, Budgets, Protokollierung. Der Router regelt die Auswahl. Beides zusammen ergibt erst den vollen Nutzen, aber es sind zwei Bauteile.
Zwei Projekte prägen das Thema. RouteLLM aus dem Forschungsumfeld von LMSYS und Berkeley und der vLLM Semantic Router, den vor allem Red Hat vorantreibt.
Inhalt
NCA KI Workshop für alle Abteilungen

KI für das ganze Team an einem Tag

Ein Tag inhouse, ohne Vorkenntnisse, mit Live Demo und Live Coding. Am Ende steht ein eigenes kleines Tool statt einer Demo App.

  1. 1
    Kostenloses Vorgespräch
    Aufgaben und Teams klären
  2. 2
    Workshoptag bei euch
    Live Demo, danach gemeinsam bauen
  3. 3
    Praxistag optional
    KI an eigenen Aufgaben einsetzen
Roland Golla
Roland Golla
Fullstack Developer
Zum Workshop für alle Abteilungen arrow_forward

LLM Routing mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet aus Duisburg heraus an Softwarequalität und KI gestützter Entwicklung. Wir betreiben lokale Modelle auf eigenen Servern in Deutschland und kennen die Frage, welche Aufgaben ein kleines Modell wirklich schafft. Diese Grenze zu finden ist Messarbeit, keine Meinungsfrage.
Routing ist der Punkt, an dem Kostenkontrolle und Datenschutz zusammenfallen. Was ein lokales Modell beantwortet, verlässt das eigene Netz nicht und kostet nichts extra. Beide Effekte hängen an derselben Entscheidung.
Passend dazu beraten wir im Vibe Coding Consulting, richten AI Coding Guidelines für PHP Projekte ein, bauen CI CD Pipelines für KI Code und begleiten den Weg zu Self Hosted KI im Unternehmen mit Mandantentrennung. Für gehostete Inferenz kommt unser Duisburger Netzwerkpartner Conversis dazu.

Warum Routing der größte Kostenhebel ist

Die meisten Teams schicken jede Anfrage an dasselbe teure Modell. Egal ob jemand nach einer Definition fragt oder eine Architektur bewerten lässt. Die Rechnung wächst dann mit der Nutzung, obwohl der größte Teil der Anfragen einfach ist.
Genau da setzt Routing an. Die schwierigen Anfragen bekommen weiter das starke Modell, der Rest geht an ein günstiges oder lokales. Der Effekt ist unmittelbar sichtbar, weil er an der Menge hängt und nicht an einem ausgehandelten Preis.
Wichtig ist die Reihenfolge. Erst messen, wohin die Token gehen, dann routen. Wer ohne Zahlen anfängt, optimiert die falsche Hälfte. Mehr dazu unter weniger Tokens brauchen und lokale KI wirtschaftlich.

RouteLLM und Semantic Router im Vergleich

Projekt Ansatz Reifegrad
RouteLLM Klassifikatoren auf Präferenzdaten aus der Chatbot Arena, starkes gegen schwaches Modell Forschungsframework mit OpenAI kompatiblem Server
vLLM Semantic Router Signalgetriebenes Routing über einen Pool aus vielen Modellen, Caching und Klassifikatoren Aktiv entwickelt, Version 0.3 seit Juni 2026
Betrieb RouteLLM als Bibliothek oder Server, Semantic Router als Envoy Erweiterung über ext_proc Semantic Router passt in Kubernetes Setups
Einsatz bei NCA Wir ordnen beide ein und messen gegen echten Verkehr, statt Benchmarks zu übernehmen Editorial, kein Standard in unserem Stack

RouteLLM: die Forschungsseite

RouteLLM kommt von LMSYS, dem Team hinter der Chatbot Arena, zusammen mit Berkeley. Der Ansatz ist wissenschaftlich sauber: Klassifikatoren lernen aus menschlichen Präferenzvergleichen, welche Anfrage ein starkes Modell braucht und welche nicht.
Mehrere Architekturen stehen zur Wahl, unter anderem Matrixfaktorisierung und BERT basierte Klassifikatoren. Ein OpenAI kompatibler Server liegt bei, damit sich das Ganze in bestehende Clients einhängen lässt. Trainingsdaten und Methodik sind offengelegt.
Die veröffentlichten Ergebnisse zeigen deutliche Einsparungen bei geringem Qualitätsverlust auf den eigenen Benchmarks. Genau das ist aber auch die Einschränkung. Die Zahlen stammen aus einer Bewertungsumgebung, nicht aus eurem Verkehr. Wer RouteLLM einsetzt, sollte den Effekt auf den eigenen Anfragen nachmessen.
Für Production fehlt drumherum einiges. Kein Proxy mit Ausfallsicherung, keine Schlüsselverwaltung, keine Verbrauchszählung. Das übernimmt ein Gateway wie LiteLLM.

RouteLLM einrichten: Befehle und Parameter

Die Installation ist unspektakulär, die Arbeit steckt in den Parametern. Interessant für uns ist der Fall, in dem das schwache Modell lokal über Ollama läuft und nur die schweren Anfragen nach außen gehen.
Code: 
          
pip install "routellm[serve,eval]"

# OpenAI kompatibler Server, schwaches Modell lokal ueber Ollama
python -m routellm.openai_server \
  --routers mf \
  --strong-model gpt-4-1106-preview \
  --weak-model ollama_chat/llama3 \
  --config config.example.yaml
Der Parameter --routers wählt die Strategie. mf steht für Matrixfaktorisierung und ist der Standard. Alternativ gibt es unter anderem bert und sw_ranking. Für die Einbettungen der Router mf und sw_ranking wird weiterhin ein OpenAI Schlüssel gebraucht, auch wenn beide Modelle lokal laufen.
Der wichtigste Parameter steht nicht auf der Kommandozeile, sondern im Feld model der Anfrage. Die Zahl dahinter ist die Kostenschwelle:
Code: 
          
from routellm.controller import Controller

client = Controller(
    routers=["mf"],
    strong_model="gpt-4-1106-preview",
    weak_model="ollama_chat/llama3",
)

response = client.chat.completions.create(
    # mf Router mit Kostenschwelle 0.11593
    model="router-mf-0.11593",
    messages=[{"role": "user", "content": "Hallo"}],
)
Diese Schwelle ratet ihr nicht, ihr kalibriert sie. Der mitgelieferte Befehl rechnet aus, welcher Wert dazu führt, dass ein gewünschter Anteil der Anfragen beim starken Modell landet:
Code: 
          
# Schwelle so setzen, dass 20 Prozent ans starke Modell gehen
python -m routellm.calibrate_threshold \
  --routers mf \
  --strong-model-pct 0.2 \
  --config config.example.yaml
Genau hier liegt der Hebel im Alltag. Ihr dreht an einer einzigen Zahl und verschiebt damit das Verhältnis von Kosten zu Qualität. Kalibriert wird ab Werk gegen einen öffentlichen Datensatz aus der Chatbot Arena. Besser ist eine Stichprobe aus eurem eigenen Verkehr, weil eure Anfragen anders verteilt sind.

vLLM Semantic Router: die Produktionsseite

Der vLLM Semantic Router stammt aus dem Umfeld der Inference Engine vLLM und wird stark von Red Hat vorangetrieben. Statt nur zwischen stark und schwach zu unterscheiden, verteilt er Anfragen über einen ganzen Pool aus Modellen.
Die Entwicklung läuft schnell. Version 0.1 erschien im Januar 2026, Version 0.2 im März, Version 0.3 im Juni. Dazu kamen semantisches Caching, Klassifikatoren für Halluzinationserkennung und Sicherheitsprüfungen sowie Zusammenarbeit mit AMD und NVIDIA.
Betrieblich passt der Router in dieselbe Welt wie das Envoy AI Gateway, weil er als Envoy Erweiterung über ext_proc läuft. Wer Kubernetes hat, bekommt Gateway und Router aus einem Guss.
Die Versionsnummer sagt trotzdem etwas. Unter 1.0 gibt es keine Zusage zu stabilen Schnittstellen. Für Experimente und messbare Einsparungen reicht das, für eine kritische Kette braucht es einen Plan für Upgrades.

Semantic Router einrichten: Befehle und Parameter

Seit Version 0.3 gibt es ein CLI namens vllm-sr und eine einzige kanonische Konfigurationsdatei. Ein Dashboard läuft auf Port 8700, der Envoy Listener nimmt Anfragen standardmäßig auf Port 8899 entgegen.
Code: 
          
pip install vllm-sr

# Konfiguration pruefen, bevor irgendwas startet
vllm-sr validate config.yaml

# Router starten
vllm-sr serve --config config.yaml

# welche Modelle kennt die aktive Konfiguration
vllm-sr model list
Der Befehl validate ist der wichtigste im Alltag. Eine kaputte Kategorie fällt sonst erst auf, wenn Anfragen falsch geroutet werden, und das merkt niemand sofort. Ein Testaufruf geht anschließend gegen den Envoy Port, mit einem virtuellen Modellnamen statt eines konkreten Modells:
Code: 
          
curl -s http://localhost:8899/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"vllm-sr/auto","messages":[{"role":"user","content":"Hallo"}]}'
Die eigentliche Steuerung sitzt in der Konfiguration. Kategorien bekommen Modelle mit einer Bewertung zwischen 0 und 1, dazu optional einen eigenen System Prompt und die Angabe, ob überhaupt gedacht werden muss:
Code: 
          
categories:
  - name: code_generation
    system_prompt: "Du bist ein erfahrener Entwickler."
    use_reasoning: true
    reasoning_effort: "medium"
    model_scores:
      - model: qwen3
        score: 0.9
  - name: general
    use_reasoning: false
    model_scores:
      - model: qwen3
        score: 0.5
Zwei Parameter lohnen besondere Aufmerksamkeit. use_reasoning entscheidet, ob eine Kategorie überhaupt ein denkendes Modell braucht, und spart bei einfachen Anfragen den größten Teil der Token. semantic_cache_similarity_threshold lässt sich pro Kategorie setzen: bei Support Anfragen darf der Wert niedrig sein, bei sensiblen Themen gehört er hoch, damit knapp ähnliche Fragen nicht dieselbe Antwort bekommen.
Ein Detail für Umsteiger: der frühere Befehl vllm-sr init wurde mit Version 0.3 entfernt. Die Konfiguration wird von Hand geschrieben oder über das Dashboard importiert. Für lokale Versuche liegt eine vollständige Docker Compose Umgebung im Repository, inklusive Envoy und Observability.

Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk

Routing ist mehr als eine Kostenfrage. Wenn ein lokales Modell eine Anfrage beantworten kann, verlässt der Inhalt das eigene Netz nicht. Die Routing Regel wird damit auch zur Datenschutzregel.
In der Praxis heißt das bei uns: Anfragen mit echten Daten laufen auf lokale Modelle über Ollama oder vLLM. Große Coding Modelle arbeiten gegen Entwicklungsumgebungen mit Fake Daten. Welche Modelle sich lokal wirklich lohnen, steht unter beste Coder Modelle für lokale Nutzung.
Für europäische Inferenz nutzen wir TensorX mit OpenAI kompatibler API und Zero Data Retention. Die rechtliche Einordnung steht bei lokale KI für Compliance.

Wann Routing lohnt und wann es schadet

Routing lohnt bei hohem Volumen mit gemischter Schwierigkeit. Chatbots, Suchoberflächen, Massenauswertungen, Klassifikation von Dokumenten. Überall dort ist der Anteil einfacher Anfragen groß, und der Router zahlt sich schnell aus.
Routing schadet bei Coding Agenten. Ein Agent hält Kontext über viele Schritte, und ein Modellwechsel mitten in der Aufgabe bricht diesen Faden. Ein billiges Modell, das eine Migration halb versteht, kostet am Ende mehr Zeit als das teure Modell an Geld gespart hätte.
Der Fehler, den wir am häufigsten sehen: Routing wird eingeführt, ohne die Qualität danach zu messen. Dann sinken die Kosten sichtbar und die Ergebnisse unsichtbar. Wer routet, braucht ein Auge auf beiden Zahlen, am besten über Langfuse.
Einen verwandten Ansatz aus dem NVIDIA Umfeld beschreiben wir bei NeMo Switchyard.

Simply put, not all prompts require the same level of reasoning.

– Red Hat Blog zum vLLM Semantic Router

LLM Routing in der NCA Praxis

Wir bauen Routing nie als ersten Schritt. Zuerst kommt ein Gateway vor die Modelle, damit sichtbar wird, wer was verbraucht. Danach schauen wir uns an, welche Anfragen sich häufen und wie schwer sie wirklich sind.
Dann läuft ein Vergleich gegen echten Verkehr: dieselben Anfragen einmal an das große Modell, einmal an ein lokales über Ollama. Wo die Antworten gleich gut sind, wandert die Route dauerhaft nach unten. Wo nicht, bleibt sie oben.
Modelle wie Qwen decken dabei einen großen Teil der einfachen Aufgaben ab. Wie groß der Aufwand wird, hängt an eurem Anfragemix und daran, wie sauber die Messung schon läuft. Wir schauen uns das an, schätzen den Aufwand und rechnen minutengenau ab. Feste Pakete gibt es nicht, ein Kennenlernen kostet nichts.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu LLM Routing

Die Fragen aus Projekten und Workshops, kurz beantwortet.
Was ist LLM Routing 2026?

Die Entscheidung, welches Modell eine einzelne Anfrage beantwortet. Ein Router schätzt die Schwierigkeit und leitet einfache Anfragen an ein günstiges oder lokales Modell, schwere an das starke. Ziel ist, Kosten zu senken, ohne die Qualität dort zu verlieren, wo sie gebraucht wird.

Was ist 2026 der Unterschied zwischen Router und Gateway?

Ein Gateway regelt den Zugang: Schlüssel, Budgets, Fallback, Protokollierung, einheitliche API. Ein Router regelt nur die Modellauswahl pro Anfrage. Die meisten Teams brauchen zuerst das Gateway, weil es Transparenz schafft. Der Router kommt danach, wenn klar ist, wohin die Kosten fließen.

Wie viel spart Routing 2026 wirklich?

Das hängt vollständig am Anfragemix. Die veröffentlichten Zahlen der Projekte stammen aus eigenen Benchmarks und lassen sich nicht übertragen. Bei Chatbots mit vielen einfachen Fragen ist der Effekt groß, bei Coding Agenten gering bis negativ. Messen auf dem eigenen Verkehr ist der einzige verlässliche Weg.

Ist RouteLLM 2026 produktionsreif?

Es ist ein Forschungsframework mit einem OpenAI kompatiblen Server, kein fertiges Produkt. Ausfallsicherung, Schlüsselverwaltung und Verbrauchszählung fehlen und müssen von einem Gateway kommen. Für Teams mit Engineering Kapazität ist es trotzdem ein solider Ausgangspunkt, weil Methodik und Trainingsdaten offenliegen.

Welchen Reifegrad hat der Semantic Router 2026?

Version 0.1 erschien im Januar 2026, Version 0.3 im Juni. Die Entwicklung ist schnell und wird von Red Hat getragen, eine stabile Schnittstellenzusage gibt es unterhalb von Version 1.0 aber nicht. Für Experimente und messbare Einsparungen reicht das, für kritische Ketten braucht es einen Upgrade Plan.

Kann ich Routing mit lokalen Modellen kombinieren?

Genau dafür lohnt es sich am meisten. Was ein lokales Modell beantwortet, kostet nichts extra und verlässt das eigene Netz nicht. Bei uns ist die günstige Stufe deshalb kein billiger Cloud Anbieter, sondern ein Modell über Ollama oder vLLM auf eigener Hardware.

Woher weiß der Router, welche Anfrage schwer ist?

Über Klassifikatoren. RouteLLM trainiert sie auf menschlichen Präferenzvergleichen aus der Chatbot Arena. Der Semantic Router arbeitet signalgetrieben mit Embeddings und weiteren Klassifikatoren, etwa für Sicherheit oder Faktenprüfung. In beiden Fällen ist es eine Schätzung, keine Garantie.

Was passiert, wenn der Router falsch entscheidet?

Dann bekommt eine schwere Anfrage ein zu kleines Modell und die Antwort wird schlechter, ohne dass jemand es merkt. Genau das ist das Hauptrisiko. Deshalb gehört zu jedem Routing eine Qualitätsmessung und ein Weg, einzelne Fälle wieder an das starke Modell zu schicken.

Brauche ich Kubernetes für Routing?

Nicht zwingend. RouteLLM läuft als Bibliothek oder als eigener Server. Der vLLM Semantic Router entfaltet seine Stärken dagegen als Envoy Erweiterung und passt damit in Cluster Setups, gerne zusammen mit dem Envoy AI Gateway. Ohne Cluster ist der Aufwand höher als der Nutzen.

Lohnt sich Routing für Coding Agenten?

Meistens nicht. Ein Agent hält Kontext über viele Schritte, und ein Modellwechsel mitten in der Aufgabe bricht diesen Faden. Die vermeintliche Ersparnis kippt schnell, wenn Ergebnisse nachgearbeitet werden müssen. Bei Massenauswertungen und Klassifikation ist das Bild umgekehrt.

Setzt Never Code Alone Router selbst ein?

Wir ordnen beide Projekte ein und prüfen sie gegen echten Verkehr, führen sie aber nicht als festen Bestandteil unseres Stacks. Unser Standard ist ein Gateway vor lokalen und externen Modellen. Routing kommt dazu, wenn die Zahlen zeigen, dass es sich rechnet.

Wie geht Never Code Alone bei der Einführung vor?

Zuerst Transparenz über ein Gateway, dann ein Vergleich derselben Anfragen gegen ein lokales Modell, danach Routen festlegen und Qualität weiter messen. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand und rechnen minutengenau ab. Feste Pakete gibt es nicht.