OpenAI stworzyło GPT-Live, chatbota zorientowanego na głos, który słucha i mówi jednocześnie, rezygnując z topornych przerw typu „mów-potem-słuchaj”, z których korzysta większość asystentów. Usługa ma na celu zapewnienie rozmowy, która płynie niczym ludzki dialog, zamiast wymuszonych przerw.

Dlaczego stary model wydawał się wadliwy

Typowe asystenci głosowi działają jak krótkofalówki: kończysz zdanie, urządzenie nagrywa, wysyła dźwięk do chmury, czeka na odpowiedź, a następnie ją odtwarza. Ten pełny cykl (round-trip) wprowadza zauważalne opóźnienie i zmusza użytkowników do pauzy, zanim będą mogli przerwać wypowiedź. Dla pokolenia wychowanego na komunikatorach natychmiastowych, to opóźnienie wydaje się archaiczne.

OpenAI odpowiedziało architekturą bez podziału na tury (turn-less). W każdej sekundzie GPT-Live decyduje, czy nadal słuchać, czy nadal mówić, czy zrobić przerwę, co pozwala przerwać asystentowi w połowie odpowiedzi lub zadać pytanie uzupełniające bez czekania na pełny cykl odpowiedzi.

Stos full-duplex w prostych słowach

  1. Oddzielna pętla audio i ścieżka rozumowania – Szybka ścieżka (fast path) obsługuje ciągłą wymianę dźwięku, podczas gdy wolna ścieżka (slow path) wykonuje cięższe zadania, takie jak wyszukiwanie w sieci czy wywoływanie narzędzi. Szybka ścieżka podtrzymuje płynność rozmowy, podczas gdy wolna ścieżka pracuje, eliminując przerażający moment „ciszy podczas myślenia”.
  2. Protokół WARP – Tradycyjne połączenia internetowe wymagają wielu uzgodnień (handshakes) przed rozpoczęciem przesyłu dźwięku, często aż sześciu pełnych cykli (round-trips). Autorski protokół OpenAI skraca te kroki do jednego cyklu, dzięki czemu rozpoczęcie sesji wydaje się niemal natychmiastowe.
  3. Go zamiast Pythona dla stabilności opóźnień – Zespół przeniósł komponenty czasu rzeczywistego z Pythona, cenionego za szybkość rozwoju, do języka Go, który zapewnia bardziej przewidywalny czas wykonywania operacji. W głosowej sztucznej inteligencji opóźnienie w najgorszym możliwym scenariuszu jest ważniejsze niż średnia prędkość; pojedyncze zająknięcie niszczy imersję, dlatego liczy się stałe opóźnienie.
  4. Skalowanie poza GPU – Przy setkach milionów użytkowników wąskim gardłem przestały być rdzenie obliczeniowe modelu, a stała się nim otaczająca infrastruktura. OpenAI odkryło, że procesory CPU i łącza sieciowe nasycają się szybciej niż jednostki GPU, dlatego wprowadzono inteligentniejsze trasowanie i zarządzanie połączeniami, aby zapewnić stały dopływ danych do GPU, nie przeciążając reszty stosu technologicznego.

Co to oznacza dla programistów

  • Rozdziel obsługę audio od logiki biznesowej – Utrzymuj lekką, stale działającą pętlę, która przetwarza sygnał z mikrofonu i wyjście głośnika. Wszystko, co może poczekać – zapytania do bazy danych, wywołania zewnętrznych API – przenieś do osobnego wątku lub usługi.
  • Priorytetyzuj stabilność opóźnień – Mierz czas odpowiedzi, skupiając się na opóźnieniach w najgorszym scenariuszu, a nie tylko na średniej. Języki i środowiska uruchomieniowe, które dają ściślejszą kontrolę nad harmonogramowaniem (np. Go, Rust), mogą być warte dodatkowego wysiłku inżynieryjnego.
  • Zminimalizuj narzut połączenia – Każde dodatkowe uzgodnienie (handshake) dodaje milisekundy, które sumują się w odczuwalne opóźnienie. Połącz uwierzytelnianie, negocjację strumienia i wybór kodeka w jedną wymianę danych, a użytkownicy odczują różnicę.

Kompromisy i otwarte pytania

Projekt typu full-duplex zwiększa złożoność.

Na co warto zwrócić uwagę w przyszłości