چگونه در شش ماه سیستمی بلادرنگ برای هوش مصنوعی صوتی پاسخ‌گو ساختیم

برای هوش مصنوعی صوتی، تشخیص زمان مناسب صحبت دشوارتر از چیزی است که به نظر می‌رسد. انسان‌ها بی‌زحمت و در کسری از ثانیه نوبت صحبت را به یکدیگر می‌دهند، اما سیستم‌های صوتی پیشین هوش مصنوعی از این ریتم عقب می‌ماندند. معماری نوبت‌محور آن‌ها به مدل‌های کوچکی موسوم به تشخیص‌دهنده نوبت متکی بود که وظیفه دشواری داشتند: اگر زود حدس می‌زدند، حرف کاربر قطع می‌شد و اگر دیر حدس می‌زدند، پاسخ کند به نظر می‌رسید. تنها پس از تصمیم تشخیص‌دهنده بود که الگوهای زبانی بزرگ (LLM) بسیار بزرگ‌تر می‌توانست کار را آغاز کند.

GPT‑Live⁠، نسل سوم سیستم صوتی ما، تشخیص‌دهنده نوبت را از مسیر صدا حذف می‌کند. مدل صوتی آن تمام‌دوطرفه است؛ یعنی می‌تواند هم‌زمان بشنود و صحبت کند. این قابلیت نیاز به تشخیص‌دهنده‌ای جداگانه را از میان می‌برد و مکالمه را فوری‌تر و طبیعی‌تر می‌کند. هنگام نیاز به استدلال عمیق‌تر یا استفاده از ابزار، GPT‑Live می‌تواند بدون برهم‌زدن جریان مکالمه با مدل‌های پیشرو ما، مانند GPT‑5.5، مشورت کند. این قابلیت‌ها در کنار هم، ترکیبی بی‌سابقه از پاسخ‌گویی مکالمه‌ای و هوشمندی به GPT‑Live می‌دهند.

ارائه این تجربه در مقیاس وسیع، به معماری سیستمی تازه و بهینه‌شده برای تأخیر کم نیاز داشت. برخلاف استنتاج معمولِ درخواست‌وپاسخ، سیستم ما صدای ورودی را به‌صورت جریانی به مدل صوتی و گفتار خروجی را به کاربر می‌رساند و هم‌زمان واگذاری را در مسیری ناهمگام و جداگانه انجام می‌دهد. در شش ماه گذشته، استنتاج مدل، مدیریت بافت و انتقال رسانه را بازطراحی کردیم تا گفتار در سراسر مسیر روان بماند.

این معماری همچنین مرزی روشن میان مسیر اصلی صدا و منطق برنامه ایجاد می‌کند. در نتیجه می‌توان رفتار برنامه را بدون اثرگذاری بر پاسخ‌گویی به‌آسانی سفارشی کرد. این زیربنا دامنه رو‌به‌گسترشی از قابلیت‌های ChatGPT Voice (ChatGPT سخنگو) را توانمند می‌کند؛ ازجمله قابلیت تازه‌عرضه‌شده کنترل رایانه و هماهنگ‌کردن عامل‌ها در برنامه دسکتاپ ChatGPT.

در این مطلب توضیح می‌دهیم چرا سیستم‌های نوبت‌محور پیشین پاسخ‌گوی نیازهای ما نبودند و چگونه سیستم جدید را برای پاسخ‌گویی در همه لایه‌ها مهندسی کردیم. به استنتاج وضعیت‌مند، مدیریت پویای بافت، واگذاری ناهمگام و بهینه‌سازی در سطح پروتکل می‌پردازیم که در کنار هم، GPT‑Live را واقعاً زنده می‌کنند.

