Jak w sześć miesięcy zbudowaliśmy system czasu rzeczywistego dla responsywnej głosowej AI

W przypadku głosowej AI ustalenie, kiedy należy się odezwać, jest trudniejsze, niż mogłoby się wydawać. Ludzie bez wysiłku przekazują sobie głos w ułamku sekundy, ale wcześniejsze systemy głosowej AI nie nadążały za tym rytmem. Ich architektura oparta na turach wykorzystywała małe modele zwane detektorami tur. Miały one niewdzięczne zadanie: decyzja podjęta zbyt wcześnie przerywała użytkownikowi, a zbyt późna powodowała, że odpowiedź wydawała się opieszała. Dopiero po podjęciu decyzji przez detektor znacznie większy LLM mógł rozpocząć pracę.

GPT‑Live⁠, nasz system głosowy trzeciej generacji, usuwa detektor tur ze ścieżki dźwięku. Jego model głosowy działa w trybie pełnego dupleksu, czyli może jednocześnie słuchać i mówić. Eliminuje to potrzebę osobnego detektora i sprawia, że rozmowa jest bardziej bezpośrednia i naturalna. Gdy potrzebne jest głębsze rozumowanie lub użycie narzędzi, GPT‑Live może bez przerywania rozmowy skorzystać z naszych pionierskich modeli, takich jak GPT‑5.5. Razem te możliwości zapewniają GPT‑Live bezprecedensowe połączenie szybkiej reakcji w rozmowie i inteligencji.

Zapewnienie takiego działania na dużą skalę wymagało nowej architektury systemu zoptymalizowanej pod kątem małych opóźnień. W przeciwieństwie do typowego wnioskowania w modelu żądanie–odpowiedź nasz system przesyła strumieniowo przychodzący dźwięk do modelu głosowego, a generowaną mowę z powrotem do użytkownika. Delegowanie odbywa się osobną ścieżką asynchroniczną. W ciągu ostatnich sześciu miesięcy przebudowaliśmy wnioskowanie modelu, zarządzanie kontekstem i transport multimediów, aby mowa płynnie przepływała przez cały system.

Architektura wyznacza również wyraźną granicę między główną ścieżką głosową a logiką aplikacji. Dzięki temu można łatwo dostosowywać działanie aplikacji bez wpływu na szybkość reakcji. Ta podstawa napędza coraz więcej funkcji ChatGPT Voice, w tym niedawno wprowadzoną możliwość sterowania komputerem i koordynowania agentów w aplikacji ChatGPT na komputer.

W tym artykule wyjaśnimy, dlaczego wcześniejsze systemy oparte na turach nie spełniały naszych potrzeb i jak zaprojektowaliśmy nowy system, aby szybko reagował w każdej warstwie. Omówimy wnioskowanie stanowe, dynamiczne zarządzanie kontekstem, asynchroniczne delegowanie i optymalizację na poziomie protokołu — elementy, dzięki którym GPT‑Live naprawdę działa na żywo.

Wcześniejsze architektury głosowe odziedziczyły po tekstowych LLM-ach podział na tury, ale każdą z nich reprezentowała osobna porcja dźwięku zamiast tekstu. W systemach kaskadowych moduły zamiany mowy na tekst, LLM i zamiany tekstu na mowę działały kolejno. Taka sekwencja zwiększała opóźnienie i pomijała sygnały, takie jak ton głosu czy tempo wypowiedzi.

Modele głos na głos udoskonaliły to podejście, przetwarzając dźwięk bezpośrednio. Nauczenie modelu bezpośredniego rozumienia i generowania mowy pozwoliło zachować szczegóły tracone podczas transkrypcji oraz szybciej odpowiadać. System nadal jednak polegał na detektorze tur, który decydował, kiedy można rozpocząć wnioskowanie. Model obsługiwał większą część interakcji, ale nadal była ona podzielona na tury.

GPT‑Live oddaje modelowi głosowemu kontrolę nad rozmową: dźwięk przepływa do modelu i z niego, a głębsze rozumowanie i użycie narzędzi odbywają się asynchronicznie. Głównym zadaniem systemu jest utrzymanie nieprzerwanej pętli multimedialnej. Inne zadania, takie jak wywoływanie pionierskich modeli i trwałe zapisywanie rozmowy, odbywają się poza ścieżką działającą na żywo.

Utrzymanie nieprzerwanej pętli multimedialnej nie zawsze jest łatwe. Każde opóźnienie transportu, przetwarzania lub wnioskowania może spowodować słyszalną przerwę albo zakłócenie. Wcześniejszy system oparty na turach tolerował pewne różnice w czasie nadejścia porcji dźwięku. System multimedialny działający na żywo musi jednak dostarczać każdą ramkę dźwięku na czas.

