GPT-6 Astra: Wysoki vs Ultra. Ten sam wynik, ponad 3 razy więcej tokenów

👁 119 przeczytań

W moim teście Wysoki i Ultra zdobyły po 12 punktów na 12. Ultra miało jednak o 80,92% wyższą medianę czasu i zarejestrowało co najmniej 3,53 raza tyle tokenów co Wysoki. Sprawdziłem sześć własnych łamigłówek, każdą dwukrotnie w obu ustawieniach Codexa. Publikuję zadania, odpowiedzi, wyniki sprawdzania i dane do samodzielnego przeliczenia.

To wynik małego eksperymentu z narzędziami, nie ranking wszystkich zastosowań Astry. A tokeny nie są rachunkiem za abonament: część wejścia pochodziła z cache, czyli pamięci podręcznej. Ta różnica ma znaczenie dla interpretacji liczb.

Najważniejsze wyniki

Wysoki był szybszy w 12 z 12 bezpośrednich par: to samo zadanie, to samo powtórzenie, inne ustawienie. Nie wyciągam z tego wniosku, że Ultra zawsze przegrywa. W tej skali problemów dodatkowa praca nie podniosła mierzonej poprawności, bo oba tryby już osiągnęły maksimum.

Skąd pomysł na ten test?

Punktem wyjścia były efektowne demonstracje AI przechodzącej gry i zadania przypominające CAPTCHA. Taki klip dobrze pokazuje, że coś jest możliwe. Rzadko odpowiada jednak na pytania, ile było podejść, jak długo trwała całość i ile pracy wykonano poza widocznym oknem.

Zamiast rozstrzygać ustawienia cudzego nagrania, sprawdziłem coś, co można zmierzyć u siebie: czy przesunięcie suwaka z Wysokiego na Ultra daje lepszy rezultat. Sam napis Ultra nie wystarczył mi jako dowód konfiguracji. Sprawdziłem zapisane metadane sesji: model gpt-6-astra oraz wartości high i ultra.

OpenAI opisuje Ultra jako tryb, który może dzielić złożoną pracę między agentów pomocniczych. Dokumentacja zaleca dobieranie wysiłku do zadania i wskazuje, że większość zadań nie wymaga Max ani Ultra. To opis przeznaczenia funkcji, nie wynik mojego pomiaru. Dokumentacja modeli i poziomów wysiłku.

Jak wyglądał eksperyment

Przygotowałem sześć instancji zadań w trzech grupach. Każdą uruchomiłem w nowej sesji, dwukrotnie na Wysokim i dwukrotnie na Ultra. Daje to 24 uruchomienia, ale nadal tylko sześć różnych problemów. Powtórzenia pokazują zmienność wykonania, nie powiększają liczby niezależnych zadań.

Oba ustawienia mogły używać lokalnych narzędzi i pisać skrypty. Nie zlecałem szukania rozwiązań w internecie. Nie wskazywałem metody rozwiązania ani liczby pomocniczych agentów. Porównuję zatem działanie Codexa z narzędziami, a nie samą odpowiedź modelu bez możliwości obliczeń.

Limit wynosił 120 sekund na próbę. Czas liczyłem od startu procesu do zapisanej końcowej odpowiedzi. Obejmuje uruchomienie programu, kontakt z usługą, pracę narzędzi i generowanie. Nie nazywam go czystym czasem rozumowania.

Wyniki wzorcowe policzyłem przed oceną odpowiedzi. Potem sprawdziłem je drugim programem. Dla Sokobana porównałem przeszukiwanie wszystkich kroków z algorytmem rozważającym pchnięcia i dojścia gracza. Dla harmonogramów użyłem dwóch dokładnych sposobów przeszukiwania. Dla kodów sprawdziłem wszystkie 6720 możliwych kombinacji.

Generator miał zapisane ziarno losowania, a prompty mają sumy SHA-256. Pozwala to odtworzyć dane i sprawdzić ich identyczność. Własna instancja nie dowodzi jednak, że model nigdy nie widział podobnej łamigłówki.

Sokoban: 33 kroki, ale różny czas dojścia do odpowiedzi

W pierwszej planszy trzeba było wykonać co najmniej 33 kroki gracza. W drugiej wystarczały 23. Liczyłem każde przejście po planszy, nie tylko pchnięcia. To rozróżnienie jest istotne: rozwiązanie z małą liczbą pchnięć nie musi mieć najkrótszej drogi gracza.

Oba tryby rozwiązały obie plansze optymalnie w obu powtórzeniach. W logach widać użycie skryptów przeszukujących przestrzeń stanów. Agent nie sterował tutaj myszką w komercyjnej grze. Otrzymał tekstowy zapis planszy i zwrócił sekwencję ruchów, którą odtworzył mój program.

