Cartesia وبوابة TrueFoundry AI: التمرير الأصيل للاستدلال الصوتي

يتكامل نموذج تحويل النص إلى كلام Sonic-3.5 من Cartesia ونموذج تحويل الكلام إلى نص بالبث Ink-2 مع بوابة TrueFoundry AI عبر واجهة تمرير مباشر أصلية. تتدفق الطلبات إلى نقطة نهاية HTTP الخاصة بـ Cartesia على المسار /tts/bytes وتدفق أحداث الخادم المرسلة على المسار /tts/sse و WebSocket ثنائي الاتجاه على المسار /tts/websocket و WebSocket الخاص ببث Ink، مع الحفاظ على دلالات بروتوكولاتها الأصلية. تقوم البوابة بحقن مفتاح API الخاص بـ Cartesia من مخزن بيانات الاعتماد المركزي الخاص بها وتُجري التحكم في الوصول وتُصدر نطاقات OpenTelemetry قبل إعادة توجيه الاتصال.

يشرح هذا المنشور لماذا لا يمكن لمقدمي خدمات استدلال الصوت استخدام نفس نمط الترجمة المتوافق مع OpenAI الذي تطبقه البوابة على مقدمي خدمات إكمال الدردشة. ويغطي كيفية تعامل مستوى البوابة مع التمرير المباشر الأصلي داخل مسار طلبات Hono الحالي. كما يغطي واجهة برمجة تطبيقات Cartesia لكل من تحويل النص إلى كلام (TTS) وتحويل الكلام إلى نص (STT). ويشمل شكل التكوين وتدفق البيانات الشامل.

لماذا لا يستخدم مقدمو خدمات الصوت مسار ترجمة OpenAI

تعمل معظم تكاملات بوابة TrueFoundry AI على مبدأ الترجمة. يصل الطلب بتنسيق متوافق مع OpenAI على المسار /chat/completions أو /embeddings أو /responses. تحل البوابة معرف النموذج إلى نقطة نهاية المزود وتترجم الطلب إلى شكله الأصلي الخاص بالمزود عبر محول. يُترجم Anthropic إلى واجهة برمجة تطبيقات الرسائل (Messages API). يُترجم Google Vertex إلى واجهة برمجة تطبيقات اللغة التوليدية (Generative Language API). يُترجم Cohere إلى مخطط الدردشة الأصلي الخاص به. تعود الاستجابة وتُترجم بشكل عكسي بحيث يرى المتصل شكل OpenAI موحدًا بغض النظر عن المزود الفعلي الذي خدم الطلب.

يعمل هذا النمط لأن دلالات إكمال الدردشة متكافئة تقريبًا عبر المزودين. توجد قائمة رسائل ومعرف نموذج ومعلمات أخذ العينات وعلامة بث واستجابة تتضمن استدعاءات الأدوات وأسباب الانتهاء. الاختلافات حقيقية ولكنها ضيقة ويمكن التوفيق بينها داخل محول.

استدلال الصوت لا يتناسب مع هذا القالب. تحتوي واجهة برمجة تطبيقات تحويل النص إلى كلام (TTS) الخاصة بـ Cartesia على معلمات ليس لها ما يعادلها في واجهة برمجة تطبيقات الصوت (Audio API) الخاصة بـ OpenAI. يقبل حقل الصوت معرف صوت Cartesia أو تضمينًا صوتيًا. تحدد كتلة output_format الحاوية والترميز ومعدل العينة ككائن منظم. يختار حقل اللغة من بين 42 لغة مدعومة. تحمل كتلة __experimental_controls معلمات السرعة والعاطفة التي تتوافق مع عناصر التحكم التعبيرية لـ Sonic-3.5. يقدم بروتوكول WebSocket سياقات متعددة الإرسال وحدود flush_id ودلالات الاستمرارية لتدفق إدخال النص من نموذج لغوي كبير (LLM) أعلى. لا شيء من هذا موجود في شكل OpenAI /v1/audio/speech.

مسار Ink-2 لتحويل الكلام إلى نص (STT) مشابه. يمرر بروتوكول WebSocket للبث إطارات الصوت في الوقت الفعلي ويُصدر نصوصًا مؤقتة ونصوصًا نهائية عندما يكتشف النموذج حدود الدور ذات المعنى الدلالي من خلال الكشف الأصلي عن الدور. نقطة نهاية OpenAI /v1/audio/transcriptions هي تحميل ملف طلب واستجابة بدون نظير للبث في المواصفات الرسمية.

ترجمة هذه الواجهة إما أن تؤدي إلى فقدان القدرة أو إدخال تعيينات غير دقيقة (فقدان للبيانات). لذلك، تعرض البوابة Cartesia من خلال التمرير المباشر الأصلي. يستمر المتصل في استخدام حزمة تطوير برامج بايثون (Python SDK) الرسمية لـ Cartesia أو أي عميل Cartesia آخر بكامل مجموعة ميزاته. تقع البوابة في المسار كحد للتحقق من الهوية والسياسة والمراقبة بدلاً من كونها مترجم بروتوكول.

كيف يعمل التمرير المباشر الأصلي داخل مستوى البوابة

بوابة TrueFoundry AI مبنية على إطار عمل Hono. تتعامل حاوية بوابة واحدة (pod) تعمل على 1 وحدة معالجة مركزية افتراضية (vCPU) و1 جيجابايت من ذاكرة الوصول العشوائي (RAM) مع أكثر من 250 طلبًا في الثانية (RPS) مع زمن انتقال إضافي يبلغ حوالي 3 مللي ثانية. الحاويات عديمة الحالة وتعتمد على وحدة المعالجة المركزية وتتوسع أفقيًا لتصل إلى عشرات الآلاف من الطلبات في الثانية. مستوى البوابة ومستوى التحكم منفصلان. يدير مستوى التحكم التكوين في PostgreSQL و ClickHouse وينشر التحديثات عبر NATS. تقوم حاويات البوابة بتخزين هذا التكوين مؤقتًا في الذاكرة.

