هزینه API هوش مصنوعی چگونه محاسبه می‌شود؟ راهنمای کامل قیمت متن، تصویر، صوت و ویدئو

یکی از نخستین پرسش‌های توسعه‌دهندگان و کسب‌وکارها پیش از استفاده از مدل‌های هوش مصنوعی این است:

هزینه API هوش مصنوعی دقیقاً چگونه محاسبه می‌شود؟

پاسخ کوتاه این است که روش محاسبۀ هزینه به نوع مدل، ارائه‌دهنده، ورودی، خروجی و قابلیت‌های استفاده‌شده بستگی دارد.

هزینۀ مدل‌های زبانی معمولاً براساس تعداد توکن‌های ورودی و خروجی محاسبه می‌شود، اما این روش برای تمام سرویس‌ها یکسان نیست. تولید تصویر ممکن است براساس توکن تصویر، تعداد تصویر، ابعاد یا کیفیت خروجی قیمت‌گذاری شود. مدل‌های صوتی ممکن است براساس دقیقه، ثانیه، کاراکتر یا توکن صوت محاسبه شوند و مدل‌های ویدئویی نیز می‌توانند به مدت، وضوح، نرخ فریم، تعداد پیکسل یا تعداد توکن تولیدشده وابسته باشند.

اگر Agent، جست‌وجوی وب، اجرای کد، ابزار خارجی، RAG یا Fallback نیز به درخواست اضافه شود، هزینۀ نهایی دیگر فقط قیمت یک فراخوانی مدل نیست.

به همین دلیل برای محاسبۀ واقعی هزینۀ API باید تمام اجزای چرخه پردازش را در نظر گرفت:

هزینۀ مدل
+ هزینۀ ورودی
+ هزینۀ خروجی
+ هزینۀ ابزارها
+ هزینۀ Retry و Fallback
+ هزینۀ ذخیره‌سازی و پردازش
+ هزینۀ زیرساخت
= هزینۀ واقعی هر عملیات

در این مقاله، انواع روش‌های قیمت‌گذاری API هوش مصنوعی را بررسی می‌کنیم و با فرمول‌ها و مثال‌های عملی نشان می‌دهیم چگونه هزینۀ متن، تصویر، صوت، ویدئو، Embedding، RAG و Agentها را محاسبه کنید.

نرخ مدل‌ها دائماً تغییر می‌کند؛ بنابراین برای قیمت نهایی همیشه باید جدول قیمت روز مدل انتخاب‌شده را بررسی کنید. فرمول‌ها و مثال‌های این مقاله مستقل از یک قیمت خاص طراحی شده‌اند و با جایگزین کردن نرخ روز مدل قابل‌استفاده‌اند.

پاسخ کوتاه: هزینه API هوش مصنوعی چگونه محاسبه می‌شود؟

هزینۀ API هوش مصنوعی معمولاً از ضرب میزان مصرف در نرخ واحد مدل به دست می‌آید:

هزینۀ درخواست = میزان مصرف × قیمت واحد

اما «میزان مصرف» و «قیمت واحد» برای انواع مختلف مدل متفاوت‌اند:

تفاوت API رایگان، اشتراک ماهانه و پرداخت براساس مصرف

یکی از اشتباهات رایج، یکسان دانستن اشتراک یک برنامۀ چت با API آن است.

اشتراک ماهانه

در اشتراک ماهانه، کاربر مبلغی ثابت برای استفاده از یک محصول آماده مانند رابط چت پرداخت می‌کند. این اشتراک معمولاً محدودیت‌های خاص خود را دارد و الزاماً شامل اعتبار API نیست.

پرداخت براساس مصرف

در API، هزینۀ استفاده معمولاً براساس میزان مصرف واقعی محاسبه می‌شود:

• تعداد توکن
• تعداد تصویر
• مدت صوت
• مدت ویدئو
• تعداد درخواست
• تعداد فراخوانی ابزار

برای مثال، داشتن اشتراک پولی یک برنامۀ چت لزوماً به معنی برخورداری از اعتبار API همان شرکت نیست. در بسیاری از پلتفرم‌ها، مصرف API صورتحساب مستقل دارد.

اعتبار رایگان

برخی ارائه‌دهندگان ممکن است اعتبار آزمایشی، Free Tier یا سهمیه محدود رایگان ارائه کنند. این اعتبار معمولاً دارای محدودیت‌هایی مانند موارد زیر است:

• تاریخ انقضا
• تعداد درخواست
• مدل‌های محدود
• سرعت کمتر
• عدم امکان استفاده تجاری
• محدودیت منطقه‌ای
• نیاز به ثبت روش پرداخت

Free Tier را نباید مبنای پیش‌بینی هزینۀ محصول Production قرار داد.

توکن چیست؟

توکن واحدی است که مدل‌های زبانی برای پردازش متن استفاده می‌کنند. یک توکن الزاماً برابر با یک کلمه نیست و می‌تواند شامل موارد زیر باشد:

• یک کلمۀ کامل
• بخشی از یک کلمه
• علامت نگارشی
• عدد
• فاصله
• ترکیبی از کاراکترها

برای نمونه، یک جملۀ فارسی ممکن است از نظر تعداد کلمه کوتاه باشد، اما به تعداد بیشتری توکن تبدیل شود. نیم‌فاصله، شیوۀ نگارش، واژه‌های انگلیسی و علائم نیز می‌توانند بر تعداد توکن اثر بگذارند.

به همین دلیل، تخمین هزینه براساس تعداد کلمه دقیق نیست. مبنای Billing باید تعداد توکن گزارش‌شده توسط مدل یا ارائه‌دهنده باشد.

توکن ورودی شامل چه چیزهایی است؟

توکن ورودی فقط متن آخرین پیام کاربر نیست. در یک درخواست Chat Completions، تمام محتوای ارسال‌شده می‌تواند بخشی از ورودی باشد:

• System Prompt
• پیام فعلی کاربر
• تاریخچۀ مکالمه
• پاسخ‌های قبلی Assistant
• تعریف ابزارها
• JSON Schema
• متن بازیابی‌شده از RAG
• محتوای فایل
• ورودی تصویر تبدیل‌شده به توکن
• Metadata پردازش‌شده توسط مدل
• نتیجۀ Tool Call
• نمونه‌های Few-shot

فرض کنید پیام جدید کاربر تنها ۳۰ توکن باشد، اما همراه آن موارد زیر نیز ارسال شوند:

System Prompt: 500 توکن
تاریخچه مکالمه: 4,000 توکن
متن بازیابی‌شده از اسناد: 3,000 توکن
تعریف ابزارها: 1,000 توکن
پیام جدید: 30 توکن

مصرف ورودی تقریباً برابر است با:

500 + 4,000 + 3,000 + 1,000 + 30
= 8,530 توکن ورودی

بنابراین کوتاه بودن پیام جدید به معنی ارزان بودن درخواست نیست.

توکن خروجی چیست؟

توکن خروجی متن یا داده‌ای است که مدل تولید می‌کند. این بخش می‌تواند شامل موارد زیر باشد:

• پاسخ متنی
• کد
• JSON
• آرگومان Tool Call
• توضیح مدل
• بخش‌هایی از پاسخ Streaming
• توکن‌های استدلال قابل‌محاسبه

در اغلب مدل‌ها، قیمت توکن خروجی از توکن ورودی بیشتر است؛ زیرا تولید هر توکن نیازمند اجرای مرحلۀ جدیدی از استنتاج است.

این تفاوت به آن معناست که کنترل طول خروجی معمولاً یکی از مهم‌ترین روش‌های کنترل هزینه است.

فرمول محاسبۀ هزینه مدل زبانی

اگر قیمت مدل برای هر یک میلیون توکن اعلام شده باشد:

هزینۀ ورودی =
(تعداد توکن ورودی ÷ 1,000,000)
× قیمت یک میلیون توکن ورودی

هزینۀ خروجی =
(تعداد توکن خروجی ÷ 1,000,000)
× قیمت یک میلیون توکن خروجی

هزینۀ کل درخواست =
هزینۀ ورودی + هزینۀ خروجی

نسخۀ یک‌خطی فرمول:

Total Cost =
(Input Tokens × Input Price
+ Output Tokens × Output Price)
÷ 1,000,000

مثال محاسبۀ هزینه یک درخواست متنی

فرض کنید قیمت فرضی یک مدل به شکل زیر باشد:

ورودی: 2 دلار برای یک میلیون توکن
خروجی: 8 دلار برای یک میلیون توکن

مصرف یک درخواست:

توکن ورودی: 12,000
توکن خروجی: 1,500

هزینۀ ورودی:

12,000 ÷ 1,000,000 × 2
= 0.024 دلار

هزینۀ خروجی:

1,500 ÷ 1,000,000 × 8
= 0.012 دلار

هزینۀ کل:

0.024 + 0.012
= 0.036 دلار

این نرخ‌ها صرفاً برای آموزش فرمول هستند و قیمت واقعی یک مدل خاص محسوب نمی‌شوند.

چرا قیمت ورودی و خروجی متفاوت است؟

مدل ورودی را در یک فرایند پردازش می‌کند، اما برای تولید پاسخ باید توکن‌ها را به‌صورت مرحله‌به‌مرحله بسازد. به همین دلیل در بسیاری از مدل‌ها، توکن خروجی گران‌تر است.

این موضوع چند نتیجۀ عملی دارد:

• پاسخ‌های طولانی می‌توانند بخش مهمی از هزینه باشند.
• درخواست «خیلی کامل توضیح بده» ممکن است هزینه را افزایش دهد.
• خروجی JSON فشرده معمولاً از توضیح آزاد طولانی ارزان‌تر است.
• max_tokens یا محدودیت خروجی باید منطقی باشد.
• انتخاب مدل گران برای پاسخ‌های ساده ممکن است اقتصادی نباشد.

قیمت هر هزار توکن چگونه محاسبه می‌شود؟

اگر قیمت برای یک میلیون توکن اعلام شده باشد، قیمت هر هزار توکن برابر است با:

قیمت هر 1,000 توکن =
قیمت هر 1,000,000 توکن ÷ 1,000

