Relais API Llama : multi-fournisseurs, facturation et migration (2026)

Depuis l'arrêt de la préversion publique de l'API Llama de Meta, les appels aux modèles Llama n'ont pas disparu : ils se sont répartis entre plateformes cloud, fournisseurs d'inférence et nœuds auto-hébergés. Pour une équipe en Chine, se connecter directement à chaque amont coûte des comptes et de l'exploitation ; le « relais » est donc devenu une pratique courante : une entrée compatible OpenAI, derrière laquelle sont branchés plusieurs amonts Llama.

Mais un relais ne change que la couche d'accès, pas les capacités du modèle. Il apporte de la commodité et de nouveaux contrôles : le modèle est-il l'original, la facturation est-elle transparente, la clé et les données sont-elles sûres, comment revenir en arrière en cas de panne d'un point unique. Cet article traite ces quatre points, puis fournit une checklist de migration.

Remarque : Meta, Llama et Llama 4 sont des marques de Meta Platforms, Inc. ; Groq, Together AI, Fireworks, OpenRouter, AWS, Azure et Google Cloud sont des marques de leurs détenteurs respectifs. Cet article est purement technique et n'implique aucune affiliation ni relation de coopération avec ces sociétés. Les modèles et tarifs suivent la documentation officielle de chaque plateforme et la page Tarifs du site ; les prix évoluent.

1. Pourquoi les relais Llama se sont multipliés en 2026

La préversion publique de l'API Llama de Meta a été retirée le 6 juillet 2026. Les poids Llama restent téléchargeables et toujours hébergés par AWS Bedrock, Azure AI Foundry, Google Cloud Vertex AI, Groq, Together AI, Fireworks, DeepInfra et d'autres, mais chaque plateforme a ses propres identifiants de modèles, interfaces, limites et factures.

Le relais unifie ces différences : l'équipe n'a qu'une clé, une URL de base et une facture, ce qui simplifie réellement la vie des petites équipes. Le prix à payer est une dépendance supplémentaire et un objet à auditer.

2. Relais, proxy, passerelle : trois mots différents

Relais/agrégation : le prestataire détient plusieurs comptes amont et transmet les requêtes vers différentes plateformes selon des règles, avec facturation et journaux unifiés. Il assure souvent la correspondance des noms de modèles, par exemple mapper llama-4-scout vers l'identifiant complet d'un amont.

Proxy : plus proche d'un reverse proxy ou d'un transfert direct, il résout l'accessibilité réseau et un point de sortie unifié ; il peut ne correspondre qu'à un seul amont et ne pas offrir de facturation ni de multi-fournisseurs.

Passerelle : périmètre plus large ; outre le transfert, elle gère authentification, quotas, membres, audit, routage et facturation. Les trois se recouvrent souvent dans les produits réels : ne regardez pas le nom, demandez ce qu'elle fait réellement.

Chaque couche de transfert ajoute une latence, un point de panne et une surface d'exposition des données ; elle doit entrer dans l'architecture et la gestion contractuelle.

3. Comment combiner plusieurs fournisseurs

Le principe est de répartir par tâche : Groq pour le dialogue à faible latence ; Bedrock, Vertex AI ou Azure pour un contrat entreprise, une conformité régionale ou un accès réseau privé ; Together AI, Fireworks, DeepInfra et les plateformes à l'usage pour le traitement par lots et les tâches hors ligne ; l'auto-hébergement lorsque les données ne peuvent pas sortir de la salle machine.

Une entrée peut porter plusieurs routes, mais chacune doit maintenir sa propre correspondance de modèles et sa base d'évaluation. Ne routez pas uniquement selon le prix : les niveaux de quantification, le contexte et le filtrage de contenu diffèrent entre amonts, et la route la moins chère ne satisfait pas forcément la qualité exigée.

4. Vérifier l'identité du modèle : même nom ne signifie pas même chose

« Llama 4 Scout » peut désigner des choses différentes selon la plateforme : version des poids, quantification (FP8, INT4, AWQ, GPTQ), fenêtre de contexte, template de dialogue, sortie maximale, parfois avec un filtrage de sécurité supplémentaire. Le nom est identique, le comportement peut varier fortement.

Six points de contrôle :

