لماذا تكلّف رموز إخراج Claude خمسة أضعاف الإدخال؟

لماذا تكلّف رموز الإخراج أكثر من رموز الإدخال

تكلّف رموز الإخراج خمسة أضعاف تكلفة رموز الإدخال في كل نموذج Claude ضمن الكتالوج الحالي. والسبب هو طبيعة الحساب. يقرأ النموذج المطالبة في مرور واحد. أما كتابة الرد فتتطلب مروراً واحداً لكل رمز، ويجب أن ينتظر كل مرور اكتمال المرور الذي يسبقه.

تظل هذه النسبة نفسها في كل صف من قائمة الأسعار، لذلك لا يغيّر النموذج الذي تختاره مقدار فاتورتك الناتج عن الإخراج. الذي يحدد ذلك هو شكل حمل العمل لديك. فالخطوة في وكيل تقرأ 60,000 رمزاً وتجيب بـ800 رمز تكاد لا تنفق شيئاً على الإخراج. أما مهمة صياغة تقرأ 2,000 رمز وتكتب 12,000 رمز فتكاد لا تنفق شيئاً على الإدخال. نحلل الحالتين أدناه باستخدام أسعار Anthropic المنشورة لشهر August 2026.

يحدث Prefill مرة واحدة، بينما يحدث Decoding مرة لكل رمز

يعالج خادم الاستدلال الطلب على مرحلتين تختلف تكلفتهما كثيراً. تقرأ مرحلة Prefill الموجّه. وتكتب مرحلة Decoding الرد.

تتعامل مرحلة Prefill مع الموجّه كاملاً دفعة واحدة. يدخل كل رمز من رموز الموجّه إلى الشبكة ضمن عملية forward pass واحدة، لذلك تصبح عمليات attention وfeed-forward عدداً صغيراً من عمليات ضرب المصفوفات الكبيرة التي تغطي آلاف الرموز في كل مرة. وتكفي قراءة واحدة لأوزان النموذج من الذاكرة لخدمة الموجّه بأكمله. تبقى وحدات المصفوفات في المسرّع مشغولة، ما يعني أن Prefill محدودة بالحساب: العامل المحدِّد هو سرعة إجراء الشريحة لعمليات الضرب.

لا يمكن لمرحلة Decoding أن تعمل بهذه الطريقة، لأن الرمز 2 يعتمد على الرمز 1. يصبح الرمز الذي أنتجه النموذج للتو جزءاً من إدخال الخطوة التالية، لذلك لا يمكن تنفيذ الخطوات في الوقت نفسه. يحصل كل رمز ناتج على عملية forward pass خاصة به، وتقرأ كل واحدة من هذه العمليات المجموعة الكاملة من أوزان النموذج من الذاكرة ذات النطاق الترددي العالي لإنتاج رمز واحد. لذلك تكون Decoding محدودة بالذاكرة: العامل المحدِّد هو سرعة نقل الأوزان، لا سرعة ضربها. وتنتج حركة الأوزان نفسها التي عالجت موجّهاً كاملاً أثناء Prefill رمزاً واحداً فقط أثناء Decoding.

تواجه أنظمة تقديم الخدمة ذلك باستخدام batching. تُنفَّذ عملية Decoding لطلبات كثيرة معاً، لذلك تنتج قراءة واحدة للأوزان رمزاً واحداً لكل طلب في الدفعة. ولهذا تكون Decoding عملية قابلة للتنفيذ أصلاً. لكن السقف تحدده الذاكرة مرة أخرى. يحتفظ كل طلب قيد التنفيذ بـKV cache (ذاكرة التخزين المؤقت للمفتاح/القيمة، وهي حالة attention المخزنة لكل رمز حتى الآن)، وتنمو هذه الذاكرة مع كل رمز يتم توليده. وعندما تمتلئ ذاكرة المسرّع بها، لا يمكن للدفعة أن تكبر أكثر.

لا يمنحك أي من ذلك رقماً دقيقاً، ولا ينبغي أن تفسّر 5x على أنّها نسبة مقاسة بين عتادين. إنها تكلفة حددتها Anthropic، واستندت في تحديدها إلى هذا التفاوت. يمكنك التحقق بنفسك من الاتجاه العام، ولا يستغرق ذلك سوى نحو دقيقة.

