GitLab abre más modelos open source para Duo Agent Platform Self-Hosted: cuándo sí conviene y cuándo no
GitLab anunció el 21 de mayo de 2026 más modelos open source para Duo Agent Platform Self-Hosted, con foco en entornos air-gapped y regulados. La novedad útil no es otra tabla de compatibilidad: es poder rutear agentes por modelo y plataforma sin entregar código a terceros por defecto.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Cuando un vendor promete agentes para toda la empresa, casi siempre asume internet abierta, inferencia cloud y tolerancia razonable a que el código salga de tu perímetro. Muchísimos equipos no viven en ese mundo.
Por eso el anuncio de GitLab del 21 de mayo de 2026 sí merece atención: Duo Agent Platform Self-Hosted ahora soporta más modelos open source y empuja una idea muy concreta para entornos regulados, air-gapped o con residencia de datos estricta. La historia no es “más modelos por tener más modelos”. La historia es más margen para asignar el modelo correcto a la tarea correcta sin depender por defecto de un proveedor externo.
GitLab lista cuatro incorporaciones para ese tramo:
- Mistral Devstral 2 123B
- GLM-5.1
- Kimi-K2.6
- MiniMax-M2.7
La señal útil no es la lista; es el patrón de despliegue
La mayoría de comparativas de modelos se queda en benchmark, latencia o precio. GitLab baja la discusión a otra capa: qué modelo puedes usar cuando no puedes mandar el código a una API pública.
Ahí entran tres piezas que la documentación deja bastante claras:
- puedes correr un AI Gateway propio;
- puedes servir modelos compatibles desde plataformas como vLLM;
- y puedes mezclar despliegue totalmente self-hosted con una configuración híbrida por feature.
Eso cambia bastante la conversación para builders empresariales. Ya no es solo “qué modelo razona mejor”, sino:
- cuál entra en tu perímetro;
- cuál aguanta tool use y diffs grandes;
- cuál merece GPU propia;
- y cuál solo usarías en ciertos flujos.
Dónde sí veo demanda cualificada
Aquí tampoco hace falta inventar volumen. Las señales de demanda son bastante obvias:
- búsqueda por
GitLab Duo self-hosted models; - equipos preguntando por
air-gapped AI agents; - comparativas de
vLLM coding agents; - y la presión creciente por operar agentes sin exponer código sensible.
Ese tráfico puede ser pequeño frente a “GPT-5” o “Claude Code”, pero es muchísimo más valioso. Quien busca esto normalmente ya está evaluando compra, arquitectura o cumplimiento.
Lo importante: GitLab no te obliga a una sola estrategia
La docs de Self-hosted models remarca algo que vale más que la lista de compatibilidad: puedes operar en varios modos.
Opción 1: totalmente self-hosted
Sirve cuando de verdad no puede salir nada del entorno. GitLab lo plantea para escenarios con barreras físicas, red aislada o regulación fuerte. Aquí el argumento es claro: inference data, prompts, código y respuestas no salen de la red del cliente.
Opción 2: híbrido por feature
También puedes tener tu propio AI Gateway para la mayoría del trabajo y usar modelos gestionados por GitLab en funciones puntuales. Esa flexibilidad es útil cuando quieres aislar lo sensible, pero no pagar la complejidad de self-hostear absolutamente todo.
La consecuencia práctica es buena: ya no tienes que elegir entre pureza ideológica y pragmatismo total. Puedes rutear por riesgo y por costo.
El error sería creer que self-hosted sale gratis
No sale gratis. Sale distinto.
Moverte a esta ruta implica asumir:
- operación del AI Gateway;
- selección de hardware o GPU VM;
- mantenimiento del serving stack;
- y pruebas serias de calidad por feature, no por intuición.
GitLab recomienda vLLM como plataforma de serving para open source, pero eso no convierte el problema en trivial. Lo vuelve posible.
Cómo decidir si este anuncio te sirve de verdad
Yo usaría un criterio simple.
Sí conviene explorar esta ruta si:
- tu equipo no puede exponer código a terceros;
- ya tienes presión por residencia de datos;
- quieres separar features por riesgo y no por moda;
- o necesitas un plan real para agentes en entornos regulados.
No conviene venderlo como solución universal si:
- todavía no tienes disciplina de evaluación;
- ni siquiera sabes qué tareas justifican un agente;
- o tu principal problema sigue siendo instrucción, no infraestructura.
En esos casos, cambiar a self-hosted solo te da más piezas que mantener.
Mi lectura
Este anuncio compite bien porque ataca una consulta que sí existe y casi siempre está mal resuelta en español: cómo correr agentes útiles cuando la política de datos no te deja usar el camino cómodo.
GitLab no está diciendo que todos deban self-hostear modelos. Está diciendo algo más razonable: si necesitas hacerlo, ahora tienes más opciones reales para empatar modelo, plataforma y restricción operativa.
Si estás comparando esta ruta con otras más abiertas, conviene cruzarla con nuestra nota sobre GitLab Orbit, porque una historia resuelve contexto y esta resuelve perímetro + modelo. Y si todavía te falta la base antes de elegir infraestructura, el punto de entrada correcto sigue siendo el curso gratis.
La conclusión corta es esta: GitLab está haciendo que Duo Agent Platform Self-Hosted se parezca menos a una casilla de compliance y más a una arquitectura usable para agentes con código sensible.