در سیستم‌های ابری کلاسیک، هزینه‌ها با مدت‌زمان فعال‌بودن منابع سنجیده میشوند، اما در مدل‌های زبانی، هر تصمیم مهندسی مثل طول پرامپت یا بافتار حافظه یک تراکنش مالی مستقیم است. فیناپس سنتی در مواجهه با API مدل‌های زبانی از کار می‌افتد؛ زیرا بدون الصاق متادیتای اختصاصی به هر درخواست، مشخص نمی‌شود کدام مشتری یا کدام قابلیت محصول بیشترین مصرف را رقم زده است.
توسعه‌دهندگان در ایران علاوه بر چالش‌های طراحی، با سختی‌های پرداخت ارزی و شارژ حساب‌های خارجی نیز مواجه هستند. عدم شفافیت در هزینه‌ها می‌تواند اعتبارهای ارزی تهیه شده با هزینهی بالا یا گیت‌وی‌های واسط را به‌سرعت مصرف کند و ارائه‌ی پایدار سرویس به مشتریان را به خطر بیندازد.
در این درس می‌آموزید چطور از روز نخست، سه بُعد انتساب هزینه (کاربر، وظیفه، مستأجر) را رهگیری کنید، تفکیک لایه‌های توکن را انجام دهید و با پیاده‌سازی نردبان مهار هزینه شامل محدودیت نرخ و سوییچ قطع اضطراری، سلامت اقتصاد واحد محصول خود را حفظ نمایید.
فیناپس سنتی (Traditional FinOps) در برابر هزینههای مدل‌های زبانی بزرگ (LLM) کم می‌آورد. اینجا هزینه‌ها از جنس تراکنش‌های توکنی هستند، نه آپ‌تایم منابع پردازشی. تگ‌ها هم به کار نمی‌آیند؛ فراخوانی API یک تراکنش است، نه یک دارایی. تصمیم‌های مهندسی (طراحی پرامپت، پنجره‌ی بافتار، طول خروجی) مستقیماً تصمیم‌های مالی هستند. راهنمای عمل سال 2026 سه بُعد انتساب هزینه را مشخص کرده است که باید از همان روز اول پیاده‌سازی شوند: به ازای کاربر (
user_id) برای قیمت‌گذاری بر اساس صندلی و پلن‌های توسعه، به ازای وظیفه (task_id+route) برای محاسبهی هزینهی بخش‌های محصول و اولویت‌بندی آن‌ها، و به ازای مستأجر (tenant_id) برای سنجش اقتصاد واحد (Unit economics) و تمدید قراردادها. چهار لایه‌ی توکن داریم (پرامپت، ابزار، حافظه، پاسخ)؛ جمع‌زدن همه‌ی آن‌ها در یک کاسه هزینههای واقعی را پنهان می‌کند. نردبان مهار هزینه در محصولات چندمستأجری: محدودیت نرخ درخواست (Rate limit) برای هر مستأجر (2 تا 3 برابر اوج مصرف مورد انتظار، همراه با خطای شفاف 429 و هدر Retry-After)؛ سقف هزینهی روزانه (1.5 تا 3 برابر سقف قراردادی؛ با رسیدن به آن، محدودیت نرخ تشدید شده و هشدار ارسال می‌شود)؛ سوییچ قطع اضطراری (Kill switch) با رسیدن z-score هزینه به بیش از 4 نسبت به خط مبنا (توقف خودکار سرویس مستأجر و پیج کردن مهندس در نوبت پاسخگویی). الگوهای انتساب هزینه: تگ‌گذاری و تجمیع (Tag-and-aggregate)، اتصال از طریق تله‌متری (Telemetry-joiner؛ متصل‌کردن شناسه‌ی ردگیری به صورتحساب با بالاترین دقت)، نمونه‌برداری و تعمیم (Sampling-and-extrapolation)، تخصیص مبتنی بر مدل، سیستم‌های مبتنی بر رویداد (Event-sourced)، و استریمینگ لحظه‌ای. سنجهی واحد: هزینه به ازای هر پرسش حلشده یا هر دست‌سازه‌ی تولیدشده؛ نه دلار به ازای هر میلیون توکن. تگ‌گذاری پس از وقوع (Retroactive) همیشه خطا دارد؛ رهگیری را دقیقاً در لحظهی ایجاد درخواست پیاده‌سازی کنید.
اهداف یادگیری
- توضیح دهید چرا فیناپس سنتی (تگ‌ها + پلن‌های ثابت) در مدیریت هزینههای LLM شکست می‌خورد و سه بُعد جدید انتساب هزینه را نام ببرید.
- چهار لایه‌ی توکن (پرامپت، ابزار، حافظه، پاسخ) را بررسی کنید و بگویید چرا صورتحساب تک‌کاسه‌ای هزینه‌ها را پنهان می‌کند.
- یک نردبان مهار هزینه (محدودیت نرخ ← سقف هزینه ← سوییچ قطع اضطراری) برای یک محصول چندمستأجری طراحی کنید.
- یک سنجهی واحد درست (هزینه به ازای هر پرسش حلشده یا هر دست‌سازه) را به‌جای «دلار به ازای هر میلیون توکن» انتخاب کنید.
صورت مسئله
صورتحساب شما 40,000 دلار آمده است، اما نمی‌دانید:
- کدام مستأجر این مبلغ را مصرف کرده است.
- کدام ویژگی محصول عامل اصلی این هزینه بوده است.
- آیا کاربری به‌شکل نامتعارف یا سوءاستفاده‌گرانه از سیستم کار کشیده است یا خیر.
- آیا مقصر اصلی متورم‌شدن پرامپت‌ها بوده، فراخوانی ابزارها، یا رشد بی‌رویه‌ی حافظه.
تگ‌گذاری و تجمیع سمت ارائه‌دهنده‌ی ابری برای منابعی مثل EC2 یا S3 جواب می‌دهد، چون تگ‌ها به ردیفهای صورتحساب منتقل میشوند. اما فراخوانیهای API مدل‌های زبانی خودبه‌خود تگ نمی‌خورند؛ باید در همان نقطه‌ی فراخوانی، شناسه‌ی کاربر، وظیفه و مستأجر را به آن متصل کنید و در کل مسیر پیش ببرید. انتساب پس از وقوع همیشه موارد مرزی و استثنا را جا می‌اندازد.
مفاهیم پایه
سه بُعد انتساب هزینه
به ازای کاربر (user_id): چه کسی چقدر هزینه می‌تراشد. برای قیمت‌گذاری صندلی و مذاکرات ارتقای پلن کاربرد دارد و کاربران پرمصرف را مشخص می‌کند.
به ازای وظیفه (task_id + route): کدام بخش محصول چقدر هزینه برمی‌دارد. به اولویت‌بندی ویژگی‌ها کمک می‌کند و نشان می‌دهد کدام ویژگی‌های پرهزینه باید کنار گذاشته شوند.
به ازای مستأجر (tenant_id): کدام مشتری سودآور است. شالوده‌ی اقتصاد واحد، قیمت‌گذاری برای تمدید قرارداد و تعیین آستانه‌های پلن‌های مختلف است.
ثبت هر سه بُعد را از همان روز اول در محل فراخوانی پیاده‌سازی کنید. پیگیری پس از وقوع همیشه کارایی کمتری دارد.
چهار لایه‌ی توکن
| لایه | مثال | درصد معمول از کل |
|---|---|---|
| پرامپت | ورودی سیستم + ورودی کاربر | 40 تا 60 درصد |
| ابزار | نتایج فراخوانی ابزار که به مدل بازگردانده شده | 20 تا 40 درصد (بارهای کاری ایجنت) |
| حافظه | گفت‌وگوهای قبلی / اسناد بازیابی‌شده | 10 تا 30 درصد |
| پاسخ | خروجی تولیدشده توسط مدل | 10 تا 30 درصد |
اگر همه‌ی این چهار لایه را در یک دسته جمع بزنید، در فرایند بهینه‌سازی سردرگم خواهید شد. آن‌ها را در شِمای انتساب هزینهی خود تفکیک کنید.
نردبان مهار هزینه
-
محدودیت نرخ درخواست به ازای هر مستأجر: 2 تا 3 برابر اوج بار مورد انتظار. خطای 429 را همراه با
Retry-Afterبرگردانید. مستأجر اصطکاک را حس می‌کند، اما صورتحساب غافلگیرکننده‌ای نخواهید داشت. -
سقف هزینهی روزانه به ازای هر مستأجر: 1.5 تا 3 برابر سقف قراردادی. واکنش در صورت عبور: تشدید محدودیت نرخ + ارسال هشدار به تیم موفقیت مشتری.
-
سوییچ قطع اضطراری در صورت رسیدن z-score هزینه به بیش از 4 نسبت به خط مبنای مستأجر: توقف خودکار دسترسی مستأجر؛ پیج‌کردن مهندس در نوبت پاسخگویی (آنکال)؛ ارجاع موضوع به تیم‌های عملیات و موفقیت مشتری.
الگوهای انتساب هزینه
- تگ‌گذاری و تجمیع: ثبت هدرهای متادیتا و تجمیع داده‌ها در زمانی دیگر. ساده است، ولی خروجی تقریبی می‌دهد.
- اتصال با تله‌متری: متصل‌کردن ردگیری‌ها به صورتحساب از طریق شناسه‌ی ردگیری. بالاترین دقت را دارد و تیم‌های باتجربه از آن استفاده می‌کنند.
- نمونه‌برداری و تعمیم: ثبت 5 تا 10 درصد درخواست‌ها و تعمیم آن به کل. برای برآورد هزینه‌ها کم‌هزینه و مناسب است، اما نقاط حاشیه‌ای و پرت توزیع را جا می‌اندازد.
- تخصیص مبتنی بر مدل: استفاده از رگرسیون برای حدس‌زدن عامل هزینه. مناسب داده‌های قدیمی فاقد تگ.
- مبتنی بر رویداد: ثبت داده‌های هزینه بهصورت رویدادهایی در یک جریان داده (مثل Kafka یا Kinesis). کاملاً لحظه‌ای.
- استریمینگ لحظه‌ای: داشبوردهایی که در کسری از ثانیه به‌روزرسانی میشوند.
سنجهی واحد: هزینه به ازای هر X
اصطلاح «دلار به ازای یک میلیون توکن» زبان فروشنده‌هاست. سنجه‌های محصول این‌ها هستند:
- هزینه به ازای هر تیکت پشتیبانی حلشده.
- هزینه به ازای هر مقاله‌ی تولیدشده.
- هزینه به ازای هر وظیفه‌ی موفق ایجنت.
- هزینه به ازای هر دقیقه‌ی نشست کاربر.
هزینه را به خروجی محصول گره بزنید؛ در غیر این صورت، مسیر بهینه‌سازی بی‌هدف و بدون مهار می‌ماند.
ساختار داده‌ی ردگیری برای انتساب هزینه
trace_id: abc123
user_id: u_42
tenant_id: t_7
task_id: task_classify_doc
route: model_haiku
layers:
prompt_tokens: 1800
tool_tokens: 600
memory_tokens: 400
response_tokens: 150
cost_usd: 0.0135
cached_input: true
batch: falseاین ساختار را در هر فراخوانی ثبت و ارسال کنید، در دیتالیک بریزید و بر اساس هر بُعد تجمیع نمایید. این داده‌ها در پشته‌ی رصدپذیری فاز 17 · 13 ذخیره و پردازش میشوند.
پشته‌ی صرفه‌جویی مرکب
راهکارهای پشته: کشینگ + پردازش دسته‌ای (Batch) + مسیریابی هوشمند + گیت‌وی. با فعال‌سازی هر چهار مورد:
- کشینگ لایه 2 (فاز 17 · 14): حدود 10 برابر کاهش هزینهی ورودی.
- پردازش دسته‌ای (فاز 17 · 15): 50 درصد تخفیف.
- مسیریابی به سمت مدل ارزان‌تر (فاز 17 · 16): 60 درصد کاهش هزینه.
- کارایی گیت‌وی (فاز 17 · 19): مدیریت افزونگی و تلاش‌های مجدد.
در بهترین حالت ترکیب این راهکارها: هزینه به حدود 5 تا 10 درصد خط مبنای اولیه و خام می‌رسد. بیشتر تیم‌ها دو یا سه اهرم را فعال می‌کنند، اما کمتر تیمی هر چهار مورد را به کار می‌گیرد.
اعدادی که باید به خاطر بسپارید
- ابعاد انتساب هزینه: به ازای کاربر، به ازای وظیفه، به ازای مستأجر.
- چهار لایه‌ی توکن: پرامپت، ابزار، حافظه، پاسخ.
- سوییچ قطع اضطراری: رسیدن z-score هزینه به بیش از 4.
- سنجهی واحد: هزینه به ازای هر پرسش حلشده، نه دلار به ازای یک میلیون توکن.
- بهینه‌سازی‌های مرکب: کاهش هزینه‌ها تا حدود 5 تا 10 درصد خط مبنا ممکن است.
استفاده از ابزارهای واقعی
فایل code/main.py یک سرویس چندمستأجری LLM را با نردبان مهار سه‌سطحی شبیه‌سازی می‌کند. در این اسکریپت رفتار یک مستأجر پرمصرف تزریق شده و فعال‌شدن سوییچ قطع اضطراری به نمایش درمی‌آید.
خروجی این درس
این درس سند outputs/skill-finops-plan.md را تولید می‌کند که با توجه به نوع محصول و مقیاس کاری، شِمای انتساب هزینه و نردبان مهار هزینه را طراحی خواهد کرد.
تمرین‌ها
- اسکریپت
code/main.pyرا اجرا کنید. سوییچ قطع اضطراری در چه z-scoreای فعال می‌شود؟ چگونه آستانه‌ی مناسب را انتخاب می‌کنید؟ - یک داشبورد هزینه بر اساس مستأجر و بر اساس وظیفه طراحی کنید. 5 نمای ابتدایی که پیاده‌سازی می‌کنید کدام‌ها هستند؟
- اقتصاد واحد بزرگ‌ترین مستأجر شما منفی شده است. سه مداخله پیشنهاد دهید و آن‌ها را بر اساس میزان تأثیر روی مشتری مرتب کنید.
- هزینهی هر تیکت حلشده را برای یک محصول پشتیبانی حساب کنید: 3 میلیون توکن به ازای هر تیکت، حدود 800 تیکت در روز، تمام ورودی‌ها با نرخ کش‌شده‌ی مدل GPT-5 به قیمت 0.125 دلار به ازای هر میلیون توکن (این قیمت زمان عرضه است؛ نرخ‌نامه‌ی رسمی لحظه‌ای را چک کنید).
- استدلال کنید که آیا تگ‌گذاری پس از وقوع اساساً می‌تواند کارآمد باشد؟ در چه شرایطی قابل قبول است؟
اصطلاحات کلیدی
| اصطلاح | در گفتار عامیانه | معنای دقیق فنی |
|---|---|---|
| انتساب به ازای کاربر (Per-user attribution) | «هزینه در سطح کاربر» | ثبت user_id روی تک‌تک فراخوانی‌ها |
| انتساب به ازای وظیفه (Per-task attribution) | «هزینهی فیچر» | ترکیب task_id + route برای تشخیص بخش مربوطه در محصول |
| انتساب به ازای مستأجر (Per-tenant attribution) | «هزینهی مشتری» | ثبت tenant_id؛ پایه‌ی تحلیل اقتصاد واحد |
| چهار لایه‌ی توکن (Four token layers) | «لایه‌های هزینه» | پرامپت + ابزار + حافظه + پاسخ |
| محدودیت نرخ درخواست (Rate limit) | «گارد 429» | سقف مصرف هر مستأجر که در لایه‌ی گیت‌وی اعمال می‌شود |
| سقف هزینهی روزانه (Daily spend cap) | «سقف روزانه» | بودجه‌ی تعریف‌شده در دامنه‌ی مستأجر به همراه ارسال هشدار |
| سوییچ قطع اضطراری (Kill switch) | «توقف خودکار» | رسیدن z-score هزینه به بیش از 4 که تعلیق خودکار را فعال می‌کند |
| هزینه به ازای حل هر مورد (Cost per resolved) | «سنجهی واحد محصول» | اتصال هزینه به خروجی محصول، نه مصرف خام توکن |
| اتصال با تله‌متری (Telemetry joiner) | «اتصال ردگیری به صورتحساب» | دقیق‌ترین الگوی انتساب هزینه |
| بهینه‌سازی مرکب (Stacked optimization) | «ترکیب کش، بچ، روت و گیت‌وی» | تجمیع صرفه‌جویی‌ها برای رساندن هزینه به 5 تا 10 درصد خط مبنا |