مدل‌های Omni: معماری تفکیک Thinker-Talker در Qwen2.5-Omni

معرفی مدل‌هایی مثل GPT-4o نشان داد که ارزش واقعی دستیارهای هوشمند نسل جدید در پاسخ‌گویی بلادرنگ و گفت‌وگوی صوتی طبیعی است. اگر کاربر مجبور باشد چندین ثانیه برای شنیدن پاسخ منتظر بماند، جریان مکالمه مختل می‌شود. رسیدن به تاخیر رفت‌وبرگشت زیر 500 میلی‌ثانیه نیازمند بازطراحی کامل پایپ‌لاین‌های سنتی تبدیل گفتار به متن، پردازش زبانی و سپس سنتز صدا است.

در اکوسیستم متن‌باز، معماری‌های نوین نظیر Qwen2.5-Omni با تفکیک هوشمندانه‌ی وظایف به دو بخش «متفکر» (Thinker) برای استدلال و «گوینده» (Talker) برای سنتز موازی و استریمینگ گفتار، این مسئله را حل کرده‌اند. شناخت این تفکیک و درک سقف تاخیر (TTFAB) برای مهندسانی که به دنبال پیاده‌سازی دستیارهای صوتی محلی یا تعاملی بدون وابستگی به سرویس‌های انحصاری هستند، اهمیت حیاتی دارد.

دموی محصولی GPT-4o در مه 2024 تحول‌آفرین بود؛ نه صرفاً به‌خاطر مدل زیربنایی‌اش، بلکه به‌دلیل ساختار محصول: رابطی صوتی که در آن شما صحبت می‌کنید، مدل هم‌زمان ورودی دوربین را می‌بیند و در کمتر از 250 میلی‌ثانیه پاسخ می‌دهد. اکوسیستم متن‌باز بقیه‌ی سال 2024 و 2025 را با تمام توان تلاش کرد تا به چنین سطحی از محصول برسد. مدل Qwen2.5-Omni (مارس 2025) معماری مرجع این طراحی باز به حساب می‌آید: یک متفکر یا Thinker (ترنسفورمر بزرگ برای تولید متن) در کنار یک گوینده یا Talker (ترنسفورمر موازی برای تولید گفتار) که از طریق استریمینگ توکن‌های گفتار به هم متصل شده‌اند. Mini-Omni این فرآیند را ساده‌تر کرد، Moshi از نظر تاخیر با آن برابری کرد و GLM-4-Voice این قابلیت را به زبان چینی گسترش داد. در این درس، معماری Thinker-Talker و سقف تاخیری (latency budget) را بررسی می‌کنیم که گفت‌وگوی زنده و بی‌درنگ را ممکن می‌سازد.

اهداف یادگیری

• پایپ‌لاین استنتاج را به دو بخش Thinker (استدلال متنی) و Talker (سنتز گفتار) تقسیم کنید و توضیح دهید چرا استریمینگ موازی در اینجا جواب می‌دهد.
• سقف تاخیر تا دریافت نخستین بایت صوتی (Time-To-First-Audio-Byte یا TTFAB) را در یک تعامل گفت‌وگویی، جزءبه‌جزء محاسبه کنید.
• نحوه‌ی کارکرد کدگذاری موقعیت در TMRoPE را در تراز زمانی میان تصویر، صوت و متن درون Thinker شرح دهید.
• دو الگوی مکالمه‌ی زنده یعنی نیمه‌دوطرفه (half-duplex) و تمام‌دوطرفه (full-duplex) را نام ببرید و توضیح دهید چطور نوبت‌گیری مکالمه بر پایه‌ی آشکارسازی فعالیت صوتی (Voice Activity Detection یا VAD)، فرایند تحویل نوبت را در حالت نیمه‌دوطرفه هدایت می‌کند.

صورت مسئله

یک دستیار صوتی بی‌درنگ باید کارهای زیادی را در زمانی بسیار کوتاه انجام دهد:

1. شنیدن کاربر: توکن‌سازی گفتار به‌صورت بی‌درنگ و استفاده از VAD برای تشخیص زمان پایان صحبت کاربر.
2. دیدن اختیاری: دریافت ورودی دوربین با نرخ 2 تا 4 فریم بر ثانیه و استریم کردن آن در کنار صوت به درون Thinker.
3. تفکر: ساخت پاسخی متناسب با تاریخچه‌ی مکالمه.
4. صحبت کردن: سنتز توکن‌های صوتی، تبدیل آن‌ها به شکل‌موج (waveform) و استریم کردن صدا روی بلندگوهای کاربر.

هر مرحله به تاخیر اضافه می‌کند. برای اینکه حس طبیعی مکالمه حفظ شود، کل تاخیر رفت‌وبرگشت باید کمتر از 500 میلی‌ثانیه باشد؛ در این بازه، کاربر اصلاً متوجه کندی نمی‌شود. مدل GPT-4o ادعای رسیدن به حدود 250 میلی‌ثانیه را دارد، Moshi حدود 160 میلی‌ثانیه است و Qwen2.5-Omni بین 350 تا 500 میلی‌ثانیه ثبت کرده است.

تمام بخش‌ها باید به‌شکل استریمینگ کار کنند؛ هیچ بخشی نمی‌تواند از الگوی «اول همه چیز را یک‌جا جمع کن، بعد دیکود کن» استفاده کند.

مفاهیم پایه

تفکیک Thinker و Talker

تفکیک ارائه‌شده در Qwen2.5-Omni به این شکل است:

• متفکر (Thinker): ترنسفورمر متنی 7B تا 80B. توکن‌های درهم‌تنیده‌ی متن، تصویر و صوت را دریافت می‌کند و توکن‌های متنی را در قالب پاسخی که باید داده شود بیرون می‌دهد.
• گوینده (Talker): ترنسفورمر کوچک‌تر تولید گفتار (200M تا 1B). توکن‌های متنی خروجی Thinker را همراه با توکن‌های بافت صوتی اخیر دریافت می‌کند و توکن‌های گسسته‌ی گفتار (اندیس‌های residual-VQ) را تولید می‌کند.
• دیکودر گفتار: یک دیکودر استریمینگ شکل‌موج (از خانواده‌ی SNAC یا MoVQGAN) که توکن‌های گفتار را در لحظه به نمونه‌های صوتی تبدیل می‌کند.

این جداسازی اهمیت زیادی دارد. Thinker باید برای استدلال قوی بزرگ باشد؛ اما Talker می‌تواند کوچک بماند، چون کارش محلی است: تبدیل متن به توکن‌های گفتار. بزرگ‌تر شدن Talker بیانگریِ آن را بهتر نمی‌کند، بلکه فقط کندترش می‌کند.

اجرای موازی این دو:

1. متفکر توکن متنی $t_i$ را تولید می‌کند.
2. گوینده توکن $t_i$ را (از طریق استریمینگ) مصرف می‌کند و توکن‌های گفتار $s_i, s_{i+1}, \ldots, s_{i+k}$ را بیرون می‌دهد.
3. دیکودر گفتار هم‌زمان با رسیدن توکن‌های گفتار آن‌ها را مصرف می‌کند و نمونه‌های صوتی تحویل می‌دهد.
4. تا زمانی که Thinker به توکن متنی $t_{i+3}$ برسد، Talker از قبل خروجی صوتیِ توکن $t_0, \ldots, t_{i+2}$ را استریم کرده است.

ساختار TMRoPE — موقعیت‌های چندحالته‌ی همگام با زمان

متفکر باید فریم‌های تصویر (مثلاً با نرخ 4 فریم بر ثانیه)، فریم‌های صوتی (با نرخ 50 فریم بر ثانیه) و متن تاریخچه‌ی مکالمه را کنار هم بگذارد. چیدمان خطی و ساده‌ی دنباله (اول همه‌ی تصاویر، بعد همه‌ی صوت‌ها، بعد متن) تراز زمانی را از بین می‌برد.

روش TMRoPE به هر توکن یک برچسب زمانی مطلق اختصاص می‌دهد: توکن تصویر در زمان t=2.3s، توکن صوتی در زمان t=2.32s و توکن متنی «stop» از کاربر در زمان t=2.35s. لایه‌ی RoPE ماتریس اتنشن را بر اساس این برچسب‌های زمانی می‌چرخاند؛ در نتیجه مدل آن‌ها را از نظر زمانی هم‌زمان درک می‌کند.

