Како смо за шест месеци направили систем у реалном времену за гласовни AI са брзим одзивом

Код гласовне вештачке интелигенције, знати када треба проговорити теже је него што звучи. Људи без напора препуштају реч једни другима за делић секунде, али претходни гласовни AI системи нису могли да прате тај ритам. Њихова архитектура заснована на сменама ослањала се на мале моделе познате као детектори смене, који су имали незахвалан задатак: ако погоде прерано, прекину корисника; ако погоде прекасно, одговор делује тромо. Тек када би детектор донео одлуку, много већи велики језички модел (LLM) могао је да почне са радом.

GPT‑Live⁠, наш гласовни систем треће генерације, уклања детектор смене из аудио-путање. Његов гласовни модел је потпуно двосмеран, што значи да истовремено може да слуша и говори. Тиме се уклања потреба за засебним детектором, а разговор делује непосредније и природније. Када су потребни дубље резоновање или употреба алата, GPT‑Live може да се обрати и нашим граничним моделима, као што је GPT‑5.5, не прекидајући ток разговора. Ове могућности заједно пружају GPT‑Live систему до сада невиђен спој брзог одзива у разговору и интелигенције.

Пружање оваквог искуства у великом обиму захтевало је нову системску архитектуру оптимизовану за мало кашњење. За разлику од типичне инференције по принципу захтев–одговор, наш систем стримује долазни звук у гласовни модел, а излазни говор назад кориснику, док се делегирање обрађује засебном асинхроном путањом. Током протеклих шест месеци прерадили смо инференцију модела, управљање контекстом и пренос медија како би говор несметано текао од почетка до краја.

Архитектура такође успоставља јасну границу између основне гласовне путање и логике апликације. То омогућава лако прилагођавање понашања апликације без утицаја на брзину одзива. Ова основа покреће све већи број могућности у услузи Govorni ChatGPT, укључујући недавно уведено управљање рачунаром и координацију агената у стоној апликацији ChatGPT.

У овом тексту објаснићемо зашто ранији системи засновани на сменама нису могли да испуне наше потребе и како смо нови систем пројектовали за брз одзив на сваком слоју. Обрадићемо инференцију са стањем, динамичко управљање контекстом, асинхроно делегирање и оптимизацију на нивоу протокола — све што заједно чини да GPT‑Live делује заиста уживо.

Раније гласовне архитектуре наследиле су смене текстуалних великих језичких модела (LLM), али је свака смена била представљена као засебан аудио-блок уместо као текст. У каскадним системима, претварање говора у текст, велики језички модел (LLM) и претварање текста у говор извршавали су се редом. Тај редослед је повећавао кашњење и занемаривао сигнале као што су тон и ритам говора.

Модели за конвертовање из говора у говор унапредили су овај приступ директном обрадом звука. Обучавање модела да изворно разуме и генерише говор омогућило му је да сачува детаље који се губе у транскрипцији и брже одговара. Ипак, систем се и даље ослањао на детектор смене да одлучи када инференција може да почне. Модел је преузео већи део интеракције, али је она и даље била заснована на сменама.

GPT‑Live препушта гласовном моделу контролу над разговором: звук улази у модел и излази из њега, док се дубље резоновање и употреба алата одвијају асинхроно. Главни задатак система је да одржава непрекинут медијски ток. Остали послови, као што су позивање граничних модела и трајно чување разговора, одвијају се ван путање уживо.

Одржавање овог медијског тока без прекида није увек једноставно. Свако кашњење у преносу, обради или инференцији може се претворити у чујну паузу или сметњу. Претходни систем заснован на сменама могао је да поднесе извесна одступања у времену пристизања аудио блока. Међутим, медијски систем уживо мора сваки аудио-оквир да испоручи на време.

Ранији рад на услузи Govorni ChatGPT и Realtime API-ју пружио нам је важну основу. Већ смо изнова изградили нашу гласовну инфраструктуру⁠ како бисмо директно стримовали звук и видео у наше системе и из њих, уз мање и предвидљивије кашњење. GPT‑Live је додатно унапредио тај дизајн, стримујући медије све до модела кроз нови систем инференције са стањем, направљен за непрекидан разговор.

Ипак, стриминг инференција била је само део решења. Да би добро функционисала у продукцији, морали смо да обезбедимо и поуздану испоруку звука од клијента до система за инференцију и да решимо изазове рада са стањем.

