لایهٔ کنترل پذیرش؛ سدی در برابر هزینه‌های پیش‌بینی‌نشده در گیت‌وی‌های AI

یک عامل کدنویسی که بدون کلید حافظه، یک اسنپ‌شات یک میلیون توکنی از مخزن کد را ارسال کند، می‌تواند در یک لحظه کل بودجه تولیدی شما را نابود کند. اگر امروز از گیت‌وی‌های سازگار با OpenAI برای مدل‌های چینی استفاده می‌کنید، باید بدانید گران‌ترین باگ‌ها دقیقاً پیش از آنکه درخواست به ارائه‌دهنده برسد، رخ می‌دهند. یک گردش‌کار پشتیبانی ممکن است در هر تلاش مجدد، جست‌وجوی وب را فعال کند، یا یک شغل دسته‌ای مشتری ممکن است از ۳۱ هزار به ۳۳ هزار توکن ورودی افزایش یابد و از یک سطح قیمت‌گذاری زمینه (Context Billing Tier) عبور کند. در برخی موارد، یک مسیر جایگزین به‌طور خاموش از یک مدل متنی به یک مسیر چندوجهی (Multimodal) تغییر مسیر می‌دهد. در این حالت، شکل API همچنان آشنا به نظر می‌رسد، اما پروفایل عملیاتی به‌طور کامل تغییر کرده است.

در ۱۸ اوت ۲۰۲۶، یک راهنمای فنی تشریح کرد که تیم‌های مهندسی چگونه می‌توانند یک کنترل‌کننده پذیرش (Admission Controller) پیاده‌سازی کنند تا کنترل رفتار زمان اجرای AI را بازپس گیرند. کنترل‌کننده پذیرش — شبیه به یک نگهبان سخت‌گیر در ورودی ساختمان که مدارک را پیش از ورود چک می‌کند — لایه سیاستی کوچکی است که پیش از اعزام درخواست اجرا می‌شود. این لایه تصمیم می‌گیرد که آیا درخواست اکنون ارسال شود، باید تغییر شکل یابد، در صف قرار گیرد، از مسیر متفاوتی استفاده کند یا با یک توضیح دقیق رد شود. این سازوکار دقیقاً مشابه روشی است که کوبرنتیز (Kubernetes) برای محافظت از خوشه‌ها از کنترل پذیرش استفاده می‌کند.

بسیاری از توسعه‌دهندگان تصور می‌کنند تمام مسیرهای تکمیل متن یکسان هستند، اما واقعیت این است که پروفایل عملیاتی مدل‌هایی مثل DeepSeek، Kimi K3، GLM و Qwen تفاوت‌های شدیدی با هم دارند. این تنوع مدل‌ها باعث شده تا پلتفرم‌هایی مانند AIBridge تلاش کنند دسترسی به مدل‌های برتر چینی را در یک درگاه واحد متمرکز کنند تا مدیریت آن‌ها ساده‌تر شود. با این حال، یک درخواست که در یک مدل به‌درستی اجرا می‌شود، ممکن است در مدل دیگر باعث جهش در سطح قیمت‌گذاری یا خطای ۴۲۹ (محدودیت نرخ درخواست) در سمت ارائه‌دهنده شود. گیت‌وی‌های AI چندمدلی به این لایه نیاز دارند تا موارد زیر را مدیریت کنند:

• بودجه‌های توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد.
• سطوح پنجرهٔ زمینه (Context Tiers).
• الزامات حافظه (Cache).
• سقف خروجی و هزینه‌های ابزار.
• سیاست‌های منطقه‌ای و ظرفیت ارائه‌دهنده.

منطق کنترل پذیرش

یک کنترل‌کننده پذیرش پرسش‌های خاصی می‌پرسد که یک مسیریاب (Router) ساده نادیده می‌گیرد. مسیریاب فقط می‌پرسد «کدام مدل باید این پرامپت را مدیریت کند؟»، اما کنترل‌کننده پذیرش می‌پرسد «آیا هزینه تولید، تأخیر یا پروفایل انطباق این درخواست پیش از اجازه عبور مشخص است؟»

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