این همان زیرساختی است که سناریوی «او هم‌زمان با گفتن سلام دست تکان داد» را ممکن می‌کند؛ مدل فریم ویدیو و صوت را در یک نقطه‌ی مفهومی مشترک از زمان می‌بیند.

سنتز استریمینگ گفتار

توکن‌های گفتار باید به‌صورت استریمینگ منتقل شوند. مدل Mini-Omni (شیه و وو، 2024) این ایده را مطرح کرد که «مدل‌های زبانی می‌توانند حین فکر کردن، به‌شکل استریمینگ بشنوند و صحبت کنند»: توکن‌های خروجی Thinker و توکن‌های خروجی Talker در یک دنباله‌ی واحد کنار هم می‌نشینند. به‌محض اینکه Thinker توکن متنی بعدی را commit کرد، Talker فعال می‌شود؛ بدون هیچ مرزبندی دسته‌ای.

مدل Moshi (دفوزه و همکاران، اکتبر 2024) سریع‌ترین پیاده‌سازی متن‌باز در این زمینه است: 160 میلی‌ثانیه TTFAB روی یک A100. معماری آن شامل یک ترنسفورمر 7B واحد است که توکن‌های متن و گفتار را در جایگاه‌های یکی‌درمیان تولید می‌کند و یک «تک‌گویی درونی» (inner monologue) دارد که استریم فکر کردن را از استریم صحبت کردن جدا نگه می‌دارد. در واقع این همان ترکیب Thinker + Talker است که با آموزش دقیق در دل یک مدل ادغام شده است.

آشکارسازی فعالیت صوتی (VAD) و نوبت‌گیری مکالمه

آشکارسازی فعالیت صوتی در سمت ورودی اجرا می‌شود. دو الگو برای مکالمه وجود دارد:

• نیمه‌دوطرفه (Half-duplex): کاربر صحبت می‌کند، مدل گوش می‌دهد. مدل صحبت می‌کند، کاربر گوش می‌دهد. جابه‌جایی نوبت با تشخیص سکوت کاربر از طریق VAD (حدود 200 میلی‌ثانیه) انجام می‌شود.
• تمام‌دوطرفه (Full-duplex): هر دو هم‌زمان می‌توانند صحبت کنند. مدل می‌تواند واکنش‌های حین کلامی نشان دهد (مثل «آهان») یا حرف کاربر را قطع کند. پیاده‌سازی این حالت بسیار دشوارتر است. Moshi از این قابلیت پشتیبانی می‌کند.

مدل Qwen2.5-Omni به‌طور پیش‌فرض نیمه‌دوطرفه است و نوبت‌گیری مکالمه را با آستانه‌ی سکوت مدیریت می‌کند. حالت تمام‌دوطرفه نیازمند مدیریت در لایه‌ی اپلیکیشن است.

مدل Qwen3-Omni (نوامبر 2025)

نسل بعدی این معماری است؛ مجهز به Thinker مدل Qwen3-80B، یک Talker بزرگ‌تر و TMRoPE-v2 بهبودیافته. تاخیر آن به 250 میلی‌ثانیه‌ی GPT-4o بسیار نزدیک است، وزن‌هایش متن‌باز هستند و نتایج بنچ‌مارک آن در OmniBench با Gemini 2.0 Live رقابت می‌کند.

سقف تاخیر در محیط عملیاتی

برای یک تعامل استریمینگ معمولی، زمان‌بندی به این صورت است:

• از میکروفون تا توکن‌های صوتی: 40 تا 80 میلی‌ثانیه.
• مرحله‌ی Prefill (پرامپت + تاریخچه): 100 تا 200 میلی‌ثانیه در مدل 7B؛ در مدل 70B بسیار بیشتر.
• نخستین توکن متنی Thinker: حدود 40 میلی‌ثانیه.
• پردازش اولین توکن متنی توسط Talker: حدود 20 میلی‌ثانیه.
• ثبت (commit) اولین توکن‌های گفتار: 40 میلی‌ثانیه.
• دیکود Residual-VQ: حدود 30 میلی‌ثانیه.
• دیکود شکل‌موج گفتار: 50 تا 80 میلی‌ثانیه.

