Mostrando entradas con la etiqueta IaaS. Mostrar todas las entradas
Mostrando entradas con la etiqueta IaaS. Mostrar todas las entradas

martes, abril 15, 2025

Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.
Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.
  • Alta disponibilidad
  • Autoescalado según carga real
  • Seguridad, versionado, observabilidad
  • Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow
Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.


Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:
  • Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).
  • Katib: AutoML y búsqueda de hiperparámetros.
  • KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.
  • Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.
  • Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.
Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen TorranoFran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.
  • Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.
  • Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.
GPU autoscaling
  • Puedes escalar vertical y horizontalmente tus modelos en GPU.
  • Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.
Raw Deployment mode
  • 1.- KServe por defecto usa Knative para autoescalar.
    • Escala basándose en tráfico HTTP (requests por segundo).
    • Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.
    • Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.
  • 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
    • Aquí ya no dependes de Knative, sino de un Deployment + HPA.
  • 3.- Prometheus Adapter + HPA con métricas personalizadas
    • Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.
    • Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.
    • Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.
Scale down a cero

¿Qué significa “scale down a cero” en KServe?
  • Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.
¿Qué beneficios tiene esta solución?
  • Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).
  • Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.
  • Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.
  • Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.
Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:
  • Validar rendimiento y exactitud del modelo en producción.
  • Detectar errores o regresiones antes de hacer el cambio completo.
  • Observar métricas y logs reales sin impactar a todos los usuarios.
Ejemplo de Canary rollout en KServe
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"
  • storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
  • canary: Define model-2 como la nueva versión que se quiere probar.
  • canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.
Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:
  • Servir un modelo LLaMA o Falcon en múltiples nodos GPU.
  • Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.
  • Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.
Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:
  • Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.
  • Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.
  • Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.
Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:
  • KServe + Istio: para gestión de modelos como microservicios.
  • Knative Serving: para escalado a 0, cold start optimizado.
  • Prometheus + Grafana: para métricas personalizadas de GPU o latencia.
  • Cert-Manager + Ingress Gateway: TLS automático para exposición segura.
  • ArgoCD o Flux: GitOps para definir modelos como código.
  • GPU Operator de NVIDIA: para gestionar drivers y nodos GPU
¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.


Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos Carlos García Blanco, CEO de Kumori

jueves, enero 02, 2025

Infra as Code vs. Platform Engineering: Una Mirada Técnica a la Tendencia Actual

En los últimos años, la gestión y automatización de infraestructuras tecnológicas ha experimentado un cambio significativo. Dos enfoques han surgido como protagonistas: el uso de herramientas de Infra as Code (IaC), y el movimiento hacia la ingeniería de plataformas (Platform Engineering) respaldado por soluciones como Axebow, de la que ya os habló nuestro compañero José Bernabéu-Auban en su artículo: "Platform Engineering as a Service: La encrucijada de la Nube y la ilusión del progreso."

Figura 1: Infra as Code vs. Platform Engineering.
Una Mirada Técnica a la Tendencia Actual

Este artículo explora ambas tendencias, haciendo especial énfasis en la complejidad y el nivel de conocimiento necesario para implementar IaC en entornos multicloud.

Infra as Code: Automatización Granular y Flexible

Infra as Code (IaC) ha sido una revolución para los equipos de DevOps y operaciones. Herramientas como Terraform, Ansible y Pulumi permiten definir y gestionar la infraestructura utilizando código, lo que garantiza consistencia, auditabilidad y capacidad de replicación. 
Sin embargo, trabajar con ib en entornos multicloud, como AWS, Google Cloud y Azure, agrega capas de complejidad que exigen un nivel avanzado de conocimiento técnico y organización.

Ventajas del Enfoque IaC

1. Granularidad y Control: Las herramientas IaC ofrecen control detallado sobre los recursos. Por ejemplo, con Terraform, se puede definir cada componente de una infraestructura cloud, desde redes hasta bases de datos.

2. Compatibilidad multicloud: Aunque IaC puede implementarse en entornos multicloud, utilizar distribuciones de Kubernetes nativas de los proveedores cloud tipo (EKS, GKE, AKS) puede limitar la portabilidad y la interoperabilidad entre plataformas, lo que puede generar dependencias que dificultan una verdadera estrategia multicloud. 
 
3. Madurez Tecnológica: Muchas herramientas IaC están bien documentadas y cuentan con una comunidad activa, lo que facilita su adopción.

