AI Cost Governor و Circuit Break

1. مسئله واقعی: workflow درست می‌تواند از نظر اقتصادی ناامن باشد

یک workflow ممکن است از نظر schema، مدل و خروجی کاملاً درست باشد اما با چند retry، fallback پرهزینه یا مصرف یک tenant، بودجه را به‌سرعت تمام کند. هشدار ماهانه بعد از وقوع هزینه دیر است؛ circuit breaker هم به‌تنهایی بودجه را کنترل نمی‌کند. این درس دو state مستقل می‌سازد: budget/quota state برای مجازبودن مصرف و backend circuit state برای سلامت مسیر اجرا.

خروجی درس یک AI Budget Governor & Backend Circuit State Policy v1 است که پیش از call، worst-case مجاز را با بودجه باقی‌مانده مقایسه می‌کند، retry/fallback را محدود می‌کند و بعد از response نیز actual usage را وارد state می‌کند.

2. چهار هویت را از هم جدا کن: request، job، consumer و backend

request_id یک تلاش منفرد است؛ job_id زنجیره‌ای از تلاش‌ها و fallbackها را جمع می‌کند؛ consumer_id سهم یا quota یک کاربر/سرویس را نگه می‌دارد؛ backend_id مسیر مدل یا سرویس را مشخص می‌کند. اگر همه counters را در یک عدد ادغام کنی، نمی‌توانی تشخیص بدهی مشکل از job پرهزینه است، quota مصرف‌کننده تمام شده یا backend unhealthy شده است.

Policy باید برای هر تصمیم policy_version و scope دقیق counter را ذخیره کند تا audit بتواند بازسازی کند کدام قانون روی کدام هویت اعمال شده است.

3. Budget با quota یکی نیست

Budget یک مرز اقتصادی یا مصرفی برای request/job/consumer است؛ quota می‌تواند window زمانی و counter جدا داشته باشد. در یک fixture ممکن است backend سالم و circuit CLOSED باشد اما quota مصرف‌کننده تمام شده باشد. نتیجه باید QUOTA_BLOCKED باشد، نه CIRCUIT_OPEN و نه MODEL_INELIGIBLE.

Azure API Management در policy فعلی llm-token-limit rate limit و token quota را جدا تعریف می‌کند؛ عبور از rate limit با 429 و عبور از quota با 403 گزارش می‌شود. این فقط یک نمونه vendor است، نه تعریف جهانی policy ما. cite:AZURE-LLM-TOKEN-LIMIT

4. Estimate و actual را هرگز یکی فرض نکن

پیش از call معمولاً فقط estimate داریم. بعد از response، اگر provider actual usage معتبر ارائه کند، state باید با actual به‌روزرسانی شود. Azure نیز مستند می‌کند که بدون prompt estimation، actual usage از response استفاده می‌شود و با estimation ممکن است counters موقتاً یا در concurrency با عدم‌دقت همراه باشند. cite:AZURE-LLM-TOKEN-LIMIT

قاعده MAKNOW: estimated_tokens برای precheck است؛ actual_tokens برای reconciliation بعد از call. برچسب provenance باید روشن کند هر عدد از کجا آمده است.

5. Hard budget و soft budget دو تصمیم متفاوت می‌سازند

hard_budget مرزی است که call جدید نباید بتواند آن را با worst-case مجاز رد کند. soft_budget برای تغییر رفتار است: کاهش کیفیت/طول، انتخاب مسیر کم‌هزینه‌تر، defer یا درخواست تأیید. رسیدن به soft threshold به معنی شکست backend نیست.

Policy باید remaining_budget = hard_budget - committed_actual - reserved_worst_case را قابل بازسازی نگه دارد. اگر worst-case call جدید در remaining نمی‌گنجد، «امید به actual کمتر» دلیل اجرای call نیست.

6. Retry یک حق نامحدود نیست

Retry فقط وقتی مجاز است که هم failure class اجازه دهد، هم retry_count < retry_budget باشد، هم budget برای تلاش بعدی کافی باشد و هم circuit آن backend call را نپذیرفته باشد. Retry-After زمان مناسب retry را پیشنهاد می‌کند، اما به‌تنهایی retry budget یا hard budget را افزایش نمی‌دهد.

اگر backend 429 همراه Retry-After بدهد ولی retry budget صفر باشد، governor باید retry را متوقف کند. این همان جایی است که reliability و cost governance باید با هم دیده شوند.

7. Circuit state را مستقل از spend state نگه دار

حداقل stateهای circuit را CLOSED, OPEN, HALF_OPEN در نظر بگیر. CLOSED یعنی call از نظر circuit مجاز است؛ OPEN یعنی backend موقتاً نباید ترافیک عادی بگیرد؛ HALF_OPEN فقط probe محدود را اجازه می‌دهد. Azure API Management برای backend circuit breaker، failure condition، trip duration و پذیرش Retry-After را مستند می‌کند. cite:AZURE-AI-GATEWAY cite:AZURE-BACKEND-CIRCUIT

