Det du tappar i molnet

Det första som händer när någon visar upp en cloud-baserad AI-lösning som svarar på fyra sekunder är att alla i rummet nickar. Det är ju bra. Det funkar. Sedan ringer en riktig kund, och de fyra sekunderna känns som tjugo. Personen i andra änden hinner tänka två gånger, börjar prata över botten, lägger på. Det är inte ett tekniskt fel. Det är ett produktfel som ser ut som en teknisk specifikation.

Jag tycker det är konstigt hur lite vi pratar om latency när vi bygger AI-funktioner. Vi diskuterar modeller, kontextfönster, priser per miljon tokens, men sällan hur det känns att sitta och vänta på ett svar. När du ringer någon och de tar fyra sekunder på sig att svara på en helt vanlig fråga, då tänker du att de är osäkra. När en bot gör samma sak tänker du att den är trasig. Människor tål inte tystnad i ett samtal. Det är en av de saker som inte syns i en demo men dödar produktionen.

Latency är inte ett tekniskt mått, det är en känsla

Säg att du har byggt en kundtjänstbot som ringer upp på OpenAI gpt-5.4 över deras API, gör en RAG-sökning mot din pgvector-databas och formulerar ett svar. På din egen dator i Stockholm, med fiberanslutning och bra dag, tar det två sekunder. I produktion, med en stökig 4G-uppkoppling i en bil utanför Linköping, tar det fem. Sex om TLS-handshaken är seg. Lägg till att du har en text-to-speech på toppen som också ringer ut till en tredjepart, och du sitter på sju sekunder innan kunden hör första stavelsen.

Det här är inte en teoretisk siffra. Det är vad som händer när du lägger flera nätverkshopp i serie. Varje hopp är en chans att något ska gå segt. Cloud-API:er har dessutom en obekväm vana att variera. Mediantiden ser bra ut, men 95:e percentilen, alltså den dåliga femte-procenten av alla anrop, är ofta tre eller fyra gånger värre. Det är de samtalen som dyker upp i klagomålen.

Lokalt blir det inte automatiskt snabbt, men du får kontroll. Kör du Llama 3.1 70B på en egen GPU i ett serverrum i Sverige, då vet du exakt hur lång tid första token tar att producera. Det varierar inte beroende på hur mycket trafik OpenAI har just nu eller om det råkar vara måndag morgon i Kalifornien. Du har själv mätt det, du kan reproducera det, och om det är för segt kan du faktiskt göra något åt det. Köpa snabbare GPU. Quantisera modellen. Byta till Qwen2.5 i en mindre storlek om det räcker.

Du äger latency, men du äger också driften

Det här är där lokalt blir mindre romantiskt. Att äga sin egen modell betyder att någon måste se till att maskinen är uppe klockan 03:14 en lördag när NVMe-disken börjar spotta dåliga sektorer. Det betyder patchning, monitoring, backup av modellvikter, och en plan för vad som händer när serverrummet blir varmt. Det är inte en katastrof, men det är arbete. Och det är arbete som inte syns på säljsidan.

Ollama gör det enklare än vad det var för två år sedan. Du kan ha en modell igång på en Mac mini med M-chip om volymen är låg, och det funkar förvånansvärt bra. Men om du är en kundtjänst som kör hundra parallella samtal under måndag morgon, då räcker inte en Mac mini, då behöver du en H100 eller två och då börjar listan över saker som kan gå sönder växa. Det jag är trött på är att den här delen av ekvationen ofta hoppas över när någon räknar på ROI för lokal AI. Hårdvarukostnaden är synlig. Driftskostnaden är osynlig tills den dyker upp som en sjuk konsulträkning i juni.

Cloud löser det här åt dig. Det är hela poängen. Du betalar en premie för att slippa tänka på filsystem, brandväggar, GPU-drivrutiner och det faktum att Linux ibland bara bestämmer sig för att hata dig. För många bolag är det rätt val. Inte för att lokalt är fel, utan för att de inte har en person som kan ta emot pageralarmet klockan tre på natten utan att hata sitt jobb dagen efter.

Räkna på 10x volym, sen läs det igen

Det här är samtalet jag önskar att fler hade innan de skrev under sitt första API-avtal. Cloud-priser ser fina ut när du testar. En tusendel av en cent här, ett par dollar där. Du sitter och leker med en chatbot på din egen tid och räkningen efter en månad är trettio dollar. Härligt.

Sen lanserar du. Och säg att lanseringen går bra. Plötsligt har du tio gånger så mycket trafik. Det är inte exotiskt, det är vad som händer när en B2B-feature börjar användas av kunder som faktiskt behöver den. Räkningen blir då inte tio gånger större. Den blir ofta tolv eller femton, för du börjar lägga till saker. Ny RAG-pipeline här, en agent som gör flera anrop per request där, embeddings som regenererar varje natt med BAAI/bge-m3 för att hålla sökindex färskt. Allt det är pay-per-token, och tokens summerar.

Jag har sett det räknas baklänges från ett känt scenario: tio tusen aktiva användare som gör i snitt fem AI-interaktioner per dag, varje interaktion drar runt tre tusen tokens in och tusen ut. Det blir 150 miljoner tokens om dagen bara på chat-modellen. Lägg till embeddings, klassificering, agent-routing, och du landar på en räkning som plötsligt är värd en heltidsanställd. Då blir frågan inte längre om lokalt är dyrare, utan om molnet är värt den extra kostnaden för den specifika typen av arbetslast.