قِس فجوة الإدخال والإخراج بنفسك

ثبّت الأدوات على أي خادم Ubuntu:

sudo apt update && sudo apt install -y curl jq moreutils

شغّل الآن مطالبة قصيرة تطلب إجابة طويلة، وسجّل وقت وصول كل سطر.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

تضيف ts -s إلى بداية كل سطر عدد الثواني المنقضية منذ بدء الأمر. توجد نقطتان مهمتان في هذا الإخراج. يمثّل أول سطر content_block_delta الزمن حتى وصول أول token، وقد حدثت عملية prefill بأكملها خلاله. كل سطر بعد ذلك يمثّل خطوة صغيرة من decoding، وتستمر الأختام الزمنية في الارتفاع حتى يصل message_stop.

اعكس النمط الآن. ضع مستنداً طويلاً في المطالبة، وحدد الإجابة بعدد قليل من tokens.

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

يستغرق الفرق الزمني الأول مدة أطول مما استغرقه مع المطالبة القصيرة، لأن prefill يقرأ نصاً أكبر بكثير. بعد وصوله، تنتهي الاستجابة تقريباً فوراً، لأن عدد tokens المتبقية لعملية decoding قليل. دخلت عشرات الآلاف من tokens، ولم تتحرك الساعة إلا قليلاً. خرجت بضع مئات منها، وظلت الساعة تعمل طوال الوقت.

تنتهي كل استجابة غير متدفقة بالأرقام التي تُحتسب الفاتورة على أساسها.

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

سجّل الحقول الأربعة كلها لكل طلب. يتضمن output_tokens عملية extended thinking، لذلك يفرض النموذج الذي يفكّر قبل الإجابة رسوماً على هذا التفكير وفق معدل الإخراج. لتسعير المطالبة قبل إرسالها، يقبل POST /v1/messages/count_tokens جسم الطلب نفسه، ويعيد {"input_tokens": N} من دون تشغيل النموذج، وهذه العملية مجانية.

ما تفرضه Claude لكل مليون رمز مميز حتى أغسطس 2026

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

العمود الأخير هو ناتج قسمة الإخراج على الإدخال، وتظهر فيه القيمة 5 في كل صف. تفرض Haiku 4.5 مبلغ $1 على الإدخال و$5 على الإخراج. وتفرض Opus 5 مبلغ $5 للإدخال و$25 للإخراج. أما Fable 5، وهي الأغلى، فتفرض $10 و$50، ومن المفيد قراءة ما الذي تتيحه لك أسعار Fable 5 قبل استبعاد الصف الأعلى سعراً. يؤدي الانتقال إلى مستوى أعلى إلى ضرب جانبي التسعير في العامل نفسه. لذلك يتغير إجمالي التكلفة، بينما تظل نسبة الإدخال إلى الإخراج كما هي تماماً.

تظهر Sonnet 5 مرتين لأن سعرها التمهيدي ينتهي. حتى 31 أغسطس 2026، تفرض $2 على الإدخال و$10 على الإخراج. اعتباراً من 1 سبتمبر 2026، يطبَّق السعر القياسي البالغ $3 للإدخال و$15 للإخراج، أي بزيادة قدرها 50% على الجانبين. تستخدم كل الأمثلة المشروحة أدناه سعر أغسطس.

تتغير الأسعار، وهذه الصفحة ليست المكان الذي ينبغي أن تتحقق منها فيه. يُعد claude.com/pricing المصدر المعتمد. أما ما يبقى صالحاً بعد تغير السعر فهو المنهجية.

هناك ملاحظة لا تعرضها قائمة الأسعار. تذكر وثائق Anthropic أن نماذج Claude 4.7 والإصدارات الأحدث تستخدم محللاً رمزياً أحدث ينتج رموزاً مميزة أكثر بنحو 30% للنص نفسه مقارنة بالمحلل الرمزي المستخدم في Sonnet 4.6 والإصدارات الأقدم. ستبدو النماذج الأحدث أفضل عند مقارنتها على أساس السعر لكل مليون رمز مميز فقط، لأن المستند نفسه يحتوي على رموز مميزة أكثر لديها. قارن التكلفة لكل مهمة مكتملة، واحتسب مطالباتك الفعلية وفق النموذج الذي تنوي استخدامه فعلاً. يوضح ما الذي تساويه مليون رمز مميز من Claude في نص فعلي شكل هذا الحجم في الاستخدام العملي.

