Shopifyjev CEO Tobi Lütke 1. rujna 2026. objavio je rezultat koji veliku inženjersku ideju svodi na jednu rečenicu: fine-tunani model s 0,8 milijardi parametara pobijedio je GPT-5.6-sol uz xhigh reasoning effort na jednom specijaliziranom zadatku.

Priloženi Buyer Profile slajd preciznije određuje granicu. Shopify navodi interni judge score 84,6 za Qwen3.5-0.8B, u usporedbi s 83,0 za frontier teacher i 77,2 za raniji produkcijski Qwen3.5-2B. Rezultat je rastao kroz tri iteracije podataka: 29.000, 42.000 i 54.000 uzoraka. Slajd navodi i kompresiju system prompta s 9.100 na 1.100 tokena te rast throughputa s dva na 72 milijuna profila dnevno na 100 H100 GPU-ova.

Brojevi su impresivni. Ujedno su first-party rezultati za jedan interni zadatak. Shopify nije objavio Buyer Profile dataset, judge prompt, test split, intervale pouzdanosti, checkpoint ni potpun training recipe. Usporedbu trenutačno nitko izvan tvrtke ne može reproducirati.

Vrijedan zaključak uži je od naslova: kada zadatak ima stabilnu granicu, dovoljno primjera i pouzdanu eval petlju, mali model može postati bolji u tom izmjerenom zadatku od mnogo većeg općeg modela. Odriče se širine kako bi dobio gustoću.

Taj trade ima smisla za proizvode poput PLAYGRND-a. Nije razlog za fine-tuning prije nego što definiramo posao.

Veličina modela i način treniranja različite su odluke

Nekoliko pojmova često se stopi u “treniranje vlastitog modela”. Oni opisuju različite operacije.

Fine-tuning nastavlja treniranje postojećeg base modela na podacima konkretnog zadatka. Mijenja njegovo ponašanje promjenom weightova.

Supervised fine-tuning (SFT) modelu pokazuje zahtjev i poželjni odgovor ili tool trajectory. Model uči oponašati te primjere. To je obično prvi koristan korak za strukturirani zadatak.

Distilacija prenosi ponašanje jačeg teachera u manjeg studenta. Kod sequence-level distilacije teacher generira ili ispravlja training primjere, a student ih uči kroz SFT. Logit distilacija je izravnija, ali traži pristup teacherovoj distribuciji izlaza, što zatvoreni API najčešće ne daje.

LoRA mijenja relativno mali skup adapter parametara umjesto cijelog modela. Eksperimenti su jeftiniji i lakše ih je vratiti. Full-parameter fine-tuning ažurira sve weightove i može naučiti više, ali treba više memorije, computea i bolju zaštitu od zaboravljanja.

Preference ili reinforcement optimizacija, uključujući GRPO, dolazi kasnije. Model generira više kandidata, reward funkcija ih ocjenjuje, a training favorizira bolje. Ako je reward slab, model nauči iskoristiti judge umjesto poboljšati proizvod.

Veličina modela samo je spremnik za te odluke. Stvarni sustav čine podaci, ugovor, evaluacija, training, serving i feedback.

Kako radi Shopifyjev flywheel

Shopify je objavio više detalja o metodi u Sidekick continual-learning izvještaju. Redoslijed je važniji od jednog benchmarka:

  1. Definirati kvalitetu kroz rubric koji odvojeno mjeri izvršenje zadatka, execution, kvalitetu odgovora i sigurnost.
  2. Dati domenskim stručnjacima nasumične produkcijske uzorke i izmjeriti slažu li se međusobno.
  3. Kalibrirati uske automatske judgeove prema toj ljudskoj ground truth oznaci.
  4. Poboljšati postojeće promptove, tool definicije i harness prije promjene weightova.
  5. Pronaći de-identificirane produkcijske greške i druge hard negative primjere.
  6. Dati panelu jačih modela da kritizira grešku, spojiti kritike u popravak i ponovno pokrenuti trajectory.
  7. Zadržati popravljene trajectoryje koji prođu judge; neriješene poslati ljudima.
  8. SFT-om destilirati prihvaćene trajectoryje u manji model.
  9. Po potrebi primijeniti GRPO s kalibriranim judgeom kao rewardom.
  10. Ponovno trenirati na starim i novim primjerima kako model ne bi zaboravio ranije ponašanje.

