كل واجهة API للذكاء الاصطناعي تحتسب الفاتورة لكل توكن. وأنت تثق بأن كائن usage الذي يعيده الـ gateway — prompt_tokens، completion_tokens — يمثّل العدد الحقيقي. لكن هذا الرقم هو الشيء الوحيد الذي يتحكم فيه المعيد البيع تحكماً كاملاً، وهو أسهل موضع يمكن أن يُحمّلك فيه فوق طاقتك بهدوء. الاسم المهذّب لذلك هو نفخ التوكنات: الـ gateway يبلّغ عن توكنات أكثر مما أرسلته أو استلمته فعلاً، فتدفع 5 أضعاف أو 10 أضعاف، وأحياناً 25 ضعفاً من التكلفة الصادقة — سواء على النموذج الأصلي أو غيره.
هذا تحديداً هو نمط الخلل الذي بُني Brievio في مواجهته، ولذلك يستحق الشرح بوضوح: كيف يجري الحشو، واختبار من 20 سطراً يمكنك تشغيله ضد أي gateway (بما فيه gateway الخاص بنا)، وكيف تقرأ النتيجة.
ما هو نفخ التوكنات فعلاً
العدد الصادق للتوكنات هو ما سيحسبه المزوّد نفسه مقابل رسائلك أنت — system prompt الخاص بك، ومحتوى المستخدم الذي كتبته، ورد النموذج. الـ gateway الجدير بالثقة يمرّر هذا العدد كما هو دون تغيير. أما المنفوخ فيحشوه. الطلب نفسه، لكن الفاتورة مختلفة تماماً:
# استهلاك صادق — العدد يطابق النص الذي أرسلته، إضافة إلى عبء بسيط
# ناتج عن قالب المحادثة (علامات الأدوار، توكنات التنسيق):
{"prompt_tokens": 24, "completion_tokens": 2, "total_tokens": 26}
# منفوخ — أرسلت ما يقارب 20 توكن من النص لكنك تدفع مقابل 1840:
{"prompt_tokens": 1840, "completion_tokens": 2, "total_tokens": 1842}
# ^ تمت حقن system prompt بحجم 1800 توكن لم تكتبه قط داخل
# الطلب وتم احتسابه عليك. على سؤال من كلمة واحدة. في كل نداء.الحيلة الأكثر شيوعاً هي system prompt محقون ومخفي: يضيف المعيد البيع بضع مئات إلى بضعة آلاف من التوكنات من نصه الخاص في مقدمة كل نداء — تمهيد «أمان»، أو غلاف توجيه، أو شخصية مزيّفة. أنت لم تكتبه قط، ولا يمكنك رؤيته، لكنك تدفع مقابله في كل طلب على حدة. وبأسعار مدخلات Sonnet، فإن بادئة وهمية بحجم 1800 توكن تساوي نحو $0.0055 هامش ربح صافٍ على سؤال من كلمة واحدة. اضرب ذلك في مليون نداء شهرياً.
اختبار العشرين سطراً
لست مضطراً لتصديق كلام أحد — ونحن من ضمنهم. أرسل prompt تعرف حجمه، ثم قارن ما احتسبه عليك الـ gateway مع العدد الذي يتحول إليه نصك فعلاً على جهازك أنت:
# token_inflation_test.py
# هل يبلّغ الـ gateway الخاص بك عن أعداد توكنات صادقة؟ أرسل prompt بحجم
# معروف، ثم قارن قيمة prompt_tokens التي بلّغ عنها الـ gateway مع عدّ
# محلي عبر tokenizer للرسائل التي أرسلتها بالضبط.
import tiktoken
from openai import OpenAI
client = OpenAI(api_key="sk-brievio-...", base_url="https://api.brievio.com/v1")
messages = [
{"role": "system", "content": "You are a terse assistant."},
{"role": "user", "content": "Reply with the single word: ok."},
]
# 1. ما الذي يحتسبه عليك الـ gateway:
resp = client.chat.completions.create(
model="claude-sonnet-4-6", messages=messages, max_tokens=5,
)
reported = resp.usage.prompt_tokens
# 2. إلى كم توكن تتحول رسائلك فعلياً، محلياً:
enc = tiktoken.get_encoding("cl100k_base") # تقريب — انظر الملاحظة أدناه
local = sum(len(enc.encode(m["content"])) for m in messages)
print(f"gateway reported prompt_tokens: {reported}")
print(f"local token count of your text: {local}")
print(f"ratio: {reported / local:.1f}x")
# طبيعي → النسبة ~1.1-1.6x (علامات الأدوار + عبء قالب المحادثة)
# نفخ → النسبة 2x / 5x / 25x (prompt مخفي يحشو مدخلاتك)كيف تقرأها: وجود عبء ثابت صغير أمر طبيعي — تضيف صيغ المحادثة حفنة من التوكنات لعلامات الأدوار وحدود الرسائل، لذا فإن نسبة حول 1.1–1.6× على prompt صغير جداً مقبولة تماماً، وتتقلّص نحو 1.0× كلما كبر prompt الخاص بك. أما نسبة 2× أو 5× أو 25× فليست خطأ تقريب — إنها حشو.
تحفّظ صادق واحد: cl100k_base الخاص بـ tiktoken هو tokenizer من OpenAI، أما Claude أو Gemini فيقسّمان النص إلى توكنات بشكل مختلف قليلاً (عادة ضمن نطاق 10–20%). لذا تعامل مع العدد المحلي بوصفه تقريباً، لا تدقيقاً بدقة التوكن الواحد. فهو لن يفسّر أبداً فجوة بحجم 2×، فضلاً عن 25× — وللحصول على رقم دقيق استخدم tokenizer المزوّد نفسه أو نقطة نهاية count-tokens الخاصة به. هذا الاختبار مصمَّم لاصطياد النفخ، لا للمناقشة حول توكنات مفردة.
افحص المخرجات والـ cache أيضاً
المدخلات هي الهدف المعتاد، لكن الحشو نفسه قد يختبئ في توكنات المخرجات وفي الـ caching. فحصان سريعان إضافيان:
# يمكن حشو المخرجات والـ cache أيضاً. فحصان إضافيان مدة كل منهما 30 ثانية:
#
# (a) المخرجات: اطلب توكن واحداً بالضبط وضع له سقفاً.
resp = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{"role": "user", "content": "Reply with only: ok"}],
max_tokens=2,
)
print(resp.usage.completion_tokens) # صادق: ~1-2. محشو: 50، 200، ...
#
# (b) الـ cache: أرسل البادئة الطويلة نفسها مرتين خلال ~5 دقائق. يفترض
# بالنداء الثاني أن يحتسب معظم المدخلات بسعر قراءة الـ cache المخفّض.
# إذا بقي حقل "cached" دائماً 0، فأنت تدفع السعر الكامل على إصابات الـ cache.
print(resp.usage.prompt_tokens_details.cached_tokens)إذا طلبت توكناً واحداً ووجدت نفسك تُحاسَب على خمسين، أو إذا بقي cached_tokens عالقاً عند صفر في نداء مكرّر مطابق، فإن العدّاد يقيس بشكل خاطئ.
من أين يأتي النفخ
- system prompts محقونة. تمهيد غلاف يُضاف إلى كل طلب — وهو المصدر الأكثر شيوعاً بفارق كبير. كبير، خفيّ، ومحتسَب عليك.
- نماذج «template proxy» معاد تغليفها. يُحشَر prompt الخاص بك داخل قالب ثابت كبير قبل أن يصل إلى النموذج. توكنات القالب توكنات حقيقية — بالنسبة للنموذج وبالنسبة لفاتورتك — لكنها ليست لك.
- أرقام usage ملفّقة. أفظ الصيغ: كائن
usageببساطة لا يطابق الواقع. والاختبار أعلاه يكشف هذا فوراً. - حشو وهمي للمخرجات. قيمة
completion_tokensالمُبلَّغ عنها تتجاوز عدد الكلمات المُعادة فعلاً.
لا شيء من هذا يستلزم نموذجاً مزيّفاً. يمكن لأي gateway أن يقدّم Claude الأصلي ومع ذلك ينفخ العدّاد — فأصالة النموذج وصدق الفاتورة وعدان منفصلان، وعليك أن تتحقق من كليهما.
المرجعية الصادقة
يمرّر Brievio أعداد التوكنات الخاصة بالمزوّد كما هي دون تغيير، ولا يحقن أي شيء في طلباتك، ويسجّل توكنات المدخلات والمخرجات الحقيقية إضافة إلى التكلفة الدقيقة في كل نداء، وكل ذلك مرئي في لوحة الاستهلاك الخاصة بك. شغّل الاختبار أعلاه ضد Brievio ويفترض أن ترى reported ≈ local + عبء صغير — وهكذا ينبغي أن يُقرأ في كل مكان. وتعرض صفحة الأسعار لدينا كل نموذج مقابل سعره المرجعي الرسمي، بحيث يكون الخصم قابلاً للتدقيق، بينما توضّح وثائق الاستهلاك بالضبط ما الحقول التي نعيدها.
إذا كان gateway أدنى بنسبة 80% من سعر القائمة، فالسؤال الأول ليس «هل النموذج حقيقي» — بل «ماذا يقول العدّاد». شغّل العشرين سطراً. تكلفتها أقل من سنت واحد، وهي أرخص عملية تحقّق واجب ستجريها يوماً على أي مورّد.