Lokalni LLM vs Claude/OpenAI API: kada se šta isplati

Prošle nedelje me je zvao osnivač jedne fintech firme iz Beograda. Pitanje je bilo direktno: "Imamo 40k poziva LLM-a dnevno, račun je već 3800 evra mesečno, da li da prebacimo sve na lokalni model?" Odgovor nije bio ni "da" ni "ne", nego pet pitanja koja sam morao da mu postavim pre nego što sam mogao da kažem bilo šta pošteno. Ovaj tekst je destilacija tih pitanja i brojeva koje sam video u praksi.

Nemam agendu. Gradio sam sisteme na Claude API-ju, na OpenAI-u, na Ollami sa Llama 3.1 i Qwen2.5 modelima, i na hibridima gde je 80% saobraćaja išlo lokalno a 20% u oblak. Svaki od tih izbora je bio ispravan za svoj kontekst, i svaki bi bio katastrofa u pogrešnom.

Pravi trošak nije cena po tokenu

Kad ljudi porede "Claude košta X po milion tokena" sa "lokalni model je besplatan", porede pogrešne stvari. Lokalni LLM nije besplatan, on je kapitalni trošak plus operativni trošak plus inženjerski trošak održavanja, dok je API operativni trošak bez glavobolje.

Evo realnog poređenja koje pravim za klijente, na osnovu Llama 3.1 70B na A100 GPU ili Qwen2.5 32B na L40S:

Tačka prelaska je negde između 50k i 100k poziva dnevno, zavisno od dužine konteksta. Ispod toga, API je gotovo uvek jeftiniji kada računaš ukupan trošak vlasništva. Iznad toga, lokalni model počinje da diše.

Ali ima jedna kvaka koju ljudi zaborave. Ako tvoj saobraćaj varira (recimo, 80% poziva ide u radno vreme), GPU stoji prazan 16 sati dnevno. API skalira na nulu, GPU ne. Tu hibrid postaje očigledan: lokalni za baseline, API za peak.

Latencija je drugačija priča od one koju očekuješ

Većina ljudi misli da je lokalni model brži jer "nema mreže". To je tačno za prvi token, ali nije cela priča.

Iz mojih merenja na produkcionim sistemima:

• Claude Sonnet preko API-ja iz Frankfurta: TTFT (time to first token) 400-700ms, throughput 60-90 tokena/sekundi.
• Llama 3.1 70B na A100 lokalno, vLLM, batch 1: TTFT 80-150ms, throughput 35-50 tokena/sekundi.
• Llama 3.1 70B na A100, batch 8 (8 paralelnih korisnika): TTFT 200-400ms po zahtevu, ali ukupan throughput sistema 250+ tokena/sekundi.

Lokalni model pobeđuje na TTFT, što je važno za chat UX. API pobeđuje na sirovom throughputu po jednom korisniku za duge odgovore. Za agentske workflow-e gde imaš 5-10 LLM poziva u nizu, lokalni model sa malim TTFT-om može da skrati ukupno trajanje agenta za 30-40% čak i kad je throughput niži.

Ako gradiš real-time voice agent, lokalno je gotovo uvek bolje. Ako gradiš nightly batch job koji procesira 200k dokumenata, latencija je nerelevantna i biraš na osnovu cene i kvaliteta.

Kvalitet: gde otvoreni modeli i dalje gube, gde sustižu

Ovo je sekcija gde mnogi tekstovi lažu. Nije istina da je Llama 3.1 405B "isto što i GPT-4". Nije, i ne treba da bude.

Za šta otvoreni modeli (Llama 3.1, Qwen2.5, Mistral) rade odlično u mojoj praksi:

• Strukturisani izlaz iz teksta: ekstrakcija polja iz faktura, ugovora, mejlova. Llama 3.1 70B sa dobrim prompt-om je u mojim testovima imala 96-98% tačnost na srpskim fakturama, što je u rangu sa GPT-4o.
• Klasifikacija i ruting: "Da li je ovaj tiket urgentan?", "U koju kategoriju ide ovaj proizvod?". Tu su čak i modeli od 7-8B parametara dovoljni.
• RAG sumiranje: kad imaš dobar retrieval, generacija je relativno laka i lokalni model je sasvim u redu.
• Code completion za interne alate: Qwen2.5-Coder je iznenađujuće dobar.

Gde otvoreni modeli i dalje gube:

• Složeno rezonovanje u više koraka: Claude Sonnet i o-serija OpenAI-a su ozbiljno ispred kada je u pitanju "razmisli pa odluči" logika.
• Tool calling pouzdanost: API-jevi imaju kalibrisaniji function calling. Lokalni modeli često haluciniraju imena alata ili pogrešno formatiraju JSON.
• Dugačak kontekst preko 32k: teoretski podržavaju, praktično degradiraju brže nego što očekuješ.
• Manje rasprostranjeni jezici sa specijalizovanim domenom: srpski medicinski tekst, na primer. Claude tu i dalje znatno bolje hvata nijanse.

Pravilo koje koristim: ako zadatak možeš da opišeš kao "uzmi input, primeni jasna pravila, vrati strukturisan output", lokalni model je verovatno dovoljan. Ako zahteva "razumevanje" u širem smislu, plati API.

Pouzdanost u produkciji: ono o čemu niko ne piše

Lokalni LLM nije servis, nego sistem koji moraš da održavaš. Stvari koje su me ujele i koje sad uvek planiram:

1. OOM (out of memory) pod opterećenjem. Llama 3.1 70B na A100 sa 80GB radi sjajno do trenutka kad neko pošalje prompt sa 28k tokena konteksta dok je batch pun. Tada pada. Rešenje: ograniči max kontekst, koristi vLLM sa paged attention, postavi request queue sa rate limitom.

2. Driver i CUDA verzije. Nadogradnja CUDA driver-a na hostu može da obori inference za nedelju dana. Pinuj sve verzije, koristi Docker sa NVIDIA Container Toolkit-om, ne dozvoli "samo da apdejtujemo nešto" na produkciji.

3. Tihi kvalitetni regresivni odgovori. Kad menjaš model verziju (Llama 3.1 -> 3.3), neki prompts koji su radili rade lošije. Bez eval suite-a ovo nećeš primetiti dok ti korisnik ne piše.

4. API rate limit je problem, ali predvidiv. OpenAI ti može uvesti 429 pod opterećenjem, ali znaš šta da radiš (exponential backoff, fallback model, queueing). Lokalno padanje je raznovrsnije i teže za debug.

Konkretno, za svaki lokalni LLM deployment koji pravim, minimum koji ide u produkciju:

# Skeletna struktura wrapper-a koju koristim
async def call_llm(prompt, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = await asyncio.wait_for(
                local_llm.generate(prompt, max_tokens=2000),
                timeout=30.0
            )
            if validate_output(result):
                return result
        except (asyncio.TimeoutError, CUDAOutOfMemory) as e:
            log_failure(e, attempt)
            if attempt == max_retries - 1:
                # Fallback na API kao safety net
                return await claude_api.generate(prompt)
            await asyncio.sleep(2 ** attempt)

Taj fallback na API je razlog zašto u praksi gotovo nijedan moj klijent ne ide "samo lokalno". Hibrid je realnost.

Privatnost i regulativa: kada je odluka već doneta

Ima slučajeva kada cena i latencija ne odlučuju, nego pravna stvar.

Ako obrađuješ:

• Medicinske podatke pacijenata u Srbiji (Zakon o zaštiti podataka o ličnosti, GDPR za EU klijente),
• Bankarske transakcije i KYC dokumente,
• Pravne dokumente za klijente koji ih ne smeju izložiti trećoj strani,
• Interne podatke firme pod NDA-om,

onda slanje tih podataka preko OpenAI ili Claude API-ja postaje pitanje koje moraš da raščistiš sa pravnikom i sa klijentom. Anthropic i OpenAI imaju zero retention opcije i potpisuju DPA, što za većinu B2B slučajeva pokriva GDPR. Ali za neke regulisane industrije, klijent jednostavno neće potpisati saglasnost.

Tu lokalni model nije pitanje cene, nego pretpostavka. I to je u redu, samo budite svesni da time povećavate svoj operativni teret. Pravi izbor je često: lokalni model za osetljive flow-ove, API za sve ostalo, sa jasno definisanim "trust boundary" između to dvoje.

Tri arhitekture koje stvarno rade

Umesto teorije, evo tri konkretna obrasca koja sam ispostavio i koja vrede.

Obrazac 1: API-first sa lokalnim fallback-om za privatnost

Default je Claude ili GPT. Ako request sadrži oznaku pii: true ili dolazi sa endpointa koji obrađuje osetljive podatke, ide na lokalni Llama 3.1. Najjednostavnije, najbrže za isporuku, najlakše za održavanje. Dobro za firme do 50k poziva dnevno gde 5-10% sadržaja zahteva izolaciju.

Obrazac 2: Lokalni baseline + API za teške zadatke

Lokalni model (Qwen2.5 32B na L40S, oko 1500 EUR mesečno) procesira 90% poziva: klasifikaciju, ekstrakciju, kratke odgovore. Composer logika detektuje kad je zadatak složen i tada poziva Claude Sonnet. Štedi 60-70% na API računu kad imaš stabilan volumen iznad 100k poziva dnevno.

Obrazac 3: API-only sa agresivnim cache-om

Pre nego što razmišljaš o lokalnom modelu, proveri da li ti uopšte treba. Semantic cache na nivou aplikacije (pgvector + embedding sličnost, threshold 0.92+) može da skrati API troškove za 40-60% za chat scenarije sa ponovljenim pitanjima. To je nedelju dana posla, a ne tri meseca kao postavljanje lokalne LLM infrastrukture.

Većini firmi koje me kontaktiraju u Srbiji i regionu treba Obrazac 1 ili Obrazac 3, ne Obrazac 2. Volumen jednostavno nije tu.

Šta bih ja uradio

Ako bih ja danas vodio onu fintech firmu sa 40k poziva dnevno i računom od 3800 evra:

1. Pre svega bih izmerio. Koliko poziva ima koji output? Koji su tačno troškovi po feature-u? Bez toga, svaka odluka je nagađanje.
2. Implementirao bih semantic cache. Realno, 30-50% poziva u fintech chat-ovima su varijante istih pitanja. To bi srušilo račun na 2000-2500 evra bez ikakvog modela.
3. Pomerio bih klasifikaciju i ekstrakciju na Qwen2.5 32B lokalno, ako se 20k+ od tih 40k poziva tiče ekstrakcije iz dokumenata. To je još 600-800 evra ušteda mesečno.
4. Zadržao bih Claude za customer-facing rezonovanje i bilo šta gde latencija i kvalitet konverzacije nose vrednost.
5. Eval suite od dana jedan. Bez toga, ne smeš da menjaš modele jer ne znaš kad si pokvario nešto.

Migracija sa pure API na hibrid se isplati za 4-6 meseci kod te firme. Ako bi mi rekao "imamo 5k poziva dnevno", odgovor bi bio: ostanite na API-ju, ulažite vreme u proizvod, ne u infrastrukturu.

To je suština koju ne želim da zaboraviš. Lokalni LLM ima smisla kad imaš volumen, kad imaš regulatorni razlog, ili kad imaš inženjerski tim koji već zna da održava GPU infrastrukturu. Ako nemaš nijedno od ta tri, plati API i fokusiraj se na vrednost koju gradiš za korisnike.

Ako ti se ovo poklapa sa pitanjima koja sad rešavaš, slobodno me povuci preko lazar-milicevic.com/#contact. Najradije razgovaram kad imaš konkretne brojeve, jer tek tada možemo da vidimo da li je lokalni model rešenje ili samo skup ukras.