• سطوح زمینه: درخواست‌های ۹۹۰ هزار توکنی Qwen فقط در مسیرهایی مجاز هستند که صراحتاً از زمینه ۱ میلیون توکنی پشتیبانی می‌کنند.
• الزامات حافظه: درخواست‌های مکرر با زمینه طولانی باید شامل یک کلید حافظه پایدار باشند، در غیر این صورت به مسیری کوتاه‌تر و ارزان‌تر هدایت می‌شوند.
• سقف خروجی: درخواست‌های با خروجی بالا برای Kimi K3 نیازمند بودجه تاییدشده برای توکن‌های تکمیل هستند تا از هزینه‌های سرسام‌آور جلوگیری شود.
• محدودیت‌های هم‌زمانی: مسیرهای DeepSeek V4 Pro زمانی که استخر هم‌زمانی حساب به آستانه ۹۰٪ برسد، در صف قرار می‌گیرند.
• بودجه ابزار: فراخوانی ابزارها برای GLM یا Qwen باید شامل بودجه و حد مجاز تلاش مجدد باشد تا از انباشت هزینه‌ها جلوگیری شود.
• سیاست منطقه‌ای: بارهای کاری حساس به GDPR باید از منطقه و سیاست لاگ‌گذاری تاییدشده استفاده کنند.
• یکپارچگی جایگزین: مسیر جایگزین (Fallback) نباید به‌طور خاموش کاربر را به کلاس قیمت‌گذاری متفاوتی منتقل کند.

استخراج قوانین ارائه‌دهندگان

برای ساخت یک کنترل‌کننده مؤثر، سیاست‌ها باید بر اساس منابع تاریخ‌دار باشند، نه حافظه. طبق داده‌های ۱۸ اوت ۲۰۲۶، سیگنال‌های زیر از ارائه‌دهندگان حیاتی هستند:

• DeepSeek: مستندات V4 Flash و V4 Pro، پنجره زمینه ۱ میلیون توکنی، نرخ‌های ورودی در حالت hit و miss حافظه، نرخ‌های خروجی، بازه‌های زمانی اوج و غیر اوج (Peak/Off-peak) و محدودیت‌های هم‌زمانی سطح حساب را لیست کرده‌اند.
• Kimi: قیمت‌گذاری Kimi K3 پنجره زمینه ۱,۰۴۸,۵۷۶ توکنی را با قیمت‌های مجزا برای hit حافظه، miss حافظه و خروجی منتشر کرده است.
• Z.AI (GLM): مدل‌های GLM-5.2 و GLM-5.1 دسته‌بندی‌های قیمتی متمایزی برای ورودی، ورودی حافظه‌شده، خروجی، ابزارها، بینایی، تصویر، ویدیو، صوت و عامل‌ها (Agents) دارند.
• QwenCloud: مستندات Qwen3.7 Plus و Flash مواردی چون قیمت‌گذاری لایه‌های زمینه، رفتار API دسته‌ای (Batch API)، حافظه زمینه، قیمت‌گذاری توکن‌های تفکر (Thinking Tokens)، هزینه‌های ابزار، مسیرهای ۱ میلیون توکنی، TPM و RPM را پوشش می‌دهند.
• Baidu Qianfan: مسیرهای ERNIE به‌عنوان سیاست‌های قیمت‌گذاری و در دسترس بودن خاص ارائه‌دهنده در نظر گرفته شده و سپس در گیت‌وی نرمال‌سازی می‌شوند.
• AIWave: یک API یکپارچه باید متادیتای مدل و تصمیمات مسیریابی را افشا کند تا تیم‌های اپلیکیشن مجبور به یادگیری تک‌تک ساختارهای قیمت‌گذاری بالادستی نباشند.

پیاده‌سازی لایه سیاست

به گزارش dev.to، اولین گام، نرمال‌سازی درخواست فراخوان در یک شیء داخلی AdmissionRequest است. این کار تضمین می‌کند که ارزیابی سیاست مستقل از فرمت ارائه‌دهنده (OpenAI Chat Completions، Responses API، فرمت Anthropic یا یک Payload سفارشی) باشد.

from dataclasses import dataclass, field

@dataclass(frozen=True)
class AdmissionRequest:
    tenant_id_hash: str
    region: str
    workload: str
    requested_model: str
    prompt_tokens: int
    max_output_tokens: int
    has_cache_key: bool
    cache_expected: bool
    uses_images: bool = False
    uses_video: bool = False
    uses_web_search: bool = False
    uses_code_interpreter: bool = False
    requested_fallbacks: list[str] = field(default_factory=list)

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

برای جلوگیری از پیچیدگی کد و زنجیره‌های طولانی از دستورات if، قوانین باید به‌عنوان داده‌های تاریخ‌دار ذخیره شوند. این کار باعث می‌شود تغییرات قیمت، زمینه و ظرفیت قابل بازبینی باشند. برای مثال، در اسنپ‌شات ۱۸ اوت ۲۰۲۶، مدل deepseek-v4-pro دارای پنجره زمینه ۱ میلیون توکنی، سقف خروجی ۳۸۴ هزار و حد هم‌زمانی ۵۰۰ درخواست است. در مقابل، qwen3.7-flash ممکن است پنجره زمینه ۱ میلیون توکنی، سقف خروجی ۱۳۱ هزار، حد TPM ۵ میلیون و حد RPM ۱۵ هزار داشته باشد. مدل glm-5.1 روی ۱۲۸ هزار توکن زمینه و ۳۲ هزار توکن خروجی محدود شده است.

