رفعت DeepSeek أسعارها — فوجدت V4 Flash نفسها لدى مزود آخر بأقل من السعر القديم

في صباح 17 أغسطس فتحت إحصاءات استخدام الـ API، وظننت في البداية أنني ارتكبت خطأ ما.

كانت DeepSeek تستهلك المال بوتيرة تقارب خمسة أضعاف ما اعتدت عليه.

كنت أعلم أن تغييرًا في الأسعار قادم. فقد أعلنت DeepSeek عنه قبل أيام، لكنني تعاملت معه ذهنيًا كزيادة عادية: ربما 20% أو 50%، وربما الضعف.

لكن ليس بهذا الحجم.

لم يكن هناك خلل في الفوترة. الأسعار الجديدة دخلت حيز التنفيذ فعلًا. نقلت DeepSeek رسميًا V4 Flash وV4 Pro إلى تسعير يعتمد على ساعات الذروة وخارج الذروة بدءًا من الساعة 16:00 UTC يوم 16 أغسطس، أي 17 أغسطس بالفعل في الصين. وكانت Reuters قد ذكرت قبل التغيير أن الزيادات، بحسب النموذج ونوع التوكن ووقت الاستخدام، ستتراوح بين 50% و1,100%. ويمكن مراجعة التوقيت في سجل تغييرات DeepSeek API.

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

كم كانت تكلفة DeepSeek وكم أصبحت الآن

قبل تغيير التسعير كانت أسعار DeepSeek V4 Flash كالتالي:

هذه الأرقام ما زالت ظاهرة في صفحة تسعير قديمة لـ DeepSeek، كما نقلت Reuters الأسعار نفسها في 3 أغسطس.

أما deepseek-v4-flash الرسمي، الموافق لـ DeepSeek-V4-Flash-0731، فأصبح سعره:

تستمر فترات الذروة من 01:00 إلى 04:00 UTC ومن 06:00 إلى 10:00 UTC وفق صفحة الأسعار الحالية.

لذلك فإن ملاحظتي بأن الفاتورة ارتفعت إلى نحو خمسة أضعاف لا تعني أن كل فئة من التوكنات ارتفع سعرها خمس مرات بالضبط. مقارنة بالسعر القديم:

• ارتفع input في حالة cache miss أثناء الذروة من $0.14 إلى $0.44، أي 3.14×؛
• ارتفع output من $0.28 إلى $1.32، أي 4.71×؛
• ارتفع cache hit من $0.0028 إلى $0.014، أي 5× تمامًا.

وبالنسبة إلى workload ينتج الكثير من المخرجات، فإن زيادة فعلية تقارب خمسة أضعاف في الإنفاق أمر منطقي تمامًا.

بحثت أولًا عن بائع آخر للنموذج نفسه

كان بإمكاني ببساطة التخلي عن DeepSeek. السوق مليء الآن بنماذج مثل Qwen وGLM وKimi وMiniMax وMistral وغيرها.

لكن تغيير النموذج يضيف متغيرًا جديدًا. يجب إعادة اختبار جودة الإجابات، وتوافق prompts، وطول التوليد، والسلوك مع السياقات الطويلة، وإعدادات sampling وغيرها.

لذلك أردت تجربة فكرة أبسط أولًا.

هل يمكنني الإبقاء على DeepSeek V4 Flash، لكن التوقف عن شراء inference من DeepSeek نفسها؟

وهنا توجد نقطة مصطلحية مهمة. لم تنشر DeepSeek مجرد «الشيفرة المصدرية للشبكة العصبية» كما ينشر المطور شيفرة تطبيق. الأدق هو أنها نشرت أوزان النموذج والمواد اللازمة لتشغيلها.

المستودع الرسمي deepseek-ai/DeepSeek-V4-Flash-0731 متاح للعامة على Hugging Face. المستودع والأوزان يستخدمان ترخيص MIT، وتقدم DeepSeek مثالًا لتشغيل النموذج عبر vLLM على عقدة واحدة تحتوي أربعة GB300.

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

طبعًا عبارة «شغّل DeepSeek محليًا» تبسط المهمة أكثر من اللازم. حجم مستودع 0731 يقارب 167 GB، والمثال الرسمي يستخدم أربعة GB300. هذه ليست عملية docker compose up على VPS بقيمة $20. ويمكن رؤية الملفات على صفحة ملفات النموذج.

