Le GPU peut attendre un composant qui ne calcule rien
Une requête d’inférence arrive d’abord sous forme de paquets. Il faut identifier son locataire, appliquer une règle réseau, terminer ou relayer son chiffrement, lire ses données, retrouver un éventuel préfixe déjà calculé, puis déplacer les blocs utiles vers le moteur qui les consommera. Cette nouvelle requête ne peut rejoindre son lot qu’après les étapes requises, même si le GPU exécute déjà d’autres lots. Si le CPU hôte traite chaque règle, chaque commande NVMe et chaque copie, des cœurs destinés au runtime deviennent des processeurs d’infrastructure.
Un Data Processing Unit déplace cette frontière. La carte possède son propre processeur, sa mémoire, ses interfaces réseau et ses accélérateurs. Elle se place entre le réseau, le stockage et l’hôte, puis traite sur place ce qui aurait traversé le noyau du serveur. Ce n’est pas un second accélérateur de modèle : aucune matrice du LLM n’y est multipliée. C’est un domaine d’exécution séparé pour le chemin qui nourrit, protège et observe l’inférence.
Ce déplacement devient visible avec BlueField-4 et Pensando Salina. NVIDIA nomme désormais ce domaine scale-in, tandis qu’AMD parle de réseau front-end pour les AI factories. Les périmètres commerciaux ne sont pas identiques, mais ils répondent à une pression commune : davantage d’agents et de contextes produisent davantage d’accès aux données, de règles de sécurité et d’état à déplacer, même lorsque le nombre de tokens calculés ne change pas.
Ce qui se passe quand une requête entre
Sans DPU, le paquet atteint la carte réseau, déclenche le traitement réseau de l’hôte, traverse les règles du pare-feu et de la virtualisation, puis réveille le runtime. Si la requête réutilise un préfixe stocké ailleurs, le même CPU participe au chemin de récupération, traite le protocole de stockage et orchestre les copies. Ces opérations peuvent être asynchrones, mais elles partagent toujours des cœurs, des caches et de la bande passante mémoire avec le service.
Avec un DPU, les opérations d’infrastructure sont appliquées avant l’entrée dans le domaine de confiance du serveur. Le DPU classe le flux, impose la politique du locataire, expose un périphérique réseau ou NVMe virtualisé à l’hôte et exécute les transferts pris en charge par son matériel. Le runtime garde la décision sémantique, par exemple ce préfixe vaut la peine d’être récupéré. Le DPU prend en charge une partie de l’exécution, par exemple déplacer ces blocs depuis ce stockage vers cette destination.
Cette séparation apporte aussi une propriété de sécurité. Une règle exécutée par le système hôte peut être contournée par un hôte compromis. Une politique correctement configurée et imposée sur la carte, avant que le trafic n’atteigne l’hôte, reste hors du contrôle du locataire. Cette indépendance explique pourquoi NVIDIA et AMD associent dans la même puce réseau, chiffrement, contrôle d’accès, stockage et télémétrie : ces fonctions peuvent observer ou transformer le même flux sans dépendre du système protégé.
BlueField-4 et Salina : 800 contre 400 Gb/s publiés
BlueField-4 annonce jusqu’à 800 Gb/s par port en Ethernet ou InfiniBand, soit 100 Go/s bruts dans une direction. Salina expose deux ports physiques 400 GbE, mais sa fiche produit limite à 400 Gb/s le débit du plan de données et celui de l’adaptateur. En mode bump-in-the-wire, les deux ports servent d’entrée et de sortie au même traitement en ligne. Les additionner reviendrait à compter deux fois le même flux. Ces plafonds ne disent ni combien d’octets utiles passent après les en-têtes, ni combien atteignent le GPU, ni combien de requêtes respectent leur objectif de latence.
| Caractéristique | NVIDIA BlueField-4 | AMD Pensando Salina |
|---|---|---|
| Réseau publié | jusqu'à 800 Gb/s par port, Ethernet ou InfiniBand | 2 × 400 GbE physiques ; 400 Gb/s pour le plan de données et l’adaptateur |
| Connexion hôte | PCIe 6 x16 | PCIe 5 x16 |
| Calcul embarqué publié | CPU Grace, 64 cœurs Arm Neoverse V2 | 16 cœurs Arm Neoverse N1 dans la fiche Helios |
| Mémoire publiée | jusqu'à 128 Go LPDDR5X | 64 Go DDR5-6400 ECC |
| Plan de données | accélérateurs en ligne et services DOCA | pipeline programmable P4, C et C++ |
| Stockage | DPU : NVMe-oF, fichiers et objets ; CMX : processeur STX distinct | NVMe-oF sur TCP ou RoCE, virtualisation NVMe |
| Écosystème IA mis en avant | DPU : DOCA ; STX et CMX : DOCA Memos avec Dynamo et NIXL | NVMe géré par le DPU et intégration Helios annoncée |
La connexion à l’hôte fixe une limite seulement quand le trafic la traverse. En mode hôte, le PCIe Peripheral Component Interconnect Express. Le bus qui relie le GPU au CPU et à la RAM. Sa bande passante (quelques dizaines de Go/s) est un à deux ordres de grandeur sous celle de la VRAM, ce qui fait du transfert hôte↔GPU un goulot dès qu'on déporte des données hors de la carte. 5 x16 atteint jusqu’à environ 64 Go/s par direction, contre 128 Go/s pour le PCIe 6 x16 de BlueField-4. Ce sont les plafonds nominaux du lien ; les paquets, les transactions et le contrôle de flux réduisent le débit utile. En mode bump-in-the-wire, la fiche Salina précise que le PCIe sert uniquement à alimenter la carte : le trafic passe d’un port réseau à l’autre. Ces plafonds ne permettent donc pas de déduire un débit de serving ni de comparer directement les deux modes.
BlueField-4 mise sur un domaine de calcul généraliste conséquent, avec 64 cœurs Grace et des accélérateurs en ligne. DOCA fournit les services et bibliothèques qui exécutent le routage, l’isolation, le stockage, la télémétrie et les transferts. Pensando organise son plan de données autour d’un pipeline P4 programmable, complété par C et C++. La différence n’oppose pas le programmable au fixe. Elle oppose deux modèles de programmation, deux intégrations au contrôle du datacenter et deux ensembles de services déjà déployés.
Le KV cache n’habite pas dans le DPU pendant le decode
Le KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire actif est relu par les kernels d’attention à chaque token. Le placer sur la DDR du DPU ou sur un NVMe pendant cette boucle ferait traverser une interconnexion beaucoup plus lente que la HBM du GPU. Le DPU n’est donc pas un remplacement de VRAM. Il intervient aux frontières de la durée de vie du cache : quand un bloc est évincé, partagé avec un autre moteur, restauré avant un decode ou conservé pour une prochaine requête.
Le nom BlueField-4 recouvre ici deux produits qu’il faut séparer. Le DPU BlueField-4 installé côté serveur traite les services d’infrastructure et les transferts pris en charge par DOCA. Le processeur de stockage Vera BlueField-4 STX est une plateforme distincte : il associe un CPU Vera, un ConnectX-9, du NVMe et jusqu’à 1,6 Tb/s de Spectrum-X pour construire CMX. Attribuer le stockage CMX ou ses 1,6 Tb/s au DPU PCIe 6 serait donc faux.
Dynamo et le gestionnaire de cache décident du placement. NIXL fournit une interface commune pour déplacer les données entre HBM, RAM et stockages fichier, bloc ou objet. DOCA Memos organise le cache distribué sur cette pile. Ces briques peuvent emprunter BlueField, mais leur présence ne prouve pas que chaque bloc de KV cache traverse le DPU. La hiérarchie de cache est détaillée dans notre analyse du KV cache comme objet central du serving ; ici, la question est de savoir quel processeur exécute chaque entrée-sortie.
AMD annonce un chemin différent : Salina accélère l’accès au stockage et pilote du NVMe destiné à étendre la capacité disponible pour le cache. Sa fiche produit confirme la virtualisation NVMe et NVMe-oF sur TCP ou RDMA Remote Direct Memory Access. Accès direct à la mémoire d'une machine distante par la carte réseau, sans passer par le processeur ni la pile logicielle du système. C'est le transport des échanges entre nœuds (InfiniBand, RoCE) : bien plus rapide qu'un socket classique, et d'un ordre de grandeur plus lent qu'un lien interne au nœud. /RoCE. Le rattachement explicite au KV cache vient toutefois d’un billet AMD de juillet 2026, pas d’un protocole public équivalent à NIXL ni d’un benchmark reproductible de serving. C’est une capacité annoncée, pas encore une preuve de gain sur un modèle et une charge définis.
Le mécanisme conduit à une conséquence moins visible. Plus le cache quitte la HBM, plus son index et sa politique deviennent critiques. Il faut connaître le propriétaire du bloc, sa version, son format, son locataire, sa destination et la valeur du recalcul évité. Le DPU sait appliquer la protection et exécuter le transfert. Il ne sait pas décider seul qu’un préfixe de 8 000 tokens sera réutilisé dans trente secondes. Cette information appartient au routeur et au runtime.
Les benchmarks publiés ne répondent pas à la même question
AMD mesure 117 millions de paquets par seconde et annonce 782 Gb/s pour son test SDN Salina en mode bump-in-the-wire, puis compare les 117 MPPS aux 80 MPPS publiés pour BlueField-3. La note publique ne précise pas si les 782 Gb/s additionnent les directions, les ports ou plusieurs cartes. Puisque la fiche Salina publie 400 Gb/s pour le plan de données et l’adaptateur, ce résultat ne doit pas être présenté comme 782 Gb/s utiles dans une direction sur une carte. Le protocole ne compare pas Salina à BlueField-4 et ne mesure ni modèle, ni cache, ni TTFT.
NVIDIA publie jusqu’à 1,45 fois le débit de stockage d’un Ethernet standard pour la pile BlueField-4 plus Spectrum-X, avec des fichiers allant jusqu’à 50 Go. Le comparateur exact, les détails complets de la charge et un résultat BlueField-4 isolé ne sont pas fournis dans le billet. La mesure montre l’effet revendiqué d’une pile co-conçue. Elle ne permet pas d’attribuer le gain au seul DPU, encore moins de le comparer à Salina.
Les affirmations sur les cœurs CPU libérés, les tokens par seconde ou l’efficacité énergétique rencontrent la même limite. Retirer le traitement réseau du CPU peut rendre ces cœurs au runtime, mais seulement si le CPU était le goulot. Si le decode sature déjà la bande passante HBM, libérer vingt cœurs ne change pas le nombre de tokens produits. Si le service passe son temps à récupérer des contextes ou à appliquer des politiques multi-locataires, le même offload peut devenir déterminant.
Le benchmark utile devrait fixer un modèle, un runtime, une longueur de préfixe, un taux de hit, un stockage et une concurrence. Il devrait publier le TTFT aux 50e, 95e et 99e percentiles, le débit de tokens sous objectif de latence, les octets déplacés, les cœurs CPU consommés et l’énergie du système complet. Aucun résultat public au 30 août 2026 ne réunit ces conditions pour les deux DPU.
Comment choisir sans inventer le benchmark manquant
Dans une pile NVIDIA Vera Rubin déjà construite autour de Dynamo, NIXL, Spectrum-X et CMX, le DPU BlueField-4 et le processeur STX appartiennent au chemin intégré, avec des rôles distincts. La valeur ne vient pas d’un port 800 Gb/s isolé, mais du fait que le runtime, la bibliothèque de transfert, le contrôle réseau et le stockage de contexte partagent le même modèle d’exploitation. Cette intégration réduit le travail d’assemblage, au prix d’une dépendance plus forte à la pile NVIDIA.
Dans une infrastructure Ethernet pilotée par P4, où l’opérateur possède déjà les outils Pensando ou veut exposer des services réseau personnalisés au bord de chaque serveur, Salina présente une autre logique. Sa fiche décrit précisément les primitives de réseau, de sécurité et de stockage. AMD l’intègre à Helios et revendique un chemin NVMe géré par le DPU pour le cache, mais la couche de serving complète reste moins documentée publiquement que le chemin Dynamo/NIXL.
Dans un petit cluster où le CPU n’est pas saturé, le stockage reste local et les préfixes sont peu réutilisés, aucun des deux ne garantit un gain rentable. Une SmartNIC ou un NIC RDMA classique peut suffire. Le DPU devient rationnel quand l’opérateur doit exécuter à la fois réseau, sécurité, stockage et isolation à haut débit sans confier ces fonctions au système qui sert les locataires.
Le bon test commence donc avant l’achat : profiler les cœurs hôtes, les files réseau, les accès stockage, les transferts de cache et les SLO de latence. Si l’attente se trouve en HBM, il faut corriger le modèle ou le GPU. Si elle se trouve dans le chemin d’infrastructure, le DPU possède enfin un problème concret à résoudre.
Conclusion
BlueField-4 et Salina déplacent une frontière plus qu’ils ne gagnent une course. Le réseau, le stockage et la sécurité ne sont plus des fonctions annexes exécutées autour du serveur : ils deviennent un domaine de calcul autonome, placé sur le chemin de chaque requête et de chaque bloc de contexte.
La prochaine question ne sera pas de savoir quel DPU affiche le plus grand débit de port. Elle sera de savoir qui contrôle l’état distribué de l’inférence. Quand un préfixe existe sur trois tiers de mémoire et plusieurs locataires, le composant décisif n’est plus celui qui transporte le plus vite, mais celui qui sait prouver quel bloc déplacer, pour qui, et pourquoi ce transfert coûte moins que son recalcul.
Sources et méthode
Les spécifications matérielles ont été arrêtées au 30 août 2026. Les débits de port et caractéristiques matérielles sont des faits vérifiés dans les fiches officielles. Les gains de performance restent des mesures constructeur limitées à leur protocole. Aucun chiffre AMD n’est utilisé comme comparaison de BlueField-4 lorsque la source mesure BlueField-3.
- NVIDIA, fiche technique BlueField-4, juin 2026 : 64 cœurs Arm Neoverse V2, jusqu’à 128 Go de LPDDR5X, PCIe 6 x16, interface 800 Gb/s et distinction entre le DPU et le processeur de stockage STX. Faits vérifiés.
- NVIDIA, « BlueField-4 Powers New Scale-In Network Infrastructure for Agentic AI Factories », 24 août 2026 : rôle du scale-in, sécurité, contrôle et stockage. Architecture décrite par NVIDIA ; gains de débit revendiqués par le constructeur.
- NVIDIA, « Scaling Agentic AI Factories Through Extreme Co-Design with NVIDIA BlueField », juillet 2026 : articulation BlueField-4, STX, DOCA Memos, NIXL et contexte distribué. Faits vérifiés pour la composition ; bénéfices de production revendiqués.
- NVIDIA, annonce Inference Context Memory Storage, 5 janvier 2026 : disponibilité H2 2026, CMX, placement matériel et intégration NIXL/Dynamo. Le gain « jusqu’à 5× » est conservé comme affirmation constructeur, sans l’utiliser pour comparer les deux DPU.
- AMD, fiche produit Pensando Salina DPU : deux ports 400 GbE, débit du plan de données et de l’adaptateur de 400 Gb/s, PCIe 5 x16, 64 Go DDR5-6400 ECC, P4/C/C++, NVMe-oF et modes de déploiement. Faits vérifiés.
- AMD, page Pensando DPU : méthode du test Salina à 117 MPPS et 782 Gb/s, comparaison avec BlueField-3. Mesure constructeur dont l’agrégation n’est pas détaillée, non transposée à BlueField-4 ou au débit de tokens.
- AMD, présentation officielle Helios : intégration de Salina et 16 cœurs Arm Neoverse N1. Faits vérifiés.
- AMD, « AI Networking Built for Scale », 23 juillet 2026 : rôle annoncé de Salina dans Helios et dans le stockage NVMe du KV cache. Architecture annoncée par AMD, sans benchmark de serving reproductible publié.
- PCI-SIG, PCI Express 6.0 Specification : débits théoriques PCIe 5 et PCIe 6. Les valeurs par direction de l’article sont des calculs vérifiables à partir des débits officiels ; elles ne représentent pas un débit applicatif.
- NVIDIA, dépôt officiel NIXL : abstraction de transfert entre mémoire GPU, RAM, fichiers, blocs et stockage objet. Fait vérifié dans le code et la documentation publics.
