لا تُحسب فاتورة DeepSeek API بضرب عدد الاستدعاءات في سعر الوحدة فحسب، بل تحددها رموز الإدخال ورموز الإخراج وحالة إصابة التخزين المؤقت معًا. كثير من الفرق يضع الميزانية وفق السعر المعلن، ثم يكتشف بعد الإطلاق أن التكلفة الفعلية أعلى بمقدار ملحوظ؛ والسبب عادةً ليس تغيّر سعر الوحدة، بل اختلاف بنية الإدخال ونسبة إصابة التخزين المؤقت وعدد المحاولات عن تقديراتها.
تقسم هذه المقالة فوترة DeepSeek API إلى أجزاء قابلة للحساب: أي الرموز تُحتسب، ولماذا يعمل التخزين المؤقت أحيانًا ولا يعمل أحيانًا أخرى، وكيف يُستخدم حقل usage في الاستجابة للتقدير، وبأي ترتيب يُنفذ خفض التكلفة. تُراجع الأسعار الفعلية في صفحة الأسعار وفي وثائق DeepSeek الرسمية.
ملاحظة: DeepSeek علامة تجارية مملوكة لمالكها. تعتمد هذه المقالة على أشكال الواجهات الشائعة في أكتوبر 2026، وقد تتغير الأسعار وأسماء الطرازات وقواعد الفوترة، لذا يُرجى التحقق من الصفحة الرسمية مرة أخرى قبل الشراء.
أولًا: تفكيك الفاتورة إلى أربعة بنود
| البند | متى ينشأ | العوامل المؤثرة | اتجاه التحسين |
|---|---|---|---|
| الإدخال (بدون إصابة الذاكرة) | دخول محتوى جديد إلى السياق للمرة الأولى | طول المستند، والرسائل السابقة، وتعريفات الأدوات | الاسترجاع، والتلخيص، والاقتطاع |
| الإدخال (مع إصابة الذاكرة) | إعادة استخدام بادئة مخزنة سابقًا | ثبات البادئة، ونسبة الإصابة | تثبيت البادئة، وتقليل المحتوى العشوائي |
| الإخراج | توليد النص والنتائج المهيكلة | طول الإخراج، وقيود التنسيق | max_tokens، وقيود JSON |
| محتوى الاستدلال | إنتاج عملية تفكير في طرازات الاستدلال | صعوبة المهمة، ومستوى الاستدلال | عدم استخدام طراز استدلال للمهام البسيطة |
يظهر التخزين المؤقت للسياق في DeepSeek عادةً على جانب الإدخال: تُحتسب البادئة المطابقة بسعر إدخال أقل، بينما تُحتسب الأجزاء غير المطابقة بسعر الإدخال القياسي. أما فرض رسوم تخزين للذاكرة ومدة الاحتفاظ بها، فتراجع وفق ما تنص عليه الوثائق الرسمية الحالية، دون الاعتماد على قواعد مقالات قديمة.
يمكن كتابة تكلفة الطلب الواحد على شكل معادلة:
تكلفة الطلب الواحد =
رموز الإدخال المطابقة للذاكرة × سعر الإصابة
+ رموز الإدخال غير المطابقة × سعر الإدخال
+ رموز الإخراج × سعر الإخراج
لا يمكن الإجابة عن سؤال «كم تبلغ تكلفة هذه الميزة شهريًا» إلا بإسقاط هذه المعادلة على السجلات. فالاطلاع على إجمالي الفاتورة في لوحة التحكم وحده لا يكشف أي مشروع أو أي نوع من الطلبات يضخم التكلفة.
ثانيًا: لماذا يوفر التخزين المؤقت التكلفة ولماذا لا يعمل كثيرًا
منطق التخزين المؤقت للسياق الأساسي هو: إذا تطابق الجزء الأول من طلبين تمامًا، فيمكن للخادم إعادة استخدام نتيجة الحساب السابقة وإعادة حساب الجزء الجديد فقط. لذلك يكون التخزين المؤقت أكثر فعالية مع المحتوى التالي:
- موجه النظام (system prompt) الثابت وتعريف الدور.
- تعريفات الأدوات ومخططات الدوال المستقرة.
- مقاطع قواعد المعرفة وأدلة المنتجات وقوالب العقود المتكررة.
- الجزء الأول غير المتغير في المحادثات متعددة الأدوار.
في المقابل، تؤدي الأساليب التالية إلى إبطال التخزين المؤقت بشكل متكرر:
- إدراج الوقت الحالي أو معرّف عشوائي أو اسم المستخدم في بداية موجه النظام.
- إعادة ترتيب الأدوات أو المستندات في كل طلب.
- وضع المستند كاملًا في المقدمة ثم طرح سؤال المستخدم بعده.
- التنقل بين طرازات أو مداخل مختلفة للنشاط نفسه.
- أن تكون البادئة قصيرة جدًا دون الوصول إلى الحد القابل لإعادة الاستخدام.
نقل المحتوى المتغير إلى نهاية الطلب ووضع المحتوى المستقر في البداية هو أبسط الممارسات وأكثرها فعالية. التخزين المؤقت جهد بذل أفضل (best effort) ولا يضمن الإصابة؛ لذلك تُقدّر الميزانية على أساس «إصابة جزئية» بدلًا من افتراض إصابة كاملة.
ثالثًا: تقدير واقعي باستخدام حقل usage
لا تخمّن عدد الرموز من عدد الكلمات. سجّل حقل usage من كل استجابة، وراقبه أسبوعًا متواصلًا لتحصل على البنية الفعلية لنشاطك.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEEPSEEK_API_KEY"],
base_url="https://api.deepseek.com",
)
resp = client.chat.completions.create(
model="deepseek-chat", # اسم الطراز وفق صفحة الأسعار
messages=[
{"role": "system", "content": "أنت مساعد خدمة عملاء، أجب في ثلاث جمل كحد أقصى."},
{"role": "user", "content": "هل يمكن تغيير العنوان بعد شحن الطلب؟"},
],
max_tokens=256,
)
usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0
print("الإدخال", usage.prompt_tokens)
print("إصابة الذاكرة", hit, "عدم الإصابة", miss)
print("الإخراج", usage.completion_tokens)
إذا لم تُعد الاستجابة حقولًا مفصلة للتخزين المؤقت، فسجّل إجمالي الإدخال وإجمالي الإخراج، ثم استنتج التفصيل من الفاتورة أو صفحة الاستخدام. المهم هو الحفاظ على اتساق تعريف الحقول، وعدم مقارنة بيانات تواريخ أو مداخل مختلفة معًا.
سجّل في التقدير على الأقل: الوقت، والمشروع، والطراز، ورموز الإدخال، ورموز الإخراج، وإصابة التخزين المؤقت، وعدد المحاولات، وما إذا كان الطلب متدفقًا. تُضرب المبالغ في سعر الوحدة في نهاية الشهر، أما المؤشرات التشغيلية فتُراجع يوميًا.
رابعًا: لماذا تتضاعف الفاتورة عدة مرات مع حجم الاستدعاء نفسه
| السيناريو | بنية الرموز النموذجية | نقطة تضخم التكلفة | أولوية التحسين |
|---|---|---|---|
| روبوت خدمة العملاء | إدخال كبير وإخراج قصير | إعادة إرسال الرسائل السابقة | التلخيص، والتخزين المؤقت، والاكتفاء بالجولات الأخيرة |
| استخراج المستندات | إدخال متوسط وإخراج مهيكل | قراءة المستند نفسه مرارًا | تخزين البادئة مؤقتًا، والمعالجة الدفعية |
| مساعد الكود | إدخال وإخراج كبيران | نتائج الأدوات والملفات الطويلة | الاسترجاع، والتقسيم، وتحديد الإخراج |
| توليد النصوص الطويلة | إدخال قصير وإخراج طويل | تراكم رموز الإخراج | التوليد على مراحل، وmax_tokens |
| مهام الاستدلال | إدخال متوسط وإخراج يتضمن التفكير | احتساب التفكير ضمن الإخراج | استخدام طراز غير استدلالي للمهام البسيطة |
يعود الاختلاف عادةً إلى خمسة مصادر:
- اختلاف نسبة الإدخال إلى الإخراج: بنية تكلفة خدمة العملاء معاكسة تمامًا لبنية كتابة النصوص الطويلة، ولا يصح تقديرهما بمتوسط واحد.
- اختلاف نسبة إصابة التخزين المؤقت: البادئة الثابتة قابلة لإعادة الاستخدام، بينما المحتوى الديناميكي يبطل الذاكرة.
- اختلاف طول السياق: عند إدخال المستند كاملًا في كل جولة، تتراكم تكلفة الإدخال مع عدد الجولات.
- اختلاف عدد المحاولات: إعادة الإرسال بعد 429 أو انتهاء المهلة يزيد حجم الطلبات، ويُراجع في الفاتورة ما إذا كانت الطلبات الفاشلة محتسبة.
- اختلاف فئة الطراز: تختلف أسعار طرازات الاستدلال وغير الاستدلال وأطوال إخراجها، وسوء الاختيار يضخم الميزانية.
خامسًا: لا تعكس ترتيب خفض التكلفة
- القياس أولًا: احسب بنية الرموز الفعلية لكل ميزة من usage والسجلات، لا من الانطباع.
- ثم ارفع نسبة إصابة الذاكرة: ثبّت موجه النظام وتعريفات الأدوات وبادئة المعرفة، وقلل المحتوى الديناميكي في البداية.
- ثم قلل الإدخال: اجعل RAG يسترجع المقاطع ذات الصلة فقط، ولخّص الرسائل السابقة، واحتفظ بالحقول الضرورية فقط من مخرجات الأدوات.
- حدّد الإخراج: اضبط
max_tokensبقيمة معقولة، واطلب JSON أو حقولًا ثابتة، وقلل الشرح المتكرر. - وزّع الأحمال على الطرازات: استخدم طرازًا خفيفًا للتصنيف والاستخراج وإعادة الصياغة، وارفع المستوى عند الاستدلال المعقد فقط.
- الطلبات غير المتزامنة والدفعات: ضع المهام غير الحساسة للتأخير مثل الوسم والتلخيص والتحليل دون الاتصال في قائمة انتظار.
- المراقبة والتنبيه: راقب الاستخدام حسب المشروع والطراز والسيناريو، واضبط سقف الميزانية.
عكس الترتيب ينتهي عادةً إلى نتيجة واحدة: استبدال الطراز بآخر أرخص، مع إدخال غير منظم وذاكرة لا تصيب، فلا تنخفض الفاتورة وتتراجع الجودة.
سادسًا: كيف تُدار الميزانية والفاتورة
- مفتاح واحد لكل مشروع، مع فصل الاختبار عن الإنتاج لتجنب تنافس الحصص.
- ضبط سقف استهلاك وتنبيهات للمفاتيح، لإيقاف الخسائر تلقائيًا عند الاستدعاءات غير الطبيعية.
- تسوية أسبوعية وفق «المشروع والطراز والسيناريو» لتحديد الاستدعاءات الأسرع نموًا.
- تسجيل التوفير الناتج عن التخزين المؤقت وتوزيع الطرازات بشكل منفصل، وإلا تعذر إثبات فعالية التحسين.
- الفرق التي تحتاج الدفع بالعملة المحلية والفواتير يمكنها توحيد الفاتورة عبر بوابة API محلية؛ وتُراجع الأسعار وأسعار الصرف وقواعد الفواتير في صفحة الأسعار.
الأسئلة الشائعة
هل يلزم تفعيل التخزين المؤقت في DeepSeek يدويًا؟
لا يلزم عادةً وضع علامة صريحة على مقطع الذاكرة، إذ يحدد الخادم تلقائيًا إمكانية إعادة استخدام البادئة؛ وتُراجع الآلية الدقيقة ومدة الاحتفاظ في الوثائق الرسمية. ما عليك فعله هو تثبيت البادئة، لا إضافة مزيد من الإعدادات.
لماذا تتقلب نسبة إصابة التخزين المؤقت صعودًا وهبوطًا؟
من الأسباب الشائعة تسلل الطوابع الزمنية أو المعرّفات العشوائية أو معلومات المستخدم إلى البادئة، أو تبديل الطلبات بين طرازات أو مداخل مختلفة. انقل المحتوى المتغير إلى النهاية ثم راقب أسبوعًا.
هل تُحتسب رموز التفكير في طرازات الاستدلال؟
تُحتسب رموز التفكير الناتجة عن طراز الاستدلال ضمن الإخراج عادةً، ويُراجع التعريف الدقيق في الوثائق الرسمية والفاتورة. لا يُنصح باستخدام طراز استدلال افتراضيًا في مهام التصنيف والاستخراج البسيطة.
أيهما أغلى: الإدخال أم الإخراج؟
سعر الإخراج أعلى من سعر الإدخال في معظم الطرازات، لكن سعر الإدخال بعد إصابة الذاكرة يكون أقل عادةً. لا تقارن السعرين وحدهما، بل احسب تكلفة الطلب الواحد وفق نسبة الإدخال إلى الإخراج لديك.
لماذا لا يتطابق التقدير مع الفاتورة؟
من البنود المنسية الشائعة الرسائل السابقة وتعريفات الأدوات وطلبات إعادة المحاولة وعدم إصابة الذاكرة والإخراج الطويل. طابق معرّف الطلب مع سجل الاستخدام لتحديد الفرق.
الخطوة التالية
أنشئ مفتاح اختبار في بوابة ZSQH AI، وشغّل مهامًا حقيقية لمدة أسبوع مع تسجيل الإدخال والإخراج وإصابة التخزين المؤقت، ثم قدّر الميزانية وفق صفحة الأسعار. تتحدد توفر الطرازات وأسعارها وفق صفحة الأسعار.
قراءات ذات صلة:
