Marvell et le silicium qui alimente discrètement l'infrastructure cloud

Ce que fait Marvell dans les centres de données cloud modernes

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.

Où Marvell s'insère dans une pile cloud typique

Si vous imaginez une armoire cloud de haut en bas, les dispositifs Marvell se trouvent souvent :

• En bordure réseau du serveur, aidant à envoyer et recevoir le trafic efficacement
• Dans les commutateurs et l'équipement réseau, dirigeant les paquets vers la bonne destination
• Près du stockage, déplaçant les données entre les SSD, les réseaux de stockage et les serveurs
• Le long des interconnexions clés, permettant une communication rapide entre composants

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.

Pourquoi la plupart de ce travail est invisible pour l'utilisateur final

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.

Une carte rapide : réseau, stockage, accélération

Le rôle de Marvell se regroupe facilement en trois catégories :

• Réseau : déplacer les paquets rapidement et de manière prévisible
• Stockage : lire/écrire des données de façon sûre à grande échelle
• Accélération : calcul dédié pour les tâches d'infrastructure répétitives

Voilà le silicium « discret » qui aide les services cloud à paraître simples en surface.

Pourquoi les clouds ont besoin de puces d'infrastructure spécialisées

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é.

Le trafic croît plus vite que la marge CPU

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.

Le trafic est–ouest domine à l'intérieur du centre de données

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.

L'efficacité est maintenant une exigence prioritaire

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 :

• Le rendement par watt (plus de travail pour le même budget énergétique)
• La densité de serveurs (plus de calcul utile par armoire)
• Le coût d'exploitation (moins d'énergie et de refroidissement pour le même débit)

Du « CPU monolithique » vers des assistants spécialisés

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.

Délestage réseau : explication des Smart NICs et des DPUs

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).

Smart NIC vs DPU (définitions simples)

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 :

• Smart NIC : une NIC avec un cerveau utile.
• DPU : une NIC plus un système dédié aux tâches d'infrastructure.

Ce qui est délesté du CPU

On délègue des travaux répétables et à fort volume qui voleraient autrement des cycles CPU aux applications. Exemples courants :

• Chemin de données réseau : commutation virtuelle, règles de routage, encapsulation/décapsulation (ex. overlays), shaping du trafic
• Sécurité : chiffrement TLS/IPsec, application de politiques de pare-feu, micro-segmentation, boot sécurisé et attestation
• Accélération du trafic de stockage : orientation efficace des paquets de stockage, dans certains designs assistance pour les flux storage-over-network
• Télémétrie : logs de flux, échantillonnage de paquets, compteurs, mesures de latence — capturés à vitesse ligne

Pourquoi c'est important : performances prévisibles et moindre charge CPU

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 :

• Libérant des cœurs CPU pour vos charges (services web, bases de données, pipelines AI)
• Stabilisant la latence parce que le traitement des paquets se fait dans des chemins matériels dédiés
• Augmentant la densité hôte : moins de ressources CPU consommées par l'infrastructure signifie plus de travail utile par serveur
• Améliorant l'isolation : les contrôles d'infrastructure peuvent tourner séparément des charges des locataires

Où se situe une DPU dans le serveur (et à quoi elle se connecte)

Physiquement, les DPUs arrivent généralement sous forme de carte d'extension PCIe ou de module OCP NIC. Elles se connectent à :

• Le top-of-rack via des ports Ethernet (souvent à haut débit)
• Le serveur hôte via PCIe, agissant comme passerelle pour le trafic réseau entrant et sortant vers le CPU et la mémoire

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.

À l'intérieur du réseau cloud : commutation Ethernet et traitement des paquets

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.

Comment les données circulent entre serveurs : ToR et spine

La plupart des centres de données cloud utilisent une architecture « leaf–spine » :

• Commutateurs Top-of-rack (ToR / leaf) situés à chaque armoire, connectent directement les serveurs de cette armoire.
• Commutateurs spine relient tous les ToR entre eux, permettant à n'importe quel serveur d'atteindre un autre en un nombre prévisible de sauts.

Ce design garde les chemins courts et constants, élément clé pour les performances à grande échelle.

Pourquoi la faible latence et le haut débit comptent

Deux métriques façonnent l'expérience utilisateur et le coût :

