Réduisez les coûts de l'API LLM grâce aux tâches par lots et à la mise en cache des invites : un manuel pratique

De nombreuses équipes paient trop cher pour les API LLM, car elles envoient chaque requête via le même chemin synchrone. Cela convient au chat, aux assistants de codage, aux agents de support, aux flux de paiement et à tout ce qui attend un utilisateur. C'est un gaspillage pour les évaluations, le marquage, l'enrichissement, les balayages de modération, l'intégration de remplissages, les rapports nocturnes et le prétraitement du contenu.

La question pratique n'est pas : Quel modèle est le moins cher ? » La question est : quel travail nécessite réellement une réponse immédiate et quel travail peut attendre ? Une fois que vous avez répondu à cette question, le contrôle des coûts des API d'IA devient un workflow d'ingénierie : classer le trafic, envoyer les tâches tolérantes à la latence au traitement par lots lorsque cela est pris en charge, structurer des invites répétées pour la mise en cache et mesurer les économies réelles après des échecs, des tentatives et des frais opérationnels.

Commencez par un audit des coûts par charge de travail et non par modèle

Avant de modifier l'architecture, exportez un échantillon d'utilisation récente de l'API et regroupez-le par charge de travail. Un tableau d'audit utile devrait inclure :

• Point de terminaison et modèle : achèvements de chat, réponses, intégrations, modération ou points de terminaison spécifiques au fournisseur.
• Jetons d'entrée et de sortie moyens : séparez les invites longues des tâches de classification courtes.
• Forme d'invite : instructions système stables, exemples réutilisables, schémas, contexte de récupération et données utilisateur dynamiques.
• Exigence de latence : secondes, minutes, heures ou jour ouvrable suivant.
• Visibilité de l'utilisateur : indique si une personne attend le résultat.
• Taux de tentatives et d'échecs : demandes mal formées, échecs de validation, délais d'expiration du fournisseur, tâches expirées et soumissions en double.
• Propriété : projet, équipe, client, clé API ou compte partenaire.
• SLA Business : la dernière fois où le résultat est encore utile.

Cet audit révèle généralement que le « trafic LLM » ne constitue pas une seule charge de travail. Il s'agit d'un mélange de fonctionnalités de produit interactives, d'automatisation interne, de reporting, de préparation des données et d'évaluation de la qualité. Les traiter comme un seul centre de coûts cache les économies les plus faciles.

Utilisez un classificateur de charge de travail à trois voies

Un simple classificateur empêche les équipes de déplacer le mauvais trafic vers le lot et d'être ensuite surprises par des attentes manquées.

Voie 1 : requêtes interactives en temps réel

Gardez-les synchrones. Ils incluent le chat UX, les copilotes, les agents d'assistance, l'examen humain dans la boucle, les flux de recherche ou de récupération en direct et les appels d'outils avec des effets secondaires immédiats. Si un utilisateur attend, la valeur d'une réponse moins chère peut être effacée par la latence.

Recommandation : optimisez cette voie avec la sélection de modèles, le découpage rapide, la gestion des limites de débit, la mise en cache le cas échéant et les nouvelles tentatives minutieuses. Ne l'envoyez pas dans une file d'attente par lots de 24 heures à moins que le produit ne le présente explicitement comme tâche en arrière-plan.

Voie 2 : requêtes Nearline pouvant attendre quelques minutes

Ces tâches n'ont pas besoin de bloquer le chargement d'une page, mais elles peuvent toujours avoir une attente de même session ou de même heure. Les exemples incluent l'analyse de document après le téléchargement, l'enrichissement CRM après la soumission du formulaire ou un rapport qui peut informer l'utilisateur lorsqu'il est prêt.

Recommandation : placez le travail Nearline derrière une file d'attente avec des états d'état explicites. En fonction du support du fournisseur et du délai, exécutez-le via de petits lots ou des travailleurs synchrones avec une priorité inférieure. Cette voie bénéficie d'ID de tâche, de webhooks et de progrès visibles par l'utilisateur.

Voie 3 : requêtes par lots hors ligne pouvant attendre jusqu'à 24 heures

Il s'agit de la principale voie d'optimisation des coûts. Les bons candidats incluent :

• évaluations à grande échelle ;
• Étiquetage des ensembles de données ;
• Enrichissement du catalogue ou du CRM ;
• résumé nocturne ;
• files d'attente d'examen de conformité ;
• intégration des remplissages ;
• balayages de modération ;
• génération de rapports périodiques ;
• Prétraitement du contenu avant l'indexation ou la publication.