متى يبدأ الإخراج في الهيمنة على فاتورتك؟

عندما يكون سعر الإخراج يعادل 5 أضعاف سعر الإدخال، يكون حساب نقطة التعادل سهلاً. سمِّ عدد رموز الإدخال I، وعدد رموز الإخراج O. تكلفة الإدخال هي I. وتكلفة الإخراج هي 5 أضعاف O. يتجاوز الإخراج نصف إنفاقك عندما تكون قيمة 5 أضعاف O أكبر من I، أي عندما تكون نسبة الرموز 5 رموز إدخال إلى رمز إخراج واحد.

لذلك، إذا كان موجّهك أطول من ردك بأكثر من خمسة أضعاف، يكون الإدخال هو البند الأعلى تكلفة. وما دون ذلك، يكون الإخراج هو الأعلى تكلفة.

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

عند نسبة 100 إلى 1، يشكّل الإخراج 4.8% من الإنفاق، ويكون تقليل الموجّه هو العمل الوحيد الذي يستحق التنفيذ. عند نسبة 5 إلى 1، تتساوى الكفتان. عند نسبة 1 إلى 6، يشكّل الإخراج 96.8%، ويصبح الموجّه هامشياً عند التقريب. يخطئ معظم الأشخاص في تقدير نسبتهم الفعلية، لذلك استخرجها من سجلاتك قبل تحسين أي شيء.

حِمل عمل لوكيل: سياق طويل ومدخلات، وإجابة قصيرة ومخرجات

نفّذ خطوة واحدة لوكيل استرجاع: 60,000 رمزاً من المستندات المسترجعة وسجل المحادثة كمدخلات، وإجابة من 800 رمز كمخرجات. هذه نسبة 75 إلى 1، وهي طبيعية لأي نظام يقرأ قبل أن يكتب.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

تشكل المخرجات 6.25% من تكلفة هذه الاستدعاء على كل نموذج، لأن النسبة ثابتة عبر قائمة الأسعار بأكملها. تبلغ تكلفة الاستدعاء $0.32$ على Opus 5، و$0.128$ على Sonnet 5 وفق سعر أغسطس، و$0.064$ على Haiku 4.5. وتنفيذ 200 خطوة من هذه الخطوات يومياً على Opus 5 يكلّف $64 يومياً.

يتضح الإجراء المؤثر فور رؤية هذا التقسيم. تقليص الإجابة من 800 رمز إلى 400 يوفر نحو 3% من تكلفة الاستدعاء. أما حذف 20,000 رمز من السياق القديم من الموجّه فيوفر نحو الثلث. لذلك فإن تقليص طول المخرجات في وكيل يعتمد على القراءة بدرجة كبيرة يقترب من كونه جهداً مهدراً. يوضّح أين تذهب رموز وكيل البرمجة فعلياً ما الذي يملأ هذا الموجّه في الأساس.

حمل إنشاء المحتوى: مطالبة قصيرة ومسودة طويلة

غيّر الشكل الآن. موجز من 2,000 رمز، ومسودة من 12,000 رمز، بنسبة 1 إلى 6.

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

يمثل الناتج 96.8% من هذه الفاتورة. تبلغ تكلفة Opus 5 مبلغ $0.31 لكل مسودة، مقابل $0.062 في Haiku 4.5. ويأتي هذا الفارق البالغ خمسة أضعاف تقريباً من جانب الناتج بالكامل، وهو بالضبط الجانب الذي يوفّر فيه النموذج الأرخص أكبر قدر من التكلفة.

يعرض العمود الأخير المهمة نفسها من خلال Batch API، الذي يخفض تكلفة الإدخال والناتج بنسبة 50%. تنخفض تكلفة Opus 5 إلى $0.155 لكل مسودة. يعيد Batch النتائج خلال 24 ساعة بدلاً من إعادتها فوراً، لذلك يناسب إنشاء التقارير ليلاً والتصنيف بالجملة. لكنه لا يناسب أي مهمة ينتظر الشخص نتائجها مباشرة.

