Co je MRC a proč ho superpočítače potřebují

Trénink současných velkých jazykových modelů (LLM) jako GPT-5.5 nebo Codex vyžaduje synchronizaci desítek až stovek tisíc grafických procesorů (GPU). V každém kroku výpočtu si tisíce čipů musí vyměnit gigabajty dat. Pokud jediný přenos zpomalí nebo selže, celý tréninkový běh čeká na nejpomalejší článek řetězce. Při provozu v měřítku 100 000 GPU a více se pak drobné síťové výpadky stávají každodenní realitou, která může stát miliony dolarů v promarněném výpočetním čase.

Protokol MRC (Multipath Reliable Connection), představený v odborném článku na arXiv v květnu 2026, na tento problém odpovídá třemi klíčovými inovacemi: packet spraying (rozprašování packetů), adaptivní load balancing podle zahlcení a statické zdrojové směrování SRv6, které umožňuje obejít poruchy bez zásahu člověka.

Jak MRC funguje v praxi

MRC staví na rozšíření protokolu RoCEv2 (RDMA over Converged Ethernet), který se standardně používá pro rychlou komunikaci mezi servery v datových centrech. Na rozdíl od tradičního RoCE, kde jeden datový tok putuje jedinou cestou, MRC každý Queue Pair (QP) — základní spojení mezi dvěma GPU — rozprostře přes 128 až 256 různých cest současně.

Každý odeslaný packet nese tzv. entropy value (EV), což je 32bitové číslo, které určuje, kudy paket projde sítí. Přijímací síťová karta (NIC) pak zapisuje data do paměti okamžitě po příjmu, bez ohledu na pořadí, v jakém packety dorazí. Díky tomu nedochází k tzv. head-of-line blocking, kdy jeden opožděný packet zablokuje všechny ostatní.

MRC zároveň vypíná mechanismus Priority Flow Control (PFC), který v klasických lossless sítích často způsobuje zahlcení mezi různými tréninkovými úlohami. Místo toho pracuje v běžném „best-effort“ režimu Ethernetu a ztráty packetů řeší selektivní retransmisí (SACK) a tzv. packet trimming. Při trimmingu switch místo zahození celého packetu odřízne jeho obsah a prioritně pošle „prázdnou“ hlavičku k cíli, což okamžitě spustí rychlé opětovné odeslání.

SRv6: statické směrování jako základ odolnosti

Pro sítě o desítkách tisíc uzlů by dynamické směrovací protokoly jako BGP byly příliš pomalé a složité na správu. Autoři MRC proto zvolili zdánlivě paradoxní řešení: vypnout dynamické směrování úplně. Místo toho každý packet nese ve své IPv6 adrese přesný seznam switchů, kterými má projít — tzv. SRv6 micro-segment (uSID) formát. Každý switch pak pouze posune segment v adrese a podle statické tabulky rozhodne, kterým portem packet poslat dál.

Tento přístup má dva klíčové výhody: za prvé MRC přesně ví, kudy packet šel, a když ztratí packet, okamžitě ví, která cesta je vadná. Za druhé odpadá závislost na řídicí rovině switchů — i když switch přestane správně fungovat, ale zůstane „nahoře“, MRC jednoduše přestane danou cestu používat, aniž by musel čekat, až si toho routingový protokol všimne.

Multi-plane topologie: více cest = nižší náklady

MRC byl navržen společně s novou topologií sítě. Místo konvenční třívrstvé architektury Clos, kde 100 000 GPU vyžaduje čtyři úrovně switchů, MRC využívá multi-plane návrh. Například 800Gb/s síťovou kartu lze rozdělit na osm nezávislých 100Gb/s portů a postavit osm paralelních dvouvrstvých sítí. Každý switch pak má 512 portů místo 64, což umožňuje obsloužit 131 072 GPU pouze ve dvou úrovních.

V praxi to znamená:

• Nižší latenci — nejdelší cesta prochází jen třemi switchy místo pěti nebo sedmi.
• Nižší náklady a spotřebu — pro plnou bisekční šířku potřebuje o 33 % méně optických transceiverů a o 40 % méně switchů než tradiční třívrstvá síť.
• Vyšší odolnost — ztráta jednoho 100Gb/s odkazu sníží kapacitu uzlu jen o 0,4 %, zatímco u 800Gb/s single-plane by to bylo 3 %.

