Kera un atstāšanās darbs
The bug report that was not a bug
The story usually starts with a number that is nearly right. Not wildly wrong. Not broken in a way that makes the dashboard red. Nearly right in the expensive way: the sort of wrong that lets one team ship, another team hesitate, and an auditor ask why the answer changed when the same model moved from one machine to another.
One build runs on an x86 server and produces a value. The next build runs on an ARM laptop and produces a value close enough that ademo survives. A GPU path is faster but rounds through the computation differently. An FPGA path is attractive for timing but suddenly the software team is having a hardware conversation. Everyone can explain a small piece of the difference. Nobody owns the whole path from source to result.
That is the space Kera is built for. Not the model idea, not the marketing slide, not a paper about a future compiler, but the compiler work that begins once a team says the same computation must run on different machines andstill mean the same thing. That obligation needs an owner. The compiler promise is not that lowering is elegant. The promise is that lowering is treated as work.
Lowering is the part of a compiler where nice language intent becomes instructions that a target can execute. It is also where vague claims become visible. If the result is supposed to be bit for bit identical across CPU, GPU, FPGA, and WebAssembly, then the compiler cannot shrug at target differences. It has to carry enough structure to decide what maychange and what must not change. It has to know memory spaces, effects, opcodes, data movement, target limits, and the receipts that prove two builds are the same computation.
The tempting version of the story is to call this a portability layer. That is too small. Portability says the program runs elsewhere. Kera is aiming at the harder statement: the program is represented as a content-addressed graph, compiled to a .keg artifact, lowered to multiple backends, and still produces the same answer. The kitchen changes. The recipe does not.
The middle nobody wants to sell
The first conversation with a serious buyer rarely begins with syntax. It begins with a mess. There is a model that matters. There is a simulation that used to be research and has become operational. There is a risk calculation whose result is no longer allowed to vary by machine. There is an edge deployment that cannot carry the full cloud runtime. There is a team that wants an accelerator but cannot afford a rewrite every time the accelerator changes.
Most tooling makes this look like a deployment problem. Choose the target, export the model, patch the runtime, accept some variance, then write a document explaining the exceptions. The document grows. The test matrix grows. The number of specialists grows. Eventually the organisation is paying for heterogeneity twice: once when it buys the hardware, again when it tries to prove the hardware did the same work.
Kera starts from the opposite end. The Kera page calls it a statically typed systems language with a graph-native, content-addressed IR. That phrase matters because the graph is not a decorative compiler diagram. It is the executable object. Source code lowers into directed acyclic graphs of operations, stored as .keg files. Each node carries defined structure. Duplicate work can be eliminated structurally. The same graph can be lowered to CPU, GPU, FPGA, and WASM without treating every target as a separate little universe.
Tāpēc Kera ir jāuzvedas kā nopietna kompilatora infrastruktūra, nevis diagramma. Neērtajā vidusceļā dzīvo klients. Tokenizācijai ir jāsaglabā baitu pozīcijas. Parsēšanai ir jāapkalpo gan rīki, gan kompilācija. Tipu pārbaudei ir jānoraida formas un malu neatbilstības, pirms tās kļūst par izpildlaika notikumiem. Aizņēmumu pārbaudei ir jāsaprot īpašumtiesības pāri resursdatora, ierīces, piespraustajai un vienotajai atmiņai. Optimizācijai ir jābūt atkārtojamai. Serializācijai ir jādod organizācijai artefakts, ko var saglabāt.
Nekas no tā nav dramatisks virsraksts. Tas ir daudz noderīgāk par virsrakstu. Tas nozīmē, ka, darba slodzei pārejot no izstrādes uz ražošanu vai no CPU bāzes līnijas uz GPU ceļu, kompilatoram ir stabils salīdzināšanas objekts: grafa nospiedums. Ja nospiedums sakrīt, darbs ir tas pats darbs. Tas ir kopīgs kontroles punkts, ko saprot inženieris, pircējs un revidents.
Grafs ir kvīts, nevis attēls
Vecais veids, kā izskaidrot programmu, ir parādīt avotu un lūgt lasītājam uzticēties kompilatoram. Kera lapa atgriežas pie cita objekta: grafa. Katra darbība ir mezgls. Malas izsaka atkarības. Grafam ir saturs. Saturā ir jaucējkods. Jaucējkods kļūst par nospiedumu, kas ceļo cauri būvēšanai.
Tas izklausās pēc iekšējas mehānikas, līdz nostājaties blakus atbilstības komandai. Atbilstības komanda nevēlas zināt, ka piegādātājam ir jauka kompilatora arhitektūra. Tā vēlas zināt, vai aprēķins, kas apstiprināts pagājušajā mēnesī, ir aprēķins, kas darbojas šodien. Grafa nospiedums ir tilts starp šīm pasaulēm. Tas nav kompilatora ekrānuzņēmums. Tas ir kompakts veids, kā pateikt: šī darbību kopa, šie tipi, šīs ievades, šie atribūti, šī atkarību struktūra.
Mezglu modelis ir apzināti stingrs. Mezgls ir shēmas versija, opkods, izvades deskriptori, ievades jaucējkodi un atribūtu kartes, kas izkārtotas kanoniskā secībā. Baitu virkne tiek jaucēta ar SHA3-256 zem domēna atdalītiem prefiksiem, tāpēc mezgla, reģiona un grafa jaucējkodi dzīvo atsevišķās nosaukumu telpās. Ja diviem mezgliem ir vienāds opkods, ievades un atribūti, tiem ir vienāds jaucējkods. Dublikāta ievietošana atgriež esošo ierakstu. Kopējo apakšizteiksmju eliminācija kļūst par reprezentācijas sekām, nevis varonīgu posmu, kas pievienots vēlāk.
Tāda ir detaļa, kas inženiertehnisku sistēmu pārvērš par kaut ko tādu, uz ko cilvēki var paļauties. Pircējs nepērk kompilatora diagrammu. Pircējs pērk mazāk strīdu par to, vai aprēķins ir mainījies. Izstrādātājs nepērk saukli par deterministisku AI. Izstrādātājs pērk grafa formātu, kurā vienādību var pārbaudīt, glabāt un izmantot rīkos. Tāpēc .keg fails nav pēcpārdomas par ieviešanu. Tas ir pārnēsājams darba ieraksts.
Astoņas mazās durvis, pirms parādās mērķis
Kad cilvēki iedomājas kompilatoru, viņi bieži uzreiz domā par backend. Viņi iztēlojas brīdi, kad kods kļūst par AVX, PTX, Verilog vai WASM. Šis brīdis ir svarīgs, taču tas ir vēlu stāstā. Lielākā daļa kompilatora darba jau ir paveikta līdz tam, klusos posmos, kas izlemj, vai backendam var uzticēties.
Kera sākas ar UTF-8 apzinātu lekseri, kas pārvērš avotu tokenos ar pilnīgu trivia izsekošanu un kļūdu atkopšanu. Tas izklausās pēc redaktora infrastruktūras, un tā arī ir. Tā ir arī rīkkopas uzticamība. Ja tiek saglabāta katra baita pozīcija, diagnostika, formatēšana, inkrementāla pārparsēšana un valodas servera darbība var saskanēt ar to, ko lietotājs patiešām uzrakstīja. Kompilators, kas agri zaudē avota formu, par šo zaudējumu maksā visur citur.
Parsētājs ir notikumu balstīts: rekursīvā nolaišanās ar Pratta izteiksmju parsēšanu ģenerē Start, Token, Finish un Error notikumus, nevis veido vienu AST, kas visiem jādalās. Notikumu plūsma baro koka veidotāju, formatētāju un valodas serveri neatkarīgi. Zaļais koks ir bez zudumiem, saglabājot tokenus un trivia. Grafu veidotājs pēc tam iet cauri šim kokam, uztur nosaukumu izšķiršanu un izveido Region mezglu katrai funkcijai.
Tikai pēc tam avots kļūst par grafu, ko kompilators nes. Strukturālā tipu pārbaude validē saderību starp darbību malām un tenzoru formas ierobežojumiem. Tipi sakrīt tikai tad, ja to kanoniskie heši ir identiski. Aizņēmumu pārbaudītājs nodrošina vienu īpašnieku katrai vērtībai, bez saistītām maināmām atsaucēm, un īpašumtiesību noteikumus starp atmiņas telpām. Efektu anotācijas tiek pārbaudītas konsekvences dēļ. Blakusefekti netiek atstāti gaumes vai vienošanās ziņā.
Optimizācijas pāreju pārvaldnieks pēc tam veic atpazīstamo kompilatora darbu: konstantes locīšanu, kopīgo apakšizteiksmju elimināciju, mirušā koda elimināciju, ielikšanu, vektorizāciju un cilpu sapludināšanu fiksēta punkta cilpā. Svarīgā frāze nav pāreju saraksts. Svarīgs ir tas, kas notiek pēc katras pārejas: grafu invariantu pārbaudītājs pārbauda heša konsekvenci un atkarību integritāti. Optimizācijai ir atļauts uzlabot grafu, nevis padarīt to noslēpumainu.
Visbeidzot, mērķa specifiski koda ģeneratori ģenerē vietējo kodu, PTX, Verilog vai WASM, un optimizētais grafs tiek serializēts .keg failā ar sekciju tabulu. Fails sākas ar maģiskajiem baitiem KEG\0 un satur sekcijas virknēm, tipiem, atribūtiem, mezgliem, reģioniem un eksportiem. Tas ir ceļš, kas komandai jāpārvalda, pirms tā var godīgi runāt par mērķiem.
Mērķi nav uzlīmes uz slaida
Mērķu sarakstu ir viegli uzrakstīt un grūti nopelnīt. CPU, GPU, FPGA un WASM glīti iederas produkta kartē. Pazemināšana līdz tiem ir vieta, kur slēpjas rēķins. Katram mērķim ir savi ieradumi, stiprās puses un atteices veidi. Kompilators, kas vēlas deterministisku heterogēnu izpildi, nevar uzskatīt šos ieradumus par kāda cita problēmu.
CPU gadījumā Kera ģenerē vietējo mašīnkodu x86-64 un ARM64, ar RISC-V Vector tehniskajā lapā. x86 ceļš izvēlas SSE2, AVX2 vai AVX-512; ARM ceļš izmanto NEON; reģistru piešķīrējs un plānotājs ir kopīgi. Produkta apgalvojums nav tikai tas, ka binārais fails pastāv. Apgalvojums ir tāds, ka mērķim specifiski SIMD kodoli tiek izvēlēti, kamēr grafs paliek tā pati aprēķina darbība.
GPU gadījumā avota materiāls nosauc PTX ģenerēšanu CUDA un ROCm, ar tensoru kodoliem, ko izmanto, ja kodola forma to atļauj. Šī pēdējā klauzula dara darbu. Aparatūras paātrinājums nav maģiski putekļi. Kodola forma vai nu atbilst tensoru kodeļa ceļam, vai neatbilst. Kompilatoram tas ir godīgi jāatklāj, pēc vajadzības jāpārvieto dati starp resursdatoru un ierīci, un jāsaglabā grafa nospiedums kā pierādījums tam, kas tiek izpildīts.
FPGA gadījumā pazemināšanas ceļš kļūst par aparatūras sarunu: Verilog sintēze, resursu novērtēšana, laika analīze un cauruļvadu plānošana paredzamai, ciklu precīzai uzvedībai. Šis ir tāds mērķis, kur roku vicināšana ir īpaši dārga. Ja pircējam ir nepieciešams stingrs reālais laiks, kompilatora virsmai ir jārunā ciklos, resursos un cauruļvados, nevis tikai ātrumā. Kera stāsts padara FPGA par tā paša grafa aizmugursistēmu, nevis pārrakstīšanu citas komandas rokās.
WASM gadījumā lapa nosauc 128 bitu SIMD malas un pārlūkprogrammas izvietošanai. Tas ir svarīgi, jo mala ir vieta, kur izvietošanas realitāte bieži saduras ar tīrību. Pārlūkprogramma, maza ierīce vai ierobežota izpildvide ne vienmēr var uzņemt to pašu steku kā serveris. Grafam vietējs pazemināšanas ceļš dod komandai iespēju pārnest to pašu aprēķinu šajā vidē, nepārvēršot malu par otru produktu.
Determinismam ir jāizdzīvo panākumos
Determinismu ir viegli solīt mazā telpā. Tas kļūst grūtāks, kad produkts gūst panākumus. Parādās vairāk lietotāju. Parādās vairāk aparatūras. Modelis pārvietojas no vienas mikroshēmas uz citu. Testa bāzes līnija, kas rakstīta vienam īpašumam, ir jāattiecina uz citu. Optimizācija, kas izskatās nekaitīga, maina reducēšanas secību. Ātrs ceļš parādās vienā izpildvidē, bet ne citā.
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.
Ja liels darbs tiek izpildīts daudzās mašīnās un kāds mezgls sabojājas, atkopšanās no kontrolpunkta nav tikai ērtība. Tā ir daļa no skaitļošanas darbspējas nodrošināšanas. Ja rezultāti tiek apkopoti uzticami, ir jādefinē apkopošanas semantika. Ja grafs ir adresēts pēc satura, sadalītajam ceļam ir jāsaglabā grafa identitāte, nevis jārada otra realitāte, tiklīdz darbs atstāj vienu mašīnu.
Šeit kļūst skaidra produkta interpretācija. Kera nav sintakses slānis ar sadalītu papildinājumu. Tā cenšas padarīt skaitļošanu pārnesamu gan pēc formas, gan aparatūras: viena programma, viens grafs, vairāki izpildes mērķi un ieraksts, ko var pārbaudīt. Sadalītā izpilde ir vēl viena vieta, kur nolaišanai ir jānes izpildes līgums.
Tas maina arī personāla stāstu. Bez kopīga kompilācijas ceļa kļūda, kas parādās tikai vienā platformā, var prasīt cilvēkus, kuri vienlaikus pārzina mikroshēmu, rīku ķēdi un izpildlaiku. Ar vienu grafu un kopīgu ceļu jautājums ir precīzāks: vai mainījās grafs, vai mainījās nolaišanas ceļš, vai mērķis pārkāpa definēto semantiku? Labāki jautājumi nenovērš smagu darbu. Tie neļauj smagajam darbam izplatīties nejauši.
Kāpēc kādam ir jāpieder ceļam
Nolaišana nevar palikt bez īpašnieka, kad tā nes rezultātus, uz kuriem cilvēki paļaujas. Grafs, kas darbojas CPU, GPU, FPGA un WASM, prasa vairāk nekā gudru attēlojumu. Tam ir nepieciešama dokumentācija, diagnostika, mērķa apgalvojumi, redaktora uzvedība, koda ģenerēšana, drošības kontroles, atbalsta sarunas un veids, kā pircējam precīzi pateikt, kas mainījās, kad mainās rezultāts.
Tas nepadara darbu mazāk tehnisku. Tas padara tehnisko darbu saistošāku. Kera pašlaik ir komerciāls Dweve produkts, nevis atvērtā koda laidiens: visas tiesības paturētas, pieejams saskaņā ar komerciālo licenci, radīts Nīderlandē un paredzēts organizācijām, kurām nepieciešams atbalstīts grafa ceļš, nevis tikai publicēts. Ja lapā ir teikts Rust 2021, grafa IR, pielāgots JIT, bez LLVM, CPU/GPU/FPGA/WASM, efektu izsekošana, īpašumtiesības pāri atmiņas telpām, iespēju drošība, sadalītā izpilde, C un Python iegulšana, CLI darbplūsmas, redaktora atbalsts un LSP rīki, tie nav dekoratīvi iekšējie elementi. Tās ir saistības, kurām jāiztur reālu darba slodžu novērtējums.
Iespēju lapa šajā ziņā ir uzmanīga. Tā apraksta dizaina mērķus un saka pārbaudīt pret savu darba slodzi. Šī atturība ir svarīga. Tā ir daudz veselīgāka nekā izlikšanās, ka katrs etalona skaitlis ir pārnesams. Sistēmai būtu jādod komandām veids, kā mērīt, pārbaudīt un salīdzināt savā vidē, nevis jāprasa tām pieņemt universālu ātruma stāstu.
Kādam ir jāpieder šim ceļam, jo katrs mērķis cenšas padarīt avotu mazāk universālu. Kera ir vieta, kur šīs mērķa atšķirības kļūst par skaidru kompilatora darbu, nevis folkloru, kas tiek nodota pēc kļūdas ziņojuma.
Diena, kad grafs kļūst par līgumu
Iedomājieties sākotnējo kļūdas ziņojumu vēlreiz, bet ar Kera jau darbplūsmā. Finanšu komanda apstiprina riska aprēķinu. Grafa nospiedums tiek ierakstīts. Pirmā izvietošana darbojas CPU. Vēlāk portfeļa analīzei tiek ieviests GPU ceļš. Vēl vēlāk zemākas latentuma cenu noteikšanai tiek izmantots FPGA ceļš. Jautājums katrā solī nav par to, vai jaunā aparatūra izklausās iespaidīgi. Jautājums ir par to, vai tiek nolaists tas pats grafs un vai mērķa semantika saglabā rezultātu identisku.
Saruna mainās. Platformas komanda var runāt par plānošanu un izmaksām. Kompilatora komanda var runāt par backends. Atbilstības komanda var runāt par nospiedumu. Uzņēmuma īpašnieks var jautāt, vai aparatūras maiņa ir operatīvs lēmums vai pārrakstīšana. Produkts dod viņiem visiem vienu objektu, uz kuru norādīt.
Tā ir satura adresētas IR klusā vērtība. Tā pārvērš starpplatformu izpildi no virknes pārliecinošu skaidrojumu par ierakstu. Tā padara grafu par kvīti. Tā ļauj vienam un tam pašam .keg failam apkalpot katru aizmugursistēmu. Tā organizācijai dod bāzes līniju, kas pieder aprēķinam, nevis vienai mašīnai.
Neviens kompilators nevar novērst nepieciešamību pēc inženiertehniskā sprieduma. Komandām joprojām rūpīgi jāizvēlas mērķi, godīgi jātestē darba slodzes, jāsaprot mērķu ierobežojumi un jāizlemj, kuri domēni prasa pilnīgu bitu identitāti. Bet Kera var padarīt šos lēmumus skaidrus. Tā var neļaut veiktspējas migrācijai nejauši kļūt par semantisko migrāciju.
Nolaišanas mācība
Kera ir svarīga, jo grūtākā daļa nav gudras nolaišanas idejas radīšana. Grūtākā daļa ir šīs idejas īstenošana visās garlaicīgajās vietās, kur inženierija vai nu kļūst uzticama, vai kļūst par folkloru: diagnostika, zaļie koki, tipu jaucējsummas, aizņēmumu pārbaude, fiksētā punkta optimizācija, invariantu validācija, .keg serializācija, aizmugursistēmas emisija, drošības politika, audita žurnāli, redaktora atbalsts un mērķim specifiska izpilde.
Nolaišana ir darbs, jo katrs mērķis cenšas padarīt avotu mazāk universālu. Deterministiskā kompilatoru inženierija ir disciplīna, kas atsakās ļaut tam notikt klusi. CPU vēlas vektorus. GPU vēlas kodolus. FPGA vēlas ciklus. WASM vēlas ierobežojumus. Organizācija vēlas vienu atbildi. Keras uzdevums ir saglabāt aprēķina nozīmi, vienlaikus ļaujot katram mērķim darīt to, kas tam padodas.
Tā ir inženiertehniska forma, nevis papīra abstrakcija. Tai ir pircējs, atteices veids, faila formāts, kompilatora ceļš un darbības sekas. Solījums nav tas, ka aparatūra kļūst vienkārša. Solījums ir tas, ka sarežģītība tiek attēlota, nolaista, pārbaudīta un pārvaldīta.
Kad parādās nākamais gandrīz pareizais skaitlis, komandai nevajadzētu sākt ar folkloru par to, kura mašīna ko izpildīja. Tai vajadzētu sākt ar grafu. Vai pirksta nospiedums sakrita? Kurš aizmugursistēmas emitēja kodu? Kuras iespējas tika piešķirtas? Kura mērķa semantika tika piemērota? Kurš artefakts tika saglabāts? Tie ir produkta jautājumi. Kera pastāv, jo tie ir arī kompilatora jautājumi.