اگر قیمت یک میلیون توکن ورودی ۳ دلار باشد:

3 ÷ 1,000 = 0.003 دلار

بنابراین هر هزار توکن ورودی ۰٫۰۰۳ دلار هزینه دارد.

بااین‌حال، بهتر است محاسبات مالی با واحد یک میلیون توکن انجام شوند تا خطای گرد کردن کاهش یابد.

تبدیل هزینه دلاری به ریال یا تومان

اگر هزینۀ درخواست به دلار محاسبه شود:

هزینۀ ریالی =
هزینۀ دلاری × نرخ تبدیل دلار به ریال

برای تبدیل ریال به تومان:

هزینۀ تومانی =
هزینۀ ریالی ÷ 10

در یک پلتفرم واقعی ممکن است عوامل دیگری نیز به مبلغ نهایی اضافه شوند:

• کارمزد سرویس
• ضریب ارائه خدمات
• مالیات
• هزینۀ پرداخت
• اختلاف نرخ تبدیل
• حداقل مبلغ قابل‌کسر
• روش گرد کردن
• هزینه زیرساخت
• قیمت خاص هر Provider

بنابراین مبلغ کسرشده از کیف پول لزوماً برابر با ضرب خام قیمت دلاری مدل در نرخ ارز نیست. روش قیمت‌گذاری سرویس باید به‌صورت شفاف در مستندات آن توضیح داده شود.

مثال کامل تبدیل هزینه به تومان

فرض کنید:

هزینۀ مدل: 0.036 دلار
نرخ فرضی دلار: 600,000 ریال
ضریب خدمات: 1.3

ابتدا هزینه ریالی خام:

0.036 × 600,000
= 21,600 ریال

پس از اعمال ضریب:

21,600 × 1.3
= 28,080 ریال

تبدیل به تومان:

28,080 ÷ 10
= 2,808 تومان

این مثال فرضی است. نرخ ارز، ضریب خدمات، حداقل کسر و قیمت مدل باید از تنظیمات واقعی سیستم خوانده شوند.

قیمت Prompt Cache چگونه محاسبه می‌شود؟

در بسیاری از کاربردها، بخش بزرگی از ورودی تکراری است:

• System Prompt
• اسناد ثابت
• تعریف ابزارها
• دستورالعمل سازمانی
• نمونه‌های Few-shot
• بخش ثابت کد

Prompt Caching می‌تواند این بخش تکراری را با نرخ متفاوتی پردازش کند.

قیمت‌گذاری Cache معمولاً یکی از این الگوها را دارد:

• توکن ورودی Cache‌شده ارزان‌تر از ورودی عادی
• هزینه جداگانه برای نوشتن Cache
• هزینه متفاوت برای Cache با TTLهای مختلف
• هزینه کمتر برای Cache Hit
• حداقل اندازۀ ورودی برای فعال شدن Cache

فرمول عمومی:

هزینۀ ورودی =
هزینۀ توکن معمولی
+ هزینۀ Cache Write
+ هزینۀ Cache Read

در مستندات رسمی ارائه‌دهندگانی مانند OpenAI و Anthropic، ورودی معمولی، ورودی Cache‌شده و در برخی موارد نوشتن Cache نرخ‌های متفاوتی دارند. قیمت‌ها و جزئیات هر مدل باید در زمان استفاده از منابع رسمی بررسی شوند. قیمت API شرکت OpenAI، قیمت API شرکت Anthropic

مثال محاسبۀ Prompt Cache

فرض کنید یک درخواست شامل موارد زیر باشد:

توکن ورودی جدید: 2,000
توکن خوانده‌شده از Cache: 20,000
توکن خروجی: 1,000

قیمت‌های فرضی:

ورودی عادی: 4 دلار به‌ازای یک میلیون توکن
Cache Read: 0.4 دلار به‌ازای یک میلیون توکن
خروجی: 12 دلار به‌ازای یک میلیون توکن

هزینۀ ورودی جدید:

2,000 ÷ 1,000,000 × 4
= 0.008 دلار

هزینۀ Cache:

20,000 ÷ 1,000,000 × 0.4
= 0.008 دلار

هزینۀ خروجی:

1,000 ÷ 1,000,000 × 12
= 0.012 دلار

هزینۀ کل:

0.008 + 0.008 + 0.012
= 0.028 دلار

بدون Cache، همان ۲۰ هزار توکن با نرخ ورودی عادی محاسبه می‌شد و هزینۀ بیشتری داشت.

آیا Prompt Cache همیشه هزینه را کاهش می‌دهد؟

خیر. Cache زمانی مفید است که:

• بخش بزرگی از Prompt تکراری باشد.
• درخواست‌ها به‌اندازۀ کافی پرتعداد باشند.
• محتوا پیش از انقضای Cache دوباره استفاده شود.
• حداقل توکن لازم برای Cache فراهم باشد.
• نوشتن Cache نسبت به تعداد Cache Hit توجیه داشته باشد.

اگر محتوا فقط یک‌بار استفاده شود، هزینۀ Cache Write ممکن است هیچ صرفه‌جویی ایجاد نکند.

توکن‌های استدلال چگونه محاسبه می‌شوند؟

برخی مدل‌های Reasoning پیش از تولید پاسخ نهایی، محاسبات داخلی بیشتری انجام می‌دهند. بسته به مدل و API، این مصرف ممکن است در قالب‌های مختلف گزارش شود:

• Reasoning Tokens
• Thinking Tokens
• Output Token Details
• Hidden Reasoning
• Billed Output Tokens

نکات مهم:

• توکن استدلال الزاماً در متن نهایی دیده نمی‌شود.
• ممکن است در محدودیت خروجی محاسبه شود.
• ممکن است با نرخ توکن خروجی قیمت‌گذاری شود.
• روش گزارش آن بین ارائه‌دهندگان متفاوت است.
• کوتاه بودن پاسخ نهایی لزوماً به معنی مصرف کم نیست.

برای Billing نباید هزینۀ مدل استدلالی را فقط از روی طول متن قابل‌مشاهده تخمین زد. اطلاعات Usage برگشتی و مستندات مدل باید مبنا باشند.

هزینه مکالمات چندمرحله‌ای

در یک چت، معمولاً تاریخچۀ پیام‌ها همراه هر درخواست جدید دوباره ارسال می‌شود.

فرض کنید مصرف ورودی در پنج پیام به شکل زیر افزایش یابد:

مصرف کل ورودی برابر با ۵ هزار توکن پیام آخر نیست:

500 + 1,300 + 2,400 + 3,700 + 5,000
= 12,900 توکن

مصرف کل خروجی:

300 + 400 + 500 + 550 + 600
= 2,350 توکن

این رشد تجمعی یکی از دلایل افزایش هزینۀ چت‌های طولانی است.

راه‌های کنترل هزینه مکالمه

• حذف پیام‌های غیرضروری
• نگهداری تعداد محدودی پیام اخیر
• خلاصه‌سازی پیام‌های قدیمی
• بازیابی فقط پیام‌های مرتبط
• ذخیرۀ اطلاعات پایدار در ساختار جداگانه
• محدود کردن طول پاسخ
• استفاده از مدل اقتصادی برای خلاصه‌سازی

هزینۀ System Prompt

System Prompt در هر درخواست ارسال می‌شود، مگر اینکه API یا مدل سازوکار دیگری مانند Cache داشته باشد.

فرض کنید System Prompt برابر ۲ هزار توکن باشد و روزانه ۱۰۰ هزار درخواست ارسال شود:

2,000 × 100,000
= 200,000,000 توکن ورودی در روز

اگر نرخ فرضی ورودی ۲ دلار برای یک میلیون توکن باشد:

200 × 2
= 400 دلار در روز

این مثال نشان می‌دهد کوتاه‌سازی System Prompt پرتکرار می‌تواند اثر مالی قابل‌توجهی داشته باشد.

System Prompt نباید صرفاً برای کوتاه شدن، کیفیت یا امنیت خود را از دست بدهد. باید محتوای تکراری، توضیح اضافه و نمونه‌های غیرضروری حذف شوند.

هزینه Tool Calling

Tool Calling حداقل شامل دو درخواست مدل است:

1. مدل تشخیص می‌دهد چه ابزاری فراخوانی شود.
2. برنامۀ شما ابزار را اجرا می‌کند.
3. نتیجۀ ابزار به مدل ارسال می‌شود.
4. مدل پاسخ نهایی را تولید می‌کند.

هزینۀ واقعی:

هزینۀ درخواست اول مدل
+ هزینۀ اجرای ابزار
+ هزینۀ درخواست دوم مدل

اگر ابزار خروجی بزرگی داشته باشد، نتیجۀ آن به توکن ورودی درخواست دوم تبدیل می‌شود.

برای مثال:

درخواست اول: 3,000 توکن ورودی + 100 توکن خروجی
نتیجۀ ابزار: 8,000 توکن
درخواست دوم: 11,100 توکن ورودی + 800 توکن خروجی

بنابراین Tool Call ساده ممکن است مصرف ورودی را چند برابر کند.

هزینه‌های احتمالی ابزار

• API جست‌وجوی وب
• API نقشه
• API مالی
• پایگاه داده
• سرویس ارسال پیامک
• پردازش فایل
• اجرای کد
• مرورگر ابری
• فضای اجرای Container
• سرویس OCR
• API شخص ثالث

فراخوانی ابزار ممکن است مستقل از مدل هزینه داشته باشد.

هزینه Agent هوش مصنوعی

Agent ممکن است برای انجام یک وظیفه چند بار مدل و ابزارها را فراخوانی کند.

فرمول عمومی:

هزینۀ Agent =
مجموع هزینه تمام فراخوانی‌های مدل
+ مجموع هزینه تمام ابزارها
+ هزینه حافظه و بازیابی
+ هزینه زیرساخت اجرا

اگر Agent در هر اجرا به‌طور متوسط:

• ۸ بار مدل را فراخوانی کند
• ۳ جست‌وجوی وب انجام دهد
• ۲ Query پایگاه داده اجرا کند
• یک فایل تولید کند

هزینۀ هر اجرای Agent بسیار بیشتر از یک درخواست ساده Chat Completion خواهد بود.

فرمول دقیق‌تر

Agent Cost =
Σ Model Call Costs
+ Σ Tool Call Costs
+ Embedding Costs
+ Retrieval Costs
+ Storage Costs
+ Compute Costs

خطر Loop

Agent ممکن است وارد حلقه شود:

فکر کردن
→ اجرای ابزار
→ دریافت نتیجه
→ فکر کردن
→ اجرای ابزار دیگر
→ تکرار

برای جلوگیری از مصرف کنترل‌نشده باید محدودیت تعریف شود:

• حداکثر تعداد مراحل
• حداکثر فراخوانی مدل
• حداکثر Tool Call
• حداکثر زمان اجرا
• حداکثر توکن
• حداکثر هزینه
• نیاز به تأیید برای ادامۀ عملیات

مثال هزینه یک Agent

فرض کنید Agent در یک اجرا سه مدل را فراخوانی کند:

هزینۀ کل:

0.008 + 0.012 + 0.02 + 0.01 + 0.002
= 0.052 دلار

اگر این Agent روزانه ۲۰ هزار بار اجرا شود:

0.052 × 20,000
= 1,040 دلار در روز

بنابراین پیش از عرضه Agent باید هزینه هر اجرای موفق، ناموفق و متوسط اندازه‌گیری شود.

هزینه Embedding چگونه محاسبه می‌شود؟

مدل‌های Embedding معمولاً براساس توکن ورودی قیمت‌گذاری می‌شوند و خروجی متنی ندارند.

فرمول:

هزینۀ Embedding =
(تعداد توکن ورودی ÷ 1,000,000)
× قیمت یک میلیون توکن Embedding

فرض کنید:

حجم اسناد: 50,000,000 توکن
قیمت فرضی: 0.10 دلار برای یک میلیون توکن

هزینۀ ساخت اولیه Embedding:

50 × 0.10
= 5 دلار

اما این تمام هزینۀ سیستم برداری نیست. هزینه‌های دیگر شامل موارد زیر هستند:

• Chunking
• ذخیره بردارها
• Vector Database
• Metadata
• Query
• Backup
• Replication
• Re-embedding
• Reranking
• مدل پاسخ‌دهنده

چرا تغییر مدل Embedding هزینه دارد؟

بردارهای دو مدل Embedding مختلف معمولاً در یک فضای برداری مشترک نیستند. اگر مدل Embedding را عوض کنید، ممکن است مجبور شوید تمام اسناد را دوباره پردازش کنید.

هزینۀ مهاجرت:

هزینۀ Re-embedding
+ پردازش اسناد
+ ساخت Index جدید
+ ذخیره‌سازی موازی
+ تست و مهاجرت

به همین دلیل انتخاب مدل Embedding باید با نگاه بلندمدت انجام شود.

هزینه RAG چگونه محاسبه می‌شود؟

هزینۀ RAG از چند بخش تشکیل می‌شود:

هزینۀ RAG =
Embedding پرسش
+ جست‌وجوی برداری
+ Reranking
+ توکن Context بازیابی‌شده
+ توکن پاسخ مدل
+ ذخیره‌سازی بردار

مثال ساده

فرض کنید هر درخواست RAG شامل موارد زیر باشد:

Embedding پرسش: 50 توکن
پنج Chunk بازیابی‌شده: 5,000 توکن
System Prompt: 800 توکن
پرسش کاربر: 150 توکن
پاسخ مدل: 700 توکن

ورودی مدل زبانی:

5,000 + 800 + 150
= 5,950 توکن

هزینه Embedding جدا از هزینۀ مدل پاسخ‌دهنده است.

کاهش هزینه RAG

• کاهش تعداد Chunkهای بازیابی‌شده
• بهبود کیفیت Retrieval
• حذف Chunkهای تکراری
• استفاده از Reranker اقتصادی
• فشرده‌سازی Context
• استفاده از Metadata Filter
• Cache پرسش‌های پرتکرار
• انتخاب مدل متناسب با پیچیدگی سؤال

ارسال Context بیشتر همیشه پاسخ بهتری تولید نمی‌کند و می‌تواند هم هزینه و هم احتمال سردرگمی مدل را افزایش دهد.

هزینه Reranking

Reranker نتایج بازیابی‌شده را دوباره مرتب می‌کند تا مرتبط‌ترین اسناد انتخاب شوند.

قیمت‌گذاری ممکن است براساس موارد زیر باشد:

• تعداد Query
• تعداد سند
• تعداد توکن Query و Document
• تعداد واحدهای جست‌وجو
• تعداد درخواست

برای محاسبۀ دقیق باید مشخص شود:

هر پرسش چند سند را Rerank می‌کند؟
میانگین طول هر سند چقدر است؟
چند Query در روز داریم؟
قیمت واحد Reranking چیست؟

اگر ۱۰۰ سند بازیابی و همگی Rerank شوند، هزینۀ بیشتری نسبت به Rerank کردن ۲۰ نامزد اولیه ایجاد خواهد شد.

قیمت تحلیل تصویر چگونه محاسبه می‌شود؟

تحلیل تصویر با تولید تصویر متفاوت است.

در تحلیل تصویر، تصویر ورودی به شکلی قابل‌پردازش برای مدل تبدیل می‌شود. روش‌های قیمت‌گذاری می‌توانند شامل موارد زیر باشند:

• توکن تصویر
• تعداد Tile
• عرض و ارتفاع
• سطح Detail
• تعداد تصویر
• توکن متن همراه
• مدل انتخاب‌شده

در برخی مدل‌ها، تصویر ابتدا Resize و سپس به Tileهای مشخص تقسیم می‌شود. هر Tile تعداد معینی توکن ایجاد می‌کند. در مدل‌های دیگر ممکن است روش تبدیل متفاوت باشد.

صفحات قیمت رسمی ارائه‌دهندگان معمولاً روش محاسبۀ ورودی تصویری را برای هر خانوادۀ مدل توضیح می‌دهند. برای نمونه، OpenAI اعلام می‌کند تصاویر برای مدل‌های مختلف با روش‌های متفاوت به توکن تبدیل می‌شوند. راهنمای قیمت API شرکت OpenAI

فرمول عمومی تحلیل تصویر

هزینۀ تحلیل تصویر =
هزینۀ توکن تصویر
+ هزینۀ متن ورودی
+ هزینۀ متن خروجی

عوامل مؤثر

• ابعاد تصویر
• نسبت تصویر
• Detail
• تعداد تصاویر
• متن Prompt
• طول پاسخ
• مدل
• روش Tokenization تصویر

دو تصویر با حجم فایل یکسان ممکن است هزینۀ متفاوتی داشته باشند؛ زیرا حجم فایل فشرده‌شده الزاماً معیار Billing مدل نیست.

تفاوت حجم فایل و هزینه تصویر

یک تصویر JPEG ممکن است فقط ۲۰۰ کیلوبایت حجم داشته باشد، اما ابعاد آن ۴۰۰۰ در ۳۰۰۰ پیکسل باشد. تصویر دیگری ممکن است یک مگابایت حجم داشته باشد اما ابعاد کوچک‌تری داشته باشد.

اگر قیمت‌گذاری بر پایۀ ابعاد، Tile یا توکن تصویر باشد، حجم فایل معیار مستقیم هزینه نیست.

حجم فایل بیشتر بر این موارد اثر می‌گذارد:

• پهنای باند
• زمان Upload
• محدودیت Request Body
• فضای ذخیره‌سازی
• Latency

قیمت تولید تصویر چگونه محاسبه می‌شود؟

مدل‌های تولید تصویر ممکن است با یکی از الگوهای زیر قیمت‌گذاری شوند:

• قیمت ثابت برای هر تصویر
• قیمت براساس کیفیت
• قیمت براساس اندازه
• قیمت براساس توکن ورودی و خروجی تصویر
• قیمت براساس تعداد پیکسل
• قیمت براساس تعداد مرحله تولید
• قیمت جداگانه برای ویرایش
• قیمت جداگانه برای ورودی مرجع

فرمول عمومی:

هزینۀ تولید تصویر =
تعداد تصاویر
× نرخ تصویر با اندازه و کیفیت انتخاب‌شده

اگر مدل مبتنی بر توکن تصویر باشد:

هزینۀ تصویر =
هزینۀ توکن متن ورودی
+ هزینۀ توکن تصویر ورودی
+ هزینۀ توکن تصویر خروجی

چرا قیمت تولید تصویر با Usage متنی برابر نیست؟

ممکن است Response فقط بخشی از Usage را نمایش دهد یا دسته‌های مختلف مصرف در قسمت‌های جداگانه گزارش شوند:

• Text Input Tokens
• Image Input Tokens
• Image Output Tokens
• Cached Tokens
• تعداد تصویر
• کیفیت
• اندازه
• قیمت ثابت عملیات

اگر فقط total_tokens یا توکن متنی را در نظر بگیرید، محاسبۀ هزینه تصویر ممکن است کمتر از مبلغ واقعی به نظر برسد.

برای بررسی اختلاف باید این موارد مشخص شوند:

1. مدل دقیق چه بوده است؟
2. کدام Provider درخواست را پردازش کرده است؟
3. تصویر چه ابعادی داشته است؟
4. کیفیت خروجی چه بوده است؟
5. چند تصویر تولید شده است؟
6. آیا تصویر مرجع ارسال شده است؟
7. آیا خروجی براساس توکن تصویر قیمت‌گذاری می‌شود؟
8. آیا Usage تمام اجزای Billable را نمایش می‌دهد؟
9. نرخ لحظۀ درخواست چه بوده است؟
10. ضریب خدمات و تبدیل ارز چگونه اعمال شده است؟

مثال قیمت‌گذاری تصویر

فرض کنید یک مدل فرضی قیمت‌های زیر را داشته باشد:

تصویر کوچک با کیفیت استاندارد: 0.02 دلار
تصویر بزرگ با کیفیت استاندارد: 0.04 دلار
تصویر بزرگ با کیفیت بالا: 0.08 دلار

