ما هو DeepInfer؟ محرك الاستدلال الخاص بـ DeepSeek، والأجزاء التي لم يطلقها

DeepInfer هو إطار الاستدلال الذي نشرته DeepSeek في 16 أكتوبر 2026 بموجب Apache-2.0، ويخدم نموذجًا واحدًا فقط: DeepSeek-V4.1-Flash، مع DeepSeek-V4.1-Flash-1017 كنقطة التحقق الافتراضية. هذا النطاق الأحادي النموذج هو أول ما ينبغي فهمه، لأنه يفسّر تقريبًا كل شيء آخر في المستودع. فليس هذا إطار تقديم عامًا يصادف أنه يتضمن إعدادًا لـ DeepSeek. بل هو مسار الشفرة الذي تشغّله DeepSeek في الإنتاج، مقتطعًا إلى الأجزاء القابلة للتعميم، وهو صريح بشأن هذا الاقتطاع: فقائمة README نفسها لما يحتاجه خدمة استدلال كاملة، وما لا يتضمنه هذا الإصدار، تسمّي نظام ذاكرة تخزين مؤقت KV، وتفكيك VE/Prefill/Decode، وموازنة الحمل عبر نسخ متوازية للبيانات. ما تحصل عليه هو مسار الحوسبة — النوى، والتوازي، وفك التشفير التخميني، والجدولة، والإخراج المنظم. وما لا تحصل عليه هو طبقة التخزين والتوجيه التي تجعل مسار الحوسبة رخيص التشغيل على نطاق واسع. وتوضح DeepSeek السبب: فهذه المكوّنات مقترنة بشدة بالبنية التحتية الداخلية، لذا يُوصف التصميم في ورقة منشورة بينما تبقى الشفرة داخل الشركة.

ما هو موجود فعليًا في المستودع

تبدو قائمة الميزات المنشورة جولةً في عنق الزجاجة عند تقديم نموذج كبير من نوع mixture-of-experts. فهناك مكتبات النواة التي أطلقتها DeepSeek سابقًا — FlashMLA للانتباه، وDeepGEMM لعمليات ضرب المصفوفات، وDeepEP للتواصل الموازي للخبراء، إضافة إلى TileKernels وDeepSelect. وهناك مخطط التوازي: يعمل الانتباه كتوازٍ للبيانات مع توازٍ متوازن للسياق، ويعمل نصف MoE كتوازٍ للخبراء مع موازن أحمال موازٍ للخبراء. وهناك DSpark، حزمة فك الترميز التخميني، بأطوال تحقق تُجدول بدلًا من أن تكون ثابتة. وهناك إعادة التشغيل المحدودة SWA، وهي الآلية التي تمنع ذاكرة التخزين المؤقت لانتباه النافذة المنزلقة من إجبار إعادة حساب كاملة عند كل فقدان في الذاكرة المؤقتة. وهناك جدولة دُفعات غير متزامنة، واستدلال لا يتغير بتغير الدفعة مع أخذ عينات حتمي، وإخراج مُهيكل مقيّد بتعبير نمطي أو مخطط JSON أو EBNF.

نقطة الدخول صغيرة عمدًا. بعد ضبط DEEPINFER_ACCELERATOR على nvidia أو ما يعادلها من Ascend وتشغيل build.sh، يتضمن المستودع examples/offline_inference.py، الذي يشغّل نقطة التحقق الافتراضية من البداية إلى النهاية. DEEPINFER_HF_MODEL_DIR يوجّهه إلى دليل أوزان مختلف. أُجريت الاختبارات المعيارية المنشورة على أربع وحدات GPU من طراز SM100 لمرحلة التعبئة المسبقة (prefill) و64 وحدة GPU من طراز SM100 لمرحلة فك التشفير (decode)، وهو حجم النشر الذي كُتب المحرك من أجله وليس عرضًا تجريبيًا بحجم حاسوب محمول.

