La latence p99 de votre modèle est de 400 millisecondes et le produit en exige 50. Comment abordez-vous ça ?

Profilez avant d'optimiser : décomposez les 400 millisecondes en récupération des caractéristiques, prétraitement, passe avant du modèle et réseau, parce que le modèle n'est souvent pas la plus grosse part. Puis attaquez la plus grosse pièce. Les gains habituels sont la concurrence sur les lectures de caractéristiques, la mise en cache, la quantification, un runtime compilé, un modèle distillé, et le déplacement de travail hors du chemin de la requête. Visez le p99 précisément, pas la moyenne.

Je ne toucherais pas au modèle tant que je n'ai pas la décomposition. Je trace une requête de bout en bout et je chronomètre la récupération des caractéristiques, la désérialisation, le prétraitement, la passe avant, le post-traitement et le réseau. Chaque fois que je l'ai fait sur un service qui semblait lent, le modèle représentait une minorité du temps. Le dernier tournait autour de 400 millisecondes au total, dont environ 90 dans le modèle et plus de 200 à attendre trois lectures séquentielles de caractéristiques sur un magasin distant. Corriger ça n'était pas un problème de ML, c'était les émettre en parallèle et mettre en cache les deux qui ne changeaient que chaque jour, et ça seul nous a fait la plus grande partie du chemin. Ensuite je regarde le modèle : batching dynamique, quantification int8, ou export vers un runtime compilé comme ONNX Runtime ou TensorRT, ce qui sur les modèles plus petits donne fréquemment un facteur deux à trois sans coût en exactitude. L'autre chose sur le p99 en particulier, c'est qu'une queue aussi loin au-dessus de la médiane n'est en général pas du calcul du tout, c'est de la file d'attente sous charge, un démarrage à froid sur une réplique fraîche, ou du ramasse-miettes. Donc je vérifie si le p50 va déjà bien, parce que si c'est le cas, le correctif est de la capacité et des pools préchauffés.