DeepSeek تفتح مصدر DeepInfer: 155 تريليون توكن يوميًا وهامش ربح 80%

نشرت DeepSeek في المصدر المفتوح محرك DeepInfer الذي يعمل عليه V4.1 Flash. وصدر مع الشيفرة تقرير هندسي بأرقام من بيئة الإنتاج: 155 تريليون توكن يوميًا من عنقود واحد، و96% إصابات في كاش الإدخال، ومتوسط time to first token يبلغ 400 مللي ثانية، وسرعة توليد 230 توكن/ثانية (حتى 300 للشيفرة البرمجية). وبحسب حسابات Latent Space، وبأسعار استثنائية قدرها $0,15 لكل مليون توكن إدخال و$0,60 لكل مليون توكن إخراج، يعادل ذلك نحو $22 مليون إيرادات يوميًا وقرابة $38 لكل مسرّع في الساعة.

من أين يأتي هامش الربح 80%

الحساب كالتالي: 155 مليون مليون توكن بسعر مختلط يقارب $0,14 تعطي نحو $1 مليون في الساعة. أما التكلفة الكاملة للبطاقة الواحدة، بحسب تقدير كاتب التحليل، فتبلغ $5–8 في الساعة. ومن هنا يتجاوز هامش ربح الاستدلال 80%، وتبلغ مدة استرداد تكلفة العنقود نحو 81 يومًا. وهذا تقدير Latent Space، أما DeepSeek نفسها فتخطط لاسترداد التكلفة خلال 10 أشهر.

وثمة تحفظ مهم: 155 تريليون توكن مُخدَّمة لا تساوي 155 تريليون توكن مولَّدة. فمع 96% إصابات في الكاش، تؤخذ معظم المدخلات من التخزين، ولا يُعاد حساب سوى جزء صغير منها. والأرقام أولية، ولا يوجد تدقيق مستقل، وتتأثر النتيجة بتركيبة الحمل وطريقة احتساب الكاش ومجموعة التكاليف المشمولة.

كيف تُبنى الحزمة

يفصل DeepInfer بين vision encoding وprefill وdecode، وتتوسع كل مرحلة بحسب عنق الزجاجة الخاص بها. يوصى بتشغيل prefill على خوادم عادية بثمانية مسرّعات، وdecode على عقد فائقة من 64–128 مسرّعًا مع wide expert parallelism لنماذج MoE.

• يقدّر مجدوِل prefill تكلفة attention ويقطّع الأجزاء (chunks) بحسب ميزانية زمنية، لا بحجم ثابت.
• توجيه prefill غير مرتبط بالكاش: تُخزَّن البادئات في مخزن مشترك، ويذهب الطلب إلى أي عامل (worker) متاح.
• يراعي توجيه decode عدد الطلبات النشطة وطول KV-cache.
• تُنسخ الخبراء الشائعة وتُعاد جدولتها دوريًا، وثمن ذلك ذاكرة HBM.
• يعمل مجدوِل CPU بشكل غير متزامن ويزيل الفجوات بين خطوات decode.
• وبحسب التحليل، لا يوجد tensor parallelism في التهيئة المعلنة لـ Blackwell.

يعتمد الكاش على عنقود 3FS بسعة نحو 100 PiB من SSD. ومدة الحفظ 3 أيام للوكلاء و7 للدردشات. أما حالة sliding-window attention فتبقى في ذاكرة المضيف. وتستعيد طريقة SWA Bounded Replay الحالة قصيرة العمر المفقودة اعتمادًا على آخر 128 توكنًا، وبحسب DeepSeek تخفّض حسابات prefill تقريبًا إلى النصف. أما التحقق التخميني التكيّفي DSpark فيضيف +6% إلى الإنتاجية في بيئة الإنتاج مقارنة بالتحقق الثابت من خمسة توكنات مسودّة.

ويتولى المكوّن deepseek-recipe طبقة الواجهة: Chat Completions وResponses وMessages API، والتجزئة المتوازية للنص إلى توكنات، والتمييز بين رموز التحكم الحقيقية والسلاسل المطابقة لها في نص المستخدم. وهذه ليست حماية كاملة من prompt injection.

ما المفتوح وما غير المفتوح

يصف الفريق الإصدار بأنه مفتوح بالكامل، لكن الوصف التقني يشير إلى أن إدارة KV-cache وموازن الأحمال لم يُنشرا كاملين بعد. فهما مرتبطان بالبنية التحتية الداخلية. كما أن 3FS، التي نُشرت سابقًا، تشكّل جزءًا منفصلًا من المنظومة. أما تنسيق الخدمة على مستوى المنتج (orchestration) فيبقى مهمة من ينشر الحزمة.

أما تقديرات المجتمع فهي ثانوية: 196B معاملًا لـ Engram، و552B معاملًا للخبراء، وDP64/EP64، وأوزان 4-بت في الغالب، وضغط KV بمقدار 400 مرة مقارنة بـ GQA. والمصدر الأصلي لا يؤكد هذه التفاصيل.

وردّت vLLM بقياسات أداء. فقد بُني DeepInfer منذ البداية على vLLM، وأظهر فريق المشروع decode-throughput ضمن حدود 6% من الرقم الذي نشرته DeepSeek على GB200 بتهيئة مماثلة، ونشر الوصفات ونتائج AgentX. وهذا تكافؤ في مرحلة واحدة، لا إعادة إنتاج للخدمة كاملة: فكاش 100 PiB والتوجيه والتوافرية ليست جزءًا من هذه النتيجة.

وبالتزامن، أعلنت OpenAI عن تخزين مؤقت للمطالبات (prompts) لمدة 12 ساعة في API بدلًا من 30 دقيقة افتراضيًا. المنتجان مختلفان، لكن الهدف واحد: وكلاء يعودون إلى سياق طويل بعد ساعات.

وعلى الفريق الذي يبني خدمة وكلاء أن يأخذ من هذا الإصدار ثلاثة أمور. الأول: احتساب الاقتصاديات بحسب نسبة إصابات الكاش ومدة حفظ البادئات، لا بسعر التوكن. الثاني: فصل prefill وdecode في مجمّعات (pools) مختلفة وموازنة prefill بحسب تقدير الحسابات. الثالث: اختبار vLLM على حملك الخاص، لأن فك التشفير (decoding) فيها قريب أصلًا من نتائج DeepSeek، بينما تكمن الفجوة الرئيسية في طبقة الكاش والتنسيق.