Hvernig OpenAI skilar raddgervigreind með lítilli töf í stórum stíl

Raddgervigreind finnst aðeins eðlileg ef samtal færist á hraða talmálsins. Þegar netið truflar heyra notendur það strax sem óþægilegar pásur, afklipptar truflanir eða seinkað innskot. Það skiptir máli fyrir raddvirkni í ChatGPT, fyrir forritara sem byggja með Realtime API, fyrir fulltrúa sem vinna í gagnvirkum verkflæðum og fyrir líkön sem þurfa að vinna úr hljóði á meðan notandi er enn að tala.

Í þeim stærðargráðum sem OpenAI vinnur á þýðir það þrjár skýrar kröfur:

• Alþjóðlegt umfang fyrir meira en 900 milljónir virkra notenda á viku
• Hröð uppsetning tengingar svo notandi geti byrjað að tala um leið og lota hefst
• Lágur og stöðugur hringferðatími miðla, með litlu flökti og litlu pakkatapi, svo víxl í samtali verði snör og skýr

Teymið hjá OpenAI sem ber ábyrgð á gagnvirkum gervigreindarsamskiptum í rauntíma endurhannaði nýlega WebRTC-staflann okkar til að leysa þrjár skorður sem fóru að rekast saman í þessum stærðargráðum: miðlalokun með einu porti fyrir hverja lotu hentar innviðum OpenAI illa, ástandsmiðaðar ICE (Interactive Connectivity Establishment)- og DTLS (Datagram Transport Layer Security)-lotur þurfa stöðugt eignarhald, og alþjóðleg leiðarstýring þarf að halda töf á fyrsta hoppi lágri. Í þessari færslu förum við yfir skipta relay plus transceiver-arkitektúrinn sem við byggðum til að viðhalda hefðbundinni WebRTC-hegðun fyrir biðlara á meðan við breyttum því hvernig pökkum er beint innan innviða OpenAI.

WebRTC er opinn staðall til að senda hljóð, mynd og gögn með lítilli töf milli vafra, farsímaforrita og netþjóna. Hann er oft tengdur jafningjasímtölum, en er líka hagnýtur grunnur fyrir rauntímakerfi milli biðlara og netþjóns því hann staðlar erfiðu þættina í gagnvirkum miðlum: ICE fyrir uppsetningu tengingar og NAT (Network Address Translation)-yfirferð, DTLS og SRTP (Secure Real-time Transport Protocol) fyrir dulkóðaðan flutning, samningagerð um merkjamál fyrir þjöppun og afkóðun hljóðs, RTCP (Real-time Transport Control Protocol) fyrir gæðastýringu og eiginleika á biðlarahlið eins og bergmálsdeyfingu og flöktjöfnun.

Þessi stöðlun skiptir máli fyrir gervigreindarvörur. Án WebRTC þyrfti hver biðlari mismunandi lausn til að koma á tengingu yfir NAT, dulkóða miðla, semja um merkjamál (kóðara og afkóðara sem valdir eru fyrir sendingu og afþjöppun) og aðlagast breyttum netskilyrðum. Með WebRTC getum við byggt á samskiptastafla sem þegar er útfærður í vöfrum og á farsímakerfum og einbeitt okkar vinnu að innviðunum sem tengja rauntímamiðla við líkön.

Við byggjum líka á WebRTC-vistkerfinu sjálfu, þar á meðal þroskuðum opnum innleiðingum og þeirri staðlavinnu sem heldur vöfrum, farsímaforritum og netþjónum samhæfðum. Grunnvinna Justin Uberti (eins af upprunalegum arkitektum WebRTC) og Sean DuBois (höfundar og umsjónaraðila Pion) gerði teymum eins og okkar kleift að byggja á vel reynslumiklum miðlainnviðum í stað þess að enduruppfinna hegðun á lágu stigi fyrir flutning, dulkóðun og stíflustýringu. Við erum heppin að bæði Justin og Sean eru nú samstarfsfélagar okkar hér hjá OpenAI og hjálpa til við að móta hvernig við færum WebRTC og rauntímagervigreind nær hvort öðru.

