Marvell och kiseln som osynligt driver molninfrastrukturen

Vad Marvell gör i moderna molndatacenter

De flesta tänker att “molnet” bara är servrar. I verkligheten är ett molndatacenter ett gigantiskt system för att flytta, lagra och skydda data i hög hastighet. Datainfrastruktur-kisel är den uppsättning specialiserade chip som hanterar dessa dataintensiva jobb så att huvud-CPU:erna inte behöver göra det.

Marvell fokuserar på detta "mellanlager": chipen som kopplar ihop beräkning med nätverk och lagring, accelera vanliga datacenteruppgifter och håller allt flytande förutsägbart under belastning.

Var Marvell passar in i en typisk molnstack

Om du föreställer dig en moln-rack uppifrån och ned sitter Marvell-enheter ofta:

• På serverns nätverkskant, och hjälper till att skicka och ta emot trafik effektivt
• I switchar och nätverksutrustning, och styr paket till rätt plats
• Nära lagring, och flyttar data mellan SSD:er, lagringsnätverk och servrar
• Längs viktiga interconnects, och möjliggör snabb kommunikation mellan komponenter

Det här är varken "appar" eller vanliga "servrar"—det är hårdvarubitarna som låter tusentals servrar bete sig som en samlad tjänst.

Varför det mesta av detta arbete är osynligt för slutanvändaren

När infrastrukturen gör sitt jobb märker du det inte direkt. Sidor laddas snabbare, video buffrar mindre och backuper blir klara i tid—men användaren ser aldrig nätverks-offload-motorn, lagringskontrollern eller switch-fabriken som möjliggör det. Dessa chip minskar tyst latens, frigör CPU-cykler och gör prestandan mer konsekvent.

En snabb karta: nätverk, lagring, acceleration

Marvells roll är lättast att gruppera i tre fack:

• Nätverk: flytta paket snabbt och förutsägbart
• Lagring: läsa/skriva data säkert i stor skala
• Acceleration: specialiserad beräkning för upprepade infrastrukturoppgifter

Det är den "tysta" kiseln som får molntjänster att kännas enkla i ytan.

Varför moln behöver specialiserade infrastrukturchip

Molnappar känns "software-defined", men det fysiska arbetet sker fortfarande i rack fulla av servrar, switchar och lagring. När efterfrågan växer kan moln inte lita på allmänna CPU:er för varje uppgift utan att stöta på hårda gränser i kostnad och effektivitet.

Trafiken växer snabbare än CPU-reserver

AI-träning och inferens flyttar enorma dataset runt i datacentret. Videoströmmar, backuper, analys och SaaS-plattformar lägger konstant bakgrundsbelastning. Även när beräkning finns tillgänglig, flyttas flaskhalsen ofta till att flytta, filtrera, kryptera och lagra data tillräckligt snabbt.

East–west-trafik dominerar inne i datacentret

Det mesta av molntrafiken rör aldrig det publika internet. Den färdas "east–west" mellan tjänster: microservice-anrop, databasläst, cache-uppdateringar, lagringsreplikering och distribuerade AI-jobb. Den interna trafiken behöver förutsägbar latens och hög genomströmning, vilket pressar nätverks- och lagringshårdvara att göra mer bearbetning nära dataplanet.

Effektivitet är nu ett förstaklasskrav

Kraft och utrymme är inte obegränsade. Om en molnleverantör kan offloada arbete som paketbearbetning, kryptering, kompression eller lagringschecksummor till dedikerad kisel, spenderar CPU mindre tid på overhead. Det förbättrar:

• Prestanda per watt (mer arbete för samma effektbudget)
• Serverdensitet (mer användbar beräkning per rack)
• Driftskostnad (lägre energi- och kylkostnad för samma genomströmning)

Från "en stor CPU" till specialiserade hjälpare

Istället för att skala genom att lägga till fler allmänna kärnor använder molnplattformar alltmer specialbyggda chip—Smart NICs/DPUs, switch-kisel, lagringskontroller och acceleratorer—för att hantera upprepade, volymintensiva infrastrukturoppgifter. Resultatet blir ett moln som är snabbare och billigare att driva, även när arbetslaster blir mer datahungriga.

Nätverks-offload: Smart NICs och DPUs förklarade