يذكر README أيضًا من أين جاءت الشيفرة، وهو أمر يستحق معرفته قبل قراءتها. بُنِي المحرّك في الأصل بشكل أساسي على vLLM، مع استلهام تصميمي من SGLang وTensorRT-LLM. ويظهر هذا النسب في البنية — فالمجدول وواجهة الانتباه المقسم إلى صفحات ومسار أخذ العينات ستبدو مألوفة لأي شخص قرأ تلك المشاريع — كما يفسّر لماذا يُعدّ الإصدار نسخةً متفرعةً عن حزمة تقديم بدلًا من بنية كُتبت من الصفر. أما ما أضافته DeepSeek فهو الجزء الخاص بنموذجها: النشر المفكك، والتوازي الواسع للخبراء مع موازنه، وإعادة تشغيل النافذة المنزلقة، وDSpark.

ما لا يحتويه، ولماذا يهم ذلك أكثر

الأجزاء الثلاثة الناقصة ليست تجاوزات صغيرة. كل واحد منها نظامٌ لا بد أن يكون موجودًا قبل أن يبدأ المحرك في خدمة حركة مرور الإنتاج، وكل منها مكلف بطريقة مختلفة.

• نظام ذاكرة التخزين المؤقت KV. إعادة استخدام البادئات هي حيث يكمن معظم التوفير في عبء عمل الدردشة، لأن إصابة ذاكرة التخزين المؤقت تحل محل عملية prefill. وبدون مخزن مؤقت، تعيد كل طلب حساب الموجّه الخاص به. يصف مقال DeepSeek نفسه المخزن الذي يستخدمه: عنقود 3FS مخصص بدلاً من ذاكرة المضيف المحلية، وذلك تحديدًا كي تتمكن أي آلة prefill من إصابة أي بادئة، ويمكن توسيع سعة التخزين المؤقت بشكل مستقل عن الحوسبة.

• فصل VE/Prefill/Decode. تشير ملاحظات README إلى أن معظم الوظائف الخاصة بجانب المحرك موجودة بالفعل في الإصدار؛ وما ينقص هو النشر. ويتيح فصل مُرمِّز الرؤية ومرحلة prefill ومرحلة decode ضبط حجم كل مرحلة وفق عنق الزجاجة الخاص بها، والتحكم في زمن الوصول إلى أول رمز بشكل منفصل عن الزمن بين الرموز. وهذا قرار بنية تحتية، وليس مجرد علامة.

• موازنة الحمل عبر النسخ المتماثلة ذات التوازي البياني. يشغّل DeepSeek أربعة موازنات — التعبئة المسبقة، وفك الترميز، ومُرمِّز الرؤية، والتوازي بين الخبراء — ويصف الأربعة جميعًا في التقرير. لا يُشحن أي من منطق التوجيه. وبدونه، لا تكون مجموعة النسخ المتماثلة أفضل من أي موجّه تضعه أمامها، وسيدمّر موجّه التوزيع الدوري الساذج معدل إصابة الذاكرة المؤقتة الذي بُني المخزن لحمايته.

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

البوابة العتادية هي المرشّح الحقيقي

يستهدف DeepInfer معالجات NVIDIA SM100 وHuawei Ascend 950. لا يوجد مسار Ampere ولا مسار Hopper، مما يستبعد معظم وحدات GPU في معظم العناقيد اليوم. وبقية سلسلة الأدوات محددة بالقدر نفسه: Linux فقط، وGCC 13 أو أحدث، وPython 3.12، وCUDA 13 لـ NVIDIA أو CANN 9.2 لـ Ascend. ولا توجد إصدارات على الإطلاق — كان لدى المستودع صفر إصدارات منشورة عند قراءته في 21 أكتوبر 2026، لذا لا يوجد شيء للتنزيل ولا شيء لتثبيت إصدار محدد. تقوم باستنساخه وبنائه مقابل سلسلة الأدوات الخاصة بك.

هذا المزيج غير معتاد في إصدار مفتوح المصدر يحظى بهذا القدر من الاهتمام، والأفضل أن يُقرأ بوصفه بيانًا دقيقًا للنطاق لا سهوًا. الأنوية الحسابية في المستودع مكتوبة لمجموعة تعليمات محددة وبنية ترابط محددة؛ والأرقام في README تأتي من تلك العتاد. ونقل مسار الحوسبة إلى جيل أقدم هو بالضبط نوع العمل الذي تنجزه المجتمعات بسرعة ولا يمكن لمنظمة هندسية أن تَعِد به. وخلال أيام من الإصدار ظهر على GitHub نقل طرف ثالث يستهدف أجزاء NVIDIA الأقدم، وهو إشارة مفيدة إلى الطلب ولا إشارة على الإطلاق إلى ما إذا كانت أرقام الإنتاجية المنشورة تصمد بعد النقل.

