۵ استاندارد متناقض در محدودیت‌های API ارائه‌دهندگان هوش مصنوعی

اگر امروز یک توسعه‌دهنده سیستم تولید بازیابی‌افزا (RAG) را از DeepSeek به Anthropic منتقل کند، شاید انتظار داشته باشد که به دلیل سقف اسمی بالاتر در محدودیت نرخ (Rate Limit)، پایداری بیشتری تجربه کند، اما در واقع احتمالاً با کرش کردن برنامه مواجه خواهد شد. دلیل این تنش در نحوه تعریف «ظرفیت» توسط این دو تامین‌کننده نهفته است: یکی تعداد درخواست‌های جاری (In-flight) را می‌شمارد و دیگری توکن‌های ارسالی در دقیقه را.

تا ۲۲ ژوئیه ۲۰۲۶، چشم‌انداز APIهای مدل‌های زبانی بزرگ (LLM) با فقدان کامل استاندارد در بحث محدودیت نرخ (Rate Limiting) شناخته می‌شود. در حالی که توسعه‌نویسان اغلب به دنبال یک جدول مقایسه‌ای واحد هستند تا «برنده» را انتخاب کنند، چنین جدولی در واقع یک «خطای مقوله‌ای» (Category Error) است. هر ارائه‌دهنده، مفهوم «محدودیت» را به گونه‌ای متفاوت تعریف می‌کند و این موضوع یک بدهی فنی پنهان برای هر تیمی است که سعی دارد استراتژی چندمدلی (Multi-model Strategy) را پیاده کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی اولاما (Ollama) و ساده‌سازی استقرار مدل‌های محلی در سیستم‌عامل‌های مختلف اشاره کردیم، بازار APIهای ابری در حال حرکت در جهت مخالف است. به‌جای یکپارچگی، ما شاهد واگرایی در نحوه محافظت ارائه‌دهندگان از خوشه‌های محاسباتی (Compute Clusters) و نحوه درآمدزایی از پهنای باند (Throughput) هستیم.

کتاب‌های قانون: معیارهای متناقض

Anthropic شفاف‌ترین اما پیچیده‌ترین سیستم را به کار می‌گیرد و از سه محور استفاده می‌کند: درخواست در دقیقه (RPM)، توکن ورودی در دقیقه (ITPM) و توکن خروجی در دقیقه (OTPM). طبق مستندات رسمی، عبور از هر یک از این سه معیار، باعث تحریک خطای ۴۲۹ به همراه هدر retry-after می‌شود. این ظرفیت‌ها به صورت مستمر پر می‌شوند (الگوریتم Token Bucket)، به این معنی که شما منتظر یک زمان بازنشانی (Reset Timestamp) ثابت نمی‌مانید.

سطوح دسترسی در آنتروپیک — شامل Start، Build، Scale و Custom — به صورت مستقیم خریداری نمی‌شوند، بلکه بر اساس تاریخچه استفاده و وضعیت حساب کاربر تخصیص می‌یابند. هر یک از این سطوح دارای یک سقف هزینه ماهانه است:

• Start: ۵۰۰ دلار
• Build: ۱,۰۰۰ دلار
• Scale: ۲۰۰,۰۰۰ دلار
• Custom: بدون سقف (از طریق تیم مدیریت حساب هماهنگ می‌شود)

برای مدل‌های Claude Opus 4.x (که نسخه‌های ۴.۵ تا ۴.۸ را پوشش می‌دهد)، محدودیت‌ها به شدت مقیاس‌پذیر هستند. جدول زیر جزئیات تفکیکی هر مدل را در این سطوح نشان می‌دهد:

