LLM waterfall: zašto lokalni model dolazi prvi, a cloud zadnji

Većina kompanija koje koriste generativnu AI plaća po principu "sve ide u cloud". To je kao voziti Teslu na motorinu jer je benzinska stanica daleko. Rezultat: mjesečni račun od četiri do deset puta veći nego što bi trebao biti, a latencija gora. Problem nije tehnologija. Problem je rutiranje. Ako imate tekstualnu analizu, routing logiku ili opis proizvoda koji se mogu obraditi s 7 milijardi parametara umjesto 70 milijardi, a vi i dalje šaljete sve u Claude za 0,003 dolara po tisuću tokena, gubite novac na način koji je gotovo namjeran. Ovdje objašnjavamo kako funkcionira cost-aware AI waterfall, koji je pristup koji koriste kompanije koje znaju što rade, i zašto većina vas to ne radi.

Arhitektura koju ćemo razmotriti nije revolucionarna. Čini se očiglednom čim je vidite. Počinje sa lokalnim modelom — najčešće neka varijanta Qwena 7B u AWQ kvantizaciji, pokrenuta putem vLLM-a na vašim GPU resursima ili rented GPU infrastrukturi. Taj model hvata otprilike 85 do 92 posto slučajeva koji ne trebaju sofisticiranu logiku — parafraziranje, ekstraktcija entiteta, klasifikacija, osnovne kalkulacije. Cijena pokretanja tog modela, ako ga amortizujete preko 10 tisuća zahtjeva dnevno na skromnoj GPU instanci, pada ispod 0,00002 dolara po milijun tokena. Slobodno čitaj to kao "besplatno". Zatim, ako lokalni model ne uspije — što se detektuje kroz confidence scoring ili jednostavnu povratnu petlju — zahtjev ide prema Groq-u. Groq nudi besplatni tier sa ograničenjima, ali za proizvodnju ima plaćeni tier od otprilike 0,0005 dolara po milijun tokena za inference. To je dvadesetak puta jeftinije od Claude-a. Treća razina je DeepSeek API, koja nudi modele kao DeepSeek-V3 po cijeni od 0,0008 dolara po milijun input tokena i 0,002 dolara po milijun output tokena — što je i dalje između tri i pet puta jeftinije od standardnih Claude Sonnet ili GPT-4 modela. Tek na kraju, ako trebate najnapredniju logiku — kompleksne odluke, duboka analiza konteksta, specijalizirani znanja — ide u Claude 3.5 Sonnet ili OpenAI GPT-4 Turbo na 0,003 dolara po input tokenu.

Zašto većina kompanija to ne radi? Razlozi su arhitekturni, ali ne tehnički. Prvo, većina AI timova je sagrađena oko jednog modela — Azure OpenAI ili Anthropic partnership. Nema fleksibilnosti u rutiranju jer je infrastruktura već ugovorena. Drugo, inženjerski tim koji implementira AI rješenja obično ne razmišlja o cost-optimization kao primarnom zahtjevu. Fokus je na "radi li", ne na "koliko je skupo". Treće, routing logika zahtijeva da razumijete vašu domenu dovoljno dobro da znate što zahtjev trebate — što je rad. Lakše je sve baciti u Claude-a i reći klijentu da je to cijena. Četvrto, latencija i throughput postaju komplicirani kada imate više modela. Ako lokalni vLLM zahtijeva 300 milisekundi, Groq zahtijeva 50 milisekundi, a Claude zahtijeva 2 sekunde, kako znate koji zahtjev trebate gdje rutirizirati bez da klijent čeka? Odgovor je u async queue-ovima i prioritizaciji, što nije trivijalno. Peto, compliance i auditabilnost. Ako koristite tri različita modela, trebate znati što je obradio koji, kako, i zašto. Jedan model je jednostavniji za reviziju.

Tehnički, waterfall izgleda ovako. Zahtjev ulazi u async queue. Prvo, izvlači se input token count — to je brz parsing, ne inference. Ako je token count ispod 500 i uzorak sličan onima koji su klasificirani kao "low-complexity", ide direktno u vLLM instancu. vLLM je framework koji pokušava biti maksimalno efikasan — koristi paged attention, dynamic batching, i operator fusion. Na GPU-u sa 24GB VRAM-a, može servirati više od 100 istovremenih zahtjeva sa Qwen 7B modelom u AWQ kvantizaciji. Latencija je često ispod 200 milisekundi čak i ako je model pod opterećenjem. Ako lokalni model završi sa povjerenjem većim od 0,8 (što je prilagodljivo po domeni), odgovor se vraća klijentu. Ako je povjerenje ispod praga ili ako model ima timeout, zahtjev ide u Groq queue. Groq je specijaliziran za inference — koristi vlastiti hardware (LPU, Language Processing Unit) koji je optimiziran za matrix operacije. Groq ima besplatni tier sa limitom od recimo 5000 zahtjeva mjesečno ili 10 milijardi tokena, što je dovoljno za development i male produkcije. Ako prebrodite besplatni tier ili trebate SLA, plaćeni tier je jasan. Ako Groq queue ima timeout ili ako je zahtjev označen kao "trebam best-in-class", ide u DeepSeek. DeepSeek je prihvatljiv jer je brz, jeftiniji od Claudea, i često dovoljno dobar za većinu slučajeva. DeepSeek-V3 ima kontekst od 64K tokena i razumno je dobar u multi-step reasoning-u. Tek na kraju, ako ništa drugo nije uspjelo ili ako je zahtjev eksplicitno označen kao "premium", ide u Claude.