شكل النشر الذي تشغّله DeepSeek فعليًا

المستند المعماري هو المكان الذي تصبح فيه افتراضات المستودع واضحة. يُفكَّك النظام إلى مُرمِّز رؤية، ومرحلتي التعبئة المسبقة (prefill) وفك التشفير (decode)، إضافةً إلى عُقد تخزين مخصصة. تستخدم مرحلة التعبئة المسبقة توازي الخبراء (expert parallelism) من 2 إلى 8 مع توازي بيانات مطابق، مع اختيار أصغر تكوين يسمح به HBM. أما مرحلة فك التشفير فتسير في الاتجاه المعاكس: توازي الخبراء وتوازي البيانات من 64 إلى 128، وهو ما تسميه DeepSeek Wide-EP، باستخدام أكبر تكوين تسمح به وحدات GPU المتاحة. ولا يُستخدَم توازي الموترات (tensor parallelism) ولا توازي السياق (context parallelism) على الإطلاق. يعمل مُرمِّز الرؤية على وحدة GPU واحدة لكل نسخة، مع التوصية بوحدات GPU أقل تكلفة، لأن المُرمِّز ليس موضع إنفاق المال.

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

تقسيم الـ prefill والـ decode عبر مراكز البيانات ممكن تقنيًا لأن DeepSeek-V4.1-Flash يضغط ذاكرة KV cache الخاصة به بقدر كبير، كما أن نشر DeepSeek نفسه يضع عقد الاستدلال في مراكز بيانات مختلفة لكن متجاورة. الميزانية نحو 400 Gbps من الربط البيني لكل ثماني وحدات GPUs، والمقال صريح بشأن تكلفة الموثوقية — فمن السهل قطع الألياف الضوئية بين المباني.

لماذا فك الترميز منتشر إلى هذا الحد؟

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

إعدادات DeepSeek محددة بما يكفي لنسخها. في التعبئة المسبقة، تحتفظ كل GPU بأربعة خبراء احتياطيين إضافيين إلى جانب الخبراء التي تملكها، وتُجمع الإحصاءات على مدى نافذة من 100 خطوة، ويُعاد تعيين الخبراء كل 1,000 خطوة، مع خلط الأوزان داخل المجموعة عبر الذاكرة المشتركة NVLink. بلغ الاختلال المقاس — أبطأ رتبة مقسومة على المتوسط — 1.074 في تكوين EP4/DP4 و1.045 في EP2/DP2. أما في فك الترميز فتمتد الإعدادات: خبير احتياطي واحد لكل GPU، ونافذة إحصاءات من 1,000 خطوة، وإعادة تعيين كل 10,000 خطوة، واختلال مقاس قدره 1.090. الفرق بين الحالتين هو المقصود. ترى التعبئة المسبقة عملاً متقطعًا وغير متجانس وتحتاج إلى إعادة موازنة سريعة؛ أما فك الترميز فيرى تدفقًا ثابتًا ويمكنه تحمل نافذة طويلة، لذا يعيد الموازنة نادرًا ولا يدفع تقريبًا شيئًا مقابل هذا الامتياز.

جانب التوجيه له الطابع نفسه. تُصنَّف طلبات prefill حسب إجمالي طول السياق إلى أربع فئات — أقل من 16K، ومن 16K إلى 64K، ومن 64K إلى 256K، و256K فما فوق — وتُسنَد المحركات إلى الفئات وفقًا لحصة كل فئة من الطلب على الحوسبة في الجولة السابقة. وداخل وحدة GPU، ليس حجم القطعة لكل خطوة prefill ثابتًا: إذ يتوقع نموذج تكلفة تربيعي مُلائم المدة التي ستستغرقها الخطوة بالنظر إلى عدد رموز التسلسل والبادئة المحسوبة بالفعل، ويحسب المجدول أكبر قطعة تتسع ضمن ميزانية 32,768 رمزًا داخل الوقت المتبقي. ويوازن موازِن فك التشفير بين بُعدين في آن واحد: عدد الطلبات وإجمالي طول ذاكرة KV cache، إذ يوجّه الطلبات القصيرة إلى وحدات GPU ذات تزامن منخفض وذاكرة تخزين مؤقت طويلة، والطلبات الطويلة إلى وحدات GPU ذات ذاكرة تخزين مؤقت صغيرة. ويلخّص DeepSeek مقدار ما يحققه كل ذلك: نحو 80 بالمئة من معيار أداء غير متصل متوازن تمامًا.