Det här är för övrigt platsen där LiteLLM och liknande verktyg blir intressanta. Du kan börja routa olika typer av frågor till olika modeller. Enkla klassificeringar går till en lokal Qwen2.5 7B på din egen maskin. Komplex resonering, där det gör skillnad, går till Anthropic Claude. Du betalar premium bara där det är värt det. Min teori är att de flesta bolag som idag kör 100 procent på cloud-API skulle kunna halvera sin räkning utan att kunderna märkte något, om de ville göra arbetet.

Hybriden är ofta rätt, men inte alltid

Hybrid är ordet som låter klokt på styrelsemötet. Vi tar det bästa av båda världarna. I praktiken innebär det att man lagt till komplexitet och hoppas att det vägs upp av flexibilitet. Ibland gör det det. Ofta gör det det inte.

När hybriden funkar är när du har en tydlig uppdelning mellan känslig data och allmän intelligens. Säg att du jobbar med journalanteckningar i sjukvård, eller med kundavtal som innehåller saker du inte vill ska dyka upp i någon annans träningsdata. Då kör du embeddings och första-läsning lokalt på en egen Llama 3.1 70B, så att råtexten aldrig lämnar huset. Sammanfattningar och slutgiltig text-generering, där datat är redan anonymiserat, kan gå till Claude eller gpt-5.4. Det är en arkitektur som har en logik. Den är inte gratis, men den är rätt.

När hybriden inte funkar är när den är ett resultat av obeslutsamhet. Vi vet inte om vi vill köra lokalt eller i molnet, så vi kör båda, och slutar med två system att underhålla istället för ett. Jag fattar fortfarande inte varför så många byggen ser ut så. Min gissning är att det är kompromiss-arkitektur som föds i möten där ingen vill ge sig. Resultatet blir då något som ingen är riktigt ansvarig för och som ingen riktigt förstår.

Det enklaste testet jag har för om en hybrid är värd det: kan du på en mening förklara vilken arbetslast som går vart och varför? Om svaret är ja, bra. Om svaret är "tja, det beror på, vi har ett trafikljus-system med flera regler", då har du byggt något som kommer att ha incidenter.

Beslutet handlar inte om kostnad

Det är här jag landar varje gång. När folk frågar mig om molnet eller lokalt, börjar de oftast med kostnad. Det är fel ingång. Kostnad är ett resultat av andra beslut, inte ett beslut i sig. Frågan är var du vill att risken ska sitta.

I molnet sitter risken hos någon annan. Du köper bort den. Anthropic, OpenAI, Google, de tar hand om uptid, GPU-allokering, modellförbättringar. När GPT-versionen blir bättre i juni får du den utan att göra något. Det är ett enormt värde. Risken du tar i utbyte är att din affärsmodell blir beroende av deras prislista, deras dataregler, och deras lust att deprecate en modell som dina kunder vant sig vid. Den dagen Anthropic höjer priset med 30 procent eller OpenAI deprecatar en modell du har byggt produktionsprompts kring, då är det din dag som blir dålig, inte deras.

Lokalt sitter risken hos dig. Det är dina hårddiskar, din uptid, din kompetens som ska vara på plats när det blir varmt i serverrummet. Men du äger också uppsidan. Du kan finetuna en modell på dina egna data utan att fråga någon. Du kan svara dina kunder att deras data aldrig lämnar huset, och faktiskt mena det. Du kan köra på en modell i tre år utan att den plötsligt försvinner.

För småbolag är cloud nästan alltid rätt start. Inte för att det är billigare, utan för att det är där du har minst risk att förlora sex månader på drift. För medelstora bolag som börjar bygga affärskritiska AI-funktioner, då börjar lokalt eller hybrid bli värt att räkna på. För en bank, en region, ett försvarsbolag, en advokatbyrå med konfidentiella avtal, då är frågan inte om utan när lokalt blir nödvändigt. Och hellre att man tänker på det innan första demoraketen lyfter än efter.

Det jag hade gjort i morgon

Om jag satt i en CTO-stol idag och visste att vi skulle köra mer AI nästa år än i år, skulle jag göra två saker. Det första är att mäta. Inte vad det kostar i nuläget, utan hur kostnaden växer med användningen. Är det linjärt? Ofta är det superlinjärt, för komplexitet i prompts ökar i takt med ambitionen. Den siffran är värd att veta innan du behöver veta den.

Det andra är att göra ett liten lokalt experiment. Sätt upp Ollama på en Mac mini eller en H100 om du har råd, och kör Llama 3.1 70B eller Qwen2.5 mot ett delmängd av era riktiga case. Inte för att ersätta cloud, utan för att lära er hur det känns att äga sin egen modell. Det ger en känsla för latency, för minneskrav, för hur ofta saker faktiskt går sönder. Den känslan är värd mer än alla benchmarks du kan läsa.

Och om du har data som inte borde lämna landet, är det inte en framtida fråga. Den är aktuell nu, och GDPR är inte den enda anledningen. Kunder har börjat fråga. Om svaret är "vi skickar det till en amerikansk leverantör som lovat att vara snäll", då är det inte ett svar som håller särskilt länge.

På Kapaciti gör vi mycket av det här. Hör av dig om det är aktuellt.