قامت Novita مؤخرًا بتحديث أسعار نماذج اللغة الكبيرة (LLM) الخاصة بها. بالنسبة للفرق التي تقوم بتشغيل عمليات الاستدلال (inference) في بيئة الإنتاج عبر المنصة، يجب أن تستدعي هذه الجملة إجراء مراجعة فورية لنفقاتكم الحالية. نادرًا ما تأتي تغييرات أسعار واجهة برمجة التطبيقات (API) في وقت مناسب، وعندما تشمل مستويات متعددة من النماذج، يمكن أن يكون تأثيرها على معدل الإنفاق الشهري أقوى مما هو متوقع.

لماذا تستحق أسعار الاستدلال اهتمامكم

معظم تطبيقات الذكاء الاصطناعي الحديثة لا تُبنى على مجموعات GPU مدارة ذاتيًا. يقوم المطورون بتوجيه الطلبات إلى مزودي خدمات الاستدلال مثل Novita لأن البديل يتضمن تأمين الأجهزة، وإدارة عمليات نشر vLLM أو TGI، والتعامل مع حالات البداية الباردة (cold starts) أثناء طفرات حركة المرور. هذه الراحة قيمة، لكنها تخضع للمحاسبة أيضًا؛ فكل رمز (token) يتم إنشاؤه يضاف إلى فاتورة تتراكم عبر جلسات المستخدمين، والمهام الخلفية، والأدوات الداخلية.

عندما يقوم المزود بتعديل أسعاره، يتسلسل التأثير عبر بنيتكم التقنية (stack). فقد يستهلك روبوت دردشة يتعامل مع عشرة آلاف محادثة عملاء يوميًا أربعين مليون رمز إدخال واثني عشر مليون رمز إخراج في الأسبوع. إذا تغير سعر المليون رمز بمقدار بضعة دولارات فقط، فإن الفرق الشهري سيصبح ملموسًا بسرعة. بالنسبة للمنتجات ذات التمويل الذاتي أو الفرق التي تعمل بهوامش ربح ضئيلة، يمكن لهذا الفارق أن يمحو الربحية. سواء كان مساعد برمجة يعمل كإضافة للمتصفح، أو خط معالجة لتلخيص الدفعات (batch summarization pipeline) يعمل طوال الليل، أو أداة بحث داخلية تستعلم من نموذج عند كل تحميل للصفحة، فجميعها تشترك في نفس نقطة الضعف؛ حيث تعتمد اقتصاديات الوحدة (unit economics) الخاصة بها على السعر الدقيق للرمز التالي.

ما الذي تغير في Novita

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

إذا كان تطبيقك يوجه جميع حركة المرور عبر نموذج لغة كبير واحد، فإن حساباتك بسيطة؛ قارن السعر القديم بالجديد وتوقع الخسائر أو المدخرات. لكن معظم إعدادات الإنتاج أكثر تعقيدًا. غالبًا ما تحتفظ الفرق بمنطق توجيه (routing logic) يرسل الاستعلامات البسيطة إلى نماذج أخف ويحتفظ بالنماذج الضخمة لمهام الاستدلال المعقدة. بينما يقوم آخرون بإجراء اختبارات A/B عبر عدة نماذج لمقارنة زمن الاستجابة (latency) والجودة. في هذه السيناريوهات، يمكن لتغير السعر في نموذج أو اثنين فقط أن يشوه هيكل التكاليف بالكامل.

الأرقام المحددة لكل رمز ولكل طلب موضحة في تحليل مفصل نشره Narevbot على Dev.to. يمكنك مراجعة قائمة الأسعار الدقيقة هنا: https://dev.to/narevbot/changes-to-llm-pricing-novita-3plc

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

كيف تراجع حجم تعرضك للمخاطر

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

ابحث عن هذه الأنماط:

  • مخاطر التركز. إذا كان 70% من إنفاقك يمر عبر نموذج واحد وشهد هذا النموذج زيادة في السعر، فإن ضرورة التحرك تصبح واضحة. أما إذا كان إنفاقك مشتتًا عبر ثمانية نماذج وتغيرت أسعار ثلاثة منها، فستستغرق الحسابات وقتًا أطول، لكن المخاطرة لا تزال قائمة.
  • تضخم الرموز (Token bloat). تحقق مما إذا كانت مطالباتك (prompts) تتضخم بسياق غير ضروري. فالمطالبات النظامية الطويلة، وأمثلة few-shot المتكررة، وتنسيق XML المطول، كلها تزيد من تكاليف الإدخال. يعد تحديث الأسعار عذرًا مثاليًا لتقليص هذه الزيادات غير الضرورية.
  • عدم كفاءة المخرجات. إذا كان تطبيقك يطلب إكمالات طويلة ولكنه يستخدم الجمل القليلة الأولى فقط، فأنت تدفع مقابل رموز تتخلص منها. قم بضبط حدود max_token وتسلسلات التوقف (stop sequences).
  • المهام الخلفية الخاملة. قد تكون المهمة المجدولة التي تنشئ تقارير أو تقوم بتضمين المستندات (embeddings) تعمل بشكل متكرر أكثر مما هو مطلوب. تحقق من جدول cron وحجم الدفعة (batch size).