La latencia p99 de tu modelo es de 400 milisegundos y el producto necesita 50. ¿Cómo lo abordas?

Perfila antes de optimizar: reparte los 400 milisegundos entre obtención de características, preprocesado, el pase hacia delante del modelo y la red, porque el modelo a menudo no es la porción mayor. Luego ataca la pieza más grande. Las ganancias típicas son concurrencia en las consultas de características, caché, cuantización, un runtime compilado, un modelo destilado, y sacar trabajo de la ruta de la petición. Apunta al p99 en concreto, no a la media.

No tocaría el modelo hasta tener un desglose. Trazo una petición de extremo a extremo y cronometro la obtención de características, la deserialización, el preprocesado, el pase hacia delante, el posprocesado y la red. Cada vez que he hecho esto en un servicio que se sentía lento, el modelo era la minoría del tiempo. El último rondaba los 400 milisegundos en total, con unos 90 en el modelo y más de 200 esperando tres consultas secuenciales de características contra un almacén remoto. Arreglar eso no era un problema de ML, era lanzarlas de forma concurrente y cachear las dos que solo cambiaban a diario, y solo con eso hicimos casi todo el camino. Después miro el modelo: batching dinámico, cuantización a int8, o exportar a un runtime compilado como ONNX Runtime o TensorRT, que en modelos pequeños suele ser una ganancia de dos o tres veces sin coste de precisión. La otra cosa sobre el p99 en concreto es que una cola tan por encima de la mediana normalmente no es cómputo, es encolamiento bajo carga, un arranque en frío en una réplica nueva, o recolección de basura. Así que compruebo si el p50 ya está bien, porque si lo está, el arreglo es capacidad y pools calientes.