یک مزیت حیاتی در اینجا این است که توکن‌های خوانده شده از حافظه پنهک (cache_read_input_tokens) در محاسبه ITPM لحاظ نمی‌شوند. برای مثال، در یک سقف ۲ میلیون ITPM، اگر نرخ برخورد با کش (Cache Hit Rate) ۸۰٪ باشد، شما عملاً می‌توانید ۱۰ میلیون توکن ورودی در دقیقه ارسال کنید، زیرا ۸ میلیون توکن کش‌شده در محاسبه محدودیت ثبت نمی‌شوند. توجه داشته باشید که Claude Haiku 3.5 استثنا است و همچنان خواندن‌های کش را می‌شمارد. علاوه بر این، دسته‌های پیام (Message Batches) و عامل‌های مدیریت‌شده (Managed Agents) با محدودیت‌های جداگانه عمل می‌کنند (۳۰۰ RPM برای ایجاد / ۱,۲۰۰ RPM برای خواندن). رسیدن به سقف ترافیک دسته‌ای به این معنا نیست که محدودیت API پیام‌های شما تمام شده است.

DeepSeek یک outlier (داده پرت) در صنعت است. این شرکت بودجه‌های دقیقه‌ای را کاملاً نادیده می‌گیرد و در عوض «هم‌زمانی» (Concurrency) — یعنی تعداد درخواست‌هایی که در یک لحظه در سطح حساب در حال اجرا هستند — را محدود می‌کند. برای نمونه، مدل deepseek-v4-pro سقف هم‌زمانی ۵۰۰ و deepseek-v4-flash سقف ۲,۵۰۰ درخواست دارد. این مکانیسم آن را برای حجم‌های کاری عامل‌های موازی ایده‌آل می‌کند اما برای کسانی که انتظار بازپراری (Refill) مبتنی بر زمان را دارند، خطرناک است. برای کسانی که درخواست‌های مشتریان مختلف را تجمیع (Multiplex) می‌کنند، می‌توان از پارامتر user_id برای جداسازی هم‌زمانی به ازای هر کاربر نهایی استفاده کرد.

دیپ‌سیک همچنین با سربار سرور برخورد منحصر به فردی دارد. به‌جای رد درخواست در زمان شلوغی سرورها، اتصال را زنده نگه می‌دارد. برای فراخوانی‌های غیر استریم، خطوط خالی ارسال می‌کند و برای فراخوانی‌های استریم، نظرات SSE : keep-alive می‌فرستد. اتصال تنها زمانی بسته می‌شود که پس از ۱۰ دقیقه، استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند — آغاز نشده باشد.

OpenAI و Google Gemini از جداول استاتیک و عمومی فاصله گرفته‌اند. هر دو اکنون محدودیت‌های هر مدل را در داشبوردهای داخلی حساب کاربر مخفی کرده‌اند و دلیل آن را نیاز به تعدیلات مکرر ذکر می‌کنند. سطوح OpenAI بر اساس هزینه تجمعی پرداختی است، که از Tier 1 (۵ دلار پرداخت شده) تا Tier 5 (۱,۰۰۰ دلار پرداخت شده) متغیر است.

سطوح و سقف‌های OpenAI:

• Free: محدودیت جغرافیایی / سقف ۱۰۰ دلار مصرف ماهانه
• Tier 1: ۵ دلار پرداختی / سقف ۱۰۰ دلار مصرف ماهانه
• Tier 2: ۵۰ دلار پرداختی / سقف ۵۰۰ دلار مصرف ماهانه
• Tier 3: ۱۰۰ دلار پرداختی / سقف ۱,۰۰۰ دلار مصرف ماهانه
• Tier 4: ۲۵۰ دلار پرداختی / سقف ۵,۰۰۰ دلار مصرف ماهانه
• Tier 5: ۱,۰۰۰ دلار پرداختی / سقف ۲۰۰,۰۰۰ دلار مصرف ماهانه

محدودیت‌های آن‌ها گسترده است و RPM، RPD (درخواست در روز)، TPM، TPD و حتی محدودیت‌های صوتی و تصویری را پوشش می‌دهد. فضای خالی در لحظه (Real-time headroom) از طریق هدرهای x-ratelimit-limit-requests و x-ratelimit-remaining-requests ردیابی می‌شود. هر پستی که RPM دقیق هر مدل را برای OpenAI ذکر کند، احتمالاً یک snapshot قدیمی است، زیرا این اعداد مدام تغییر می‌کنند و در داشبورد قرار دارند.

Google Gemini یک لایه زمانی به صورت‌حساب خود اضافه کرده است. سطوح بر اساس هزینه و زمان سپری شده تعریف می‌شوند:

• Free: پروژه فعال یا تست رایگان / بدون سقف هزینه
• Tier 1: حساب پرداخت متصل / سقف ۲۵۰ دلار
• Tier 2: ۱۰۰ دلار پرداختی + ۳ روز از اولین پرداخت / سقف ۲,۰۰۰ دلار
• Tier 3: ۱,۰۰۰ دلار پرداختی + ۳۰ روز از اولین پرداخت / سقف ۲۰,۰۰۰ تا ۱۰۰,۰۰۰+ دلار

الزامات ۳ روزه و ۳۰ روزه غیرمعمول هستند؛ پرداخت مبلغ به تنهایی باعث حذف دوره انتظار نمی‌شود. آن‌ها همچنین یک دروازه هزینه ۱۰ دقیقه‌ای غلتان (Rolling 10-minute spend gate) را اعمال می‌کنند (۱۰ دلار برای Tier 1 و ۲۰۰ دلار برای Tier 2 و 3). یک جهش ناگهانی در هزینه می‌تواند کاربر را محدود (Throttle) کند، حتی اگر TPM او در محدوده مجاز باشد. عبور از محدودیت منجر به خطای 429 RESOURCE_EXHAUSTED می‌شود. این قوانین برای Gemini Developer API است؛ Vertex AI از یک سیستم سهمیه (Quota) کاملاً مجزا استفاده می‌کند.

Moonshot (Kimi) از یک نردبان پرداخت صریح بر اساس شارژهای تجمعی استفاده می‌کند. پلتفرم بین‌المللی آن‌ها (platform.kimi.ai) برای شروع به شارژ ۱ دلاری نیاز دارد. سطوح آن‌ها چهار متغیر را کنترل می‌کنند: هم‌زمانی، RPM، TPM و توکن در روز (TPD).

مون‌شات همچنین یک پلتفرم داخلی (platform.moonshot.cn) با نردبان RMB (از ۰ تا ۲۰,۰۰۰ یوان) دارد که شرایط ورود متفاوتی دارد و این دو صرفاً تبدیل ارز یکدیگر نیستند. پرش از سطح ۰ به ۱ بسیار شدید است: با ۹ دلار شارژ اضافی، RPM از ۳ به ۲۰۰ و هم‌زمانی از ۱ به ۵۰ می‌رسد. کاربران باید بدانند که مدل‌های جدید مثل Kimi K3 ممکن است به دلیل محدودیت‌های ظرفیت بالادستی، فارغ از سطح کاربر، خطای ۴۲۹ بدهند. در چنین مواردی، خرید سطح بالاتر هیچ سودی ندارد و یک مدل جایگزین (Fallback) الزامی است.

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

بسته به معماری برنامه شما، اولین دیواری که با آن برخورد می‌کنید متفاوت است. بحث بر سر این نیست که چه کسی «بالاترین RPM» را دارد، بلکه این است که کدام طراحی محدودیت با الگوی فراخوانی شما سازگار است.

• فراخوانی‌های کوچک و سریع (مثل Autocomplete یا رابط کاربری چت): شما با محدودیت RPM (درخواست در دقیقه) برخورد می‌کنید. Anthropic Scale یا OpenAI Tier 4-5 بهترین گزینه‌ها هستند.
• فراخوانی‌های با زمینه عظیم (مثل RAG یا اسناد طولانی): شما با ITPM/TPM (توکن ورودی در دقیقه) مواجه می‌شوید. آنتروپیک به دلیل رایگان بودن خواندن حافظه پنهک، قوی‌ترین انتخاب است.
• عامل‌های موازی (Parallel Agents با پخش گسترده ناگهانی): شما با محدودیت‌های هم‌زمانی (Concurrency) می‌جنگید. مدل دیپ‌سیک دقیقاً برای این کار طراحی شده است، به ویژه سقف ۲,۵۰۰ تایی در مدل Flash.
• مقیاس پایدار (تولید/Production): سقف هزینه ماهانه مانع شماست. OpenAI Tier 5 (سقف ۲۰۰ هزار دلار) یا Anthropic Scale اهداف نهایی هستند.
• ورودی یا بودجه‌های محدود: با سقف‌های سطوح اولیه برخورد می‌کنید، مانند Moonshot T0-T1 یا Gemini Free.