la fiche modèle : version des poids, quantification, longueur de contexte, date de coupure des connaissances, éventuel affinage ;
l'identifiant et le champ de version renvoyés par /models, pour écarter un alias flou ;
une empreinte comportementale avec un prompt fixe : nombre de tokens, structure de sortie, rappel sur contexte long ;
les appels d'outils, la sortie JSON, le format de streaming et les capacités multimodales, qui révèlent le plus les différences ;
les en-têtes de réponse, l'identifiant de requête et l'identifiant amont, pour retrouver un nœud précis en cas de problème ;
une comparaison A/B sur votre jeu d'évaluation métier, plutôt que demander au modèle « qui es-tu » : une auto-description ne prouve rien.

Pour les activités sensibles à la version, figez l'identifiant de modèle et l'amont, sans accepter de « mise à jour automatique ».

5. Transparence de la facturation : décomposer la facture

Une facture de relais combine généralement plusieurs couches : coût des tokens amont, marge ou coefficient du prestataire, consommation minimale, remise de rechargement, requêtes échouées et tentatives. Regarder seulement le « prix au million de tokens » laisse échapper des postes.

Vérifiez au minimum : entrée, sortie et succès de cache sont-ils facturés séparément ; qui compte les tokens et avec quel tokenizer ; une interruption de streaming ou un timeout est-il facturé ; une tentative est-elle facturée deux fois ; quel taux de change s'applique entre devises ; la facture peut-elle être émise au nom de l'entreprise. La méthode sûre est d'exiger un journal d'usage par requête, avec identifiant, modèle, tokens, durée et nom de l'amont, puis d'échantillonner chaque jour pour rapprocher.

La facturation et les modèles de ZSQH AI Gateway suivent la page Tarifs du site ; quelle que soit la passerelle choisie, rechargez d'abord un petit montant, faites tourner une semaine, puis vérifiez coefficients et règles sur les requêtes échouées avec la facture réelle. L'inscription se fait sur la page d'inscription.

6. Clés, données et risque de point unique

Un relais voit les prompts et les sorties en clair : c'est inhérent au modèle, aucune promesse ne l'efface. À la sélection, demandez : combien de temps les journaux sont conservés, qui peut y accéder, servent-ils à l'entraînement, quel est le mécanisme de suppression, existe-t-il un accord de traitement des données. Pour des données personnelles ou clients, anonymisez les champs ou gardez les requêtes sensibles sur un nœud auto-hébergé.

Côté clés, émettez une sous-clé par projet, avec quota et liste blanche de modèles, rattachement à la source, rotation régulière et révocation immédiate en fin de projet. La clé principale ne doit jamais être dans un front-end ni une application mobile. Le relais est lui-même un point unique : s'il tombe, le nombre d'amonts derrière ne change rien. Une activité critique doit conserver une voie directe ou auto-hébergée de secours.

7. Bascule : transformer « changer de fournisseur » en processus

La bascule ne doit pas dépendre d'une modification de code dans l'urgence. Maintenez une table de routage, classez les amonts par priorité, avec pour chacun une clé, un identifiant de modèle et un budget de timeout propres ; en cas d'échec du contrôle de santé, coupez le circuit et passez au suivant ; ajoutez backoff exponentiel et gigue ; en cas d'échec total, dégradez vers un modèle plus petit ou renvoyez une erreur explicable.

L'exemple minimal ci-dessous ne montre que la bascule séquentielle ; la production ajoute coupe-circuit, journaux et contrôle des quotas. Les identifiants de modèles et adresses suivent la documentation de chaque plateforme.

import os
from openai import OpenAI

ROUTES = [
    ("groq", "https://api.groq.com/openai/v1",
     "llama-4-scout-17b-16e-instruct", "GROQ_API_KEY"),
    ("together", "https://api.together.xyz/v1",
     "meta-llama/Llama-4-Scout-17B-16E-Instruct", "TOGETHER_API_KEY"),
    ("gateway", "https://votre-passerelle.example.com/v1",
     "llama-4-scout", "GATEWAY_API_KEY"),
]

def chat(messages):
    last_error = None
    for name, base_url, model, key_env in ROUTES:
        try:
            client = OpenAI(
                base_url=base_url,
                api_key=os.environ[key_env],
                timeout=30,
            )
            return client.chat.completions.create(
                model=model,
                messages=messages,
            )
        except Exception as exc:
            last_error = exc
    raise last_error

