google/gemini-3.1-flash-tts-preview mot Google: Gemini 3.6 Flash

Vad gäller pris är google/gemini-3.1-flash-tts-preview det billigare alternativet — cirka 33% under Google: Gemini 3.6 Flash för indatatokens. För latenskänsliga arbetsbelastningar returnerar Google: Gemini 3.6 Flash den första token snabbare. När det gäller benchmark-kvalitet leder Google: Gemini 3.6 Flash det sammansatta indexet. Välj google/gemini-3.1-flash-tts-preview för att minimera kostnaden, eller Google: Gemini 3.6 Flash när svarshastighet betyder mest.

Både google/gemini-3.1-flash-tts-preview och Google: Gemini 3.6 Flash är tillgängliga via samma OrcaRouter-slutpunkt till leverantörskostnad utan tokenpåslag, så att byta mellan dem är en rad kod och siffrorna nedan är vad du faktiskt betalar. Denna jämförelse hämtar aktuella priser, det publicerade kontextfönstret och OrcaRouters egna mätningar av latens och genomströmning så att du kan väga kostnad mot prestanda för din specifika arbetsbelastning istället för att förlita dig på en leverantörs huvudsakliga benchmark. Det rätta valet beror nästan alltid på formen på din trafik — promptlängd, hur mycket text du genererar, hur latenskänsliga dina användare är och hur svårt resonemanget är — så avsnitten nedan bryter ner beslutet en dimension i taget och avslutas med en konkret rekommendation. Där ett mätvärde saknas för en av de två modellerna utelämnas den raden istället för att gissas, så varje påstående här backas upp av ett verkligt tal.

För indatatokens kostar google/gemini-3.1-flash-tts-preview $1.00 per 1M jämfört med $1.50 för Google: Gemini 3.6 Flash, och för utdata $20.00 jämfört med $7.50 per 1M. Utdatatokens är oftast det som avgör notan: en chatt- eller agentbelastning som genererar långa svar domineras av utdatapriset, så modellen som ser billigare ut på indata kan ändå bli det dyrare valet totalt sett. Uppskatta ditt verkliga förhållande mellan indata och utdata innan du väljer enbart på pris — en hämtningstung prompt med ett kort svar och en kort prompt med en lång generering hamnar på motsatta sidor av denna tabell. Ett praktiskt sätt att beräkna detta är att ta ett representativt urval av dina prompter, räkna det genomsnittliga antalet indata- och utdatatokens, och multiplicera vardera med de två modellernas respektive priser; modellen med den lägsta blandade kostnaden för din faktiska mix är den att slå. Kom ihåg att båda priserna här är leverantörens råpris — OrcaRouter lägger inte till något påslag — så jämförelsen är rättvis och besparingarna du räknar ut är besparingarna du behåller.

Latens och genomströmning avgör hur modellen känns i produktion. Median (p50) svarslatens är hur länge en typisk förfrågan väntar innan den första token; genomströmning (tokens per sekund) avgör hur snabbt svaret strömmar när det väl börjat. För interaktiv chatt och agentloopar betyder låg p50-latens mest eftersom användaren väntar på den första token; för batch-generering och långa svar dominerar genomströmningen den upplevda tiden eftersom svaret är långt. 7-dagarsgraferna ovan visar om varje modells latens är stabil eller drivande, vilket ett enda huvudtal döljer — en modell med ett bra genomsnitt men en brusig svans kan ändå missa en strikt p95-SLA. Om din produkt har en latensbudget, läs både medianen och kurvans form, och kom ihåg att den totala latensen även omfattar ditt nätverkssteg och eventuella hämtnings- eller verktygsanrop du gör runt modellen.

Benchmark-poäng approximerar förmåga men ersätter inte tester på dina egna prompter. De sammansatta index som visas här aggregerar flera offentliga utvärderingar, och percentilen markerar var varje modell hamnar jämfört med alla jämförbara modeller i katalogen — en användbar signal för en kortlista, men ingen garanti för din uppgift. En modell som leder på ett allmänt intelligensindex kan ändå ligga efter inom din domän (kodning, extraktion, flerspråkighet, resonemang med lång kontext), så använd benchmarks för att smalna av fältet och kör sedan båda modellerna på en representativ del av din trafik. Var uppmärksam på det specifika index som matchar ditt användningsfall snarare än toppsiffran: en kodningstung produkt bör väga kodningsindexet tyngre, en forskningsassistent resonemangsindexet. Benchmarks åldras också när modeller uppdateras, så behandla dem som en utgångshypotes du bekräftar med din egen utvärderingsuppsättning.

Om kostnaden är den avgörande begränsningen, börja med den billigare modellen för din faktiska förhållande mellan indata och utdata och gå bara upp om kvaliteten inte räcker till. Om responsivitet är prioriteten — användarvänd chatt, agenter, allt där någon väntar — väg p50-latens och genomströmning tyngre än en liten prisskillnad. Om du driver det tyngsta resonemanget, kodningen eller arbetet med lång kontext, låt vinnaren i benchmark och kontextfönster leda och acceptera det högre priset där det lönar sig. Eftersom båda modellerna ligger bakom samma API är det lågrisk-draget att routa en del av den verkliga trafiken till vardera och jämföra kostnad, latens och svarskvalitet på dina egna prompter innan du bestämmer dig. Ett vanligt mönster är att skikta: skicka merparten av enkla, högvolymsförfrågningar till den billigare eller snabbare modellen och reservera den starkare modellen för de förfrågningar som verkligen behöver den, vilket fångar merparten av kvalitetsvinsten till en bråkdel av kostnaden. Oavsett vilken du väljer, håll bytet reversibelt — med en radändring av modellnamnet kan du flytta trafik tillbaka så fort siffrorna eller dina krav förändras.

Under de senaste 7 dagarna har Google: Gemini 3.6 Flash den lägre medianlatensen för svar.