Automotive Special Address: Advancing Level 4 Autonomy, the Path to Scalable, Safe AVs and Robotaxis (a proč je rok 2025 zlomový)

Rok 2025 je pro oblast autonomního řízení (AV) zvláštní tím, že se tu potkává několik trendů najednou. Na jedné straně pokračuje zrychlování AI. Na druhé straně se autonomní řízení postupně mění z dlouhodobého výzkumného tématu na reálnou průmyslovou cestu k hromadné výrobě. A do toho přichází velká otázka: jak postavit autonomii tak, aby byla škálovatelná, bezpečná a zároveň udržitelně vyvíjitelná pro stovky situací na silnici.

V tomto článku shrnuji klíčové myšlenky a architektonické kroky, které zazněly v rámci special address zaměřeného na cestu k Level 4 autonomie. Zaměřím se na to, co znamená „physical AI“ v automobilovém průmyslu, proč je důležitá cloud-to-car pipeline, jak funguje platforma NVIDIA DRIVE Hyperion, co je koncept Halos, proč se v modelech objevuje agentic a reasoning AI, a jak do toho zapadá simulace, sběr dat a (neo)opravitelná práce s edge cases.

Obsah

• 🧠 Proč je rok 2025 „momentem“ pro autonomní řízení
• 🚗 Autonomie je „jasnější než dřív“: co to prakticky znamená pro L4
• 🎥 Jak vypadá „reasoning“ v praxi: auto, které vyhodnocuje a vysvětluje
• 🤖 Physical AI: proč jsou autonomní auta prvním masově nasaditelným „agentem“ v reálném světě
• 🏗️ DRIVE Hyperion: třípočítačový pohled na trénink, simulaci a inference
• 🔧 Halos: bezpečnostní základ, který má zlevnit vývoj a zvýšit důvěru v nasazení
• 🖥️ AGX Orin a Blackwell: výkon v autě jako klíč k modelům, ne jen k senzorům
• 📷 Senzory jako společný jazyk: proč je „common sensor suite“ tak důležitý
• 🤝 Hyperion fleet data a spolupráce s Uberem: data jako závod, ale i ekosystém
• 🧪 Mario 1.5: reasoning model, který umí trasy a tax prompts
• 🧰 Od open modelu k produkci: proč je pipeline tréninku a validace stejně důležitá jako model
• 🧊 Simulace a Nurek: pixely, rekonstrukce a uzavřená smyčka testování
• 🧭 Hybridní AV stack: end-to-end pro zážitek, classical pro interpretable safety
• 📈 L2++ teď, L4 potom: roadmapa škálování od adresy k adrese
• 🏁 Vývoj zrychluje: iterace tisíckrát a rychlý turnaround mezi tréninkem a evaluací
• 🤝 Ekosystém: OEM, Tier 1 a spolupráce pro sdílené senzory a data
• 🧠 Co si z toho odnáším: hlavní závěry pro budoucnost škálovatelných, bezpečných AV
• 🔮 Kam to podle mě směřuje: od robotaxi do mainstreamu, ale bezpečně

🧠 Proč je rok 2025 „momentem“ pro autonomní řízení

Podle pohledu z praxe se AV dostává do bodu, který připomíná boom „nové generace“. Důvod je jednoduchý: AI se posouvá směrem k modelům, které nejsou jen pasivním vnímáním okolí, ale umí uvažovat a vytvářet plánování v kontextu. V autonomním autě to znamená něco zásadního: auto musí průběžně vyhodnocovat, co se děje, co se může stát a jak zareagovat, když je situace neočekávaná.

V posledních letech se vývoj AV výrazně proměnil vlivem několika typů modelů:

• Vision-language-action (VLA) přináší schopnost pracovat s vizuálními informacemi a akcemi v jednom „rámci“.
• Foundation modely (například sloužící jako základní „jazyk“ nebo reprezentace) zrychlují vývoj tím, že nemusíte začínat od nuly.
• Reasoning modely jsou důležité pro práci s komplexitou a edge cases. Jde o to, aby systém rozkládal scénáře dřív, než se z nich stanou problémy.

Tady vzniká nový motiv: už nejde jen o to, aby auto „poznalo“ co vidí. Jde o to, aby auto pochopilo, co je podstatné, a zvolilo akci bezpečným způsobem.

