Strategien für die Modell-Routing-Logik bei lokalen Modellen

Mit Tokios lassen sich mehrere Modelle bereitstellen; jedes erhält dabei einen eigenen öffentlichen Namen. Durch Ändern des model-Feldes in der Anfrage erfolgt die Weiterleitung zwischen den Modellen. Der Endpunkt sowie der API-Schlüssel bleiben unverändert; lediglich der Wert von model variiert.

Funktionsweise des Routings

Jede Deployment verfügt über einen eindeutigen öffentlichen Namen. Empfängt Tokios eine Anfrage, liest es das model-Feld, sucht das passende Deployment anhand dieses Namens, ersetzt es durch die zugehörige Upstream-Modell-ID und leitet die Anfrage anschließend durch den Connector weiter. Die Client-Konfiguration bleibt unverändert – lediglich der Wert von model ändert sich.

Ein Connector für mehrere Modelle

Ein einziger Connector kann mehrere Modelle bedienen. Listen Sie dazu alle Upstream-Modell-IDs in Routes auf und ordnen Sie sie den jeweiligen lokalen Bezeichnungen in Upstreams zu:

tokios-connector.json

{
  "Connector": {
    "ConnectorId": "con_...",
    "Token": "ct-...",
    "Routes": [
      { "Model": "gemma4:e4b",    "UpstreamId": "ollama" },
      { "Model": "qwen2.5-coder", "UpstreamId": "lmstudio" }
    ],
    "Upstreams": {
      "ollama":   { "BaseUrl": "http://127.0.0.1:11434/v1" },
      "lmstudio": { "BaseUrl": "http://127.0.0.1:1234/v1" }
    }
  }
}

Anschließend erstellen Sie im Dashboard für jedes Modell eine Deployment, wobei jedes einen öffentlichen Namen erhält (zum Beispiel gemma-tunnel → gemma4:e4b sowie qwen-coder → qwen2.5-coder); alle verweisen auf denselben Connector.

Möchten Sie die Modelle getrennt halten? In diesem Fall können Sie auch für jedes Modell einen eigenen Connector einrichten, jeweils mit eigenen Werten für ConnectorId, Token und Upstream. Beide Varianten sind nutzbar – der Server sendet stets lediglich die jeweilige Modell-ID durch den Tunnel.

Modellwechsel in Anfragen

Sobald beide Deployments registriert sind, lässt sich das Modell durch Ändern des model-Feldes problemlos wechseln.

# Use the Gemma model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Hello"}]}'

# Use the Qwen model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen-coder", "messages": [{"role": "user", "content": "Hello"}]}'

Der Endpunkt, der Autorisierungs-Header sowie sämtliche weitere Parameter bleiben unverändert. Tokios übernimmt die Verteilung der Anfragen.

Wechseln Sie das Backend ohne Änderungen an den Clients vorzunehmen.

Da die Clients lediglich den öffentlichen Namen des Modells verwenden, lässt sich ein Modell problemlos auf andere Hardware oder ein anderes Backend verschieben, ohne dass Konfigurationen angepasst werden müssen: Ändern Sie einfach die Deployment-Einstellungen (oder die Upstream-Modell-ID des Connectors) so, dass sie auf den neuen Server verweisen, behalten Sie den gleichen öffentlichen Namen bei – bereits laufende Anfragen funktionieren weiterhin einwandfrei.

Routing-Strategien

Wenn mehrere lokale Modelle betrieben werden, wäre es ressourcenverschwendend, jede Anfrage an dasselbe Modell zu senden. Für Programmieraufgaben ist kein 120B Reasoning-Modell erforderlich; für einfache Klassifizierungen braucht man kein 70B Dichte-Modell. Durch Routing lässt sich jede Anfrage an das für sie am besten geeignete Modell leiten – so lässt sich Geschwindigkeit, Qualität oder Kosten je nach Anforderung optimieren. Die Nutzung ausschließlich eines einzigen 1 Modells für alle Aufgaben erfordert stets Kompromisse: Große Modelle bewältigen jede Aufgabe gut, reagieren jedoch langsam und verbrauchen viel VRAM. Kleine Modelle antworten schnell, haben aber Schwierigkeiten bei komplexen logischen Überlegungen. Routing ermöglicht den Einsatz beider Typen:

Geschwindigkeit: Einfache Anfragen werden an kleine, schnelle Modelle gesendet; komplexe Aufgaben an große Modelle.
Qualität: Programmieraufgaben werden an spezialisierte Code-Modelle geleitet; allgemeine Gespräche an allgemein einsetzbare Modelle.
Kosten: Kleinere Modelle verbrauchen weniger Energie und VRAM, wodurch mehr Kapazität für anspruchsvolle Aufgaben bleibt.
Ausfallsicherheit: Sollte das primäre Modell belegt oder nicht verfügbar sein, werden Anfragen automatisch an ein Backup-Modell weitergeleitet.

Ein Modell pro Deployment

