Jinsi OpenAI inavyowasilisha voice AI yenye ucheleweshaji mdogo kwa kiwango kikubwa

Voice AI huhisi ya asili tu ikiwa mazungumzo yanaenda kwa kasi ya usemi. Mtandao unapozuia, watu husikia mara moja kama kimya kisicho cha kawaida, kukatizwa kwa ghafla, au kuingilia kwa kuchelewa. Hilo ni muhimu kwa sauti ya ChatGPT, kwa wasanidi wanaojenga kwa Realtime API, kwa wakala wanaofanya kazi katika mtiririko shirikishi, na kwa miundo inayohitaji kuchakata sauti mtumiaji akiwa bado anaongea.

Kwa kiwango cha OpenAI, hilo hutafsiriwa kuwa mahitaji matatu halisi:

• Ufikiaji wa kimataifa kwa zaidi ya watumiaji amilifu milioni 900 kila wiki
• Uanzishaji wa muunganisho wa haraka ili mtumiaji aanze kuongea mara tu kipindi kinapoanza
• Muda mdogo na thabiti wa kutuma na kupokea mawasiliano, kukiwa na mabadiliko madogo ya ucheleweshaji na upotevu mdogo wa data, ili kubadilishana zamu kuwe rahisi

Timu ya OpenAI inayosimamia mwingiliano wa AI wa wakati halisi hivi karibuni ilibuni upya stack yetu ya WebRTC kushughulikia vikwazo vitatu vilivyoanza kugongana kwa kiwango kikubwa: kukomesha media kwa mlango mmoja kwa kila kipindi hakulingani vyema na miundombinu ya OpenAI, vipindi vya ICE (Interactive Connectivity Establishment) na DTLS (Datagram Transport Layer Security) vyenye hali vinahitaji umiliki thabiti, na uelekezaji wa kimataifa lazima uweke usubiri wa hatua ya kwanza chini. Katika chapisho hili, tunaeleza usanifu wa mgawanyo wa relay pamoja na transceiver tuliounda ili kuhifadhi tabia ya kawaida ya WebRTC kwa wateja huku tukibadilisha jinsi paketi zinaelekezwa ndani ya miundombinu ya OpenAI.

WebRTC ni kiwango huria cha kutuma sauti, video, na data zenye usubiri mdogo kati ya vivinjari, programu za simu, na seva. Mara nyingi huhusishwa na simu za peer-to-peer, lakini pia ni msingi wa vitendo kwa mifumo ya wakati halisi ya mteja hadi seva kwa sababu huweka viwango vya sehemu ngumu za media shirikishi: ICE kwa uanzishaji wa muunganisho na upitiaji wa NAT (Network Address Translation), DTLS na SRTP (Secure Real-time Transport Protocol) kwa usafirishaji uliosimbwa, majadiliano ya codec kwa kubana na kufasiri sauti, RTCP (Real-time Transport Control Protocol) kwa udhibiti wa ubora, na vipengele vya upande wa mteja kama kufuta mwangwi na kuhifadhi jitter.

Uwekaji huo wa viwango ni muhimu kwa bidhaa za AI. Bila WebRTC, kila mteja angehitaji jibu tofauti la jinsi ya kuanzisha muunganisho kupitia NAT, kusimba media, kujadiliana codec (visimbaji na vifyonzaji vilivyochaguliwa kwa utumaji na ufunguaji), na kuzoea hali za mtandao zinazobadilika. Kwa WebRTC, tunaweza kujenga juu ya stack ya itifaki ambayo tayari imetekelezwa katika vivinjari na majukwaa ya simu, tukielekeza kazi yetu kwenye miundombinu inayounganisha media ya wakati halisi na miundo.

