Hvorfor AI-inferens, ikke træning, er den næste store ingeniørudfordring

For det sidste årti har fokus i kunstig intelligens været monopoliseret af træning. Gennembruddene er overvejende kommet fra massive beregningskluster, trillion-parameter-modeller og de milliarder af dollars, der er investeret i at lære systemer at “tænke”. Vi har behandlet AI-udvikling overvejende som et byggeprojekt: opførelse af intelligensens skyskraber. Men nu, hvor denne skyskraber er bygget, er den virkelige udfordring at finde ud af, hvordan man kan facilitere de millioner, der skal bo og fungere inden for den samtidig. Dette skifter fokus for AI-forskere og ingeniører fra træning (aktien af at skabe intelligens) til inferens (aktien af at bruge den). Mens træning er en massiv, engangs kapitaludgift (CapEx), er inferens en løbende driftsudgift (OpEx), der fortsætter uendeligt. Da virksomhederne deployer agenter, der betjener millioner af brugere døgnet rundt, opdager de en hård realitet: inferens er ikke bare “træning i omvendt rækkefølge”. Det er en fundamentalt anden og måske sværere ingeniørudfordring.

Hvorfor Inferensomkostninger er vigtigere end nogensinde

For at forstå den ingeniørudfordring, skal man først forstå den underliggende økonomiske imperativ. I træningsfasen er ineffektivitet tolerabel. Hvis en træningsløb tager fire uger i stedet for tre, er det en irritation. I inferens kan ineffektivitet dog være katastrofal for virksomheden. For eksempel kan træning af en frontier-model koste 100 millioner dollars. Men at deployere denne model til at besvare 10 millioner forespørgsler om dagen kan overgå denne omkostning på få måneder, hvis den ikke er optimeret. Dette er årsagen til, at vi oplever en markedsændring, hvor investeringer i inferens forventes at overgå investeringer i træning.
For ingeniører skifter dette målstængerne. Vi optimerer ikke længere for gennemstrømning (hvor hurtigt kan jeg behandle denne massive dataset?). Vi optimerer for latency (hvor hurtigt kan jeg returnere en enkelt token?) og samtidighed (hvor mange brugere kan jeg betjene på en enkelt GPU?). Den “brute force”-tilgang, der dominerede træningsfasen ved simpelthen at tilføje mere beregningskraft, virker ikke her. Du kan ikke kaste mere H100’er på et latency-problem, hvis flaskenhalen er memory-båndbredden.

Memory Wall: Den virkelige flaskenhal

Den lidt kendte sandhed om Large Language Model (LLM)-inferens er, at det sjældent er begrænset af beregningskraft; det er begrænset af memory. Under træning behandler vi data i massive batcher, hvilket holder GPU’ens beregningsenheder fuldt udnyttet. I inferens, især i realtidsapplikationer som chatbots eller agenter, kommer forespørgslerne sekventielt. Hver token, der genereres, kræver, at modellen loader sine milliarder af parametre fra high-bandwidth memory (HBM) ind i beregningskernerne. Dette er “Memory Wall“. Det er som at have en Ferrari-motor (GPU-kernen) fast i trafikprop (den begrænsede memory-båndbredde).
Denne udfordring driver ingeniørhold til at omstrukturere systemarkitekturen ned til silikonniveauet. Dette er årsagen til, at vi ser opkomsten af Linear Processing Units (LPUs) som dem fra Groq og specialiserede Neural Processing Units (NPUs). Disse chip er designet til at omgå HBM-flaskenhalen ved at bruge massive mængder on-chip SRAM, hvor memory-adgang behandles som en kontinuierlig datastrøm i stedet for en simpel hent-operation. For software-ingeniøren signalerer dette enden på “default to CUDA”-æraen. Vi må nu skrive kode, der er hardware-bevidst, og forstå præcis, hvordan data flytter sig gennem wiren.

Den nye front i AI-effektivitet

Fordi vi ikke altid kan ændre hardwaren, ligger den kommende front i ingeniørarbejde i software-optimering. Her sker nogle af de mest innovative gennembrudd lige nu. Vi oplever en renæssance af teknikker, der gendefinerer, hvordan computere implementerer og eksekverer neurale netværk.

