ملاحظة الكاتب: يشرح هذا المقال بنود فواتير واجهات API لنماذج اللغة الكبيرة، من رموز الإدخال والإخراج والتخزين المؤقت والاستدلال إلى رسوم المحتوى متعدد الوسائط، ويقدّم طرقًا عملية لمراجعة الاستخدام عبر سجلات الاستدعاء، واكتشاف «الارتفاع المفاجئ في التكلفة»، والتعامل مع تغيّرات الأسعار.
تفتح الفاتورة في نهاية الشهر، فتجد أن تكلفة أحد النماذج ارتفعت عن الشهر الماضي، رغم أن عدد الاستدعاءات لم يتغير تقريبًا. هذا موقف مألوف لكثير من الفرق التي تستخدم واجهات API لنماذج اللغة الكبيرة في بيئة الإنتاج. يقدّم هذا المقال طريقة تقوم على تفصيل بنود الفوترة ومطابقتها مع سجلات الاستدعاء، لتساعدك على فهم فاتورة API ومراجعتها.
هذا المقال ليس ملخصًا للأسعار. أسعار المزوّدين تتغير باستمرار، لذلك لن نذكر أسعارًا محددة، بل سنركز على أسس الفوترة وطرق مراجعتها التي تظل مفيدة على المدى الطويل.
ومن المؤشرات الجديرة بالاهتمام أن شركة متخصصة في البنية التحتية للذكاء الاصطناعي كانت توظّف لشغل منصب تشغيل منصة لنماذج اللغة الكبيرة في نوفمبر 2026. وذُكر صراحةً ضمن مسؤوليات الوظيفة «التحقق من التكاليف والفوترة»، بما يشمل مراجعة أسس احتساب رموز الإدخال والإخراج والتخزين المؤقت والاستدلال، وكذلك رسوم الصور والصوت والفيديو، مع اكتشاف الفواتير غير المعتادة وتغيّرات الأسعار والفروقات في الفوترة في الوقت المناسب. حاجة المنصة إلى شخص متخصص في هذه المهمة تدل على مدى تعقيد الفوترة نفسها. وبصفتك مستخدمًا لواجهة API، تحتاج أنت أيضًا إلى اتباع طريقة منتظمة لمراجعة فواتيرك.
ما الذي ستستفيده؟ بعد قراءة المقال، ستتمكن من تمييز مصادر بنود فاتورة API لنماذج اللغة الكبيرة، ومراجعة الاستخدام عبر سجلات الاستدعاء، وتحديد أسباب «الارتفاع المفاجئ في تكلفة الطلب نفسه» بسرعة.
أهم ما يجب معرفته عن فاتورة API لنموذج اللغة الكبير: 5 بنود للفوترة
تكلفة استدعاء النموذج ليست عادةً مجرد «عدد الاستدعاءات × سعر الوحدة». فلكل بند مصدره وسعره، والنظر إلى البنود مجتمعة قد يؤدي بسهولة إلى فهم خاطئ لتركيبة التكلفة.
| بند الفوترة | مصدره | طريقة التسعير الشائعة | ما ينبغي مراقبته عند مراجعة الفاتورة |
|---|---|---|---|
| رموز الإدخال (Token) | موجه النظام، وسجل المحادثة، وتعريفات الأدوات، والمستندات المسترجعة، ومدخلات المستخدم | تُحسب حسب عدد الرموز، وعادةً ما تكون أرخص من رموز الإخراج | هل يزداد طول السياق تدريجيًا دون ملاحظة؟ |
| رموز الإخراج (Token) | الرد المرئي الذي يولّده النموذج | تُحسب حسب عدد الرموز، وسعرها عادةً أعلى من سعر الإدخال | طول الرد وإعداد max_tokens |
| رموز الذاكرة المؤقتة (Token) | بادئة الإدخال التي عُثر عليها في الذاكرة المؤقتة | غالبًا ما يُطبق خصم على الجزء المسترجع، ويفرض بعض المزوّدين سعرًا منفصلًا للكتابة | هل ينخفض معدل الاستفادة من الذاكرة المؤقتة؟ |
| رموز الاستدلال (Token) | عملية التفكير الداخلية لنموذج الاستدلال | تُحسب عادةً بسعر الإخراج، لكنها لا تظهر بالضرورة في الرد | هل يزداد طول عملية الاستدلال؟ |
| الفوترة متعددة الوسائط | إدخال الصور والصوت والفيديو أو توليدها | حسب عدد الصور أو الثواني أو الدقة، أو بتحويلها إلى رموز | هل تغيّرت إعدادات المواصفات؟ |
لماذا يصعب أحيانًا مطابقة فاتورة API لنموذج اللغة الكبير؟
السبب الأول هو الرموز غير المرئية. قد تكتب في الشفرة سؤالًا واحدًا من المستخدم، لكن الطلب المرسل فعليًا قد يتضمن آلاف الرموز من موجه النظام، وسجل محادثة متعدد الجولات، ومخطط الأدوات (Schema). وقد يولّد نموذج الاستدلال أيضًا عددًا كبيرًا من رموز التفكير التي لا يراها المستخدم. تُحتسب كل هذه الرموز في الفاتورة، رغم أنها لا تظهر في الواجهة.
السبب الثاني هو اختلاف أسس القياس. ففي حالة «إدخال الصور» مثلًا، يحاسب بعض المزوّدين حسب عدد الصور، بينما يحوّل آخرون الدقة إلى رموز. وكذلك «التخزين المؤقت»: يفعّله بعض المزوّدين تلقائيًا، ويشترط آخرون تحديده صراحةً؛ ويقدّم بعضهم خصمًا على القراءة فقط، بينما يفرض آخرون رسومًا إضافية على الكتابة. لذلك، عند المقارنة بين النماذج والمزوّدين، يجب أولًا توحيد أساس المقارنة.
السبب الثالث هو تغيّر المتغيرات بمرور الوقت. فقد يشير الاسم المستعار للنموذج إلى إصدار جديد، وقد يؤدي تعديل صغير في بادئة الموجه إلى فقدان الاستفادة من الذاكرة المؤقتة بالكامل، كما قد يستغرق نموذج الاستدلال وقتًا أطول في التفكير عند مواجهة أسئلة أصعب. وهكذا قد تتغير الفاتورة حتى لو بقي سعر الوحدة ثابتًا.
شرح بنود فوترة واجهات API لنماذج اللغة الكبيرة
رموز الإدخال: الجزء الذي يُستهان بتكلفته غالبًا
تشمل رموز الإدخال (Tokens) كل ما «يقرأه» النموذج في الطلب، وليس رسالة المستخدم وحدها. في المحادثات متعددة الجولات، يُعاد إرسال سجل المحادثة السابق في كل جولة. وكلما طالت المحادثة، ارتفعت تكلفة الإدخال لكل جولة، واقتربت التكلفة الإجمالية من النمو بمربع عدد الجولات.
تستهلك تطبيقات التوليد المعزز بالاسترجاع (RAG) أيضًا قدرًا كبيرًا من رموز الإدخال. ويحدد عدد مقاطع المستندات المسترجعة وطول كل منها تكلفة الإدخال مباشرة. وعند استخدام استدعاء الدوال (Function Calling)، يُحتسب مخطط JSON Schema الخاص بتعريف الأدوات ضمن المدخلات في كل طلب؛ وكلما زاد عدد الأدوات، زادت التكلفة الثابتة.
انتبه أيضًا إلى أن مُجزِّئات النص تختلف من نموذج إلى آخر. فقد يختلف عدد الرموز في النص الصيني نفسه اختلافًا ملحوظًا بين نموذجين، لذلك لا يصح تقدير تكلفة أحدهما بناءً على عدد الرموز في الآخر.
رموز الإخراج: سعر أعلى تتحكم فيه المعلمات مباشرةً
رموز الإخراج (Token) هي محتوى الرد الذي يولّده النموذج. لدى معظم المزوّدين، يكون سعر رمز الإخراج أعلى بوضوح من سعر رمز الإدخال، لذا فإن «جعل النموذج أقل إسهابًا» غالبًا ما يوفّر أكثر من ضغط الإدخال.
تحدد max_tokens الحد الأقصى لتكلفة الإخراج، لكنها لا تضمن اكتمال الرد. إذا قُطع الرد، تظل الأجزاء التي وُلّدت خاضعة للفوترة. وعند انقطاع البث في منتصف الإخراج، قد تختلف طريقة احتساب الرموز المولّدة بين المنصات، لذا يُرجى الرجوع إلى التوضيحات الرسمية.
رموز التخزين المؤقت: التوفير مشروط بتحقق المطابقة
تقوم فكرة التخزين المؤقت للموجهات على أنه عندما تشترك طلبات متعددة في بادئة متطابقة، مثل موجه النظام نفسه أو مستند طويل مشترك، يمكن للمزوّد إعادة استخدام الجزء الذي سبق أن عالجه وتقديم خصم على هذا الجزء من الإدخال.
هناك عدة قواعد شائعة للتخزين المؤقت ينبغي التحقق منها واحدةً تلو الأخرى:
- هل يُفعّل تلقائيًا؟ يفعّله بعض المزوّدين افتراضيًا، بينما يتطلب آخرون تحديد موضع التخزين المؤقت صراحةً في الطلب؛
- متطلبات تطابق البادئة: يُشترط عادةً التطابق حرفيًا من البداية، وأي تغيير في البادئة يؤدي إلى فقدان التطابق لكل ما يلي موضع التغيير؛
- الحد الأدنى للطول ومدة الصلاحية: قد لا تُخزّن البادئات القصيرة جدًا مؤقتًا، وبعد انتهاء الصلاحية يلزم كتابتها مجددًا؛
- هل الكتابة مدفوعة؟ يفرض بعض المزوّدين على الكتابة الأولى في الذاكرة المؤقتة سعرًا أعلى من سعر الإدخال العادي، ولا تصبح التكلفة أقل إلا عند القراءة اللاحقة.
عند مراجعة الفواتير، احسب «رموز القراءة من الذاكرة المؤقتة» و«رموز الإدخال العادي» كلًا على حدة، حتى لا تفسّر انخفاض معدل المطابقة خطأً على أنه زيادة في عدد الاستدعاءات.
رموز الاستدلال: لا تراها، لكنك تدفع ثمنها
تجري نماذج الاستدلال تفكيرًا داخليًا قبل تقديم الإجابة، وتُحتسب رموز هذه العملية عادةً بسعر رموز المخرجات. في كثير من الحالات، لا يُعرض لك محتوى الاستدلال كاملًا، ولا يمكنك معرفة عدد رموزه إلا من حقول الاستخدام.
يتغير عدد رموز الاستدلال بحسب صعوبة السؤال ومستوى الاستدلال المحدد. حتى عند استخدام الواجهة نفسها، قد ترتفع الفاتورة إذا أصبحت أسئلة المستخدمين أكثر صعوبة. وإذا كان عملك يتطلب مجرد تصنيف بسيط أو تحويل للتنسيق، فإن استخدام نموذج استدلال يعني غالبًا الدفع مقابل تفكير لا تحتاج إليه.
فوترة الوسائط المتعددة: تأكد أولًا من أساس الحساب
تختلف طرق فوترة الوسائط المتعددة اختلافًا كبيرًا، لذا من المهم مراجعة صفحة الأسعار الرسمية لكل نموذج على حدة. يعرض الجدول التالي طرق التسعير الشائعة، لكن القواعد الفعلية تخضع لما يعلنه كل مزود حاليًا.
| النوع | طريقة التسعير الشائعة | أهم العوامل المؤثرة في التكلفة | توصية للتحقق |
|---|---|---|---|
| إدخال الصور (الفهم) | تحويل الدقة إلى رموز، أو التسعير لكل صورة | أبعاد الصورة، وإعداد مستوى التفاصيل | تسجيل الدقة الفعلية قبل الرفع وبعده |
| توليد الصور | التسعير لكل صورة، أو حسب رموز المخرجات | الأبعاد، ومستوى الجودة، وعدد الصور المُولّدة | تسجيل إعدادات كل طلب |
| إدخال الصوت وإخراجه | التسعير حسب المدة، أو تحويل الصوت إلى رموز | مدة الصوت، وطريقة معالجة العينات | تسجيل المدة الفعلية للصوت |
| توليف الكلام | التسعير حسب عدد الأحرف أو الرموز | طول النص، ومستوى جودة الصوت | تسجيل طول النص المستخدم للتوليف |
| توليد الفيديو وفهمه | التسعير حسب الثواني أو الإطارات أو مستوى الدقة | المدة، والدقة، ومعدل الإطارات | تسجيل المدة والدقة معًا |
| Embedding | التسعير حسب رموز الإدخال | طول النص، وحجم الدفعة | احتساب التكلفة منفصلة عن سعر الإدخال العادي |
🎯 نصيحة تقنية: من الأفضل استخدام نقطة دخول موحّدة لتطبيقات الوسائط المتعددة، لتسهيل إدارة طرق الفوترة المختلفة في مكان واحد. يشير التعريف الرسمي لـ APIYI على apiyi.com إلى أن نماذج المنصة تستخدم رصيدًا موحّدًا، وأن المنصة توفر إحصاءات الاستخدام وسجلات الاستدعاءات. يمكنك أولًا التحقق من الحقول المعروضة في السجلات عبر لوحة التحكم، ثم تحديد المعلمات الإضافية التي تحتاج إلى تسجيلها في جدول مطابقة الفواتير.
البدء سريعًا بمطابقة فواتير API لنماذج اللغة الكبيرة: 4 خطوات
الفكرة الأساسية لمطابقة الفواتير هي: اضرب الاستخدام الذي سجلته في لقطة الأسعار التي احتفظت بها لحساب التكلفة المتوقعة، ثم قارنها بفاتورة المنصة. إذا تجاوز الفرق النطاق المقبول، فتحقق من البنود واحدًا تلو الآخر.
الخطوة 1: تسجيل حقول الاستخدام بعد كل استدعاء
تعيد واجهات API المتوافقة مع تنسيق OpenAI عادةً كائن usage في الاستجابة. فيما يلي الحقول الشائعة ومعانيها. قد تختلف البيانات التي يعيدها كل نموذج أو منصة، لذا أرسل طلبًا تجريبيًا للتأكد قبل التكامل.
| الحقل (الصيغة الشائعة المتوافقة مع OpenAI) | المعنى | بند الفوترة المقابل |
|---|---|---|
prompt_tokens |
إجمالي رموز الإدخال في الطلب | الإدخال، بما في ذلك الجزء المخزن مؤقتًا |
prompt_tokens_details.cached_tokens |
الجزء من الإدخال الذي استُرجع من ذاكرة التخزين المؤقت | القراءة من ذاكرة التخزين المؤقت |
completion_tokens |
إجمالي رموز الإخراج | الإخراج، وقد يشمل جزء الاستدلال |
completion_tokens_details.reasoning_tokens |
جزء الاستدلال من الإخراج | الاستدلال |
model |
اسم النموذج الذي أعاد الاستجابة فعليًا | لتحديد التغييرات في الإصدار |
يُنصح بحفظ المعلومات التالية على الأقل في قاعدة البيانات بعد كل استدعاء:
- وقت الطلب، ومعرّف الطلب، ومعرّف سيناريو الاستخدام؛
- اسم النموذج المحدد في الطلب وقيمة
modelالمُعادة في الاستجابة؛ - جميع حقول الاستخدام في الجدول أعلاه، مع تسجيل الحقول المفقودة كقيم فارغة بدلًا من 0؛
- معلمات الطلبات متعددة الوسائط، مثل أبعاد الصورة ومدة الصوت وعدد العناصر المطلوب توليدها؛
- ما إذا كان الاستدعاء يستخدم البث، وما إذا أُعيدت المحاولة، وما إذا قُطع الإخراج (
finish_reason).
لاحظ أن prompt_tokens وcompletion_tokens يمثلان غالبًا الإجمالي، بينما يُعد التخزين المؤقت والاستدلال تفاصيل ضمن هذا الإجمالي. عند حساب التكلفة، اطرح هذه التفاصيل من الإجمالي أولًا، ثم اضرب كل جزء في سعره المقابل، حتى لا تحسب التكلفة مرتين أو تفوّت الخصم.
الخطوة 2: الاحتفاظ بسجل أسعار مؤرخ
لا تضع أسعار الوحدات مباشرة في الشفرة. يُنصح بالاحتفاظ بجدول لسجل الأسعار، يسجل كل صف فيه اسم النموذج، وبند الفوترة، وسعر الوحدة، والعملة، وتاريخ السريان، والمصدر (صفحة الأسعار الرسمية أو إعلان المنصة).
عند تغيير الأسعار، أضف صفًا جديدًا بدلًا من استبدال القيم القديمة. بهذه الطريقة، يمكنك إعادة حساب فاتورة أي يوم سابق باستخدام الأسعار السارية آنذاك. وإذا كنت تستدعي النماذج عبر منصة تجميع مثل APIYI، فاعتمد الأسعار التي تعلنها المنصة حاليًا، مع تسجيل تاريخ الاطلاع عليها أيضًا.
الخطوة 3: حساب التكلفة المتوقعة
يمكن تقسيم التكلفة المتوقعة لكل استدعاء إلى عدة بنود وجمعها:
- رموز الإدخال التي لم تُسترجع من ذاكرة التخزين المؤقت × سعر وحدة الإدخال؛
- رموز القراءة من ذاكرة التخزين المؤقت × سعر وحدة القراءة من ذاكرة التخزين المؤقت (مع إضافة تكلفة الكتابة إن كانت تُحتسب بشكل منفصل)؛
- رموز الإخراج المرئية × سعر وحدة الإخراج؛
- رموز الاستدلال × سعر الوحدة المقابل للاستدلال (وهو غالبًا نفس سعر الإخراج، لكن يُرجع إلى التوضيحات الرسمية)؛
- تُحسب الأجزاء متعددة الوسائط بشكل منفصل وفق آلية احتساب كل منها.
بعد تجميع هذه التكاليف حسب اليوم والنموذج وسيناريو العمل، تحصل على سجل يوضح «المبلغ الذي تتوقع إنفاقه».
الخطوة 4: المقارنة مع سجلات المنصة والفواتير
قارن سجلّك الخاص بإحصاءات الاستخدام وسجلات الاستدعاء على المنصة. ابدأ بمقارنة المبلغ الإجمالي، ثم تكلفة كل نموذج، وأخيرًا حدّد الطلبات التي تظهر فيها فروق.
يُنصح بتحديد هامش تفاوت مقبول. فالفروق الطفيفة شائعة بسبب أسعار الصرف ودقة الفوترة والمناطق الزمنية المستخدمة في الإحصاءات؛ ولا تحتاج إلى مراجعة تفصيلية إلا الفروق التي تتجاوز هذا الهامش.
🚀 بداية سريعة: إذا كنت تستدعي النماذج عبر APIYI على apiyi.com، فابدأ بتصدير سجلات الاستدعاء لفترة محددة، ثم طابقها طلبًا بطلب مع حقول
usageالتي سجّلتها. تحقّق مما إذا كانت حقول المنصة المتاحة حاليًا تميّز بين رموز التخزين المؤقت ورموز الاستدلال؛ وإن لم تُدرجها بشكل منفصل، فاعتمد على حقول الاستجابة المسجّلة محليًا لتفاصيل الاستخدام.
مؤشرات غير طبيعية في فواتير API لنماذج اللغة الكبيرة: كيف تتحقق من التغير المفاجئ في التكلفة؟
يُعد التغير المفاجئ في تكلفة النوع نفسه من الطلبات إشارة تستحق الانتباه. يعرض الجدول التالي الأسباب الشائعة وطرق التحقق منها.
| الظاهرة غير الطبيعية | السبب المحتمل | طريقة التحقق |
|---|---|---|
| ارتفاع تكلفة الطلب الواحد مع ثبات عدد الاستدعاءات | يشير الاسم المستعار للنموذج إلى إصدار جديد يختلف سعره أو استهلاكه من Token | قارن قيمة الحقل model في الاستجابات قبل التغير وبعده |
| ارتفاع تكلفة الإدخال مع ثبات إجمالي Token للإدخال | انخفاض معدل الاستفادة من ذاكرة التخزين المؤقت | راجع نسبة cached_tokens وتحقق مما إذا تغيرت بداية الموجه |
| ارتفاع تكلفة الإخراج مع ثبات طول الرد الظاهر | زيادة Token الاستدلال | راجع اتجاه reasoning_tokens وتحقق من معاملات مستوى الاستدلال |
| ارتفاع Token الإدخال تدريجيًا وباستمرار | عدم اقتطاع سجل المحادثة، أو زيادة المقاطع المسترجعة، أو إضافة تعريفات أدوات | افحص عينة من أجسام الطلبات الكاملة |
| عدد الاستدعاءات أكبر من حجم العمليات | إعادة المحاولة من جانب العميل أو إعادة الإرسال بعد انتهاء المهلة | احسب العدد بعد إزالة التكرارات وفق معرّف الطلب ومعرّف العملية |
| ارتفاع مفاجئ في تكلفة الصور أو الفيديو | زيادة الدقة أو مستوى الجودة أو عدد العناصر المطلوب توليدها | قارن معاملات المواصفات في الطلبات |
| اختلاف سعر الوحدة في الفاتورة عن لقطة الأسعار | تغيير الأسعار من المزود الرسمي أو المنصة | راجع صفحة الأسعار والإعلانات، ثم حدّث لقطة الأسعار |
فقدان الاستفادة من ذاكرة التخزين المؤقت: زيادة يصعب ملاحظتها في التكلفة
غالبًا ما يحدث ذلك بسبب تعديل «يبدو غير ضار». مثلًا، إضافة التاريخ الحالي إلى بداية موجه النظام، أو إدراج معرّف المستخدم في بدايته. عندئذ تختلف بداية كل طلب، فلا يمكن الاستفادة من ذاكرة التخزين المؤقت، وتعود تكلفة الإدخال مباشرة إلى السعر الكامل.
الطريقة الصحيحة هي وضع المحتوى الثابت أولًا، والمحتوى المتغير في النهاية. بعد تعديل قالب الموجه، راجع في اليوم التالي ما إذا تغيرت نسبة الاستفادة من ذاكرة التخزين المؤقت.
تغير طول الاستدلال: مستوى الصعوبة يؤثر أيضًا في الفاتورة
ترتبط تكلفة نماذج الاستدلال بصعوبة الأسئلة. إذا طرح المستخدمون فجأة مجموعة من الأسئلة المعقدة في يوم معين، فسترتفع Token الاستدلال بوضوح، وهذا تذبذب طبيعي. لكن إذا استمرت في الارتفاع رغم ثبات نوع الطلبات، فتحقق مما إذا تغير إصدار النموذج أو معاملات الاستدلال.
عادات مراجعة فواتير واجهات API لنماذج اللغة الكبيرة عند تغير الأسعار
لا يمكن التحكم في تغير الأسعار، لكن يمكنك التحكم في مدى سرعة اكتشافه. إليك مجموعة من عادات المراجعة التي يمكنك الالتزام بها على المدى الطويل:
- أسبوعيًا: راجع اتجاهات التكلفة لكل نموذج ومتوسط تكلفة الطلب الواحد، وانتبه إلى التغيرات المفاجئة؛
- شهريًا: طابق الفواتير بالكامل، وحدد سبب كل فرق يتجاوز الحد المسموح؛
- بعد كل تعديل على قالب الموجه: راقب نسبة الاستفادة من ذاكرة التخزين المؤقت لمدة يوم أو يومين؛
- قبل تبديل أي نموذج أو ترقيته: قارن استهلاك الرموز (Tokens) والتكلفة بين النموذجين القديم والجديد باستخدام حجم صغير من الطلبات؛
- تابع الإعلانات: اشترك في إعلانات تحديث الأسعار والنماذج لدى المزوّدين أو المنصات التي تستخدمها، وحدّث سجل الأسعار فور وصولها؛
- ثبّت الإصدار: استخدم في بيئة الإنتاج أسماء نماذج تتضمن رقم إصدار محددًا قدر الإمكان، لتجنب المفاجآت الناتجة عن الترقية التلقائية للأسماء المستعارة.
💡 نصيحة للاختيار: إذا كان نشاطك يستخدم نماذج من عدة مزوّدين، فقد تستغرق مطابقة الفواتير عبر حسابات متعددة وقتًا طويلًا. يتيح لك الوصول الموحّد عبر APIYI على apiyi.com الاطلاع على استخدام النماذج المختلفة ضمن رصيد واحد ومجموعة سجلات واحدة، مما يسهل مقارنة تكلفة الطلب الواحد. يُنصح بالتحقق أولًا من مستوى التفاصيل المتاح في لوحة التحكم.
الأسئلة الشائعة FAQ
س1: ما المقصود بـ Token في فاتورة API لنموذج لغة كبير؟
Token هي الوحدة الأساسية التي يعالج بها النموذج النص، ويمكن فهمها على أنها مقطع ناتج عن تجزئة النص. قد يقابل الحرف الصيني الواحد وحدة Token واحدة أو أكثر، بحسب أداة التجزئة الخاصة بالنموذج. تُحتسب الفاتورة عادةً بشكل منفصل وفق عدد وحدات Token في كل فئة، مثل الإدخال والإخراج والتخزين المؤقت والاستدلال.
س2: ما الفرق بين وحدات Token المخزنة مؤقتًا ووحدات Token العادية للإدخال؟
كلاهما من وحدات الإدخال، لكن وحدات Token المخزنة مؤقتًا هي الجزء المطابق لبادئة سبق تخزينها، وعادةً ما تستفيد من سعر مخفّض. أما وحدات الإدخال العادية فتُحتسب بالسعر الكامل. يفرض بعض المزودين أيضًا رسومًا منفصلة على الكتابة الأولى في الذاكرة المؤقتة، لذا يجب حساب الأنواع الثلاثة كلٌّ على حدة عند مطابقة الفاتورة.
س3: لماذا لا تظهر وحدات Token الخاصة بالاستدلال في الرد؟
تنتج وحدات Token الخاصة بالاستدلال عن تفكير النموذج الداخلي. ولا تعيد نماذج كثيرة عملية الاستدلال كاملةً إلى الجهة المستدعية، بل تذكر عدد هذه الوحدات فقط في حقل الاستخدام. وتُحتسب عادةً بسعر وحدات الإخراج، لذا قد تكون التكلفة مرتفعة حتى لو كان الرد قصيرًا.
س4: لماذا قد تتغير تكلفة الطلب نفسه فجأة؟
هناك ثلاثة أسباب شائعة: أن يشير الاسم المستعار للنموذج إلى إصدار جديد، أو أن يتغير نص بادئة الموجه فلا تُستخدم النسخة المخزنة مؤقتًا، أو أن يزداد طول الاستدلال. وقد ترجع الزيادة أيضًا إلى رسوم مكررة بسبب إعادة المحاولة، أو إلى رفع مواصفات الوسائط المتعددة. يمكنك تحديد السبب بفحص الإشارات الواردة في جدول مؤشرات الخلل في هذا المقال، واحدةً تلو الأخرى.
س5: كيف أستخدم سجلات المنصة لمطابقة فاتورة API الخاصة بنموذج لغة كبير؟
ابدأ بتسجيل حقل `usage` ومعرّف الطلب لكل استجابة في نظامك، ثم صدّر سجلات الاستدعاءات من المنصة وطابقها مع سجلاتك طلبًا بطلب. على سبيل المثال، في APIYI apiyi.com، يمكنك عرض إحصاءات الاستخدام وسجلات الاستدعاءات من لوحة التحكم. تحقق أولًا من الحقول التي تتضمنها السجلات، ثم ادمجها مع سجلاتك المحلية لمطابقة الفاتورة.
س6: كيف أقدّر تكلفة نموذج متعدد الوسائط؟
راجع أولًا صفحة الأسعار الرسمية لتحديد طريقة الاحتساب: هل هي لكل صورة، أم لكل ثانية، أم بتحويل الدقة إلى وحدات Token؟ بعد ذلك، سجّل مواصفات الطلب في سجلاتك، مثل أبعاد الصورة ومدة الصوت ودقة الفيديو ومدته، واستخدم هذه القيم مع أسعار الوحدات لتقدير التكلفة.
س7: من أين أبدأ إذا اكتشفت فرقًا عند مطابقة الفاتورة؟
تحقق أولًا من أن نسخة الأسعار التي تعتمد عليها محدثة، لاستبعاد أثر أي تغيير في الأسعار. ثم قارن عدد الاستدعاءات لاستبعاد إعادة المحاولة والطلبات المكررة. أخيرًا، قسّم الفروق حسب النموذج وبند الفوترة لتحديد ما إذا كان الخلل في الإدخال أو التخزين المؤقت أو الاستدلال أو الوسائط المتعددة.
س8: ما حدود طريقة مطابقة الفواتير هذه؟
يعتمد ذلك على حقول الاستخدام التي تُرجعها الاستجابة. وإذا كانت بعض النماذج أو واجهات API لا تُرجع تفاصيل التخزين المؤقت والاستدلال، فلا يبقى سوى الاعتماد على فاتورة المنصة. كذلك قد تسبب أسعار الصرف ودقة الفوترة والمنطقة الزمنية للإحصاءات فروقًا طفيفة، لذا من الأفضل تحديد حدّ تفاوت معقول بدلًا من السعي إلى تطابق تام.
أهم النقاط حول فواتير واجهات API لنماذج اللغة الكبيرة
- تتكون التكلفة من بنود متعددة: تختلف أسعار وحدات الإدخال والإخراج والتخزين المؤقت والاستدلال والوسائط المتعددة، لذا يجب حساب كل منها على حدة.
- رموز الإدخال لا تقتصر على سؤال المستخدم: تشمل أيضًا موجه النظام وسجل المحادثة والمستندات المسترجعة وتعريفات الأدوات.
- تعتمد الاستفادة من التخزين المؤقت على تطابق البادئة: ضع المحتوى الثابت أولًا والمتغيرات بعده، وتحقق من معدل الاستفادة بعد تعديل القالب.
- رموز الاستدلال غير مرئية لكنها مدفوعة: تجنب استخدام نماذج الاستدلال للمهام البسيطة، وراقب اتجاه طول الاستدلال.
- في الوسائط المتعددة، اسأل أولًا: «كيف تُحسب التكلفة؟»: قد تُحسب لكل صورة أو لكل ثانية أو بحسب الدقة؛ ارجع إلى صفحة الأسعار الرسمية.
- طابق الفواتير في أربع خطوات: سجّل الاستخدام، واحتفظ بنسخ من الأسعار، واحسب التكلفة المتوقعة، ثم قارنها بالسجلات والفواتير.
- تسهّل الواجهة الموحدة مطابقة الفواتير: يمكنك الاستعانة بالرصيد الموحد وسجلات الاستدعاء في APIYI عبر apiyi.com لمراجعة استخدام نماذج متعددة من مكان واحد.
الخلاصة
لفهم فواتير API لنماذج اللغة الكبيرة ومراجعتها، ركّز على ثلاث خطوات:
- قسّم التكلفة: افصل تكلفة كل استدعاء إلى مدخلات، وذاكرة تخزين مؤقت، ومخرجات، واستدلال، ومحتوى متعدد الوسائط، وحدد مصدر كل جزء؛
- احتفظ بسجلاتك: سجّل حقول الاستخدام ومعلمات المواصفات لكل استدعاء في قاعدة بيانات، واحتفظ بلقطات للأسعار مرفقة بتواريخها؛
- قارن بانتظام: راقب الاتجاهات أسبوعيًا، وطابق إجمالي الحساب شهريًا. وعند حدوث تغير مفاجئ في التكلفة، تحقّق تباعًا من إصدار النموذج، ومعدل الاستفادة من ذاكرة التخزين المؤقت، وطول الاستدلال، وإعادة المحاولة، ومعلمات المواصفات.
يتولى مشغّلو المنصات التحقق من قواعد احتساب الفواتير هذه، لكن من المهم أيضًا أن تبني عادة المطابقة الخاصة بك بصفتك مستخدمًا للـ API. وإذا كان عملك يتطلب استدعاء نماذج من عدة مزودين، فنوصي بالربط الموحد عبر APIYI على apiyi.com، لعرض الاستخدام وسجلات الاستدعاء في لوحة تحكم واحدة، ثم مطابقتها باستخدام الطريقة الموضحة في هذا المقال.
📚 المراجع
- إعلان توظيف على V2EX: وظيفة تشغيل منصة نماذج اللغة الكبيرة لدى شركة متخصصة في البنية التحتية لوكلاء الذكاء الاصطناعي: تتضمن مسؤوليات الوظيفة «التحقق من التكاليف والفوترة»
- الرابط:
v2ex.com/t/1254263 -
توضيح: نُشر في 2026-11-03، ويصف حاجة فريق المنصة إلى التحقق من قواعد فوترة رموز الإدخال والإخراج، ورموز التخزين المؤقت والاستدلال، وكذلك الصور والصوت والفيديو، ورصد الفواتير غير المعتادة وتغيرات الأسعار وفروق الفوترة
-
صفحات التسعير الرسمية لمزودي النماذج: المصدر الموثوق الوحيد للأسعار المحددة وقواعد الفوترة
- الرابط: ابحث في قسم التسعير أو الوثائق على الموقع الرسمي للمزود الذي تستخدمه
- توضيح: تتغير الأسعار باستمرار، لذا احرص على تسجيل تاريخ الاطلاع عند الاستشهاد بها
الكاتب: الفريق التقني في APIYI
للتواصل التقني: إذا كانت لديك أسئلة حول مطابقة فواتير API لنماذج اللغة الكبيرة، يمكنك التواصل معنا عبر الصفحة الرئيسية لـ APIYI على apiyi.com. وللمزيد من موارد الربط، راجع مركز الوثائق على docs.apiyi.com
