211service.com
Suksessen til maskinlæring hviler på skalerbarhet
Levert av Væpne
Steve Roddy er visepresident for Machine Learning Group i Arm.
Endring er konstant, og kunstig intelligens (AI) og maskinlæring (ML) endrer alt på nytt. For utviklere som prøver å bringe nye produkter og tjenester til markedet som utnytter AI og ML, blir utfordringene forsterket av det faktum at teknologilandskapet fortsatt utvikler seg.
I motsetning til den tradisjonelle innebygde sektoren, som viser et lineært forhold mellom behovet for mer prosessytelse og måten ytelsen brukes på, er det en forskjell mellom AI og ML, og maskinvareplattformene de vil kjøre på: ML er i konstant endring.
Besøk innholdssenteret
Skalerbar maskinlæring
Bevegelsen bort fra sekvensiell tenkning
ML vil sannsynligvis bli brukt overalt, akkurat som tradisjonell innebygd programvare brukes i dag. Men i motsetning til tradisjonell kode, som er skrevet linje for linje i et sekvensielt mønster (selv om autogenerering brukes), vil ML bli distribuert som modeller, skapt av rammeverk som lærer. Modeller vil, i en veldig reell forstand, bli født. Og som enhver form for avkom, kan du aldri være sikker på akkurat hva du vil få før den kommer.
For utviklere vil den forutsigbare naturen til innebygd programvare forsvinne eller endre seg betydelig. Det utvikles verktøy som hjelper til med å forutsi hvordan en modell vil fungere, eller vil pålegge visse begrensninger på måten modellen er utformet for å overholde plattformen, men disse er begynnende og på ingen måte et universalmiddel. Det er sannsynlig at tilpasning til systemets begrensninger vil føre til tap i nøyaktighet. Naturen til ML er at den leverer nøyaktigheten som er nødvendig på den medfølgende maskinvaren. Det følger derfor at hvis maskinvaren er i stand til å tilpasse seg, kan du unngå å gå på akkord med nøyaktigheten.
Det er ingen enhet som passer alle for maskinlæring. Ingeniører må utforme systemer som tilbyr skalerbar ytelse og kan justere typen prosesseringsressurs de leverer basert på oppgaven.
Måten en modell utfører på en fast maskinvareplattform vil også endre seg. Den forutsigbare naturen til innebygd programvare har lenge vært en bærebjelke i design; ideen om at kodens egenskaper vil endre seg etter at den har blitt distribuert, er faktisk innholdet i ingeniørers mareritt. Innebygde systemer er utviklet innenfor ytelsesparametere, en konvolutt basert på effekt, kostnad, varmespredning, størrelse, vekt og et hvilket som helst antall målbare elementer som kan byttes ut mot hverandre for å nå definerte mål. Dette er i hovedsak hvordan innebygd utvikling alltid har blitt gjort, men det er ikke slik det vil bli gjort i fremtiden.
Skalerbarhet er den nye normen
I stedet må ingeniører designe systemer som tilbyr skalerbar ytelse, som er i stand til å dynamisk justere typen prosesseringsressurs de leverer basert på den aktuelle oppgaven. Dette er annerledes enn det innebygde ingeniører kan være komfortable med akkurat nå. I noen år har innebygde prosessorer hatt muligheten til å variere sin driftsfrekvens og forsyningsspenning basert på arbeidsbelastning. I hovedsak kan prosessorens kjerne gå saktere når den ikke er opptatt; nedskalering av hovedklokkefrekvensen betyr direkte at færre transistorer slås på og av per sekund, noe som sparer strøm. Når kjernen virkelig trenger å bli opptatt, skaleres klokkefrekvensen opp, noe som øker gjennomstrømningen. Det er en sammenheng mellom forsyningsspenning og klokkefrekvens; ved å redusere begge, forsterkes mengden energi som spares. Denne typen skalering vil ikke være nok til å levere kraften og ytelsen som trengs i de innebygde enhetene som nå utvikles for å kjøre ML-modeller.
Det er fordi måten vi måler ytelse på kommer til å endre seg. Akkurat nå måles prosessorer typisk i form av operasjoner per sekund; vi måler det nå i teraops, eller billioner av operasjoner per sekund (TOPS). Å bruke TOPS til å måle ytelsen til en prosessor som utfører slutninger vil ikke gi like mye mening som det gjør når du kjører sekvensiell kode, fordi måten modellen kjører på ikke er direkte sammenlignbar med vanlig innebygd programvare. ML-prosessorer vil bli målt på nøyaktigheten de oppnår når de leverer et gitt antall slutninger per sekund for en gitt strømmengde. Vi har ikke en standardverdi for det ennå, men vi kan si at det å bare øke klokkefrekvensen for å møte slutningene/s-målet ikke er garantert og vil sannsynligvis sprenge strømbudsjettet, uten å forbedre nøyaktigheten.
Veien til inferens er full av variabler
Hvorfor? Årsaken ligger i måten ML-modeller fungerer på. Med mange lag med sannsynlighet for å gå gjennom, er det like mange variabler som kan endre banen gjennom disse lagene. Den virkelige verden vil ha en mye større innvirkning på måten ML-modeller utføres på, med langt mer variasjon enn lineær sekvensiell innebygd kode. Ta naturlig språkbehandling og talegjenkjenning som et eksempel: Talerens stemme og kadens vil alle spille en rolle i modellens effektivitet, men det kan også være samspill mellom disse parameterne som resulterer i en annen opplevelse under ulike forhold. Bare å øke prosessorens hastighet i dette tilfellet vil kanskje ikke returnere det ønskede resultatet.
Videre er en av de definerende egenskapene til ML dens evne til å lære. Selv om forsterkende læring ikke brukes i selve enheten, er det fortsatt mulig at data vil bli matet tilbake til en stormaskin der modellen kan justeres basert på resultatene som er observert. Selv uten denne tilbakemeldingen er det sannsynlig at modellen vil bli forbedret over tid, rent på grunn av måten ML fortsatt utvikler seg på. Dette vil føre til at en ny modell blir opprettet og distribuert (ved bruk av for eksempel trådløse oppdateringer), som da vil ha potensielt helt andre behandlingskrav, som fungerer annerledes under samme eller lignende forhold.
Den skiftende naturen til ML-modeller betyr at mens dagens CPU-arkitekturer kan brukes og blir brukt for ML, kan dagens arkitekturer nesten helt sikkert ikke gi den mest optimale måten å utføre dem på. Ja, modeller kan kjøre på CPUer ved å bruke alle de vanlige ALU-funksjonene som finnes i de fleste prosessorer. De kan også dra nytte av svært parallelle arkitekturer som har massivt flere forekomster av disse funksjonene, for eksempel GPUer, men det er allerede klart at GPUer ikke er den beste måten å utføre ML-modeller på. Faktisk har vi allerede eksempler på nevrale prosesseringsenheter, og halvlederindustrien jobber hardt med å utvikle helt nye arkitekturer for å utføre ML-modeller mer effektivt. På et tidspunkt blir enten maskinvaren eller programvaren fikset for å la den andre gå videre. Den riktige måten å løse dette på er å forplikte seg til et felles programvarerammeverk som kan brukes på tvers av kompatible, men skalerbare maskinvareplattformer, slik at begge utvikler seg sammen.
Fleksible heterogene arkitekturer
Ved å gjøre dette kan skalerbarheten som trengs for å støtte AI og ML, utvides fra kjernen av nettverket til ytterkanten, uten å låse arkitekturen til en fast plattform. Project Trillium er Arms heterogene ML-databehandlingsplattform som består av kjerner og programvare. Arm utvider Project Trillium til å adressere ML på hvert punkt i nettverket. Den vanlige programvareplattformen her er Arms nevrale nettverksprogramvarebiblioteker, Arm NN, som kan kjøre på tvers av Arm-prosessorplattformer og også er kompatible med ledende tredjeparts nevrale nettverksrammeverk. Maskinvaren inkluderer de eksisterende Arm Cortex-A- og Arm Mali GPU-prosessorene som blir forbedret for AI og ML, samt helt nye prosessorer for ML-akselerasjon.
Når det gjelder skalerbarhet, kan og kjører ML på prosessorer som er så små og ressursbegrensede i Cortex-M-klassen, og like funksjonsrike som Mali GPU-ene. Imidlertid er ekte skalerbarhet nødvendig for å møte alle behovene til ML fra kjernen til kanten, som er der neste trinn i prosessorutviklingen kommer inn. Nevrale prosessorenheter, eller NPU-er, representerer den nye generasjonen prosessorarkitektur som vil støtte ML i flere applikasjoner.
Only Arm tilbyr dette nivået av skalerbarhet på tvers av ML-landskapet. Å velge skalerbare arkitekturer som kan være sammensatt av MCUer, CPUer, GPUer og NPUer vil hjelpe fremtidssikre maskinvareplattformer mot nye programvareapplikasjoner som ikke engang er utviklet ennå.
Det er mange ukjente, når det gjelder hvilke ML-modeller vi skal lage i fremtiden, hvor mye datakraft de trenger for å levere ønsket nøyaktighet, hvor raskt informatikere vil være i stand til å forbedre modellene slik at de trenger mindre kraft – alt av disse hensynene har en direkte innvirkning på den underliggende maskinvaren. Det eneste vi vet er at å møte sluttbrukernes endrede forventninger krever en fleksibel og skalerbar plattform.