Molnservrar spenderar oväntat mycket tid på "infrastrukturarbete" istället för att köra din applikation. Varje paket måste flyttas, inspekteras, loggas och ibland krypteras—ofta av huvud-CPU:n. Nätverks-offload flyttar dessa sysslor till specialiserad hårdvara, där Smart NICs och DPUs dyker upp i många moderna datacenter (inklusive system byggda med Marvell-kisel).

Smart NIC vs. DPU (på enkelt språk)

En Smart NIC är ett nätverkskort som gör mer än grundläggande skicka/motta. Förutom vanliga Ethernet-portar innehåller det extra bearbetning (ofta Arm-kärnor och/eller programmerbar logik) för att köra nätverksfunktioner på kortet.

En DPU (Data Processing Unit) tar ett steg längre: den är utformad för att fungera som en dedikerad "infrastruktur-dator" inne i servern. En DPU kombinerar vanligen högpresterande nätverk, flera CPU-kärnor, hårdvaruacceleratorer (krypto, paketbearbetning) och starka isoleringsfunktioner så att den kan hantera dataförflyttning och säkerhet utan att luta sig på värd-CPU:n.

En praktisk mental modell:

• Smart NIC: ett NIC med hjälpsamma hjärnor.
• DPU: ett NIC plus ett dedikerat system för infrastrukturoppgifter.

Vad som offloadas från CPU:n

Offload riktar sig mot repetitivt, högvolymarbete som annars skulle ta CPU-cykler från applikationer. Vanliga exempel inkluderar:

• Nätverksdataplanet: virtuell switching, routingregler, inkapsling/avkapsling (t.ex. overlays), trafikformning
• Säkerhet: TLS/IPsec-kryptering, brandväggspolicyer, mikro-segmentering, secure boot och attestation
• Acceleration av lagringstrafik: styra lagringspaket effektivt, i vissa design hjälpa flöden för nätverksbaserad lagring
• Telemetri: flow-loggar, paketprovtagning, räknare, latensmätningar—fångade i linjehastighet

Varför det spelar roll: förutsägbar prestanda och lägre CPU-belastning

När CPU:n måste "vakta" nätverk kan applikationsprestanda svänga beroende på trafiktoppar, bullriga grannar eller säkerhetsbelastning. Offload hjälper genom att:

• Frigöra CPU-kärnor för dina faktiska arbetsuppgifter (webbtjänster, databaser, AI-pipelines)
• Stabilisera latens eftersom paketbearbetning sker i dedikerade hårdvaruvägar
• Öka värddens densitet: färre CPU-resurser åt infrastruktur betyder mer användbart arbete per server
• Förbättra isolation: infrastrukturella kontroller kan köras separat från hyresgästernas arbetslaster

Var en DPU sitter i servern (och vad den ansluts till)

Fysiskt kommer DPUs oftast som ett PCIe add-in-kort eller en OCP NIC-modul. De ansluts till:

• Top-of-rack-nätverket via Ethernet-portar (ofta höghastighetslänkar)
• Värdservern via PCIe, och agerar som gateway för nätverkstrafik till och från CPU och minne

Konceptuellt blir DPU:n en "trafikpolis" mellan nätverket och servern—hanterar policy, kryptering och switching så värdens OS och CPU:er kan fokusera på att köra applikationer.

Inom molnnätverk: Ethernet-switching och paketbearbetning

När du öppnar en app eller flyttar data till molnet, färdas din förfrågan vanligtvis genom ett nät av Ethernet-switchar som kopplar ihop tusentals servrar som om de vore en enda stor maskin.

Hur data rör sig mellan servrar: top-of-rack och spine

De flesta molndatacenter använder en "leaf-spine"-design:

• Top-of-rack (ToR) / leaf-switchar sitter i varje rack och kopplar direkt till servrarna där.
• Spine-switchar kopplar ihop alla ToR-switchar, så vilken server som helst kan nå en annan på ett förutsägbart antal hopp.

Denna design håller vägarna korta och konsekventa, vilket är avgörande för prestanda i stor skala.

Varför låg latens och hög genomströmning spelar roll

Två siffror formar användarupplevelse och kostnad:

