Gemini ignorerar temperature och top_p i nya modeller

Om du bygger mot Gemini API:t och skickar `temperature`, `top_p` eller `top_k` i dina requests: sluta lita på dem. Google har deprecerat de tre sampling-parametrarna i Gemini 3.6 Flash och alla modeller som släpps därefter. Requesten går fortfarande igenom, du får HTTP 200 men värdena har ingen effekt på vad modellen svarar. Parametrarna är så kallade no-ops, tysta och verkningslösa.

Det är precis den tystnaden som gör den här ändringen besvärlig. Skickar du fel parameter till många API:er får du ett felmeddelande och rättar det på minuten. Här händer inget synligt. Koden fungerar, testerna kör och kvaliteten på output kan ändå ha förändrats utan att någon märker det förrän en användare klagar. Diskussionen har redan fått stor spridning på Hacker News, där utvecklare jämför anteckningar om vad som faktiskt slutat fungera.

Tre justerbara rattar blev en fast intern policy

Tidigare gav Gemini dig tre parametrar för att styra hur slumpmässigt modellen väljer nästa ord. `temperature` styrde hur mycket variation, `top_p` och `top_k` begränsade urvalet av kandidat-tokens. Sätt temperature lågt så blev svaren förutsägbara, sätt den högt så blev de mer kreativa och spretiga.

I Gemini 3.6 Flash och Gemini 3.5 Flash-Lite, båda lanserade i juli 2026 och tillgängliga i skarp drift från start, finns den kontrollen inte längre. Modellen kör en enda intern sampling-policy per version. Du kan inte justera den utifrån.

Det märks direkt på determinismen. Samma prompt med samma seed ger nu mer konsistenta token-sekvenser än förut. Den slumpmässighet som tidigare kom från sampling är borta. För vissa är det en lättnad, för andra är det exakt problemet.

Fyra ställen där din kod går sönder utan att säga till

Det är inte uppenbart var en tyst parameter-deprecering slår. Här är de vanligaste fällorna och de har det gemensamt att inget felmeddelande varnar dig. Determinism-pipelines som byggt cache-nycklar eller deduplicering på modellens exakta output kan börja missa träffar eller skapa dubbletter när token-sekvenserna ändrar karaktär. Golden-file- och snapshot-tester börjar flaka efter modellbytet, vilket ser ut som en kvalitetsregression men egentligen bara betyder att facit inte längre matchar den nya samplingen.

Strukturerad output som förlitade sig på låg temperature plus stram top_p för att få ut parsebar JSON tappar den garantin, eftersom du inte längre kan tvinga fram determinismen den vägen. Kreativitets-reglage i ditt användargränssnitt fortsätter att röra sig när användaren drar i dem men de påverkar inte modellen längre. Slidern lever kvar, effekten är död.

Den sista är lite tragikomisk. Du har en knapp i din produkt som lovar något den inte längre kan leverera.

Googles svar är system instructions

Googles officiella ersättning är system instructions. I stället för att skruva på en siffra beskriver du önskat beteende i klartext som modellen läser innan den svarar. Vill du ha korta, sakliga svar skriver du det som en instruktion. Vill du ha varierat, kreativt språk beskriver du det.

Det är en annan sorts kontroll. En numerisk sampling-konstant är trubbig men förutsägbar, en instruktion i naturligt språk är precisare i intention men svårare att mäta. För den som byggt pipelines runt temperature-sweeps, alltså att köra samma prompt på flera temperaturnivåer för att få fram olika varianter, betyder det ombyggnad. Variationen får nu komma från att du formulerar om prompten eller gör flera separata anrop, inte från en ratt.

Google har samlat de här ändringarna i sin officiella migreringsguide för Gemini 3.6 Flash, som går igenom samtliga API-förändringar en efter en.

Agera medan allt fortfarande returnerar 200

Just nu ignoreras parametrarna tyst. Google har inte satt något datum för när de går från no-op till hårt fel men riktningen är tydlig, senare blir de ett error. Det ger dig ett fönster att städa i lugn och ro medan koden ännu inte kraschar. Den fullständiga listan över vad som deprecerats finns dokumenterad i Googles egna release notes.

Tre andra ändringar i Gemini 3.6 Flash ger däremot tydliga felmeddelanden. `candidate_count` är borta, prefill är borta och du kan inte längre skicka både `thinking_budget` och `thinking_level` i samma anrop. Dem hittar du direkt eftersom API:t säger ifrån. Sampling-deprecering är den enda som smyger och därför den du bör leta efter först.

En sak till som är värd att kolla samtidigt: Gemini 3.5 Flash-Lite kör med `minimal` som standard, tunat för genomströmning. Det är en rejäl kostnadsväxel. På samma uppsättning uppgifter kostade 3.6 Flash på `minimal` runt 74 procent mindre per körning än samma modell på `medium`, där tänkande-tokens stod för merparten av den fakturerade outputen. Byter du modell utan att titta på default-nivån kan notan ändras åt endera hållet. Är du osäker på om det lönar sig att fortsätta betala för flera AI-abonnemang parallellt kan det vara läge att räkna på vilka som faktiskt lönar sig.

Google har inte förklarat varför

Det korta svaret är att Google inte har publicerat en fullständig motivering. I diskussionerna kring ändringen har flera rimliga förklaringar dykt upp, ingen bekräftad.

En möjlighet är att modellen justerar sin sampling dynamiskt under inferens, vilket gör en fast användarparameter meningslös. En annan handlar om att SynthID-vattenmärken göms i sampling-generatorns slumptal och utan slump finns inget att gömma dem i. Det finns också de som pekar på destillation, alltså att träna mindre modeller på en större modells output, som kräver deterministiska svar för att fungera väl.

Oavsett skäl är den praktiska slutsatsen densamma. Ratten är borta, den kommer inte tillbaka och den gäller alla modeller framåt.

FAQ

Slutar mina gamla requests att fungera direkt?

Nej. Requests med `temperature`, `top_p` eller `top_k` returnerar fortfarande HTTP 200 i Gemini 3.6 Flash. Värdena ignoreras bara. Google har flaggat att de senare kan bli hårda fel men något datum finns inte ännu.

Gäller det här alla Gemini-modeller?

Nej, det gäller Gemini 3.6 Flash, Gemini 3.5 Flash-Lite och varje ny modell Google släpper framöver. Äldre modellversioner behåller sitt tidigare beteende men om du planerar att uppgradera bör du räkna med att parametrarna slutar ha effekt.

Hur får jag varierade svar nu när temperature är borta?

Du bygger variationen på prompt-nivå i stället. Antingen formulerar du om prompten mellan anropen eller gör du flera separata modell-anrop med olika instruktioner. Det kräver mer arbete än att dra i en enda parameter men ger dig samtidigt tydligare kontroll över vad varje variant faktiskt ska skilja sig i.

Hur vet jag om min kod redan påverkats?

Kör dina snapshot- och golden-file-tester mot den nya modellen och jämför output. Kontrollera också allt som byggt cache-nycklar eller JSON-parsning på antagandet att låg temperature gav deterministiska svar. Om du vill experimentera med kontrollerad slump i egen kod under tiden finns en slumpgenerator att leka med.

Ändringen är liten i kod men stor i vana. För den som byggt hela AI-verktygsflöden runt tre samplingsiffror är det värt att sätta av en eftermiddag på migreringen nu, medan API:t fortfarande är förlåtande.