Pia tunajenga juu ya mfumo wa WebRTC wenyewe, ikijumuisha utekelezaji uliokomaa wa open-source na kazi ya viwango inayoweka vivinjari, programu za simu, na seva zikiweza kushirikiana. Kazi ya msingi ya Justin Uberti (mmoja wa wasanifu wa awali wa WebRTC) na Sean DuBois (muundaji na mdumishaji wa Pion) iliwezesha timu kama yetu kujenga juu ya miundombinu ya media iliyojaribiwa badala ya kubuni upya tabia ya usafirishaji wa kiwango cha chini, usimbaji, na udhibiti wa msongamano. Tuna bahati kwamba Justin na Sean sasa ni wenzetu hapa OpenAI, wakisaidia kuelekeza jinsi tunavyoleta WebRTC na AI ya wakati halisi karibu zaidi.

Kwa AI, sifa muhimu zaidi ni kwamba sauti inafika kama mkondo endelevu. Wakala wa kuzungumza anaweza kuanza kunakili, kuwaza, kutuma ombi la kutumia zana, au kuzalisha usemi wakati mtumiaji bado anaongea, badala ya kusubiri upakiaji kamili. Hiyo ndiyo tofauti kati ya mfumo unaoonekana kuwa wa mazungumzo ya kawaida na ule unaoonekana kama push-to-talk.

Baada ya kuchagua WebRTC, swali lililofuata lilikuwa ni mahali pa kuikomesha (mahali ambapo tungepokea na kumiliki muunganisho wa WebRTC—kwa mfano, ukingoni) na jinsi ya kuunganisha vipindi hivyo na backend ya inference. Ukomezaji ni muhimu kwa sababu unaamua jinsi tunavyoshughulikia hali ya kipindi cha wakati halisi, usafirishaji wa media, uelekezaji, usubiri, na utenganishaji wa hitilafu.

SFU, au selective forwarding unit, ni seva ya media inayopokea mkondo mmoja wa WebRTC kutoka kwa kila mshiriki na kusambaza kwa kuchagua mikondo kwa wengine. Katika muundo huu, SFU hukomesha muunganisho tofauti wa WebRTC kwa kila mshiriki, na AI hujiunga kama mshiriki mwingine katika kipindi hicho. Hilo linaweza kufaa kwa bidhaa ambazo kiasili zina washiriki wengi, kama simu za vikundi, madarasa, au mikutano ya ushirikiano. Huweka codec za sauti, ujumbe wa RTCP, njia za data, kurekodi, na sera ya kila mkondo katika sehemu moja.¹

Hata katika bidhaa za mteja hadi AI, SFU mara nyingi huwa mwanzo wa chaguo-msingi kwa sababu huwezesha timu kutumia tena mfumo mmoja uliothibitishwa kwa signaling, uelekezaji wa media, kurekodi, observability, na upanuzi wa baadaye kama kuhamishia kwa binadamu au kuongeza washiriki zaidi.

Mzigo wetu wa kazi ni tofauti. Vipindi vingi ni 1:1—mtumiaji mmoja akizungumza na muundo mmoja, au programu moja ikizungumza na wakala mmoja wa wakati halisi—na unyeti wa usubiri katika kila zamu. Kwa umbo hilo la trafiki, tulichagua muundo wa transceiver: huduma ya ukingo ya WebRTC hukomesha muunganisho wa mteja kisha kubadilisha media na matukio kuwa itifaki rahisi za ndani kwa inference ya muundo, unukuzi, uzalishaji wa usemi, matumizi ya zana, na uratibu.

Katika muundo huu, transceiver ndiyo huduma pekee inayomiliki hali ya kipindi cha WebRTC, ikijumuisha ukaguzi wa muunganisho wa ICE, handshake ya DTLS, funguo za usimbaji za SRTP, na mzunguko wa maisha wa kipindi. “Ukomezaji” hapa unamaanisha kwamba transceiver ndiyo mwisho unaokamilisha handshakes hizo na kusimba au kufungua usimbaji wa media. Kuweka hali hiyo katika sehemu moja kulifanya umiliki wa kipindi uwe rahisi zaidi kueleweka, na kuliruhusu huduma za backend kupanuka kama huduma za kawaida badala ya kutenda kama peer za WebRTC zenyewe.

