Den dolda kostnaden för molnet

Kapitel 5 — Den dolda kostnaden för molnet

Den rådande berättelsen de senaste fem åren är att molnet är kostnadseffektivt, skalbart och enkelt. För många arbetsbelastningar är det helt sant. För företags-RAG är det dock allt oftare inte det. Och det ögonblick då du inser det är vanligtvis i slutet av första kvartalet, när fakturan kommer.

Låt oss ta den mest underskattade posten på fakturan: API:erna för modellerna för seende. När ett företag matar in sitt fotoarkiv i en modern RAG måste varje foto "beskrivas" av en multimodal modell som extraherar innehåll, objekt, kontext, eventuell text som överlagras, stämning, komposition. En stor europeisk modellleverantör – fortfarande utan namn – erbjöd 2025 en utmärkt modell från Qwen-familjen med 32 miljarder parametrar, till ett intressant pris per bild. Problemet, som upptäcktes först i praktiken och efter månader av produktion: under belastning trunkerade leverantören svaren. Inte alltid, inte på ett förutsägbart sätt, inte när testteamet var närvarande: slumpmässigt. Ett av tio bilder, ibland en av fem, kom tillbaka med en JSON som var avhuggen på mitten, dåligt parsad, med partiella eller noll metadata. Tiderna sköt i höjden från tio sekunder till tvåhundra sekunder per bild, utan något mönster. Kostnaden för återförsök – eftersom återförsök betalas, varje anrop, även det som servern trunkerar – var högre än förväntat. Databasen var heterogen: vissa foton rika på metadata, andra avbrutna. Och teamet kunde inte återskapa problemet i testmiljöer, eftersom belastningen var låg i test och allt fungerade.

Lösningen kom i tre delar: en mer kompakt prompt (kortare svar trunkeras inte lika ofta), en intelligent retry-logik (om svaret tar mer än femtio sekunder och returnerar tomt, försök igen direkt) och — när volymen motiverar det — möjligheten att helt hoppa över molnet och köra visionsmodellen på en lokal GPU, långsammare men deterministisk. Rätt arkitektur, enligt denna erfarenhet, är inte "moln alltid" eller "lokalt alltid". Det är "välj för varje anrop, baserat på vad som behövs just nu".

Sedan är det kapitlet om frågor. Varje användarsökning, i en klassisk moln-naturlig RAG, utlöser en kaskad av betalda API-anrop. Ett för inbäddning av frågan. Ett för avsiktsklassificering (vilken typ av fråga är det?). Ett för omrankning av dokument. Ett för att generera det slutliga svaret. Var och en kostar en bråkdel av en cent. För en intern tjänst med femtio användare och tiotusen frågor per dag — vilket inte är lite, men inte heller ett enormt antal för ett medelstort företag — kommer den månatliga räkningen upp i siffror som skulle få även en tolerant CFO att rynka på näsan. Och tillväxten är linjär: fördubbla användarna, fördubbla räkningen. Det finns inga skalfördelar i de förbrukade token, inte för dig.

Det finns också ett problem som låg under ytan 2025 och som blev centralt 2026: varje enskild fråga skickar bitar av företagsdokument – ibland konfidentiella, ibland skyddade av sekretessavtal, ibland föremål för branschregler – till servrarna hos en extern leverantör, i jurisdiktioner som inte alltid sammanfaller med din, med loggningspolicyer som inte alltid är tydliga. Mer än ett europeiskt företag har under de senaste arton månaderna upptäckt, oftast under en revision – vanligtvis initierad av en orolig kund eller en ISO-granskning – att deras kontrakt, prislistor och tekniska specifikationer hade behandlats (och potentiellt loggats för att "förbättra tjänsten") av infrastruktur utanför EU. Överraskningen har oftast kostat mer än den besparing på lokal hårdvara som man hade velat undvika.

Alternativet är inte den motsatta dogmen. "Nej till molnet, ja till lokalt" är lika fel som "ja till molnet alltid". Alternativet är en arkitektur som låter dig välja, för varje enskild del av pipelinen — inbäddning, klassificering, omrangordning, vision, slutlig generering — om du vill använda en molnmodell eller en lokal modell, och att ändra dig på en dag, inte ett kvartal. Detta kräver en design där leverantörerna är utbytbara, där ingen del är fastnaglad vid ett specifikt företags namn, där övergången från Regolo till Ollama (eller vice versa) är en konfigurationsrad, inte en omskrivning. Och det här var, fram till nyligen, sällsynt. Populära ramverk, trots fasaden av "leverantörsoberoende", var i själva verket starkt gifta med någon.