• Latens (hur lång tid ett paket tar) påverkar interaktiva arbetslaster—API:er, databaser, mikrotjänster och realtidsanalys.
• Genomströmning (hur mycket data per sekund) påverkar bulköverföringar—lagringsreplikering, backuper, streaming och stora AI-dataset.

Molnoperatörer försöker hålla latensen stabil även när länkar är upptagna, samtidigt som de trycker igenom stora mängder trafik.

Nyckelfunktioner: switching, paketbearbetning, QoS

En Ethernet-switch-chip gör mer än att bara "skicka paket." Den måste:

• Slå upp destinationer (MAC, VLAN och ofta routing/overlay-headrar) i linjehastighet.
• Buffra och schemalägga trafik för att undvika att trängsel sprider sig genom fabricen.
• Tillämpa QoS (Quality of Service) så latenskänsliga flöden inte drunknar i bakgrundsöverföringar.
• Stödja telemetri och congestion controls som hjälper operatörer att fintrimma prestanda.

Leverantörer som Marvell bygger kisel som fokuserar på att göra dessa uppgifter förutsägbart i mycket höga hastigheter.

Vad "högre hastigheter" möjliggör

Att gå från 25/100G till 200/400/800G är inte bara en siffra. Högre hastigheter kan innebära:

• Fler VM:ar per rack utan att nätverket blir överbelastat
• Snabbare lagringstillgång (särskilt för disaggregated eller nätverksbaserad NVMe)
• Kortare AI-träningscykler genom att mata GPU:er med data mer konsekvent

Resultatet är ett datacenternätverk som känns mindre som "kablar" och mer som delad infrastruktur för varje arbetsbelastning ovanpå.

Lagringskisel: kontrollers, NVMe och dataskydd

När folk pratar om molnprestanda föreställer de sig ofta CPU:er och GPU:er. Men en stor del av "hastigheten" (och tillförlitligheten) avgörs av lagringskiseln som sitter mellan flash-enheter och resten av servern. Det lagret är typiskt en lagringskontroller—specialbyggda chip som styr hur data skrivs, läses, kontrolleras och återställs.

Vad en lagringskontroller faktiskt gör

En lagringskontroller är trafikdirigenten för persistent data. Den delar upp inkommande skrivningar i hanterbara bitar, schemalägger läsningar så varm data returneras snabbt och kör ständiga integritetskontroller så korrupta bitar inte tyst blir till korrupta filer.

Den hanterar också det oansenliga bokföringsarbetet som gör lagring förutsägbar i skala: mappar logiska block till fysiska flash-platser, balanserar wear så diskarna håller längre och håller latensen jämn när många applikationer rör vid samma lagringspool.

NVMe: varför det är överallt

NVMe (Non-Volatile Memory Express) är ett protokoll designat för snabb flashlagring. Det blev vanligt eftersom det minskar overhead och stöder parallella "kösystem"—vilket betyder att många operationer kan vara igång samtidigt, vilket passar molnarbetslaster där tusentals små läs/skriv händer samtidigt.

För molnleverantörer handlar NVMe inte bara om maximal genomströmning; det handlar om konsekvent låg latens under belastning, vilket håller applikationer responsiva.

Inbyggda funktioner: kryptering, kompression och RAID-liknande skydd

Moderna kontrollers innehåller ofta hårdvarufunktioner som annars skulle belasta CPU:n:

• Kryptering/dekryptering för att skydda data i vila med minimal prestandapåverkan
• Kompression för att lagra mer och flytta mindre (nyttigt när bandbredd är flaskhalsen)
• RAID-liknande paritet och erasure coding-assistans för att tolerera fel och återbygga data snabbare

Varför lagringsprestanda ändrar appbeteende

Lagring är inte en isolerad del—den formar hur applikationer beter sig:

• Databaser är beroende av snabba, konsekventa skrivningar för transaktioner och hållbara loggar.
• Analys-pipelines kan stanna upp när läsning av stora dataset blir en kö-problem.
• Backuper och återställningar blir affärskritiska när genomströmningen är begränsad.

Kort sagt, lagringskisel förvandlar rå flash till pålitlig, höggenomströmningsinfrastruktur.

Anslutningsgrunder: PCIe och CXL på enkelt språk