عندما يصل طلب Cartesia إلى حاوية بوابة، يتم تشغيل نفس مسار ما قبل التوجيه الذي يعمل لإكمال الدردشة. يتم التحقق من صحة رمز JWT المقدم في الطلب مقابل مفاتيح IdP العامة المخزنة مؤقتًا دون الحاجة إلى استدعاء مصادقة خارجي. يتم التحقق من التفويض مقابل خريطة المستخدمين إلى النماذج المخزنة في الذاكرة والتي يحافظ NATS على تزامنها. تحل طبقة التوجيه معرف النموذج (مثل sonic-3.5 أو ink-2) إلى نقطة نهاية المزود المكونة لهذا النموذج وإلى بيانات اعتماد حساب Cartesia المخزنة في مستوى التحكم. لا يتم إعادة كتابة نص الطلب والمسار ومعلمات الاستعلام. يتم فقط تجريد رؤوس Authorization و X-API-Key من الطلب الوارد واستبدالها بمفتاح API الخاص بـ Cartesia من مخزن بيانات الاعتماد الآمن. يصبح عنوان URL المعاد توجيهه هو أصل Cartesia (https://api.cartesia.ai/...) مع الحفاظ على المسار والطريقة المطابقين. يتم بث النص الأساسي دون تغيير.

بالنسبة لنقاط نهاية WebSocket (wss://api.cartesia.ai/tts/websocket ونقطة نهاية بث Ink)، تُجري البوابة مصافحة ترقية HTTP. بعد نجاح الترقية، تحتفظ البوابة باتصالين WebSocket (أحدهما مع العميل والآخر مع Cartesia) وتعمل كوكيل للإطارات في كلا الاتجاهين. يتم الحفاظ على نموذج السياق متعدد الإرسال الذي تعرضه Cartesia لأن البوابة لا تفسر حمولات الإطارات. العميل الذي يفتح WebSocket واحدًا ويُجري عشرات عمليات التوليد المتزامنة مقابل قيم context_id مختلفة يرى نفس السلوك عبر البوابة كما لو كان يتحدث إلى Cartesia مباشرة.

يعمل مسار نشر التتبع غير المتزامن الذي تستخدمه البوابة لإكمال الدردشة أيضًا لحركة مرور Cartesia. تُصدر البوابة نطاقات لمعالج HTTP الوارد وحل بيانات الاعتماد واستدعاء المزود الصادر (أو جلسة WebSocket). بالنسبة لطلبات تحويل النص إلى كلام (TTS)، تحمل هذه النطاقات المدة والحالة واسم النموذج المحلول وتجزئة النص. بالنسبة لجلسات تحويل الكلام إلى نص (STT)، يلتقط النطاق عمر الاتصال وعدد الرسائل. يتم نشر النطاقات بشكل غير متزامن إلى NATS بعد اكتمال الطلب. يقرأ مصدر OpenTelemetry من المسار غير المتزامن ويعيد توجيه التتبعات إلى الواجهة الخلفية المكونة (gRPC أو HTTP). التصدير إضافي ولا يغير تخزين التتبع الخاص بالبوابة. لا تفشل البوابة أبدًا طلب Cartesia حتى لو كانت نقطة نهاية OTEL الخارجية غير قابلة للوصول.

يعمل مسار تتبع التكلفة أيضًا في وضع التمرير المباشر. تحاسب Cartesia على أساس الاعتمادات التي تُترجم إلى أحرف مُركبة لتحويل النص إلى كلام (TTS) وثوانٍ مُنسوخة لتحويل الكلام إلى نص (STT). تسجل البوابة حجم الطلب وبيانات تعريف مدة الاستجابة وتنشرها إلى نفس ناقل أحداث NATS الذي يجمع بيانات تكلفة إكمال الدردشة. تحسب خدمة المجمع إجماليات لكل مستخدم ولكل فريق ولكل نموذج تظهر في عرض التحليلات الموحد جنبًا إلى جنب مع حركة مرور الدردشة.

ما تعرضه Cartesia

تبني Cartesia نماذج صوتية على بنية نموذج فضاء الحالة. تُسمى عائلة تحويل النص إلى كلام (TTS) Sonic والنموذج الإنتاجي الحالي هو Sonic-3.5. تُسمى عائلة تحويل الكلام إلى نص (STT) Ink والنموذج الإنتاجي الحالي هو Ink-2.

Sonic-3.5 هو نموذج تحويل النص إلى كلام (TTS) للبث بزمن وصول الصوت الأول أقل من 90 مللي ثانية ودعم أصلي لـ 42 لغة. وهو مصنف رقم 1 من حيث الطبيعية وينطق الأرقام والحروف الأبجدية مثل أرقام الهواتف والمعرفات ورسائل البريد الإلكتروني بشكل صحيح دون معالجة مسبقة، مع معالجة الكلمات الإنجليزية المتجانسة لفظًا والمختلفة معنى وكتابة مثل read و bass من السياق المحيط. يعرض عناصر تحكم دقيقة في مستوى الصوت والسرعة والعاطفة من خلال معلمات API وعلامات SSML. يتم عرض النموذج من خلال ثلاثة أشكال لنقاط النهاية تناسب حالات استخدام مختلفة.

الأول هو POST /tts/bytes. هذه نقطة نهاية متزامنة للدفعات تُرجع ملف الصوت بالكامل في نص الاستجابة. تقبل تنسيقات إخراج MP3 أو WAV أو PCM الخام وهي مناسبة لتوليد الأصول الصوتية مسبقًا حيث يكون زمن الانتقال الكامل لانتظار الإخراج الكامل مقبولاً.

الثاني هو POST /tts/sse. هذا تدفق أحداث مرسلة من الخادم. يُصدر النموذج أجزاء صوتية تدريجيًا أثناء توليدها. يناسب هذا التطبيقات التي تشغل الصوت تدريجيًا وتحتاج إلى ميزة وقت البايت الأول ولكنها لا تحتاج إلى بث النص المدخل إلى النموذج.

الثالث هو WSS /tts/websocket. هذه هي نقطة النهاية الموصى بها لوكلاء الصوت في الوقت الفعلي. الاتصال ثنائي الاتجاه ويدعم التوليدات المتعددة عبر حقل context_id. يمكن لـ WebSocket واحد مفتوح أن يحمل عشرات التوليدات المتزامنة. يسمح context_id بتوليد الاستمرارية حيث يمكن دفع مقاطع نصية إضافية إلى سياق موجود للحفاظ على النبرة عبر نقاط الربط. يعد هذا مهمًا عندما يكون مصدر النص الأصلي هو نموذج لغوي كبير (LLM) يقوم بالبث رمزًا تلو الآخر، وتحتاج تقنية تحويل النص إلى كلام (TTS) إلى متابعة إيقاع توليد النص. يدعم بروتوكول WebSocket أيضًا التفريغ اليدوي عبر علامات flush_id التي تنشئ حدودًا صوتية منفصلة ضمن سياق واحد.

Ink-2 هو نموذج STT للبث المباشر، تم بناؤه من الألف إلى الياء لوكلاء الصوت الإنتاجيين. يسجل أقل معدل خطأ في الكلمات وأفضل اكتشاف للدور من بين أي نموذج STT للبث المباشر، وينسخ البيانات المنظمة مثل أرقام الهواتف والتواريخ ورسائل البريد الإلكتروني بدقة من أول مرة. قدرته المميزة هي اكتشاف الدور الأصيل. يعرف Ink-2 متى يبدأ المتحدث وينتهي دون الحاجة إلى VAD منفصل، ويصدر دورة حياة كاملة لأحداث الدور (turn.start و turn.update و turn.eager_end و turn.resume و turn.end) حتى يعرف الوكيل بالضبط متى يستمع ويفكر ويستجيب. يحدد تحديد نقطة النهاية الدلالي نهاية الدور بالمعنى بدلاً من الصمت، بحيث لا تؤدي وقفة في منتصف الفكرة إلى تشغيل الوكيل قبل الأوان، بينما يمنح turn.eager_end النموذج اللغوي الكبير (LLM) اللاحق ميزة البدء المبكر قبل تأكيد اكتمال الدور. نقطة النهاية هي WebSocket للبث المباشر يقبل إطارات صوت PCM بتردد 16 كيلو هرتز ويصدر نصوصًا مؤقتة ونهائية عندما يلتزم بها النموذج. الترميز الصوتي الافتراضي هو pcm_s16le بتردد 16000 هرتز.

تقوم Cartesia بقطع اتصالات WebSocket بعد 3 دقائق من عدم النشاط. تتم إعادة ضبط المهلة مع كل إطار يتم إرساله في أي من الاتجاهين. عادةً ما يقوم العملاء بتشغيل آليات الحفاظ على الاتصال (keepalives) القائمة على الصمت لإبقاء الاتصال مفتوحًا عبر فجوات النطق.

واجهة التكامل

تتم إضافة Cartesia إلى بوابة TrueFoundry AI في ثلاث خطوات من لوحة التحكم. انتقل إلى AI Gateway ثم إلى Models واختر Cartesia. أضف حساب Cartesia بإدخال اسم حساب فريد ومفتاح Cartesia API. يتم تخزين المفتاح مشفرًا في مستوى التحكم ولا يتم كشفه أبدًا لوحدات بوابة (gateway pods) مباشرةً. اختياريًا، أضف متعاونين للتحكم في المستخدمين والفرق التي يمكنها توجيه حركة المرور عبر هذا الحساب. ثم سجل نموذجًا واحدًا أو أكثر بالنقر على "إضافة نموذج" (Add Model) وتوفير اسم عرض (Display name) ومعرف نموذج (Model ID) ونوع نموذج (Model type). بالنسبة لـ Cartesia، يجب أن يكون معرف النموذج (Model ID) واسم العرض (Display name) متطابقين ويجب أن يتطابقا تمامًا مع معرف نموذج Cartesia (مثل sonic-3.5 و ink-2 وما إلى ذلك).

واجهة إعداد حساب Cartesia بسيطة.

يستخدم الاستدلال حزمة تطوير البرامج (SDK) الأصلية لـ Cartesia مع استبدال عنوان URL للبوابة كعنوان URL الأساسي. يبدو عميل Python كما يلي.

import os
from cartesia import Cartesia

client = Cartesia(
    api_key=os.environ["TFY_API_KEY"],
    base_url="https://<your-gateway-host>/cartesia",
)

response = client.tts.bytes(
    model_id="sonic-3.5",
    transcript="The road goes ever on and on.",
    voice={"mode": "id", "id": "6ccbfb76-1fc6-48f7-b71d-91ac6298247b"},
    output_format={"container": "wav", "encoding": "pcm_f32le", "sample_rate": 44100},
)

تعمل نفس استدعاءات حزمة تطوير البرامج (SDK) لنقطة نهاية WebSocket ولـ Ink-2 STT WebSocket. يحل JWT الصادر عن TrueFoundry محل مفتاح Cartesia API في إعدادات حزمة تطوير البرامج (SDK). تعتقد حزمة تطوير البرامج (SDK) أنها تتحدث إلى Cartesia مباشرة لأن البوابة تحافظ على مسارات عناوين URL وأشكال الاستجابة. تتم إدارة التكلفة والتحكم في الوصول والتتبع كلها بشكل غير مرئي في مسار الطلب.

ملخص البنية

تدفق البيانات الشامل (من البداية إلى النهاية) مباشر وواضح. يفتح العميل طلب HTTP أو WebSocket مقابل عنوان URL للبوابة باستخدام حزمة تطوير البرامج (SDK) الخاصة بـ Cartesia. تقوم وحدة البوابة (gateway pod) بمصادقة JWT مقابل مفاتيح IdP العامة المخزنة مؤقتًا وتحل معرف النموذج إلى حساب Cartesia المكون. تزيل رأس المصادقة الوارد وتستبدله بمفتاح Cartesia API من مخزن بيانات الاعتماد. تقوم بإعادة توجيه الطلب أو ترقية WebSocket إلى https://api.cartesia.ai. بالنسبة لجلسات WebSocket، تقوم بربط الإطارات في كلا الاتجاهين حتى يغلق أحد الطرفين الاتصال. بعد اكتمال الطلب، تنشر البوابة نطاقًا إلى NATS الذي يغذي مصدر OTEL ومجمع التكلفة.

ما لا يلزم هو أمر مهم. لا يوجد تفرع لحزمة تطوير البرامج (SDK) الخاصة بـ Cartesia. لا توجد طبقة ترجمة خفية تقوم بتسطيح معلمات TTS إلى شكل OpenAI Audio وتفقد معرف الصوت ونموذج سياق البث في هذه العملية. لا يوجد مسار تتبع منفصل لحركة مرور الصوت وآخر مختلف لحركة مرور الدردشة. لا يوجد مفتاح API لكل خدمة موزع عبر رمز التطبيق. لا يوجد مُنهي WebSocket من جانب العميل يجب نشره بشكل منفصل لتطبيق التحكم في الوصول إلى نقاط نهاية البث.

المبدأ المعماري الذي يجعل هذا يعمل هو الفصل بين دلالات البروتوكول ودلالات الحوكمة. يحمل بروتوكول Cartesia معنى خاصًا بمجال الصوت لا يمكن تعميمه بسهولة على مزودين آخرين. طبقة الحوكمة (المصادقة والترخيص وحقن بيانات الاعتماد والمراقبة وتتبع التكلفة) مستقلة عن المزود ويمكن تشغيلها أمام أي مصدر HTTP أو WebSocket دون فحص الحمولة. يحافظ التمرير الأصيل (Native passthrough) على الأول بينما يطبق الثاني. والنتيجة هي أن سطح الميزات الكامل لـ Cartesia (سياقات Sonic-3.5 واستمراريته وضوابط العاطفة وتدفق النسخ الصوتي المباشر لـ Ink-2) متاح للعملاء، بينما تنطبق الضمانات التشغيلية التي توفرها بقية بوابة الذكاء الاصطناعي (AI Gateway) لحركة مرور الدردشة على حركة مرور الصوت على نفس وحدات البوابة (gateway pods) بنفس مستوى التحكم ونفس الواجهات الخلفية للتتبع والتكلفة.