يوفر xAI واجهة Grok API، ويُحاسب عليها بالرموز مع تسعير الإدخال والإخراج منفصلًا. كثير من الفرق لا تنظر عند إعداد الميزانية إلا إلى سعر النموذج، ثم تكتشف بعد الإطلاق فجوة كبيرة بين الفاتورة والتقدير: رسائل التاريخ تُنقل كل جولة، والإخراج مكتوب بإسهاب، وإعادة المحاولة بلا تباعد، والمستندات الطويلة تُحمَّل مرارًا. كل ذلك يضاعف التكلفة.
لا يثبّت هذا المقال أي سعر وحدة، بل يفكك بنية فوترة Grok API ويقدم طريقة تقدير قابلة للتكرار وترتيبًا لضبط التكلفة. الأسعار الفعلية والنماذج المتاحة وأطوال السياق مرجعها وثائق xAI الرسمية وصفحة أسعار النماذج.
ملاحظة: xAI وGrok علامتان تجاريتان لأصحاب حقوقهما، وهذا المقال تقني فقط. قد تتغير أسماء النماذج والواجهات والأسعار، لذا راجع الصفحات الرسمية وصفحة أسعار النماذج قبل الشراء.
أولًا: من ماذا تتكون فاتورة Grok API
تستخدم Grok API شكل Chat Completions المتوافق مع OpenAI، وتتكون الفاتورة عادة أساسًا من رموز الإدخال ورموز الإخراج. في المشاريع الفعلية يجب أيضًا احتساب التخزين المؤقت واستدعاء الأدوات والسياق الطويل وإعادة المحاولة الفاشلة.
| بند الفوترة | متى ينشأ | عوامل التضخيم الشائعة | وسيلة الضبط |
|---|---|---|---|
| رموز الإدخال | موجه النظام، رسائل التاريخ، تعريفات الأدوات، المستندات | إعادة نقل التاريخ كاملًا كل جولة | التلخيص، التقليم، استرجاع المقاطع |
| الإدخال المخزن مؤقتًا | إعادة استخدام البادئة نفسها | بادئة غير مستقرة فلا تصيب | تثبيت النظام وترتيب الأدوات |
| رموز الإخراج | المحتوى الذي يولده النموذج | إجابات مطولة وتنسيق غير مضبوط | ضبط max_tokens والإخراج المنظم |
| استدعاء الأدوات | استدعاء الدوال والبحث وغيرها | حلقات متعددة واستعلامات مكررة | تقييد الجولات وتخزين النتائج |
| السياق الطويل | مستندات ومحادثات طويلة | إدخال المكتبة كاملة وقراءة متكررة | المعالجة بالمقاطع وأخذ المقاطع ذات الصلة |
| إعادة المحاولة | إعادة الإرسال بعد 429 أو المهلة | غياب التباعد وتزامن مرتفع | التباعد الأُسّي وفحص عدم التكرار |
قد يكون لكل نموذج أو قدرة أساس فوترة مستقل، مثل هل يُسعَّر الإدخال المخزن مؤقتًا، وهل تُحاسب استدعاءات الأدوات منفصلة. المرجع هو تعليمات الفوترة الرسمية من xAI. قبل الميزانية حدد بنود الفوترة التي تستخدمها فعلًا، ثم ناقش سعر الوحدة.
ثانيًا: لماذا تختلف الفاتورة عدة أضعاف مع العدد نفسه من الاستدعاءات
قد يكون عدد الاستدعاءات متطابقًا والفاتورة مختلفة تمامًا. يأتي الاختلاف عادة من ستة مواضع:
- نسبة الإدخال إلى الإخراج: روبوت خدمة العملاء إدخاله كبير وإخراجه متوسط؛ وتوليد المحتوى إدخاله قصير وإخراجه طويل. لا يمكن تقدير بنيتي التكلفة بمتوسط واحد.
- تراكم السياق: المحادثة متعددة الجولات تحمل التاريخ كاملًا كل مرة، فترتفع رموز الإدخال سريعًا مع الجولات.
- نسبة إصابة التخزين المؤقت: البادئة الثابتة قابلة لإعادة الاستخدام؛ والطوابع الزمنية والمعرّفات العشوائية وقوائم الأدوات الديناميكية تعطل التخزين المؤقت.
- فئة النموذج: تختلف قدرات طرازات Grok وأسعار وحدتها، واستخدام طراز رفيع لمهمة بسيطة يضاعف الميزانية.
- عدد المحاولات: كل إعادة محاولة طلب جديد، وإعادة الإرسال الفوري بعد 429 تصنع عاصفة محاولات.
- طول الإخراج: سعر الإخراج أعلى عادة من الإدخال، والإجابات الطويلة والتفسيرات المكررة والتنسيق غير المضبوط ترفع التكلفة.
| السيناريو | بنية الرموز | التكلفة الرئيسية | اتجاه التحسين |
|---|---|---|---|
| روبوت خدمة العملاء | إدخال كبير وإخراج متوسط | نقل رسائل التاريخ المتكرر | التلخيص والتخزين المؤقت |
| استخراج المستندات | إدخال طويل وإخراج قصير | قراءة المستند مرارًا | الاسترجاع ونموذج صغير |
| مساعد الشيفرة | إدخال وإخراج كبيران | نتائج الأدوات وعملية التفكير | تقليم مخرجات الأدوات وتوجيه النماذج |
| توليد المحتوى | إدخال قصير وإخراج طويل | رموز الإخراج | التوليد بالمقاطع وتقييد الطول |
ثالثًا: حساب تكلفة الطلب الواحد
إذا فككنا الطلب، يمكن التعبير عن التكلفة بالمعادلة:
تكلفة الطلب الواحد =
رموز الإدخال غير المخزنة × سعر الإدخال
+ رموز الإدخال المخزنة × سعر التخزين المؤقت
+ رموز الإخراج × سعر الإخراج
+ رسوم إضافية مثل الأدوات أو البحث
المعادلة نفسها ليست صعبة، لكن الحصول على عدد الرموز الحقيقي هو الصعب. لا تخمّن بعدد الأحرف، بل اقرأ حقل usage من الاستجابة:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["GROK_API_KEY"],
base_url=os.environ.get("GROK_BASE_URL", "https://ai.zhongshangqihang.com/v1"),
)
resp = client.chat.completions.create(
model="grok-4",
messages=[{"role": "user", "content": "قسّم هذا المتطلب إلى خمس مهام تطويرية."}],
max_tokens=512,
)
usage = resp.usage
print("رموز الإدخال:", usage.prompt_tokens)
print("رموز الإخراج:", usage.completion_tokens)
print("إجمالي الرموز:", usage.total_tokens)
اضرب المبلغ في سعر الوحدة الفعلي لحسابك، واقرأ السعر من أسعار النماذج، ولا تستخدم لقطة شاشة عمرها أشهر. قد تختلف أسماء حقول إحصاء إصابة التخزين المؤقت بين تطبيقات التوافق، والمرجع ما تعيده الاستجابة.
رابعًا: ترتيب خفض التكلفة
لخفض التكلفة ترتيب، وعكسه يهدر الجهد. يُنصح بالخطوات السبع التالية:
- قياس الأساس أولًا: صدّر سجلات الطلبات الحقيقية لأسبوع، وأحصِ رموز الإدخال والإخراج حسب المشروع والنموذج والسيناريو لتعرف أين تُصرف الأموال.
- توجيه النماذج: التصنيف والاستخراج وإعادة الصياغة بنماذج صغيرة، والاستدلال المعقد بالنماذج الرفيعة، والتوزيع حسب صعوبة المهمة لا حسب عادة الفريق.
- تقليل الإدخال: لا يسترجع RAG إلا المقاطع ذات الصلة، وتُلخَّص رسائل التاريخ، ويُحتفظ من مخرجات الأدوات بالحقول الضرورية فقط.
- تقييد الإخراج: اضبط
max_tokensالمناسب واطلب JSON أو حقولًا ثابتة، وقلل المجاملات والتفسيرات المكررة. - الاستفادة من التخزين المؤقت: ثبّت موجه النظام وتعريفات الأدوات وبادئة قاعدة المعرفة، وتحقق هل الإصابة تحدث فعلًا.
- حوكمة إعادة المحاولة: استخدم تباعدًا أُسّيًا مع تذبذب عشوائي في 429 والمهلة، واضبط سقف المحاولات، وتجنب إعادة المحاولة العنيفة بفاصل ثابت.
- الميزانية والتنبيهات: ضع سقوفًا لكل مشروع، وراجع أسبوعيًا ترتيب الاستهلاك، وحدد النمو الزائد فورًا.
ابدأ بحوكمة الإدخال والتخزين المؤقت قبل التفكير في نموذج أرخص. وإلا فأنت تجعل الإخراج غير المستقر أرخص فقط، وستعود تكلفة إعادة العمل.
خامسًا: كيف تدير الميزانية والفاتورة
- مفتاح واحد لكل مشروع مع سقف ميزانية للمشروع، لتجنب تنافس الخدمات على الحصة.
- سجّل على الأقل الوقت والنموذج ورموز الإدخال والإخراج ورمز الحالة ومعرّف الطلب، دون تسجيل المفتاح كاملًا أو المحتوى الحساس.
- طابق شهريًا حسب «المشروع والنموذج والسيناريو» لاكتشاف الاستدعاءات الأسرع نموًا.
- سجّل التوفير الناتج عن التخزين المؤقت وتوجيه النماذج وتقييد الإخراج منفصلًا، وإلا لا يمكن إثبات أثر التحسين.
- يمكن للفرق التي تحتاج الدفع باليوان والفاتورة الضريبية استخدام بوابة AI محلية لتوحيد الفاتورة؛ والأسعار وأسعار الصرف وقواعد الفاتورة مرجعها أسعار النماذج.
الأسئلة الشائعة
هل تتكون فاتورة Grok API من الإدخال والإخراج فقط؟
الفاتورة الشائعة تتكون أساسًا من رموز الإدخال والإخراج، لكن الإدخال المخزن مؤقتًا واستدعاء الأدوات والبحث قد يكون لها أساس فوترة منفصل. البنود الدقيقة مرجعها تعليمات الفوترة الرسمية وتفاصيل الفاتورة.
لماذا لا يكون التقدير بمتوسط الرموز دقيقًا؟
المتوسط يخفي الطلبات ذات الذيل الطويل. قلة من الطلبات ذات السياق الطويل أو الإخراج الطويل أو إعادة المحاولة قد تنتج معظم التكلفة. قراءة التوزيع من السجلات الحقيقية أدق من ضرب متوسط في عدد الاستدعاءات.
كم يوفر التخزين المؤقت؟
يعتمد على نسبة إعادة استخدام البادئة ونسبة الإصابة. قراءة التخزين المؤقت أرخص عادة من سعر الإدخال العادي، لكن الكتابة قد تحمل علاوة، والبادئة القصيرة جدًا أو المتغيرة كل مرة لا تصيب. تحقق من الإصابة في السجلات أولًا ثم قدّر التوفير.
هل الإخراج الأطول أغلى؟
عادة نعم، لأن رموز الإخراج تُسعَّر منفصلة وسعرها غالبًا أعلى من الإدخال. تقييد الإجابة على الطول الذي تحتاجه الأعمال مع الإخراج المنظم أسرع أثرًا عادة من تغيير النموذج.
كيف تستخدم الفرق المحلية الدفع باليوان؟
يمكن استدعاء Grok عبر بوابة AI توفر الشحن باليوان والفاتورة الضريبية وتوحيد فاتورة عدة نماذج. النماذج المتاحة والأسعار وقواعد الفاتورة مرجعها أسعار النماذج.
الخطوة التالية
أنشئ مفتاح اختبار في ZSQH AI Gateway، وسجّل رموز الإدخال والإخراج لدفعة مهام حقيقية، ثم أعد الميزانية وفق المعادلة أعلاه. توفر النماذج والأسعار في أسعار النماذج.
قراءات ذات صلة:
