محدودیتها
محدودیتها
محدودیتهای داتهوش دو دستهاند: سقفهایی که شما هنگام ساخت API key تعیین میکنید، و مرزهای ثابتی که خود gateway برای هر درخواست اعمال میکند. همهٔ آنها در سمت سرور اجرا میشوند.
سقفهای هر API key
هنگام ساخت key این مقادیر را تعیین میکنید و در سمت سرور روی همان key اعمال میشوند:
| سقف | کد رد شدن |
|---|---|
| درخواست در دقیقه (RPM) | api_key_rpm_exceeded |
| توکن در دقیقه (TPM) | api_key_tpm_exceeded |
| درخواست همزمان در جریان | api_key_concurrency_exceeded |
| سقف هزینه، به تومان | api_key_or_account_spend_limit |
| فهرست مدلهای مجاز | api_key_model_not_allowed |
| فهرست IP مجاز | api_key_ip_not_allowed |
| scopeها | api_key_scope_insufficient |
| زمان انقضا | api_key_expired |
سه کد اول با وضعیت 429 برمیگردند و retryable: true دارند؛ سقف هزینه و کنترلهای مجوز با 403 برمیگردند و تلاش دوباره در آنها فایدهای ندارد.
این سقفها محافظ شما هم هستند: کلید افشاشده نمیتواند سریعتر از سقفهایش از کیف پول خرج کند. تا جایی که بار کاریتان اجازه میدهد آنها را تنگ ببندید.
پس از ساخت، بخشی از این مقادیر از سرور خوانده نمیشود. در نسخهٔ فعلی API فقط requestsPerMinute روی خواندن key برمیگردد؛ بقیه هنگام ساخت ثبت میشوند و باید همانجا با دقت وارد شوند. عوضکردن آنها بعداً به معنای ساخت key تازه است.
TPM چطور حساب میشود
سقف توکن در دقیقه پیش از اجرای درخواست با یک برآورد بررسی و پس از اجرا با مصرف اندازهگیریشده تسویه میشود. بنابراین درخواستی با max_completion_tokens بزرگ، همان ابتدا بخش بزرگی از سهمیهٔ دقیقهٔ شما را میگیرد، حتی اگر در نهایت کمتر مصرف کند. اگر سقف تنگی دارید، سقف توکن خروجی را واقعبینانه بگذارید.
مرزهای هر درخواست
اینها پیشفرضهای gateway هستند و در محیط شما ممکن است سختگیرانهتر تنظیم شده باشند:
| مرز | پیشفرض |
|---|---|
| اندازهٔ بدنهٔ درخواست | ۱۶ مگابایت |
| عمق JSON | ۶۴ |
| تعداد گرههای JSON | ۱۰۰٬۰۰۰ |
| طول هر رشتهٔ JSON | ۲۵۶ کیلوبایت |
| تعداد اعضای یک آرایه | ۱۶٬۳۸۴ |
| تعداد فیلدهای یک شیء | ۲۵۶ |
| سقف توکن خروجی | ۱٬۰۰۰٬۰۰۰ |
| درخواستهای همزمان روی این نمونه | ۱۰٬۰۰۰ |
| مهلت اتصال به ارائهدهنده | ۲ ثانیه |
| مهلت کل فراخوانی سرویسهای داخلی | ۱۰ ثانیه |
عبور از هر یک از این مرزها یک خطای 400 است، نه پاسخ ناقص.
سقفهای مدل
context_window و max_output_tokens هر مدل در پاسخ GET /v1/models میآید؛ همین دو مرجع معتبرند. عبور از طول زمینه با context_length_exceeded رد میشود.
فشار روی خود سرویس
اگر بار روی سرویس از ظرفیت عبور کند، بهجای پاسخ کند یا نیمهکاره، خطای صریح میگیرید:
- service_degraded — ظرفیت این نمونه در حال اشباع است.
- all_same_model_endpoints_unavailable — برای این مدل مسیر سالمی نمانده است.
- provider_overloaded — ارائهدهنده ظرفیت ندارد.
هر سه قابلتلاشدوباره هستند؛ با احترام به retry_after_seconds دوباره بفرستید.
مطالب مرتبط
- خطاها و محدودیتها — جدول کامل کدها و قاعدهٔ تلاش دوباره
- مسیردهی و تلاش مجدد
- احراز هویت و امنیت کلید
گام بعدی
BYOK یعنی «کلید ارائهدهندهٔ خودت»: بهجای اعتبار مشترک داتهوش، درخواست با اعتبارنامهٔ خودتان روی حساب خودتان با ارائهدهنده اجرا میشود. این صفحه هم معنای BYOK را توضیح میدهد و هم — مهمتر — میگوید امروز از آن چه چیزی در دسترس است و چه چیزی نیست.
این صفحه دقیقاً میگوید چه چیزی ذخیره میشود، چه چیزی نمیشود، و چه چیزی در کنترل داتهوش نیست. برای تصمیمهای حساس، همین تفکیک مهم است.
هر خطا با پوشش بومی پروتکل برمیگردد تا مدیریت خطای SDK شما بدون تغییر کار کند. داتهوش روی پوشش OpenAI چند فیلد اضافه میگذارد که برای تصمیمگیری لازماند.