أما بالنسبة إلى شركة inference تمتلك GPU cluster، فالمعادلة مختلفة. الترخيص لم يعد العائق الرئيسي؛ وتبقى الأجهزة والكهرباء واستغلال GPU وbatching والـ software stack وكفاءة inference.

وجدت Runware

بعد بحث طويل، كان Runware من أكثر الخيارات إثارة للاهتمام.

كيف وجدت Runware؟ استخدمت طريقتي المفضلة في البحث. طلبت أولًا من نموذج ذكاء اصطناعي أن يكتب لي prompt تفصيليًا للعثور على أرخص مزود inference موثوق نسبيًا لهذا النموذج بالذات. بعد ذلك شغّلت نحو 15–20 عملية بحث منفصلة باستخدام الـ prompt نفسه، وجمعت كل النتائج، ثم وضعتها في محادثة نهائية واحدة وطلبت مقارنة المرشحين واختيار أقوى خيار. بعد ذلك فقط راجعت الفائز يدويًا: صفحة النموذج، الأسعار، الوثائق، ثم الـ API نفسه.

ساعدني الذكاء الاصطناعي على توسيع نطاق البحث، لكنه لم يتخذ القرار النهائي نيابة عني. اجتاز Runware مراجعتي اليدوية، وربطته بنفسي، والتوصية هنا مبنية على ذلك الاختبار الفعلي.

فهو يقدم حاليًا checkpoint ‏DeepSeek-V4-Flash-0731 نفسه مع سياق 1M، وليس نموذجًا مجهولًا باسم «DeepSeek-compatible». وتعرض صفحة النموذج الأسعار التالية:

في البداية ظننت أنني أخطأت في موضع الفاصلة العشرية.

لكن المقارنة الأهم ليست مع أسعار DeepSeek الجديدة المرتفعة، بل مع الأسعار القديمة التي كانت تبدو رخيصة أصلًا.

كان input القديم لدى DeepSeek بسعر $0.14، بينما Runware بسعر $0.076. أي أن Runware أرخص بنحو 45.7%، وأن سعر DeepSeek القديم كان أعلى بنحو 1.84×.

وكان output القديم $0.28 مقابل $0.153 لدى Runware. أي أن Runware أرخص بنحو 45.4%، وأن DeepSeek القديم كان أعلى بنحو 1.83×.

بعد زيادة ضخمة في الأسعار، وجدت API خارجيًا يشغّل checkpoint ‏V4 Flash 0731 نفسه، ليس فقط بأقل من سعر DeepSeek الجديد، بل بنحو نصف سعر DeepSeek القديم الرخيص.

وبالمقارنة مع الأسعار الرسمية الحالية تصبح الفجوة أكبر. خارج الذروة، Runware أرخص تقريبًا 2.9× في cache-miss input و4.3× في output. وفي الذروة تصبح الفجوة نحو 5.8× و8.6×.

هناك استثناء مهم: cache hits الرخيصة. DeepSeek تتقاضى حاليًا $0.007/M خارج الذروة للـ cached input، بينما Runware تتقاضى $0.014/M. لذلك لا يمكن تقييم workload يعتمد بكثافة على cache hits من خلال سعر input/output العادي فقط.

السعر المنخفض لا قيمة له إذا كان الـ API لا يعمل

جدول الأسعار وحده لا يكفيني. API يكلف $0.000001 للطلب عديم الفائدة إذا كان نصف الطلبات يفشل.

لذلك ربطت Runware وبدأت بإرسال طلبات فعلية.

احتفظت بلقطتين من usage dashboard. الأولى أظهرت:

790 requests
56 success
734 errors

هذا يبدو سيئًا جدًا بمفرده. لكن لاحقًا أصبحت الأرقام:

1,570 requests
836 success
734 errors

أي أن الفرق بين القياسين كان بالضبط:

+780 requests
+780 successful
+0 new errors

لا أتعامل مع ذلك كدليل على uptime بنسبة 99.999%. هذه اللقطات لا تثبت شيئًا من هذا القبيل، كما أنها لا تكشف سبب الأخطاء الـ734 الأولى.

