Jak GPT‑5.6 łączy pionierską inteligencję z pionierską wydajnością

Rodzinę modeli GPT‑5.6 zaprojektowaliśmy tak, aby równoważyła możliwości i koszt w całym spektrum zadań, do których użytkownicy wykorzystują nasze modele. Nasz model podstawowy GPT‑5.6 Sol, przy poziomie rozumowania Maks, przewyższa Claude Fable 5 w rankingu Artificial Analysis Coding Agent Index, kosztując mniej niż połowę jego ceny. Terra dorównuje GPT‑5.5 w testach inteligencji przy dwukrotnie niższej cenie, a Luna to nasz najszybszy i najtańszy model, którego cena jest o 80% niższa niż cena Sol. Aby osiągnąć taką wydajność, nasze zespoły badawcze i techniczne wprowadziły znaczące optymalizacje we wszystkich głównych warstwach stosu. Ulepszenia te obejmują nasze modele, wnioskowanie (sposób uruchamiania modeli w celu generowania wyników) oraz otoczenie operacyjne agentów używane zarówno przez Codex, jak i ChatGPT Work.

W ciągu ostatnich czterech lat rozszerzyliśmy skalę działania naszych modeli do miliarda aktywnych użytkowników i ponad 2 milionów firm. Wydajność miała kluczowe znaczenie dla udostępniania wszystkim korzyści płynących z inteligencji. Naszą misją jest zapewnienie, aby ogólna sztuczna inteligencja przynosiła korzyści całej ludzkości. Przez te lata stale poszukiwaliśmy kolejnych możliwości optymalizacji całego stosu, aby oferować najbardziej wydajne modele na każdym poziomie krzywej kosztu i inteligencji. Dzięki GPT‑5.6 osiągnęliśmy dotąd najwyższą wydajność inteligencji w przeliczeniu na token. Model ten wytrenowano tak, aby wykonywał więcej pracy na token. Podczas trenowania optymalizujemy zarówno skuteczność realizacji zadań, jak i wydajność, ucząc model wybierania bardziej bezpośredniej drogi do celu.

W tym artykule wychodzimy poza same modele i pokazujemy, jak zwiększyliśmy wydajność dzięki postępom w dwóch innych głównych obszarach stosu: 1) wnioskowaniu — optymalizując równoważenie obciążenia, dekodowanie spekulatywne, buforowanie i jądra obliczeniowe, aby uzyskiwać więcej wyników z tego samego sprzętu — oraz 2) otoczeniu operacyjnym agentów, między innymi dzięki lepszemu zarządzaniu nadmiarem kontekstu, użyciem narzędzi i powtarzaną pracą. Pokażemy też, jak GPT‑5.6 Sol autonomicznie przyczynił się do osiągnięcia kilku z tych korzyści. Choć każde pojedyncze ulepszenie może wydawać się niewielkie, ich efekty kumulują się, pozwalając nam wyznaczać pionierski poziom zarówno inteligencji, jak i wydajności.

W świecie ograniczonych zasobów obliczeniowych, gdzie zapotrzebowanie na modele rośnie szybciej niż dostępna moc, wydajność stanowi podstawę projektowania każdego systemu. Dotyczy to zwłaszcza naszego stosu wnioskowania, który uruchamia wytrenowane modele w celu generowania odpowiedzi. Naszym głównym celem jest obsługa większej liczby tokenów na tym samym sprzęcie przy zachowaniu oczekiwanych przez użytkowników poziomów inteligencji, opóźnień, dostępności i niezawodności.

Osiągnięcie tego celu wymaga optymalizacji całego systemu. Model może być bardzo wydajny w izolacji, a mimo to kosztowny w obsłudze, jeśli żądania są źle rozdzielane, sprzęt pozostaje bezczynny lub przesyłanie danych spowalnia obliczenia. Ulepszenia na każdej warstwie kumulują się. Korzyści wynikają z optymalizacji routingu (dokąd trafiają żądania), planowania (kiedy są wysyłane), jąder obliczeniowych (oprogramowania działającego na GPU), buforowania (zapisywania i ponownego wykorzystywania pracy) oraz implementacji modelu (kolejności wykonywania kodu na GPU). GPT‑5.6 Sol w Codex odegrał kluczową rolę we wszystkich tych optymalizacjach.