Wcześniejsze prace nad ChatGPT Voice i Realtime API dały nam ważne podstawy. Wcześniej przebudowaliśmy już naszą infrastrukturę głosową⁠, aby bezpośrednio przesyłać strumieniowo dźwięk i obraz do naszych systemów i z nich, z mniejszym i bardziej przewidywalnym opóźnieniem. GPT‑Live rozwinął ten projekt: multimedia są przesyłane strumieniowo aż do modelu za pośrednictwem nowego, stanowego systemu wnioskowania stworzonego z myślą o ciągłej rozmowie.

Wnioskowanie strumieniowe było jednak tylko częścią rozwiązania. Aby system dobrze działał w środowisku produkcyjnym, musieliśmy również zapewnić niezawodne dostarczanie dźwięku od klienta do stosu wnioskowania i rozwiązać problemy związane ze stanowością.

Jedną z pierwszych decyzji było wyraźne oddzielenie przepływu multimediów od logiki aplikacyjnej i biznesowej. Dźwięk przemieszcza się między klientem a modelem głosowym dedykowaną szybką ścieżką. Delegowanie, użycie narzędzi i inne zadania aplikacji odbywają się za asynchroniczną granicą RPC. Powolne wywołanie narzędzia lub usługi backendowej może opóźnić własny wynik, ale nie zatrzyma przepływu multimediów.

Ten podział wyznacza również wyraźną granicę dostosowywania systemu. Aplikacje mogą zmieniać narzędzia, zasady i działanie backendu bez wpływu na frontend multimedialny, który odpowiada za nieprzerwany przepływ dźwięku. Ścieżka działająca na żywo pozostaje niewielka, przewidywalna i skupiona na zadaniach, które muszą być wykonywane w czasie rzeczywistym.

Frontend multimedialny i logikę wnioskowania napisaliśmy w Go, zastępując wcześniejszą implementację w Pythonie opartą na asyncio. Znacznie poprawiło to płynność dostarczania ramek: wartość p95 nowego systemu odpowiada wartości p50 poprzedniego.

Podstawę warstwy transportowej stanowi WebRTC. Zaprojektowano go z myślą o multimediach o niskich opóźnieniach. Może działać mimo utraty pakietów, dryfu zegara i zmian połączenia klienta. Jeśli pakiety dotrą z opóźnieniem, WebRTC może nieznacznie rozciągnąć dźwięk, aby zapobiec przerwom, a następnie na krótko przyspieszyć odtwarzanie, by wrócić do czasu rzeczywistego.

Ograniczając buforowanie i blokowanie w całym systemie, możemy zapewnić czas reakcji poniżej sekundy, którego ludzie oczekują od rozmowy.

Wnioskowanie stanowe wiąże się z własnymi kompromisami operacyjnymi. Sesja głosowa może pozostawać aktywna przez długi czas, ale jej kontekst stale rośnie, a instancje modelu są uruchamiane i wyłączane zależnie od zapotrzebowania.

Aby rozwiązać te problemy, stworzyliśmy mechanizm płynnego przełączania między instancjami modelu. Gdy konieczna jest zmiana, możemy rozgrzać zastępczą instancję modelu obok dotychczasowej, wstępnie wypełnić ją bieżącym kontekstem sesji, równolegle prowadzić wnioskowanie w obu instancjach, a następnie przełączyć się, gdy nowa będzie w pełni gotowa.

Ten sam podstawowy mechanizm obsługuje również dynamiczne kompaktowanie kontekstu. W miarę trwania rozmowy nagromadzony kontekst może w końcu przekroczyć limit kontekstu modelu. Kompaktowanie może zmniejszyć kontekst do rozmiaru mieszczącego się w limicie, ale operacja ta wymaga czasu. Ponieważ zmienia wcześniejszy kontekst, unieważnia również pamięć podręczną klucz-wartość (KV) modelu, w której przechowywane są klucze i wartości uwagi z przetworzonych wcześniej tokenów. Odbudowa tego stanu wymaga ponownego wstępnego wypełnienia, co powoduje dodatkowe opóźnienie.

Zamiast tego traktujemy kompaktowanie jako kolejne kontrolowane przejście. Gdy pierwotna instancja modelu kontynuuje rozmowę, system kompaktuje kontekst i przygotowuje instancję zastępczą z nowym kontekstem. Kiedy nowa instancja jest gotowa, możemy się na nią przełączyć bez przerywania transmisji multimediów. Dzięki temu system obsługuje długie rozmowy i kompaktuje kontekst zawsze, gdy jest to konieczne.

