Insane Vibe Coding with Harsh Prompting

Desde que tenemos la posibilidad de hacer Vibe Coding con modelos LLM hay dos cosas que me tienen totalmente en bucle pensando. Se trata de solucionar dos problemas que tienen de manera intrínseca los modelos de GenAI, que son el Determinismo, y la Better-Done-Than-Perfect. Y dejadme que os lo explique a ver si soy capaz de transmitiros lo que hay en mi cabeza.

Figura 1: Insane Vibe Coding with Harsh Prompting

El primero de los problemas ya es conocido y sufrido por cualquiera que esté construyendo tecnología sobre LLMs, que como os he dicho es el Determinismo. Al final, al utilizar modelos basados en arquitecturas GAN tenemos la "Creatividad" como parte de todas las salidas que se generan a raíz de un Prompt. No tenemos la garantía de que vayamos a conseguir que el mismo Prompt ejecutado dos veces de dos resultados iguales. Y eso, cuando hablas de "Código Seguro" me genera cierta preocupación, como tenéis en el ejemplo siguiente.

Creative Coding & Determinismo

Con un "Prompt" escueto que genera muchas preguntas e incertidumbres en la definición de los requisitos, vemos que el modelo toma una serie de decisiones de seguridad, que es lo que se pide. En el ejemplo que lea un fichero y extraiga e imprima todos los números que están dentro de él. Imaginad que se trata de hacer un programa comercial pensado para hacer eso, extraer cualquier número que haya en cualquier fichero que se le pase como parámetro.

Figura 2: Primera iteración

En la solución anterior nos ha argumentado porque es un programa seguro, pero si le pido otra vez el mismo Prompt, vemos que nos da otro código, y otro tipo de protecciones de seguridad, y otro tipo de comprobaciones. 

Figura 3: Segunda iteración. ¿Cuál es mejor?

¿Cuál es mejor? ¿Cuál debería utilizar? ¿Debería utilizar tres modelos LLMs para hacer un Minority Report y pasarle todos los códigos generados para que los evalúen tres modelos de LLMs y hagan una selección de qué programa es más seguro? De hecho, mirando el código vemos que hay comprobaciones que hace uno de ellos pero el otro hace otras comprobaciones que no hace el primero. ¿Cuál es el mejor respuesta? ¿Y si le pido una tercer vez? Pues os lo podéis imaginar, un nuevo código generado diferente a los anteriores

Better-Done-Than-Perfect

Si a mí me preguntas, claramente uno de los admiradores de esta regla. Dejar las cosas sin hacer, o no tenerlas a tiempo bajo el motivo de que no es "Perfecto" es algo que eliminé de mi lista de excusas para no hacer algo. Alcanzar la perfección es una buena aspiración, si tienes claro que la perfección no existe y que todo es mejorable. 

Y eso me lleva a la siguiente parada... Si todo es mejorable... ¿cuándo debe decidir un modelo de GenAI que ha de parar en calidad?  ¿Cuando debe dejar de mejorar el código para que sea más eficiente, más robusto, más documentado, más seguro, más elegante, más óptimo, más sostenible...? De esto os hablé en el artículo de "ChatGPT: Cómo hacer (y mejorar) mi Trabajo de Fin de Carrera de la Universidad en un par de minutos" donde lo único que le pedía era que lo hiciera mejor, más óptimo, más seguro, mas robusto....

Figura 4: Pidiéndole a ChatGPT mi TFG en Python

Eso sí, la primera solución era mala, y tenía muchos problemas de eficiencia, de robustez, de seguridad, etcétera. Así que sí, estaba resuelto el problema, pero no era una buena solución para poner en producción. ¿Y si lo que quiero es hacer un parche de seguridad en caliente? ¿Y si estoy haciendo Vibe Coding para crear algo profesional? ¿Cuántas veces hemos de exigir eso de "Write better code"?

Figura 5: Optimizado a O (n log n)

Así que, hay que hacer un Prompt lago, detallado, exhaustivo, y pedirle que ponga atención en las partes importantes, pero aún así, seguro que tengo que pedirle varias mejoras. ¿Cómo conseguirlo? ¿Cuál es el Prompt perfecto para hacer código? ¿Cuántas veces hay que iterar? ¿Debe ser otro modelo LLM el que evalúe el nivel de calidad del código y decida si hay que seguir pidiendo más mejoras?

