Routage des modèles : cessez d'utiliser un seul modèle pour tout

Exécuter un modèle de 70 milliards de paramètres pour résumer un e-mail de 200 mots est un gaspillage. Utiliser un modèle de 3 milliards de paramètres pour passer en revue du code en production est imprudent. La plupart des systèmes se situent quelque part entre les deux — et c’est là qu’intervient le routage de modèles.

Il associe la complexité de la tâche aux capacités du modèle. Les compromis sont réels, mais les économies aussi.

Le problème du routage

Les utilisateurs commencent généralement avec un seul modèle et s’y en tiennent. Cela fonctionne jusqu’à ce que vous remarquiez le coût, la latence, ou les deux. L’alternative consiste à construire un routeur — quelque chose qui décide quel modèle traite quelle requête.

Quatre stratégies fonctionnent en pratique :

1. Basé sur les capacités — router en fonction de ce que le modèle peut faire
2. Sensible au coût — router en fonction de ce que vous êtes prêt à dépenser
3. Sensible à la latence — router en fonction de la rapidité requise
4. Hybride — les combiner

Chaque stratégie optimise quelque chose de différent. En choisir une est généralement une décision concernant ce qui fait le plus mal.

Routage basé sur les capacités

L’approche la plus simple. Classifiez la tâche, envoyez-la au modèle qui la traite.

Si la tâche n’a pas besoin du modèle plus grand, ne l’utilisez pas. Un modèle de 1,5B gère bien la classification de sentiments. Il n’écrira simplement pas un essai cohérent.

La mise en œuvre est simple :

ROUTING_RULES = {
    "classify": {"model": "qwen2.5-1.5b", "max_tokens": 100},
    "summarize": {"model": "qwen2.5-7b", "max_tokens": 500},
    "code_review": {"model": "qwen2.5-coder-7b", "max_tokens": 2000},
    "reason": {"model": "qwen2.5-32b", "max_tokens": 4000},
    "creative": {"model": "claude-sonnet-4", "max_tokens": 8000},
}

def route_request(task_type: str) -> dict:
    return ROUTING_RULES.get(task_type, ROUTING_RULES["reason"])

Le piège est la classification elle-même. Si vous identifiez mal le type de tâche, vous routez vers le mauvais modèle. J’ai vu des systèmes classer la revue de code comme « résumé » et perdre en qualité silencieusement.

Routage sensible au coût

L’inférence locale brille ici. Les modèles locaux sont pratiquement gratuits après l’amortissement du matériel. Une RTX 5080 s’amortit en environ six mois avec une utilisation modérée de l’API.

Si vous traitez des milliers de requêtes par session, même $0,05 d’électricité bat $15/M jetons.

Le routage basé sur le budget revient à des options moins chères au fur et à mesure que vous dépensez :

class CostAwareRouter:
    def __init__(self, budget_per_session: float = 0.10):
        self.budget = budget_per_session
        self.spent = 0.0
        self.models = {
            "cheap": {"model": "qwen2.5-7b", "cost": 0.0},
            "medium": {"model": "qwen2.5-32b", "cost": 0.0},
            "expensive": {"model": "claude-sonnet-4", "cost": 0.000015},
        }

    def route(self, task: str) -> str:
        ratio = self.spent / self.budget
        if ratio < 0.5:
            return self.models["expensive"]["model"]
        elif ratio < 0.8:
            return self.models["medium"]["model"]
        return self.models["cheap"]["model"]

La qualité se dégrade au fur et à mesure que vous basculez sur des options moins chères. Vous commencez avec Claude, passez à Qwen-32B, puis à Qwen-7B. À la fin d’une longue session, la sortie est nettement moins bonne. Si cela a de l’importance dépend de ce que vous construisez.

Routage sensible à la latence

Les outils interactifs ont besoin de premiers jetons rapides. Les travaux par lots peuvent attendre. La différence est généralement un facteur de cinq en taille de modèle.

