Dónde encajan los modelos en una arquitectura

El modelo es una dependencia, no la arquitectura

La Sección 12.1 describió un modelo como una función probabilística a la que se accede mediante una API. En una arquitectura es un contenedor entre muchos y, normalmente, una pequeña parte del código. Un asistente de atención al cliente tiene un frontend de chat, un almacén de conversaciones, integraciones con los servicios de pedidos y de reembolsos, un índice de búsqueda, identidad, logging, un traspaso a agentes humanos y un pipeline de despliegue; la llamada al modelo es una línea en medio. Por tanto, las preguntas arquitectónicas son las de siempre, aplicadas a un nuevo tipo de dependencia: dónde se ejecuta, cómo se llama, qué hay entre ella y quienes la llaman, qué ocurre cuando es lenta, se equivoca o no está disponible, y quién responde de su salida.

Acertar con estas preguntas importa más que elegir el mejor modelo del mes. Los modelos se sustituyen cada pocos meses; el gateway, el diseño de las alternativas, el conjunto de evaluación y el proceso de revisión humana duran años. Las decisiones de esta sección son de las significativas y difíciles de revertir, en el sentido del Capítulo 1, así que merecen registros de decisiones; la elección de una versión concreta del modelo debe ser fácil de cambiar.

Tres lugares donde puede ejecutarse un modelo

API de modelos alojadas. El proveedor ejecuta el modelo y tú pagas por token. Esto abarca las API propias de los proveedores de vanguardia (OpenAI, Anthropic y Google, entre otros) y las plataformas en la nube que revenden los modelos de varios proveedores dentro de tu cuenta de nube existente. Es la forma más rápida de empezar y da acceso a los modelos más capaces, sin aceleradores que comprar ni operar. Los costos son un precio por token que crece con el uso, unos límites de tasa que fija otro, una dependencia de la disponibilidad del proveedor, modelos que quedan obsoletos según el calendario del proveedor y datos que salen de tu perímetro. Los contratos, las condiciones de tratamiento de datos, las opciones de conservación nula o limitada y el procesamiento regional reducen esta última preocupación, pero no la eliminan.

Modelos de pesos abiertos autoalojados. Un modelo de pesos abiertos (open-weight) publica sus pesos entrenados, así que puedes ejecutarlo en tus propios aceleradores o en aceleradores alquilados con un servidor de inferencia como vLLM. Algunos ejemplos son los modelos de Meta (Llama), Mistral, Alibaba (Qwen), DeepSeek, Google (Gemma) y OpenAI (gpt-oss). Tú controlas la ruta de los datos, la versión exacta y el fine-tuning, y con un volumen alto y constante el costo por token puede quedar muy por debajo de los precios de las API. A cambio, asumes la planificación de capacidad de un hardware escaso y caro, la utilización (los aceleradores ociosos cuestan lo mismo que los ocupados), las actualizaciones, los parches de seguridad y las guardias. Las licencias importan: algunos modelos de pesos abiertos usan licencias permisivas como Apache 2.0, mientras que otros usan licencias propias con condiciones de uso o de escala, y la mayoría no publican sus datos de entrenamiento. La Open Source AI Definition de la Open Source Initiative (versión 1.0, octubre de 2024) pone el listón más alto que los simples pesos abiertos. Una vía intermedia, la que usa el propio chatbot de este curso, es llamar a modelos de pesos abiertos a través de un proveedor de inferencia externo: precio por token, sin hardware y con la libertad de llevar el mismo modelo a otro sitio.

Modelos en el dispositivo. Los modelos pequeños, a menudo de unos pocos miles de millones de parámetros o menos y cuantizados a una precisión menor, se ejecutan en teléfonos, computadoras portátiles o en el navegador. Ofrecen privacidad (los datos nunca salen del dispositivo), funcionamiento sin conexión, ningún costo por llamada y una latencia muy baja, a cambio de una capacidad mucho menor, una gran dispersión del rendimiento entre dispositivos, descargas de la app más grandes y la dificultad de actualizar modelos ya distribuidos a millones de dispositivos. Muchos productos los combinan: un modelo pequeño en el dispositivo se encarga de las tareas rápidas y privadas y deriva las más difíciles a la nube.

Inferencia online y puntuación por lotes