När molnleverantörer uppgraderar servrar byter de inte bara CPU:er. De behöver också det "bindemedel" som låter CPU:er prata med nätverkskort, lagring och acceleratorer utan att kräva en komplett redesign. Därför spelar standarder som PCIe och CXL roll: de håller delar kompatibla, gör uppgraderingar mindre riskfyllda och hjälper datacenter att skala på ett förutsägbart sätt.

PCIe: motorvägen inne i servern

PCIe (Peripheral Component Interconnect Express) är huvudlänken som används för att ansluta komponenter som:

• NICs (nätverkskort)
• SSD:er och lagringskontrollers
• GPUs och andra acceleratorer
• DPUs/Smart NICs

En enkel modell: PCIe är som att lägga till fler körfält på en motorväg. Nyare PCIe-generationer ökar hastigheten per körfält, och bredare länkar (x8, x16 osv.) ger mer total kapacitet. För molnoperatörer påverkar detta direkt hur snabbt data kan röra sig mellan beräkning och de enheter som matar den.

Marvells infrastruktur-kisel sitter ofta i ena änden av dessa PCIe-anslutningar—inne i ett NIC, DPU, lagringskontroller eller switch-nära komponent—så PCIe-kapacitet kan vara en praktisk begränsare (eller möjliggörare) för prestandauppgraderingar.

CXL: använda samma väg för att dela minne mer effektivt

CXL (Compute Express Link) bygger på PCIe:s fysiska anslutning men lägger till nya sätt för enheter att dela minnesliknande resurser med lägre overhead. Enkelt uttryckt hjälper CXL servrar att behandla vissa externa resurser (som minnesexpansion eller poolat minne) mer som en lokal förlängning än en avlägsen enhet.

Praktiska utfall för molndesign

Vinsten är inte bara "snabbare." PCIe och CXL möjliggör:

• Mer flexibel systemdesign: mixa och matcha beräknings-, nätverks- och lagringsbyggstenar
• Bättre utnyttjande: minska strandade resurser (t.ex. minne i en server medan en annan saknar)
• Smidigare uppgraderingar: nyare kort och kontrollers kan användas i befintliga serverfamiljer enklare

Anslutningsstandarder får inga stora rubriker, men de påverkar starkt hur snabbt moln kan anta bättre nätverk, lagring och acceleration.

Specialanpassad acceleration: syftesbyggd beräkning för molnarbetslaster

"Specialanpassad acceleration" i molninfrastruktur betyder inte alltid en stor, generell GPU. Oftare innebär det att lägga till små, specialiserade beräkningsblock som snabbar upp en upprepad uppgift—så CPU:erna kan fokusera på att köra applikationer.

Vad "specialanpassad" egentligen betyder

Molnarbetslaster varierar mycket: en lagringstung databasserver har andra flaskhalsar än en videostreaming-edge eller en brandväggsbox. Syftesbyggd kisel riktar in sig direkt på dessa flaskhalsar—ofta genom att flytta en funktion till hårdvara så den kör snabbare, mer konsekvent och med mindre CPU-overhead.

Vanliga acceleratorer du faktiskt märker

Några praktiska kategorier återkommer:

• Packetbehandlingsassistenter: parsa headrar, styra flöden, forma trafik och tillämpa policys i linjehastighet.
• Säkerhetsacceleration: krypto (IPsec/TLS), nyckelhantering och inline-inspektion som annars skulle bränna CPU-cykler.
• Lagringsacceleration: erasure coding, kompression, dedupe-assist, RAID-paritet och checksummor—särskilt där genomströmning och förutsägbar latens betyder mest.
• Video/media: transkodning, paketering och innehållsberedning för streamingpipelines.
• AI-inference-hjälpare: inte alltid fullskaliga träningsacceleratorer—ibland små motorer för embedding-sökningar, pre/post-processing eller model-serving.

Hur företag anpassar chip till arbetslaster

Stora molnteam börjar ofta med profilering: var stannar förfrågningar, och vilka uppgifter upprepas miljoner gånger per sekund? Sedan väljer de om de ska accelerera via ett programmerbart motor (mer anpassningsbart) eller fixed-function-blocks (högst effektivitet). Leverantörer som Marvell tillhandahåller ofta byggstenar—nätverk, säkerhet, lagringsgränssnitt—så den "specialanpassade" delen kan fokusera på plattformens specifika heta vägar.

Avvägningen: prestanda per watt vs flexibilitet

Fixed-function-acceleration vinner ofta på prestanda per watt och determinism, men är svårare att återanvända om arbetslaster förändras. Mer programmerbara alternativ är enklare att vidareutveckla, men kan kosta mer kraft och lämna viss prestanda outnyttjad. De bästa designerna blandar båda: flexibla kontrollplaner med hårdvaru-snabba vägar där det räknas.

Effekt och effektivitet: göra mer arbete per watt

Ström är ofta den verkliga gränsen i ett datacenter—inte hur många servrar du kan köpa, utan hur mycket elektricitet du kan leverera och bli av med som värme. När en anläggning når sin effektgräns är det enda sättet att växa att få mer nyttigt arbete ur varje watt.

Varför "offload" sparar energi

Allmänna CPU:er är flexibla men inte alltid effektiva på repetitiva infrastrukturoppgifter som pakethantering, kryptering, lagringsprotokollbehandling eller telemetri. Syftesbyggd infrastrukturskisel (t.ex. Smart NICs/DPUs, switchar och lagringskontrollers) kan utföra dessa uppgifter med färre cykler och mindre förlorat arbete.

Energivinsten är ofta indirekt: om offload minskar CPU-användningen kan du köra samma arbetsbelastning med färre CPU-kärnor aktiva, lägre klockfrekvenser eller färre servrar. Det kan också minska minnes- och PCIe-tryck, vilket ytterligare skär ner effektförbrukningen.

Kylning och utrymme är en del av chip-beslutet

Varje watt blir värme. Mer värme betyder snabbare fläktar, högre kylflöde och striktare rack-planering. Högre densitets-rack kan vara attraktiva, men bara om du kan kyla dem konsekvent. Därför spelar chip-val roll bortom rå genomströmning: en komponent som drar mindre effekt (eller förblir effektiv vid hög belastning) låter operatörer packa mer kapacitet i samma fotavtryck utan att skapa hotspots.

Hur man värderar effektkrav

Effekt-siffror är lätta att marknadsföra och svåra att jämföra. När du ser "bättre prestanda per watt", titta på:

• Mätkontexten: genomströmning, latensmål, paketstorlekar och aktiverade funktioner (t.ex. kryptering på/av).
• Systemgränsen: endast chip-effekt vs. hela kortet vs. serverpåverkan.
• Belastningsbeteende: effektivitet vid 20–40% nyttjande kan vara viktigare än topp.
• Jämförbara baser: samma arbetslaster, samma CPU-generation, liknande NIC/switch-konfiguration.

De mest trovärdiga påståendena kopplar watt till en specifik, reproducerbar arbetsbelastning och visar vad som förändrades på server- eller racknivå—inte bara ett datablad.

Säkerhets- och tillförlitlighetsfunktioner byggda i infrastrukturkisel

Molnleverantörer delar samma fysiska maskiner mellan många kunder, så säkerhet kan inte läggas på i efterhand. Mycket av den hanteras ner på chip-nivå—i smart NICs/DPUs, molnnätverkschip, Ethernet-switch-kisel och datacenter-lagringskontrollers—där hårdvaru-offload kan tillämpa skydd i full linjehastighet.

Hårdvarurot och secure boot (kedjan att "endast betrodd kod körs")

De flesta infrastrukturchip inkluderar en hårdvarurot: en liten, oföränderlig logikdel och nycklar som kan verifiera firmware innan något annat startar. Med secure boot kontrollerar chippet kryptografiska signaturer på sin firmware (och ibland på värdens boot-komponenter), och vägrar köra modifierad eller okänd kod.

Detta är viktigt eftersom en komprometterad DPU eller lagringskontroller kan ligga "mellan" dina servrar och nätverk-/lagringsfabricen. Secure boot minskar risken för dold persistens på det lagret.

Inline-kryptering för data i transit och i vila

Kryptering accelereras ofta direkt i kisel så den inte stjäl CPU-tid:

• Data in transit: DPUs och Smart NICs kan offloada IPsec/TLS-liknande bearbetning och nyckelhantering samtidigt som genomströmningen hålls hög.
• Data at rest: lagringskisel kan utföra inline-kryptering vid skrivning och dekryptera vid läsning, integrerat i NVMe-vägar utan att göra varje I/O till en CPU-tung uppgift.

