Model nestačí, když pipeline brzdí koordinace

Při 600 TB multimodálních dat nerozhoduje jen model, ale celá infrastruktura. Benchmark Anyscale a CoreWeave ukazuje, jak orchestrace, storage a GPU dohromady zkrátily titulkování na 95 minut.

---

Článek vychází z textu týmů Anyscale a CoreWeave: Video Captioning at scale: 600 TB in 95 minutes with Anyscale on CoreWeave (CoreWeave Blog)

Máte model i GPU rozpočet, ale pipeline na video a audio se zasekne dřív než inference. Benchmark Anyscale a CoreWeave ukazuje, že při 600 TB dat rozhoduje infrastruktura, ne jen model. Zprovoznění pod 24 hodin i titulkování za 95 minut bereme jako praxi, ne výjimku.

Kontext: titulkování videí jako infrastruktura, ne jen model

U multimodálních dat v internetovém měřítku už nejde o CPU úlohu. Video, audio, LiDAR i satelitní vstupy se musí dekódovat, filtrovat, zpracovat a normalizovat, což v tomto objemu naráží hlavně na provoz celého prostředí.

Právě na tom je vidět, proč samotný model nestačí. Anyscale a CoreWeave v tomto nasazení postavily pipeline pro titulkování videí napříč miliony klipů a chtěly ověřit, jak rychle se dá dostat od registrace účtu k produkční úloze.

Z dat vyplývá, že cílem nebylo jen spustit jeden běh, ale prověřit, zda lze takovou infrastrukturu uvést do chodu bez obvyklého týdny či měsíce dlouhého čekání na první výsledek. V hlavním běhu pak systém pracoval na 1 600 GPU, s rezervací 200 uzlů.

To pro nás znamená jednoduché pravidlo: u podobných úloh rozhoduje stejně výkon modelu jako schopnost udržet zpracovatelské prostředí stabilní a připravené k nasazení.

Dvě vrstvy architektury: orchestrace workloadu a provoz clusteru

Anyscale a CoreWeave postavily přístup na rozdělení rolí. Ray OSS a Anyscale řídily vrstvu zátěže: plánovaly úkoly a herce, streamovaly data a podle poptávky škálovaly pracovníky. CoreWeave naopak držel infrastrukturu na Kubernetes běžícím přímo na bare metal uzlech s GPU ovladači, síťovými i úložnými rozhraními a pluginy pro sledování.

Tahle dělba zkracuje cestu do produkce, protože orchestrace neřeší provozní detaily clusteru a infrastruktura nemusí suplovat logiku workloadu. V praxi tím tým oddělil plánování výpočtu od správy prostředí, ve kterém výpočet běží.

Do stejné logiky zapadlo i řízení dostupnosti. CoreWeave Mission Control průběžně vyhodnocoval zdraví uzlů a clusterů, zachytával zpožděné uzly a nezdravé uzly automaticky nahrazoval. Pro provoz to znamenalo méně ručních zásahů při škálování a menší riziko, že se běh zadrhne na vadném uzlu.

Z dat vyplývá, že rychlost nevznikla z jednoho nástroje, ale z propojení obou vrstev. Instalace Anyscale trvala 1 hodinu místo celého čtvrtletí a od registrace účtu po spuštění produkční úlohy to trvalo méně než 24 hodin. CoreWeave zároveň rezervoval dynamický cluster až na 1 600 GPU, takže tým měl cestu od zprovoznění k produkci připravenou bez čekání na infrastrukturu.

Na první validaci tým použil Ray Core s ručně spravovanými herci. Praktický problém byl v tom, že pevný seznam herců se nepřizpůsoboval poptávce. V praxi to znamenalo, že orchestrace držela krok hůř než samotné zpracování.

Do toho vstupovalo i čtení videa přes vzdálené funkce, které dekódovaly klíčové snímky na CPU. Ray Data později převzal řízení jinak: streamoval provádění a škáloval zdroje podle zátěže, takže tým oddělil ingestaci od dekódování přes Parquet manifest.

Validace na 600 GB ukázala první úzké hrdlo

Při testu na 600 GB datech na pevném poolu 256 GPU se objevilo první úzké hrdlo. Podle autorů benchmarku to byl signál, že problém neleží v modelu, ale v tom, jak pipeline drží krok s rostoucím objemem.

Batched inference proto tým zjednodušil na tok read_parquet, flat_map, processor, write_parquet. Tím se důraz přesunul z ruční správy herců na streamovací pipeline, která umí lépe vykrývat proměnlivou poptávku.

Škálování na 600 TB a storage bez úzkého hrdla

Tým rozšířil dataset z 600 GB na 600 TB pomocí pipeline Ray, která generovala 1 000 syntetických variant každého videa přes FFmpeg. Tady už se ukázalo, že škálování neřeší jen výpočet, ale i tok dat mezi vrstvami.

CoreWeave AI Object Storage absorboval zápisy rychlostí 40 GB/s. Z dat vyplývá, že storage se v zápisu nestal brzdou a opakované čtení modelových vah zůstalo díky LOTA mimo úzké hrdlo. Tím vzniklo prostředí pro další měření škálování na GPU-hodinu i průchodnost systému.