Baada ya kuchagua muundo wa transceiver, utekelezaji wetu wa kwanza ulikuwa huduma moja ya Go iliyojengwa juu ya Pion iliyoshughulikia signaling na ukomezaji wa media. Inaiendesha sauti ya ChatGPT, mwisho wa WebRTC wa Realtime API, na miradi kadhaa ya utafiti.

Kiutendaji, huduma ya transceiver hufanya kazi mbili:

• Signaling: majadiliano ya SDP, uchaguzi wa codec, uthibitisho wa ICE, na usanidi wa kipindi
• Media: kukomesha miunganisho ya chini ya WebRTC na kudumisha miunganisho ya juu kwa huduma za backend kwa inference na uratibu

Tulitaka huduma iendeshwe kama miundombinu yetu mingine yote: kwenye Kubernetes, ambapo kazi inaweza kuongezeka na kupungua, na kuhama kati ya hosti kadiri mahitaji yanavyobadilika. Lakini muundo wa kawaida wa WebRTC wa mlango mmoja kwa kila kipindi hauendani vizuri na mazingira hayo, kwa sababu unategemea safu kubwa za milango ya umma ya UDP ambazo ni ngumu kufichua, kulinda, na kuhifadhi wakati pod zinapoongezwa, kuondolewa, au kupangwa upya.²

Tatizo la kwanza lilikuwa muundo wenyewe wa mlango mmoja kwa kila kipindi. Katika concurrency ya juu, hilo linamaanisha kufichua na kusimamia safu kubwa sana za milango ya UDP.

• Vipatanisha mzigo vya wingu na huduma za Kubernetes hazijaundwa kuhimili maelfu ya milango ya UDP ya umma kwa kila huduma. Kila safu ya ziada huongeza ugumu wa uendeshaji katika usanidi wa load balancer, ukaguzi wa afya, sera ya firewall, na usalama wa utoaji.³
• Safu kubwa za milango ya UDP ni ngumu kulinda kwa sababu huongeza uso unaofikika kutoka nje na kufanya sera ya mtandao kuwa ngumu zaidi kukaguliwa.
• Pia haziendani vizuri na autoscaling. Pods huongezwa, huondolewa, na hupangwa upya kila mara katika Kubernetes. Kuhitaji kila pod ihifadhi na kutangaza safu kubwa thabiti ya milango hufanya unyumbufu huo kuwa dhaifu.⁴

Ndiyo maana mifumo mingi ya WebRTC huelekea mlango mmoja wa UDP kwa kila seva, pamoja na utenganishaji wa kiwango cha programu nyuma ya mlango huo.⁵

Miundo ya mlango mmoja kwa kila seva husuluhisha idadi ya milango, lakini huleta tatizo la pili: kuhifadhi umiliki wa kila kipindi katika kundi la seva.

ICE na DTLS ni itifaki zenye hali. Mchakato uliounda kipindi unahitaji kuendelea kupokea paketi za kipindi hicho ili uweze kuthibitisha ukaguzi wa muunganisho, kukamilisha handshake ya DTLS, kufungua usimbaji wa SRTP, na kushughulikia mabadiliko ya baadaye ya kipindi kama kuanzishwa upya kwa ICE. Ikiwa paketi za kipindi hicho hicho zitaishia kwenye mchakato tofauti, usanidi unaweza kushindwa au media inaweza kuvunjika.

Hilo lilitupa lengo mahususi: kufichua uso mdogo, thabiti wa UDP kwa intaneti ya umma, huku bado tukielekeza kila paketi kwa transceiver inayomiliki kipindi husika cha WebRTC.

Tulitathmini njia kadhaa za kufika hapo, ikijumuisha TURN (Traversal Using Relays around NAT), ambapo relay ya ukingo hukomesha mgao wa mteja na kusambaza trafiki kwa niaba yake.²