La segunda pregunta es si hay un usuario esperando. La inferencia online llama al modelo en la ruta de la solicitud, así que se aplican objetivos de latencia: los usuarios notan el tiempo hasta las primeras palabras visibles, que es por lo que las respuestas del chat se envían en streaming, y abandonan una solicitud que tarda muchos segundos. Las llamadas online necesitan timeouts, límites de concurrencia y capacidad para el pico de la noche, exactamente igual que cualquier dependencia síncrona del Capítulo 6.

La puntuación por lotes procesa muchos elementos sin que nadie espere: etiquetar por la noche dos millones de platos de la carta con sus alérgenos, resumir las conversaciones de soporte del día anterior, volver a generar los embeddings de una colección de documentos. El trabajo por lotes puede usar el modelo adecuado más barato, ejecutarse cuando hay capacidad libre y reintentar con calma. Varios proveedores ofrecen interfaces asíncronas por lotes que aceptan un archivo de solicitudes y devuelven los resultados en unas horas con un descuento considerable. Entre ambas está la inferencia asíncrona: una solicitud se pone en cola, se avisa al usuario de que el resultado llegará después (una decisión de reembolso por correo electrónico, el resumen de un documento en unos minutos) y unos workers vacían la cola a un ritmo controlado, usando las colas y el back pressure del Capítulo 9 para absorber los picos y los límites de tasa del proveedor. Sacar el trabajo de la ruta online es una de las decisiones de costo y fiabilidad más eficaces que existen.

Modelos clásicos en producción: características, registros y desviación

No todos los modelos son modelos de lenguaje grandes. La estimación del tiempo de entrega y la puntuación de fraude de la plataforma de reparto de comida son modelos supervisados clásicos (Sección 12.1), entrenados con sus propios datos, y traen sus propios problemas de operación. La descripción que hizo Uber en 2017 de su plataforma Michelangelo es una buena referencia, entre otras cosas porque sus modelos de tiempo de entrega de UberEATS combinan una característica por lotes (el tiempo medio de preparación de un restaurante durante siete días) con otra casi en tiempo real (la misma medida en la última hora).

El fallo clásico es el desfase entre entrenamiento y servicio (training-serving skew), que las Rules of Machine Learning de Google definen como una diferencia entre el rendimiento durante el entrenamiento y el rendimiento durante el servicio. Nombran tres causas: tratar los datos de forma diferente en los dos pipelines, que los datos cambien entre el entrenamiento y el servicio, y los bucles de retroalimentación entre el modelo y el sistema. Supón que el trabajo de entrenamiento calcula el tiempo de preparación de un restaurante en SQL, incluidos los pedidos cancelados, y que el servicio en vivo lo calcula en Java, excluyéndolos. Ambos pasan sus tests, y el modelo empeora en silencio. Los remedios de Google son reutilizar código entre los pipelines siempre que sea posible y registrar las características realmente usadas en el momento de servir, para luego entrenar con esos registros; informa de que la página de inicio de YouTube mejoró significativamente tras hacerlo.

Un almacén de características (feature store) aborda la primera causa poniendo una única definición de cada característica a disposición en dos lugares. En Feast, de código abierto, un almacén offline proporciona el historial para el entrenamiento y un almacén online proporciona valores con baja latencia para la predicción. También da corrección en el tiempo (point-in-time correctness): una fila de entrenamiento de un pedido hecho a las 19:00 debe ver cada característica tal como estaba a las 19:00, o se filtrará información del futuro al entrenamiento y los resultados offline parecerán mejores que los reales. Sin embargo, un almacén de características no es un pipeline ni una base de datos. La documentación de Feast dice que depende de herramientas previas y de datos guardados en otro lugar. Se justifica cuando varios modelos comparten características; un único modelo por lotes rara vez necesita uno. El almacén online también se suma a la ruta de cada predicción, así que necesita un timeout y un mecanismo alternativo, como una estimación predeterminada de 30 a 45 minutos.

