یک اپلیکیشن هوش مصنوعی در مقیاس عملیاتی ممکن است نه به دلیل ضعف مدل، بلکه به خاطر پراکسیِ جلوی آن کرش کند. طبق تحلیل فنی منتشر شده در ۱۵ اکتبر ۲۰۲۶، پراکسی‌های استاندارد REST باعث ایجاد نقاط شکست بحرانی می‌شوند—به‌ویژه توقف‌های بافر استریم و تایم‌اوت‌های پیش‌پُرکردن—که در معماری‌های سنتی میکروسرویس وجود نداشتند. استقرار یک گیت‌وی LLM اغلب فاش می‌کند که الگوهای استاندارد پراکسی HTTP زمانی که با استریم‌های طولانی‌مدت، تولید توکن‌های پویا و تایم‌اوت‌های آبشاری در سمت ارائه‌دهنده مواجه می‌شوند، شکست می‌خورند.

بسیاری از تیم‌های مهندسی برای متمرکز کردن دسترسی به چندین ارائه‌دهنده، اعمال سقف هزینه‌های جهانی و پیاده‌سازی جایگزینی خودکار (Failover)، از گیت‌وی‌های هوش مصنوعی استفاده می‌کنند. آن‌ها تصور می‌کنند با یک تغییر ساده در base_url در SDK، همه چیز به‌طور یکپارچه کار می‌کند. در تئوری، این فرآیند Onboarding ساده است: توسعه‌دهنده آدرس base_url را از نقطه انتهایی ارائه‌دهنده به URL گیت‌وی داخلی تغییر می‌دهد و یک اعتبارنامه‌ی گیت‌وی را ارسال می‌کند، بدون اینکه منطق برنامه تغییر کند.

قبل: اتصال مستقیم به ارائه‌دهنده

from openai import OpenAI
client = OpenAI(
    api_key="sk-provider-secret-key"
)

بعد: اتصال مسیریابی شده از طریق گیت‌وی LLM

client = OpenAI(
    base_url="http://gateway.internal:8080/v1",
    api_key="sk-bf-virtual-key"
)

اما تفاوت در اینجاست: در حالی که یک فراخوانی API استاندارد که روی بدنه ثابت JSON کار می‌کند در ۵۰ تا ۲۰۰ میلی‌ثانیه تمام می‌شود، پاسخ یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — می‌تواند ۳۰ تا ۱۲۰ ثانیه اتصال را باز نگه دارد تا صدها توکن را از طریق انتقال‌های HTTP تکه‌تکه (Chunked) ارسال کند. مسیریابی ترافیک استنتاج (Inference) غیرقطعی — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — با مسیریابی داده‌های استاتیک میکروسرویس‌ها کاملاً متفاوت است.

همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه Patronus از LLMها در برابر تزریق پرامپت غیرمستقیم محافظت می‌کند اشاره کردیم، اکنون تمرکز از امنیت محتوا به پایداری زیرساخت تغییر کرده است. این تغییر رویکرد در حالی رخ می‌دهد که اتکای بیش از حد به مدل‌های زبانی برای مدیریت امنیت می‌تواند ریسک‌های ساختاری جدیدی را در خط تولید نرم‌افزار ایجاد کند. برای یک توسعه‌دهنده عملیاتی، این تفاوت یعنی فاصله بین یک رابط چت روان و رابطی که ۱۵ ثانیه یخ می‌زند و سپس یک‌باره کوهی از متن را بیرون می‌ریزد. Bifrost، یک گیت‌وی متن‌باز که توسط Maxim AI با زبان Go توسعه یافته، با ارائه مسیریابی یکپارچه، جایگزینی خودکار و قابلیت مشاهده (Observability)، این مرزهای شکست را برطرف می‌کند.

تله‌ی بافر استریم

پراکسی‌های معروفی مثل NGINX یا Envoy معمولاً بافرینگ پاسخ را به‌صورت پیش‌فرض فعال دارند. در حالی که پاسخ‌های استاندارد HTTP بلافاصله یک هدر Content-Length برمی‌گردانند، استریم توکن‌ها بر اساس Transfer-Encoding: chunked و انواع رسانه‌ای text/event-stream کار می‌کند تا تکه‌های متن (Deltas) را هم‌زمان با تولید مدل ارسال کند.

