همهٔ مقاله‌ها

· Casimiro Ferreira· 7 دقیقه مطالعه

صادرات و کوانتیزهٔ مدل‌های باز گفتار تا واقعاً اجرا شوند

  • ONNX
  • CoreML
  • GGUF
  • ASR
  • OVOS
  • OpenVoiceOS
  • Quantization
  • Open Source

یک مدل تشخیص گفتار که به‌صورت یک checkpoint پژوهشی منتشر شده معمولاً یک پوشه از وزن‌های PyTorch، یک اسکریپت آموزش و یادداشتی است که می‌گوید روی چه GPU‌ای آموزش دیده. این برای بازتولید یک امتیاز محک کافی است. برای نصب روی یک Raspberry Pi، یک تلفن یا یک لپ‌تاپ بدون اتصال اینترنت کافی نیست. رسیدن از یکی به دیگری کار تبدیل است، و بیشترین بخشی است که تعیین می‌کند آیا یک مدل باز گفتار اصلاً به یک دستگاه واقعی می‌رسد یا نه.

ما این کار تبدیل را حرفه‌ای انجام می‌دهیم: گرفتن مدل‌های باز ASR (تشخیص خودکار گفتار، یعنی گفتار به متن) و TTS (متن به گفتار) و تبدیل آن‌ها به فایل‌هایی که آفلاین، روی CPU های معمولی یا شتاب‌دهنده‌های درون‌دستگاهی اجرا می‌شوند، بدون نیاز به هیچ پشتهٔ آموزشیِ Python در زمان اجرا. بیشتر نتایج زیر سازمان OpenVoiceOS در Hugging Face منتشر می‌شوند، نه زیر سازمان خودمان، و این انتخاب عمدی است — در ادامه دلیلش را می‌بینید.

چرا یک checkpoint یک استقرار نیست

یک checkpoint PyTorch یا NeMo به یک محیط Python خاص نیاز دارد: نسخه‌های درست کتابخانه‌ها، معمولاً یک GPU، و خودِ چارچوب آموزشی تنها برای اجرای استنتاج. آن پشته بزرگ است، پیوسته تغییر می‌کند و چیزی نیست که بخواهید درون یک دستیار صوتی بگنجانید که باید روی یک برد کوچک بوت شود.

صادرات مدل این را با تبدیل شبکهٔ آموزش‌دیده به قالبی که خالصاً برای استنتاج ساخته شده حل می‌کند — بدون کد آموزش، بدون autograd، بدون قفل‌شدگی به یک چارچوب. ما سه چنین قالبی را هدف می‌گیریم، هر یک برای یک شکل استقرار متفاوت:

  • ONNX (Open Neural Network Exchange) یک قالب گراف قابل‌حمل است که طیف گسترده‌ای از زمان‌اجراها می‌توانند آن را روی CPU یا GPU، روی Linux، Windows، macOS یا بردهای توکار اجرا کنند. این قالب پیش‌فرض ماست چون هرجا onnxruntime اجرا شود کار می‌کند، که تقریباً همه‌جاست.
  • CoreML قالب استنتاج درون‌دستگاهیِ اپل است. یک بستهٔ CoreML روی موتور عصبی یا GPU یک Mac یا iPhone اجرا می‌شود، نه روی CPU، که برای تشخیص گفتار بی‌درنگ روی سخت‌افزار اپل اهمیت دارد.
  • GGUF قالبی است که llama.cpp و بوم‌سازگان آن به کار می‌برند، ساخته‌شده برای مدل‌های کوانتیزه‌شده و به‌سبک LLM که باید با ردپای حافظهٔ کوچک اجرا شوند. ما آن را برای مدل‌های گفتاریِ نوین و مبتنی بر ترنسفورمر به کار می‌بریم که از نظر معماری به یک مدل زبانی نزدیک‌ترند تا به یک مدل صوتیِ کلاسیک.

انتخاب هدف درست تزئینی نیست. یک مدل ASR مبتنی بر Conformer (معماریِ پشتِ بیشتر تشخیص‌دهنده‌های گفتار مدرن، که کانولوشن و خودتوجهی را ترکیب می‌کند) به‌سادگی به ONNX یا CoreML تبدیل می‌شود. یک مدل گفتاریِ مبتنی بر Qwen3، در زیر پوسته، یک مدل زبانی است، پس به‌طور طبیعی در خط لولهٔ GGUF/llama.cpp جا می‌گیرد.

