Stratégies de routage des modèles pour les modèles locaux

Tokios permet d’exposer plusieurs modèles, chacun sous son propre nom public, et de les relier entre eux en modifiant simplement le champ model dans votre requête. Le point de terminaison et la clé API restent identiques ; seul le contenu du champ model varie.

Principe du routage

Chaque déploiement possède un nom public unique. Lorsque Tokios reçoit une requête, il analyse le champ model, identifie le déploiement correspondant, remplace alors cette valeur par l’ID de modèle amont propre à ce déploiement, puis transmet la requête via le connecteur. La configuration de votre client demeure inchangée ; il suffit de modifier le champ model.

Un seul connecteur, plusieurs modèles

Un unique connecteur peut desservir plusieurs modèles. Listez chaque ID de modèle amont dans Routes et associez-le à un nom local désigné dans Upstreams :

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

Ensuite, créez un deployment pour chaque modèle dans la console, en attribuant à chacun un nom public (par exemple gemma-tunnel devient gemma4:e4b, qwen-coder devient qwen2.5-coder), tous pointant vers ce même connecteur.

Préférez-vous les séparer ? Il est également possible de lancer un connecteur distinct pour chaque modèle, chacun doté de ses propres valeurs ConnectorId, Token et Upstream. Les deux méthodes sont valables ; le serveur n’envoie jamais qu’un seul ID de modèle dans le tunnel.

Changer de modèle dans les requêtes

Une fois les deux déploiements enregistrés, il suffit de modifier le champ model pour basculer d’un modèle à l’autre.

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

Le point de terminaison, l’en-tête d’authentification ainsi que tous les autres paramètres demeurent inchangés. Tokios se charge de la distribution des requêtes.

Permutez le backend sans modifier les clients.

Puisque les clients ne font référence qu’au nom public du modèle, il est possible de le déplacer vers un autre matériel ou un autre backend sans modifier la configuration client : il suffit de mettre à jour le déploiement (ou l’ID de modèle amont du connecteur) afin qu’il pointe vers le nouveau serveur, tout en conservant le même nom public, et les requêtes existantes continueront de fonctionner.

Stratégies de routage

Lorsque plusieurs modèles locaux sont en service, orienter toutes les requêtes vers le même modèle entraîne un gaspillage de ressources. Une requête de codage n’a pas besoin d’un modèle de raisonnement tel que 120B, et une tâche de classification simple ne requiert pas un modèle dense comme 70B. Le routage permet d’envoyer chaque requête au modèle le plus adapté à la tâche, optimisant ainsi la vitesse, la qualité ou le coût selon les besoins. Utiliser exclusivement le modèle 1 pour toutes les tâches implique un compromis : un modèle volumineux assure de bons résultats mais répond lentement et consomme davantage de VRAM. Un modèle plus petit répond rapidement mais peine à effectuer des raisonnements complexes. Le routage offre la possibilité d’utiliser les deux :

Vitesse : les requêtes simples sont traitées par un modèle petit et rapide, tandis que les tâches complexes sont confiées à un modèle plus volumineux.
Qualité : les tâches de codage sont traitées par un modèle spécialisé en programmation, et les conversations générales par un modèle polyvalent.
Coût : les modèles plus petits consomment moins d’énergie et de VRAM, laissant ainsi de la marge pour les tâches exigeantes.
Résilience : si le modèle principal est surchargé ou indisponible, les requêtes sont automatiquement redirigées vers un modèle de secours.

Un modèle par déploiement

La méthode la plus simple consiste à enregistrer chaque modèle en tant que déploiement Tokios distinct, puis à laisser le client choisir le modèle à appeler en modifiant le champ model.

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

Votre client envoie des requêtes en incluant la valeur model appropriée :

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

Cas d’utilisation : vous exécutez des modèles 2–3 et votre application choisit le modèle à invoquer. Il s’agit du point de départ le plus fréquent.

Routage basé sur les tâches

Selon le type de tâche, on oriente les requêtes : vers un modèle spécialisé en programmation pour les demandes de codage, vers un modèle polyvalent pour les conversations, et vers un modèle à forte capacité de raisonnement pour les problèmes complexes. Le client ou une couche intermédiaire analyse la requête et sélectionne le déploiement adéquat.

Type de tâche	Catégorie de modèle recommandée	Exemple de déploiement	Raison de ce choix
Génération et refactorisation de code	Spécialisé en programmation	Qwen3-Coder-30B exécuté via vLLM	Entraîné spécifiquement pour le code ; il excelle en matière de syntaxe et de logique
Chat général et résumé de texte	MoE (35B–122B)	Qwen3.5-35B-A3B sur Atlas	Débit élevé ; 3B paramètres actifs par jeton
Raisonnement complexe et calculs mathématiques	Modèles denses 70B+	Qwen3-32B ou 70B sur vLLM	Qualité supérieure pour le raisonnement en plusieurs étapes
Appel d’outils et systèmes d’agents	Modèle capable d’utiliser des outils	GLM-4.5-Air sur vLLM	Prise en charge efficace de l’appel de fonctions
Vision, multimodale	Modèle multimodal	Qwen3-VL sur vLLM	Gère nativement les entrées d’images