🚗 Autonomie je „jasnější než dřív“: co to prakticky znamená pro L4

Level 4 autonomie je často vnímán jako teoretický cíl. V realitě ale lidé chtějí konkrétní odpovědi: kdy se to dá nasadit, jak se ověří bezpečnost, jak se zajistí škálování a co je minimální sada komponent pro robustní chování.

Klíčová myšlenka z prezentované strategie je, že cesta k L4 je v tomto období strukturálně čitelnější než dřív. Nejde jen o jednu technologii, ale o celek:

• lepší modely, které zvládnou „reasoning“ nad složitostí ulic,
• platforma pro běh modelů v autě s dostatečným výkonem a pamětí,
• bezpečnostní vrstvy, které umí držet systém v mezích při neočekávaných událostech,
• cloud infrastruktura pro trénink, simulaci a verifikaci,
• a konečně ekosystém dat a spolupráce OEM partnerů.

Tohle vysvětluje, proč se v oboru cítí zřetelné zrychlení. Vývoj není zpomalený. Naopak, celé průmyslové úsilí se posouvá směrem k plné autonomii rychleji, než tomu bylo dřív.

🎥 Jak vypadá „reasoning“ v praxi: auto, které vyhodnocuje a vysvětluje

Jedna z nejpřesvědčivějších částí sdělení byla ukázka prototypové jízdy v reálném světě. V autě běžel reasoning model a systém průběžně vyhodnocoval okolí. Současně bylo možné se doptat na detaily situace a auto umělo „narrate“ (popisovat nahlas), co pozoruje a proč.

V reálné jízdě se tak objevují typické situace, které v autonomii rozhodují o tom, jestli se auto chová správně:

• měnění jízdního pruhu podle trasy,
• čekání na mezeru v protisměru,
• objevení dvojitě zaparkovaného vozidla v pruhu a plán obejití,
• detekce chodce v přechodu a zpomalování s yield,
• setkání s vozidlem, které kříží dráhu, a bezpečné vyčkání.

Tahle ukázka je důležitá, protože ukazuje jednu zásadní věc: reasoning se nemá projevit až ve „finální krizové akci“. Má běžet v pozadí a připravovat systém na to, co je neočekávané. Jinými slovy: auto se nemá „zjistit, že je problém“ až v momentě problému. Má být připravené ještě předtím.

Záměr je rozkládat edge cases dřív, než se stanou problémy.

🤖 Physical AI: proč jsou autonomní auta prvním masově nasaditelným „agentem“ v reálném světě

V diskusi se hodně zmiňuje pojem physical AI. Pro autonomii je to přirozené: AV není jen aplikace. Je to fyzicky jednající agent v prostředí, které se mění. Bezpečnost proto není „podmínka navíc“. Je to vlastnost, která musí být součástí architektury.

Autonomní vozidlo se dá chápat jako jedna z prvních velkých průmyslových implementací physical AI. A proto se změnilo i zaměření vývoje: nestačí mít skvělé modely. Musíte je dostat do těla systému, do výpočetní platformy, do bezpečnostních vrstev a do procesu vývoje, který se dá opakovat.

V tom je velká „grand mission“: cílem je posunout autonomní kilometry z dnešního minima na úroveň, kdy bude prakticky každé měření „autonomní“. Zazněly i orientační čísla pro velikost příležitosti:

• každý rok se celkem najetí řádově měří na 13 bilionů mil (globálně, napříč kategoriemi vozidel a dopravy),
• dnes je autonomně řízeno jen zhruba 0,006 % z této vzdálenosti.

Ta mezera je obrovská. A právě proto dává smysl budovat platformy, které škálují vývoj a nasazení, místo aby každý OEM dělal znovu to samé od nuly.

🏗️ DRIVE Hyperion: třípočítačový pohled na trénink, simulaci a inference

Když se bavíme o škálování, je potřeba mít jasný model „kde co běží“. V prezentované strategii se zmiňuje, že NVIDIA Drive AV dnes stojí na třech počítačích:

1. Tréninkový počítač (typicky cloud nebo data center), kde se učí modely.
2. Simulační počítač v cloudu, kde se ověřují scénáře a dělá validační práce.
3. Inference počítač v autě, kde model reálně běží v reálném čase.

