Kera a práce snižování
Bug report, který nebyl bug
Příběh obvykle začíná číslem, které je skoro správné. Ne úplně špatné. Ne rozbité tak, že by dashboard zčervenal. Skoro správné tím drahým způsobem: tak špatné, že jeden tým může nasadit, druhý tým váhá a auditor se ptá, proč se odpověď změnila, když se stejný model přesunul z jednoho stroje na druhý.
Jedno sestavení běží na x86 serveru a vyprodukuje hodnotu. Další sestavení běží na ARM notebooku a vyprodukuje hodnotu dostatečně blízkou na to, aby demo přežilo. GPU cesta je rychlejší, ale zaokrouhluje výpočet jinak. FPGA cesta je lákavá kvůli časování, ale najednou má softwarový tým hardwarovou konverzaci. Každý umí vysvětlit malou část rozdílu. Nikdo nevlastní celou cestu od zdroje k výsledku.
To je prostor, pro který je Kera postavená. Ne nápad na model, ne marketingový slajd, ne článek o budoucím kompilátoru, ale kompilátorová práce, která začíná ve chvíli, kdy tým řekne, že stejný výpočet musí běžet na různých strojích a přesto znamenat totéž. Tato povinnost potřebuje vlastníka. Slib kompilátoru není, že lowering je elegantní. Slib je, že se s loweringem zachází jako s prací.
Lowering je část kompilátoru, kde se hezký záměr jazyka stává instrukcemi, které cíl může provést. Je to také místo, kde se vágní tvrzení stávají viditelnými. Pokud má být výsledek bitově identický napříč CPU, GPU, FPGA a WebAssembly, kompilátor si nemůže dovolit mávnout rukou nad rozdíly mezi cíli. Musí nést dostatek struktury, aby rozhodl, co se může změnit a co se změnit nesmí. Musí znát paměťové prostory, efekty, opkódy, přesuny dat, omezení cílů a účtenky, které dokazují, že dvě sestavení jsou stejný výpočet.
Lákavá verze příběhu je nazvat to vrstvou přenositelnosti. To je příliš málo. Přenositelnost říká, že program běží jinde. Kera míří na těžší tvrzení: program je reprezentován jako obsahově adresovaný graf, zkompilovaný do .keg artefaktu, spuštěný na více backendech, a přesto produkuje stejnou odpověď. Kuchyně se mění. Recept se nemění.
Prostředek, který nikdo nechce prodávat
První konverzace s vážným kupcem málokdy začíná syntaxí. Začíná nepořádkem. Existuje model, na kterém záleží. Existuje simulace, která bývala výzkumem a stala se provozem. Existuje výpočet rizika, jehož výsledek se už nesmí lišit podle stroje. Existuje edge nasazení, které nemůže unést plný cloudový runtime. Existuje tým, který chce akcelerátor, ale nemůže si dovolit přepisovat pokaždé, když se akcelerátor změní.
Většina nástrojů to dělá jako problém s nasazením. Vyberte cíl, exportujte model, opravte runtime, přijměte určitou odchylku, pak napište dokument vysvětlující výjimky. Dokument roste. Testovací matice roste. Počet specialistů roste. Nakonec organizace platí za heterogenitu dvakrát: jednou, když kupuje hardware, a podruhé, když se snaží dokázat, že hardware udělal stejnou práci.
Kera začíná z opačného konce. Stránka Kera to nazývá staticky typovaný systémový jazyk s grafově nativním, obsahově adresovaným IR. Tato fráze je důležitá, protože graf není dekorativní kompilátorový diagram. Je to spustitelný objekt. Zdrojový kód se snižuje do orientovaných acyklických grafů operací, uložených jako .keg soubory. Každý uzel nese definovanou strukturu. Duplicitní práce může být eliminována strukturálně. Stejný graf může být spuštěn na CPU, GPU, FPGA a WASM, aniž by se každý cíl bral jako samostatný malý vesmír.
Proto se Kera musí chovat jako seriózní kompilátorová infrastruktura, ne jako diagram. Zákazník žije právě v tom nepříjemném středu. Tokenizace musí zachovávat pozice bajtů. Parsování musí napájet nástroje i kompilaci. Typová kontrola musí odmítnout neshody tvarů a hran dřív, než se stanou běhovými událostmi. Kontrola půjček musí rozumět vlastnictví napříč hostitelskou, zařízenou, připnutou a jednotnou pamětí. Optimalizace musí být opakovatelná. Serializace musí organizaci dát artefakt, který si může ponechat.
Nic z toho není dramatický titulek. Je to mnohem užitečnější než titulek. Znamená to, že když se pracovní zátěž přesune z vývoje do produkce, nebo ze základní cesty CPU na cestu GPU, má kompilátor stabilní věc k porovnání: otisk grafu. Pokud se otisk shoduje, je práce stejná práce. To je společný kontrolní bod, kterému rozumí inženýr, kupující i auditor.
Graf je účtenka, ne obrázek
Starý způsob vysvětlení programu je ukázat zdroj a požádat čtenáře, aby kompilátoru důvěřoval. Stránka Kera se stále vrací k jinému objektu: ke grafu. Každá operace je uzel. Hrany vyjadřují závislosti. Graf má obsah. Obsah má hash. Hash se stává otiskem, který prochází celým sestavením.
To zní jako vnitřní mechanismy, dokud se nepostavíte vedle týmu pro shodu s předpisy. Tým pro shodu nechce vědět, že dodavatel má pěknou architekturu kompilátoru. Chce vědět, jestli výpočet schválený minulý měsíc je výpočet, který běží dnes. Otisk grafu je most mezi těmito světy. Není to snímek obrazovky kompilátoru. Je to kompaktní způsob, jak říct: tato sada operací, tyto typy, tyto vstupy, tyto atributy, tato struktura závislostí.
Model uzlů je záměrně přísný. Uzel je verze schématu, operační kód, deskriptory výstupů, hashe vstupů a mapy atributů uspořádané v kanonickém pořadí. Bajty jsou hashovány algoritmem SHA3-256 pod doménově oddělenými prefixy, takže hashe uzlů, oblastí a grafů žijí v oddělených jmenných prostorech. Pokud mají dva uzly stejný operační kód, vstupy a atributy, mají stejný hash. Vložení duplikátu vrátí existující záznam. Eliminace společných podvýrazů se stává důsledkem reprezentace, ne hrdinským průchodem přidaným později.
To je ten druh detailu, který mění inženýrský systém v něco, na co se lidé mohou spolehnout. Kupující nekupuje diagram kompilátoru. Kupující kupuje méně sporů o tom, jestli se výpočet změnil. Vývojář nekupuje slogan o deterministické AI. Vývojář kupuje formát grafu, kde lze shodu zkontrolovat, uložit a použít nástroji. Soubor .keg tedy není dodatečný nápad implementace. Je to přenosný záznam práce.
Osm malých dveří, než se objeví cíl
Když si lidé představí kompilátor, často hned skočí k backendu. Představí si okamžik, kdy se kód stane AVX, PTX, Verilog nebo WASM. Ten okamžik je důležitý, ale přichází pozdě v příběhu. Většina práce kompilátoru už tehdy proběhla, v tichých fázích, které rozhodují o tom, zda lze backendu věřit.
Kera začíná lexerem pracujícím s UTF-8, který převádí zdrojový kód na tokeny s plným sledováním trivia a obnovou po chybách. To zní jako záležitost editoru, a také to tak je. Je to ale také spolehlivost nástrojového řetězce. Pokud je zachována pozice každého bajtu, mohou diagnostika, formátování, inkrementální reparsování a chování jazykového serveru odpovídat tomu, co uživatel skutečně napsal. Kompilátor, který brzy ztratí podobu zdroje, za tuto ztrátu platí všude jinde.
Parser je založen na událostech: rekurzivní sestup s Prattovým parsováním výrazů generuje události Start, Token, Finish a Error, místo aby vytvářel jediný AST, který musí všichni sdílet. Proud událostí nezávisle napájí stavitele stromu, formátor a jazykový server. Zelený strom je bezztrátový, zachovává tokeny i trivia. Stavitel grafu pak tento strom prochází, udržuje rozlišení jmen a vytváří uzel Region pro každou funkci.
Teprve poté se zdroj stává grafem, který kompilátor nese. Strukturální typová kontrola ověřuje kompatibilitu napříč hranami operací a omezení tvarů tenzorů. Typy odpovídají pouze tehdy, jsou-li jejich kanonické hashe identické. Kontrola půjček vynucuje jednoho vlastníka pro každou hodnotu, žádné aliasované měnitelné reference a pravidla vlastnictví napříč paměťovými prostory. Anotace efektů se kontrolují z hlediska konzistence. Vedlejší účinky nejsou ponechány vkusu ani konvenci.
Správce průchodů optimalizace pak dělá tu rozpoznatelnou práci kompilátoru: konstantní sbalování, eliminaci společných podvýrazů, eliminaci mrtvého kódu, inlining, vektorizaci a fúzi smyček v pevném bodě. Důležitá věta není seznam průchodů. Důležité je to, co se děje po každém průchodu: validátor invariantů grafu kontroluje konzistenci hashů a integritu závislostí. Optimalizace smí graf zlepšovat, ne ho činit záhadným.
Nakonec generátory kódu specifické pro cílovou platformu emitují nativní kód, PTX, Verilog nebo WASM, a optimalizovaný graf se serializuje do souboru .keg s tabulkou sekcí. Soubor začíná magickými bajty KEG\0 a nese sekce pro řetězce, typy, atributy, uzly, regiony a exporty. To je cesta, kterou musí tým zvládnout, než může poctivě mluvit o cílových platformách.
Cílové platformy nejsou samolepky na prezentaci
Seznam cílových platforem se snadno píše a těžko zaslouží. CPU, GPU, FPGA a WASM se úhledně vejdou do produktové karty. Snížení na ně je místo, kde se skrývá účet. Každá cílová platforma má své vlastní zvyky, silné stránky a způsoby selhání. Kompilátor, který chce deterministické heterogenní provádění, nemůže tyto zvyky považovat za cizí problém.
Na CPU Kera generuje nativní strojový kód pro x86-64 a ARM64, přičemž RISC-V Vector je v technickém listu. Cesta x86 volí SSE2, AVX2 nebo AVX-512; cesta ARM používá NEON; alokátor registrů a plánovač jsou sdílené. Tvrzení produktu není jen to, že binárka existuje. Tvrzení je, že se vybírají SIMD jádra specifická pro daný cíl, zatímco graf zůstává stejným výpočtem.
Na GPU zdrojový materiál zmiňuje generování PTX pro CUDA a ROCm, přičemž tensorová jádra se používají, když to tvar jádra umožňuje. Ta poslední věta dělá práci. Hardwarová akcelerace není kouzelný prášek. Tvar jádra buď zapadá do cesty tensorových jader, nebo ne. Kompilátor to musí poctivě odhalit, přesouvat data mezi hostitelem a zařízením, když je to potřeba, a stále držet otisk grafu jako důkaz toho, co se vykonává.
Na FPGA se cesta snižování stává hardwarovým rozhovorem: syntéza Verilogu, odhad zdrojů, časová analýza a plánování pipeline pro předvídatelné chování přesné na cyklus. Toto je druh cíle, kde je mávnutí rukou obzvlášť drahé. Pokud kupující potřebuje tvrdý real-time, povrch kompilátoru musí mluvit v cyklech, zdrojích a pipeline, ne jen v rychlosti. Příběh Kery dělá z FPGA backend téhož grafu místo přepisu jiným týmem.
Na WASM stránka jmenuje 128bitové SIMD pro edge a nasazení v prohlížeči. To je důležité, protože edge je místo, kde se realita nasazení často střetává s čistotou. Prohlížeč, malé zařízení nebo omezené běhové prostředí nemohou vždy hostit stejný stack jako server. Cesta snižování nativní pro graf dává týmu způsob, jak přenést stejný výpočet do tohoto prostředí, aniž by se z edge stal druhý produkt.
Determinismus musí přežít úspěch
Determinismus se v malé místnosti slibuje snadno. Je těžší, když produkt uspěje. Přichází více uživatelů. Objevuje se více hardwaru. Model se přesouvá z jednoho čipu na druhý. Testovací základna napsaná pro jedno prostředí musí pokrýt jiné. Optimalizace, která vypadá neškodně, změní pořadí redukce. Rychlá cesta se objeví v jednom běhovém prostředí, ale ne v jiném.
The Kera page frames determinism as bit for bit across platforms. That is not a cosmetic claim. It changes product obligations. Primitive arithmetic has defined precision semantics across all targets. Reductions have defined tie-breaking so scheduling and hardware do not change the result. Neural network primitives have deterministic implementations on CPU, GPU, FPGA, and WASM. The graph means the same thing wherever it runs.
This is why undefined behaviour, garbage collector pauses, and implicit side effects are not small language preferences. They are cracks in the execution surface. Kera’s page says no LLVM dependency, no garbage collector, no undefined behaviour. Explicit types, explicit effects, and ownership across memory spaces are product controls. They reduce the number of places a result can change while everyone is looking somewhere else.
There is a human side to this too. When a robotics controller changes behaviour across devices, when a finance workflow rounds one cent differently, when a scientific result cannot be repeated by a reviewer, or when a game simulation diverges between targets, the argument is not really about compiler theory. It is about institutional confidence. Kera’s consumer copy uses simple stories because the underlying problem is simple to feel: same instructions, same answer, on any computer you own.
That confidence must survive acceleration. If performance requires teams to abandon determinism, the product has only moved the risk. Kera tries to keep performance and determinism in the same contract by making the graph the unit of meaning and the target path the unit of execution.
Security is part of lowering
Compiler discussions often isolate security as runtime work. Kera’s source material does not. It talks about capability-based security, a SecurityManager, a default-deny gate, a PolicyBuilder, seccomp BPF, Linux namespaces, and a thread-safe tamper-evident audit log in a fixed-capacity ring buffer. Those words belong in the engineering story because lowering does not end when instructions are emitted. The emitted work still has to run with boundaries.
Capability tokens are granted at startup. Privileged actions require an explicit capability. Access rules are declared up front. A BPF filter restricts syscalls. Namespace isolation separates process, mount, and network views. Security-relevant events land in an audit log. The short sentenceis: nothing is permitted by default.
That matters for heterogeneous execution because targets create surfaces. A CPU process, GPU transfer, FPGA path, browser runtime, and distributed job do not fail in identical ways. A product has to keep policy attached to the work as it moves. If the graph says what the computation is, the runtime controls say what the computation may do.
There is also an operations reason to bring security into the compiler story. Teams do not want one product for compilation, anotherfor policy, another for logging, and another for explanation if the seams between them become the place where incidents hide. Kera’s page does not claim to solve all security. It does something narrower and more useful: it makes permissions explicit and auditedin the execution environment the compiler feeds.
Distributed work is still lowering
The technical sheet names distributed execution, ring allreduce, and checkpoint recovery. In another product, those might be brochure items. In Kera, they belong to the same lowering conversation because parallelism changes the shape of a computation. Data, model, and pipeline parallelism are not just ways to go faster. They are ways to split work without losing the meaning of the original graph.
Pokud velká úloha běží napříč mnoha stroji a jeden uzel selže, obnovení z kontrolního bodu není jen pohodlí. Je to součást toho, aby byl výpočet provozuschopný. Pokud jsou výsledky spolehlivě agregovány, musí být sémantika agregace definována. Pokud je graf adresován obsahem, musí distribuovaná cesta zachovat identitu grafu, místo aby vymýšlela druhou realitu, jakmile úloha opustí jeden stroj.
Právě zde se produktová interpretace vyjasňuje. Kera není syntaxová vrstva s distribuovaným doplňkem. Snaží se učinit výpočet přenosným jak napříč tvary, tak napříč hardwarem: jeden program, jeden graf, více cílů spuštění a záznam, který lze zkontrolovat. Distribuované spuštění je dalším místem, kde musí lowering nést prováděcí kontrakt.
Mění to také personální příběh. Bez sdílené kompilační cesty může chyba, která se objeví pouze na jedné platformě, vyžadovat lidi, kteří znají čip, nástrojový řetězec i běhové prostředí zároveň. S jedním grafem a sdílenou cestou je otázka ostřejší: změnil se graf, změnila se cesta loweringu, nebo cíl porušil definovanou sémantiku? Lepší otázky neodstraňují tvrdou práci. Zabraňují tomu, aby se tvrdá práce šířila náhodně.
Proč musí někdo vlastnit cestu
Lowering nemůže zůstat bez vlastníka, jakmile nese výsledky, na které se lidé spoléhají. Graf, který běží na CPU, GPU, FPGA a WASM, potřebuje víc než chytré zobrazení. Potřebuje dokumentaci, diagnostiku, tvrzení o cílech, chování editoru, generování kódu, bezpečnostní kontroly, podporu v konverzacích a způsob, jak kupujícímu přesně sdělit, co se změnilo, když se změní výsledek.
To nedělá práci méně technickou. Dělá technickou práci více závaznou. Kera je v současnosti komerční produkt Dweve, nikoli open-source vydání: všechna práva vyhrazena, dostupné pod komerční licencí, vyrobeno v Nizozemsku a určeno pro organizace, které potřebují cestu grafu podporovanou, nikoli pouze publikovanou. Pokud stránka uvádí Rust 2021, grafové IR, vlastní JIT, žádné LLVM, CPU/GPU/FPGA/WASM, sledování efektů, vlastnictví napříč paměťovými prostory, schopnostní bezpečnost, distribuované spuštění, vkládání C a Pythonu, pracovní postupy CLI, podporu editoru a nástroje LSP, nejsou to dekorativní interní záležitosti. Jsou to závazky, které musí přežít hodnocení skutečnými pracovními zátěžemi.
List schopností je v tomto ohledu opatrný. Popisuje návrhové cíle a říká, abyste ověřili proti své pracovní zátěži. Tato zdrženlivost má význam. Je mnohem zdravější než předstírat, že každé číslo benchmarku platí všude. Systém by měl týmům poskytnout způsob, jak měřit, kontrolovat a porovnávat ve vlastním prostředí, ne po nich žádat, aby přijali univerzální příběh o rychlosti.
Někdo musí vlastnit tuto cestu, protože každý cíl se snaží učinit zdroj méně univerzálním. Kera je místem, kde se tyto rozdíly mezi cíli stávají explicitní prací kompilátoru, nikoli folklórem předávaným po hlášení chyby.
Den, kdy se graf stane kontraktem
Představte si znovu původní hlášení chyby, ale s Kerou již v pracovním postupu. Finanční tým schválí výpočet rizika. Otisk grafu je zaznamenán. První nasazení běží na CPU. Později je pro analýzu portfolia zavedena cesta GPU. Ještě později je pro cenotvorbu s nižší latencí použita cesta FPGA. Otázka v každém kroku není, zda nový hardware zní působivě. Otázkou je, zda je snižován stejný graf a zda sémantika cíle udržuje výsledek identický.
Konverzace se mění. Platformní tým může mluvit o plánování a nákladech. Kompilátorový tým může mluvit o backendech. Tým pro shodu může mluvit o otisku. Vlastník byznysu se může ptát, zda je přesun hardwaru provozním rozhodnutím, nebo přepisem. Produkt jim všem dává jeden objekt, na který mohou ukázat.
To je tichá hodnota obsahově adresovaného IR. Mění spouštění napříč platformami ze série přesvědčivých vysvětlení na záznam. Dělá z grafu účtenku. Umožňuje stejnému .keg souboru napájet každý backend. Dává organizaci základní linii, která patří výpočtu, nikoli jedinému stroji.
Žádný kompilátor nemůže odstranit potřebu inženýrského úsudku. Týmy stále musí pečlivě vybírat cíle, poctivě testovat pracovní zátěže, rozumět limitům cílů a rozhodovat, které domény vyžadují bitovou shodu. Kera ale může tato rozhodnutí učinit explicitními. Může zabránit tomu, aby se migrace výkonu náhodou stala migrací sémantickou.
Ponaučení z loweringu
Kera je důležitá, protože těžká část není mít chytrý nápad na lowering. Těžká část je nést ten nápad všemi nudnými místy, kde se inženýrství buď stává důvěryhodným, nebo se mění v folklór: diagnostika, zelené stromy, hashování typů, borrow checking, fixpointová optimalizace, validace invariantů, serializace .keg, emise backendu, bezpečnostní politika, auditní logy, podpora editorů a spouštění specifické pro cíle.
Lowering je práce, protože každý cíl se snaží učinit zdroj méně univerzálním. Deterministické kompilátorové inženýrství je disciplína odmítání toho, aby se to stalo tiše. CPU chce vektory. GPU chce kernely. FPGA chce cykly. WASM chce omezení. Organizace chce jednu odpověď. Úkolem Kery je zachovat význam výpočtu a zároveň nechat každý cíl dělat to, v čem je dobrý.
To je inženýrský tvar, ne papírová abstrakce. Má kupujícího, způsob selhání, formát souboru, cestu kompilátoru a provozní důsledky. Slib není, že se hardware stane jednoduchým. Slib je, že složitost je reprezentována, snížena, zkontrolována a vlastněna.
Až přijde další téměř správné číslo, tým by neměl muset začínat folklórem o tom, který stroj co spustil. Měl by začít grafem. Shodoval se otisk? Který backend vygeneroval kód? Která oprávnění byla udělena? Která sémantika cíle byla použita? Který artefakt byl uložen? To jsou produktové otázky. Kera existuje, protože jsou to také kompilátorové otázky.