Fyrir gervigreind er mikilvægasti eiginleikinn sá að hljóð berist sem samfelldur straumur. Talsambærilegur fulltrúi getur byrjað að umrita, rökræða, kalla á verkfæri eða búa til tal á meðan notandinn er enn að tala, í stað þess að bíða eftir fullu upphali. Það er munurinn á kerfi sem finnst samtalslegt og kerfi sem minnir á ýta-og-tala.

Þegar við höfðum valið WebRTC var næsta spurning hvar ætti að ljúka því (þar sem við myndum taka við og eiga WebRTC-tenginguna, til dæmis á jaðrinum) og hvernig ætti að tengja þessar lotur við ályktunarbakendann. Lokun skiptir máli því hún ræður því hvernig við meðhöndlum ástand rauntímalota, miðlaflutning, leiðarstýringu, töf og einangrun bilana.

SFU, eða selective forwarding unit, er miðlanetþjónn sem tekur við einum WebRTC-straumi frá hverjum þátttakanda og sendir valda strauma áfram til hinna. Í þessu líkani lýkur SFU sérstakri WebRTC-tengingu fyrir hvern þátttakanda og gervigreindin tengist sem annar þátttakandi í lotunni. Það getur hentað vel fyrir vörur sem eru í eðli sínu með marga þátttakendur, svo sem hópsímtöl, kennslustundir eða samvinnufundi. Þá eru hljóðmerkjamál, RTCP-skilaboð, gagnarásir, upptaka og stefna fyrir hvern straum á einum stað.¹

Jafnvel í vörum milli biðlara og gervigreindar er SFU oft sjálfgefinn upphafspunktur því það gerir teymum kleift að endurnýta eitt sannreynt kerfi fyrir merkjagjöf, miðlaleiðarstýringu, upptöku, sýnileika og framtíðarviðbætur eins og að færa samskipti yfir til manneskju eða bæta við fleiri þátttakendum.

Álagið okkar er öðruvísi. Flestar lotur eru 1:1 — einn notandi sem talar við eitt líkan, eða eitt forrit sem talar við einn fulltrúa í rauntíma — með næmi fyrir töf í hverju víxli. Fyrir þessa umferðargerð völdum við transceiver-líkanið: WebRTC-jaðarþjónusta lýkur biðlaratengingunni og umbreytir síðan miðlum og atburðum í einfaldari innri samskiptareglur fyrir líkanaályktun, umritun, talmyndun, verkfæranotkun og stýringu.

Í þessari hönnun er transceiver eina þjónustan sem á ástand WebRTC-lotunnar, þar á meðal ICE-tengiprófanir, DTLS-handabandið, SRTP-dulkóðunarlykla og lífsferil lotunnar. „Lokun“ merkir hér að transceiver er endapunkturinn sem klárar þessi handabönd og dulkóðar eða afkóðar miðlana. Að halda þessu ástandi á einum stað gerði eignarhald lota auðveldara að skilja, og það lét bakendaþjónustur skala eins og venjulegar þjónustur í stað þess að haga sér sjálfar eins og WebRTC-jafningjar.

Eftir að hafa valið transceiver-líkanið var fyrsta innleiðingin okkar ein Go-þjónusta byggð á Pion sem sá bæði um merkjagjöf og miðlalokun. Hún knýr raddvirkni ChatGPT, WebRTC-endapunkt Realtime API og fjölda rannsóknarverkefna.

Í rekstri sinnir transceiver-þjónustan tveimur hlutverkum:

• Merkjagjöf: SDP-samningar, val á merkjamáli, ICE-skilríki og uppsetning lotu
• Miðlar: Lýkur niðurstreymandi WebRTC-tengingum og viðheldur uppstreymandi tengingum við bakendaþjónustur fyrir ályktun og stýringu

Við vildum að þjónustan keyrði eins og aðrir innviðir okkar: á Kubernetes, þar sem álag getur skalað upp og niður og færst milli hýsa eftir því sem eftirspurn breytist. En hefðbundna WebRTC-líkanið með einu porti fyrir hverja lotu hentar því umhverfi illa, því það byggir á stórum sviðum af opinberum UDP-portum sem erfitt er að birta, verja og viðhalda þegar poddum er bætt við, þeir fjarlægðir eða endurraðað.²

Fyrsta vandamálið var sjálft líkanið með einu porti fyrir hverja lotu. Við mikla samtímisnotkun þýðir það að birta og stjórna mjög stórum sviðum af UDP-portum.