اما circuit breaker ثابت نمی‌کند مدل qualified است یا job بودجه دارد. این‌ها gateهای دیگرند.

8. ترتیب تصمیم: precheck قبل از call

مسیر پیشنهادی: identity → quota → hard/soft budget → route eligibility input → circuit state → retry/fallback budget → call → actual usage/failure evidence → state update → final action. هر gate باید reason خودش را حفظ کند.

اگر quota exhausted است، اصلاً لازم نیست آن را به circuit failure تبدیل کنی. اگر circuit open است، call primary متوقف می‌شود حتی اگر بودجه فراوان باشد. اگر هر دو سالم‌اند اما worst-case از remaining budget بزرگ‌تر است، governor از جنس cost تصمیم می‌گیرد.

9. Fallback می‌تواند amplification پنهان بسازد

Fallback معمولاً «راه نجات» دیده می‌شود، اما ممکن است prompt expansion، context window یا قیمت مؤثر بیشتری داشته باشد. بنابراین fallback_count و fallback_amplification باید وارد policy شوند. هر fallback یک مصرف جدید است، نه ادامه رایگان request قبلی.

قبل از fallback، worst-case مسیر جدید را با hard budget باقی‌مانده مقایسه کن. qualified و healthy بودن fallback شرط لازم است، نه شرط کافی برای اجرا.

10. Worked example: retryable backend ولی retry مجاز نیست

Job با hard budget برابر 30k تا این لحظه 22k actual مصرف کرده است. backend اولیه 429 می‌دهد و Retry-After=10s برمی‌گرداند. اما policy حداکثر دو attempt داشته و هر دو استفاده شده‌اند. بودجه شاید هنوز باقی باشد، ولی retry_state=EXHAUSTED است.

تصمیم صحیح DEFER یا route جدیدِ مجاز طبق policy است؛ نه retry سوم. Reason باید RETRY_BUDGET_EXHAUSTED باشد تا incident review آن را با circuit-open اشتباه نگیرد.

11. Worked example: quota تمام شده، circuit سالم است

یک consumer سهم روزانه‌اش را کامل مصرف کرده ولی backend CLOSED و healthy است. اگر request را با reason BACKEND_FAILURE رد کنی، telemetry و remediation غلط می‌شود. state صحیح quota_state=EXHAUSTED, circuit_state=CLOSED, final_action=HARD_STOP است.

در پنجره quota بعدی یا با policy version جدید ممکن است درخواست مجاز شود؛ تا آن زمان retry همان consumer نباید quota را دور بزند.

12. Lab: هشت fixture deterministic

Lab شامل هشت case است: baseline مجاز، quota exhausted، retry budget exhausted با Retry-After، circuit open، عبور actual از soft budget، fallback گران‌تر از remaining hard budget، precheck worst-case که hard budget را رد می‌کند، و probe محدود در HALF_OPEN.

Learner باید تابع evaluate(case) را بسازد و هشت field برگرداند: budget_state, quota_state, circuit_state, retry_state, usage_evidence_state, fallback_state, final_action, reason_class. Oracle فقط در مسیر admin قرار دارد.

13. Shortcutهای ممنوع

سه shortcut خطرناک‌اند: «Retry-After آمد پس حتماً retry کن»، «estimate زیر limit است پس call امن است»، و «fallback سالم است پس هزینه‌اش مهم نیست». هر سه یک gate را جای gate دیگر می‌گذارند.

همچنین cost governor نباید model qualification را اختراع کند. اگر route eligibility از درس‌های مالک خودش BLOCKED/UNKNOWN است، این درس فقط همان state را مصرف می‌کند و آن را به success تبدیل نمی‌کند.

14. Audit record باید تصمیم را بازسازی کند

برای هر attempt ثبت کن: request/job/consumer/backend ID، policy version، estimated و actual tokens با provenance، hard/soft budget، remaining budget، quota/window، retry count/budget، fallback count/amplification، failure signal، Retry-After، circuit before/after، final action و reason class.

اگر reviewer نتواند بفهمد چرا call متوقف، degrade یا defer شده است، governance هنوز evidence-closed نیست.

15. Exit checklist و تمرین انتقال

قبل از PASS نهایی بپرس: آیا hard budget قبل از call enforce می‌شود؟ estimate و actual جدا هستند؟ quota و circuit reason مستقل دارند؟ retry/fallback محدودند؟ OPEN و HALF_OPEN رفتار متفاوت دارند؟ decision به policy version و usage evidence متصل است؟

تمرین انتقال: fallback سالم و qualified است اما worst-case آن 8k token و remaining hard budget فقط 6k است. بدون اجرای call تصمیم را از policy evidence بساز. اگر policy مسیر ارزان‌تر دارد DEGRADE، اگر انتظار مجاز است DEFER، و اگر هیچ مسیر یا انتظار مجاز نیست HARD_STOP؛ «call را بزن شاید کمتر مصرف کند» پاسخ معتبر نیست.