اگر چهار تصویر بزرگ با کیفیت بالا تولید شوند:

4 × 0.08
= 0.32 دلار

هزینۀ نهایی ممکن است شامل ورودی متنی، تصویر مرجع یا کارمزد سرویس نیز باشد.

هزینه ویرایش تصویر

ویرایش تصویر ممکن است شامل موارد زیر باشد:

• تصویر اصلی
• Mask
• Prompt
• تصویر مرجع
• خروجی جدید

در برخی مدل‌ها، تصویر ورودی نیز توکن مصرف می‌کند. بنابراین:

هزینۀ ویرایش =
هزینۀ تصویر ورودی
+ هزینۀ Prompt
+ هزینۀ تصویر خروجی

ویرایش یک تصویر بزرگ با چند مرجع ممکن است از تولید مستقیم یک تصویر گران‌تر شود.

قیمت تبدیل گفتار به متن

Speech-to-Text معمولاً براساس یکی از این واحدها محاسبه می‌شود:

• دقیقه صوت
• ثانیه صوت
• توکن صوت
• مدت فایل پردازش‌شده

فرمول مبتنی بر دقیقه:

هزینه =
مدت صوت به دقیقه
× قیمت هر دقیقه

برای فایل ۴۵ دقیقه‌ای با نرخ فرضی ۰٫۰۰۶ دلار در دقیقه:

45 × 0.006
= 0.27 دلار

ممکن است عوامل زیر نیز مؤثر باشند:

• تشخیص گوینده
• Timestamp
• ترجمۀ هم‌زمان
• مدل دقیق‌تر
• Streaming
• زبان
• تعداد کانال صوت
• پردازش Realtime

گرد کردن مدت صوت

برخی سرویس‌ها ممکن است مصرف را در سطح ثانیه، دقیقه یا بازه‌های مشخص گرد کنند.

برای مثال، اگر Billing به دقیقه و با گرد کردن رو به بالا انجام شود:

فایل 61 ثانیه‌ای → 2 دقیقه قابل‌محاسبه

اما سرویس دیگری ممکن است ۶۱ ثانیه را دقیقاً محاسبه کند. این تفاوت در حجم بالا اهمیت دارد.

قیمت تبدیل متن به گفتار

Text-to-Speech ممکن است براساس این موارد محاسبه شود:

• تعداد کاراکتر
• تعداد توکن متن
• مدت صوت خروجی
• مدل و کیفیت صدا
• صدای استاندارد یا حرفه‌ای
• Streaming یا Batch

فرمول مبتنی بر کاراکتر:

هزینه =
(تعداد کاراکتر ÷ واحد اعلام‌شده)
× قیمت واحد

فاصله، علائم و کاراکترهای خاص ممکن است در شمارش لحاظ شوند. روش دقیق باید از مستندات مدل بررسی شود.

هزینه مدل‌های صوتی Realtime

در مکالمۀ صوتی بلادرنگ، هزینه ممکن است ترکیبی باشد:

توکن صوت ورودی
+ توکن صوت خروجی
+ توکن متن ورودی
+ توکن متن خروجی
+ مدت اتصال

اگر مکالمه ۱۰ دقیقه طول بکشد، سکوت، تشخیص پایان نوبت، Transcript و پاسخ صوتی ممکن است در Billing نقش داشته باشند.

در طراحی محصول صوتی باید هزینه را به شکل زیر اندازه‌گیری کنید:

هزینه به‌ازای هر دقیقه مکالمه موفق

و نه فقط:

هزینه هر درخواست API

قیمت تولید موسیقی و صدا

مدل‌های تولید موسیقی یا افکت صوتی ممکن است براساس موارد زیر قیمت‌گذاری شوند:

• مدت خروجی
• تعداد Generation
• کیفیت
• تعداد Track
• توکن
• Credit اختصاصی سرویس
• مجوز استفاده تجاری

در این سرویس‌ها Credit همیشه معادل توکن نیست. باید نرخ تبدیل Credit به عملیات و هزینۀ خرید Credit بررسی شود.

قیمت API تولید ویدئو

تولید ویدئو یکی از پیچیده‌ترین مدل‌های قیمت‌گذاری را دارد. هزینۀ آن ممکن است به موارد زیر وابسته باشد:

• مدت ویدئو
• عرض و ارتفاع
• رزولوشن
• نسبت تصویر
• نرخ فریم
• کیفیت
• تعداد پیکسل
• مدل
• سرعت تولید
• Text-to-Video یا Image-to-Video
• تعداد تصاویر مرجع
• First Frame و Last Frame
• صدا
• تعداد خروجی
• توکن ویدئو
• تعداد Credit

قیمت‌گذاری براساس ثانیه

هزینۀ ویدئو =
مدت ویدئو به ثانیه
× قیمت هر ثانیه

اگر قیمت فرضی ۰٫۱ دلار به‌ازای هر ثانیه باشد:

ویدئوی 10 ثانیه‌ای:
10 × 0.1 = 1 دلار

قیمت‌گذاری براساس پیکسل و مدت

برخی مدل‌ها ممکن است مصرف را از ترکیب ابعاد و مدت محاسبه کنند:

Usage Unit =
عرض × ارتفاع × مدت × ضریب نرخ فریم

سپس مقدار به یک واحد استاندارد تقسیم می‌شود:

Billable Tokens =
(Width × Height × Duration × Frame Factor)
÷ Divisor

مقادیر دقیق Frame Factor و Divisor برای هر مدل متفاوت‌اند.

مثال مقایسۀ وضوح

تعداد پیکسل هر فریم:

720p: 1280 × 720 = 921,600 پیکسل
1080p: 1920 × 1080 = 2,073,600 پیکسل

نسبت:

2,073,600 ÷ 921,600
= 2.25

اگر قیمت کاملاً متناسب با تعداد پیکسل باشد، ویدئوی 1080p می‌تواند ۲٫۲۵ برابر ویدئوی 720p واحد پردازشی مصرف کند؛ هرچند مدل واقعی ممکن است ضریب و قیمت‌گذاری متفاوتی داشته باشد.

Image-to-Video چه هزینه‌ای دارد؟

در Image-to-Video ممکن است هزینه‌های زیر وجود داشته باشند:

• پردازش تصویر ورودی
• تصویر First Frame
• تصویر Last Frame
• تصاویر مرجع
• توکن Prompt
• تولید فریم‌ها
• مدت خروجی
• وضوح
• صدا

بنابراین قیمت فقط از طول Prompt به دست نمی‌آید.

هزینه درخواست ناموفق

پاسخ به این پرسش وابسته به مرحلۀ شکست است.

خطا پیش از اجرای مدل

اگر درخواست به‌دلیل API Key نامعتبر، JSON اشتباه یا مدل ناموجود پیش از استنتاج رد شود، معمولاً مصرف مدل رخ نمی‌دهد.

خطا پس از شروع پردازش

اگر مدل بخشی از عملیات را انجام داده و سپس اتصال قطع شود، ممکن است مصرف ایجاد شده باشد.

قطع Streaming

اگر کاربر Stream را پس از دریافت بخشی از پاسخ متوقف کند، توکن‌های تولیدشده تا آن لحظه ممکن است قابل‌محاسبه باشند.

Timeout کلاینت

Timeout برنامه الزاماً به معنی لغو پردازش بالادستی نیست. ممکن است مدل همچنان کار کند، مگر اینکه درخواست واقعاً Cancel شده باشد.

خطای Tool

اگر مدل Tool Call تولید کرده و ابزار شکست بخورد، هزینه فراخوانی مدل اول همچنان مصرف شده است.

برای Billing دقیق باید نتیجۀ هر مرحله ثبت شود.

هزینه Retry

اگر یک درخواست سه بار ارسال شود، هر تلاش موفق به استنتاج می‌تواند هزینه جداگانه ایجاد کند.

هزینۀ کل Retry =
هزینۀ تلاش اول
+ هزینۀ تلاش دوم
+ هزینۀ تلاش سوم

Retry فقط باید برای خطاهای موقت انجام شود:

• 429
• 500
• 502
• 503
• 504
• Timeout اتصال
• خطای موقت شبکه

Retry برای خطای 400 یا 401 فقط ترافیک و پیچیدگی را افزایش می‌دهد.

Retry و عملیات غیر Idempotent

در Tool Calling، Retry ممکن است عملیات واقعی را تکرار کند:

• ثبت سفارش
• ارسال پیام
• کسر موجودی
• ایجاد پرداخت
• حذف داده

برای چنین عملیات‌هایی باید Idempotency Key و کنترل تکرار وجود داشته باشد.

هزینه Fallback

Fallback پایداری را افزایش می‌دهد، اما ممکن است هزینه را بیشتر کند.

اگر مدل اول بخشی از درخواست را پردازش و سپس خطا دهد و درخواست به مدل دوم منتقل شود:

هزینۀ نهایی =
مصرف مدل اول
+ مصرف مدل جایگزین

اگر مدل اول قبل از شروع استنتاج خطا دهد، ممکن است هزینه‌ای ثبت نشود.

برای ارزیابی Fallback باید این متریک‌ها ثبت شوند:

• نرخ Fallback
• دلیل Fallback
• مصرف مسیر اول
• مصرف مسیر دوم
• اختلاف قیمت مدل‌ها
• نرخ موفقیت پس از Fallback
• Latency اضافه‌شده

هزینه Batch API

برخی ارائه‌دهندگان برای پردازش غیرهم‌زمان و حجیم، نرخ پایین‌تری ارائه می‌کنند. برای مثال، پردازش Batch می‌تواند برای وظایفی مناسب باشد که پاسخ فوری نیاز ندارند:

• دسته‌بندی اسناد
• تولید Embedding
• خلاصه‌سازی آرشیو
• برچسب‌گذاری محصول
• استخراج اطلاعات
• ارزیابی Dataset

OpenAI در صفحۀ رسمی قیمت‌گذاری خود برای Batch Processing نرخ متفاوتی نسبت به پردازش استاندارد اعلام می‌کند؛ مقدار تخفیف و شرایط باید در زمان استفاده بررسی شود. قیمت رسمی OpenAI API

