Coût et latence d’inférence : dimensionner un service IA pour les pics de sinistres

Ce qu’il faut retenir

• Un service d’inférence pour la gestion de sinistres se dimensionne à partir d’un scénario de charge daté, de délais métier et d’un taux d’erreur admissible. Le prix affiché d’un modèle ne donne aucune de ces trois informations.
• Il faut séparer le temps d’attente, le temps de préparation, le premier résultat et la fin de la réponse. Une médiane correcte peut masquer une file incontrôlée au 95e ou au 99e percentile.
• La capacité utile est celle qui termine un dossier exploitable : appels de recours, validations, échecs, reprises humaines et stockage des preuves entrent dans le coût complet.
• Un pic se maîtrise d’abord par des priorités, des limites de file et des modes dégradés réversibles. Ajouter des accélérateurs sans politique d’admission peut simplement produire davantage de travail à reprendre.
• Le test décisif est un rejeu chronologique avec la distribution réelle des tailles et des tâches, suivi d’un exercice de saturation. Les optimisations sont retenues seulement si elles préservent la qualité et les délais de chaque voie métier.

Écrire le contrat de service avant de compter les GPU ou les jetons

« Dimensionner l’IA » n’est pas une exigence exploitable. Une équipe peut viser un accusé de réception en quelques secondes, une extraction documentaire dans la minute ou une proposition de synthèse avant la prise en charge par un gestionnaire. Ces sorties n’ont ni la même urgence, ni le même coût d’erreur, ni la même possibilité de traitement différé. Le premier livrable est donc un contrat par tâche, pas un nombre de machines.

Le contrat précise l’entrée admissible, la sortie attendue, le délai à partir duquel elle perd sa valeur, les contrôles obligatoires et le comportement en cas d’échec. Il distingue au minimum les voies interactives, où une personne attend, des traitements asynchrones, qui peuvent absorber une file. Une génération non validée n’est pas comptée comme terminée si le processus exige une vérification ou un passage en revue.

Voie	Début de l’horloge	Fin de l’horloge	Indicateur de qualité	Repli
Accueil du sinistre	réception du message	accusé fidèle et traçable	aucune promesse ou donnée inventée	message déterministe
Lecture d’une pièce	fichier disponible	champs contrôlés et provenance conservée	erreurs par champ et type de document	file documentaire
Orientation	dossier minimal complet	file et motif proposés	confusions pondérées par conséquence	tri manuel
Synthèse	sources autorisées figées	brouillon cité présenté au gestionnaire	couverture et fidélité aux pièces	vue documentaire classique

Les objectifs sont exprimés par percentile et par issue : p50, p95 et p99 des demandes acceptées, rejetées, escaladées et abandonnées. Un objectif moyen autorise quelques demandes extrêmement lentes à disparaître dans l’agrégat. Il faut aussi fixer la fraîcheur maximale d’un résultat asynchrone et l’âge de file qui déclenche une action.

Mesurer une demande de bout en bout, pas seulement le temps du modèle

La latence d’inférence pure est un morceau de la chaîne. Une trace utile sépare l’admission, l’attente, la préparation du contexte, le premier appel, la génération ou le calcul, les outils, la validation, les nouvelles tentatives et l’écriture du résultat. Pour un modèle génératif, deux mesures supplémentaires sont parlantes : le délai avant le premier jeton et le temps jusqu’au dernier jeton. Elles répondent à des expériences différentes.

Chaque trace porte une classe de tâche, une taille d’entrée, une taille de sortie, une version de route, une issue et un identifiant technique dissocié des données du dossier. La longueur seule ne suffit pas : deux requêtes de même taille peuvent mobiliser des outils différents ou traverser des files distinctes. La politique de routage entre modèles et procédures doit donc apparaître dans la mesure.

Le chronométrage commence avant l’appel au modèle. Sinon, un système peut afficher une inférence rapide tout en accumulant dix minutes de documents à prétraiter. Il se termine lorsque la sortie remplit le contrat métier, pas lorsque le fournisseur renvoie un statut HTTP. Une réponse rejetée par le validateur consomme de la capacité sans créer de résultat.

Segment de trace	Question opérationnelle	Erreur d’interprétation
Admission	la demande était-elle autorisée et complète ?	facturer au modèle un rejet qui pouvait être local
File	combien de temps et combien de demandes attendaient ?	attribuer la saturation au calcul seul
Préparation	quels documents, recherches ou transformations ont été nécessaires ?	oublier le coût des outils et du stockage
Exécution	quelle route, quelle version et quelle taille réelle ?	comparer des charges non équivalentes
Validation	la sortie a-t-elle été acceptée, reprise ou escaladée ?	compter toutes les réponses comme réussies

