تصور کنید در یک مصاحبه شغلی حساس هستید و هر پاسخی که می‌دهید با ۴.۲ ثانیه سکوت مطلق مواجه می‌شود؛ این فاصله، مرز میان یک گفتگوی طبیعی و یک ماشین شکسته است. توسعه‌دهنده پلتفرم Preterview، که یک پلتفرم مصاحبه مبتنی بر صدا است، سه هفته را صرف کالبدشکافی این تأخیر کرد تا زمان پاسخ‌دهی را از ۴۲۴۷ میلی‌ثانیه به ۷۸۰ میلی‌ثانیه برساند. یک تحلیل فنی دقیق نشان می‌دهد که گلوگاه اصلی به‌ندرت خودِ مدل زبانی (LLM) بود، بلکه مجموعه‌ای از «انتظارهای عمدی» بود که در تنظیمات پیش‌فرض سیستم تعبیه شده بودند.
بسیاری از توسعه‌دهندگان تأخیر در هوش مصنوعی صوتی را یک «جعبه سیاه» از زمان استنتاج (Inference) — که مثل لحظه آشپزی واقعی است، نه دوره آموزش آشپز — می‌بینند. اما در واقعیت، این تأخیر مجموعه‌ای از ۶ انتظار متوالی است: تشخیص پایان گفتار (Endpointing)، تبدیل گفتار به متن (Transcription)، زمان تا نخستین توکن (TTFT)، تولید پاسخ (Completion Generation)، سنتز صوتی (Audio Synthesis) و بافر شبکه. اکثر توسعه‌دهندگان بر تنظیمات پیش‌فرضی تکیه می‌کنند که منتظر می‌ماند تا یک جمله کامل شود یا یک فایل صوتی کامل تولید شود و سپس پخش را آغاز کند.
برای پلتفرمی مثل Preterview که مصاحبه‌های شغلی پرفشار را با سه سبک مختلف مصاحبه‌کننده شبیه‌سازی می‌کند و در نهایت یک گزارش مکتوب امتیازدهی شده ارائه می‌دهد، این مکث‌ها به معنای شکست سیستم است. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت و تجربه کاربری مدل‌های زبانی اشاره کردیم، کاربر در شرایط استرس، سکوت دو ثانیه‌ای را نه به عنوان پردازش، بلکه به عنوان کرش کردن سیستم می‌بیند. این اتفاق یک حلقه بازخورد منفی ایجاد می‌کند؛ کاربر در میان سکوت می‌گوید «الو؟» و این کار باعث ایجاد یک ترنسکریپت جدید شده و عامل هوشمند را بیشتر گیج می‌کند. این چالش‌ها در تعاملات صوتی، یادآور تلاش‌های مشابه برای جایگزینی تایپ با ورودی‌های صوتی در محیط‌های اداری است که در آن کیفیت و سرعت تبدیل صدا به متن نقش حیاتی دارد.
اندازه‌گیری حقیقت
توسعه‌دهنده برای جلوگیری از «دروغ گفتن به خود» با استفاده از معیارهای نادرست، ابزار اندازه‌گیری را از سرور به بلندگوی کاربر منتقل کرد. به نقل از مستندات پروژه، برچسب‌های زمانی سمت سرور ۲۰۰ میلی‌ثانیه خوش‌بینانه‌تر از واقعیت بودند، زیرا بافر ضبط صدای مرورگر و زمان لازم برای آپلود داده‌ها را نادیده می‌گرفتند.
روش جدید اندازه‌گیری شامل موارد زیر بود:
- ضبط مسیر ورودی خام (Raw Input Track) برای هر جلسه.
- اجرای تشخیص فعالیت صوتی (VAD) به‌صورت آفلاین برای یافتن
t_last_speech(لحظه واقعی پایان آخرین هجای کاربر). - ثبت زمان اولین فریم صوتی شنیدنی در سمت کلاینت به‌جای رویداد «پاسخ ارسال شد» در سرور.
- استفاده از یک ساعت یکنواخت (Monotonic Clock) برای حذف خطاهای ناشی از ترکیب
Date.now()در دو ماشین مختلف.
آبشار تأخیر
با تحلیل ۴۰ جلسه ضبط‌شده، مشخص شد که تأخیر ۴.۲ ثانیه‌ای اولیه از این اجزای خاص تشکیل شده بود:
- تشخیص پایان گفتار (Endpointing): ۱۲۰۰ میلی‌ثانیه (پنجره سکوت ثابت)
- تبدیل گفتار به متن Deepgram: ۳۱۰ میلی‌ثانیه (ترنسکریپت نهایی پس از نقطه پایان)
- زمان تا نخستین توکن (TTFT) مدل زبانی: ۱۰۵۰ میلی‌ثانیه (پرامپت سیستمی ۶.۸ هزار توکنی، بدون کش)
- تولید پاسخ: ۱۲۴۰ میلی‌ثانیه (خروجی JSON ساختاریافته، حدود ۱۸۰ توکن)
- تولید صدای ElevenLabs: ۳۸۰ میلی‌ثانیه (تولید کامل فایل قبل از شروع پخش)
- شبکه و بافر: ۶۷ میلی‌ثانیه
با نگاه به این اعداد، استنتاج مدل ۲۲۹۰ میلی‌ثانیه از کل زمان ۴۲۴۷ میلی‌ثانیه‌ای را گرفت، اما ۱۹۵۷ میلی‌ثانیه صرف «انتظار عمدی» شد: انتظار برای سکوت جهت تأیید پایان نوبت کاربر، انتظار برای تکمیل یک شیء JSON و انتظار برای آماده شدن کامل فایل صوتی.
چهار بهینه‌سازی کلیدی
بزرگ‌ترین دستاورد، استریم کردن تبدیل متن به گفتار (TTS) از اولین مرز جمله‌ای بود. به‌جای جریان قدیمی — یعنی await llm.complete() و سپس await tts.generate() و در نهایت play — سیستم اکنون اولین جمله کامل را در لحظه‌ای که استریم توکن‌ها آن را تولید می‌کند، به ElevenLabs می‌فرستد. این تغییر به تنهایی حدود ۱۴۳۰ میلی‌ثانیه صرفه‌جویی کرد؛ زیرا انتظار ۱۲۴۰ میلی‌ثانیه‌ای برای «باقی‌مانده پاسخ» را حذف کرد و تولید کامل ۳۸۰ میلی‌ثانیه‌ای را با یک تکه (Chunk) اولیه ۹۰ میلی‌ثانیه‌ای جایگزین نمود.
دوم، پیاده‌سازی کشینگ پرامپت برای پرامپت سیستمی و زمینه جلسه انجام شد. از آنجا که پرامپت سیستمی و وضعیت جاری مصاحبه در مجموع حدود ۶.۸ هزار توکن هستند و در هر نوبت یکسان می‌مانند، استفاده از یک نشانگر کنترل کش (Cache-control marker) روی این پیشوند استاتیک، زمان TTFT را از ۱۰۵۰ به ۳۱۰ میلی‌ثانیه کاهش داد و ۷۴۰ میلی‌ثانیه زمان ذخیره کرد. این بهینه‌سازی در مدیریت داده‌ها، تفاوت‌های بنیادینی را در عملکرد مدل‌ها ایجاد می‌کند؛ مشابه آنچه در مقایسه قابلیت‌های سازمان‌دهی ChatGPT و تحلیل لحظه‌ای Grok مشاهده می‌کنیم.
سوم، سیستم به «نقطه پایان تطبیقی» (Adaptive Endpointing) تغییر یافت. یک پنجره سکوت ثابت ۱۲۰۰ میلی‌ثانیه‌ای فرض می‌کند هر مکثی معنای یکسانی دارد. سیستم جدید بر اساس متن ترنسکریپت تصمیم می‌گیرد:
- بندهای کامل (مثلاً «...و این‌طور مهاجرت داده‌ها را مدیریت کردم»): ۲۲۰ میلی‌ثانیه انتظار.
- کلمات پرکننده یا حروف ربط معلق (مثلاً «...و بعد، اوم...»): ۹۰۰ میلی‌ثانیه انتظار.
این تغییر، میانگین انتظار نقطه پایان را به ۲۸۰ میلی‌ثانیه رساند و ۹۲۰ میلی‌ثانیه زمان ذخیره کرد.
در نهایت، خروجی JSON ساختاریافته از مسیر گفتار حذف شد. خط لوله امتیازدهی به JSON نیاز داشت، اما کاربر فقط به متن ساده نیاز دارد. با تقسیم این فرآیند به دو فراخوانی — یکی برای گفتار فوری و دومی (غیرمسدودکننده) برای استخراج ساختاریافته — سیستم ۱۸۰ میلی‌ثانیه دیگر را ذخیره کرد. این کار همچنین غیرقابل‌پیش‌بینی بودن «رمزگشایی محدود» (Constrained Decoding) را که اغلب به تأخیرات انتهایی (Tail Latency) ضربه می‌زند، حذف کرد.
بودجه نهایی زمان
پس از این تغییرات، بودجه اندازه‌گیری شده برای هر نوبت به ۷۸۰ میلی‌ثانیه رسید:
- تصمیم نقطه پایان تطبیقی: ۲۸۰ میلی‌ثانیه
- ترنسکریپت نهایی Deepgram: ۱۲۰ میلی‌ثانیه
- زمان TTFT مدل (با کش و متن ساده): ۱۸۰ میلی‌ثانیه
- توکن‌ها تا اولین مرز جمله‌ای: ۷۰ میلی‌ثانیه
- اولین تکه صوتی ElevenLabs: ۹۰ میلی‌ثانیه
- شبکه و بافر: ۴۰ میلی‌ثانیه
هزینه سرعت
افزایش سرعت، حالت‌های شکست جدیدی را معرفی کرد. در نقطه پایان ثابت ۲۵۰ میلی‌ثانیه‌ای، توسعه‌دهنده ۴۱۸ نوبت را در ۱۲ جلسه بررسی کرد و متوجه شد ربات در ۳۱٪ موارد حرف انسان‌ها را قطع می‌کند. نقطه پایان تطبیقی این نرخ را به ۶٪ رساند، اما توازن میان پاسخ‌دهی سریع و دقت همچنان یک تنش دائمی است.
جدا کردن جملات نیز دشوار بود. استفاده از دستور ساده split('.') باعث می‌شد عباراتی مثل «Node.js» یا «۳.۵ سال» در وسط کلمه قطع شوند و منجر به تولید صدایی با توقف‌های سخت در میان اعداد شود. راهکار نهایی، تعریف قانونی سخت‌گیرانه‌تر بود: نقطه به‌دنبال یک فاصله و یک حرف بزرگ، به شرطی که تکه متن حداقل ۶۰ کاراکتر باشد تا سپس به TTS ارسال شود.
همچنین استریم کردن پیش‌رو (Streaming ahead) هزینه‌ها را بالا برد. چون سیستم صدا را قبل از شنیده شدن توسط کاربر تولید می‌کند، قطع شدن صحبت توسط کاربر منجر به هدر رفتن کاراکترها می‌شود. در ابتدا، ۱۸٪ از کاراکترهای گفتار تولید شده دور ریخته می‌شدند. محدود کردن پیش‌بینی به دو جمله، این اتلاف را به حدود ۷٪ کاهش داد.
مشکل P95
ناامیدکننده‌ترین معیار، تأخیر P95 است که روی ۱.۶ ثانیه باقی مانده است. دلیل این اتفاق تقریباً به‌طور کامل انقضای کش پرامپت است. ورودی‌های کش دارای زمان انقضا (TTL) هستند. وقتی یک داوطلب برای فکر کردن به پاسخی چند دقیقه سکوت می‌کند، هنگام بازگشت با یک پیشوند «سرد» مواجه می‌شود و باید تمام زمان TTFT بدون کش را بپردازد.
این یعنی کسی که بیشترین نیاز را به یک پاسخ سریع و تشویق‌کننده دارد — یعنی کسی که طولانی‌ترین سکوت را داشته — کندترین پاسخ را می‌گیرد. برای کاهش این اثر، توسعه‌دهنده اکنون یک سیگنال ارزان‌قیمت «زنده نگه داشتن» (keepalive) در طول سکوت‌های طولانی ارسال می‌کند تا کش حفظ شود.
این تغییر معماری ثابت می‌کند که در اکثر عامل‌های صوتی، مدل گلوگاه نیست، بلکه لوله‌کشی سیستم است. اگر رابط کاربری صوتی می‌سازید، اندازه‌گیری را از آخرین هجای انسان تا اولین فریم صوتی شنیدنی شروع کنید. احتمالاً می‌بینید سیستم شما بیشتر از آنکه فکر کند، منتظر سکوت می‌ماند.
گام بعدی شما
- اندازه‌گیری تأخیر را از سمت کلاینت (بلندگو) انجام دهید، نه سرور.
- استریم کردن TTS را از اولین مرز جمله‌ای پیاده‌سازی کنید تا انتظار برای تکمیل کل پاسخ حذف شود.
- از کشینگ پرامپت سیستمی برای کاهش زمان TTFT استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو