Дауыстық ЖИ үшін қашан сөйлеу керегін анықтау көрінгеннен күрделірек. Адамдар секундтың бір бөлігінде бір-біріне сөзді еш қиындықсыз береді, ал бұрынғы дауыстық ЖИ жүйелері бұл ырғаққа ілесе алмайтын. Олардың кезекке негізделген архитектурасы кезек детекторлары деп аталатын шағын модельдерге сүйенді. Бұл модельдердің міндеті оңай емес еді: тым ерте болжаса, пайдаланушының сөзі бөлінеді; тым кеш болжаса, жауап баяу сезіледі. Детектор шешім қабылдағаннан кейін ғана әлдеқайда үлкен LLM (үлкен тілдік модель) жұмысқа кірісе алатын.
Үшінші буындағы дауыс жүйеміз GPT‑Live кезек детекторын аудио арнасынан алып тастайды. Оның дауыс моделі толық дуплексті, яғни бір уақытта тыңдап та, сөйлеп те отыра алады. Бұл жеке детектор қажеттілігін жойып, әңгімені жедел әрі табиғи етеді. Тереңірек ой қорыту немесе құралдарды пайдалану қажет болса, GPT‑Live әңгіме ағынын үзбей GPT‑5.5 сияқты озық модельдерімізге де жүгіне алады. Осы мүмкіндіктер GPT‑Live жүйесіне әңгімелесу жеделдігі мен ойлау деңгейінің бұрын-соңды болмаған үйлесімін береді.
Бұл мүмкіндікті кең ауқымда ұсыну үшін төмен кідіріске оңтайландырылған жаңа жүйе архитектурасы қажет болды. Әдеттегі сұрау-жауап инференсінен өзгеше, жүйеміз кіріс аудионы дауыс моделіне, ал шығыс сөзді пайдаланушыға ағынмен жібереді және табыстауды бөлек асинхронды арнада өңдейді. Соңғы алты айда сөздің басынан аяғына дейін бірқалыпты ағуын сақтау үшін модель инференсін, мәнмәтінді басқаруды және медиа тасымалдауды қайта жасадық.
Архитектура негізгі дауыс арнасы мен қолданба логикасы арасында айқын шекара да қалыптастырады. Осының арқасында жауап беру жылдамдығына әсер етпей, қолданба әрекетін оңай бейімдеуге болады. Бұл негіз ChatGPT Voice жүйесіндегі мүмкіндіктердің ұлғайып келе жатқан ауқымын, соның ішінде жақында іске қосылған компьютерді басқару және ChatGPT жұмыс үстелі қолданбасында агенттерді үйлестіру мүмкіндігін қамтамасыз етеді.
Бұл жазбада бұрынғы кезекке негізделген жүйелер неге талаптарымызға сай болмағанын және жаңа жүйенің әр қабатын жедел әрекеттесуге қалай бейімдегенімізді түсіндіреміз. GPT‑Live жүйесін шын мәнінде тікелей сезіндіру үшін бірге жұмыс істейтін күй сақтайтын инференсті, мәнмәтінді динамикалық басқаруды, асинхронды табыстауды және протокол деңгейіндегі оңтайландыруды қарастырамыз.
Бұрынғы дауыс архитектуралары мәтіндік LLM (үлкен тілдік модель) жүйелерінің кезекке негізделген сипатын мұра етті, бірақ әр кезек мәтін емес, жеке аудио блогы түрінде берілді. Каскадты жүйелерде сөзді мәтінге түрлендіру, LLM (үлкен тілдік модель) және мәтінді сөзге түрлендіру бірінен соң бірі орындалатын. Мұндай реттілік кідірісті арттырып, дауыс ырғағы мен сөйлеу қарқыны сияқты белгілерді елемеді.
Сөз сөйлеуден сөз сөйлеуге модельдері аудионы тікелей өңдеу арқылы бұл тәсілді жетілдірді. Модельді сөйлеуді тікелей түсініп, тудыратындай етіп дайындау транскрипция кезінде жоғалатын мәліметтерді сақтауға және жылдамырақ жауап беруге мүмкіндік берді. Бірақ жүйе инференстің қашан басталатынын анықтау үшін әлі де кезек детекторына сүйенді. Модель әрекеттесудің көбірек бөлігін атқарғанымен, әрекеттесу кезекке негізделген күйінде қалды.
GPT‑Live дауыс моделіне әңгімені басқаруға мүмкіндік береді: аудио модельге кіріп-шығып жатады, ал тереңірек ой қорыту мен құралдарды пайдалану асинхронды түрде орындалады. Жүйенің негізгі міндеті — үздіксіз медиа циклін сақтау. Озық модельдерді шақыру және әңгімені тұрақты сақтау сияқты басқа жұмыстар тікелей арнадан тыс орындалады.
Бұл медиа циклін үздіксіз сақтау әрдайым оңай емес. Тасымалдау, өңдеу немесе инференстегі кез келген кідіріс естілетін үзіліске не дыбыс ақауына айналуы мүмкін. Алдыңғы кезекке негізделген жүйе аудио блогының келу уақытындағы аздаған ауытқуға төзе алатын. Ал тікелей медиа жүйесі әр аудио кадрды дәл уақытында жеткізуі керек.
ChatGPT Voice және Realtime API бойынша бұрынғы жұмысымыз маңызды негіз қалады. Аудио мен бейнені жүйелерімізге тікелей енгізіп, олардан тікелей ағынмен шығару үшін, кідірісі төмен әрі болжамды болатындай дауыс инфрақұрылымымызды қайта құрған едік. GPT‑Live бұл құрылымды әрі қарай дамытып, үздіксіз әңгімеге арналған жаңа күй сақтайтын инференс жүйесі арқылы медианы модельге дейін ағынмен жеткізді.
Алайда ағындық инференс шешімнің бір бөлігі ғана еді. Оның өндірістік ортада дұрыс жұмыс істеуі үшін клиенттен инференс стекіне аудионың сенімді жеткізілуін қамтамасыз етіп, күйді сақтауға байланысты қиындықтарды да шешуіміз керек болды.
Бастапқы шешімдеріміздің бірі медиа ағынын қолданба және бизнес логикасынан арнайы бөлу болды. Аудио клиент пен дауыс моделі арасында арнайы жылдам арнамен өтеді. Табыстау, құралдарды пайдалану және қолданбаның басқа жұмыстары асинхронды RPC шекарасының ар жағында орындалады. Баяу құрал шақыруы немесе серверлік қызмет өз нәтижесін кешіктіре алады, бірақ медиа ағынын тоқтата алмайды.
Бұл бөлу жүйеде бейімдеуге арналған айқын шекара да қалыптастырады. Қолданбалар аудио ағынын сақтауға жауапты медиа интерфейсіне әсер етпей-ақ құралдарын, саясаттарын және серверлік әрекетін өзгерте алады. Тікелей арна шағын, болжамды күйде қалып, нақты уақытта атқарылуы тиіс жұмысқа ғана бағытталады.
Бұрынғы Python asyncio іске асыруының орнына медиа интерфейсі мен инференс логикасын Go тілінде жаздық. Бұл кадрлардың бірқалыпты жеткізілуін едәуір жақсартты: жаңа жүйенің p95 көрсеткіші бұрынғы жүйенің p50 көрсеткішіне тең болды.
WebRTC тасымалдау негізін қамтамасыз етеді. Ол кідірісі төмен медиаға арналып жасалған және пакет жоғалғанда, сағат ауытқығанда не клиент қосылымы өзгергенде де жұмысын жалғастыра алады. Пакеттер кешіксе, WebRTC үзілісті болдырмау үшін аудионы білінер-білінбес созып, кейін нақты уақытқа қайта жету үшін ойнатуды қысқа мерзімге жеделдете алады.
Жүйе бойындағы буферлеу мен бұғаттауды азайту арқылы адамдар әңгімеден күтетін бір секундқа жетпейтін жауап жылдамдығын қамтамасыз етеміз.
Күй сақтайтын инференстің өзіндік операциялық ымыралары бар. Дауыс сеансы ұзақ уақыт белсенді болуы мүмкін, бірақ оның мәнмәтіні үздіксіз ұлғаяды, ал модель даналары сұранысқа қарай іске қосылып, тоқтатылады.
Осы мәселелерді шешу үшін модель даналары арасында жіксіз ауысу тетігін жасадық. Ауысу қажет болғанда, қолданыстағы данамен қатар алмастырушы модель данасын дайындап, оған ағымдағы сеанс мәнмәтінін алдын ала енгіземіз, екеуінде де инференсті қатар орындаймыз да, жаңа дана толық дайын болғанда соған ауысамыз.
Осы негізгі тетік мәнмәтінді динамикалық ықшамдауды да қолдайды. Әңгіме жалғасқан сайын жиналған мәнмәтін ақырында модельдің мәнмәтін шегінен асуы мүмкін. Ықшамдау мәнмәтін көлемін осы шекке сыйатындай азайта алады, бірақ бұл әрекет уақыт алады. Ол бұрынғы мәнмәтінді өзгертетіндіктен, бұрын өңделген токендердің назар кілттері мен мәндерін сақтайтын модельдің кілт-мән (KV) кэшін де жарамсыз етеді. Бұл күйді қайта құру үшін жаңа алдын ала толтыру қажет, ал ол қосымша кідіріс тудырады.
Сондықтан ықшамдауды тағы бір басқарылатын ауысу ретінде қарастырамыз. Бастапқы модель данасы әңгімені жалғастырып жатқанда, жүйе мәнмәтінді ықшамдап, жаңа мәнмәтіні бар алмастырушы модель данасын дайындайды. Бұл дана дайын болғанда, медиа ағынын үзбей соған ауыса аламыз. Осының арқасында жүйе қажет кезінде ықшамдау жүргізіп, ұзақ қоңырауларды қолдай алады.
Күрделі жұмыс тікелей арнадан тыс орындалады, сондықтан ауысу кезінде де әңгіменің ырғағы бұзылмайды.
GPT‑Live жүйесінің қолданыстағы озық модельдерді шақыру мүмкіндігі оған зор қуат беріп, «сөйлеуді» тереңірек «ойлаудан» тиімді түрде ажыратады. Алайда осы екі модельді архитектураны біртұтас жүйедей сезіндіру үшін өзара байланысты екі инженерлік мәселені шешу қажет болды.
Тереңірек жұмыс үшін тапсырманы беру
GPT-Live жылдам әрі табиғи жауап береді, ал GPT-5.5 іздеуді фондық режимде орындайды
Біріншіден, нәтиже жүріп жатқан әңгімеге пайдалы болатындай тез қайтуы керек. Сондықтан бағыттаудан, көмексөзді өңдеуден бастап инференс пен құрал шақыруларына дейінгі бүкіл табыстау жолындағы кідірісті барынша азайттық. Сонымен бірге өнімнің басқа жүйелеріне әлі де бөлек хабарлар қажет, сондықтан жүріп жатқан әңгімені олар түсінетін пішінде көрсетуге тура келді.
Табыстау жіберілгенде, озық модельдің әңгімеге пайдалы нәтиже беруіне дейінгі уақытты оңтайландырамыз. Озық модель ой қорытып немесе құралдарды қолданып жатқанда, дауыс моделі әңгімені қысқа уақыт жалғастыра алады, бірақ шектен тыс баяу жауапты жасыра алмайды. Сондықтан бағыттау, көмексөзді өңдеу, инференс және құрал шақыруларын қамтитын толық табыстау циклін жауап беру уақытының бір бөлігі деп қарастырдық.
Алғашқы оңтайландыру — озық модель мен оған қажет құралдарды табыстау сұралмай тұрып дайындау. Дауыс сеансы басталғанда, қолданба сервері озық модельге арналған инференс сеансын жасап, оны әңгіменің бастапқы мәнмәтінімен алдын ала толтырады. Осылайша алғашқы табысталған сұрауға дейін көмексөз толық өңделеді.
Содан кейін бұл инференс сеансын дауыс арқылы сөйлесу қолжетімді күйде сақтап, кейінгі сұрауларды сол сеансқа тұрақты түрде бағыттаймыз. Көмексөзді кэштеумен бірге бұл тәсілдер кідірісті азайтады, ал орындаушы істен шыққан жағдайда жүйені оңай қалпына келтіруге болады.
Ой қорыту көлемі, нәтиже көлемінің шектері, құрал схемалары және модель мен құрал арасындағы айналымдар да әңгіменің пайдалы нәтижені қашан алатынына әсер етеді. Жауапты жылдамдату үшін осы параметрлерді реттедік. Табыстау жолындағы жұмысты азайту арқылы дауыс моделінің озық модельдеріміздің нәтижелерін жылдам пайдалануына мүмкіндік бердік.
Дауыс моделі үздіксіз сөйлеу ағынымен жұмыс істегенімен, айналасындағы көптеген жүйе, соның ішінде ChatGPT әңгіме интерфейсі мен аналитика және қауіпсіздік инфрақұрылымының бөліктері әлі де пайдаланушы мен ассистент кезектеріне сүйенеді. Сондықтан қолданба сервері қабаттасқан әрі кейде екіұшты әңгімені жеке хабарларға ажыратады.
Аудио келіп түскен сайын сервер кім сөйлеп тұрғанын анықтап, хабарлар кезегін құру үшін жартылай транскрипттер мен уақыт сигналдарын пайдаланады. Ең жаңа хабар алдын ала нұсқа күйінде қалады: жаңа сөз түскен сайын оның мәтіні, уақыты және сөйлеушіге тиесілігі өзгеруі мүмкін. Сөйлеуші жеткілікті уақыт бойы сөзін жалғастырып, тиесілігін сенімді анықтауға болғанда, сервер тиісті хабарды түпкілікті бекітеді.
Сөйлеушілердің бір мезгілде сөйлеуі бұл үдерісті күрделендіреді. Пайдаланушы сөйлеп жатқанда ассистенттің қысқа растауы (мысалы, «mm hmm» немесе «okay») міндетті түрде жеке хабарға айналмауы керек. Ал ассистенттің мазмұнды араласуы көбіне жеке хабар болуы тиіс. Сол сияқты, пайдаланушы ассистент сөйлеп жатқанда сөзге араласса да, көрсетілетін ассистент жауаптарының тұтастығына басымдық береміз.
Әр сегменттеу саясаты жеделдік пен сенімділік арасында ымыра жасайды. Тым ерте бекіту тарихты бөлшектеп, ретін тұрақсыз етеді; тым ұзақ күту транскрипттер мен оларға тәуелді мүмкіндіктерді кешіктіреді. Сондықтан жүйе әңгіменің өзара байланысты екі көрінісін сақтайды: ағымдағы күйдің болжамды көрінісі және айтылған сөздердің түпкілікті жазбасы. Қолданба интерфейсіндегі әңгіме көрінісі жаңартуларды өңдей алады, сондықтан болжамды көріністі пайдаланады. Ал аналитика конвейеріне журналдау үшін түпкілікті транскрипт қажет.
Осының арқасында ChatGPT жүйесінің қалған бөлігі тікелей дауыс арнасына кезекпен сөйлеу талабын жүктемей-ақ әңгіменің тұрақты көрінісін алады.
Жауап беру жылдамдығы пайдаланушы түймені басқан сәттен басталады. GPT‑Live жүйесінде әңгіме басталмас бұрын жүйе медиа арнасын орнатып, аудионы модель арқылы өткізе бастауы керек. Сондықтан іске қосу реттілігінің әр бөлігі шешуші жолға кіреді.
Жоғарыда айтылғандай, WebRTC нақты уақыттағы жұмысқа мықты негіз береді, бірақ кәдімгі WebRTC сеансын бастау үшін протоколдық келісулер мен желілік айналымдардың таңғаларлықтай көп саны қажет. WebRTC кейінгі QUIC сияқты протоколдарды қалыптастырған желілік айналымдарды азайту талабынан бұрын пайда болды. Сондықтан оның негізгі протоколдары бірге қолданылғанда кейде бір жұмысты қайталайды. Мысалы, толық WebRTC стегі аясында қажет болмаса да, әр протоколда DoS шабуылынан қорғайтын жеке тетік болды.
Біз стекті талдап, медиа мен деректерді іске қосуға қажет желілік айналым санын алтыдан бірге дейін азайтатын WebRTC Abridged Roundtrip Protocol (WARP(жаңа терезеде ашылады)) протоколын әзірледік. WARP мұны кері үйлесімді протокол жақсартулары арқылы орындайды: DTLS келісуін ICE арқылы бірге жіберу (SPED(жаңа терезеде ашылады)), жылдамырақ DTLS 1.3(жаңа терезеде ашылады) келісуін пайдалану, SCTP келісуін алдын ала жүргізу (SNAP(жаңа терезеде ашылады)) және DCEP(жаңа терезеде ашылады) орнына деректер арналарын алдын ала келісу.
Бұл жұмыс кеңірек экожүйеге пайдалы болуы үшін WARP жүйесін WebRTC қауымдастығындағы әріптестермен бірге ашық спецификациялар жиынтығы ретінде әзірледік. Ұсыныстарды IETF ұйымының TSVWG жұмыс тобы арқылы ілгерілетіп жатырмыз. WARP қолдауы libwebrtc мен Pion жүйелеріне қосылды, ал басқа WebRTC іске асыруларында жұмыс жалғасуда.
Медиа келісуін оңтайландырғаннан кейін бір кідіріс ерекше байқалды: WebRTC қосылмас бұрын SDP параметрлерін бөлісу үшін қолданылатын сигналдық алмасу. Бұл алмасуды шешуші жолдан шығару үшін Instant Connect деп аталатын тәсілді әзірледік. Ол сервер ресурстарын алдын ала резервтемей және қолданыстағы WebRTC іске асыруларына еш өзгеріс енгізбей, осы параметрлерді алдын ала келіседі.
Instant Connect стандартты сигналдық ағынмен қатар жұмыс істейді. Алдын ала келісілген параметрлер жарамды болса, сервер алғашқы медиа пакеті келгенде сеансты іске қоса алады. Олар ескірген немесе жарамсыз болса, сигналдық ағын әлдеқашан жүріп жатады, сондықтан клиент қосымша кідіріссіз оған қайта ауыса алады.
Instant Connect пен WARP бірге пайдаланушы ниетінен тікелей медиа ағынына дейінгі уақытты айтарлықтай қысқартады. SDP алмасуы шешуші жолдан шығарылып, WARP тасымалдау келісуін қысқартқандықтан, енді клиент сеансты бір ғана UDP пакетімен бастай алады. Сервер бірден жауап беріп, жүйенің қалған бөлігіне пайдаланушы үшін шын мәнінде маңызды жұмысты — тыңдап, жауап беруді — бастауға мүмкіндік береді.
Жүйе қағаз жүзінде жылдам көрінгенімен, нақты дауыс трафигі кезінде кідіріп қалуы мүмкін. GPT‑Live жүйесіне пайдаланушылармен сөйлесуге мүмкіндік бермес бұрын, біз өндірістік ChatGPT Voice сеанстарының шағын әрі біртіндеп ұлғайтылған үлесін қолданыстағы жетілдірілген дауыс режиміне де, жаңа жүйемізге де бағыттайтын үнсіз сынақ өткіздік. Жетілдірілген дауыс режимі пайдаланушыларға әдеттегідей қызмет көрсете берді, ал көлеңкелі арна инференсті тек оқуға арналған режимде орындады. Осылайша пайдаланушылар еститін дыбысты өзгертпей, жүйені нақты клиенттермен, желілермен, әртүрлі ұзақтықтағы сеанстармен және географиялық таралу жағдайында сынадық.
Алғашқы сабақтардың бірі — жүйенің қанша жүктемені көтере алатынын тек GPU өткізу қабілетімен анықтауға болмайтыны. Дауыс сеанстары ашық қалып, кадрларды үздіксіз жібереді, сондықтан CPU жағындағы ағын өңдегіштері, кезектер мен желілік арналар инференспен қатар ауқымдалуы керек. Нақты жүктеме кезінде қосалқы құрамдастардың бірі жүктеме сынақтарындағы болжамымыздан ертерек шегіне жетіп, инференс сұрауларының жиналуына және кідірістің біртіндеп ұлғаюына әкелді. Сондықтан «GPU қанша сұрауды өңдей алады?» деген сұрақтың орнына «Әр кадрды кестеге сай өңдей отырып, жүйе бір мезгілде қанша сеансты қолдай алады?» деген сұрақ қойдық.
Сынақ географияның да негізгі фактор екенін көрсетті. Сеансты алыстағы есептеу ресурстарына бағыттау іске қосу және ағынмен жіберу барысында бірнеше кезеңде кідіріс тудыруы мүмкін. Біз модельді енгізуді өңірлік есептеу ресурстары және трафикті бағыттау конфигурациясымен бірге тексеріп, кейін кідірісті бастапқы өңір бойынша талдай бастадық. Инференсті пайдаланушыларға жақындату көмектесті, бірақ бұл кеңірек тұжырымды да растады: басынан аяғына дейінгі жедел әрекет ету тек модель серверіне емес, жолдағы әрбір қызметке байланысты.
Басқа ақаулар тек шынайы сеанс циклдерінде байқалды. Ұзақ сеанстар жад пен тұрақты сақтау жүйесіне түсетін қысымды көрсетті. Қайта қосылу кезінде ықшамдау мен күйді қалпына келтіру сыналды. Клиенттің қалыпты ажырауы жұмысты тоқтату кезіндегі келісуде жарыс жағдайларын анықтады. Бұл мәселелер қысқа жүктеме сынақтарында сирек байқалды, өйткені олар уақытқа, жиналған күйге және қызметтер шекарасындағы әрекетке тәуелді еді.
Соңында, өндірістік ортадағы сынақ бақылау мүмкіндігі мен енгізуді басқаруды жақсартуға мәжбүр етті. Біз әртүрлі кідіріс көздерін араластыратын метрикаларды, жиынтық көрсеткіштері ақаулы жеке қозғалтқыштарды жасыратын бақылау тақталарын және сыналған әрі енгізілген жүйелер арасындағы конфигурация алшақтығын анықтадық. Оған жауап ретінде егжей-тегжейлі телеметрияны, сенімді конфигурациялармен салыстырып тексеруді, кезеңдік ауқымдауды және жеке арналарды жылдам оқшаулау не өшіру мүмкіндігін қостық. Үнсіз сынақ жүйе қабылдай алатын трафик көлемін ғана емес, ақауды қаншалықты тез анықтап, шектеп және одан қалпына келе алатынымызды тексеретін ерте іске қосу дайындығына айналды.
GPT‑Live жүйесін ChatGPT ауқымына жеткізу үшін бір негізгі қағидаға құрылған мүлде жаңа жүйе қажет болды: дауыс ағыны үзілмеуге тиіс. Ағындық инференс толық дуплексті модельге аудионы үздіксіз жеткізеді. Арнайы медиа арна кадрлардың сенімді жеткізілуін қамтамасыз етеді. Асинхронды табыстау тереңірек ойлауды қатар орындауға мүмкіндік береді. Оңтайландырылған тасымалдау пайдаланушыға дейінгі бүкіл жолда жедел әрекеттесуді сақтайды.
GPT‑Live негізіндегі архитектура қазірдің өзінде нақты уақыттағы әрекеттесуге арналған кеңірек платформаға айналып келеді. Ол ChatGPT Voice жүйесінің әңгімеден агенттік үйлестіруге дейін кеңеюін қамтамасыз етеді және алдағы GPT‑Live API негізі болады. Уақыт өте келе ол дауыстық әңгімені тірі сезіндіретін жеделдікті жоғалтпай, дауыс арқылы сөйлесу көбірек құрылғыға, қолданбаға және модалдыққа таратуға жол ашады.
Осындай инженерлік мәселелерді шешкіңіз келсе, бізге жұмысқа келіңіз.

