Den neste viktige AI-distribusjonen trenger kanskje ikke å kjøre i en enorm nettskyklynge. Den kan kjøre inne i et kamera, en fabrikkrobot, et kjøretøy, en medisinsk enhet eller en betalingsterminal, der båndbredde, strøm, latenstid, personvern og driftskostnader betyr mer enn å ha den størst mulige modellen.

Dette skiftet skaper en annen type AI-arbeid. Teamene trenger fortsatt modellutviklere, men de trenger også folk som kan få modeller til å passe til faktisk maskinvare, måle kvalitet under begrensninger, integrere opprinnelige inferenskjøringsmiljøer og avgjøre når en mindre modell er god nok til en oppgave.

Dette er den mindre glamorøse halvdelen av modellkappløpet: ikke bare å forbedre intelligensen, men å gjøre intelligensen mulig å distribuere.

Hvorfor mindre modeller endrer distribusjonsspørsmålet

En nettskymodell kan ofte bruke mer datakraft på å besvare en forespørsel. Et innebygd system kan ikke anta en pålitelig nettverkstilkobling, et ubegrenset batteri eller et romslig budsjett per kall. En robot som venter flere hundre millisekunder på hver persepsjons- eller kontrollavgjørelse, kan være utrygg eller ineffektiv. Et produkt som sender hvert bilde eller hver lydprøve til et API, kan medføre uakseptable kostnader knyttet til personvern og dataoverføring.

Disse begrensningene endrer utviklingsmålet. Spørsmålet blir: Hva er den minste modellen som oppfyller de nødvendige målene for nøyaktighet, latenstid, minne, energibruk og pålitelighet på den faktiske enheten?

Dette spørsmålet gjelder langt mer enn forbrukerdingser. Det er viktig for produsenter som inspiserer deler på en produksjonslinje, logistikkselskaper som sporer utstyr, sykehus som behandler sensitive signaler, og programvareleverandører som prøver å tilby AI-funksjoner uten at inferensregningene blir deres største variable kostnad.

Tre teknikker bak skiftet

Kvantisering representerer modellvekter, og noen ganger aktiveringer, med tall med lavere presisjon. Overgangen fra formater som BF16 eller FP16 til 8-bits- eller 4-bitsrepresentasjoner kan redusere minnekravene og kan forbedre gjennomstrømningen, avhengig av maskinvaren og implementeringen. Avveiningen er at lavere presisjon kan redusere kvaliteten eller skape numeriske problemer, så dette må testes i stedet for å antas å være ufarlig.

Destillering trener en mindre studentmodell til å gjengi nyttig atferd fra en større lærermodell. Studenten kan lære av lærerens resultater, mellomliggende signaler eller oppgavespesifikke eksempler. Den trenger ikke å gjenskape alle egenskapene til den større modellen; den trenger å utføre måloppgaven godt nok.

Optimalisert inferens tilpasser kjøringen til et bestemt kjøremiljø og en bestemt prosessor. Det kan omfatte valg av kjerner, kompilering av grafer, bunting, minneplanlegging, mellomlagring og maskinvarespesifikk akselerasjon. NVIDIA’s TensorRT Model Connect, som er kunngjort i offentlig forhåndsvisning, er ett eksempel på verktøy utviklet for å gjøre støttede Hugging Face- eller lokale sjekkpunkter om til TensorRT-inferens fra ende til ende uten en mellomliggende ONNX-eksport. Det oppgitte målområdet omfatter robotikk-, enhets- og plattformarbeidsbelastninger.

Disse teknikkene forsterker hverandre. Destillering kan produsere en kompakt modell; kvantisering kan redusere størrelsen ytterligere; et optimalisert kjøremiljø kan avgjøre om den resulterende modellen faktisk er rask på den tiltenkte brikken.

Et nyttig resultat er ikke det samme som en mindre fil

Modellkomprimering bør behandles som en produkt- og systemøvelse, ikke som et triks for topplister. En modell som er 40 prosent mindre, men ikke oppdager kritiske objekter i dårlig belysning, kan være dårligere for en lagerrobot. En språkmodell som er billig per token, men genererer ugyldige strukturerte resultater, kan øke arbeidet med reparasjoner i etterfølgende systemer. En modell som presterer godt i en referansetest, kan svikte når termisk struping, kamerastøy, ustabil tilkobling eller uvanlige brukerinndata kommer inn i bildet.

Liquid AIs rapport om kvantiseringsbevisst destillering for selskapets små LFM2.5-modeller er en nyttig illustrasjon av målet. Selskapet rapporterte at de beholdt 96.5 % til 97.4 % av BF16-ytelsen, samtidig som minnebruk og gjennomstrømning for Q4_0 ble bevart. Disse tallene er rapportert av selskapet og gjelder spesifikke modeller; de bør ikke generaliseres til alle arkitekturer. Men de viser hvilken type sammenligning fagfolk bør se etter: bevart kvalitet målt sammen med minnebruk og hastighet, ikke bare et komprimeringsforhold.

For en distribusjon bør godkjenningstesten minst omfatte:

  • oppgavekvalitet på representative, vanskelige eksempler;
  • maksimalt minne- og lagringsbehov;
  • latenstid for første svar og i stabil drift;
  • gjennomstrømning ved realistisk samtidighet;
  • energiforbruk eller termisk atferd der det er relevant;
  • feilatferd når inndata mangler, er støyende eller ligger utenfor distribusjonen;
  • kostnaden og den operative belastningen ved å oppdatere modellen.