Usanifu tuliotoa hugawa uelekezaji wa paketi na ukomezaji wa itifaki. Signaling bado hufika kwa transceiver kwa ajili ya usanidi wa kipindi, huku media ikiingia kwanza kupitia relay. Relay ni safu nyepesi ya usambazaji ya UDP yenye uso mdogo wa umma, na transceiver ni mwisho wa WebRTC wenye hali ulio nyuma yake.

Relay haifungui usimbaji wa media, haiendeshi mashine za hali za ICE, wala haishiriki katika majadiliano ya codec. Husoma metadata ya paketi ya kutosha kuchagua unakoenda, kisha husambaza paketi kwa transceiver inayomiliki kipindi. Transceiver bado huona mtiririko wa kawaida wa WebRTC na bado humiliki hali yote ya itifaki. Kwa mtazamo wa mteja, hakuna chochote kuhusu kipindi cha WebRTC kinachobadilika.

Uelekezaji wa paketi ya kwanza ndio hatua muhimu katika usanidi huu. Relay lazima ielekeze paketi ya kwanza kutoka kwa mteja kabla ya kipindi chochote kuwepo kwenye njia ya paketi yenyewe badala ya kusimama kwenye huduma ya nje ya kutafuta.

Kila kipindi cha WebRTC tayari kina njia ya uelekezaji asilia ya itifaki: kipande cha jina la mtumiaji cha ICE, au ufrag, kitambulisho kifupi kinachobadilishanwa wakati wa usanidi wa kipindi na kurudiwa katika ukaguzi wa muunganisho wa STUN. Tunazalisha ufrag ya upande wa seva ili iwe na metadata ya uelekezaji ya kutosha tu kwa relay kubaini klasta lengwa na transceiver mmiliki.

Wakati wa signaling, transceiver hutenga hali ya kipindi na kurudisha relay VIP ya pamoja na mlango wa UDP katika jibu la SDP. VIP ni anwani pepe ya IP inayowakilisha kundi la relay; ikiunganishwa na mlango, humpa mteja mwisho mmoja thabiti, kama `203.0.113.10:3478`, hata kama kuna vielelezo vingi vya relay nyuma yake. Paketi ya kwanza ya mteja kwenye njia ya media kwa kawaida huwa ombi la STUN (Session Traversal Utilities for NAT) binding, ambalo ICE hutumia kuthibitisha kwamba paketi zinaweza kufika kwenye anwani iliyotangazwa.

Relay huchambua kiasi kidogo tu cha paketi hiyo ya kwanza ya STUN ili kusoma ufrag ya seva, kufasiri kidokezo cha uelekezaji, na kusambaza paketi kwa transceiver mmiliki. Kila transceiver husikiliza kwenye soketi ya UDP ya pamoja, ikimaanisha mwisho mmoja wa mfumo wa uendeshaji uliounganishwa na IP:mlango ya ndani, si soketi moja kwa kila kipindi. Baada ya relay kuunda kipindi kutoka kwa IP:mpango ya chanzo ya mteja hadi transceiver inayolengwa, paketi zinazofuata za DTLS, RTP, na RTCP hutiririka ndani ya kipindi bila kufasiri upya ufrag.

Kipindi cha relay kimewekwa kuwa kidogo sana kimakusudi, kikijumuisha tu kipindi cha kumbukumbu ya ndani kinachoelekeza usambazaji wa paketi, pamoja na vihesabu muhimu vya ufuatiliaji na vipima muda vya kuisha kwa kipindi na usafishaji. Chaguo hili la usanifu hudumisha uelekezaji wa paketi moja kwa moja kwenye njia ya paketi. Relay ikianza upya na kupoteza kipindi, paketi inayofuata ya STUN hujenga upya kipindi kutoka kwa kidokezo cha uelekezaji cha ufrag. Ili kuifanya iwe ya kuaminika zaidi, cache ya Redis hutumika kushikilia ulinganifu wa <IP ya mteja + Mlango, IP ya transceiver + Mlango> mara tu njia inapowekwa ili iweze kurejeshwa mapema zaidi, kabla paketi inayofuata ya STUN haijafika.

