¿Debería tu equipo de ingeniería alojar su propio modelo de código abierto?

David Abitbol, quien dirige las operaciones de IA en Revolut, describió el despliegue en una charla en la conferencia de AI Engineer en Nueva York a finales de 2026. Revolut hace seguimiento de dos cifras en una muestra de alrededor de 2.000 ingenieros: el tiempo de codificación en horas y el tiempo de entrega en días, desde que se toma una funcionalidad hasta que queda fusionada y lista para desplegar.

Un despliegue inicial de Gemini de Google con acceso a datos internos mejoró ambas métricas de forma modesta, principalmente al sustituir las búsquedas en la documentación. Después llegó Claude Code de Anthropic bajo presupuestos de tokens estrictos por ingeniero, tras que algunos ingenieros generaran facturas elevadas con poco retorno claro, y Abitbol dice que al principio mostró poco efecto medible.

Lo que cambió las cifras fue alojar un modelo de pesos abiertos, el GLM de Z.ai, a partir de alrededor de abril de 2026, sin ningún límite de tokens. El tiempo de codificación mejoró alrededor de un 60% y el tiempo de entrega alrededor de un 70%. Revolut ahora trata el modelo alojado internamente como la opción predeterminada para la codificación diaria, con una facturación fija y predecible, y reserva las herramientas de frontera como la excepción para los problemas más difíciles.

Con aproximadamente 2.000 ingenieros, servir el modelo requirió 56 GPU Nvidia B200, buscando un tiempo hasta el primer token por debajo de tres segundos (las quejas empiezan después de cinco). El costo combinado resultó en alrededor de US$0,30 por millón de tokens, cerca de un décimo de lo que Revolut había estado pagando a Anthropic y OpenAI combinados.

La propia lectura de Abitbol sobre los datos es la parte más útil: el tiempo de entrega mejoró más que el tiempo de codificación, lo que significa que la codificación nunca fue el principal cuello de botella. Cuando ya nadie tiene que ahorrar tokens para el ticket más difícil del trimestre, los ingenieros empiezan a usar la IA en el correo, Jira, Confluence y el resto del trabajo que rodea a una funcionalidad, no solo en el código en sí.

Esa lección se mantiene sin importar qué modelo use un equipo. Un equipo que usa una API de frontera y asigna un presupuesto de tokens por ingeniero, o limita el uso para controlar el costo, está recreando exactamente el mismo problema de racionamiento que Revolut resolvió al eliminar los límites. La solución no siempre es alojar el modelo; a veces basta con un plan de precios más económico o más fijo con el mismo modelo de frontera.

La conclusión práctica para cualquier líder de ingeniería es medir el tiempo de entrega, no solo el tiempo de codificación o las líneas generadas, antes de decidir si las herramientas de IA están valiendo la pena, y vigilar si los propios ingenieros están racionando su uso por presión de costos o de cuota.

Esta página se centra en la decisión de costo de equipo y despliegue: si alojar el modelo o no, y cómo implementarlo una vez que se decide hacerlo. Para la pregunta más amplia e independiente del modelo sobre qué significan realmente los pesos abiertos, el código abierto y las API cerradas, y por qué los laboratorios y los gobiernos los tratan de forma distinta, la guía de Nightschool AI Modelos de IA de código abierto frente a cerrado cubre ese terreno en profundidad.

Las cifras de infraestructura de Revolut son una advertencia útil contra la idea de que alojar un modelo es sencillo una vez que se tienen las GPU. De abril a agosto de 2026, con la cantidad de GPU fija en 56, la carga subió de alrededor de 3 a más de 7 solicitudes por segundo, mientras que el tiempo hasta el primer token cayó de aproximadamente 14 segundos a menos de 2, una mejora de latencia del 88% sin hardware nuevo.

Abitbol atribuye alrededor del 80% de esa mejora a la configuración de servicio, no a las GPU: limitar la longitud de contexto muy por debajo del máximo anunciado del modelo, usar cuantización de menor precisión en hardware de GPU de generación actual, y ajustar cómo se divide la caché de atención del modelo entre los dispositivos. Su resumen para los equipos que consideran este camino es directo: cargar los pesos en las GPU y darlo por terminado produce un rendimiento pésimo.

Ese trabajo de ajuste es un costo operativo real y continuo que la mayoría de los equipos subestima cuando compara el precio nominal de un modelo alojado internamente con una factura de API.