Sredinom 2026. razmak između modela koje možete pokrenuti na vlastitom hardveru i onih dostupnih samo preko API-ja se suzio. Qwen3.6 35B-A3B i Gemma 4 27B rade na 24GB VRAM-a, uz kvalitet koji je za veliku većinu developerskih zadataka – kod, sumarizaciju, RAG, agentne pipeline-ove s jasno definisanim tool-ovima – potpuno dovoljan. Ovaj tekst je praktičan vodič od nule do prvog API poziva na localhost-u: hardver, izbor modela, kvantizacija, alati i konkretne komande.

Zašto lokalno, a ne API

Razlozi su konkretni, ne ideološki.

Privatnost. Podaci – kod, interni dokumenti, klijentski upiti – ne napuštaju mašinu. Za timove koji rade s osjetljivim materijalom to skida cijelu kategoriju rizika (data residency, ugovori o obradi podataka, ugovori o povjerljivosti) koja postoji čim upit ode na eksterni endpoint.

Trošak. Nema naplate po tokenu. Trošak je unaprijed (hardver) i tekući (struja), a ne granični po upitu – što se isplati tek pri visokom volumenu ili kontinuiranom razvojnom radu (iteracija na promptovima, batch-evaluacija).

Kontrola. Birate tačnu verziju modela i kvantizaciju, i one ostaju takve dok ih vi ne promijenite. Vendor vam ne može tiho zamijeniti model iza istog naziva ili ugasiti endpoint.

Offline rad i latencija. Radi bez interneta i bez network round-trip-a, što je relevantno za edge deployment i za razvoj na terenu.

Iskreno o trade-offu: za teže rezonovanje i agentne zadatke s dugim, nepredvidivim tool-use lancima, najveći closed-weight modeli (flagship tier kod OpenAI-a, Anthropica, Google-a) i dalje generalno vode. Lokalni model je pravi izbor kad je zadatak dovoljno definisan da manji, brži model radi posao – ne kao univerzalna zamjena.

Trošak vrijedi računati konkretno, ne uopšteno. Ako vaš tim šalje desetine hiljada upita dnevno kroz interni alat (code review bot, klasifikacija ticket-a, RAG nad internom dokumentacijom), po-token naplata se akumulira brzo, dok je hardver jednokratan trošak koji se amortizuje kroz mjesece rada. Za povremenu upotrebu ili zadatke koji zahtijevaju najbolji mogući kvalitet po upitu, ta računica ide u drugom pravcu – API i dalje pobjeđuje.

Hardver: šta zaista treba

VRAM je primarna prepreka za GPU inferenciju. Model (težine + KV cache) mora stati u VRAM. Prelazak s FP16 na Q4 kvantizaciju smanjuje otisak u memoriji za oko 4x uz mali gubitak kvaliteta – to je razlog zašto kvantizacija nije opcionalna sitnica nego prvi korak u planiranju hardvera.

Grube VRAM granice pri Q4 kvantizaciji:

  • 8B model ≈ 5–6 GB
  • 14B model ≈ 9 GB
  • 30–32B model ≈ 19–20 GB
  • 70B model ≈ 38–40 GB

16 GB VRAM je praktični pod za 2026. – ispod toga teško idete iznad 13B klase modela s razumnom brzinom.

CPU/RAM inferencija radi, ali je spora. Upotrebljivo za male modele (do ~4B) ili kao overflow kad MoE model dijelom stane u VRAM, dijelom ne. Za 30B+ modele CPU-only nije komforan izbor za interaktivan rad.

Apple Silicon i unified memory (UMA) mijenjaju računicu. CPU, GPU i Neural Engine dijele jedan memorijski pool, pa Mac s 64GB unified memory može pokrenuti modele koje RTX 4090 sa svojih 24GB VRAM-a ne može – VRAM granica na diskretnoj GPU kartici ne postoji na istom mjestu kod Apple Silicon arhitekture. M5 čip (mart 2026) dodaje Neural Accelerators po jezgru, što kroz MLX i Metal 4 navodno ubrzava generaciju u odnosu na M4 – konkretan procenat kruži u sekundarnim izvorima, ali nije nezavisno potvrđen, pa ga treba tretirati kao tvrdnju, ne kao mjerenje.

Runtime/framework također utiče na brzinu, neovisno od samog hardvera: u zajednici se navodi da je MLX brži od llama.cpp na M5 kod modela koji stanu kompletno u memoriju, dok se razlika gubi kod velikih dense modela (70B-klasa) gdje je memorijski propusni opseg, a ne compute, ograničavajući faktor. I ovo je community-reported opservacija bez primarnog benchmark izvora – korisno za intuiciju, ne za odluku o kupovini hardvera.

