Microsoft Foundry: modelos abiertos sin el stack

Qué cambia cuando un modelo abierto pasa a producción

AT&T corre alrededor de 530 GPUs —unas 430 de ellas AMD Instinct MI300X— y un solo modelo, Phi-4, procesa más de 700.000 millones de tokens al mes para preparación de datos y generación de datos sintéticos. Es el tipo de cifra que separa un experimento de un sistema productivo, y explica por qué la decisión ya no es «qué modelo uso» sino «qué parte del stack de serving estoy dispuesto a operar».

La nota original de VentureBeat plantea el problema como un único problema de ingeniería: modelo, forma de despliegue, capacidad, acelerador y propiedad del stack se eligen juntos o no se eligen bien. Conviene leerla con una advertencia previa: el artículo incluye enlaces a Microsoft y a AMD y promociona Managed Compute en Foundry, así que las cifras de rendimiento que cita son de proveedor. Úsalas como punto de partida para tus propias pruebas, no como veredicto.

¿Qué modelo de despliegue encaja con tu carga de trabajo?

La primera bifurcación es simple de enunciar y difícil de resolver: pago por token o capacidad dedicada.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Pago por token: tiene sentido cuando el consumo es flexible, irregular o todavía no sabes cuánto vas a usar. No exige infraestructura propia ni comprometer GPU.
Capacidad dedicada: aparece cuando hay demanda sostenida, objetivos de latencia y throughput predecibles, necesidad de una configuración específica de GPU o de un modelo abierto concreto.

Entre ambos hay un punto medio que la nota describe explícitamente: alquilar capacidad GPU dedicada y conservar el control sobre modelo y configuración de infraestructura, sin construir y operar el stack completo de serving. Managed Compute en Microsoft Foundry es la propuesta de Microsoft para ese espacio.

El error clásico de founder acá es elegir por precio de lista. El pago por token es barato de arrancar y caro de escalar en cargas agénticas, donde cada request arrastra contexto largo. La capacidad dedicada es lo contrario: exige un compromiso de gasto que solo se justifica si la utilización real lo acompaña.

¿Cómo se diseñan capacidad, latencia y throughput?

Cuando el workload corre sobre infraestructura dedicada, capacidad y performance dejan de ser un número en la factura y pasan a ser variables de ingeniería. Hay que estimar demanda, aprovisionar y elegir un punto de operación entre latencia y throughput:

Aplicaciones interactivas priorizan tiempo de respuesta.
Cargas batch o de alto volumen optimizan throughput y aceptan más latencia.

La economía también cambia de forma. Ya no es solo un costo de consumo por token: entran en juego la capacidad de GPU aprovisionada, su utilización, el costo por GPU-hora y el trabajo efectivamente completado. El indicador que importa es el costo efectivo por token o por request, no el precio de la hora de GPU.

Esto no es una discusión de nicho. Gartner proyecta que el gasto mundial en IaaS optimizado para IA crecerá 96% hasta 2026, hasta US$42.000 millones, y alcanzará los US$66.000 millones en 2027, según Network World. La misma firma estima que en 2026 el gasto global en inferencia (US$23.300 millones) superará al de entrenamiento (US$19.000 millones), y que el 55% del gasto en IaaS optimizado para IA irá a inferencia ese año, subiendo al 59% en 2027. Traducido: la factura que estás optimizando es la que más crece del mercado.

¿Cuánto del stack de serving quieres gestionar tú?

Esta es la pregunta que más impacto tiene sobre tu equipo y la que menos se discute en las hojas de cálculo. La propuesta de Managed Compute en Foundry reparte el trabajo así:

Tu equipo controla: selección de modelo y acelerador, capacidad aprovisionada, punto de operación entre latencia y throughput, y escalado de capacidad.
La plataforma gestiona buena parte del entorno: runtime y contenedores, tuning y optimización de infraestructura, actualizaciones de software y runtime, y parches de vulnerabilidades.

Ese reparto es la decisión real. Un equipo de plataforma pequeño puede sostener el control sobre las variables que afectan performance y economía sin mantener cada capa por debajo. Y como el servicio vive dentro de Foundry, se conservan las mismas APIs de inferencia, autenticación, networking, SDKs y observabilidad entre tipos de despliegue, algo que evita reescribir la aplicación cada vez que cambia la forma de servir.

¿Qué características del acelerador importan de verdad?

No es la ficha técnica del chip, es si el modelo entra y cuántos usuarios concurrentes aguanta.

La memoria define si un modelo cabe en una configuración y cuántas GPU requiere. Más memoria significa modelos más grandes en menos GPU y margen para técnicas como batching. El ancho de banda de memoria determina con qué eficiencia se mueven los datos. En AMD Instinct MI300X, cada GPU aporta 192 GB de HBM3 y hasta 5,3 TB/s de ancho de banda, con 1,5 TB en una plataforma de ocho GPU. Ese margen importa sobre todo en contexto largo, donde los pesos del modelo y la caché KV compiten por la misma memoria.

