Inference engineering: vad det är och vad AI-drift kostar

Inference engineering är arbetet med att få ett AI-system att leverera rätt kvalitet, svarstid och kostnad när det används i drift. Det börjar efter att en modell finns tillgänglig och fortsätter så länge tjänsten används.

Varje anrop förbrukar resurser. I ett externt API syns de ofta som debiterade indata och utdata. I egen drift syns de som acceleratorer, minne, energi, köer och arbetstid. Kostnaden per svar är därför inte en enda egenskap hos modellen. Den beror på hela flödet.

Skillnaden mellan träning och inferens

Träning förändrar modellens parametrar med hjälp av data. Inferens är körningen som använder en tränad modell för att producera ett resultat. Ett företag som använder en färdig molntjänst betalar normalt inte för leverantörens ursprungliga träning som en separat post. Däremot påverkar användningen den löpande kostnaden.

En pilot kan se billig ut därför att få personer gör få anrop. När samma funktion byggs in i ett arbetsflöde kan antalet anrop, längden på instruktionerna och mängden hämtad kontext växa samtidigt. Det är skälet att mäta per slutförd uppgift och inte bara per enskilt svar.

Inference engineering omfattar bland annat:

• val av modell för varje deluppgift,
• mängden text och andra data som skickas in,
• hur mycket modellen producerar,
• återanvändning genom cache,
• samtidighet, köer och svarstid,
• kvalitetskontroll och omkörningar,
• verktygsanrop och hämtning från andra system,
• kostnaden för mänsklig granskning.

En billig körning som ofta måste göras om kan bli dyrare än en mer träffsäker körning.

Börja med uppgiften, inte modellnamnet

Den användbara frågan är inte vilken modell som är bäst i allmänhet. Frågan är vilken lösning som klarar ett definierat kvalitetskrav för en bestämd uppgift.

Klassificering av inkommande ärenden, sammanfattning av korta texter och utvinning av fasta fält kan ofta testas med mindre modeller eller traditionell kod. Analys av ett tvetydigt ärende kan kräva mer kapacitet, fler källor och mänsklig kontroll.

Forskningsarbetet FrugalGPT visar principen bakom modellkaskader: olika frågor kan skickas till olika modeller, och ett billigare första steg kan lämna över när kvaliteten inte räcker. Resultaten i studien gäller dess modeller och testuppgifter, inte varje verksamhet. Den bestående lärdomen är att routing måste utvärderas mot ett eget facit.

Ett vanligt upplägg är:

1. definiera ett mätbart kvalitetskrav,
2. kör en stark modell för att skapa en baslinje,
3. prova en mindre modell på samma material,
4. identifiera vilka fall som behöver lämnas vidare,
5. mät kostnad och kvalitet för hela kedjan.

Om kvalitetskravet saknas går det alltid att visa en lägre kostnad genom att välja en enklare modell. Det säger ingenting om nyttan.

Vad kostar ett svar?

Hos API-leverantörer är token ofta beräkningsenheten för text. Indata och utdata kan ha olika pris, och cache, batchkörning eller särskilda tjänstenivåer kan påverka kalkylen. OpenAI:s prislista och Googles prislista visar leverantörernas aktuella villkor. Priserna ska läsas den dag kalkylen görs; länkarna kontrollerades den 24 augusti 2026.

En enkel kostnadsrad för ett API-anrop kan skrivas:

kostnad = indata × pris för indata + utdata × pris för utdata + verktyg och andra tjänster

För en arbetsprocess behöver fler poster läggas till:

kostnad per godkänd uppgift = alla körningar + datatjänster + lagring + övervakning + mänsklig granskning

Det är den andra raden som går att jämföra med dagens arbetssätt.

I egen drift försvinner tokenpriset från fakturan men inte kostnaden. Då behöver kalkylen omfatta hårdvara eller molnkapacitet, utnyttjandegrad, energi, driftpersonal, övervakning, reservkapacitet och uppgraderingar. En accelerator som står oanvänd större delen av dygnet kan ge hög kostnad per faktiskt svar.

De viktigaste mätvärdena

Kostnad per godkänd uppgift

Mät inte bara kostnad per anrop. Räkna vad det kostar att nå ett resultat som passerar kontrollen. Ta med omkörningar, eskaleringar och manuella rättningar.

Kvalitet mot ett facit

Facit kan vara märkta ärenden, godkända sammanfattningar eller en uppsättning dokument där rätt fält är kända. Mät fel som påverkar beslut separat från kosmetiska avvikelser.

