Fine-Tuning Gemma 4 på Apple Silicon: Kan det erstatte Claude Sonnet for innholdsgenerering?

Vi driver en sportsdataplattform som publiserer kamprapporter og ligaoppsummeringer på tvers av ni idretter. Hver artikkel har blitt generert gjennom API-kall til Claude Sonnet — pålitelig, høy kvalitet, men dyrt i stor skala. Vi ønsket å vite: kunne en åpen kildekode-modell, fine-tunet på våre egne data, produsere artikler av sammenlignbar kvalitet mens den kjørte helt på lokalt maskinvare?

Dette innlegget går gjennom det fullstendige eksperimentet — fra datapreparing til LoRA fine-tuning til en direkte sammenligning — ved hjelp av Googles Gemma 4 31B-modell, Apples MLX-rammeverk og en MacBook Pro M3 Max med 96GB samlet minne. Vi bryter også ned den virkelige økonomien: når sparer det faktisk penger å trene en egendefinert modell sammenlignet med API-kall?

Hva er Gemma 4?

Gemma 4 er Googles åpenvektet store språkmodell-familie, utgitt i 2025 som etterfølger til Gemma 2-serien. Nøkkelordet er åpenvektet — i motsetning til proprietære modeller som GPT-4 eller Claude er Gemma 4s vekter fritt tilgjengelige for nedlasting, fine-tuning og distribusjon uten løpende API-avgifter.

Modellen kommer i flere størrelser. Vi brukte 32B-parameter instruksjonsjustert variant (google/gemma-4-31B-it), som sitter på et søtt punkt mellom evne og maskinvarekrav. Ved full fp16-presisjon trenger det omtrent 62GB minne; med 4-bits kvantisering komprimeres det til omtrent 16GB, lite nok til å kjøre på en bærbar datamaskin med 32GB RAM.

Det som gjør Gemma 4 spesielt interessant for vårt brukstilfelle:

• Ingen API-kostnader — når den er lastet ned, er inferens gratis (minus elektrisitet)
• Fine-tunable — LoRA-adaptere lar deg spesialisere modellen på ditt domene med minimal beregning
• Kjører på forbrukerutstyr — Apples Silicon sitt arkitektur med samlet minne gjør det mulig å trene og kjøre en 31B-modell på en MacBook Pro
• Kommersiell-vennlig lisens — Gemmas vilkår tillater kommersiell bruk, noe som gjør det levedyktig for produksjonarbeidsbelastninger

Avveiingen er klar: du gir opp bekvemmeligheten av et API-kall plug-and-play i bytte mot kontroll, privat og dramatisk lavere marginale kostnader i stor skala.

Problemet

Vår plattform genererer hundrevis av artikler per dag på tvers av fotball, basketball, ishockey, NFL, baseball, rugby, volleyball og håndball. Hver artikkel koster omtrent $0,016 i API-kall til Claude Sonnet. Det summerer seg raskt — 500 artikler per dag betyr $240 per måned, eller $2 880 per år.

Utover kostnad ønsket vi:

• Kontroll over modellen — evnen til å fine-tune på vår eksakte redaksjonelle stil i stedet for å oppfordre en generell modell til det
• Offline-inferens — ingen avhengighet av ekstern API-tilgjengelighet
• Dataprivacy — kampdataene forlater aldri vår infrastruktur

Hypotesen: hvis vi trener en 31B-parameter modell på 120 “perfekte” artikler skrevet av Claude Sonnet, burde den lære strukturen, tonen og sportsspesifikke konvensjoner godt nok til å produsere artikler autonomt.

Rørledningen

Eksperimentet kjørte i fem faser:

Fase 1: Valg av treningskamper — Ikke alle kamper gjør gode treningseksempler. Vi bygget et rikhetsscoringsystem som favoriserte datadense kamper med hendelser, statistikk og ligasammenheng. Vi valgte 100 kampartikler og 20 ligarundesummeringer, med mangfold på tvers av resultattyper (hjemmesegre, borteseire, uavgjort, blowouts, comebacks). For dette innledende eksperimentet fokuserte vi utelukkende på fotball: 120 treningseksempler totalt.

Fase 2: Generering av referanseartikler med Claude Sonnet — Hver kamps JSON-data ble transformert til en strukturert tekstprompt og sendt til Claude Sonnet med en systemprompt som definerte den inverterte pyramideartikkelstrukturen: overskrift, ledeparagraf med poengsum, kronologiske nøkkelmomenter, statistikkanalyse, ligasammenheng og et kort fremtidsblikk. Hver artikkel kostet ~$0,016. Det fullstendige 120-artikkel datasettet kostet under $2.

Fase 3: Datasetformatering — Artikler ble konvertert til Gemmas chat-format (<start_of_turn>user / <start_of_turn>model) og delt 90/10 i 115 trening og 13 valideringseksempler.

