Neocloud-urile nu mai sunt doar un refugiu pentru GPU-uri scare. Astăzi, startup-urile native AI aleg infrastructura pe criterii de latență, capacitate de burst și deschidere — nu pe disponibilitatea chipurilor. CoreWeave, unul dintre jucătorii dominanți, demonstrează că modul în care cablezi și alimentezi clusterele GPU poate deplasa latența cu ordine de mărime. Pentru furnizorii de hosting și echipele DevOps care gestionează workload-uri de inferență la scară, această realitate schimbă regula jocului: nu mai contează doar câte H100 sau H200 ai în raft, ci cum le legești între ele și la rețea.
Ghid ServerSpan relevant: Locația VPS-ului Asterisk: latență, jitter și rutare.
–
De la scarță la optimizare: noua economie a neocloud-urilor
Până recent, diferentierierea principală între furnizori de GPU cloud era simplă: cine are stoc. Acea eră s-a încheiat. CoreWeave raportează că cererea s-a deplasat spre burst capacity — capacitatea de a scală instantaneu pentru spike-uri de inferență — și spre latență deterministă. Startup-urile care rulează modele de producție (RAG, agenți conversaționali, generare cod) nu toleră jitter de 200–500 ms între request-uri identice.
Această schimbare forțează furnizorii să investească în trei direcții simultan: networking-ul de tip NVLink/NVSwitch la nivel de rack, fabric-ul de comutație RoCE v2 sau InfiniBand NDR la nivel de cluster, și distribuția de putere care elimina throttle-ul termic sub sarcini sostenite. Un furnizor de dedicated servers care ignoră aceste straturi livrează hardware, nu performanță. Diferența se măsoară în tokeni pe secundă și, implicit, în cost per million tokens pentru clientul final.
Pentru mai multe detalii despre această parte a subiectului, vezi Performanța site-ului tău: De ce să câștigi online e ca și cum ai câștiga Open Championship.
–
Stratul fizic: cablare, putere și topologie
La nivel de raft, topologia NVLink 4.0 (900 GB/s bidirecțional per GPU pe H100) definește granularitatea comunicării intra-nod. Dar battalions de GPU-uri nu scală decât dacă fabric-ul de comutație suportă all-reduce și all-gather fără congestie. CoreWeave evidențiază că deploy-urile care folosesc switch-uri 400 GbE cu RoCE v2 configurate corect (PFC, ECN, DCBX) reduc latența colectivă cu 30–40% față de deploy-uri identice pe Ethernet standard cu TCP/IP.
Alimentarea este la fel de critică. Un rack de 8× H100 SXM5 consumă 5.6–7 kW în pic, dar profilele de putere reale arată spike-uri de 1.5–2× media pe ferestre de 10–50 ms în timpul *warm-up*-ului modelului sau la prefill lung. Dacă PDU-urile și UPS-urile nu sunt dimensionate pentru crest factor și nu au monitorizare per port cu sampling sub-secundă, GPU-urile intră în power throttling (reducere clock, TDP limit) — și latența explodă. O soluție pragmatică: PDU-uri inteligente cu outlet-level metering și alerte programabile la 80% capacitate nominală, integrate în telemetria clusterului (Prometheus + node-exporter custom).
Căile de cablare — DAC-uri passive vs. AOC vs. transceiver-uri optice — nu sunt neutre. DAC-uri passive de 3 m la 400 GbE introduc atenuare care forțează FEC (RS-FEC 544/514) și adaugă ~100 ns latență per hop. AOC-urile elimină atenuarea dar costă 3–4× mai mult. Pentru clustere de inferență unde tail latency (p99) contează mai mult decât throughput brut, recomandarea CoreWeave este: DAC passive până la 2 m intra-rack, AOC pentru interconnect rack-to-switch, transceiver-uri optice single-mode pentru spine.
–
Stocarea și networking-ul ca differențiatori de latență
Inferența modernă nu e compute-bound exclusiv. Modelele cu context lung (128k–1M tokeni) cer prefill masiv și KV cache care nu încăpează în VRAM. Soluția: offload pe NVMe local (PCIe 5.0, 14 GB/s citire secvențială) sau pe storage distribuit cu RDMA (NVMe-oF/TCP). CoreWeave raportează că migrarea KV cache pe storage NVMe-oF cu latență sub-200 μs reduce time-to-first-token cu 35–50% pe modele 70B+ comparativ cu recomputare sau swap pe disk local SATA.
Networking-ul de stocare trebuie să partajeze fabric-ul cu cel de calcul — sau să fie izolat cu QoS strict. O arhitectură validată: spine-leaf cu switch-uri 800 GbE (Tomahawk 5 / Jericho 3), VLAN-uri dedicate pentru storage traffic, ECN activat end-to-end, buffer-uri deep (cel puțin 64 MB per port) pentru a absorbi microburst-urile de checkpoint și replica ale KV cache. Furnizorii care oferă servere dedicate cu atachament direct la astfel de fabricuri (exemplu: https://www.dedicated-servers.ro/servere-dedicate/) permit clienților să evite penalizarea public cloud egress și să controleze topologia la nivel de pachet.
–
Burst capacity și economie: de la rezervat la elastic
Modelul economic clasic — rezervă GPU-uri pe 1–3 ani — devine ineficient când workload-ul e spicos: batch inference noaptea, spike-uri la lansare feature, evenimente marketing. Neocloud-urile introduc burst pools: GPU-uri disponibile on-demand la preț premium (2–3× reserved), dar fără angajament. CoreWeave implementează asta prin scheduler-e Kubernetes custom (Kueue + PriorityClass + preemption) care evacă workload-uri best-effort (training, batch) în favoarea burst inference cu SLA de latență.
Pentru un furnizor de hosting, implementarea burst capacity înseamnă:
- Partitionare cluster: noduri reserved (clienti cu contracte anuale) vs. noduri elastic (pool comun)
- Autoscale pe metrici custom:
vllm:request_queue_depth,vllm:gpu_cache_usage_percent, nu pe CPU/RAM - Prețare transparentă: $/GPU-ora reserved vs. $/GPU-ora burst, cu burst credits cumpărate în avans
Această abordare transformă capacitatea inutilizată (în medie 30–40% la furnizorii tradiționali) în venit marginal, oferind clienților flexibilitatea de a plăti doar pentru performanța de vârf când au nevoie. Platforme precum https://www.serverspan.ro/ exploră deja modele hybride care combină colocation propriu cu burst în cloud partener.
–
Pași practici pentru furnizorii de infrastructură AI
- Auditează topologia NVLink/NVSwitch la fiecare raft nou — validează cu
nvidia-smi nvlink -sșinccl-tests(all-reduce bandwidth > 85% teoretic). - Configurează RoCE v2 end-to-end: PFC pe priority 3, ECN pe switch-uri și NIC-uri (Mellanox ConnectX-7), verifică cu
ibv_rc_pingponglatența sub-2 μs hop-to-hop. - Dimensionare putere pentru crest factor 2×: PDU-uri monitorizate per port, alerte la 80%, headroom UPS 25% peste pic maxim simultan.
- Deploy NVMe-oF pentru KV cache: target-uri PCIe 5.0 U.3, inițiatori cu
nvme-cli+nvmet, latență p99 < 200 μs validată cufio --ioengine=io_uring. - Implementează burst scheduler: Kueue + PriorityClass
burst-inference(preemption allowed) vs.batch-training(preemptible), metrics exporter pentruvllmqueue depth. - Monitorizează tail latency, nu media: dashboards p50/p95/p99 per model, per client, cu alerte pe p99 > SLA threshold.
–
Concluzie
Cablarea și alimentarea GPU-urilor nu sunt detalii de implementare — sunt leverele prin care un furnizor de infrastructură transformă hardware commoditizat în serviciu diferențiat. CoreWeave demonstrează că ordinea de mărime de latență vine din disciplină la stratul fizic: topologie NVLink validată, fabric RoCE v2 tunat, putere dimensionată pentru spike-uri reale, storage NVMe-oF pentru KV cache, și scheduler-e care onorează SLA-uri de burst. Pentru hosting providers și echipe DevOps românești, mesajul e clar: investiți în telemetrie granuloasă la nivel de rack, automatizați validarea topologiei la deploy, și pachetați capacitatea elastică ca produs, nu ca excepție. Clienții care rulează inferență în producție plătesc pentru predictibilitate — și predictibilitatea se construiește la nivel de cuplu de fir și bară de distribuție.
–