کل TTFAB: بین 320 تا 490 میلی‌ثانیه در مدل 7B؛ بین 600 تا 900 میلی‌ثانیه در مدل 70B. کیفیت مدل‌های پیشرو معمولاً به اندازه‌ی 70B به بالا نیاز دارد؛ از این رو شکاف تاخیر در مدل‌های پیشرو پدید می‌آید.

محاسبات نرخ توکن

در صوت 16kHz با 50 توکن گفتار پایه‌ای در ثانیه، برای هر ثانیه خروجی به 50 توکن گفتار نیاز دارید. Talker باید با نرخ 50 توکن در ثانیه یا بیشتر خروجی دهد تا عقب نماند. با در نظر گرفتن نرخ پردازش معمول مدل‌های زبانی که روی یک H100 بین 30 تا 80 توکن در ثانیه است، یک Talker کوچک (200M تا 300M) سرعت کافی را دارد؛ اما یک Talker مدل 7B عقب خواهد افتاد.

دلیل طراحی مدل‌های کوچک و اختصاصی برای Talker همین است؛ نمی‌توان صرفاً گفت «از همان مدل اصلی استفاده می‌کنیم».

اجرای عملی

فایل code/main.py:

• یک پایپ‌لاین Thinker-Talker را با نرخ‌های شبیه‌سازی‌شده‌ی تولید توکن پیاده می‌کند.
• مقدار TTFAB را بر اساس اندازه‌های دلخواه مدل و نرخ نمونه‌برداری میکروفون محاسبه می‌کند.
• نوبت‌گیری مکالمه در حالت نیمه‌دوطرفه را با آستانه‌ی سکوت VAD نشان می‌دهد.

خروجی کاربردی

خروجی این درس فایل outputs/skill-omni-streaming-budget.md است. این مستند بر اساس ویژگی‌های مدنظر شما برای یک محصول صوتی زنده (مثل TTFAB هدف، ورودی تصویر، دوزبانه بودن یا حالت تمام‌دوطرفه)، مناسب‌ترین مدل را از میان Qwen2.5-Omni ،Qwen3-Omni ،Moshi یا Mini-Omni انتخاب کرده و ابعاد Thinker/Talker را تعیین می‌کند.

تمرین‌ها

1. سقف TTFAB هدف شما 300 میلی‌ثانیه است. با فرض یک Thinker با اندازه‌ی 7B و Talker با اندازه‌ی 300M، سهم تاخیر هر جزء را مشخص کنید.

2. مدل Qwen2.5-Omni از TMRoPE استفاده می‌کند. شرح دهید مدل برای پرامپتی که در آن کاربر در زمان t=1s شروع به صحبت می‌کند و دوربین در زمان t=1.2s یک حرکت بدنی را ثبت می‌کند، چه ورودی‌هایی را می‌بیند.

3. پشتیبانی از حالت تمام‌دوطرفه ایجاب می‌کند مدل حین شنیدن، صدا نیز تولید کند. ساختاری برای داده‌های آموزشی پیشنهاد دهید که این رفتار را بیاموزد.

4. بخش 4 از مقاله‌ی Moshi را مطالعه کنید. سازوکار تفکیک در «تک‌گویی درونی» را شرح دهید و بگویید چرا این روش از جداسازی سنتی به Thinker-Talker بی‌نیاز است.

5. سقف نرخ پردازش را محاسبه کنید: Talker با چه سرعتی باید توکن تولید کند تا با گفتار 16kHz در نرخ 50 توکن لایه‌ی پایه در ثانیه هماهنگ بماند؟

اصطلاحات کلیدی

مطالعه‌ی بیشتر

• شو و همکاران — Qwen2.5-Omni (arXiv:2503.20215)
• تیم Qwen — Qwen3-Omni (arXiv:2509.17765)
• شیه و وو — Mini-Omni (arXiv:2408.16725)
• دفوزه و همکاران — Moshi (arXiv:2410.00037)
• زنگ و همکاران — GLM-4-Voice (arXiv:2412.02612)