Den skjulte kostnaden ved skyen

Kapittel 5 — Den skjulte kostnaden ved skyen

Den dominerende fortellingen de siste fem årene sier at skyen er kostnadseffektiv, skalerbar og enkel. For mange arbeidsmengder er dette helt sant. For bedriftsmessige RAG-applikasjoner er det imidlertid ofte ikke tilfelle. Og tidspunktet du innser det er vanligvis på slutten av første kvartal, når fakturaen kommer.

La oss ta den mest undervurderte kostnaden: API-ene for visjonsmodeller. Når et selskap laster opp sitt fotoarkiv til en moderne RAG, må hvert bilde "beskrives" av en multimodal modell som trekker ut innhold, objekter, kontekst, eventuell tekst som er påført, stemning og komposisjon. En stor europeisk modellleverandør – fortsatt uten navn – tilbød i 2025 en utmerket modell fra Qwen-familien med 32 milliarder parametere, til en interessant pris per bilde. Problemet, som kun ble oppdaget i praksis og etter måneder med produksjon: under belastning, avkortet leverandøren svarene. Ikke alltid, ikke på en forutsigbar måte, ikke når testteamet var til stede: tilfeldigvis. Ett av ti bilder, noen ganger ett av fem, kom tilbake med en JSON som var kuttet i to, dårlig parset, med delvise eller null metadata. Tidene skjøt i været fra ti sekunder til tohundre sekunder per bilde, uten mønster. Kostnaden for forsøk – fordi forsøk koster penger, hvert kall, selv det serveren avkorter – var høyere enn forventet. Databasen var inhomogen: noen bilder var rike på metadata, andre var avkortet. Og teamet klarte ikke å gjenskape problemet i testmiljøer, fordi belastningen var lav i testene og alt fungerte.

Løsningen kom i tre deler: en mer kompakt prompt (kortere svar blir mindre avbrutt), en intelligent returlogikk (hvis svaret tar mer enn femti sekunder og returnerer tomt, prøv på nytt umiddelbart) og – når volumet rettferdiggjør det – muligheten til å hoppe over skyen helt og kjøre synsmodellen på en lokal GPU, som er tregere, men deterministisk. Riktig arkitektur, basert på denne erfaringen, er ikke "alltid sky" eller "alltid lokalt". Det er "velg for hvert kall, basert på hva som trengs akkurat da".

Så er det kapittelet om spørringer. Hver brukersøk, i en klassisk sky-native RAG, utløser en kaskade av betalte API-kall. Ett for å legge inn spørsmålet. Ett for intensjonsklassifisering (hvilken type spørsmål er det?). Ett for å rangere dokumentene på nytt. Ett for å generere det endelige svaret. Hver av dem koster en brøkdel av en øre. For en intern tjeneste med femti brukere og ti tusen spørringer per dag – som ikke er lite, men heller ikke et enormt tall for en gjennomsnittlig bedrift – kommer den månedlige regningen opp i tall som til og med en tolerant CFO ville rynke på nesen av. Og veksten er lineær: dobler du brukerne, dobler du regningen. Det er ingen stordriftsfordeler i forbrukte tokens, ikke for deg.

Det er også et problem som lå under radaren i 2025 og som ble sentralt i 2026: Hver eneste spørring sender deler av bedriftsdokumenter – noen ganger konfidensielle, noen ganger dekket av NDA-er, noen ganger underlagt bransjeregler – til servere til en ekstern leverandør, i jurisdiksjoner som ikke alltid stemmer overens med din, med loggføringspolicyer som ikke alltid er krystallklare. Mer enn ett europeisk selskap har de siste atten månedene oppdaget under en revisjon – vanligvis utløst av en bekymret kunde eller en ISO-sjekk – at deres kontrakter, prisliste og tekniske spesifikasjoner ble behandlet (og potensielt logget for å «forbedre tjenesten») av infrastruktur utenfor EU. Overraskelsen har vanligvis kostet mer enn besparelsene på lokal maskinvare man ønsket å unngå.

Alternativet er ikke den motsatte dogmen. "Nei til skyen, ja til lokalt" er like feil som "ja til skyen alltid". Alternativet er en arkitektur som lar deg velge, for hvert enkelt stykke av pipelinen — embedding, klassifisering, reranking, visjon, endelig generering — om du vil bruke en skybasert modell eller en lokal modell, og ombestemme deg på en dag, ikke et kvartal. Dette krever en design der leverandørene er utskiftbare, der ingen del er naglet til navnet på en bestemt bedrift, der overgangen fra Regolo til Ollama (eller omvendt) er en konfigurasjonslinje, ikke en omskriving. Og dette, inntil nylig, var sjeldent. Populære rammeverk, til tross for fasaden av "leverandøruavhengig", var faktisk veldig gift med noen.