Fase 4: Fine-Tuning med LoRA på MLX — Her tjener Apple Silicon pengene sine. Hele 31B-modellen passer i samlet minne på M3 Max. Vi brukte LoRA til å sette inn små trenerbare matriser i 16 lag, og la til bare 16,3 millioner trenerbare parametere — 0,053% av totalen.

Valideringstap falt fra 6,614 til 1,224 over 345 iterasjoner, med den bratteste forbedringen i de første 100 trinnene.

Fase 5: Kvantisering — Vi brukte 4-bits kvantisering ved hjelp av MLX, og komprimerte modellen fra 62GB til ~16GB. Dette gjorde inferensen 2,6 ganger raskere mens man opprettholdt akseptabel kvalitet.

Resultater: Gemma 4 vs. Claude Sonnet

Vi sammenlignet fem artikler generert fra identiske kampdata på tvers av alle tre konfigurasjoner.

Hvor den fine-tunete Gemma 4 utmerker seg:

• Overskrifter er konsekvent sterke — i ett tilfelle ord-for-ord identisk med Sonnets utgang
• Artikkelstrukturen følger det inverterte pyramidemønsteret perfekt
• Kampfakta (lagunavn, poengsum, målscorere, minutter) blir rapportert nøyaktig i de fleste tilfeller

Hvor Sonnet fortsatt leder:

• Narrativ flyt — Sonnets artikler leses mer naturlig med bedre avsnittoverganger
• Faktisk presisjon — null hallusinasjoner eller feilattribusjoner i testsettet
• Konsistens — produserer pålitelig artikler i målordtellingen med enhetlig kvalitet

Var LoRA-trening verdt det? Absolutt. Uten LoRA produserer grunnmodellen Gemma 4 utgang full av interne tanketokener (<|channel>thought), markdown-formatering og generisk sportsskriving. Den fine-tunete modellen gir ren, produksjonsklar tekst i vår eksakte redaksjonelle stil. Hele LoRA-treningen kostet $2 i API-kall og 2,5 timer beregning.

Viktig merknad: M3 Max var en testbenkk, ikke et produksjonsmål

MacBook Pro M3 Max tjente sitt formål som en utvikling- og eksperimentasjonsplattform. Det beviste at fine-tuning og inferens på en 31B-modell er teknisk mulig på Apple Silicon. Men vi ville aldri distribuere produksjonarbeidsbelastninger på en lokal bærbar datamaskin.

For faktisk produksjonsdistribusjon er en cloud-GPU-instans det riktige valget. Her er hvordan en realistisk distribusjon ser ut på AWS.

Kostnadsanalyse: Cloud-GPU vs. Sonnet API vs. Lokal maskin

AWS GPU-distribusjon (g5.xlarge — NVIDIA A10G, 24GB VRAM)

Den kvantiserte 4-bits Gemma 4-modellen (16GB) passer komfortabelt på en enkelt A10G-GPU. Inferenshastigheten på A10G er dramatisk raskere enn Apple Silicon — omtrent 15 sekunder per artikkel vs. 80 sekunder på M3 Max.

Side-by-Side månedlig kostnadssammenligning (500 artikler/dag)

GPU-fordelen er klar: 74% kostnadsreduksjon på on-demand-instanser, 89% på spot-instanser, sammenlignet med Sonnet API-kall — med generasjonshastigheter bare 7-8 ganger saktere enn et API-kall i stedet for 40 ganger saktere på M3 Max.

Lokal maskinøkonomi

Den lokale M3 Max har den laveste marginale kostnaden ($0,0007/artikkel i elektrisitet) men den høyeste initialinvesteringen. Med ~45 artikler per time (4-bits kvantisert) produserer en enkelt M3 Max omtrent 1 080 artikler per dag som kjører 24/7.

Når gir lokalt mening? For selskaper som trenger 100% dataprivacy og ikke kan bruke skybaserte modeller — enten på grunn av regulatoriske krav, kontraktlige forpliktelser eller drift i sensitive domener — eliminerer lokal distribusjon all ekstern dataoverføring. Kampdataene, modellvektene og det genererte innholdet forlater aldri selskapets lokaler. Dette handler ikke om kostnadsoptimering; det handler om samsvar og kontroll. Industrier som forsvar, helsevesen, finans og jus kan finne dette som det eneste akseptable distribusjonsmodellen.

Når betaler det seg å trene en egendefinert modell?

Det kritiske spørsmålet: ved hvilket volum blir investeringen i fine-tuning break-even mot bare å bruke Claude Sonnet for alt?

Engangskosten for egendefinert modellrørledning

Break-Even-beregning

Sparingene per artikkel avhenger av distribusjonen din:

Hvis vi ekskluderer utviklertid (behandler den som en ugjenkallelig kostnad for læringsopplevelsen) og bare teller harde infrastrukturkostnader ($21):

Matematikken er enkel: hvis du genererer mer enn ~1 500 artikler, betaler den egendefinerte modellen seg selv i harde kostnader alene. Inkludert utviklertid presser break-even til omtrent 35 000-45 000 artikler, eller omtrent 2,5-3 måneder på 500 artikler per dag.

I stor skala (500+ artikler/dag) er de årlige sparingene betydelige:

Hybridstrategien

Den mest praktiske tilnærmingen er hybrid: bruk den fine-tunete Gemma 4-modellen for rutineinnhold (hoveddelen av volumet), og reservér Claude Sonnet for:

• Komplekse artikler som krever dypere analytisk resonnement
• Uvanlige situasjoner der modellen har ingen treningsdata
• Nye idretter eller innholdstyper før fine-tuning-data finnes
• Kvalitetskritiske stykker der null hallusinasjonsrisiko er essensielt

Dette gir deg kostnadsfordelene ved selvvertede inferens på 80-90% av ditt volum mens du holder Sonnets overlegne kvalitet tilgjengelig for edge-tilfellene som betyr mest.

Hva vi lærte

LoRA er bemerkelsesverdig effektiv for stiloverføring. Med bare 115 treningseksempler lærte modellen vår eksakte artikkelformat, tone og sportsspesifikke konvensjoner. Den inverterte pyramidestrukturen, aktiv-verb-stilen og datagrunnede tilnærmingen overførte alle rent.

Apple Silicon er en levedyktig treningsplattform for 31B-modeller. M3 Max håndterte hele modellen med gradient checkpointing, som toppet på 76,4GB. Treningen ble fullført på 2,5 timer — raskt nok til å iterere på hyperparametere innen en enkelt arbeidsdag.

Strukturerte inndata betyr enormt. Kvaliteten på dataformatteringen påvirker direkte artikkelkvaliteten. Investering i omfattende datautvinning gir utbytte både på API- og selvvertede stier.

Produksjonsdistribusjon hører hjemme i skyen (for de fleste team). M3 Max beviste konseptet. AWS GPU-instanser leverer hastigheten og påliteligheten som trengs for produksjonarbeidsbelastninger med 74-89% mindre kostnad enn API-kall. Lokale maskiner gjenstår som det riktige valget bare når dataprivacy-krav utelukker all ekstern infrastruktur.

Break-even-matematikken favoriserer egendefinerte modeller i moderat skala. Ethvert team som genererer mer enn ~1 500 artikler vil gjenvinne de harde kostnadene ved fine-tuning nesten umiddelbart. Det virkelige spørsmålet er ikke om egendefinerte modeller sparer penger — det er om teamet ditt har ingeniørkapasiteten til å bygge og vedlikeholde rørledningen.

Konklusjon

Fine-tuning av Gemma 4 31B produserte en innholdsgenerator som samsvarer med Claude Sonnet når det gjelder overskriftskvalitet, artikkelstruktur og faktisk nøyaktighet — mens den reduserer per-artikkel-kostnader med 74-89% på skyinfrastruktur og muliggjør fullt privat, på-lokale distribusjon for organisasjoner som krever det.

M3 Max MacBook tjente rent som en testbenkk for dette eksperimentet. Ekte produksjonsdistribusjon ville kjørt på AWS GPU-instanser (g5.xlarge med A10G), hvor den kvantiserte modellen genererer artikler på omtrent 15 sekunder til $0,0042 hver — sammenlignet med $0,016 per Sonnet API-kall.

For selskaper som trenger fullstendig dataprivacy og ikke kan bruke skybaserte AI-tjenester, er en lokal maskin som kjører den kvantiserte modellen et legitimt alternativ. Med ~45 artikler per time håndterer en enkelt arbeidsstasjon moderate volumer med null ekstern dataavsløring. Maskinvareinvesteringen betaler seg selv på omtrent 8 måneder sammenlignet med API-kostnader.

Økonomien er klar: på 500 artikler per dag sparer en egendefinert fine-tunet modell på AWS spot-instanser over $2 000 per år sammenlignet med Claude Sonnet API-kall. Break-even-punktet kommer på under 3 måneder. For team som allerede kjører innholdsgenerering i stor skala, representerer kombinasjonen av åpenvektede modeller, LoRA fine-tuning og vare-GPU-maskinvare et troverdig, kostnadseffektivt alternativ til proprietære API-er.

Bygget med FlowHunt . Den fullstendige rørledningen — fra datapreparing gjennom fine-tuning til inferens — er tilgjengelig som en del av vår sportsdataplattform-verktøykasse.