Réduire la latence d'inférence
La latence d'un modèle, c'est le temps entre la question et le premier mot de réponse, puis la cadence des mots suivants. Neuf leviers l'attaquent, chacun sur un point différent du chemin de décodage : les kernels spécifiques au hardware (`flash attention`, du calcul écrit pour la carte), la `page attention` (paginer le cache clé-valeur comme la mémoire virtuelle d'un OS), la compilation du modèle (`TorchCompile`, `TensorRT`, pour une exécution native sur la puce), le decodage spéculatif (un petit modèle propose cinq mots, le gros les approuve d'un coup), le batching continu (insérer les nouvelles requêtes dès qu'un créneau se libère), le prétraitement asynchrone (préparer l'entrée suivante pendant que le modèle travaille), le cache au niveau requête (même question, réponse déjà stockée, servie instantanément), le préchauffage du modèle (le charger en mémoire GPU pour zéro démarrage à froid) et la quantization (poids passés de 32 bits à 8 bits, même modèle, plus rapide).
Forces
- Neuf leviers nets, chacun rattaché à un goulot identifiable du chemin de décodage
- Transforme « c'est lent » en une décision mesurable : quel goulot, quel levier, quel gain
- Certains leviers (quantization, préchauffage, cache requête) sont accessibles sans réécrire le modèle
Limites
- Empiler les leviers à l'aveugle ajoute de la complexité sans gain si le goulot réel est ailleurs
- Plusieurs leviers touchent des couches basses (kernels, compilation) hors de portée sans contrôle du serveur d'inférence
Pour qui
- Devs qui servent un modèle et voient le temps de réponse plomber l'expérience utilisateur
- Leads techniques qui doivent savoir quel levier de latence mérite l'effort avant d'engager l'équipe