ما أستطيع قوله أضيق بكثير: خلال الـ780 طلبًا التالية، ارتفع عداد النجاح بمقدار 780 ولم يتحرك عداد الأخطاء.

وكان الـ API سريعًا أيضًا خلال هذا الاختبار. في الجزء الظاهر من السجل، اكتملت معظم الطلبات الناجحة في أجزاء من الثانية وحتى نحو 1.5 ثانية. وكانت تكلفة الطلبات القصيرة الظاهرة غالبًا في حدود $0.000005–$0.000018. وبعد مئات الطلبات الناجحة ظل إجمالي الإنفاق المعروض قريبًا من سنت واحد فقط.

عند هذه النقطة لم يعد Runware بالنسبة إليّ مجرد سطر في جدول مقارنة. لقد ربطت الـ API فعلًا، وأنتج ردودًا، وكانت تكلفة حركة الاختبار ضئيلة جدًا.

هذه ليست دعاية — وأنا أختبر Runware منذ يوم واحد فقط

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

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

غادرت DeepSeek API الرسمي المكلف فورًا لأنني لم أرد الاستمرار في حرق المال بالتعرفة الجديدة وأنا أقيّم البدائل. نقلت الـ traffic وبدأت اختبار Runware مباشرة.

حتى الآن أنا راضٍ جدًا عن هذا القرار. عند إنهاء المقال كان Runware قد عالج لي بالفعل 1,000 طلب AI ناجح. هذا لا يثبت uptime في المستقبل ولا الأداء عند كل حجم، لكنه يكفي لأقول إن هذا ليس مزودًا رأيته فقط في جدول أسعار: أنا أستخدمه فعلًا.

لذلك توصيتي محدودة ومقصودة: راجعت Runware بنفسي، وهو يعمل جيدًا لدي اليوم، وحاليًا أنصح بتجربته. إذا تغيرت الخدمة، فقد يتغير رأيي أيضًا.

ربما صنعت DeepSeek منافسًا سعريًا لنفسها

من هنا تبدأ تفسيرات شخصية، لا حقائق رصدتها مباشرة.

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

حين كان API الرسمي رخيصًا للغاية، لم يكن هذا التوتر واضحًا. لماذا أبحث عن GPU cluster لدى طرف آخر بينما تبيع DeepSeek نفسها inference بسعر $0.14/$0.28؟

بعد رفع الأسعار تتغير المعادلة. إذا وصل السعر الرسمي في الذروة إلى $0.44 input و$1.32 output، بينما يقدم مزود مستقل checkpoint نفسه بسعر $0.076/$0.153، يصبح الدافع الاقتصادي لتجربة البديل قويًا جدًا.

وهذا ليس loophole غير متوقع. ترخيص MIT للأوزان المنشورة يسمح باستخدام واسع، بما في ذلك الاستخدام التجاري، والمستودع الرسمي يتضمن إرشادات للتشغيل الذاتي.

لهذا لا أصف Runware ببساطة بأنه «يعيد بيع توكنات DeepSeek». الصورة الأدق هي:

DeepSeek
    │
    ├── DeepSeek API الرسمي
    │
    └── أوزان DeepSeek V4 Flash المفتوحة
                   │
                   ├── بنية Runware التحتية
                   ├── مزودو inference آخرون
                   └── GPU cluster خاص بك

النموذج نفسه لم يعد مرتبطًا ببائع inference واحد.

هل كان فتح الأوزان خطأً تجاريًا؟

لا أستطيع عرض ذلك كحقيقة.

سيكون من السهل أكثر من اللازم القول إن DeepSeek فتحت النموذج، وبالتالي سيبيعه المنافسون بسعر أقل وستفقد الشركة المال. نحن لا نعرف اقتصادياتها الداخلية.

استراتيجية open-weight قد تمنح فوائد أخرى:

• انتشارًا أوسع للنموذج؛
• تكاملات أكثر؛
• نفوذًا أكبر داخل المنظومة؛
• فرصة ليصبح النموذج معيارًا فعليًا في منتجات أطراف أخرى؛
• عددًا أكبر من المطورين؛
• تبنيًا مؤسسيًا؛
• شعبية بحثية؛
• ضغطًا على المنافسين.