معماری‌های صوتی پیشین ماهیت نوبت‌محور الگوهای زبانی بزرگ (LLM) متنی را به ارث برده بودند، با این تفاوت که هر نوبت به‌جای متن، بسته‌ای صوتی و مجزا بود. در سیستم‌های آبشاری، تبدیل گفتار به متن، الگوهای زبانی بزرگ (LLM) و تبدیل متن به گفتار، هرکدام به‌ترتیب اجرا می‌شدند. این اجرای ترتیبی تأخیر را افزایش می‌داد و نشانه‌هایی مانند لحن و آهنگ گفتار را نادیده می‌گرفت.

مدل‌های مکالمه-به-مکالمه با پردازش مستقیم صدا، این رویکرد را بهبود دادند. آموزش مدل برای درک و تولید بومی گفتار باعث شد جزئیاتی را که در رونویسی از دست می‌روند حفظ کند و سریع‌تر پاسخ دهد. اما سیستم همچنان برای تعیین زمان آغاز استنتاج به تشخیص‌دهنده نوبت وابسته بود. مدل بخش بیشتری از تعامل را مدیریت می‌کرد، اما تعامل همچنان نوبت‌محور بود.

GPT‑Live کنترل مکالمه را به مدل صوتی می‌سپارد: صدا به مدل وارد و از آن خارج می‌شود و استدلال عمیق‌تر و استفاده از ابزار به‌صورت ناهمگام انجام می‌گیرند. وظیفه اصلی سیستم، حفظ چرخه‌ای بی‌وقفه برای رسانه است. کارهای دیگر، مانند فراخوانی مدل‌های پیشرو و ذخیره پایدار مکالمه، بیرون از مسیر زنده انجام می‌شوند.

بی‌وقفه نگه داشتن این چرخه رسانه همیشه آسان نیست. هرگونه تأخیر در انتقال، پردازش یا استنتاج ممکن است به مکث یا اعوجاجی شنیدنی تبدیل شود. یک سیستم نوبت‌محور قدیمی‌تر می‌توانست مقداری تفاوت در زمان رسیدن یک بسته صوتی را تحمل کند. اما یک سیستم رسانه زنده باید هر فریم صوتی را دقیقاً سر وقت تحویل دهد.

