Így építettünk hat hónap alatt valós idejű rendszert a válaszkész hangalapú MI-hez

A hangalapú MI számára nehezebb eldönteni, mikor szólaljon meg, mint gondolnánk. Az emberek a másodperc törtrésze alatt, könnyedén adják át egymásnak a szót, a korábbi hangalapú MI-rendszerek azonban nem tudták tartani ezt a ritmust. Körökre épülő architektúrájuk apró, kördetektoroknak nevezett modellekre támaszkodott, amelyek hálátlan feladatot kaptak: ha túl korán tippeltek, félbeszakították a felhasználót; ha túl későn, a válasz vontatottnak érződött. A jóval nagyobb LLM csak a detektor döntése után kezdhetett dolgozni.

Harmadik generációs hangrendszerünk, a GPT‑Live⁠ eltávolítja a kördetektort a hangútvonalról. Hangmodellje teljes duplex működésű, vagyis egyszerre képes figyelni és beszélni. Így nincs szükség külön detektorra, a beszélgetés pedig közvetlenebbnek és természetesebbnek hat. Ha alaposabb érvelésre vagy eszközhasználatra van szükség, a GPT‑Live a beszélgetés menetének megszakítása nélkül élvonalbeli modelljeinkhez, például a GPT‑5.5‑höz is fordulhat. E képességek együtt a beszélgetési válaszkészség és az intelligencia példátlan kombinációját adják a GPT‑Live‑nak.

Ennek az élménynek a nagy léptékű biztosításához új, kis késleltetésre optimalizált rendszerarchitektúrára volt szükség. A szokásos kérés-válasz alapú következtetéstől eltérően rendszerünk a bejövő hangot folyamatosan a hangmodellbe, a kimenő beszédet pedig vissza a felhasználóhoz streameli, miközben a delegálást külön aszinkron útvonalon kezeli. Az elmúlt hat hónapban átdolgoztuk a modell következtetését, a kontextuskezelést és a médiaátvitelt, hogy a beszéd a teljes útvonalon egyenletesen áramoljon.

Az architektúra egyértelmű határt teremt az alapvető hangútvonal és az alkalmazáslogika között is. Így az alkalmazás viselkedése egyszerűen testreszabható a válaszkészség befolyásolása nélkül. Ez az alap működteti a ChatGPT Hang egyre bővülő képességeit, köztük az újonnan bevezetett funkciót, amellyel a ChatGPT asztali alkalmazásában vezérelheted számítógépedet és koordinálhatod ügynökeidet.

Ebben a bejegyzésben bemutatjuk, miért nem feleltek meg igényeinknek a korábbi, körökre épülő rendszerek, és hogyan tettük az új rendszert minden rétegében válaszkésszé. Kitérünk az állapottartó következtetésre, a dinamikus kontextuskezelésre, az aszinkron delegálásra és a protokollszintű optimalizálásra, amelyek együtt teszik igazán élővé a GPT‑Live‑ot.

A korábbi hangarchitektúrák átvették a szöveges LLM-ek körökre épülő jellegét, de minden kört szöveg helyett különálló hangcsomagként ábrázoltak. A kaszkádolt rendszerekben a beszédfelismerés, az LLM és a beszédszintézis egymás után futott. Ez a sorrendiség növelte a késleltetést, és figyelmen kívül hagyta az olyan jelzéseket, mint a hangszín és a beszédtempó.

A beszéd-beszéd modellek a hang közvetlen feldolgozásával javítottak ezen a megközelítésen. Mivel a modellt a beszéd közvetlen megértésére és létrehozására tanítottuk, megőrizhette az átírás során elvesző részleteket, és gyorsabban válaszolhatott. A rendszer azonban továbbra is a kördetektorra támaszkodott annak eldöntésében, mikor kezdődhet el a következtetés. A modell többet kezelt az interakcióból, de az továbbra is körökre épült.

A GPT‑Live a hangmodellt teszi a beszélgetés irányítójává: a hang be- és kiáramlik a modellből, miközben az alaposabb érvelés és az eszközhasználat aszinkron módon történik. A rendszer elsődleges feladata a megszakítás nélküli médiahurok fenntartása. Más feladatok, például az élvonalbeli modellek meghívása és a beszélgetés tartós tárolása, az élő útvonalon kívül történnek.

