d-Matrix Raptor et NVIDIA NVLink Fusion : une carte de placement des phases d'inférence pour baies hétérogènes

Pourquoi cette annonce compte, et ce qu'elle ne prouve pas encore

Le 10 septembre, d-Matrix et NVIDIA ont décrit une collaboration visant à intégrer le XPU Raptor prévu par d-Matrix dans l'infrastructure IA NVIDIA à l'échelle de la baie via NVLink Fusion, avec des références à MGX, aux CPU Vera, à Spectrum-X et à la connectivité Astera Labs. C'est un vrai signal d'architecture pour les équipes d'inférence. Ce n'est pas une mesure de performance d'un produit livré.

Cette distinction compte plus que le titre du communiqué. d-Matrix indique que la finalisation de conception de Raptor est attendue avant la fin de 2026, avec de premiers XPU Raptor dans MGX attendus en Q4 2027. Corsair est la plateforme d-Matrix décrite comme étant en production aujourd'hui. La question à court terme n'est donc pas : "Cela doit-il remplacer maintenant une pile d'inférence déployable ?" La meilleure question est : "Que faudrait-il mesurer avant qu'une baie hétérogène mérite la confiance de la production ?"

Mon avis : l'aspect intéressant n'est pas qu'un autre accélérateur puisse s'attacher à une histoire de baie centrée sur NVIDIA. L'aspect intéressant est de savoir si le préremplissage et le décodage peuvent être séparés sans payer un coût de coordination si élevé que la séparation devient du théâtre. Le préremplissage et le décodage sollicitent les systèmes différemment. Le préremplissage tend à récompenser le calcul parallèle sur la séquence d'entrée. Le décodage devient souvent plus complexe autour de la latence inter-jetons, du mouvement mémoire, de la concurrence et du comportement de l'ordonnanceur. Si une future baie combine des GPU NVIDIA, des CPU hôtes Vera et des XPU Raptor au moyen de tissus définis de mise à l'échelle verticale et horizontale, le gagnant ne sera pas le fournisseur qui possède le plus beau graphique de bande passante. Le gagnant sera la topologie qui améliore le délai jusqu'au premier jeton, la latence inter-jetons, le coût de transfert d'état, les files d'attente et le débit utile sous le même objectif de qualité de modèle.

Pour une approche plus large du placement, la discussion précédente d'Optijara sur les tests de placement modèle-matériel est un complément utile. La même règle s'applique ici : l'accélérateur n'est qu'une partie du chemin de service. Pour les contrôles de mesure, l'échelle de fidélité Qdrant Supernova FineWeb 10B est aussi pertinente, car elle traite la mesure comme une chaîne de comparaisons contrôlées plutôt que comme un score de titre unique.

L'architecture de baie annoncée en termes simples

Les éléments publics pointent vers plusieurs couches qui ne doivent pas être fondues en une affirmation vague sur une baie plus rapide. NVLink Fusion est la voie de NVIDIA pour connecter du silicium personnalisé à son tissu de mise à l'échelle verticale à haute vitesse. Dans cette annonce, c'est la couche de tissu qui rend la feuille de route Raptor intéressante à suivre, parce qu'elle suggère un avenir où des accélérateurs non GPU peuvent se placer plus près des systèmes accélérés NVIDIA qu'ils ne le feraient par un chemin d'appareil détaché conventionnel.

Spectrum-X relève d'une autre couche. Il est positionné autour du réseau Ethernet de mise à l'échelle horizontale, ce qui compte lorsque les baies et les grappes communiquent au-delà d'un seul domaine de mise à l'échelle verticale. Mélanger les deux termes brouille la question d'ingénierie. NVLink Fusion concerne l'attachement de mise à l'échelle verticale autour de systèmes accélérés. Spectrum-X concerne le réseau de mise à l'échelle horizontale. Les deux peuvent compter en inférence, mais ils exercent une pression sur des frontières différentes.

MGX est l'enveloppe d'intégration pour la conception mécanique, l'alimentation et le refroidissement. Il ne faut pas le lire comme une promesse que chaque accélérateur devient interchangeable, que chaque région mémoire est automatiquement partagée, ou que les logiciels de service peuvent déplacer l'état sans travail opérationnel. Les CPU Vera sont référencés comme processeurs hôtes dans le contexte de l'architecture annoncée. Raptor joue le rôle de XPU prévu. Astera Labs est nommé comme partenaire de connectivité, mais les publications publiques ne soutiennent pas de revendications supplémentaires sur des détails de silicium non divulgués.

Le contexte 3DIMC de d-Matrix est pertinent parce qu'il explique le vocabulaire d'architecture centré sur la mémoire du fournisseur, y compris un boîtier à deux niveaux qui combine DRAM et SRAM dans la description du fournisseur. Il ne doit pas être traité comme du HBM, comme Pavehawk, ni comme une preuve de production pour des baies Raptor.

La Carte de placement des phases d'inférence

La Carte de placement des phases d'inférence d'Optijara est une façon pratique d'évaluer ce type de feuille de route de baie hétérogène. C'est un cadre de mesure, pas une affirmation selon laquelle Raptor met aujourd'hui en oeuvre toute la topologie ci-dessous.

Phase 1 : ingestion de l'invite et regroupement

La première décision n'est pas le matériel. C'est le profil de trafic. La distribution de longueur des invites, les schémas de rafales, la réutilisation du contexte et la politique d'admission déterminent si le préremplissage peut être regroupé efficacement. Un tissu de baie ne peut pas sauver un ordonnanceur qui mélange des classes de requêtes incompatibles.

Phase 2 : préremplissage à dominante GPU

