كيف تحكمنا في تكاليف تشغيل نماذج LLM بالتوجيه والضمانات - دروس من حادثة $705 في اليوم

نظرة عامة: قصة بدأت بفاتورة بقيمة $705

في الأول من يونيو 2026، ظهر في لوحة تحكم الفواتير الخاصة بـ Anthropic ما يقارب $705 كتكلفة ليوم واحد.

كانت جميع الجلسات التسع تعمل على نموذج Opus. جلسة مراقبة واحدة وحدها استمرت 9.4 ساعات، وأنجزت 1,145 دورة، وسجلت 138 تنبيهًا عبر ScheduleWakeup، مستهلكةً $381. هذه الحلقة المراقبة الواحدة وحدها كانت مسؤولة عن 54% من إجمالي تكاليف اليوم. وبلغت قراءات cache_read 195 مليون رمز، شكّلت 42% من إجمالي الفاتورة.

لم يستغرق الأمر وقتًا طويلًا لتحديد السبب. لم تكن المشكلة في إخفاق ذاكرة التخزين المؤقت. كانت نتيجة تراكم سياق ضخم مع دورات متكررة، مضروبًا في سعر Opus (المدخلات $15/MTok، المخرجات $75/MTok).

يكشف هذا المقال بصدق عن نتائج تدقيق في التكاليف استمر شهرًا كاملًا إثر تلك الحادثة، إلى جانب أربع آليات تحكم نشغلها فعليًا في بيئة الإنتاج. وفي النهاية، نشرح كيف جرى تحويل هذه الخبرة التشغيلية إلى منتجَي ThakiCloud Praxis و AI Platform.

---

أين تتسرب التكاليف: نتائج التدقيق الشهري

بعد الحادثة، حللنا بيانات الفواتير لمدة شهر باستخدام cost_audit.py وrouter_audit.py. من إجمالي التكاليف البالغة $4,691، كان الاكتشاف الأكثر صدمةً هو التالي.

90.3% من التكاليف جاءت من دورات الجلسة الرئيسية لـ Opus. لم تكن العوامل الفرعية هي نقطة التسرب الأكبر، بل كان النموذج الافتراضي للجلسة.

قد يبدو بديهيًا أن “تشغيل عوامل فرعية كثيرة يجعل الأمور أكثر تكلفةً.” غير أن الواقع كان مختلفًا. كانت العوامل الفرعية تستخدم Sonnet بالفعل، وكان معدل الامتثال لتوجيه LLM الفرعي 96.4%. المشكلة أن نموذج الجلسة الرئيسي – المنسق – كان مثبتًا على Opus. مئات من الدورات التي تضمنت عمليات بحث في الملفات، وأسئلة بسيطة، وتنسيق خطوط الأنابيب والتي كان بمقدور Sonnet معالجتها بكفاءة، كلها عولجت بسعر Opus ($15/MTok).

كانت الوفورات المحتملة التي حسبها router_audit.py واضحة. تحويل الجلسة الرئيسية إلى Sonnet سيخلق هامشًا إضافيًا بقيمة $3,388. وتحسين توجيه العوامل الفرعية سيوفر $1,533 إضافية شهريًا، لتصل نسبة التخفيض الإجمالية إلى 80.4%. ما يعني أن أكثر من $3,800 من أصل $4,691 كان إنفاقًا غير ضروري.

ما يحدد التكلفة ليس السعر الوحدوي، بل التكرار. الفرق بين استخدام Opus في 10 دورات يوميًا مقابل 1,000 دورة أكبر بكثير من فرق السعر الوحدوي بين Opus و Sonnet ($15 مقابل $3).

إليك ملخص أسعار النماذج الوحدوية:

النموذج	المدخلات ($/MTok)	المخرجات ($/MTok)	قراءة الذاكرة المؤقتة ($/MTok)	التكلفة النسبية
Haiku	$0.80	$4.00	$0.08	~1x
Sonnet	$3.00	$15.00	$0.30	~4x
Opus	$15.00	$75.00	$1.50	~19x

يبلغ الفرق في سعر المدخلات بين Opus و Haiku نحو 19 ضعفًا. تشغيل مهمة استكشافية واحدة على Haiku بدلًا من Opus يتيح 18 استدعاءً إضافيًا لـ Haiku بالتكلفة الموفرة.

---

توجيه النماذج: طبيعة المهمة تحدد مستوى النموذج

المبدأ الأول الذي وضعناه بناءً على نتائج التدقيق بسيط. حدد دائمًا معامل النموذج بوضوح، واستخدم المستوى المناسب لطبيعة المهمة.