A médiahurok megszakítás nélküli fenntartása nem mindig egyszerű. Az átvitel, a feldolgozás vagy a következtetés bármely késése hallható szünetet vagy torzítást okozhat. Egy korábbi, körökre épülő rendszer elviselt némi eltérést a hangcsomag érkezési idejében. Egy élő médiarendszernek azonban minden hangképkockát időben kell kézbesítenie.

A ChatGPT Hangon és a Realtime API-n végzett korábbi munkánk fontos alapot teremtett. Már korábban újjáépítettük hangalapú infrastruktúránkat⁠, hogy a hangot és a videót közvetlenül, kisebb és kiszámíthatóbb késleltetéssel streamelhessük be és ki rendszereinkből. A GPT‑Live továbbfejlesztette ezt a kialakítást: egy folyamatos beszélgetésre épített, új, állapottartó következtetési rendszeren keresztül egészen a modellig streameli a médiát.

A streamelt következtetés azonban csak a megoldás egyik része volt. A megbízható éles működéshez a kliens és a következtetési rendszer közötti hangkézbesítést is biztosítanunk kellett, és kezelnünk kellett az állapottartás kihívásait.

Már korán úgy döntöttünk, hogy a médiafolyamot különválasztjuk az alkalmazás- és üzleti logikától. A hang külön gyors útvonalon halad a kliens és a hangmodell között. A delegálás, az eszközhasználat és más alkalmazási feladatok egy aszinkron RPC-határon túl zajlanak. Egy lassú eszközhívás vagy backendszolgáltatás késleltetheti a saját eredményét, de nem akaszthatja meg a média áramlását.

Ez a szétválasztás a testreszabás számára is egyértelmű határt teremt a rendszerben. Az alkalmazások anélkül módosíthatják eszközeiket, szabályzataikat és backendjük működését, hogy ez érintené a hang folyamatos továbbításáért felelős média-frontendet. Az élő útvonal kicsi és kiszámítható marad, és kizárólag a valós időben elvégzendő feladatokra összpontosít.

A média-frontendet és a következtetési logikát Go nyelven írtuk meg, leváltva a korábbi Python-alapú asyncio megvalósítást. Ez jelentősen egyenletesebbé tette a képkockák kézbesítését: az új rendszer p95 értéke megegyezik a korábbi rendszer p50 értékével.

Az átvitel alapját a WebRTC biztosítja. Kis késleltetésű médiaátvitelre tervezték, és csomagvesztés, óraeltérés vagy a klienskapcsolat változásai mellett is működőképes marad. Ha a csomagok késve érkeznek, a WebRTC finoman megnyújthatja a hangot a kimaradások elkerülésére, majd rövid időre felgyorsíthatja a lejátszást, hogy utolérje a valós időt.

A pufferelés és blokkolás rendszerszintű minimalizálásával biztosíthatjuk a beszélgetésektől elvárt, egy másodpercnél gyorsabb válaszkészséget.

Az állapottartó következtetés saját üzemeltetési kompromisszumokkal jár. Egy hangalapú munkamenet sokáig aktív maradhat, miközben a kontextusa folyamatosan bővül, a modellpéldányok pedig az igényeknek megfelelően indulnak el és állnak le.

E problémák kezelésére zökkenőmentes átadási mechanizmust építettünk a modellpéldányok közé. Amikor váltásra van szükség, a meglévő mellett előkészíthetünk egy helyettesítő modellpéldányt, előre feltölthetjük az aktuális munkamenet kontextusával, párhuzamosan futtathatjuk a következtetést mindkettőn, majd akkor válthatunk, amikor az új példány teljesen készen áll.

Ugyanez az alapmechanizmus a dinamikus kontextusmegőrzést is támogatja. A beszélgetés előrehaladtával a felhalmozódó kontextus végül túllépheti a modell kontextuskorlátját. A kontextusmegőrzés a korlátnak megfelelő méretűre csökkentheti a kontextust, a művelet azonban időigényes. Mivel a korábbi kontextust is módosítja, érvényteleníti a modell kulcs-érték (KV) gyorsítótárát is, amely a már feldolgozott tokenek figyelmi kulcsait és értékeit tárolja. Ennek az állapotnak az újjáépítéséhez újabb előzetes feltöltés szükséges, ami további késést okoz.

Ezért a kontextusmegőrzést inkább egy újabb felügyelt váltásként kezeljük. Miközben az eredeti modellpéldány folytatja a beszélgetést, a rendszer tömöríti a kontextust, és előkészít egy helyettesítő modellpéldányt az új kontextussal. Amint ez a példány elkészül, a médiafolyam megszakítása nélkül válthatunk át rá. Így a rendszer hosszú hívásokat is támogat, és szükség szerint megőrzi a kontextust.

