۳.۷ ثانیه در برابر ۱.۴ ثانیه؛ این تمام چیزی است که یک تغییر بنیادین در لایه داده می‌تواند در تجربه کاربری ایجاد کند. اگر از عامل‌هایی استفاده می‌کنید که برای هر پاسخ باید چند ثانیه «فکر کنند» یا «بیدار شوند»، باید بدانید که گلوگاه اصلی دیگر قدرت مدل نیست، بلکه نحوه دسترسی به حافظه است.
به گزارش Wire در ۹ ژوئیه ۲۰۲۶، این شرکت دلیل مهاجرت کانتینرهای زمینه (Context Containers) خود را از Cloudflare Durable Objects به یک محیط اجرای جدید روی Fly Machines توضیح داد. کانتینرهای زمینه در واقع مخازن ایزوله شده‌ای از دانش پردازش‌شده هستند که شامل ورودی‌ها، بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — و گراف‌های منشأ هستند که از طریق پروتکل زمینه مدل (MCP) مورد پرس‌وجو قرار می‌گیرند.
همان‌طور که در تحلیل‌های پیشین ما درباره بهینه‌سازی استنتاج در لبه اشاره کردیم، فاصله فیزیکی میان داده و پردازش همیشه یک چالش بوده است. از روز اول، هر کانتینر در Wire به عنوان یک Durable Object در کلودفلر عمل می‌کرد. این ساختار برای هزاران واحد کوچک و عمدتاً غیرفعال عالی بود، اما تیم فنی در نهایت با یک سقف عملکردی برخورد کرد.
برای اینکه عامل‌های هوش مصنوعی بتوانند به صورت قابل‌اطمینان عمل کنند، به یک وضعیت پایدار (Persistent State) نیاز دارند که مانند یک «مغز محلی» عمل کند. این کانتینرها را به عنوان فایل‌کابین‌های دیجیتالی تصور کنید؛ اگر عامل هوش مصنوعی برای هر بار دسترسی به یک حقیقت، مجبور باشد ثانیه‌ها منتظر باز شدن قفل کابین بماند، تجربه کاربر کاملاً تخریب می‌شود. این نیاز به مدیریت بهینه دانش، به‌ویژه در محیط‌های سازمانی، را می‌توان در تغییر رویکرد از بات‌های تک‌کاربره به عامل‌های چندنفره برای مدیریت دانش مشاهده کرد که بر اهمیت اشتراک و دسترسی سریع به زمینه متمرکز است. اگرچه Cloudflare شروع سریعی را فراهم کرد، اما فاصله فیزیکی میان جایی که داده‌ها ذخیره شده بودند و جایی که هوش مصنوعی آن‌ها را پردازش می‌کرد، محدودیت‌های ساختاری ایجاد کرد.
بر اساس مستندات منتشر شده در usewire.io، تیم فنی با چهار دیوار ساختاری مواجه بود: نخست اینکه شاخص برداری در سرویس مجزایی به نام Vectorize قرار داشت که باعث ایجاد یک گام شبکه (Network Hop) اضافی در حیاتی‌ترین مسیر می‌شد و نسخه‌ی دومی از وضعیت داده‌ها ایجاد می‌کرد که احتمال ناهماهنگی (Drift) در آن وجود داشت. از آنجایی که SQLite در Durable Objects نمی‌تواند افزونه‌ها (Extensions) را بارگذاری کند، این شاخص هرگز نمی‌توانست به داخل منتقل شود. دوم، محاسبات از داده‌ها جدا بود. بازیابی اطلاعات یک خط لوله چندمرحله‌ای است که شامل تولید کاندیداهای ترکیبی (Hybrid Candidate Generation)، ادغام (Fusion)، گسترش پرس‌وجو و بازرتبه‌بندی گسترده (Wide Reranking) است؛ در Durable Objects، تنها بخش کوچکی از این فرآیند می‌توانست در جایی که داده‌ها حضور داشتند اجرا شود.
سوم، نشانه‌های مکانی (Location Hints) ایستا بودند. یک شیء (Object) پس از ایجاد هرگز جابه‌جا نمی‌شود؛ این یعنی کانتینری که در لندن ساخته می‌شد، برای همیشه به ناوگان عامل‌هایی در ویرجینیا خدمات می‌داد. علاوه بر این، کاربران نمی‌توانستند ظرفیت اختصاصی برای یک مستأجر (Tenant) واحد خریداری کنند. در نهایت، تیم‌های تحت نظارت قوانین رگولاتوری، نیاز به گزینه‌های میزبانی شخصی (Self-hosting) روی زیرساختی داشتند که خودشان کنترل کنند، امری که محیط اجرای انحصاری کلودفلر نمی‌توانست فراهم کند.
برای حل این مشکل، Wire محیط اجرای کانتینرها را از پایه بازسازی کرد. آن‌ها سیستم جدید را با استفاده از داده‌ها، کانتینرها، پرسش‌ها و داوران کاملاً یکسان نسبت به سیستم قدیمی بنچ‌مارک کردند. طبق اعلام این شرکت، تغییرات کلیدی شامل موارد زیر است:
- ذخیره‌سازی یکپارچه: هر سازمان اکنون یک فرآیند میزبان (با استفاده از Bun) روی Fly Machines برای تمام کانتینرهایش دارد.
- شاخص‌گذاری داخلی: آن‌ها به SQLite به همراه افزونه sqlite-vec مهاجرت کردند. این کار باعث شد شاخص برداری درون خود فایل SQLite جاسازی شود و بازیابی کاندیداها در همان فرآیند (In-process) اجرا شود.
- توزیع پویا: یک مسیریاب منطقه‌ای (Per-region router) اکنون کانتینرها را در نزدیک‌ترین نقطه به فراخوان‌کننده قرار می‌دهد. لایه کنترل (Control Plane) از طریق درخواست‌های امضا شده با لایه داده ارتباط برقرار می‌کند و هرگز به محتوای کانتینر دسترسی ندارد.
- پایداری و سازگاری: برای جایگزینی تکثیر خودکار کلودفلر، سیستم ارسال مداوم WAL (Write-Ahead Log) به ذخیره‌سازهای شیء پیاده‌سازی شد. عملیات نوشتن تا زمانی که فریم WAL ذخیره نشود، تایید (Acknowledge) نمی‌شود. استفاده از Group Commit این تأخیر را در حدود ۱۰۰ میلی‌ثانیه نگه می‌دارد.
- بازیابی وضعیت: اسنپ‌شات‌ها به ذخیره‌ساز شیء ارسال می‌شوند تا کانتینر بتواند در هر نقطه از جهان، بیت به بیت بازسازی شود.
نتایج این تغییرات ملموس است. فراخوان‌های ابزار (Tool Calls) در حالت گرم اکنون تأخیر ثابتی معادل ۰.۳ ثانیه دارند، در حالی که پیش‌تر ۰.۴ ثانیه بود و اغلب به بالای ۲ ثانیه می‌پرید. زمان بیداری (Wake Time) که پیش‌تر ۳.۷ ثانیه بود، اکنون به ۱.۴ ثانیه رسیده است. نکته مهم این است که این تأخیر مربوط به «راه‌اندازی سرد» (Cold Start) در سطح Durable Object نبود (زیرا ایزوله‌ها در میلی‌ثانیه بیدار می‌شوند)، بلکه زمانی بود که پشته نرم‌افزاری Wire صرف می‌کرد تا خودش را بازسازی کند؛ محیط اجرای جدید این زمان را به شدت کاهش داد.
همچنین کیفیت بازیابی (Recall@5) از ۷۸.۱٪ به ۸۹.۱٪ افزایش یافت. شرکت اشاره کرد که این پیشرفت تا حدی مدیون استفاده از مدل برداری جدیدتر است. با این حال، معماری جدید باعث می‌شود عملیات‌های هزینه‌بر مانند Over-fetching و بازرتبه‌بندی گسترده ارزان شوند، زیرا شاخص‌های هر کانتینر به اندازه کافی کوچک هستند که جستجوی دقیق نزدیک‌ترین همسایه (Exact Nearest-Neighbor Search) را ممکن سازند.
این چرخش راهبردی نشان می‌دهد که توسعه‌دهندگان در حال درک این واقعیت هستند که راحتی مدل‌های «بدون سرور» (Serverless) اغلب به قیمت از دست دادن کنترل‌های دقیقی است که برای تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — ضروری است. در کنار بهینه‌سازی زیرساختی، مدیریت هزینه‌های عملیاتی نیز اهمیتی حیاتی دارد؛ برای مثال، می‌توان به استراتژی Autowired.ai برای کاهش ۴۰ درصدی هزینه‌های Amazon Bedrock اشاره کرد که نشان می‌دهد چگونه تغییر در نحوه پردازش داده‌ها می‌تواند منجر به کاهش چشمگیر هزینه‌ها شود. جالب اینجاست که این تغییرات تجربه کاربر را مختل نکرده است؛ APIهای REST، URLهای کانتینر، ۵ ابزار MCP و شکل پاسخ‌ها کاملاً یکسان باقی مانده‌اند.
در حال حاضر، Wire این محیط اجرا را در حالت بتا برای محیط‌های پیش‌نمایش و محیط‌های کاری اختیاری اجرا می‌کند. این شرکت قصد دارد پس از تکمیل کامل مهاجرت به تولید و اطمینان از سبز ماندن شاخص‌های پایداری (Durability Tripwires)، محیط اجرای کانتینر را به صورت متن‌باز (Open-source) منتشر کند.
گام بعدی شما
- اگر در حال طراحی عامل‌های هوش مصنوعی با تأخیر بالا هستید، بررسی کنید که آیا داده‌های شما و واحد پردازش در یک منطقه جغرافیایی قرار دارند یا خیر.
- برای کاهش تأخیر بازیابی، استفاده از دیتابیس‌های برداری داخلی (In-process) مانند sqlite-vec را به جای APIهای خارجی آزمایش کنید.
- ساختار MCP را برای استانداردسازی دسترسی عامل‌ها به کانتینرهای دانش بررسی کنید.
اما این بهینه‌سازی‌ها تنها نیمی از مسیر است؛ اثر این تغییرات بر هزینه استنتاج در مقیاس میلیونی را در گزارش بعدی بررسی خواهیم کرد.
گفتگو