Un registro de modelos hace para los modelos entrenados lo que un repositorio de artefactos hace para las compilaciones (Sección 10.5). El de MLflow, por ejemplo, numera cada versión, la vincula a la ejecución que la produjo y ofrece etiquetas y alias móviles como champion. Los servicios cargan el alias, de modo que la promoción y el rollback son un pequeño cambio, pero registra la versión exacta que hay detrás en cada predicción, o no podrás explicar más tarde una mala estimación. Cada versión debe anotar sus definiciones de características, la instantánea de los datos de entrenamiento y los resultados de evaluación.

Después, vigila la segunda causa, que ninguna herramienta elimina. Compara las distribuciones de las características en vivo con las vistas en el entrenamiento, compara las predicciones con los resultados reales a medida que llegan, y reentrena a través del pipeline con los controles de evaluación de la Sección 12.5.

Un gateway de IA entre las aplicaciones y los modelos

En cuanto más de un equipo o una funcionalidad llaman a modelos, un gateway de IA (AI gateway) dedicado se amortiza. Desempeña el papel que un API gateway desempeña para los microservicios, especializado en el tráfico de modelos. Las aplicaciones llaman a un único endpoint interno con un único formato de solicitud y su propia identidad; el gateway guarda las claves de los proveedores, traduce a la API de cada proveedor, aplica el enrutamiento y las alternativas, hace cumplir las cuotas y los presupuestos de gasto por equipo, aplica límites de tasa, registra cada llamada (modelo, versión, número de tokens, latencia, costo, resultado) para el trazado y la asignación de costos, puede guardar respuestas en caché y ofrece un lugar donde conectar de forma centralizada los guardrails de entrada y de salida.

Las ventajas son arquitectónicas: la elección del proveedor pasa a ser una decisión de configuración en lugar de un cambio de código en cada servicio, las claves dejan de estar dispersas por las aplicaciones, el gasto es visible por funcionalidad y una caída de un proveedor se gestiona una sola vez. Los costos son los de cualquier intermediario compartido. Es una nueva dependencia crítica que debe tener alta disponibilidad, añade una pequeña latencia y sus logs se convierten en un almacén concentrado de prompts que pueden contener datos personales, por lo que se le aplican reglas de enmascarado y de conservación (consulta privacidad desde el diseño). Existen productos de gateway de código abierto y gestionados, y las plataformas en la nube incluyen funciones de gateway; construir uno ligero es razonable para un sistema pequeño, pero las cuotas, el streaming, los reintentos y la contabilidad dan más trabajo de lo que parece.

Enrutamiento y cascadas

No todas las solicitudes necesitan el modelo más capaz. El enrutamiento decide de antemano qué modelo debe atender una solicitud, mediante reglas (la funcionalidad, el nivel del cliente, el idioma) o un clasificador pequeño y rápido. En el asistente de soporte, ¿dónde está mi pedido? puede ir a un modelo pequeño y barato que llama a una herramienta, mientras que una queja sobre tres problemas distintos va a un modelo más grande. Una cascada de modelos, en cambio, prueba primero un modelo más barato y escala solo cuando una comprobación indica que su respuesta no es lo bastante buena. FrugalGPT (2023), de Chen, Zaharia y Zou, mostró que unas cascadas bien ajustadas pueden acercarse a la calidad del modelo más potente con una fracción del costo.

Una cascada solo es tan buena como su comprobación de escalado. Las comprobaciones fiables son deterministas: la salida no supera la validación del esquema, una fuente citada no existe, falta un campo obligatorio, una regla de negocio rechaza la propuesta. Un modelo verificador que puntúa la respuesta es más débil, pero a menudo útil. La declaración de confianza del propio modelo es la señal menos fiable y no debe usarse sola. Las cascadas también tienen costos: las solicitudes escaladas pagan dos llamadas y esperan a ambas, ahora hay dos modelos que evaluar y mantener sincronizados, y el techo de calidad lo fija la comprobación, no el modelo potente. Mide la tasa de escalado; si la mayoría de las solicitudes escalan, usa enrutamiento en su lugar.

Escaleras de alternativas entre modelos y proveedores