Le préremplissage est un candidat naturel pour les GPU, car il peut bénéficier d'un calcul parallèle dense sur la séquence d'entrée. Dans une future baie hétérogène, le chemin de préremplissage doit être comparé à une référence sur le même GPU, pas à une fiche abstraite de spécifications d'accélérateur. La métrique ici est le délai jusqu'au premier jeton sous des mélanges réalistes d'invites.

Phase 3 : transfert d'état à travers le tissu de baie

C'est la frontière que beaucoup d'annonces minimisent. Déplacer l'état requis d'une phase à une autre peut introduire de la sérialisation, un délai de transport, des files d'attente et des frictions de format mémoire. Une bande passante élevée du tissu ne signifie pas automatiquement une faible latence visible par l'utilisateur.

Phase 4 : candidats de décodage orientés XPU

Le décodage est sensible à la longueur de sortie, à la concurrence, au comportement du cache, à la précision prise en charge et à la latence inter-jetons. Un chemin de décodage XPU pourrait être attractif s'il améliore la génération soutenue sous le même objectif de qualité et le même objectif de service. Cela doit être mesuré. La prise en charge de NVLink Fusion seule n'est pas une preuve.

Phase 5 : complétion, détokénisation et retour de l'ordonnanceur

La boucle de service se termine par la détokénisation, la diffusion de la réponse et le retour vers le contrôle d'admission. Si la file de décodage est congestionnée, les gains du préremplissage peuvent disparaître. Si la réutilisation du cache est élevée, une autre topologie peut gagner. La carte force les équipes à observer chaque frontière au lieu de célébrer un seul composant.

{
  "framework": "Carte de placement des phases d'inférence",
  "status": "cadre d'évaluation conceptuel, pas une mesure de performance de Raptor",
  "phases": ["ingestion", "préremplissage", "transfert_etat", "decodage", "retour_ordonnanceur"],
  "decision_rule": "comparer le débit utile à qualité de modèle, mix de trafic et objectifs de service équivalents"
}

Ce qu'il faut mesurer avant de croire que l'architecture gagne

Le plan de mesure doit séparer la capacité par étape du comportement au niveau du service. Le TTFT n'est pas la latence de décodage. La latence de décodage n'est pas le temps total de complétion. Des jetons par seconde sans seuil de qualité ne constituent pas un débit utile.

La mesure doit utiliser la même famille de modèles, le même seuil de qualité, la même distribution d'invites, la même distribution de sorties et le même objectif de service. Cela semble pointilleux, mais c'est la seule façon de garder la comparaison honnête. Changez deux variables à la fois et le résultat devient une histoire sur le dispositif de test, pas sur la baie.

Intégration annoncée, artefact disponible et expérience requise

Aucune mesure de performance matérielle Optijara n'a été réalisée pour Raptor. Chaque test propre à Raptor ci-dessus est une étape d'évaluation future proposée pour le moment où des artefacts publics et des systèmes déployables existeront.

Erreurs courantes dans la lecture des annonces d'inférence hétérogène

Erreur 1 : confondre bande passante et latence

Un lien rapide peut réduire un goulot d'étranglement tandis que les files d'attente, la sérialisation, la disposition de l'état et les décisions de l'ordonnanceur dominent encore l'expérience utilisateur. La latence de service est le résultat du chemin complet.

Erreur 2 : supposer qu'une baie partagée signifie une mémoire partagée

L'intégration dans une baie partagée ne signifie pas automatiquement mémoire partagée arbitraire, transfert KV sans copie, compatibilité CUDA ou service de modèles interchangeable. Ce sont des revendications logicielles et système qui exigent des preuves explicites.

Erreur 3 : supposer que la séparation des phases est toujours meilleure

La séparation du préremplissage et du décodage peut sous-performer lorsque les invites sont courtes, les sorties sont brèves, le mouvement d'état est coûteux, les files sont déséquilibrées ou la prise en charge de précision diffère entre les appareils.

Erreur 4 : ignorer la forme des files et la longueur de sortie

Les charges fortement orientées décodage avec de longues sorties créent une pression différente de celle de réponses d'assistant courtes ou d'invites enrichies par recherche. Un seul chiffre moyen de jetons par seconde peut masquer un mauvais comportement de traîne.

Erreur 5 : traiter les dates de feuille de route comme des preuves de production

La finalisation de conception attendue avant la fin de 2026 et les premiers XPU Raptor dans MGX attendus en Q4 2027 sont des signaux de planification utiles. Ce ne sont pas des preuves de disponibilité actuelle, de prix, de latence en production ou de compatibilité.

Une liste de contrôle pratique pour les futures baies de classe Raptor

Le chemin pratique consiste à construire le banc de test avant d'acheter l'histoire d'architecture. Commencez par caractériser la charge de travail. Ajoutez une référence sur le même appareil. Ajoutez un chemin candidat séparé seulement lorsque les artefacts existent. Mesurez le TTFT, la latence inter-jetons, la latence de traîne, la profondeur de file, la pression mémoire, la saturation du transport, la reprise après panne et le débit utile. Gardez constants le modèle, la barre de qualité et l'objectif de service.

Les réserves ne sont pas spectaculaires : coût de mise en oeuvre, variance selon fournisseurs et modèles, contrôles de confidentialité, obsolescence du cache, contraintes de format mémoire, complexité d'ordonnancement et maturité d'intégration. Pour les équipes qui planifient une future infrastructure, Optijara peut aider à concevoir la méthode d'évaluation et les tests de placement des phases afin que les décisions d'architecture soient mises sous pression avant de devenir des engagements de service.