الفصل 14 — اقتصاديات الرموز وتسعير API

تم النشر في: 1447-11-19 آخر تحديث في: 1448-01-23 الإصدار: 1
الفصل 14 — اقتصاديات الرموز وتسعير API

الفصل 14 — اقتصاديات الرموز وتسعير API

المقالة الرابعة عشرة من الجولة الفصلية لـ LLM Primer VI: توسيع أنظمة الذكاء الاصطناعي. الفصل الذي يربط فيزياء الفصل 1 ببنود الفاتورة — ويُوضِّح لماذا فاتورة الشهر الأول في الغالب لا تُشبه ما نمذجه الفريق.


لماذا يوجد هذا الفصل

عاملت الفصول السابقة كلفة الاستدلال كحقيقة فيزيائية — بايتات مُنقولة عبر HBM، وFLOP مُنفَقة في ضرب مصفوفات، وثوانٍ GPU مُستهلَكة من طلب. ذلك التأطير صحيح للفريق الذي يمتلك السيليكون. للفئة الأكبر بكثير من الفرق التي تشتري استدلالاً من API، تُعاد صياغة سطح التكلفة بالوحدة التي يُسعِّرها المزوِّد: الرمز. الفصل 14 حول لماذا يُسعَّر الرمز بالطريقة التي يُسعَّر بها، ولماذا لجانبَي المدخل والمُخرَج من نفس الاستدعاء أسعار مختلفة جداً، وكيف تنتهي بهدوءٍ تاريخ محادثة روبوت الدردشة وتفكير نموذج الاستدلال غير المرئي على الفاتورة.

في سطر واحد: يُسعَّر الرمز لأنه يُخطَّط تقريباً خطياً على الحوسبة التي يُنفقها المزوِّد، لكن رمز المُدخَل ورمز المُخرَج كائنا تكلفة مختلفان، والفريق الذي يُعاملهما كواحد يُفاجَأ.

14.1 المُخرَج يكلف 4–8× المُدخَل لأن فك التشفير هو المرحلة المُقيَّدة بعرض النطاق

رمز المُدخَل يركب مسار التعبئة الأمامية — كثيف، مُقيَّد بالحوسبة، متوازٍ عبر كل مواضع المُوجِّه، يركب بالضبط عبء العمل الذي صُمِّمت GPU له. على نموذج 70B، H100 تلتهم عشرات الآلاف من رموز المُدخَل في الثانية لأن العملية ضرب مصفوفات عريض بكثافة حوسبة عالية. رمز المُخرَج يركب مسار فك التشفير — تسلسلي، مُقيَّد بعرض نطاق الذاكرة، رمز واحد لكل تمرير أمامي، كل خطوة تقرأ كل ذاكرة KV من HBM. نفس H100 تُنتج 50–100 رمز مُخرَج في الثانية لكل طلب. النسبة بين الإنتاجيَّتين هي النسبة التي تعكسها ورقة السعر. نماذج الطليعة في 2025 تشحن ديناران إلى خمسة دنانير لكل مليون رمز مُدخَل وعشرة إلى ثلاثين لكل مليون مُخرَج — عدم تماثل 4:1 إلى 8:1 ليس اختيار هامش بل تمرير مباشر لعدم التماثل الحوسبي الأساسي. المُدخَل المُخزَّن أرخص لأن المزوِّد دفع كلفة التعبئة الأمامية على طلب سابق. واجهات API الدُّفعية بنصف السعر لأن المزوِّد يستطيع جدولة العمل في نوافذ سعة عاطلة. رموز الاستدلال هي رموز مُخرَج لأنها كذلك داخل المحرك.

14.2 رافعة التحسين تعتمد على شكل المدخل/المُخرَج

الخطأ نمذجة التكلفة برقم عقلي واحد — «الرموز تكلف س» — بدل تحليل المدخل والمُخرَج بشكل منفصل. عميلٌ لخدمة العملاء الفارزة كثيفة الاسترجاع يُرسل 8,500 رمز مُدخَل ويحصل على استجابة 600 رمز، تُهيمن عليه كلفة المُدخَل بأسعار الطليعة (نحو 255$ مُدخَل مقابل 90$ مُخرَج لكل 10,000 طلب يومياً). نظامُ صياغة طويلة على نفس الحجم — 2,200 رمز مُدخَل داخل، 3,000 رمز مُخرَج خارج — يُهيمن عليه المُخرَج (66$ مُدخَل مقابل 450$ مُخرَج). نصيحة التحسين معاكسة في الحالتَين: قصِّر المُوجِّه للأولى، قصِّر الاستجابة للثانية، ووجِّه إلى نموذج يُفضِّل ملف تسعيره المحور المُهيمن. تحليل ثانٍ يستحق التشغيل هو بحسب المستأجر أو عبء العمل. أنظمة متعدِّدة المستأجرين تُظهر تقريباً دائماً انحرافاً بقانون قوى حيث تحتسب أعلى 10 بالمئة من المستأجرين نصف الإنفاق أو أكثر، وعمل تحسين التكلفة المُستهدَف لأولئك المستأجرين يُسدِّد أضعافاً أكثر من العمل المُوحَّد المُوزَّع عبر الذيل الطويل.