إغفال معامل model عند استدعاء أداة Agent يتسبب في تشغيله على النموذج الافتراضي للجلسة (Opus إن كان كذلك، بسعر $15/MTok). هذا هو أصل تسرب تكاليف العوامل الفرعية. في بيئة Claude Code، القيم الصحيحة هي "haiku" و"sonnet" و"opus". لا حاجة لأي ربط إضافي بمعرّفات أخرى.

إليك كيفية تشغيلنا لجدول التوجيه:

• الاستكشاف، وقراءة الملفات، و grep، وعمليات البحث البسيطة: haiku. عمل للقراءة فقط يحتاج إلى مخرجات منظمة. المهام التي تلخص أو تقارن ثلاثة ملفات أو أكثر تنتمي إلى هنا أيضًا.
• بحث في قاعدة الكود، والتلخيص، والترجمة: haiku. مهام لا تتطلب حكمًا.
• التحليل، والتنفيذ، وتوليد الكود، والمراجعة: sonnet. هذه هي نقطة التوازن بين الجودة والتكلفة؛ معظم المهام تقع هنا.
• توليد التقارير، وكتابة المحتوى: sonnet. الافتراضي للمهام التوليدية.
• قرارات المعمارية، والاستدلال المتعدد الخطوات المعقد، والتصحيح العميق: opus. مبرر في هذه الحالات فحسب.

Agent({
  description: "Explore usage patterns in the codebase",
  model: "haiku",   # exploration/search = haiku, model must be specified
  prompt: "..."
})

نوجّه أيضًا النموذج الافتراضي للجلسة بناءً على طبيعة المهمة. نفتح الجلسات بـ /model sonnet لتنسيق خطوط الأنابيب، والبرمجة اليومية، وعمليات البحث في الملفات. نتحول إلى /model opus فقط عند الحاجة إلى قرارات معمارية.

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

تطبيق هذا التوجيه باستمرار أنتج معدل امتثال للتوجيه الفرعي بنسبة 96.4%. معظم العوامل الاستكشافية الـ 55 تعمل الآن على Haiku. قد تبدو الوفورات لكل مهمة فردية صغيرة، لكن مئات المهام الاستكشافية يوميًا تتراكم لتصنع فارقًا بقيمة $1,533 شهريًا.

تُعدّ إدارة دورة حياة الجلسة مهمةً أيضًا. عندما تتجاوز الجلسة 50 دورة أو يتجاوز السياق 40%، نبدأ من جديد بـ /clear. في الجلسات الضخمة، تنمو تكاليف cache_read خطيًا مع كل دورة مع تضخم السياق. هذا هو سبب بلوغ تكاليف cache_read 42% من الإجمالي في حادثة 1 يونيو.

---

الترقية التلقائية المبنية على المراجعة: البيانات تحدد النموذج

الحجة المضادة الواقعية القائلة إن “تثبيت جميع المهارات على Sonnet سيدمر الجودة” صحيحة. المهارات التي تكون جودة مخرجاتها هي المنتج نفسه – كتصنيف المحتوى، والإثراء، وكتابة الخيوط – تقصر Sonnet فعليًا في بعض الأحيان. لهذا اخترنا الترقية المبنية على المراجعة.

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

القيمة الافتراضية هي البداية بـ Sonnet. إذا تجاوزت حالات الإخفاق المتتالية 2، فإن تلك المهارة وحدها تُرقَّى تلقائيًا إلى Opus. يؤدي التشغيل النظيف إلى إعادة تعيين التتالي، لكن لا يوجد تراجع تلقائي. بمجرد أن تحتاج مهارة إلى Opus، لا تُخفَّض إلا يدويًا. تُرسل إشعارات Slack عند الإخفاق والترقية.

يتكون التنفيذ من ملفين.

يعمل scripts/skills/skill_model_policy.json كسجل مركزي.

{
  "skills": {
    "twitter-timeline-to-slack": {
      "model": "opus",
      "pinned": true,
      "reason": "classification+enrichment+thread writing quality threshold",
      "fail_streak": 0
    }
  },
  "_default": {
    "model": "sonnet",
    "escalate_to": "opus",
    "max_fail_streak": 2,
    "fail_streak": 0
  }
}

يجلب المشغّل النموذج من السياسة قبل التنفيذ، ويسجل المراجعة عند الخروج.

SKILL_NAME="bespin-news-digest"
MODEL="${MY_MODEL:-$(python3 scripts/skills/skill_retro.py get-model "$SKILL_NAME" 2>/dev/null || echo sonnet)}"

# ... run claude -p --model "$MODEL" ...

python3 scripts/skills/skill_retro.py record "$SKILL_NAME" "$RC" "$RUN_LOG" 2>/dev/null || true