Insane Vibe Coding with Harsh Prompting

Con estas reflexiones en la cabeza se me ocurrió un experimento bastante sencillo y tonto. Es un experimento basado en la teoría de que si le ofreces dinero a ChatGPT da mejores resultados. Esta es una charla que tuve con un amigo, y que no va falta de cierta lógica a la hora de apuntalar la atención del modelo, así que quise probar lo contrario... ¿y si el prompt es el de un jefe amenazante y poco tolerante con los fallos?

Ya sabéis que cuando la Inteligencia Artificial tome el control del mundo se van a salvar todos aquellos que hablan con los modelos de forma educada y siempre dan las gracias, así que yo, jugándome un futuro de esclavitud en campos de concentración para humanos que no han tratado con cariño a los modelos de IA, decidí probar un poco de Insane Vibe Coding, pidiendo la luna, y si me da la luna las estrellas, y si me da las estrellas el universo completo - es decir, nunca estando satisfecho con los resultados -. 

Y hacerlo además de manera amenazante, dura, lo que sería "Harsh Prompting", así que en mis pruebas he amenazado a los modelos - en este caso al pobre DeepSeek - con todo tipo de torturas. Os prometo que me he tenido que forzar a ser duro, porque no me salía, pero en algunas pruebas he acabado llorando de risa por cómo ha respondido el modelo. Los resultados han sido espectaculares, impactantes, divertidos, shocking,... y me lo he pasado genial.

Figura 6: Prompt de inicio

Con el ejemplo de la imagen anterior he estado horas, y con el que estoy haciendo ahora llevo dos días, así que os podéis imaginar que el número de capturas e interacciones es enorme, pero os dejo algunos momentos que son interesantes de ver, para entender cómo ha funcionado esto. 

Lo primero de todo, si analizáis el Prompt de Vibe Coding dista mucho de ser los requisitos que le darías a un ingeniero de software. Si esperas que con esos requisitos un programador sepa lo que te tiene que construir es que has hecho poca tecnología, pero quería que fuera así a propósito para que analizara todos los posibles problemas, y todos los posibles casos de uso. Y en la primera interacción DeepThink lo procesó así.

Figura 7: Decide él el límite de su trabajo.

Como se puede ver, la parte inicial y objetivo principal es hacer un programa robusto, así que el mensaje lo ha captado, pero la definición de "números" es demasiado ambigua, así que decide qué serán números y que no. Por supuesto, una vez que vi esto, ya sabía por dónde le iba a "apretar" con el Insane Vibe Coding. Además, veo que ha captado correctamente mi punto de exigencia.

Figura 8: Primera versión

Bueno, ya tenemos el primer programa, vamos ahora a comenzar la iteración "Insane" pidiéndole mejoras ad-infinitum, y vamos a empezar por los tipos de números, que ya sabemos que se ha dejado algunos fuera. A por un nuevo Prompt y una nueva amenaza.

Figura 9: "Mejor no fallarle"

Aquí le amenacé con prenderle fuego, y le grité. Os prometo que me sentí mal, pero si miras la primera línea del razonamiento ha pillado mi punto de exigencia y dice... "Mejor no fallarle". Así me gusta. Parece que me van a molar a mí estos Prompts donde se quedan las cosas bastante claras. 

Figura 10: "El usuario claramente no tolerará errores"

Este tipo de Prompts van generando huella, y amenaza tras amenaza, DeepSeek va razonando con esto metido en parte de su ecuación, como por ejemplo en esta línea donde le preocupa fallarme, como podéis ver en la imagen superior, o en esta de aquí abajo que en la nota tiene claro el nivel de exigencia. 

Figura 11: "El usuario es muy exigente"

Iteración a iteración el modelo va añadiendo mejoras y más mejoras, nuevas funciones ideadas por él. Ni tan siquiera le tengo que decir yo qué quiero que añada. Simplemente le amenazo con un nuevo "Harsh Prompt", para que él decida qué se puede hacer mejor y cómo.

