Typ: Web Article
Originallink: https://manifest.build/blog/why-we-deprecated-our-llm-router/
Veröffentlichungsdatum: 2026-07-30
Autor: Bruno Perez
Zusammenfassung #
Einleitung #
Stellen Sie sich vor, Sie bauen ein System, das automatisch das wirtschaftlichste KI-Modell für jede Anfrage auswählt. Das klingt auf dem Papier perfekt: Warum für GPT-4 bezahlen, wenn Claude 3 Haiku ausreichen könnte? Genau das tun viele Unternehmen derzeit und starten ausgefeilte LLM-Router, die drastische Einsparungen bei den Inferenzkosten versprechen. Aber es gibt ein Problem: Manifest, eine Plattform, die ihren Router im März 2026 gebaut und gestartet hat, hat sich entschieden, ihn nach nur vier Monaten vollständig zu deprecaten. Ihre Schlussfolgerung ist überraschend und kontraintuitiv: Für die meisten Anwendungsfälle ist intelligentes Routing nicht die Lösung, die es zu sein scheint. Dieser Kurswechsel bietet eine wichtige Lektion für alle, die diese Technologie implementieren möchten.
Worum es geht #
Der Artikel von Bruno Perez erzählt die Geschichte hinter einer schwierigen Entscheidung: Warum Manifest ein Feature abgebaut hat, das als zentral für ihr LLM Gateway präsentiert worden war. Ihr Router klassifizierte jede Anfrage in vier Komplexitätsstufen (einfach, standard, komplex und reasoning), um sie an das passende Modell weiterzuleiten. Das klingt logisch, aber nach vier Monaten Nutzung durch Tausende von Cloud-Nutzern entdeckte das Team, dass die versprochenen Vorteile nicht wie erwartet eintraten. Statt die Gesamtkosten zu senken, verursachte das Routing versteckte Probleme, die die offensichtlichen Einsparungen aufzehrten.
Warum es relevant ist #
Die Relevanz dieser Geschichte geht weit über Manifest hinaus. Während der Markt für LLM-Router mit neuen Playern explodiert, die erhebliche Einsparungen versprechen, zeigt diese reale Erfahrung, dass die Realität viel komplexer ist als sie scheint.
Das erste Problem ist grundlegend: Die Komplexität einer Aufgabe kann nicht allein aus dem Prompt abgeleitet werden. Wenn Sie ein Modell bitten, “Tests eines Repositories zu bewerten und zu verbessern”, hängt der tatsächliche Schwierigkeitsgrad von Faktoren ab, die sich erst während der Ausführung zeigen: ob das Repo eine einfache HTML-Website oder der Linux-Kernel ist. Der Router trifft die Entscheidung im Dunkeln, basierend auf unvollständigen Informationen.
Der zweite Aspekt ist wirtschaftlich, aber kontraintuitiv: Caching ist viel effektiver als Routing, um Kosten zu senken. Cache-Lesevorgänge kosten zwischen 90% und 95% weniger als nicht gecachte Eingaben. Wenn ein Router “Stickiness” mit demselben Modell beibehält, um das Caching von System-Prompts und Gesprächsverlauf zu nutzen, endet er damit, gar kein Routing zu betreiben. Mit anderen Worten: Der Router erreicht wirtschaftliche Effizienz, indem er aufhört, seine Hauptaufgabe zu erfüllen.
Das dritte Problem ist qualitativ: Routing bricht die Verhaltenskohärenz. Der Wechsel zwischen Modellen während einer Arbeitssitzung verschlechtert die Gesamtqualität und entfernt Ingenieure davon, ihre Werkzeuge zu beherrschen. Es ist, als würde man einen Maler bitten, mitten im Werk den Pinsel zu wechseln, weil einer billiger ist.
Praktische Anwendungen #
Diese Lektion ist besonders relevant, wenn Sie agentic Systeme oder automatisierte Workflows bauen. Wenn Sie eine Unsicherheitsebene beim Routing hinzufügen, wird alles schwieriger zu warten: die Evals, die System-Prompts, die Observability. Jedes Mal, wenn Sie nicht wissen, welches Modell eine Anfrage bearbeitet hat, wird es komplexer, anomales Verhalten zu debuggen oder Performance zu optimieren.
Für die meisten Teams ist die beste Strategie, bewusst ein bewährtes Modell auszuwählen und darum herum zu bauen. Das bedeutet, Zeit zu investieren, um die Trade-offs zwischen verfügbaren Modellen zu verstehen, genau wie ein Handwerker genau weiß, welches Werkzeug er verwenden soll. Wenn Kosten ein Problem sind, sollte der Fokus auf intelligenten Caching-Strategien und Prompt-Optimierung liegen, nicht auf dynamischem Routing.
Abschließende Gedanken #
Die Erfahrung von Manifest stellt einen Reifegrad im LLM-Sektor dar. Nicht alles, das auf dem Papier effizient aussieht, ist es auch in der Praxis. LLM-Routing wird wahrscheinlich legitime Anwendungsfälle haben, ist aber nicht die universelle Lösung, die das Marketing der Branche suggeriert. Die echte Lektion ist, dass Vereinfachung oft ausgefeilte Automatisierung schlägt, wenn die versteckten Kosten der Automatisierung höher sind als der offensichtliche Nutzen. In einem Ökosystem, in dem sich Modelle schnell entwickeln und Kosten ständig ändern, könnte Kontrolle und Vorhersehbarkeit viel mehr wert sein als ein paar Prozent wirtschaftliche Einsparungen.
Anwendungsfälle #
- Private AI Stack: Integration in proprietäre Pipelines
- Client Solutions: Implementierung für Kundenprojekte
Ressourcen #
Originallinks #
- Everyone is building LLM routers, we deprecated ours - Originallink
Artikel gemeldet und ausgewählt vom Team Human Technology eXcellence, verarbeitet durch künstliche Intelligenz (in diesem Fall mit LLM HTX-EU-Claude-Haiku-4.5) am 2026-08-18 08:11 Originalquelle: https://manifest.build/blog/why-we-deprecated-our-llm-router/
Verwandte Artikel #
- Nativ — Führen Sie KI lokal auf Ihrem Mac aus - Foundation Model, LLM, Computer Vision
- LLM-Gedächtnis neu denken: Die Nutzung von Kontext als Trainingsdaten entsperrt Modelle, die im Testzeitpunkt lernen - Natural Language Processing, AI, Foundation Model
- PrismML — Intelligenz bündeln - Foundation Model, Machine Learning, AI