Justin Uberti és Zahan Malkani, az OpenAI műszaki munkatársai bemutatják a GPT‑Live nevű harmadik generációs hangrendszert, amely a korábbi, fordulóalapú architektúrák korlátait hivatott leküzdeni. A rendszer célja, hogy a beszélgetés emberi ritmusához hasonló, alig észlelhető késleltetésű visszajelzést adjon: a modell egyszerre hallgat és beszél, így nincs szükség külön fordulódetektorra.
Mi változott a korábbi rendszerekhez képest?
Korábbi megközelítésekben a beszédfeldolgozás egymás után futó elemekből állt: beszédfelismerés (speech‑to‑text), nagy nyelvi modell (LLM) és beszédszintézis (text‑to‑speech). Ezek egymás után növelték a késleltetést és elveszítették a hangalmazásban rejlő finom jelzéseket. A beszéd‑beszéd (speech‑to‑speech) modellek javítottak ezen azzal, hogy közvetlenül hangon dolgoztak, de továbbra is fordulódetektorra támaszkodtak: az interakció továbbra is fordulókra tagolt maradt.
GPT‑Live ehelyett a hangmodellt helyezi a beszélgetés középpontjába: az audio folyamatosan áramlik be és ki a modellből, míg a mélyebb gondolkodást és eszközhívásokat (például frontier modellek, köztük GPT‑5.5) aszinkron módon végzi a rendszer. Az élő (media) útvonal elsődleges feladata, hogy megszakítás nélkül tartsa a hangfolyamot; minden egyéb munka a live útvonaltól elkülönítve zajlik.
Mire volt szükség a skálázható, alacsony késleltetésű működéshez?
A csapat hat hónapon át újraépítette az inferencia, a kontextuskezelés és a médiaátvitel rétegeit. A főbb mérnöki döntések:
- A médiaáramlás elkülönítése az alkalmazáslogikától: az audio egy dedikált, gyors úton halad a kliens és a hangmodell között; a delegálás, eszközhasználat és üzleti logika aszinkron RPC‑határon múlik.
- Átírás Go nyelvre a média frontend és inferencia logika számára a korábbi Python asyncio megoldás helyett, ami jelentősen javította a keretátadások simaságát (a p95 teljesítmény megfelelt a korábbi p50‑nek).
- WebRTC használata a transport alapjaként, mert az alacsony késleltetésre és hibajavításra optimalizált: csomagvesztés, óraeltolódás és klienskapcsolat‑váltás esetén is folyamatban tartja a médiumot.
Ezek együtt lehetővé tették, hogy a rendszer alacsony pufferelést és blokkolást alkalmazzon, és így másodpercnél rövidebb válaszidőt érjen el.
Állapotkezelés és átadás modellek között
A hosszú élettartamú hangmunkamenetek folyamatosan növelték a kontextust, miközben a modellpéldányok igény szerint elindultak és leálltak. Ennek kezelése érdekében a mérnökök egy zökkenőmentes átadási mechanizmust építettek:
- Párhuzamos előmelegített példányok: amikor átállásra van szükség, a helyettesítő példányt „melegítik fel” a jelenlegi munkamenet kontextusával, párhuzamosan futtatnak inferenciát mindkét példányon, és csak akkor váltanak, amikor az új példány teljesen készen áll.
- Dinamikus kontextuskompaktálás: amikor a beszélgetés kontextusa meghaladná a modell limitjét, a rendszer kompaktálja a kontextust és előkészít egy új példányt az új kontextussal, majd átad anélkül, hogy a médiafolyam megszakadna.
A nehezebb feldolgozás (pl. kontextuskompaktálás) mindig a live útvonalon kívül történik, így a beszélgetés folyamatos marad.
Aszinkron delegálás frontier modelleknek
GPT‑Live képes a „beszélgetés” és a „mélyebb gondolkodás” szétválasztására: a hangmodell folyamatban tartja a beszélgetést, miközben a háttérben frontier modelleket, például GPT‑5.5‑öt hív meg keresésre vagy eszközhasználatra. A delegálási útvonal gyorsítása érdekében több optimalizációt alkalmaztak:
- A frontier modell és szükséges eszközök előkészítése a hangmunkamenet kezdetén: az alkalmazásszerver létrehoz egy inferencia munkamenetet a frontier modell számára és előfeltölti a kezdeti kontextussal.
- Stabil munkamenet‑affinitás és prompt‑cache használata a késleltetés csökkentésére.
- A delegálási költségek minimalizálása (kimeneti korlátok, eszköz‑sémák és model‑eszköz körutak finomhangolása), hogy a hangmodell gyorsan be tudja építeni a kapott eredményeket.
A tervezés célja, hogy a delegálás gyorsan adjon hasznos választ, mert a hangmodell csak rövid ideig tud „kitartani” a saját folyamataival, míg a frontier gondolkodik.
A beszélgetés szegmentálása és UI‑kompatibilitás
Bár a hangmodell folyamatos audiót kezel, a ChatGPT felügyeleti és analitikai rendszerek, valamint a felhasználói felület továbbra is gyakran forduló‑alapú üzenetekre épülnek. Ennek kezelése:
- A szerver részben kész átírások és időzítési jelek alapján következteti a beszélő jogát és üzenetsorokat épít.
- A legújabb üzenet kezdetben provizórikus: a szöveg, időzítés és beszélő‑hozzárendelés változhat, amíg elég adat nem érkezik a véglegesítéshez.
- A rendszer két nézetet tart fenn: egy spekulatív, frissítő nézetet a felhasználói UI‑nak és egy autoritatív, végleges naplózott átírást az analitikának.
Ez a megközelítés stabil nézetet ad a ChatGPT többi részének anélkül, hogy a live hangútvonalra fordulókat kényszerítené.
Transport‑optimalizációk: WARP és Instant Connect
A gyors reagálás a felhasználói gombnyomás pillanatában kezdődik, ezért a csatlakozási protokollok optimalizálása is kritikus. A WebRTC‑alap természetes alap, de a hagyományos WebRTC‑kezdés sok hálózati kézfogást igényel. Ennek csökkentésére a csapat több megoldást vezetett be:
- WARP (WebRTC Abridged Roundtrip Protocol): visszafelé kompatibilis protokolljavítások együttese, amely a média és adat indítását hat hálózati körutazásról egyre csökkenti. Elemei közé tartozik a DTLS‑handshake ICE‑re piggybackelése (SPED), DTLS 1.3 használata, SCTP elő‑egyeztetése (SNAP) és adatcsatornák elő‑egyeztetése DCEP helyett.
- Instant Connect: az SDP paraméterek előegyeztetése a kritikus útvonalon kívül, így ha az előegyeztetett paraméterek érvényesek, a szerver képes élő munkamenetet materializálni az első média‑csomag érkezésekor; ha nem, a normál jelzésfolyam lép életbe hibamentesen.
Ezek együtt lehetővé teszik, hogy a kliens egyetlen UDP csomaggal elindítsa a munkamenetet, és a szerver azonnal válaszoljon.
Termelési tesztek és üzemeltetési tanulságok
A GPT‑Live bevezetése előtt az OpenAI „silent testet” futtatott: egy növekvő részarányt irányítottak át a gyártási ChatGPT Voice munkamenetekből a régi Advanced Voice Mode és az új rendszer árnyékútjára. Ennek eredményei:
- A kapacitást nem csak GPU‑átviteli teljesítményként kell mérni; a hangmunkamenetek folyamatos kereteket küldenek, így CPU‑oldali streamkezelők, sorok és hálózati utak is telítődhetnek.
- A földrajz (latencia a forráshoz képest) elsőrendű tényezővé vált; az inference közelebb vitele a felhasználókhoz segített csökkenteni a késleltetést.
- Hosszú munkamenetek memórianyomást, konzisztencia‑helyreállítást és shutdown‑zavarokat hoztak felszínre, amelyeket rövidebb load‑tesztek nem mutattak.
- Javították a megfigyelhetőséget, finomabb telemetriát vezettek be, éles konfigurációk ellenőrzését és lépcsőzetes forgalmi növelést alkalmaztak a gyors hibadetektálás és visszaállítás érdekében.
A csendes teszt többé már nem csak kapacitásvizsgálat volt, hanem az üzemeltetési eljárások és helyreállítási folyamatok próbája is.
Mire jó ez a platform?
A GPT‑Live mögötti architektúra már túlmutat egyetlen beszélgetési funkción: alapját képezi a ChatGPT Voice bővülő képességeinek — például számítógépvezérlés és ügynökkoordináció a ChatGPT asztali alkalmazásban — és később a GPT‑Live API‑nak. A cél az, hogy a hangélmények több eszközön, alkalmazásban és modalitásban azonnaliságot tartsanak meg anélkül, hogy feláldoznák a válaszkészséget.
Ha ezek az engineering kihívások érdekelnek, a szerzők felhívják a szakembereket, hogy csatlakozzanak hozzájuk.
Szerzők: Justin Uberti és Zahan Malkani, Members of Technical Staff (OpenAI) — eredeti poszt alapján.