اكتشاف حالات الإخفاق محافظ. نحسب فقط rc != 0 أو علامات السجل: Failed to authenticate، وAPI Error:، وTraceback. خطأ شبكي عابر واحد لا يُطلق الترقية. يجب أن يتراكم التتالي. هذا التحفظ مهم. الكشف العدواني سيرفع كل اضطراب عابر إلى Opus، ما يلغي فائدة التحكم في التكاليف.

إزالة مفتاح النموذج لمهارة معينة من EnvironmentVariables في plist يتيح للسياسة أن تعمل. نضيف متغير البيئة مرة أخرى فقط عند الحاجة إلى تجاوز يدوي. هذا الهيكل يعني أننا لا نحتاج إلى قرار مسبق بشأن “أي نموذج نستخدم” عند إضافة مهارة جديدة. ابدأ بـ Sonnet، والبيانات ستُرقّيه.

عندما تبدو الجودة غير كافية، أول شيء يجب فعله هو إضافة خطوة تحقق. قبل ترقية النموذج، جرب إرفاق خطوة تحقق عكسي بنتائج fan-out. السبب الأكثر شيوعًا لمشكلات الجودة ليس ضعف النموذج، بل غياب مرحلة التحقق. تكوين العمال بتكلفة منخفضة مع وضع خطوة التحقق النهائية فقط على Opus يُعظم الجودة مقابل التكلفة.

---

نقل الحلقات إلى cron ونظافة السياق

كانت جلسة المراقبة التي شكّلت 54% من حادثة 1 يونيو مهمةً لا يحتاج فيها Claude إلى الحكم في كل نبضة. يمكن تشغيل لقطات الأسعار، ومقارنات الحالة، وفحوصات الصحة دون Claude.

انقل المراقبة المتكررة من الحلقة الساخنة لـ Claude إلى cron. التكلفة تصبح $0.

# Run every 5 minutes; Slack alert only on anomaly detection
# com.thaki.toss-monitor.plist
scripts/toss_monitor_tick.sh

المبدأ الجوهري لهذا النمط هو “استدعِ Claude فقط عند وجود إنسان أو حدث.” تتولى نصوص الشل جميع عمليات استطلاع الحالة؛ لا يُوقظ Claude إلا عند تجاوز عتبة أو رصد إشارة شاذة. كانت 138 دورة ScheduleWakeup التي أحرقت $381 ذلك اليوم في معظمها عمليات فحص حالة بسيطة. استخراج تلك المهام إلى cron يعني عدم نشوء أي تكاليف لـ Claude أصلًا.

إذا كانت حلقة Claude ضرورية فعليًا، نلتزم بثلاث قواعد.

أولًا، نستخدم Haiku أو Sonnet فحسب. Opus غير مبرر للمراقبة. إهدار نموذج يكلف 19 ضعفًا في مقارنات الحالة البسيطة أمر مرفوض. ثانيًا، نحتفظ بالحالة في ملف (monitor-state.json) حتى تبدأ كل نبضة بسياق أدنى. نقرأ ملف الحالة فحسب ونصدر حكمًا، بدلًا من سحب تاريخ المحادثة الكامل. ثالثًا، نشغّل /clear قبل أن تتجاوز الجلسة 50 دورة أو 40% من السياق.

نستعرض الأنماط المضادة المحددة التي كشفتها حادثة 1 يونيو في نظافة السياق. جرى قراءة الملف نفسه 10 مرات ضمن جلسة واحدة. نُفِّذ أمر cd 153 مرة، مع أن git يعمل مباشرةً على دليل العمل الحالي دون الحاجة إلى بادئة cd. أُلقيت مخرجات ضخمة خامًا في السياق الرئيسي. هذه العوامل الثلاثة رفعت تكاليف cache_read إلى 42% من الإجمالي.

ضمن جلسة واحدة، لا تُعِد أبدًا قراءة ملف تمت قراءته بالفعل. اكتب مخرجات الأدوات الكبيرة في /tmp/scratch-{task}.md وأعد المسار فقط إلى الجلسة الرئيسية. إذا كانت مخرجات مصفوفة JSON ذات البنية المتكررة كثيفة، استخدم ضغط headroom SmartCrusher. [تقديري] تُظهر المعايير إمكانية تحقيق توفير بنسبة 50% أو أكثر. إضافة البادئة rtk تضغط أيضًا مخرجات الشل بنسبة 60-90%.

---

Praxis وAI Platform: تحويل الخبرة التشغيلية إلى منتج

ترجمت هذه الخبرة التشغيلية إلى منتجَي ThakiCloud.