Konkretni brojevi čine razliku. Pretpostavimo da vaša kompanija obradi 10 milijuna tokena dnevno. To je razumna brojka za mid-market aplikaciju. Ako sve ide u Claude 3.5 Sonnet, to je 0,003 dolara po tisuću input tokena. Deset milijuna tokena dnevno znači 30 dolara dnevno, 900 dolara mjesečno. Ako ista 10 milijuna tokena ide kroz waterfall — pretpostavimo 85 posto kroz vLLM (besplatno), 10 posto kroz Groq (0,0005 dolara po milijun tokena), 4 posto kroz DeepSeek (0,0008 dolara po milijun input tokena), i 1 posto kroz Claude (0,003 dolara po milijun tokena) — dobivate: vLLM 8,5 milijuna tokena po 0 dolara, Groq 1 milijun tokena po 0,0005 dolara, DeepSeek 0,4 milijuna tokena po 0,0008 dolara, Claude 0,1 milijuna tokena po 0,003 dolara. Ukupno: 0 + 0,50 + 0,32 + 0,30 dolara = 1,12 dolara dnevno, ili 33 dolara mjesečno. To je 27 puta jeftinije. Čak i ako je vaš waterfall manje efikasan — recimo 60 posto kroz vLLM, 20 posto kroz Groq, 15 posto kroz DeepSeek, 5 posto kroz Claude — dobivate 0 + 1 + 1,2 + 1,5 dolara = 3,70 dolara dnevno, ili 111 dolara mjesečno. To je i dalje 8 puta jeftinije od samo Claude-a.

Latencija nije žrtva. Većina waterfall implementacija ima P95 latenciju koja je zapravo bolja nego ako sve ide u jedan cloud model. Zašto? Jer lokalni vLLM ima predvidljivu latenciju — obično 150 do 300 milisekundi. Groq ima latenciju od 30 do 100 milisekundi jer je specijaliziran za inference i nema queue-a kao AWS ili Azure. DeepSeek ima latenciju od 500 do 1500 milisekundi jer je remote, ali je i dalje brži od Claude-a koji može biti 2 do 5 sekundi ako je opterećen. Ako rutiranje radi dobro, klijent vidi P50 latenciju od 200 milisekundi jer je većina zahtjeva obradjena lokalnim modelom. Ako je zahtjev koji trebam Groq, P95 je možda 300 milisekundi. Samo rare premium zahtjevi čekaju 2 sekunde. To je bolje nego ako sve ide u Cloud i P95 je uvijek 2 sekunde.

Kako znate što trebate rutirizirati? To je gdje dolazi domenska analiza. Trebate razumjeti vašu domenu. Ako ste AI kompanija koja radi na customer support, trebate znati da je 70 posto zahtjeva klasifikacija ili FAQ matching — to je Qwen 7B posao. 20 posto je kompleksnija analiza — to je Groq posao. 10 posto trebaje reasoning ili kontekstualnu analizu — to je DeepSeek posao. 0 posto trebaje Claude jer, iskreno, za customer support, Claude je overkill. Ako ste kompanija koja radi na medical documentation, situacija je drugačija — trebate veću sigurnost i više reasoning-a. Ali čak i tada, prvi waterfall korak bi bio lokalni model za ekstrakciju i normalizaciju, ne za kompleksnu analizu. Domenska znanja trebate sakupiti kroz analizu zahtjeva — što je zapravo dobar rad koji trebate napraviti ionako.

Implementacijski detalji su pragmatični. Trebate async queue sistem — Redis ili RabbitMQ. Trebate health checks za svaki model endpoint. Trebate confidence scoring — što znači da vLLM ne vraća samo odgovor, nego i score povjerenja. Za klasifikaciju, to je lako — koristite softmax output. Za generaciju, to je teže — možete koristiti perplexity ili self-critique, ali to dodaje latenciju. Alternativa je da koristite heuristike — ako je output kraći od očekivanog, nižite score. Trebate i logging — trebate znati što je koji model obradio, kako, i zašto. To je važno za debugging i za razumijevanje gdje je optimizacija bila uspješna. Trebate i fallback strategiju — što ako vLLM pada? Ide direktno u Groq. Što ako Groq pada? Ide u DeepSeek. Što ako sve pada? Trebate graceful degradation — možda vraćate cached odgovor ili jednostavnu poruku o grešci umjesto da klijent čeka.

Kvaliteta nije žrtva ako je routing dobar. Lokalni Qwen 7B model ima razumne performanse na većini zadataka — nije Claude, ali za klasifikaciju, ekstrakciju, i parafraziranje, razlika je često manja od 5 posto. Groq koristi iste modele kao OpenAI za određene slučajeve, ili koristi vlastite modele koji su komparabilni.