كُتب هذا المقال للمهندسين الذين أرادوا إضافة وكيل صوتي لكنهم ترددوا أمام الارتباط بمزوّد واحد وتكلفة واجهة OpenAI Realtime، ولمسؤولي البنية التحتية الذين يوازنون ما إذا كان الصوت الحواري قابلاً للتشغيل على حزمتهم الخاصة. باختصار، إن تصميم العرض التجريبي hugging-voice من Hugging Face والمكتبة التي تعمل تحته، speech-to-speech، بسيط وعملي في آن معاً. فهو يفتح خط المعالجة الصوتي اللحظي بمراحله الأربع كمصدر مفتوح، بينما يغلّف الطرف الخارجي بالواجهة نفسها التي يقدمها OpenAI Realtime. لذا إن كان لديك بالفعل كود مكتوب لعميل OpenAI اللحظي، فيمكنك الانتقال إلى حزمتك الخاصة بتغيير سطر واحد فقط: العنوان الذي يشير إليه الخادم. لا نستشهد بأرقام الأداء إلا ضمن النطاق الذي نشره المشروع، ونوضّح مسبقاً أنها ليست أرقاماً قسناها بأنفسنا.
نظرة عامة
خلال العام الماضي، لم يعد الصوت الحواري ميزة جانبية لروبوتات الدردشة النصية، بل صار فئة منتجات قائمة بذاتها. يتكلم المستخدم، ويتوقع أن يعود الرد فوراً، بالطريقة التي يتدفق بها حوار بشري. المشكلة أن المسار التجاري لتلبية هذا التوقع تقارب فعلياً نحو حفنة من الخدمات المغلقة مثل واجهة OpenAI Realtime. مريحة، نعم، لكن حركة الصوت تُحاسَب عادةً بالثانية لا بالرمز، وتخرج البيانات من نطاقك، ويرتبط كل من النموذج والأصوات بالمزوّد.
يأتي hugging-voice كمثال معاكس لهذا الاتجاه. عنوانه الفرعي يقولها مباشرة: “صوت لحظي مفتوح يمكنك فعلاً تشغيله بنفسك”. الفكرة الجوهرية هي أن الرحلة كاملة، أي تحويل الصوت الوارد إلى الميكروفون إلى نص، وإرساله إلى نموذج لغوي، وإعادة الرد صوتاً، مفتوحة كخط معالجة يمكن استبدال كل مكوّن فيه. بالنسبة لنا نحن الذين نخدم النماذج في بيئات محلية وسيادية، يعني هذا أنه صار هناك تطبيق مرجعي ملموس لسؤال “هل يمكن تشغيل الصوت اللحظي على مجموعتنا الخاصة؟”
ما هو hugging-voice وما هو speech-to-speech
لنحدد المصطلحات أولاً: hugging-voice هو العرض التجريبي (Space) الذي يمكنك التحدث إليه مباشرة في المتصفح، والمحرك الذي يعالج الصوت داخله فعلياً هو مكتبة speech-to-speech. تقسّم المكتبة الوكيل الصوتي اللحظي إلى أربع مراحل: كشف النشاط الصوتي (VAD)، وتحويل الكلام إلى نص (STT)، ونموذج لغوي (LLM)، وتحويل النص إلى كلام (TTS). تعمل كل مرحلة في خيط منفصل وتُوصل بطوابير، بحيث يتدفق خرج مرحلة إلى المرحلة التالية بثاً حياً. يظهر نص جزئي قبل أن ينهي المستخدم كلامه، ويبدأ توليد الكلام على الكلمات الأولى قبل أن يكمل النموذج الجملة، ما يقلّص زمن الاستجابة المُدرَك.
تدفق صوتي لحظي"] --> B["كشف الكلام VAD
Silero VAD v5"] B --> C["التعرّف على الكلام STT
Parakeet TDT · Whisper"] C --> D["توليد الرد LLM
OpenAI-compatible API · vLLM · llama.cpp"] D --> E["تركيب الكلام TTS
Qwen3-TTS · Kokoro"] E --> F["خرج السماعة
تشغيل ببثّ حي"] G["خادم WebSocket
متوافق مع OpenAI Realtime"] -.- B G -.- C G -.- D G -.- E
في هذا المخطط، خادم WebSocket على اليمين هو سلاح المشروع الحقيقي. مجرد لصق أربع مراحل معاً ليس جديداً. ما يميّز speech-to-speech هو أنه يغلّف خط المعالجة بأكمله بنقطة نهاية WebSocket متوافقة مع بروتوكول OpenAI Realtime. هذا يتيح لعميل OpenAI لحظي قائم أن يتصل بهذا الخادم كأنه OpenAI نفسه. ويجدر بالذكر أن هذه الحزمة ليست لعبة تجريبية: فهي تشغّل البنية التحتية الصوتية اللحظية لروبوتات Reachy Mini من Hugging Face في الإنتاج.
الانتقال بسطر واحد
هذا هو الجزء الذي يسمّيه المشروع نفسه “الترحيل بسطر واحد”. الشيء الوحيد الذي على عميل كان يستخدم OpenAI Realtime تغييره هو عنوان الاتصال. في ما يلي مثال عميل Python الذي توثّقه وثائق المشروع.
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8765/v1",
websocket_base_url="ws://localhost:8765/v1",
api_key="not-needed",
)
with client.realtime.connect(model="local") as conn:
conn.send({
"type": "session.update",
"session": {
"type": "realtime",
"instructions": "You are a helpful assistant.",
"audio": {
"input": {
"turn_detection": {
"type": "server_vad",
"interrupt_response": True,
}
}
},
}
})
for event in conn:
print(event.type)
ما يستحق الانتباه هو أن base_url وwebsocket_base_url يشيران إلى خادم محلي، وأن api_key غير مطلوب فعلياً. أما التعليمات المُمرَّرة عبر session.update، وكشف الأدوار المعتمد على VAD في جهة الخادم، ومقاطعة الرد أثناء بثّه، فكلها تتبع المخطط نفسه الذي يتبعه OpenAI Realtime. بعبارة أخرى، يكاد كود التطبيق لا يتغير، ولا ينتقل سوى الخلفية من واجهة خارجية إلى خادمك الخاص. وللفرق التي تقلق من الارتباط بمزوّد واحد، فإن توافق الواجهة هذا يمثّل بمفرده أكبر قيمة عملية.
التثبيت والتشغيل
مسار إقامة الخادم مختصر بالقدر نفسه. يغطي التثبيت الافتراضي المسار اللحظي القياسي دفعة واحدة.
pip install speech-to-speech
يستخدم الإعداد الافتراضي Parakeet TDT لـ STT، وواجهة متوافقة مع OpenAI لـ LLM، وQwen3-TTS لـ TTS. وإن احتجت خلفية محددة، فثبّتها بالإضافات.
pip install "speech-to-speech[kokoro]"
pip install "speech-to-speech[faster-whisper]"
يبدو تشغيل الخادم هكذا. يطلق هذا الأمر خادماً متوافقاً مع OpenAI Realtime عبر WebSocket محلي.
export OPENAI_API_KEY=...
speech-to-speech
النقطة المثيرة هنا هي أن مرحلة LLM يمكن أن تعمل محلياً بالكامل. في ما يلي مثال يقيم نموذجاً من فئة Gemma 4 بواسطة llama.cpp، ويجعل speech-to-speech يشير إلى تلك النقطة المحلية.
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF -np 2 -c 65536
speech-to-speech \
--model_name "ggml-org/gemma-4-E4B-it-GGUF" \
--responses_api_base_url "http://127.0.0.1:8080/v1" \
--responses_api_api_key ""
على أجهزة Mac بمعالج Apple Silicon يمكنك تفعيل الإعدادات المحسّنة وربط نموذج mlx، وعلى العكس، إن نقص عتاد GPU المحلي، يمكنك توجيه خلفية LLM إلى Hugging Face Inference Providers.
speech-to-speech \
--local_mac_optimal_settings \
--model_name "mlx-community/Qwen3-4B-Instruct-2507-bf16"
إن القدرة على نقل خط المعالجة نفسه عبر الطيف كله، من التشغيل المحلي الكامل إلى تفويض الاستدلال السحابي، ببضعة أعلام (flags)، هي فضيلة في التصميم.
استبدال الوحدات: خلفيات STT وLLM وTTS
سبب قراءة هذا المشروع كبنية مرجعية لا مجرد عرض تجريبي هو أن خلفية كل مرحلة قابلة للاستبدال. باختصار:
| المرحلة | الخلفية الافتراضية | البدائل |
|---|---|---|
| VAD | Silero VAD v5 | مدمجة فقط |
| STT | Parakeet TDT | Whisper, Faster Whisper, Paraformer |
| LLM | واجهة متوافقة مع OpenAI | Transformers, mlx-lm, vLLM, llama.cpp |
| TTS | Qwen3-TTS | Kokoro, Pocket TTS, ChatTTS, MMS |
وهناك أيضاً أربعة أوضاع تشغيل. الوضع الافتراضي realtime هو WebSocket الذي يتكلم بروتوكول OpenAI Realtime؛ ويرتبط local مباشرة بالميكروفون والسماعة؛ ويتبادل الوضعان websocket وsocket صوت PCM الخام عبر WebSocket وTCP على التوالي. ويمكن تحديد اللغة أو تركها للكشف التلقائي. إن القدرة على مزج دقة STT، وجودة LLM وتكلفته، وطابع TTS وزمن استجابته بما يناسب متطلباتك، هي بالضبط درجة الحرية التي لا تمنحها واجهة مغلقة.
زمن الاستجابة، وحالة واقعية
في الوكيل الصوتي، يهمّ زمن الاستجابة بقدر ما تهمّ الدقة. يشعر الناس بانقطاع الحوار إذا تأخر الرد بضع مئات من الأجزاء من الثانية فقط. يستهدف العرض التجريبي للصوت اللحظي الذي نشرته Hugging Face بالتعاون مع Cerebras مشكلة زمن الاستجابة مباشرة. يستخدم الإعداد Parakeet من Nvidia لـ STT، ونموذج Gemma 4 من Google DeepMind يعمل على استدلال Cerebras للنموذج اللغوي، وQwen3-TTS من Alibaba لـ TTS. والهدف هو خفض زمن استجابة مرحلة LLM باستدلال Cerebras فائق السرعة كي يتدفق الحوار بطبيعية تضاهي التحدث إلى إنسان. غير أنه، ضمن ما استطاع هذا المقال التحقق منه، لم تُنشر أرقام محددة بالأجزاء من الثانية، لذا نتحفظ عن مقارنة كمية.
وهناك دليل إنتاجي أيضاً. تشغّل هذه الحزمة روبوتات Reachy Mini المذكورة آنفاً، وتذكر Hugging Face أن أكثر من 9,000 روبوت منتشرة بالفعل في الميدان. وسبب هوس المشروع بزمن الاستجابة هو أن سرعة الاستجابة في البيئات المدمجة هي ما يجعل التفاعل “يبدو حياً”. وقد تناولنا سابقاً ميزانية زمن الاستجابة للوكلاء الصوتيين من زاوية خدمة GPU، فإن كنت تفكر في كيفية توزيع زمن الاستجابة عبر كل مرحلة من خط المعالجة، نقترح قراءة ميزانية زمن استجابة الوكيل الصوتي وخدمة GPU إلى جانب هذا المقال.
دلالات على منتجات ThakiCloud
يتشابك خط المعالجة هذا بطبيعية مع منتجينا كليهما.
من منظور ai-platform، فإن مرحلة LLM في speech-to-speech لا تستهلك في النهاية سوى نقطة نهاية متوافقة مع OpenAI، لذا يمكنك وضع خدمة vLLM من ThakiCloud مباشرة في ذلك المكان. ويصبح نموذجا STT وTTS حِملين منفصلين يشغلان GPU، وقوّتنا تكمن بالضبط في تحميل مثل هذه الأحمال الاستدلالية غير المتجانسة على مجموعة واحدة معاً، بجدولة GPU عبر Kueue وعزلها بين المستأجرين. وحركة الصوت تميل إلى تراكم التكلفة بالثانية، لذا تعمل تنافسية تكلفة الوحدة للخدمة الذاتية بقوة خاصة، وتلائم هذه الحزمة المفتوحة المتطلبات المحلية والسيادية حيث يجب ألا تغادر البيانات المبنى. وللعملاء الذين تمثّل لهم واجهة صوتية مغلقة عبئاً، يمكننا أن نقدّم خيار “تشغيلها على مجموعتك الخاصة عبر الواجهة نفسها”.
ومن منظور Paxis، الصوت قناة دخل وخرج جديدة تُلحق بالوكيل. Paxis هو مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى، وواجهة speech-to-speech المتوافقة مع OpenAI Realtime تسهّل إضافة قناة الصوت هذه إلى تنسيق الوكلاء القائم. فيمكن تكوين مسار يصبح فيه أمر منطوق دخلاً للوكيل، وتعود فيه نتيجة تنفيذ مهارة صوتاً، مع مرورها عبر بوابات السياسات وسجلات التدقيق. الخدمة الذاتية منخفضة التكلفة (ai-platform) تصنع اقتصاديات الوكلاء الصوتيين، وفوقها يتعامل مستوى التحكّم Agent-Native (Paxis) مع الصوت كقناة بأمان.
خاتمة
الرسالة التي يبعثها hugging-voice واضحة. لم يعد الصوت اللحظي مضطراً للاتكاء وحده على واجهات مغلقة لبضعة مزوّدين؛ وعند الحاجة، يمكنك إبقاء الواجهة كما هي ونقل الخلفية وحدها إلى بنيتك التحتية الخاصة. هذا التصميم، باختيار كل مرحلة من VAD إلى TTS وتغيير سطر واحد فقط لدى العميل، يخفض بشدة الحاجز أمام الفرق التي تدرس الخدمة الذاتية. وإن أردت رؤيته بنفسك، فتحدّث إليه مباشرة في العرض التجريبي (Space)، أو ابدأ بـ pip install speech-to-speech من مستودع GitHub.
بنية حلقة التحكم التي يراقب فيها عميل نموذج لغوي كبير قياسات وحدة معالجة الرسوميات وعمق طابور كل مستأجر، وينتج قيمة ضبط محدودة النطاق للتزامن، ليعيد من خلالها ضبط تشكيلة الدفعة (batch configuration). هذا رسم تخطيطي مفاهيمي للبنية، وليس نتيجة مقيسة فعلياً على عتاد.
سجّلت السياسة الثابتة أعلى إنتاجية وأقل عدد من الطلبات المُسقَطة، بينما كان أداء كلا الشكلين الديناميكيين ضعيفاً في المحاكاة. هذه نتائج محاكاة قائمة انتظار حتمية بمتوسط 20 بذرة عشوائية، وليست قيماً مقيسة فعلياً على وحدة معالجة رسوميات.
كان زمن الاستجابة عند المئين 99 للسياسة الثابتة هو الأدنى، ولم يتمكن أي من المتحكمين الديناميكيين من تقليل زمن الاستجابة في الذيل (tail latency) ضمن نطاق هذه المحاكاة. هذه نتائج محاكاة بمتوسط 20 بذرة عشوائية، وليست قِيماً مقيسة فعلياً على عتاد.