d-Matrix Raptor y NVIDIA NVLink Fusion: mapa de asignación de fases de inferencia para racks heterogéneos

Por qué importa este anuncio y qué no demuestra todavía

El 10 de septiembre, d-Matrix y NVIDIA describieron una colaboración para llevar la XPU Raptor prevista por d-Matrix a la infraestructura de IA a escala de rack de NVIDIA mediante NVLink Fusion, con referencias a MGX, las CPU Vera, Spectrum-X y la conectividad de Astera Labs. Es una señal real de arquitectura para los equipos de inferencia. No es un benchmark de un sistema disponible.

Esa distinción importa más que el titular del comunicado de prensa. d-Matrix dice que se espera el tape-out de Raptor antes de finales de 2026, con las primeras XPU Raptor en MGX previstas para Q4 de 2027. Corsair es la plataforma de d-Matrix descrita como en producción hoy. Por tanto, la pregunta a corto plazo no es: "¿Debería esto reemplazar ahora una pila de inferencia desplegable?" La mejor pregunta es: "¿Qué tendría que medirse antes de que un rack heterogéneo merezca confianza en producción?"

Mi punto de vista: lo interesante no es que otro acelerador pueda conectarse a una historia de rack centrada en NVIDIA. Lo interesante es si prefill y decode pueden dividirse sin pagar un coste de coordinación tan alto que la división se convierta en teatro. Prefill y decode tensionan los sistemas de formas distintas. Prefill tiende a recompensar el cómputo paralelo sobre la secuencia de entrada. Decode a menudo se complica por la latencia entre tokens, el movimiento de memoria, la concurrencia y el comportamiento del planificador. Si un rack futuro combina GPU NVIDIA, CPU host Vera y XPU Raptor mediante fabrics definidos de scale-up y scale-out, el ganador no será el proveedor con el gráfico de ancho de banda más bonito. Ganará la topología que mejore el tiempo hasta el primer token, la latencia entre tokens, el coste de transferencia de estado, la formación de colas y el goodput bajo el mismo objetivo de calidad del modelo.

Para una mentalidad más amplia de asignación, la discusión anterior de Optijara sobre pruebas de asignación de modelo a hardware es un complemento útil. La misma regla se aplica aquí: el acelerador es solo una parte de la ruta de serving. Para los controles de benchmark, la escalera de fidelidad de Qdrant Supernova FineWeb 10B también es relevante porque trata la medición como una cadena de comparaciones controladas en lugar de una sola puntuación de titular.

La arquitectura de rack anunciada en términos sencillos

El material público apunta a varias capas que no deberían mezclarse en una sola afirmación vaga sobre un rack más rápido. NVLink Fusion es la vía de NVIDIA para conectar silicio personalizado a su fabric de scale-up de alta velocidad. En este anuncio, esa es la capa de fabric que hace que valga la pena observar la hoja de ruta de Raptor, porque sugiere un futuro en el que aceleradores que no son GPU pueden situarse más cerca de los sistemas acelerados de NVIDIA de lo que estarían mediante una ruta convencional de dispositivo separado.

Spectrum-X es una capa distinta. Se posiciona en torno a redes de scale-out basadas en Ethernet, lo que importa cuando racks y clústeres se comunican más allá de un solo dominio de scale-up. Mezclar los dos términos enturbia la pregunta de ingeniería. NVLink Fusion habla de acoplamiento scale-up alrededor de sistemas acelerados. Spectrum-X habla de redes scale-out. Ambos pueden importar en inferencia, pero ejercen presión sobre límites diferentes.

MGX es el marco de integración para diseño mecánico, alimentación eléctrica y refrigeración. No debería leerse como una promesa de que todo acelerador se vuelve intercambiable, de que cualquier región de memoria se comparte automáticamente o de que el software de serving puede mover estado sin trabajo operativo. Las CPU Vera se mencionan como procesadores host en el contexto de la arquitectura anunciada. Raptor es el rol de XPU previsto. Astera Labs se nombra como socio de conectividad, pero los comunicados públicos no respaldan afirmaciones adicionales sobre detalles de silicio no divulgados.

El contexto de 3DIMC de d-Matrix es relevante porque explica el lenguaje de arquitectura centrada en memoria del proveedor, incluido un encapsulado de dos pisos que combina DRAM y SRAM según la descripción del proveedor. No debería tratarse como HBM, como Pavehawk ni como evidencia de producción para racks Raptor.

El mapa de asignación de fases de inferencia

El mapa de asignación de fases de inferencia de Optijara es una forma práctica de evaluar este tipo de hoja de ruta de rack heterogéneo. Es un marco de medición, no una afirmación de que Raptor implemente actualmente toda la topología siguiente.

Fase 1: ingesta de prompts y batching

La primera decisión no es de hardware. Es la forma del tráfico. La distribución de longitud de los prompts, los patrones de ráfagas, la reutilización de contexto y la política de admisión determinan si el prefill puede agruparse de manera eficiente. Un fabric de rack no puede rescatar a un planificador que mezcla clases de solicitudes incompatibles.

Fase 2: prefill intensivo en GPU

