Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Al utilizar modelos económicos como DeepSeek Chat, GPT-4o-mini o Gemini 2.5 Flash, los costos de API se reducen considerablemente. El problema surge cuando, con un ligero aumento en el tráfico, los tiempos de respuesta se disparan de 10 a 60 segundos. En una estructura de peticiones HTTP síncronas convencional, este retraso bloquea los procesos de los trabajadores del servidor, dejándolos inoperativos, mientras que el frontend colapsa lanzando un error de tiempo de espera (timeout).
Para un desarrollador independiente o un proyecto secundario con un presupuesto ajustado, la caída del servidor es fatal. Sin embargo, no es opción regresar a modelos costosos. Es necesario romper la conexión síncrona directa entre el cliente y el LLM, implementando una arquitectura de separación asíncrona que entregue de manera segura la salida imperfecta del modelo al frontend.
No se debe permitir que el servidor web espere directamente a que el LLM complete la inferencia. Con FastAPI actuando como puerta de enlace (API gateway), se deben combinar un agente de mensajes Redis y trabajadores distribuidos de Celery para separar por completo la recepción de solicitudes y la operación de inferencia real. Cuando un usuario envía una solicitud, el servidor devuelve inmediatamente solo el ID de la tarea y cierra la conexión.
Si se ejecuta Celery con la configuración predeterminada, las tareas se perderán o se ejecutarán duplicadas si un trabajador falla. Para soportar tiempos de tarea prolongados, característicos de la inferencia con LLM, es necesario aumentar visibility_timeout a 3600 segundos y especificar task_acks_late = True para enviar la confirmación de recepción solo cuando la tarea finalice normalmente. También es fundamental configurar worker_prefetch_multiplier = 1 para evitar que un solo trabajador acapare varias tareas pesadas y genere un cuello de botella.
