Ile tak naprawdę „myśli” AI podczas tłumaczenia?

Gemini to model, który nie przestaje zaskakiwać. To najlepszy LLM do tłumaczeń dostępny „od ręki” dla większości języków. Dzięki funkcji myślenia można rozgryźć nawet najtrudniejsze wyzwania, takie jak idiomy, nawiązania do anime czy unikalny brand voice™.

Problem w tym, że myślenie zajmuje czas. Myślenie kosztuje – każdy poświęcony na nie token jest płatny. Jako deweloper chcesz mieć kontrolę nad obiema tymi kwestiami.

Z Gemini 2.5 było łatwo. Gemini 3 wszystko skomplikowało.

Oto czego dowiedzieliśmy się w laboratoriach Transeptu

Co się zmieniło w Gemini 3

Gemini 2.5 oferowało parametr thinkingBudget, czyli liczbowy limit tokenów przeznaczonych na procesy myślowe. Gemini 3 z niego zrezygnowało. Zastąpiono go parametrem thinkingLevel – ustawieniem kategorycznym z czterema wartościami: minimal, low, medium oraz high. Te dwa parametry wzajemnie się wykluczają; w obecnych wersjach SDK przesłanie obu do modelu Gemini 3 skutkuje błędem 400.

To zmienia znaczenie „kontroli kosztów” w praktyce. Wcześniej można było narzucić sztywny pułap wydatków. Teraz to model decyduje, ile tokenów zużyje w ramach poziomu „medium”.

Zakładamy, że modele są dotrenowywane tak, aby dostosowywały czas namysłu do stopnia trudności zadania, podobnie jak robią to ludzie. Narzucanie arbitralnych limitów mogłoby więc upośledzić tę zdolność.

Ile jednak tokenów faktycznie zużywają poziomy low, medium i high?

Dane

Oto próbka danych z dwóch tygodni rzeczywistego ruchu tłumaczeniowego – około 1000 wywołań w trzech modelach Gemini 3. Dane o tokenach procesu myślowego pochodzą z pola usageMetadata.thoughtsTokenCount w każdej odpowiedzi, co stanowi najdokładniejsze możliwe źródło informacji.

Tokeny myślowe według modelu

Liczba 15 725 to nie literówka. Jedno wywołanie tłumaczenia w modelu Flash, przy ustawieniu medium, pochłonęło piętnaście tysięcy tokenów rozumowania.

Zazwyczaj takie napompowane wyniki są efektem wycieku surowych tokenów myślowych Gemini do treści wyjściowej. Jak wiadomo, „myślenie” modelu nie jest tym, co on faktycznie myśli, lecz wygładzonym podsumowaniem; prawdziwe rozumowanie LLM przypomina raczej strumień świadomości.

Warto jednak zauważyć, że w tym konkretnym przypadku Gemini spokojnie głowiło się nad przekładem literackiego fragmentu z angielskiego na ukraiński, zawierającego frazę w rodzaju „czysta stal odrzuca lakiery i farby”. Model testował metodą brute-force chyba z dwanaście opcji, aż w końcu uznał wynik za satysfakcjonujący.

Kilka tygodni później – aktualizacja. Te 15,725 tokenów nie było jednorazowym aktem oddania ze strony Gemini, lecz schematem specyficznym dla złożonych zadań.

Przy większym ruchu, zwłaszcza w gemini-3.1-flash-lite, ta sama liczba ciągle powraca. Podejrzanie wąski przedział 15,724–15,729 tokenów pojawia się w dziesiątkach zapytań, z których prawie wszystkie to modele Lite „mielące” audyty glosariuszy. Co ciekawe, pracują one w trybie niskiego wysiłku (low), którego nikt nie podejrzewałby o bycie najdroższym ustawieniem.