Za CPU-only setup, bitniji je propusni opseg RAM-a (memory bandwidth) nego broj jezgara – inferencija je kod velikih modela usko grlo na memoriji, ne na računanju, pa dvostruko brži CPU s istim RAM propusnim opsegom donosi mali efektivni dobitak. Na duže, kontinuirano opterećenje (batch evaluacija, servis koji stoji upaljen po cijeli dan) vrijedi i planirati hlađenje – konzumerske GPU kartice pri 100% opterećenju satima nisu dizajnirane za data-center thermal profile, pa throttling nije neobičan.

Odabir modela: presjek sredine 2026.

Mixture-of-experts (MoE) modeli mijenjaju kako treba čitati specifikacije. Bitan hardverski broj je često broj aktivnih parametara, ne ukupan broj parametara – community coverage skoro uvijek naglašava ukupan broj, što preuveličava stvarne VRAM potrebe. Primjer: Qwen3.6-35B-A3B ima 35B ukupno, ali samo ~3B aktivnih po tokenu – VRAM potreba je bliža 3B-klasi nego 35B-klasi dense modela.

Trenutna lokalno-realistična ponuda:

  • Qwen3.6 (Alibaba) – trenutno vodeća open-weight familija za lokalno pokretanje. 27B (dense) i 35B-A3B (MoE), objavljeni april 2026, nativni kontekstni prozor (context window) od 262K tokena, proširiv na oko 1M.
  • Gemma 4 (Google DeepMind) – objavljen 2. aprila 2026. Veličine E2B/E4B/26B/31B, Apache 2.0 licenca (Gemma 3 je imala restriktivniju licencu, u Gemma 4 je uklonjena), 256K kontekstni prozor.
  • Llama 4 (Meta) – Scout (staje na jednu high-end GPU karticu, MoE arhitektura) i Maverick (400B ukupno, MoE) su trenutno dostupan open-weight nivo. Behemoth ostaje neobjavljen/preview, koristi se samo kao teacher model za destilaciju.
  • Mistral Small 4 (16. mart 2026) – unificirani rezonovanje/multimodalni/agentic-coding model, Apache 2.0, veličina realistična za lokalno pokretanje. Mistral Large 3 (decembar 2025) je MoE 675B ukupno / 41B aktivnih – to je data-center klasa, ne lokalni hardver.
  • DeepSeek – V3.2 (1. decembar 2025, MIT licenca) je opšte-namjenski open release i trenutno najrelevantniji DeepSeek model za lokalno pokretanje. V4-Pro (1.6T) i V4-Flash (284B) su najavljeni kao preview 24. aprila 2026, ali su data-center razmjera. R2 nema potvrđen datum izlaska.

Kod odabira po zadatku, active-parameter razlika mijenja preporuku: za agentne pipeline-ove s puno tool-calling koraka, MoE model s malim brojem aktivnih parametara (npr. Qwen3.6-35B-A3B) daje brzinu bliže 3B-klasi modelu uz kvalitet bliže 35B-klasi za taj konkretan korak – dobar kompromis kad latencija po koraku određuje ukupno korisničko iskustvo. Za zadatke gdje je bitnija dosljednost jednog dugog odgovora (sumarizacija, generisanje dokumentacije), dense model iste veličine je predvidiviji, jer se kod MoE routing-a kvalitet može neznatno razlikovati između tokena zavisno koji expert-i su aktivirani.

Napomena o pouzdanosti: mnogi SEO-agregator sajtovi navode konkretne benchmark brojeve (npr. specifične IFEval ili SWE-Bench procente po modelu) koje nije bilo moguće potvrditi na primarnom izvoru (zvaničnom model card-u, GitHub repou ili vendor blogu). Takve brojeve u ovom tekstu izostavljamo – tretirajte ih kao community claim dok god ih ne vidite u primarnom izvoru.

Kvantizacija: GGUF, AWQ, NVFP4

Prva stvar koju vrijedi razdvojiti: GGUF je format fajla, ne algoritam kvantizacije. To je samostalan format, default za llama.cpp/Ollama/LM Studio na CPU-u, konzumerskoj GPU kartici i Apple Silicon uređajima. AWQ i GPTQ su algoritmi čiji izlaz obično završava u safetensors formatu – popularna pokrivenost ova dva sloja često pomiješa, što je vrijedno preciznosti u developerskom tekstu.

  • GGUF, Q4_K_M – standardna polazna tačka za lokalni experiment. Q5_K_M je korak gore u kvalitetu uz veći otisak.
  • AWQ – activation-aware skaliranje, danas generalno bolji od GPTQ na modernim modelima (otprilike 0.5–1.0% bolji perplexity na istom bit-width-u), s bržim kernelima kroz vLLM/TensorRT-LLM. GPTQ se smatra uglavnom superseded za nove release-ove, ali je i dalje čest u starijim checkpoint-ima.
  • NVFP4 – novi 4-bitni floating-point format (E2M1, s FP8-E4M3 fine-grained skaliranjem) koji zahtijeva Blackwell-generaciju NVIDIA hardvera (RTX 50-serija, B200) – H100/A100 i pre-Blackwell konzumerske kartice nemaju FP4 tensor core-ove. Prema vLLM/llm-compressor dokumentaciji i NVIDIA-inim tehničkim materijalima, NVFP4 nosi oko 1.6x veći throughput u odnosu na BF16 uz sličan kvalitet – ovo je vendor/dokumentacijska tvrdnja, ne nezavisno mjerenje treće strane. Pre-kvantizirani checkpoint-i se pojavljuju pod nvidia/ namespace-om na Hugging Face-u.

