La inferencia cuesta más de lo que el producto ingresa. ¿Cómo lo recortarías sin destrozar la calidad?

Mide el coste por petición y encuentra dónde se concentra, ya que el tráfico suele estar sesgado. Luego aplica, en orden aproximado: caché de peticiones repetidas o casi duplicadas, una cascada para que un modelo barato atienda a la mayoría fácil y solo escale los casos inciertos, cuantización más un runtime compilado, hardware bien dimensionado con batching adecuado, y por último recortar el trabajo que nadie aguas abajo consume.

Empiezo consiguiendo el coste por petición y troceándolo, porque el tráfico casi siempre está sesgado y una clase pequeña de peticiones tiende a comerse el presupuesto. Después la victoria más barata suele ser la caché. En un sistema, una parte apreciable de las peticiones eran repeticiones exactas en cuestión de minutos, y una caché de vida corta indexada por una entrada normalizada quitó un buen trozo de carga con un día de trabajo. Lo siguiente es la cascada. Ejecuta un modelo pequeño y barato sobre todo y solo escala al caro cuando el pequeño está inseguro. Si el modelo pequeño resuelve con confianza el setenta por ciento del tráfico, has recortado el coste en casi esa fracción manteniendo la precisión en los casos difíciles, y el umbral de escalado es ajustable contra un presupuesto de calidad. Después viene la ingeniería: cuantización, un runtime compilado, batching dinámico para que el acelerador no esté ocioso, y comprobar si estamos en hardware sobredimensionado para el modelo. La última pregunta que hago es la incómoda, que es si se usa cada predicción. Una vez encontré un pipeline puntuando toda la base de usuarios cada noche cuando la superficie solo mostraba los primeros miles, y puntuar menos entidades fue el mayor ahorro individual.