Fait : les principaux fournisseurs proposent désormais des API par lots asynchrones pour les charges de travail adaptées. L'API Batch d'OpenAI lit les requêtes d'un fichier téléchargé, écrit les résultats dans un fichier de sortie et cible le traitement dans les 24 heures. OpenAI indique que l'utilisation de l'API Batch prise en charge est proposée avec une réduction de 50 % par rapport aux API synchrones. L'API Message Batches d'Anthropic est conçue pour de grands volumes de requêtes de messages, un traitement asynchrone, un débit plus élevé et un coût 50 % inférieur. L'API Gemini Batch de Google est conçue pour traiter de gros volumes de requêtes asynchrones à 50 % du coût standard, avec un délai d'exécution cible de 24 heures.

Compromis : « jusqu'à 24 heures » est excellent pour les remplissages et les évaluations, mais inacceptable pour les flux de travail interactifs. Le traitement par lots est une stratégie de planification, et non un remplacement universel de l'inférence synchrone.

Concevoir le chemin du lot comme un cycle de vie de tâche

L'erreur d'implémentation à éviter est de traiter le batch comme un seul appel d'API. Il s'agit d'un cycle de vie : accepter le travail, le valider, le conserver, le soumettre, l'interroger, le réconcilier et exposer les résultats.

Architecture de référence

1. Accepter une requête normalisée : gardez la forme de la requête proche de votre format d'API compatible OpenAI existant lorsque cela est possible. Ajoutez des métadonnées telles que le projet, l'équipe, le client, la clé d'idempotence, le délai demandé et le centre de coûts.
2. Classez la charge de travail : attribuez la requête à un lot en temps réel, en quasi-ligne ou hors ligne. Cela doit être basé sur des règles et non caché dans le code de l'application.
3. Créez un identifiant de tâche : renvoie immédiatement un identifiant de tâche pour le travail en ligne et hors ligne.
4. Valider la compatibilité : vérifiez si le fournisseur et le modèle sélectionnés prennent en charge le lot pour le point de terminaison, la modalité, la taille du fichier, les outils, le format de réponse et d'autres fonctionnalités demandés.
5. Conserver les lignes de requête : stockez les lignes JSONL normalisées ou les charges utiles spécifiques au fournisseur. Incluez un ID de ligne stable pour le rapprochement.
6. Soumettre le lot : téléchargez le fichier de requête ou la charge utile du lot en ligne en fonction des limites du fournisseur et de la taille de la tâche.
7. Statut de l'interrogation : suivez les états du fournisseur tels que validation, en cours, terminé, échoué, expiré, annulation et annulé, le cas échéant.
8. Stocker les lignes de sortie : écrire les réponses réussies, les erreurs au niveau des lignes, l'utilisation des jetons, le nombre de jetons mis en cache lorsqu'ils sont disponibles et les identifiants du fournisseur.
9. Avertir les consommateurs : exposer un point de terminaison de récupération, un webhook, une notification de tableau de bord ou une alerte Telegram.
10. Rapprocher la facturation : attribuez le coût au projet, à l'équipe, au client, à la clé API et à l'ID de tâche d'origine.

Ce modèle simplifie l'application. Les équipes produit soumettent des travaux et reçoivent des états de tâches. La passerelle ou la couche d'orchestration gère les différences entre les fournisseurs, les fichiers batch, les tentatives et la comptabilité.

Utiliser des états de travail explicites

Définissez les états internes même si chaque fournisseur utilise des noms différents :

• en file d'attente : accepté mais non soumis ;
• validation : le fournisseur ou la passerelle vérifie le fichier ;
• en cours d'exécution : soumis et en cours de traitement ;
• terminé : tous les résultats disponibles collectés ;
• completed_with_errors : certaines lignes ont échoué à la validation ou à l'exécution ;
• expiré : délai dépassé avant que toutes les lignes ne soient complétées ;
• annulé : arrêté par l'utilisateur, le système ou la stratégie ;
• échec : échec au niveau de la tâche nécessitant une intervention.

Fait : OpenAI documente les statuts des lots, notamment validation, échec, en cours, terminé, expiré, annulation et annulé. Il note également que si un lot expire, le travail déjà terminé est renvoyé et facturé tandis que le travail restant est annulé.

Recommandation : ne présumez jamais que les tâches par lots sont tout ou rien. Créez dès le début la gestion des statuts au niveau des lignes.

Calculer les économies après pannes et frais généraux

Un modèle d'économies simple suffit à la plupart des équipes :

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
ajusté_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimate_ savings = baseline_cost - ajusté_batch_cost

Ensuite, calculez cela par charge de travail, et non globalement. Une suite d’évaluation nocturne peut permettre des économies substantielles. Un workflow quasi-ligne avec de nombreuses lignes mal formées, des solutions de secours urgentes ou des réexécutions répétées peuvent enregistrer moins que prévu.

