درون سازوکار BullMQ برای کنترل بارهای سنگین هوش مصنوعی

تصور کنید یک درخواست تبدیل متن به تصویر، تمام حافظهٔ ویدیویی (VRAM) را اشغال کند و سخت‌افزار را برای چندین دقیقه قفل کند تا در نهایت سیستم با خطای Out-of-Memory (OOM) به طور کامل سقوط کند. برای جلوگیری از این فاجعه، در ۲۰ اوت ۲۰۲۶، یک راهنمای فنی در وب‌سایت dev.to معماری ناهمگام (Asynchronous) مبتنی بر BullMQ و Redis را برای مدیریت این بحران معرفی کرد.

چالش منابع در رسانه‌های زاینده

بسیاری از برنامه‌های وب سنتی با داده‌های سبک JSON و در بازه‌های زمانی کوتاه از طریق چرخه‌های درخواست-پاسخ HTTP کار می‌کنند. اما خط لوله‌های تولید رسانه در هوش مصنوعی زاینده (Generative AI) — که شامل مدل‌های انتشار فضای نهفته عمیق (Deep Latent Space Diffusion)، پردازش تنسورهای ویدئویی در زمان واقعی و گراف‌های پیچیده اجرای شیدر WebGPU است — مانند غول‌های بلعنده منابع هستند. این سیستم‌ها با اشغال شدید حافظه، زمان‌های پردازش غیرخطی و محدودیت‌های سخت‌افزاری شدید شناخته می‌شوند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت منابع در مدل‌های محلی اشاره کردیم، تلاش برای اجرای این عملیات سنگین به صورت هم‌زمان (Synchronous) در یک API معمولی یا هندلر درخواست WebSocket، یک اشتباه استراتژیک و یک ضدالگوی معماری (Anti-pattern) است. اگر یک درخواست کاربر مستقیماً خط لوله استنتاج بدون بافر را فعال کند، رشتهٔ پردازشی Node.js بلافاصله مسدود می‌شود. این وضعیت ریسک توقف زنجیره‌ای رشته‌ها (Thread Starvation) را ایجاد می‌کند، زیرا اتصالات هم‌زمان، توصیف‌گرهای سوکت (Socket Descriptors) موجود را اشباع می‌کنند.

وقتی چندین کاربر هم‌زمان درخواست‌های باکیفیت ارسال می‌کنند، سیستم به یک دیوار سخت‌افزاری ترسناک برخورد می‌کند: اتمام حافظهٔ ویدیویی. برخلاف رم سیستم که می‌تواند به طور ایمن از فضای Swap روی دیسک استفاده کند بدون اینکه منجر به فروپاشی فاجعه‌بار عملکرد شود، واحد پردازش گرافیکی (GPU) مرزهای حافظهٔ سخت و غیرقابل مذاکره‌ای دارد. به نقل از مستندات فنی، به محض اینکه تخصیص VRAM از ظرفیت فیزیکی فراتر رود، درایورهای CUDA یا ROCm خطای OOM صادر می‌کنند که غیرقابل بازیابی است. این اتفاق بلافاصله باعث کرش کردن فرآیند استنتاج، فاسد شدن تنسورهای وضعیت میانی و شکست تمام کارهای فعال به صورت یک‌باره می‌شود. این چالش‌های سخت‌افزاری در مقیاس صنعتی بسیار رایج است؛ برای مثال، ShadowSocial با پیاده‌سازی صف‌بندی پویا توانست هزینه‌های مربوط به RAM هوش مصنوعی را به شدت بهینه کند تا از توقفات ناگهانی جلوگیری شود.

آنالوژی توسعه وب: استخرهای رشته در مقابل میکروسرویس‌های رویدادمحور

برای حل این مشکل، توسعه‌دهندگان باید «قصد کاربر» را از «اجرای محاسباتی» جدا کنند. این رویکرد شبیه به تکامل سرورهای وب از مدل‌های یکپارچه (Monolithic) که برای هر درخواست یک رشته اختصاص می‌دادند، به میکروسرویس‌های رویدادمحور است.