الذاكرة المؤقتة، ومسألة الثلاثة أيام

تعيش ذاكرة KV المؤقتة على عنقود 3FS مخصص، لا في ذاكرة المضيف المحلية، وهذا القرار يقود بقية تصميم التخزين. تُخزَّن البيانات بترميز محو 10+2، لذا تصمد كل مجموعة ترميز أمام فشل عقدتين في آن واحد؛ ويُصدر طلب القراءة طلبات إلى جميع العقد الـ11 في المجموعة، وأي 10 استجابات تكفي لفك الترميز. يعمل عامل جمع القمامة على كل عقدة تخزين ويطرد وفق LRU بعد تجاوز عتبة محددة. يحتوي الخادم الموصى به على 20 قرصًا صلب الحالة سعة كل منها 30.73 TB، ويحافظ على 40 GB/s على الأقل من القراءة و5 GB/s من الكتابة، وبسعة تكفي للاحتفاظ بنحو 24 ساعة من البيانات لكل خادم. عمليًا، يعمل العنقود بنحو 14.4 TB من الذاكرة المؤقتة المنطقية لكل GPU متصل، مع سعة فعلية أكبر من ذلك.

تتجلى المقايضة عند تحديد مدة إقامة البيانات في الذاكرة المؤقتة. لا توجد منطقية لانتهاء الصلاحية على جانب الذاكرة المؤقتة؛ إذ يُضبط TTL على جانب التخزين عند ثلاثة أيام لحركة الوكلاء وسبعة أيام لحركة روبوتات الدردشة، ضمن عنقود يضم نحو 100 بيتابايت من تخزين الحالة الصلبة. وُجد هذا التقسيم لأن حركة روبوتات الدردشة لها ذيل طويل من الإصابات أثقل بكثير — إذ تُقرأ كمية صغيرة من الذاكرة المؤقتة مرات عديدة، لذا فإن فقدانها يخفض معدل الإصابات الإجمالي أكثر مما يوحي به الحجم. تقدر تكلفة DeepSeek المقاسة لتقليص مدة احتفاظ روبوتات الدردشة إلى ثلاثة أيام بنسبة 0.5 إلى 1 بالمئة من معدل إصابات الذاكرة المؤقتة. وهو رقم صغير يمثل في الواقع كمية كبيرة من التعبئة المسبقة المُعاد حسابها.

تحصل آلية الانتباه ذات النافذة المنزلقة على ذاكرة مؤقتة منفصلة بقواعد مختلفة. لا تدخل ذاكرة SWA المؤقتة ضمن الكتل المقسمة إلى صفحات؛ إذ يشغل كل تسلسل فتحة واحدة ثابتة الحجم في ذاكرة المضيف، وبالنسبة إلى DeepSeek-V4.1-Flash فإن الطبقات المخزَّنة هي الطبقات العشرون الأولى. ولا تبقى إلا تلك المنطقة — 20 طبقة × 134 رمزًا × 528 بايت، أي 1,415,040 بايت لكل تسلسل بصيغة MXFP8. لا يذهب أي شيء إلى عنقود التخزين؛ بل يبقى في ذاكرة الآلة التي أنتجته، مع دليل في الذاكرة يسجّل أي آلة تحتفظ بأي محتوى، وعند حدوث إصابة عبر آلة أخرى يُسحب مرة أخرى عبر VLAN بسعة 400 Gbps.

الآليتان اللتان تنتجان الأرقام الرئيسية

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

