صيغ توفير التكاليف ونقاط التحول في الترميز حسب الإحساس

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

يمكن تلخيص أنماط فوترة أدوات الترميز بالذكاء الاصطناعي إلى ثلاثة أنواع:

  1. الفوترة حسب الرمز (Token): تشمل جميع واجهات برمجة التطبيقات، Claude Code (Claude Pro)، Codex Cli (ChatGPT Plus)، Zhipu Lite/Pro، و Cursor الإصدار الجديد. جوهرها جميعاً فوترة حسب الرمز، وتقدم بعض المنتجات خصومات على الباقات.
  2. الفوترة حسب عدد استدعاءات API: مثل OpenRouter (الحد المجاني)، ModelScope، Gemini Code Assistant (1000 استدعاء مجاني يومياً)، Chutes وغيرها.
  3. الفوترة حسب عدد المطالبات (Prompts): مثل Cursor الإصدار القديم (500 مرة)، Github Copilot (300 مرة) وغيرها.

هذه الأنماط الثلاثة جوهرها جميعاً الدفع لاستنتاج النموذج ومعالجة السياق، والاختلاف يكمن في دقة التقييم وشكل الحدود.

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

دالة التكلفة الإجمالية الموحدة

لأي أداة i، يمكن كتابة التكلفة الإجمالية في دورة فوترة واحدة كالتالي:

Totali=Cashi+Timei+RiskiTimei=R⋅HoursiRiski=R⋅ReworkHoursi\begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \\ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \\ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned}

حيث R هو سعر وقتك (بال yuan/ساعة). إذا كنت لا تريد تضمين الوقت، يمكنك تعيين R = 0، وتنخفض الصيغة إلى مقارنة التكلفة النقدية البحتة.

اتفاقية المتغيرات

لتوحيد أنماط الفوترة الثلاثة، يتم تقسيم حمل العمل إلى مستويين: “الجلسة (session)” و"التكرار (iteration)". يعتبر الفحص والفهرسة عند دخول مشروع جديد عملية لمرة واحدة، والحوار المستمر وتعديل الكود ضمن نفس السياق عملية قابلة للتكرار.

نعرف المتغيرات:

  • S_i: التكلفة الثابتة للأداة i (رسوم الاشتراك أو الحد الأدنى الشهري للاستهلاك)
  • N_s: عدد الجلسات الجديدة في هذه الدورة (تغيير المشروع، مسح السياق، فتح جلسة جديدة كلها تحسب)
  • N_{it}: عدد التكرارات الفعالة في هذه الدورة (توضيح المتطلبات، تعديل الكود، إصلاح الأخطاء إلخ)
  • R: سعر الوقت (yuan/ساعة)
  • h0_i: وقت بدء التشغيل البارد لكل جلسة جديدة (ساعات)
  • h1_i: متوسط وقت كل تكرار (ساعات)
  • p_{\mathrm{fail},i}: احتمال فشل كل تكرار يحتاج لإعادة عمل (من 0 إلى 1)
  • h_{\mathrm{re},i}: متوسط وقت إعادة العمل الواحدة (ساعات)

إذن يمكن كتابة عنصري الوقت والمخاطرة كالتالي:

Hoursi=Ns⋅h0i+Nit⋅h1iReworkHoursi=Nit⋅pfail,i⋅hre,i\begin{aligned} \mathrm{Hours}_i &= N_s \cdot h0_i + N_{it} \cdot h1_i \\ \mathrm{ReworkHours}_i &= N_{it} \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i} \end{aligned}

بعد ذلك نحتاج فقط لكتابة Cash_i للأنماط الثلاثة للفوترة.

التكلفة النقدية للفوترة حسب الرمز (Token)

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

نعرف المتغيرات:

  • Tin0_i: إجمالي رموز الإدخال لكل جلسة جديدة
  • r0_i \in [0,1]: نسبة ضربات ذاكرة الإدخال المؤقتة في الجلسة الجديدة
  • Tin1_i: إجمالي رموز الإدخال لكل تكرار
  • r1_i \in [0,1]: نسبة ضربات ذاكرة الإدخال المؤقتة في التكرار
  • Tout0_i, Tout1_i: كمية رموز الإخراج
  • Pin_i, Pcache_i, Pout_i: معلمات الأسعار (yuan/مليون رمز)

يمكن للأدوات التي لا تدعم تسعير الذاكرة المؤقتة تعيين r0_i=r1_i=0 أو Pcache_i=Pin_i.

إذن:

Cashi(token)=Si+1106[Ns⋅(Pini⋅(1−r0i)⋅Tin0i+Pcachei⋅r0i⋅Tin0i+Pouti⋅Tout0i)+Nit⋅(Pini⋅(1−r1i)⋅Tin1i+Pcachei⋅r1i⋅Tin1i+Pouti⋅Tout1i)]\begin{aligned} \mathrm{Cash}^{(\mathrm{token})}_i &= S_i + \frac{1}{10^6}\Bigl[ N_s \cdot \bigl(Pin_i \cdot (1-r0_i)\cdot Tin0_i + Pcache_i \cdot r0_i\cdot Tin0_i + Pout_i \cdot Tout0_i\bigr) \\ &\qquad + N_{it} \cdot \bigl(Pin_i \cdot (1-r1_i)\cdot Tin1_i + Pcache_i \cdot r1_i\cdot Tin1_i + Pout_i \cdot Tout1_i\bigr) \Bigr] \end{aligned}

هذه المعادلة تفسر مباشرةً نتيجة تجريبية: في نفس الجلسة، العمل بشكل غاطس ومتواصل، N_{it} يزيد لكن Tin0_i يدفع مرة واحدة فقط، متوسط تكلفة كل تكرار ينخفض. التبديل المتكرر بين المشاريع أو مسح السياق بشكل متكرر يجعل Tin0_i يدفع مراراً.

التكلفة النقدية للفوترة حسب استدعاءات API

المفتاح في فوترة استدعاءات API هو أن “الاستدعاء الواحد” يشمل الحوار، استدعاء الأدوات، قراءة الملفات، البحث، تنفيذ الأوامر إلخ. يجب تقدير:

  • A0_i: عدد استدعاءات API لكل جلسة جديدة
  • A1_i: عدد استدعاءات API لكل تكرار
  • Ccall_i: سعر كل استدعاء (yuan/مرة)

صيغة التكلفة النقدية:

Cashi(call)=Si+Ccalli⋅(Ns⋅A0i+Nit⋅A1i)\mathrm{Cash}^{(\mathrm{call})}_i = S_i + Ccall_i \cdot (N_s \cdot A0_i + N_{it} \cdot A1_i)

إذا كانت الأداة تقدم حداً مجانياً Q(مرات/دورة) ويجب الانتظار بعد تجاوزه بدلاً من الدفع، يمكن إضافة وقت الانتظار إلى تكلفة الوقت، وتحويل الاستدعاءات الزائدة إلى Hours_i، والاستمرار في استخدام Total_i للمقارنة.

التكلفة النقدية للفوترة حسب عدد المطالبات (Prompts)

فوترة المطالبات تعادل “المطالبة الواحدة” بتقديم مهمة واحدة. يجب تقدير:

  • P0_i: عدد المطالبات لكل جلسة جديدة
  • P1_i: عدد المطالبات لكل تكرار
  • Cprompt_i: سعر كل مطالبة (yuan/مرة)

صيغة التكلفة النقدية:

Cashi(prompt)=Si+Cprompti⋅(Ns⋅P0i+Nit⋅P1i)\mathrm{Cash}^{(\mathrm{prompt})}_i = S_i + Cprompt_i \cdot (N_s \cdot P0_i + N_{it} \cdot P1_i)

للمنتجات “الشهرية تشمل N مرات”، يمكن استخدام السعر الظلي (shadow price) تقريباً: لنفترض أن رسوم الاشتراك الدوري هي S_i، والحصة هي Q_i، إذن Cprompt_i \approx S_i / Q_i. رغم أنه ليس هامشياً نقدياً صارماً، لكنه يحول “ندرة الحصة” إلى تكلفة فرصة قابلة للحساب.

نقطة التحول: صيغة خط التقسيم بين أداتين

نكتب المعادلة أعلاه بشكل موحد. للأداة i:

Totali=Si+Ns⋅(c0i+R⋅h0i)+Nit⋅(c1i+R⋅h1i+R⋅pfail,i⋅hre,i)\mathrm{Total}_i = S_i + N_s \cdot (c0_i + R \cdot h0_i) + N_{it} \cdot (c1_i + R \cdot h1_i + R \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i})

حيث c0_i، c1_i تمثلان التكلفة النقدية للبدء البارد والتكرار الواحد، على التوالي، وتتوافقان مع التوسيعات المختلفة في الأنماط الثلاثة للفوترة.

مع أداتين A و B، عند ثبات N_s، لجعل Total_A = Total_B، يمكن حل عدد التكرارات عند نقطة التحول:

Nit∗=(SB−SA)+Ns⋅((c0B−c0A)+R⋅(h0B−h0A))(c1A−c1B)+R⋅(h1A−h1B)+R⋅(pfail,A⋅hre,A−pfail,B⋅hre,B)N_{it}^{\ast} = \frac{ (S_B - S_A) + N_s \cdot \bigl((c0_B - c0_A) + R \cdot (h0_B - h0_A)\bigr) }{ (c1_A - c1_B) + R \cdot (h1_A - h1_B) + R \cdot \bigl(p_{\mathrm{fail},A} \cdot h_{\mathrm{re},A} - p_{\mathrm{fail},B} \cdot h_{\mathrm{re},B}\bigr) }

التفسير:

عندما يكون المقام موجباً، إذا كان N_{it} > N_{it}^{\ast} فإن A أوفر، وإذا كان N_{it} < N_{it}^{\ast} فإن B أوفر. عندما يكون المقام سالباً، ينعكس اتجاه عدم المساواة. عندما يكون المقام قريباً من 0، يعني أن التكلفة الحدية المجمعة لكل تكرار متشابهة تقريباً، ويعتمد الاختيار أساساً على التكلفة الثابتة وتكلفة البدء البارد.

يمكنك استخدام هذه الصيغة لحساب ثلاثة نقاط تحول نموذجية، وهي: أداة فوترة الرموز مقابل أداة فوترة المطالبات، أداة فوترة الرموز مقابل أداة فوترة استدعاءات API، وأداة فوترة استدعاءات API مقابل أداة فوترة المطالبات. ما عليك سوى توسيع c0, c1 الخاصة بكل منها إلى الرموز، أو عدد الاستدعاءات، أو عدد المطالبات.

إستراتيجية عملية: طرق عملية لتقليل التكاليف

1. التطوير الغاطس: إستراتيجية تحسين فوترة الرموز

للأدوات التي تتبع فوترة الرموز (مثل Codex Cli)، الإستراتيجية الأساسية هي الحفاظ على استقرار سياق العمل.

المبدأ: تجنب دفع Tin0_i مراراً. العمل المستمر في نفس المشروع يوزع تكلفة تحميل السياق الأولي، كما أن ارتفاع نسبة ضربات الذاكرة المؤقتة يسرع الاستجابة بشكل كبير.

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

2. دمج المتطلبات: إستراتيجية تحسين فوترة استدعاءات API

للأدوات التي تتبع فوترة الاستدعاءات (مثل Gemini Code Assistant)، الإستراتيجية الأساسية هي الاستفادة القصوى من استدعاءات “إنشاء السياق”.

المبدأ: توزيع تكلفة A0_i. عمليات استدعاء الأدوات، قراءة الملفات إلخ كلها تحسب في عدد الاستدعاءات.

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

3. معالجة المهام الكبيرة: إستراتيجية تحسين فوترة المطالبات

للأدوات التي تتبع فوترة المطالبات (مثل Cursor الإصدار القديم)، فهي مناسبة للمهام الكبيرة أو الصيانة الباردة.

المبدأ: تأمين التكلفة الحدية. بغض النظر عن طول السياق، تكلفة المطالبة الواحدة ثابتة.

التطبيق: “المهمة الكبيرة” تعني استهلاك رموز ضخم (قراءة ملفات كثيرة، سياق طويل جداً) ولكن إخراج محدود، أو تحتاج لنموذج عالي الجودة للتحكم. مثل هذه المهام تستخدم أدوات الفوترة حسب المرات بأعلى كفاءة تكلفة. المهام الصغيرة باستخدام أدوات الفوترة حسب المرات تكون كفاءة التكلفة منخفضة.

عملية اختيار قابلة للحساب

يُظهر مخطط التدفق التالي تعيين المتغيرات إلى منطق الاختيار. بعد تقدير حجم N_s و N_{it}، استخدم صيغة نقطة التحلم للمقارنة لتحديد الحل الأمثل.

flowchart TD
    A[تحديد حمل العمل لهذه الدورة] --> B[تقدير N_s: عدد الجلسات الجديدة]
    B --> C[تقدير N_it: عدد التكرارات لكل جلسة]
    C --> D[تقدير c0, c1 لكل نوع أدوات]
    D --> E[تعويض في صيغة N_it*]
    E --> F{الشكل الرئيسي للحمل?}
    F -->|N_s كبير, N_it صغير| G[الأولوية: فوترة المطالبات أو استدعاءات API]
    F -->|N_s صغير, N_it كبير| H[الأولوية: فوترة الرموز]
    F -->|كلاهما كبير| I[تقسيم سير العمل: البدء البارد بالمطالبات/الاستدعاءات، المرحلة المتعمقة بالرموز]

    classDef in fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef calc fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef decide fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef out fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A,B,C in
    class D,E calc
    class F decide
    class G,H,I out