Der einfachste Ansatz besteht darin, jedes Modell als eigenständiges Tokios-Deployment zu registrieren und dem Client die Auswahl zu überlassen, indem er lediglich das model Feld anpasst.

tokios-connector.json

{
  "Connector": {
    "Routes": [
      { "Model": "qwen3-coder", "UpstreamId": "ollama" },
      { "Model": "gemma-tunnel", "UpstreamId": "ollama" }
    ],
    "Upstreams": {
      "ollama": { "BaseUrl": "http://127.0.0.1:11434/v1" }
    }
  }
}

Ihr Client sendet Anfragen mit dem passenden model-Wert.

# Code task → code model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3-coder", "messages": [{"role": "user", "content": "Write a Python function to sort a list"}]}'

# General chat → general model
curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gemma-tunnel", "messages": [{"role": "user", "content": "Summarize this article"}]}'

Anwendungsfall: Sie führen 2–3-Modelle aus, und Ihre Anwendung entscheidet, welches Modell aufgerufen wird. Dies ist der häufigste Ausgangspunkt.

Routing basierend auf Aufgabentypen

Nach Art der Aufgabe routen: Programmieranfragen an ein spezialisiertes Code-Modell, Gespräche an ein allgemeines Modell sowie komplexe logische Aufgaben an ein leistungsstarkes Modell. Der Client bzw. eine Middleware-Ebene prüft die Anfrage und wählt die passende Deployment-Instanz aus.

Art der Aufgabe	Empfohlene Modellklasse	Beispielhafte Deployment-Konfiguration	Begründung
Erstellung und Umgestaltung von Code	Spezialisiert auf Programmierung	Qwen3-Coder-30B, betrieben über vLLM	Speziell für Programmieraufgaben trainiert; überzeugt durch präzise Syntax und logische Strukturen
Allgemeine Gespräche sowie Zusammenfassungen	MoE (35B–122B)	Qwen3.5-35B-A3B auf Atlas	Hohe Durchsatzrate; 3B aktive Parameter pro Token
Komplexes logisches Denken sowie mathematische Aufgaben	Dichte Architektur mit 70B+ Elementen	Qwen3-32B bzw. 70B auf vLLM	Bessere Qualität bei mehrstufigen logischen Abläufen
Aufruf externer Werkzeuge sowie Agenten	Modell, das Werkzeuge nutzen kann	GLM-4.5-Air auf vLLM	Ausgezeichnete Unterstützung beim Aufruf von Funktionen
Vision – multimodal	Multimodales Modell	Qwen3-VL in Kombination mit vLLM	Verarbeitet Bilddaten direkt ohne zusätzliche Konfiguration

Die einfachste Umsetzung erfolgt direkt im Anwendungscode: Prüfen Sie den Anfragetyp und wählen Sie anschließend den passenden Deployment-Namen aus.

def select_model(task_type: str) -> str:
    routing = {
        "code": "qwen3-coder",
        "chat": "gemma-tunnel",
        "reasoning": "glm-4-chat",
        "vision": "qwen3-vl",
    }
    return routing.get(task_type, "gemma-tunnel")

Für komplexere Routing-Logiken empfiehlt sich ein Gateway wie LiteLLM oder OpenRouter, welches Anfragen analysiert und gemäß konfigurierbaren Regeln an das zuständige Backend weiterleitet.

Routing auf Gateway-Ebene

Setzen Sie ein Routing-Proxy zwischen Ihre Clients und Tokios ein. Dieses Proxy bestimmt anhand von Anfrage-Attributen, Auslastung oder individuellen Regeln, welches Tokios-Deployment genutzt wird.LiteLLM kann mehrere Tokios-Deployments verwalten und Anfragen basierend auf Modell-Aliasen weiterleiten.

litellm_config.yaml

model_list:
  - model_name: gpt-4  # alias
    litellm_params:
      model: openai/qwen3-coder  # Tokios deployment
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY
  - model_name: gpt-4
    litellm_params:
      model: openai/gemma-tunnel  # fallback
      api_base: https://api.tokios.com/v1
      api_key: sk-tok-YOUR_KEY

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2

Clients senden Anfragen an das LiteLLM-Proxy unter Verwendung des Alias gpt-4; das Proxy leitet diese anschließend an das entsprechende Tokios-Deployment weiter.OpenRouter unterstützt Modell-Fallback sowie Lastverteilung über mehrere Anbieter. Registrieren Sie Ihren Tokios-Endpunkt als eigenen Anbieter und konfigurieren Sie die Routing-Regeln im OpenRouter-Dashboard.

Fallback-Ketten

Konfigurieren Sie ein primäres Modell sowie 1 oder mehr Fallback-Modelle. Sollte das primäre Modell belegt, offline oder fehlerhaft sein, wird die Anfrage an das nächste Modell in der Kette weitergeleitet.

import requests

FALLBACK_MODELS = ["qwen3-coder", "gemma-tunnel", "qwen3-32b"]

