Stop čekanju: Kako se radi deployment modela bez bugova
Zaboravi na obećanja o ‘jednostavnom deploymentu’ jednim klikom. To je marketinška šuplja priča koja rezultira serverom koji se ruši u tri ujutro dok ti pokušavaš objasniti klijentu zašto mu je biznis stao. Ako misliš da je ‘it works on my machine’ dovoljno za produkciju, tvoj kod je tempirana bomba. U stvarnom svijetu, deployment je kao varenje pod vodom — jedan loš spoj i sve ide u propast. Ti trebaš sistem, a ne sreću.
Mrtvi pikseli koda: Zašto tvoj model puca u produkciji
Najveća greška koju ćeš napraviti je ignorisanje okruženja. Tvoj lokalni GPU nije isto što i Azure instanca. Osjetit ćeš onaj specifičan miris panike kad logovi počnu izbacivati ‘CUDA out of memory’ greške. To se dešava jer nisi predvidio kako se activation functions ponašaju pod velikim opterećenjem. Kod mora biti armiran. Svaki bajt koji uđe u RAM mora imati svoju svrhu, inače ćeš dobiti sistem koji je trom i neupotrebljiv. Ne dopusti da ti model ‘krvari’ memoriju. To nije samo tehnički problem; to je finansijski gubitak koji ćeš osjetiti na kraju mjeseca. Kao što kaže stari Mike iz server sale: ‘Nema tog koda koji loš hardware može sakriti, ali ima lošeg deploymenta koji će spržiti i najbolji server’.
WARNING: Nikada ne ostavljaj API ključeve i lozinke u .env fajlovima koji se commituju na GitHub. To je kao da ostaviš ključeve od kuće u bravi dok ideš na godišnji. Jedan bot-skener i tvoji podaci (i novac na Azure-u) će nestati za manje od 60 sekundi.
Docker kontejneri: Zašto ti treba ‘izolovana ćelija’ za kod
Ako ne koristiš Docker, ti se ne baviš deploymentom, ti se kockaš. Kontejnerizacija nije samo trend; to je jedini način da osiguraš da tvoj model radi isto u Sarajevu i u data centru u Frankfurtu. Zamisli Docker kao brodski kontejner — nije ga briga šta je unutra, bitno je da su dimenzije fiksne. Ja sam jednom proveo 14 sati pokušavajući shvatiti zašto Python biblioteka ne radi, samo da bih saznao da je verzija operativnog sistema na serveru bila za 0.1 starija. Nikad više. Slather (namaži) te Dockerfile instrukcije sloj po sloj. Svaki sloj je štit. Ako želiš naučiti više o stabilnosti, pogledaj kako AI prati stabilnost servera u realnom vremenu.