• Skýjaálagsdreifarar og Kubernetes-þjónustur eru ekki hannaðar fyrir tugþúsundir opinberra UDP-porta á hverja þjónustu. Hvert viðbótarsvið eykur rekstrarflækju í stillingum álagsdreifara, heilsuprófunum, eldveggsstefnu og öryggi útgáfa.³
• Stór svið af UDP-portum eru erfið í vörnum því þau stækka það yfirborð sem hægt er að ná utan frá og gera netstefnu erfiðari í úttekt.
• Þau henta líka illa sjálfvirkri stigvaxningu. Poddum er stöðugt bætt við, þeir fjarlægðir og endurraðað í Kubernetes. Að krefjast þess að hver poddi fráteki og auglýsi stórt stöðugt portsvið gerir slíkan sveigjanleika brothættan.⁴

Þess vegna færa mörg WebRTC-kerfi sig í átt að einu UDP-porti fyrir hvern netþjón, með afmargföldun á forritsstigi á bak við það port.⁵

Hönnun með einu porti á netþjón leysir fjölda porta, en hún kynnir annað vandamál: að varðveita eignarhald hverrar lotu yfir þyrpingu kerfa.

ICE og DTLS eru ástandsmiðaðar samskiptareglur. Ferlið sem bjó til lotu þarf áfram að taka við pökkum þeirrar lotu svo það geti sannreynt tengiprófanir, lokið DTLS-handabandinu, afkóðað SRTP og unnið úr síðari breytingum á lotu eins og ICE-endurræsingum. Ef pakkar fyrir sömu lotu lenda hjá öðru ferli getur uppsetning misfarist eða miðlar rofnað.

Það gaf okkur skýrt markmið: að birta lítið, fast UDP-yfirborð á opna internetið en samt beina hverjum pakka til þess transceiver sem á viðkomandi WebRTC-lotu.

Við metum nokkrar leiðir til að ná þessu, þar á meðal TURN (Traversal Using Relays around NAT), þar sem jaðarrelay lýkur úthlutunum biðlara og sendir umferð áfram fyrir þeirra hönd.²

Arkitektúrinn sem við settum í notkun skiptir pakkaleiðarstýringu frá lokun samskiptareglna. Merkjagjöf nær enn til transceiver fyrir uppsetningu lotu, á meðan miðlar fara fyrst inn um relay. Relay er létt UDP-framsendingarlag með litlu opinberu yfirborði og transceiver er ástandsmiðaður WebRTC-endapunktur á bak við það.

Relay afkóðar ekki miðla, keyrir ekki ICE-ástandsvélar og tekur ekki þátt í samningagerð um merkjamál. Það les næg metagögn úr pökkum til að velja áfangastað og sendir síðan pakkann áfram til þess transceiver sem á lotuna. Transceiver sér því enn eðlilegt WebRTC-flæði og á áfram allt ástand samskiptareglna. Frá sjónarhóli biðlarans breytist ekkert við WebRTC-lotuna.

Leiðarstýring fyrsta pakkans er lykilskrefið í þessari uppsetningu. Relay þarf að beina fyrsta pakkanum frá biðlara áður en nokkur lota er til á sjálfri pakkaleiðinni, frekar en að stöðva á ytri uppflettiþjónustu.

Hver WebRTC-lota ber nú þegar innbyggðan krókhengil fyrir leiðarstýringu: ICE-notandabrotsstrenginn, eða ufrag, stutt auðkenni sem skipt er á við uppsetningu lotu og er endurtekið í STUN-tengiprófunum. Við búum til ufrag þjónshliðarinnar þannig að það innihaldi rétt næg leiðarstýringarmetagögn til að relay geti ráðið áfangaklasann og þann transceiver sem á lotuna.

Við merkjagjöf úthlutar transceiver ástandi lotu og skilar sameiginlegu relay-VIP og UDP-porti í SDP-svarinu. VIP er sýndar-IP-tala sem stendur framan við relay-þyrpinguna; ásamt portinu gefur hún biðlaranum einn stöðugan áfangastað, til dæmis 203.0.113.10:3478, þótt mörg relay-tilvik sitji á bak við hann. Fyrsti pakki biðlarans á miðlaleiðinni er yfirleitt STUN (Session Traversal Utilities for NAT) bindingarbeiðni, sem ICE notar til að sannreyna að pakkar geti náð auglýstu vistfangi.

Relay þáttar nægilega mikið af þessum fyrsta STUN-pakka til að lesa ufrag þjónsins, afkóða leiðarstýringarvísbendinguna og senda pakkann áfram til þess transceiver sem á lotuna. Hver transceiver hlustar á sameiginlegri UDP-sökkli, það er einum endapunkti stýrikerfis sem er bundinn innri IP-tölu og porti, ekki einum sökkli fyrir hverja lotu. Eftir að relay býr til lotu frá uppruna-IP-tölu og porti biðlarans yfir á áfangastað transceiver flæða síðari DTLS-, RTP- og RTCP-pakkar innan lotunnar án þess að ufrag þurfi að afkóða aftur.

Lota relay er viljandi mjög einföld og samanstendur aðeins af lotu í minni sem upplýsir pakkaframsendingu, ásamt nauðsynlegum teljurum fyrir vöktun og tímastillum fyrir lok lotu og tiltekt. Þessi hönnun heldur pakkaleiðarstýringu beint á pakkaleiðinni. Ef relay endurræsist og missir lotuna endurbyggir næsti STUN-pakki lotuna út frá leiðarstýringarvísbendingunni í ufrag. Til að gera þetta enn áreiðanlegra er Redis-skiminni notað til að geyma vörpunina <IP-tala + port biðlara, IP-tala + port transceiver> þegar leiðin hefur verið staðfest svo hægt sé að endurheimta hana mun fyrr, áður en næsti STUN-pakki berst.

Þegar við höfðum minnkað opinbera UDP-yfirborðið niður í lítinn fjölda stöðugra vistfanga og porta gátum við dreift sama relay-mynstri á heimsvísu. Global Relay er þyrping okkar af landfræðilega dreifðum relay-inngangspunktum sem allir útfæra sömu hegðun fyrir pakkaframsendingu.

Víð landfræðileg innleiðing styttir fyrsta hoppið frá biðlara til OpenAI því pakki getur farið inn á net okkar um relay nálægt notandanum, bæði landfræðilega og í netfræðilegri legu, í stað þess að fara fyrst yfir opna internetið til fjarlægs svæðis. Í reynd þýðir það minni töf, minna flökt og færri taphrinur sem mætti annars forðast áður en umferð nær burðarnetinu okkar.⁶

Við notum Cloudflare geo- og nálægðarstýringu fyrir merkjagjöf svo fyrsta HTTP- eða WebSocket-beiðnin nái til nærliggjandi transceiver-klasa. Samhengi beiðninnar ræður staðsetningu lotunnar og hvaða Global Relay-inngangspunktur er auglýstur til biðlarans. SDP-svarið gefur upp vistfang Global Relay, á meðan ufrag inniheldur nægar upplýsingar fyrir Global Relay til að leiða miðla til tilnefnds klasa og fyrir relay til að leiða áfram til áfangatransceiver.

Saman setja landfræðilega stýrð merkjagjöf og Global Relay bæði uppsetningu og miðla á nálæga inngönguleið á meðan lotan helst bundin við einn transceiver. Það dregur úr hringferðatíma fyrir merkjagjöf og fyrir fyrstu ICE-tengiprófunina, sem styttir beint þann tíma sem notandi bíður áður en tal getur hafist.

Við skrifuðum relay-þjónustuna í Go og héldum innleiðingunni viljandi afmarkaðri. Á Linux tekur netstafli kjarnans við UDP-pökkum frá netviðmóti vélarinnar og skilar þeim til sökkuls, endapunkts stýrikerfis sem ferli les úr eftir að hafa bundið IP-tölu og port. Relay keyrir í notendarými, þannig að venjulegt Go-ferli les pakkahausa úr þeim sökkli, uppfærir lítið magn flæðisástands og sendir pakka áfram án þess að ljúka WebRTC. Við þurftum enga umgjörð til að komast fram hjá kjarnanum, sem myndi leyfa ferli í notendarými að kanna raðir netkerfisins beint fyrir hærri pakkahraða en myndi líka bæta við rekstrarflækju.

Lykilákvarðanir í hönnun:

• Engin lokun samskiptareglna: Relay þáttar aðeins STUN-hausa/ufrag; fyrir síðari DTLS-, RTP- og RTCP-pakka notar það skyndiminni ástands og heldur pökkum ógagnsæjum.
• Tímabundið ástand: Það heldur úti litlu korti í minni með stuttum tímamörkum frá vistfangi biðlara yfir á áfangastað transceiver fyrir flæðisástand og sýnileika.
• Lárétt stigvaxni: Mörg relay-tilvik keyra samhliða á bak við álagsdreifara. Ástandið er ekki hart WebRTC-ástand, svo endurræsingar valda litlu umferðartapi og fljótri endurheimt flæðis.

Skilvirkniaðgerðir:

• SO_REUSEPORT er Linux-sökkulvalkostur sem leyfir mörgum relay-vinnsluþráðum á sömu vél að binda sama UDP-portið. Kjarninn dreifir síðan innkomnum pökkum á þessa vinnsluþræði, sem kemur í veg fyrir að einn lestrarlykkja verði flöskuháls.
• runtime.LockOSThread festir hverja goroutine sem les UDP við ákveðinn OS-þráð. Ásamt SO_REUSEPORT hefur það tilhneigingu til að halda pökkum úr sama flæði (uppruna- og áfangastaðar IP:port ásamt samskiptareglu) á sama CPU-kjarna, sem bætir skyndiminnisstaðsetningu og dregur úr samhengisskiptum.
• Forúthlutaðir biðlar og lágmörkuð afritun halda þáttun og úthlutunarkostnaði lágum til að forðast sorphirðu í Go.

Þessi innleiðing annaðist alþjóðlega rauntímamiðlaumferð okkar með tiltölulega litlu relay-fótspori, svo við héldum okkur við einfaldari hönnunina í stað þess að taka á okkur leið fram hjá kjarnanum.

Þessi arkitektúr gerir okkur kleift að reka WebRTC-miðla í Kubernetes án þess að birta þúsundir UDP-porta. Það skiptir máli því minna og fast UDP-yfirborð er auðveldara að verja og dreifa álagi yfir, og það gerir innviðunum kleift að skala án þess að frátekin séu stór svið af opinberum portum. Með betri stuðningi innviða frá Kubernetes og meira öryggi vegna minna yfirborðs viðheldur þessi hönnun líka hefðbundinni WebRTC-hegðun fyrir biðlara og staðfestir að hönnun án SFU var rétt sjálfgefin leið fyrir okkar álag. Flestar lotur okkar eru punktur-til-punkts, viðkvæmar fyrir töf og auðveldari í stigvaxningu þegar ályktunarþjónustur þurfa ekki sjálfar að haga sér eins og WebRTC-jafningjar.

Víðari lærdómurinn er að best er að bæta flækju við þunnt leiðarstýringarlag, ekki við hverja bakendaþjónustu og ekki í sérsniðna hegðun biðlara. Að umrita leiðarstýringarmetagögn í innbyggðan reit samskiptareglu gaf okkur ákvörðuð leið fyrir fyrsta pakka, lítið opinbert UDP-fótspor og nægan sveigjanleika til að staðsetja inngang nær notendum um allan heim.

Nokkur val voru sérstaklega mikilvæg:

• Varðveita merkingarfræði samskiptareglna á jaðrinum. Biðlarar tala enn hefðbundið WebRTC, sem heldur samhæfni milli vafra og farsíma óskertri.
• Halda erfiðu lotuástandi á einum stað. Transceiver á ICE, DTLS, SRTP og lífsferil lotunnar; relay sendir aðeins pakka áfram.
• Leiðarstýra með upplýsingum sem þegar eru til staðar við uppsetningu. ICE ufrag gaf okkur krókhengil fyrir fyrsta pakka án þess að bæta við háð á uppflettingu á heitri leið.
• Fínstilla fyrir algengasta tilvikið áður en farið er í lausnir fram hjá kjarnanum. Afmörkuð Go-innleiðing með varkárri notkun á SO_REUSEPORT, þráðafestingu og lágri úthlutun við þáttun dugði fyrir okkar álag.

Rauntíma raddgervigreind virkar aðeins þegar innviðir láta töfina verða ósýnilega. Fyrir okkur þýddi það að breyta lögun WebRTC-uppsetningar okkar án þess að breyta því sem biðlarar vænta af WebRTC sjálfu.