Den skjulte pris ved cloud computing

Kapitel 5 — Den skjulte pris ved cloud computing

Den dominerende fortælling de sidste fem år er, at cloud computing er billigt, skalerbart og simpelt. For mange arbejdsbelastninger er det helt korrekt. For enterprise RAG er det dog ofte ikke tilfældet. Og det tidspunkt, hvor du opdager det, er typisk i slutningen af første kvartal, når fakturaen kommer.

Lad os tage den mest undervurderede post på regningen: API'erne til visionsmodeller. Når en virksomhed indlæser sit fotoarkiv i en moderne RAG, skal hvert foto "beskrives" af en multimodal model, der udtrækker indhold, objekter, kontekst, eventuelle overlejrede tekster, stemning, komposition. En stor europæisk modeludbyder – stadig uden navn – tilbød i 2025 en fremragende model fra Qwen-familien med 32 milliarder parametre til en interessant pris pr. billede. Problemet, der kun blev opdaget i marken og efter måneders produktion: under belastning afkortede udbyderen svarene. Ikke altid, ikke på en forudsigelig måde, ikke når testteamet var foran: tilfældigt. Et ud af ti billeder, nogle gange et ud af fem, kom tilbage med en JSON, der var afskåret midt over, dårligt parset, med partielle eller nul metadata. Tiderne steg fra ti sekunder til to hundrede sekunder pr. billede, uden mønster. Omkostningerne ved genforsøg – for genforsøg betales, hvert kald, selv det, som serveren afkorter – var højere end forventet. Databasen var heterogen: nogle fotos rige på metadata, andre afkortede. Og teamet kunne ikke genskabe problemet i testmiljøer, fordi belastningen var lav i test, og alt fungerede.

Løsningen kom i tre dele: en mere kompakt prompt (kortere svar afkortes mindre), en intelligent retry-logik (hvis svaret tager mere end halvtreds sekunder og returnerer tomt, prøv igen med det samme) og – når volumenet berettiger det – muligheden for helt at springe skyen over og køre visionsmodellen på en lokal GPU, som er langsommere, men deterministisk. Den rigtige arkitektur, ifølge denne erfaring, er ikke "altid sky" eller "altid lokal". Det er "vælg for hvert kald, baseret på hvad der er brug for i øjeblikket".

Så er der kapitlet om forespørgsler. Hver brugerundersøgelse udløser i en klassisk cloud-native RAG en kaskade af betalte API-kald. En til indlejring af spørgsmålet. En til hensigtklassificering (hvilken type spørgsmål er det?). En til omrangering af dokumenter. En til generering af det endelige svar. Hver koster en brøkdel af en cent. For en intern tjeneste med halvtreds brugere og titusind forespørgsler om dagen – hvilket ikke er lidt, men heller ikke et enormt antal for en mellemstor virksomhed – løber den månedlige regning op i beløb, der ville få selv en tolerant CFO til at rynke på næsen. Og væksten er lineær: fordobler du brugerne, fordobler du regningen. Der er ingen stordriftsfordele i de forbrugte tokens, ikke for dig.

Der er også et problem, der lå under radaren i 2025, og som blev centralt i 2026: Hver eneste forespørgsel sender stykker af virksomhedsdokumenter – nogle gange fortrolige, nogle gange dækket af NDA'er, nogle gange underlagt branchebestemmelser – til servere hos en ekstern leverandør i jurisdiktioner, der ikke altid stemmer overens med din, med logopbevaringspolitikker, der ikke altid er gennemsigtige. Mere end én europæisk virksomhed har i løbet af de sidste atten måneder kun opdaget under en revision – normalt udløst af en bekymret kunde eller en ISO-kontrol – at deres kontrakter, prislister og tekniske specifikationer var blevet behandlet (og potentielt logget med henblik på "forbedring af tjenesten") af infrastruktur uden for EU. Overraskelsen har normalt kostet mere, end den hardwarebesparelse, man havde forsøgt at undgå.

Alternativet er ikke den modsatte dogme. "Ingen cloud, kun lokalt" er lige så forkert som "altid cloud". Alternativet er en arkitektur, der giver dig mulighed for at vælge, for hvert enkelt stykke af pipelinen — embedding, klassificering, reranking, vision, endelig generering — om du vil bruge en cloud-model eller en lokal model, og ændre mening på én dag, ikke på et kvartal. Dette kræver et design, hvor leverandørerne er udskiftelige, hvor ingen del er fastlåst til en bestemt virksomheds navn, hvor overgangen fra Regolo til Ollama (eller omvendt) er en konfigurationslinje, ikke en omskrivning. Og det var sjældent for nylig. Populære frameworks var, på trods af facaden af "provider-agnostisk", faktisk meget gift med nogen.