Najcięższe zadania pozostają poza ścieżką działającą na żywo, dlatego nawet podczas przełączania rozmowa ani na chwilę nie traci rytmu.

Możliwość wywoływania przez GPT‑Live istniejących pionierskich modeli daje mu ogromne możliwości, skutecznie oddzielając „mówienie” od głębszego „myślenia”. Aby jednak ta architektura złożona z dwóch modeli sprawiała wrażenie jednego systemu, musieliśmy rozwiązać dwa powiązane problemy inżynieryjne.

Po pierwsze, wyniki muszą wracać dostatecznie szybko, by przydały się w trwającej rozmowie. Musieliśmy więc ograniczyć opóźnienia na całej ścieżce delegowania — od routingu i przetwarzania polecenia po wnioskowanie i wywołania narzędzi. Jednocześnie inne systemy w produkcie nadal potrzebują odrębnych wiadomości, dlatego musieliśmy przedstawić trwającą rozmowę w zrozumiałej dla nich formie.

Po zleceniu delegowania optymalizujemy czas do chwili, gdy pionierski model wygeneruje coś przydatnego w rozmowie. Model głosowy może przez chwilę podtrzymywać rozmowę, gdy pionierski model prowadzi rozumowanie lub używa narzędzi, ale nie zdoła ukryć dowolnie długiego oczekiwania na odpowiedź. Dlatego całą pętlę delegowania — routing, przetwarzanie polecenia, wnioskowanie i wywołania narzędzi — uwzględniliśmy w budżecie czasu reakcji.

Pierwsza optymalizacja polega na przygotowaniu pionierskiego modelu i potrzebnych mu narzędzi, zanim pojawi się żądanie delegowania. Po rozpoczęciu sesji głosowej serwer aplikacji tworzy sesję wnioskowania pionierskiego modelu i wstępnie wypełnia ją początkowym kontekstem rozmowy. Dzięki temu polecenie jest w pełni przetworzone jeszcze przed pierwszym delegowanym żądaniem.

Następnie utrzymujemy tę sesję wnioskowania przez całą rozmowę głosową i stosujemy stabilne koligacje sesji przy kolejnych żądaniach. W połączeniu z buforowaniem poleceń techniki te zmniejszają opóźnienia, a jednocześnie pozwalają łatwo odzyskać sprawność po awarii procesu roboczego.

Na czas uzyskania użytecznego wyniku wpływają też nakład na rozumowanie, limity odpowiedzi, schematy narzędzi i komunikacja między modelem a narzędziami. Dostosowaliśmy te parametry, aby przyspieszyć odpowiedzi. Ograniczając ilość pracy na ścieżce delegowania, umożliwiliśmy modelowi głosowemu szybkie wykorzystywanie wyników naszych pionierskich modeli.

Chociaż model głosowy przetwarza ciągłe strumienie mowy, wiele otaczających go systemów nadal działa na turach użytkownika i asystenta. Dotyczy to między innymi interfejsu rozmowy ChatGPT oraz części naszej infrastruktury analitycznej i bezpieczeństwa. Serwer aplikacji rozdziela więc nakładającą się, niekiedy niejednoznaczną rozmowę na odrębne wiadomości.

W miarę napływania dźwięku serwer wykorzystuje częściowe transkrypcje i sygnały czasowe, aby ustalić, kto mówi, i tworzyć kolejkę wiadomości. Najnowsza wiadomość pozostaje tymczasowa — jej tekst, czas i przypisanie do mówcy mogą się zmieniać wraz z napływem kolejnych wypowiedzi. Gdy dana osoba mówi wystarczająco długo, by można było wiarygodnie przypisać jej wypowiedź, serwer zatwierdza odpowiednią wiadomość.

Nakładanie się głosów dodatkowo komplikuje sytuację. Krótkie potwierdzenie asystenta, gdy mówi użytkownik (np. „mm hmm” lub „okay”), nie zawsze powinno stać się osobną wiadomością. Istotne wtrącenie asystenta często powinno jednak zostać wyodrębnione. Podobnie dbamy o spójność wyświetlanych odpowiedzi asystenta, nawet gdy użytkownik zaczyna mówić w ich trakcie.

