الاستخدام & الإحصائيات

تعرّف على كيفية تتبّع استهلاكك من الرصيد، وفهم آلية احتساب الرموز (Tokens)، وتحسين طلباتك لخفض التكلفة.

التحقق من رصيدك الحالي

الرصيد المتاح
842.50
رصيدة — تُحدَّث فور كل طلب
GET /api/billing/subscription

يمكنك الاستعلام عن رصيدك الحالي برمجيًا في أي وقت عبر نقطة النهاية التالية:

HTTP Request
GET https://llmapi.resayil.io/api/billing/subscription Authorization: Bearer YOUR_API_KEY

يعيد الطلب الناجح استجابةً بتنسيق JSON تحتوي على تفاصيل الاشتراك وإجمالي الرصيد المتبقي:

JSON Response
{ "tier": "free", "status": "active", "expires_at": null, "credits": 842.50 }

حقل credits يمثّل رصيدك المتاح حاليًا. تُخصم الرصيدة مع كل طلب بحسب عدد الرموز والنموذج المستخدَم.

كيف تُحتسب الرموز (Tokens)؟

يقيس النظام استهلاكك بالرموز (Tokens). الرمز الواحد يعادل تقريبًا أربعة أحرف باللغة الإنجليزية، أو كلمة إلى كلمة ونصف. كل طلب يحتسب نوعين من الرموز:

  • prompt_tokens — رموز الرسالة المُرسَلة إلى النموذج (بما في ذلك رسائل النظام والسياق السابق).
  • completion_tokens — رموز الاستجابة التي ولّدها النموذج.
  • total_tokens — المجموع: prompt_tokens + completion_tokens. هذا هو الرقم المستخدَم في احتساب الخصم.

تظهر هذه القيم في حقل usage ضمن كل استجابة:

JSON — usage field
{ "usage": { "prompt_tokens": 42, "completion_tokens": 118, "total_tokens": 160 } }

صيغة خصم الرصيد

لا تُخصم الرموز بمعدل ثابت لجميع النماذج. يعتمد النظام على معامل ضرب خاص بكل نموذج يعكس تكلفته التشغيلية:

total_tokens إجمالي الرموز
×
model_multiplier معامل النموذج
=
credits_deducted الرصيد المخصوم
نوع النموذج معامل الضرب أمثلة
النماذج القياسية 0.5× – 1.5× Mistral, Llama 3, Neural Chat
النماذج المتقدمة 2× – 3.5× GPT-4o, Claude 3.5, Gemini Pro

مثال: إذا أرسلت طلبًا بـ 200 رمز إجماليًا باستخدام نموذج محلي بمعامل 1×، يُخصم 200 رصيدة. نفس الطلب عبر نموذج سحابي بمعامل 3×، يُخصم 600 رصيدة.

ملاحظة: يمكنك الاطلاع على معامل الضرب الدقيق لكل نموذج في صفحة النماذج المتاحة.

البث الفوري مقابل الاستجابة الكاملة

يدعم LLM Resayil وضعَي الاستجابة: الكاملة (non-streaming) والبث الفوري (streaming عبر stream: true). آلية احتساب الرموز متطابقة في كلا الوضعين — الفارق يكمن في طريقة استلام البيانات فحسب:

  • غير بث (Non-streaming): تصل الاستجابة كاملةً في رسالة واحدة، وتتضمّن حقل usage مباشرةً.
  • بث فوري (Streaming): تصل الاستجابة على شكل أجزاء (chunks) عبر Server-Sent Events. حقل usage يظهر في الجزء الأخير ([DONE]).

الخصم من الرصيد يتمّ بعد اكتمال الاستجابة بالكامل في كلتا الحالتين. لا يتأثر إجمالي الرموز المحتسبة بطريقة الاستلام.

تتبُّع آخر استخدام لمفتاح API

يحتفظ النظام بطابع زمني (last_used_at) لكل مفتاح API، يُحدَّث بدقة كل دقيقة لتقليل الضغط على قاعدة البيانات. يمكنك مشاهدة هذه القيمة في صفحة مفاتيح API في لوحة التحكم.

يُفيد هذا المؤشر في رصد النشاط غير المعتاد أو التحقق من أن التطبيق يستخدم المفتاح الصحيح. إن رأيت مفتاحًا لم يُستخدَم منذ فترة طويلة، يُنصح بإلغائه وإنشاء مفتاح جديد.

نصائح لتحسين استهلاك الرصيد

اتبع هذه الممارسات لخفض تكلفة طلباتك دون التضحية بالجودة:

  1. اختصر رسائل النظام: رسائل النظام الطويلة تُحتسب في كل طلب. احرص على إيجازها مع الحفاظ على وضوحها.
  2. استخدم نماذج محلية للمهام البسيطة: النماذج المحلية بمعامل 0.5×–1.5× مناسبة لمعظم المهام العامة وتكلفتها أقل بكثير.
  3. حدّ من max_tokens: ضبط قيمة max_tokens يمنع النموذج من توليد استجابات أطول من اللازم.
  4. قلّل من سياق المحادثة: كلما أرسلت رسائل تاريخية أكثر في كل طلب، ارتفعت تكلفة prompt_tokens. احذف الرسائل القديمة غير الضرورية.
  5. احجز النماذج السحابية للمهام المعقدة: استخدم نماذج GPT-4o أو Claude فقط عندما تتطلب المهمة قدرات استدلال متقدمة.

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

هل تحتاج إلى رصيد إضافي؟

تعرّف على طريقة شراء حزم الرصيد الإضافية (Top-Up).

الانتقال إلى صفحة الشحن →