Découvrez comment le silicium d'infrastructure de Marvell prend en charge le réseau cloud, le stockage et l'accélération personnalisée — alimentant discrètement des centres de données plus rapides et plus efficaces.
La plupart des gens pensent que le « cloud » ce sont juste des serveurs. En réalité, un centre de données cloud est un gigantesque système pour déplacer, stocker et protéger des données à haute vitesse. Le silicium d'infrastructure de données regroupe les puces spécialisées qui prennent en charge ces tâches intensives en données afin que les CPU principaux n'aient pas à le faire.
Marvell se concentre sur cette couche « intermédiaire » : les puces qui connectent le calcul au réseau et au stockage, accélèrent des tâches courantes des centres de données et maintiennent un flux prévisible sous charge.
Si vous imaginez une armoire cloud de haut en bas, les dispositifs Marvell se trouvent souvent :
Ce ne sont ni des « apps » ni des « serveurs » au sens habituel — ce sont des briques matérielles qui permettent à des milliers de serveurs de se comporter comme un service cohérent.
Quand le silicium d'infrastructure fait son travail, vous ne le remarquez pas. Les pages se chargent plus vite, la vidéo se met moins en mémoire tampon et les sauvegardes se terminent à temps — mais l'utilisateur ne voit pas le moteur de délestage réseau, le contrôleur de stockage ou la trame de commutation qui rendent cela possible. Ces puces réduisent discrètement la latence, libèrent des cycles CPU et rendent les performances plus constantes.
Le rôle de Marvell se regroupe facilement en trois catégories :
Voilà le silicium « discret » qui aide les services cloud à paraître simples en surface.
Les applications cloud semblent « définies par logiciel », mais le travail physique a toujours lieu dans des armoires remplies de serveurs, de commutateurs et de stockage. À mesure que la demande augmente, les clouds ne peuvent pas s'appuyer sur des CPU généralistes pour tout sans atteindre des limites fortes en coût et en efficacité.
L'entraînement et l'inférence AI déplacent d'énormes jeux de données à travers le centre de données. Les flux vidéo, les sauvegardes, l'analytique et les plateformes SaaS ajoutent une charge constante en arrière-plan. Même quand le calcul est disponible, le goulot d'étranglement se déplace souvent vers le fait de déplacer, filtrer, chiffrer et stocker les données assez vite.
La plupart du trafic cloud ne touche jamais l'internet public. Il circule « est–ouest » entre services : appels microservice-à-microservice, lectures de base de données, mises à jour de cache, réplication de stockage et charges AI distribuées. Ce trafic interne nécessite une latence prévisible et un haut débit, ce qui pousse le matériel réseau et de stockage à effectuer plus de traitements près du chemin de données.
La puissance et l'espace ne sont pas illimités. Si un fournisseur cloud peut déléguer des tâches comme le traitement de paquets, le chiffrement, la compression ou les checksums de stockage à du silicium dédié, le CPU utilise moins de cycles pour la surcharge. Cela améliore :
Plutôt que de scaler en ajoutant des cœurs généralistes, les plates-formes cloud utilisent de plus en plus des puces dédiées — Smart NICs/DPUs, silicium de commutation, contrôleurs de stockage et accélérateurs — pour gérer des tâches d'infrastructure répétitives à fort volume. Le résultat est un cloud plus rapide et moins coûteux à exploiter, même si les charges deviennent plus gourmandes en données.
Les serveurs cloud passent un temps surprenant à exécuter du « travail d'infrastructure » au lieu de votre application. Chaque paquet doit être déplacé, inspecté, journalisé et parfois chiffré — souvent par le CPU principal. Le délestage réseau transfère ces tâches à du matériel spécialisé : c'est là que les Smart NICs et les DPUs entrent dans de nombreux centres de données modernes (y compris dans des systèmes construits avec des puces Marvell).
Une Smart NIC est une carte d'interface réseau qui fait plus que l'envoi/la réception basique. En plus des ports Ethernet habituels, elle comporte un calcul supplémentaire (souvent des cœurs Arm et/ou de la logique programmable) pour exécuter des fonctions réseau directement sur la carte.
Une DPU (Data Processing Unit) va un cran plus loin : elle est conçue pour agir comme un « ordinateur d'infrastructure » dédié à l'intérieur du serveur. Une DPU combine typiquement un réseau haute performance, plusieurs cœurs CPU, des accélérateurs matériels (crypto, traitement de paquets) et des fonctions d'isolation fortes pour gérer le mouvement de données et la sécurité sans s'appuyer sur le CPU hôte.
Un modèle mental pratique :
On délègue des travaux répétables et à fort volume qui voleraient autrement des cycles CPU aux applications. Exemples courants :
Quand le CPU doit « surveiller » le réseau, les performances des applications peuvent varier selon les pics de trafic, les voisins bruyants ou les rafales de travail de sécurité. Le délestage aide en :
Physiquement, les DPUs arrivent généralement sous forme de carte d'extension PCIe ou de module OCP NIC. Elles se connectent à :
Conceptuellement, la DPU devient un « agent de la circulation » entre le réseau et le serveur — gérant politiques, chiffrement et commutation pour que l'OS hôte et les CPU restent concentrés sur l'exécution des applications.
Lorsque vous ouvrez une app ou déplacez des données vers le cloud, votre requête ne va généralement pas « à un serveur » — elle traverse une toile de commutateurs Ethernet qui relient des milliers de serveurs comme s'ils formaient une seule machine géante.
La plupart des centres de données cloud utilisent une architecture « leaf–spine » :
Ce design garde les chemins courts et constants, élément clé pour les performances à grande échelle.
Deux métriques façonnent l'expérience utilisateur et le coût :
Les opérateurs cloud cherchent à maintenir une latence stable même lorsque les liens sont occupés, tout en poussant d'énormes volumes de trafic.
Une puce de commutation Ethernet fait plus que « forwarder » des paquets. Elle doit :
Des fournisseurs comme Marvell conçoivent du silicium focalisé sur l'exécution prévisible de ces tâches à très grande vitesse.
Passer de 25/100G à 200/400/800G n'est pas qu'une question de chiffres. Des débits plus élevés signifient :
Le résultat est un réseau de centre de données qui ressemble moins à des « fils » et plus à une infrastructure partagée pour toutes les charges.
Quand on parle de performance cloud, on imagine souvent CPU et GPU. Pourtant une grande part de la « vitesse » (et de la fiabilité) est déterminée par le silicium de stockage entre les disques flash et le reste du serveur. Cette couche est typiquement un contrôleur de stockage — des puces conçues pour gérer comment les données sont écrites, lues, vérifiées et reconstruites.
Un contrôleur de stockage est le chef d'orchestre des données persistantes. Il segmente les écritures entrantes, planifie les lectures pour que les données chaudes reviennent rapidement, et exécute en continu des vérifications d'intégrité pour que des bits corrompus ne deviennent pas des fichiers corrompus.
Il gère aussi la comptabilité peu glamour qui rend le stockage prévisible à l'échelle : cartographie des blocs logiques vers la flash physique, équilibrage d'usure pour prolonger la durée des disques, et maintien d'une latence stable quand de nombreuses applications sollicitent le même pool.
NVMe (Non-Volatile Memory Express) est un protocole conçu pour le stockage flash rapide. Il est devenu courant car il réduit l'overhead et supporte des files parallèles de requêtes — ce qui permet à de nombreuses opérations d'être en vol simultanément, adapté aux charges cloud où des milliers de petites lectures/écritures se produisent en parallèle.
Pour les fournisseurs cloud, NVMe ne concerne pas seulement le débit de pointe ; il s'agit d'une latence basse et constante sous charge, ce qui maintient les applications réactives.
Les contrôleurs modernes incluent souvent des fonctions matérielles qui évitent de consommer des cycles CPU :
Le stockage n'est pas un sous-système isolé — il influe sur le comportement des applications :
En bref, le silicium de stockage transforme la flash brute en une infrastructure cloud performante et fiable.
Quand les fournisseurs cloud mettent à jour des serveurs, ils ne changent pas seulement les CPU. Ils doivent aussi mettre à jour la « toile » qui permet aux CPU de parler aux cartes réseau, au stockage et aux accélérateurs sans réinventer toute l'architecture. C'est pourquoi des standards comme PCIe et CXL comptent : ils gardent les composants interopérables, facilitent les mises à niveau et aident les centres de données à évoluer de façon prévisible.
PCIe (Peripheral Component Interconnect Express) est le lien interne principal utilisé pour connecter :
Un modèle utile : PCIe, c'est comme ajouter des voies à une autoroute. Les générations plus récentes augmentent la vitesse par voie, et des liens plus larges (x8, x16, etc.) ajoutent plus de capacité totale. Pour les opérateurs cloud, cela affecte directement la rapidité des échanges entre le calcul et les périphériques.
Le silicium d'infrastructure de Marvell se retrouve souvent à une extrémité de ces connexions PCIe — dans une NIC, une DPU, un contrôleur de stockage ou un composant adjacent à un commutateur — donc la capacité PCIe peut limiter (ou permettre) les montées en performance.
CXL (Compute Express Link) repose sur la même couche physique que PCIe mais ajoute des moyens pour que les dispositifs partagent des ressources de type mémoire avec moins d'overhead. En termes simples, CXL aide les serveurs à considérer certaines ressources externes (expansion mémoire ou mémoire partagée) comme une extension locale plutôt qu'un périphérique lointain.
Le bénéfice n'est pas seulement « plus rapide ». PCIe et CXL permettent :
Les standards de connectivité ne font pas la une, mais ils façonnent fortement la vitesse d'adoption de meilleurs réseaux, stockages et accélérateurs.
« Accélération personnalisée » n'implique pas toujours un énorme GPU généraliste greffé sur un serveur. Plus souvent, il s'agit d'ajouter de petites unités de calcul spécialisées qui accélèrent une tâche répétée — pour que les CPU se concentrent sur l'application.
Les charges cloud sont très variées : un nœud orienté stockage a des goulots d'étranglement différents d'une edge box de streaming ou d'un pare-feu. Le silicium dédié cible ces goulots directement — en déplaçant souvent une fonction en matériel pour qu'elle s'exécute plus vite, plus uniformément et avec moins d'overhead CPU.
Quelques catégories pratiques reviennent souvent :
Les grandes équipes cloud commencent typiquement par du profiling : où les requêtes se bloquent-elles, quelles tâches se répètent des millions de fois par seconde ? Elles choisissent ensuite d'accélérer via un moteur programmable (plus adaptable) ou des blocs à fonction fixe (plus efficace). Des fournisseurs comme Marvell fournissent souvent des blocs de construction — réseau, sécurité, interfaces stockage — pour que la partie « personnalisée » se concentre sur les chemins chauds propres à la plate-forme.
Les accélérateurs à fonction fixe gagnent en performance par watt et en déterminisme, mais sont moins faciles à réaffecter si la charge change. Les options programmables s'adaptent mieux, mais coûtent souvent plus en énergie et laissent parfois de la performance sur la table. Les meilleurs designs combinent les deux : plans de contrôle flexibles avec des chemins rapides matériels là où c'est critique.
La puissance est souvent la vraie limite d'un centre de données — pas seulement le nombre de serveurs que vous pouvez acheter, mais l'électricité que vous pouvez fournir et évacuer sous forme de chaleur. Quand une installation atteint son envelope énergétique, la seule façon de croître est d'extraire plus de travail utile par watt.
Les CPU généralistes sont flexibles, mais pas toujours efficaces pour les tâches répétitives d'infrastructure : traitement de paquets, chiffrement, protocoles de stockage ou télémétrie. Le silicium d'infrastructure dédié (Smart NICs/DPUs, commutateurs, contrôleurs) peut exécuter ces tâches avec moins de cycles et moins de travail gaspillé.
Le gain énergétique est souvent indirect : si le délestage réduit l'utilisation CPU, on peut exécuter la même charge avec moins de cœurs actifs, des fréquences plus basses ou moins de serveurs. Cela réduit aussi la pression mémoire et le trafic PCIe, ce qui épargne encore de la puissance.
Chaque watt devient de la chaleur. Plus de chaleur signifie des ventilateurs plus rapides, plus de débit de refroidissement et une planification de rack plus stricte. Des racks à haute densité sont attractifs, mais seulement si on peut les refroidir de façon fiable. Ainsi, le choix des puces importe au-delà du débit brut : un composant qui consomme moins (ou reste efficace en charge) permet de densifier sans créer de points chauds.
Les chiffres d'efficacité sont faciles à marketer et difficiles à comparer. Quand vous voyez « meilleure performance par watt », vérifiez :
Les revendications crédibles relient les watts à une charge répétable et montrent l'impact à l'échelle serveur ou armoire — pas seulement sur une fiche technique.
Les fournisseurs cloud partagent le même matériel physique entre de nombreux clients, donc la sécurité ne peut pas être « ajoutée après coup ». Une grande partie est appliquée au niveau de la puce — dans les Smart NICs/DPUs, le silicium réseau, la commutation Ethernet et les contrôleurs de stockage — où le délestage matériel peut appliquer des protections à débit ligne.
La plupart des silicons d'infrastructure incluent une racine matérielle de confiance : une logique et des clés immuables qui vérifient le firmware avant tout démarrage. Avec le secure boot, la puce vérifie les signatures cryptographiques de son firmware (et parfois du boot hôte), refusant d'exécuter du code modifié ou inconnu.
C'est important car une DPU ou un contrôleur compromis peut se situer « entre » vos serveurs et le fabric réseau/stockage. Le secure boot réduit le risque de persistance cachée à ce niveau.
Le chiffrement est souvent accéléré directement en silicium pour ne pas voler des cycles CPU :
Parce que c'est inline, la sécurité n'implique pas forcément une baisse des performances du stockage.
Les clouds multi-locataires exigent une séparation stricte. Les puces d'infrastructure aident à appliquer l'isolation via des files matérielles, la protection mémoire, des fonctions de virtualisation et l'application de politiques — de sorte que le trafic ou les requêtes de stockage d'un locataire ne puissent pas espionner un autre. C'est particulièrement critique quand des DPUs gèrent le réseau virtuel et quand des périphériques PCIe sont partagés.
La fiabilité n'est pas seulement « absence de pannes » — c'est détection et récupération rapides. De nombreux designs de silicium d'infrastructure incluent compteurs de télémétrie, rapports d'erreur, hooks de traçage de paquets et métriques de santé que les équipes cloud intègrent dans leurs systèmes de monitoring. Lorsqu'un incident survient (pertes, pics de latence, erreurs de lien, tempêtes de retry), ces signaux aident à identifier si le problème vient de la commutation Ethernet, de la DPU ou du contrôleur de stockage — réduisant le temps de résolution et améliorant la disponibilité globale.
Imaginez une action simple : vous ouvrez une application de shopping et touchez « Voir l'historique des commandes ». Cette unique requête traverse plusieurs systèmes — et chaque étape est une opportunité de retard.
Votre requête atteint le bord cloud et le load balancer. Le paquet est dirigé vers un serveur d'application sain.
Il arrive sur l'hôte applicatif. Traditionnellement, le CPU hôte gère beaucoup de la « plomberie » : chiffrement, règles de pare-feu, réseau virtuel et gestion des files.
L'app interroge une base de données. La requête traverse le réseau du data center jusqu'au cluster de base, puis récupère les données depuis le stockage.
La réponse revient par le même chemin. Les résultats sont empaquetés, chiffrés et renvoyés à votre téléphone.
Les Smart NICs/DPUs et le silicium spécialisé (y compris des solutions de fournisseurs comme Marvell) déplacent le travail répétable hors des CPU généralistes :
Les opérateurs cloud ne choisissent pas une puce parce qu'elle est « plus rapide » en abstracto — ils la choisissent quand le travail est important, répétable et mérite d'être transformé en matériel dédié. Le silicium spécialisé est le plus précieux à grande échelle (millions de requêtes similaires), quand les besoins de performance sont prévisibles et quand de petits gains d'efficacité se cumulent à travers les flottes.
Les équipes cartographient généralement leurs goulots vers des fonctions spécifiques : traitement de paquets et sécurité dans le chemin réseau, traduction de stockage et protection des données dans le chemin I/O, ou primitives compression/crypto/AI dans les blocs d'accélération. La question clé : le travail peut-il être délesté sans casser le modèle logiciel ? Si votre plateforme dépend de fonctionnalités Linux, d'un comportement de commutation virtuel ou de sémantiques de stockage particulières, la puce doit s'insérer dans ces hypothèses.
Demandez des clarifications sur :
Les benchmarks comptent, mais seulement s'ils reflètent la production : mélanges réels de paquets, profondeurs de files réelles et isolation réaliste des locataires. La puissance s'évalue en « travail par watt », pas en débit maximal — surtout quand les armoires sont limitées en puissance.
L'effort d'intégration est souvent décisif. Une puce 10% meilleure sur le papier peut perdre face à une autre plus simple à déployer, surveiller et patcher à grande échelle.
Les équipes cloud réduisent le risque en privilégiant les standards (Ethernet, NVMe, PCIe/CXL), des APIs bien documentées et des outils de gestion interopérables. Même en utilisant des fonctionnalités propres à un vendeur (y compris Marvell et pairs), elles essaient de garder des plans de contrôle portables pour que le hardware évolue sans réécrire toute la plateforme.
Le même principe s'applique côté logiciel : en construisant des services destinés à s'exécuter sur cette infrastructure, il est utile de garder des architectures portables. Des plateformes comme Koder.ai peuvent accélérer le prototypage et l'itération de backends web (Go + PostgreSQL) et de frontends React via un workflow chat-driven, tout en permettant d'exporter le code source et de déployer selon les contraintes cloud et conformité propres aux équipes.
Le silicium d'infrastructure cloud passe de « accélération intéressante » à plomberie de base. À mesure que davantage de services deviennent sensibles à la latence (inférence AI, analytique en temps réel, inspection de sécurité), les puces qui gèrent le réseau, le stockage et le déplacement de données efficacement compteront autant que les CPU.
Les réseaux à large bande passante ne sont plus une option haut de gamme — c'est attendu. Cela pousse la commutation Ethernet, le traitement de paquets et les DPUs/Smart NICs vers des ports plus rapides, une latence plus basse et un meilleur contrôle de congestion. Les fournisseurs comme Marvell continueront à concurrencer sur la quantité de travail pouvant être délestée en matériel (chiffrement, télémétrie, virtual switching) sans ajouter de complexité opérationnelle.
PCIe et CXL permettront de plus en plus la désagrégation : mutualiser mémoire et accélérateurs pour que les armoires puissent être « composées » selon la charge. L'opportunité silicon n'est pas seulement la PHY CXL — ce sont les contrôleurs, la commutation et le firmware qui rendent les ressources mutualisées prévisibles, sécurisées et observables pour les équipes cloud.
Les grands fournisseurs cherchent différenciation et intégration serrée entre silicium réseau, contrôleurs de stockage et accélérateurs personnalisés. Attendez-vous à davantage de programmes semi-personnalisés où un bloc standard (SerDes, commutation Ethernet, NVMe) est couplé à des fonctionnalités spécifiques à la plateforme, des outils de déploiement et des fenêtres de support longues.
La performance par watt sera la métrique vedette, surtout à mesure que les plafonds énergétiques limitent l'expansion. Les fonctions de sécurité se rapprocheront du chemin de données (chiffrement inline, secure boot, attestation). Enfin, les chemins de mise à niveau compteront : pouvez-vous adopter de nouveaux débits, des révisions CXL ou des fonctionnalités de délestage sans repenser toute la plateforme — ni rompre la compatibilité avec les armoires existantes ?
Marvell cible principalement la couche « chemin des données » dans les centres de données cloud : réseau (NICs/DPUs, silicium de commutation), contrôleurs de stockage (NVMe et fonctions associées) et blocs d'accélération spécialisés (crypto, traitement de paquets, compression, télémétrie). L'objectif est de déplacer, protéger et gérer les données à grande échelle sans mobiliser les cœurs CPU principaux.
Parce que les CPU généralistes sont flexibles mais inefficients pour les tâches d'infrastructure répétitives et à fort volume comme le traitement de paquets, le chiffrement ou les protocoles de stockage. Déléguer ces tâches à du silicium dédié améliore :
Une Smart NIC est une carte réseau qui intègre un calcul supplémentaire pour exécuter des fonctions réseau directement sur la carte. Une DPU (Data Processing Unit) va plus loin : elle fonctionne comme un « ordinateur d'infrastructure » dédié avec plusieurs cœurs, des accélérateurs matériels et des fonctions d'isolation.
Parmi les délestages courants :
Cela réduit la charge CPU et aide à stabiliser la latence sous charge.
La majorité du trafic circule « est–ouest » à l'intérieur du centre de données : appels service-à-service, réplication de stockage, trafic base de données/cache et charges AI distribuées. Ce trafic interne nécessite une latence prévisible et un débit élevé, ce qui pousse à traiter davantage dans les NICs/DPUs et le silicium de commutation pour maintenir des performances constantes à grande échelle.
La plupart des centres hyperscale utilisent une topologie leaf–spine (ToR + spine) :
Le silicium de commutation doit acheminer les paquets, tamponner les rafales, appliquer la QoS et fournir de la télémétrie — tout cela à débit ligne.
Un contrôleur de stockage s'intercale entre la mémoire flash et le reste du système et réalise le travail qui rend le stockage rapide et fiable :
Beaucoup intègrent aussi l'accélération matérielle pour , et , afin que le stockage ne monopolise pas le CPU hôte.
NVMe est conçu pour la mémoire flash avec peu d'overhead et une forte parallélisme (files multiples, nombreuses opérations en vol). Dans le cloud, l'avantage se situe souvent au niveau d'une latence constamment basse sous charge, pas seulement du débit maximal — particulièrement quand des milliers de petites IO frappent le stockage partagé en même temps.
PCIe est l'interconnexion interne haute vitesse pour NICs, DPUs, SSDs, GPUs et accélérateurs. CXL utilise la même couche physique mais ajoute des moyens plus efficaces de partager des ressources de type mémoire.
Concrètement, PCIe/CXL permettent :
Demandez des preuves liées à des charges réalistes et à vos exigences opérationnelles :
L'effort d'intégration pèse souvent autant que la performance brute.