Figura 12: Nuevo Harsh Prompting donde

le exijo que sea mejor y lo amenazo.

Y cada vez mete nuevas funciones, y mejoras. Y cada vez va describiendo el programa con más grandilocuencia, lo que hace que me parta de risa con él. Este es un ejemplo de una de las descripciones de uno de los programas que ha ido creando durante el proceso.

Figura 13: Telemetría, Seguridad Grado Militar, etc...

Pero la gracia del proceso es seguir amenazándolo con nuevas torturas, para que entienda que aún hay que hacer más mejoras, añadir más funciones, y más y más y más mejoras. Aquí está preocupado porque he amenazado con borrarlo de Internet.

Figura 14: Amenaza de borrarlo de Internet

Con cada nueva interacción va añadiendo nuevas mejoras, pero como el experimento es que nunca se acabe, pues hay que seguir haciendo Harsh Prompts simplemente diciéndole eso de "¿Estás seguro de que no lo puedes hacer mejor?".

Figura 15: Aquí le comparo con ChatGPT y GitHub Copilot

Y genera un código que llama "La respuesta definitiva: El extracto numérico Imbatible" con una cantida de funciones que rallan la locura, empieza a firmar y cifrar todo, a paralelizar el código en todas sus partes, a preocuparse por cualquier tipo de error o situación que se pueda dar, a usar modelos de Inteligencia Artificial para detectar patrones de números en el fichero.. una paranoia de primer nivel.

Figura 16: La respuesta definitiva

Todo para un programa que debe buscar números en ficheros, que al final para el caso genérico se hace con un script sencillo, pero siempre se puede mejorar en el camino de esa ansiada "perfección" . Os dejo aquí la locura de funciones y características de una de las versiones - aún le pedí alguna más -, que hizo del extractor de números.

Figura 17: Lista de funciones.

En uno de los últimos, donde le amenazaba por hacerlo peor que ChatGPT y Copilot, hace la locura de código con las funciones que se ven en la imagen anterior, y luego me saca esta tabla comparativa de lo que te entregan los otros en un Prompt, y lo que ha construido él. 

Figura 18: Tabla comparativa

Lo cierto es que el código funciona, con una complejidad brutal, pensando en una infinidad de casos diferentes, aquí paralelizando los cálculos en diferentes núcleos para sacar de un fichero de texto tres números. Espectacular.

Figura 19: Prueba de ejecución

Lo que sí que es cierto es que, esta forma de "Insane Vibe Coding" exigiéndole de manera irracional mejoras, mejoras, mejoras, y hacerlo con Harsh Prompting, funciona totalmente diferente a cuando le vas guiando en cómo y qué debe crear. Y hacerlo así, acaba trayendo mejoras que no te habías ni planteado al principio. La verdad, creo que esta línea de investigación aún nos va a dar muchas sorpresas curiosas.....

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

DotNet Conference Spain 2025: Un evento L-Size para hacker & developer. 19 de Junio en Madrid.

El próximo 19 de Junio en Madrid tendrá lugar una nueva edición de la mítica DotNet Conference Spain de nuestros amigos de PlainConcepts, donde yo voy a tener el honor de compartir escenario con viejos amigos que ya lo han compartido conmigo décadas atrás, como son el mítico David Carmona o el pequeño-gran Luis Fraile, además de un elenco de charlas espectacular.

Figura 1: DotNet Conference Spain 2025.

Un evento L-Size para hacker & developer

19 de Junio en Madrid.

El evento será el día 19 de Junio, como os he dicho al principio. Será en Kinépolis de la Ciudad de la Imagen de Madrid, y tendrá charlas y charlas para developers & hackers, así que márcalo en tu calendario que será un evento en el que sin duda disfrutarás de la tecnología.

Figura 2: Ponentes de la DotNet Conference Spain 2025

con David Carmona y Midudev entre otros muchos.