Batch مناسب نیست اگر:

• کاربر منتظر پاسخ زنده است.
• نتیجه باید فوری باشد.
• درخواست به مکالمۀ تعاملی تعلق دارد.
• عملیات به ترتیب زمانی حساس است.

هزینه Priority و Flex Processing

برخی سرویس‌ها سطوح مختلف پردازش ارائه می‌کنند:

• Standard
• Priority
• Flex
• Batch
• Reserved Capacity
• Regional Processing

معمولاً:

• Priority سرعت یا ثبات بیشتری دارد و ممکن است گران‌تر باشد.
• Flex ارزان‌تر است اما زمان و دسترس‌پذیری کمتری تضمین می‌کند.
• Batch برای پردازش غیرهم‌زمان مناسب است.
• Region خاص ممکن است ضریب قیمت متفاوت داشته باشد.
• ظرفیت رزروشده مدل اقتصادی متفاوتی دارد.

مقایسۀ قیمت مدل بدون توجه به Processing Tier ممکن است اشتباه باشد.

هزینه جست‌وجوی وب

اگر مدل از ابزار جست‌وجوی وب استفاده کند، هزینه ممکن است شامل دو بخش باشد:

هزینۀ فراخوانی جست‌وجو
+ هزینۀ توکن مدل

بسته به سرویس، محتوای نتایج جست‌وجو نیز ممکن است به ورودی مدل تبدیل شود و توکن مصرف کند.

اگر Agent در یک پاسخ پنج بار جست‌وجو انجام دهد، هر پنج عملیات باید در هزینه لحاظ شوند.

هزینه اجرای کد و Container

مدل‌هایی که امکان اجرای کد دارند ممکن است از محیط محاسباتی جداگانه استفاده کنند.

واحد قیمت‌گذاری ممکن است شامل موارد زیر باشد:

• مدت Session
• حافظه
• CPU
• فضای ذخیره
• تعداد Container
• عملیات اجرا
• زمان فعال بودن محیط

اگر Container پس از پایان کار بسته نشود، ممکن است هزینه اضافی ایجاد شود. Lifecycle محیط اجرایی باید کنترل شود.

هزینه ذخیره‌سازی و فایل

کاربردهای مبتنی بر فایل می‌توانند هزینه‌های جانبی داشته باشند:

• Upload
• فضای ذخیره
• مدت نگهداری
• پردازش اولیه
• OCR
• Parsing
• Embedding
• Vector Store
• دانلود
• پهنای باند
• Backup

هزینۀ API مدل فقط بخشی از هزینه سیستم مدیریت سند است.

هزینه پنهان Latency

مدل ارزان‌تر ممکن است بسیار کندتر باشد. این کندی می‌تواند هزینه‌های غیرمستقیم ایجاد کند:

• اشغال طولانی‌تر Worker
• افزایش تعداد اتصال
• نیاز به سرور بیشتر
• کاهش نرخ تبدیل
• ترک کاربر
• افزایش Retry
• افزایش صف
• هزینه پشتیبانی

در انتخاب مدل باید Price-Performance بررسی شود، نه فقط قیمت توکن.

مدل ارزان‌تر همیشه کم‌هزینه‌تر نیست

فرض کنید:

اگر مدل ارزان در ۴۰ درصد موارد نیاز به تکرار یا بررسی انسانی داشته باشد، هزینه واقعی آن ممکن است بیشتر شود.

معیار مناسب:

هزینه به‌ازای نتیجۀ موفق

فرمول:

Cost per Successful Outcome =
Total Cost ÷ Number of Successful Results

هزینه کیفیت پایین

هزینه واقعی هوش مصنوعی فقط صورتحساب API نیست. پاسخ اشتباه می‌تواند باعث موارد زیر شود:

• اتلاف زمان نیروی انسانی
• پاسخ نادرست به مشتری
• تصمیم اشتباه
• دوباره‌کاری
• کاهش اعتماد
• زیان مالی
• ریسک حقوقی
• افزایش درخواست پشتیبانی

در وظایف حساس، مدل ارزان با خطای بیشتر ممکن است از مدل گران و دقیق پرهزینه‌تر باشد.

تفاوت Usage و مبلغ نهایی

Usage نشان می‌دهد چه منابعی مصرف شده‌اند، اما مبلغ نهایی ممکن است با فرمول ساده توکن متفاوت باشد.

دلایل رایج:

• نرخ ورودی و خروجی متفاوت
• Cached Token
• Reasoning Token
• Image Token
• Audio Token
• تعداد خروجی
• ابزارهای پولی
• Processing Tier
• Provider متفاوت
• نرخ ارز
• ضریب خدمات
• مالیات
• حداقل مبلغ کسر
• گرد کردن
• Retry
• Fallback
• تأخیر در ثبت Usage

برای بررسی یک صورتحساب باید Usage کامل و جدول قیمت همان زمان در دسترس باشد.

حداقل مبلغ کسر چیست؟

اگر هزینه واقعی یک درخواست بسیار کم باشد، ذخیره و پردازش مبالغ خرد ممکن است مشکلاتی ایجاد کند. بعضی سامانه‌ها حداقل مبلغی برای هر درخواست یا تراکنش مالی تعیین می‌کنند.

فرمول:

مبلغ قابل‌کسر =
Max(هزینۀ محاسبه‌شده، حداقل مبلغ)

برای مثال فرضی:

هزینۀ محاسبه‌شده: 300 ریال
حداقل کسر: 1,000 ریال
مبلغ نهایی: 1,000 ریال

وجود چنین سیاستی باید برای کاربر شفاف باشد، زیرا در درخواست‌های کوچک اختلاف محسوسی ایجاد می‌کند.

گرد کردن قیمت

نباید در مراحل میانی محاسبه، اعداد را زود گرد کرد.

روش نامناسب:

هزینه هر بخش را گرد کن
→ بخش‌ها را جمع کن

روش بهتر:

تمام محاسبات را با دقت بالا انجام بده
→ مجموع نهایی را طبق سیاست مالی گرد کن

در حجم بالا، خطای بسیار کوچک هر درخواست می‌تواند به اختلاف بزرگ تبدیل شود.

برای محاسبات مالی بهتر است از Decimal یا عدد صحیح در کوچک‌ترین واحد پول استفاده شود، نه Floating Point معمولی.

فرمول عمومی هزینه در AI Gateway

Provider Cost USD =
Text Input Cost
+ Cached Input Cost
+ Text Output Cost
+ Reasoning Cost
+ Image Input Cost
+ Image Output Cost
+ Audio Input Cost
+ Audio Output Cost
+ Video Cost
+ Tool Cost

سپس:

Local Base Cost =
Provider Cost USD × Exchange Rate

و در صورت وجود ضریب خدمات:

Final Cost =
Local Base Cost × Service Multiplier

پس از آن:

Charge Amount =
Round(Max(Final Cost, Minimum Charge))

این فرمول باید بر اساس سیاست واقعی پلتفرم تنظیم شود.

نمونه پیاده‌سازی ماشین‌حساب هزینه با JavaScript

function calculateTextCost({
  inputTokens,
  outputTokens,
  cachedInputTokens = 0,
  inputPricePerMillion,
  outputPricePerMillion,
  cachedInputPricePerMillion = 0,
}) {
  const regularInputTokens = Math.max(
    0,
    inputTokens - cachedInputTokens,
  );

  const inputCost =
    (regularInputTokens / 1_000_000) *
    inputPricePerMillion;

  const cachedInputCost =
    (cachedInputTokens / 1_000_000) *
    cachedInputPricePerMillion;

  const outputCost =
    (outputTokens / 1_000_000) *
    outputPricePerMillion;

  return {
    inputCost,
    cachedInputCost,
    outputCost,
    totalUsd:
      inputCost + cachedInputCost + outputCost,
  };
}

const result = calculateTextCost({
  inputTokens: 12_000,
  cachedInputTokens: 8_000,
  outputTokens: 1_500,
  inputPricePerMillion: 2,
  cachedInputPricePerMillion: 0.2,
  outputPricePerMillion: 8,
});

console.log(result);

در برخی Usageها، inputTokens ممکن است توکن Cache‌شده را در خود داشته باشد و در برخی ساختارها تفکیک متفاوتی وجود دارد. پیش از کم کردن cachedInputTokens باید قرارداد دقیق Provider بررسی شود.

تبدیل هزینه به پول محلی با JavaScript

برای محاسبات مالی Production بهتر است از Decimal Library استفاده شود. نمونۀ ساده آموزشی:

function convertUsdToLocal({
  costUsd,
  usdToIrr,
  markupMultiplier = 1,
  minimumChargeIrr = 0,
}) {
  const rawCostIrr = costUsd * usdToIrr;
  const finalCostIrr =
    rawCostIrr * markupMultiplier;

  return Math.max(
    Math.round(finalCostIrr),
    minimumChargeIrr,
  );
}

const chargeIrr = convertUsdToLocal({
  costUsd: 0.036,
  usdToIrr: 600_000,
  markupMultiplier: 1.3,
  minimumChargeIrr: 1_000,
});

console.log({
  chargeIrr,
  chargeToman: chargeIrr / 10,
});

ماشین‌حساب هزینه با Python

from dataclasses import dataclass
from decimal import Decimal, ROUND_HALF_UP


MILLION = Decimal("1000000")


@dataclass(frozen=True)
class TokenPricing:
    input_per_million: Decimal
    output_per_million: Decimal
    cached_input_per_million: Decimal = Decimal("0")


@dataclass(frozen=True)
class TokenUsage:
    input_tokens: int
    output_tokens: int
    cached_input_tokens: int = 0


def calculate_token_cost(
    usage: TokenUsage,
    pricing: TokenPricing,
) -> dict[str, Decimal]:
    regular_input_tokens = max(
        0,
        usage.input_tokens - usage.cached_input_tokens,
    )

    input_cost = (
        Decimal(regular_input_tokens)
        / MILLION
        * pricing.input_per_million
    )

    cached_cost = (
        Decimal(usage.cached_input_tokens)
        / MILLION
        * pricing.cached_input_per_million
    )

    output_cost = (
        Decimal(usage.output_tokens)
        / MILLION
        * pricing.output_per_million
    )

    return {
        "input_cost_usd": input_cost,
        "cached_cost_usd": cached_cost,
        "output_cost_usd": output_cost,
        "total_cost_usd": (
            input_cost + cached_cost + output_cost
        ),
    }