Mara tulipopunguza uso wa umma wa UDP hadi idadi ndogo ya anwani na milango thabiti, tuliweza kutumia mfumo uleule wa relay kimataifa. Global Relay ni kundi letu la sehemu za kuingilia za relay zilizosambazwa kijiografia ambazo zote hutekeleza tabia ileile ya kusambaza paketi.

Uingizaji mpana wa kijiografia hupunguza hatua ya kwanza kutoka kwa mteja hadi OpenAI kwa sababu paketi inaweza kuingia kwenye mtandao wetu katika relay iliyo karibu na mtumiaji, kwa jiografia na topolojia ya mtandao, badala ya kuvuka intaneti ya umma hadi eneo la mbali kwanza. Kwa vitendo, hilo humaanisha usubiri mdogo, jitter ndogo, na milipuko michache ya upotevu inayoweza kuepukika kabla trafiki haijafika kwenye uti wa mgongo wa mtandao wetu.⁶

Tunatumia uelekezaji wa Cloudflare geo na proximity kwa signaling ili ombi la awali la HTTP au WebSocket lifike kwenye klasta ya transceiver iliyo karibu. Muktadha wa ombi huamua eneo la kipindi na sehemu ya kuingilia ya Global Relay inayotangazwa kwa mteja. Jibu la SDP hutoa anwani ya Global Relay, huku ufrag ikiwa na taarifa za kutosha kwa Global Relay kuelekeza media kwenye klasta iliyoteuliwa na kwa relay kuelekeza kwa transceiver lengwa.

Pamoja, signaling inayoelekezwa kijiografia na Global Relay huweka usanidi na media kwenye njia ya karibu ya kuingia huku zikiweka kipindi kikiwa kimeunganishwa kwa transceiver moja. Hilo hupunguza muda wa kwenda na kurudi kwa signaling na kwa ukaguzi wa kwanza wa muunganisho wa ICE, jambo ambalo hupunguza moja kwa moja muda ambao mtumiaji husubiri kabla ya usemi kuanza.

Tuliandika huduma ya relay kwa Go na tukadumisha utekelezaji mwembamba kimakusudi. Kwenye Linux, stack ya mtandao ya kernel hupokea paketi za UDP kutoka kwa kiolesura cha mtandao cha mashine na kuzipeleka kwenye soketi, mwisho wa mfumo wa uendeshaji ambao mchakato husoma baada ya kuunganisha IP:Mlango. Relay huendeshwa katika userspace, kwa hivyo mchakato wa kawaida wa Go husoma vichwa vya paketi kutoka kwenye soketi hiyo, husasisha kiasi kidogo cha hali ya mtiririko, na husambaza paketi bila kukomesha WebRTC. Hatukuhitaji mfumo wowote wa kernel-bypass, ambao ungesaidia mchakato wa userspace kuchunguza foleni za mtandao moja kwa moja kwa ajili ya kasi kubwa ya pakiti lakini pia ungeongeza ugumu wa uendeshaji.

Chaguo kuu za usanifu:

• Hakuna ukomezaji wa itifaki: Relay huchambua vichwa vya STUN/ufrag pekee; hutumia hali ya cache kwa DTLS, RTP, na RTCP zinazofuata, na hivyo kuweka paketi zikiwa opaque.
• Hali ya muda mfupi: Hudumisha ramani ndogo ya ndani ya kumbukumbu, yenye muda mfupi wa kuisha, ya anwani ya mteja hadi sehemu lengwa ya transceiver kwa hali ya mtiririko na observability.
• Upanuzi mlalo: Vielelezo vingi vya relay huendeshwa sambamba nyuma ya load balancer. Hali si hali ngumu ya WebRTC, kwa hivyo kuanza upya husababisha trafiki ndogo na urejeshaji wa haraka wa mtiririko.

Hatua za ufanisi:

• SO_REUSEPORT ni chaguo la soketi la Linux linaloruhusu wafanyakazi wengi wa relay kwenye mashine moja kuunganisha mlango uleule wa UDP. Kisha kernel husambaza paketi zinazoingia kati ya wafanyakazi hao, jambo linalozuia mkwamo wa mzunguko mmoja wa kusoma.
• runtime.LockOSThread hufunga kila goroutine inayosoma UDP kwenye thread maalum ya OS. Ikichanganywa na SO_REUSEPORT, hilo huwa na mwelekeo wa kuweka paketi kutoka mtiririko uleule (IP:Mlango ya chanzo na sehemu lengwa pamoja na itifaki) kwenye kiini kilekile cha CPU, kuboresha ukaribu wa cache na kupunguza kubadilisha muktadha.
• Buffer zilizotengwa mapema na kunakili kidogo huweka gharama ya uchambuzi na ugawaji chini ili kuepuka garbage collection katika Go.

Utekelezaji huu ulishughulikia trafiki yetu ya kimataifa ya media ya wakati halisi kwa footprint ndogo ya relay, kwa hivyo tuliendelea na muundo rahisi badala ya kuchukua njia ya kernel bypass.

Usanifu huu hutuwezesha kuendesha media ya WebRTC katika Kubernetes bila kufichua maelfu ya milango ya UDP. Hilo ni muhimu kwa sababu uso mdogo na thabiti wa UDP ni rahisi zaidi kulinda na kusawazisha mzigo, na huiruhusu miundombinu kupanuka bila kuhifadhi safu kubwa za milango ya umma. Kwa usaidizi bora wa miundombinu kutoka Kubernetes na usalama zaidi kutokana na uso mdogo, muundo huu pia huhifadhi tabia ya kawaida ya WebRTC kwa wateja na kuthibitisha kwamba muundo usio na SFU ulikuwa chaguo sahihi la msingi kwa kazi yetu. Vipindi vyetu vingi ni point-to-point, inahitaji kasi ya haraka, na ni rahisi kupanua wakati huduma za inference hazihitaji kujiendesha kama peer za WebRTC.

Somo pana zaidi ni kwamba mahali bora pa kuongeza ugumu ni katika safu nyembamba ya uelekezaji, si katika kila huduma ya backend, wala katika tabia maalum ya mteja. Kusimba metadata ya uelekezaji ndani ya sehemu asilia ya itifaki kulitupatia uelekezaji wa paketi ya kwanza wa uhakika, footprint ndogo ya umma ya UDP, na unyumbufu wa kutosha kuweka sehemu za kuingilia karibu na watumiaji duniani kote.

Chaguo chache zilikuwa muhimu hasa:

• Hifadhi semantics za itifaki ukingoni. Wateja bado huzungumza WebRTC ya kawaida, jambo linalohifadhi ushirikiano wa vivinjari na simu.
• Weka hali ngumu za kipindi katika sehemu moja. Transceiver inamiliki ICE, DTLS, SRTP, na mzunguko wa maisha wa kipindi; relay husambaza paketi tu.
• Elekeza kwa taarifa ambayo tayari ipo katika usanidi. Ufrag ya ICE ilitupatia njia ya kuelekeza paketi ya kwanza bila kuongeza utegemezi wa utafutaji katika njia kuu ya usindikaji.
• Boresha kwa hali ya kawaida kabla ya kufikia kernel bypass. Utekelezaji mwembamba wa Go wenye matumizi makini ya SO_REUSEPORT, thread pinning, na uchambuzi wa ugawaji mdogo ulitosha kwa kazi yetu.

Voice AI ya wakati halisi hufanya kazi tu wakati miundombinu inafanya ucheleweshaji usisikike. Kwetu,hiyo ilimaanisha kubadilisha muundo wa mfumo wetu wa WebRTC bila kubadilisha kile ambacho wateja wanakitarajia kutoka kwenye WebRTC yenyewe.