Optimiser les LLM : 12 stratégies pour réduire coûts et latence

Introduction aux défis des LLM en production

Les modèles de langage de grande taille, ou LLM, sont devenus des outils essentiels dans de nombreuses applications modernes. Cependant, leur mise en production peut rapidement révéler des défis inattendus en termes de coûts et de latence. Lors des phases de prototypage, les systèmes semblent souvent fonctionner sans accroc : les utilisateurs sont peu nombreux, les appels au modèle sont limités, et les prompts sont courts, ce qui entraîne des temps de réponse acceptables. Mais une fois en production, la réalité change. Les pics de trafic peuvent surcharger le système, les demandes s'accumulent, et les conversations s'allongent. Les pipelines de génération augmentée par récupération (RAG) ajoutent des couches de complexité en intégrant de larges contextes à chaque prompt. Les agents, qui auparavant ne sollicitaient qu'un seul outil, en appellent désormais plusieurs, et les limites de sortie généreuses initialement fixées augmentent insidieusement la latence et les coûts. La clé pour résoudre ces problèmes ne réside pas nécessairement dans l'acquisition de meilleurs modèles ou de plus de GPU, mais plutôt dans l'optimisation des tâches existantes : réduire le nombre de tokens, diminuer les appels, utiliser des modèles plus petits pour des tâches simples, réutiliser efficacement le cache, et minimiser le temps passé dans les files d'attente.

1. Mesurer les bonnes métriques de latence

Avant de chercher à optimiser, il est crucial de comprendre où le temps est réellement dépensé. La latence de bout en bout est une mesure utile, mais elle ne suffit pas à identifier les causes d'une réponse lente. Un système LLM en production doit suivre plusieurs métriques clés :

• Temps d'attente : la durée pendant laquelle une demande reste en attente avant le début du traitement.
• Temps jusqu'au premier token (TTFT) : le délai avant que l'utilisateur ne voie le premier token de la réponse en streaming.
• Latence inter-token : la vitesse à laquelle le modèle génère chaque token suivant.
• Latence de bout en bout : le temps total écoulé de la demande à la réponse complète.
• Comptes de tokens d'entrée et de sortie : principaux facteurs influençant le coût d'inférence.
• Taux de réussite du cache : fréquence à laquelle les caches de prompt, de récupération ou de réponse évitent un travail répété.
• Latence des outils et de récupération : temps passé en dehors du modèle lui-même.
• Latence P50, P95 et P99 : ces mesures de latence des queues sont souvent plus pertinentes que la moyenne.

Par exemple, un TTFT élevé peut signaler des prompts trop longs, une récupération lente ou une file d'attente. Une latence inter-token élevée peut indiquer un modèle surdimensionné, un GPU surchargé, une mauvaise configuration de lot ou une pression mémoire. Sans ces mesures, les équipes risquent d'optimiser les mauvais goulets d'étranglement.

2. Réduire agressivement les tokens de sortie

Les tokens de sortie générés par un modèle sont souvent la source la plus évidente de latence et de coût. Chaque token de complétion doit être généré de manière séquentielle par le modèle. Ainsi, une réponse deux fois plus longue peut prendre environ deux fois plus de temps à produire et coûter significativement plus cher. Pour atténuer ce problème, plusieurs stratégies peuvent être mises en place :

• Définir des limites de max_tokens ou de complétion réalistes.
• Demander des réponses concises lorsque les utilisateurs n'ont pas besoin de longues explications.
• Utiliser des séquences d'arrêt lorsque cela est approprié.
• Éviter de demander au modèle de reformuler la question de l'utilisateur.
• Utiliser des schémas JSON compacts et des noms de champs plus courts.
• Supprimer les résumés, avertissements et contextes répétés inutiles des sorties.
• Séparer les modes "réponse brève" et "explication détaillée" dans l'interface utilisateur du produit.

Par exemple, un assistant de support interne peut n'avoir besoin que d'une réponse en trois points et d'un lien source, sans nécessiter une explication de 700 mots par défaut. Une règle simple à suivre est de ne pas payer pour des tokens que l'utilisateur ne lira pas.