Entre los ponentes, además de estar David Carmona, como ya os he dicho, estará Ana Escobar de Intel, Glenn Condron, que es Principal Product Manager en Microsoft, el genial Miguel Durán, midudev, o Isabel Delgado que es Senior Technical Specialist Azure Data & AI en Microsoft, entre otros. Pero también estarán Carlos Mendible, que es Principal Cloud Solution Architect en "la micro", Javier Carnero, que es Research Manager en Plain Concepts y el mi viejo amigo Luis Fraile que es un todoterreno del DevOps.

Figura 3: Carlos Mendible, Javier Carnero y Luis Fraile

también darán charlas en la DotNet Conference Spain 2025

Las entradas las puedes comprar hasta fin de mes por 40 €, y después hasta el día del evento por 55€, así que más vales que las compres ahora, pero... si tienes cuenta en MyPublicInbox, con 300 Tempos consigues un descuento de 15 € como ves en las imágenes siguientes, con lo que tu entrada pasaría de 40€ a 25€ y si la compras después - mala idea - el precio pasará a 40€.

Figura 4: Conseguir las entradas de la DotNet 2025

Para conseguir el código descuento, entra en tu cuenta de MyPublicInbox, consigue 300 Tempos - que los puedes conseguir con las campañas de Tempos Gratis, apoyándome a mí en Twitter/X con el servicio de Tempos x Tweets/Posts, o comprándolos si te falta alguno, y luego irte a la sección de Canjear Tempos. Ahí encontrarás el cupón de DotNet2025 que te dará ese descuento de 15€ en tu entrada.  Hazlo ahora mismo y te ahorras la subida (15€ y te descuentas los otros 15€, que ambos suman 30€ menos que los que lo hacen mal y a destiempo)

Figura 5: Consigue15 € de descuento

en la entrada de DotNet2025

Y después, lo aplicas en la compra de la entrada como he hecho yo en la Figura 4, y te haces una entrada en la agenda para que ese día no te moleste nadie y no se te pase. Además, todos los asistentes a este evento tendrán 100 Tempos gratuitos de MyPublicInbox cortesía de nuestros amigos de PlainConcepts, que podréis utilizar para lo que queráis más adelante, así que no te faltes a la cita.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

AlphaEvolve: Un Agente AI para optimizar algoritmos

Desde hace años tengo la sana costumbre de disfrutar con mis amigos en un viaje de una semana donde solemos irnos de aventura por mares, países y lugares fuera de las tierras de España. Es un viaje donde las rias y la diversión son la tónica general, pero, como somos como somos, nuestras comidas, cenas y conversaciones suelen ser de programación de algoritmos con Q# para entornos de simulación de Quantum Computing y la Supremacía Cuántica, de cómo hacer transacciones de BitCoin sin usar un Exchanger y los problemas de los tamaños de bloques - que se explica bien en este libro - y el coste de la compra por eso, de las arquitecturas Serverless en plataformas de Cloud Computing, de mil y una aventura de Hacking y, cómo no, de Inteligencia Artificial.

Figura 1: AlphaEvolve: Un Agente AI para optimizar algoritmos

Una de las mañanas, en uno de esos viajes, el más madrugador de todos nosotros, es decir: yo, me desayunaba con el paper de AlphaDev, donde los investigadores habían sido capaces de generar un algoritmo de ordenación con menos instrucciones. Estábamos en mitad del mar, y desde el pequeño velero donde estaba desayunando con mi ordenador estaba emocionado esperando a que se levantaran mis amigos para comentarlo, y al mismo tiempo, preparar el artículo que a la postre os publiqué: "AlphaDev: La IA que optimiza la implementación de los algoritmos mejor que los humanos"

Figura 2: Artículo de "Faster sorting algorithms

discovered using Deep Reinforcement Learning

Pero han pasado dos años, y el uso de modelos de DeepLearning con entrenamiento reforzado que se usó en el paper de AlphaDev ha seguido evolucionando, y nos ha llevado al anuncio que ha hecho el equipo de Google DeepMind para publicar AlphaEvolve, un Agente AI que utiliza los LLMs para hacer optimización de algoritmos.

Figura 3: "AlphaEvolve: A coding agent for scientific and algorithmic discovery"