De nøyaktige målene varierer fra produkt til produkt. Et kamera kan være opptatt av bilder per sekund og falske negative. Et talegrensesnitt kan være opptatt av responstid fra ende til ende. En robot kan være opptatt av tidsfrister for kontrollsløyfen og sikker reserveatferd. Poenget er å knytte modelevalueringen til de fysiske eller økonomiske konsekvensene av svikt.

Hvor det nye arbeidet oppstår

Den voksende muligheten er ikke begrenset til dem som utvikler arkitekturer. Den omfatter flere praktiske roller:

  • Inferensingeniører profilerer modeller på målakseleratorer, velger kjøretidsmiljøer, optimaliserer grafer og diagnostiserer flaskehalser knyttet til latenstid eller minne.
  • Ingeniører innen modellkomprimering utvikler kvantiserings- og destillasjonspipelines, velger kalibreringsdata og måler kvalitetstap etter oppgave og segment.
  • Edge ML-ingeniører pakker modeller for mobile, innebygde, industrielle eller automotive miljøer og håndterer oppdateringer under begrenset tilkobling.
  • Programvareingeniører innen robotikk kobler persepsjonsmodeller til sensorer, planleggingssystemer og sikkerhetsbegrensninger der timing er viktig.
  • Maskinvarebevisste produktingeniører avgjør om en arbeidsbelastning hører hjemme på en enhet, i edge-laget eller i skyen – og utformer smidige overleveringer mellom dem.
  • Spesialister på utrulling og validering bygger testsett som inkluderer termiske forhold, strømforbruk, nettverk og virkelige miljøforhold.

Det finnes også arbeid for applikasjonsutviklere. Et produktteam trener kanskje ikke en modell, men må likevel velge et modellformat, integrere et inferensbibliotek, håndtere operatorer som ikke støttes, eksponere konfidens- eller avståelsesatferd og sørge for at oppgraderinger kan reverseres.

Å utforme skillet mellom sky og edge blir en designferdighet

Små modeller eliminerer ikke skymodeller. De gjør hybridsystemer mer attraktive. En enhet kan bruke en kompakt modell til umiddelbar deteksjon og deretter sende utvalgte hendelser til en større modell for forklaring eller dypere analyse. En robot kan beholde sikkerhetskritisk persepsjon lokalt, samtidig som den bruker skyen til læring på tvers av hele robotflåten. Et kundestøtteprodukt kan sende rutinemessig klassifisering til en liten modell og eskalere tvetydige tilfeller til en mer kapabel modell.

Denne arkitekturen kan redusere båndbreddebruk og latenstid, men introduserer beslutninger som trenger et tydelig ansvar. Hvilken informasjon sendes bort fra enheten? Hva skjer uten tilkobling? Hvilken modellversjon produserte en handling? Kan enheten trygt rulle tilbake? Hvordan overvåkes ytelsen når hver maskinvarekonfigurasjon oppfører seg forskjellig?

Dette er utrullingsspørsmål, ikke bare modellspørsmål. De belønner fagfolk som forstår grensesnittene mellom maskinlæring, innebygde systemer, nettverk, produktkrav og drift.

En praktisk læringsvei

Hvis du vil bevege deg mot dette arbeidet, bør du bygge én liten, men målbar utrulling i stedet for bare å samle modellsertifikater. Begynn med en oppgave som har et tydelig mål, for eksempel bildeklassifisering, gjenkjenning av nøkkelord, dokumentkategorisering eller en kompakt lokal assistent.

  1. Etabler en referanse. Registrer kvalitet, modellstørrelse, minnebruk, latenstid og gjennomstrømning ved hjelp av et reproduserbart testsett.
  2. Kvantiser den. Sammenlign minst én versjon med lavere presisjon med referansen. Dokumenter hvilke eksempler som endres, og om feilene konsentrerer seg i en viktig kategori.
  3. Prøv destillasjon eller oppgavespesifikk finjustering. Mål om en mindre modell kan bevare atferden produktet faktisk trenger.
  4. Kjør den på målmaskinvaren. En skrivebordsbenchmark er ikke dokumentasjon på ytelsen på en telefon, mikrodatamaskin, GPU, akselerator eller robotdatamaskin.
  5. Pakk utrullingen. Inkluder forbehandling, etterbehandling, versjonsmetadata, helsesjekker og en reservesti.
  6. Skriv rapporten om avveiningene. Forklar hvorfor den valgte modellen vinner på tvers av kvalitet, latenstid, minne, energi, personvern og kostnad – ikke bare hvorfor den har høyest poengsum.

Nyttige verktøy avhenger av målstacken, men de overførbare ferdighetene er de samme: profilering, numerisk resonnering, datavalg, testutforming, feilsøking og tydelig kommunikasjon av avveininger. Lær å lese en modellgraf, undersøke operatørstøtte, identifisere minneflytting som en flaskehals og skille teoretisk beregningskapasitet fra målt latenstid fra ende til ende.

Karrieresignalet

Det viktige karriereskiftet er å gå fra å spørre «Hvilken modell er smartest?» til å spørre «Hvilket system leverer det nødvendige resultatet under de virkelige begrensningene?» Store modeller vil fortsatt være verdifulle, særlig for åpen problemløsning og kompleks generering. Men mange kommersielle oppgaver og oppgaver i den fysiske verden er avgrensede nok til at en kompakt, rask og privat modell kan være det bedre produktet.

Det skaper rom for fagfolk som kan bygge bro mellom forskning og utrulling. Vinnerne vil ikke alltid være teamene med den største modellen. Det kan være teamene som forstår arbeidsbelastningen, komprimerer intelligent, benchmarker ærlig og leverer et pålitelig system på den tilgjengelige maskinvaren.

For en AI-karriere er dette en varig lærdom: intelligens er bare én del av leveransen. Den andre delen er å få den til å passe.