Każda metoda segmentacji wymaga kompromisu między aktualnością a pewnością. Zbyt wczesne zatwierdzanie prowadzi do fragmentarycznej historii i niestabilnej kolejności. Zbyt długie oczekiwanie opóźnia transkrypcje i zależne od nich funkcje. System utrzymuje więc dwa powiązane obrazy rozmowy: wstępny obraz bieżącego stanu oraz ostateczny zapis tego, co powiedziano. Widok rozmowy w interfejsie aplikacji obsługuje aktualizacje, dlatego korzysta z obrazu wstępnego. Zapisywanie danych w potoku analitycznym wymaga jednak ostatecznej transkrypcji.

Dzięki temu pozostałe elementy ChatGPT otrzymują stabilny obraz rozmowy bez narzucania podziału na tury ścieżce głosowej działającej na żywo.

Szybka reakcja zaczyna się już w chwili, gdy użytkownik klika przycisk. W GPT‑Live system musi ustanowić ścieżkę multimedialną i zacząć przekazywać dźwięk przez model, zanim rozpocznie się rozmowa. Dlatego każdy element sekwencji uruchamiania znajduje się na ścieżce krytycznej.

Jak wspomnieliśmy wcześniej, WebRTC zapewnia solidną podstawę komunikacji w czasie rzeczywistym, ale rozpoczęcie standardowej sesji WebRTC wymaga zaskakująco wielu uzgodnień protokołów i cykli komunikacji sieciowej. WebRTC powstał przed upowszechnieniem podejścia skupionego na ograniczaniu liczby cykli komunikacji, które ukształtowało późniejsze protokoły, takie jak QUIC. W rezultacie jego protokoły bazowe używane razem czasami powtarzają te same czynności. Na przykład każdy protokół zawierał własny mechanizm ochrony przed atakami DoS, nawet gdy nie był on potrzebny w kontekście całego stosu WebRTC.

Przeanalizowaliśmy stos i opracowaliśmy protokół WebRTC Abridged Roundtrip Protocol (WARP⁠(otwiera nowe okno)), który skraca uruchamianie transmisji multimediów i danych z sześciu cykli komunikacji sieciowej do zaledwie jednego. WARP osiąga to dzięki zestawowi wstecznie zgodnych usprawnień protokołów: dołączeniu uzgadniania DTLS do ICE (SPED⁠(otwiera nowe okno)), zastosowaniu szybszego uzgadniania DTLS 1.3⁠(otwiera nowe okno), wstępnemu uzgadnianiu SCTP (SNAP⁠(otwiera nowe okno)) oraz wstępnemu uzgadnianiu kanałów danych zamiast korzystania z DCEP⁠(otwiera nowe okno).

Zaprojektowaliśmy WARP jako zestaw otwartych specyfikacji, współpracując z członkami społeczności WebRTC, aby z efektów tych prac mógł korzystać cały ekosystem. Rozwijamy te propozycje w grupie roboczej TSVWG organizacji IETF. Obsługę WARP dodano już do libwebrtc i Pion, a prace trwają również w innych implementacjach WebRTC.

Po zoptymalizowaniu uzgadniania multimediów wyróżniało się jeszcze jedno opóźnienie: wymiana sygnalizacyjna służąca do przekazania parametrów SDP, zanim WebRTC może nawiązać połączenie. Aby usunąć tę wymianę ze ścieżki krytycznej, opracowaliśmy rozwiązanie nazwane Instant Connect. Uzgadnia ono parametry z wyprzedzeniem, bez rezerwowania zasobów serwera i bez wprowadzania zmian w istniejących implementacjach WebRTC.

Instant Connect działa równolegle ze standardowym przepływem sygnalizacyjnym. Jeśli wstępnie uzgodnione parametry są prawidłowe, serwer może utworzyć sesję po nadejściu pierwszego pakietu multimedialnego. Jeśli parametry są nieaktualne lub nieprawidłowe, przepływ sygnalizacyjny już trwa, więc klient może przejść na rozwiązanie rezerwowe bez dodatkowego opóźnienia.

Instant Connect i WARP wspólnie radykalnie skracają czas od zamiaru użytkownika do rozpoczęcia transmisji multimediów na żywo. Dzięki usunięciu wymiany SDP ze ścieżki krytycznej i skróceniu uzgadniania transportu przez WARP klient może teraz rozpocząć sesję jednym pakietem UDP. Serwer może odpowiedzieć natychmiast, dzięki czemu reszta systemu zaczyna robić to, na czym rzeczywiście zależy użytkownikowi: słuchać i odpowiadać.