Las API de modelos fallan de todas las formas en que fallan las dependencias remotas, y de algunas propias: respuestas de límite de tasa (HTTP 429) cuando se agota una cuota, errores de sobrecarga en los momentos de más actividad, respuestas lentas que superan un timeout, caídas regionales y modelos retirados en una fecha de obsolescencia. Los patrones del Capítulo 9 se aplican directamente, organizados como una escalera de alternativas (fallback ladder): una lista ordenada de peldaños, cada uno de los cuales se prueba cuando falla el de arriba. Una escalera típica es el modelo principal; el mismo modelo en otra región o en otro proveedor de alojamiento; un modelo distinto de capacidad similar de un segundo proveedor; un modelo más pequeño y rápido; y, por último, una respuesta sin IA, como un mensaje predefinido útil, los resultados de búsqueda del centro de ayuda o un traspaso a una persona.

Reglas de diseño para una escalera: da a cada peldaño su propio timeout y a toda la escalera un plazo total, para que el usuario nunca espere cuatro fallos lentos seguidos; respeta Retry-After y pon un modelo con límite de tasa en un periodo de enfriamiento (un circuit breaker sencillo) en lugar de bombardearlo; no reintentes los errores que volverán a fallar, como una solicitud demasiado grande o rechazada por un filtro de contenido; valida la salida en cada peldaño, porque un peldaño inferior puede producir respuestas con una forma ligeramente distinta; evalúa cada peldaño con el mismo conjunto de evaluación, ya que los prompts suelen necesitar ajustes por modelo; y registra qué peldaño respondió, para que los paneles de calidad puedan distinguir una respuesta degradada de una normal.

Las propias funcionalidades de IA de este curso son un ejemplo pequeño y real. Las respuestas de ArchitectBot y la corrección de las respuestas escritas de las pruebas se generan a través de una escalera de varios modelos de pesos abiertos servidos por un único proveedor de inferencia, que se prueban en un orden de preferencia fijo. A un modelo que devuelve una respuesta de límite de tasa se le aplica un periodo de enfriamiento durante el tiempo que pide el proveedor (dentro de unos límites fijados); una solicitud que falla, agota su timeout o devuelve una respuesta inutilizable pasa al siguiente peldaño; esos peldaños comparten un presupuesto de tiempo global, y un segundo proveedor sirve como último peldaño. El diseño cambia algo de calidad de las respuestas en los peldaños inferiores por disponibilidad: es preferible una respuesta algo más débil a ninguna.

Humanos en el bucle

El concepto de humano en el bucle (human in the loop) describe varios diseños distintos, y conviene nombrar a cuál se refiere uno. Aprobación antes del efecto: el modelo redacta y una persona aprueba (un reembolso por encima de un límite, una respuesta a un regulador, un cambio en producción). Revisión después del efecto: las salidas surten efecto de inmediato y las personas revisan una muestra o los casos marcados. Escalado: el modelo gestiona lo que puede y pasa el resto a una persona, con la conversación y la evidencia. Retroalimentación: las personas etiquetan o corrigen las salidas para crear conjuntos de evaluación y mejorar los prompts.

Cada diseño tiene consecuencias arquitectónicas. La aprobación crea una cola que debe dimensionarse para el volumen máximo, como la cola de revisión de fraude de la sección 12.1, y añade una latencia que se mide en minutos u horas. Las personas que aprueban cientos de sugerencias buenas empiezan a aprobar sin leer (sesgo de automatización), así que la interfaz debe mostrar la evidencia y la acción exacta, resaltar lo inusual y registrar con qué frecuencia los revisores cambian la propuesta; una tasa de modificación cercana a cero es una señal de alarma, no un éxito. Los traspasos necesitan todo el contexto para que el cliente no tenga que repetirse. La supervisión humana que exige la normativa para algunos usos es aún más exigente: la persona debe entender los límites del sistema y poder anularlo.

La cadena de suministro de modelos: pesos, pickles y AI-BOM

Un modelo que descargas es una dependencia, así que todo lo de la Sección 8.6 se aplica, con una dificultad añadida. El código fuente se puede revisar; miles de millones de pesos, no. La lista de riesgos de LLM de OWASP dice que los modelos son cajas negras binarias y advierte de que los modelos preentrenados pueden ocultar sesgos, puertas traseras o funciones maliciosas que las evaluaciones de seguridad no detectan. Hay, por tanto, dos riesgos separados: que cargar el archivo ataque tu máquina, y que el propio modelo se comporte mal.

