HUMAIN MI355X: una prueba de coste por token para nubes GPU
Evalúa una nueva nube GPU en capacidad activa, interconexión, soporte de stack, precio, egress, SLA y coste por token antes de enrutar tráfico de producción.
Convierte un anuncio de nube GPU en una prueba de coste por token transformando la capacidad activa, la interconexión y el precio en coste por token y coste de fallo. El equilibrio está entre la capacidad activa y la capacidad futura. Para un segundo GPU de cómputo, el coste bruto es el precio por hora GPU dividido entre 3600 por respuesta; divide entre el número de tokens para obtener el coste bruto por token. La capacidad futura es un parámetro de planificación, no de servicio.
La capacidad es el único número que inicia la prueba
El 31 de agosto de 2026, el despliegue de GPU AMD, Cisco y HUMAIN Instinct MI355X estaba operativo en Arabia Saudita y atendiendo a clientes de HUMAIN en el país y otros mercados.
El despliegue de producción en Arabia Saudita utiliza GPU AMD Instinct MI355X, CPU AMD EPYC y la infraestructura de red crítica de Cisco.
HUMAIN ofrece esa capacidad como un modelo GPU como servicio para entrenamiento e inferencia.
Una fase posterior de hasta 250 MW con GPU MI400 está programada para comenzar en 2027, con la capacidad adicional disponible en la segunda mitad de ese año.
La joint venture AMD-Cisco-HUMAIN tiene como objetivo hasta 1 GW de infraestructura de IA para 2030.
Las líneas de expansión son contexto, no puntuación. Un ingeniero de producción necesita los números de hoy: GPU activas, megavatios activos y si el fabric puede soportar la ruta de servicio. Los megavatios planificados no soportan las solicitudes de hoy.
La ficha de puntuación convierte un lanzamiento en un modelo de coste
Realiza estas comprobaciones antes de enrutar tráfico. Cada elemento es un número que puedes solicitar en una llamada.
- Número de GPU activas y MW activos, no MW planificados.
- Topología de interconexión, latencia del fabric y dominios de fallo.
- Soporte de stack: compatibilidad de modelo, driver y framework de servicio.
- Precio por hora GPU, precio de egress y condiciones de capacidad reservada.
- SLA, ventanas de mantenimiento y tiempo de sustitución de nodos fallidos.
- Modelo de coste por token: tokens por hora GPU, egress y coste de fallo.
La capacidad indica si la oferta absorbe tu tráfico. La interconexión indica si los tokens llegan a tiempo. El soporte de stack indica si la carga de trabajo se ejecuta. El soporte de stack es un elemento de decisión antes del precio. El precio y el egress fijan el coste. El SLA fija el coste de una hora mala.
Comienza con el stack de servicio que ya utilizas. Elige un tamaño de modelo, tamaño de lote y longitud de token que coincidan con producción. Mide tokens por hora GPU, multiplica por el precio de hora GPU y suma egress si la respuesta sale de la región. Ese es el coste bruto por token antes del fallo.
Un piloto debería revelar la falta de número de GPU activas, latencia del fabric o egress antes de comprometer tráfico.
La latencia y el coste de fallo deciden la ruta
El despliegue saudí de MI355X anunciado utiliza un fabric de la serie Cisco N9000 basado en Cisco Silicon One y ópticas Cisco 800G para interconectar las GPU MI355X.
En la prueba simulada de GPU y almacenamiento Fukuoka–Tokyo de GMO de julio de 2025, una condición de latencia de 15 ms produjo una disminución de rendimiento de aproximadamente 12% en dos tareas de prueba.
Úsalo como proxy de latencia del fabric: si la ruta de servicio añade suficiente retraso para reducir el rendimiento, el precio por hora GPU deja de importar. Un fallo de nodo también cuesta solicitudes perdidas, reintentos, timeouts y posiblemente un usuario.
Calcula el coste de fallo antes de firmar. Multiplica el tiempo de inactividad esperado por los tokens que habrías servido, suma egress para reintentos o movimientos entre regiones y compara el resultado con el precio por hora GPU. Si el coste de fallo supera la diferencia de precio, la nube más barata no es más barata.
Establece una regla de enrutamiento. Envía una pequeña parte del tráfico a la nueva nube, mantén la ruta antigua disponible y mide la latencia de cola, tokens por hora GPU y tasa de error. Si la nueva ruta supera a la antigua en coste por token y se mantiene dentro del presupuesto de latencia, aumenta la parte. Si no cumple algún umbral, detente y solicita el número que falta.
El piloto debería fallar rápido
Trata un piloto como una prueba corta con un umbral de detención, no como una demostración. Elige una carga de trabajo representativa que sea barata de reejecutar, ejecútala lo suficiente para ver la varianza y registra los números que usarías en una decisión de enrutamiento. Un piloto superado es una decisión de enrutamiento, no un comunicado de prensa.
Escribe el umbral de detención antes de que se mueva el tráfico: coste por token, latencia o coste de fallo. Si la nueva nube no cumple el umbral, no lo promedies. Solicita la capacidad, el detalle de interconexión o la condición de precio que falta. Registra el número que falta, no solo el resultado.
Cuando el piloto supera la prueba, prueba la escala: capacidad activa en pico, fabric en el tamaño de lote objetivo y SLA a través del dominio de fallo. Si todo pasa, el lanzamiento se convierte en una opción de servicio. Si no, mantén el tráfico de producción en la ruta antigua y solicita la capacidad, la latencia o la condición de precio que falta.