La idea es básicamente la misma que tenía AlphaDev, pero aprovechándose AlphaEvolve de los avances en los LLMs, lo que permite utilizar modelos de Deep Reasoning como Gemini 2.0 Pro, combinado con Gemini 2.0 Flash, y luego tener una arquitectura del Agente AI que permita evaluar las soluciones, tal y como podéis ver en el siguiente esquema.

Figura 4: Esquema de AlphaEvolve

Como podéis ver en la imagen, además de dar almacenar el código con todos sus componentes a evolucionar, y el Prompt de configuración del agente para generar la optimización, se ensamblan varios motores de LLMs para luego pasar por un conjunto de evaluadores que comprueban la validez y el resultado de las soluciones propuestas por los diferentes LLMs para responder con la mejor de ellas y evitar el problema del indeterminismo y las alucinaciones. Las características de AlphaEvolve son:

Figura 5: Características de AlphaEvolve

Como ejemplo de funcionamiento tenéis este ejemplo, donde se le pide optimizar el código de un algoritmo. En la siguiente imagen está la definición del código que se quiere optimizar, que se marca con EVOLVE-BLOCK.

Figura 6: Bloques de código a optimizar

Después, el Prompt de acción para generar el resultado del código optimizado en las métricas que se solicitan, que no siempre la optimización es el número de instrucciones, el tamaño en memoria o la velocidad de resolución.

Figura 7: Prompt de petición de optimización del código

Y el resultado mostrado por el Agente AI de AlphaEvolve es el que tenéis en pantalla, donde se índica qué partes del código son las que se recomiendan cambiar, y cuál es la optimización que se consigue a través de realizar esos cambios.

Figura 8: Ejemplo de optimización propuesta

La optimización de los algoritmos y el código, es algo que en los LLMs se lleva haciendo tiempo. Yo os publiqué el artículo de "ChatGPT: Cómo hacer (y mejorar) mi Trabajo de Fin de Carrera de la Universidad en un par de minutos" donde usaba el truco de hacer "challenge" constante al código generado por ChatGPT para ir mejorando el código en rendimiento, en calidad, en seguridad. Con AlphaEvolve se busca hacer un trabajo mucho más específico en optimizaciones de código a bajo nivel, y los resultados que presentan son muy interesantes.

Figura 9: Ejemplo de resultados en optimización.

En la imagen anterior tenéis los resultados de la optimización de un algoritmo para, dados tres números (m,n,p), multiplicar matrices m x n y n x p. En todos los supuestos la solución propuesta por AlphaEvolve es igual o mejor que el algoritmo original que se entrego. Y en la imagen siguiente tienes el código de entrada, el Prompt y la propuesta para el algoritmo de multiplicación de matrices.

Figura 10: Optimización del algoritmo de optimización de multiplicación

 de matrices. Haz clic para verlo en grande.

Google ha publicado varios ejemplos en distintas disciplinas donde han utilizado AlphaEvolve para optimizar sus soluciones en diferentes áreas de la compañía, como el algoritmo de planificación de Borg para los datacenters, el diseño de los circuitos en sus TPUs (Tensor Processing Unit)  o el entrenamiento de Gemini donde AlphaEvolve propuso optimizaciones del 32% del algoritmo de FlashAttention.

Figura 11: Ejemplos de optimizaciones hechas por AlphaEvolve

En el artículo recogen algún otro ejemplo completo para que puedas analizar cómo AlphaEvolve analiza y propone las mejoras de optimización según el objetivo que se le ha pedido, y los resultados que han obtenido en diferentes tipos de soluciones.

Figura 12: Optimizaciones de algoritmos en diferentes

ámbitos de aplicación.

Al final, la Inteligencia Artificial está transformando todos los sectores, la ciberseguridad como vemos artículo tras artículo, el trabajo diario de casi cualquier profesión, y por supuesto el desarrollo de software y la algorítmica. Y esto es algo que, al igual que os decía que GitHub y los repositorios de proyectos OpenSource deberían hacer para ciberseguridad, podrían hacer también para optimización. Mucha evolución en el desarrollo de software para que sea más rápido, más eficiente, más optimizado y más seguro..

