AWS تضيف قياس الاستهلاك إلى البث الصوتي: 12 دقيقة من الصوت تساوي 720 وحدة

تستمر محادثة الوكيل الصوتي عشرين دقيقة، لكن العميل يصمت أحياناً، أو يستمع إلى الرد، أو يبحث عن رقم طلبه. فما الذي سيدخل فعلاً في فاتورة النموذج؟ أضافت AWS إلى SageMaker AI آلية تتيح لمزوّدي النماذج المعتمدة على البث إرسال الاستهلاك الفعلي إلى AWS Marketplace أثناء الجلسة. فإذا كان المنتج يحتسب ثواني الصوت المعالَج، تتحول 12 دقيقة من هذا الصوت إلى 720 وحدة مستحقة الدفع.

هذا تغيير مفيد للفرق التي تبيع أو تنشر خدمات التعرف على الكلام وتركيبه عبر Marketplace، إذ يتيح ربط رسوم الجزء البرمجي بالاستهلاك. أما تكلفة بنية SageMaker التحتية فتبقى بنداً منفصلاً: فنقطة النهاية (endpoint) المفعّلة تواصل استهلاك المال.

لماذا لا يكفي رد الخادم وحده

في واجهة API التقليدية يكون الأمر بسيطاً نسبياً: يُرسَل طلب، ثم تصل النتيجة، ويذكر الخادم حجم الاستخدام في ترويسة الرد. وعند هذه النقطة يكون العمل قد انتهى والاستهلاك معروفاً.

أما في الواجهة الصوتية فالاتصال يدوم أطول. يرسل العميل الصوت باستمرار ويتلقى النص المفرَّغ، وقد تستغرق الجلسة نصف دقيقة أو نصف ساعة. والترويسة المُمرَّرة عند إنشاء الاتصال لا تسمح بإبلاغ استهلاك جديد بانتظام. كما أن الدفع بالساعة للجزء البرمجي قد يشمل فترات يكون فيها النموذج متاحاً دون أن يعالج شيئاً.

حلّت AWS هذه المشكلة باتصال WebSocket ثانٍ بين SageMaker وخادم النموذج. الأول ينقل بيانات المعالجة والنتائج، والثاني ينقل رسائل صغيرة للفوترة. ويربط معرّف طلب مشترك بين الاتصالين وبين المحادثة الواحدة.

يحدد المزوّد بنفسه معنى الوحدة المستحقة الدفع. تستخدم الرسائل الاسم inference.count، لكنه لا يُلزم باعتبار كل طلب وحدة مستقلة؛ فقد تكون الوحدات مثلاً ثواني من الصوت. ويجب أن تتوافق قواعد الاحتساب والسعر مع العرض المنشور في Marketplace.

كيف يُحتسب الاستهلاك أثناء المحادثة

لنتخيل خدمة لتفريغ المكالمات تُحاسَب بالثانية من الصوت. جمع الخادم 30 ثانية من المعالجة وأرسل رسالة عن 30 وحدة مستخدمة. ثم عالج 30 ثانية أخرى وأبلغ عن 30 وحدة أخرى. كل سجل يتضمن الزيادة منذ التقرير السابق، لذلك فإن إعادة إرسال المجموع التراكمي ستضخّم الاستهلاك.

توصي AWS بالإبلاغ عن الاستخدام تدريجياً وإرسال السجل الأخير فور انتهاء الجلسة. وهكذا يقل الصوت المعالَج غير المحتسب عند الانقطاع المفاجئ. والاتصال المفتوح بحد ذاته لا يعني صوتاً مستحق الدفع، فهذا تحدده قواعد كل منتج.

وللقناة قيود: رسالة واحدة في الثانية لكل اتصال، وحد أقصى 512 بايت، وسجل واحد بالضبط في كل إطار نصي. ويمكن إرسال عدة وحدات متراكمة في سجل واحد. وللحماية من التكرار يوجد ClientToken: إذ يُهمَل أي سجل مكرر يحمل الرمز نفسه ضمن الاتصال الواحد.

كانت Deepgram الشريك الأول، وهي تستخدم الآلية لاحتساب رسوم التعرف على الكلام وتركيبه. وفي تكاملها يحسب الخادم الاستهلاك تلقائياً، ولا يحتاج تطبيق العميل إلى أي إعداد إضافي للقياس.

أين قد يضيع الاحتساب

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

يجب اتخاذ هذا القرار بحسب طبيعة المنتج. ففي مركز الاتصال قد تكون كلفة مقاطعة المحادثة أعلى من ثوانٍ غير محتسبة. ومع ذلك فالقناة الإلزامية لا تضمن خصماً صحيحاً: فالرسائل الخاطئة قد تُرفض رغم ذلك. كما أن التسليم عبر TCP لا يثبت أن الاستهلاك وصل إلى الفاتورة.

قبل الإطلاق توصي AWS باختبار بحجم معروف: إرسال 12 دقيقة من الصوت المحتسب، والحصول على مجموع 720 وحدة، ثم مطابقة سجلات الخادم مع تقارير البائع ومع المبالغ المحتسبة على المشتري. ويجب اختبار الانقطاعات والرسائل غير الصحيحة بشكل منفصل. والخلاصة العملية للمشتري: توضيح تعريف الوحدة واحتساب البنية التحتية على حدة. أما للمزوّد: فعليه إدراج مطابقة الاحتساب في إعداد الإصدار.