برای روشن شدن موضوع، ۵۰ ورکر (Worker) که درخواست‌های RAG با ۳۰,۰۰۰ توکن می‌فرستند، تنها ۱۰٪ از سقف ۵۰۰ هم‌زمانی DeepSeek-v4-pro را اشغال می‌کنند. اما در ارائه‌دهنده‌ای با سقف ۲ میلیون ITPM، همین ۵۰ درخواست در یک دقیقه، مجموعاً ۱.۵ میلیون توکن مصرف کرده و ۷۵٪ ظرفیت را می‌گیرد و با هر نوسان کوچک ترافیکی، ریسک خطای ۴۲۹ را به همراه دارد. به همین دلیل مهاجرت بین ارائه‌دهندگان غافلگیرکننده است: دیواری که به آن توجه نمی‌کردید، همان دیواری می‌شود که شما را می‌زند.

رمزگشایی از سیگنال ۴۲۹

مدیریت خطای ۴۲۹ مستلزم دانستن نوع دیواری است که به آن برخورد کرده‌اید، زیرا راهکار برای محدودیت‌های «صبر کن» (بودجه‌های دقیقه‌ای) با محدودیت‌های «کاهش سرعت» (هم‌زمانی) متفاوت است.

• Anthropic: دقیق‌ترین داده‌ها را از طریق هدرهای anthropic-ratelimit-requests-remaining ، -input-tokens-remaining و -output-tokens-remaining ارائه می‌دهد. این به شما می‌گوید دقیقاً کدام محور به صفر رسیده است و هدر retry-after می‌گوید چند ثانیه صبر کنید.
• OpenAI: از هدرهای x-ratelimit-remaining-requests و x-ratelimit-remaining-tokens برای اعلام وضعیت پنجره زمانی استفاده می‌کند.
• Google Gemini: خطای RESOURCE_EXHAUSTED می‌دهد. شما باید تشخیص دهید این محدودیت دقیقه‌ای است یا دروازه هزینه ۱۰ دقیقه‌ای غلتان.
• DeepSeek: در صورت رسیدن به سقف هم‌زمانی، خطای ۴۲۹ استاندارد می‌دهد. چون این یک محدودیت «کاهش سرعت» است، صرفاً صبر کردن برای چند ثانیه بدون کاهش تعداد درخواست‌های جاری (Worker pool)، مشکلی را حل نمی‌کند. تلاش مجدد برای خطای هم‌زمانی بدون کاهش درخواست‌های در جریان، فقط باعث برخورد دوباره به همان دیوار می‌شود.
• Moonshot / Kimi: خطای استاندارد ۴۲۹ می‌دهد. کاربر باید بررسی کند که آیا از محور هم‌زمانی، RPM یا TPM عبور کرده است.

استراتژی‌های جایگزین (Failover)

از آنجا که هیچ ارائه‌دهنده‌ای سقف جهانی و همه‌جانبه ندارد، تاب‌آورترین معماری، یک حلقه جایگزین بین‌شرکتی (Cross-vendor failover) است. با قرار دادن چندین ارائه‌دهنده پشت یک درگاه واحد مانند ofox، خطای ۴۲۹ از یک شرکت باعث انتقال خودکار به شرکت دیگر می‌شود.

مثلاً یک زنجیره درخواست می‌تواند از deepseek-v4-pro به glm-5.2 و سپس به kimi-k3 برود. این کار محدودیت ساختاری لایه‌ی زیرساختی یک شرکت — مانند سقف هم‌زمانی — را که با ارتقای سطح پرداخت نیز قابل حذف نیست، به یک افزایش جزئی در تأخیر (Latency) تبدیل می‌کند، نه یک شکست کامل برنامه.

import os, time, random, httpx
OFOX = "https://api.ofox.ai/v1/chat/completions"
HEADERS = {"Authorization": f"Bearer {os.environ['OFOX_API_KEY']}"}
CHAIN = ["deepseek/deepseek-v4-pro", "z-ai/glm-5.2", "moonshotai/kimi-k3"]