یک سرویس گزارش‌گیری دیتابیس در سطح سازمانی را در نظر بگیرید. در سرورهای چندرشته‌ای قدیمی (مانند Apache با PHP یا Java Servlets)، هر درخواست برای یک گزارش تجمیعی SQL چند گیگابایتی، یک رشته اختصاصی از سیستم‌عامل می‌گرفت. در زمان پیک ترافیک — مثلاً وقتی پنجاه تحلیل‌گر درخواست گزارش‌های تاریخی دفتر کل را می‌دادند — استخر رشته‌ها فوراً تخلیه می‌شد. درخواست‌های جدید در بافرهای حافظه نامحدود صف می‌گرفتند و توصیف‌گرهای فرآیند سیستم‌عامل را مصرف می‌کردند تا اینکه سرور به دلیل سربار تعویض زمینه (Context-switching) و گرسنگی حافظه، کاملاً متوقف شود.

راهکار مدرن، پذیرش I/O غیرمسدودکننده، حلقه‌های رویداد (Event Loops) و کارگزاران پیام پایدار مانند RabbitMQ, Kafka یا AWS SQS است. در این مدل، یک درگاه API درخواست را می‌پذیرد، داده‌ها را اعتبارسنجی می‌کند، شرح کار را به یک پیام سبک سریالایز کرده و آن را در یک صف پیام پایدار می‌اندازد. سپس مجموعه‌ای از سرویس‌های ورکر — که به طور مستقل از لایه API مقیاس‌بندی شده‌اند — این پیام‌ها را با سرعتی کنترل‌شده که توسط مکانیزم فشار معکوس (Backpressure) مدیریت می‌شود، مصرف می‌کنند.

در دنیای رسانه‌های مولد، Redis و BullMQ نقش این کارگزار پیام و لایه صف‌بندی را ایفا می‌کنند، در حالی که ورکرهای GPU به عنوان میکروسرویس‌های ایزوله عمل می‌کنند. در اینجا VRAM شما مانند یک استخر اتصال (Connection Pool) دیتابیس ارزشمند است؛ همان‌طور که یک دیتابیس فقط تعداد محدودی اتصال هم‌زمان را تحمل می‌کند پیش از آنکه قفل شود، یک GPU نیز فقط می‌تواند تعداد محدودی از وزن‌های مدل، ماتریس‌های توجه و نقشه‌های ویژگی نهفته (Latent Feature Maps) را به طور هم‌زمان در VRAM نگه دارد. بهینه‌سازی این لایه‌ها می‌تواند منجر به نتایج اقتصادی چشم‌گیری شود، مشابه آنچه در تجربه ShadowSocial برای کاهش ۶۰ درصدی هزینه‌های تولید ویدیو مشاهده شد.

Redis به عنوان لایه هماهنگی

Redis در اینجا به عنوان سیستم عصبی مرکزی عمل می‌کند. این ابزار همزمان نقش کارگزار پیام، لاگ تراکنش‌های پایدار و ماشین وضعیت اتمیک را دارد. طبق گزارش نویسندگان راهنما، این موضوع حیاتی است زیرا چندین گره GPU که احتمالاً روی ماشین‌های مختلف در یک خوشه (Cluster) ابری هستند، باید هماهنگ شوند تا هیچ دو ورکری یک کار مشابه را به طور هم‌زمان تصاحب نکنند.

ردیس این هماهنگی را از طریق معناشناسی اجرای تک‌رشته‌ای برای دستورات فردی و اجرای اسکریپت‌های اتمیک Lua مدیریت می‌کند. عملیاتی مانند BRPOPLPUSH (یا اسکریپت‌های سفارشی Lua در BullMQ که هش‌ها، مجموعه‌های مرتب‌شده و لیست‌های ردیس را مدیریت می‌کنند) تضمین می‌کنند که تغییرات وضعیت — مانند انتقال یک کار از حالت «در انتظار» به «فعال» — به صورت اتمیک رخ دهد. این امر از شرایط رقابتی (Race Conditions) جلوگیری می‌کند، جایی که ممکن است دو ورکر سعی کنند یک کار تولید تصویر با اولویت بالا را به طور هم‌زمان بردارند.

مدیریت وضعیت تغییرناپذیر (Immutable State Management)

این معماری به شدت بر مدیریت وضعیت تغییرناپذیر تکیه دارد. در این صف توزیع‌شده، داده‌های ورودی (Payloads)، پارامترهای پیکربندی و پرامپت‌های تنسوری اولیه، پس از ثبت در Redis، به عنوان رکوردهای تغییرناپذیر تلقی می‌شوند.

