Ukryty koszt chmury

Rozdział 5 — Ukryty koszt chmury

Dominujący narracja ostatnich pięciu lat mówi, że chmura jest tania, skalowalna i prosta. Dla wielu obciążeń jest to całkowicie prawda. Dla korporacyjnych aplikacji RAG coraz częściej tak nie jest. A moment, w którym się o tym dowiadujesz, to zazwyczaj koniec pierwszego kwartału, kiedy przychodzi faktura.

Wybierzmy najbardziej niedocenianiony element kosztów: API modeli wizyjnych. Kiedy firma wprowadza swoje archiwum fotograficzne do nowoczesnego systemu RAG, każde zdjęcie musi zostać "opisane" przez model multimodalny, który wyodrębnia z niego zawartość, obiekty, kontekst, ewentualne teksty nakładane, nastrój, kompozycję. Duński dostawca modeli — wciąż bez nazwy — oferował w 2025 roku doskonały model z rodziny Qwen o 32 miliardach parametrów, w atrakcyjnej cenie za obraz. Problem, odkryty dopiero w praktyce i po miesiącach produkcji: pod obciążeniem dostawca obcinał odpowiedzi. Nie zawsze, nie w przewidywalny sposób, nie gdy przed nim znajdował się zespół testowy: losowo. Co dziesiąte zdjęcie, czasami jedno na pięć, wracało z obciętym JSON-em, źle sparsowanym, z niekompletnymi lub pustymi metadanymi. Czas skakał z dziesięciu sekund do dwóchset sekund na obraz, bez żadnego wzorca. Rachunek za ponowne próby — ponieważ ponowne próby są płatne, każde wywołanie, nawet to, które serwer obcina — był wyższy niż oczekiwano. Baza danych była niejednorodna: niektóre zdjęcia bogate w metadane, inne ucięte. A zespół nie mógł odtworzyć problemu w środowiskach testowych, ponieważ w testach obciążenie było niskie i wszystko działało.

Rozwiązanie przyszło w trzech częściach: bardziej zwięzły prompt (krótsze odpowiedzi rzadziej się obcinają), inteligentna logika ponawiania (jeśli odpowiedź trwa dłużej niż pięćdziesiąt sekund i wraca pusta, spróbuj ponownie natychmiast) i — gdy wolumen to uzasadnia — możliwość całkowitego pominięcia chmury i uruchomienia modelu wizyjnego na lokalnej karcie GPU, wolniejszej, ale deterministycznej. Właściwa architektura, jak wynika z tego doświadczenia, to nie "zawsze chmura" ani "zawsze lokalnie". To "wybierz dla każdego zapytania, w zależności od tego, czego potrzeba w danym momencie".

Następnie jest rozdział zapytań. Każde wyszukiwanie użytkownika w klasycznym, natywnym dla chmury RAG uruchamia kaskadę płatnych wywołań API. Jedno dla osadzenia pytania. Jedno dla klasyfikacji intencji (jakiego typu jest pytanie?). Jedno dla ponownego rankingu dokumentów. Jedno dla wygenerowania ostatecznej odpowiedzi. Każde kosztuje ułamki centa. Dla usługi wewnętrznej z pięćdziesięcioma użytkownikami i dziesięcioma tysiącami zapytań dziennie — co nie jest mało, ale też nie jest ogromną liczbą dla średniej firmy — miesięczny rachunek sięga kwot, które zniechęciłyby nawet pobłażliwego CFO. A wzrost jest liniowy: podwoisz liczbę użytkowników, podwoisz rachunek. Nie ma ekonomii skali w zużytych tokenach, nie dla ciebie.

Istniał również problem, który w 2025 roku był ukryty, a w 2026 roku stał się centralny: każde pojedyncze zapytanie wysyła fragmenty dokumentów firmowych — czasem poufnych, czasem objętych umowami NDA, czasem podlegających regulacjom branżowym — na serwery dostawcy zewnętrznego, w jurysdykcjach, które nie zawsze pokrywają się z Twoją, z zasadami przechowywania logów, które nie zawsze są jasne. Wiele europejskich firm w ciągu ostatnich osiemnastu miesięcy odkryło podczas audytu — zwykle zainicjowanego przez zaniepokojonego klienta lub weryfikację ISO — że ich umowy, cenniki i specyfikacje techniczne zostały przetworzone (i potencjalnie zalogowane w celu "udoskonalenia usługi") przez infrastrukturę spoza UE. Zaskoczenie to zwykle kosztowało więcej niż oszczędności na sprzęcie lokalnym, które chciano uniknąć.

Alternatywą nie jest dogmatyczna przeciwstawność. "Nie dla chmury, tylko lokalnie" jest równie błędne, co "zawsze chmura". Alternatywą jest architektura, która pozwala wybrać, dla każdego pojedynczego elementu potoku — osadzanie, klasyfikacja, ponowne szeregowanie, wizja, generacja końcowa — czy użyć modelu chmurowego, czy lokalnego, i zmienić zdanie w ciągu dnia, a nie kwartału. Wymaga to projektu, w którym dostawcy są wymienni, gdzie żaden element nie jest trwale związany z nazwą konkretnej firmy, gdzie przejście z Regolo do Ollamy (lub odwrotnie) to linia konfiguracji, a nie przepisywanie kodu. A to, do niedawna, było rzadkie. Popularne frameworki, pomimo pozorów "niezależności od dostawcy", były w rzeczywistości silnie powiązane z kimś.