Posts

Benchmark lokalnog modela: koliko tokena u sekundi zaista dobijaš

„Sporo je" nije podatak. Bez broja ne znaš da li je model loše izabran, da li se deo slojeva preliva na procesor, ili je sve normalno i očekivanja su bila pogrešna. Ovaj tekst pokazuje šta se meri, čime i kako se rezultat čita. Sve dalje u Fazi 5 — nadzor, kapacitet, trošak — počiva na brojevima odavde. Šta se meri Dve faze rade po različitim pravilima, kako je objašnjeno u tekstu o CPU i GPU inferenciji : Mera Šta govori Ograničena čime Prefill (pp) Brzina čitanja prompta Računom Decode (tg) Brzina generisanja odgovora Propusnošću memorije TTFT Čekanje na prvi znak Dužinom prompta Propusnost Ukupno tokena u sekundi, svi korisnici Postavkom servisa Jedan broj ne opisuje postavku. Model može da generiše šezdeset tokena u sekundi, a da korisnik čeka pola minuta na prvi znak jer je prompt dugačak. Za razgovor je bitan TTFT plus decode; za paketnu obradu jedino ukupna p...

RAG nad sopstvenom dokumentacijom

„Hoću da model zna našu dokumentaciju" je najčešći zahtev koji ćeš dobiti. Odgovor gotovo nikad nije fine-tuning — nego RAG, postupak koji relevantne delove tvojih fajlova pronađe i ubaci u prompt pre nego što model odgovori. Open WebUI to već ume, kako je pokazano u tekstu o njemu . Ovaj tekst objašnjava šta se ispod dešava i kako se gradi sopstveno rešenje, jer ćeš ga pre ili kasnije trebati. Postupak Priprema (jednom): dokumenti → sečenje na delove → embeddings → vektorska baza Pri svakom pitanju: pitanje → embedding → pretraga po sličnosti → n najbližih delova → prompt: "Odgovori na osnovu ovog konteksta: ..." → model Model se ne menja. Težine ostaju iste; menja se samo ono što mu stiže u promptu. To je razlog zašto RAG radi na svakom modelu i zašto se dokument dodat jutros koristi već u podne. Embedding Numerički zapis značenja teksta. Dva teksta sličnog značenja imaju bliske zapise, i to bez ijedne zajedničke reči: "restart nginx ...

journalctl i LLM: objašnjenje sistemskih grešaka jednom komandom

Prethodni tekstovi su postavili sve delove. Ovim se sklapaju u jednu komandu koju ćeš zaista kucati — onu koja na pad servisa u dva ujutru odgovori nečim korisnijim od trideset redova stack trace-a. Alatka se zove zasto i do kraja teksta stoji u /usr/local/bin . Zašto baš journal Sistemski log je idealan ulaz za model iz tri razloga. Struktura je poznata. Svaki zapis ima jedinicu, prioritet, vreme i poruku. Model ne pogađa šta gleda. Filtriranje već postoji. journalctl ume da suzi po servisu, prioritetu i vremenu pre nego što išta ode modelu — što je, kako pokazuje prethodni tekst , najvažniji korak. Izlaz u JSON obliku. Nema parsiranja teksta: $ journalctl -u nginx -n 3 -o json --no-pager | jq -r '.MESSAGE' Podsetnik na osnovne oznake stoji u tekstu o journalctl . Najkraća upotrebljiva verzija $ journalctl -u nginx -n 50 --no-pager \ | jq -Rs '{ model: "qwen3:8b", messages: [ {role: "system", content: ...

AI u bash skriptama — automatska analiza logova

Python klijent iz prethodnog teksta je pravi alat kad obrada ima strukturu. Ali najveći deo posla na serveru već živi u bashu — cron zadaci, skripte za nadzor, jednolinijski lanci koji rade godinama. Za njih model treba da bude još jedna karika u pipe-u, kao grep ili awk . Ovaj tekst pokazuje kako se to radi tako da ne pukne prvog dana. Problem koji rešavaš pre svega ostalog Ovo izgleda kao da radi: $ TEKST=$(tail -20 /var/log/nginx/error.log) $ curl -s http://localhost:11434/v1/chat/completions \ -d "{\"model\":\"qwen3:8b\",\"messages\":[{\"role\":\"user\",\"content\":\"$TEKST\"}]}" I puca čim log sadrži navodnik, obrnutu kosu crtu ili prelom reda — dakle odmah. JSON postane neispravan, servis vrati 400, a poruka o grešci ne govori ništa korisno. Rešenje je da JSON nikad ne sastavljaš ručno. Za to postoji jq : $ tail -20 /var/log/nginx/error.log \ | jq -Rs '{ model: "q...