Ray Data zpracoval 43 700 klipů a vytvořil 1 milion titulků. Pro provoz to znamenalo, že pipeline držela vysoký průtok i při velkém objemu dat. Zároveň využil 73 % času GPU, který potřeboval Ray Core, a vyprodukoval 3,7x více titulků na GPU-hodinu.

Na stejné úrovni zůstala i efektivita po škálování clusteru z 256 na 1 600 GPU. To je důležité, protože růst výkonu nepřinesl jen větší kapacitu, ale udržel i poměr mezi přidělenými a skutečně využitými GPU. Z dat vyplývá, že odstranění ruční orchestrace a posun ke streamingu omezily zbytečné prodlevy.

Benchmarky propustnosti a efektivity na GPU-hodinu

Celkový výkon vzrostl z 1 273 na 12 666 titulků za sekundu. To ukazuje, že systém nespoléhal jen na jeden výkonný uzel, ale dokázal škálovat průchodnost napříč celým clusterem. Přepisování 600 TB videa skončilo za 95 minut.

Při čtení CoreWeave AI Object Storage servíroval 110 až 120 GB/s napříč přibližně 46 CPU uzly, zatímco dataset čtečky zpracovaly 677 GB MP4 souborů a stream z úložiště dosahoval asi 4,5 GB/s. Na zápisu storage absorboval data bez zjevného úzkého hrdla. Při čtení ani zápisu se tak storage nestal omezením, které by brzdilo GPU.

Načtení 17GB modelu trvalo přibližně dvě sekundy. Podle LOTA bylo načtení 1,88x rychlejší než u objektového úložiště třetí strany. To v praxi zkracovalo čekání mezi jednotlivými kroky pipeline a omezovalo prostoje, které by jinak snižovaly využití GPU.

Co tyto výsledky znamenají pro další kroky

Z těchto benchmarků nám vyplývá hlavně jedna věc: výkon nestojí jen na počtu GPU, ale na tom, zda orchestrace, storage a načítání modelů drží krok s výpočtem. Právě to připravilo půdu pro další závěry o přenositelnosti řešení.

Koordinace stacku jako podmínka výkonu

Na tomto případě vidíme, že při takovém objemu dat nerozhoduje jen model, ale hlavně orchestrace napříč celým stackem. Spravovaný Kubernetes, plánovač a úložiště musely fungovat současně, aby 1 600 GPU zůstalo v plném zatížení. Když se jedna vrstva zpomalí, výkon se nepropadne v modelu, ale v koordinaci.

Pro marketéry a e-commerce týmy z toho plyne jednoduché pravidlo: když výkon kampaní, feedů nebo datových procesů naráží na limity, nehledejme hned chybu v „jádru“ řešení. Často je slabé místo v přenosu dat, správě kapacity nebo v tom, jak jednotlivé vrstvy drží krok.

Jakmile máme backlog ve správě dat měřený v měsících, je pravděpodobné, že problém není v modelech. Provoz pak nebrzdí ambice týmu, ale technická koordinace a její dopad na využití výpočetních zdrojů.

Co si z toho odnášíme pro praxi

Na tomto případu si potvrzujeme, že při multimodálních pipeline ve velkém měřítku nebývá hlavní limit v modelu, ale v tom, zda orchestrace, CPU fáze, storage a health management dokážou udržet GPU bez prostojů. Když se soustředíme jen na výkonnější model nebo více GPU, snadno přehlédneme, že skutečný propad vzniká v přenosu dat, čekání na dekódování nebo v neřízeném škálování.

Pro nás je přenositelné hlavně toto: výkon v produkci neřešíme izolovaně po vrstvách, ale jako tok, který musí držet krok od ingestu až po zápis. Jakmile jedna část zpomalí, throughput se zlomí dřív v koordinaci než v samotném výpočtu. Stejné pravidlo platí i mimo video pipeline — u kampaní, feedů nebo datových procesů je často potřeba nejdřív odhalit úzké hrdlo v provozu, ne v „jádru“ řešení.

FAQ

Je větší GPU cluster automaticky řešení problémů s propustností?
Ne. Bez sladěné orchestrace, rychlého CPU zpracování a dostatečně rychlého storage mohou GPU jen čekat. Více výpočetního výkonu samo o sobě neodstraní provozní úzké hrdlo.

Kde bývá nejčastěji skrytý limit, když model běží dobře v testu, ale ne v produkci?
Nejčastěji v datové cestě: dekódování, načítání vstupů, batchování, síť nebo storage. Test modelu často neodhalí, že zbytek pipeline nestíhá držet krok.

Má smysl řešit optimalizaci CPU vrstvy, když hlavní náklady jsou na GPU?
Ano. Když CPU nestíhá připravovat data, GPU stojí a náklady rostou bez přidané hodnoty. CPU fáze bývá levnější na optimalizaci než další navyšování GPU kapacity.

Co je typická chyba při škálování podobné pipeline?
Předpoklad, že zrychlení přijde samo s větším clusterem. Pokud nejsou sladěné vstupní data, plánování, storage a health management, škáluje se i čekání.

Jak poznáme, že problém není v modelu, ale v koordinaci stacku?
Když GPU není dlouhodobě vytížené, ale model v izolaci funguje dobře. Pak je potřeba profilovat celý tok, ne jen přesnost nebo inference na jednom uzlu.

Zdroj: Video Captioning at scale: 600 TB in 95 minutes with Anyscale on CoreWeave (CoreWeave Blog)

---