Suivez au moins ces statistiques :

• synchronisation par rapport aux dépenses en jetons par lots ;
• Jetons d'entrée et de sortie par modèle ;
• Nombre de tâches par lots et nombre moyen de lignes par tâche ;
• taux d'échec au niveau des lignes ;
• taux d'emploi expiré ;
• coût de réexécution ;
• coût de repli pour la synchronisation ;
• coût par équipe, projet, clé, client et compte partenaire

Recommandation : traitez le repli synchrone automatique comme une exception et non comme une valeur par défaut. Il protège les délais, mais s’il est trop utilisé, il peut effacer les économies attendues. Ajoutez une stratégie telle que "repli uniquement si le délai commercial est dans les deux heures et que le travail n'a pas commencé".

Ajouter une mise en cache des invites pour les préfixes longs répétés

Le traitement par lots réduit le prix unitaire des travaux éligibles. La mise en cache des invites réduit le coût effectif et la latence des longues invites répétées lorsque le comportement du fournisseur le permet.

Fait : la mise en cache des invites OpenAI s'applique automatiquement aux invites de plus de 1 024 jetons sur les modèles pris en charge, met en cache le préfixe calculé le plus longtemps précédemment et signale les cached_tokens dans les détails d'utilisation de l'API. OpenAI indique que les caches d'invites sont généralement effacés après 5 à 10 minutes d'inactivité et supprimés dans l'heure suivant la dernière utilisation, et que les caches d'invites ne sont pas partagés entre les organisations.

Le modèle de mise en œuvre est simple : placez le contenu stable en premier et le contenu volatil en dernier.

Meilleure structure d'invite pour la mise en cache

Instructions système
Texte de politique stable
Schéma de sortie stable
Exemples stables
Contexte de référence réutilisable
---
Saisie dynamique spécifique à l'enregistrement
Métadonnées dynamiques d'utilisateur ou de ligne

Par exemple, une tâche d'enrichissement de catalogue peut réutiliser la même taxonomie, le même schéma de sortie, les mêmes règles de marque et les mêmes exemples sur 50 000 produits. Chaque ligne modifie uniquement le titre, la description et les attributs du produit. Placer le préfixe réutilisable en premier donne au fournisseur une meilleure chance de réutiliser les calculs mis en cache lorsqu'ils sont pris en charge.

Compromis : la mise en cache n'est pas un stockage permanent et ne doit pas être considérée comme garantie. Les fenêtres de cache, l'isolation, la longueur minimale des invites et les rapports diffèrent selon le fournisseur. Mesurez les jetons mis en cache plutôt que de supposer des économies.

Valider le support du fournisseur avant la soumission

Les API par lots diffèrent. La passerelle doit valider l'éligibilité avant de soumettre une tâche.

Faits : L'API OpenAI Batch ne prend pas en charge le streaming et a des limites de débit de lot distinctes. Anthropic documente les limitations des lots, notamment une limite de taille de lot de 100 000 requêtes ou 256 Mo, une expiration de 24 heures, une disponibilité des résultats de 29 jours, des limites de débit et la possibilité que les lots dépassent légèrement les limites de dépenses d'espace de travail configurées. Google prend en charge les requêtes par lots en ligne pour les petites tâches de moins de 20 Mo et les fichiers d'entrée JSONL pour les requêtes par lots plus volumineuses.

Utilisez une liste de contrôle de compatibilité :

• Le modèle demandé est-il disponible via l'API batch de ce fournisseur ?
• Le point de terminaison est-il pris en charge ?
• La demande nécessite-t-elle une diffusion en continu ? Si oui, rejetez le lot.
• Utilise-t-il des outils ou des effets secondaires qui doivent se produire immédiatement ?
• Le fichier batch dépasse-t-il les limites du fournisseur ?
• Le résultat attendu est-il toujours utile dans le délai d'achèvement du fournisseur ?
• Les résultats sont-ils disponibles suffisamment longtemps pour que les systèmes en aval puissent les récupérer ?
• La charge de travail peut-elle tolérer une exécution partielle ?

Recommandation : échec de la validation prématurément avec une raison claire. Un candidat par lot rejeté est moins cher qu'un travail expiré ou mal formé qui doit être retravaillé ultérieurement.

Garanties pour les équipes, les agences et les partenaires

Les systèmes batch peuvent tranquillement dépenser beaucoup d'argent car ils traitent des fichiers volumineux en arrière-plan. Ajoutez des contrôles avant un déploiement à grande échelle :