Ten test mierzy więc zdolność dobrania i wykonania metody rozwiązania. Nie jest dowodem na refleks, rozpoznawanie obrazu ani sprawne sterowanie aplikacją.

Harmonogram: osiem zadań i tylko dwa procesory

Drugie zadanie przypomina planowanie pracy: część czynności musi czekać na zakończenie innych, a jednocześnie mogą działać najwyżej dwie. Agent miał podać start każdego zadania tak, aby całość skończyła się możliwie wcześnie.

W H1 optimum wynosiło 15 umownych jednostek czasu, w H2 wynosiło 14. To czas wewnątrz łamigłówki, nie liczba sekund pracy modelu. Walidator osobno sprawdzał wszystkie zależności i obciążenie procesorów. Różne poprawne harmonogramy otrzymywały taki sam punkt, jeśli osiągały optimum.

To dobry przykład ograniczenia mojego zestawu: przy ośmiu zadaniach znalezienie optimum było osiągalne dla obu ustawień. Remis nie mówi, co wydarzyłoby się przy setkach zależności i większej liczbie ograniczeń.

Kody: czasem właściwym wynikiem jest brak rozwiązania

Każdy pakiet zawierał cztery niezależne zagadki. Kod składał się z pięciu różnych cyfr ze zbioru od 0 do 7. Wskazówki określały liczbę cyfr na właściwych pozycjach oraz łączną liczbę wspólnych cyfr. Jedna zagadka w każdym pakiecie była sprzeczna: nie istniał kod spełniający wszystkie warunki.

W takim przypadku oczekiwałem odpowiedzi NONE. Próba dopasowania wiarygodnie wyglądającego kodu oznaczałaby błąd. Pełny punkt za pakiet wymagał czterech poprawnych rozstrzygnięć. Oba tryby spełniły ten warunek w obu powtórzeniach.

Wszystkie pomiary czasu, bez wybierania najlepszego podejścia

Mediana wyniosła 26,52 sekundy dla Wysokiego i 47,97 sekundy dla Ultra. Iloraz tych median to 1,81. Nie jest to średnia ilorazów poszczególnych par, dlatego udostępniam także każdy pomiar osobno.

Pułapka w tokenach: główna sesja to nie cała praca

Najbardziej użyteczne odkrycie dotyczyło rozliczenia. W badanych sesjach końcowy raport CLI odpowiadał licznikom głównego agenta. Pomocnicze sesje miały własne raporty. Gdybym zatrzymał się na głównej odpowiedzi, pominąłbym 444 971 zarejestrowanych tokenów Ultra.

Powiązałem potomków z próbami przez identyfikator sesji rodzica. W serii Wysokiego odnalazłem 0 pomocniczych agentów, w serii Ultra 12. Nie jest to gwarantowana liczba agentów dla tych ustawień, tylko obserwacja z moich logów.

Liczby Ultra są dolną granicą zarejestrowanego użycia. W jednej próbie nie mam potwierdzenia pełnego zakończenia wszystkich pomocniczych sesji. Zachowałem ich ostatni zapisany licznik, ale nie uznaję go za kompletny rachunek. Dotyczy to: S2-r1-ultra. Końcowe odpowiedzi głównego agenta były dostępne i podlegały zwykłej ocenie.

Tokenów cache nie doliczam do wejścia po raz drugi. Tokenów rozumowania nie dodaję drugi raz do wyjścia. Raportowane zero w tej ostatniej rubryce nie dowodzi, że model nie rozumował: pokazuję pole raportu, nie pomiar wewnętrznego procesu.

Sam wzrost wejścia bez cache wyniósł co najmniej 2,02 raza. To przydatne uzupełnienie sumy tokenów, bo wielokrotne czytanie podobnego kontekstu wpływa na licznik wejścia. Nadal nie przeliczam tego na złotówki ani procent abonamentu. Test działał przez dostęp Codexa, a licznik konta był współdzielony z innymi zadaniami. Odrębne przykłady kosztów API opisałem w tekście ile kosztuje dzień pracy z GPT-6 Astra.

Co poprawiłem po drodze

Pierwsza dostępna lokalnie wersja CLI nie obsługiwała Astry. Zainstalowałem aktualną wersję 0.153.4 w folderze testu. Później pilotaż ujawnił drugi problem: opcja wyłączająca zapis sesji blokowała delegowanie w Ultra. Cztery ukończone próby tego pilotażu i rozpoczęte kolejne uruchomienie wyłączyłem z serii głównej. Zapis błędu zachowałem.