Desafíos del Enfoque IaC

Complejidad en Entornos Multicloud: Gestionar IaC en una nube ya es complejo; al incorporar múltiples proveedores como AWS, Google Cloud y Azure, se deben manejar diferencias en APIs, servicios y configuraciones. Esto incrementa los riesgos de errores y la necesidad de conocimientos especializados para unificar estrategias.

• Curva de Aprendizaje Pronunciada: Configurar y mantener IaC en un entorno multicloud requiere habilidades avanzadas, lo que implica un costo significativo en términos de formación y tiempo. Los equipos deben dominar lenguajes de configuración, comprender arquitecturas de cada proveedor y desarrollar experiencia en integración. 
 
Esta curva de aprendizaje puede traducirse en retrasos en la implementación y mayores gastos operativos, ya que el tiempo necesario para alcanzar la plena competencia puede ser considerable. Además, los errores derivados de una capacitación insuficiente pueden aumentar los costos asociados al re-trabajo y a la resolución de problemas.

• Escalabilidad Limitada sin Buenas Prácticas: Sin una estrategia bien definida, las configuraciones de IaC pueden volverse inmanejables a medida que crecen las implementaciones.

• Fragmentación Operativa: La falta de estandarización entre nubes puede resultar en implementaciones inconsistentes y más difíciles de mantener.

Platform Engineering: Abstracción y Estandarización

La Ingeniería de Plataformas o Platform Engineering  se posiciona como un enfoque holístico para gestionar infraestructuras y herramientas de desarrollo. Soluciones conocidas como plataformas de ingeniería, entre las que se encuentra Axebow, buscan crear una capa unificada que abstraiga la complejidad técnica y proporcione a los equipos de desarrollo y operaciones una experiencia optimizada.


Beneficios del Enfoque de Platform Engineering


1. Abstracción de Complejidad: Estas plataformas permiten a los equipos trabajar en un entorno preconfigurado que automatiza las configuraciones comunes, reduciendo la necesidad de conocimientos especializados.


2. Control y Optimización de Costes: La ingeniería de plataformas facilita la supervisión y gestión eficiente de los recursos, permitiendo identificar y eliminar ineficiencias en el uso de la infraestructura. Esto es particularmente relevante en entornos multicloud, donde los costos pueden escalar rápidamente si no se controlan adecuadamente. Poder optimizar el coste es un factor fundamental.
3. Productividad Mejorada: Con una plataforma estandarizada, los desarrolladores pueden enfocarse en construir aplicaciones en lugar de preocuparse por los detalles de la infraestructura.
4. Escalabilidad Organizacional: La ingeniería de plataformas promueve la coherencia y facilita la escalabilidad al ofrecer una base uniforme para todas las aplicaciones.

5. Seguridad y Gobernanza: La centralización de la gestión reduce los riesgos de configuraciones inseguras o incoherentes.


Desafíos del Platform Engineering

• Costos Iniciales: Implementar este tipo de plataformas requiere una inversión significativa en tiempo y recursos.

• Menor Flexibilidad Inicial: Aunque la abstracción reduce la complejidad, también puede limitar la capacidad de personalización para casos excepcionales.

• Resistencia al Cambio: Los equipos acostumbrados a trabajar con IaC y scripting pueden ser reticentes a adoptar un enfoque centralizado.

Ambos enfoques tienen su lugar en las estrategias modernas de infraestructura. En muchas organizaciones, la convergencia entre ambas filosofías está generando híbridos donde IaC establece las bases de la infraestructura, mientras que la ingeniería de plataformas ofrece una experiencia optimizada para los desarrolladores.

Consideraciones Finales

La elección entre Infra as Code & Scripting vs. Platform Engineering no es excluyente. Las organizaciones deben evaluar sus necesidades específicas, madurez técnica y objetivos a largo plazo. Mientras que IaC es ideal para entornos donde se requiere un control fino y personalización, la ingeniería de plataformas sobresale en contextos donde la escalabilidad y la eficiencia del equipo son prioritarias.

Figura 8: Comparación y Convergencia

En última instancia, herramientas como Axebow representan una evolución hacia un enfoque más colaborativo y orientado a la experiencia del usuario, marcando el camino hacia el futuro de la automatización de infraestructuras. Si quieres probar un servicio líder como el de Axebow solo entra en nuestra web.

Un saludo,


Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares