Marvell kupuje XConn: zašto AI data centri u 2026 postaju „network-first“

Kada proizvođač čipova kupi interconnect specijalistu, to obično nije „još jedna akvizicija“. To je poruka gde se bottleneck pomera. Marvell-ov dogovor (~$540M) za preuzimanje XConn Technologies je signal da AI infrastruktura više nije samo „koliko GPU-ova imaš“, već koliko efikasno pomeraš podatke između compute, memorije i storage-a.

Za IT timove ovo je zapravo korisno: pravi upgrade plan postaje jasniji. Umesto da juriš samo „još GPU“, fokus ide na plumbing koji omogućava da GPU farma radi kao jedan sistem — switching, fabric dizajn, bandwidth, latencija i operativna vidljivost.

U nastavku: (1) šta ovaj potez govori o smeru AI data centara, (2) gde realno nastaju problemi u praksi, i (3) checklist koji možeš da koristiš za 2026 budžet i arhitekturu.

Šta se desilo (i zašto je bitno)

Marvell je objavio da preuzima XConn Technologies za vrednost oko $540M (kombinacija keša i akcija), uz očekivano zatvaranje transakcije početkom 2026. Cilj je jačanje pozicije u AI i cloud data center connectivity — gde efikasan prenos podataka postaje ključna prednost.

Čak i ako ne pratiš M&A, poruka je jednostavna: konektivnost postaje diferencijator. U 2026, performanse AI-a su sve više „systems problem“, a sve manje „jedan GPU problem“.

AI data centri: bottleneck se seli na interconnect

AI trening i inference na većim modelima imaju drugačiji profil od klasičnih enterprise workload-a. Kod „normalnih“ aplikacija često su limit CPU, storage IOPS ili DB contention. Kod AI klastera brzo dođeš do limita u bandwidth-u i latenciji između komponenti.

• GPU ↔ GPU: sinhronizacija i razmena podataka između više uređaja
• GPU ↔ memorija: dovoljno brz feed da GPU ne „gladuje“
• GPU ↔ storage: streaming dataset-a i checkpoint-ova
• Operativa klastera: telemetrija, congestion, incidenti i degradacije performansi

Zato pojmovi poput PCIe/CXL, switching, fabric, i optics ulaze u AI planove: oni praktično određuju da li ti se klaster ponaša kao jedna mašina ili kao skup izolovanih nodova.

Šta to znači u praksi za 2026

Ne gradi svaka firma hyperscale AI, ali isti obrazac vidiš i u manjim on-prem / private cloud okruženjima. „AI upgrade“ koji ti stvarno treba je često set infrastrukturnih upgrade-a:

• Upgrade mrežnog throughput-a (25/100/200/400G) u skladu sa rastom klastera
• Low-latency switching + konzistentan MTU end-to-end (bez skrivenih fragmentacija)
• Bolja fabric vidljivost (drops, congestion, microbursts) i tooling
• Promena storage arhitekture: tiering dataset-a, brz checkpoint, predvidljiva latencija
• Jasna segmentacija mreže (mgmt vs storage vs data vs tenant) da blast radius bude manji

Koristan mentalni model: u klasičnom IT-u mreža je često „dovoljno dobra“, pa optimizuješ compute. Kod AI-a, mreža/interconnect odlučuje da li compute uopšte može da se koristi efikasno.

Biznis ugao: kad CFO pritisak postane arhitektura pritisak

Ovo je zanimljivo jer povezuje tržište i realnu arhitekturu. Svi jure AI, ali bez rešavanja data-movement problema nema stabilne AI platforme. Zato budžeti sve češće idu na interconnect, switching, optics i operativu (observability) — a ne samo na compute.

Za mid-market i enterprise timove pitanje glasi: kad ulažeš u AI, da li gradiš platformu koja je pouzdana — ili demo klaster koji se raspadne čim dođe pravi workload?

Checklist za 2026: šta proveriti pre nego što skaluješ AI workload-e

Ova lista je praktična — možeš je proći sa mrežnim, sistemskim i storage timom.

A) Fabric i switching

• Definiši target throughput po nodu i po rack-u (danas + 12 meseci)
• Standardizuj MTU i validiraj end-to-end (uključujući firewall/gateway/ToR)
• Proveri oversubscription i uplink kapacitet u leaf-spine dizajnu
• Uvedi monitoring congestion-a (drops, microbursts; ECN ponašanje gde ima smisla)
• Planiraj optics/cabling strategiju i spares (kvar optics-a = incident)

B) Storage i data path

• Odvoji ingest dataset-a od checkpoint/backup path-a gde god može
• Benchmark ne samo throughput nego i tail latency (p95/p99)
• Tiering: NVMe za hot, object/NAS za cold, i jasne lifecycle politike
• Testiraj restore/checkpoint workflow (ne samo „piše brzo jednom“)

C) Operativa i pouzdanost

• Definiši ponašanje na link failure, ToR reboot, storage degradaciju
• Odluči telemetry stack (logovi/metrike/traces) i pragove alarma
• Runbook za congestion incident i performance regresiju
• Capacity plan: headroom za eksperimente bez udara na produkciju

Tabela: klasičan data centar vs AI-driven data centar

Zaključak: AI je sve više interconnect problem — i to je dobra vest

Akvizicija XConn-a je indikator da je konektivnost strateška komponenta AI infrastrukture. Bilo da gradiš AI klaster ili samo pripremaš data centar za teže AI workload-e, takeaway je isti: prvo isplaniraj fabric, storage tiering i operativnu vidljivost — pa tek onda skaluješ compute.

Kad to uradiš kako treba, AI kapacitet postaje predvidljivo ulaganje u platformu — a ne rizičan eksperiment koji padne na prvom ozbiljnom opterećenju.