وقتی یک ورکر کاری را برمی‌دارد، نسخهٔ اصلی شرح کار را تغییر نمی‌دهد، بلکه:

• تنظیمات تغییرناپذیر را می‌خواند.
• نسخه‌های محلی کاری را در حافظه فرآیند خود برای مدت زمان اجرای WebGPU یا دستکاری تنسورهای CUDA ایجاد می‌کند.
• رویدادهای وضعیت مجزا و دارای برچسب زمانی را به Redis بازمی‌گرداند (مثلاً progress: 45% یا status: active).

این سخت‌گیری در تغییرناپذیری، باگ‌های توزیع‌شده مانند رقابت‌های «خواند-تغییر-نوشت» (Read-Modify-Write) را حذف می‌کند و سیستم را به راحتی قابل حسابرسی و تکرارپذیر می‌سازد. اگر یک ورکر در میانه تولید به دلیل نقص سخت‌افزاری کرش کند، تعریف تغییرناپذیر کار در Redis دست‌نخورده باقی می‌ماند و این به صف اجازه می‌دهد تا به طور ایمن کار را به وضعیت «در انتظار» یا «شکست‌خورده» برگرداند بدون اینکه فساد داده‌ای رخ دهد. این نوع تاب‌آوری در سطح زیرساخت، یادآور سازوکارهای همگام‌سازی گره‌های جایگزین در PyTorch است که برای کاهش زمان توقف در آموزش مدل‌های بزرگ طراحی شده‌اند.

BullMQ برای ارکستراسیون

در حالی که Redis ابزارهای پایه را فراهم می‌کند، BullMQ مدیریت سطح بالا یا ارکستراسیون را بر عهده دارد. صف‌های سادهٔ «اولین ورودی، اولین خروجی» (FIFO) برای هوش مصنوعی زاینده کافی نیستند چون هزینه محاسباتی هر تسک به شدت متفاوت است.

• مدیریت هم‌زمانی (Concurrency): اجازه می‌دهد ورکرها با یک پارامتر هم‌زمانی سخت تعریف شوند (مثلاً concurrency: 1 برای هر دستگاه GPU فیزیکی). این یک دیوار دفاعی سخت در برابر اتمام VRAM است. حتی با وجود ده هزار کار معلق تبدیل متن به تصویر، ورکر در هر لحظه فقط یک کار را درخواست، دانلود و اجرا می‌کند و تضمین می‌کند که اوج مصرف VRAM هرگز از نیازهای سنگین‌ترین workload فعالش فراتر نرود.
• صف‌های اولویت‌دار و عدالت (Fairness): با استفاده از مجموعه‌های مرتب‌شده ردیس (ZSET)، BullMQ از اولویت بومی پشتیبانی می‌کند. به هر کار یک مقدار اولویت عددی اختصاص می‌یابد. این به کاربران سطح سازمانی که خط لوله‌های ارتقای ویدیو به 4K در زمان واقعی را اجرا می‌کنند اجازه می‌دهد تا از کاربران سطح رایگان که تصاویر استاندارد 512x512 تولید می‌کنند جلو بزنند، بدون اینکه کارهای پس‌زمینه کم‌اولویت برای همیشه دچار گرسنگی منابع شوند.
• محدودیت نرخ و فشار معکوس APIهای خارجی: خط لوله‌های زاینده اغلب به APIهای خارجی وابسته هستند، مانند فضای ذخیره‌سازی ابری برای دارایی‌های رندر شده، Pinecone برای جاسازی‌های چندوجهی (Multimodal Embeddings)، یا سرویس‌های نظارتی شخص ثالث برای فیلترینگ ایمنی. BullMQ محدودکننده‌های نرخ داخلی را پیاده می‌کند که حداکثر تعداد کارهای پردازش شده در یک بازه زمانی مشخص را تعریف می‌کند. این کار از بروز خطاهای HTTP 429 (Too Many Requests) جلوگیری کرده و از وابستگی‌های پایین‌دستی محافظت می‌کند.

تاب‌آوری و بازخورد در زمان واقعی