3. Diriger les demandes vers le plus petit modèle capable

Toutes les tâches ne nécessitent pas le modèle le plus grand ou le plus coûteux. De nombreux flux de travail en production sont répétitifs et structurés, tels que l'analyse de sentiment, la modération de contenu, la génération de JSON structuré ou le résumé basique. Ces tâches peuvent souvent être exécutées sur un modèle plus petit, offrant une qualité acceptable, un coût inférieur et des réponses plus rapides. Une approche efficace est le routage de modèle :

• Envoyer des demandes simples à un petit modèle à faible coût.
• Évaluer la confiance, la complexité ou la qualité de sortie.
• Escalader les demandes difficiles vers un modèle plus puissant uniquement si nécessaire.

Vous pouvez router en fonction de facteurs tels que la longueur du prompt, le type de tâche, le niveau de l'utilisateur, la confiance du modèle, la qualité de récupération ou un classificateur léger. Cette approche évite de faire de votre modèle le plus capable la réponse par défaut à chaque demande.

4. Réduire le nombre d'appels LLM

Une erreur courante en production est de construire des flux de travail avec trop d'appels de modèle séquentiels. Par exemple, un agent peut classer la demande de l'utilisateur, réécrire la demande, récupérer des documents, résumer les documents récupérés, générer une réponse, critiquer la réponse, puis réécrire la réponse. Chaque appel ajoute de la latence, du coût, des points de défaillance et de la complexité opérationnelle. Il est essentiel de rechercher des étapes qui peuvent être combinées. Un seul prompt bien conçu avec une sortie structurée peut remplacer deux ou trois appels de modèle. Identifiez également les étapes qui n'ont pas besoin d'un LLM du tout. Utilisez du code déterministe pour :

• Validation de champ
• Règles de routage simples
• Vérifications de permission
• Requêtes de base de données

Pour les tâches indépendantes, exécutez-les en parallèle. La récupération, la classification et l'enrichissement en arrière-plan n'ont souvent pas besoin d'attendre les uns les autres.

5. Concevoir des prompts pour la mise en cache de préfixes

La mise en cache de prompts est l'une des façons les plus efficaces de réduire le coût et le temps pour des prompts longs répétés. La plupart des systèmes LLM ont un contenu stable qui apparaît dans chaque demande, comme les instructions système, les définitions d'outils, les exemples en quelques coups, la documentation produit, le matériel de référence long, et le contexte statique pour un flux de travail. Placez ce contenu réutilisable au début du prompt. Mettez le contenu changeant plus tard, comme l'état de la conversation, les horodatages actuels, les passages récupérés, et les données spécifiques à l'utilisateur. Cet ordre est important car le contenu changeant en début de prompt peut invalider le préfixe réutilisable. Un prompt bien structuré peut transformer un long contexte répété en un cache au lieu de payer pour le traiter à partir de zéro pour chaque demande.

6. Ajouter plusieurs couches de cache

La mise en cache de prompts est utile, mais elle ne devrait pas être la seule mise en cache dans votre système. Une application LLM en production peut bénéficier de plusieurs couches de cache :

• Cache de réponse exacte : stockez les réponses pour des demandes identiques. Cela fonctionne bien pour des questions stables telles que "Quels sont vos plans tarifaires ?", "Comment réinitialiser mon mot de passe ?", ou "Quelle est votre politique de remboursement ?" Utilisez la version et les valeurs de durée de vie (TTL) afin que les réponses obsolètes ne soient pas servies indéfiniment.

• Cache sémantique : un cache sémantique peut réutiliser une réponse lorsqu'une nouvelle demande est très similaire à une précédente.

• Cache de récupération : mettez en cache les embeddings, les résultats de recherche, les résultats de réévaluation et les morceaux de documents pour des requêtes répétées.

• Cache de résultats d'outils : de nombreux outils d'agent produisent des données déterministes ou lentement changeantes. Mettez en cache les sorties des API, des requêtes de base de données, des recherches de produits et des récupérations web lorsque les exigences de fraîcheur le permettent.

L'objectif est simple : ne demandez pas sans cesse au modèle de traiter des informations que votre système connaît déjà.

7. Contrôler votre budget de contexte de génération augmentée par récupération

Le RAG peut améliorer la précision, mais il peut également devenir une source majeure de latence et de coût. Un modèle d'échec typique ressemble à ceci : récupérer trop de documents, ajouter des passages complets sans réévaluation, inclure des morceaux en double, garder tout l'historique de conversation, ajouter des sorties d'outils brutes et du HTML, et envoyer tout au modèle "juste au cas où". Le résultat est un grand prompt qui est coûteux à traiter, plus lent à générer et souvent moins précis car le modèle doit rechercher des informations non pertinentes. Utilisez plutôt un budget de contexte : récupérez moins de documents, réévaluez avant d'envoyer le contenu au modèle, dédupliquez les morceaux qui se chevauchent, supprimez le texte de navigation, les éléments de base et le HTML, utilisez des résumés concis pour les tours de conversation plus anciens, incluez uniquement la sortie d'outil nécessaire pour la décision actuelle, et définissez des budgets de tokens séparés pour les instructions système, le contexte récupéré, l'historique de chat et la sortie. Plus de contexte n'est pas toujours un meilleur contexte.

8. Déplacer le travail non interactif vers le traitement par lots

Toutes les tâches LLM ne nécessitent pas une réponse immédiate. Des tâches telles que le résumé en masse, la génération de rapports, le traitement de base de connaissances, les flux de travail nocturnes, et l'extraction à grande échelle devraient généralement être exécutées de manière asynchrone. Le traitement par lots peut réduire les coûts et protéger le trafic utilisateur interactif des charges de travail en arrière-plan. Gardez les systèmes en temps réel concentrés sur les demandes qui affectent directement les utilisateurs. Envoyez les travaux hors ligne vers des files d'attente de priorité inférieure, des API par lots ou des travailleurs programmés. Cette séparation améliore l'expérience des utilisateurs tout en rendant l'utilisation de l'infrastructure plus prévisible.

9. Ajuster le traitement par lots pour la latence, pas seulement le débit

Le traitement par lots aide les GPU à traiter plusieurs demandes efficacement. Cependant, des lots plus grands ne sont pas automatiquement meilleurs. Un traitement par lots agressif peut améliorer le débit tout en augmentant le temps d'attente et en nuisant au TTFT. Un système peut sembler efficace du point de vue de l'utilisation du GPU alors que les utilisateurs subissent des réponses lentes. Ajustez le traitement par lots par rapport aux objectifs de niveau de service orientés utilisateur : temps d'attente maximum acceptable, P95 et P99 TTFT, latence inter-token, volume de demandes simultanées, longueur moyenne des prompts et des sorties, priorité du travail interactif par rapport au travail en arrière-plan. Pour les modèles auto-hébergés, le traitement par lots continu ou en vol est souvent précieux car les demandes complétées peuvent quitter le lot pendant que de nouvelles demandes entrent. L'objectif n'est pas une utilisation maximale du GPU. L'objectif est la meilleure expérience utilisateur dans une enveloppe de coût acceptable.

10. Gérer soigneusement le cache clé-valeur et la longueur du contexte

Les charges de travail à long contexte peuvent consommer rapidement la mémoire GPU. Le cache clé-valeur (KV) stocke les informations nécessaires à la génération de tokens. À mesure que les fenêtres de contexte et les demandes simultanées augmentent, la mémoire du cache KV devient une contrainte majeure pour l'infrastructure. Cela peut conduire à la préemption des demandes, à la réduction de la simultanéité, et à des échecs de mémoire. Pour gérer cela, définissez des limites réalistes pour : longueur de contexte maximum, longueur de sortie maximum, demandes simultanées, mémoire de conversation par utilisateur, nombre de morceaux récupérés, et taille de sortie d'outil. Les systèmes de cache KV paginés, la quantification du cache KV et la planification consciente de la mémoire peuvent aider, mais ils doivent être validés par rapport à votre charge de travail réelle. Ne dévoilez pas une fenêtre de contexte massive simplement parce que le modèle le prend en charge. La plupart des applications n'ont pas besoin d'utiliser des fenêtres de contexte très larges.