Inférence

Ce qui se passe pendant l'inférence

L'inférence désigne l'usage du modèle entraîné. Le texte d'entrée est découpé en jetons, convertis en représentations numériques, puis traversés par le réseau. Le modèle calcule une distribution de probabilités sur le jeton suivant, en choisit un selon le réglage de température, l'ajoute au texte et recommence. La réponse se construit donc progressivement, jeton après jeton, jusqu'à un critère d'arrêt. Le même mécanisme s'applique à chaque échange : rien n'est mémorisé d'une session à l'autre, sauf si l'application renvoie elle-même l'historique.

Deux phases se distinguent. La première traite la consigne entière et remplit le cache d'attention, qui conserve les calculs déjà faits. La seconde produit la réponse, un jeton à la fois, en relisant ce cache. Cette seconde phase domine la durée perçue : elle est séquentielle par nature, ce qui explique qu'une réponse longue mette plus de temps qu'une réponse courte, même sur un modèle rapide. La taille du cache croît avec la longueur du contexte, ce qui renchérit les longues conversations.

Ce qui détermine le coût et la vitesse

Le coût dépend d'abord de la taille du modèle et du nombre de jetons traités, en entrée comme en sortie. Une longue consigne, un document joint, un historique de conversation conservé : tout se paie. La quantification réduit la mémoire nécessaire et accélère souvent le calcul, avec une perte de qualité variable. Le matériel fixe le plafond : mémoire, bande passante, capacité de calcul parallèle. Un modèle servi à plusieurs se dimensionne sur la mémoire totale, qui doit contenir les poids et les états des requêtes en cours.

Les serveurs arbitrent entre latence et débit. Traiter plusieurs demandes ensemble, par lots, augmente le nombre de réponses par heure mais allonge l'attente individuelle. La mise en cache des préfixes répétés évite de recalculer un même contexte, ce qui compte pour une consigne système servie à tous. Ces réglages relèvent de l'exploitation et changent l'expérience autant que le choix du modèle. Le débit se mesure en jetons par seconde, la latence en temps avant le premier jeton : deux indicateurs distincts, souvent confondus.

Ce que cela implique pour un projet

Un projet doit chiffrer le nombre de sollicitations, la longueur moyenne des entrées et des sorties, la pointe d'activité. Sans ces ordres de grandeur, le dimensionnement se fait au ressenti et la facture surprend. Les délais d'attente, les files et les reprises sur erreur se prévoient côté application : un modèle qui met trop longtemps à répondre doit être coupé proprement, pas laissé bloquer un utilisateur. Une file d'attente visible vaut mieux qu'un écran figé, qui pousse à interrompre une requête en cours.

La supervision complète le dispositif : temps de réponse, taux d'échec, volume de jetons, coût par jour. Ces mesures orientent les arbitrages, entre un modèle plus petit pour les tâches simples et un modèle plus grand pour les cas difficiles. Router les demandes selon leur difficulté est souvent plus rentable que d'uniformiser sur le modèle le plus coûteux. Ces mesures se relèvent automatiquement, sinon elles sont estimées et l'arbitrage se fait sur des impressions. Un tableau de bord simple suffit, à condition d'être regardé chaque semaine.