Když se mluví o trénování špičkových AI modelů, většina pozornosti míří na čipy, počet GPU a velikost datacenter. To je pochopitelné. Jenže samotné přidání dalších GPU problém neřeší. Ve skutečnosti se tím často otevře úplně nový: jak přimět obrovské množství akcelerátorů, aby pracovaly jako jeden celek, bez zbytečných prostojů, výpadků a síťových zácp.
Právě tady se ukazuje, proč dnešní AI potřebuje jiný typ síťové architektury, než jaký dlouhé roky stačil pro běžný internet nebo klasická cloudová datacentra. OpenAI v této oblasti představilo přístup nazvaný Multipath Reliable Connection, zkráceně MRC. Jde o síťový protokol navržený pro superpočítače určené k trénování velkých modelů, kde tisíce až statisíce GPU musí komunikovat synchronně a spolehlivě.
Na první pohled to může znít jako okrajová infrastrukturní záležitost. Není. Ve výsledku jde o to, jak rychle a spolehlivě lze vyvíjet lepší modely, jak efektivně se využije drahý hardware a kolik výkonu se neztratí jen proto, že jedna část systému na chvíli zadrhne.
Mark Handley z týmu Core Networking a Greg Steinbrecher z Workload Systems popsali, proč klasické síťové principy v éře AI přestávají stačit, jak MRC funguje a proč se OpenAI rozhodlo otevřít tento standard i ostatním. A čím víc jsem se do toho tématu nořil, tím jasnější bylo, že budoucnost AI nebude stát jen na lepších modelech, ale i na lepších sítích.
Obsah
- 🧠 Proč nestačí jen přidat víc GPU
- 🏗️ Jak AI změnila způsob, jakým se staví datacentra
- 🌐 Proč klasické síťové protokoly pro AI nestačí
- ⚠️ Když jedna malá chyba zastaví obrovský stroj
- 🛠️ Co je Multipath Reliable Connection a proč je důležité
- 🔁 Síť, která se sama vyhne poruše
- 📡 Proč jednodušší síť může být lepší síť
- 📈 Co to znamená pro rychlost vývoje AI modelů
- 🤝 Proč OpenAI otevírá MRC celému odvětví
- ⚙️ Jak MRC stojí na Ethernetu a proč je to zásadní
- 🔬 Proč multimodální modely tlačí síť ještě víc
- 💡 Co je na tom všem možná nejdůležitější
- 🚀 A co dál? Limity, škálování a trochu sci-fi
- 📌 Shrnutí: proč nový síťový přístup může změnit tempo AI
🧠 Proč nestačí jen přidat víc GPU
V tradičním pohledu na výkon počítačových systémů se nabízí jednoduchá úvaha: když je jedna GPU dobrá, tisíc GPU bude tisíckrát lepších. Jenže trénování moderních AI modelů takto nefunguje.
Při výuce velkého modelu se práce rozděluje mezi mnoho GPU, které zpracovávají části výpočtu paralelně. To je důvod, proč se dnes daří stavět stále schopnější systémy. Jenže tato paralelizace má háček. Všechny tyto akcelerátory se musí průběžně domlouvat na výsledku jednotlivých kroků. Jinými slovy, komunikace mezi GPU není vedlejší provoz. Je přímo součástí výpočtu.
Pokud se jeden z těchto prvků opozdí, čekají na něj ostatní. Když jedna GPU zpomalí, celá synchronizovaná skupina se zadrhne. Když dojde k chybě, může být nutné zastavit krok, vrátit se zpět nebo znovu synchronizovat stav. Po tu dobu výpočetní hardware neprovádí užitečnou práci.
To je zásadní rozdíl oproti klasickému internetu nebo běžným cloudovým službám. Tam mnoho uživatelů vede mnoho oddělených komunikací. Když je některá z nich pomalejší, zbytek systému to často skoro nepocítí. V trénování AI ale všichni dělají jednu obrovskou společnou úlohu. A to mění pravidla hry.
Mark Handley to popisuje velmi přesně: jde o jeden z nejnáročnějších typů zátěže, jaký lze na síť vůbec položit. Síť není jen dopravní infrastruktura. Stává se součástí samotného superpočítače.
🏗️ Jak AI změnila způsob, jakým se staví datacentra
Po dlouhá léta byla velká datacentra navrhována hlavně pro webovou éru. Cílem bylo vytvořit jakýsi oceán výpočetního výkonu, ze kterého si různé služby ukrojí to, co potřebují. Infrastrukturní tým mohl být relativně oddělený od týmů, které na této infrastruktuře provozovaly aplikace.
AI tenhle model obrátila naruby.
Greg Steinbrecher vysvětluje, že v OpenAI se ukázalo, jak zásadní je společný návrh modelů a systémů. Nestačí mít jednu skupinu, která “dodá hardware”, a druhou, která “na něm něco natrénuje”. Trénování frontier modelů je dnes tak těsně spjaté s vlastnostmi sítě, serverů, restartů, chyb a plánování úloh, že bez této spolupráce by škálování naráželo na stále bolestivější limity.
Je to vlastně logické. Když trénovací běh stojí obrovské peníze, spotřebuje obrovské množství energie a běží na špičkovém hardwaru, každá sekunda nečinnosti bolí. Každé zaváhání sítě se propisuje do rychlosti vývoje nových modelů. A každá nevyužitá GPU znamená promarněný výkon.
To je důvod, proč dnes infrastruktura není “něco pod kapotou”, ale strategická součást výzkumu. Lidé, kteří se starají o síť a provoz klastrů, sedí v těsném kontaktu s výzkumníky. Řeší, jak konkrétní pracovní zátěže sedí na konkrétní generaci serverů, co se děje při výpadku a jak odstranit úzká hrdla dřív, než se z nich stane zásadní problém.
🌐 Proč klasické síťové protokoly pro AI nestačí
Pro pochopení problému je užitečné vrátit se o krok zpět. Internet i mnoho datacentrových sítí vyrostly z předpokladu, že síť obsluhuje mnoho nezávislých konverzací. Někdo posílá e-mail, jiný streamuje video, další načítá web. Provoz je rozptýlený a ve velkém množství toků se špičky a propady často statisticky vyrovnají.
Jenže při trénování AI nejde o mnoho nezávislých komunikací. Jde o jednu obrovskou synchronizovanou komunikaci přes velké množství GPU. Pokud data mezi nimi netečou hladce, výpočet se zpomalí nebo zastaví.
Další komplikace je fyzická topologie datacenter. Takový AI superpočítač nelze postavit na jednom přepínači. Ani na jednoduché stromové hierarchii. Potřebujete hierarchie hierarchií přepínačů, tedy velmi rozsáhlou síť s tisíci přepínačů a miliony optických spojů.
Mezi jednou GPU a druhou pak existují tisíce možných cest. To zní jako výhoda. A někdy je. Jenže pokud necháte provoz náhodně rozptýlit, může se stát, že více přenosů skončí na stejné trase a vytvoří úzké hrdlo. Když se to stane v běžném síťovém provozu, systém si s tím často poradí. V synchronním trénování AI je ale důležitá úplně jiná metrika.
Nejde o průměr. Jde o nejhorší případ.
Greg mluví o tom, že při těchto zátěžích se neřeší, jak rychle komunikuje průměrná dvojice GPU. Rozhodující je, který jediný síťový link se stal největším úzkým hrdlem. Právě ten totiž určí tempo celé skupiny. Všechny prvky postupují v lockstep režimu, tedy v pevném rytmu. A jeden zadrhnutý článek zpomalí všechno.
To je svět takzvaných “tail metrics”, extrémně nepříjemných odchylek na konci rozdělení. Nezáleží na tom, že většina sítě běží krásně. Pokud je někde jedno velmi špatné místo, pocítí ho celý trénovací běh.
⚠️ Když jedna malá chyba zastaví obrovský stroj
Ve velkém AI clusteru nejsou poruchy výjimkou. Jsou normální součástí života systému.
To je možná jedna z nejdůležitějších myšlenek celé debaty. Jakmile stavíte infrastrukturu v opravdu masivním měřítku, musíte počítat s tím, že něco se kazí pořád. Ne jednou za čas. Prakticky neustále.
Matematika je neúprosná. Když zdvojnásobíte velikost systému a poruchy jednotlivých prvků jsou přibližně nezávislé, průměrný čas mezi poruchami systému se zkrátí zhruba na polovinu. A v síti je komponent výrazně víc než samotných GPU.
Už jen připojení jednoho akcelerátoru znamená síťový adaptér, optické transceivery, lasery na obou stranách, první přepínač a další vrstvy sítě za ním. Když se vše sečte přes více úrovní přepínačů, dostanete o několik řádů více síťových komponent, než kolik je GPU na okraji celé soustavy.
Mark Handley upozorňuje, že v jednom takovém objektu mohou být doslova miliony optických spojů. V tom okamžiku přestává dávat smysl uvažovat stylem “snad se nic nepokazí”. Místo toho je nutné navrhovat síť tak, aby poruchy absorbovala a běžela dál.
Problém tradičních protokolů je v tom, že při výpadku linky nebo zmatku v přepínači musí síť nejdřív zjistit, co se stalo, předat informaci dál a přepočítat cesty. To zabere čas. Někdy sekundy, někdy v krajních případech i desítky sekund. Pro AI training je to věčnost.
Během takového “čekání na stabilizaci” jsou GPU nečinné. A to je přesně ten druh ztrát, který si při velkých trénovacích bězích nikdo nemůže dovolit ignorovat.
🛠️ Co je Multipath Reliable Connection a proč je důležité
Multipath Reliable Connection, zkráceně MRC, je odpověď na tuto kombinaci problémů: extrémní synchronizaci, mnoho možných cest v síti, citlivost na nejhorší případy a neustálé drobné poruchy.
Základní myšlenka má dvě hlavní části:
- Rozkládat provoz přes více cest současně, aby se síť lépe vyvažovala a nevznikala horká místa.
- Odstranit nejasnost při ztrátě nebo přeskupení paketů, aby systém rychle poznal, co opravdu chybí a co se jen opozdilo.
To zní technicky, ale princip je překvapivě srozumitelný.
Když rozprostřete pakety přes více tras, máte větší šanci využít kapacitu sítě rovnoměrně. Jenže pakety pak mohou dorazit v jiném pořadí, protože různé cesty mají různé zpoždění. Pokud navíc někde vznikne zácpa, klasická síť by některé pakety prostě zahodila. Příjemce pak neví, jestli má ještě čekat, nebo zda se paket skutečně ztratil.
MRC to řeší technikou, kterou Mark popisuje jako packet trimming. Když by kvůli přetížení hrozilo zahazování paketů, síť nevyhodí celý paket. Místo toho odřízne jeho datovou část a pošle dál alespoň malou hlavičku. Příjemce tak okamžitě ví, že tento paket nelze považovat za “jen zpožděný”. Ví, že má rovnou požádat o opětovné odeslání.
Tím se odstraní nejistota, která by jinak vznikla mezi ztrátou a pouhým přeskupením paketů. A právě tato jistota je pro synchronní AI workload zásadní.
Výsledek? Lepší rozložení provozu, méně bolestivé zácpy a rychlejší zotavení při problémech.
🔁 Síť, která se sama vyhne poruše
Jedna z nejpůsobivějších vlastností MRC je schopnost obejít poruchu bez toho, aby se kvůli tomu musela dlouze “domlouvat” celá síť.
V tradičním modelu výpadek linky spustí proces šíření informace přes směrovací protokoly. Každý prvek sítě postupně oznamuje svým sousedům, že určitou cestou už nelze provoz vést. Teprve až se tato informace rozšíří a síť konverguje na nové mapě cest, začne opět plynule fungovat.
MRC tento problém výrazně zjednodušuje. Každý endpoint dokáže velmi rychle poznat, že určitá cesta nefunguje nebo není výhodná, a prostě ji přestane používat. Není potřeba čekat na centrální autoritu ani na globální konvergenci. Reakce probíhá lokálně a v řádu milisekund.
Greg Steinbrecher to popisuje skoro až s úlevou. Dříve mohl výpadek znamenat, že celý běh na pár sekund stojí, než se síť “srovná”. S MRC endpointy samy rychle přestanou problémovou trasu používat a pokračují po jiných cestách. Pro trénovací běh je dopad malý a krátký.
“Víme, že jsme vyhráli, když výzkumníci přestanou potřebovat vědět, jaký síťový protokol tenhle cluster používá.”
To je mimochodem skvělá definice dobré infrastruktury. Když funguje, přestane být tématem.
Mark Handley jde ještě dál. Jakmile MRC spolehlivě obchází poruchy samo, ztrácí velký význam i část dynamiky uvnitř samotných přepínačů. OpenAI proto na největších škálách využívá statické směrování a vypíná tradiční routing protokoly. Přepínače tak mají při startu nastavenou konfiguraci a pak už své tabulky v zásadě nemění.
To je odvážný krok, ale dává smysl. Pokud umí inteligence sedět na okraji sítě a adaptivně vybírat funkční cesty, může být střed sítě mnohem jednodušší. A jednoduchost je ve velkém měřítku obrovská výhoda.
📡 Proč jednodušší síť může být lepší síť
Jedna z nejzajímavějších částí celého přístupu spočívá v přesunu složitosti. Místo aby byla síť uvnitř plná dynamiky, rozhodování a rekonfigurací, MRC posouvá inteligenci k okrajům. Samotné přepínače mohou být “hloupější”, a tím i předvídatelnější.
Mark zmiňuje využití technologie IPv6 Segment Routing, která umožňuje, aby každý paket nesl informaci o přesné sadě přepínačů, přes které má projít. To znamená, že cesta není složitě dopočítávána uvnitř sítě při každém kroku. Paket ji v podstatě zná předem.
Tím se střed sítě zjednoduší. A ve světě hyperscale infrastruktury to není drobnost. Složitý střed je těžší spravovat, hůře se ladí, častěji se porouchá a hůře se rozšiřuje. Jednodušší střed je robustnější.
Další výhoda se týká samotné fyzické architektury datacenter. Greg upozorňuje, že díky schopnosti MRC dobře pracovat s více cestami lze stavět plošší a menší sítě, s menším počtem vrstev přepínačů. To má několik praktických dopadů:
- nižší spotřebu energie,
- nižší cenu,
- méně zařízení, která se mohou pokazit,
- větší podíl energie, který jde skutečně do GPU a ne do síťové režie.
Ve světě, kde se řeší každá kilowatthodina a každé procento efektivity, je to mimořádně důležitá vlastnost. MRC tedy není jen o spolehlivosti. Je i o lepší ekonomice a energetické efektivitě superpočítačů pro AI.
📈 Co to znamená pro rychlost vývoje AI modelů
Když se bavíme o síťovém protokolu, je snadné ztratit ze zřetele, proč na tom vůbec záleží mimo úzký svět infrastruktury. Greg to formuloval naprosto jasně: hlavní dopad je ten, že díky tomu mohou přicházet lepší a inteligentnější modely rychleji.
Není to reklamní slogan. Je to přímý důsledek toho, jak funguje trénovací pipeline.
Pokud je síť stabilnější, úlohy méně padají. Pokud je výkon předvídatelnější, výzkumníci nemusí řešit, jestli jejich běh dopadl hůř jen proto, že sdíleli rack s jinou náročnou úlohou. Pokud výpadky linků neznamenají sekundy prostojů, GPU tráví více času skutečným výpočtem. A pokud se tím zrychlí celý iterativní výzkumný cyklus, organizace může rychleji testovat, vyhodnocovat a vylepšovat modely.
To je důležitý bod i v širší debatě o tom, proč nové modely nevznikají jako rutinní “softwarový update”. Každý velký model je výzkumný projekt. Má své nejistoty, experimenty, slepé uličky i technická omezení. Spolehlivější infrastruktura sice sama o sobě nevymyslí lepší architekturu modelu, ale dramaticky zvyšuje šanci, že výzkumný tým může postupovat rychleji a s menším třením.
Když síť přestane být častým zdrojem bolesti, uvolní se kapacita na řešení dalších problémů. A těch je v AI pořád víc než dost.
🤝 Proč OpenAI otevírá MRC celému odvětví
Jedna z nejzajímavějších strategických částí celého oznámení je, že OpenAI nechce MRC držet jako uzavřenou výhodu jen pro sebe. Specifikace má vyjít jako otevřený standard přes Open Compute Project.
Na vývoji se navíc podíleli významní partneři včetně Microsoftu, Nvidie, AMD, Broadcomu a Intelu. To samo o sobě ukazuje, že nejde o malou interní optimalizaci, ale o pokus posunout celý průmysl.
Důvodů je několik.
1. Otevřené standardy zrychlují inovaci
Ethernet uspěl právě proto, že se stal otevřeným standardem, na kterém se shodl celý ekosystém. Díky tomu mohl síťový průmysl desítky let iterovat jedním směrem. OpenAI chce, aby se něco podobného stalo i na vyšší vrstvě, která řeší specifické potřeby AI superpočítačů.
2. Rozdrobený dodavatelský řetězec by škodil všem
Greg mluví otevřeně o tom, že by byla škoda, kdyby se výrobci a provozovatelé vydali každý svou proprietární cestou kvůli malé individuální výhodě. Při současném tempu AI buildoutu je infrastruktura v podstatě sdílený osud celého odvětví. Když se ekosystém sjednotí, může růst rychleji.
3. Těžké problémy není nutné řešit desetkrát zvlášť
Mark Handley to shrnuje jednoduše: to, co se tu řeší, je už tak dost obtížné. Není důvod, aby každý hráč znovu vynalézal kolo. Pokud se průmysl shodne na dobrém směru, všichni mohou těžit z vyšší rychlosti vývoje a lepší kompatibility.
Tohle je mimochodem velmi střízlivý a praktický přístup. V AI se často mluví hlavně o modelech, produktech a benchmarkech. Ale bez sdílených základních stavebních kamenů by vývoj infrastruktury mohl začít narážet na zbytečné tření. A to by ve výsledku zpomalilo každého.
⚙️ Jak MRC stojí na Ethernetu a proč je to zásadní
Důležitou vlastností MRC je, že nevzniká mimo hlavní proud síťového světa. Nestaví paralelní vesmír. Naopak, staví na Ethernetu.
To je velmi důležité z technického i strategického hlediska.
Ethernet je dnes výsledkem desítek let evoluce. Není to stejné Ethernetové prostředí jako před deseti, dvaceti nebo čtyřiceti lety. Je rychlejší, robustnější a mnohem schopnější. Díky tomu může MRC využívat vše, co globální síťový průmysl už vybudoval.
Mark i Greg zdůrazňují, že pokud bude Ethernet dál škálovat, může s ním škálovat i MRC. To znamená, že nejde o slepou uličku vázanou na jeden konkrétní typ hardwaru nebo jednu generaci superpočítače. Jde o flexibilní základ, který by měl nést i další generace AI systémů.
Samozřejmě to neznamená, že práce končí. V sítích je vždy co zlepšovat. Přenosové rychlosti porostou, poměr mezi latencí a objemem dat se bude měnit a systémy budou klást stále nové nároky na fair sharing, congestion control i tail latency. Ale právě otevřenost a návaznost na Ethernet dávají MRC šanci stát se dlouhodobě životaschopným základem.
Pokud vás zajímá širší kontext vývoje Ethernetu, dobrý přehled nabízí například IEEE 802.3 Ethernet Working Group.
🔬 Proč multimodální modely tlačí síť ještě víc
Když se dnes mluví o AI, už dávno nejde jen o text. Modely pracují s obrazem, zvukem, videem a různými kombinacemi těchto modalit. Přesné detaily architektur Greg nerozebírá, ale zdůrazňuje jednu podstatnou věc: čím schopnější a pokročilejší modely jsou, tím tvrdší nároky kladou na zbytek systému.
To se projevuje dvěma způsoby:
- roste objem dat, která se musí mezi GPU přesouvat,
- zmenšuje se tolerance na zpoždění, protože ostatní části stacku jsou stále lépe optimalizované.
To druhé je zvlášť zajímavé. Když výzkumné a systémové týmy vylepší výpočty na GPU, síť tím paradoxně dostane ještě větší tlak. Pokud jsou výpočty rychlejší, čekání na síť je relativně dražší. Síť se tak snadno stane dalším úzkým hrdlem.
Právě proto Greg mluví o nutnosti vertikální integrace. Lidé, kteří rozumějí workloadům, musí chápat aspoň část síťových omezení. A síťaři musí mít povědomí o tom, co přesně se děje na úrovni modelového trénování. Bez této koordinace není možné posouvat hranice škálování tak rychle, jak si dnešní AI závod žádá.
💡 Co je na tom všem možná nejdůležitější
Na celé věci mě zaujala jedna jednoduchá, ale silná myšlenka: v moderní AI už nestačí optimalizovat izolované části systému. Nestačí mít nejlepší model, nejlepší GPU nebo nejlepší software scheduler. Rozhodující je, jak dobře celý ten obrovský stroj funguje jako jeden organismus.
MRC je hezký příklad tohoto uvažování. Neřeší jen “rychlejší přenos paketů”. Řeší konkrétní systémový problém, který se objeví teprve tehdy, když se pokusíte provozovat AI v opravdu velkém měřítku:
- tisíce až statisíce GPU,
- synchronní workload,
- citlivost na nejhorší případ,
- stále přítomné poruchy,
- obrovské energetické i finanční náklady každé minuty běhu.
To je přesně ten druh problému, který nebývá na první pohled vidět, ale ve výsledku rozhoduje o tom, kdo bude schopný škálovat dál a kdo začne narážet na strop.
🚀 A co dál? Limity, škálování a trochu sci-fi
Kde jsou hranice tohoto přístupu? Podle Grega je MRC navrženo tak, aby zůstalo flexibilní a rostlo spolu s Ethernetem. To neznamená, že neexistují fyzikální limity. Existují a jeden z nejdůležitějších je velmi známý: rychlost světla.
V určitém bodě nelze data přesouvat rychleji, než dovolí fyzika. To má přímé důsledky pro rozmístění výpočetních systémů. Když se občas objeví nápad přesunout velké AI trénování do vesmíru, zní to futuristicky, ale v praxi by to narazilo právě na latenci, poruchovost a servisovatelnost.
Mark Handley je v tomto směru velmi přímočarý. Představa trénování podobného tomu, které probíhá v moderních pozemských AI superpočítačích, je ve vesmíru těžko představitelná. Nejen kvůli zpoždění, ale i kvůli tomu, že takové systémy dnes potřebují průběžné zásahy techniků. A opravovat síťovou infrastrukturu na orbitě není zrovna běžný provozní model.
Greg připouští, že snová část jeho osobnosti považuje takovou představu za fascinující. Praktická část ale říká, že už na Zemi je tohle všechno nesmírně těžké. A to zní jako rozumný závěr.
Jinými slovy, pokud chceme v blízké budoucnosti více AI výkonu, cesta povede spíš přes více a lepší pozemská výpočetní centra, ne přes kosmická datacentra.
📌 Shrnutí: proč nový síťový přístup může změnit tempo AI
Když to celé zjednoduším, MRC řeší velmi konkrétní bolest moderní AI infrastruktury: jak udržet obrovské množství GPU v synchronizovaném pohybu, i když je síť složitá, poruchy jsou běžné a klasické protokoly reagují příliš pomalu.
Jeho přínos se dá shrnout do několika bodů:
- lepší využití více síťových cest bez chaotických hotspotů,
- rychlejší reakce na přetížení a ztrátu paketů,
- lokální obcházení poruch bez dlouhé globální konvergence,
- jednodušší a plošší síťová architektura,
- nižší spotřeba a cena při vysokém výkonu,
- stabilnější trénovací běhy, které méně zatěžují výzkumné týmy,
- rychlejší iterace při vývoji nových modelů.
Na tom je krásně vidět, že budování AI není jen o algoritmech. Je to i o optice, přepínačích, routingu, latenci, chybových stavech a o tom, jak přesunout složitost tam, kde ji systém zvládne nejlépe.
Možná právě to je nejpřesnější obraz současné AI éry. Nejde už jen o chytřejší software. Jde o to, aby celý stack, od výzkumu po síťové pakety, táhl jedním směrem.
A když se to povede, výsledek není jen elegantnější infrastruktura. Jsou to rychlejší a spolehlivější cesty k modelům, které budou umět víc.
