jueves, junio 18, 2026
lunes, enero 19, 2026
Tu SmartTV de Sony, Samsung, LG, Hisense & TCL te vigila y les han demandado en USA
![]() |
| Figura 6: Libro de Machine Learning aplicado a Ciberseguridad de Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández |
Publicado por
Chema Alonso
a las
7:01 a. m.
0
comentarios
Etiquetas: Ads, Amazon, BigData, datos, e-goverment, Insights, Machine Learning, Netflix, Privacidad, SmartTV
jueves, mayo 29, 2025
FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"
Publicado por
Chema Alonso
a las
6:01 a. m.
0
comentarios
Etiquetas: Amazon, Cifrado, criptoanálisis, Criptografía, Firma Digital, Google, libro, Libros, Microsoft, PKI, Quantum, Seguridad Informática
martes, abril 15, 2025
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.
¿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
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.
![]() |
| Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández |
KServe: servir modelos como si fueran microservicios
- 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.
- 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.
- 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.
- 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.
- 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.
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?
- 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.
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.
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.
- 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.
- 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
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.
Autores: Miguel Angel Chuecos / Carlos García Blanco, CEO de Kumori
Publicado por
Chema Alonso
a las
6:01 a. m.
0
comentarios
Etiquetas: AI, Amazon, AWS, Azure, developer, DevOps, docker, Google Cloud, IA, IaaS, Inteligencia Artificial, Kubernetes, LLM, LLMs, Machine Learning, Microsoft, ML, SecDevOps
jueves, enero 02, 2025
Infra as Code vs. Platform Engineering: Una Mirada Técnica a la Tendencia Actual
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.
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.
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.
• 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.
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.
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,
Publicado por
Chema Alonso
a las
6:01 a. m.
0
comentarios
Etiquetas: Amazon, AWS, Azure, developer, DevOps, Google Cloud, IaaS, Microsoft, SecDevOps
miércoles, febrero 07, 2024
Amazon Web Services (AWS): Hardening de Infraestructuras Cloud Computing en @0xWord
Figura 3: Índice del libro "Amazon Web Services (AWS):
![]() |
| Figura 5: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a la Agenda". https://MyPublicInbox.com/0xWord |
![]() |
| Figura 6: Cuando lo agregues estará en tu agenda |
Publicado por
Chema Alonso
a las
6:01 a. m.
0
comentarios
Etiquetas: 0xWord, Amazon, AWS, Cloud, Cloud computing, Firewall, firewalls, fortificación, hardening, libro, Libros, MyPublicInbox, Tempos, WAF
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
-
Un informe de Tech Transparency Project, después del lío con el Jailbreak del Bikini en Twitter/X , y de la masificación de DeepFakes en el...
-
Circula por la red un truco que llegó a mí de casualidad , donde se explica cómo conseguir ver más de una vez - e incluso capturar - las fot...
-
Las técnicas de OSINT son aquellas que te permiten buscar información en fuentes abiertas. O lo que es lo mismo, sacar datos de plataformas...
-
Los costes de los Tokens en los últimos modelos de IA empiezan a crear una nueva brecha entre las empresas y ciudadanos que tienen acceso ...
-
Hace mucho tiempo, cuando se creo el " Modo Incógnito " de los navegadores, que algunos llamaron también " Modo Privado ...
-
La computación cuántica está avanzando hacia un modelo de consumo en el que la mayoría de los usuarios accederán a los recursos cuánticos a ...
-
Hay gente que cree que Google ha alcanzado la perfección con su buscador, pero la realidad es que tienen que mejorar mucho a varios niveles....
-
Ayer publiqué un post que tiene ver con las opciones de privacidad de Facebook asociadas a los correos electrónicos , y mañana sacaré la se...
-
La noticia del 21 de Julio - que ya me pilló con el post de ayer publicado - fue la del incidente de seguridad reportado por OpenAI y Huggi...
-
Continuando con el contenido de la primera parte de este artículo que puedes leer aquí: " Blind Quantum Computing (1) " vamos a ve...





DragonJAR
8.8 Chile
Ekoparty
e-Hack MX
AREA 51
Comunidad Dojo Panamá
ARPAHE SOLUTIONS 


















































