ხმოვანი ხელოვნური ინტელექტისთვის იმის განსაზღვრა, როდის ილაპარაკოს, იმაზე რთულია, ვიდრე ჩანს. ადამიანები ერთმანეთს სიტყვას წამის მცირე მონაკვეთში ძალდაუტანებლად გადასცემენ, წინა ხმოვანი AI სისტემები კი ამ რიტმს ვერ მიჰყვებოდნენ. მათი მონაცვლეობაზე დაფუძნებული არქიტექტურა იყენებდა მცირე მოდელებს, რომლებსაც მონაცვლეობის დეტექტორები ეწოდება და რთული ამოცანა ჰქონდათ: თუ ნაადრევად გამოიცნობდნენ, მომხმარებელს სიტყვას აწყვეტინებდნენ; თუ დააგვიანებდნენ, პასუხი ნელი ჩანდა. ბევრად უფრო დიდ LLM-ს მუშაობის დაწყება მხოლოდ დეტექტორის გადაწყვეტილების შემდეგ შეეძლო.
ჩვენი მესამე თაობის ხმოვანი სისტემა GPT‑Live მონაცვლეობის დეტექტორს აუდიოს მარშრუტიდან იღებს. მისი ხმოვანი მოდელი სრულდუპლექსიანია, რაც ერთდროულად მოსმენასა და ლაპარაკს ნიშნავს. ეს ცალკე დეტექტორის საჭიროებას აქრობს და საუბარს უფრო უშუალოსა და ბუნებრივს ხდის. როცა უფრო ღრმა მსჯელობა ან ხელსაწყოს გამოყენებაა საჭირო, GPT‑Live‑ს შეუძლია საუბრის ნაკადის შეუფერხებლად მიმართოს ჩვენს მოწინავე მოდელებს, მაგალითად GPT‑5.5‑ს. ერთობლივად ეს შესაძლებლობები GPT‑Live‑ს საუბრისას სწრაფი რეაგირებისა და ინტელექტის უპრეცედენტო შეხამებას აძლევს.
ამ გამოცდილების ფართო მასშტაბით მიწოდებას მცირე დაყოვნებაზე ოპტიმიზებული ახალი სისტემური არქიტექტურა დასჭირდა. ჩვეულებრივი მოთხოვნა-პასუხის ინფერენსისგან განსხვავებით, ჩვენი სისტემა შემომავალ აუდიოს ხმოვან მოდელში, ხოლო გამომავალ მეტყველებას მომხმარებლისკენ სტრიმავს; დელეგირებას კი ცალკე ასინქრონული მარშრუტით ამუშავებს. ბოლო ექვს თვეში მოდელის ინფერენსი, კონტექსტის მართვა და მედიის გადაცემა გადავამუშავეთ, რათა მეტყველება თავიდან ბოლომდე შეუფერხებლად მიედინებოდეს.
ეს არქიტექტურა ძირითად ხმოვან მარშრუტსა და აპლიკაციურ ლოგიკას შორის მკაფიო საზღვარსაც ქმნის. ამის წყალობით აპლიკაციის ქცევა რეაგირების სისწრაფეზე ზემოქმედების გარეშე მარტივად ირგება. ეს საფუძველი ChatGPT‑ის ხმოვან რეჟიმში შესაძლებლობების მზარდ სპექტრს უზრუნველყოფს, მათ შორის ახლახან გაშვებულ ფუნქციას, რომლითაც ChatGPT‑ის დესკტოპის აპში კომპიუტერს მართავთ და აგენტების მუშაობას ათანხმებთ.
ამ სტატიაში ავხსნით, რატომ ვერ აკმაყოფილებდა ჩვენს საჭიროებებს წინა, მონაცვლეობაზე დაფუძნებული სისტემები და როგორ შევქმენით ახალი სისტემა, რომელიც ყველა დონეზე სწრაფად რეაგირებს. განვიხილავთ მდგომარეობის მქონე ინფერენსს, კონტექსტის დინამიკურ მართვას, ასინქრონულ დელეგირებასა და პროტოკოლის დონის ოპტიმიზაციას, რომლებიც ერთად GPT‑Live‑ს ნამდვილად ცოცხალს ხდის.
ადრეულმა ხმოვანმა არქიტექტურებმა ტექსტური LLM-ების მონაცვლეობითი ბუნება გადაიღო, თუმცა თითოეული რეპლიკა ტექსტის ნაცვლად ცალკე აუდიობლობით იყო წარმოდგენილი. კასკადურ სისტემებში მეტყველების ტექსტად გარდაქმნა, LLM და ტექსტის მეტყველებად გარდაქმნა თანმიმდევრულად სრულდებოდა. ეს თანმიმდევრობა დაყოვნებას ზრდიდა და ხმის ტონისა და ტემპის მსგავს მინიშნებებს უგულებელყოფდა.
მეტყველების გარდაქმნა მეტყველებად მოდელებმა აუდიოს უშუალოდ დამუშავებით ეს მიდგომა გააუმჯობესა. მეტყველების ბუნებრივად გაგებასა და გენერირებაზე მოდელის გაწვრთნამ ტრანსკრიფციისას დაკარგული დეტალების შენარჩუნებისა და უფრო სწრაფად პასუხის შესაძლებლობა მოგვცა. თუმცა ინფერენსის დაწყების დროის განსაზღვრისას სისტემა კვლავ მონაცვლეობის დეტექტორს ეყრდნობოდა. მოდელი ურთიერთქმედების მეტ ნაწილს ამუშავებდა, მაგრამ ურთიერთქმედება კვლავ მონაცვლეობითი იყო.
GPT‑Live საუბარზე ზედამხედველობას ხმოვან მოდელს აკისრებს: აუდიო მოდელში და მოდელიდან უწყვეტად მიედინება, უფრო ღრმა მსჯელობა, ხელსაწყოების გამოყენება კი ასინქრონულად სრულდება. სისტემის მთავარი ამოცანა მედიის უწყვეტი ციკლის შენარჩუნებაა. სხვა სამუშაო, როგორიცაა მოწინავე მოდელების გამოძახება და საუბრის შენახვა, ცოცხალი მარშრუტის მიღმა სრულდება.
მედიის ამ ციკლის შეუფერხებლად შენარჩუნება ყოველთვის მარტივი არ არის. გადაცემის, დამუშავების ან ინფერენსის ნებისმიერმა დაყოვნებამ შეიძლება გასაგონი პაუზა ან არტეფაქტი წარმოქმნას. წინა, მონაცვლეობაზე დაფუძნებულ სისტემას აუდიო მონაცემების მიღების დროის გარკვეული ცვალებადობის ატანა შეეძლო. თუმცა ცოცხალი მედიის სისტემამ თითოეული აუდიოკადრი ზუსტად დროულად უნდა მიაწოდოს.
ChatGPT‑ის ხმოვან რეჟიმსა და Realtime API-ზე ადრეულმა მუშაობამ მნიშვნელოვანი საფუძველი მოგვცა. ჩვენ უკვე თავიდან გვქონდა აგებული ხმოვანი ინფრასტრუქტურა, რათა აუდიო და ვიდეო პირდაპირ სისტემებში და სისტემებიდან უფრო მცირე და პროგნოზირებადი დაყოვნებით გაგვესტრიმა. GPT‑Live-მა ეს დიზაინი კიდევ უფრო განავითარა: უწყვეტი საუბრისთვის შექმნილი ახალი, მდგომარეობის მქონე ინფერენსის სისტემით მედია უშუალოდ მოდელამდე მიედინება.
თუმცა სტრიმინგული ინფერენსი გადაწყვეტის მხოლოდ ნაწილი იყო. საწარმოო გარემოში გამართული მუშაობისთვის ასევე უნდა უზრუნველგვეყო აუდიოს საიმედო მიწოდება კლიენტიდან ინფერენსის სტეკამდე და მდგომარეობის შენარჩუნებასთან დაკავშირებული სირთულეები გადაგვეჭრა.
ერთ-ერთი ადრეული გადაწყვეტილება მედიის ნაკადის აპლიკაციური და ბიზნეს ლოგიკისგან მკაფიოდ გამოყოფა იყო. აუდიო კლიენტსა და ხმოვან მოდელს შორის გამოყოფილი სწრაფი მარშრუტით მოძრაობს. დელეგირება, ხელსაწყოების გამოყენება და სხვა აპლიკაციური სამუშაო ასინქრონული RPC საზღვრის მიღმა სრულდება. ხელსაწყოს ნელმა გამოძახებამ ან ბეკენდის სერვისმა შეიძლება საკუთარი შედეგი დააყოვნოს, მაგრამ მედიის ნაკადს ვერ შეაჩერებს.
ეს გამიჯვნა სისტემას მორგებისთვის მკაფიო საზღვარსაც აძლევს. აპლიკაციებს შეუძლიათ შეცვალონ ხელსაწყოები, წესები და ბეკენდის ქცევა ისე, რომ აუდიოს უწყვეტობაზე პასუხისმგებელ მედიის ფრონტენდზე გავლენა არ მოახდინონ. ცოცხალი მარშრუტი მცირე, პროგნოზირებადი და მხოლოდ რეალურ დროში შესასრულებელ სამუშაოზე ორიენტირებული რჩება.
მედიის ფრონტენდი და ინფერენსის ლოგიკა Go-ში დავწერეთ და Python-ის წინა asyncio იმპლემენტაცია ჩავანაცვლეთ. ამან კადრების მიწოდების თანაბრობა მნიშვნელოვნად გააუმჯობესა: ახალი სისტემის p95 წინა სისტემის p50-ს გაუტოლდა.
გადაცემის საფუძველს WebRTC ქმნის. ის მცირე დაყოვნებით მედიის გადასაცემადაა შექმნილი და მუშაობას პაკეტების დაკარგვის, საათების აცდენისა და კლიენტის კავშირის ცვლილებების დროსაც აგრძელებს. თუ პაკეტები გვიან მოდის, WebRTC-ს შეუძლია აუდიო შეუმჩნევლად გაწელოს, რათა წყვეტა აიცილოს, შემდეგ კი დაკვრა მცირე ხნით დააჩქაროს და რეალურ დროს დაეწიოს.
მთელ სისტემაში ბუფერიზაციისა და ბლოკირების მინიმუმამდე დაყვანით ვაღწევთ წამზე ნაკლებ რეაგირებას, რასაც ადამიანები საუბრისგან ელიან.
მდგომარეობის მქონე ინფერენსს თავისი საოპერაციო კომპრომისები ახლავს. ხმოვანი სესია შეიძლება დიდხანს დარჩეს აქტიური, თუმცა მისი კონტექსტი უწყვეტად იზრდება, მოდელის ეგზემპლარები კი მოთხოვნის მიხედვით ირთვება და ითიშება.
ამ საკითხების გადასაჭრელად მოდელის ეგზემპლარებს შორის შეუმჩნეველი გადაცემის მექანიზმი შევქმენით. როცა გადასვლაა საჭირო, არსებულის პარალელურად შემცვლელი მოდელის ეგზემპლარს ვათბობთ, მიმდინარე სესიის კონტექსტით წინასწარ ვავსებთ, ინფერენსს ორივეზე პარალელურად ვასრულებთ და სრულ მზადყოფნაში მყოფ ახალ ეგზემპლარზე გადავდივართ.
იგივე ძირითადი მექანიზმი კონტექსტის დინამიკურ შეკუმშვასაც უზრუნველყოფს. საუბრის გაგრძელებისას დაგროვილმა კონტექსტმა საბოლოოდ შეიძლება მოდელის კონტექსტის ლიმიტს გადააჭარბოს. შეკუმშვას შეუძლია კონტექსტი ლიმიტის ფარგლებში მოაქციოს, თუმცა ამ ოპერაციას დრო სჭირდება. რადგან ის წარსულ კონტექსტს ცვლის, ასევე აუქმებს მოდელის გასაღები-მნიშვნელობის (KV) ქეშს, რომელშიც ადრე დამუშავებული token-ების ყურადღების მექანიზმი და მნიშვნელობები ინახება. ამ მდგომარეობის ხელახლა აგებას ახალი წინასწარი შევსება სჭირდება, რაც დამატებით დაყოვნებას იწვევს.
ამის ნაცვლად, შეკუმშვას კიდევ ერთ მართვად გადასვლად განვიხილავთ. სანამ მოდელის თავდაპირველი ეგზემპლარი საუბარს აგრძელებს, სისტემა კონტექსტს კუმშავს და ახალი კონტექსტით შემცვლელ ეგზემპლარს ამზადებს. როგორც კი ეს ეგზემპლარი მზად იქნება, მასზე მედიის ყოველგვარი წყვეტის გარეშე გადავდივართ. ეს სისტემას ხანგრძლივი ზარების მხარდაჭერისა და საჭიროებისამებრ შეკუმშვის საშუალებას აძლევს.
რთული სამუშაო ცოცხალი მარშრუტის მიღმა სრულდება, ამიტომ საუბარი გადაცემის დროსაც კი არ წყდება.
არსებული მოწინავე მოდელების გამოძახების შესაძლებლობა GPT‑Live‑ს დიდ ძალას ანიჭებს და „ლაპარაკს“ უფრო ღრმა „აზროვნებისგან“ ფაქტობრივად აცალკევებს. თუმცა ამ ორმოდელიანი არქიტექტურის ერთიან სისტემად აღსაქმელად ორი დაკავშირებული საინჟინრო პრობლემის გადაჭრა იყო საჭირო.
დელეგირება უფრო სიღრმისეული სამუშაოსთვის
GPT-Live სწრაფ და ბუნებრივ პასუხებს უზრუნველყოფს, ხოლო GPT-5.5 ძიებას ფონურ რეჟიმში ამუშავებს
პირველ რიგში, შედეგი მიმდინარე საუბრისთვის გამოსადეგად საკმარისად სწრაფად უნდა დაბრუნებულიყო, ამიტომ დაყოვნება დელეგირების მთელ მარშრუტზე შევამცირეთ — მარშრუტიზაციიდან და მოთხოვნის დამუშავებიდან ინფერენსამდე და ხელსაწყოების გამოძახებამდე. ამავე დროს, პროდუქტის სხვა სისტემებს კვლავ ცალკეული შეტყობინებები სჭირდება, ამიტომ მიმდინარე საუბარი მათთვის გასაგები ფორმით უნდა წარმოგვედგინა.
დელეგირების გაგზავნისას ვცდილობთ, მოწინავე მოდელმა საუბრისთვის სასარგებლო შედეგი რაც შეიძლება სწრაფად შექმნას. ხმოვან მოდელს შეუძლია საუბარი მცირე ხნით გააგრძელოს, სანამ მოწინავე მოდელი მსჯელობს ან ხელსაწყოებს იყენებს, თუმცა უსასრულოდ ნელ პასუხს ვერ დამალავს. ამიტომ დელეგირების სრული ციკლი — მარშრუტიზაცია, მოთხოვნის დამუშავება, ინფერენსი და ხელსაწყოების გამოძახება — რეაგირების დროის ბიუჯეტის ნაწილად მივიჩნიეთ.
პირველი ოპტიმიზაცია მოწინავე მოდელისა და საჭირო ხელსაწყოების დელეგირების მოთხოვნამდე მომზადებაა. ხმოვანი სესიის დაწყებისას აპლიკაციის სერვერი მოწინავე მოდელისთვის ინფერენსის სესიას ქმნის და მას საუბრის საწყისი კონტექსტით წინასწარ ავსებს, რათა პირველი დელეგირებული მოთხოვნის მიღებამდე მოთხოვნა სრულად იყოს დამუშავებული.
შემდეგ ინფერენსის ამ სესიას მთელი ხმოვანი საუბრის განმავლობაში ვინარჩუნებთ და მომდევნო მოთხოვნებისთვის სესიის სტაბილურ მიბმას ვიყენებთ. მოთხოვნის ქეშირებასთან ერთად ეს მეთოდები დაყოვნებას აუმჯობესებს, ხოლო მუშა პროცესის ხარვეზისგან აღდგენა მარტივი რჩება.
საუბრისთვის სასარგებლო შედეგის მიღების დროზე ასევე მოქმედებს მსჯელობის ძალისხმევა, გამომავალი მონაცემების ლიმიტები, ხელსაწყოების სქემები და მოდელსა და ხელსაწყოს შორის მიმოცვლა; უფრო სწრაფი პასუხებისთვის ეს პარამეტრებიც დავარეგულირეთ. დელეგირების მარშრუტზე საჭირო სამუშაოს შემცირებით ხმოვან მოდელს ჩვენი მოწინავე მოდელების შედეგების სწრაფად გამოყენების საშუალება მივეცით.
მიუხედავად იმისა, რომ ხმოვანი მოდელი მეტყველების უწყვეტ ნაკადებზე მუშაობს, მის გარშემო არსებული ბევრი სისტემა კვლავ მომხმარებლისა და ასისტენტის მონაცვლეობით რეპლიკებს იყენებს, მათ შორის ChatGPT‑ის საუბრის ინტერფეისი და ჩვენი ანალიტიკური და უსაფრთხოების ინფრასტრუქტურის ნაწილები. ამიტომ აპლიკაციის სერვერი ერთმანეთზე გადაფარულ და ზოგჯერ ორაზროვან საუბარს ცალკეულ შეტყობინებებად ყოფს.
აუდიოს მიღებისას სერვერი ნაწილობრივი ტრანსკრიპტებისა და დროითი სიგნალების საფუძველზე ადგენს, რომელი მოსაუბრის ჯერია, და შეტყობინებების რიგს ქმნის. უახლესი შეტყობინება დროებითია: დამატებითი მეტყველების მიღებისას შეიძლება შეიცვალოს მისი ტექსტი, დრო და მოსაუბრეზე მიკუთვნება. როდესაც მოსაუბრე საკმარისად დიდხანს ინარჩუნებს სიტყვას და მიკუთვნება სანდო ხდება, სერვერი შესაბამის შეტყობინებას საბოლოო სახეს აძლევს.
მოსაუბრეების ხმის გადაფარვა ამას ართულებს. მომხმარებლის საუბრისას ასისტენტის მოკლე დასტური (მაგალითად, „ოჰ“ ან „ოკეი“) ყოველთვის ცალკე შეტყობინებად არ უნდა იქცეს. თუმცა ასისტენტის შინაარსიანი ჩართვა ხშირად ცალკე შეტყობინება უნდა იყოს. ასევე პრიორიტეტს ვანიჭებთ ასისტენტის ნაჩვენები პასუხების თანმიმდევრულობას მაშინაც კი, როცა მომხმარებელი შუაში ერთვება.
სეგმენტაციის ყველა წესი სიახლესა და სიზუსტეს შორის კომპრომისს გულისხმობს. ნაადრევად დაფიქსირება ფრაგმენტულ ისტორიასა და არასტაბილურ თანმიმდევრობას ქმნის; ზედმეტად ხანგრძლივი ლოდინი კი ტრანსკრიპტებსა და მათზე დამოკიდებულ ფუნქციებს აყოვნებს. ამიტომ სისტემა საუბრის ორ დაკავშირებულ ხედს ინარჩუნებს: მიმდინარე მდგომარეობის წინასწარ ხედსა და ნათქვამის ავტორიტეტულ ჩანაწერს. აპლიკაციის ინტერფეისში საუბრის ხედს განახლებების დამუშავება შეუძლია, ამიტომ ის წინასწარ ხედს იყენებს. ანალიტიკის კონვეიერში ჩასაწერად კი საბოლოო ტრანსკრიპტია საჭირო.
ამგვარად, ChatGPT‑ის დანარჩენ ნაწილს საუბრის სტაბილური ხედი აქვს, ცოცხალ ხმოვან მარშრუტს კი მონაცვლეობითი საუბარი არ ეხვევა თავს.
სწრაფი რეაგირება მომხმარებლის მიერ ღილაკზე დაწკაპუნებისთანავე იწყება. GPT‑Live-ის შემთხვევაში საუბრის დაწყებამდე სისტემამ მედიის მარშრუტი უნდა დაამყაროს და აუდიოს მოდელში მიწოდება დაიწყოს. ამიტომ გაშვების თანმიმდევრობის თითოეული ნაწილი კრიტიკულ მარშრუტზე ხვდება.
როგორც ზემოთ აღვნიშნეთ, WebRTC რეალურ დროში მუშაობისთვის ძლიერ საფუძველს ქმნის, თუმცა სტანდარტული WebRTC სესიის დაწყებას გასაოცრად ბევრი პროტოკოლური შეთანხმება და ქსელური ორმხრივი მიმოცვლა სჭირდება. WebRTC შეიქმნა მანამდე, სანამ ორმხრივი მიმოცვლის შემცირებაზე აქცენტი QUIC-ის მსგავს შემდგომ პროტოკოლებს ჩამოაყალიბებდა. ამის გამო მისი საბაზისო პროტოკოლები ერთად გამოყენებისას ზოგჯერ ერთსა და იმავე სამუშაოს იმეორებს. მაგალითად, თითოეულ პროტოკოლს საკუთარი DoS-ის საწინააღმდეგო მექანიზმი ჰქონდა, მაშინაც კი, როცა WebRTC-ის სრული სტეკის კონტექსტში ის საჭირო არ იყო.
სტეკი გავაანალიზეთ და შევქმენით WebRTC Abridged Roundtrip Protocol (WARP(იხსნება ახალ ფანჯარაში)), რომელიც მედიისა და მონაცემების გაშვებას ექვსი ქსელური ორმხრივი მიმოცვლიდან ერთამდე ამცირებს. WARP ამას უკუთავსებადი პროტოკოლური გაუმჯობესებებით აღწევს: DTLS შეთანხმების ICE-ზე თანდართვით (SPED(იხსნება ახალ ფანჯარაში)), უფრო სწრაფი DTLS 1.3(იხსნება ახალ ფანჯარაში) შეთანხმების გამოყენებით, SSCTP-ის დამყარების პროცესის წინასწარი მოლაპარაკებით (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‑ის ხმოვანი რეჟიმის საწარმოო სესიების მცირე და თანდათან მზარდ ნაწილს ერთდროულად ვამისამართებდით როგორც არსებულ გაუმჯობესებულ ხმის რეჟიმში, ისე ჩვენს ახალ სისტემაში. გაუმჯობესებული ხმის რეჟიმი მომხმარებლებს ჩვეულებრივ ემსახურებოდა, ჩრდილოვანი არხი კი ინფერენსს მხოლოდ წაკითხვის რეჟიმში ასრულებდა. ამგვარად, მომხმარებლების მოსმენილი პასუხების შეუცვლელად სისტემა რეალური კლიენტების, ქსელების, სხვადასხვა ხანგრძლივობის სესიებისა და გეოგრაფიული განაწილების პირობებში გამოვცადეთ.
ერთ-ერთი პირველი გაკვეთილი იყო, რომ სიმძლავრე მხოლოდ GPU-ის მწარმოებლურობით ვერ განისაზღვრებოდა. ხმოვანი სესიები ღია რჩება და კადრებს უწყვეტად აგზავნის, ამიტომ CPU-ზე მომუშავე ნაკადების დამმუშავებლები, რიგები და ქსელური მარშრუტებიც ინფერენსთან ერთად უნდა მასშტაბირდებოდეს. რეალური დატვირთვისას ერთ-ერთმა დამხმარე კომპონენტმა გაჯერების ზღვარს დატვირთვის ტესტით ნავარაუდევზე ადრე მიაღწია, რის გამოც ინფერენსის მოთხოვნები დაგროვდა და დაყოვნება გაძლიერდა. სიმძლავრის შესახებ კითხვა „რამდენ მოთხოვნას გაუმკლავდება GPU?“ შევცვალეთ კითხვით: „რამდენ ერთდროულ სესიას გაუძლებს სისტემა ისე, რომ თითოეული კადრი დროულად დამუშავდეს?“
ტესტმა ასევე აჩვენა, რომ გეოგრაფიას უპირველესი მნიშვნელობა ჰქონდა. სესიის შორეულ სიმძლავრეზე გადამისამართებამ შეიძლება დაყოვნება გაშვებისა და სტრიმინგის რამდენიმე ეტაპზე გაზარდოს. მოდელების განახლებების შემოწმება რეგიონულ სიმძლავრესა და ტრაფიკის მარშრუტიზაციის კონფიგურაციასთან ერთად დავიწყეთ, შემდეგ კი დაყოვნება წყაროს გეოგრაფიის მიხედვით დავყავით. ინფერენსის მომხმარებლებთან მიახლოება დაგვეხმარა, თუმცა უფრო ფართო გაკვეთილიც გაამყარა: სრული სისტემის რეაგირების სისწრაფე მარშრუტში მონაწილე ყველა სერვისზეა დამოკიდებული და არა მხოლოდ მოდელის სერვერზე.
სხვა ხარვეზები მხოლოდ სესიის რეალისტური სასიცოცხლო ციკლის განმავლობაში იჩენდა თავს. ხანგრძლივმა სესიებმა მეხსიერებასა და მონაცემთა შენახვაზე დატვირთვა გამოავლინა. ხელახლა დაკავშირებები შეკუმშვასა და მდგომარეობის აღდგენას ამოწმებდა. კლიენტის ჩვეულებრივმა გათიშვებმა გამორთვის შეთანხმებისას კონკურენტული მდგომარეობები გამოავლინა. ეს პრობლემები მოკლე დატვირთვის ტესტებში იშვიათად ჩნდებოდა, რადგან დამოკიდებული იყო დროზე, დაგროვილ მდგომარეობასა და სერვისების საზღვრებს მიღმა ქცევაზე.
დაბოლოს, საწარმოო გარემოში ტესტირებამ დაკვირვებისა და ეტაპობრივი გაშვების მართვის გაუმჯობესება გვაიძულა. აღმოვაჩინეთ მეტრიკები, რომლებიც დაყოვნების სხვადასხვა წყაროს ერთმანეთში ურევდა, დაფები, რომელთა აგრეგირებული მონაცემები ცალკეულ გაუმართავ ძრავებს ფარავდა, და კონფიგურაციის სხვაობა გამოცდილი და დანერგილი სისტემების შორის. ამის საპასუხოდ დავამატეთ უფრო დეტალური ტელემეტრია, ცნობილ გამართულ კონფიგურაციებთან შედარებით ვალიდაცია, ეტაპობრივი ზრდა და ცალკეული მარშრუტების სწრაფად იზოლირების ან გამორთვის შესაძლებლობა. უხმო ტესტი გაშვების ადრეულ რეპეტიციად იქცა — მან შეამოწმა არა მხოლოდ სისტემის მისაღები ტრაფიკის მოცულობა, არამედ ისიც, რამდენად სწრაფად შევძლებდით ხარვეზის აღმოჩენას, შეკავებასა და მისგან აღდგენას.
GPT‑Live-ის ChatGPT‑ის მასშტაბამდე მისაყვანად სრულიად ახალი სისტემა დაგვჭირდა, რომელიც ერთ ფუნდამენტურ პრინციპზე ავაგეთ: ხმა უწყვეტად უნდა მიედინებოდეს. ინფერენსის სტრიმინგი სრულდუპლექსიან მოდელს აუდიოს უწყვეტად აწვდის. მედიის გამოყოფილი მარშრუტი კადრების საიმედო მიწოდებას უზრუნველყოფს. ასინქრონული დელეგირება უფრო ღრმა აზროვნების პარალელურად შესრულების საშუალებას იძლევა. ოპტიმიზებული გადაცემა მომხმარებლამდე მიღწევისას სწრაფ რეაგირებას ინარჩუნებს.
GPT‑Live-ის არქიტექტურა უკვე რეალურ დროში ურთიერთქმედების უფრო ფართო პლატფორმად ყალიბდება. მას ეფუძნება ChatGPT‑ის ხმოვანი რეჟიმი, რომელიც საუბრიდან აგენტურ კოორდინაციაზე ვრცელდება, და მასვე დაეფუძნება მომავალი GPT‑Live API. დროთა განმავლობაში ის ხმოვან გამოცდილებას მეტ მოწყობილობაზე, აპსა და მოდალობაზე გაავრცელებს ისე, რომ არ დაკარგოს უშუალობა, რომელიც ხმოვან საუბარს ცოცხალ შეგრძნებას ანიჭებს.
თუ ასეთი საინჟინრო პრობლემების გადაჭრა გსურთ, შემოგვიერთდით.
