Strategien für das Modell-Routing bei lokalen Modellen

Mit Tokios koennen Sie mehrere Modelle bereitstellen – jedes unter einem eigenen oeffentlichen Namen – und zwischen ihnen weiterleiten, indem Sie das model-Feld in Ihrer Anfrage aendern. Der Endpunkt und der API-Schluessel bleiben gleich; nur der model-Wert aendert sich.

So funktioniert Routing

Jedes Deployment hat einen eindeutigen oeffentlichen Namen. Wenn Tokios eine Anfrage erhaelt, liest es das model-Feld, findet das Deployment mit diesem Namen, schreibt ihn in die Upstream-Modell-ID dieses Deployments um und leitet die Anfrage durch den Tunnel des Connectors weiter. Ihre Client-Konfiguration aendert sich nie – nur der model-Wert.

Ein Connector, viele Modelle

Ein einzelner Connector kann mehrere Modelle bedienen. Listen Sie jede Upstream-Modell-ID in Routes auf und ordnen Sie sie einem benannten lokalen Upstream 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" }
    }
  }
}

Anschliessend registrieren Sie ein Deployment fuer jedes Modell in der Konsole und geben jedem einen oeffentlichen Namen (z.B. gemma-tunnel → gemma4:e4b, qwen-coder → qwen2.5-coder), die alle auf diesen Connector zeigen.

Lieber getrennt? Sie koennen auch einen Connector pro Modell betreiben, jeweils mit eigener ConnectorId/Token und Upstream. Beide Ansaeetze funktionieren – der Server sendet nur die Modell-ID durch den Tunnel.

Modellwechsel in Anfragen

Nachdem beide Deployments registriert sind, wechseln Sie Modelle nur durch Aendern des model-Felds:

# 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 Auth-Header und jeder andere Parameter bleiben identisch. Tokios uebernimmt das Routing.

Backend tauschen, ohne Clients anzufassen

Da Clients nur den oeffentlichen Namen referenzieren, koennen Sie ein Modell auf andere Hardware oder ein anderes Backend verschieben, ohne Client-Konfigurationen zu aendern: Aktualisieren Sie das Deployment (oder den Upstream des Connectors), damit es auf den neuen Server zeigt, behalten Sie den gleichen oeffentlichen Namen bei, und bestehende Anfragen funktionieren weiterhin.

Routing-Strategien

Wenn Sie mehrere lokale Modelle betreiben, verschwendet das Senden jeder Anfrage an dasselbe Modell Ressourcen. Eine Coding-Anfrage braucht kein 120B Reasoning-Modell, und eine einfache Klassifizierung braucht kein 70B Dense-Modell. Mit Routing koennen Sie jede Anfrage an das Modell leiten, das am besten zur Aufgabe passt – optimiert nach Geschwindigkeit, Qualitaet oder Kosten je nach Workload. Wenn Sie 1 Modell fuer alles verwenden, erzwingt das Kompromisse. Ein grosses Modell bewaeltigt jede Aufgabe gut, antwortet aber langsam und verbraucht mehr VRAM. Ein kleines Modell antwortet schnell, hat aber Schwierigkeiten bei komplexem Reasoning. Mit Routing bekommen Sie beides:

Geschwindigkeit: Einfache Anfragen gehen an ein kleines, schnelles Modell; komplexe Aufgaben an ein grosses Modell
Qualitaet: Code-Aufgaben gehen an ein code-spezialisiertes Modell; allgemeiner Chat an einen Generalisten
Kosten: Kleinere Modelle verbrauchen weniger Strom und VRAM und lassen mehr Spielraum fuer anspruchsvolle Aufgaben
Ausfallsicherheit: Wenn Ihr primaeres Modell belegt oder offline ist, werden Anfragen an ein Backup weitergeleitet

Ein Modell pro Deployment

Der einfachste Ansatz – registrieren Sie jedes Modell als eigenes Tokios-Deployment und lassen Sie den Client waehlen, welches aufgerufen wird, indem er das model-Feld aendert.

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"}]}'

Wann verwenden: Sie betreiben 2–3 Modelle und Ihre Anwendung steuert, welches Modell aufgerufen wird. Dies ist der haeufigste Ausgangspunkt.

Aufgabenbasiertes Routing

Nach Aufgabentyp routen – Coding-Anfragen an ein code-spezialisiertes Modell, Chat an einen Generalisten und Reasoning an ein Dense-Modell. Der Client oder eine Middleware-Schicht prueft die Anfrage und waehlt das Deployment.

Aufgabentyp	Empfohlene Modellklasse	Beispiel-Deployment	Grund
Code-Generierung, Refactoring	Code-spezialisiert	Qwen3-Coder-30B auf vLLM	Speziell fuer Code trainiert; besser bei Syntax und Logik
Allgemeiner Chat, Zusammenfassungen	MoE (35B–122B)	Qwen3.5-35B-A3B auf Atlas	Schneller Durchsatz; 3B aktive Parameter pro Token
Komplexes Reasoning, Mathematik	Dense 70B+	Qwen3-32B oder 70B auf vLLM	Hoehere Qualitaet bei mehrstufigem Reasoning
Tool-Aufrufe, Agenten	Tool-faehiges Modell	GLM-4.5-Air auf vLLM	Starke Function-Calling-Unterstuetzung
Vision, multimodal	Multimodales Modell	Qwen3-VL auf vLLM	Verarbeitet Bild-Eingaben nativ