Lorsque vous diffusez des jetons à un utilisateur, la latence du premier jeton est ce qu’ils ressentent. Un modèle de 32B prenant une demi-seconde pour démarrer semble lent comparé à un modèle de 1,5B qui se déclenche instantanément.

class LatencyAwareRouter:
    def __init__(self):
        self.model_latencies = {
            "qwen2.5-1.5b": {"first_token": 0.05, "complete": 0.5},
            "qwen2.5-7b": {"first_token": 0.15, "complete": 2.0},
            "qwen2.5-32b": {"first_token": 0.5, "complete": 10.0},
            "claude-sonnet-4": {"first_token": 0.3, "complete": 5.0},
        }

    def route(self, target_latency: float) -> str:
        for model, latencies in sorted(
            self.model_latencies.items(),
            key=lambda x: x[1]["complete"]
        ):
            if latencies["complete"] <= target_latency:
                return model
        return "qwen2.5-1.5b"

Les chiffres de latence sont approximatifs — ils dépendent de votre matériel, de la quantification et de la taille du lot. Mesurez sur votre propre configuration.

Stratégies de repli

Les modèles échouent. Les APIs limitent les taux. Les dépassements de temps arrivent. Le modèle qui fonctionne est une chaîne de repli, ordonnée du meilleur au plus fiable :

class FallbackRouter:
    def __init__(self):
        self.fallback_chain = [
            {"model": "claude-sonnet-4", "timeout": 30},
            {"model": "qwen2.5-72b", "timeout": 60},
            {"model": "qwen2.5-32b", "timeout": 120},
            {"model": "qwen2.5-7b", "timeout": 300},
        ]

    def route_with_fallback(self, prompt: str) -> str:
        for config in self.fallback_chain:
            try:
                return self.call_model(
                    config["model"], prompt,
                    timeout=config["timeout"]
                )
            except (TimeoutError, APIError) as e:
                log.warning(f"Model {config['model']} failed: {e}")
                continue
        raise RuntimeError("All fallback models failed")

Le dernier modèle de la chaîne devrait être local. Il est plus lent, mais il ne tombera pas en panne à cause d’un problème réseau ou d’une clé API.

Quand le routage aide

Le routage a du sens lorsque votre charge de travail est mixte. Si vous faites de la classification, du résumé et du raisonnement dans le même système, un routeur économise de l’argent et réduit la latence.

Il n’a pas de sens si tout ce que vous faites a la même complexité. Utilisez simplement le modèle qui est bon pour cette tâche. Le routeur ajoute une complexité dont vous n’avez pas besoin.

Le prototypage précoce est une autre raison de l’éviter. Faites fonctionner la tâche avec un seul modèle, puis ajoutez le routage lorsque le coût ou la latence deviennent réellement un problème.

Compromis

Chaque stratégie de routage optimise quelque chose et sacrifie autre chose :

• Modèle unique — le plus simple, le plus coûteux, qualité constante
• Basé sur les capacités — meilleur coût, qualité plus élevée par tâche, complexité modérée
• Sensible au coût — le moins cher, qualité variable, complexité modérée
• Sensible à la latence — le plus rapide, peut sacrifier la qualité, complexité modérée
• Hybride — le meilleur de tout, le plus complexe à implémenter

Les systèmes de production convergent généralement vers l’hybride. Commencez par un routage basé sur les capacités, ajoutez la sensibilité au coût lorsque la facture arrive, ajoutez la sensibilité à la latence lorsque les utilisateurs se plaignent de lenteur.

Ressources associées

• Optimisation des coûts pour les systèmes LLM — budgétisation des jetons, mise en cache, modèles de repli
• Les garde-fous LLM en pratique — validation des entrées, filtrage des sorties, sécurité
• Conception de systèmes multi-modèles — architecture pour plusieurs modèles
• Architecture LLM — pilier de conception système : routage, coût, garde-fous et orchestration