L'inférence coûte plus cher que ce que le produit rapporte. Comment réduiriez-vous ça sans casser la qualité ?

Mesurez le coût par requête et trouvez où il se concentre, puisque le trafic est en général déséquilibré. Puis appliquez, à peu près dans cet ordre : mise en cache des requêtes répétées ou quasi identiques, cascade pour qu'un modèle bon marché traite la majorité facile et n'escalade que les cas incertains, quantification plus runtime compilé, matériel correctement dimensionné avec un bon batching, et enfin suppression du travail que rien en aval ne consomme.

Je commence par obtenir le coût par requête et par le découper, parce que le trafic est presque toujours déséquilibré et qu'une petite classe de requêtes a tendance à manger le budget. Ensuite le gain le moins cher est en général la mise en cache. Sur un système, une part significative des requêtes étaient des répétitions exactes en quelques minutes, et un cache à courte durée de vie indexé sur une entrée normalisée a supprimé une bonne partie de la charge pour une journée de travail. Vient ensuite la cascade. Faites tourner un petit modèle bon marché sur tout et n'escaladez vers le modèle coûteux que quand le petit est incertain. Si le petit modèle traite avec confiance soixante-dix pour cent du trafic, vous avez réduit le coût de presque autant tout en gardant l'exactitude sur les cas difficiles, et le seuil d'escalade se règle face à un budget de qualité. Après ça vient l'ingénierie : quantification, runtime compilé, batching dynamique pour que l'accélérateur ne tourne pas à vide, et vérification qu'on n'est pas sur un matériel surdimensionné pour le modèle. La dernière question que je pose est la plus inconfortable : est-ce que chaque prédiction sert ? J'ai un jour trouvé un pipeline qui scorait toute la base d'utilisateurs chaque nuit alors que la surface n'affichait jamais que les quelques milliers du haut, et scorer moins d'entités a été la plus grosse économie à elle seule.