التكلفة والزمن — فاتورتك بتتحسب إزاي

فكّر في كل رسالة كإنها تاكسي بالعدّاد: بيحسب على المسافة (tokens) واللي بتضيفه في السياق بيكبّر العدّاد كل مرة.

زي الرومينج بالميجابايت وإنت مسافر: كل حاجة بتبعتها وتستقبلها بتتحسب، وكل ما تسيب الشات «شغّال» بيرجّع نفس السياق كل دور، كإنك بتعيد تحميل نفس الصورة كل شوية.

شات بيبعت كل تاريخ المحادثة مع كل رسالة، فبتدفع على نفس الكلام القديم مرة ورا مرة والفاتورة بتتراكم مع طول الجلسة؛ تلخيص الأدوار القديمة بيقصّ التكلفة من غير ما يكسر التجربة.

المعادلة الأساسية: التكلفة = (tokens داخلة × سعر الإدخال) + (tokens خارجة × سعر الإخراج) — والإخراج غالبًا أغلى من الإدخال بـ 3–5 مرات. الأسعار بتتقال «لكل مليون token»، والفاتورة الحقيقية بتيجي من الضرب في عدد النداءات. الزمن بينقسم لجزئين: وقت لأول token (معالجة مدخلاتك)، وبعدين توليد token-بـtoken — فطول الردّ هو المتحكم الأول في الزمن الكلي. وفيه سلاحين أساسيين: streaming بيعرض الرد أثناء توليده فالمستخدم بيحسّ بسرعة أكبر بكتير من غير ما الزمن الفعلي يتغيّر، وprompt caching بيخصم نسبة كبيرة من تمن الأجزاء المتكررة (زي رسالة system طويلة بتتبعت في كل نداء).

حسبة سريعة بتوريك ليه الشات الطويل بيغلى: التاريخ بيتبعت تاني كل دور، فالإدخال بيتراكم شبه تربيعي مع عدد الأدوار:

const IN = 0.15 / 1e6, OUT = 0.60 / 1e6;   // $/token (موديل صغير)
const system = 500, perTurn = 200, reply = 300;

let history = 0, bill = 0;
for (let turn = 1; turn <= 10; turn++) {
  const input = system + history + perTurn; // التاريخ كله بيتبعت تاني
  bill += input * IN + reply * OUT;
  history += perTurn + reply;
}
console.log(bill.toFixed(4)); // جرّب 10 أدوار ضد 50 وشوف القفزة

🧪 جرّب بنفسك — احسب تكلفة محادثة ١٠ أدوار: خد أسعار موديل حقيقي من صفحة التسعير بتاعة المزوّد، وافترض: رسالة system بـ 500 token، كل رسالة مستخدم 200، وكل رد 300. احسب بإيدك (أو بالكود اللي فوق) تكلفة كل دور من العشرة والإجمالي — لاحظ إن الدور العاشر أغلى من الأول بكتير رغم إن الرسالة نفس الطول. بعدين أعد الحسبة بافتراض إنك بتلخّص التاريخ الأقدم من 4 أدوار في 150 token، وقارن الوفر. اضرب الفرق في 100,000 مستخدم شهريًا — الرقم ده هو اللي بيتقال في اجتماع الميزانية.

• اختبار التكلفة بمحادثات قصيرة والصدمة في production. التاريخ المتراكم بيخلّي تكلفة الرسالة الأخيرة في جلسة طويلة أضعاف الأولى — اعمل الحسبة على جلسة 20 دور مش دورين.
• تجاهل إن الإخراج أغلى. ردود ثرثارة من غير داعي بتضرب في أغلى بند في الفاتورة — حدّ الطول بالتعليمات وmax_tokens.
• الإطلاق من غير عدّادات. لازم تسجّل tokens لكل نداء من أول يوم — أول خبر عن مشكلة التكلفة المفروض ييجي من dashboard عندك، مش من فاتورة آخر الشهر.

اعمل حسبة التكلفة والزمن قبل ما تعتمد أي feature فيها LLM: (tokens متوقعة لكل استخدام) × (استخدامات متوقعة شهريًا) × (السعر). لو الرقم مقلق، عندك أدوات بالترتيب: قصّر السياق، لخّص التاريخ، نزّل موديل أصغر للأجزاء البسيطة، فعّل caching. وفعّل streaming في أي واجهة تفاعلية — أرخص تحسين إحساس بالسرعة موجود.

متخليش هوس التكلفة يقود قبل ما يبقى فيه حاجة شغّالة: في الـ prototype، جودة النتيجة هي السؤال الوحيد. وفي الحجم الصغير (مئات النداءات يوميًا) فرق السنتات مش مستاهل تعقيد caching وrouting — ساعة مهندس أغلى من فاتورة الشهر كله. حسّن لما الأرقام تقول فيه حاجة تتحسّن.