Kürzen Sie die Ausgaben für große Sprachmodelle mit einem LiteLLM-Token-Router

LiteLLM ist ein Open-Source-Gateway, das die Anfragesyntax von OpenAI an viele Anbieter weiterleitet. Es erfüllt mehrere Funktionen; dieser Artikel konzentriert sich auf die Modellrouteierung – dabei wird jede Anfrage an ein ausreichend günstiges Modell gesendet, damit der Tokenverbrauch unter Kontrolle bleibt.

Was eine Modellrouteur-Software leistet

Ein Router befindet sich zwischen Ihrer Anwendung und den Anbietern. Der Client authentifiziert sich weiterhin einmal beim Gateway. Das Gateway prüft jede Anfrage und wählt mithilfe einer von Ihnen definierten Richtlinie aus, welches upstream-Modell antworten soll. Man kann es als eine leichte Entscheidungsebene betrachten: Einfache Anfragen benötigen nicht das teuerste Modell.

Intuition zur tokenbasierten Routeierung

LiteLLM kann die Eingabetoken zählen, bevor es die Anfrage weiterleitet. Eine praktische Heuristik lautet:

• Kurze Aufgaben wie „eine Seite lesen und zusammenfassen“ → Haiku-Modellklasse
• Dichte Python-Codeblöcke, die tiefes Denken erfordern → Opus-Modellklasse

Alles in der Mitte → Sonnet-Klasse-Modelle

Dieses Muster ist tokenbasiertes Routing. Kurze Anfragen sind günstig; lange Anfragen teuer. Produktionsysteme fügen oft eine Intent-Klassifizierung hinzu, um eine höhere Genauigkeit zu erreichen, doch bereits die tokenbasierte Heuristik allein kann die Kosten um etwa dreißig Prozent senken.

Ohne Routing

Jede Anfrage landet bei einem einzigen, teuren Modell. Die Kosten steigen linear mit der Menge – es gibt keine Berücksichtigung der Schwierigkeit der Anfrage.

Mit Routing

Derselbe Traffic wird klassifiziert und auf verschiedene Ebenen verteilt. Die Entwickler rufen weiterhin eine einzige Gateway-URL auf; der Proxy entscheidet, welches gebührenpflichtige Modell tatsächlich ausgeführt wird.

Ein simulierter Monat mit Entwicklertraffic

Ich habe beide Konfigurationen mit LiteLLM getestet. Zunächst wurden alle Anfragen an Opus gesendet. Etwa siebenhundert Anfragen führten zu einer Rechnung von fast 60 $.

Dann habe ich den Router eingeschaltet. Opus erhielt nur Anfragen, deren Eingabetoken mehr als 300 betrug. Der benutzerdefinierte Logger, der diese Richtlinie umsetzt, sieht so aus:

from litellm.integrations.custom_logger import CustomLogger
import litellm
import random

class TokenRouter(CustomLogger):
    async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):
        # Skip routing for mock models - simulation handles model selection
        if "mock" in data.get("model", ""):
            return data

        # SMART ROUTING based on token complexity
        messages = data.get("messages", [])
        token_count = litellm.token_counter(
            model="gpt-3.5-turbo",
            messages=messages
        )

        if token_count < 50:
            data["model"] = "haiku"
            tier = "HAIKU  (5%)"
        elif token_count < 300:
            data["model"] = "sonnet"
            tier = "SONNET (30%)"
        else:
            data["model"] = "opus"
            tier = "OPUS   (65%)"

        print(f"[ROUTER] Tokens: {token_count} → {tier}")
        return data

proxy_handler_instance = TokenRouter()

Von 741 Anfragen erreichten 494 (etwa 66%) weiterhin Opus. Der Rest verteilte sich auf Sonnet und Haiku, wobei Haiku den kleinsten Anteil hatte. Die Rechnung für eine vergleichbare Arbeitslast sank auf 43 $ – es gab keine Veränderung in der Art und Weise, wie Entwickler Anfragen formulieren.

Fazit aus den Zahlen

• 741 Anfragen – ein realistischer Monatsverbrauch für Entwickler
• 60 $ als Basiswert – Opus für alles
• 43 $ mit Routing – dieselbe Arbeit, intelligantere Auswahl
• ~28 % Ersparnis – ausschließlich am Proxy, für die Kunden unsichtbar

Die Einsparungen steigen, je mehr Ingenieure hinzugefügt werden, je teurere Modelle eingesetzt werden und je höher die Token-Mengen sind. Nicht jede Anfrage erfordert das leistungsstärkste Modell aus dem Katalog.

LiteLLMs Router kümmert sich leise und effizient darum. Die Ingenieure behalten den gleichen OpenAI-ähnlichen Client; die Finanzabteilung erhält eine kleinere Rechnung.

Die hier verwendeten Benchmarks basieren auf LiteLLM v1.98 lokal mit Ollama-Alternativen sowie den Listenpreisen von Anthropic zur Kostenermittlung. Die tatsächlichen Einsparungen hängen davon ab, wie sich Ihre Anfragekombinationen nach Schwierigkeitsgrad verteilen.