def chat_with_fallback(prompt: str) -> str:
    for model in FALLBACK_MODELS:
        try:
            response = requests.post(
                "https://api.tokios.com/v1/chat/completions",
                headers={
                    "Authorization": "Bearer sk-tok-YOUR_KEY",
                    "Content-Type": "application/json"
                },
                json={"model": model, "messages": [{"role": "user", "content": prompt}]},
                timeout=30
            )
            response.raise_for_status()
            return response.json()["choices"][0]["message"]["content"]
        except (requests.RequestException, KeyError):
            continue
    raise RuntimeError("All models failed")

Die Tokios-Connector melden ihren Status an das Gateway. Wird ein Connector offline, erhalten Anfragen an die entsprechenden Deployments die Antwort 503. Ihre Anwendung kann dies erkennen und die Anfrage mit einem anderen Deployment erneut senden; alternativ lässt sich ein Gateway wie LiteLLM einrichten, das den Fallback automatisch übernimmt.

Routen basierend auf Kosten

Leiten Sie einfache Anfragen mit hohem Volumen an ein kleineres, kostengünstigeres Modell weiter und reservieren Sie das große Modell für anspruchsvollere Aufgaben.

Art der Anfrage	Ziel der Routung	Begründung
Klassifizierung und Extraktion	MoE mit 3 bis 4B aktiven Parametern	Schnell; geringer Rechenaufwand pro Token
Zusammenfassung (kurz)	7B bis 14B dichte oder MoE-Modelle	Angemessene Qualität sowie schnelle Reaktionszeiten
Komplexes logisches Schlussfolgern	32B mit dichter Architektur oder 122B mit MoE-Technologie	Höhere Qualität bei Aufgaben mit mehreren Schritten
Code-Generierung	Modell, das speziell für Code-Generierung optimiert ist	Bessere Ergebnisse bei begrenztem Token-Budget

Diese Strategie verringert den Gesamtbedarf an Rechenleistung und Energieverbrauch – ein wichtiger Aspekt bei der Nutzung auf Consumer-Hardware, bei der VRAM und Leistungsaufnahme begrenzt sind.

Entscheidungsmatrix

Strategie	Komplexität	Am besten geeignet für	Wann ist die Verwendung sinnvoll?
Ein Modell pro Deployment	Gering	Erste Schritte: 2–3 Modelle	Sie entscheiden selbst, welches Modell im Anwendungscode aufgerufen wird.
Routen basierend auf Aufgaben	Mittel	Programmierung, Chat sowie logisches Schlussfolgern	Für verschiedene Aufgabentypen benötigen Sie unterschiedliche Modelle.
Routen auf Gateway-Ebene	Hoch	Mehrere Clients, gemeinsame Infrastruktur	Sie benötigen zentrale Routing-Regeln, ohne den Client-Code ändern zu müssen
Fallback-Ketten	Mittel	Hohe Verfügbarkeit	Ihr primäres Modell könnte offline gehen oder an seine Konkurrenzgrenzen stoßen
Kostenbasiertes Routing	Mittel	Hohes Aufkommen an gemischten Arbeitslasten	Sie möchten die Rechenkosten minimieren, indem einfache Aufgaben an kleinere Modelle gesendet werden

Diese Strategien schließen sich nicht gegenseitig aus. Ein gängiges Produktionsmuster kombiniert ein auf Aufgaben basierendes Routing (Code → Code-Modell) mit Fallback-Ketten (Primäres Modell → Ersatzmodell) hinter einem Gateway-Proxy.

Nächste Schritte

Wählen Sie ein lokales Modell

Vergleichen Sie Modelle sowie Backends, um festzulegen, welche Deployments Sie registrieren möchten.

Führen Sie Benchmarks für Ihre Deployment durch.

Messen Sie die Durchsatzrate sowie die Latenz, um Ihre Routing-Entscheidungen bei tatsächlichen Arbeitslasten zu überprüfen.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Strategien für die Modell-Routing-Logik bei lokalen Modellen

Funktionsweise des Routings

Ein Connector für mehrere Modelle

Modellwechsel in Anfragen

Wechseln Sie das Backend ohne Änderungen an den Clients vorzunehmen.

Routing-Strategien

Entscheidungsmatrix

Nächste Schritte

Wählen Sie ein lokales Modell

Führen Sie Benchmarks für Ihre Deployment durch.

​Funktionsweise des Routings

​Ein Connector für mehrere Modelle

​Modellwechsel in Anfragen

​Wechseln Sie das Backend ohne Änderungen an den Clients vorzunehmen.

​Routing-Strategien

​Entscheidungsmatrix

​Nächste Schritte

Wählen Sie ein lokales Modell

Führen Sie Benchmarks für Ihre Deployment durch.

Funktionsweise des Routings

Ein Connector für mehrere Modelle

Modellwechsel in Anfragen

Wechseln Sie das Backend ohne Änderungen an den Clients vorzunehmen.

Routing-Strategien

Entscheidungsmatrix

Nächste Schritte