Pilven piilokustannukset

Luku 5 — Pilven piilokustannukset

Viimeisten viiden vuoden vallitseva kertomus on, että pilvi on edullinen, skaalautuva ja yksinkertainen. Monille työkuormille tämä pitää täysin paikkansa. Yritysten RAG-sovelluksille se ei kuitenkaan usein ole totta. Ja hetki, jolloin huomaat tämän, on yleensä ensimmäisen vuosineljänneksen lopussa, kun lasku saapuu.

Otetaan laskelman aliarvostetuin kohta: näköismallien API-rajapinnat. Kun yritys lataa kuvakokoelmansa moderniin RAG-järjestelmään, jokainen kuva on "kuvattava" monimuotoisella mallilla, joka poimii siitä sisällön, objektit, kontekstin, mahdolliset päällekkäiset tekstit, tunnelman ja sommittelun. Suuri eurooppalainen mallitoimittaja – jonka nimeä ei vielä paljasteta – tarjosi vuonna 2025 erinomaisen Qwen-perheen 32 miljardin parametrin mallin kiinnostavaan hintaan kuvaa kohden. Ongelma, joka havaittiin vasta käytännössä ja kuukausien tuotannon jälkeen: toimittaja katkoi vastauksia kuormituksen alaisena. Ei aina, ei ennustettavasti, ei kun testitiimi oli paikalla: satunnaisesti. Yksi kymmenestä kuvasta, toisinaan jopa yksi viidestä, palautti puolikkaan JSON-tiedoston, joka oli jäsennetty huonosti, ja jossa oli puutteellisia tai tyhjiä metatietoja. Aika nousi kymmenestä sekunnista kahteen sataan sekuntiin kuvaa kohden, ilman mitään kaavaa. Uusintayritysten lasku – koska uusintayrityksistä maksetaan, jokaisesta kutsusta, jopa siitä, jonka palvelin katkaisee – oli odotettua suurempi. Tietokanta oli epäyhtenäinen: joissakin kuvissa oli runsaasti metatietoja, toisissa puutteellisesti. Ja tiimi ei pystynyt toistamaan ongelmaa testausympäristöissä, koska testauksessa kuormitus oli alhainen ja kaikki toimi.

Ratkaisu saapui kolmessa osassa: tiiviimpi kehote (lyhyemmät vastaukset eivät katkea niin helposti), älykäs uudelleenyrityslogiikka (jos vastauksen saamisessa kestää yli viisikymmentä sekuntia ja se palauttaa tyhjän, yritä heti uudelleen) ja – kun volyymi sen oikeuttaa – mahdollisuus ohittaa pilvi kokonaan ja ajaa näkömalli paikallisella GPU:lla, joka on hitaampi mutta deterministinen. Oikea arkkitehtuuri, tämän kokemuksen perusteella, ei ole "aina pilvi" eikä "aina paikallinen". Se on "valitse jokaiselle kutsulle sen mukaan, mitä sillä hetkellä tarvitaan".

Sitten on kyselyjen luku. Jokainen käyttäjän haku käynnistää klassisessa pilvipohjaisessa RAG:ssa maksullisten API-kutsujen putouksen. Yksi kysymyksen upottamiseen. Yksi tarkoituksen luokitteluun (millainen kysymys on?). Yksi dokumenttien uudelleenjärjestämiseen. Yksi lopullisen vastauksen luomiseen. Jokainen maksaa murto-osan sentistä. Sisäiselle palvelulle, jossa on viisikymmentä käyttäjää ja kymmenentuhatta kyselyä päivässä – mikä ei ole vähän, mutta ei myöskään valtava määrä keskikokoiselle yritykselle – kuukausilasku nousee lukemiin, jotka saavat jopa joustavan talousjohtajan kurtistamaan kulmiaan. Ja kasvu on lineaarista: tuplaat käyttäjät, tuplaat laskun. Kulutettujen tokenien skaalaus ei ole mahdollista, ei sinulle.

On myös ongelma, joka oli vuonna 2025 pinnan alla ja joka vuonna 2026 nousi keskeiseksi: jokainen yksittäinen kysely lähettää pätkiä yritysdokumenteista – joskus luottamuksellisia, joskus NDA:n alaisia, joskus toimialakohtaisten määräysten alaisia – ulkopuolisen palveluntarjoajan palvelimille, lainkäyttöalueille, jotka eivät välttämättä vastaa omaasi, ja lokien säilytyskäytännöt eivät ole aina selkeitä. Yli yksi eurooppalainen yritys on viimeisen kahdeksantoista kuukauden aikana huomannut vasta auditoinnin aikana – yleensä huolestuneen asiakkaan tai ISO-tarkastuksen johdosta – että sen sopimukset, hinnastot ja tekniset tiedot on käsitelty (ja mahdollisesti kirjattu palvelun "parantamiseksi") EU:n ulkopuolisilla infrastruktuureilla. Yllätys on yleensä maksanut enemmän kuin paikallisen laitteiston säästö, jonka haluttiin välttää.

Vastavaihtoehto ei ole vastakkainen dogma. "Ei pilveen, paikallisesti kyllä" on yhtä väärä kuin "pilveen aina". Vastavaihtoehto on arkkitehtuuri, jonka avulla voit valita jokaiselle putkilinjan osalle – upotukset, luokittelu, uudelleenjärjestely, näkökyky, lopullinen generointi – käytätkö pilvimallia vai paikallista mallia, ja muuttaa mielesi päivässä, et vuosineljänneksessä. Tämä edellyttää suunnittelua, jossa toimittajat ovat vaihdettavissa, jossa mikään osa ei ole naulattu tietyn yrityksen nimeen, jossa siirtyminen Regolosta Ollamaan (tai päinvastoin) on konfiguraatiorivi, ei uudelleenkirjoitus. Ja tämä oli, kunnes äskettäin, harvinaista. Suositut kehykset, huolimatta "toimittajasta riippumattomasta" julkisivusta, olivat todellisuudessa hyvin naimisissa jonkun kanssa.