Operar LLM multimodales entre motores y nubes

Mi contribución

Construí flujos de trabajo de serving en GPU y de despliegue, seleccioné runtimes en función de la compatibilidad del modelo, reparé fallas silenciosas de compilación y de enrutamiento de tráfico, y aprovisioné la identidad necesaria para la inferencia autenticada. Trabajé con el equipo de la aplicación para promover y validar la integración del fallback en los distintos entornos.

El trabajo evolucionó por etapas: una prueba de concepto de un router de tres proveedores, rutas de serving específicas por modelo con vLLM y llama.cpp, y una posterior integración del fallback de detección de impresión en producción. Son piezas de ingeniería relacionadas con registros de validación separados.

Elige el runtime a partir del modelo

Un identificador de modelo no basta para garantizar que un motor de serving pueda cargar su arquitectura, su cuantización y su proyector de visión. Agregué un resolver que lee los metadatos del modelo y selecciona vLLM o llama.cpp, con imágenes, flujos de trabajo de despliegue y grupos de concurrencia separados.

La ruta de vLLM siguió sirviendo su modelo existente mientras el runtime alternativo se desarrollaba de forma aislada. Los controles cruzados rechazaban un modelo en el flujo de trabajo equivocado antes de construir una imagen o aprovisionar un pod. Las pruebas también comprobaban que una solicitud nominalmente exitosa contuviera de verdad una respuesta utilizable: un modelo de razonamiento podía agotar su presupuesto de tokens antes de producir contenido de respuesta.

Depura la capa que realmente falló

En pods de GPU reales, un ciclo de vida de contenedor aparentemente sano ocultaba una falla de carga de una biblioteca compartida. La imagen original de llama.cpp esperaba sus bibliotecas dentro de su propio directorio de trabajo; cambiar ese directorio rompía el arranque. Hacer explícita la ruta de la biblioteca resolvió la caída. Las hipótesis previas sobre el manejo del entrypoint y la compatibilidad del driver no explicaban esa falla en particular.

Los perfiles de GPU, el contexto del modelo y los ajustes de la caché de clave/valor se mantuvieron explícitos por runtime. Un valor de concurrencia configurado más alto no se trató como una mejora medida del rendimiento. La entrega registró 164 pruebas aprobadas y validación en pods de GPU reales; los pods experimentales se limpiaron después.

Un despliegue en verde todavía puede servir la revisión antigua

Un pipeline de despliegue en Cloud Run tenía tres fallas que se enmascaraban entre sí: fijaciones de dependencias incompatibles, tráfico que permanecía en una revisión más antigua y smoke tests que ejercitaban esa imagen más antigua. Reparé la cadena de dependencias, moví las actualizaciones de tráfico al comando correcto y verifiqué que el digest servido coincidiera con la imagen construida por CI.

La validación previa al merge construye la etapa de dependencias sin descargar pesos de modelo de varios gigabytes. Los smoke tests en runtime se ejecutan desde la ruta de red que usan los clientes reales, y los controles de despliegue rechazan argumentos inconsistentes o cambios de ingress inseguros. Una salida de comando exitosa es una señal; servir la revisión prevista es el resultado.

Fallback de producción e identidad

La integración posterior de la aplicación usó un proveedor alojado, un modelo multimodal autoalojado y una ruta final de CNN. Aprovisioné una identidad dedicada de Kubernetes y de cuenta de servicio de Google en desarrollo, staging y sandbox, otorgando la invocación sobre el servicio objetivo en lugar de roles amplios de proyecto. El clúster de producción heredado siguió usando su identidad de nodo existente; este cambio no lo convirtió a Workload Identity.

Los cuatro entornos pasaron sus verificaciones de identidad y de proveedor al cierre. En la muestra registrada posterior al despliegue en producción, 395 solicitudes HTTP devolvieron 200. Tres timeouts del proveedor primario llegaron a un modelo autoalojado frío y luego se completaron a través del fallback final. Esto describe el despliegue observado, no un SLA de disponibilidad.

El escalado a cero es una concesión operativa: un servicio de GPU en frío puede tardar unos cinco minutos en iniciar, mientras que el presupuesto de la aplicación es de unos 30 segundos. Por eso importan el precalentamiento y el siguiente fallback. Se agregaron verificaciones de autenticación y monitoreo de alto tráfico con umbrales calibrados según el uso real, en lugar de alertar en cada solicitud de fallback esperada.

Resultados y medición

La entrega de serving según el modelo registró dos rutas de runtime aisladas y 164 pruebas aprobadas. El despliegue posterior del fallback verificó la identidad y el comportamiento de la aplicación en cuatro entornos. Esos resultados están separados del anterior POC de router descrito más abajo.

Las mediciones de optimización de arranque también necesitan su propio alcance: una prueba de imagen mejoró de 5m16s a 3m32s; una prueba posterior de arranque limpio registró unos 4m05s. Las distintas configuraciones y rutas de prueba no deberían reducirse a una afirmación universal sobre el cold start.

El anterior POC de router de tres proveedores

Construí un router con FastAPI para ejercitar el flujo normal, el fallback en frío y en caliente, la ruta del proveedor final, las verificaciones de estado y la falla de todos los proveedores. Seis escenarios pasaron. La infraestructura de pruebas se eliminó después, a la espera de una decisión de adopción en producción para ese router; la integración posterior del fallback en la aplicación es una entrega distinta.

Las observaciones registradas de solicitudes del POC fueron 568 ms en RunPod, 1,917 ms en Cloud Run GPU y 7,681 ms en la ruta del GCE Managed Instance Group, con una observación de fallback en frío de unos 41 segundos. Fueron solicitudes de prueba particulares, no percentiles de latencia de producción. GCE Managed Instance Group no significa particionamiento de GPU Multi-Instance GPU.

Opera la flota, no pods individuales

También conecté el inventario del router con el descubrimiento dinámico de Prometheus, de modo que el monitoreo siguiera a los workers de GPU efímeros en lugar de depender de una lista de direcciones actualizada manualmente. Lee el estudio de caso de observabilidad de la flota para conocer su alcance de despliegue y sus límites de monitoreo.

La lección

El serving de modelos es un sistema de decisiones de compatibilidad, identidad, despliegue y falla. Valida de forma independiente el modelo cargado, la revisión servida y el comportamiento del fallback; una compilación en verde o una respuesta de estado HTTP no pueden probar las tres cosas.