Na tyto tři vrstvy se pak skládají „služby“ do několika vrstev. Společným cílem je vytvořit platformu, která je pro OEM a vývojáře AV opakovatelná: jednou postavíte základ, a pak už se soustředíte na model a chování.

🔌 5 vrstev služeb nad třemi počítači

Podle popisu se chápání platformy skládá do pěti vrstev:

• Hardware (DRIVE Hyperion jako jednotná referenční architektura pro compute a senzory).
• OS a platform software ve formě Halos.
• Model layer (například Alpamayo, Mario a další modelové komponenty, které se vyvíjí v ekosystému).
• Applications (konkrétní AV funkce, jako L2++, parkování, safety a další).
• Infrastructure (cloud foundation modely a nástroje pro vývoj a validaci modelů).

Tohle rozdělení je důležité, protože problém autonomie není jen „model“. Je to celý produktový systém, který musí být bezpečně nasaditelný, udržitelně vyvíjený a dobře ověřitelný.

🔧 Halos: bezpečnostní základ, který má zlevnit vývoj a zvýšit důvěru v nasazení

Jedním z nejdůležitějších bodů strategie je koncept Halos. Halos jsou popisované jako jednotná software safety foundation pro L4. A nejde jen o „operační systém“. Je to sada vrstev:

• OS vrstva, která je certifikovaná na vysokou úroveň bezpečnosti,
• middleware, která propojuje modely a hardware a zároveň snižuje zátěž OEM vývojářů,
• budoucí bezpečnostní guardrails nad end-to-end modely.

Zaznělo, že DriveOS se postupně stává součástí Halos. Halos OS má poskytovat knihovny a podporu pro efektivní běh AI modelů v autě, a také má podporovat jak Linux, tak QNX.

V praxi se Halos snaží řešit velký problém autonomie: když OEM dělá příliš mnoho „obslužného“ softwaru kolem senzorů a abstrakčních vrstev, potřebuje stovky inženýrů. Pokud middleware a část abstrakcí přebírá platforma, OEM tým může víc pracovat na skutečném odlišení: chování a modely.

🛡️ Guardrails pro end-to-end modely

Další krok je přidat bezpečnostní guardrails, aby vývoj end-to-end modelů šel stavět na již existujících bezpečnostních mechanismech. Zmiňuje se i využití „classical stack“ jako bezpečnostního zábradlí.

Myšlenka je přitom jednoduchá a zároveň průmyslově klíčová: i když chcete end-to-end přístup, potřebujete mít jistotu, že systém umí v kritických chvílích přepnout na bezpečnější trajektorii nebo minimal risk maneuver.

🖥️ AGX Orin a Blackwell: výkon v autě jako klíč k modelům, ne jen k senzorům

Platforma Hyperion staví na L4-ready počítačové architektuře. Zmíněný „core“ je založen na dual AGX SoC, což je vlajková loď současné generace pro onboard AI. Uvnitř se navazuje na architekturu Blackwell, která je údajně stejná jako pro trénink foundation modelů, takže tok práce (train a inference) je konzistentnější.

Dva detaily jsou pro autonomii obzvlášť důležité:

• podpora různých precision formátů, včetně 4-bit floating point, aby se zlepšila výkonnost při omezené paměťové propustnosti v autě,
• škálování výkonu ve vztahu k tomu, že inference v reálném čase musí být deterministická a „dost rychlá“ pro bezpečné rozhodování.

V prezentaci zaznělo, že využití FP4 může přinést výrazné zrychlení oproti předchozí generaci. Pro čtenáře je to důležité v širším smyslu: když modely rostou a reasoning se přidává do smyčky rozhodování, potřebujete výpočet, který to reálně utáhne.

📷 Senzory jako společný jazyk: proč je „common sensor suite“ tak důležitý

Hyperion navrhuje i referenční design senzoru. Klíčová logika zní: pouze když máte jednotnou senzorovou architekturu, data jsou lépe sdílitelná napříč OEM a platformami. To urychluje jak vývoj, tak validační práci.

Zaznělo, že jsou k dispozici minimálně dvě konfigurace:

• High model pro vyšší úrovně autonomie včetně highway a urban L3 až L4 (zmiňované 14 high-definition kamer, až 4 vnitřní kamery, a devět radarů plus jeden lidar).
• Base model orientovaný na náklady, se 10 kamerami a třemi radary, schopný pokrýt full hand-free highway a urban funkce a i park-to-park scénáře (v rámci budování s partnery).

Důležitou vlastností je také redundance: návrh má mít plnou senzorovou redundanci tak, aby při single point of failure systém stále běžel bezpečně.

🤝 Hyperion fleet data a spolupráce s Uberem: data jako závod, ale i ekosystém

Autonomie není jen inženýrský problém. Je to i problém dat. V prezentaci zaznělo, že se pracuje na fleet přístupu ve spolupráci s Uberem, který má sloužit pro data collection a „jump start“ pro vývojový ekosystém.

Myšlenka je stejná jako u cloud-to-car pipeline: sběr dat, reálné ověření a zpětnovazební cyklus tréninku jsou zásadní pro robustní modely.

🧪 Mario 1.5: reasoning model, který umí trasy a tax prompts

Další část se zaměřila na modelovou vrstvu. Byla zmíněna aktualizace open modelu Alpamayo ve verzi 1.5 (v prezentaci se uvádí jako „příští generace“), a zároveň oznámení Mario 1.5.

Pro laiky: „10 miliard parametrů“ zní obrovsky, ale pro autonomii je to spíš startovní bod. Důležité je, co model umí udělat nad rámec samotného mapování obrazů.

Vylepšení Mario 1.5 v prezentované verzi zahrnovaly:

• routing capability: model umí sledovat trasu, a to v různých formátech jako waypoints, nav guidance nebo vektorové reprezentace.
• textové prompty pro taxi (v kontextu je to dotazování řidiče nebo pasažéra, co auto zkouší dělat). Prakticky: „Hey Mercedes, proč?“ nebo „Hey Mercedes, pull over…“
• multiple camera configurations: model může podporovat různé počty kamer (1, 2, 4) a různé FOV a umístění.

Zaznělo také, že Mario 1.5 dosáhl vysokého umístění v otevřeném benchmarku Lingo QA, což je signál, že model je schopnější v práci s otázkami a interpretací textu nebo situace.

📊 Tréninkový „data pyramid“ a proč není 80 000 hodin málo

V prezentaci se uvedlo, že model byl trénovaný na 80 000 AV datech. Zároveň se zdůraznilo, že model nebyl trénovaný „od nuly“. Základ backbone pochází z reasoning modelu Cosmos. Cosmos foundation model měl údajně trénink na internet-scale datech a na obrovském množství hodin reálných dat. Následně byl na to natrénovaný reasoning model.

Výsledek je takový, že model v praxi kombinuje širokou základní reprezentaci (z foundation) a specializaci na doménu AV (z AV tréninku). To podporuje obecnější generalizaci do terénu.

🧰 Od open modelu k produkci: proč je pipeline tréninku a validace stejně důležitá jako model

Jedna z realistických částí sdělení byla důležitá: dostat open source model do produkčního nasazení není „jen fine-tuning“. Je potřeba kontrolovaný proces, kde se řeší:

• jemné doladění tak, aby model fungoval ve všech scénářích,
• sestavení datové sady přes sběr z terénu i syntetickou generaci,
• příprava dat (hledání a kurace),
• validace a simulace,
• zpětná vazba z failure módů z reálných jízd do tréninku.

V autonomii se chyby neopravují jednou a navždy. Musí se iterativně najít, pochopit a znovu naučit. Proto je tooling klíčový.

🗂️ Open source data: 7 000 hodin a důraz na diverzitu

Kromě modelu se zmiňuje i open source data sada, aktuálně cca 7 000 hodin vysokokvalitních AV dat. Přínos je dvojí:

• diverzita (25 zemí),
• hodnota pro evaluaci a testování, i když to nemusí být „dost“ pro samotné trénování produkčního systému.

🧊 Simulace a Nurek: pixely, rekonstrukce a uzavřená smyčka testování

Pokud chce člověk dělat closed-loop evaluaci, potřebuje umět rekonstruovat obraz tak, aby simulované změny odpovídaly realitě. V prezentaci se objevuje nástroj Nurek, který má sloužit k neural reconstruction.