def convert_to_irr(
    cost_usd: Decimal,
    usd_to_irr: Decimal,
    markup: Decimal = Decimal("1"),
    minimum_charge_irr: int = 0,
) -> int:
    calculated = cost_usd * usd_to_irr * markup

    rounded = int(
        calculated.quantize(
            Decimal("1"),
            rounding=ROUND_HALF_UP,
        )
    )

    return max(rounded, minimum_charge_irr)


pricing = TokenPricing(
    input_per_million=Decimal("2"),
    output_per_million=Decimal("8"),
    cached_input_per_million=Decimal("0.2"),
)

usage = TokenUsage(
    input_tokens=12000,
    cached_input_tokens=8000,
    output_tokens=1500,
)

cost = calculate_token_cost(usage, pricing)

charge_irr = convert_to_irr(
    cost_usd=cost["total_cost_usd"],
    usd_to_irr=Decimal("600000"),
    markup=Decimal("1.3"),
    minimum_charge_irr=1000,
)

print(cost)
print({
    "charge_irr": charge_irr,
    "charge_toman": Decimal(charge_irr) / Decimal("10"),
})

چرا Decimal مهم است؟

اعداد Floating Point نمی‌توانند تمام اعداد اعشاری را دقیق نمایش دهند:

0.1 + 0.2 !== 0.3

در یک درخواست کوچک، این اختلاف ناچیز است؛ اما در میلیون‌ها تراکنش می‌تواند باعث ناسازگاری Billing شود.

راهکارهای مناسب:

• استفاده از Decimal
• ذخیرۀ پول در کوچک‌ترین واحد صحیح
• ذخیرۀ نرخ‌ها با دقت کافی
• گرد کردن فقط در مرحلۀ نهایی
• ثبت نسخۀ جدول قیمت
• ثبت نرخ ارز استفاده‌شده

طراحی دیتابیس Billing

برای هر درخواست بهتر است اطلاعات زیر ثبت شوند:

request_id
user_id
organization_id
api_key_id
provider_id
requested_model
actual_model
input_tokens
cached_input_tokens
output_tokens
reasoning_tokens
image_input_units
image_output_units
audio_input_units
audio_output_units
video_units
tool_cost_usd
provider_cost_usd
exchange_rate
markup_multiplier
final_charge_irr
status
started_at
completed_at
pricing_version

نمونۀ جدول مفهومی:

CREATE TABLE ai_usage_costs (
    id UUID PRIMARY KEY,
    request_id TEXT NOT NULL UNIQUE,
    organization_id UUID NOT NULL,
    api_key_id UUID,
    provider_id UUID,
    requested_model TEXT NOT NULL,
    actual_model TEXT NOT NULL,

    input_tokens BIGINT NOT NULL DEFAULT 0,
    cached_input_tokens BIGINT NOT NULL DEFAULT 0,
    output_tokens BIGINT NOT NULL DEFAULT 0,
    reasoning_tokens BIGINT NOT NULL DEFAULT 0,

    provider_cost_usd NUMERIC(20, 10) NOT NULL,
    exchange_rate_irr NUMERIC(20, 4) NOT NULL,
    markup_multiplier NUMERIC(12, 6) NOT NULL,
    final_charge_irr BIGINT NOT NULL,

    pricing_version TEXT NOT NULL,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

این ساختار باید براساس مدل‌های متن، تصویر، صوت و ویدئوی پلتفرم توسعه یابد.

چرا Pricing Version لازم است؟

قیمت مدل‌ها ممکن است تغییر کند. اگر فقط قیمت فعلی مدل را نگهداری کنید، بازسازی صورتحساب درخواست قدیمی دشوار می‌شود.

برای هر درخواست باید Snapshot یا Version قیمت ثبت شود:

model_price_version: 2026-07-13

اطلاعات مهم:

• نرخ ورودی
• نرخ خروجی
• نرخ Cache
• نرخ تصویر
• نرخ صوت
• نرخ ویدئو
• نرخ ارز
• ضریب خدمات
• حداقل کسر
• روش گرد کردن

هزینۀ تخمینی و هزینۀ نهایی

پیش از اجرای مدل فقط می‌توان هزینه را تخمین زد؛ زیرا طول خروجی هنوز مشخص نیست.

تخمین پیش از درخواست

Estimated Cost =
Known Input Cost
+ Maximum Expected Output Cost

محاسبۀ پس از درخواست

Actual Cost =
Reported Usage × Applied Pricing

در Wallet پیش‌پرداخت می‌توان:

1. موجودی را پیش از درخواست بررسی کرد.
2. بودجۀ تقریبی را رزرو کرد.
3. مدل را اجرا کرد.
4. هزینه واقعی را محاسبه کرد.
5. مبلغ واقعی را کسر کرد.
6. رزرو اضافه را آزاد کرد.

این روش برای درخواست‌های گران مانند تولید ویدئو یا Agentهای طولانی اهمیت دارد.

Pre-check کیف پول

بررسی صرف مثبت بودن موجودی کافی نیست. اگر کاربر ۱۰۰ تومان موجودی داشته باشد اما درخواست احتمالاً ۵۰ هزار تومان هزینه داشته باشد، سیستم باید سیاست مشخصی داشته باشد.

روش‌های ممکن:

• حداقل موجودی لازم
• رزرو حداکثر هزینه
• محدود کردن طول خروجی
• رد درخواست پرهزینه
• توقف Streaming پس از عبور از بودجه
• انتقال به مدل اقتصادی‌تر

Atomic Debit

کسر موجودی باید Atomic باشد تا دو درخواست هم‌زمان نتوانند بیش از موجودی کیف پول مصرف کنند.

الگوی نامناسب:

خواندن موجودی
→ بررسی کافی بودن
→ اجرای درخواست
→ کسر موجودی

دو Worker ممکن است هم‌زمان موجودی یکسان را بخوانند.

الگوی بهتر:

• Transaction دیتابیس
• Atomic Function
• Row Lock
• Ledger
• Idempotency Key
• Unique Request ID

هر Request ID باید حداکثر یک‌بار به کیف پول اعمال شود.

Ledger بهتر از نگهداری صرف موجودی است

بهتر است علاوه بر مقدار موجودی، دفتر تراکنش‌ها نیز نگهداری شود:

موجودی باید از مجموع Ledger قابل‌بازسازی باشد یا دست‌کم با آن تطبیق داده شود.

جلوگیری از کسر تکراری

اگر Callback یا Worker دوبار اجرا شود، نباید هزینۀ درخواست دوبار کسر شود.

راهکار:

UNIQUE(request_id, transaction_type)

الگوی Idempotent:

1. Request ID دریافت شود.
2. بررسی شود قبلاً Billing شده یا نه.
3. Usage ثبت شود.
4. Debit با همان Request ID انجام شود.
5. درخواست تکراری نتیجۀ قبلی را دریافت کند.

هزینه Streaming چگونه ثبت می‌شود؟

در Streaming ممکن است Usage فقط در پایان دریافت شود. مشکلات احتمالی:

• کاربر زود قطع می‌کند.
• Event نهایی دریافت نمی‌شود.
• Provider Usage را در Stream برنمی‌گرداند.
• Gateway در میان پاسخ Restart می‌شود.

راهکارها:

• استفاده از Usage گزارش‌شده توسط Provider
• ثبت رویدادهای Stream
• تخمین محافظه‌کارانه در صورت نبود Usage
• دریافت Usage از Log ارائه‌دهنده
• ثبت وضعیت usage_pending
• فرایند Reconciliation
• Cancel کردن درخواست بالادستی پس از قطع کاربر

Reconciliation چیست؟

Reconciliation فرایند تطبیق Usage داخلی با صورتحساب یا گزارش Provider است.

برای مثال:

مصرف ثبت‌شده داخلی
در برابر
مصرف اعلام‌شده Provider

اختلاف می‌تواند به دلایل زیر ایجاد شود:

• Event از دست‌رفته
• Timeout
• Retry
• Usage دیرهنگام
• خطای Worker
• قیمت قدیمی
• Provider متفاوت
• گرد کردن
• Request ID ناسازگار

سیستم Billing حرفه‌ای باید گزارش اختلاف و امکان اصلاح داشته باشد.

کنترل بودجه

بودجه می‌تواند در سطوح مختلف تعریف شود:

• هر درخواست
• هر کاربر
• هر API Key
• هر پروژه
• هر سازمان
• هر مدل
• روزانه
• هفتگی
• ماهانه

Soft Limit

با عبور از حد، هشدار ارسال می‌شود اما سرویس ادامه دارد.

Hard Limit

با عبور از حد، درخواست‌های جدید متوقف می‌شوند.

مدل ترکیبی

۸۰٪ بودجه → هشدار
۹۰٪ بودجه → محدود کردن مدل‌های گران
۱۰۰٪ بودجه → توقف درخواست

بودجۀ هر درخواست

برای Agent و تولید محتوای طولانی:

{
  "max_cost_usd": 0.10,
  "max_model_calls": 8,
  "max_tool_calls": 5,
  "max_duration_seconds": 120
}

حتی اگر API Gateway چنین فیلدهایی را مستقیماً نپذیرد، برنامه می‌تواند آن‌ها را در Orchestrator خود اعمال کند.

تشخیص مصرف غیرعادی

الگوهای مشکوک:

• افزایش ناگهانی درخواست
• خروجی‌های بسیار طولانی
• استفاده غیرمنتظره از مدل گران
• تعداد زیاد Retry
• مصرف از یک IP جدید
• فعال شدن مکرر Fallback
• Agent Loop
• تولید تصویر یا ویدئوی پرتعداد
• افزایش توکن System Prompt
• نشت API Key

واکنش‌های ممکن:

• هشدار
• کاهش Rate Limit
• تعلیق کلید
• توقف مدل خاص
• نیاز به تأیید
• محدودسازی IP
• چرخش API Key
• بررسی دستی

متریک‌های مهم هزینه

هزینه هر درخواست

Total Cost ÷ Total Requests

هزینه هر کاربر فعال

Total AI Cost ÷ Active Users

هزینه هر نتیجۀ موفق

Total Cost ÷ Successful Outcomes

هزینه هر مکالمه

Total Chat Cost ÷ Conversations

هزینه هر دقیقۀ صوت

Total Audio Cost ÷ Audio Minutes

هزینه هر تصویر موفق

Total Image Cost ÷ Accepted Images

هزینۀ AI به‌عنوان درصد درآمد

AI Cost ÷ Revenue × 100

این معیار برای بررسی پایداری اقتصادی محصول مهم است.

Unit Economics محصول هوش مصنوعی

فرض کنید اشتراک ماهانه یک محصول ۵۰۰ هزار تومان باشد و متوسط هزینه هر کاربر:

مدل‌های متنی: ۱۲۰ هزار تومان
Embedding و Vector DB: ۲۰ هزار تومان
زیرساخت: ۳۰ هزار تومان
پشتیبانی و عملیات: ۴۰ هزار تومان

هزینۀ متغیر:

120,000 + 20,000 + 30,000 + 40,000
= 210,000 تومان

حاشیۀ مشارکت پیش از هزینه‌های ثابت:

500,000 - 210,000
= 290,000 تومان

فروش اشتراک نامحدود بدون شناخت الگوی مصرف می‌تواند زیان‌ده باشد.

طراحی پلن قیمت‌گذاری محصول

روش‌های رایج:

پرداخت براساس مصرف

کاربر دقیقاً براساس مصرف پرداخت می‌کند.

مزایا:

• ارتباط مستقیم درآمد و هزینه
• ریسک کمتر برای سرویس
• مناسب توسعه‌دهندگان

چالش:

• پیش‌بینی صورتحساب برای کاربر دشوارتر است.

اشتراک با سهمیه

هر پلن مقدار مشخصی اعتبار یا مصرف دارد.

مزایا:

• درآمد قابل‌پیش‌بینی
• تجربۀ ساده‌تر

چالش:

• نیاز به طراحی دقیق Fair Use

اشتراک و مصرف اضافه

اشتراک پایه به همراه هزینۀ مصرف بالاتر از سهمیه.

Credit

هر عملیات مقدار مشخصی Credit مصرف می‌کند.

این روش برای یکپارچه کردن متن، تصویر و ویدئو مفید است، اما نرخ تبدیل Credit باید شفاف باشد.

ساخت جدول قیمت مدل‌ها

برای هر مدل بهتر است این اطلاعات ذخیره شوند:

model_id
provider_id
input_price
output_price
cached_input_price
cache_write_price
reasoning_price
image_input_price
image_output_price
audio_input_price
audio_output_price
video_price
pricing_unit
currency
effective_from
effective_to
version

قیمت نباید فقط براساس نام مدل باشد؛ زیرا یک مدل ممکن است از چند Provider با نرخ‌های متفاوت ارائه شود.

قیمت Provider و قیمت مدل

Model ID و Provider هر دو باید در Usage ثبت شوند.

ممکن است:

مدل یکسان
+ Provider متفاوت
= قیمت متفاوت

دلایل:

• منطق قیمت‌گذاری Provider
• موقعیت جغرافیایی
• Processing Tier
• ظرفیت
• قرارداد تجاری
• نرخ Cache
• هزینۀ منطقه‌ای

اگر AI Gateway درخواست را به Provider دیگری Fallback کند، Billing باید از قیمت مسیر واقعی استفاده کند، مگر سیاست تجاری سرویس چیز دیگری باشد.

قیمت ثابت یا قیمت واقعی Provider؟

دو رویکرد وجود دارد:

Pass-through Pricing

هزینۀ واقعی Provider به همراه ضریب خدمات محاسبه می‌شود.

Unified Pricing

پلتفرم برای هر مدل یک قیمت ثابت تعریف می‌کند، مستقل از Provider پشت صحنه.

هر روش مزایا و چالش‌های خود را دارد. مهم این است که سیاست برای کاربر شفاف و در Billing به‌صورت سازگار اجرا شود.

چگونه هزینۀ ماهانه را تخمین بزنیم؟

فرمول پایه:

Monthly Cost =
Daily Requests
× Average Cost per Request
× Days

مثال:

درخواست روزانه: 50,000
متوسط هزینه درخواست: 0.002 دلار
تعداد روز: 30

50,000 × 0.002 × 30
= 3,000 دلار در ماه

برای تخمین دقیق‌تر درخواست‌ها را دسته‌بندی کنید:

جمع:

200 + 900 + 1,500 + 500
= 3,100 دلار

محاسبۀ جداگانه هر Workload از استفاده از یک میانگین کلی دقیق‌تر است.

سناریوهای کم، متوسط و زیاد

برای بودجه‌بندی سه سناریو بسازید:

سناریوی کم‌مصرف

کاربران کمتر
خروجی کوتاه‌تر
مدل اقتصادی
Fallback محدود

سناریوی متوسط

براساس رفتار موردانتظار.

سناریوی پرمصرف

رشد سریع کاربر
Prompt طولانی
مدل گران‌تر
Retry بیشتر
Agent پرتکرار

بودجۀ زیرساخت باید سناریوی پرمصرف را نیز تحمل کند.

تست واقعی به‌جای تخمین نظری

بهترین روش برآورد هزینه:

1. یک Dataset واقعی از درخواست‌ها بسازید.
2. مدل‌های مناسب را انتخاب کنید.
3. تمام درخواست‌ها را اجرا کنید.
4. Usage واقعی را ثبت کنید.
5. کیفیت پاسخ را ارزیابی کنید.
6. هزینه هر نتیجۀ موفق را محاسبه کنید.
7. P50، P95 و P99 هزینه را بررسی کنید.
8. مدل مناسب را برای هر دسته انتخاب کنید.

میانگین به‌تنهایی کافی نیست. چند درخواست بسیار بزرگ می‌توانند بخش زیادی از هزینه را ایجاد کنند.

تحلیل توزیع هزینه

متریک‌های مهم:

• P50 هزینه هر درخواست
• P95 هزینه هر درخواست
• P99 هزینه هر درخواست
• گران‌ترین Endpointها
• گران‌ترین کاربران
• گران‌ترین مدل‌ها
• بیشترین System Prompt
• بیشترین Retry
• بیشترین Fallback
• بالاترین خروجی

ممکن است ۱ درصد درخواست‌ها ۳۰ درصد کل هزینه را ایجاد کنند.

روش‌های کاهش هزینه API هوش مصنوعی

مدل مناسب برای هر وظیفه

همۀ درخواست‌ها به مدل قدرتمند نیاز ندارند.

طبقه‌بندی ساده → مدل اقتصادی
تحلیل عمومی → مدل متعادل
استدلال دشوار → مدل قدرتمند

محدود کردن خروجی

• تعیین سقف خروجی
• درخواست پاسخ مختصر
• استفاده از JSON
• حذف توضیح اضافه
• توقف تولید غیرضروری

مدیریت تاریخچه

• حذف پیام قدیمی
• خلاصه‌سازی
• Retrieval هدفمند
• ذخیرۀ حافظه ساختاریافته

Prompt Caching

برای محتوای ثابت و پرتکرار.

Batch Processing

برای عملیات غیر فوری.

Cache پاسخ

برای درخواست‌های عمومی، پایدار و غیرشخصی.

کنترل Retry

فقط برای خطاهای موقت و با محدودیت.

کاهش RAG Context

ارسال Chunkهای مرتبط‌تر به‌جای متن بیشتر.

محدود کردن Agent

تعداد مراحل، ابزارها و بودجه باید محدود باشد.

توقف درخواست پس از قطع کاربر

به‌ویژه در Streaming.

چه چیزهایی را نباید برای کاهش هزینه قربانی کرد؟

• امنیت
• کنترل دسترسی
• اعتبارسنجی خروجی
• کیفیت وظایف حساس
• پایداری
• حریم خصوصی
• Logging ضروری
• امکان Audit
• تأیید انسانی عملیات مهم

کاهش هزینه‌ای که ریسک یا خطای محصول را افزایش دهد ممکن است صرفه‌جویی واقعی نباشد.

محاسبۀ هزینه API درواره

درواره دسترسی یکپارچه به مدل‌های مختلف هوش مصنوعی را از طریق API فراهم می‌کند. Base URL عمومی برای اتصال ابزارها و نرم‌افزارها:

https://api.darvareh.ir/v1

در یک درخواست متنی، اطلاعات Usage معمولاً می‌تواند شامل توکن ورودی، خروجی و مجموع مصرف باشد. هزینه نهایی به موارد زیر وابسته است:

• مدل انتخاب‌شده
• Provider پردازش‌کننده
• نوع ورودی و خروجی
• نرخ مدل
• تعداد توکن یا واحد مصرف
• نرخ تبدیل ارز
• سیاست قیمت‌گذاری پلتفرم
• حداقل مبلغ کسر
• قابلیت‌های جانبی
• Retry یا Fallback

برای مدل‌های تصویر، صوت و ویدئو نباید فقط از فرمول توکن متنی استفاده کرد. واحد مصرف باید از تنظیمات همان مدل و پاسخ Provider استخراج شود.

نمونه درخواست به درواره

curl "https://api.darvareh.ir/v1/chat/completions" \
  -H "Authorization: Bearer $DARVAREH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {
        "role": "system",
        "content": "پاسخ را مختصر و دقیق بنویس."
      },
      {
        "role": "user",
        "content": "API Gateway چیست؟"
      }
    ]
  }'

Model ID باید از فهرست مدل‌های درواره انتخاب شود.

ثبت Usage در برنامه

const response = await client.chat.completions.create({
  model: "MODEL_ID",
  messages: [
    {
      role: "user",
      content: "این متن را خلاصه کن.",
    },
  ],
});

const usage = response.usage;