جانب فك الترميز هو حيث يكون التوفير كبيرًا. في هذه البنية، تُشتق ذاكرة التخزين المؤقت للكتل في طبقات فك الترميز بالإسقاط من الحالة المخفية لآخر طبقة ترميز، لذا لا يلزم حساب سوى ذاكرة التخزين المؤقت SWA الخاصة بفك الترميز لكل طبقة — وإعادة بنائها بدقة ستعني تمرير آخر 2,560 رمزًا عبر 20 طبقة فك ترميز في كل عملية تعبئة مسبقة. أما إعادة تشغيل 128 رمزًا بدلًا من ذلك، واستخدام النتيجة لفك الترميز فقط بدلًا من إدخالها إلى ذاكرة التخزين المؤقت للبادئة، فيقلل إجمالي حسابات التعبئة المسبقة بنحو النصف. هذا التغيير الواحد يستحق أكثر من معظم تحسينات النواة، وهو من الأمور التي لا يقدر عليها إلا فريق يملك بنية النموذج.

مساهمة DSpark أصغر وأكثر تقليدية. لرموز المسودة احتمالات قبول مختلفة تبعًا للطلب والموضع، لذا فإن التحقق من خمس مسودات ثابتة في كل خطوة يهدر الحوسبة على رموز سيُرفض معظمها. يتنبأ رأس ثقة بمعدل قبول كل رمز مسودة، ويرتب المجدول المسودات حسب العائد المتوقع، ثم يتحقق فقط من البادئة التي تزيد الإنتاجية إلى الحد الأقصى. في بيئة الإنتاج، لا يزال نموذج المسودة يولّد خمسة رموز في كل خطوة؛ أما عدد الرموز التي يُتحقق منها فينخفض من 5.00 إلى ما بين 3.2 و4.4، أي خفض بنحو 30 بالمئة، بينما يكاد الطول المقبول لا يتغير — 3.29 مقابل 3.20. واستنادًا إلى بيانات قياس EP64/DP64، يعادل ذلك إنتاجية أعلى بنسبة 4 إلى 7 بالمئة عند نحو 60 تسلسلًا متزامنًا لكل رتبة. وعند 60 بالتحديد، ترتفع الإنتاجية لكل رتبة من 13,730 إلى 14,466 رمزًا في الثانية. أما دون نحو 16 تسلسلًا متزامنًا، فتكون هذه التقنية خسارة صافية صغيرة، وهو أمر يجدر معرفته قبل اعتمادها في نشر منخفض الحركة.

ماذا يعني رقم 155 تريليون

الرقم الأكثر اقتباسًا المرتبط بهذا الإصدار هو مجموعة حوسبة واحدة تخدم 155 تريليون رمز يوميًا بإيراد إجمالي قدره 38 دولارًا أمريكيًا لكل ساعة GPU بأسعار فترات الانخفاض. وكلا الشقين مُبلَّغ عنه من المورّد، وليس أيٌّ منهما معيار أداء يمكنك إعادة إنتاجه، وهذا لا يجعلهما غير مثيرين للاهتمام — فرقم الإيراد لكل ساعة GPU هو نوع مختلف تمامًا من الادعاءات عن رقم الإنتاجية، لأنه يدمج الاستفادة والتسعير ومعدل إصابة الذاكرة المخبئية في سطر واحد. وهو أيضًا الرقم الأرجح أن يُقتبس من دون قيوده، لذا تستحق القيود أن تُكتب صراحةً: مجموعة حوسبة واحدة، وأسعار فترات الانخفاض، وإيراد لا تكلفة، وإجمالي يشمل التعبئة المسبقة وفك التشفير ومشفّر الرؤية.

هناك إفصاحان أصغر أكثر فائدة بصورة مباشرة. تفتقر نواة فك التشفير FlashMLA في المستودع العام إلى تحسين تجميعي واحد مُعاير يدويًا تمتلكه النسخة الداخلية، مما يجعلها أبطأ بنسبة 5 إلى 10 بالمئة عند قياسها منفردة؛ وتذكر DeepSeek أن الأداء من طرف إلى طرف لا يختلف بأكثر من 5 بالمئة. كما أن نموذج المسودة الداخلي لفك التشفير التخميني أحدث من النسخة المنشورة، وقد وُصِف فرق الأداء بأنه صغير. يضع هذان البيانان توقعًا بشأن مقدار الأداء المنشور الذي يمكن لطرف ثالث بلوغه عبر نسخ الشيفرة، والجواب هو: معظمه، بشرط أن تتطابق العتاد.