14.3 تراكم السياق ورموز التفكير غير المرئية يُضخِّمان الفاتورة

أكثر الرموز كلفةً هو الذي نسي الفريق أنه يُرسَل. واجهات API عديمة الحالة؛ كل طلب يشحن تاريخ المحادثة الكامل كمُدخَل على كل استدعاء. كلفة المُدخَل التراكمية عبر محادثة من N دور تنمو تربيعياً في N، ناقصاً رصيد التخزين المؤقت للبادئات. فريقٌ سعَّر نظامه على أساس دور واحد يجد، بعد ستة أشهر، أن متوسط محادثته يمتد الآن ثمانية أدوار وتضاعفت كلفة المُدخَل لكل محادثة تقريباً مربَّعاً. المُضخِّم الصامت الثاني هو رموز الاستدلال. نماذج مثل o1/o3، والتفكير المُمتد من Anthropic، وDeepSeek R1، ومُتغيِّرات الاستدلال من Google تُنتج حجماً كبيراً من التفكير الداخلي قبل الإجابة المرئية — غالباً 4,000–8,000 رمز خلف استجابة مرئية بطول 500 رمز. تلك الرموز تركب نفس حلقة فك تشفير المُخرَج وتُفوتَر كمُخرَج؛ ولا تُعاد إلى المستدعي إلا إن طلبها الكود. التخفيف هو ضبط كائن استخدام استجابة API بشكل صحيح — prompt_tokens وcached_prompt_tokens وcompletion_tokens وreasoning_tokens وأي فئات خاصة بالمزوِّد — وتنبيه الفئات المجهولة بدل إسقاطها بصمت. كل بُعد فوترة جديد يُضيفه المزوِّد يجب أن يظهر في مخطَّط استخدام الفريق، وإلا الفاتورة التالية مفاجأة.

يجدر بنا تذكُّره: مخطَّط تسجيل استخدام بـ «رموز مُدخَل» و«رموز مُخرَج» فحسب مخطَّطٌ سيمتصُّ بصمت كل فئة فوترة جديدة يُقدِّمها المزوِّد. سجِّل كل بُعد مُفصَح عنه بشكل منفصل، نبِّه المجاهيل، وأعِد تحليل التكاليف كل ربع سنة.

ما يُمهِّد له الفصل 14

حالما يستطيع الفريق قراءة فاتورته الخاصة بتحليل المدخل مقابل المُخرَج، ولكل مستأجر، ولكل فئة، السؤالُ التالي — الذي سيطرحه القسم المالي — هو ما إذا كان يجب على الفريق الدفع لكل رمز أصلاً. يمشي الفصل 15 على البديل: أَعِد الاستدلال إلى الداخل، استأجر أو اشترِ GPU، وادفع لكل ساعة GPU بدلاً. حسابيات التعادل نظيفة. ما هو أقل نظافة، وما تُقلِّل أغلب الفرق شأنه، هو كل ما على الجانب المخصَّص من دفتر الحسابات ليس على فاتورة GPU: هندسة المنصة، وترقيعات الأمان، وكوريغرافيا ترقية النموذج، ودورة المناوبة التي تُجيب حين تسقط عقدة من الأسطول.


التالي — الفصل 15: واجهات API بلا خادم مقابل البنية التحتية المخصَّصة. صيغة التعادل، والبند المخفي، ومواقف هجينة حيث كلاهما هو الإجابة الصحيحة.

هل تريد الصورة الكاملة؟ يشمل فصل الكتاب فئتَي البيانات TokenPricing وUsageRecord القابلتَين للتشغيل، ودالة كلفة المحادثة التراكمية التي تُكمِّم التربيع، والمثال المشروح للتكلفة اليومية «للوكيل الذي نما»، وحواشي «بلغة بسيطة» عن لماذا يكلف المُخرَج أكثر وكيف يعمل العدَّاد حين لا يراقبه أحد. اطّلع على LLM Primer VI على أمازون ←

SHO
SHO
مدير التكنولوجيا والمؤسس لشركة RECEIPTROLLER. يركز على البيانات، مدفوع بالابتكار، دائم الفضول.