Python skripta koja komunicira sa lokalnim modelom

Dosad si sa modelom pričao kroz curl . To je dobro za razumevanje i za jednokratne provere, ali čim treba obraditi listu fajlova, ponoviti neuspeo zahtev ili proslediti izlaz dalje, bash postaje tesan. Ovaj tekst gradi Python klijent — od najmanjeg primera do alatke koju stvarno možeš staviti u /usr/local/bin . Priprema Zvanična openai biblioteka radi sa svakim OpenAI-kompatibilnim servisom, pa i sa tvojim: $ python3 -m venv ~/.venv/ai $ source ~/.venv/ai/bin/activate $ pip install openai Sistemski Python nemoj dirati; na novijim distribucijama pip to ionako odbija. Podešavanja idu u okruženje, ne u kod: $ cat ~/.ai_env export AI_BASE_URL=http://localhost:11434/v1 export AI_API_KEY=k_alen_3f8a2b91c7d45e6f export AI_MODEL=qwen3:8b $ chmod 600 ~/.ai_env $ source ~/.ai_env Ovim ista skripta radi i sa lokalnom Ollamom i sa vLLM-om iza proxy-ja , bez ijedne izmene. Najmanji klijent #!/usr/bin/env python3 import os from openai import OpenAI klijent = OpenAI( base...

Zaštita API-ja: ključevi, firewall i ograničavanje pristupa

Otvoren port sa modelom nije isto što i otvoren port sa veb sajtom. Ovde neko ko dođe do adrese ne gleda tvoje stranice — koristi tvoju karticu, tvoju struju i, ako je model povezan sa alatima ili dokumentima, tvoje podatke. Proxy iz prethodnog teksta je rešio prenos. Ovim tekstom se rešava pitanje ko sme da prođe. Šta zapravo štitiš Karticu. Jedan skript u petlji zauzme resurs koji si kupio. Podatke. Sistemski prompt, priloženi dokumenti i istorija razgovora sadrže više nego što misliš. Radnje. Ako model ima alate, pristup API-ju je pristup tim alatima. Odgovornost. Servis koji generiše šta god ko zatraži, sa tvoje adrese, tvoj je problem. Ollama nema nikakvu autentifikaciju i neće je dobiti — po zamisli je alat za lokalnu upotrebu. llama.cpp i vLLM imaju jedan zajednički ključ, što je bolje od ničega i lošije od onoga što ti treba. Zaključak je jednostavan: zaštita se ne dešava u servisu, nego iznad njega. Slojevi 1. Servis sluša samo na 127.0.0.1 2. F...

Nginx reverse proxy i HTTPS ispred lokalnog LLM-a

Do sada je sve slušalo na 127.0.0.1 i to je bila ispravna odluka. Kad servis treba da bude dostupan spolja, između njega i mreže ide proxy koji radi ono što ni Ollama ni vLLM ne umeju: TLS, kontrolu pristupa i ograničavanje broja zahteva. Ovaj tekst pokriva prvi deo — postavljanje proxy-ja i sertifikata. Autentifikacija i ključevi su tema sledećeg teksta ; ova dva idu zajedno i nijedan sam nije dovoljan. Šta proxy rešava Bez proxy-ja Sa proxy-jem HTTP, sve u čitljivom obliku TLS sa važećim sertifikatom Nema kontrole pristupa Ključevi, IP liste, lozinke Nema ograničenja broja zahteva Rate limiting Nema zapisa ko je šta tražio Pristupni log Svaki servis na svom portu Više servisa na jednom imenu Postavka izgleda ovako: Internet → Nginx :443 (TLS) → Ollama :11434 (lokalno) → Open WebUI :3000 (lokalno) → vLLM :8000 (...