Construire le scénario de pic à partir des arrivées réelles

Un pic de sinistres n’est pas un multiplicateur uniforme. Les premières heures peuvent concentrer des déclarations courtes, puis les photographies et justificatifs arrivent, les relances se croisent et les gestionnaires consultent les dossiers en parallèle. La distribution des tâches, des formats et des longueurs change dans le temps. Le test doit conserver cette chronologie.

Le scénario de charge part d’un historique anonymisé et agrégé : arrivées par minute, catégories de tâche, percentiles de taille, pièces par dossier, taux de données manquantes et recours observés. Il exclut le contenu personnel du banc de charge lorsqu’une représentation synthétique suffit. Les valeurs extrêmes sont conservées comme classes de test au lieu d’être lissées.

1. Choisir la période. Identifier un épisode représentatif et dater la fenêtre de mesure.
2. Reconstruire les arrivées. Rejouer les horodatages relatifs plutôt qu’envoyer un lot instantané artificiel.
3. Préserver la composition. Maintenir proportions de tâches, tailles, langues, documents absents et échecs.
4. Ajouter des frontières. Tester des paliers au-dessus du maximum observé sans présenter ces scénarios comme une prévision certaine.
5. Introduire les pannes. Retard d’un fournisseur, accélérateur indisponible, base documentaire lente et file humaine saturée.
6. Mesurer le retour à l’équilibre. Vérifier l’âge maximal de file et le temps nécessaire pour résorber le stock.

Une campagne qui envoie toujours la même requête courte mesure surtout la stabilité d’un chemin heureux. La suite de recette doit contenir les demandes longues, les sorties longues, les lots de pages, les refus et les escalades. Les scénarios et leurs hypothèses sont versionnés avec les résultats.

Établir une courbe de capacité sous contrainte de délai

La capacité n’est pas un débit maximal isolé. C’est le débit soutenu tant que la qualité et les délais du contrat restent respectés. Pour chaque configuration, on augmente progressivement la concurrence, on mesure le débit terminé et les percentiles de latence, puis on repère le point où la file croît durablement. Ce point constitue une limite de service, pas une cible d’exploitation quotidienne.

La relation de Little relie le nombre moyen d’éléments dans un système, le débit moyen et le temps moyen passé dans le système, à condition d’observer un régime stable. Elle aide à vérifier la cohérence d’une mesure, mais ne remplace pas le test des pointes ni les percentiles. Une file qui augmente pendant le test indique précisément que le régime n’est plus stable.

Une première estimation de capacité peut utiliser le taux d’arrivée de pointe, le temps de service mesuré et un facteur de marge. Elle doit ensuite être corrigée par le temps de démarrage, les limites de concurrence, la mémoire, la taille des séquences et les dépendances. Un autoscaler réagit après observation ; il ne crée pas instantanément une capacité chaude. La documentation Kubernetes décrit d’ailleurs l’autoscaling comme une boucle périodique, capable d’utiliser des métriques personnalisées, avec une gestion spécifique des instances qui ne sont pas encore prêtes.

Pour comparer deux architectures, tracer sur un même graphique le débit terminé, le p95 de bout en bout, l’âge de la plus vieille demande, la qualité et le coût. Une configuration qui gagne en requêtes par seconde en dépassant le délai métier n’est pas meilleure. Les scénarios de MLPerf Inference illustrent cette séparation entre contraintes de latence et métriques de débit, mais leurs résultats ne préjugent pas de la charge documentaire d’un assureur.

Calculer le coût par résultat terminé

Le coût unitaire fournisseur constitue une entrée. Le dénominateur utile est le nombre de demandes qui produisent une sortie acceptée, et non le nombre d’appels lancés. Le numérateur agrège les appels principaux, les nouvelles tentatives, les modèles de recours, les outils, l’infrastructure réservée, le transfert, le stockage, l’observabilité, les licences, les contrôles humains et la reprise des erreurs.

Pour une période donnée, on peut écrire : coût par résultat terminé = coût total de la voie / nombre de résultats acceptés. Le tableau doit aussi présenter le coût par demande reçue et par dossier, car plusieurs demandes peuvent concerner la même affaire. Les coûts fixes et variables restent séparés afin de ne pas extrapoler une expérience peu chargée à une exploitation continue.