Konkrétně se uvádí, že Nurek umí rekonstruovat pixel při změně pozice vozidla. To je kritické pro:

• uzavřenou smyčku evaluace stacku,
• replay simulace v přísném režimu,
• validaci end-to-end modelů v kontextu kompletního systému.

Zaznělo, že v interním vývoji probíhá miliony simulací denně. V přirovnání se říká „jíme vlastní psí žrádlo“ (tj. používáme tooling sami na sobě), což je dobrý signál z hlediska praktické zralosti.

🧠 Fixer a Harvester: generování objektů a zvyšování diverzity dat

Kromě rekonstrukce se zmiňují i generativní modely otevřené jako součást Nurek open source úsilí:

• Fixer (v prezentaci jako genAI model),
• Harvester: umí „vyzvednout“ objekt z reálného záběru a uložit ho pro další využití.

Praktický přínos: můžete objekt vložit do jiných videí a tím dramaticky zvyšovat diverzitu. Výsledkem je více variety edge scénářů bez nutnosti, aby se všechny stejné incidenty musely stát ve světě.

🌦️ Cosmos Transfer: renderování sekvencí do jiného prostředí

Dalším zmíněným nástrojem je Cosmos Transfer. Princip je podobný, ale zaměřený na prostředí: můžete renderovat sekvenci do jiného prostředí.

Příklady, které zazněly:

• změna počasí,
• změna světelných podmínek,
• změna města a terénu.

To zní až „příliš snadno“, dokud si neuvědomíte, kolik práce by stálo ručně shromáždit identické scénáře ve všech variacích. Transfer je způsob, jak zrychlit a rozšířit dataset tak, aby model lépe generalizoval.

🧭 Hybridní AV stack: end-to-end pro zážitek, classical pro interpretable safety

Jedna z nejsilnějších částí strategie je tvrzení, že driver AV stack je hybridní: kombinuje end-to-end model s classical stackem.

Proč to dává smysl? Protože end-to-end může přinášet „human-like driver experience“. Zároveň ale průmysl tradičně staví ADAS/AV systémy na normách funkční bezpečnosti (například ISO 26262 a koncepty FUSA). To znamená, že interpretable safety a ověřitelnost je zásadní.

Hybridní přístup umožňuje:

• zachovat moderní chování a flexibilitu end-to-end modelu,
• neohrozit bezpečnostní interoperabilitu díky classical stacku,
• mít bezpečnostní arbitrátor, který umí v kritické situaci přepnout.

⚖️ Bezpečnostní arbitrátor jako „přepínač reality“

Popis je obrazný, ale praktický: když model end-to-end vyhodnotí, že situace je riziková, arbitrátor může změnit plán na classical trajektorii, která je bezpečnější. Cíl je „seamless“ přechod s téměř nulovým zpožděním.

Tohle je důležité pro důvěru: systém nemusí být perfektní ve všech scénářích, pokud umí včas zvolit bezpečný alternativní režim.

📈 L2++ teď, L4 potom: roadmapa škálování od adresy k adrese

Strategie se orientuje na praktickou škálovatelnost. L2++ se bere jako nejbližší krok, protože je to velká plocha reálné jízdy s měřitelným dopadem. V prezentaci zaznělo, že je cílem škálovat address-to-address schopnosti v rámci dalších měsíců a poté začít initial deployment pro L4 flotilu.

Byla nastíněna i orientační časová osa:

• letos: škálování L2++ (address-to-address) a rozšiřování schopností,
• příští rok: počáteční nasazení L4 flotil v omezeném rozsahu,
• do roku 2028: nasazení L4 v osobních vozidlech ve spolupráci s partnery.

V prezentaci se také zmiňuje, že systém je škálovatelný na L4 v rámci rozšiřitelné software struktury. To znamená, že L2++ běží na hlavním ECU a satelitní ECU poskytuje další senzory a redundanci.

🧱 Hlavní ECU a satelitní ECU: bezpečnostní redundantní stack

Konkrétní návrh architektury je takový, že:

• na hlavním ECU běží L2++ stack (co se dělá dnes),
• na satelitních ECU běží bezpečnostně redundantní stack, často classical, doplněný o minimum risk maneuver při single point of failure.

To je praktický způsob, jak znovu použít code repository a doručovat L2++ i L4 do partnerů.