به دلیل زمان‌بر بودن کارهای مولد، سیستم نمی‌تواند به اتصالات باز (Socket) تکیه کند. اگر مرورگر کاربر دچار نوسان شبکه شود یا درگاه API در حین یک رندر دو دقیقه‌ای ویدیو ری‌استارت شود، یک اتصال هم‌زمان قطع شده و کاربر با یک رابط کاربری خراب مواجه می‌شود.

در عوض، سیستم از یک خط لوله استریم رویداد ناهمگام استفاده می‌کند که توسط هندلرهای Webhook تحمل‌پذیر و کانال‌های Pub/Sub واکنش‌گرا پشتیبانی می‌شود. همان‌طور که ورکر GPU مراحل انتشار (Diffusion) را طی می‌کند یا فریم‌ها را پردازش می‌کند، به طور دوره‌ای تله‌متری پیشرفت را ارسال می‌کند. این رویدادها در کانال‌های Pub/Sub ردیس منتشر شده و در تاریخچه داده‌های کار BullMQ ثبت می‌شوند.

سرویس‌های هندلر Webhook در پایین‌دست، این استریم‌ها را گوش می‌دهند. وقتی یک کار به نقطه عطفی می‌رسد — مانند تکمیل رمزگشایی نهفته (Latent Decoding)، تولید پیش‌نمایش‌های بندانگشتی یا آپلود نهایی فایل در ذخیره‌ساز اشیاء — هندلر Webhook به‌روزرسانی‌های وضعیت را به صورت امن به اپلیکیشن کلاینت ارسال می‌کند.

هیدراتاسیون فرانت‌اند و به‌روزرسانی وضعیت

در سمت فرانت‌اند، این به‌روزرسانی‌ها از طریق Reducerهای وضعیت تغییرناپذیر پردازش می‌شوند. این فرآیند یک چرخه حیات خاص را دنبال می‌کند:

1. رندر استاتیک: بارگذاری اولیه صفحه یا وضعیت‌های فضای کاری به صورت استاتیک رندر شده و به مرورگر ارسال می‌شوند.
2. هیدراتاسیون (Hydration): بسته جاوااسکریپت سمت کلاینت اجرا می‌شود، هندلرهای رویداد را متصل می‌کند، اتصالات WebSocket را برای به‌روزرسانی‌های مبتنی بر Webhook برقرار می‌کند و ویوپورت‌های تعاملی بوم WebGPU را نصب می‌کند.
3. انتقال وضعیت: همان‌طور که پیشرفت از ۱۰٪ به ۱۰۰٪ می‌رسد، داده‌های دریافتی از Webhook باعث ایجاد اشیاء وضعیت جدید می‌شوند، به جای اینکه درخت‌های وضعیت موجود را تغییر دهند. این منجر به رندرهای React پیش‌بینی‌پذیر و بسیار نرم (Buttery-smooth) می‌شود.

اگر تحویل یک Webhook به دلیل قطعی موقت شبکه شکست بخورد، هندلر از سیاست‌های تلاش مجدد با تأخیر نمایی (Exponential Backoff) استفاده می‌کند تا تضمین شود که معناشناسی «حداقل یک‌بار تحویل» (At-least-once delivery) در مرزهای توزیع‌شده حفظ شود.

منطق پیاده‌سازی در محیط عملیاتی (Production)

پیاده‌سازی این سیستم نیازمند پیکربندی خاصی از کلاینت ioredis است. به طور مشخص، مقدار maxRetriesPerRequest باید روی null تنظیم شود. این یک الزام اجباری برای BullMQ است تا بتواند دستورات مسدودکننده (مانند BRPOPLUSH یا XREADGROUP) را به درستی مدیریت کند؛ در غیر این صورت، سیستم ممکن است در زمان قطعی شبکه کرش کند یا استثناهای مدیریت‌نشده صادر کند.

در یک ساختار TypeScript در سطح تولید، صف با قوانین خاص دوام و بهداشت پیکربندی می‌شود:

• تأخیر نمایی: کارها با attempts: 3 و یک تأخیر بازگشتی (مثلاً شروع از ۵ ثانیه) پیکربندی می‌شوند تا لرزش‌های سخت‌افزاری گذرا یا خطاهای درایور WebGPU را به طور خودکار مدیریت کنند.
• بهداشت حافظه: برای جلوگیری از انباشت نامحدود حافظه در Redis طی هفته‌ها استفاده، قوانین removeOnComplete (مثلاً برای داده‌های قدیمی‌تر از ۳۶۰۰ ثانیه) و removeOnFail (مثلاً برای داده‌های قدیمی‌تر از ۸۶۴۰۰ ثانیه) اعمال می‌شوند.
• ایمنی نوع (Type Safety): اینترفیس‌هایی مانند GenerationJobData (شامل userId, prompt, model, webhookUrl) و WebhookPayload (شامل jobId, status, progress, resultUrl) ثبات داده‌ها را در سراسر خط لوله ناهمگام تضمین می‌کنند.