Poste	Unité de mesure	Preuve à conserver
Modèles externes	entrée, sortie, cache, outils et appels	version tarifaire datée et journal agrégé
Modèles hébergés	temps de calcul et capacité réservée	configuration, utilisation et énergie si disponible
Préparation	pages, recherches, conversions et stockage	trace par étape et volume
Qualité	validation automatique et échantillonnage	résultats des contrôles et taux de rejet
Reprise	minutes humaines et délais supplémentaires	motif, rôle et issue de la reprise
Capacité inutilisée	heures réservées non consommées	profil de charge et décision de marge

Le coût d’une erreur ne doit pas être transformé en chiffre précis sans donnée. Il peut être classé : reformulation locale, reprise opérationnelle, retard client, communication erronée, exposition de données ou influence sur une décision. Cette matrice sert à interdire certaines voies, à fixer l’échantillonnage et à arbitrer la dépense de validation.

Concevoir les files, l’admission et la dégradation avant le pic

Quand la demande dépasse la capacité, trois choix existent : attendre, refuser ou réduire le travail. L’absence de règle laisse ces choix aux timeouts et aux comportements implicites. Chaque file doit donc avoir une taille maximale, une priorité, un délai d’expiration, une politique de nouvelle tentative et une issue de secours.

La priorité ne doit pas découler d’un prompt. Elle est calculée à partir d’attributs métier autorisés : tâche, canal, délai contractuel, état du dossier et besoin d’une personne. La file interactive ne doit pas être bloquée par un traitement analytique volumineux. Les traitements différables peuvent être mis en pause, mais restent visibles avec leur âge et leur volume.

La dégradation préserve une fonction minimale connue. Par exemple, l’accueil peut utiliser un accusé déterministe sans résumé ; l’extraction peut conserver OCR et classement mais suspendre la génération ; la synthèse peut devenir un affichage ordonné des pièces. Le découpage entre règles, estimation et génération rend ces replis possibles.

Signal	Action bornée	Condition de retour
âge de file en hausse continue	fermer les voies différables et plafonner les entrées	âge sous seuil pendant une fenêtre définie
p95 interactif hors objectif	basculer vers la réponse minimale	capacité chaude vérifiée
taux de validation en baisse	arrêter la route concernée, sans augmenter les reprises	cause identifiée et non-régression passée
fournisseur indisponible	activer route de secours ou file humaine	test de santé puis ouverture progressive
budget journalier atteint	réserver la dépense aux tâches prioritaires	nouvelle enveloppe explicitement validée

NVIDIA Triton documente le regroupement dynamique de demandes ainsi que des propriétés de file, des niveaux de priorité et des délais. Ces mécanismes ne définissent pas la politique métier : ils l’exécutent. De même, un autoscaler fondé uniquement sur le CPU peut réagir trop tard si la contrainte réelle est l’âge d’une file, la mémoire ou une limite externe.

Évaluer les optimisations d’inférence après la baseline

Le batching améliore souvent l’utilisation d’un accélérateur, mais il peut attendre quelques millisecondes pour former un lot et donc pénaliser les voies les plus urgentes. La taille de lot, le délai maximal et la compatibilité des formes se règlent sur la courbe de capacité. Les requêtes très hétérogènes peuvent nécessiter des files ou des règles de regroupement distinctes.

La quantification, la compilation, le cache de préfixe, la gestion du cache clé-valeur et le speculative decoding modifient des compromis différents. Le papier sur PagedAttention traite de la gestion mémoire pour servir des modèles de langage ; celui sur le speculative decoding montre une méthode visant à accélérer la génération sans changer sa distribution cible dans le cadre étudié. Aucun résultat publié ne garantit le gain d’un dossier d’assurance particulier.

Une optimisation passe quatre portes : sortie fonctionnellement comparable, absence de régression sur les cas critiques, gain mesuré sous le profil de charge cible et comportement sûr en saturation. Le gain de débit seul ne suffit pas. Le recours à un modèle plus compact pour une tâche bornée est souvent plus simple à expliquer et à isoler qu’une optimisation générale du modèle le plus lourd.

Pour chaque essai, conserver modèle, moteur, matériel, précision, paramètres de batching, limites de contexte, concurrence et versions. Sans cet inventaire, une comparaison ultérieure mélange le bénéfice du moteur, du modèle et de la charge. Les prix et quotas externes sont datés plutôt que recopiés comme constantes durables dans l’architecture.

Scénario pédagogique : absorber un afflux après un événement climatique

Le scénario suivant est hypothétique et ne décrit aucun résultat client. Après un événement climatique, le volume de déclarations augmente. L’objectif du système est de préserver l’accueil, préparer des informations et ordonner le travail. Il ne décide ni garantie, ni responsabilité, ni indemnisation.

