اشتراك ChatGPT مقابل واجهة برمجة التطبيقات (API): مفاضلات التكلفة للمطورين

نادراً ما يعتمد القرار بين ChatGPT وواجهة برمجة التطبيقات (API) على السعر المعلن فقط. بل يعتمد على حجم الطلبات وعلى ما يُسمح لكل نموذج تسعير بالقيام به أصلاً. الاشتراك هو رسوم شهرية ثابتة لمستخدم بشري واحد يستخدم تطبيق المحادثة؛ في حين تقيس واجهة برمجة التطبيقات كل رمز (token) ترسله وتستقبله. وتحديد الخيار الأرخص بالنسبة لك يعود إلى رقمين يجب عليك البحث عنهما بدلاً من الاعتماد على الذاكرة: فاتورة اشتراكك الفعلية وتكلفة واجهة برمجة التطبيقات الفعلية لكل طلب لديك.

النقاط الرئيسية

• اشتراك ChatGPT هو مقعد بسعر ثابت للاستخدام البشري الفردي في واجهة المحادثة. وهو ليس وسيلة لمصادقة زيارات واجهة برمجة التطبيقات الآلية أو متعددة المستخدمين.
• تتم فوترة واجهة برمجة التطبيقات (API) لكل رمز، ولا توجد فئة اشتراك بسعر ثابت خاصة بها.
• نقطة التعادل هي سعر الاشتراك الشهري ÷ التكلفة لكل طلب. يتغير كلا المدخلين بمرور الوقت، لذا احصل عليهما من مصادر مباشرة ومحدثة قبل اتخاذ القرار.
• تُعد الأغلفة البرمجية (wrappers) غير الرسمية أو القائمة على الهندسة العكسية حول المنتج الاستهلاكي لتفادي فوترة واجهة برمجة التطبيقات انتهاكاً لشروط خدمة المزود.

ما تتم فوترة كل منهما عليه فعلياً

هذان نظامان منفصلان للفوترة مبنيان على افتراضات مختلفة:

• الاشتراك (Plus / Team / Enterprise): يغطي الاستخدام التفاعلي في تطبيق المحادثة. وتفرض خطط مثل Plus وTeam رسوماً دورية ثابتة لكل مقعد، في حين تتضمن ترتيبات Enterprise عادةً شروطاً مخصصة. تحقق من شروط المزود الحالية مباشرةً بدلاً من افتراض أن جميع الخطط تتبع أسعاراً ثابتة متطابقة.
• واجهة برمجة التطبيقات (API): لا يوجد اشتراك. يتم قياس كل رمز إدخال (input token)، ورمز مخزن مؤقتاً (cached token)، ورمز إخراج (output token) وفقاً لسعر النموذج المحدد.

نظراً لأن تسعير الاثنين يتم بشكل منفصل، فإن رقم الاشتراك منذ أشهر مضت لا يخبرك بأي شيء عن نقطة التعادل اليوم. تحقق من صفحات المزود الحالية مباشرةً: وثائق تسعير API وصفحة تسعير ChatGPT.

كيفية حساب نقطة التعادل الخاصة بك

المعادلة بسيطة:

طلبات نقطة التعادل شهرياً = سعر الاشتراك الشهري ÷ تكلفة API لكل طلب

للحصول على جانب واجهة برمجة التطبيقات، قم ببناء التكلفة لكل طلب من أرقامك الخاصة:

1. قدّر متوسط رموز الإدخال لكل طلب (الموجه الأساسي/system prompt + رسالة المستخدم + أي سياق مسترجع).
2. قدّر متوسط رموز الإخراج لكل طلب.
3. اضرب كلاً منهما في السعر الحالي للإدخال والإخراج للنموذج الذي اخترته، ثم اجمعهما.

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

مثال توضيحي

