Observar una flota efímera de inferencia de IA
El discovery dinámico de Prometheus mantuvo visibles los workers de GPU y los pods de inferencia a medida que cambiaban las direcciones de su proveedor.
Cinco targets estaban UP en la instantánea del rollout. Esta entrega agregó visibilidad; las reglas de paging fueron un seguimiento aparte.
Contribución de un vistazo
- Mi responsabilidad
- Inventario dinámico de targets, integración con el discovery de Prometheus y dashboards de la flota.
- Alcance
- Workers de inferencia efímeros; el discovery se actualizaba cada 30 segundos.
- Colaboración y límites
- Conecté las capas de inventario y de monitoreo. Las reglas de paging fueron un trabajo de seguimiento aparte.
- Resultado
- Cinco targets estaban UP en la instantánea del rollout; los redeploys de los workers ya no requerían una lista estática mantenida manualmente.
El problema
Los pods de GPU alquilados reciben nuevas direcciones del proveedor después de cada redeploy. Una lista estática de targets de Prometheus se rompe a medida que esas direcciones cambian, y una vista web solo para operadores no ofrece el historial ni la visibilidad compartida que se necesitan para el diagnóstico.
Mi contribución
Expuse un inventario dinámico de targets desde el router, lo conecté con el HTTP service discovery de Prometheus y construí una vista en Grafana de la flota de inferencia. El router ya rastreaba los heartbeats de los workers, así que era el lugar adecuado para describir la topología activa.
Cómo funcionaba el discovery
Prometheus consultaba el inventario sobre HTTPS cada 30 segundos. La lista incluía el router, los workers activos y los pods de inferencia; los workers obsoletos desaparecían automáticamente. El endpoint del inventario usaba autenticación bearer, y las métricas de los workers se protegían antes de quedar expuestas para scraping.
El dashboard reunía los streams activos, la utilización de los workers y los tokens de inferencia por segundo. Mantuve los identificadores de stream de alta cardinalidad fuera de los gauges a nivel de router y conservé las métricas detalladas de stream en la capa de los workers.
Resultados y medición
El rollout verificó cinco targets UP: un router, dos workers y dos pods de inferencia. El dashboard mostraba datos de stream e inferencia en vivo. Estos conteos describen la instantánea de validación, no el tamaño máximo de la plataforma.
El límite operativo
Esta entrega estableció la observabilidad, dejando los umbrales de alerta y la responsabilidad del on-call como una decisión aparte. El endpoint de métricas agregadas del motor de inferencia conservó una excepción de autenticación documentada; la integración del discovery no volvió privado cada endpoint por sí sola.
La definición del dashboard estaba versionada, pero la importación seguía siendo un paso manual. El aprovisionamiento automático era una mejora posterior, no una capacidad que se afirme para este rollout.
Por qué importó
La abstracción útil era la flota, no un pod alquilado individual. Reutilizar el inventario del router puso esa abstracción a disposición del sistema de monitoreo sin agregar una segunda fuente de verdad mantenida manualmente.
Trabajo relacionado: servir modelos multimodales entre motores y nubes.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Los targets estáticos son simples pero se degradan después de los redeploys. Un inventario propiedad del router sigue al componente que ya conoce los workers activos.
Contrapartida
El discovery depende del endpoint del inventario; las etiquetas de stream de alta cardinalidad pueden encarecer las métricas a nivel de flota.
Lo que mejoraría a continuación
Próxima mejora: agregar verificaciones de frescura del discovery y probar el comportamiento de las alertas cuando el inventario o un worker desaparece.