A felhő rejtett költségei

5. fejezet – A felhő rejtett költségei

Az elmúlt öt év narratívája szerint a felhő költséghatékony, skálázható és egyszerű. Sok munkafolyamat esetén ez tökéletesen igaz. A vállalati RAG-alkalmazások esetében azonban egyre gyakrabban nem az. És a pillanat, amikor rájössz, általában az első negyedév vége, amikor megérkezik a számla.

Vegyük a számla leginkább alábecsült elemét: a vizuális modellek API-jai. Amikor egy vállalat betölti fotóit egy modern RAG-be, minden fotót egy többmódusú modellnek kell "leírnia", amely kinyeri a tartalmat, tárgyakat, kontextust, esetleges ráírt szövegeket, hangulatot, kompozíciót. Egy nagy európai modell-szolgáltató – még név nélkül – 2025-ben kínált egy kiváló, 32 milliárd paraméteres Qwen családbeli modellt, érdekes képenkénti áron. A probléma, amelyet csak a gyakorlatban és hónapoknyi termelés után fedeztek fel: terhelés alatt a szolgáltató levágta a válaszokat. Nem mindig, nem kiszámítható módon, nem akkor, amikor a tesztelő csapat állt előtte: véletlenszerűen. Tíz fotó közül egy, néha öt közül egy érkezett vissza félbe vágott JSON-nal, rosszul értelmezve, hiányos vagy null metadattal. Az idők tíz másodpercről kétszáz másodpercre ugrottak képenként, mintázat nélkül. Az újratöltés költsége – mert az újratöltéseket meg kell fizetni, minden hívást, még azt is, amelyet a szerver levág – magasabb volt a vártnál. Az adatbázis inhomogén volt: néhány fotó gazdag metadattal, mások csonkán. És a csapat nem tudta reprodukálni a problémát tesztkörnyezetben, mert a teszteken alacsony volt a terhelés, és minden működött.

A megoldás három részből állt: egy tömörebb prompt (a rövidebb válaszok kevésbé vágódnak le), egy intelligens újrapróbálkozási logika (ha a válasz több mint ötven másodpercet vesz igénybe és üresen tér vissza, azonnal próbálkozzon újra) és – ha a mennyiség indokolja – a felhő teljes kihagyása és a vizuális modell futtatása egy helyi, lassabb, de determinisztikus GPU-n. A megfelelő architektúra, ebben a tapasztalatban, nem a "mindig felhő" és nem a "mindig helyi". A "válasszon minden hívásnál, attól függően, hogy mire van szükség abban a pillanatban".

Aztán ott vannak a lekérdezések. Minden felhasználói keresés egy klasszikus, felhőalapú RAG esetén egy fizetős API-hívások sorozatát indítja el. Egy a kérdés beágyazásához. Egy a szándék osztályozásához (milyen típusú a kérdés?). Egy a dokumentumok átrendezéséhez. Egy a végső válasz generálásához. Mindegyik töredék centbe kerül. Egy belső szolgáltatás ötven felhasználóval és naponta tízezer lekérdezéssel – ami nem kevés, de egy közepes méretű vállalkozás számára nem is hatalmas szám – a havi számla olyan összegre rúg, ami még egy engedékeny pénzügyi igazgatót is felháboríthat. A növekedés lineáris: ha megduplázod a felhasználók számát, megduplázod a számlát. Nincs méretgazdaságosság a felhasznált tokenekben, nem neked.

Van egy olyan probléma is, ami 2025-ben még háttérben alakult, de 2026-ra központi kérdéssé vált: minden egyes lekérdezés a vállalati dokumentumok darabjait – néha bizalmas, néha NDA-val fedett, néha iparági szabályozásoknak alávetett – küldi egy külső szolgáltató szervereire olyan joghatóságokra, amelyek nem feltétlenül egyeznek meg az Ön joghatóságával, és amelyek napló-megőrzési szabályzatai nem mindig átláthatóak. Több európai vállalat is az elmúlt tizennyolc hónapban csak egy audit során – általában egy aggódó ügyfél vagy egy ISO ellenőrzés által kiváltott – fedezte fel, hogy szerződéseiket, árajánlataikat és műszaki specifikációikat az EU-n kívüli infrastruktúrák dolgozták fel (és potenciálisan naplózta a "szolgáltatás javítása" céljából). Az ilyen meglepetés általában többe kerül, mint a helyi hardverrel szemben elért megtakarítás, amit el akartak kerülni.

A megoldás nem az ellentétes dogma. A "Nem a felhő, hanem a helyi megoldás" ugyanolyan rossz, mint a "Mindig a felhő". A megoldás egy olyan architektúra, amely lehetővé teszi, hogy minden egyes elemre a folyamatban – beágyazás, osztályozás, újrarangsorolás, látás, végső generálás – kiválaszthassuk, hogy felhőalapú vagy helyi modellt használjunk, és egy nap alatt megváltoztassuk a véleményünket, nem egy negyedév alatt. Ehhez egy olyan tervre van szükség, amelyben a szállítók cserélhetők, ahol egyetlen elem sem ragadt le egy adott vállalat nevéhez, ahol a Regolóról az Ollamára (vagy fordítva) való átállás egy konfigurációs sor, nem pedig egy újrafogalmazás. És ez, egészen nemrégig, ritka volt. A népszerű keretrendszerek, a "szállító-semleges" látszat ellenére, valójában nagyon kötődtek valakihez.