DeepSeek تمنح المستخدمين رموزًا (توكنات) كتعويض بعد انقطاع استمر ساعات

فقدت DeepSeek في 15 أكتوبر دردشة الويب وواجهة API لعدة ساعات. نحو الساعة 8 صباحًا بدأت الخدمة تردّ برسالة «الخادم غير متاح مؤقتًا»، وأظهرت صفحة الحالة تأثّر ثلاثة مكوّنات دفعة واحدة: الدردشة وV4 Pro API وV4.1 Flash API. وفي وقت لاحق منحت الشركة المستخدمين رموزًا (توكنات) كتعويض. وهذه خطوة لافتة في السوق الصينية، إذ يكتفي مزوّدو النماذج عادةً بالاعتذار ونشر تحليل ما بعد الحادثة (postmortem).

كيف تطوّر العطل

وصلت الشكاوى الأولى نحو الساعة 8 صباحًا. فقد توقفت النسخة الويب وواجهة API عن الاستجابة تقريبًا في وقت واحد، وعند كثير من المستخدمين معًا، فبدت المشكلة منذ البداية واسعة النطاق لا محلية. وصنّفت صفحة الحالة الرسمية الحادثة على أنها انقطاع جزئي (partial outage). أي أن جزءًا من الطلبات كان قد يمرّ، لكن لم يكن ممكنًا الاعتماد على عمل مستقر.

بحلول الساعة 9 حدّثت DeepSeek إعلانها: تم تحديد السبب، وتتواصل أعمال الاستعادة. وفي الجزء المتاح من مادة Jiqizhixin ينقطع نص الإعلان، لذلك لا نذكر تفاصيل السبب الجذري (الشبكة، أو عنقود الاستدلال، أو النشر، أو الحمل)، فالشركة لم تكشف عنها علنًا. ويشير عنوان المادة الأصلية إلى توقف دام عدة ساعات.

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

لماذا التعويض بالرموز تحديدًا

اختيار هذه العملة منطقي. فواجهة API في DeepSeek تُحتسب تكلفتها بالرموز (التوكنات)، وبالتالي يندمج منح الرموز مباشرة في نموذج الفوترة القائم: لا حاجة إلى استرداد مبالغ ولا إلى فواتير ولا إلى تسويات محاسبية. وهي خطوة زهيدة الكلفة على الشركة نفسها أيضًا. فتكلفة الرموز الممنوحة تساوي كلفة الحوسبة لا سعر البيع بالتجزئة، ولا تتطلب في المدى القريب أموالًا فعلية.

وثمة أثر ثانٍ. فالرموز تربط العميل بالمنصة: من حصل على رصيد يكون أرجح أن ينفقه على DeepSeek بدلًا من أن ينتقل إلى المنافسين. وهذا تفسيرنا نحن لا تصريح من الشركة. أما حجم التعويض وشروط الحصول عليه فلم يرد ذكرهما في الجزء المتاح من المادة، لذلك لا يمكن تقدير مدى سخاء هذه الخطوة حتى الآن.

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

ما المعروف حتى الآن

• بداية العطل: نحو الساعة 8:00 صباحًا من 15 أكتوبر.
• الخدمات المتأثرة: دردشة الويب وV4 Pro API وV4.1 Flash API.
• التصنيف على صفحة الحالة: انقطاع جزئي.
• نحو الساعة 9:00: أعلنت DeepSeek أنها وجدت السبب.
• المدة: عدة ساعات، بحسب عنوان Jiqizhixin.
• التعويض: رموز (توكنات)؛ ولم يُذكر الحجم ولا الشروط في المواد المتاحة.

ما الذي ينبغي أن تفعله الفرق التي تعمل عبر API

أولًا: راجعوا الرصيد وسجل الإضافات في الحساب الشخصي. إذا كان التعويض تلقائيًا فينبغي أن يظهر هناك؛ وإذا كان يتطلب تقديم طلب فالأفضل عدم تأجيله.

ثانيًا: افحصوا كيف تعامل منتجكم مع صباح ذلك اليوم. إذا كانت الطلبات تفشل ببساطة مع خطأ، فهذا هو الوقت المناسب لإضافة إعادة المحاولة بفواصل زمنية متزايدة أسّيًا (exponential backoff) ومهلات زمنية لا تُعلّق واجهة المستخدم.

ثالثًا: أعدّوا مسارًا احتياطيًا. فنموذج احتياطي من مزوّد آخر، أو نموذج مفتوح محلي للسيناريوهات الحرجة، كلفته قليلة مقارنةً بعدة ساعات من التوقف. ويصلح لذلك أي موجّه طلبات (router) يبدّل تلقائيًا بحسب رمز الخطأ.

وأخيرًا، اشتركوا في صفحة الحالة وأعدّوا تنبيهات على مقاييس الأخطاء الخاصة بكم. فمعرفة المشكلة من شكاوى العملاء تأتي أبطأ من معرفتها عبر المراقبة، وفي حالة DeepSeek بلغت الفجوة بين العطل وأول بيان رسمي نحو ساعة.