يفيد توجيه المهام إلى النماذج هنا بطريقة لا يفيد بها في خطوة الوكيل. إذا كان الجزء المطوّل من المهمة آلياً، مثل إعادة تنسيق النص أو توسيع مخطط وافقت عليه مسبقاً، فإن النموذج الأرخص ينشئ هذه الرموز بخُمس التكلفة. يوضّح الاختيار بين Opus وSonnet وHaiku موضع الحد الفعلي للجودة.

تُخفِّض التخزين المؤقت تكلفة الإدخال فقط

يخزّن التخزين المؤقت للمطالبات بادئة المطالبة على الخادم، ثم يفرض جزءاً من سعر الإدخال عند قراءتها مجدداً. اعتباراً من August 2026، تكون المعاملات 1.25x من سعر الإدخال الأساسي لكتابة ذاكرة مؤقتة مدتها 5 minutes، و2x لكتابة ذاكرة مؤقتة مدتها 1 hour، و0.1x لقراءة تطابق من الذاكرة المؤقتة.

لا يشمل ذلك الإخراج. لا يوجد إخراج مخزّن مؤقتاً. تُحاسَب كل token يكتبها النموذج بسعر الإخراج الكامل في كل مرة، بصرف النظر عن مقدار المطالبة الذي أُعيد من الذاكرة المؤقتة كتطابق.

لنأخذ خطوة الوكيل نفسها على Opus 5، مع تقديم 55,000 من أصل 60,000 token للإدخال من ذاكرة مؤقتة دافئة.

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

تنخفض تكلفة الاستدعاء من $0.32 إلى $0.0725. ولا يتغير سطر الإخراج: $0.02 قبل التخزين المؤقت، و$0.02 بعده. يخفض التخزين المؤقت الفاتورة ويغيّر توزيعها. كان الإخراج يمثل 6.25% من تكلفة ذلك الاستدعاء. وأصبح الآن أكثر من ربع التكلفة، ما يغيّر العامل الذي يستحق المعالجة تالياً.

يتحمل الاستدعاء الأول تكلفة الكتابة. تكلف كتابة ذاكرة مؤقتة مدتها 5 minutes مقدار 1.25x من سعر الإدخال الأساسي، ولذلك تسترد تكلفتها بعد تطابق واحد. أما الكتابة لمدة 1 hour فتكلف 2x، ولذلك تحتاج إلى تطابقين. يوضّح معاملات الكتابة والقراءة، ومتى يتوقف التخزين المؤقت عن تحقيق جدوى اقتصادية هذه الحسابات بالتفصيل.

أربع وسائل يمكنك التحكم بها

1. اضبط max_tokens عند طول المخرجات في النسبة المئوية 95، وليس عند الحد الأقصى للنموذج.
2. وجّه الخطوات المطوّلة إلى نموذج أرخص.
3. نفّذ بالدفعات كل ما لا ينتظر أحد نتيجته.
4. احذف التعليمات التي تزيد طول الردود.

max_tokens حدّ أقصى صارم. ولا يكلّف ضبطه على قيمة مرتفعة شيئاً بحد ذاته، لأن الفوترة تعتمد على الرموز التي يُنتجها النموذج، لا على قيمة الحد الأقصى. ما يفعله السقف السخي هو إزالة القيد عن الرد عندما يسير بشكل خاطئ. استخرج توزيع output_tokens من سجلاتك، واضبط السقف أعلى بقليل من النسبة المئوية 95، وعالج stop_reason: "max_tokens" في التعليمات البرمجية عبر متابعة الرد أو إعادة المحاولة. اكتشاف الاقتطاع يكلّف أقل من دفع تكلفة رد مطوّل من 4,000 رمز ثم التخلص منه. يدخل التفكير الممتد ضمن output_tokens أيضاً، لذا اضبط ميزانيته استناداً إلى الأدلة نفسها.

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