Prefill es un candidato natural para GPU porque puede beneficiarse de cómputo paralelo denso sobre la secuencia de entrada. En un rack heterogéneo futuro, la ruta de prefill debería compararse con una línea base en la misma GPU, no con una hoja abstracta de especificaciones de acelerador. La métrica aquí es el tiempo hasta el primer token bajo mezclas realistas de prompts.

Fase 3: transferencia de estado a través del fabric del rack

Este es el límite que muchos anuncios subestiman. Mover el estado necesario de una fase a otra puede introducir serialización, demora de transporte, colas y fricción de formato de memoria. Un alto ancho de banda del fabric no significa automáticamente baja latencia visible para el usuario.

Fase 4: candidatos de decode orientados a XPU

Decode es sensible a la longitud de salida, la concurrencia, el comportamiento de caché, la precisión admitida y la latencia entre tokens. Una ruta de decode en XPU podría ser atractiva si mejora la generación sostenida bajo el mismo objetivo de calidad y de servicio. Eso tiene que medirse. El soporte de NVLink Fusion por sí solo no es prueba.

Fase 5: finalización, detokenización y retroalimentación del planificador

El bucle de serving termina con detokenización, transmisión de la respuesta y retroalimentación hacia el control de admisión. Si la cola de decode está congestionada, las ganancias de prefill pueden desaparecer. Si la reutilización de caché es alta, puede ganar una topología distinta. El mapa obliga a los equipos a observar cada límite en lugar de celebrar un componente.

{
  "framework": "Mapa de asignación de fases de inferencia",
  "status": "marco conceptual de evaluación, no un benchmark de Raptor",
  "phases": ["ingest", "prefill", "state_handoff", "decode", "scheduler_feedback"],
  "decision_rule": "comparar el goodput con la misma calidad del modelo, mezcla de tráfico y objetivos de servicio"
}

Qué medir antes de creer que la arquitectura gana

El plan de medición debería separar la capacidad por etapa del comportamiento a nivel de servicio. TTFT no es latencia de decode. La latencia de decode no es el tiempo total de finalización. Tokens por segundo sin un umbral de calidad no es goodput.

El benchmarking debería usar la misma familia de modelos, umbral de calidad, distribución de prompts, distribución de salida y objetivo de servicio. Suena exigente, pero es la única forma de mantener honesta la comparación. Si se cambian dos variables a la vez, el resultado se convierte en una historia sobre la configuración de la prueba, no sobre el rack.

Integración anunciada frente a artefacto disponible frente a experimento requerido

Optijara no realizó benchmarks de hardware para Raptor. Cada prueba específica de Raptor anterior es un paso futuro de evaluación propuesto para cuando existan artefactos públicos y sistemas desplegables.

Errores comunes al leer anuncios de inferencia heterogénea

Error 1: tratar el ancho de banda como latencia

Un enlace rápido puede reducir un cuello de botella mientras las colas, la serialización, la disposición del estado y las decisiones del planificador siguen dominando la experiencia del usuario. La latencia de servicio es el resultado de la ruta completa.

Error 2: asumir que un rack compartido significa memoria compartida

La integración de rack compartido no significa automáticamente memoria compartida arbitraria, transferencia KV de copia cero, compatibilidad CUDA o rutas de serving intercambiables. Esas son afirmaciones de software y sistema que necesitan evidencia explícita.

Error 3: asumir que la separación de fases siempre es mejor

La separación de prefill y decode puede rendir peor cuando los prompts son cortos, las salidas son breves, el movimiento de estado es caro, las colas están desequilibradas o el soporte de precisión difiere entre dispositivos.

Error 4: ignorar la forma de la cola y la longitud de salida

Las cargas dominadas por decode con salidas largas crean una presión distinta a las respuestas breves de asistente o a prompts aumentados por recuperación. Una sola cifra media de tokens por segundo puede ocultar un mal comportamiento en la cola de latencia.

Error 5: tratar las fechas de hoja de ruta como evidencia de producción

El tape-out esperado antes de finales de 2026 y las primeras XPU Raptor en MGX esperadas para Q4 de 2027 son señales útiles de planificación. No son prueba de disponibilidad actual, precio, latencia de producción ni compatibilidad.

Una lista de verificación práctica para futuros racks de clase Raptor

El camino práctico es construir el banco de pruebas antes de comprar la historia de arquitectura. Empieza con la caracterización de la carga de trabajo. Añade una línea base en el mismo dispositivo. Añade una ruta dividida candidata solo cuando existan los artefactos. Mide TTFT, latencia entre tokens, latencia de cola, profundidad de cola, presión de memoria, saturación de transporte, recuperación ante fallos y goodput. Mantén constantes el modelo, el umbral de calidad y el objetivo de servicio.

Las advertencias no son vistosas: coste de implementación, varianza de proveedor y modelo, controles de privacidad, desactualización de caché, restricciones de formato de memoria, complejidad de planificación y madurez de integración. Para equipos que planifican infraestructura futura, Optijara puede ayudar a diseñar el método de evaluación y las pruebas de asignación de fases para que las decisiones de arquitectura se prueben bajo presión antes de convertirse en compromisos de serving.