A nehéz munka az élő útvonalon kívül marad, így a beszélgetés még az átadás során is zavartalanul folytatódik.

A GPT‑Live nagy erejét az adja, hogy képes meghívni a meglévő élvonalbeli modelleket, így gyakorlatilag különválasztja a „beszédet” az alaposabb „gondolkodástól”. Ahhoz azonban, hogy ez a kétmodelles architektúra egyetlen rendszernek érződjön, két összefüggő mérnöki problémát kellett megoldanunk.

Először is, az eredményeknek elég gyorsan kell visszaérkezniük ahhoz, hogy hasznosak legyenek a folyamatban lévő párbeszédben. Ezért a teljes delegálási útvonalon minimalizálnunk kellett a késleltetést, az irányítástól és az utasítás feldolgozásától a következtetésen át az eszközhívásokig. Eközben a termék más rendszereinek továbbra is különálló üzenetekre van szükségük, ezért a folyamatban lévő beszélgetést számukra érthető formában kellett megjelenítenünk.

Delegálás indításakor azt az időt optimalizáljuk, amely alatt az élvonalbeli modell valami hasznosat ad a beszélgetéshez. A hangmodell rövid ideig továbbviheti a párbeszédet, amíg egy élvonalbeli modell érvel vagy eszközöket használ, de egy tetszőlegesen lassú választ nem képes elfedni. Ezért a teljes delegálási hurkot – az irányítást, az utasítás feldolgozását, a következtetést és az eszközhívásokat – beleszámítottuk a válaszkészségi keretbe.

Az első optimalizálás az élvonalbeli modell és a szükséges eszközök előkészítése még a delegálási kérés előtt. A hangalapú munkamenet kezdetekor az alkalmazásszerver következtetési munkamenetet hoz létre az élvonalbeli modell számára, és előre feltölti a beszélgetés kezdeti kontextusával. Így az utasítás feldolgozása még az első delegált kérés előtt befejeződik.

Ezt a következtetési munkamenetet ezután a teljes hangbeszélgetés alatt elérhetően tartjuk, az egymást követő kérésekhez pedig stabil munkamenet-affinitást használunk. Az utasítás-gyorsítótárazással együtt ezek a technikák csökkentik a késleltetést, miközben egy feldolgozó hibája továbbra is könnyen helyreállítható.

Az érvelési ráfordítás, a kimeneti korlátok, az eszközsémák, valamint a modell és az eszközök közötti oda-vissza körök szintén befolyásolják, mikor kap a beszélgetés használható eredményt, ezért ezeket is gyorsabb válaszokra hangoltuk. A delegálási útvonalon szükséges munka minimalizálásával lehetővé tettük, hogy a hangmodell gyorsan beépítse élvonalbeli modelljeink eredményeit.

Bár a hangmodell folyamatos beszédfolyamokkal dolgozik, számos környező rendszer továbbra is felhasználói és asszisztensi köröket kezel, köztük a ChatGPT beszélgetési felülete, valamint analitikai és biztonsági infrastruktúránk egyes részei. Az alkalmazásszerver ezért különálló üzenetekre bontja az egymásba érő, időnként kétértelmű beszélgetést.

A hang beérkezésekor a szerver részleges átiratok és időzítési jelek alapján állapítja meg, kinél van a szó, és üzenetsort épít. A legújabb üzenet ideiglenes marad: a szövege, időzítése és beszélőhöz rendelése egyaránt változhat, ahogy újabb beszéd érkezik. Amint valaki elég hosszan beszél ahhoz, hogy a hozzárendelés megbízható legyen, a szerver véglegesíti a megfelelő üzenetet.

A beszélők egyidejű megszólalása tovább bonyolítja ezt. Az asszisztens rövid visszajelzéséből, miközben a felhasználó beszél – például „ühüm” vagy „rendben” –, nem feltétlenül kell külön üzenetet készíteni. Egy érdemi asszisztensi közbeszólásból azonban gyakran igen. Hasonlóképpen, a megjelenített asszisztensi válaszok összefüggőségét akkor is előnyben részesítjük, ha a felhasználó közben megszólal.

