Guide complet gratuit
Concevez une LLM inference gateway qui se place entre les équipes produit internes et plusieurs model providers/backends, en gérant le routing, le streaming, les quotas et les contrôles de sûreté à...
Le rythme de l’entretien reste compact, pour que la page consacre son attention aux vraies décisions de conception.
Ne vous contentez pas d’énoncer les besoins : demandez-les. Chaque carte associe la contrainte de conception à une question de clarification que vous pouvez dire à voix haute avant de dessiner l’architecture.
01Qui l'appelle — chaque équipe produit, ou seulement quelques-unes ?
Toutes les équipes l'appellent. La gateway est la seule porte vers les fournisseurs de modèles. Chaque équipe reçoit une clé d'API et chaque cas d'usage une politique, si bien que le failover, les quotas et la rédaction vivent à un seul endroit au lieu de quarante.
02Un provider commence à défaillir — à qui revient le problème ?
La gateway en est propriétaire. Chaque cas d'usage déclare une chaîne de repli de modèles compatibles en schéma, avec vérification de santé par fournisseur. Les réponses portent model_used et fallback_reason, pour que les appelants sachent quel modèle a répondu.
03Les utilisateurs regardent-ils la réponse apparaître mot à mot — le temps jusqu'au premier mot compte-t-il pour le produit ?
Oui — les tokens traversent la gateway dès l'instant où le provider les émet, jamais bufferisés ; la gateway compte les tokens en cours de stream pour que quota et coût voient aussi le trafic en streaming.
04Les limites se comptent-elles en requêtes ou en tokens ?
Les tokens. Une requête peut coûter 100 tokens ou 100 000, donc chaque équipe reçoit un débit en tokens par minute et un budget mensuel en dollars. Compter les requêtes passerait à côté du vrai coût.
05Le même prompt arrive mille fois — générer mille fois ?
Non — une répétition identique peut être répondue une fois puis réutilisée, mais uniquement au sein de l'équipe qui a demandé ; le trafic personnalisé ou propre à un utilisateur doit toujours être généré à neuf.
06Le provider livre une nouvelle version de modèle — qui met à jour, et quand ?
Politique par équipe. Une équipe peut épingler une version pour une sortie stable, ou prendre les mises à niveau au fil des livraisons du fournisseur. Les équipes qui épinglent reçoivent un compte à rebours le jour où le fournisseur déprécie leur modèle.
Hors périmètreEntraîner ou fine-tuner des modèles (uniquement servir le trafic) · Construire la stack de serving GPU elle-même (c'est du côté du provider) · Identité et sessions des utilisateurs finaux — les callers sont des services internes
01Combien de latence la gateway elle-même peut-elle ajouter ?
L'organisation fait environ 2M de requêtes par jour, et la gateway n'ajoute que ~10-20 ms sur le chemin de la requête. La latence du premier token est la métrique produit. La gateway ne doit jamais être la raison pour laquelle elle double.
02À quelle vitesse un provider mourant doit-il être détecté ?
Un fournisseur défaillant est détecté en quelques secondes, par fournisseur et par modèle. Combien de secondes est une décision produit. Chaque seconde de délai, ce sont plus de requêtes utilisateur qui échouent.
03Qu'est-ce qui est journalisé des prompts et des réponses ?
Les métadonnées sont toujours journalisées : tokens, modèle, coût, latence, trace id. Le contenu du prompt et de la réponse n'est journalisé qu'après le passage du hook de rédaction des PII (informations personnelles identifiables). Des prompts bruts dans les journaux transformeraient la gateway en incident de conformité.
04À quel point le plafond de budget d'une équipe est-il strict — si les requêtes arrivent en rafale juste à la limite, un léger dépassement est-il tolérable ?
Le plafond est absolu. Cent requêtes en parallèle ne doivent pas dépenser chacune le dernier dollar. Le budget d'une équipe ne peut jamais être dépassé par une rafale, car ce sont de vrais dollars facturés.
05La dépense s'envole à 2 h du matin — en combien de temps sait-on qui et pourquoi ?
Chaque appel atterrit dans un registre d'usage : équipe, cas d'usage, modèle, tokens, coût, et indicateurs de cache et de failover. L'attribution est interrogeable en quasi temps réel. Vous n'attendez pas de la reconstruire à partir des factures fournisseurs en fin de mois.
Les vrais entretiens sondent bien plus qu’une liste propre. Ces questions de périmètre séparent ceux qui interrogent le problème de ceux qui le récitent.
Traitez chaque estimation comme une pression qui justifie un composant : cache, file, partition, réplica, pool de workers ou chemin de repli.
Cost attribution — des tokens, pas des requêtes
Une équipe : 200,000 requêtes/jour, ~3,000 input + 800 output tokens chacune, à $3 par 1M input et $15 par 1M output tokens600M input × $3 + 160M output × $15 = $1,800 + $2,400 = $4,200/jour ≈ $126K/mois
Une limite de débit par requête ne peut pas voir cette facture du tout. Les quotas et budgets doivent se compter en tokens, avec entrée et sortie facturées séparément.
Budget de détection du failover
Le volume de l'organisation est de ~2M requêtes/jour (donné dans les NFR) : 2M ÷ 86 400 s ≈ 23 requêtes/s en moyenne, et un pic de journée de travail de ~4× la moyenne ≈ 100 requêtes/s, surtout sur le provider principal ; le circuit breaker utilise une fenêtre glissante de 10 s avec un seuil d'erreur de 20 %100 requêtes/s × 10 s ≈ 1 000 appels dans la fenêtre ; lors d'une panne totale, 20 % de 1 000 = 200 erreurs s'accumulent au bout de 200 ÷ 100 ≈ 2 s — donc ≈ 200 requêtes échouent avant que le circuit breaker ne s'ouvre
La longueur de la fenêtre fixe la douleur utilisateur que vous acceptez. Une fenêtre plus courte se déclenche plus vite mais oscille sur un à-coup d'une seconde. Choisissez-la comme un chiffre produit, et associez-la à des sondes half-open.
First token en streaming vs bufferisé
Une réponse de 800 tokens générée à ~60 tokens/s ; une gateway qui bufferise retient la réponse complète avant de la transmettrepremier byte bufferisé : 800 ÷ 60 ≈ 13 s ; premier token en pass-through : ~0.5-1 s → latence perçue ~15-25× pire
Chaque hop synchrone ajouté au chemin du stream est payé sur toutes les requêtes — le stream doit être inspecté en mouvement, jamais garé.
Économie du cache sémantique
2M requêtes/jour à l'échelle de l'org, 15% de taux de hit exact + sémantique combiné, ~$0.021 de coût provider par requête (d'après le calcul de tokens ci-dessus)300,000 hits × $0.021 ≈ $6,300/jour ≈ $190K/mois économisés ; un hit répond en ~50 ms au lieu de ~13 s
De l'argent réel et un énorme gain de latence — mais chaque hit est une chance de servir la mauvaise réponse, donc les clés doivent inclure le tenant, la version du modèle et la version du template.
Profondeur de file lors d'un brownout
Un brownout divise par deux le débit du provider primaire pendant 5 minutes au pic de ~100 requests/s : 100 arrivent, 50 servis, rien de délestéle backlog grossit (100 - 50) × 300 s = 15,000 requêtes ; à ~20 requests/s de capacité libre après reprise, le drainage prend encore ~12 minutes
Tout mettre en file transforme 5 minutes de brownout en ~18 minutes de dégradation et 15K connexions ouvertes — délestez plutôt le trafic batch et basculez le trafic interactif en failover.
Exemple de décision
Deux millions de requêtes par jour à travers quarante équipes, à environ deux cents chacune, ça fait à peu près 42 000 $ par jour de dépense fournisseur. Et chacun de ces fournisseurs a un blackout de quelques minutes une semaine du mois.
Je construirais un seul chemin de gateway. Il authentifie l'équipe, réserve max_tokens sur son budget, vérifie le cache exact puis sémantique, route selon la chaîne de modèles du cas d'usage avec un disjoncteur sur le taux d'erreur par fournisseur, et fait passer les tokens du fournisseur en flux direct tout en les mesurant au vol. L'usage se règle dans un registre par équipe. Le contenu du prompt ne touche les journaux qu'après le passage du hook de rédaction. Les versions de modèle sont une politique par équipe — épinglées avec un compte à rebours de dépréciation, ou mises à niveau automatiquement derrière un canary d'évaluation.
Ce que je NE ferais PAS. Premièrement, laisser les équipes appeler les fournisseurs directement — c'est quarante implémentations du failover et zéro attribution partagée. Deuxièmement, compter les requêtes pour le quota, puisqu'un ping de 100 tokens et une boucle d'agent de 100 000 tokens ne sont pas la même dépense. Troisièmement, mettre les flux en tampon pour les inspecter. Une gateway qui attend la réponse complète transforme un premier token à 1 seconde en 13 secondes de silence.
S'il y a une seule équipe, un seul modèle, et une dépense mensuelle à quatre chiffres, une simple bibliothèque cliente partagée avec des réessais est la réponse honnête. La gateway ne mérite sa complexité que lorsque les équipes, les fournisseurs ou la dépense se multiplient.
D’abord une image complète, puis chaque chemin comme son propre schéma — le chemin d’écriture et le chemin de lecture portent un trafic différent et justifient des composants différents.
Image complète
Le hot path est auth → réservation de budget → cache → route → stream ; l'ajustement du ledger et la tenue de la santé se tiennent en dehors. Un déclenchement de breaker ne change que le choix du router — les callers gardent le même contrat et voient simplement model_used changer.
Chemin 1
La gateway compte les tokens à mesure qu'ils circulent et ajuste le ledger de réservé à réel en fin de stream — quota et coût voient le trafic en streaming exactement comme des appels bloquants.
Chemin 2
Le fallback doit être schema-compatible avec le primaire, et la réponse dit quel modèle a répondu — une substitution silencieuse casse toute équipe qui dépend de la forme de sortie.
Avant d’optimiser, rendez le contrat inspectable : endpoints, entités, propriété, retries et état.
POST/v1/responses
req{ use_case, messages, max_tokens, stream: true, output_schema? }
résStream de tokens SSE ; les trailers portent model_used, le décompte des tokens, le coût, les flags cache/fallback
L'identité de l'équipe vient de l'API key, jamais du request body — un seul contrat devant chaque provider, si bien que changer de provider ne touche jamais au code produit.
GET/v1/usage (team_id, window=month)
rés{ tokens, cost_usd, by_model, by_use_case }
La cost attribution comme fonctionnalité produit — les responsables d'équipe et la finance lisent ceci, pas les factures du provider.
PUTinternal: policy(team_id, changes)
réspolicy hot-reloadée : pins, budgets, model chain, kill switch
Couper une équipe emballée est une écriture de config, pas un déploiement d'urgence.
Entités principales
TeamPolicyteam_id (PK) · use_case · model_chain (primary → fallbacks) · version_policy: pinned/auto · tokens_per_min · monthly_budget_usd · redaction_profile
Hot-reloadable — un changement de budget ou un kill switch ne doit pas attendre un déploiement.
UsageLedgerEntryrequest_id (PK) · team_id · model_used · input_tokens · output_tokens · cost_usd · cache_hit · fallback_reason?
La source de vérité de l'attribution — écrite comme une réservation avant l'appel, ajustée aux valeurs réelles après.
ProviderHealthprovider + model · error_rate (sliding window) · p95 latency · breaker: closed/open/half-open
Ce que le router lit avant chaque dispatch ; les sondes half-open décident quand le trafic est réautorisé.
CacheEntryembedding key · tenant_scope · model + template version · response · ttl
Un hit qui ignore l'une quelconque de ces clés, voilà comment part une réponse périmée ou d'un autre tenant.
Choisissez une voie pour le dernier tiers de l’entretien. Chaque voie vous donne le sujet, la question de l’examinateur à laquelle répondre, et le mode d’échec à éviter.
Un stream meurt au token 400 sur 800 avec un provider en 500. Que voit le client, et peut-on basculer en failover une génération in-flight ?
Terminez le stream par un événement d'erreur explicite. Ne devenez jamais silencieux, et n'insérez jamais des tokens d'un autre modèle — il ne finira pas la même phrase à moitié écrite. On ne peut pas reprendre une génération en plein vol, donc le failover est un redémarrage explicite sur le repli. Réglez l'appel mort dans le ledger pour les seuls 400 tokens qu'il a produits.
Régénérer silencieusement sur le provider B et raccorder les tokens — le client a déjà affiché la moitié d'une réponse, et le nouveau modèle ne produira pas la même suite ; reprendre, c'est redémarrer, et cela doit être explicite.
La boucle d'agent emballée d'une équipe a brûlé le budget mensuel de l'org en deux jours. Déroulez les contrôles qui auraient dû exister, dans l'ordre où ils auraient dû se déclencher.
Les contrôles réserver-puis-régler passent en premier. Chaque appel réserve son max_tokens d'avance et se règle à l'usage réel après, si bien que des boucles parallèles ne peuvent pas toutes dépenser le même dernier dollar. Ensuite, un plafond de tokens par minute par équipe ralentit la boucle. Une alerte de taux de consommation en dollars par heure l'attrape dès le premier jour — le plafond mensuel n'est que le filet de sécurité.
Une facture mensuelle comme seul contrôle — un comptage de tokens par appel, des caps par équipe et des alertes sur le TAUX de consommation (dollars par heure par rapport à la baseline) attrapent cela au jour un, pas au jour trente.
Un utilisateur change un mot critique dans le prompt et reçoit quand même la réponse en cache de l'ANCIEN prompt. Où le cache sémantique a-t-il fauté, et qu'est-ce qui le borne ?
L'erreur, c'était de se fier à la similarité seule. La négation inverse le sens à 0,98 de similarité cosinus, donc un prompt quasi identique n'est pas le même prompt. Faites d'abord une correspondance exacte et laissez l'étage sémantique s'abstenir dans le doute. Cadrez chaque entrée par clé : tenant, version du modèle, et version du template. Gardez le trafic personnalisé dehors, et donnez à chaque hit un TTL.
Le seuil de similarité comme toute la sécurité — la négation inverse le sens à 0,98 de similarité cosinus ; les clés ont besoin du tenant, du modèle et de la version du template, le trafic personnalisé reste dehors, et les hits portent un TTL.
Le provider annonce que votre modèle épinglé meurt dans 90 jours. À qui revient le problème, et à quoi ressemble le chemin d'upgrade de la gateway ?
La passerelle le fait remonter ; l'équipe décide. Le compte à rebours démarre le jour où le fournisseur annonce, pas au jour 90. Puis une porte d'éval : rejouez les prompts golden de l'équipe sur la nouvelle version, faites un canary sur une petite tranche live, basculez sur leur feu vert. Mettre à niveau en silence une équipe épinglée tue la stabilité pour laquelle elle a épinglé.
Auto-upgrader tout le monde en silence — les équipes épinglées pour la stabilité de sortie obtiennent un eval gate sur leurs propres golden prompts, une tranche de canary et une validation, avec le compte à rebours affiché dès le premier jour.
La sûreté ajoute un appel de modération synchrone avant la génération et la latence du first-token double. Comment gardez-vous à la fois le garde-fou ET le budget de latence ?
Lancez les contrôles en parallèle, pas devant. Déclenchez la modération d'entrée en même temps que le routage et l'envoi au fournisseur, et annulez la génération si elle échoue. Sa latence se cache alors derrière du travail déjà en cours. Pour la sortie, scannez le stream par fenêtres glissantes avec une coupure nette en plein flux — ne mettez pas en buffer une réponse de 13 secondes pour l'inspecter à la fin.
Sérialiser chaque vérification devant l'appel provider — les vérifications d'input tournent en parallèle du routing, et la modération d'output scanne le stream par fenêtres glissantes avec un cut-off, au lieu de bufferiser toute la réponse.
Expliquez passerelle d'inférence LLM à voix haute et obtenez une évaluation IA de votre explication.