Routage au niveau des services dans une passerelle AI API : rapide, standard, provisionné et par lots sans fournisseurs de codage en dur
Une architecture pratique pour exposer des niveaux de charge de travail d'IA indépendants du fournisseur au niveau de la passerelle, puis mapper chaque demande à une capacité rapide, standard, provisionnée ou par lots avec des contrôles, des analyses et des enregistrements de facturation des locataires.
Le routage au niveau du service est la couche de stratégie qui décide si une requête d'IA mérite une capacité premium à faible latence, une capacité normale à la demande, un débit réservé ou un traitement asynchrone réduit. Sans cette couche, les équipes d'application codent généralement les indicateurs, les noms de déploiement et les points de terminaison de lots spécifiques au fournisseur directement dans le code produit. Cela rend la latence, le coût, le quota et le comportement de facturation des locataires difficiles à gérer.
La passerelle doit exposer l'intention de la charge de travail, et non les mécanismes du fournisseur. Une équipe produit doit être capable de dire « ceci est une réponse d'assistance interactive » ou « ceci est un travail d'enrichissement nocturne », tandis que la passerelle mappe cette intention à la bonne option de capacité en amont et enregistre ce qui s'est réellement passé.
Le problème du lecteur : les classes de capacité deviennent une logique applicative
Les équipes utilisant plusieurs fournisseurs de modèles commencent souvent par un simple routage de modèles : envoyez cet ID de modèle à ce fournisseur. Le routage devient plus difficile lorsque les fournisseurs exposent différentes classes de capacité :
- Gestion premium des requêtes à faible latence pour les chemins destinés aux utilisateurs.
- Capacité partagée standard pour le trafic synchrone ordinaire.
- Capacité dédiée ou provisionnée pour un débit prévisible.
- API par lots ou asynchrones pour les charges de travail tolérantes à la latence.
- Comportement de débordement lorsque la capacité réservée est épuisée.
Si chaque application gère elle-même ces choix, l'organisation perd le contrôle sur quatre éléments : qui peut utiliser la capacité premium, combien cela coûte, que se passe-t-il lorsque la capacité n'est pas disponible et si le niveau choisi a suffisamment amélioré le produit pour justifier la dépense.
Le modèle pratique consiste à placer une couche de qualité de service indépendante du fournisseur à l'intérieur de la passerelle API IA.
Faits sur lesquels s'appuyer
Les détails varient selon le fournisseur, mais plusieurs faits observables soutiennent une conception au niveau de la passerelle.
- Fait : Certains fournisseurs proposent un niveau de service par demande pour le traitement premium. OpenAI décrit le mode rapide comme une option par demande utilisant le paramètre
service_tieret indique qu'il est facturé à un prix plus élevé que le traitement standard. OpenAI indique également que le traitement prioritaire a été renommé Mode rapide le 30 juillet 2026, tandis queservice_tier=priorityetservice_tier=fastsont acceptés pour les requêtes API. - Fait : Le traitement des demandes Premium ne constitue peut-être pas un univers de quota distinct. OpenAI note que les limites de débit du mode rapide sont partagées avec d'autres niveaux de service et que des augmentations rapides du trafic peuvent déclencher un comportement d'augmentation du débit dans lequel une partie du trafic peut être envoyée au traitement standard à la place.
- Fait : Le niveau de service peut être une dimension de reporting et de facturation. OpenAI indique que les clients de l'API peuvent regrouper les données du tableau de bord d'utilisation par niveau de service et élément de ligne. Anthropic documente
standard,priorityetbatchcomme valeurs de niveau de service dans les rapports d'utilisation de l'API. - Fait : Les API par lots peuvent réduire considérablement les coûts du travail asynchrone. La documentation sur les tarifs d'Anthropic indique que son API Batch prend en charge le traitement asynchrone de gros volumes avec une réduction de 50 % sur les jetons d'entrée et de sortie. La documentation de l'API Gemini Batch de Google décrit d'importantes charges de travail asynchrones à 50 % du coût standard, avec des compromis en termes de délai d'exécution, par exemple jusqu'à 24 heures pour certaines tâches à volume élevé.
- Fait : Le débit provisionné est un modèle de capacité distinct. Microsoft documente le débit provisionné par Azure OpenAI comme une capacité dédiée, contrairement aux déploiements standard où la capacité est partagée et le débit peut varier en fonction de la demande. Microsoft documente également les répercussions des déploiements provisionnés vers les déploiements standard dans la même ressource Azure OpenAI.
Il est recommandé de ne pas refléter tous les termes du fournisseur dans le code de l'application. Il est recommandé de normaliser ces mécanismes en niveaux de passerelle orientés métier.
Définir des niveaux de passerelle indépendants du fournisseur
Commencez par nommer les niveaux en fonction du comportement de la charge de travail, et non de la terminologie du fournisseur. Une première taxonomie utile est :
interactive_fastinteractive_standardcapacité_réservéebackground_discountemergency_fallbackCette liste de niveaux est volontairement petite. Si vous créez vingt niveaux, les développeurs contourneront le système. La passerelle peut toujours mapper un niveau neutre à plusieurs mécanismes spécifiques au fournisseur en interne.
Séparer le niveau demandé du niveau sélectionné
L'appelant doit envoyer un niveau demandé, mais la passerelle doit enregistrer à la fois le niveau demandé et le niveau réellement sélectionné. Ce ne sont pas toujours les mêmes.
Exemple de métadonnées de requête :
{
"model": "support-chat-par défaut",
"messages" : [...],
"métadonnées": {
"workflow": "customer_support_reply",
"tenant_id": "tenant_123",
"requested_gateway_tier": "interactive_fast",
"end_user_id": "u_789"
}
Exemple d'enregistrement d'expédition :
{
"request_id": "req_abc",
"tenant_id": "tenant_123",
"api_key_id": "key_live_456",
"workflow": "customer_support_reply",
"model_alias": "support-chat-default",
"requested_gateway_tier": "interactive_fast",
"selected_provider": "provider_a",
"selected_provider_tier": "rapide",
"tier_outcome": "selected_as_requested",
"downgrade_reason": nul,
"input_tokens": 1840,
"output_tokens": 420,
"latency_ms": 1420,
"estimated_cost_usd": "0,0312",
"settled_cost_usd": "0,0308"
Si une demande de prime est envoyée au traitement standard en raison de limites de rampe ou de règles budgétaires des locataires, cela doit être visible :
{
"requested_gateway_tier": "interactive_fast",
"selected_provider_tier": "standard",
"tier_outcome": "déclassé",
"downgrade_reason": "tenant_premium_budget_exhausted"
Cette distinction évite les analyses trompeuses. Si les tableaux de bord affichent uniquement ce que l'appelant a demandé, la finance verra l'intention premium mais pas l'exécution premium. Si les tableaux de bord n'affichent que le résultat en amont, les équipes produit ne sauront pas quand leur flux de travail sensible à la latence s'est vu refuser la capacité premium.
Créer une matrice de capacités avant le routage
Un routeur de niveau service a besoin d'une matrice de capacités. La matrice doit répondre : pour un modèle, une région, un locataire et un workflow donnés, quels mécanismes de capacité sont disponibles ?
Champs minimum :
fournisseurmodel_or_deploymentrégionssupports_syncsupports_batchsupports_premium_tiersupports_provisioned_capacitysupports_spilloverprovider_tier_valuesbilling_line_itemsknown_downgrade_behaviortenant_allowlist
Un exemple simplifié :
gateway_tier_map :
interactif_fast :
préféré:
- fournisseur : openai
requête_params :
service_tier : rapide
- fournisseur : anthropique
requête_params :
service_tier : priorité
solution de repli :
- gateway_tier : interactive_standard
autorisé_quand : politique.allows_standard_downgrade
background_discount :
préféré:
- fournisseur : anthropique
mode : lot
- fournisseur : Gémeaux
mode : lot
solution de repli :
- file d'attente : delay_retry
autorisé_quand : vrai
capacité_réservée :
préféré:
- fournisseur : azure_openai
déploiement_class : provisionné
solution de repli :
- fournisseur : azure_openai
classe_deploiement : standard
autorisé_quand : policy.allows_spilloverCette matrice doit être une configuration et non du code dispersé. Les changements de nom des fournisseurs, la disponibilité régionale et le traitement de facturation changeront au fil du temps. La mise à jour d'une stratégie de passerelle est plus sûre que le redéploiement de chaque application qui appelle l'API.
Classez les charges de travail avant de choisir la capacité
Le plus difficile n'est pas le mappage des fournisseurs. Il s'agit de décider quelles demandes méritent quel niveau.
Bons candidats pour interactive_fast
- Assistants vocaux où le retard interrompt la conversation.
- Chat orienté client sur les chemins de conversion ou de fidélisation à forte valeur ajoutée.
- Opérations Human-in-the-loop où un agent attend activement.
- Incidents de production où la latence affecte directement l'atténuation.
Bons candidats pour interactive_standard
- Copilotes internes.
- Prend en charge la rédaction là où un humain peut tolérer un temps de réponse normal.
- Caractéristiques du produit pour lesquelles le temps de réponse est important mais n'est pas critique.
Bons candidats pour background_discount
- Résumé du soir.
- Enrichissement de documents volumineux.
- Évaluations hors ligne.
- Actualisations de l'intégration groupée.
- Étiquetage Analytics et génération de rapports.
Bons candidats pour reserved_capacity
- Charges de travail de production stables à volume élevé.
- Des charges de travail client sous contrat avec des engagements de débit prévisibles.
- Trafic qui ne peut pas tolérer les variations entre voisins bruyants et dont l'utilisation est suffisante pour justifier une capacité dédiée.
Une règle simple est la suivante : ne permettez pas aux appelants de choisir une capacité premium simplement parce qu'ils préfèrent la vitesse. Exiger un flux de travail déclaré, l'autorisation du locataire et une enveloppe budgétaire.
Appliquer les autorisations des locataires et des clés API
Chaque locataire et clé API doivent avoir un ensemble de niveaux autorisés. Les nouvelles clés doivent par défaut appartenir aux niveaux standard et en arrière-plan, et non aux niveaux premium.
Exemple de politique de locataire :
{
"tenant_id": "tenant_123",
"allowed_gateway_tiers": [
"standard_interactif",
"background_discount"
],
"premium_tier": {
"activé": faux,
"monthly_budget_usd": "0.00",
"approval_required": vrai
},
"capacité_réservée": {
"activé": vrai,
"deployment_pool": "support-prod-ptu",
"allow_spillover_to_standard": vrai,
"spillover_monthly_budget_usd": "500,00"
}
Exemple de remplacement au niveau de la clé :
{
"api_key_id": "key_voice_prod",
"allowed_gateway_tiers": ["interactive_fast"],
"workflow_allowlist": ["voice_control_loop"],
"premium_daily_budget_usd": "75,00",
"max_premium_traffic_percent": 15
La stratégie au niveau de la clé empêche toute expansion accidentelle. Un développeur ne peut pas prendre une clé destinée au trafic vocal et l'utiliser pour un script de synthèse groupée à moins que le flux de travail ne soit également autorisé.
Concevoir explicitement le comportement de rétrogradation et de débordement
Le comportement de rétrogradation est une décision concernant le produit, et pas seulement une décision concernant l'infrastructure. Lorsque la capacité premium ou provisionnée n'est pas disponible, la passerelle doit choisir l'une des quatre voies suivantes :
- Procéder selon la norme : utile lorsque la disponibilité importe plus que la cohérence de la latence.
- File d'attente : utile pour les tâches en arrière-plan et les charges de travail par lots.
- Échec rapide : utile lorsqu'une réponse lente serait pire qu'une absence de réponse, comme dans le cas de boucles étroites en temps réel.
- Demander à l'appelant de réessayer : utile lorsque le client peut réessayer en toute sécurité avec un délai d'attente et une clé d'idempotence préservée.
Exemple de stratégie :
downgrade_policy :
boucle_contrôle_voix :
request_tier : interactif_fast
if_fast_unavailable : fail_fast
code_erreur : tier_capacity_unavailable
customer_support_reply :
request_tier : interactif_fast
if_fast_unavailable : procédure_on_standard
record_outcome : déclassé
nightly_document_enrichment :
request_tier : background_discount
if_batch_unavailable : file d'attente
max_queue_delay_hours : 24
contracted_api_customer :
request_tier : capacité_réservée
if_reserved_exhausted : spillover_to_standard
require_spillover_budget : vraiNe cachez pas les retombées. Les retombées peuvent améliorer la disponibilité, mais elles modifient le coût et l’interprétation des SLO. Les factures et les analyses doivent indiquer la demande de capacité réservée, l'événement de débordement, la capacité standard réellement utilisée et la raison.
Connecter le routage au niveau du service à la facturation
Une passerelle ne peut pas contrôler les dépenses en primes si le choix du niveau ne fait pas partie du grand livre. Stockez ces champs pour chaque demande ou tâche :
- Niveau de passerelle demandé.
- Niveau de fournisseur ou classe de capacité sélectionné.
- Résultat du niveau : sélectionné, rétrogradé, mis à niveau, mis en file d'attente, débordement, rejeté.
- Raison du résultat.
- Identifiants de locataire, de clé API, d'utilisateur et de workflow.
- Alias du modèle et modèle ou déploiement en amont.
- Coût estimé avant expédition.
- Le coût réglé une fois l'utilisation du fournisseur connu est connu.
- Latence et nombre de tentatives pour les requêtes synchrones.
- Durée de soumission par lots, heure d'achèvement et état d'ingestion des résultats pour les tâches asynchrones.
Grâce à ces champs, la passerelle peut répondre aux questions que se poseront la finance et l'ingénierie :
- Quels locataires ont utilisé la capacité premium cette semaine ?
- Quels workflows ont généré les dépenses les plus élevées ?
- À quelle fréquence les demandes premium sont-elles rétrogradées vers la version standard ?
interactive_fasta-t-il suffisamment amélioré la latence p95 pour justifier la prime ?- Combien le traitement par lots en arrière-plan a-t-il permis d'économiser par rapport au traitement standard synchrone ?
- Quelle retombée standard la capacité provisionnée a-t-elle générée ?
La recommandation importante : facturer le niveau réellement utilisé, tout en affichant également le niveau demandé pour le contexte opérationnel. Sinon, les locataires seront soit surpris par le coût, soit induits en erreur sur la qualité du service.
Ajoutez des garde-corps pour que la prime ne devienne pas la valeur par défaut
Une fois que les équipes découvrent un niveau plus rapide, elles risquent d'en abuser. Fixez des limites à la passerelle avant un déploiement à grande échelle.
- Budget premium par locataire : plafonds mensuels et quotidiens stricts.
- Approbation du workflow : Premium autorisé uniquement pour les workflows nommés.
- Plafond de partage du trafic : par exemple, pas plus de 10 % des requêtes synchrones d'un locataire peuvent utiliser
interactive_fastsans approbation. - Alerte Standard vers Premium : alerte lorsqu'un flux de travail qui utilise normalement le standard est mis à niveau.
- Alerte de taux d'utilisation Premium : alerte lorsque les dépenses prévues dépassent l'enveloppe approuvée.
- Expiration automatique : les dérogations d'urgence temporaires doivent expirer sans nettoyage manuel.
- Vérifications d'éligibilité par lots : bloquez les tâches en masse des niveaux Premium synchrones lorsqu'elles répondent aux critères de lot.
Les garde-corps doivent être réversibles. Lors d'un incident, un opérateur agréé peut être amené à accorder une dérogation temporaire à la prime. Ce remplacement doit être accompagné d'un motif, d'un approbateur, d'un budget, d'un délai d'expiration et d'un enregistrement d'audit.
Séquence de mise en œuvre
Un déploiement sécurisé ne commence pas par l'activation du routage premium partout. Commencez par la mesure.
1. Ajouter une classification de niveau fantôme
Classez chaque demande dans un niveau de passerelle proposé, mais ne modifiez pas encore le routage. Enregistrez le niveau proposé à côté des métadonnées existantes en matière de latence, de coût et de flux de travail. Cela révèle la quantité de trafic qui serait transférée vers une capacité premium, par lots ou réservée si la politique était appliquée.
2. Créer la matrice des capacités
Répertoriez les mécanismes du fournisseur, les modèles pris en charge, les régions, les limites, les champs de rapport et le comportement de rétrogradation connu. Traitez les comportements de rétrogradation inconnus comme un risque jusqu'à ce qu'ils soient testés.
3. Appliquer les autorisations des locataires en mode simulation
Enregistrez si chaque demande sera autorisée, rétrogradée, mise en file d'attente ou rejetée. Partagez les résultats avec les propriétaires de produits avant l'application.
4. Activer un niveau pour une cohorte
Choisissez un flux de travail restreint, tel qu'un chemin de réponse d'assistance en direct ou une tâche de synthèse nocturne. Activez le niveau de passerelle approprié pour une petite cohorte de locataires. Mesurez la latence P50, la latence P95, le coût, le taux de rétrogradation, le taux d'erreur et les métriques commerciales destinées aux utilisateurs, le cas échéant.
5. Développez uniquement lorsque les données le prennent en charge
Si le niveau Premium améliore la latence mais pas les résultats du produit, limitez-le. Si le traitement par lots réduit les coûts sans nuire au comportement du produit, développez-le. Si la capacité provisionnée reste inactive, réexaminez l'engagement ou acheminez-y un trafic plus prévisible.
Compromis à rendre explicites
- Les niveaux Premium à faible latence peuvent améliorer la réactivité, mais ils peuvent partager des limites de débit ou déclencher des contraintes de rampe. Ils ne remplacent pas la définition des limites de débit.
- La capacité provisionnée améliore la prévisibilité, mais elle peut entraîner un gaspillage d'argent lorsque l'utilisation est faible. La capacité standard ou par lots peut être meilleure pour le trafic ponctuel ou tolérant la latence.
- Le traitement par lots peut réduire le coût des jetons, mais il modifie le comportement du produit, car les réponses sont asynchrones et peuvent arriver beaucoup plus tard.
- Les noms de niveaux indépendants du fournisseur simplifient le code de l'application, mais la passerelle doit maintenir une matrice de fonctionnalités à jour, car les fournisseurs utilisent des noms, des limites, des lignes de facturation et des comportements de rétrogradation différents.
- La rétrogradation automatique améliore la disponibilité, mais elle peut brouiller les attentes en matière de SLO et de facturation, à moins que la passerelle n'enregistre le niveau réellement utilisé.
- Des contrôles stricts des locataires évitent les dépenses surprises, mais des politiques trop rigides peuvent bloquer les flux de production urgents, à moins qu'il n'existe un chemin de remplacement contrôlé.
Prédiction : le niveau de service deviendra une dimension de routage de premier ordre
Prédiction : à mesure que les API de modèles évoluent, le niveau de service deviendra aussi important pour le routage de l'IA que le choix du modèle, la région et la fenêtre contextuelle. Les équipes ne se contenteront pas de demander « quel modèle doit répondre à cette question ? » Ils demanderont « quel modèle, sous quelle classe de capacité, pour quel budget locataire, avec quelle politique de déclassement ? »
Recommandation : Concevez dès maintenant le grand livre de passerelle et le modèle de stratégie afin que de nouvelles classes de capacité de fournisseur puissent être ajoutées sans modifier le code de l'application. Même si vous commencez uniquement avec standard et batch, utilisez des champs tels que requested_gateway_tier, selected_provider_tier et tier_outcome dès le début.
Liste de contrôle exploitable
- Ne définissez pas plus de cinq niveaux de passerelle indépendants du fournisseur.
- Exiger que chaque clé API déclare les niveaux et les flux de travail qu'elle peut utiliser.
- Créez une matrice de capacités du fournisseur pour les comportements premium, standard, provisionnés, par lots et de débordement.
- Enregistrer le niveau demandé, le niveau sélectionné, le résultat d'une rétrogradation ou d'un débordement, la latence, l'utilisation et le coût réglé.
- Nouvelles clés par défaut pour les niveaux standard ou en arrière-plan.
- Ajoutez des budgets premium, des plafonds de partage de trafic et des alertes.
- Rendre explicite le comportement de rétrogradation par workflow.
- Commencez par les métriques fantômes avant l'application.
- Déployez d'abord la capacité premium ou provisionnée auprès d'une petite cohorte.
- Développez-le uniquement lorsque la latence, la fiabilité ou les statistiques commerciales en justifient le coût.
Conclusion
Le routage au niveau des services appartient à la passerelle API AI, car il s'agit d'une décision politique transversale. Cela affecte la latence, les coûts, les quotas, les autorisations des locataires, les factures et les attentes opérationnelles. Les équipes d'application ne doivent pas coder en dur les noms de niveaux ou les classes de déploiement spécifiques au fournisseur uniquement pour exprimer l'urgence de la charge de travail.
Une passerelle pratique expose des niveaux neutres tels que interactive_fast, interactive_standard, reserved_capacity et background_discount. Il mappe ces niveaux sur des mécanismes spécifiques au fournisseur, applique les autorisations des locataires, enregistre le résultat réel et fait de la capacité premium une exception intentionnelle plutôt que le chemin par défaut.