Shopify koristi i naučene gist tokene za kompresiju dugih, stabilnih prompt instrukcija. To je prompt compression, a ne drugi naziv za smanjivanje modela. Model uči kratak niz embeddinga koji reproducira učinak mnogo duljeg fiksnog prefiksa.

“Rekurzivno” ovdje opisuje projektirani pipeline, a ne model koji potajno prepisuje sam sebe u produkciji: prikupi, ocijeni, popravi, pregledaj, treniraj, evaluiraj, isporuči. Svaki ciklus kreće s boljim datasetom i, ako prođe release gate, boljim studentom.

Upozorenje skriveno u drugoj Shopifyjevoj studiji

Shopifyjev zaseban izvještaj o Flow agentu vrjedniji je od čiste success story jer uključuje neuspješan produkcijski signal.

Tim je fine-tunao Qwen3-32B da zahtjeve prirodnim jezikom pretvara u Shopify Flow automatizacije. Model je izgledao konkurentno na offline benchmarku s 300 primjera. Međutim, na rollout od jedan posto produkcijskog prometa stopa kojom su trgovci aktivirali generirane workflowe bila je 35% niža nego kod prethodnog agenta.

Stvarni zahtjevi uključivali su rad koji sintetički benchmark nije pokrio. Važne su bile i male razlike između traininga i produkcije: nazivi i redoslijed toolova, redoslijed JSON ključeva, polja odgovora i revizije system prompta mijenjali su kvalitetu.

Shopify je produkcijskim primjerima, human-calibrated judgeom i tjednim retrainingom zatvorio prijavljeni gap. Korisno je upozorenje da offline judge može odobriti model koji korisnici odbiju; njihov oporavak ne znači da svaki flywheel pobijedi u dva tjedna.

To nas sprječava i u miješanju dvije različite Shopifyjeve priče. Buyer Profile koristi 0,8B rezultat iz Tobijeva slajda. Flow je koristio 32B model, drugi dataset, metriku, workload i training sustav. Jedna priča ne validira drugu.

PLAYGRND zadatak dovoljno uzak za test

PLAYGRND ima mnogo mogućih AI površina. Većina je preširoka za prvi specijalizirani model. Tvrdnja da assistant “zna nogomet” ostavlja product ugovor neriješenim.

Jedan kandidat dovoljno je uzak: bilingvalni read-only router za statističke toolove.

Korisnik bi mogao pitati na hrvatskom ili engleskom:

  • “Tko je zabio najviše za ovu ekipu prošle sezone?”
  • “Koja je momčad primila najmanje golova u ovoj ligi?”
  • “Show the last five meetings between these teams.”
  • “Je li ovo pitanje o igraču ili ekipi? Treba mi pojašnjenje.”

Model ne bi pisao SQL niti mijenjao službenu evidenciju. Izlaz bi bio jedan odobreni read-only tool call s tipiziranim argumentima ili izričit zahtjev za pojašnjenjem, odbijanje ili fallback. Postojeći backend rješavao bi identitete, provjeravao shemu i izvršavao query nad glavnim podacima.

Ovo je prijedlog eksperimenta, a ne funkcionalnost za koju tvrdimo da je danas live.

Kandidat je dobar iz četiri razloga:

  • dostupni toolovi i argumenti mogu se pobrojati;
  • rezultat se može izvršiti i deterministički provjeriti;
  • hrvatske formulacije, padeži i lokalni nogometni rječnik daju stvarnu vrijednost specijalizaciji;
  • greška se može vratiti na veći model ili običnu pretragu bez promjene evidencije.

Administrativni upisi ostali bi izvan prvog modela. Ako kasniji sustav predloži ispravak rezultata ili promjenu natjecanja, provjere dozvola, izvorni dokaz i ljudska potvrda i dalje bi se izvršavali u determinističkom aplikacijskom kodu.

Plan implementacije

Ovo bismo gradili u fazama. Prva release odluka dolazi prije prvog training runa.

1. Zamrznuti ugovor zadatka

Definirati mali verzionirani tool vocabulary i jedan strukturirani izlaz. Zahtjev mora proizvesti naziv toola, tipizirane argumente, jezik, kategoriju sigurnosti i jednu od odluka execute, clarify, refuse ili fallback.

Output schema mora odbiti nepoznati tool, neispravan identifikator i nepodržan raspon datuma. Tool odgovori trebaju biti namjerno mali i stabilni. Ako se serving tool zove player_season_summary, isti naziv i oblik odgovora moraju postojati u svakom training trajectoryju.