تصمیمات باید به‌عنوان اکشن‌های صریح بازگردانده شوند، نه صرفاً درست یا غلط. یک مقدار ساده true یا false باعث می‌شود فراخوان مجبور شود حدس بزند چه اتفاقی افتاده است. کنترل‌کننده از پنج اکشن پایدار استفاده می‌کند:

۱. Allow: اعزام فوری در مسیر انتخاب‌شده.
۲. Reshape: ارسال پس از کاهش سقف خروجی، غیرفعال کردن یک ابزار یا الزام به ارائه کلید حافظه.
۳. Queue: انتظار به دلیل محدودیت ظرفیت مسیر.
۴. Fallback: استفاده از مسیر جایگزین تاییدشده با سیاست مشابه.
۵. Deny: رد درخواست با دلیلی که برای توسعه‌دهنده قابل خواندن باشد.

ارزیابی سیاست پیش از اعزام

ارزیاب در مورد زمینه طولانی و استفاده از ابزار بسیار سخت‌گیر است. اگر درخواستی از max_context_tokens یک مسیر فراتر رود، رد می‌شود. اگر max_output_tokens بیش از حد باشد، اکشن روی reshape تنظیم شده و سقف خروجی به حد مجاز سیاست آن مسیر کاهش می‌یابد و یک هشدار صادر می‌شود.

آستانه‌های حافظه نیز اجرا می‌شوند. اگر درخواستی بدون کلید حافظه پایدار از حد مجاز requires_cache_key_above_tokens عبور کند (مثلاً ۲۰۰ هزار توکن برای DeepSeek V4 Pro یا ۱۲۸ هزار توکن برای Qwen3.7 Flash)، رد می‌شود. به همین ترتیب، درخواست‌های شامل تصویر، ویدیو، جست‌وجوی وب یا مفسر کد در صورتی که مسیر صراحتاً از این قابلیت‌ها یا ابزارها پشتیبانی نکند، پذیرفته نمی‌شوند.

در نهایت، کنترل‌کننده ظرفیت زنده را بررسی می‌کند. اگر درخواست‌های فعال برای یک ارائه‌دهنده به ۹۰٪ حد هم‌زمانی حساب (account_concurrency_limit) برسد، درخواست در صف قرار می‌گیرد. این آستانه یک مثال است؛ عامل‌های کدنویسی تعاملی ممکن است به سیاست‌های صف‌بندی متفاوتی نسبت به کارهای ارزیابی آفلاین نیاز داشته باشند.

مدیریت جایگزین‌ها و متادیتا

جایگزین‌ها (Fallbacks) اغلب جایی هستند که گیت‌وی‌ها کنترل را از دست می‌دهند. جایگزینی که پنجره زمینه، نوع داده (Modality)، قیمت ابزار یا سقف خروجی را تغییر می‌دهد، باید به‌عنوان یک درخواست پذیرش جدید تلقی شود. سیستم از میان requested_fallbacks عبور کرده و برای هر کاندید، یک AdmissionRequest جدید می‌سازد و آن را از تابع admit عبور می‌دهد.

این موضوع هنگام جابجایی بین ارائه‌دهندگان حیاتی است. یک مسیر DeepSeek V4 ممکن است پنجره زمینه ۱ میلیون توکنی و سیگنال‌های هم‌زمانی سطح حساب را افشا کند، در حالی که مسیر Qwen لایه‌های زمینه، TPM، RPM و توکن‌های تفکر را نمایش می‌دهد. مسیر GLM دسته‌بندی‌های مجزایی برای متن، بینایی، ابزارها، تولید تصویر، ویدیو، صوت و محصولات عامل (Agent) اضافه می‌کند. تلقی کردن این‌ها به‌عنوان مسیرهای ساده تکمیل متن، یک باگ عملیاتی است.

برای بهبود تجربه توسعه‌دهنده (SDK ergonomics)، گیت‌وی باید متادیتای پذیرش را در پاسخ نمایش دهد. در پاسخ‌های سازگار با OpenAI، شکل استاندارد حفظ می‌شود اما یک شیء aiwave با فضای نام اختصاصی اضافه می‌شود:

{
  "id": "chatcmpl_placeholder",
  "object": "chat.completion",
  "model": "qwen3.7-flash",
  "usage": { "prompt_tokens": 240000, "completion_tokens": 1800, "total_tokens": 241800 },
  "aiwave": {
    "admission": {
      "action": "allow",
      "snapshot_date": "2026-08-17",
      "route": "qwen3.7-flash",
      "reason": "request satisfies route admission policy",
      "cache_required": true,
      "cache_key_present": true,
      "tool_budget_applied": false
    }
  }
}

