Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) vs Google: Gemini 3.1 Pro Preview Custom Tools

Dla obciążeń wrażliwych na opóźnienia Google: Gemini 3.1 Pro Preview Custom Tools zwraca pierwszy token wcześniej. Pod względem jakości benchmark Google: Gemini 3.1 Pro Preview Custom Tools prowadzi w indeksie złożonym.

Zarówno Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview), jak i Google: Gemini 3.1 Pro Preview Custom Tools są dostępne przez ten sam endpoint OrcaRouter po koszcie dostawcy i bez żadnej marży na tokenach, więc przełączanie się między nimi to zmiana jednej linii, a liczby poniżej to dokładnie to, co faktycznie płacisz. To porównanie pobiera ceny na żywo, opublikowane context window oraz własne pomiary latency i throughput OrcaRouter, abyś mógł ważyć koszt względem wydajności dla swojego konkretnego obciążenia zamiast polegać na wystawowym benchmarku dostawcy. Właściwy wybór prawie zawsze zależy od kształtu twojego ruchu — długości promptów, ilości generowanego tekstu, tego jak wrażliwi na latency są twoi użytkownicy oraz jak trudne jest rozumowanie — dlatego sekcje poniżej rozkładają decyzję na jeden wymiar naraz i kończą się konkretną rekomendacją. Wszędzie tam, gdzie dla jednego z dwóch modeli brakuje metryki, dany wiersz jest pomijany, a nie zgadywany, więc każde twierdzenie tutaj jest poparte rzeczywistą liczbą.

Jeden lub oba te modele nie ujawniają tutaj ceny za token (może to być model w wersji darmowej, rozliczany za wywołanie lub jeszcze niewyceniony), więc traktuj kolumny kosztów jako orientacyjne i potwierdź stawkę na żywo na własnej stronie każdego modelu, zanim ułożysz na niej budżet.

Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) przyjmuje do 66K tokenów kontekstu, a Google: Gemini 3.1 Pro Preview Custom Tools przyjmuje 1M. Context window ogranicza, ile materiału źródłowego — dokumentów, kodu, wcześniejszej rozmowy — możesz wysłać w jednym żądaniu. Większe okno pozwala pominąć dzielenie na fragmenty i orurowanie wyszukiwania dla długich wejść, ale nadal płacisz stawkę tokenów wejściowych za wszystko, co wysyłasz, więc większe okno to możliwość, a nie zniżka. Dopasuj okno do najdłuższego pojedynczego żądania, jakie twoje obciążenie realnie generuje, a nie do największej liczby na stronie. Miej też na uwadze, że jakość może się pogarszać ku końcowi bardzo długiego kontekstu w każdym modelu, więc duże okno najlepiej traktować jako zapas na okazjonalne długie wejścia, a nie jako przyzwolenie na wypełnianie każdego żądania do limitu.

Latency i throughput decydują o tym, jak model odczuwa się w produkcji. Mediana (p50) latency odpowiedzi to czas oczekiwania typowego żądania przed pierwszym tokenem; throughput (tokeny na sekundę) ustala, jak szybko odpowiedź jest strumieniowana po rozpoczęciu. Dla interaktywnego czatu i pętli agentów najbardziej liczy się niska latency p50, bo użytkownik czeka na pierwszy token; dla generacji wsadowej i wyjścia długiej formy throughput dominuje nad całkowitym czasem, bo odpowiedź jest długa. Wykresy trendu z 7 dni powyżej pokazują, czy latency każdego modelu jest stabilna, czy dryfuje — coś, co pojedyncza nagłówkowa liczba ukrywa: model o świetnej średniej, lecz zaszumionym ogonie może i tak nie spełnić rygorystycznego SLA p95. Jeśli twój produkt ma budżet latency, czytaj zarówno medianę, jak i kształt krzywej, i pamiętaj, że latency od końca do końca obejmuje także twój przeskok sieciowy oraz wszelkie wyszukiwania lub wywołania narzędzi, które wykonujesz wokół modelu.

Wyniki benchmarków przybliżają zdolności, ale nie zastępują testów na twoich własnych promptach. Pokazane tu indeksy złożone agregują wiele publicznych ewaluacji, a percentyl zaznacza, gdzie każdy model plasuje się wobec wszystkich porównywalnych modeli w katalogu — użyteczny sygnał na krótką listę, nie gwarancja dla twojego zadania. Model prowadzący w indeksie inteligencji ogólnej może nadal pozostawać w tyle w twojej dziedzinie (kodowanie, ekstrakcja, wielojęzyczność, rozumowanie na długim kontekście), więc użyj benchmarków, by zawęzić pole, a potem uruchom oba modele na reprezentatywnym wycinku swojego ruchu. Zwróć uwagę na konkretny indeks pasujący do twojego przypadku użycia, a nie na liczbę nagłówkową: produkt intensywny w kodowaniu powinien ważyć indeks kodowania, a asystent badawczy indeks rozumowania. Benchmarki też starzeją się w miarę aktualizowania modeli, więc traktuj je jako hipotezę wyjściową, którą potwierdzasz własnym zestawem ewaluacyjnym.

Jeśli koszt jest wiążącym ograniczeniem, zacznij od tańszego modelu na twoim rzeczywistym miksie wejścia i wyjścia i przejdź wyżej tylko wtedy, gdy zabraknie jakości. Jeśli priorytetem jest responsywność — czat dla użytkowników, agenci, każdy przypadek, w którym ktoś czeka — przeważ latency p50 i throughput nad niewielką różnicą ceny. Jeśli forsujesz najtrudniejsze rozumowanie, kodowanie lub pracę na długim kontekście, pozwól prowadzić zwycięzcy w benchmarku i context window i zaakceptuj wyższą stawkę tam, gdzie się opłaca. Ponieważ oba modele stoją za tym samym API, ruchem o niskim ryzyku jest skierowanie ułamka rzeczywistego ruchu do każdego z nich i porównanie kosztu, latency oraz jakości odpowiedzi na twoich własnych promptach przed podjęciem decyzji. Częstym wzorcem jest warstwowanie (tier): kieruj większość łatwych, wysokowolumenowych żądań do tańszego lub szybszego modelu, a mocniejszy model zarezerwuj dla żądań, które go naprawdę potrzebują, co przechwytuje większość zysku jakościowego za ułamek kosztu. Cokolwiek wybierzesz, utrzymuj przełączenie odwracalnym — zmianą nazwy modelu o jedną linię możesz przenieść ruch z powrotem w chwili, gdy liczby lub twoje wymagania się zmienią.

W ciągu ostatnich 7 dni Google: Gemini 3.1 Pro Preview Custom Tools utrzymuje niższe medianowe opóźnienie odpowiedzi.