المستودع كما هو عليه الآن

التُقطت اللقطة أعلاه في 21 أكتوبر 2026 وتُظهر الصفحة وهي تعرض 16.3k نجمة. وعند استعلام GitHub API في اليوم نفسه، أعاد 16,590 نجمة و1,649 تفرعة و176 مشكلة مفتوحة، مع تعطيل المشكلات وتوجيه النقاش إلى GitHub Discussions بدلًا من ذلك. وقد واصل عدد النجوم الارتفاع منذ ذلك الحين، لذا اقرأ كل رقم هنا بوصفه طابعًا زمنيًا لا خاصيةً من خصائص الشيفرة. إن حركة مرور بهذا الحجم في أقل من أسبوع تقول عن الاهتمام بمكدس تقديم DeepSeek أكثر مما تقوله عن جاهزية الشيفرة، ويكمل عدد الإصدارات الصفري الصورة.

إذا كنت تفكر في تشغيله بنفسك

الخلاصة الصادقة هي أن DeepInfer يستحق القراءة المتأنية ويصعب تشغيله. ستخبرك أربعة أسئلة ما إذا كان مناسبًا.

• هل لديك SM100 أو Ascend 950؟ كل شيء آخر في سلسلة الأدوات يتبع هذا الأمر. فبدون المسرّع الصحيح لا تنتقل الأرقام المنشورة، والمنافذ المجتمعية غير مُتحقَّق منها على نطاق الإنتاج.

• هل يمكنك تشغيل 64 وحدة GPU لفك التشفير ضمن نطاق اتصال واحد؟التوازي الواسع للخبراء ليس تحسينًا يمكنك تجاهله؛ بل هو التكوين الذي صُمم مسار فك التشفير حوله. وتحت هذا النطاق، فأنت تشغّل نظامًا مختلفًا يحمل الاسم نفسه.

• هل تمتلك بالفعل ذاكرة تخزين مؤقت للبادئات؟ إذا لم يكن الأمر كذلك، فأنت تقارن مسار الحوسبة في DeepInfer بحزمة منافسة تأتي مزودة بواحدة، وستبدو المقارنة أسوأ مما يستحقه التصميم.

• هل تستطيع تحمّل كتابة طبقة التوجيه؟ إن تجميع مرحلة Prefill في دلاء، وموازنة مرحلة decode، وإعادة إسناد الخبراء موصوفة على نحو يكفي لإعادة تنفيذها، وإعادة تنفيذها تستغرق أسابيع من العمل لا ينجزها المستودع نيابة عنك.

إذا كنت تفضّل عدم امتلاك أيٍّ مما سبق

بالنسبة لمعظم الفرق، السؤال العملي ليس كيفية نشر DeepSeek-V4.1-Flash، بل أين يمكن استدعاؤه. فالنموذج متاح عبر API متوافقة دون بناء عنقود من 128 وحدة معالجة رسومات أو إعادة تنفيذ موازن أحمال، وهو النموذج نفسه الذي كانت هذه المقالة تصف هندسته — المعالجة نفسها للسياق، والسلوك نفسه في المخرجات المنظمة، ودون أعمال الفصل.

المقارنة التي ينبغي إجراؤها ليست أي محرك أسرع نظريًا، لأن الأرقام المنشورة هي قياسات يُبلّغ عنها المورّد على عتاد لا يملكه معظم القراء. بل هي ما إذا كان عبء العمل حالةً تغيّر فيها مدة TTL لذاكرة التخزين المؤقت البالغة ثلاثة أيام ومجمع فك ترميز بـ64 GPU السعرَ، أم حالةً يكون فيها طلب كل بضع ثوانٍ عبر API أرخص ببساطة من أي من العمليات الموصوفة أعلاه. وفي الحالة الثانية — وهي معظم الحالات — فإن المقدار المناسب من DeepInfer الذي ينبغي استخدامه هو صفر، والمقدار المناسب الذي ينبغي قراءته هو كله. ابدأ من صفحة نموذج DeepSeek V4.1 Flash إذا أردت نقطة النهاية؛ وابدأ من README الخاص بالمستودع إذا أردت معرفة ما تفعله نقطة النهاية.