موجّه LLM المدرك للتكاليف في Praxis يتحول تلقائيًا إلى نماذج أقل تكلفةً مع تناقص هامش الميزانية. منطق الاختيار التلقائي للنموذج خطوة بخطوة المشروح أعلاه مُنفَّذ على مستوى المنتج. عندما يُستهلك 70% من الميزانية الشهرية، ينزل النموذج الافتراضي إلى Sonnet؛ وفوق 90%، يتراجع إلى Haiku. المهارات ذات عتبة الجودة الحرجة مثبّتة ومستثناة من التراجع.

تتبع التكاليف والتحكم في الحصص في AI Platform يجمع تكاليف LLM بشكل منفصل لكل فريق ومشروع. تجري المنصة عمليات تدقيق مكافئة لـ cost_audit.py تلقائيًا، وترسل تنبيهًا عندما تتجاوز حصة استخدام Opus لفريق معين عتبة محددة. هذا تطبيق لنفس المنهجية المتبعة في تنسيق أعباء عمل GPU باستخدام Kubernetes Kueue – على ميزانيات رموز LLM.

claude-code-ccr-cost-routing هو تحسين في اتجاه مختلف. يبقى النموذج الرئيسي على Anthropic، بينما تُوجَّه العوامل الفرعية إلى مزودين خارجيين (MiniMax وGLM وDeepSeek وQwen). يُعالَج الاستكشاف والتلخيص والترجمة بأسعار وحدوية أقل بكثير من Sonnet، مع الحفاظ على اتساق المنسق الرئيسي.

هذه الأساليب الثلاثة تشترك في شيء واحد. التكلفة لا تُترك للصدفة؛ الكود يتحكم فيها بشكل حتمي.

---

القيود والدروس المستفادة

ثمة قيود يجب أن نكشفها بصدق.

الترقية المبنية على المراجعة لا تتضمن تراجعًا تلقائيًا. المهارات المُرقّاة إلى Opus لا يمكن تخفيضها إلا يدويًا. مع مرور الوقت، قد يتزايد عدد مهارات Opus المثبّتة. المراجعة اليدوية الدورية ضرورية. هذا خيار تصميمي متعمد. الحكم المحافظ هو “لا تخفّض مهارة احتاجت مرةً إلى Opus دون بيانات”، والمقايضة هي قبول احتمال التباعد.

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

ضمانات التكلفة وحدها لا يمكن أن تحل محل الجودة. الآليات الموصوفة في هذا المقال تدور حول الحفاظ على الجودة مع تخفيض التكاليف – لا التضحية بالجودة لتخفيض التكاليف. إذا انخفضت الجودة في مهارة معينة، فإن التصميم يقضي بارتفاعها طبيعيًا إلى Opus عبر التتالي.

الدرس الأكبر هو: تكلفة النموذج لا يحددها سعره الوحدوي، بل تكرار اختيار النموذج. حتى لو كان سعر Opus $15/MTok، إذا نادرًا ما يُستخدم Opus تبقى التكاليف منخفضة. وعلى العكس، حتى لو كان Haiku بسعر $0.80/MTok، تشغيله في حلقة من 1,145 دورة يُولّد تكاليف كبيرة.

الدرس الثاني هو: شخّص أولًا السبب الجذري لمشكلات الجودة. عندما تشعر أن Sonnet غير كافٍ، أول ما يجب التحقق منه ليس مستوى النموذج بل وجود أو غياب خطوة تحقق. إذا استُهلكت نتائج fan-out دون تحقق عكسي، ستكون الجودة غير مستقرة حتى مع Opus. تكوين العمال بتكلفة منخفضة مع وضع البوابة النهائية فقط على Opus هو التوجه الصحيح.

ترتيب التبني الصحيح هو التالي:

1. أخرج الحلقات والمراقبة إلى cron، مما يُلغي تكاليف Claude كليًا.
2. اخفض النموذج الافتراضي للجلسة إلى Sonnet. هذه أكبر رافعة على إجمالي التكاليف.
3. اجعل معامل model إلزاميًا في جميع استدعاءات العوامل الفرعية.
4. شغّل cost_audit.py لأسبوع لتدقيق التكاليف وتحديد نقاط التسرب.
5. رقِّ فقط المهارات التي تعاني من قصور حقيقي في الجودة إلى Opus عبر آلية المراجعة.
6. كرر التدقيق بشكل دوري وعدّل بالنظر في الأرقام.

اتباع هذا الترتيب يمنع تكرار حادثة $705 في اليوم. في الوقت ذاته، يترسّخ نظام تعمل فيه المهام التي تكفيها جودة Sonnet على Sonnet، والاستكشافات التي يكفيها Haiku على Haiku.

---

تعكس ThakiCloud هذه الخبرة التشغيلية في Praxis وAI Platform. إذا كنت تتساءل عن كيفية عمل توجيه LLM المدرك للتكاليف كمنتج، تواصل معنا على hello@thakicloud.co.kr.