🏁 Vývoj zrychluje: iterace tisíckrát a rychlý turnaround mezi tréninkem a evaluací

Autonomní vývoj potřebuje rychlou iteraci. V prezentaci zazněly extrémně časté iterace end-to-end modelů. Zmiňuje se, že se začalo vyvíjet end-to-end model zhruba před rokem a už proběhly tisíce iterací. Odhad zní jako desítky verzí denně.

Tohle je možné jen díky kombinaci:

• GPU clusterů pro trénink a rychlé přepisování iterací,
• simulation a replay pipeline pro closed-loop evaluaci,
• toolingu na přípravu a validaci dat.

Důležitý detail je turnaround čas: z pole a zpět do uzavřené evaluace má být vše v řádu hodin. V prezentaci se uvádí, že to momentálně zvládnou během šesti hodin, s cílem zkrátit to na několik hodin.

🤝 Ekosystém: OEM, Tier 1 a spolupráce pro sdílené senzory a data

Žádný jeden hráč nezvládne autonomii sám. V prezentované strategii se opakovaně objevuje myšlenka ekosystému: OEM, Tier 1, AV software vývojáři, a mobility nebo robotaxi partneři.

Zmíněné příklady spoluprací:

• spolupráce s Mercedesem, kde po pěti letech partnerství bylo nasazení technologie do globálních Mercedes vozů (s výjimkou Číny) a pokračuje rozšiřování address-to-address L2 plus capability,
• práce s dalšími OEM zákazníky (včetně zmíněných značek),
• partnerství s Uberem pro L4 data a deployment plán v několika městech.

Co je společné? Snižování „duplicitní práce“: když mají OEM a platformy společnou senzorovou architekturu a bezpečnostní middleware, vývoj jde rychleji.

🧠 Co si z toho odnáším: hlavní závěry pro budoucnost škálovatelných, bezpečných AV

Když se na to podívám jako na souvislý příběh, vidím pět hlavních závěrů, které z prezentované strategie vyplývají:

1. Modely se posouvají směrem k reasoning a agentic schopnostem. Auto už není jen detektor. Potřebuje uvažovat nad situací a plánovat.
2. Bezpečnost musí být architektonická vlastnost, ne dodatečná kontrola. Halos a guardrails mají sloužit jako safety foundation pro end-to-end přístupy.
3. Platforma musí škálovat vývoj. Třípočítačový model (train, simulation, inference) a pět vrstev služeb nad ním snižují náklady na integraci.
4. Senzory a data jsou společný jazyk pro celý ekosystém. Common sensor suite zlepšuje sdílení dat a přenositelnost přístupů.
5. Simulace a uzavřená smyčka jsou zrychlovač. Nurek, Fixer, Harvester a Cosmos Transfer zvyšují diverzitu scénářů a zkracují iterace.

Celý cíl je jasný: posunout autonomní kilometry z dnešního zlomku na výrazně vyšší úroveň. A to se nestane jednou velkou výjimkou. Stane se to opakovaným cyklem vývoje, validace a nasazení, který dokáže zvládnout edge cases a zároveň držet bezpečnostní závazky.

🔮 Kam to podle mě směřuje: od robotaxi do mainstreamu, ale bezpečně

Autonomní vozidla budou nejspíš jedním z prvních masově nasazovaných physical AI agentů. A pokud se ukáže, že hybridní stack, bezpečnostní guardrails a škálovatelná cloud-to-car platforma skutečně fungují, budeme svědky dvou paralelních trendů:

• zvyšování schopností v běžném provozu (L2++ škálování, address-to-address),
• postupný přechod k L4 flotilám v omezených regionech, které se dají lépe testovat a validovat.

Rok 2025 je podle mého názoru hlavně o „srozumitelnosti cesty“. Ne o tom, že by autonomní řízení bylo magicky vyřešeno. Je o tom, že architektonický a vývojový rámec se konečně skládá do podoby, kterou lze opakovat a měřit.

Pokud mě zajímá future of AV, pak mě nejvíc láká právě tenhle mix: reasoning modely v autě, bezpečnostní platforma, a simulace, která pomáhá iterovat rychleji než realita. A to je přesně to, co potřebujete, aby se autonomní řízení změnilo z unikátního experimentu na robustní průmyslový produkt.