Un modèle en production coûte, rate et recommence

Dans un carnet de notes, un appel à un modèle coûte zéro, prend le temps qu’il prend et réussit toujours, parce qu’on relance jusqu’à ce que ça marche avant de montrer le résultat. Trois hypothèses fausses, sur lesquelles beaucoup d’architectures sont posées.

En production, un modèle est une dépendance externe, facturée à l’appel, avec une latence qui varie et un taux d’échec qui n’est pas nul. Exactement comme une passerelle de paiement, à ceci près qu’une passerelle de paiement, elle, renvoie deux fois la même réponse pour deux fois la même question.

Le coût par appel décide de l’architecture

C’est la ligne qui surprend les équipes qui découvrent leur première facture. Un traitement qui appelle trois modèles en chaîne pour produire un résultat coûte trois fois, à chaque tentative, y compris les tentatives ratées. Si l’utilisateur peut relancer, il coûte autant de fois qu’il relance.

La question à se poser avant d’écrire la première ligne n’est pas « quel modèle est le meilleur », c’est « combien coûte un résultat rendu, en comptant les échecs ». La réponse détermine s’il faut mettre du cache, s’il faut découper, et s’il faut refuser certaines demandes.

La latence est une contrainte de produit, pas une métrique

Sur KLAAS, la contrainte est écrite : une miniature en 1280x720, à visage constant, en moins de soixante secondes. Ce n’est pas un objectif de performance, c’est la définition du produit. Au-delà, l’utilisateur retourne à son outil de montage et le produit n’a plus de raison d’exister.

Une contrainte de temps posée ainsi décide de l’architecture avant le choix du modèle. Elle dit ce que l’on peut se permettre de faire en série, ce qu’il faut paralléliser, et ce qu’il faut préparer à l’avance parce que ça ne tiendra jamais dans la fenêtre.

La reprise sur erreur n’est pas optionnelle

Un appel qui échoue doit avoir une suite écrite : réessayer, réessayer autrement, ou rendre la main proprement. Les trois sont des décisions produit, pas des détails d’implémentation.

Réessayer à l’identique sur une erreur de quota ne sert à rien et coûte deux fois. Réessayer avec un modèle de repli change le résultat, et il faut décider si ce résultat différent est acceptable ou s’il vaut mieux dire non. Rendre la main proprement suppose qu’il existe un message qui a du sens pour quelqu’un qui n’a pas lu la documentation.

La reproductibilité est ce qui se vend

Le point dur de KLAAS n’est pas de générer une image. C’est que le visage du créateur soit le même d’un rendu à l’autre. Un résultat spectaculaire une fois sur trois n’est pas un produit, c’est une machine à sous.

Ce qui vaut pour une image vaut pour tout le reste. Un modèle qui répond bien la plupart du temps, dans un système où personne ne sait dire quand il répond mal, n’est pas industrialisé. Il est en démonstration permanente.

Ce que ça change dans les faits

Traiter le modèle comme une dépendance externe ordinaire. On mesure ce qu’il coûte, on mesure ce qu’il rate, on décide de la suite quand il rate, et on vérifie que la même entrée donne un résultat exploitable. Rien de tout cela n’est spécifique à l’IA. C’est ce que l’on fait depuis toujours avec un service tiers, et c’est précisément ce que l’on oublie de faire quand la nouveauté occupe toute la place.