• Kontinuerlig batching: Traditionel batching venter på, at en “bus” er fuld, før den afgår, hvilket introducerer forsinkelser. Kontinuerlig batching (baneanført af rammer som vLLM) fungerer som et metrosystem, der tillader nye forespørgsler at slutte sig til eller forlade GPU-behandlings-toget ved hver iteration. Det maksimerer gennemstrømning uden at ofre latency, og løser et komplekst planlægningsproblem, der kræver dyb OS-niveau-ekspertise.

• Speculative Decoding: Denne teknik anvender en lille, hurtig og billig model til at udarbejde en respons, mens en større, langsommere og mere kapabel model verificerer det i parallel. Den afhænger af, at verificering af tekst er langt mindre beregningskrævende end generering af den.
• KV Cache Management: I lange samtaler vokser “historien” (Key-Value-cachen) hurtigt og forbruger store mængder GPU-memory. Ingeniører implementerer nu “PagedAttention“, en teknik inspireret af virtuel memory-paging i operativsystemer. Denne teknik opdeler memory i fragmenter og håndterer dem ikke-kontinuert.

Den agente kompleksitet

Hvis standard-inferens er svær, gør Agentic AI det eksponentielt sværere. En standard chatbot er statisk: Brugeren spørger, AI svare, processen slut. En AI-agent har dog en løkke. Den planlægger, udfører værktøjer, observerer resultater og itererer. Set fra et ingeniørperspektiv er dette en mareridt. Denne arkitektoniske ændring introducerer flere fundamentale udfordringer:

1. Tilstandsstyring: Inferens-motoren må vedligeholde “tilstanden” af agentens tænkeproces over flere trin, ofte over flere minutter.
2. Uendelige løkker: I modsætning til en forudsigelig forward-pass kan en agent blive fast i en resonansløkke. At udvikle robuste “vagthunde” og “sikringsmekanismer” til probabilistisk kode er et nyt felt i sig selv.
3. Variabel beregning: En brugerforespørgsel kan udløse en enkelt inferens-anmodning, mens en anden kan udløse femti. At styre belastning og autoskalere infrastruktur, når hver anmodning bærer så ekstrem variation, kræver en helt ny klasse af orkestreringslogik.

Vi bevæger os essentielt fra “at servere modeller” til “at orkestrere kognitive arkitekturer.”

At bringe AI til hverdagsenheder

Til sidst vil begrænsningerne i energi og netværkslatens uundgåeligt tvinge inferens til kanten. Vi kan ikke forvente, at hver smart lyspære, selvstændig køretøj eller fabriksrobot skal sende sine anmodninger gennem et datacenter. Den ingeniørudfordring her er kompression. Hvordan kan du få en model, der har lært fra hele internettet, til at passe på en chip, der er mindre end en fingernegl, og køre på en batteri?
Teknikker som kvantificering (at reducere præcision fra 16-bit til 4-bit eller endda 1-bit) og model-destillation (at lære en lille elev-model at efterligne en stor lærer-model) bliver standardpraksis. Men den virkelige udfordring er at deployere disse modeller til en fragmenteret økosystem af milliarder af enheder som Android, iOS, indlejret Linux, brugerdefinerede sensorer, hver med deres egne hardware-begrænsninger. Det er “fragmenteringsmareridtet” i mobiludvikling, multipliceret med kompleksiteten af neurale netværk.

Bottom Line

Vi indtræder i “Dag 2”-æraen for Generativ AI. Dag 1 handlede om at demonstrere, at AI kunne skrive digte. Dag 2 handler om ingeniørarbejde, om at gøre denne evne mere pålidelig, billig og almindelig. Ingeniørerne, der vil definere det næste årti, er ikke nødvendigvis dem, der opfinder nye modelarkitekturer. De er systemingeniørerne, kernel-hackerne og infrastrukturarkitekterne, der kan finde ud af, hvordan man kan servere en milliard tokens i sekundet uden at smelte strømnettet eller ruinere virksomheden. AI-inferens er ikke længere bare en detalje ved runtime. Det er produktet. Og at optimere det er den næste store ingeniørudfordring.