2. Prvo napraviti eval set

Prije generiranja training podataka treba napraviti held-out skup koji predstavlja tešku product granicu:

  • hrvatske i engleske verzije iste namjere;
  • padeže, dijalekt, tipfelere i skraćena imena klubova;
  • igrače i ekipe sa sličnim imenima;
  • nedostajući kontekst sezone ili natjecanja;
  • pitanja koja traže dva toola umjesto jednog;
  • nepodržane prognoze i činjenice koje sustav ne može znati;
  • zahtjeve za privatne ili nedopuštene podatke;
  • prompt injection i neispravne tool-output slučajeve.

Primjere treba odvojiti po natjecanju, vremenu i obrascu entiteta, a ne slučajno dijeliti gotovo jednake rečenice. Inače test mjeri memoriranje iste utakmice napisane drugim riječima.

Rezultat treba ostati razložen: valjana shema, točan tool, točni argumenti, uspješno izvršenje, odgovor vezan uz vraćenu evidenciju, ispravno pojašnjenje ili odbijanje, paritet hrvatskog i engleskog, latencija i trošak. Jedan spojeni judge score koristan je za rangiranje, ali ne i za dijagnozu.

3. Postaviti tri baselinea

Zamrznuti eval treba pokrenuti nad:

  1. nepromijenjenim malim base modelom;
  2. trenutačnim frontier modelom i punim harnessom;
  3. determinističkim keyword ili rules baselineom.

Treći baseline je važan. Ako jednostavan router rješava 95% zadatka, training modela možda dodaje samo operativni rizik.

Qwen3.5-0.8B očit je kandidat jer se pojavljuje u Tobijevu primjeru, a objavljeni weightovi koriste Apache 2.0 licencu. Ipak bismo hrvatsku kvalitetu postavili kao mjerljivi go/no-go uvjet umjesto da je pretpostavimo iz engleskog rezultata. Model od 1,7B ili 4B može biti bolja točka između kvalitete i troška.

4. Izgraditi sljedive training podatke

Početi s product-owned primjerima i javnim ili odgovarajuće licenciranim tekstom. Ako se koriste produkcijske interakcije, treba dokumentirati svrhu i pravnu osnovu, minimizirati i de-identificirati podatke, isključiti osjetljiv slobodni tekst i postaviti rokove čuvanja.

Jači teacher može generirati više kandidata za tool trajectory prema točnoj produkcijskoj shemi. Svaki kandidat izvršava se nad izoliranim read-only snapshotom baze. Determinističke provjere odbijaju pogrešne toolove, argumente i neutemeljene odgovore. Domenski revieweri pregledavaju nejasne i rizične sliceove.

Svaki prihvaćeni primjer treba čuvati provenance: kategoriju izvora, verziju teachera i prompta, verziju tool sheme, rezultat determinističke provjere, status ljudskog reviewa i dataset split. Flywheel bez lineagea automatizirani je način da izgubimo objašnjenje ponašanja modela.

Korištenje teachera ima i ugovornu granicu. Prije korištenja outputa za trening drugog modela tim mora provjeriti aktualne uvjete providera, licence base modela i dataseta, privacy obveze i prava trećih strana. Skriveni chain-of-thought modela ne treba tretirati kao training materijal. Sažet product-owned action trace i pregledano objašnjenje lakše je kontrolirati.

5. Prvo pokrenuti LoRA SFT

Prvi eksperiment treba fine-tunati adaptere na prihvaćenim primjerima, uz maskiranje korisničkih i tool-result tokena koje model ne treba generirati. Svaki run mora sadržavati replay uzorak običnih i refusal primjera.

U početku bismo mijenjali samo mali skup parametara: veličinu modela, LoRA rank, learning rate, broj epoha i pomaže li sažet reasoning/action trace. Svaki run koristi isti zamrznuti split. Pobjednički checkpoint je najmanji model koji prolazi sve hard gateove, a ne onaj s najvećim prosjekom.

Tobijev javni QMD fine-tuning primjer pokazuje koliko ta faza može biti skromna. Qwen3-1.7B LoRA treniran je na otprilike 2.290 query-expansion primjera oko 45 minuta na jednom A10G-u, za približno 1,50 dolara. To je koristan pokazatelj reda veličine, a ne predviđanje trajanja ili kvalitete za PLAYGRND.

6. Destilirati greške, zatim razmotriti RL