System może na papierze wydawać się szybki, a mimo to zacinać się przy rzeczywistym ruchu głosowym. Zanim umożliwiliśmy GPT‑Live rozmowy z użytkownikami, przeprowadziliśmy cichy test: niewielką, stopniowo zwiększaną część produkcyjnych sesji ChatGPT Voice kierowaliśmy równocześnie do dotychczasowego zaawansowanego trybu głosowego i naszego nowego systemu. Zaawansowany tryb głosowy nadal obsługiwał użytkowników jak zwykle, a ścieżka cieniowana wykonywała wnioskowanie w trybie tylko do odczytu. Dzięki temu system miał styczność z rzeczywistymi klientami, sieciami, czasem trwania sesji i rozkładem geograficznym, lecz użytkownicy nadal słyszeli to samo.

Jednym z pierwszych wniosków było to, że wydajności systemu nie można sprowadzać do przepustowości procesorów GPU. Sesje głosowe pozostają otwarte i stale przesyłają ramki, dlatego obsługiwane przez CPU strumienie, kolejki i ścieżki sieciowe muszą skalować się wraz z wnioskowaniem. Przy rzeczywistym obciążeniu jeden z komponentów pomocniczych osiągnął granicę wydajności wcześniej, niż wskazywały testy obciążeniowe. Żądania wnioskowania zaczęły się kumulować, a opóźnienia narastać. Zmieniliśmy więc pytanie o wydajność z „Ile żądań może obsłużyć GPU?” na „Ile równoczesnych sesji może obsłużyć system, dostarczając każdą ramkę na czas?”

Test wykazał też, że położenie geograficzne ma kluczowe znaczenie. Skierowanie sesji do odległego centrum przetwarzania może zwiększyć opóźnienie na kilku etapach uruchamiania i strumieniowania. Zaczęliśmy weryfikować wdrożenia modeli wraz z regionalną wydajnością i konfiguracją sterowania ruchem, a następnie analizować opóźnienia według lokalizacji źródłowej. Przeniesienie wnioskowania bliżej użytkowników pomogło, ale potwierdziło też ogólniejszy wniosek: szybkość reakcji całego systemu zależy od każdej usługi na ścieżce, a nie tylko od serwera modelu.

Inne awarie ujawniały się dopiero podczas realistycznych cykli życia sesji. Długotrwałe sesje ujawniły problemy z pamięcią i trwałym zapisem danych. Ponowne połączenia poddawały próbie kompaktowanie i odtwarzanie stanu. Zwykłe rozłączenia klientów ujawniły wyścigi podczas uzgadniania zamknięcia. Problemy te rzadko występowały w krótkich testach obciążeniowych, ponieważ zależały od czasu, nagromadzonego stanu i zachowania na granicach usług.

Testy produkcyjne zmusiły nas również do poprawy obserwowalności i mechanizmów kontroli wdrożeń. Znaleźliśmy metryki łączące różne źródła opóźnień, pulpity, na których wartości zagregowane ukrywały niesprawne instancje, oraz rozbieżności konfiguracji między systemami testowanymi a wdrożonymi. W odpowiedzi dodaliśmy bardziej szczegółową telemetrię, weryfikację względem sprawdzonych konfiguracji, etapowe zwiększanie ruchu oraz możliwość szybkiego izolowania lub wyłączania poszczególnych ścieżek. Cichy test stał się wczesną próbą generalną przed premierą. Sprawdzaliśmy nie tylko, ile ruchu system może przyjąć, ale też jak szybko potrafimy wykryć i opanować awarię oraz przywrócić działanie.

Wprowadzenie GPT‑Live na skalę ChatGPT wymagało stworzenia zupełnie nowego systemu opartego na jednej podstawowej zasadzie: głos musi płynąć bez przerw. Wnioskowanie strumieniowe stale dostarcza dźwięk do modelu działającego w trybie pełnego dupleksu. Dedykowana ścieżka multimedialna zapewnia niezawodne dostarczanie ramek. Asynchroniczne delegowanie pozwala równolegle prowadzić bardziej złożone rozumowanie. Zoptymalizowany transport zapewnia szybką reakcję systemu na całej drodze do użytkownika.

Architektura GPT‑Live już staje się szerszą platformą interakcji w czasie rzeczywistym. Napędza ChatGPT Voice, który wykracza poza rozmowę i obejmuje koordynację agentową, a także będzie podstawą nadchodzącego interfejsu API GPT‑Live. Z czasem pozwoli udostępniać funkcje głosowe na większej liczbie urządzeń, w większej liczbie aplikacji i modalności, bez utraty bezpośredniości, dzięki której rozmowa głosowa sprawia wrażenie prowadzonej na żywo.

Jeśli chcesz rozwiązywać takie problemy inżynieryjne, dołącz do nas⁠.