Retour au Journal
•6 min de lecture

Création d'une couche de routage d'IA résiliente multi-fournisseurs avec le SDK Vercel AI

Comment concevoir une couche de routage LLM de niveau production intégrant le basculement automatique (failover), des modèles de secours et des sorties structurées avec Zod via le SDK Vercel AI.

Vercel AI SDKTypeScriptLLM RoutingZodAI Engineering
Création d'une couche de routage d'IA résiliente multi-fournisseurs avec le SDK Vercel AI

Lors du déploiement de modèles de langage de grande taille (LLM) en production, la fiabilité s'avère souvent être le principal goulet d'étranglement. Dépendre d'un seul fournisseur de modèles introduit des risques de point de défaillance unique : limites de taux d'API (HTTP 429), pannes temporaires de service (HTTP 500/503) ou pics de latence soudains.

Pour garantir la disponibilité et l'efficacité des coûts, les équipes ont besoin d'une couche de routage dynamique capable de basculer automatiquement vers des modèles de secours ou de changer de fournisseur en fonction des paramètres d'entrée.

Dans ce guide, nous allons implémenter une couche de routage multi-fournisseurs résiliente et typée en utilisant le SDK Vercel AI et Zod.

L'architecture de la résilience LLM

Une couche de routage résiliente repose sur trois principes fondamentaux :

  1. Basculements séquentiels (Failovers) : Si le fournisseur principal échoue, le système réessaie automatiquement la requête en utilisant un fournisseur secondaire.
  2. Sélection dynamique : Les requêtes courtes sont envoyées à des modèles rapides et peu coûteux, tandis que les entrées plus volumineuses sont dirigées vers des modèles à haut contexte.
  3. Validation typée : Quel que soit le modèle qui traite la requête, le schéma de sortie reste identique et validé.
               +-------------------+
               |  Incoming Request |
               +-------------------+
                         |
                         v
             +-----------------------+
             | Dynamic Route Selector|
             +-----------------------+
               /                   \
        (Short Input)          (Long Input)
             /                       \
            v                         v
   +-----------------+       +-----------------+
   |  Primary Model  |       |  Primary Model  |
   | (OpenAI Luna)   |       | (Gemini-3.1-Pro)|
   +-----------------+       +-----------------+
            |                         |
       (On Failure)              (On Failure)
            v                         v
   +-----------------+       +-----------------+
   | Fallback Model  |       | Fallback Model  |
   | (Gemini-3.5-Fl) |       | (Claude-Sonnet5)|
   +-----------------+       +-----------------+
            \                         /
             \                       /
              v                     v
            +-------------------------+
            |  Zod Schema Validation  |
            +-------------------------+
                        |
                        v
               +-------------------+
               | Validated Output  |
               +-------------------+

Implémentation des mécanismes de secours (Fallbacks) avec le SDK Vercel AI

Le SDK Vercel AI fournit un wrapper fallback intégré qui vous permet de spécifier une liste prioritaire de modèles. Si un appel au premier modèle échoue, le SDK réessaie automatiquement en utilisant les modèles suivants dans le tableau.

Voici comment initialiser un modèle résilient avec des fournisseurs de secours :

import { fallback } from 'ai';
import { openai } from '@ai-sdk/openai';
import { google } from '@ai-sdk/google';
import { anthropic } from '@ai-sdk/anthropic';

// Initialize a resilient model that crosses three distinct providers
export const resilientModel = fallback([
  openai('terra'),
  anthropic('claude-sonnet-5'),
  google('gemini-3.1-pro')
]);

Lorsque vous appelez generateText ou generateObject avec resilientModel, le SDK gère automatiquement les erreurs, les délais d'attente et les tentatives de réexécution.

Solutions de secours locales avec Ollama

Pour une disponibilité hors ligne, des environnements hybrides ou une exécution sans coût lors des tests locaux, vous pouvez intégrer des modèles hébergés localement via Ollama. Le SDK Vercel AI traite les modèles Ollama comme des fournisseurs de premier plan, vous permettant de basculer directement des API cloud vers le silicium local.

Voici comment configurer une solution de secours hybride cloud-local:

import { fallback } from 'ai';
import { openai } from '@ai-sdk/openai';
import { ollama } from '@ai-sdk/ollama';

// Fallback to a locally hosted Llama 4 Scout model if the OpenAI API is unreachable
export const hybridModel = fallback([
  openai('luna'),
  ollama('llama4-scout')
]);