کوانتیزه چه هزینه‌ای دارد و چه چیزی می‌خرد

کوانتیزه یعنی ذخیرهٔ وزن‌های یک مدل با بیت‌های کمتر به‌ازای هر عدد — ۱۶ بیت یا ۸ بیت یا ۴ بیت به‌جای اعداد اعشاری ۳۲ بیتی‌ای که با آن‌ها آموزش دیده. اعداد کوچک‌تر فایل کوچک‌تری می‌سازند و روی سخت‌افزار مناسب، استنتاج سریع‌تری، چون داده‌ی کمتری باید جابه‌جا شود و محاسبات ارزان‌تری باید انجام گیرد.

می‌توانیم برای یک مدل واقعی رقم دقیقی روی این معامله بگذاریم. nvidia/parakeet-tdt-0.6b-v3 یک مدل ASR با ۰٫۶ میلیارد پارامتر است. مؤلفهٔ mel-encoder نسخهٔ CoreML آن در دقت کامل ۱۱۳۲٫۵ مگابایت است؛ با palettize کردن تا ۴ بیت به ۲۸۴٫۲ مگابایت می‌رسد — کاهشی ۳٫۹۹ برابری، که تقریباً دقیقاً در هر سه زیرمؤلفه‌اش (encoder، decoder، شبکهٔ تصمیم مشترک) یکسان است. در سراسر کل بسته، نسخهٔ صادرشدهٔ کوانتیزه‌نشدهٔ CoreML حدود ۱٫۱۴ گیگابایت است؛ نسخهٔ ۴ بیتی حدود ۲۹۳ مگابایت. این تفاوت میان مدلی است که به‌راحتی روی یک تلفن جا می‌گیرد و مدلی که به‌سختی جا می‌گیرد.

هزینه‌اش دقت است: بیت‌های کمتر به‌ازای هر وزن یعنی دقت کمتر، و از نقطه‌ای به بعد این به‌صورت خطاهای تشخیصیِ بیشتر نمود می‌یابد. راه استاندارد برای اندازه‌گیری آن برای ASR، WER است (نرخ خطای واژه — درصد واژه‌هایی که مدل در مقایسه با رونوشت درست اشتباه می‌گیرد). به همین دلیل چند سطح کوانتیزه از همان مدل را کنار هم منتشر می‌کنیم — ۴ بیت، ۶ بیت، ۸ بیت (int8) و fp16 — به‌جای انتخاب یکی و امید به اینکه برای هر دستگاهی به‌قدر کافی خوب باشد. یک تلفن و یک رومیزی می‌توانند نقاط متفاوتی روی آن منحنی را تحمل کنند.

مسئلهٔ اعتبارسنجی

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

این پایه‌ای‌ترین الزام برای هر تبدیلی است که عرضه می‌کنیم: همان صدا را از میان مدل مبدأ و مدل تبدیل‌شده عبور دهید و تأیید کنید که با هم هم‌خوان‌اند. گامی پرزرق‌وبرق نیست، اما نادیده گرفتنش دقیقاً همان‌طوری است که یک «زبان پشتیبانی‌شده» به‌خاموشی از کار می‌افتد.

چرا مدل‌ها زیر OpenVoiceOS زندگی می‌کنند، نه زیر ما

صادرات مدل یک توانمندیِ شرکتی است: یک checkpoint و یک دستگاه هدف به ما بدهید، و ما آن را آفلاین، اعتبارسنجی‌شده، در سطح کوانتیزه‌ای که با سخت‌افزارتان جور است اجرا می‌کنیم. اما مدل‌های تبدیل‌شده‌ای که از checkpoint های باز و بدون سفارش تولید می‌کنیم به OpenVoiceOS می‌روند، پلتفرم باز دستیار صوتی‌ای که این مدل‌ها برای اجرا روی آن ساخته شده‌اند — نه به فضای نام خودمان.

