Hvorfor AI-inferens, ikke trening, er den neste store ingeniørutfordringen

For det siste tiåret har fokuset på kunstig intelligens vært monopolisert av trening. Gjennombruddene har i stor grad kommet fra massive beregningskluster, trillion-parametermodeller og de milliarder av dollar som er brukt på å lære systemer å “tenke”. Vi har behandlet AI-utvikling i stor grad som et byggeprosjekt: bygging av skyskraperen av intelligens. Men nå som denne skyskraperen er bygget, er den virkelige utfordringen å finne ut hvordan man kan fasilitere de millioner som trenger å bo og operere innen den samtidig. Dette skifter fokuset for AI-forskere og ingeniører fra trening (aksen av å skape intelligens) til inferens (aksen av å bruke den). Mens trening er en massiv, engangs kapitalutgift (CapEx), er inferens en pågående driftsutgift (OpEx) som fortsetter uendelig. Når bedrifter distribuerer agenter som betjener millioner av brukere døgnet rundt, oppdager de en hard realitet: inferens er ikke bare “trening i revers”. Det er en grunnleggende annen, og kanskje hardere, ingeniørutfordring.

Hvorfor inferenskostnader betyr mer enn noen gang

For å forstå ingeniørutfordringen, må man først forstå den underliggende økonomiske imperativ. I treningsfasen er ineffektivitet tolerabel. Hvis en treningskjøring tar fire uker i stedet for tre, er det en irritasjon. I inferens, derimot, kan ineffektivitet være katastrofalt for bedrifter. For eksempel kan trening av en frontiermodell kanskje koste 100 millioner dollar. Men å distribuere denne modellen for å svare på 10 millioner forespørsler per dag kan overgå denne kosten på noen måneder hvis den ikke er optimalisert. Dette er hvorfor vi er vitne til en markedsendring, med inferensinvesteringer prognostisert å overgå treningsinvesteringer.
For ingeniører skifter dette målstolpene. Vi optimerer ikke lenger for gjennomstrømming (hvor raskt kan jeg prosessere denne massive datamengden?). Vi optimerer for latency (hvor raskt kan jeg returnere en enkelt token?) og samtidighet (hvor mange brukere kan jeg betjene på en GPU?). Den “brutale” tilnærmingen som dominerte treningsfasen ved å bare legge til mer beregning, fungerer ikke her. Du kan ikke kaste mer H100 på et latencyproblem hvis flasken er minnebandbredden.

Minneveggen: Den virkelige flasken

Den lite kjente sannheten om Large Language Model (LLM) inferens er at det sjelden er begrenset av beregning; det er begrenset av minne. Under trening prosesserer vi data i massive batcher, og holder GPUens beregningsenheter fullt utnyttet. I inferens, spesielt for sanntidsapplikasjoner som chatbots eller agenter, kommer forespørsler sekvensielt. Hver token som genereres, krever at modellen laster sine milliarder parametre fra høy-båndvidde-minne (HBM) inn i beregningskjerne. Dette er “Minneveggen“. Det er som å ha en Ferrari-motor (GPU-kernen) fast i trafikk (den begrensede minnebandbredden).
Denne utfordringen driver ingeniørteam til å tenke om systemarkitekturen ned til silikon-nivå. Dette er hvorfor vi ser oppblomstringen av Linear Processing Units (LPUs) som de fra Groq, og spesialiserte Neural Processing Units (NPUs). Disse chipene er designet for å omgå HBM-flasken ved å bruke massive mengder on-chip SRAM, og behandle minnetilgang som en kontinuerlig datastrøm i stedet for en enkel hent-operasjon. For programvareingeniøren signaliserer dette slutten på “default to CUDA”-æraen. Vi må nå skrive kode som er hardware-bevisst, og forstå nøyaktig hvordan data flytter seg gjennom ledningen.

Det nye grenselandet for AI-effektivitet

Fordi vi ikke alltid kan endre hardware, ligger den kommende grensen for ingeniørarbeid i programvareoptimalisering. Dette er hvor noen av de mest innovative gjennombruddene skjer for tiden. Vi er vitne til en renessanse av teknikker som redefinerer hvordan datamaskiner implementerer og kjører neurale nettverk.