Model, który jedenaście razy z rzędu zatrzymuje się na tej samej liczbie, nie tyle dobiera sformułowania, co uderza w sufit. Tryb niskiego wysiłku (low) nasyca się w okolicach 15,7 tys. tokenów. Mniejsze modele, takie jak lite, myślą mniej efektywnie, więc trudne zadania zmuszają je do spalania ogromnej liczby tokenów. W przypadku większych modeli to się nie zdarza – tam każdy z ich tokenów z większym prawdopodobieństwem stanowi istotny krok w stronę odpowiedzi.

To nasycenie ma zresztą swoją cenę. W Gemini 3 tokeny myślowe wliczają się do limitu maxOutputTokens. Zapytanie, które zużywa 15,7 tys. na myślenie, nie zostawia niemal nic na odpowiedź, a mimo to cały ten proces jest rozliczany według stawki za tokeny wyjściowe. Przy budżecie 16 tys. tokenów audyt małych dokumentów w około połowie przypadków wracał pusty (finishReason=MAX_TOKENS), co skłoniło nas do zbadania sprawy.

Zwiększenie budżetu leczy objawy, a nie przyczynę. Przesunęliśmy limit audytu na 32 tys. tokenów w trybie low, co po nasyconym procesie myślowym zostawia około 16 tys. na wynik – dzięki temu puste odpowiedzi przestały się pojawiać. Jednak samo myślenie wcale się nie skróciło. W Gemini 3 nie da się go ograniczyć, więc model nadal spala około 15,7 tys. tokenów; większy budżet daje po prostu odpowiedzi miejsce, by mogła się pojawić.

Jedynym realnym sposobem na uporanie się z tym „maksowaniem” myślenia do 16 tys. było ograniczenie zakresu zadania.

minimal to jedyny poziom, który zachowuje się jak prawdziwy limit, z sufitem w okolicach 2 tys. tokenów. Jest on jednak dostępny wyłącznie dla modeli Lite.

Tokeny myślowe według typu zadania (Flash vs Pro, oba w ustawieniu medium)

Przy zwykłym tłumaczeniu Pro „myśli” niemal dwukrotnie mniej niż Flash. Przewyższa go pod tym względem tylko przy zadaniach polegających na przeredagowywaniu tekstu. Intensywność rozumowania zależy od trudności zadania, a nie od pozycjonowania marketingowego modelu.

Można uznać, że Pro osiąga lepsze wyniki w benchmarkach tłumaczeniowych właśnie dzięki zdolności do głębszej analizy w sytuacjach, które tego wymagają.

Wnioski praktyczne

• Nie ustawiaj parametru thinkingBudget dla modelu Gemini 3. Zostanie on zignorowany lub wywoła błąd.
• Poziom medium nie ma odgórnego limitu. Realistycznie należy zakładać ok. 4 tys. tokenów myślowych p90 na wywołanie, a nie 2 tys.
• Jeśli potrzebujesz sztywnego limitu kosztów, używaj minimal tam, gdzie to możliwe. Przerywanie generowania odpowiedzi nie ma sensu – i tak zostaniesz obciążony kosztami.
• Jeśli rozliczasz się za każde wywołanie, sprawdzaj usageMetadata.thoughtsTokenCount przy każdej odpowiedzi. Ta liczba nie znajduje się w treści odpowiedzi, ale widnieje na fakturze.
• W trybie medium model Pro przy prostych zadaniach prawdopodobnie „myśli” mniej niż wynosi jego mediana, a przy trudnych – więcej. Modele Lite i Flash nie wykazują takiej zmienności.

Oznacza to, że Pro jest najlepszym modelem do korekty i dopracowywania tekstów na poziomie wykraczającym poza bazowe możliwości LLM, gdyż to właśnie wtedy aktywuje się jego kreatywność. Surowe tłumaczenia robocze lepiej powierzyć modelowi Flash.

Wymaga to jednak czasu i nakładów finansowych. W Transept znaleźliśmy sposób na ograniczenie kosztów modelu Pro, stosując inteligentną logikę korekty, która angażuje go tylko do najtrudniejszych fragmentów. Używamy Pro również do planowania i podejmowania decyzji, delegując wykonanie mniejszym i dotrenowanym modelom.

W ten sposób wszystko działa jak należy.