اگر در حال ساخت یک پروکسی برای Claude هستید، احتمالاً سیستم شما در محیط تست عالی عمل می‌کند اما به محض ورود کاربران واقعی، فرو می‌پاشد. شما با افت‌های پراکنده و گزارش‌های نامنظم مواجه می‌شوید و برخی کاربران بدون هیچ دلیلی پاسخی دریافت نمی‌کنند.
مقیاس‌پذیری زیرساخت‌های هوش مصنوعی مسیر خطی ندارد. همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی زیرساخت‌های Anthropic اشاره کردیم، تمرکز اکنون از قابلیت‌های مدل به «لوله‌کشی» انتقال داده‌ها تغییر کرده است. برای یک برنامه‌نویس، پروکسی — مثل پذیرنده‌ای که تمام تماس‌ها را می‌گیرد و به مدیر می‌رساند — یک مسیر ساده به نظر می‌رسد، اما در واقع گلوگاه تمام کاربران است.
به گزارش وب‌سایت dev.to در ۱۰ ژوئن ۲۰۲۶، مقصر اصلی «محدودیت نرخ دو-بعدی» است. Anthropic هم تعداد درخواست در دقیقه (RPM) و هم تعداد توکن در دقیقه (TPM) را رصد می‌کند. برای مثال، حساب‌های سطح ۱ اجازه ۵۰ RPM و ۵۰,۰۰۰ TPM دارند. در یک پروکسی چندکاربره، این‌ها مخازن جداگانه نیستند و هر کاربر از یک ظرف مشترک برداشت می‌کند؛ شبیه محدودیت تعداد ورودی در یک صف نانوایی که اگر همه هم‌زمان برسند، صف می‌شکند.
بیشتر توسعه‌دهندگان از الگوی تکرار ثابت استفاده می‌کنند و دقیقاً یک ثانیه صبر می‌کنند تا دوباره تلاش کنند. این کار باعث ایجاد «تپه‌های ترافیکی هم‌زمان» می‌شود؛ یعنی ۱۰ درخواست شکست‌خورده، همگی در یک میلی‌ثانیه دوباره ارسال می‌شوند. برای حل این مشکل، باید از عقب‌نشینی نمایی با جیتر (Exponential Backoff with Jitter) استفاده کرد. این روش — مثل کسی که وقتی در بسته است، اول یک ثانیه، بعد دو ثانیه و بعد چهار ثانیه صبر می‌کند — با افزودن یک متغیر تصادفی به زمان انتظار، بار ترافیکی را پخش می‌کند.
علاوه بر تکرارها، شکست‌های خاموش در گزارش‌ها پنهان شده‌اند. این موارد شامل خطاهای ۵۲۹ (Overloaded) هستند که توسط منطق‌های مخصوص خطای ۴۲۹ شناسایی نمی‌شوند. بدون رصد درخواست‌های هر کاربر و زمان‌بندی آگاه از توکن، یک «کاربر حرفه‌ای» می‌تواند کل صف را تصاحب کند و صفحه را برای دیگران منجمد کند.
برای اکثر تیم‌ها، این وضعیت به معنای انباشت «بدهی فنی» در حوزه هوش مصنوعی است. ساعت‌هایی که صرف وصله‌پینه کردن حلقه‌های تکرار می‌شود، از زمان ساخت ویژگی‌های واقعی محصول کم می‌کند. باید نگاه خود را به پروکسی از یک ابزار ساده به یک مسئله پیچیده زمان‌بندی تغییر دهید.
گام بعدی شما
- تنظیمات Timeout خود را بررسی کنید؛ اگر روی ۱۵ ثانیه است، آن را به ۳۰ تا ۶۰ ثانیه افزایش دهید تا پاسخ‌های طولانی Claude قطع نشوند.
- منطق Jitter را برای پخش ترافیک در لایه تکرار درخواست‌ها پیاده کنید.
- سیستمی برای رصد میزان مصرف توکن به تفکیک هر کاربر طراحی کنید.
اما مدیریت حافظه در این لایه حتی پیچیده‌تر است — به تحلیل ما درباره‌ی پنجره‌های متنی بزرگ مراجعه کنید.
گفتگو