Extraction de données structurées et typées

L'un des défis du routage multi-fournisseurs est de s'assurer que les différents modèles respectent exactement la même structure de sortie. L'utilisation de Zod avec l'API generateObject résout ce problème.

Définisons un schéma pour extraire des métadonnées structurées à partir de profils de développeurs bruts :

import { generateObject } from 'ai';
import { z } from 'zod';
import { resilientModel } from './models';

const ProfileSchema = z.object({
  fullName: z.string(),
  skills: z.array(z.string()),
  yearsOfExperience: z.number(),
  certifications: z.array(
    z.object({
      name: z.string(),
      issuer: z.string()
    })
  )
});

export async function extractProfile(text: string) {
  try {
    const { object } = await generateObject({
      model: resilientModel,
      schema: ProfileSchema,
      prompt: `Extract structured profile details from the following resume text:\n\n${text}`
    });

    return object;
  } catch (error) {
    console.error('Failed to extract profile after exhausting all fallbacks:', error);
    throw new Error('Profile extraction failed');
  }
}

Étant donné que la sortie est analysée et validée par Zod au moment de l'exécution, le code de votre application peut s'appuyer en toute confiance sur la structure renvoyée, quel que soit le modèle de la chaîne de secours qui a réussi.

Routage dynamique basé sur la taille du contexte

Bien que les basculements séquentiels protègent contre les pannes totales, ils n'optimisent pas les coûts ni les limites de jetons (tokens). Par exemple, envoyer un document de 100 000 jetons à un modèle ayant une limite de 128 000 jetons est tout à fait acceptable, mais l'envoyer à un modèle limité à 16 000 jetons provoquera une erreur immédiate.

Nous pouvons construire un routeur dynamique qui inspecte la taille de l'entrée avant de choisir la chaîne de modèles appropriée :

import { LanguageModel, generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { google } from '@ai-sdk/google';
import { anthropic } from '@ai-sdk/anthropic';

// Define specialized model chains
const standardChain = fallback([
  openai('luna'),
  google('gemini-3.5-flash')
]);

const highContextChain = fallback([
  google('gemini-3.1-pro'),
  anthropic('claude-sonnet-5')
]);

// Estimate token count (simple word-count approximation for demo)
function estimateTokens(text: string): number {
  return text.trim().split(/\s+/).length * 1.3;
}

export async function smartRouteRequest(promptText: string) {
  const tokenEstimate = estimateTokens(promptText);
  
  // Route to the appropriate chain based on input size
  const model = tokenEstimate > 50000 ? highContextChain : standardChain;

  return generateText({
    model,
    prompt: promptText
  });
}

Ce modèle permet de maintenir des coûts bas en orientant les tâches standards vers des modèles économiques et rapides, tout en réservant les modèles premium à large contexte pour les charges de travail lourdes.

Télémétrie et observabilité

Pour suivre la fréquence à laquelle votre couche de routage sollicite les modèles de secours, vous pouvez vous connecter aux fonctionnalités expérimentales de télémétrie du SDK Vercel AI. Cela permet de collecter des indicateurs sur l'utilisation des jetons, la latence et les taux de réussite des fournisseurs :

import { generateText } from 'ai';
import { resilientModel } from './models';

const response = await generateText({
  model: resilientModel,
  prompt: 'Analyze this log output...',
  experimental_telemetry: {
    isEnabled: true,
    functionId: 'analyze-logs',
    metadata: {
      environment: 'production'
    }
  }
});

Ces traces sont centralisées dans des collecteurs OpenTelemetry standards, offrant à votre équipe une visibilité complète sur les basculements et la santé des fournisseurs.

Conclusion et compromis

Une couche de routage multi-fournisseurs renforce considérablement la fiabilité. Néanmoins, il convient de prendre en compte certains compromis :

  • Variations de style : Les modèles de secours peuvent présenter des styles de rédaction, des nuances de formatage ou des profils de conformité distincts.
  • Démarrages à froid : Relancer une requête ayant échoué sur un modèle secondaire ajoute de la latence pour l'utilisateur final.
  • Clés API des fournisseurs : Votre infrastructure doit configurer et gérer les clés API, les quotas de limites de taux et les comptes de facturation de plusieurs plateformes.

Grâce aux API unifiées du SDK Vercel AI, vous pouvez concevoir une architecture de routage robuste capable de protéger vos applications en production contre les pannes individuelles des fournisseurs.

Share this article