Ինչպես վեց ամսում ստեղծեցինք արագ արձագանքող ձայնային ԱԲ-ի իրական ժամանակի համակարգ

Ձայնային ԱԲ-ի համար խոսելու ճիշտ պահը որոշելն ավելի դժվար է, քան թվում է։ Մարդիկ վայրկյանի մի մասում առանց ջանքի խոսքը փոխանցում են միմյանց, սակայն նախորդ ձայնային ԱԲ համակարգերը չէին հասցնում հետևել այդ ռիթմին։ Նրանց հերթափոխային ճարտարապետությունը հիմնվում էր խոսքի հերթը որոշող փոքր մոդելների վրա, որոնց աննախանձելի խնդիր էր բաժին ընկել. շատ շուտ գուշակելու դեպքում օգտատիրոջ խոսքն ընդհատվում էր, իսկ ուշ գուշակելու դեպքում պատասխանը դանդաղ էր թվում։ Միայն այն բանից հետո, երբ դետեկտորը կայացնում էր իր որոշումը, շատ ավելի մեծ 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 սահմանից այն կողմ։ Դանդաղ գործիքային կանչը կամ հետին ծառայությունը կարող է ուշացնել իր արդյունքը, բայց չի կարող կանգնեցնել մեդիա հոսքը։

Այս տարանջատումը համակարգին տալիս է նաև հստակ սահման՝ հարմարեցումների համար։ Հավելվածները կարող են փոխել իրենց գործիքները, քաղաքականություններն ու բեքենդ վարքագիծը՝ չազդելով ձայնի անխափան շարժման համար պատասխանատու մեդիա ֆրոնթենդի վրա։ Իրական ժամանակի ուղին մնում է փոքր, կանխատեսելի և կենտրոնացած իրական ժամանակում պարտադիր կատարվող աշխատանքի վրա։

Մեդիա ֆրոնթենդը ու ինֆերենսի տրամաբանությունը գրեցինք 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 համայնքի մասնակիցների հետ, որպեսզի այս աշխատանքից օգտվի ամբողջ էկոհամակարգը։ Առաջարկներն առաջ ենք տանում 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-ի համար։ Ժամանակի ընթացքում այն թույլ կտա ձայնային փորձառությունները տարածել ավելի շատ սարքերի, հավելվածների և եղանակների վրա՝ չկորցնելով ձայնային զրույցին կենդանի հաղորդակցության զգացողություն տվող անմիջականությունը։

Եթե ցանկանում եք լուծել նման ինժեներական խնդիրներ, միացեք մեր թիմին⁠։