Varför AI-inferens, inte utbildning, är den nästa stora ingenjörsutmaningen

Under det senaste decenniet har strålkastarljuset inom artificiell intelligens varit monopoliserat av utbildning. Genombrotten har till stor del kommit från stora beräkningskluster, modeller med trillionsparametrar och de miljarder dollar som investerats i att lära system att “tänka”. Vi har behandlat AI-utveckling till stor del som ett byggnadsprojekt: att bygga skyskrapan av intelligens. Men nu när denna skyskrapa har byggts, är den verkliga utmaningen att ta reda på hur man kan underlätta för de miljoner som behöver leva och verka inom den samtidigt. Detta förskjuter fokus för AI-forskare och ingenjörer från utbildning (akten att skapa intelligens) till inferens (akten att använda den). Medan utbildning är en massiv, engångskapitalutgift (CapEx), är inferens en fortlöpande driftsutgift (OpEx) som fortsätter oändligt. När företag distribuerar agenter som betjänar miljontals användare dygnet runt, upptäcker de en hård verklighet: inferens är inte bara “utbildning i omvänd ordning”. Det är en fundamentalt annorlunda, och kanske svårare, ingenjörsutmaning.

Varför inferenskostnader är viktigare än någonsin

För att förstå den ingenjörsutmaningen måste man först förstå den underliggande ekonomiska imperativet. Under utbildningsfasen är ineffektivitet tolererbar. Om en utbildningskörning tar fyra veckor istället för tre, är det ett besvär. I inferens, däremot, kan ineffektivitet vara katastrofal för affärer. Till exempel kan utbildning av en frontmodell kosta 100 miljoner dollar. Men att distribuera den modellen för att besvara 10 miljoner förfrågningar per dag kan överstiga den kostnaden på bara några månader om den inte optimeras. Detta är varför vi ser en marknadsförändring, med inferensinvesteringar förväntas överstiga utbildningsinvesteringar.

För ingenjörer förskjuter detta målstolparna. Vi optimerar inte längre för genomströmning (hur snabbt kan jag bearbeta denna stora datamängd?). Vi optimerar för latens (hur snabbt kan jag returnera en enskild token?) och samtidighet (hur många användare kan jag betjäna på en GPU?). Den “brutala” metoden som dominerade utbildningsfasen genom att enkelt lägga till fler beräkningar fungerar inte här. Du kan inte kasta fler H100:or på ett latensproblem om flaskhalsen är minnesbandbredden.

Minnesväggen: Den verkliga flaskhalsen

Den lite kända sanningen om stora språkmodellers (LLM) inferens är att den sällan begränsas av beräkningar; den är begränsad av minne. Under utbildning bearbetar vi data i stora batchar, vilket håller GPU:ns beräkningsenheter fullt utnyttjade. I inferens, särskilt för realtidsapplikationer som chatbots eller agenter, kommer förfrågningar in sekventiellt. Varje genererad token kräver att modellen laddar sina miljarder parametrar från högbandviddsminne (HBM) in i beräkningskärnorna. Detta är “Minnesväggen“. Det är som att ha en Ferrari-motor (GPU-kärnan) fast i köer (den begränsade minnesbandbredden).

Denna utmaning driver ingenjörsteam att ompröva systemarkitektur ner till kisel­nivå. Detta är varför vi ser uppkomsten av linjära bearbetningsenheter (LPUs) som de från Groq, och specialiserade neuronnätverksbearbetningsenheter (NPUs). Dessa chip är utformade för att kringgå HBM-flaskhalsen genom att använda stora mängder on-chip-SRAM, vilket behandlar minnesåtkomst som en kontinuerlig dataflöde snarare än en enkel hämtningsoperation. För programvaruutvecklaren signalerar detta slutet på “standard-CUDA”-eran. Vi måste nu skriva kod som är maskinvaru-medveten, förstå exakt hur data flyttas genom ledningen.

Den nya fronten för AI-effektivitet

Eftersom vi inte alltid kan ändra maskinvaran, ligger den kommande fronten för ingenjörer i programvaruoptimering. Här sker några av de mest innovativa genombrotten just nu. Vi ser en renässans av tekniker som omdefinierar hur datorer implementerar och kör neuronnät.