وقتی بافرینگ فعال باشد، پراکسی تکه‌های SSE ورودی را می‌گیرد و در حافظه نگه می‌دارد تا به یک حد نصاب بافر داخلی — که معمولاً ۴ یا ۸ کیلوبایت است — برسد.

این اتفاق باعث ایجاد یک توقف در زمان تا نخستین توکن (TTFT) می‌شود. کاربر رابط کاربری یخ‌زده را می‌بیند، تصور می‌کند اپلیکیشن از کار افتاده و اتصال را قطع می‌کند. اگر کاربر سوکت را ببندد، گیت‌وی و ارائه‌دهنده بالادستی ممکن است همچنان به تولید توکن‌ها ادامه دهند و بودجه استنتاج را برای متنی که هرگز خوانده نمی‌شود، مصرف کنند.

علاوه بر این، چون استنتاج در مدل‌های استدلالی (Reasoning Model) — مدلی که قبل از جواب درنگ می‌کند، شبیه شطرنج‌بازی که چند حرکت جلوتر را می‌بیند — ممکن است برای چند ثانیه متوقف شود، لودبالانسرهای میانی ممکن است این کانال ساکت را به عنوان یک سوکت مرده تفسیر کنند. وقتی تایم‌اوت اتصال بدون فعالیت (Idle Timeout) می‌رسد، پراکسی‌ها به‌طور بی‌صدا یک بسته TCP RST ارسال کرده یا سوکت را می‌بندند.

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

بن‌بست پیش‌پُرکردن و تایم‌اوت‌های معکوس

تأخیر استنتاج از دو مرحله متمایز تشکیل شده است: مرحله پیش‌پُرکردن (Prefill یا همان TTFT) و زمان تولید بین‌توکنی. TTFT تحت تأثیر مرحله پیش‌پُرکردن مدل است، جایی که ارائه‌دهنده تمام توکن‌های پرامپت ورودی را جذب می‌کند.

برای وظایف RAG سازمانی که حاوی ۶۴,۰۰۰ توکن از اسناد بازیابی شده هستند، مرحله پیش‌پُرکردن به‌تنهایی می‌تواند ۱۲ تا ۲۵ ثانیه زمان ببرد تا اولین توکن ارسال شود. پس از شروع تولید، تسکی که ۲,۰۰۰ توکن را با سرعت ۴۰ توکن بر ثانیه تولید می‌کند، به ۵۰ ثانیه دیگر زمان نیاز دارد.

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

• چت ساده/پرسش و پاسخ: ورودی < ۵۰۰ توکن؛ ۱۵۰ توکن خروجی؛ پیش‌پُرکردن ۰.۴ تا ۱.۲ ثانیه؛ تولید ۲ تا ۴ ثانیه؛ تایم‌اوت امن ۱۵ ثانیه.
• استخراج سند: ورودی ۱۵,۰۰۰ توکن؛ ۸۰۰ توکن خروجی؛ پیش‌پُرکردن ۳.۰ تا ۸.۰ ثانیه؛ تولید ۱۵ تا ۲۵ ثانیه؛ تایم‌اوت امن ۶۰ ثانیه.
• تولید کد: ورودی ۴,۰۰۰ توکن؛ ۱,۵۰۰ توکن خروجی؛ پیش‌پُرکردن ۱.۵ تا ۳.۵ ثانیه؛ تولید ۳۰ تا ۵۰ ثانیه؛ تایم‌اوت امن ۹۰ ثانیه.
• RAG سازمانی: ورودی ۶۴,۰۰۰ توکن؛ ۲,۵۰۰ توکن خروجی؛ پیش‌پُرکردن ۱۲.۰ تا ۲۵.۰ ثانیه؛ تولید ۶۰ تا ۱۰۰ ثانیه؛ تایم‌اوت امن ۱۸۰ ثانیه.