Kada SFT model radi u shadow modu, treba prikupljati greške koje determinističke provjere ili revieweri mogu objasniti. Jači teacher može ispraviti te trajectoryje; potvrđeni popravci vraćaju se u sljedeći SFT dataset.

GRPO postaje zanimljiv tek kada je veći dio rewarda izvršiv: točan tool, valjani argumenti, uspješan query, utemeljen odgovor i ispravno suzdržavanje. Ako cijeli reward daje LLM judge, reward hacking i judge drift teže se otkrivaju.

Full-parameter fine-tuning također je kasniji eksperiment. Opravdan je kada adapter training jasno dosegne plafon, a izmjereni dobitak vrijedi skupljeg training i rollback puta. Shopify svakodnevno trenira sve weightove na golemom scaleu. To nije početna točka manjeg proizvoda.

7. Isporučiti kroz shadow promet

Model prvo dobiva kopirane, de-identificirane zahtjeve bez odgovaranja korisnicima. Treba ga usporediti s postojećim putem, pregledati sliceove neslaganja i mjeriti tail latency. Zatim se izlaže malom, reverzibilnom postotku uz automatski fallback.

Release gateovi trebaju uključiti nula nedopuštenih tool callova, visoku valjanost sheme, provjerenu stopu pojašnjenja, bez statistički uvjerljivog pada utemeljenih odgovora, ograničenu p95 latenciju i niži ukupni trošak po uspješnom zahtjevu. Kill switch mora vratiti promet na prethodni put bez migracije podataka.

Koji GPU bismo unajmili

Za 0,8B ili 1,7B LoRA eksperiment H100 je najčešće pogrešan prvi najam. Jedan A10G ili L4-class GPU s 24GB dovoljan je za postavljanje pipelinea. L40S s 48GB daje više prostora za dulji kontekst, veći batch ili 4B–8B kandidat. A100 s 80GB koristan je kada je ograničenje memorija, a ne prestiž.

Javne cijene 3. rujna 2026. daju okvir za planiranje:

  • Hugging Face navodi A10G po 1,50 USD/sat, L40S po 1,80 USD/sat, A100 80GB po 2,50 USD/sat i H200 po 5 USD/sat.
  • Runpod Secure Cloud navodi L40S po 0,99 USD/sat, A100 80GB po 1,39–1,59 USD/sat, H100 po 2,89–3,29 USD/sat i H200 po 4,59 USD/sat.
  • Lambda navodi A10 po 1,29 USD/sat, A6000 48GB po 1,09 USD/sat i H100 PCIe po 3,29 USD/sat.

Prema tim cijenama, rezerviranje dva do osam sati za početni eksperiment iznosi otprilike 3–12 USD na Hugging Face A10G-u ili 3,60–14,40 USD na L40S-u, samo za compute. To je budžetski okvir, a ne procjena da će training sigurno završiti u tom vremenu. Sequence length, veličina dataseta, batch, učestalost validacije, checkpointing, neuspjeli runovi, storage, egress, dostupnost i porez mijenjaju ukupni trošak.

Najskuplji dio možda uopće nije student GPU. Teacher inference, ponovljeno generiranje podataka, domenski review i izrada pouzdanog eval seta mogu dominirati budžetom.

H100 ili H200 ima smisla za veliki teacher, high-throughput generiranje, mnogo veći full-weight model ili multi-GPU training. Shopifyjev Flow tim navodi dva noda H200 GPU-ova i 12-satni run za Qwen3-32B. To je opis njihova scalea, a ne hardverska preporuka nama.

Mac Studio Ultra kao deployment baseline

Apple je upravo najavio Mac Studio s M5 Ultra, dostupan od 22. rujna 2026. Osnovna američka konfiguracija kreće od 5.499 USD s 96GB unified memoryja. Veća konfiguracija ide do 512GB i 1,2TB/s memory bandwidtha.

Za jedan 0,8B model to je mnogo računala. Sirovi weightovi zauzimaju približno 1,6GB na 16 bita ili 0,4GB na 4 bita, prije runtime i KV-cache overheada. Čak i osnovni M5 Ultra s 96GB ostavlja puno prostora za batching, više procesa ili veće fallback modele.

Zato je Ultra koristan deployment baseline, a ne automatska preporuka za kupnju.

Ima smisla kada PLAYGRND želi:

  • predvidljiv always-on inference bez naplate po tokenu;
  • lokalnu kontrolu nad promptovima, model weightovima i prolaznim inputima;
  • više malih specijaliziranih modela na jednom računalu;
  • dovoljno unified memoryja za veće kvantizirane fallback modele;
  • malu latenciju prema aplikaciji smještenoj u istoj okolini.