• Kontinuerlig batchning: Traditionell batchning väntar på att “bussen” fylls innan den avgår, vilket introducerar förseningar. Kontinuerlig batchning (banbrytande av ramverk som vLLM) fungerar som ett tunnelbanesystem, vilket tillåter nya förfrågningar att ansluta eller lämna GPU-bearbetningståget vid varje iteration. Den maximaliserar genomströmning utan att offra latens, vilket löser ett komplext schemaläggningsproblem som kräver djup OS-nivåexpertis.

• Speculativ avkodning: Denna teknik använder en liten, snabb och billig modell för att skissa en svar, medan en större, långsammare och mer kapabel modell verifierar den parallellt. Den förlitar sig på det faktum att verifiera text är mycket mindre beräkningskrävande än att generera den.
• KV-cachehantering: I långa samtal växer “historien” (nyckel-värde-cachen) snabbt, vilket konsumerar stora mängder GPU-minne. Ingenjörer implementerar nu “PagedAttention“, en teknik inspirerad av virtuell minnespaginering i operativsystem. Denna teknik bryter minnet i fragment och hanterar det icke-sammanhängande.

Den agenta komplexiteten

Om standardinferens är svårt, gör agentbaserad AI det exponentiellt svårare. En standardchatbot är tillståndslös: Användaren frågar, AI svarar, processen slutar. En AI-agent, däremot, har en loop. Den planerar, kör verktyg, observerar resultaten och itererar. Ur ett ingenjörsperspektiv är detta en mardröm. Denna arkitekturförändring introducerar flera grundläggande utmaningar:

1. Tillståndshantering: Inferensmotorn måste upprätthålla “tillståndet” för agentens tankeprocess över flera steg, ofta över flera minuter.
2. Oändliga loopar: Till skillnad från en förutsägbar framåtriktad passering kan en agent fastna i en resonemangsloop. Att konstruera robusta “väktare” och “säkerhetsbrytare” för sannolikhetskod är ett helt nytt fält.
3. Variabel beräkning: En användarfråga kan utlösa ett enda inferensanrop, medan en annan kan utlösa femtio. Att hantera belastning och autoskalningsinfrastruktur när varje förfrågan bär sådan extrem variation kräver en helt ny klass av orkestreringslogik.

Vi flyttar oss från “att betjäna modeller” till “att orkestrera kognitiva arkitekturer”.

Att ta AI till vardagsenheter

Slutligen kommer energi- och nätverkslatensbegränsningarna oundvikligen att tvinga inferens till kanten. Vi kan inte förvänta oss att varje smart ljuskula, autonom fordon eller fabriksrobot ska dirigera sina förfrågningar via ett datacenter. Den ingenjörsutmaningen här är komprimering. Hur kan man få en modell som lärde sig från hela internet att passa på en chip som är mindre än en fingernagel, som körs på en batteri?

Tekniker som kvantifiering (att minska precisionen från 16-bit till 4-bit eller till och med 1-bit) och modelldestillering (att lära en liten elevmodell att imitera en stor lärarmodell) blir standardpraxis. Men den verkliga utmaningen är att distribuera dessa modeller till en fragmenterad ekosystem av miljarder enheter som Android, iOS, inbäddad Linux, anpassade sensorer, var och en med sina egna maskinvarubegränsningar. Det är “fragmenteringsmardrömmen” av mobilutveckling, förstärkt av komplexiteten i neuronnät.

Slutsatsen

Vi går in i “Dag 2”-eran av generativ AI. Dag 1 handlade om att demonstrera att AI kunde skriva poesi. Dag 2 handlar om ingenjörskap, att göra den förmågan mer tillförlitlig, prisvärd och allmänt tillgänglig. De ingenjörer som kommer att definiera det kommande decenniet är inte nödvändigtvis de som uppfinner nya modellarkitekturer. De är systemingenjörerna, kärnkodarna och infrastrukturarkitekterna som kan ta reda på hur man kan betjäna en miljard token per sekund utan att smälta elkraftsnätet eller ruinera företaget. AI-inferens är inte längre bara en detalj i körningen. Det är produkten. Och att optimera den är den nästa stora ingenjörsutmaningen.