La mise en œuvre la plus simple se fait dans le code de votre application : examinez le type de requête puis choisissez le nom du déploiement :

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

Pour un routage plus sophistiqué, utilisez un passerelle tel que LiteLLM ou OpenRouter qui analyse les requêtes et les redirige vers le backend approprié selon des règles configurables.

Routage au niveau de la passerelle

Placez un proxy de routage entre vos clients et Tokios. Ce proxy détermine quel déploiement Tokios utiliser en fonction des attributs de la requête, de la charge ou de règles personnalisées.LiteLLM peut se placer devant plusieurs déploiements Tokios et effectuer le routage selon des alias de modèles :

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

Les clients envoient leurs requêtes au proxy LiteLLM en utilisant l’alias gpt-4 ; le proxy redirige alors vers le déploiement Tokios que vous avez configuré.OpenRouter prend en charge la redondance de modèles ainsi que l’équilibrage de charge entre plusieurs fournisseurs. Ajoutez votre point de terminaison Tokios en tant que fournisseur personnalisé et définissez les règles de routage dans le tableau de bord OpenRouter.

Chaînes de redondance

Configurez un modèle principal ainsi que 1 modèles de secours. Lorsque le modèle principal est occupé, hors ligne ou renvoie une erreur, la requête est transmise au modèle suivant de la chaîne.

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

Les connecteurs Tokios communiquent leur état au passerelle. Si un connecteur devient hors ligne, les requêtes destinées aux déploiements associés renvoient 503. Votre application peut alors effectuer une nouvelle tentative via un autre déploiement, ou vous pouvez configurer un passerelle tel que LiteLLM pour gérer automatiquement le basculement vers un autre modèle.

Routage basé sur les coûts

Dirigez les requêtes fréquentes et simples vers un modèle plus petit et moins coûteux, tout en réservant le modèle volumineux aux tâches nécessitant ses capacités.

Type de requête	Destination du routage	Motif du routage
Classification et extraction	Architecture MoE avec 3 à 4B paramètres actifs	Rapide et nécessitant peu de ressources par jeton
Synthèse de texte (courte)	7B–14B dense ou MoE	Qualité suffisante ; réponse rapide
Raisonnement complexe	32B combiné à une version dense ou 122B avec architecture MoE	Qualité supérieure dans les tâches nécessitant plusieurs étapes
Génération de code	Modèle spécialisé dans le traitement du code	Résultats optimisés par rapport au budget de jetons disponible

Cette approche diminue la charge de calcul et la consommation d’énergie, ce qui est crucial pour les matériels grand public dotés de VRAM et de puissance limités.

Matrice de décision

Stratégie	Complexité	Idéal pour	Quand l’utiliser
Un seul modèle par déploiement	Faible	Getting started, 2–3 models	Vous décidez quel modèle appeler dans le code de votre application
Routage basé sur les tâches	Moyen	Programmation, discussion et raisonnement	Vous avez besoin de modèles différents pour des types de tâches variés
Routage au niveau du passerelle	Élevé	Plusieurs clients partageant la même infrastructure	Vous souhaitez mettre en place des règles de routage centralisées sans avoir à modifier le code client.
Chaînes de secours	Niveau moyen	Haute disponibilité	Votre modèle principal peut se retrouver hors ligne ou atteindre ses limites de concurrence.
Routage basé sur les coûts	Niveau moyen	Charges de travail mixtes à fort volume	Vous voulez réduire au maximum les coûts de calcul en envoyant les tâches simples à des modèles plus petits.

Ces stratégies ne s’excluent pas mutuellement. Un schéma de production courant combine le routage selon les tâches (code → modèle de code) avec des chaînes de secours (modèle principal → modèle de secours) derrière un proxy de passerelle.

Prochaines étapes

Choisissez un modèle local

Comparez les modèles et les backends afin de déterminer quels déploiements il convient d’enregistrer.

Évaluez les performances de votre déploiement.

Mesurez le débit et la latence afin de valider vos choix de routage dans des conditions de charge réelles.

Matériel et compatibilité

Servir et connecter votre runtime

Connecter un client ou une app

Comparer

Stratégies de routage des modèles pour les modèles locaux

Principe du routage

Un seul connecteur, plusieurs modèles

Changer de modèle dans les requêtes

Permutez le backend sans modifier les clients.

Stratégies de routage

Matrice de décision

Prochaines étapes

Choisissez un modèle local

Évaluez les performances de votre déploiement.

​Principe du routage

​Un seul connecteur, plusieurs modèles

​Changer de modèle dans les requêtes

​Permutez le backend sans modifier les clients.

​Stratégies de routage

​Matrice de décision

​Prochaines étapes

Choisissez un modèle local

Évaluez les performances de votre déploiement.

Principe du routage

Un seul connecteur, plusieurs modèles

Changer de modèle dans les requêtes

Permutez le backend sans modifier les clients.

Stratégies de routage

Matrice de décision

Prochaines étapes