Vad som går sönder när LLM-funktioner möter riktiga användare

Tidigare i år låg en svensk LLM-inferensleverantör nere i nästintill ett dygn. Hårdvarufel på huvud-GPU-noden — den typen av sak som inte syns i något arkitekturdiagram.

Mailet som gick ut till kunder var ärligt på ett sätt som är ovanligt i branschen: "when working with hardware, murphy's law applies in full." En backup-modell sattes upp inom en timme. En andra GPU-nod väntade på CPU-kort som inte hade installerats än. Kunderna fick lära sig vad redundans verkligen kostar att inte ha.

Det här är vad LLM i produktion faktiskt handlar om. Inte vilken modell som ska väljas. Inte om prompten är optimerad. Det handlar om vad som händer när infrastrukturen under modellen får hicka — och om man har byggt något som klarar det.

Skillnaden mellan en demo som funkar och en funktion som lever

En LLM-demo körs på handvald indata, en användare, en bra dag. Modellen svarar snyggt och allt ser ut som att det är klart att gå live.

Produktion är något helt annat. Det är trafiktoppar man inte räknat med. Det är en användare som stavar fel i varje mening, kopierar in en hel PDF i chatfönstret eller medvetet försöker få modellen att säga något olämpligt.

Och det är kostnaden som plötsligt multipliceras med antalet aktiva kunder. En funktion som verkade billig i pilot blir påtagligt dyr när den faktiskt används av tusentals.

Plus leverantören. När PoC:n går från pilot till produktion hamnar ni i en helt annan riskbild — ni är inte längre den enda variabeln i ekvationen:

• OpenAI ändrar sina anropsgränser
• Anthropic uppdaterar en modell och svaren förändras subtilt
• En inferensleverantör väntar på CPU-kort som skulle ha installerats för flera veckor sedan

Ingen av de sakerna syns i utvecklingsmiljön. Alla händer i produktion.

Skiftet är inte tekniskt — det är disciplinärt. Att bygga en LLM-funktion som funkar är inte samma sak som att bygga en LLM-funktion som lever. Det första kräver en bra prompt och en bra modell. Det andra kräver att ni har tänkt på vad som händer när någon av dem inte fungerar.

Vad som är värt att bygga in från start

Vi gör inte allt det här på alla projekt. Det beror på avvägningen mellan risk och hur snabbt något ska ut. En intern PoC behöver inte samma robusthet som en kundvänd funktion i en SaaS-produkt med betalande användare.

Men det här är listan jag skulle gå igenom innan något går till produktion:

Spårning av varje LLM-anrop. Inte bara felmeddelanden — varje prompt, varje svar, latens, kostnad. Det är skillnaden mellan att upptäcka att modellen börjat hallucinera samma dag det händer, och att upptäcka det tre veckor senare när kundansvarig ringer.

Det går att bygga själv eller använda verktyg som Langfuse, LangSmith eller PostHog. Det viktiga är att ni har det innan ni behöver det.

Kostnadstak per användare och per dag. En enda missbrukad slutpunkt kan generera fakturor på flera tusen kronor per timme. Hårda gränser på antal anrop per användare och per dag är inte överoptimering — det är grundläggande hygien. Lika viktigt: budget-larm i molnleverantörens översikt, inte bara hos LLM-leverantören.

Plan för låg konfidens. När modellen är osäker, vad händer? Eskalerar ni till mänsklig handläggning? Visar ni en varning? Eller loggar ni och hoppas? Det är ett produktbeslut, inte ett tekniskt — men det måste vara taget innan ni går live. "Vi tar det när det blir aktuellt" betyder att ni tar det efter att en användare fått ett felaktigt svar.

Plan B för leverantören. För känsliga kunder bygger vi in flera leverantörer direkt — samma prompt skickas till en annan modell om primärleverantören svarar 500 eller överskrider tidsgränsen. För andra räcker det att ha en dokumenterad och testad reservväg. Det viktiga är att inte upptäcka att man inte har en plan den dagen er primärleverantör ligger nere i ett dygn.

Versionering av prompts i git. Prompts är kod. De ska granskas, versioneras och kunna återställas till tidigare version. När en modell uppdateras och svaren plötsligt blir sämre vill ni kunna jämföra: är det prompten som ändrats, eller är det modellen?

Det ingen berättar om

Det som inte står i LLM-leverantörens marknadsföring:

Modellerna ändras under fötterna på er. OpenAI, Anthropic och alla andra uppdaterar sina modeller löpande. Samma modellnamn idag är inte samma modell som för tre månader sedan — viktningar, säkerhetsfilter och beteenden glider över tid utan att versionsnumret ändras.

Ibland blir det bättre. Ibland blir det subtilt sämre på exakt det er funktion behöver. Utan en testsvit som körs regelbundet märker ni det inte förrän en kund hör av sig.

Hårdvara går sönder och leverantörer är inte gudar. Incidenten i inledningen är inte ovanlig — det ovanliga var att leverantören var transparent med varför. Stora leverantörer döljer ofta orsaken bakom generiska statusuppdateringar. Att lita på att en leverantör alltid är uppe är inte en strategi, det är ett antagande.

Latensen staplar sig. Lägg till RAG och svarstiden dubbleras. Lägg till verktygsanrop och den dubbleras igen. Lägg till en validering med en andra modell och plötsligt är ni uppe i åtta sekunder per svar.

Det som kändes snabbt i demo blir oacceptabelt i en produkt där användaren förväntar sig direkt återkoppling.

Svenska är inte engelska. De flesta modeller är tränade tyngst på engelska. Hallucinationsrisken är högre på svenska. Specifika svenska termer — inom juridik, vård eller en nischad bransch — kräver ofta egna tester eller finjustering av modellen. "Det funkar på engelska" är inte ett bevis på att det funkar på svenska.

Sällsynta gränsfall är värsta sorten. En bugg som drabbar 1 av 1000 interaktioner är svår att fånga i test men oundviklig i produktion. Det är därför spårning och loggning är värt mer än det verkar. Ni kan inte fixa det ni inte ser.

Hur vi börjar nu

Om vi startade ett LLM-projekt idag som ska till produktion inom kort — så här skulle vi prioritera, i ordning:

1. Bekräfta att LLM är rätt verktyg. Många problem som ser ut som LLM-problem är egentligen vanlig automation eller en bra integration. Vi börjar inte med "vilken modell" — vi börjar med vad som faktiskt ska hända för användaren och vad det kostar om det blir fel.

2. Bygg in grundläggande observerbarhet från dag ett. Spårning av varje LLM-anrop. Kostnadsspårning per användare. Ett enkelt sätt att exportera de tio värsta svaren från senaste veckan. Det här tar dagar att lägga till nu och veckor att lägga till sen.

3. En testsvit på 20–50 prompts. Körs innan varje produktionsläggning. Inte ett perfekt testbibliotek — bara tillräckligt för att fånga om modellen glidit sedan förra versionen.

4. En plan B-leverantör med samma prompt-format färdigtestat. Behöver inte vara aktiv från dag ett. Men dokumenterad och redo att aktiveras under en eftermiddag.

Allt det här är arbetet som inte syns i en demo. Det är inte glamoröst. Men det är skillnaden mellan en LLM-funktion som genererar värde i månader och en som genererar supportärenden i veckor.

Om ni vill prata om var ert eget projekt står — vad som är redo för produktion och vad som behöver mer arbete innan det är det — så är det den typen av samtal vi har varje vecka. Det vi gör på AI-strategi-uppdrag är just det: gå från idé till en plan ni faktiskt kan genomföra, inklusive den infrastruktur som inte syns i säljpresentationen.