Једна од раних одлука била је да медијски ток јасно одвојимо од апликативне и пословне логике. Звук се између клијента и гласовног модела преноси наменском брзом путањом. Делегирање, употреба алата и други задаци апликације одвијају се иза асинхроне RPC границе. Спор позив алата или позадинска услуга могу да одложе сопствени резултат, али не могу да зауставе ток медија.

Ово раздвајање систему пружа и јасну границу за прилагођавање. Апликације могу да мењају своје алате, смернице и понашање позадинских система, а да не утичу на медијски фронтенд задужен за непрекидан ток звука. Путања уживо остаје мала, предвидљива и усредсређена на послове који морају да се обаве у реалном времену.

Медијски фронтенд и логику инференције написали смо у језику Go, заменивши претходну Python имплементацију засновану на asyncio. То је знатно побољшало равномерност испоруке оквира: p95 новог система изједначио се са p50 претходног.

WebRTC пружа основу за пренос. Пројектован је за медије са малим кашњењем и може да настави са радом упркос губитку пакета, одступању часовника и променама везе клијента. Ако пакети закасне, WebRTC може неприметно да развуче звук како би спречио прекиде, а затим накратко убрза репродукцију да би поново достигао реално време.

Смањивањем баферовања и блокирања широм система можемо да постигнемо одзив краћи од секунде, какав људи очекују од разговора.

Инференција са стањем подразумева посебне оперативне компромисе. Гласовна сесија може дуго остати активна, али њен контекст непрестано расте, док се инстанце модела покрећу и гасе у складу са потражњом.

Да бисмо решили ове проблеме, направили смо механизам за неприметну примопредају између инстанци модела. Када је прелаз потребан, можемо да загрејемо заменску инстанцу модела упоредо са постојећом, унапред је попунимо тренутним контекстом сесије, паралелно покренемо инференцију на обе и пређемо на нову када буде потпуно спремна.

Исти основни механизам подржава и динамичку компакцију контекста. Како разговор одмиче, његов нагомилани контекст на крају може да премаши ограничење контекста модела. Компакција може да смањи контекст тако да стане у ограничење, али та операција захтева време. Пошто мења претходни контекст, она поништава и кеш кључева и вредности (KV) модела, у којем се чувају кључеви и вредности пажње из раније обрађених токена. Поновна изградња тог стања захтева ново почетно попуњавање и уноси додатно кашњење.

Уместо тога, компакцију третирамо као још један контролисани прелаз. Док првобитна инстанца модела наставља разговор, систем компактује контекст и припрема заменску инстанцу модела са новим контекстом. Када та инстанца буде спремна, можемо да пређемо на њу без икаквог прекида медијског тока. Тако систем може да подржи дуготрајне позиве и обави компакцију кад год је потребна.

Захтеван посао остаје ван путање уживо, па разговор тече без застоја чак и током примопредаје.

Могућност GPT‑Live система да позива постојеће граничне моделе даје му велику моћ, практично раздвајајући „говор“ од дубљег „размишљања“. Међутим, да би ова архитектура са два модела деловала као један систем, морали смо да решимо два повезана инжењерска проблема.

Прво, резултати морају да стигну довољно брзо да би били корисни у текућем разговору, па смо морали да сведемо на минимум кашњење дуж целе путање делегирања — од усмеравања и обраде инструкције до инференције и позива алата. Истовремено, другим системима у производу и даље су потребне засебне поруке, па смо разговор који је у току морали да представимо у облику који могу да разумеју.

Када пошаљемо делегирани задатак, оптимизујемо време потребно да гранични модел произведе нешто корисно за разговор. Гласовни модел може накратко да одржава разговор док гранични модел резонује или користи алате, али не може да прикрије произвољно спор одговор. Зато смо целу петљу делегирања — усмеравање, обраду инструкције, инференцију и позиве алата — укључили у временски оквир за одзив.

Прва оптимизација је припрема граничног модела и свих потребних алата пре него што се затражи делегирање. Када започне гласовна сесија, сервер апликације прави сесију инференције за гранични модел и унапред је попуњава почетним контекстом разговора, чиме обезбеђује да инструкција буде потпуно обрађена пре првог делегираног захтева.