Svarstid

Användaren märker både tiden till första tecknet och tiden tills hela uppgiften är klar. Ett agentflöde kan göra flera anrop bakom ett enda klick, så slutpunkten måste mätas från användarens perspektiv.

Token och kontext

Logga indata, utdata och hämtad kontext per steg. Långa systeminstruktioner och stora dokument som skickas om vid varje anrop kan dominera kostnaden. Kortare är inte alltid bättre, eftersom för lite kontext kan skapa fler fel.

Fel och omkörningar

Ett system som misslyckas tyst är svårare att styra än ett som stoppar. Logga timeout, ogiltiga strukturer, misslyckade verktygsanrop och fall där en människa tog över.

Volym och toppar

Medelvärdet räcker inte. Köer och kapacitetsproblem uppstår ofta när många använder tjänsten samtidigt. Testa normal trafik och realistiska toppar.

Fem sätt att minska kostnaden

1. Skicka mindre irrelevant kontext

Hämta bara de dokumentdelar som behövs för uppgiften. Mät samtidigt om urvalet missar viktig information. En kort prompt med fel underlag är inte en förbättring.

2. Begränsa utdata

Be om det format och den längd som processen använder. Strukturerade fält är ofta billigare att kontrollera än en lång fri text, men formatet behöver valideras.

3. Återanvänd stabilt innehåll

Instruktioner och referensmaterial som upprepas kan ibland cachas. Besparingen beror på leverantörens villkor och på hur ofta samma prefix verkligen återkommer.

4. Välj modell per steg

Använd en enkel lösning för förutsägbara steg och mer kapacitet där bedömningen är svår. Routingregeln ska bygga på testresultat, inte på antagandet att enkla frågor alltid ser enkla ut i förväg.

5. Stoppa onödiga loopar

Agenter och omprövande flöden kan fortsätta göra anrop utan att förbättra resultatet. Sätt gränser för antal försök, total kostnad och tid. Lämna över när gränsen nås.

API eller egen drift?

Ett API ger låg starttröskel och en tydlig användningsmätare. Leverantören sköter hårdvaran, men priser, villkor och modeller kan ändras. Egen drift ger mer kontroll över modell, dataflöde och kapacitet men kräver kompetens och en tillräcklig belastning för att resurserna ska användas väl.

Valet bör jämföras på samma grund:

• kostnad per godkänd uppgift,
• krav på svarstid och tillgänglighet,
• datakrav och behörigheter,
• kapacitet vid toppar,
• kostnad för personal och övervakning,
• möjlighet att byta modell eller leverantör.

Det finns inget generellt svar. En kombination kan vara rimlig: egen drift för stabil hög volym och API för sällsynta eller svåra uppgifter.

Så gör du ett prov före utrullning

Välj ett avgränsat arbetsflöde och samla ett representativt prov. Ta med vanliga fall, svåra undantag och indata som ska stoppas. Dokumentera dagens tid, fel och kostnad.

Kör sedan minst två tekniska alternativ mot samma prov. För varje alternativ sparar du modellval, instruktion, tokenåtgång, svarstid, fel, kostnad och granskarens beslut. Ändra en sak i taget när du försöker förbättra utfallet.

När provet går i drift ska samma mätvärden följas. Verkliga användare skriver annorlunda än testgruppen, och volymen kan förändra både köer och beteende.

Ledningens kontrollfrågor

Den som godkänner en AI-tjänst behöver kunna få raka svar på följande:

1. Vilken arbetsuppgift mäter vi?
2. Vad räknas som ett godkänt resultat?
3. Vad kostar en godkänd uppgift vid normal volym och topp?
4. Vilka fel leder till stopp eller mänsklig granskning?
5. Vilka delar kan byta modell utan att processen skrivs om?
6. Hur upptäcker vi att kvalitet eller pris har förändrats?

Dessa frågor gör inference engineering till ekonomistyrning och kvalitetsarbete, inte en jakt på en viss modell.

Slutsats

Inference engineering kopplar tekniska val till ett faktiskt arbetsflöde. Den viktigaste enheten är inte token, anrop eller accelerator, utan en godkänd slutförd uppgift.

Börja med facit och baslinje. Mät hela kedjan, inklusive omkörningar och mänsklig kontroll. Prova mindre modeller, cache och routing först när du kan visa att kvalitetskravet fortfarande nås. Då blir en lägre kostnad ett belagt resultat i den egna verksamheten, inte ett löfte från en prislista.