Anatomija propasti: Šta se desi kad preskočiš testiranje
Hajde da pričamo o fizici žaljenja. Kada pustiš model bez ‘stress testa’, ti zapravo testiraš strpljenje svojih korisnika. Model može raditi savršeno za jedan upit, ali šta kad ih dođe 10.000 u sekundi? Voda se širi kad se smrzne, a tvoj delay (kašnjenje) se širi kad se server preoptereti. To je čista matematika. Ako tvoj API odgovor traje duže od 200ms, izgubio si 20% korisnika. Ako traje duže od sekunde, tvoj model je mrtav. Ja sam naučio lekciju kad mi je jedan mali skript za analizu prodaje srušio bazu jer nisam podesio timeout. Baza se ‘zaključala’ i niko nije mogao ništa kupiti tri sata. Šteta? Više od 5000 KM. To je ‘Financial Sting’ koji ne želiš osjetiti. Uvijek koristi automatizaciju logova da vidiš anomalije prije nego postanu katastrofe.
Da li automatizacija stvarno smanjuje bugove?
Da, ali samo ako je pravilno postavljena. Automatizacija nije čarobni štapić; to je mašina koja ponavlja tvoje korake. Ako su ti koraci pogrešni, automatizacija će samo brže praviti greške. Cilj je da svaki ‘push’ na server prođe kroz rigorozan proces validacije gdje ljudski nadzor služi kao zadnja linija odbrane. Za detalje o tome, pročitaj o tome kako dodati ljudski nadzor u AI procese.
Zašto ti treba ‘Staging’ okruženje (i zašto ga nemaš)
Mnogi mali biznisi štede na staging serveru. To je idiotizam. Staging je tvoja laboratorija gdje možeš detonirati bombu bez da iko povrijedi. Ako tvoj deployment proces ide direktno sa laptopa na ‘live’ sajt, ti si jedan pogrešan ‘Enter’ udaljen od nezaposlenosti. Prema podacima iz 2026. godine, 85% svih padova sistema u IT sektoru uzrokovano je lošom konfiguracijom, a ne lošim kodom. To je poražavajuće. Sredi to tako što ćeš hostovati model na Azure-u na jeftin način za početak, kao što je opisano u ovom vodiču za hostovanje AI modela na Azure-u.
Kako prepoznati loš model prije deploymenta?
Gledaj metriku. Ako tvoj model ima ‘accuracy’ od 99.9% na trening setu, a 60% na testnom, imaš problem koji se zove overfitting. To je kao da učiš odgovore napamet umjesto da razumiješ gradivo. U produkciji će takav model halucinirati gore nego neko na lošim gljivama. Sreži to odmah. Isključi ga. Nemoj ga deploy-ovati dok ne dobiješ stabilne rezultate na podacima koje model nikad nije vidio. Halucinacije su rak AI sistema.
Alat godine: Zašto je tvoj drill (bušilica) zapravo Git
U workshopu, Git je tvoj najvažniji alat. Ne samo za čuvanje koda, već za ‘roll-back’. Ako nešto krene po zlu — a krenut će — moraš biti u stanju da vratiš sve na prethodno stabilno stanje u roku od 30 sekundi. Ako ti treba duže od toga, tvoj sistem je loše dizajniran. Git commit poruke ne smiju biti ‘fix’, ‘update’, ‘opet ja’. One moraju biti forenzički dokazi: ‘Smanjen memorijski leak u NLP modulu’. To spašava živote kad si umoran i pokušavaš shvatiti šta si radio prije tri dana. Za one koji tek ulaze u ovaj svijet, preporučujem da pogledaju plan učenja za IT karijeru jer osnove Git-a su tamo nezaobilazne.
Zaključak koji nije kraj: Održi sistem budnim
Deployment nije kraj puta; to je tek početak. Model u produkciji je živa stvar. On ‘stari’, podaci se mijenjaju, korisnici se ponašaju nepredviđeno. Moraš imati senzore. Moraš čuti ‘škripu’ u bazi podataka prije nego što sve pukne. Budi onaj tip koji provjerava logove uz jutarnju kafu, ne zato što moraš, već zato što znaš da je to jedini način da mirno spavaš. DIY pristup u deploymentu znači da razumiješ svaki šaraf u svom sistemu. Nemoj biti samo programer, budi inženjer koji zna zašto mu se mašina grije. I zapamti, u 2026. godini, brzina je bitna, ali je stabilnost valuta kojom se plaća povjerenje. Nemoj je prokockati zbog lijenosti.

![Pokreni AI na svom kompjuteru bez interneta [Korak po korak]](https://aiskola.org/wp-content/uploads/2026/02/Pokreni-AI-na-svom-kompjuteru-bez-interneta-Korak-po-korak.jpeg)

Ova analiza deploymenta i izazova sa sistemom je zaista duboka i na pravom je mjestu! Često sam i sam imao sličnih problema sa postavljanjem modela u produkciju, posebno u pogledu testiranja i stres testova koji su često preskočeni. Spomenuo si važnost Docker kontejnenerizacije, što smatram neophodnim za efikasno upravljanje verzijama i kompatibilnošću među okruženjima, ali isto tako zna biti izazovno za početnike. Ono što mi je posebno ostalo u glavi je priča o monitoringu i važnosti senzora – prepoznajem koliko je to ključ za pravovremeno djelovanje i održavanje stabilnosti. Možda bi bilo korisno podijeliti neke konkretne alate ili primjere automatske detekcije problema iz prakse. Kakve su vaše iskustvo ili preporuke za jednostavni početak s tim?