کارهای پیشین روی ChatGPT Voice (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، یعنی 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 را در اختیار کاربران بگذاریم، آزمایشی خاموش انجام دادیم که سهمی اندک و به‌تدریج فزاینده از نشست‌های عملیاتی Voice ChatGPT (ChatGPT سخنگو) را هم‌زمان به تجربه فعلی Advanced Voice Mode (دستیار صوتی پیشرفته) و سیستم جدیدمان هدایت می‌کرد. Advanced Voice Mode (دستیار صوتی پیشرفته) طبق معمول به کاربران خدمت می‌کرد و مسیر سایه نیز استنتاج را در حالت فقط‌خواندنی اجرا می‌کرد. به این ترتیب، بدون تغییر آنچه کاربران می‌شنیدند، سیستم در معرض دستگاه‌های کاربری، شبکه‌ها، طول نشست‌ها و پراکندگی جغرافیایی واقعی قرار گرفت.

یکی از نخستین درس‌ها این بود که ظرفیت را نمی‌توان صرفاً به توان عملیاتی GPU تقلیل داد. نشست‌های صوتی باز می‌مانند و پیوسته فریم می‌فرستند؛ بنابراین کنترل‌کننده‌های جریان، صف‌ها و مسیرهای شبکه در سمت CPU باید همگام با استنتاج مقیاس‌پذیر شوند. زیر بار واقعی، یکی از مؤلفه‌های پشتیبان زودتر از برآورد آزمون بار به اشباع رسید؛ در نتیجه درخواست‌های استنتاج انباشته شدند و تأخیر به‌طور فزاینده‌ای بالا رفت. پرسش ظرفیت را از «یک GPU چند درخواست را می‌تواند مدیریت کند؟» به «سیستم با اجرای به‌موقع همه فریم‌ها، چند نشست هم‌زمان را می‌تواند پایدار نگه دارد؟» تغییر دادیم.

این آزمایش همچنین نشان داد که موقعیت جغرافیایی باید از ملاحظات اصلی باشد. هدایت نشست به ظرفیتی دوردست می‌تواند در چندین مرحله از راه‌اندازی و پخش جریانی تأخیر ایجاد کند. اعتبارسنجی انتشار مدل را همراه با ظرفیت منطقه‌ای و پیکربندی هدایت ترافیک آغاز کردیم و سپس تأخیر را بر اساس موقعیت جغرافیایی مبدأ تفکیک کردیم. نزدیک‌تر کردن استنتاج به کاربران مؤثر بود، اما درس کلی‌تری را نیز تأیید کرد: پاسخ‌گویی سرتاسری به تک‌تک سرویس‌های مسیر وابسته است، نه فقط سرور مدل.

برخی خرابی‌های دیگر فقط در چرخه عمر واقعی نشست‌ها آشکار شدند. نشست‌های طولانی‌مدت فشار وارد بر حافظه و ماندگاری داده را آشکار کردند. اتصال‌های مجدد، فشرده‌سازی و بازیابی وضعیت را به چالش کشیدند. قطع اتصال عادی دستگاه‌های کاربری، شرایط رقابتی در دست‌دهیِ خاموش‌سازی را آشکار کرد. این مشکلات به‌ندرت در آزمون‌های بار کوتاه پدیدار می‌شدند، زیرا به گذشت زمان، وضعیت انباشته و رفتار میان مرز سرویس‌ها وابسته بودند.

در نهایت، آزمایش در محیط عملیاتی ما را واداشت مشاهده‌پذیری و کنترل‌های انتشار را بهبود دهیم. با معیارهایی روبه‌رو شدیم که منابع مختلف تأخیر را درهم می‌آمیختند، داشبوردهایی که داده‌های تجمیعی‌شان موتورهای ناسالم را پنهان می‌کرد و اختلاف پیکربندی میان سیستم‌های آزمایش‌شده و مستقرشده. در پاسخ، داده‌های تله‌متری دقیق‌تر، اعتبارسنجی با پیکربندی‌های سالمِ شناخته‌شده، افزایش مرحله‌ای ترافیک و امکان جداسازی یا غیرفعال‌سازی سریع مسیرها را افزودیم. آزمایش خاموش به تمرینی زودهنگام برای عرضه تبدیل شد؛ نه‌فقط برای سنجش میزان ترافیک قابل‌پذیرش، بلکه برای اینکه ببینیم خرابی را با چه سرعتی می‌توانیم شناسایی و مهار کنیم و از آن بازیابی شویم.

رساندن GPT‑Live به مقیاس ChatGPT مستلزم ساخت سیستمی کاملاً جدید حول یک اصل بنیادی بود: صدا باید بی‌وقفه جریان داشته باشد. استنتاج جریانی، مدل تمام‌دوطرفه را پیوسته با صدا تغذیه می‌کند. یک مسیر اختصاصی رسانه، تحویل مطمئن فریم‌ها را تضمین می‌کند. واگذاری ناهمگام امکان می‌دهد پردازش عمیق‌تر به‌موازات مکالمه انجام شود. انتقال بهینه، تجربه را در تمام مسیر تا کاربر پاسخ‌گو نگه می‌دارد.

معماری زیربنایی GPT‑Live از همین حالا در حال تبدیل شدن به پلتفرمی گسترده‌تر برای تعامل بلادرنگ است. این معماری، ChatGPT Voice (ChatGPT سخنگو) را در مسیر گسترش از مکالمه به هماهنگی عامل‌محور توانمند می‌کند و زیربنای API آینده GPT‑Live خواهد بود. به‌مرور، این معماری اجازه می‌دهد تجربه‌های صوتی بدون از دست دادن حس فوریتی که مکالمه صوتی را زنده جلوه می‌دهد، دستگاه‌ها، برنامه‌ها و شیوه‌های بیشتری را دربرگیرند.

اگر دوست دارید چنین مسائل مهندسی‌ای را حل کنید، به ما بپیوندید⁠.