Minden szegmentálási szabály kompromisszumot köt a frissesség és a bizonyosság között. A túl korai véglegesítés töredezett előzményeket és bizonytalan sorrendet eredményez, a túl hosszú várakozás pedig késlelteti az átiratokat és a rájuk épülő funkciókat. A rendszer ezért két összefüggő nézetet tart fenn a beszélgetésről: egy előzetes nézetet az aktuális állapotról és egy hiteles nyilvántartást az elhangzottakról. Az alkalmazás beszélgetési felülete képes kezelni a frissítéseket, ezért az előzetes nézetet használja. Az analitikai folyamat naplózásához azonban végleges átirat szükséges.

Így a ChatGPT többi része stabil képet kap a párbeszédről anélkül, hogy az élő hangútvonalra körökre osztott működést kényszerítenénk.

A válaszkészség már abban a pillanatban számít, amikor a felhasználó a gombra kattint. A GPT‑Live esetében a rendszernek még a beszélgetés kezdete előtt létre kell hoznia a médiaútvonalat, és meg kell kezdenie a hang továbbítását a modellen keresztül. Így az indítási folyamat minden része a kritikus útvonalra kerül.

Mint fentebb említettük, a WebRTC stabil valós idejű alapot biztosít, egy hagyományos WebRTC-munkamenet elindításához azonban meglepően sok protokollkézfogásra és oda-vissza hálózati körre van szükség. A WebRTC még azelőtt született, hogy az oda-vissza körök minimalizálása olyan későbbi protokollok központi szempontjává vált volna, mint a QUIC. Emiatt az alapjául szolgáló protokollok együtt használva időnként megismétlik ugyanazt a munkát. Például mindegyik protokoll saját DoS-védelmi mechanizmussal rendelkezett, még akkor is, ha arra a teljes WebRTC-verem összefüggésében nem volt szükség.

Elemeztük a vermet, és kifejlesztettük a WebRTC Abridged Roundtrip Protocolt (WARP⁠(új ablakban nyílik meg)), amely a média és az adatok indításához szükséges hat oda-vissza hálózati kört egyetlen körre csökkenti. A WARP ezt visszafelé kompatibilis protokollfejlesztésekkel éri el: a DTLS-kézfogást az ICE-re ülteti (SPED⁠(új ablakban nyílik meg)), a gyorsabb DTLS 1.3⁠(új ablakban nyílik meg)-kézfogást használja, előre egyezteti az SCTP-kézfogást (SNAP⁠(új ablakban nyílik meg)), és az adatcsatornákat is előre egyezteti a DCEP⁠(új ablakban nyílik meg) használata helyett.

A WARP-ot nyílt specifikációk együtteseként, a WebRTC-közösség közreműködőivel együtt terveztük, hogy a szélesebb ökoszisztéma is hasznosíthassa ezt a munkát. A javaslatokat az IETF TSVWG munkacsoportján keresztül visszük tovább. A WARP támogatása már bekerült a libwebrtc-be és a Pionba, és más WebRTC-megvalósításokban is folyik a munka.

A média-kézfogás optimalizálása után egy fennmaradó késés tűnt ki: az SDP-paraméterek megosztására szolgáló jelzésváltás, amelyre a WebRTC csatlakozása előtt van szükség. Hogy ezt a váltást eltávolítsuk a kritikus útvonalról, kifejlesztettük az Instant Connectet. A paramétereket előre egyezteti szerverkapacitás lefoglalása és a meglévő WebRTC-megvalósítások módosítása nélkül.

Az Instant Connect a szabványos jelzési folyamattal párhuzamosan fut. Ha az előre egyeztetett paraméterek érvényesek, a szerver az első médiacsomag beérkezésekor létrehozhatja a munkamenetet. Ha elavultak vagy érvénytelenek, a jelzési folyamat már fut, így a kliens további késleltetés nélkül visszatérhet hozzá.

Az Instant Connect és a WARP együtt drámaian lerövidíti a felhasználói szándék és az élő médiafolyam indulása közötti időt. Mivel az SDP-csere kikerült a kritikus útvonalról, a WARP pedig egyetlen lépésre csökkenti az átviteli kézfogást, a kliens már egyetlen UDP-csomaggal elindíthatja a munkamenetet. A szerver azonnal válaszolhat, így a rendszer többi része megkezdheti azt a munkát, amely a felhasználónak valóban fontos: a figyelést és a válaszadást.

