Det et modellbytte avslørte
Feil på fire steder rundt Turboscores lokale modell, fra gangene den ble lagt til, byttet eller flyttet. Ingen av dem er en dom over modellen.
Søket i Turboscore spør en lokal modell, via Ollama, bare når mønstergjenkjenneren ikke klarer å lese et spørsmål på egen hånd. Den modellen er byttet ut og flyttet mer enn én gang. Ingen av flyttene gikk fra et skybasert API til en lokal modell; alle gikk fra Ollama til Ollama, en annen modell eller en annen maskin. Hver gang modellen begynte å kjøre, ble byttet eller ble flyttet, dukket det opp noe: i ledeteksten vår, koden vår, konfigurasjonen vår, eller en jobb som ikke gjorde det kommentaren sa.
Tallene er hentet fra commit-meldingene til rettingene, skrevet da de ble gjort. De er ikke kjørt på nytt for dette notatet.
1. Et eksempel i ledeteksten ble svaret
I januar 2026 fikk uttrekket av søkeparametere en modell, for spørsmål som «en bensin-V8 som Elvis». Koden ble først
levert med llama3.2 som modellnavn, en modell som ikke var installert; det ble rettet tre dager senere.
Ledeteksten viste ett utfylt eksempel med konkrete verdier: en Cadillac, year_max 1980. For spørsmål som ikke
traff noen kulturell referanse, kopierte modellen eksempelet. «Pålitelig bil» ga 0 biler; etter at eksempelet fikk
plassholdere i stedet, 7 319. «Anbefal en bil»: 0, så 20 505. «Rask bil»: 8, så 970.
Samme uke la modellen til fuel_type = gasoline på 8 av 8 nøytrale spørsmål, og styrte vage søk bort fra elbiler og
hybrider; en uttrykkelig regel tok det ned til 0 av 8. Og koden som hentet JSON ut av svaret, brukte et mønster som
ikke kan treffe et nøstet objekt, og et svar den ikke kunne tolke, feilet stille.
Rettingene i ledeteksten ble stående, og modellen spørres nå sjeldnere: når mønstergjenkjenneren allerede har en karosseritype eller en tidsbetingelse og spørsmålet ikke har noen kulturell referanse, blir modellen ikke spurt i det hele tatt. Verdiene i et eksempel i ledeteksten er, for modellen, et mulig svar.
2. Et bytte for én funksjon endret en annen
I februar ble søkets modellkall flyttet over på den felles Ollama-klienten. Kallet oppgir ingen modell, så det tar det konfigurasjonen sier. I juli flyttet to commits samme kveld, en søkeretting som også endret utrullingsmalen og en engangsmigrering av produksjonsinnstillingene, hovedmodellen fra llama3.1:8b på en utviklingsmaskin til gemma3:4b på produksjonsserveren. Begge oppgir samme grunn: svartid i en annen funksjon, rådgivningssvarene, som hadde fått tidsavbrudd mens utviklingsmaskinen var opptatt.
Ingen av dem sier at søkets modellkall leser den samme innstillingen. Gjennom den fikk også søkeuttrekket ny modell. Det tar fortsatt den modellen konfigurasjonen navngir. En modell er en avhengighet; en konfigurasjonslinje som navngir én, endrer hvert sted i koden som kaller modellen uten å navngi sin egen.
3. Den gamle modellens toleranse skjulte en feil i språkgjenkjenningen
Samme dag kom en retting for norske spørsmål som ble besvart på svensk eller engelsk. Språkgjenkjenneren fant det svenske vilken inne i det norske hvilken, og kjente ikke det norske hva i det hele tatt, så ledeteksten ba modellen svare på feil språk. Commiten med rettingen noterer at llama3.1:8b hadde skjult dette ved å svare på spørsmålets språk uansett; gemma3:4b fulgte instruksen den fikk.
En mer lydig modell er en test av instruksene. Feilen lå i språkgjenkjenneren, og den var der før byttet.
4. Holdt varm, men ble kald
På produksjonsserveren ble modellen lastet ut når den sto ubrukt, og neste spørsmål måtte vente på en kaldstart på rundt
15 sekunder, fikk tidsavbrudd og falt tilbake til den andre maskinen. En cron-jobb ble lagt inn for å pinge modellen
hvert 30. minutt. Kommentaren sa at modellen ble liggende lastet i 60 minutter. Kallet sendte ingen keep_alive, så
Ollama brukte standardverdien sin på fem minutter. Etter det regnestykket, hvis ingen spørsmål kom i mellomtiden, var modellen kald
i 25 minutter av hver halvtime, og det første spørsmålet etter en stille periode betalte akkurat den forsinkelsen jobben
var laget for å hindre. Ti dager
senere flyttet et ping med keep_alive angitt modellens utløp fra fem minutter til seksti, kontrollert på serveren.
Feilstien hadde sin egen feil, funnet samme dag som byttet: når kallet til Ollama feilet, fikk brukeren en engelsk unnskyldning med den rå unntaksteksten hengt på. Nå kommer en kort melding om at tjenesten er opptatt, på brukerens språk.
Trege og kalde stier skjuler ting begge veier. Et tidsavbrudd som faller tilbake til et trygt svar, skjulte også en modell som svarte feil når den var varm; det tilfellet er beskrevet i En test som kan feile.
Hva dette notatet ikke påstår
Det sammenligner ikke de to modellene. Det finnes ingen fersk måling av llama3.1:8b mot gemma3:4b på dagens søkeløsning, så ingen påstand her handler om hvilken som er best eller raskest. Poenget er smalere: et bytte endrer oppførsel der ingen ser etter, så kontrollene hører hjemme på hvert sted i koden som kaller modellen, ikke bare i funksjonen byttet var ment for.