هل يرفع Tokenizer الجديد في Claude Opus 4.7 تكلفة البرومبت؟

ترقية نموذج الذكاء الاصطناعي لا تعني فقط مقارنة السعر لكل مليون token. هناك طبقة أقل ظهوراً لكنها مؤثرة: الـ tokenizer، أي القاعدة التي تقطع النص قبل دخوله إلى النموذج. إذا تغيرت هذه القاعدة، فقد يتحول النص نفسه إلى عدد مختلف من الرموز، والرموز هي إحدى وحدات التسعير الأساسية في وثائق واجهات برمجة تطبيقات النماذج اللغوية.

حالة Claude Opus 4.7 مثال واضح. وثائق Anthropic تنص على أن الـ tokenizer الجديد قد يستخدم عند معالجة النصوص نحو 1x إلى 1.35x من الرموز مقارنة بالنماذج السابقة، أي حتى نحو 35% أكثر، مع اختلاف ذلك حسب المحتوى. كما توضح أن استدعاء /v1/messages/count_tokens سيعيد عدداً مختلفاً من الرموز لـ Claude Opus 4.7 مقارنةً بـ Claude Opus 4.6.

الخلاصة: قد يصبح البرومبت أغلى، لكن ليس دائماً بنسبة 35%

القراءة الأدق هي: إذا زاد عدد input tokens للنص نفسه، وبقي سعر رمز الإدخال كما هو، فقد ترتفع تكلفة جزء الإدخال في الطلب. لكن Anthropic لا تقول إن كل برومبت سيزيد 35%؛ النطاق الرسمي هو تقريباً من 1x إلى 1.35x، والتأثير يختلف حسب المحتوى.

كذلك لا يصح تحويل زيادة الرموز مباشرة إلى زيادة مساوية في الفاتورة كاملة. في تسعير Claude API، توجد بنود منفصلة مثل

Base Input Tokens

Cache Writes

Cache Hits

Output Tokens

لماذا يتغير عدد الرموز للنص نفسه؟

الـ token ليس بالضرورة كلمة، ولا حرفاً واحداً. قد يكون جزءاً من كلمة، أو كلمة كاملة، أو علامة ترقيم، أو مقطعاً من نص أطول. لذلك لا يكفي حساب عدد الكلمات أو الأحرف لتقدير التكلفة بدقة.

دليل OpenAI الخاص بـ tiktoken يوضح أن حساب الرموز يعتمد على اختيار encoding مناسب للنموذج، بينما توضح وثائق Gemini أن مدخلات ومخرجات Gemini API تُحوَّل إلى tokens، بما في ذلك النصوص والصور وأنواع مدخلات أخرى.

بعبارة أبسط: التقدير بعدد الكلمات مفيد للتخمين السريع، لكنه ليس صالحاً للمحاسبة أو التخطيط الدقيق. ما يهم فعلاً هو عدد الرموز الذي يعيده العداد الرسمي للنموذج المستهدف. وكون Claude Opus 4.7 وClaude Opus 4.6 يعطيان أرقاماً مختلفة عبر count_tokens يثبت أن تغيير الـ tokenizer وحده قد يغير عدّ النص نفسه.

كيف نفهم رقم 35%؟

العبارة الشائعة	القراءة الأدق
Opus 4.7 يجعل كل برومبت أغلى 35%	تبسيط زائد. الرقم الرسمي هو نحو 1x–1.35x من الرموز، والتأثير يختلف حسب المحتوى.
النص نفسه قد يُحسب بعدد أكبر من الرموز	صحيح. وثائق Anthropic تقول إن tokenizer الجديد في Opus 4.7 قد يستخدم رموزاً أكثر، وأن عدّ الرموز سيختلف عن Opus 4.6.
تغيير الـ tokenizer يؤثر فقط في حد السياق، لا في التكلفة	غير مكتمل. وثائق التسعير تعتمد على بنود مثل input وoutput وcache، لذلك تغير عدد الرموز قد يدخل في حساب التكلفة.
الأفضل استخدام العداد الرسمي بدلاً من التخمين	صحيح. OpenAI توفر إرشادات لحساب input tokens وtiktoken، وGemini توفر count_tokens، وAnthropic تشير إلى /v1/messages/count_tokens.