Egy rendszer papíron gyorsnak tűnhet, valós hangforgalom mellett mégis leállhat. Mielőtt a GPT‑Live beszélgetni kezdett volna a felhasználókkal, csendes tesztet futtattunk: az éles ChatGPT Hang-munkamenetek kis, fokozatosan növelt részét egyszerre irányítottuk a meglévő speciális hang módhoz és az új rendszerünkhöz. A speciális hang mód a megszokott módon szolgálta ki a felhasználókat, miközben az árnyékútvonal csak olvasási módban futtatta a következtetést. Így a rendszert valós klienseknek, hálózatoknak, munkamenet-hosszaknak és földrajzi eloszlásnak tettük ki anélkül, hogy megváltozott volna, amit a felhasználók hallottak.

Az egyik első tanulság az volt, hogy a kapacitás nem vezethető vissza pusztán a GPU adatátviteli egységére. A hangalapú munkamenetek nyitva maradnak, és folyamatosan küldik a képkockákat, ezért a CPU-oldali streamkezelőknek, várólistáknak és hálózati útvonalaknak a következtetéssel együtt kell skálázódniuk. Valós terhelés mellett egy kiegészítő komponens a terheléses tesztjeink becslésénél hamarabb telítődött, így a következtetési kérések feltorlódtak, a késleltetés pedig tovább halmozódott. A kapacitásra vonatkozó kérdést a „Hány kérést képes kezelni egy GPU?” helyett így tettük fel: „Hány egyidejű munkamenetet képes fenntartani a rendszer úgy, hogy minden képkocka időben célba érjen?”

A teszt azt is megmutatta, hogy a földrajzi elhelyezkedés elsődleges szempont. Ha egy munkamenetet távoli kapacitáshoz irányítunk, az az indítás és a streamelés több pontján is növelheti a késleltetést. A modellbevezetések ellenőrzését ezután a regionális kapacitás és a forgalomirányítás konfigurációjával együtt végeztük, a késleltetést pedig forrásrégiók szerint bontottuk fel. A következtetés felhasználókhoz közelebb helyezése segített, de egy tágabb tanulságot is megerősített: a teljes folyamat válaszkészsége az útvonal minden szolgáltatásától függ, nem csak a modellszervertől.

Más hibák csak életszerű munkamenet-életciklusok során jelentkeztek. A hosszú munkamenetek memória- és tartós tárolási terhelést tártak fel. Az újracsatlakozások próbára tették a kontextusmegőrzést és az állapot-visszaállítást. A kliensek szokásos leválásai versenyhelyzeteket tártak fel a leállítási kézfogásban. Ezek a problémák ritkán jelentkeztek rövid terheléses tesztekben, mert az időtől, a felhalmozódott állapottól és a szolgáltatáshatárokon átívelő viselkedéstől függtek.

Végül az éles tesztelés a megfigyelhetőség és a bevezetési vezérlők javítására is rákényszerített bennünket. Találtunk olyan mérőszámokat, amelyek összemosták a késleltetés különböző forrásait, olyan irányítópultokat, amelyek összesítései elfedték az egyes hibás motorokat, valamint konfigurációs eltéréseket a tesztelt és a telepített rendszerek között. Válaszul részletesebb telemetriát, bevált konfigurációkkal való ellenőrzést, szakaszos felfuttatást, valamint az egyes útvonalak gyors elkülönítésének vagy letiltásának lehetőségét vezettük be. A csendes teszt korai indulási főpróbává vált: nemcsak azt mértük fel, mekkora forgalmat képes fogadni a rendszer, hanem azt is, milyen gyorsan tudjuk észlelni és megfékezni a hibákat, majd helyreállítani a működést.

A GPT‑Live ChatGPT léptékű működtetéséhez teljesen új rendszert kellett építenünk egy alapelv köré: a hangnak folyamatosan áramolnia kell. A streamelt következtetés folyamatosan hanggal látja el a teljes duplex modellt. A külön médiaútvonal gondoskodik a képkockák megbízható kézbesítéséről. Az aszinkron delegálás lehetővé teszi, hogy az alaposabb gondolkodás párhuzamosan fusson. Az optimalizált átvitel egészen a felhasználóig megőrzi az élmény válaszkészségét.

A GPT‑Live mögötti architektúra máris a valós idejű interakciók szélesebb körű platformjává válik. Ez működteti a ChatGPT Hangot, miközben az a beszélgetéstől az ügynöki koordináció felé fejlődik, és ez lesz a közelgő GPT‑Live API alapja is. Idővel lehetővé teszi, hogy a hangalapú élmények több eszközre, alkalmazásra és modalitásra terjedjenek ki anélkül, hogy elveszne a hangbeszélgetések élő közvetlensége.

Ha ilyen mérnöki problémákat szeretnél megoldani, dolgozz velünk⁠.