Svaka firma koja je poslednje tri godine puštala AI u produkciju krenula je na isti način: API ključ, račun koji se plaća po utrošku i model koji vrti neko drugi. Tako je i trebalo da počne, jer cloud AI API-ji sabijaju mesece infrastrukturnog posla u jedno popodne, a nijedan razuman tim ne gradi serving stack pre nego što dokaže da proizvod uopšte radi. Ali „ispravan prvi izbor“ i „ispravan trajan izbor“ nisu ista tvrdnja: za jednu klasu workloada račun, granica podataka i zavisnost od tuđeg rasporeda vremenom počnu da govore u prilog infrastrukturi koju posedujete. Pravo pitanje nije da li seliti, nego koje workloade, kada i kako, a da pritom ne stavite celu firmu na jedan rek servera.
Tri pritiska
Prvi pritisak je oblik troška, a ne njegova visina. Naplata po utrošku znači da račun ide u pravoj liniji kroz upotrebu: svaki novi klijent, svaka funkcionalnost koja zove model i svaki pozadinski posao koji automatizujete pomeraju vas duž te linije. Uspeh tu ne pomaže nego odmaže, jer račun raste upravo zato što proizvod radi. Apsolutni iznos je manje važan od oblika: firma koja u ceni svake transakcije nosi naknadu plaćenu trećoj strani trajno je izdvojila deo marže, i to po ceni koju ne određuje ona. Sopstvena inferencija obrće taj oblik, jer hardver plaćate jednom, a operativni trošak posle toga ostaje uporedivo ravan, pa je iznad određene iskorišćenosti svaki naredni poziv skoro besplatan. Gde tačno stoji ta tačka preseka, pokazaće vaš saobraćaj, a ne broj iz tuđeg blog posta.
Drugi pritisak je granica podataka. Svaki prompt je izvoz: podaci o klijentima, ugovorne odredbe, medicinske beleške, kod, sve što workload dodirne napušta vašu infrastrukturu i prolazi kroz obrađivača kojeg proveravate papirologijom, a ne pristupom. Ugovori, odredbe o čuvanju podataka i regionalni hosting to ublažavaju, a za mnoge poslove ublažavaju i dovoljno. Ali ima podataka koji peku u rukama: regulisani, privilegovani, konkurentski poverljivi. Za njih je najčistija priča o usklađenosti ujedno i najkraća, a glasi da podaci nikada ne izlaze napolje. Taj argument jača svaki put kada neki workload uđe dublje u srž kompanije.
Treći pritisak je najtiši i zove se tuđe odluke. API koji se naplaćuje po utrošku je zavisnost čiji plan razvoja ne kontrolišete. Modeli se gase po rasporedu provajdera, a zamena, koliko god bila sposobna, drugačije se ponaša prema promptovima i evaluacionim setovima koje ste štimovali za prethodnika. Ograničenja broja poziva, kapacitet i cene menjaju se objavom. Ništa od toga nije zlonamerno, tako naprosto izgleda život nizvodno od tuđe odluke. Sistem koji je tiho postao ključna infrastruktura zaslužuje istu proveru kao i svaki drugi pojedinačni dobavljač koji sedi na kritičnoj putanji.
Račun raste upravo zato što proizvod radi. Na ovaj razgovor tera oblik troška, a ne njegova visina.
Iskren protivargument
Sopstvena infrastruktura je češće pogrešan nego ispravan potez i te izuzetke vredi izgovoriti naglas. Ako vam je obim skroman, naplata po utrošku ispada jeftinija od plate čoveka kojeg biste morali da zaposlite da to vodi, pa argument o tački preseka seče na obe strane. Ako poslu zaista treba sposobnost frontier modela, open-weight alternative je možda još ne dostižu, a razliku u kvalitetu nijedna kupovina hardvera ne popravlja. I ako u timu nema nikoga ko može da preuzme GPU-ove, drajvere, serving softver i planiranje kapaciteta kao prvorazrednu operativnu odgovornost, kupovinom hardvera ste fakturu zamenili generatorom ispada. Potez ima smisla tamo gde se seku tri uslova: održiv obim, poslovi koje open-weight modeli rešavaju u kvalitetu koji vam treba i neko ko ume da vodi ono što ste kupili, bilo iz kuće bilo od partnera.
Šta posedovanje zaista podrazumeva
Posao je konkretan i uglavnom bez sjaja. Dimenzionisanje ide prvo: hardver za inferenciju bira se prema stvarnom saobraćaju, odnosno prema veličini modela, dužini konteksta, ciljanoj latenciji i vršnoj konkurentnosti, a ne prema specifikaciji sa papira. Izbor modela je vežba iz evaluacije, a ne čitanje rang-liste: kandidate među open-weight modelima puštate kroz evaluacioni set napravljen od vašeg stvarnog posla, jer jedini benchmark koji nešto znači jeste onaj vaš. Serving stack, dakle inference server, batching, kvantizacija i failover, danas je zreo open-source alat, ali je istovremeno i sistem koji neko mora da vodi, sa monitoringom, alertima i disciplinom nadogradnje kakvu traži svaki produkcijski sistem. A telemetrija kvaliteta ulazi među uobičajene dashboarde: sopstveni modeli se ne popravljaju tiho pod vama, ali ni ne nazaduju tiho, pa tempo držite vi, a sa tempom i obavezu da promenu primetite.
Jedna disciplina drži celu stvar na okupu, a to je cloud osnovica. Pre nego što se ijedan workload pomeri, izmeri se kako se ponaša danas: kvalitet na evaluacionom setu, latencija i trošak po jedinici posla. Sopstveni stack zaslužuje taj workload tek kada tu osnovicu dostigne ili nadmaši, dokazivo i pre prelaska. Bez tog merenja migracija je skok u prazno posle kojeg sledi svađa. Sa njim je migracija rezultat benchmarka posle kojeg sledi odluka.
Selite kao što puštate u produkciju: jedan po jedan workload
Obrazac koji radi isti je kao kod svake rizične zamene: postepeno, uz mogućnost povratka i uz merenje. Workloadi se sele jedan po jedan, počev od najmanje rizičnog: interni alati i batch obrada idu pre bilo čega što klijent vidi. Svaki od njih prvo vrti shadow saobraćaj na sopstvenom stacku dok je API i dalje merodavan, a prelazi se tek kada benchmark izdrži pod stvarnim opterećenjem; API ostaje kao rezerva sve dok se poverenje ne zaradi umesto da se pretpostavi. To je strangler obrazac primenjen na inferenciju i znači da firma nikada nije jedan loš dan udaljena od saznanja da je sve stavila na nov hardver. Tako izgleda i angažman koji upravo vodimo: hardver za inferenciju po meri, specificiran prema izmerenim workloadima, migracija koja ide workload po workload i svaki prelazak uslovljen svojom cloud osnovicom.
Jedan sporedni efekat ovakvog rada zaslužuje da bude pomenut: evaluacioni setovi, osnovice i rutiranje koje gradite zbog migracije trajno menjaju način na koji vodite AI. Projekat završavate znajući šta koji workload traži, koliko košta na bilo kojoj podlozi i kako da ga ponovo preselite, pa su sledeća promena cene kod provajdera ili gašenje modela vežba u tabeli, a ne vatrogasna akcija. Jednom izgrađena opcionalnost nastavlja da se isplaćuje.
Krajnje stanje je obično hibridno
Ovo vredi reći izričito, jer se rasprava obično postavlja kao izbor između dve krajnosti: skoro niko ne završi potpuno van clouda i to nije neuspeh migracije. Stabilno krajnje stanje za većinu firmi jeste odluka o rutiranju, doneta za svaki workload posebno. Poslovi velikog obima, dobro shvaćeni i osetljivi po pitanju podataka, rade na sopstvenoj infrastrukturi, gde ravan oblik troška i kratka priča o usklađenosti rade svoje. Eksperimentalne funkcionalnosti, poslovi sa naglim skokovima i sve čemu zaista treba frontier model ostaju na naplati po utrošku, gde elastičnost i sposobnost vrede cene po pozivu. Infrastruktura koju posedujete postaje osnova, a API postaje ono što je oduvek trebalo da bude: skuplja opcija za kojom posežete namerno, a ne podrazumevana vrednost u koju ste odlutali. Sloj za rutiranje koji to omogućava je tanak, ali potpuno menja pregovaračku poziciju, jer svaki workload ima gde da ode i svaki dobavljač to zna.
Odluka u nekoliko rečenica
Ostanite na naplati po utrošku dok je obim mali, dok vam trebaju sposobnosti koje daju samo frontier modeli ili dok niko ne može da preuzme operativu. Počnite da merite onog trenutka kada račun postane stavka o kojoj rukovodstvo pita: napravite evaluacioni set, uhvatite osnovice i izračunajte tačku preseka svojim brojevima. Selite tek kada workload prođe sva tri testa (održiv obim, dostižan kvalitet na open-weight modelima i imenovan vlasnik infrastrukture), i selite ga na dosadan način, jedan benchmarkom uslovljen prelazak za drugim. Firme koje ovo rade kako treba ne tretiraju sopstvenu AI infrastrukturu kao izjavu o sebi, nego kao svaku drugu odluku da li graditi ili iznajmiti: sa osnovicom, benchmarkom i putem nazad.