Un ejemplo concreto de cómo eso se convierte en decisiones: GLM 5.3 Flash, un modelo de 320.000 millones de parámetros con 18.000 millones activos por token y 512K de ventana de contexto, se ofrece en tres configuraciones sobre MI300X. Una de cuatro GPU apunta a chat compacto, coding y cargas de agentes; dos configuraciones de ocho GPU usan paralelismo tensorial, de datos y de expertos para priorizar o bien concurrencia y tiempo hasta el primer token, o bien margen de memoria para contexto más largo.

En pruebas con carga conversacional, la configuración de ocho GPU (TP4 + DP2 + EP) entregó aproximadamente 1,8× el throughput de salida de la configuración de cuatro GPU, con más de la mitad de reducción en el tiempo promedio hasta el primer token. Otras cargas mostraron ganancias menores. La lección: el mismo hardware rinde distinto según el workload, y elegir por titular de GPU es una forma cara de equivocarse.

¿Por qué un benchmark de GPU no decide nada?

Porque mide el chip, no tu aplicación. La nota lo dice sin rodeos: los benchmarks de acelerador dicen relativamente poco sobre si una configuración sirve para producción. Lo que hay que medir es a nivel de workload:

¿Cuántas GPU necesita el modelo?
¿Qué latencia y throughput entrega en un punto de operación definido?
¿Cuántos usuarios o requests concurrentes soporta manteniendo el objetivo?
¿Qué tan bien se está usando la capacidad aprovisionada?
¿Cómo se traduce el consumo de GPU-hora en costo por token o por unidad de trabajo?

Hay evidencia externa de que este enfoque paga. IBM Research reportó un costo de serving combinado de aproximadamente US$0,11 por millón de tokens —unas 11,5 veces menos que un stack de API propietario equivalente— sirviendo un modelo abierto de 744.000 millones de parámetros con el framework open source llm-d, según TechTimes. En el mismo ecosistema, un caso conjunto de Tesla y Red Hat documentó 3× más tokens de salida por segundo y la mitad del tiempo hasta el primer token corriendo Llama 3.1 70B sobre GPU AMD MI300X con enrutamiento de caché. Son números de terceros, no del proveedor del hardware, y apuntan a lo mismo: la ganancia viene del stack y del enrutamiento, no solo del silicio.

El mercado se está moviendo en esa dirección. IBM firmó un acuerdo de US$240 millones con Together AI para ofrecer inferencia de modelos abiertos sobre un clúster de Nvidia HGX B300 en IBM Cloud, según Network World, con modelos como DeepSeek, Nemotron, MiniMax, Kimi y GLM. Y en julio de 2026, Microsoft y Mistral anunciaron que Mistral Medium 3.5 —un modelo de pesos abiertos— y OCR 4 están disponibles en Microsoft Foundry, según el comunicado de Microsoft. La ruta «modelo abierto servido de forma gestionada» ya no es experimental: es una línea de producto de varios proveedores.

Qué significa esto para tu startup

1. Mide tu costo efectivo por token, no el precio de la GPU. Antes de comprometer capacidad dedicada, calcula cuántos tokens por hora produce realmente tu configuración bajo tu carga real. Sin utilización, la GPU-hora es un número decorativo.

2. Haz benchmark con tu propio tráfico, en dos configuraciones mínimo. La diferencia de 1,8× entre cuatro y ocho GPU existe, pero no aplica igual a toda carga. Prueba tu caso interactivo y tu caso batch por separado; el punto de operación óptimo suele ser distinto para cada uno.

3. Define la frontera de gestión antes de firmar. Escribe en una hoja qué capas mantiene tu equipo —modelo, acelerador, capacidad, escalado— y qué delega —runtime, parches, actualizaciones—. Si no tienes a alguien cubriendo parches de seguridad en runtime, esa capa no debería ser tuya.

4. Revisa si tu ventana de contexto cabe. Si tu producto depende de contexto largo o de agentes multi-turno, la memoria del acelerador y la gestión de caché KV son la restricción real, no el número de GPU. Cambiar de configuración puede ser más barato que cambiar de chip.

Conclusión

Correr modelos abiertos en producción es, sobre todo, una decisión sobre límites. Cuánto control quieres, cuánta operación absorbes y cuánto pagas por la capacidad que no usas. La propuesta de Microsoft Foundry con MI300X es una respuesta razonable a ese equilibrio, y las cifras de Gartner sobre el crecimiento del gasto en inferencia confirman que la pregunta ya no es opcional. Pero el dato que decide no está en la ficha del proveedor: está en el benchmark que hagas con tu propio tráfico, en tu propia configuración, midiendo cuánto te cuesta cada token que sí sirves.