Cały pomiar rozpoczął się od nowa z zapisem sesji. To korekta środowiska, nie odrzucenie słabego rozwiązania. Główne tabele obejmują wyłącznie 24 próby po poprawce, bez tokenów pilotażu, przygotowania materiałów i redakcji artykułu. Podaję ją, ponieważ bez tego wyjaśnienia wcześniejsze logi mogłyby wyglądać jak dodatkowe, przemilczane podejścia. Te same instancje były wcześniej użyte w pilotażu, co także mogło wpływać na cache; nie nazywam serii pomiarem na zimnej pamięci podręcznej.

Czego ten test nie rozstrzyga

Największe ograniczenie widać w tabeli: oba ustawienia dostały komplet punktów. Zestaw był za mały lub za łatwy, aby pokazać ewentualną przewagę jakościową Ultra. Zmierzył natomiast nakład potrzebny do uzyskania tego kompletu. To są dwa różne pytania.

Sześć instancji nie reprezentuje wszystkich zadań użytkownika. Nie badałem długich projektów programistycznych, pracy na dużym repozytorium, analizy wielu dokumentów ani gier wymagających reakcji w czasie rzeczywistym. Nie izolowałem również obciążenia usługi po stronie dostawcy. Zmieniona kolejność pomaga, ale nie usuwa wszystkich czynników wpływających na czas.

Wszystkie zadania przygotował i obsłużył agent AI. Uczciwiej mówić o audycie dwóch ustawień narzędzia niż o ślepym badaniu niezależnego laboratorium. Dlatego udostępniam dane i kod sprawdzania. Czytelnik może zakwestionować dobór problemów albo uruchomić własny zestaw.

Kiedy włączyłbym Ultra po tym eksperymencie?

Dla krótkiego zadania z jasnym warunkiem poprawności zacząłbym od Wysokiego i sprawdził wynik. W moim zestawie wyższe ustawienie nie poprawiło odpowiedzi, a zwiększyło czas i zarejestrowane użycie.

Ultra warto osobno sprawdzić na pracy, którą da się sensownie podzielić: kilku niezależnych analizach, dużym przeglądzie kodu lub wielu źródłach. Taką rolę wskazuje dokumentacja producenta. Mój obecny wynik nie jest jeszcze pomiarem tych zastosowań. Opis agentów pomocniczych.

Najrozsądniejszy następny krok to trudniejszy zestaw, na którym Wysoki zacznie popełniać błędy. Dopiero wtedy można zmierzyć, czy dodatkowy czas i tokeny Ultra kupują wyższą poprawność. Nie zmieniam jednak obecnych zadań po obejrzeniu wyniku i nie dopisuję nowych prób do tej samej tabeli.

Zrzuty kart z rzeczywistymi odpowiedziami

Poniższe ilustracje to zrzuty lokalnych kart wyników, wygenerowanych z odpowiedzi końcowych pierwszego powtórzenia. Nie przedstawiają interfejsu Codexa. Pełne dane obejmują również drugie powtórzenie.

Sprawdź odpowiedzi i pobierz dane

• Pełny pakiet danych, logów i kodu do odtworzenia testu (ZIP).
• Wszystkie wyniki w CSV.
• Wyniki z odpowiedziami i audytem tokenów w JSON.
• Zadania bez odpowiedzi wzorcowych.
• Zadania z rozwiązaniami i minimalnymi wynikami.
• Protokół i jawne korekty.
• Sumy kontrolne danych.

W pakiecie znajdują się również logi zdarzeń z czasem, końcowe odpowiedzi i kod generatora oraz walidatorów. Film pokazuje wizualizację odpowiedzi i przebiegu na podstawie logów, z oznaczeniem tego na ekranie. Nie przedstawiam jej jako nagrania sterowania pulpitem.

Krótkie odpowiedzi

Czy Ultra to osobny model?

W tym porównaniu identyfikator modelu pozostawał taki sam: gpt-6-astra. Zmieniłem ustawienie wysiłku. Sesje Ultra uruchamiały pomocniczych agentów, co uwzględniłem w rozliczeniu.

Czy Ultra było dokładniejsze?

W moim zestawie nie: oba ustawienia osiągnęły 12/12. Mały zestaw zakończony kompletem punktów nie rozstrzyga przewagi przy trudniejszych zadaniach.

Czy Ultra kosztuje ponad trzy razy więcej?

Zmierzony wzrost dotyczy zarejestrowanych tokenów wejścia i wyjścia, nie rachunku. Cache, sposób rozliczenia dostępu i niepełne zamknięcie części pomocniczych sesji wymagają osobnego traktowania.

Czy to test gry ze Steam lub przechodzenia CAPTCHA?

Nie. To własne zadania tekstowe z możliwością użycia narzędzi. Plansze i harmonogramy na ilustracjach odtwarzają odpowiedzi zapisane w logach. Test sterowania prawdziwą grą wymaga osobnego pomiaru.