التنفيذ بالدفعات هو الوسيلة الوحيدة التي تخفّض تكلفة المخرجات. تحصل على خصم 50% على الجانبين، وتصل النتائج خلال 24 ساعة، وتندرج ضمن ذلك كل المهام المجدولة.

الوسيلة الأخيرة هي التي يتجاوزها الناس عادةً. عبارات مثل "كن دقيقاً" و"اشرح استدلالك" تزيد طول مخرجات كل استدعاء ستجريه مستقبلاً. استبدلها بالشكل الذي تريده: "أجب في ثلاث جمل كحد أقصى"، أو "أعد كائن JSON فقط، من دون مقدمة". تضيف مطالبة نظام 300 رمز إلى كل رد، فتكلّف خمسة أضعاف تكلفة إضافة الرموز الـ300 نفسها إلى المطالبة. يشرح الحفاظ على تكاليف وكيل قيد التشغيل تحت السيطرة جانب المراقبة، ومن المفيد حسم ما إذا كانت API أو الاشتراك الثابت أرخص وفق نمط استخدامك قبل أن تنفق أسبوعاً في ضبط الإنفاق لكل رمز، بينما كان الاشتراك سيتكفّل به.

FAQ

لماذا تكلّف رموز المخرجات أكثر من رموز المدخلات؟

يتطلب توليدها وقتاً أطول بكثير من وقت المسرّع لكل رمز. تُعالج المطالبة في تمريرة أمامية واحدة على كامل محتواها، لذلك تغطي قراءة واحدة لأوزان النموذج آلاف الرموز، وتكون الأجهزة مقيّدة بمعدل عمليات الضرب. أما الاستجابة فتُنتج رمزاً واحداً في كل مرة، ويحتاج كل رمز إلى تمريرة أمامية مستقلة تعيد قراءة أوزان النموذج كاملة، لذلك تكون الأجهزة مقيّدة بعرض نطاق الذاكرة بدلاً من ذلك. تفرض Anthropic سعراً للمخرجات يعادل 5 أضعاف سعر المدخلات عبر كامل الكتالوج الحالي، من Haiku 4.5 إلى Fable 5.

هل يجعل التخزين المؤقت للمطالبة رموز المخرجات أرخص؟

لا. ينطبق التخزين المؤقت للمطالبة على المدخلات فقط. اعتباراً من August 2026، تكلّف قراءة ذاكرة التخزين المؤقت 0.1x من سعر المدخلات الأساسي، وتكلّف عمليات الكتابة فيها 1.25x لمدة 5 minutes أو 2x لمدة 1 hour. تُحاسَب المخرجات بالسعر الكامل في كل استدعاء، بصرف النظر عما فعله التخزين المؤقت. لذلك يغيّر التخزين المؤقت شكل فاتورتك وحجمها معاً: عندما ينخفض جانب المدخلات بشدة، تصبح المخرجات هي الجزء الذي يستحق المعالجة.

هل تكلّفني قيمة max_tokens المرتفعة أموالاً إذا كانت الاستجابة قصيرة؟

لا. تُحاسَب على الرموز التي ينتجها النموذج فعلياً، لذلك تمثل max_tokens حداً أقصى وليست حجزاً مسبقاً. لكنها تظل مهمة لأنها الحد الصارم الوحيد للاستجابة التي تستمر بلا توقف. اضبطها أعلى بقليل من النسبة المئوية 95 من output_tokens الذي رصدته، ثم عالج stop_reason: "max_tokens" في الشيفرة بدلاً من إرسال إجابة مبتورة بصمت.

كيف أعرف نسبة رموز المدخلات إلى رموز المخرجات لدي؟

سجّل input_tokens وoutput_tokens وcache_read_input_tokens وcache_creation_input_tokens من الكائن usage لكل استجابة، ثم اقسم الإجماليات على مدار أسبوع. إذا تجاوزت النسبة 5 مدخلات إلى 1 مخرج، فتكمن التكلفة في المطالبة، لذا خزّن الجزء الثابت مؤقتاً واختصر الباقي. وإذا كانت النسبة أقل من ذلك، فتكمن التكلفة في الاستجابة، لذا حدّد طولها وانقل الخطوات التي تولّد معظمها إلى نموذج أرخص أو إلى Batch API.