Затим ту сесију инференције држимо доступном током целог гласовног разговора и користимо стабилну повезаност сесије за узастопне захтеве. Уз кеширање инструкција, ове технике смањују кашњење, а опоравак од квара радног процеса остаје једноставан.

Напор резоновања, ограничења излаза, шеме алата и размене између модела и алата такође утичу на то када разговор добија користан резултат, па смо та подешавања прилагодили ради бржих одговора. Смањивањем посла потребног на путањи делегирања омогућили смо гласовном моделу да брзо укључи резултате наших граничних модела.

Иако гласовни модел ради са непрекидним токовима говора, многи околни системи и даље се ослањају на смене корисника и асистента, укључујући интерфејс разговора у услузи ChatGPT и делове наше аналитичке и безбедносне инфраструктуре. Зато сервер апликације разлаже преклапајући, понекад двосмислен разговор на засебне поруке.

Док звук пристиже, сервер користи делимичне транскрипте и временске сигнале да утврди ко тренутно говори и састави ред порука. Најновија порука остаје привремена; њен текст, време и додељени говорник могу се мењати како пристиже још говора. Када говорник довољно дуго задржи реч да би приписивање било поуздано, сервер финализује одговарајућу поруку.

Преклапање говора додатно отежава овај поступак. Кратка потврда асистента док корисник говори (нпр. “mm hmm” или “okay”) не мора нужно постати засебна порука. Међутим, садржајно убацивање асистента често би требало да постане порука. Слично томе, дајемо предност кохерентности приказаних одговора асистента чак и када се корисник укључи усред одговора.

Свака политика сегментације прави компромис између ажурности и извесности. Прерано потврђивање ствара фрагментирану историју и нестабилан редослед; предуго чекање одлаже транскрипте и функције које од њих зависе. Зато систем одржава два повезана приказа разговора: привремени приказ тренутног стања и меродаван запис изговореног. Приказ разговора у корисничком интерфејсу апликације може да обрађује измене, па користи привремени приказ. Међутим, за евидентирање у аналитичком систему потребан је коначни транскрипт.

Тако остатак услуге ChatGPT добија стабилан приказ разговора без наметања смена говорника гласовној путањи уживо.

Брз одзив почиње чим корисник кликне на дугме. Уз GPT‑Live, систем мора да успостави медијску путању и почне да прослеђује звук кроз модел пре него што разговор може да почне. Зато се сваки део поступка покретања налази на критичној путањи.

Као што је већ речено, WebRTC пружа снажну основу за рад у реалном времену, али покретање стандардне WebRTC сесије захтева изненађујуће много протоколарних руковања и повратних путовања кроз мрежу. WebRTC је настао пре него што су каснији протоколи, попут QUIC-а, почели да се обликују око смањивања броја повратних мрежних путовања. Због тога његови основни протоколи понекад понављају исти посао када се користе заједно. На пример, сваки протокол је имао сопствени механизам заштите од DoS напада, чак и када он није био потребан у контексту целог WebRTC система.

Анализирали смо систем и развили WebRTC Abridged Roundtrip Protocol (WARP⁠(отвара се у новом прозору)), који покретање медија и података скраћује са шест повратних мрежних путовања на само једно. WARP то постиже скупом уназад компатибилних побољшања протокола: преношењем DTLS руковања преко ICE-а (SPED⁠(отвара се у новом прозору)), коришћењем бржег DTLS 1.3⁠(отвара се у новом прозору) руковања, унапред договореним SCTP руковањем (SNAP⁠(отвара се у новом прозору)) и унапред договореним каналима за податке уместо коришћења DCEP-а⁠(отвара се у новом прозору).

WARP смо осмислили као скуп отворених спецификација, сарађујући са члановима WebRTC заједнице, како би шири екосистем имао користи од овог рада. Предлоге унапређујемо кроз радну групу TSVWG организације IETF, а подршка за WARP већ је додата у libwebrtc и Pion, док је рад на другим WebRTC имплементацијама у току.

Након оптимизације медијског руковања, издвојило се још једно кашњење: размена сигнализације којом се деле SDP параметри пре него што WebRTC може да се повеже. Да бисмо ту размену уклонили са критичне путање, развили смо решење које називамо Instant Connect. Оно унапред договара те параметре без резервисања серверских капацитета и без икаквих измена постојећих WebRTC имплементација.