Le modèle de secours peut avoir un contexte, un tokenizer et des capacités d'appel d'outils différents : après bascule, limitez la longueur d'entrée et journalisez un marqueur de dégradation, pour éviter un « appel réussi mais résultat inutilisable ».

8. Migrer depuis l'ancienne API Llama : neuf étapes

Inventoriez URL de base, clés, identifiants de modèles, versions de SDK et modes d'appel dans le code.
Déplacez les identifiants de modèles dans la configuration et établissez la table de correspondance ancien/nouvel amont.
Choisissez l'amont principal et le secours, en confirmant région, paiement, facture et clauses de données.
Modifiez l'authentification et l'URL de base ; privilégiez une interface compatible OpenAI pour limiter les changements de SDK.
Retestez streaming, appels d'outils, mode JSON et entrées visuelles.
Ajustez contexte, sortie maximale et timeouts selon les limites du nouvel amont.
Comparez qualité, latence P95 et coût par requête sur votre jeu métier.
Rappropriez pendant une semaine : comptage des tokens, requêtes échouées et règles de tentative.
Déployez par paliers de 10 %, 50 % puis la totalité, avec retour arrière en un clic et instantané de configuration.

9. Tableau de vérification d'un service de relais

Point	Question à poser	Pratique conseillée
Identité du modèle	Version des poids, quantification, contexte	Exiger la fiche modèle, exécuter un jeu fixe
Composition amont	Vers quels fournisseurs, choix possible ?	Pouvoir voir l'amont et l'identifiant de requête
Facturation	Entrée/sortie, cache, requêtes échouées	Journal par requête, rapprochement par échantillon
Quotas	Membres et projets limités séparément ?	Sous-clés et alertes budgétaires
Données	Durée des journaux, usage pour l'entraînement	Accord de traitement, anonymisation des champs
Stabilité	Limitation, SLA, notification d'incident	Test de charge et canal de secours
Bascule	Changement automatique multi-amont ?	Table de routage propre, exercices réguliers
Contrat	Facture, remboursement, préavis d'arrêt	Inscrire aux conditions d'achat et de sortie

Questions fréquentes

Quelle différence entre un relais Llama et un accès direct à l'amont ?

L'accès direct suppose de détenir comptes, clés et factures amont : contrôle fort mais maintenance élevée. Le relais regroupe plusieurs amonts derrière une interface, avec activation rapide et facture unifiée, mais ajoute une dépendance et exige de vérifier identité du modèle, facturation et clauses de données.

Comment savoir si le relais fournit bien le Llama d'origine ?

Consultez la fiche modèle et les champs de version, interrogez /models, testez le comportement sur prompt fixe, le comptage du tokenizer, le contexte long et les appels d'outils, puis comparez sur votre jeu métier. L'auto-description du modèle et le nom marketing ne suffisent pas comme preuve.

Pourquoi la facture du relais ne correspond-elle pas à l'amont ?

Les causes courantes sont le tokenizer, le mode de calcul du cache, la facturation des échecs et tentatives, le coefficient ou la consommation minimale, et la conversion de devise. Exigez un journal par requête et rapprochez par identifiant, plutôt que de comparer le total mensuel.

Que faire si le service de relais tombe ?

Conservez une voie directe ou auto-hébergée pour les activités critiques, basculez par priorité, avec coupe-circuit et dégradation ; vérifiez aussi dans le contrat la notification d'incident, le SLA et les conditions de sortie. Ne placez pas tout le trafic sur un seul relais.

Combien de code faut-il modifier pour migrer ?

Si les deux interfaces sont compatibles OpenAI, seuls l'URL de base, la clé et l'identifiant de modèle changent généralement ; l'usage de protocoles propriétaires cloud, de vision, d'appels d'outils ou de détails de streaming demande plus de travail. Configurez d'abord les identifiants de modèles, puis validez par paliers.

En résumé

La valeur d'un relais Llama réside dans la couche d'accès : entrée unifiée, facture unifiée, bascule multi-amont. Il ne change pas les capacités du modèle et ne résout pas automatiquement les questions de conformité et de données. Inscrivez dans les critères d'acceptation l'identité du modèle, la facturation, les risques liés aux clés et aux données, et le processus de bascule : la migration devient alors beaucoup plus maîtrisable.