السعر الرخيص لكل رمز لا يعني بالضرورة تكلفة أقل لمطوري البرمجة بالذكاء الاصطناعي

قد يكون النموذج رخيصاً لكل رمز (Token) ومكلفاً لكل مطور في آن واحد. لا تناقض هنا: المقارنة تكون غالباً بين منتجين مختلفين؛ واجهة API تُحاسبك على كل رمز، واشتراك برمجي يضع سقفاً نسبياً لما يدفعه المستخدم ما دام ضمن قواعد الاستخدام الخاصة بالخطة.

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

سعر منخفض للمليون، وفاتورة بلا سقف

تُدرج GLM-5.2 سعراً قدره 1.40 دولار لكل مليون رمز إدخال، و0.26 دولار لكل مليون رمز إدخال مخزن مؤقتاً، و4.40 دولار لكل مليون رمز مخرجات. 1 قد تبدو هذه الأرقام جذابة في الاستخدام المعتاد، لكن الحساب يتغير سريعاً مع الأحجام الضخمة:

• مليار رمز إدخال غير مخزن مؤقتاً: 1,400 دولار
• مليار رمز إدخال مخزن مؤقتاً: 260 دولاراً
• مليار رمز مخرجات: 4,400 دولار

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

يساعد التخزين المؤقت كثيراً عند إعادة استخدام السياق؛ إذ تُحاسب الرموز المعاد استخدامها بسعر إدخال مخزن مؤقتاً أقل بكثير. لكن الفاتورة النهائية تظل رهناً بالمزيج الفعلي بين الإدخال غير المخزن، والإدخال المخزن، والمخرجات. 1

لماذا تحتاج مقارنة «7,800 يوان يومياً» إلى تفاصيل إضافية؟

تداولت مقارنة تقدّر استخدام API لـGLM-5.2 بنحو 7,800 يوان صيني يومياً، مقابل تكلفة أسبوعية ثابتة أقل بكثير لاشتراك Codex. وهي تعبّر عن فرق حقيقي بين الفوترة حسب الاستخدام والاشتراك ذي الحصة، لكن ادعاء حجم الرموز يحتاج إلى تدقيق.

وفق الأسعار المنشورة لـGLM-5.2، فإن عشرات مليارات رموز الإدخال غير المخزنة مؤقتاً وحدها ستكلف عشرات آلاف الدولارات يومياً، وستكون تكلفة المخرجات بهذا الحجم أعلى بكثير. 1 لذلك قد تعكس فاتورة قدرها 7,800 يوان حجماً فعلياً أقل من الرموز القابلة للفوترة، أو نسبة مرتفعة من الإدخال المخزن مؤقتاً، أو مزيجاً معيناً من الإدخال والمخرجات، أو سعراً مخفضاً، أو أساس تسعير مختلفاً.

الخلاصة العملية: لا تكفي حصيلة الرموز وحدها. عند مقارنة سير عمل برمجي، قِس ما يلي:

1. رموز الإدخال غير المخزنة مؤقتاً؛
2. رموز الإدخال المخزنة مؤقتاً؛
3. رموز المخرجات؛
4. فترات إعادة ضبط الحصص وحدود الخطة؛
5. وما إذا كان تجاوز الحصة ينتقل إلى استخدام مدفوع.

الاشتراك يحدّ الإنفاق، لا يجعل الاستدلال مجانياً

لا يجعل الاشتراك تكلفة الاستدلال صفراً، بل يغيّر الطرف الذي يتحمل تقلبها.

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

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

بعض خطط البرمجة المحلية تبقى مقيدة بالرصيد

الفارق ليس بين نموذج صيني وآخر أجنبي، بل في طبيعة المنتج: هل هو عداد رموز مفتوح، أم محفظة أرصدة، أم حصة سخية تتجدد دورياً؟

تستخدم GLM Coding Plan قيدين صريحين: حصة نقاط متحركة لكل خمس ساعات، وحصة نقاط أسبوعية. فالخطة Pro تمنح 12,000 نقطة كل خمس ساعات و60,000 نقطة أسبوعياً، فيما تمنح Max 28,000 و140,000 نقطة على الترتيب. ويُحتسب الاستهلاك من رموز الإدخال والإدخال المخزن والمخرجات بمعاملات تختلف حسب النموذج. 2

أما Qoder فتوضح هيكل الأرصدة بشكل مباشر: تقدم خططها المدفوعة 2,000 أو6,000 أو20,000 رصيد شهرياً للنماذج المميزة، ثم تنقل المستخدم بعد نفادها إلى نموذج أساسي ذي عدد رسائل محدود. كما تقول إن موارد النماذج المميزة المضمنة تعادل قيمة الاشتراك، إضافة إلى الموارد الإضافية الممنوحة. 17

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

مضاعفات الذروة تكشف السعة المتاحة للمستخدم

ليست حدود الحصة القيد الوحيد؛ إذ تستطيع الشركات تغيير سرعة استهلاك الحصة في ساعات الضغط.

تذكر وثائق Z.ai الحالية أن GLM-5.3 يستهلك الحصة بمعامل 1× خارج الذروة و3× في الذروة، بينما يُدرج GLM-5.3-Flash بمعاملَي 0.4× و1.2× على التوالي. 4 كما تحدد نظرة GLM Coding Plan فترة ذروة في أيام العمل من 14:00 إلى18:00 بتوقيت UTC+8. 2

هذه آلية لإدارة السعة: يبقى سعر الاشتراك النقدي نفسه، لكن مقدار العمل الذي تغطيه الحصة قد ينخفض خلال الفترات المزدحمة. ولا ينبغي تعميم ذلك على كل خطط GLM-5.2 أو كل الفترات الزمنية من دون مراجعة شروط الخطة الحالية نفسها.

ما الذي تثبته الأدلة بشأن مشكلات الوصول؟

قد تكون التقارير عن نفاد الحصص اليومية، أو تراجع الوصول إلى GLM-5.2، أو قصر مدة الاحتفاظ بالذاكرة المؤقتة، أو ضعف التجميع بين المستخدمين، أو نقص قدرة الاستدلال لدى مزود بعينه، معقولة من الناحية التقنية؛ لكنها ليست جميعاً مثبتة في المواد المتاحة هنا.

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

والاختبار المفيد يجب أن يكون على عبء عمل حقيقي وفي ساعات عمل الفريق: حجم المستودع، وسلوك التخزين المؤقت، وطول المخرجات، وعدد الوكلاء المتوازيين، والانتظار في الطوابير، وسلوك الخطة عند بلوغ الحد—كلها أهم من سعر معلن واحد لكل مليون رمز.

قاعدة الشراء لفرق البرمجة الكثيفة

تظل واجهات LLM الصينية منخفضة التكلفة جذابة للاستدلال الخفيف أو المتوقع، ولا سيما عندما يستطيع سير العمل إعادة استخدام سياق مخزن مؤقتاً. 1 وهي خيار قوي للفرق التي تحتاج تحكماً مباشراً في API وتستطيع إدارة ميزانية الرموز بدقة.

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

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

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