def ask(messages):
    for model in CHAIN:
        for attempt in range(3):
            r = httpx.post(OFOX, headers=HEADERS, json={"model": model, "messages": messages}, timeout=60)
            if r.status_code == 429:
                if attempt == 2: break # Hop to next vendor
                base = 2 ** attempt
                time.sleep(base + random.uniform(0, base * 0.3))
                continue
            r.raise_for_status()
            return model, r.json()
    raise RuntimeError("every vendor in the chain is rate-limited right now")

import OpenAI from "openai";
const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY
});
const chain = ["deepseek/deepseek-v4-pro", "z-ai/glm-5.2", "moonshotai/kimi-k3"];
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

export async function ask(messages) {
  for (const model of chain) {
    for (let attempt = 0; attempt < 3; attempt++) {
      try {
        return { model, res: await client.chat.completions.create({ model, messages }) };
      } catch (e) {
        if (e.status !== 429) throw e;
        if (attempt === 2) break;
        const base = 2 ** attempt;
        await sleep((base + Math.random() * base * 0.3) * 1000);
      }
    }
  }
  throw new Error("every vendor in the chain is rate-limited right now");
}

این رویکرد از «کرش‌های مرموز» جلوگیری می‌کند؛ جایی که سیستم در محیط تست (Staging) عالی عمل می‌کند اما در تولید (Production) به دلیل یک دیوار پنهان توکن-در-دقیقه می‌لرزد. بسته به نیاز خود، می‌توانید بین چندین مسیر یکپارچه‌سازی انتخاب کنید:

• ofox (درگاه واحد): بهترین برای جایگزینی بین‌شرکتی با یک کلید. ریسک توقف درخواست توسط یک ارائه‌دهنده را کم می‌کند. این روش سقف فیزیکی ارائه‌دهنده‌ها را بالا نمی‌برد، اما منطق مسیریابی (Routing) را ساده می‌کند.
• کلیدهای مستقیم ارائه‌دهنده: کمترین قیمت به ازای هر توکن و بیشترین کنترل، اما نیاز به مدیریت دستی هر مدل محدودیت (مثل keep-alive در دیپ‌سیک یا دروازه هزینه گوگل دارد).
• OpenRouter/Aggregators: یکپارچه‌سازی مدل‌ها، اما نیاز به مقایسه مدل‌های هزینه و منطق جایگزینی در سطح ارائه‌دهنده دارد، زیرا مدل‌های تک-ارائه‌دهنده چیزی برای مسیریابی مجدد ندارند.
• Router سفارشی: کنترل کامل بر منطق تلاش مجدد (Retry) و جایگزینی، اما هزینه نگهداری تمام پیچیدگی‌ها و رفتارهای خاص هر شرکت بر عهده توسعه‌دهنده است.

این پراکندگی، هزینه جابجایی (Switching Cost) را به طور بنیادی تغییر می‌دهد. تغییر ارائه‌دهنده دیگر فقط جایگزینی یک کلید API نیست، بلکه نیاز به یک ممیزی کامل این است که شکل درخواست‌های خاص شما چگونه با منطق محدودکننده شرکت جدید تعامل می‌کند. هر مسیری را که انتخاب کنید، بدانید که هیچ چیز محدودیت نرخ ارائه‌دهنده را حذف نمی‌کند — تنها راهکار این است که تا چه حد هوشمندانه درخواست‌ها را به دور از اولین دیواری که برخورد می‌کنند، مسیریابی کنید.

گام بعدی شما

• اگر از چندین مدل استفاده می‌کنید، یک جدول اثرات متقابل (Cross-matrix) از RPM و TPM ایجاد کنید تا نقاط شکست احتمالی را شناسایی نمایید.
• برای سیستم‌های حساس، منطق Failover را با استفاده از درگاه‌های یکپارچه پیاده‌سازی کنید تا وابستگی به تک-تامین‌کننده حذف شود.
• در مدیریت خطای ۴۲۹، هدرهای retry-after را به جای استفاده از زمان‌های تصادفی، به عنوان منبع اصلی زمان‌بندی بازگشت قرار دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.