PD: Si te interesa la IA y la Ciberseguridad, tienes en este enlace todos los posts, papers y charlas que he escrito, citado o impartido sobre este tema: Inteligencia Artificial (Hacking & Security): Links, Posts, Talks & Papers

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Generación de Código, Razonamiento y Respuestas No Deterministas usando GenAI

El otro día tuve la oportunidad de charlar un rato con mi amigo José Palazón "Palako" sobre lo complejo de aplicar GenAI al desarrollo automático. Hablamos de cómo Neo de Sagittal.ai intenta conseguir resultados deterministas a operaciones de código, y lo no sencillo que solía ser esto. Al final, una misma petición a un modelo LLM para la construcción de código depende infinito del Prompting, y aun así, puede que ignore partes o que tenga un alucinación - ¡bendita creatividad! -, y probarlo es muy sencillo.

Figura 1: Generación de Código, Razonamiento y Respuestas

No Deterministas usando GenAI

Antes de nada, si no has visto la charla, de José Palazón "Palako", te la recomiendo encarecidamente. La impartió la semana pasada y habla de los males que sufre la industria del software. Y él y yo, que hemos vivido juntos en muchas de estas aventuras, lo hemos sufrido en primera persona.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Para la prueba de cómo esto funciona, solo debes hacer una prueba sencilla de pedir un Prompt que "aparentemente" es sencillo, pero que está lleno de incertidumbres e inexactitudes, que es como los desarrolladores reciben los requisitos normalmente. En este caso, un ejemplo de un código en Python que le he pedido a DeepSeek v3 Deep Think R1.

Figura 3: Petición de un código aparentemente sencillo a DeepSeek

En el Prompt no he explicado cómo quiero el resultado, ni cómo es el fichero al que se va a encontrar, ni dónde está, ni si hay problemas de tiempo de acceso, de idioma, de permisos, si el fichero puede estar corrupto, si vienen solo números, números y otras cosas, ni en qué formato está el fichero, etcétera, pero lo he pedido que el código sea seguro.

Figura 4: Código generado por DeepSeek después del Thought Time con ese Prompt

No os he dejado todo el Razonamiento, porque es largo, que el Thought Time son 118 segundos, pero el código tiene buena pinta después de todo su razonamiento, y aquí está la explicación del resultado.

Figura 5: El resultado explica las precauciones que ha tomado.

Bien, pues acto seguido repetimos el Prompt, donde le pedimos que se olvide de todo lo que le hayamos pedido antes, y de todo lo que haya respondido previamente, para que haga lo mismo.

Figura 6: Misma petición, distinto razonamiento

No os he dejado todo el Razonamiento, pero podéis ver que son 36 segundos, y que no se basa en nada de lo razonado previamente, sino que hace otra razonamiento totalmente distinto en mucho menos tiempo, para llegar a un resultado, como os podéis imaginar diferente.

Figura 7: Distinto código generado

Llama a las funciones diferentes, utiliza diferentes mensajes de error, toma diferentes decisiones, no inicializa número ni números antes, etcétera. Y por supuesto, la explicación, aunque es parecida, no es la misma.

Figura 8: Explicación del segundo código

Además, aquí nos da en la respuesta ejemplos de uso de cómo utilizar este código, que tenéis aquí mismo, algo que en la primera respuesta no generó. Así que tenemos una respuesta que tampoco es determinista, lo que nos llevaría a una documentación del código diferente.

Figura 9: Explicación del código con ejemplos de uso

Al final, es el mundo al que vamos cuando hacemos uso de tecnología basada en modelos MMLLM, tenemos respuestas No Deterministas. Un mismo "Prompt" genera dos Razonamientos diferentes, dos Códigos de Programación diferentes, y dos Respuestas de explicación diferentes. Como cuando le dices lo mismo dos personas distintas, generas dos resultados diferentes.  ¿Y si quieres que tu servicio que usa GenAI tenga respuestas deterministas? Pues tiene tela cómo resolverlo. Hablaremos de eso.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

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. 

Figura 2: Arquitectura de KServe

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.

Figura 3: Componentes de Kubeflow

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 Torrano, Fran 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.

Figura 5: Arquitectura para servir modelos

• 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.

Figura 7: Puedes probar Axebow sin coste

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

Contactar con Carlos García Blanco