Instant Connect ради упоредо са стандардним током сигнализације. Ако су унапред договорени параметри важећи, сервер може да успостави сесију када стигне први медијски пакет. Ако су застарели или неважећи, ток сигнализације је већ у току, па клијент може да пређе на резервни поступак без додатног кашњења.

Instant Connect и WARP заједно драстично скраћују време од намере корисника до покретања медијског тока уживо. Пошто је SDP размена уклоњена са критичне путање, а WARP објединио руковање преносом, клијент сада може да покрене сесију једним UDP пакетом. Сервер може одмах да одговори, омогућавајући остатку система да започне посао до којег је кориснику заиста стало: слушање и одговарање.

Систем на папиру може деловати брзо, а ипак застати под стварним гласовним саобраћајем. Пре него што смо омогућили да GPT‑Live разговара са корисницима, спровели смо тихи тест који је мали, постепено повећаван удео продукционих сесија услуге Govorni ChatGPT усмеравао и ка постојећем режиму напредног гласа и ка нашем новом систему. Режим напредног гласа је наставио да услужује кориснике као и обично, док је паралелна путања обављала инференцију у режиму само за читање. Тако смо систем изложили стварним клијентима, мрежама, трајањима сесија и географској расподели, не мењајући оно што су корисници чули.

Једна од првих лекција била је да се капацитет не може свести на пропусну моћ GPU-а. Гласовне сесије остају отворене и непрекидно шаљу оквире, па руковаоци токовима на CPU страни, редови и мрежне путање морају да се скалирају упоредо са инференцијом. Под стварним оптерећењем, помоћна компонента достигла је засићење раније него што су предвиђале наше процене из тестова оптерећења, па су се захтеви за инференцију нагомилавали, а кашњење увећавало. Питање о капацитету променили смо са „Колико захтева GPU може да обради?“ на „Колико истовремених сесија систем може да одржи, а да сваки оквир стигне на време?“

Тест је показао и да географија мора бити један од главних приоритета. Усмеравање сесије ка удаљеним капацитетима може изазвати кашњење у више тачака током покретања и стримовања. Почели смо да проверавамо увођење модела заједно са регионалним капацитетима и конфигурацијом усмеравања саобраћаја, а затим да рашчлањујемо кашњење према географији извора. Приближавање инференције корисницима помогло је, али је потврдило и ширу поуку: одзив од почетка до краја зависи од сваке услуге на путањи, а не само од сервера модела.

Други кварови јављали су се само током реалистичних животних циклуса сесија. Дуготрајне сесије откриле су оптерећење меморије и трајног складиштења. Поновна повезивања ставила су на пробу компакцију и обнављање стања. Уобичајена прекидања везе клијената открила су услове трке у руковању гашењем. Ови проблеми ретко су се јављали у кратким тестовима оптерећења јер су зависили од времена, нагомиланог стања и понашања преко граница услуга.

На крају, тестирање у продукцији приморало нас је да побољшамо опсервабилност и контроле увођења. Пронашли смо метрике које су мешале различите изворе кашњења, контролне табле чији су збирни подаци скривали појединачне неисправне погоне и разлике у конфигурацији између тестираних и примењених система. Зато смо додали детаљнију телеметрију, проверу у односу на поуздане конфигурације, постепено увођење и могућност брзог изоловања или онемогућавања појединачних путања. Тихи тест постао је рана проба покретања — не само количине саобраћаја коју систем може да прихвати већ и брзине којом можемо да откријемо, ограничимо и отклонимо квар.

Довођење GPT‑Live система на ниво обима услуге ChatGPT захтевало је потпуно нов систем изграђен око једног основног начела: глас мора да тече. Стриминг инференција непрекидно снабдева двосмерни модел звуком. Наменска медијска путања обезбеђује поуздану испоруку оквира. Асинхроно делегирање омогућава да се дубље размишљање одвија паралелно. Оптимизован пренос одржава брз одзив све до корисника.

Архитектура на којој почива GPT‑Live већ прераста у ширу платформу за интеракцију у реалном времену. Она покреће Govorni ChatGPT док се он шири са разговора на координацију агената, а биће и основа предстојећег GPT‑Live API-ја. Временом ће омогућити да гласовна искуства обухвате више уређаја, апликација и модалитета, без губитка непосредности због које гласовни разговор делује као да се заиста одвија уживо.

Ако желите да решавате овакве инжењерске проблеме, придружите нам се⁠.