Despliegue y operación

“Desplegar un modelo no es lanzar un cohete. Es abrir una cocina: la parte difícil es el ajetreo del mediodía, todos los días.”

La ruta de la petición en producción

Una funcionalidad de IA servida no es una llamada al modelo; es un pipeline. Una petición toca una caché, pasa una salvaguarda de entrada, llega al modelo, pasa una salvaguarda de salida y regresa, con una ruta de respaldo para cuando el modelo es lento o está caído. Cada etapa es infraestructura corriente, y cada una es donde controlas el coste, la seguridad y la fiabilidad.

El coste y la latencia son parámetros de diseño

El entrenamiento es gasto de capital; la inferencia es gasto operativo: pagas por llamada, para siempre. A escala, el coste de los modelos se convierte en una partida presupuestaria real, y las decisiones que lo controlan son arquitectónicas, tomadas pronto. Las grandes palancas: el tamaño del modelo (usa el modelo más pequeño que pase tu evaluación), la longitud del contexto (cada token del prompt cuesta en cada llamada) y la caché.

La caché es la palanca de coste de mayor impacto y la más pasada por alto. Muchas peticiones son casi idénticas; una caché por coincidencia exacta o semántica puede servirlas gratis. La caché de prompt (reutilizar el coste de un prompt de sistema largo y estable entre llamadas) reduce aún más la factura. Las palancas de coste, en orden de impacto.↗

La latencia es una decisión de producto, no solo un número. El streaming la oculta: los usuarios toleran mucho mejor una respuesta lenta que empieza de inmediato que una rápida que llega de golpe tras una pausa. Y la latencia de los agentes se acumula: un agente de 10 pasos a dos segundos por paso son veinte segundos, lo cual es un producto distinto de una respuesta de un segundo.

Fiabilidad: el modelo fallará

Los proveedores tienen caídas. A los modelos se les limita la tasa, expiran y de vez en cuando devuelven basura. Tu funcionalidad debe degradarse, no derrumbarse. Las defensas son las clásicas de los sistemas distribuidos: tiempos de espera, reintentos con retroceso exponencial, un respaldo (un modelo más pequeño, una respuesta en caché o un honesto «inténtalo de nuevo en un momento») y un cortacircuitos para que la mala tarde de un proveedor no te arrastre con él.

Cambiar un sistema en producción sin romperlo

Los sistemas de IA cambian constantemente: los prompts se ajustan, los modelos se actualizan, la recuperación se afina, los proveedores deprecian versiones bajo tus pies. Cada uno de esos cambios es una ocasión para regresar en silencio. La disciplina del cambio seguro es la misma que para cualquier sistema de producción, aplicada a un componente probabilístico.

• Condiciona cada cambio al conjunto de evaluación: sin pasar la evaluación, no se despliega (capítulo 6).
• Despliega gradualmente: haz un despliegue canario sobre una porción del tráfico, observa las métricas, luego amplía.
• Fija las versiones de modelo: nunca dejes que «latest» cambie tu comportamiento sin que lo sepas.
• Mantén una reversión: los prompts y las elecciones de modelo se revierten tan limpiamente como el código.
• Vigila la producción, no solo las evaluaciones: los casos que envían los usuarios sorprenderán a tu conjunto de pruebas.

Por dónde seguir a partir de aquí

Ya tienes la forma de un sistema de IA real: un modelo delgado en una envoltura gruesa y determinista, alimentado por la recuperación, potenciado por herramientas, mantenido honesto por las evaluaciones y operado como cualquier otro servicio de producción. Dos direcciones lo profundizan: protegerlo frente a la nueva superficie de ataque que todo esto abre, y las guías de prompting y RAG para patrones prácticos.