Praktično pravilo: Q4 nosi otprilike 1–3% degradacije perplexity-ja u odnosu na FP16 – to je sweet spot za lokalnu single-user upotrebu. Za produkciju ili agentic tool-use radne opterećenja gdje se greške akumuliraju kroz korake, ima smisla ići na AWQ 4-bit ili GGUF Q5_K_M za dodatni headroom.

Alati: šta koristiti za šta

  • Ollama – de facto standard za one-developer radni tok. Go daemon koji ispod haube koristi llama.cpp (x86/generic) ili MLX (Apple Silicon, od v0.19, mart 2026). CLI, osnovni web GUI, i OpenAI-compatible API na localhost:11434.
  • llama.cpp – sirovi engine, najviše kontrole (kvantizacija, broj thread-ova, batch size), najniži overhead. Kontinuirani build-tagged release-ovi, preko 900 kontributora i preko 2600 tagovanih verzija.
  • LM Studio – uglađen GUI, pokreće GGUF i MLX jedno pored drugog. Ima lms CLI (lms get/ls/load/server start/chat), a prema zvaničnoj dokumentaciji i samostalan headless daemon za servere i CI okruženja odvojen od GUI-ja.
  • vLLM – za throughput i multi-user serving lokalno – PagedAttention, continuous batching, OpenAI-compatible server. Linux + NVIDIA je zreo put; nema native Windows podršku (potreban WSL2) i nema macOS podršku.
  • TextGen (raniji text-generation-webui, repo preseljen na oobabooga/textgen, stari URL redirect-uje) – i dalje aktivan; verzija 4.x dodala vision, tool-calling, OpenAI- i Anthropic-compatible API-je, native desktop app.
  • Jan.ai – aktivan, sve više okrenut agentnim radnim tokovima (Project workspaces, Browser MCP).

Kako birati: za brzi start i eksperimentisanje – Ollama. Za maksimalnu kontrolu nad kvantizacijom i performansama – llama.cpp direktno. Za GUI bez CLI-ja i paralelno testiranje GGUF/MLX verzija – LM Studio. Za serviranje više konkurentnih korisnika – vLLM. Za multimodalne/tool-calling scenarije s desktop app-om – TextGen.

Slojevi lokalnog LLM stacka: hardver, format kvantizacije, inferencijski engine i API sloj koji ih sve povezuje Slojevi lokalnog LLM stacka od hardvera do API poziva koji zove vaš kod ULAZ GPU VRAM, sistemska RAM, Apple Silicon unified memory šta fizički imate određuje sve slojeve iznad ograničava dostupan format FORMAT GGUF, AWQ, NVFP4 koliko modela stane u dostupnu memoriju ograničava izbor enginea ENGINE Ollama, llama.cpp, LM Studio, vLLM šta format i hardver dozvoljavaju da pokrenete postaje dostupno kao API IZLAZ Jedna OpenAI-compatible tačka koju vaš kod zove localhost:11434/v1 – bez obzira šta je ispod Svaki donji sloj ograničava šta je moguće u sloju iznad njega. Pusti ponovo
Svaki sloj lokalnog LLM stacka ograničava šta je moguće u sloju iznad njega – od hardvera do API poziva.

Korak po korak: od instalacije do prvog API poziva

Primjer s Ollama-om, trenutno najmanje-otporni put od nule do radnog endpoint-a.

1. Instalacija

curl -fsSL https://ollama.com/install.sh | sh

(na macOS: brew install ollama; na Windows: instalacioni fajl s ollama.com)

2. Preuzimanje modela

ollama pull qwen3.6:27b

Ovo povlači GGUF (ili MLX na Apple Silicon) verziju modela – veličina download-a zavisi od kvantizacije koju Ollama defaultno bira.

3. Prva inferencija

ollama run qwen3.6:27b

Otvara interaktivni prompt u terminalu. Isti efekat u GUI alatu: lms chat u LM Studio-u.