دلیلش روشن است: OpenVoiceOS جایی است که مدل‌ها استفاده می‌شوند. یک مدل تبدیل‌شده که در یک حساب شرکتی نشسته یک artifact خوب است. همان مدل، منتشرشده جایی که ovos-stt-plugin-onnx-asr، ovos-stt-plugin-coreml یا ovos-stt-plugin-rover بتوانند آن را با نام پیدا کنند، زبانی است که یک دستیار واقعی اکنون می‌تواند بگوید یا بفهمد. انتشار زیر سازمان خودِ پلتفرم چیزی است که یک تبدیل را به عملکرد پشتیبانی‌شده تبدیل می‌کند به‌جای یک کنجکاوی پژوهشی، و راهی است که مطمئن می‌شویم انجام این کار یک‌بار به سود هر نصب OpenVoiceOS تمام می‌شود، نه فقط مشتری‌ای که آن را درخواست کرده.

برای روشن بودن دربارهٔ انتساب: ما این مدل‌های صوتی را از صفر آموزش نمی‌دهیم، و چنین ادعایی هم نداریم. پژوهش زیربنایی — مدل‌های Parakeet و Conformer انویدیا، مدل‌های IndicConformer از AI4Bharat برای زبان‌های هندی، مدل‌های دانشگاهی و مؤسسات عمومی مانند Proxecto Nós گالیسیا یا مدل‌های Conformer مرکز HiTZ باسک، و تلاش‌های مستقل تبدیل مدل برای زبان‌های آفریقایی و اقلیت — متعلق به تیم‌هایی است که آن‌ها را آموزش داده‌اند. آنچه ما می‌افزاییم تبدیل، کوانتیزه، بررسیِ درستی در برابر نسخهٔ اصلی، و اتصال افزونه‌ای است که به یک دستیار اجازه می‌دهد نتیجه را با نام بارگذاری کند.

مقیاس آن کار تبدیل، به‌طور مستقیم از آنچه منتشر شده شمرده: بیش از نود گونهٔ ASR از Parakeet (در اندازه‌ها، زبان‌ها و سطوح کوانتیزهٔ مختلف) صادرشده به ONNX و CoreML؛ بیش از سی مدل Conformer انویدیا؛ بیست‌ودو مدل IndicConformer از AI4Bharat که زبان‌های کم‌منبع هندی را پوشش می‌دهند؛ بیست‌ودو مدل wav2vec2 برای زبان‌هایی از جمله سوئدی، ایسلندی، فارویی، فنلاندی و هر دو صورت نوشتاری نروژی؛ نه مدل Conformer برای باسکی و گالیسیایی؛ و مدل‌های Whisper و wav2vec2 تبدیل‌شده به‌طور مستقل که زبان‌های آفریقایی و کریول مانند شونا، زولو، خوسا، مالاگاسی، کریول هائیتی و قبایلی را پوشش می‌دهند. با شمارش تنها تبدیل‌های تأییدشدهٔ ASR بر اساس کدِ زبانِ متمایز، این دست‌کم ۷۴ زبان مختلف با یک تشخیص‌دهندهٔ گفتارِ آفلاین و کوانتیزه‌شدهٔ در دسترس امروز است — پیش از شمارش فهرست جداگانهٔ صداهای TTS صادرشده برای زبان‌هایی مانند باسکی، آراگونی، آستوریایی، گالیسیایی، اکسیتانی و عربی.

اگر زبان یا دستگاه شما امروز هیچ گزینهٔ آفلاینی ندارد

بیشتر زبان‌ها هرگز یک گزینهٔ تجاریِ گفتارِ آفلاین نمی‌گیرند، چون بازار آن زبان به‌تنهایی توجیه‌گر ساخت آن توسط یک فروشنده نیست. الگوی بالا — گرفتن یک checkpoint باز موجود، تبدیل آن به قالبی که روی سخت‌افزاری که واقعاً دارید اجرا می‌شود، کوانتیزهٔ آن تا جا بگیرد، بررسی آن در برابر نسخهٔ اصلی، و اتصال آن به یک افزونه — به اندازهٔ بازار وابسته نیست. به وجود داشتنِ یک checkpoint باز برای شروع وابسته است، که به‌طور فزاینده حالت عادی است.

اگر مدل گفتاری‌ای دارید که تنها روی یک GPU آموزشی اجرا می‌شود، یا دستگاهی که اکنون هیچ پشتیبانی گفتارِ آفلاینی به زبانش ندارد، با ما تماس بگیرید یا ببینید این کار سرتاسر روی صفحهٔ خدمات ما چه شکلی دارد.