Ai2 publicó el 9 de octubre de 2026 en Hugging Face cómo ha cambiado la forma de repartir miles de GPUs NVIDIA H100, B200 y B300 entre unos 150 investigadores internos. No es una noticia vistosa de modelo nuevo. Precisamente por eso merece atención: habla del problema que aparece cuando la IA deja de ser una demo y empieza a consumir recursos de verdad.
El equipo de infraestructura de Ai2 explica que llegó a tener peticiones de GPU entre dos y tres veces superiores a la capacidad disponible. Su sistema anterior, basado en prioridades y trabajos protegidos frente a interrupción, acabó generando comportamientos previsibles: equipos que retenían recursos, colas difíciles de defender y decisiones caso por caso. La solución que describen combina presupuestos de tiempo de GPU, reparto jerárquico justo y contratos de uso por tramos de tiempo.
Para una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, la lectura no es "necesitamos un clúster de GPUs". La lectura útil es más cercana: si la IA va a entrar en ventas, soporte, administración, ingeniería o atención al cliente, alguien tiene que decidir qué trabajo merece gastar cómputo, tokens, licencias y horas de revisión. Si no se decide antes, se decide tarde y con la factura encima.
Qué ha contado Ai2
Ai2 gestiona clústeres de entre 88 y 1.024 GPUs para cargas grandes de entrenamiento distribuido. En la publicación separan cuatro métricas: disponibilidad, ocupación, impacto y utilización. La parte interesante está en "impacto": no basta con que las máquinas estén ocupadas, tienen que estar ocupadas con el trabajo que más valor aporta.
Según el artículo, el sistema anterior permitía que algunos trabajos no fueran interrumpibles. Eso daba seguridad a quien lanzaba experimentos largos, pero también abría la puerta a bloquear capacidad. Ai2 habla incluso de casos de GPU squatting, cargas sin trabajo real que mantenían acceso reservado para cuando alguien quisiera usarlo.
La alternativa fue dejar de discutir cada cola como si fuera una emergencia técnica. En vez de asignar máquinas fijas a equipos, asignaron presupuestos de tiempo de GPU. Cada proyecto sabe qué parte de la capacidad le corresponde. Si quiere proteger un trabajo, lo paga con su presupuesto. Si no hay presupuesto, el trabajo puede ejecutarse cuando haya hueco, pero no bloquea a otros.
Dicho en castellano de empresa: menos "esto es urgente porque lo digo yo" y más "este proyecto tiene una bolsa aprobada, este otro no".
Por qué esto importa fuera de un laboratorio
La mayoría de empresas de Gipuzkoa no están entrenando modelos frontera. Pero sí están empezando a acumular consumo de IA en sitios distintos: ChatGPT Enterprise, Copilot, Gemini, Claude, APIs de modelos, vector databases, automatizaciones, RAG privado, transcripción de reuniones, OCR, agentes conectados al CRM o herramientas de soporte.
Al principio parece poco. Una licencia aquí, un piloto allí, unas llamadas API en un flujo de n8n, un asistente documental para un equipo. Después llega la pregunta incómoda: quién está usando qué, para qué tarea, con qué retorno y con qué límite.
Ese salto suele pillar a las empresas a medias. Finanzas ve gasto fragmentado. IT ve herramientas que han entrado por varios caminos. Dirección ve promesas de productividad, pero pocas métricas comparables. Los equipos, mientras tanto, solo quieren que la IA funcione cuando la necesitan.
El artículo de Ai2 pone nombre a una idea sencilla: la capacidad compartida necesita reglas antes de saturarse.
El equivalente empresarial: presupuesto de IA por caso de uso
No hace falta copiar el modelo de Ai2. Sí conviene copiar la disciplina.
Para un piloto de IA en una empresa local, yo empezaría por presupuestar el caso de uso, no la herramienta. Por ejemplo:
- triaje de incidencias de soporte;
- resumen de reuniones comerciales;
- revisión de facturas recibidas;
- asistente RAG para documentación interna;
- clasificación de leads;
- agente que prepara borradores en el CRM.
Cada caso debería tener una bolsa clara: coste mensual máximo, volumen esperado, responsable, herramienta permitida, datos que puede usar y criterio para parar. No hace falta hacerlo burocrático. Basta con que nadie pueda decir dentro de dos meses: "no sabemos quién lo está usando ni cuánto cuesta".
El presupuesto tampoco debería limitarse al precio del modelo. Hay otros costes más silenciosos: preparar datos, revisar respuestas, mantener conectores, corregir errores, formar al equipo y medir si el flujo se usa. En algunos pilotos, los tokens son la parte barata. Lo caro es el tiempo humano que se va en perseguir excepciones.
Señales de que necesitas poner orden
Hay síntomas bastante claros:
- varios equipos contratan herramientas de IA sin saber qué usa el resto;
- nadie sabe qué prompts, automatizaciones o agentes están en producción;
- el gasto sube, pero no hay una métrica de ahorro o conversión;
- se discute cada excepción como si fuera nueva;
- un piloto funciona en demo, pero nadie ha definido quién paga su uso real;
- IT se entera tarde de que una herramienta ya toca datos internos.
Cuando aparecen dos o tres de estas señales, no hace falta frenar todo. Hace falta hacer inventario y poner límites razonables.
Un marco práctico para empresas de Gipuzkoa
La versión corta puede caber en una tabla con siete columnas:
Caso de uso Equipo dueño Datos permitidos Acción de la IA Revisión humana Límite mensual Métrica Triaje de tickets Soporte correo de soporte y histórico de categorías resumir, clasificar y proponer urgencia antes de responder al cliente 300 euros tiempo hasta primera clasificación RAG documental Oficina técnica manuales internos aprobados responder con fuentes revisión por responsable de área 500 euros respuestas útiles con fuente correcta Leads B2B Comercial formularios y CRM autorizado preparar ficha de encaje comercial decide siguiente paso 250 euros leads cualificados aceptadosLa tabla no resuelve el proyecto, pero cambia la conversación. Ya no se habla de "meter IA" en abstracto. Se habla de trabajo, datos, coste y resultado.
El gancho comercial está en gobernar antes de escalar
La noticia de Ai2 tiene un gancho claro para captación cualificada: muchas empresas no necesitan más demos de IA, necesitan una forma seria de decidir qué pilotos merecen recursos.
Eso aplica tanto a una pyme industrial de Gipuzkoa como a una empresa de servicios en Donostia - San Sebastián o a un equipo distribuido en Euskadi. La IA puede ahorrar tiempo, sí. También puede repartir gasto por toda la organización sin que nadie vea el dibujo completo.
Antes de escalar agentes, RAG o automatizaciones, conviene responder cuatro preguntas:
- qué tarea consume recursos;
- qué equipo se hace responsable;
- cuánto puede gastar al mes;
- qué métrica demuestra que merece seguir.
Si esas cuatro respuestas no existen, el piloto todavía no está preparado para crecer.
Qué haría antes de comprar más licencias
Primero, un inventario de usos reales. No solo herramientas aprobadas: usos reales. Quién resume reuniones, quién pega documentos, quién usa APIs, quién ha montado automatizaciones y qué datos pasan por cada flujo.
Después, separaría tres bolsas: productividad personal, procesos de equipo y sistemas críticos. No tienen el mismo riesgo ni deberían tener el mismo control. Un asistente para redactar borradores internos puede tener reglas ligeras. Un agente que consulta CRM, tickets o facturas necesita permisos, registro y revisión.
Por último, pondría límites mensuales por caso de uso. Si un piloto demuestra retorno, se amplía. Si no lo demuestra, se cierra sin drama. Es una forma mucho más sana de trabajar que dejar crecer el gasto por inercia.
Umintia puede ayudar a hacer ese mapa inicial: casos de uso, datos, límites, permisos, métricas y siguiente piloto razonable. No hace falta empezar con una arquitectura enorme. Hace falta saber qué trabajo merece presupuesto y cuál sigue siendo curiosidad técnica.