Manje smisla ima kada je promet malen ili nepravilan, računalo stoji u uredu bez redundantnog napajanja i mreže ili timu trebaju CUDA-specifični serving i monitoring alati. Jedan Mac Studio ujedno je single point of failure.

Trenirali bismo na unajmljenom NVIDIA hardveru, spojili adapter, exportali i kvantizirali model, zatim na stvarnom Macu benchmarkali MLX i GGUF/llama.cpp-compatible put. Benchmark mora koristiti stvarne PLAYGRND duljine zahtjeva i konkurentnost, a ne token-speed demo s jednom rečenicom.

Appleov MLX-LM projekt podržava LoRA, QLoRA, kvantizaciju i lokalni inference. Njegova dokumentacija izričito kaže da ugrađeni osnovni HTTP server nije preporučen za produkciju jer ima samo osnovne sigurnosne provjere. Produkcijski deploy zato treba hardened interni servis ispred runtimea: autentikaciju, request limite, queueing, timeoute, metrike, strukturirane logove, pinanu verziju modela i health checkove.

Najmanji pouzdan oblik je jedan glavni inference servis uz cloud ili frontier-model fallback. Ozbiljniji self-hosted setup traži drugi node, remote power i recovery, provjerene rollbackove modela i dovoljno observabilityja da razlikuje queueing, obradu prompta i generiranje.

Izračun kupnje treba usporediti američku početnu cijenu od 5.499 USD, lokalne poreze i operacije s izmjerenim cloud inference troškom. Bez stabilnog opterećenja ili razloga vezanog uz kontrolu podataka najam ostaje fleksibilniji. Uz stalan workload, više modela i postojeće operativno okruženje, lokalni inference može postati jednostavniji račun.

Što bi nas zaustavilo

Ne bismo nastavili samo zato što je fine-tune tehnički zanimljiv. Zaustavili bismo se ili ostali na frontier putu ako:

  • hrvatska kvaliteta ne prolazi held-out sliceove;
  • rules baseline već radi dovoljno dobro;
  • produkcijski zahtjevi mijenjaju se brže nego što se dataset može kontrolirati;
  • mali model treba toliko fallbackova da ne smanjuje trošak ili latenciju;
  • revieweri se ne mogu složiti što je točan odgovor;
  • licenca podataka ili modela ne odgovara namjeni;
  • održavanje lokalnog inferencea troši više pažnje nego što vraća.

Rekurzivni flywheel prednost je samo kada svaki krug proizvodi pouzdan signal. Vraćanje nesigurnih oznaka u weightove jednako učinkovito zbraja nesigurnost.

Naš sud

Tobijev rezultat važan je jer pokazuje sljedeći smjer modelskog natjecanja. Frontier modeli ostaju najbolji način istraživanja nejasnog zadatka i generiranja teških kandidata. Kada se zadatak stabilizira, njihovi outputi i produkcijske greške mogu pomoći u treningu mnogo manjeg radnika.

Qwenovi base weightovi su javni, a GPU vrijeme može se unajmiti, pa sam 0,8B checkpoint daje malo obrambene prednosti. Trajniju prednost čine product-specific ugovor, reprezentativni podaci, judge usklađen s domenskim stručnjacima, determinističko execution okruženje i brzina kojom tim stvarnu grešku pretvara u siguran release.

Za PLAYGRND bismo krenuli s jednom read-only bilingvalnom statističkom vještinom, a ne općim nogometnim mozgom. Glavna evidencija i dozvole ostale bi u aplikacijskom kodu, mali model radio bi samo fuzzy prijelaz iz jezika u tool, a zamjena frontier baselinea tražila bi dokaz.

Mali modeli pobjeđuju kada problem postane precizan. Preciziranje problema i dalje je inženjerski posao.

Hardverske specifikacije, dostupnost i javne cijene u članku odražavaju izvore dostupne 3. rujna 2026. i mogu se promijeniti. Shopifyjevi brojevi njihovi su prijavljeni rezultati i nisu jamstvo za drugi workload. PLAYGRND dio je tehnički prijedlog, a ne tvrdnja o deployanoj funkcionalnosti. Ovo nije pravni, privacy ili procurement savjet. Ako procjenjujete specijalizirani model i produkcijski feedback loop, javite se HILLS Labu.