Die einfachste Umsetzung liegt in Ihrem Anwendungscode – pruefen Sie den Anfragetyp und waehlen Sie den Deployment-Namen:

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")

Fuer anspruchsvolleres Routing verwenden Sie ein Gateway wie LiteLLM oder OpenRouter, das Anfragen prueft und basierend auf konfigurierbaren Regeln an das richtige Backend weiterleitet.

Routing auf Gateway-Ebene

Platzieren Sie einen Routing-Proxy zwischen Ihren Clients und Tokios. Der Proxy entscheidet, welches Tokios-Deployment basierend auf Anfrage-Attributen, Auslastung oder benutzerdefinierten Regeln verwendet wird.LiteLLM kann vor mehreren Tokios-Deployments sitzen und basierend auf Modell-Aliasen routen:

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 den LiteLLM-Proxy mit dem Alias gpt-4, und der Proxy leitet an das Tokios-Deployment weiter, das Sie konfiguriert haben.OpenRouter unterstuetzt Modell-Fallback und Lastverteilung ueber mehrere Provider. Fuegen Sie Ihren Tokios-Endpunkt als benutzerdefinierten Provider hinzu und konfigurieren Sie Routing-Regeln im OpenRouter-Dashboard.

Fallback-Ketten

Konfigurieren Sie ein primaeres Modell mit 1 oder mehreren Fallback-Modellen. Wenn das primaere Modell belegt, offline ist oder einen Fehler zurueckgibt, wird die Anfrage an das naechste 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")

Tokios-Connectors melden ihren Status an das Gateway. Wenn ein Connector offline geht, geben Anfragen an Deployments auf diesem Connector 503 zurueck. Ihre Anwendung kann dies abfangen und mit einem anderen Deployment erneut versuchen, oder Sie koennen ein Gateway wie LiteLLM konfigurieren, um den Fallback automatisch abzuwickeln.

Kostenbasiertes Routing

Leiten Sie einfache Anfragen mit hohem Volumen an ein kleineres, guenstigeres Modell weiter und reservieren Sie das grosse Modell fuer Aufgaben, die es benoetigen.

Anfragetyp	Routen an	Grund
Klassifizierung, Extraktion	MoE mit 3–4B aktiven Parametern	Schnell; geringer Rechenaufwand pro Token
Zusammenfassung (kurz)	7B–14B Dense oder MoE	Ausreichende Qualitaet; schnelle Antwort
Komplexes Reasoning	32B+ Dense oder 122B MoE	Hoehere Qualitaet bei mehrstufigen Aufgaben
Code-Generierung	Code-spezialisiertes Modell	Bessere Ausgabe fuer das Token-Budget

Diese Strategie reduziert den Gesamtbedarf an Rechenleistung und Stromverbrauch – wichtig bei der Nutzung auf Consumer-Hardware, wo VRAM und Leistungsaufnahme begrenzt sind.

Entscheidungsmatrix

Strategie	Komplexitaet	Am besten fuer	Wann verwenden
Ein Modell pro Deployment	Niedrig	Einstieg mit 2–3 Modellen	Sie steuern im Anwendungscode, welches Modell aufgerufen wird
Aufgabenbasiertes Routing	Mittel	Coding + Chat + Reasoning	Sie brauchen verschiedene Modelle fuer verschiedene Aufgabentypen
Routing auf Gateway-Ebene	Hoch	Mehrere Clients, gemeinsame Infrastruktur	Sie wollen zentralisierte Routing-Regeln ohne Aenderung des Client-Codes
Fallback-Ketten	Mittel	Hochverfuegbarkeit	Ihr primaeres Modell koennte offline gehen oder Concurrent-Limits erreichen
Kostenbasiertes Routing	Mittel	Hochvolumen, gemischte Workloads	Sie wollen Rechenkosten minimieren, indem Sie einfache Aufgaben an kleinere Modelle senden

Diese Strategien schliessen sich nicht gegenseitig aus. Ein haeufiges Produktionsmuster kombiniert aufgabenbasiertes Routing (Code → Code-Modell) mit Fallback-Ketten (primaer → Backup) hinter einem Gateway-Proxy.

Naechste Schritte

Ein lokales Modell waehlen

Vergleichen Sie Modelle und Backends, um zu entscheiden, welche Deployments Sie registrieren wollen.

Ihr Deployment testen

Messen Sie Durchsatz und Latenz, um Ihre Routing-Entscheidungen unter realen Workloads zu validieren.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Strategien für das Modell-Routing bei lokalen Modellen

So funktioniert Routing

Ein Connector, viele Modelle

Modellwechsel in Anfragen

Backend tauschen, ohne Clients anzufassen

Routing-Strategien

Entscheidungsmatrix

Naechste Schritte

Ein lokales Modell waehlen

Ihr Deployment testen

​So funktioniert Routing

​Ein Connector, viele Modelle

​Modellwechsel in Anfragen

​Backend tauschen, ohne Clients anzufassen

​Routing-Strategien

​Entscheidungsmatrix

​Naechste Schritte

Ein lokales Modell waehlen

Ihr Deployment testen

So funktioniert Routing

Ein Connector, viele Modelle

Modellwechsel in Anfragen

Backend tauschen, ohne Clients anzufassen

Routing-Strategien

Entscheidungsmatrix

Naechste Schritte