Del portátil al clúster: llevar un agente de IA a producción con vLLM en OpenShift

Un agente que corre en un portátil es un sueño para una sola persona: Qwen3 razona, Ollama sirve, ningún dato sale de la máquina y la factura es cero. Pero el sueño termina en cuanto la tapa se cierra para volver a casa, o una segunda persona quiere tocar la misma mente; un montaje de una máquina y un usuario se derrumba ante la realidad multiusuario. El presentador construye toda su pregunta sobre esa fractura: cómo convertir este montaje silencioso en un servicio que use una multitud, sin caer en la trampa de la máquina única .

El montaje inicial es sobrio: un agente de tres herramientas que lleva una calculadora, un buscador web y una conexión GitHub MCP, con el razonamiento aportado por el modelo abierto Qwen3 y el servicio a cargo de Ollama en el portátil. Como ningún dato sale de la caja, no hay dolor de privacidad ni línea de coste; la libertad de ensayo es total. El anfitrión describe esta comodidad como un dúo de una persona y una máquina, y luego plantea con nitidez la pregunta de producción: cómo puede el mismo agente vivir sin depender de un portátil con la tapa cerrada.

La idea más fuerte llega en el primer minuto: nada cambia dentro del agente — lo que cambia es dónde se sirve el modelo y dónde corre el agente. Hay dos gestos: primero Ollama cede el paso a un servidor de inferencia ajustado al tráfico simultáneo, y luego todo el montaje se mete en un contenedor y se muda a un clúster OpenShift. La misma forma funciona con puntos de acceso externos como Claude o GPT; al agente no le importa de dónde viene el razonamiento mientras tenga una abstracción de punto de acceso con la que hablar. La documentación de Unsloth describe servidores como Ollama y vLLM conectados con el mismo patrón de interfaz compatible con OpenAI, y por eso la distancia entre portátil y clúster se reduce a tres líneas de un archivo .env.

Primer gesto: la capa del modelo

El primer gesto apunta a la capa del modelo. El montaje Ollama del portátil se sustituye por servicio vLLM vía OpenShift AI; vLLM es un proyecto abierto nacido en Berkeley que, según la presentación del blog de RedHat, se diseñó para la eficiencia de la memoria de los aceleradores y la velocidad, reuniendo más de 40 000 estrellas en GitHub. Como explica el artículo de fondo de TheNewStack, el servidor sostiene con eficiencia las llamadas apiladas sobre un mismo modelo gracias al agrupamiento continuo y la atención paginada, con familias admitidas desde Llama y Mistral hasta Granite y DeepSeek. En el flujo de AI Hub, el modelo se trae de una dirección URI de HuggingFace, se eligen recursos de aceleración y un motor de ejecución, y el despliegue produce un enlace interno para el acceso dentro del clúster, un enlace externo para el acceso desde fuera, más una clave API que autentica las peticiones. La diferencia en .env cabe en tres líneas: el servicio vLLM del clúster en vez de Ollama en local, la clave nueva y la identidad de modelo que espera vLLM.

La mente de la máquina es Qwen3. Según el anuncio oficial publicado en GitHub, el buque insignia 235B-A22B compite con modelos de primer nivel como DeepSeek-R1 y Gemini-2.5-Pro en código y matemáticas, mientras un pequeño montaje de expertos mezclados como 30B-A3B y versiones densas de 0,6B a 32B se comparten en pesos abiertos bajo licencia Apache 2.0. Una ventana de contexto larga y un modo de pensamiento híbrido hacen a la familia apta para cargas de agente que llaman herramientas; el pequeño montaje gratuito del portátil en la demostración es el rostro cotidiano de esa apertura de licencia.

Segundo gesto: contenedor y clúster

El segundo gesto apunta al agente mismo. Primero se toma un comando de sesión desde la consola OpenShift para entrar al clúster; luego la imagen se construye con Podman, se envía vía Quay y se pone en servicio — Docker hace el mismo trabajo. Los comandos make del repositorio reducen los pasos de construcción, envío y despliegue a unas pulsaciones. Un minuto después, el punto de acceso del modelo y el agente corren como pods lado a lado en el mismo clúster; el pod se programa, la imagen se descarga, y el agente que vivía en un portátil hace un minuto ahora vive como un pod en OpenShift. Ni una línea de código cambió — solo cambió la dirección del domicilio.

En la prueba en directo, el agente primero se tantea con una búsqueda web y una pregunta de cálculo, y luego se le pide leer un ticket en GitHub y abrir uno nuevo, con la misma herramienta MCP cargando lecturas y escrituras desde dentro del clúster. Los registros de diálogo se siguen en el patio de juegos RedHat OpenShift AI en vez de una terminal local; del modelo al agente hasta el patio de juegos, todo corre en el clúster, y el montaje pasa al seguimiento en registros dentro del clúster .

Desplegado no significa listo para producción

El final traza una frontera honesta: el pod puede leer cualquier archivo de su propio contenedor y alcanzar casi todo fuera; visibilidad de conductas, límites de recursos, uso seguro multiequipo, permisos asignados al agente y acotación de conductas brillan por su ausencia. Según el enfoque de confianza cero del artículo de CNCF, el tráfico de red sin coto y los puntos de acceso abiertos en cargas de IA sobre clústeres son la edición cara de problemas clásicos — una clave robada no es una fuga pequeña sino una factura que se hincha. El diseño abierto de Agent Sandbox recogido por InfoQ levanta aislamiento con una cortina gVisor, mientras la vía de areneros efímeros presentada por Google en KubeCon apunta a la misma brecha. El repositorio y el manifiesto esperan en los enlaces; el blindaje queda como tema del próximo video.