• Latence (le temps qu'un paquet met) : impacte les workloads interactifs — APIs, bases de données, microservices et analytique en temps réel.
• Débit (quantité de données par seconde) : impacte les transferts massifs — réplication de stockage, sauvegardes, streaming et grands jeux de données AI.

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.

Fonctions clés : commutation, traitement de paquets, QoS

Une puce de commutation Ethernet fait plus que « forwarder » des paquets. Elle doit :

• Chercher les destinations (MAC, VLANs, et souvent en-têtes de routage/overlay) à débit ligne.
• Tamponner et ordonnancer le trafic pour éviter que la congestion ne se propage dans le fabric.
• Appliquer la QoS (Quality of Service) pour que les flux sensibles à la latence ne soient pas étouffés par les transferts de fond.
• Supporter la télémétrie et les contrôles de congestion qui aident les opérateurs à affiner les performances.

Des fournisseurs comme Marvell conçoivent du silicium focalisé sur l'exécution prévisible de ces tâches à très grande vitesse.

Ce que permettent les « débits plus élevés »

Passer de 25/100G à 200/400/800G n'est pas qu'une question de chiffres. Des débits plus élevés signifient :

• Plus de VM par armoire sans sursouscription réseau
• Accès au stockage plus rapide (surtout pour les NVMe désagrégés ou réseau)
• Cycles d'entraînement AI plus courts en alimentant plus régulièrement les GPUs

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.

Silicium de stockage : contrôleurs, NVMe et protection des données

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.

Ce que fait réellement un contrôleur de stockage

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 : pourquoi il est partout

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.

Fonctions intégrées : chiffrement, compression et protections de type RAID

Les contrôleurs modernes incluent souvent des fonctions matérielles qui évitent de consommer des cycles CPU :

• Chiffrement/déchiffrement pour protéger les données au repos avec un impact minimal sur les performances
• Compression pour stocker plus et transférer moins (utile quand la bande passante est le goulot)
• Assistance parité/erasure coding pour tolérer les pannes et reconstruire les données plus vite

Pourquoi les performances de stockage changent le comportement des apps

Le stockage n'est pas un sous-système isolé — il influe sur le comportement des applications :

• Bases de données : dépendent d'écritures rapides et constantes pour les transactions et logs durables.
• Pipelines analytiques : peuvent se bloquer quand la lecture de grands jeux de données devient une file d'attente.
• Sauvegardes et restaurations : deviennent des enjeux de continuité si le débit est limité.

En bref, le silicium de stockage transforme la flash brute en une infrastructure cloud performante et fiable.

Fondations de connectivité : PCIe et CXL en termes simples

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 : l'autoroute haute vitesse à l'intérieur d'un serveur

PCIe (Peripheral Component Interconnect Express) est le lien interne principal utilisé pour connecter :

• NICs
• SSDs et contrôleurs de stockage
• GPUs et autres accélérateurs
• DPUs/Smart NICs

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 : utiliser la même route pour partager la mémoire plus efficacement

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.

Conséquences pratiques pour le design cloud

Le bénéfice n'est pas seulement « plus rapide ». PCIe et CXL permettent :

• Des designs système plus flexibles : mixer calcul, réseau et stockage
• Meilleure utilisation : réduire les ressources inutilisées (par ex. mémoire libre sur un serveur pendant qu'un autre manque)
• Mises à niveau plus fluides : nouvelles cartes et contrôleurs pouvant s'insérer plus facilement dans des familles de serveurs existantes

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 : calcul dédié pour les charges cloud

« 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.

Ce que « personnalisé » signifie vraiment

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.

Exemples d'accélération concrets

Quelques catégories pratiques reviennent souvent :

• Aides au traitement de paquets : parsing d'en-têtes, steering de flux, shaping et application de politiques à débit ligne.
• Accélération sécurité : crypto (IPsec/TLS), gestion de clés et inspections inline.
• Accélération stockage : erasure coding, compression, déduplication, assistance parité et checksums.
• Vidéo/média : transcodage, packaging et conditionnement pour pipelines de streaming.
• Aides pour l'inférence AI : moteurs modestes pour recherches d'embeddings, pré/post-traitement ou serving de modèles.

Comment les entreprises adaptent les puces aux charges

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.

Le compromis : performance par watt vs flexibilité

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.

Puissance et efficacité : faire plus de travail par watt

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.

Pourquoi le « délestage » économise de l'énergie

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.

Le refroidissement et l'espace entrent en compte

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.

Comment évaluer les affirmations d'efficacité

Les chiffres d'efficacité sont faciles à marketer et difficiles à comparer. Quand vous voyez « meilleure performance par watt », vérifiez :

• Le contexte de mesure : débit, objectifs de latence, tailles de paquets, fonctionnalités activées (ex. chiffrement on/off)
• La frontière du système : puissance de la puce seule vs carte complète vs impact serveur entier
• Le comportement en charge : efficacité à 20–40% d'utilisation peut compter plus que le pic
• Des bases comparables : même charge, même génération de CPU, configuration NIC/commutateur similaire

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.

Sécurité et fiabilité intégrées au silicium d'infrastructure

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.

Racine matérielle de confiance et secure boot

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.

Chiffrement inline pour les données en transit et au repos

Le chiffrement est souvent accéléré directement en silicium pour ne pas voler des cycles CPU :

• Données en transit : DPUs et Smart NICs peuvent déléguer le traitement IPsec/TLS et la gestion de clés tout en maintenant un haut débit.
• Données au repos : le silicium de stockage peut effectuer du chiffrement inline à l'écriture et déchiffrer à la lecture, s'intégrant aux chemins NVMe sans transformer chaque I/O en tâche CPU-intensive.

Parce que c'est inline, la sécurité n'implique pas forcément une baisse des performances du stockage.

Isolation entre locataires sur une infrastructure partagée

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.

Observabilité pour détecter les problèmes plus tôt

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.

Exemple de bout en bout : comment une requête cloud devient plus rapide

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.

Étapes : requête → base de données → réponse

1. Votre requête atteint le bord cloud et le load balancer. Le paquet est dirigé vers un serveur d'application sain.

2. 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.

3. 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.

4. La réponse revient par le même chemin. Les résultats sont empaquetés, chiffrés et renvoyés à votre téléphone.

Où la latence s'infiltre

• Sauts réseau et traitement de paquets : chaque saut ajoute des micro-délai, mais le coût plus important peut être le travail par paquet — décisions de routage, encapsulation de tunnels, vérifications ACL.
• I/O stockage : même avec du NVMe rapide, des délais surviennent quand les files s'accumulent, quand les métadonnées sont mal gérées ou quand le chemin stockage brûle des cycles CPU.
• Contention CPU : si les mêmes cœurs CPU exécutent l'app et les tâches d'infrastructure, le trafic en rafale peut créer des "voisins bruyants".

Comment le délestage et l'accélération enlèvent les goulots

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 :

• Délestage réseau pour gérer tunneling, commutation/steering et application de politiques près du fil.
• Accélération crypto pour réduire le coût du TLS/IPsec afin que le chiffrement n'ôte pas de cycles applicatifs.
• Accélération stockage pour améliorer la gestion des files NVMe, les tâches de protection des données et libérer l'hôte de la comptabilité I/O lourde.

Ce qui s'améliore en pratique

• Latence en queue plus basse : moins de requêtes « rares mais pénalisantes » lors des pics.
• Débit supérieur : plus de requêtes servies par serveur car les CPU se concentrent sur la logique applicative.
• Meilleure constance : des performances plus stables parce que le travail d'infrastructure est isolé et prévisible.

Comment les équipes cloud choisissent le silicium pour leur infrastructure

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.

Partir de la charge, pas de la fiche technique

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.

Questions à poser aux vendeurs (avant un PoC)

Demandez des clarifications sur :

• Pour quelles charges le silicium est optimisé aujourd'hui (et lesquelles non)
• Stabilité de la roadmap : compatibilité pin/board entre générations, fenêtres de support firmware, cadence de livraison des fonctionnalités
• Compatibilité : pilotes, support hyperviseur, intégrations Kubernetes/CNI et hooks d'observabilité
• Approvisionnement et cycle : délais, stratégie second-source, disponibilité à long terme

Comment les équipes évaluent les options

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.

Éviter le lock-in

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.

Ce qui vient pour le silicium d'infrastructure de données

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.

Le haut débit devient la norme

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.

CXL et l'infrastructure composable deviennent pratiques

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.

Plus de silicium personnalisé dans les grandes plateformes

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.

À surveiller lors de l'évaluation des pièces de nouvelle génération

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 ?