Costul ascuns al cloud-ului

Capitolul 5 — Costul ascuns al cloud-ului

Narațiunea dominantă din ultimii cinci ani spune că cloud-ul este economic, scalabil și simplu. Pentru multe sarcini de lucru, acest lucru este perfect adevărat. Pentru RAG-urile enterprise, din ce în ce mai des, nu este așa. Și momentul în care îți dai seama este de obicei la sfârșitul primului trimestru, când sosește factura.

Să luăm în considerare cel mai subestimat element al costului: API-urile modelelor de viziune. Când o companie încarcă arhivele sale foto într-un RAG modern, fiecare fotografie trebuie "descrisă" de un model multimodal care extrage conținut, obiecte, context, eventuale texte suprapuse, starea de spirit, compoziția. Un mare furnizor european de modele — încă fără nume — oferea, în 2025, un model excelent din familia Qwen cu 32 de miliarde de parametri, la un preț per imagine interesant. Problema, descoperită doar pe teren și după luni de producție: sub sarcină, furnizorul trunchia răspunsurile. Nu întotdeauna, nu într-un mod previzibil, nu atunci când era echipa de testare în față: aleatoriu. O fotografie din zece, uneori una din cinci, revenea cu un JSON tăiat pe jumătate, parsate greșit, cu metadate parțiale sau nule. Timpii explodau de la zece secunde la două sute de secunde per imagine, fără un tipar. Factura pentru reîncercări — pentru că reîncercările se plătesc, fiecare apel, chiar și cel pe care serverul îl trunchiază — era mai mare decât se aștepta. Baza de date era neomogenă: unele fotografii bogate în metadate, altele trunchiate. Și echipa nu a reușit să reproducă problema în mediile de testare, deoarece în testare sarcina era scăzută și totul funcționa.

Soluția a venit în trei părți: un prompt mai compact (răspunsurile mai scurte se trunchiază mai puțin), o logică de retry inteligentă (dacă răspunsul durează mai mult de cincizeci de secunde și revine gol, încearcă imediat din nou) și — când volumul o justifică — posibilitatea de a sări cu totul peste cloud și de a rula modelul de viziune pe o GPU locală, mai lentă, dar deterministă. Arhitectura potrivită, din această experiență, nu este "cloud mereu" nici "local mereu". Este "alege pentru fiecare apel, în funcție de ce este necesar în acel moment".

Apoi este capitolul interogărilor. Fiecare căutare a utilizatorului, într-un RAG nativ cloud clasic, declanșează o cascadă de apeluri API plătite. Una pentru embedding-ul întrebării. Una pentru clasificarea intenției (ce tip de întrebare este?). Una pentru reranking-ul documentelor. Una pentru generarea răspunsului final. Fiecare costă o fracțiune de centim. Pentru un serviciu intern cu cincizeci de utilizatori și zece mii de interogări pe zi — care nu sunt puține, dar nici un număr enorm pentru o companie medie — factura lunară ajunge la cifre care l-ar face pe un CFO indulgent să încrețească fruntea. Și creșterea este liniară: dublezi utilizatorii, dublezi factura. Nu există economii de scară în token-urile consumate, nu pentru tine.

Există și o problemă care în 2025 era latentă și care în 2026 a devenit centrală: fiecare interogare trimite fragmente din documente corporative — uneori confidențiale, uneori acoperite de NDA, uneori supuse reglementărilor din industrie — către serverele unui furnizor extern, în jurisdicții care nu coincid întotdeauna cu a ta, cu politici privind conservarea logurilor nu întotdeauna clare. Mai mult de o companie europeană, în ultimele optsprezece luni, a descoperit doar în timpul unui audit — de obicei inițiat de un client îngrijorat sau de o verificare ISO — că propriile contracte, liste de prețuri și specificații tehnice au fost procesate (și potențial înregistrate în scopuri de "îmbunătățire a serviciului") de infrastructuri din afara UE. Surpriza, de obicei, a costat mai mult decât economiile realizate prin evitarea hardware-ului local.

Alternativa nu este dogma opusă. "Nu cloud, da local" este la fel de greșit ca "cloud da întotdeauna". Alternativa este o arhitectură care vă permite să alegeți, pentru fiecare element al pipeline-ului — embedding, clasificare, reranking, viziune, generare finală — dacă să utilizați un model cloud sau unul local, și să vă schimbați părerea într-o zi, nu într-un trimestru. Acest lucru necesită un design în care furnizorii sunt interschimbabili, în care nicio piesă nu este fixată pe numele unei companii specifice, în care trecerea de la Regolo la Ollama (sau invers) este o linie de configurare, nu o rescriere. Și asta, până de curând, era rar. Framework-urile populare, în ciuda fațadei de "agnostic față de furnizor", erau de fapt foarte căsătorite cu cineva.