• Budgets par lots par équipe : des limites de dépenses en ligne et hors ligne sont séparées.
• Taille maximale des fichiers et nombre de lignes : appliquez les limites du fournisseur et vos propres limites opérationnelles.
• File d'attente de lettres mortes : conserve les lignes non valides contenant des erreurs de validation pour examen.
• Clés d'idempotence : évitez que des accusations en double ne soient soumises à nouveau accidentellement.
• Vérification des informations personnelles : les fichiers batch peuvent créer de nouvelles obligations en matière de conservation des données et de confidentialité.
• Politique de conservation : définissez la durée de stockage des fichiers de requête, des fichiers de sortie et des journaux.
• Règle de notification : alertez les propriétaires lorsque les tâches échouent, expirent ou dépassent le budget.
• Attribution : enregistrez le projet, l'équipe, le client, la clé API, le modèle, le fournisseur, l'ID de tâche et l'ID de ligne.

Pour les agences et les revendeurs, l'attribution est particulièrement importante. Si un partenaire exécute des tâches d'enrichissement ou d'évaluation pour plusieurs clients, le système doit indiquer le coût par client et par tâche, et pas seulement par facture du fournisseur.

Comment cela correspond à une passerelle API IA

Une passerelle API IA est un endroit naturel pour mettre en œuvre cela, car elle se situe déjà entre les applications et les fournisseurs de modèles. La passerelle peut préserver une surface d'API compatible OpenAI pour les développeurs tout en ajoutant une planification tenant compte des coûts.

Les fonctionnalités utiles de la passerelle incluent :

• Facturation unifiée : comparez les dépenses synchrones, par lots, mises en cache et de secours en un seul endroit.
• Analyse de l'utilisation de l'IA : répartissez l'utilisation par modèle, fournisseur, point de terminaison, équipe, projet et clé API.
• Contrôles d'équipe : définissez des budgets distincts pour les charges de travail interactives et hors ligne.
• Attribution de clé API : identifiez le service ou le client qui a créé chaque emploi.
• Notifications d'état : envoyez des alertes lorsque des tâches par lots sont terminées, échouent, expirent ou approchent d'une date limite.
• Flux de travail de l'API partenaire : permet aux agences ou aux revendeurs de créer des tâches et de récupérer des résultats pour le compte des clients tout en préservant la comptabilité au niveau du client.

Prédiction : davantage d'équipes géreront les coûts LLM avec des politiques de planification, et pas seulement avec des substitutions de modèles. À mesure que la prise en charge par lots évolue parmi les fournisseurs, l'architecture gagnante sera acheminée par urgence, compatibilité des fonctionnalités et exigences comptables avant d'être acheminée par prix du modèle.

Liste de contrôle de mise en œuvre

• Exportez 30 jours d'utilisation de l'API LLM.
• Classez chaque charge de travail en temps réel, quasi-en ligne ou hors ligne.
• Choisissez une charge de travail hors connexion dont la responsabilité est claire et dont le délai est indulgent.
• Valider la prise en charge par lots du fournisseur pour le point de terminaison et le modèle requis.
• Définissez les états de tâche internes et les statuts au niveau des lignes.
• Ajoutez des clés d'idempotence, des ID de tâche et des ID par ligne.
• Stockez les enregistrements normalisés de demandes et de réponses avec des contrôles de conservation.
• Envoyez le premier lot derrière un indicateur de fonctionnalité.
• Mesurez le coût de référence synchrone par rapport au coût de lot ajusté.
• Restructurez les invites longues et répétées pour placer les préfixes stables en premier.
• Suivez les jetons mis en cache, les lignes ayant échoué, les tâches expirées et les dépenses de secours.
• Développez-le uniquement une fois que les économies et le comportement opérationnel sont visibles dans les analyses.

Conclusion exploitable

Ne démarrez pas le contrôle des coûts de l'API IA en demandant à chaque équipe d'utiliser un modèle moins cher. Commencez par séparer le travail urgent du travail qui peut attendre. Gardez les requêtes interactives synchrones. Déplacez les évaluations, l'enrichissement, le balisage, les remplissages, les balayages de modération et les rapports par lots lorsque le support du fournisseur et les délais commerciaux s'adaptent. Structurez de longues invites répétées pour la mise en cache. Mesurez ensuite les économies réelles après les pannes, les réexécutions, le stockage et les coûts de secours.

La meilleure mise en œuvre est volontairement ennuyeuse : ID de tâche, validation, statuts au niveau des lignes, budgets, analyses d'utilisation et propriété claire. C'est cette couche opérationnelle qui transforme les remises des fournisseurs en économies fiables.

Lecture connexe

• Attribution des clés API et contrôles des dépenses des équipes
• politiques de routage, de tentatives et de secours pour les API LLM
• notes d'implémentation liées à Model Gate