Pierwszym ważnym przykładem jest równoważenie obciążenia. W skali globalnej kierujemy żądania na podstawie takich czynników jak położenie geograficzne, dostępna moc oraz typ akceleratora (rodzaj GPU lub wyspecjalizowanego układu obsługującego model). W obrębie klastra rozdzielamy pracę między instancje modelu na podstawie obciążenia, długości kontekstu, dostępności pamięci podręcznej i innych właściwości żądania. W każdej instancji praca musi być następnie sprawnie rozdzielana między akceleratory, podsieci modelu i rdzenie obliczeniowe. GPT‑5.6 Sol w Codex pomaga nam analizować ruch produkcyjny, wykrywać wcześniej pomijane źródła nierównowagi, testować nowe strategie routingu i stale dostrajać te heurystyki. Już same ulepszenia równoważenia obciążenia znacznie obniżyły koszty obsługi naszych modeli.

Użyliśmy też GPT‑5.6 Sol do optymalizacji przebiegu w przód modelu, czyli obliczeń przekształcających dane wejściowe w przewidywania kolejnego tokenu. Nawet gdy poszczególne operacje przebiegają szybko, nadmierne przenoszenie danych w pamięci, synchronizacja i nieefektywny układ danych mogą pozostawiać procesory GPU bezczynne. Aby temu zapobiec, GPT‑5.6 Sol wskazał pracę, którą można było wykonać z wyprzedzeniem, pominąć lub zrównoleglić. Za pomocą Codex model GPT‑5.6 Sol autonomicznie przepisał i zoptymalizował nasze produkcyjne jądra obliczeniowe — podstawowy kod wykonujący operacje matematyczne składające się na działanie modelu. Było to możliwe między innymi dlatego, że wytrenowaliśmy GPT‑5.6 w skutecznym tworzeniu i ulepszaniu jąder obliczeniowych w językach Triton⁠(otwiera nowe okno) i Gluon⁠(otwiera nowe okno) — dwóch językach programowania GPU o otwartym kodzie źródłowym, rozwijanych przez OpenAI. Te działania, wraz z szerzej zakrojonymi ulepszeniami jąder obliczeniowych opracowanymi przez GPT‑5.6 Sol, obniżyły całkowite koszty obsługi o 20%. Dużo zainwestowaliśmy również w narzędzia weryfikacyjne, takie jak narzędzie open source FpSan⁠(otwiera nowe okno) (Floating-Point Sanitizer), które pomaga sprawdzać poprawność jąder obliczeniowych napisanych przez GPT‑5.6 Sol.

Dekodowanie spekulatywne to kolejny sposób na zwiększenie szybkości i wydajności. Technika ta polega na uruchomieniu mniejszego modelu roboczego (zwanego „spekulatorem”) równolegle z modelem głównym. Proponuje on kilka tokenów, które model główny weryfikuje jednocześnie. Po zaakceptowaniu tych propozycji system może wygenerować wiele tokenów wyjściowych w jednym przebiegu modelu głównego, ograniczając kosztowne obliczenia sekwencyjne. GPT‑5.6 Sol ulepszył własny model roboczy, projektując i przeprowadzając setki eksperymentów nad jego architekturą oraz testując zmiany rozmiaru, struktury i funkcji. Ponadto GPT‑5.6 Sol uruchomił i monitorował proces trenowania spekulatora, autonomicznie interweniując w razie problemów, takich jak awarie sprzętu i niestabilność trenowania. Uzyskane ulepszenia zwiększyły wydajność generowania tokenów o ponad 15%.

Podczas przetwarzania niebuforowanych tokenów wejściowych model tworzy pamięć podręczną klucz-wartość (KV) w jednym intensywnym obliczeniowo przebiegu, a podczas generowania danych wyjściowych wielokrotnie ją odczytuje i rozszerza. Optymalna konfiguracja obsługi — między innymi grupowanie żądań, fragmentacja i zarządzanie KV — w dużym stopniu zależy od obciążenia: długości polecenia i danych wyjściowych, wielkości partii, współczynnika trafień w pamięci podręcznej, właściwości zapytań i innych czynników. Wcześniej przestrzeń konfiguracji była jednak zbyt duża, by systematycznie ją dostrajać, więc inżynierowie musieli polegać na ogólnych heurystykach. Dzięki GPT‑5.6 Sol w Codex mogliśmy analizować obciążenia produkcyjne, generować i oceniać proponowane konfiguracje oraz precyzyjnie optymalizować ustawienia silnika i modelu dla każdego scenariusza. Pozwala to w praktyce osiągnąć nowy poziom optymalizacji dopasowanej do obciążenia i uzyskać więcej użytecznych wyników wnioskowania z tego samego sprzętu.

