Jak OpenAI rozwiązało problem opóźnień w głosowym AI na masową skalę

OpenAI opublikowało szczegółowy techniczny opis tego, jak przeprojektowało swoją infrastrukturę WebRTC, by głosowe AI działało bez zauważalnych opóźnień – i to dla milionów użytkowników jednocześnie. To nie jest kolejny press release o nowym modelu. To rzadki przypadek, gdy wielka firma pokazuje, co dzieje się pod maską.

Jeśli kiedykolwiek rozmawiałeś z ChatGPT w trybie głosowym i miałeś wrażenie, że odpowiada niemal natychmiast – to nie przypadek. Za tym stoi architektura, którą OpenAI musiało zbudować od zera, bo gotowych rozwiązań po prostu nie było.

WebRTC – stary standard, nowe wyzwania

WebRTC to otwarty standard służący do przesyłania audio, wideo i danych między przeglądarkami, aplikacjami mobilnymi i serwerami z minimalnym opóźnieniem. Technologia istnieje od lat – Discord, Google Meet, setki innych aplikacji z niej korzystają. Problem w tym, że nikt wcześniej nie musiał łączyć jej z wnioskowaniem dużych modeli językowych w czasie rzeczywistym, obsługując ruch globalny.

Zespół odpowiedzialny za interakcje w czasie rzeczywistym przeprojektował stos WebRTC, by zmierzyć się z trzema ograniczeniami naraz: modelem „jeden port UDP na sesję” (który nie pasuje do infrastruktury OpenAI), potrzebą stabilnego zarządzania sesjami ICE i DTLS oraz wymogiem utrzymania niskiego opóźnienia pierwszego przeskoku w skali globalnej.

Brzmi technicznie? Bo jest. Ale konsekwencje są bardzo konkretne.

Skąd bierze się poczucie „żywej” rozmowy

Kluczowy insight, który OpenAI opisuje w swoim wpisie, dotyczy tego, czym głosowe AI różni się od tradycyjnych asystentów głosowych opartych na schemacie: nagraj – prześlij – przetworz – odpowiedz.

W głosowym AI opartym na strumieniowaniu audio, model może zacząć transkrybować, wnioskować, wywoływać narzędzia czy generować mowę, jeszcze zanim użytkownik skończy mówić. To różnica między systemem, który sprawia wrażenie konwersacji, a systemem, który działa jak walkie-talkie.

To zdanie warto zapamiętać. Właśnie dlatego Advanced Voice Mode w ChatGPT czuje się inaczej niż Siri sprzed pięciu lat.

Architektura, która działa w Kubernetes

OpenAI zdecydowało się na rozwiązanie, które firma nazywa „split relay plus transceiver” – brzmi skomplikowanie, ale sens jest prosty: rozdzielono miejsce, w którym pakiety trafiają do infrastruktury (edge), od miejsca, gdzie faktycznie odbywa się przetwarzanie przez model.

Takie podejście pozwala uruchamiać media WebRTC w Kubernetes bez otwierania tysięcy portów UDP. Mniejsza i stała powierzchnia UDP jest łatwiejsza do zabezpieczenia i load balancowania, a infrastruktura może skalować się bez rezerwowania dużych publicznych zakresów portów.

Implementacja oparta jest na Go z kilkoma kluczowymi decyzjami projektowymi:

• wstępnie alokowane bufory i minimalne kopiowanie danych, by ograniczyć narzut garbage collectora
• wykorzystanie SO_REUSEPORT i przypinania wątków dla lepszej wydajności na poziomie systemu operacyjnego
• pominięcie kernel bypass (np. DPDK) – bo nie było takiej potrzeby

Ta implementacja obsłużyła globalny ruch mediów w czasie rzeczywistym przy relatywnie małym footprincie relay, dlatego OpenAI zachowało prostszą wersję zamiast sięgać po bardziej złożone rozwiązania.

Komentarz redakcji

Rzadko zdarza się, by firma tej rangi pokazywała tak techniczny opis swojej infrastruktury – i to jest samo w sobie wartościowe. Przejrzystość w branży AI to wciąż rzadkość. Ale warto zadać sobie pytanie: dlaczego OpenAI to publikuje akurat teraz? Dokumenty techniczne to również sygnał dla rynku – „patrzcie, jak głęboko to robimy”. Z jednej strony, opis architektury WebRTC to uczciwa wiedza dla deweloperów budujących na Realtime API. Z drugiej – to też element wizerunkowy, sposób na pokazanie, że za ChatGPT stoi coś więcej niż dobry model. Mnie bardziej interesuje pytanie o granicę między „czujemy się jak rozmowa” a „jesteśmy rozmową”. Bo opóźnienie na poziomie niewidocznym dla ucha to jedno – ale co z jakością rozumienia kontekstu, emocji, przerywania? Infrastruktura jest tylko fundamentem. Budynek dopiero powstaje.

Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl

Kto za tym stoi

OpenAI nie zbudowało tego w próżni. Fundamentalne prace Justina Ubertiego, jednego z oryginalnych architektów WebRTC, oraz Seana DuBoisa, twórcy i opiekuna biblioteki Pion, umożliwiły zespołom budowanie na sprawdzonej infrastrukturze mediów zamiast wymyślania transportu, szyfrowania i kontroli przeciążenia od zera. Obaj są teraz pracownikami OpenAI.

To szczegół, który mówi coś ważnego o strategii firmy: zamiast licencjonować lub integrować zewnętrzne rozwiązania, OpenAI zatrudnia ludzi, którzy je stworzyli. Kontrola nad całym stosem – od modelu po UDP.

Co to oznacza dla deweloperów

Realtime API, które OpenAI udostępnia deweloperom, jest bezpośrednim owocem tej architektury. Tysiące deweloperów buduje z wykorzystaniem tego API od czasu jego premiery w publicznej becie – a firma optymalizowała je pod kątem niezawodności, niskich opóźnień i wysokiej jakości, by umożliwić wdrożenia produkcyjne agentów głosowych.

Dla tych, którzy budują aplikacje głosowe, lista kluczowych możliwości wygląda dziś tak:

• strumieniowanie audio „mowa-do-mowy” bez pośrednich etapów transkrypcji
• obsługa przerywania rozmowy (jak w naturalnej konwersacji)
• wywoływanie narzędzi w tle, podczas gdy model kontynuuje mówienie
• globalne trasowanie z niskim opóźnieniem pierwszego przeskoku

Firma Genspark przetestowała model w warunkach dwujęzycznego tłumaczenia i inteligentnego routingu intencji – opóźnienie okazało się bliskie zeru, przy zachowaniu precyzji rozpoznawania intencji nawet w szybkich wymianach zdań.

Infrastruktura jako przewaga konkurencyjna

Wpis OpenAI jest ciekawy nie tylko technicznie. To sygnał, że wyścig o głosowe AI toczy się nie tylko na poziomie modeli, ale też infrastruktury. Google, Meta, Anthropic – wszyscy budują swoje wersje konwersacyjnych agentów głosowych. Ale jak zauważa OpenAI, większość sesji to połączenia punkt-do-punktu, wrażliwe na opóźnienia, łatwiejsze do skalowania gdy serwisy inferencyjne nie muszą zachowywać się jak pełnoprawne węzły WebRTC.

Innymi słowy: uproszczenie architektury było celowym wyborem, nie kompromisem. I to właśnie takie decyzje projektowe budują długoterminowe przewagi – niewidoczne dla użytkownika, ale fundamentalne dla tego, czy produkt w ogóle działa.