سنتز معماری تفصیلی

برای درک کامل چرخه حیات یک درخواست رسانه زاینده، می‌توان جریان داده را از پذیرش تا رندر نهایی ردیابی کرد:

• پذیرش و اعتبارسنجی: کلاینت یک پیکربندی پیچیده رسانه زاینده را از طریق یک نقطه انتهایی API ارسال می‌کند. API داده‌ها را بر اساس قوانین تایپینگ سخت اعتبارسنجی می‌کند تا تضمین شود تمام پارامترها پیش از ورود به صف، به درستی شکل گرفته‌اند.
• ورود به صف: به جای اجرای مستقیم تولید، API درخواست را به یک شیء کار تغییرناپذیر سریالایز کرده و آن را به BullMQ (که توسط خوشه Redis پشتیبانی می‌شود) می‌فرستد و یک اولویت و کلید گروه‌بندی مناسب به آن اختصاص می‌دهد.
• پولینگ کنترل‌شده: گره‌های ورکر GPU مستقل، که توسط محدودیت‌های هم‌زمانی محلی برای جلوگیری از اشباع VRAM محدود شده‌اند، صف ردیس را بررسی (Poll) می‌کنند. وقتی جایگاه اجرای یک ورکر آزاد شود، آن ورکر به طور اتمیک صاحب بالاترین کار در انتظار از نظر اولویت می‌شود.
• اجرای ایزوله: ورکر پارامترهای تغییرناپذیر کار را بارگذاری می‌کند، VRAM لازم را تخصیص می‌دهد و خط لوله محاسباتی سنگین را — با بهره‌گیری از پردازش WebGPU یا ران‌تایم‌های محلی CUDA — اجرا می‌کند. در طول اجرا، معیارهای پیشرفت محاسبه می‌شوند.
• استریم رویداد و Webhookها: با رسیدن به نقاط عطف، ورکر رویدادهای پیشرفت را در Redis Pub/Sub منتشر می‌کند. هندلرهای Webhook این رویدادها را گرفته و به سمت کلاینت استریم می‌کنند.
• هیدراتاسیون کلاینت و به‌روزرسانی UI: کلاینت فرانت‌اند که کاملاً هیدراته شده و به استریم‌های رویداد در زمان واقعی گوش می‌دهد، تله‌متری پیشرفت را از طریق به‌روزرسانی‌های وضعیت تغییرناپذیر دریافت کرده و پیش‌نمایش‌های لحظه‌ای را بدون ریسک نشت حافظه، شرایط رقابتی یا کرش سخت‌افزاری به کاربر نمایش می‌دهد.

این موتور توزیع‌شده، یک مونولیت شکننده را به یک سیستم مقیاس‌پذیر تبدیل می‌کند. با تلقی کردن VRAM به عنوان یک استخر اتصال دیتابیس ارزشمند، توسعه‌دهندگان می‌توانند زیرساخت‌های زاینده خود را با اطمینان مقیاس‌بندی کنند.

این رویکرد معماری، رویه این حوزه را از مدیریت منابع «امیدوارانه» به محدودسازی هم‌زمانی «الگوریتمیک و سخت» تغییر می‌دهد. این کار گلوگاه را از درایور شکننده GPU به یک صف نرم‌افزاری بادوام و قابل مدیریت منتقل می‌کند.

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

گام بعدی شما

• خط لوله‌های استنتاج فعلی خود را بررسی کنید تا نقاط گلوگاه هم‌زمان (Synchronous) را شناسایی کنید.
• اوج مصرف VRAM را برای هر مدل اندازه‌گیری کنید تا عدد دقیق concurrency برای هر گره سخت‌افزاری را تعیین کنید.
• برای مدیریت کارهای طولانی‌مدت، پیاده‌سازی Webhook را جایگزین اتصالات WebSocket مستقیم کنید.

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