لمعرفة كيفية عمل الحسابات، ضع في اعتبارك قيماً توضيحية افتراضية: اشتراك بقيمة 20 دولاراً/شهرياً وحجم عمل يبلغ متوسطه 0.01 دولار لكل طلب في رموز واجهة برمجة التطبيقات المحتسبة. ستكون نقطة التعادل 20 ÷ 0.01 = 2,000 طلب/شهرياً. تحت هذا الحجم تكون واجهة برمجة التطبيقات أرخص لحجم العمل هذا؛ وفوقه بكثير، تكون الخطة هي الأرخص (حيثما يسمح الاستخدام التفاعلي والشروط). استبدل فاتورتك الفعلية وتكلفتك الحقيقية لكل طلب — الطريقة تظل صحيحة، لكن الأرقام التوضيحية لا تنطبق حرفياً.

من أين تأتي تكلفة واجهة برمجة التطبيقات فعلياً

• عادة ما يتم تسعير رموز الإدخال مقابل رموز الإخراج بشكل مختلف، وغالباً ما تكلف رموز الإخراج أضعافاً مضاعفة.
• عادة ما يكون اختيار النموذج عاملاً أكبر تأثيراً من تبديل فئات الفوترة لدى مزود واحد.
• طول السياق (Context length). واجهات برمجة تطبيقات إكمال المحادثة (Chat completion APIs) هي عموماً استدعاءات طلب/استجابة عديمة الحالة (stateless): ما لم يقدم المزود ميزة لحفظ حالة المحادثة أو التخزين المؤقت للموجهات (prompt-caching)، فعادةً ما يُعاد إرسال المحادثة السابقة بالكامل كرموز إدخال في كل دور. تحقق من معالجة السياق وأي خصومات على المدخلات المخزنة مؤقتاً في الوثائق الحالية للنموذج الذي تستخدمه، حيث يتغير هذا بين الإصدارات.
• الأوضاع الدفعية (Batch) أو غير المتزامنة (asynchronous)، حيثما توفرت، يمكن أن تسعر نفس العمل بأقل من الاستدعاءات المتزامنة.

تقليل تكلفة واجهة برمجة التطبيقات دون الإضرار بالجودة

• وجّه الأعمال البسيطة ذات الحجم الكبير (التصنيف، الردود القصيرة) إلى نموذج أرخص بدلاً من استخدام الفئة الأكثر تكلفة لكل شيء.
• ضع حداً أقصى لـ max_tokens عندما لا تكون هناك حاجة للاستجابات الكاملة الطول.
• استخدم الأوضاع الدفعية أو غير المتزامنة للأعمال التي لا تتطلب إجابة فورية.
• قم بتخزين الاستجابات مؤقتاً (cache) للطلبات المتطابقة المتكررة.
• بعد الإطلاق، اختبر بعض النماذج على نفس المهمة وقارن التكلفة النهائية لكل مهمة مكتملة في سجلات استخدامك، وليس فقط السعر الإعلاني لكل رمز.

عندما لا يكون الاشتراك خياراً على الإطلاق

لأي عمل يخدم أكثر من مستخدم نهائي واحد، أو أي برنامج نصي غير مراقب (unattended script)، فأنت تخضع لتسعير واجهة برمجة التطبيقات بشكل افتراضي: الاشتراكات غير مرخصة لخدمة طلبات أشخاص آخرين. إن التطوير والاعتماد على أغلفة برمجية غير رسمية تعيد تشغيل جلسة محادثة استهلاكية ينتهك شروط خدمة المزود، ويتعطل كلما تغيرت الواجهة الأساسية، ويخاطر بتعليق الحساب. إذا كانت التكلفة هي مصدر القلق، فإن الحل يكمن في اختيار النموذج والوضع المناسبين، وليس تجاوز الفوترة.

تشغيل هذا على TokenLab

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

• تصفح التوفر والأسعار الحالية على صفحة النماذج.
• اقرأ أسعار نموذج معين، وحدود السياق، وتنسيقات الطلبات المقبولة باستخدام GET /v1/models/{model}، أو اعرض الكتالوج بأكمله عبر GET /v1/models.
• الرسوم وطبقات التسليم وعناصر التحكم في الإنفاق موثقة في الفوترة والتسعير.
• مفتاح واحد يعمل عبر تنسيقات Chat Completions وResponses وAnthropic Messages وGemini؛ راجع تنسيقات API ودليل البدء السريع.

القيود

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