La voie A accuse réception à partir des données effectivement reçues. Elle utilise un texte déterministe quand le service génératif dépasse son délai. La voie B contrôle format et lisibilité des pièces puis envoie les documents compatibles vers une chaîne dédiée. La voie C prépare une orientation à partir d’une taxonomie limitée. La voie D assemble un brouillon de synthèse cité pour les dossiers suffisamment complets.

Les quatre voies n’entrent pas dans la même file. L’accueil possède une capacité minimale réservée. L’analyse documentaire est asynchrone et publie son âge de file. La synthèse s’interrompt avant l’accueil lorsque la capacité se resserre. Les sorties invalides ne sont pas renvoyées plusieurs fois sans limite : elles passent dans une file d’exception avec un motif.

1. Heure normale. Mesurer la distribution de tailles, les taux d’acceptation et le coût complet.
2. Montée progressive. Rejouer les arrivées jusqu’au point où l’âge de file commence à croître.
3. Activation des priorités. Vérifier que l’accueil respecte encore son contrat quand les lots documentaires attendent.
4. Perte d’une dépendance. Couper la route principale et observer le repli, les doublons et la récupération.
5. Retour à la normale. Résorber le stock sans rouvrir toutes les voies simultanément.

La réussite n’est pas « aucune file ». Une file bornée peut absorber un pic. La preuve attendue est que les demandes critiques gardent leur délai, que les demandes différées restent visibles, que le stock se résorbe dans une durée acceptable et que la qualité ne baisse pas silencieusement.

Organiser la recette et l’exercice de saturation

La recette réunit produit, gestion, architecture, sécurité, exploitation et contrôle des coûts. Elle emploie un jeu de charge reproductible et un jeu fonctionnel indépendant. Un test de performance sans vérification des sorties peut récompenser une configuration qui tronque, refuse ou simplifie trop de demandes.

Porte de recette	Preuve	Échec bloquant
Fonction	sorties acceptées par tâche et segment	erreur interdite ou preuve manquante
Délai	p50, p95, p99 et âge de file par issue	voie critique hors contrat
Capacité	débit terminé en régime stable	file qui croît sans mécanisme de protection
Coût	coût par demande, résultat et dossier	reprises ou capacité réservée absentes du calcul
Dégradation	repli déclenché, observé et annulé	coupure non maîtrisée ou doublons
Récupération	temps de résorption et cohérence des états	stock invisible ou demandes perdues

Les résultats sont présentés sous forme de courbes, pas seulement d’un meilleur point. Il faut voir où la qualité, le délai ou le coût se dégrade. Toute nouvelle version de modèle, de moteur, de matériel ou de politique repasse un sous-ensemble sentinelle et le scénario de charge qui couvre son changement.

Piloter la production avec des seuils et une réversibilité testée

Le tableau de bord opérationnel suit simultanément arrivées, débit terminé, âge des files, taux d’acceptation, escalades, latence par segment, coût complet et santé des dépendances. Une alerte isolée sur l’utilisation d’un accélérateur n’indique pas si les dossiers avancent. À l’inverse, une utilisation basse peut être normale si la charge est faible ou signaler une file bloquée en amont.

Les seuils déclenchent des actions connues : réduire une concurrence, fermer une voie, revenir à un modèle précédent, suspendre les tâches différables ou basculer vers une procédure humaine. Le NIST AI RMF recommande de relier les mesures au contexte de déploiement et de surveiller le système en exploitation. Cette discipline complète l’observabilité technique par une lecture du risque et des impacts.

Le rapport mensuel rapproche les prévisions des valeurs observées : composition des tâches, tailles, appels de recours, capacité inutilisée, temps humain et incidents. Il indique les hypothèses devenues fausses. Le budget suivant est établi sur cette réalité, sans présenter le coût du fournisseur ou un benchmark public comme une facture prévisionnelle certaine.

Sources et références primaires

• NVIDIA Triton Inference Server — Model Configuration : documentation officielle sur le scheduling, le dynamic batching et les politiques de file.
• Kubernetes — Horizontal Pod Autoscaling : documentation officielle sur la boucle d’autoscaling, les métriques et l’état de préparation.
• MLCommons — MLPerf Inference Datacenter : scénarios, contraintes de latence, métriques de débit et règles de conformité.
• Efficient Memory Management for Large Language Model Serving with PagedAttention : publication primaire sur la gestion du cache et le serving de modèles de langage.
• Fast Inference from Transformers via Speculative Decoding : publication primaire ; les gains dépendent du modèle, du matériel et de la charge étudiés.
• NIST AI Risk Management Framework : cadre officiel de mesure, suivi et gestion des risques d’un système IA.
• EIOPA — Generative AI Market Survey : publication institutionnelle sur les usages et la gestion des risques dans l’assurance.