كما أشارت Reuters إلى اعتماد مطوري النماذج الصينيين على نهج open-weight لتحقيق انتشار واسع بين المطورين في تغطيتها لسوق الذكاء الاصطناعي الصيني.

لذلك من المبكر أن أصف القرار بأنه خطأ تجاري. لكنني أستطيع صياغة استنتاج أضيق:

بفتح الأوزان، تخلت DeepSeek طوعًا عن احتكار inference لنموذجها نفسه.

وعندما يصبح API الرسمي أغلى بكثير، تظهر نتائج ذلك القرار بوضوح أكبر. لم تعد DeepSeek تنافس Qwen وOpenAI وAnthropic وMoonshot فقط، بل تنافس أيضًا، بصورة ما، شركات تبيع inference لنموذج DeepSeek المفتوح نفسه.

هذا ممتاز لمشتري الـ API، لكنه يجعل استراتيجية تحقيق الدخل أكثر تعقيدًا.

لماذا لا أشغّل DeepSeek بنفسي

السؤال التالي واضح: إذا كانت الشركات الخارجية تستطيع تشغيل DeepSeek وبيع inference، فلماذا لا أفعل الشيء نفسه؟

لأن هناك فجوة ضخمة بين «النموذج مجاني للتنزيل» و«inference مجاني».

يمكن تنزيل الأوزان. لا يمكن تنزيل GPUs.

تحتاج إلى شراء أو استئجار أجهزة باهظة، وتوفير VRAM كافية، وتحميل checkpoint ضخم، وإعداد inference engine وbatching وKV cache وmonitoring وscaling وredundancy، ثم توليد حمل كافٍ لإبقاء GPUs مشغولة.

المثال الرسمي لـ DeepSeek V4 Flash 0731 يستخدم عقدة واحدة مع أربعة GB300.

بالنسبة إلى مزود inference متخصص قد يكون هذا الاستثمار منطقيًا لأنه يوزع تكلفة البنية التحتية على عدد كبير من العملاء. أما لمطور واحد، فقد يكون دفع $0.076 لكل مليون input tokens أكثر عقلانية بكثير من استثمار مبلغ كبير في GPUs ثم محاولة الحفاظ على استغلال مرتفع لها.

في الوقت الحالي أفضل شراء inference، لكنني أصبحت أفهم بصورة أفضل ما الذي أشتريه فعليًا.

أهم ما تعلمته من ذلك الصباح

في بداية اليوم كنت أنظر إلى DeepSeek كأي SaaS API: هناك نموذج DeepSeek، إذن DeepSeek تحدد تكلفة استخدامه.

بحلول المساء تغيرت الصورة في ذهني: هناك checkpoint لـ DeepSeek، وهناك سوق تنافسي من الشركات المستعدة لتشغيل ذلك checkpoint من أجلي.

هذان سوقان مختلفان جذريًا.

عندما يكون النموذج مغلقًا، يتحكم مالكه إلى حد كبير في سعر الـ API. أما عندما تكون الأوزان مفتوحة بترخيص permissive، فإن سعر inference يتأثر أيضًا بالمنافسة بين مزودي البنية التحتية.

بالنسبة إليّ، أصبحت هذه الفكرة ملموسة جدًا في 17 أغسطس. كان DeepSeek V4 Flash القديم بسعر $0.14 input و$0.28 output. السعر الرسمي الجديد يصل إلى $0.44/$1.32 في الذروة. بينما يقدم Runware حاليًا DeepSeek-V4-Flash-0731 بسعر $0.076/$0.153.

لقد اختبرت هذا الـ API بنفسي، وعمل مع حركة الطلبات التي أرسلتها.

هل ستظل هذه الأسعار كما هي بعد شهر؟ لا أعرف. وهل سيتحمل المزود نفسه كل حجم ممكن وكل نمط حركة؟ لم أثبت ذلك أيضًا.

لكن شيئًا واحدًا تغير بالنسبة إليّ: بعد هذا الارتفاع في الأسعار، لم أعد أفترض أن الـ API الرسمي لصاحب نموذج open-weight هو تلقائيًا أفضل مكان لشراء inference.

خطوتي الأولى الآن هي أن أرى من يستطيع أيضًا تشغيل الأوزان نفسها، وكم يطلب مقابل ذلك.