4. Izlaganje API-ja

Ollama automatski servira OpenAI-compatible endpoint na http://localhost:11434/v1 (na Linuxu je potreban ručni ollama serve). LM Studio nudi ekvivalent kroz lms server start ili headless daemon mod.

5. Integracija u kod

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = client.chat.completions.create(
    model="qwen3.6:27b",
    messages=[{"role": "user", "content": "Objasni razliku između GGUF i AWQ."}]
)
print(response.choices[0].message.content)

Isti pattern (samo base_url različit) radi identično za Ollama, LM Studio i TextGen – bilo koji kod pisan protiv OpenAI SDK-a se prenosi bez izmjena.

6. Uvoz vlastitog GGUF fajla

Ollama traži da sirovi GGUF fajl umotate u Modelfile (ollama create, obično 10–60 sekundi). LM Studio i TextGen učitavaju GGUF direktno, bez tog koraka.

7. Skaliranje iznad single-user

Kad broj konkurentnih upita poraste, prelazak na vLLM (Docker, Linux + NVIDIA) mijenja profil za multi-user opterećenje – PagedAttention i continuous batching su dizajnirani baš za konkurentne upite, ne za single-user chat. vLLM-ovi vlastiti benchmarci pokazuju značajno veći throughput u odnosu na generičke Transformers pipeline-ove (do 24x); koliko to konkretno znači u odnosu na Ollama-u pod istim opterećenjem nije nezavisno mjereno – tretirajte to kao kvalitativnu, ne brojčanu, razliku dok ne testirate na svom setup-u.

Uobičajeni problemi

Disk se puni brže nego što mislite. Modeli su 4–40+ GB svaki, a Ollama (~/.ollama/models), LM Studio (~/.lmstudio/models) i eventualni Hugging Face cache (~/.cache/huggingface) čuvaju odvojene kopije istog modela u različitim formatima. Na aktivnoj razvojnoj mašini 50–150 GB potrošenog prostora je normalno, ne izuzetak.

Prvi download traje. Vrijeme skaliranja je proporcionalno veličini modela i brzini konekcije – 70B-klasa modela na tipičnom broadband-u može trajati satima.

RAM/VRAM pravilo: veličina fajla na disku je približno jednaka RAM-u/VRAM-u koji je potreban, plus 1–2 GB za KV cache (7B Q4_K_M ≈ 4–5 GB, 13B ≈ 8–9 GB).

Zrelost drajvera/runtime-a se razlikuje. NVIDIA/CUDA put je najzreliji. Apple Silicon kroz Metal/MLX je dobro podržan u Ollama-i i LM Studio-u. AMD zahtijeva ROCm 7.2.x na Linuxu, s primjetno slabijom Windows podrškom. vLLM nema macOS podršku i nema native Windows podršku – WSL2 je obavezan.

Provjera kvalitete: brzi sanity check

Prije nego što lokalni setup uključite u realni pipeline, vrijedi ga testirati na vašem konkretnom zadatku, ne na tuđem benchmark rezultatu. Vendor-ovi benchmark brojevi (SWE-Bench, AIME, RULER i slično) mjere prosjek na tuđem skupu zadataka – ne garantuju ništa o vašem promptu, vašem formatu izlaza ili vašem tool schema-u. Praktičan test: uzmite 15–20 stvarnih primjera iz vašeg trenutnog radnog toka (ne sintetičkih), pustite ih kroz kandidat-model na kvantizaciji koju planirate koristiti u produkciji, i ručno ocijenite izlaz. Ako je tool-calling dio zadatka, provjerite posebno strogo – kvantizacija ispod Q4 (ili agresivan AWQ na malom modelu) često degradira strukturiranu tool-call sintaksu prije nego što degradira obično ćaskanje, jer je tačan JSON format osjetljiviji na sitne greške u predviđanju tokena nego prirodan tekst. Ako kvantizovani model promaši format u 1 od 10 poziva, to je u agentnom loop-u koji radi 20 koraka gotovo garantovan pad negdje na putu.

Zaključak

Lokalno pokretanje LLM-a sredinom 2026. nije nišna vježba – hardver, modeli i alati su dovoljno zreli da za jasno definisane developerske zadatke (kod, RAG, agentni pipeline-ovi s ograničenim tool-setom) budu realna alternativa API-ju, ne samo hobi projekt. Odluka se svodi na trade-off koji je lako artikulisati: unaprijed trošak hardvera i malo više operativnog rada, u zamjenu za privatnost, predvidivost troška i kontrolu nad tačnom verzijom modela koju koristite. Za teže, otvorene rezonovanje zadatke, najveći closed-weight modeli i dalje generalno vode – provjerite tu granicu na svom konkretnom zadatku prije nego što donesete arhitekturnu odluku.

Izvori