Optymalizacja wnioskowania to ciągła pętla informacji zwrotnej. Mierzymy działanie środowiska produkcyjnego, wskazujemy największe braki, wdrażamy zmiany i sprawdzamy, czy usprawniają cały system, a nie tylko pojedynczy test porównawczy. GPT‑5.6 Sol i Codex przyspieszają każdy etap tej pętli. Dzięki temu nasz zespół może badać więcej pomysłów, szybciej reagować na zmieniające się obciążenia i tworzyć stos wnioskowania, który zapewnia użytkownikom mniejsze opóźnienia, większą przepustowość i niższe koszty.

ChatGPT Work i Codex realizują złożone zadania za pomocą serii żądań do modelu i wywołań narzędzi. W ramach jednej tury — od żądania użytkownika po końcową odpowiedź — Codex może przejrzeć kod źródłowy, przeszukać historię wdrożeń, przeczytać raporty o incydentach, edytować plik i uruchomić testy. Każdy etap może wymagać osobnego żądania.

Przygotowanie kontekstu, przesyłanie danych, wnioskowanie, wywoływanie narzędzi i uruchamianie procesów wymagają czasu oraz mocy obliczeniowej. Jeśli zadanie wymaga 30 żądań do modelu, dodatkowa sekunda przy każdym z nich daje odczuwalne opóźnienie. Poprawa ogólnej wydajności wymaga ograniczenia powtarzanej pracy w całym systemie, a nie tylko przyspieszenia modelu.

Te zwielokrotniające się koszty wpłynęły na projekt naszego otoczenia operacyjnego agentów — warstwy orkiestracji napisanej w języku Rust, która łączy modele, narzędzia i środowisko użytkownika. Dalej wyjaśnimy, jak ograniczanie nadmiaru kontekstu, ładowanie narzędzi i ponowne wykorzystywanie wykonanej pracy zwiększają wydajność każdego żądania.

Gdy agenci uzyskują dostęp do większej liczby narzędzi, umiejętności, wtyczek i historii rozmów, okna kontekstu mogą szybko się rozrastać. Zwiększa to koszty, rozprasza model i wywołuje niepotrzebne rozumowanie. Otoczenie operacyjne może ograniczać ten narzut dzięki odroczonemu wykrywaniu, które udostępnia integracje, niestandardowe narzędzia MCP, umiejętności i wtyczki dopiero wtedy, gdy są potrzebne. Otoczenie operacyjne zapobiega też nieoczekiwanemu zajmowaniu okna kontekstu przez poszczególne narzędzia i integracje MCP. Domyślnie dane wyjściowe narzędzia są ograniczone do 10 000 tokenów, chyba że model zażąda innego limitu.

Jak już wspomniano, pętla agenta może w ramach jednej tury wielokrotnie przesyłać do procesorów GPU te same instrukcje, historię rozmowy, definicje narzędzi i wcześniejsze wyniki. Przetwarzanie tych powtarzających się danych wejściowych jest kosztowne, dlatego buforowanie poleceń ponownie wykorzystuje obliczenia związane z wcześniej przetworzonym prefiksem polecenia. Aby zachować ten prefiks, otoczenie operacyjne traktuje całą historię widoczną dla modelu jako przeznaczoną wyłącznie do dopisywania: nowe wiadomości, wyniki narzędzi i aktualizacje środowiska są dodawane na końcu, zamiast trafiać do wcześniejszego kontekstu. Narzędzia są również przedstawiane w deterministycznej kolejności, a ustawienia środowiska wykonawczego, takie jak zasady zatwierdzania, stosuje się podczas wykonywania zadań, zamiast osadzać je w definicjach narzędzi. Takie rozwiązanie przyczynia się do wysokiego ogólnego współczynnika trafień w pamięci podręcznej poleceń w Codex i ChatGPT Work.

Wzrost wydajności osiągnięty dzięki GPT‑5.6 jest efektem wieloletnich, kumulujących się ulepszeń całego stosu — od badań i wnioskowania po nasze otoczenie operacyjne agentów. Rola GPT‑5.6 we wdrożeniu wielu z tych ulepszeń pozwala nam z optymizmem patrzeć na dalsze przyspieszenie optymalizacji. Będziemy nadal intensywniej optymalizować między innymi jądra obliczeniowe, a także wprowadzać fundamentalne ulepszenia naszego stosu. Chcemy przekazywać użytkownikom i klientom korzyści z tych stale wprowadzanych ulepszeń technicznych w postaci szerzej dostępnej i bardziej opłacalnej inteligencji.

Specjalne podziękowania dla Matthew Ferrariego, Philippe’a Tilleta, Ahmeda Ibrahima, Joego Gershensona i Steve’a Coffeya z zespołu technicznego za ich wkład w ten artykuł.