Výsledky z produkčního provozu

Podle výzkumné zprávy běží MRC v současnosti v několika masivních trénovacích clusterech OpenAI a Microsoftu a byl použit k trénování nejnovějších frontier modelů pro ChatGPT a Codex. Autoři uvádějí konkrétní data z provozu:

• V clusteru s 75 000 GPU docházelo během tréninku k průměrně několika link flapům za minutu mezi switchy první a druhé úrovně. Dříve by tyto výpadky mohly trénink přerušit; s MRC na ně operátoři prakticky nemusí reagovat.
• Při výpadku optického transceiveru na T0 switchi, který způsobil blikání čtyř odkazů najednou, trpěl výkon synchronního tréninku asi minutu poklesem o 25 %, ale úloha nezhavarovala a plně se zotavila bez lidského zásahu.
• Při experimentálním selhání T1 switchu během 75K GPU tréninku bylo dropnuto přibližně 580 000 packetů, ale propustnost úlohy se rychle stabilizovala, protože MRC postižené cesty okamžitě vyřadil.

V testovacím prostředí MRC na NICích NVIDIA ConnectX-8 dosáhl latence 5,09 μs pro komunikaci v rámci jednoho racku a 6,54 μs při přechodu mezi úrovněmi switchů. Přenosová rychlost při zprávách 32 kB dosáhla 770 Gb/s, což odpovídá 96 % teoretického maxima 800Gb/s linky. V kolektivních operacích NCCL při škále 42 000 GPU MRC dosáhl až 92 GB/s na síťovou kartu.

Otevřená spolupráce napříč průmyslem

Jedním z pozoruhodných aspektů projektu je šíře průmyslové spolupráce. MRC byl implementován nejen v NVIDIA ConnectX-8, ale také v AMD Pollara a Vulcano a v Broadcom Thor Ultra. Podpora SRv6 byla přidána do switchů NVIDIA Spectrum-4 a 5 (Cumulus, SONiC), Broadcom Tomahawk 5 a společně s Aristou i do EOS.

Autoři zveřejnili specifikaci MRC pod otevřenou licencí prostřednictvím Open Compute Project (OCP). To znamená, že technologie není uzamčena v ekosystému jediného výrobce a mohou ji adoptovat i další provozovatelé cloudových center nebo výzkumné instituce.

Co to znamená pro české firmy a Evropu

Pro české uživatele a firmy nemá MRC přímý dopad na každodenní používání ChatGPT, ale ovlivňuje pozadí, v němž služba funguje. Nižší náklady na provoz superpočítačů mohou v dlouhodobém horizontu přispět k dostupnějším cenám API nebo předplatného. Pro české výzkumné instituce a univerzity, které budují vlastní výpočetní clustery pro AI, je otevřená specifikace MRC zajímavou alternativou k proprietárním řešením.

Evropský kontext je důležitý i z hlediska energetické náročnosti. Trénování největších modelů spotřebuje obrovské množství elektřiny. Snížení počtu switchů a optických modulů o desítky procent přímo znamená nižší spotřebu datového centra. V době, kdy EU zpřísňuje požadavky na udržitelnost digitální infrastruktury, jde o relevantní technický krok vpřed.

Zároveň stojí za zmínku, že Microsoft — jeden z klíčových partnerů MRC — provozuje několik cloudových regionů v Evropě včetně západní Evropy. Optimalizace jejich trénovací infrastruktury se tak může projevit i v kapacitách dostupných evropským zákazníkům služeb Azure OpenAI Service.

Závěr

MRC není produkt, který by si běžný uživatel mohl stáhnout, ale je to přesně ten druh infrastrukturní inovace, která umožňuje současné tempo vývoje generativní AI. Zatímco veřejnost sleduje nové modely a funkce ChatGPT, v datových centrech OpenAI a Microsoftu pracuje protokol, který tichoučko směruje biliony packetů za sekundu přes stovky tisíc GPU. Že dokáže přežít selhání switchů, blikající kabely a přetížené linky bez zásahu člověka, je technický úspěch, na kterém stojí každá další aktualizace umělé inteligence.