Essais sur la latence des systèmes IA
La latence d'un système LLM n'est pas un problème d'infrastructure — c'est une décision d'architecture. À partir d'un certain seuil, l'attente n'est plus une attente, c'est une régression d'UX. Et le réflexe naturel — ajouter un retry, augmenter le timeout, mettre du caching — masque souvent un problème plus profond : que faire quand le modèle prend trois fois plus de temps que prévu. Ces essais traitent les trade-offs concrets : streaming comme choix UX plutôt que de transport, fallbacks et timeouts comme art de la dégradation gracieuse, fast mode et son rapport coût-vitesse, et la logique de retry qui ment quand elle compte ce qu'elle ne devrait pas compter. À lire pour qui ship un produit où la latence est une feature à part entière.
Votre logique de retry vous ment
Les retries naïfs transforment une requête lente en trois requêtes lentes et appellent ça de la résilience. Ce qu'il faut faire à la place.
Le streaming des réponses est une décision d'UX, pas de transport
Quand streamer, quand attendre, et pourquoi ce choix appartient autant au produit qu'à l'ingénierie. Trois patterns et leurs compromis.
Fallbacks, timeouts et l'art de se dégrader gracieusement
Le modèle sera en panne, lent ou dans l'erreur. Concevez pour cela avant la panne et la fonctionnalité cesse d'être fragile.