طريقة مبسطة لتقدير الأثر المالي

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

تكلفة الإدخال الإضافية ≈ (رموز الإدخال بالـ tokenizer الجديد − رموز الإدخال بالـ tokenizer القديم) × سعر رمز الإدخال

لكن هذه الصيغة لا تغطي الفاتورة كلها. التكلفة الفعلية قد تشمل output tokens، وكتابة الكاش، وضربات الكاش، أو بنوداً أخرى بحسب المزود. وثائق Anthropic تفصل هذه البنود، كما توفر OpenAI وGemini صفحات تسعير رسمية يمكن الرجوع إليها عند بناء نموذج تكلفة داخلي.

ماذا تفعل قبل ترقية النموذج؟

1. اختبر حمولة الطلب كاملة، لا رسالة المستخدم وحدها

في التطبيقات الواقعية، ما يصل إلى النموذج لا يكون عادةً جملة المستخدم فقط. قد يتضمن system prompt، وسياقاً طويلاً، ونتائج أدوات، وملفات، وصوراً، وتعليمات تنسيق. وثائق Gemini تذكر أن كل المدخلات والمخرجات تُحوَّل إلى tokens، بما في ذلك النص والصور، كما يعرض دليل OpenAI لحساب الرموز مثالاً لمدخلات تجمع بين النص والصورة.

2. استخدم عداد الرموز الرسمي للنموذج المستهدف

لا تعتمد على عداد عام إذا كنت تحتاج رقماً قريباً من الفاتورة. OpenAI توفر responses.input_tokens.count وإرشادات tiktoken، وGemini توفر count_tokens، بينما تشير وثائق Anthropic الخاصة بـ Opus 4.7 إلى /v1/messages/count_tokens وتوضح أن Opus 4.7 سيعيد عدداً مختلفاً عن Opus 4.6.

3. خذ عينات من أنواع المحتوى المهمة لديك

لا تختبر برومبتاً قصيراً واحداً ثم تعمم النتيجة. بما أن Anthropic تقول إن الزيادة تختلف حسب المحتوى، فالأفضل قياس أنواع الطلبات الأكثر استخداماً أو الأعلى تكلفة: السياقات الطويلة، البيانات المنظمة، محادثات الدعم، طلبات البرمجة، أو أي payload يمثل إنفاقك الحقيقي.

4. طبّق الفارق على التسعير الرسمي

بعد مقارنة عدد input tokens في النموذجين، استخدم صفحة التسعير الرسمية للنموذج لحساب فرق تكلفة الإدخال. بعدها أعد إدخال output tokens وcache writes وcache hits، إن كانت مستخدمة، في نموذج التكلفة الكامل. صفحات Anthropic وOpenAI وGemini الرسمية هي نقطة البداية لهذا الحساب.

5. قرر إن كنت تحتاج إلى تحسين البرومبت

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

الخلاصة العملية

الـ tokenizer الجديد يمكن فعلاً أن يجعل النص نفسه يستهلك tokens أكثر. في Claude Opus 4.7، تؤكد وثائق Anthropic أن معالجة النص قد تستخدم نحو 1x إلى 1.35x من الرموز مقارنة بالنماذج السابقة، أي حتى نحو 35% أكثر، مع اختلاف التأثير حسب المحتوى.

لكن السؤال الأهم ليس: هل الرقم 35% صحيح؟ بل: كم زاد عدد input tokens في طلباتك أنت؟ وهل تغيرت المخرجات؟ وكيف تُحاسب بنود الكاش؟ وما سعر النموذج في صفحة التسعير الرسمية؟ قبل الترقية، شغّل عداد الرموز الرسمي على payload حقيقي، ثم طبّق التسعير الرسمي. هذه هي الطريقة الأكثر أماناً لمعرفة ما إذا كان البرومبت سيصبح أغلى فعلاً.