El primero proviene de los formatos de archivo. El formato pickle de Python, durante mucho tiempo el predeterminado para los checkpoints de PyTorch, puede ejecutar código mientras se carga, y la propia guía de Hugging Face es no deserializar con pickle datos de fuentes no fiables. Su Hub analiza lo que se sube y enumera las importaciones sospechosas, pero dice claramente que esto no es infalible. Desde la versión 2.6, torch.load de PyTorch usa por defecto un modo restringido weights_only, pero su documentación sigue diciendo que nunca se carguen datos de una fuente no fiable. Safetensors es la mejor respuesta: un formato diseñado para almacenar tensores de forma segura, a diferencia de pickle. Un repositorio también puede llevar código. Los modelos personalizados en la biblioteca Transformers necesitan trust_remote_code=True, lo que debe tratarse como la decisión de ejecutar el programa de otra persona.

Si la plataforma de reparto de comida aloja por su cuenta un modelo de pesos abiertos, de esto se deriva una política razonable. Prefiere safetensors y rechaza los archivos pickle externos. Replica los modelos aprobados en un almacén interno, para que producción nunca los descargue directamente de un hub público, y fija cada uno por revisión exacta y hash del archivo. Carga los modelos nuevos en un sandbox sin credenciales y sin acceso saliente a la red (Sección 10.1). Prueba cada modelo con tus propios casos y somételo a red teaming antes de usarlo, ya que ni un análisis ni un buen benchmark muestran cómo se comporta en tus tareas. Aplica las mismas reglas a complementos como los adaptadores LoRA, que OWASP enumera como un riesgo por sí mismo.

La firma ayuda con el origen. El proyecto model-signing de OpenSSF, lanzado como versión 1.0 en 2025, usa Sigstore para firmar modelos, de modo que la manipulación sea detectable y un modelo pueda vincularse a la identidad que lo produjo. Una firma válida dice quién publicó el archivo y que no ha cambiado. No dice que el modelo sea seguro.

Mantén también un inventario. Un AI-BOM extiende la lista de materiales de software a los modelos, los conjuntos de datos y el resto de un sistema de IA. Dos estándares cubren esto. CycloneDX admite un ML-BOM desde la versión 1.5, que registra modelos, conjuntos de datos, licencias, el linaje desde los modelos base y los detalles de la model card. SPDX 3.0 añadió un perfil de IA que cubre el tipo de modelo, la información de entrenamiento, la evaluación de riesgos de seguridad y el uso de energía. Para la plataforma, la entrada de un modelo de soporte con fine-tuning registraría el modelo base y su licencia, el adaptador, los datos de entrenamiento y el servidor de inferencia. Si se descubre que un modelo base está comprometido o cambia su licencia, podrás encontrar cada uso en minutos. Con una API alojada ves mucho menos, así que anota la versión fechada del modelo y lo que te haya dicho el proveedor. Ambos estándares están evolucionando, así que comprueba la versión vigente.

Construir o comprar, y cómo elegir un modelo

La pregunta de construir o comprar tiene más de dos respuestas. Puedes comprar una funcionalidad de IA completa dentro de un producto que ya usas (el asistente de un proveedor de software de helpdesk); construir sobre API alojadas; hacer fine-tuning de un modelo para tu tarea; autoalojar pesos abiertos; o, rara vez, entrenar el tuyo propio. Usa la lente estratégica del diseño guiado por el dominio: compra para capacidades genéricas, como la transcripción de reuniones, y construye donde la IA toca tu dominio central y tus propios datos te dan una ventaja. Construyas lo que construyas, mantén el código específico de cada proveedor detrás de un puerto con un adaptador por proveedor, y evita depender de funcionalidades que solo ofrece un proveedor, salvo que su valor justifique la dependencia del proveedor (lock-in).

Elige los modelos con tu propio conjunto de evaluación, no con las clasificaciones públicas (leaderboards). Las clasificaciones miden tareas generales que pueden no parecerse a las tuyas, y hay modelos que se han ajustado para puntuar bien en algunas de ellas. Define los criterios y sus pesos antes de probar, como en cualquier decisión ponderada, y después preselecciona dos o tres candidatos y mídelos con unos cientos de ejemplos reales. Espera que la respuesta sea una combinación, como un modelo pequeño para el enrutamiento y uno más grande para los casos difíciles, más que un único ganador.