Dweve

Indblik i Core: 2.900+ operationer på tværs af 12 backends

Hundredtusindvis af håndoptimerede kerner. 2.900+ operationer i 76 kategorier. 25 talformater og 12 backends. Et indblik i Core, Dweves beregningsfundament.

Indblik i Core: 2.900+ operationer på tværs af 12 backends

Hvad fortæller antallet af operationer?

Matrixmultiplikation lyder som én enkelt opgave. Implementeringen afhænger af, hvad værdierne betyder, hvordan de lagres, hvordan mellemresultater summeres, og hvilken hardware der udfører arbejdet. En pakket binær matrix og en matrix med flydende kommatal kan dele en abstrakt operation, men kræve forskellige regneregler og forskellig kode.

Core er Dweves beregningsfundament til træning og inferens. Det offentlige katalog omfatter hundredtusindvis af håndoptimerede kerner på tværs af 2.900+ operationer i 76 kategorier, 25 talformater og 12 backends. Tallene beskriver forskellige dele af systemet. En operation angiver beregningen. Et talformat definerer repræsentationen. En backend angiver et eksekveringsmål. En kerne implementerer en bestemt kombination af valg.

Det er vigtigere at forstå denne forskel end at betragte kataloget som ét stort antal funktioner. En udvikler skal vide, om den nødvendige kombination findes, og hvilken kontrakt den følger.

2.900+ operationer i 76 kategorier; 25 talformater; 12 backends. Hundredtusindvis af håndoptimerede kerner implementerer de understøttede eksekveringsvalg.

Beregningen og dens repræsentation hænger sammen

Tag en reduktion: En række værdier kombineres til ét resultat. Ordet »sum« efterlader flere spørgsmål ubesvarede. Er inputtene fortegnede heltal, fastkomma- eller flydendekomma-værdier? Hvilken repræsentation bruges til det akkumulerede resultat? Hvad sker der, når repræsentationen ikke kan rumme den næste værdi?

Core knytter disse valg til operationen. Eksekveringskontrakten omfatter datatype, bredde, pakning, akkumulator, backend, instruktionssæt, dispatchpolitik og determinismetilstand. Ændres ét af dem, kan beregningens betydning ændres, selv om operationens navn er det samme.

De 25 talformater omfatter binære, ternære, heltals-, fastkomma-, adaptive og flydendekommafamilier. Familienavnet er kun udgangspunktet for at beskrive aritmetikken. Bredde, fortegn, skala og lagerlayout har også betydning. Kataloget skal derfor læses som en samling understøttede kombinationer, ikke som et løfte om, at alle operationer findes i ethvert tænkeligt format på alle mål.

Derfor kan et udvekslingsformat heller ikke besvare alle spørgsmål om eksekvering. ONNX beskriver en beregningsgraf med typede input, output og operatorer. Det giver systemer en fælles modelbeskrivelse, men runtime-miljøet skal stadig implementere operatorerne. ONNX-dokumentationen om begreber forklarer forskellen mellem grafrepræsentation og eksekvering.

Læs et eksekveringsvalg ud fra operationen, repræsentationen, akkumulatoren, backenden og reglerne for reproduktion. Diagrammet viser et repræsentativt udsnit, ikke en dækningsmatrix.

12 backends med eksplicitte eksekveringsvalg

Cores 12 backends spænder over skalar eksekvering, CPU-instruktionssæt samt GPU- og portable mål. De offentlige mål omfatter Scalar, SSE2, AVX2, AVX-512, NEON, SVE2, CUDA, ROCm, Metal, Vulkan, WebGPU og WASM. Navnene beskriver eksekveringsveje i Core, ikke separate modelversioner.

Dispatch vælger en understøttet implementering til operationen og dens eksekveringskontrakt på den aktuelle vært. Den valgte vej registreres sammen med eksekveringscellen, værten og begrundelsen. Derfor kan en kørsel gennemgås ud fra de valg, den faktisk traf.

Portabilitet har stadig grænser. WebAssembly-dokumentationen skelner eksempelvis mellem et portabelt binærformat og de API’er, værtsmiljøet stiller til rådighed. Kørsel i og uden for en browser kan give adgang til forskellige grænseflader. WebAssembly-dokumentationen om portabilitet giver nyttig kontekst for denne forskel. En backendbetegnelse alene forklarer ikke, hvilket driftsmiljø en applikation bruger.

Cores plads i Dweve

Core bruger primitives-biblioteket til grundlæggende operationer og samler dem i beregningssystemet. Loom er bygget oven på Core og bruger solvers-biblioteket til ræsonnement. Hver del har dermed et tydeligt ansvar: primitives leverer grundoperationer, Core udfører beregninger, og Loom bygger ræsonnement oven på fundamentet.

Dweve er tjenesten. Fabric er dens API og portal, hvor mennesker og applikationer får adgang til tjenesten. Fabric overtager hverken Cores beregningsopgave eller Looms ræsonnementsopgave. Grænsefladen og systemerne bag den har forskellige formål.

Core bruger primitives-biblioteket. Loom er bygget oven på Core og bruger solvers-biblioteket. Fabric er API’et og portalen til Dweve-tjenesten.

Tag udgangspunkt i den eksekvering, du har brug for

Når et beregningssystem skal vurderes, så begynd med en konkret beregning og den nødvendige repræsentation. Spørg derefter, hvilken backend der udfører den, hvilke regler der gælder for akkumulator og pakning, og hvilken kontrakt for reproducerbarhed der er deklareret. Sådan bliver kataloget brugbart for et team.

Cores offentlige tal beskriver katalogets bredde. Eksekveringskontrakten forklarer, hvordan det skal læses. Begge dele hører med: hvilke opgaver systemet dækker, og hvad en bestemt implementering betyder i praksis.