• Kontinuerlig batching: Tradisjonell batching venter på at en “buss” fyller før den avgår, noe som introduserer forsinkelser. Kontinuerlig batching (pionert av rammeverk som vLLM) fungerer som et tunnelbanesystem, og lar nye forespørsler slutte seg til eller forlate GPU-prosessortoget på hver iterasjon. Det maksimerer gjennomstrømming uten å ofre latency, og løser et komplekst planleggingsproblem som krever dypt OS-nivå ekspertise.

• Spesulativ dekoding: Denne teknikken anvender en liten, rask og billig modell for å utarbeide en respons, mens en større, langsommere og mer kapabel modell verifiserer den i parallell. Den bygger på at verifisering av tekst er langt mindre komputasjonelt kostbar enn generering av tekst.
• KV Cache Management: I lange samtaler vokser “historien” (nøkkel-verdi-cachen) raskt, og forbruker store mengder GPU-minne. Ingenicører implementerer nå “PagedAttention“, en teknikk inspirert av virtuell minnehåndtering i operativsystemer. Denne teknikken bryter minnet ned i fragmenter og håndterer det ikke-kontinuerlig.

Den agente kompleksiteten

Hvis standard inferens er hard, gjør Agentic AI det eksponentielt harder. En standard chatbot er statisk: Bruker spør, AI svarer, prosessen slutter. En AI-agent, derimot, har en loop. Den planlegger, kjører verktøy, observerer resultater og itererer. Fra et ingeniørperspektiv er dette en mareritt. Denne arkitektoniske skiftet introduserer flere grunnleggende utfordringer:

1. Tilstandshåndtering: Inferensmotoren må vedlikeholde “tilstanden” til agentens tenkeprosess over flere steg, ofte over flere minutter.
2. Uendelige løkker: I motsetning til en forutsigbar fremover-passering, kan en agent bli fast i en resonneringsløkke. Ingeniører må utvikle robuste “vaktmestre” og “sikringsbrytere” for probabilistisk kode, noe som er et helt nytt felt.
3. Variabel beregning: En enkelt brukerforespørsel kan utløse en enkelt inferensanrop, mens en annen kan utløse femti. Å håndtere last og autoskalering av infrastruktur når hver forespørsel har så ekstrem variasjon, krever en helt ny klasse av orkestreringslogikk.

Vi beveger oss essensielt fra “å betjene modeller” til “å orkestrere kognitive arkitekturer.”

Å bringe AI til hverdagsenheter

Til slutt vil grensene for energi og nettverksforsinkelse uunngåelig tvinge inferens til kanten. Vi kan ikke forvente at hver smart lyspære, autonom bil eller fabrikkrobot skal sende sine forespørsler gjennom et datasenter. Ingeniørutfordringen her er komprimering. Hvordan kan du få en modell som lærte fra hele internettet på en chip som er mindre enn en fingernegl, og som kjører på en batteri?
Teknikker som kvantisering (reduksjon av presisjon fra 16-bit til 4-bit eller til og med 1-bit) og modelldestillasjon (å lære en liten elevmodell å mime en stor lærer) blir standardpraksis. Men den virkelige utfordringen er å distribuere disse modellene til et fragmentert økosystem av milliarder av enheter som Android, iOS, innbyggede Linux, tilpassede sensorer, hver med sine egne hardwarebegrensninger. Det er “fragmenteringsmarerittet” fra mobilutvikling, multiplisert med kompleksiteten til neurale nettverk.

Bunnen linjen

Vi går inn i “Dag 2”-æraen for Generativ AI. Dag 1 var om å demonstrere at AI kunne skrive poesi. Dag 2 er om å ingeniørere, å gjøre denne evnen mer pålitelig, rimelig og ubenyttet. Ingeniørerne som vil definere det neste tiåret er ikke nødvendigvis de som oppfinner nye modellarkitekturer. De er systemingeniører, kernelhakkere og infrastrukturarkitekter som kan finne ut hvordan de kan betjene en milliard token per sekund uten å smelte strømnettet eller gjøre selskapet konkurs. AI-inferens er ikke lenger bare en kjøringsdetalj. Det er produktet. Og å optimalisere det er den neste store ingeniørutfordringen.