Eftersom det är inline behöver säkerhet inte betyda långsammare lagringsnätverk.

Isolation mellan hyresgäster i delad infrastruktur

Multitenant-moln förlitar sig på strikt separation. Infrastrukturchip kan hjälpa till att upprätthålla isolation med hårdvaruköer, minnesskydd, virtuella funktioner och policygenomförande—så en hyresgästs trafik eller lagringsförfrågningar inte kan snoka i en annans. Detta är särskilt viktigt när DPUs hanterar virtuellt nätverk och när PCIe-enheter delas över arbetslaster.

Observabilitetsfunktioner som upptäcker problem tidigare

Tillförlitlighet är inte bara "inga fel"—det är snabbare upptäckt och återställning. Många data-infrastruktur-kiseldesigner inkluderar telemetri-räknare, felrapportering, paketspårningskrokar och hälso-metriker som molnteam kan mata in i övervakningssystem. När något går fel (drops, latensspikar, link-fel, retry-stormar) hjälper dessa inbyggda signaler att bedöma om problemet ligger i Ethernet-switching, DPU:n eller lagringskontrollern—vilket kortar tid till åtgärd och förbättrar drifttid.

Ett ända-till-ända-exempel: Hur en molnförfrågan blir snabbare

Föreställ dig en enkel handling: du öppnar en shoppingapp och trycker på "Visa orderhistorik." Den förfrågan färdas genom flera system—och varje steg är en möjlighet till fördröjning.

Steg-för-steg: förfrågan → databas → svar

1. Din förfrågan når molnkanten och load balancern. Paketet routas till en frisk applikationsserver.

2. Det når applikationshosten. Traditionellt hanterar värd-CPU mycket av "plumbing": kryptering, brandväggsregler, virtuellt nätverk och köhantering.

3. Appen frågar en databas. Den förfrågan måste färdas över datacenternätverket till en databaskluster och sedan hämta data från lagring.

4. Svaret återvänder på samma sätt. Resultaten paketeras, krypteras och skickas tillbaka till din telefon.

Var latens smyger in

• Nätverkshopp och paketbearbetning: varje hopp lägger till mikroförseningar, men den större kostnaden kan vara per-paket-arbetet—routingbeslut, tunnelinkapsling, ACL-kontroller.
• Lagrings-I/O: även med snabb NVMe dyker fördröjningar upp när köer byggs upp, metadata hanteras ineffektivt eller när lagringsvägen belastar CPU:n.
• CPU-konkurrens: om samma CPU-kärnor kör både din applikation och infrastrukturarbete kan burstig trafik skapa "bullriga grannar".

Hur offload och acceleration tar bort flaskhalsar

Smart NICs/DPUs och specialiserad infrastrukturskisel (inklusive lösningar från leverantörer som Marvell) flyttar upprepade uppgifter bort från allmänna CPU:er:

• Nätverks-offload kan hantera tunnling, switching/styrning och policy nära kabeln.
• Kryptoacceleration minskar kostnaden för TLS/IPsec.
• Lagringsacceleration förbättrar NVMe-köhantering, RAID/data-protektion och frigör värden från tung I/O-bokföring.

Vad som förbättras i praktiken

• Lägre tail-latens: färre "sällsynta men smärtsamma" långsamma förfrågningar vid trafiktoppar.
• Högre genomströmning: fler förfrågningar per server eftersom CPU:er fokuserar på applikationslogik.
• Bättre konsekvens: prestandan blir jämnare eftersom infrastrukturarbetet isoleras och blir förutsägbart.

Hur molnteam väljer kisel för sin infrastruktur

Molnoperatörer väljer inte infrastrukturchip för att de är "snabbare" i abstrakt mening—de väljer dem när arbetet är stort, upprepat och värt att flytta in i dedikerad hårdvara. Specialiserad kisel är mest värdefull i stor skala (miljontals liknande förfrågningar), när prestandabehoven är förutsägbara (stabila trafikmönster, kända protokoll) och när små effektvinster blir betydande besparingar över hela flottan.

Börja med arbetslasten, inte databladet