بدتر از آن، اگر تایم‌اوت سمت کلاینت کوتاه‌تر از گیت‌وی باشد، «بن‌بست پیش‌پُرکردن» رخ می‌دهد. اگر کلاینت در ثانیه ۲۰ درخواست را لغو کند در حالی که ارائه‌دهنده در حال تکمیل یک پیش‌پُرکردن ۲۲ ثانیه‌ای است، کلاینت بلافاصله یک درخواست تکراری (Retry) ارسال می‌کند. این کار یک پرامپت مشابه و از نظر محاسباتی سنگین را دوباره به صف می‌فرستد. اگر چندین کلاینت این کار را انجام دهند، ظرفیت بالادستی اشباع شده و هر درخواست بعدی قبل از ارسال حتی یک توکن، لغو می‌شود.

سیستم‌های عملیاتی به یک معماری تایم‌اوت سه‌لایه نیاز دارند:
۱. تایم‌اوت اتصال: ۳ تا ۵ ثانیه برای دست‌دادن (Handshake) اولیه TCP/TLS.
۲. تایم‌اوت TTFT: ۱۵ تا ۳۰ ثانیه برای اجازه دادن به پیش‌پُرکردن پرامپت‌های پیچیده.
۳. تایم‌اوت بین‌توکنی: ۵ تا ۱۰ ثانیه بین توکن‌های متوالی برای شناسایی سوکت‌های متوقف شده.

خطرات جایگزینی ساده (Naive Failover)

جایگزینی خودکار با یک ارائه‌دهنده ثانویه هدفی کلیدی برای پایداری است، به‌ویژه چون APIهای مدل‌های بزرگ به‌طور مکرر دچار افت کیفیت سرویس می‌شوند. طبق داده‌های ردیابی حوادث از تجمیع‌کننده‌های وضعیت (Status Aggregators)، APIهای اصلی در فصل‌های اخیر ده‌ها مورد افت کیفیت و افزایش نرخ خطا داشته‌اند. با این حال، منطق جایگزینی ساده (Naive) هنگام فعال بودن استریم، شکست‌های شدیدی ایجاد می‌کند.

اگر ارائه‌دهنده‌ای بعد از ارسال ۳۰۰ توکن از یک پاسخ ۱۰۰۰ توکنی شکست بخورد، یک گیت‌وی ساده نمی‌تواند درخواست را به‌سادگی از توکن صفر با یک مدل دیگر شروع کند. این منجر به «مشکل محموله نیمه‌ارسال‌شده» می‌شود. کلاینت متن تکراری دریافت می‌کند که خروجی‌های ساختاریافته مانند JSON یا سینتکس کد را خراب می‌کند.

مثالی از فساد استریم:

{ "summary": "The customer requested a refund due to damaged goods received on", "summary": "The customer requested a refund due to damaged goods received on Tuesday morning." }

فراتر از فساد استریم، ناسازگاری‌های ساختاری هنگام مسیریابی بین ارائه‌دهندگانی مانند Anthropic Claude Sonnet و OpenAI GPT-4o ظاهر می‌شود:

• محدودیت پنجره زمینه (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که جا برای چند ورق دارد — در کلود از ۲۰۰,۰۰۰ توکن فراتر می‌رود، در حالی که برخی جایگزین‌ها در ۳۲,۰۰۰ یا ۱۲۸,۰۰۰ توکن قطع می‌شوند و منجر به خطای ۴۰۰ (Context Window Exceeded) می‌گردند.
• پارامترهای نمونه‌گیری: پارامترهایی مثل top_k توسط آنتروپیک و گوگل جمینای پذیرفته می‌شوند اما در نقاط انتهایی OpenAI باعث خطای ۴۰۰ (Bad Request) می‌شوند.
• خروجی‌های ساختاریافته: OpenAI به اسکیماهای JSON خاص در response_format نیاز دارد، در حالی که سایر بک‌اندها به پرامپت‌های سیستمی یا تعاریف فراخوانی ابزار (Tool-calling) متفاوتی نیاز دارند.

تلاطم محدودیت نرخ (Rate-Limit)

پراکسی‌های استاندارد بر اساس تعداد درخواست در دقیقه (RPM) محدود می‌کنند، اما در هوش مصنوعی این معیار بی‌فایده است. یک درخواست با ۱۰۰,۰۰۰ توکن می‌تواند کل سهمیه توکن در دقیقه (TPM) یک ارائه‌دهنده را مصرف کند، در حالی که ۱۰۰ درخواست کوچک چنین نمی‌کنند.

بدون محدودیت توکن-آگاه، یک پردازش دسته‌ای (Batch Job) در پس‌زمینه می‌تواند خطای HTTP 429 (Too Many Requests) ایجاد کند و تمام کاربران تعاملی را مسدود کند. Bifrost، یک گیت‌وی متن‌باز توسعه یافته توسط Maxim AI، این مشکل را با استفاده از کلیدهای مجازی و بودجه‌های سلسله‌مراتبی برای جداسازی کلاینت‌های اپلیکیشن از اسرار ارائه‌دهنده حل می‌کند.

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

• محدودیت نرخ هر کلید: کنترل هم‌زمان RPM و TPM.
• بودجه‌های سلسله‌مراتبی: اعمال سقف هزینه‌ها در سطح کلید، تیم و سازمان برای رد درخواست‌ها قبل از اینکه هزینه ایجاد کنند.
• لیست سفید مدل‌ها: محدود کردن کلیدهای توسعه به مدل‌های مقرون‌به‌صرفه و رزرو مدل‌های استدلالی پیشرو (Frontier) برای محیط عملیاتی.

تداخل‌های کش معنایی

کشینگ هزینه‌ها را کم می‌کند اما «انحراف معنایی» ایجاد می‌کند. گیت‌وی‌های استاندارد بر اساس تطابق دقیق (Exact Match) با استفاده از هش SHA-256 از پرامپت و پارامترها تکیه می‌کنند که سربار آن زیر یک میلی‌ثانیه و انحراف آن صفر است.

اما کش معنایی از یک مدل Embedding و ذخیره‌ساز برداری استفاده می‌کند تا پرامپت‌هایی با شباهت کسینوسی (Cosine Similarity) بالاتر از یک آستانه (مثلاً ۰.۹۲) را شناسایی کند. این کار ۱۵ تا ۴۵ میلی‌ثانیه تأخیر اضافه می‌کند و ریسک تداخلات مثبت کاذب خطرناکی را به همراه دارد. برای مثال، درخواستی برای «سیاست مرجوعی بین‌المللی» ممکن است پاسخ کش‌شده برای «سیاست مرجوعی داخلی» را برگرداند اگر شباهت آن‌ها ۰.۹۴ باشد.

استراتژی‌های کش بر اساس ریسک و مورد استفاده متفاوت است:

• تطابق دقیق: هش SHA-256؛ سربار < ۱ میلی‌ثانیه؛ انحراف صفر؛ ایده‌آل برای پرامپت‌های سیستمی ثابت و پرس‌وجوهای قطعی.
• شباهت معنایی: جستجوی برداری/Embedding؛ سربار ۱۵ تا ۴۵ میلی‌ثانیه؛ ریسک بالای مثبت کاذب؛ ایده‌آل برای FAQهای گفتگو-محور با حجم بالا.
• کش پیشوند پرامپت: در سطح ارائه‌دهنده بالادستی؛ مسیریابی زیر میلی‌ثانیه؛ ریسک حداقلی؛ ایده‌آل برای گفتگوهای چندمرحله‌ای عامل‌ها.

حتی حیاتی‌تر از این، ریسک نشت داده‌های بین‌مستاجری (Cross-tenant) است. اگر بافت احراز هویت (Authorization Context) در کلید کش حذف شود، کاربر B ممکن است پاسخ کش‌شده‌ای را دریافت کند که حاوی داده‌های خصوصی کاربر A است. استقرارهای عملیاتی باید فضای نام‌های (Namespaces) کش را بر اساس کلید مجازی، شناسه مستاجر و نقش کاربر ایزوله کنند.

نقطه کور هوش مصنوعی سایه (Shadow AI)

بسیاری از سازمان‌ها متوجه می‌شوند بخش بزرگی از ترافیک AI را به‌طور کامل دور می‌زند. این «هوش مصنوعی سایه» زمانی رخ می‌دهد که توسعه‌دهندگان از ابزارهایی مثل Cursor، Claude Code یا اپلیکیشن‌های دسکتاپ ChatGPT با کلیدهای API شخصی استفاده می‌کنند و تمام لاگ‌های شرکتی و حفاظ‌های امنیتی را دور می‌زنند. کد منبع حساس شرکت و طراحی‌های داخلی اسکیم‌ها اغلب از این طریق حفاظ‌های مرکزی را دور می‌زنند.

Bifrost Edge که در حال حاضر در نسخه آلفا است، سعی می‌کند این مشکل را با اجرای یک عامل محلی روی macOS، ویندوز و لینوکس حل کند. این ابزار ترافیک نقاط انتهایی را از طریق پلتفرم‌های MDM مانند Jamf یا Microsoft Intune به گیت‌وی مرکزی مسیریابی می‌کند. این به مدیران اجازه می‌دهد تا کنترل ادغام‌های خارجی را از طریق حاکمیت MCP (Model Context Protocol) حفظ کنند و اطمینان حاصل کنند که حذف اسرار (Secret Redaction) و سقف هزینه‌ها روی لپ‌تاپ‌های توسعه‌دهندگان نیز مانند میکروسرویس‌های سرور اعمال می‌شود.

بنچمارک‌های عملکرد

افزودن لایه گیت‌وی معمولاً تأخیر ایجاد می‌کند. با این حال، بنچمارک‌های Bifrost نشان می‌دهد که این سیستم می‌تواند ۵,۰۰۰ درخواست در ثانیه را با تنها ۱۱ میکروثانیه سربار پردازشی اضافی به ازای هر درخواست روی نمونه‌های استاندارد ابری مدیریت کند.

این سربار پایین برای زنجیره‌های عامل‌محور (Agentic) که در آن‌ها تأخیر پراکسی جمع می‌شود، حیاتی است. تیم‌های زیرساخت باید اطمینان حاصل کنند که محیط اجرای آن‌ها در حین پیاده‌سازی این سیاست‌های حاکمیتی، به یک گلوگاه تبدیل نشود.

چک‌لیست سخت‌سازی معماری

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

• پیکربندی بافر: غیرفعال کردن بافرینگ پاسخ برای مسیرهای text/event-stream. تنظیم تایم‌اوت‌های خواندن روی حداقل ۱۸۰ ثانیه برای تسک‌های استدلالی.
• معماری تایم‌اوت: پیاده‌سازی رویکرد سه‌لایه (اتصال، TTFT و بین‌توکنی).
• جایگزین‌های آگاه از محموله: اعتبارسنجی تعداد توکن‌ها در برابر پنجره‌های زمینه هدف قبل از تلاش مجدد. اجتناب از تلاش‌های مجدد در میانه استریم پس از اینکه تکه‌های داده به کلاینت ارسال شده‌اند.
• تله‌متری: صادر کردن متریک‌ها از طریق OpenTelemetry و Prometheus. نظارت بر مدت زمان انتظار در صف، نرخ‌های جایگزینی (Fallback) و توزیع TTFT.
• کارایی زمان اجرا: استفاده از محیط‌های اجرای با توان عملیاتی بالا برای به حداقل رساندن سربار پردازشی اضافی.

این تغییر در زیرساخت نشان می‌دهد که دوران «نصب سریع و بدون تنظیمات» (Drop-in) در ادغام هوش مصنوعی به پایان رسیده است. پایداری اکنون نیازمند یک صفحه کنترل (Control Plane) تخصصی است که توکن‌ها را بفهمد، نه فقط بسته‌ها را. برای سخت کردن استک خود، با بازرسی تنظیمات بافر پراکسی و پیاده‌سازی استراتژی تایم‌اوت مجزا برای طولانی‌ترین پرامپت‌های RAG خود شروع کنید.

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