console.log({
  model: response.model,
  inputTokens: usage?.prompt_tokens,
  outputTokens: usage?.completion_tokens,
  totalTokens: usage?.total_tokens,
});

Usage برگشتی منبع مهمی برای مشاهده مصرف است، اما محاسبۀ مالی نهایی باید با جدول قیمت، نوع مدل و اطلاعات Billing پلتفرم انجام شود.

چک‌لیست بررسی اختلاف هزینه

اگر مبلغ کسرشده با تخمین شما متفاوت بود، این موارد را بررسی کنید:

• آیا Model ID دقیق را بررسی کرده‌اید؟
• آیا Provider واقعی مشخص است؟
• آیا قیمت مربوط به همان نسخۀ مدل است؟
• آیا نرخ ورودی و خروجی را جدا محاسبه کرده‌اید؟
• آیا Cached Token وجود داشته است؟
• آیا Reasoning Token محاسبه شده است؟
• آیا تصویر، صوت یا ویدئو واحد جدا دارد؟
• آیا چند خروجی تولید شده است؟
• آیا Retry اتفاق افتاده است؟
• آیا Fallback فعال شده است؟
• آیا ابزار پولی فراخوانی شده است؟
• آیا Processing Tier متفاوت بوده است؟
• آیا حداقل مبلغ کسر اعمال شده است؟
• آیا نرخ ارز زمان درخواست را استفاده کرده‌اید؟
• آیا ضریب خدمات اعمال شده است؟
• آیا Usage تمام بخش‌های Billable را نشان می‌دهد؟
• آیا مبلغ ریالی را با تومان اشتباه گرفته‌اید؟

پرسش‌های متداول

هزینه API هوش مصنوعی چگونه محاسبه می‌شود؟

هزینه از ضرب میزان مصرف در نرخ واحد مدل به دست می‌آید. میزان مصرف ممکن است توکن، تصویر، ثانیه صوت، مدت ویدئو، تعداد درخواست یا فراخوانی ابزار باشد.

قیمت توکن چیست؟

قیمت توکن معمولاً به‌صورت قیمت یک میلیون توکن اعلام می‌شود. مدل می‌تواند برای توکن ورودی، خروجی و Cache نرخ‌های متفاوتی داشته باشد.

آیا یک توکن برابر یک کلمه است؟

خیر. توکن می‌تواند یک کلمه، بخشی از کلمه، علامت یا ترکیبی از کاراکترها باشد. تعداد توکن باید با Tokenizer یا Usage واقعی سنجیده شود.

آیا متن فارسی توکن بیشتری مصرف می‌کند؟

این موضوع به Tokenizer مدل، نوع متن و شیوۀ نگارش بستگی دارد. برای تخمین دقیق باید متن‌های فارسی واقعی محصول با مدل انتخاب‌شده آزمایش شوند.

آیا System Prompt هم هزینه دارد؟

بله. هر محتوایی که همراه درخواست به مدل ارسال شود می‌تواند جزو توکن ورودی باشد، از جمله System Prompt، تاریخچه، ابزارها و Context بازیابی‌شده.

چرا توکن خروجی گران‌تر است؟

در بسیاری از مدل‌ها، تولید هر توکن خروجی به پردازش مرحله‌به‌مرحله نیاز دارد؛ به همین دلیل نرخ خروجی بیشتر از ورودی است.

آیا پاسخ کوتاه همیشه ارزان است؟

نه لزوماً. ممکن است System Prompt، تاریخچه، RAG Context یا توکن‌های استدلال حجم زیادی داشته باشند.

قیمت API تولید تصویر چگونه محاسبه می‌شود؟

بسته به مدل، قیمت می‌تواند براساس تعداد تصویر، اندازه، کیفیت، توکن تصویر، تعداد پیکسل یا عملیات ویرایش محاسبه شود.

چرا Usage تولید تصویر با مبلغ نهایی برابر نیست؟

ممکن است Usage قابل‌مشاهده فقط توکن متن را نشان دهد و Image Token، کیفیت، اندازه یا قیمت ثابت تولید جداگانه محاسبه شود.

قیمت تحلیل تصویر با تولید تصویر چه تفاوتی دارد؟

در تحلیل تصویر، تصویر ورودی توسط مدل پردازش و معمولاً به توکن یا Tile تبدیل می‌شود. در تولید تصویر، خود خروجی تصویری واحد هزینه دارد.

قیمت API صوت چگونه محاسبه می‌شود؟

Speech-to-Text ممکن است براساس دقیقه یا ثانیه صوت باشد. Text-to-Speech می‌تواند براساس کاراکتر، توکن یا مدت خروجی محاسبه شود.

قیمت API ویدئو چگونه محاسبه می‌شود؟

ممکن است براساس مدت، وضوح، ابعاد، تعداد پیکسل، نرخ فریم، توکن یا Credit محاسبه شود. فرمول هر مدل باید جداگانه بررسی شود.

آیا درخواست ناموفق هزینه دارد؟

اگر پیش از اجرای مدل رد شود معمولاً مصرفی ندارد؛ اما اگر مدل پردازش را آغاز کرده باشد، ممکن است مصرف ایجاد شده باشد.

آیا Retry هزینه را افزایش می‌دهد؟

بله. هر تلاش جدیدی که مدل را اجرا کند می‌تواند هزینۀ جداگانه داشته باشد.

آیا Fallback رایگان است؟

لزوماً خیر. اگر مدل اول مصرف ایجاد کرده و سپس مدل دوم فراخوانی شود، ممکن است هزینۀ هر دو ثبت شود.

هزینۀ Agent چگونه محاسبه می‌شود؟

هزینۀ Agent برابر مجموع تمام فراخوانی‌های مدل، ابزارها، Embedding، بازیابی، ذخیره‌سازی و زیرساخت اجرا است.

آیا مدل ارزان‌تر همیشه بهتر است؟

خیر. اگر مدل ارزان پاسخ‌های نامعتبر بیشتری تولید کند و نیازمند Retry یا اصلاح انسانی باشد، هزینه هر نتیجۀ موفق آن ممکن است بیشتر شود.

چگونه هزینۀ ماهانه را تخمین بزنیم؟

تعداد درخواست ماهانه را در متوسط هزینه هر درخواست ضرب کنید. برای دقت بیشتر، Workloadها را براساس نوع درخواست و مدل جدا محاسبه کنید.

آیا اشتراک ChatGPT شامل API می‌شود؟

اشتراک محصول چت و مصرف API معمولاً صورتحساب‌های جداگانه دارند. شرایط دقیق باید در مستندات رسمی سرویس بررسی شود.

چگونه از مصرف غیرعادی جلوگیری کنیم؟

Rate Limit، سقف بودجه، محدودیت مدل، هشدار مصرف، محدودیت Agent، چرخش کلید و مانیتورینگ هزینه را فعال کنید.

آیا API Key باید در Frontend باشد؟

خیر. API Key باید در Backend یا Secret Manager نگهداری شود.

قیمت مدل‌های درواره را از کجا ببینیم؟

قیمت و مشخصات هر مدل باید از فهرست به‌روز مدل‌ها و اطلاعات حساب درواره بررسی شود؛ زیرا نرخ مدل‌ها و ارائه‌دهندگان ممکن است تغییر کند.

جمع‌بندی

هزینۀ API هوش مصنوعی یک فرمول واحد برای تمام مدل‌ها ندارد. مدل‌های زبانی معمولاً براساس توکن ورودی و خروجی قیمت‌گذاری می‌شوند، اما مدل‌های تصویر، صوت و ویدئو واحدهای متفاوتی دارند.

برای محاسبۀ درست باید این مراحل را انجام دهید:

1. مدل و Provider واقعی را مشخص کنید.
2. واحد قیمت‌گذاری مدل را پیدا کنید.
3. تمام ورودی‌ها و خروجی‌ها را اندازه‌گیری کنید.
4. Cache، Reasoning و ابزارها را جدا محاسبه کنید.
5. Retry و Fallback را در نظر بگیرید.
6. نرخ ارز و سیاست خدمات را اعمال کنید.
7. مبلغ نهایی را با دقت مالی گرد کنید.
8. Usage را در سطح هر Request ID ثبت کنید.
9. هزینه را با گزارش Provider تطبیق دهید.
10. هزینه هر نتیجۀ موفق را اندازه بگیرید.

در مدل‌های متنی، فرمول پایه به شکل زیر است:

هزینۀ کل =
(توکن ورودی × نرخ ورودی
+ توکن خروجی × نرخ خروجی)
÷ 1,000,000

اما در یک محصول واقعی، فرمول کامل‌تر است:

هزینۀ واقعی =
مدل
+ Cache
+ ابزار
+ Retry
+ Fallback
+ ذخیره‌سازی
+ زیرساخت
+ عملیات

درواره با فراهم کردن دسترسی یکپارچه به مدل‌های مختلف از طریق یک API، فرایند اتصال، آزمایش و مدیریت مصرف مدل‌ها را برای توسعه‌دهندگان ساده‌تر می‌کند.

برای شروع، API Key خود را ایجاد کنید، مدل موردنظر را انتخاب کنید و از Base URL زیر استفاده کنید:

https://api.darvareh.ir/v1

انتخاب هوشمندانۀ مدل، ثبت دقیق Usage و کنترل بودجه سه اصل مهم برای ساخت یک محصول هوش مصنوعی پایدار و اقتصادی هستند.

مقالات مرتبط پیشنهادی

• توکن در API هوش مصنوعی چیست و چگونه محاسبه می‌شود؟
• بهترین API هوش مصنوعی برای سایت و اپلیکیشن
• API سازگار با OpenAI چیست؟
• AI Gateway چیست و چه تفاوتی با API Gateway دارد؟
• Prompt Caching چیست و چگونه هزینه مدل را کاهش می‌دهد؟
• Context Window چیست و چه تأثیری بر هزینه API دارد؟
• Fallback در API هوش مصنوعی چیست؟
• Auto Router چیست و چگونه مدل مناسب را انتخاب می‌کند؟
• Embedding چیست و هزینۀ سیستم RAG چگونه محاسبه می‌شود؟