وقتی کنترل‌کننده درخواستی را رد می‌کند، یک خطای اپلیکیشن شفاف شامل نوع admission_denied و پیامی مثل «درخواست‌های زمینه طولانی نیازمند کلید حافظه پایدار هستند» و همچنین تخمینی از توکن‌های پرامپت برمی‌گرداند. این بسیار مفیدتر از خطای ۴۲۹ ارائه‌دهنده یا Timeout است.

مشاهده‌پذیری عملیاتی

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

• رد پذیرش بر اساس دلیل: نشان می‌دهد که آیا مستندات، پیش‌فرض‌های SDK یا پرامپت‌های مشتری نیاز به اصلاح دارند.
• توکن‌های خروجی تغییرشکل‌یافته بر اساس مسیر: نقاطی را که بودجه‌های تکمیل بیش از حد باز هستند، افشا می‌کند.
• درخواست‌های صف‌بندی‌شده بر اساس ارائه‌دهنده: پیش از آنکه خطاهای ۴۲۹ برای کاربر قابل مشاهده شوند، هشدار می‌دهد.
• جایگزین‌ها بر اساس مسیر اصلی: وابستگی‌های پنهان به ارائه‌دهندگان ثانویه را شناسایی می‌کند.
• درخواست‌های زمینه طولانی بدون کلید حافظه: گردش‌کارهایی را می‌یابد که به پشتیبانی حافظه در سطح SDK نیاز دارند.
• تلاش‌های مجدد فعال‌شده با ابزار: از حلقه‌های تکرار که هزینه‌های ابزار را چندبرابر می‌کنند، جلوگیری می‌کند.

چک‌لیست عملیاتی برای انتشار

پیش از فعال کردن یک مسیر مدل چینی جدید در محیط تولید، شرایط زیر باید برقرار باشد:

• منبع قیمت‌گذاری: صفحات رسمی ارائه‌دهنده باز شده و تاریخ‌گذاری شده باشند.
• پنجره زمینه: مسیر دارای سیاست تست‌شده برای حداکثر ورودی و حداکثر خروجی باشد.
• سیاست حافظه: درخواست‌های زمینه طولانی نیازمند کلید حافظه پایدار باشند.
• سیاست ابزار: مسیرهای فعال‌شده با ابزار دارای محدودیت‌های صریح برای هر درخواست باشند.
• سیاست ظرفیت: محدودیت‌های هم‌زمانی، TPM یا RPM در داده‌ها نمایش داده شده باشند.
• سیاست جایگزین: جایگزین‌ها به‌طور مجزا پذیرفته شوند و به‌طور خاموش جایگزین نشوند.
• متادیتای پاسخ: کاربران SDK بتوانند اسنپ‌شات و دلیل پذیرش را مشاهده کنند.
• بهداشت لاگ‌ها: هیچ داده شخصی، رمز یا پرامپت خامی در لاگ‌های پذیرش نوشته نشود.

این الگو محدود به یک ارائه‌دهنده نیست. هم‌زمانی و بازه‌های اوج DeepSeek، اقتصاد حافظه زمینه طولانی Kimi، کاتالوگ گسترده ابزارها و وجه‌های GLM، لایه‌های زمینه و هزینه‌های ابزار QwenCloud و قیمت‌گذاری خاص ERNIE همگی به یک نتیجه مهندسی اشاره دارند: سازگاری درخواست (Request Compatibility) با سازگاری تولیدی (Production Compatibility) یکی نیست.

نتیجه نهایی: APIهای سازگار با OpenAI ارزشمند هستند زیرا کار یکپارچه‌سازی را کاهش می‌دهند، اما نیاز به سیاست‌گذاری را از بین نمی‌برند. اگر گیت‌وی شما هر درخواستی را که با امضای متد SDK مطابقت دارد می‌پذیرد، در واقع اجازه داده است که بازار ارائه‌دهنده، رفتار زمان اجرای شما را تعریف کند. یک کنترل‌کننده پذیرش این کنترل را به تیم پلتفرم بازمی‌گرداند. برای تیم‌هایی که از نقاط انتهایی یکپارچه مانند AIWave استفاده می‌کنند، این لایه تضمین می‌کند که متادیتای مدل و تصمیمات مسیریابی افشا شوند، بدون اینکه هر تیم اپلیکیشن مجبور باشد ساختارهای قیمت‌گذاری هر ارائه‌دهنده بالادستی را یاد بگیرد. این سیستم، طول زمینه، آمادگی حافظه، سقف خروجی، استفاده از ابزار، هم‌زمانی و رفتار جایگزین را به تصمیمات صریحی تبدیل می‌کند که توسعه‌دهندگان می‌توانند پیش از خروج درخواست از سیستم، آن‌ها را درک کنند.