Team brukar kartlägga sina största flaskhalsar till specifika funktioner: paketbearbetning och säkerhet i nätvägen, lagringstranslation och dataskydd i I/O-vägen, eller kompression/krypto/AI-primitiver i acceleratorblock. En nyckelfråga är om jobbet kan offloadas utan att bryta mjukvarumodellen. Om plattformen förlitar sig på viss Linux-funktionalitet, virtuella switchbeteenden eller lagringssemantik måste chippet passa dessa antaganden.

Frågor att ställa leverantörer (före PoC)

Be om klarhet i:

• Vilka arbetslaster kiseln är tuned för idag (och vilka den inte är)
• Roadmap-stabilitet: nästa generations pin/board-kompatibilitet, firmware-supportfönster och funktionstillförsel
• Kompatibilitet: drivrutiner, hypervisor-stöd, Kubernetes/CNI-integrationer och observability-krokar
• Leverans och livscykel: ledtider, second-source-strategi och långsiktig tillgänglighet

Hur team utvärderar alternativ

Benchmarks betyder något, men bara om de speglar produktion: verkliga paketmixar, verkliga lagringskö-djup och realistisk tenant-isolering. Effekt utvärderas som "arbete per watt", inte toppgenomströmning—särskilt när rack har effektbegränsningar.

Integrationsinsatsen är ofta avgörande. Ett chipp som är 10% bättre i specifikation kan förlora mot ett som är enklare att provisionera, övervaka och patcha i stor skala.

Undvik inlåsning

Molnteam minskar risk genom att föredra standarder (Ethernet, NVMe, PCIe/CXL), väldokumenterade API:er och interoperabelt management-verktyg. Även när de använder leverantörsfunktioner (inklusive de från Marvell och konkurrenter) försöker de hålla högre nivåns kontrollplan portabel så hårdvara kan bytas utan att kräva en full plattformsomskrivning.

Samma princip gäller på mjukvarusidan: när du bygger tjänster som så småningom ska köras på denna infrastruktur, hjälp till att hålla arkitekturer portabla. Plattformar som Koder.ai kan snabba upp prototypande och iteration av webb-backends (Go + PostgreSQL) och React-frontends via en chattdriven arbetsflöde, samtidigt som team kan exportera källkod och distribuera enligt sina egna moln- och efterlevnadskrav.

Vad som kommer härnäst för data-infrastruktur-kisel

Molninfrastrukturskisel går från "trevligt att ha" acceleration till grundläggande rörledningar. När fler tjänster blir latenskänsliga (AI-inferens, realtidsanalys, säkerhetsinspektion) kommer chip som hanterar nätverk, lagring och dataförflyttning effektivt att bli lika viktiga som CPU:er.

Högre bandbredd blir standard

Högre bandbreddsnätverk är inte längre en specialnivå—de förväntas. Det driver Ethernet-switching, paketbearbetning och DPUs/Smart NICs mot snabbare portar, lägre latens och bättre congestion control. Leverantörer som Marvell kommer fortsätta konkurrera om hur mycket arbete som kan offloadas i hårdvara (kryptering, telemetri, virtuell switching) utan att öka driftkomplexiteten.

CXL och komponerbar infrastruktur blir praktiskt

PCIe och CXL-anslutning kommer i högre grad möjliggöra disaggregation: poola minne och acceleratorer så rack kan "komponeras" per arbetsbelastning. Kiselmöjligheten är inte bara CXL-PHY:t—det är kontrollers, switching och firmware som gör poolade resurser förutsägbara, säkra och observerbara för molnteam.

Mer specialanpassad kisel inom stora plattformar

Stora leverantörer vill ha differentiering och tightare integration över molnnätverkschip, datacenter-lagringskontrollers och specialacceleration. Förvänta fler semi-anpassade program där en standard byggsten (SerDes, Ethernet-switching, NVMe) paras med plattformspecifika funktioner, distributionsverktyg och långa supportfönster.

Vad man bör följa när man utvärderar nästa generations delar

Prestanda per watt blir huvudmåttet, särskilt när effektbegränsningar sätter stopp för expansion. Säkerhetsfunktioner flyttas närmare dataplanet (inline-kryptering, secure boot, attestation). Slutligen kommer uppgraderingsvägar vara viktiga: kan du anta ny bandbredd, CXL-revisioner eller offload-funktioner utan att redesigna hela plattformen—eller bryta kompatibiliteten med befintliga rack?