شرکت Shadow: کاهش تأخیر چندوجهی از ۴.۲ به ۲.۶ ثانیه

اگر امروز برای تولید محتوای چندوجهی منتظر می‌مانید، احتمالاً با مشکل «تأخیر دم» (Tail Latency) دست‌وپنجه نرم می‌کنید؛ جایی که کندترین بخش سیستم، کل خروجی را متوقف می‌کند. شرکت Shadow با معرفی معماری سنتز مستقیم، این سد زمانی را شکست و میانگین زمان تکمیل عملیات را از ۴.۲ ثانیه به ۲.۶ ثانیه کاهش داد. این تغییر بنیادین که جزئیات آن در گزارش فنی وب‌سایت dev.to منتشر شده است، به معنای گذار از مدل استاندارد صنعت یعنی «هماهنگ‌کننده مرکزی» به سمت یک هسته رویدادمحور تحت عنوان «استودیوی تاریک» (Dark Studio) است.

در اکثر خط لوله‌های رسانه‌ای هوش مصنوعی، یک حلقه درخواست/پاسخ همزمان (Synchronous) وجود دارد که در آن یک مدیر مرکزی منتظر می‌ماند تا هر مرحله — متن، تصویر، چیدمان و صدا — به‌طور کامل تمام شود و سپس مرحله بعد را شروع کند. این وضعیت باعث ایجاد مشکل «تأخیر دم» می‌شود؛ به این معنا که کندترین مرحله، کل خط لوله را مسدود می‌کند. برای مثال، اگر رندر بصری ۴۰۰ میلی‌ثانیه زمان ببرد، کل سیستم متوقف می‌شود، حتی اگر میکس صدا در ۵۰ میلی‌ثانیه آماده شده باشد. این وضعیت شبیه به کارخانه‌ای است که تیم بسته‌بندی ده دقیقه بیکار می‌ماند چون تیم رنگ‌آمیزی کمی عقب است، در حالی که محصول از قبل برای بسته‌بندی آماده است.

رویکرد Shadow این منطق را معکوس می‌کند. فلسفه «استودیوی تاریک» آن‌ها، محیط تولید را ایزوله کرده و آن را مشاهده‌پذیر و بومیِ رویدادها (Event-native) می‌کند. در این سیستم، سنتز چندوجهی به‌جای مجموعه‌ای از گام‌های مجزا، به عنوان یک مسئله «جریان داده» (Streaming) دیده می‌شود. در این محیط، هیچ بخشی در هسته سیستم فرض نمی‌کند که باید در یک حلقه درخواست/پاسخ همزمان قرار بگیرد.

معماری سه حلقه‌ای

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

• لایه پذیرش (Ingest Layer): این لایه درخواست‌های HTTP همزمان را برای پذیرش پرامپت‌ها و اعتبارسنجی آن‌ها در برابر سیاست‌های سیستمی مدیریت می‌کند. این تنها بخش همزمان در جریان اولیه درخواست است.
• حلقه سنتز (Synthesis Ring): یک خط لوله ناهمزمان و رویدادمحور است که عملیات واقعی چندوجهی (Multimodal) — مدلی که مثل انسان هم‌زمان متن، عکس و صدا را می‌فهمد — در آن رخ می‌دهد. سنتزکننده در این حلقه هرگز از وجود HTTP خبر ندارد و تنها وظیفه‌اش تولید رویدادهاست.
• حلقه تله‌متری (Telemetry Ring): سیستمی مبتنی بر رویدادهای ارسالی سرور (SSE) است که تغییرات وضعیت را به مشترکین (Subscribers) پخش می‌کند. یک لایه تبدیل کوچک، رویدادهای سنتز را به فریم‌های SSE برای کلاینت‌ها ترجمه می‌کند.

سنتز مستقیم در برابر هماهنگ‌سازی

در مدل سنتز مستقیم، گره‌های مربوط به هر وجه (Modality) منتظر دستور یک هماهنگ‌کننده نمی‌مانند. در عوض، هر گره به محض آماده شدن خروجی جزئی خود، آن را منتشر می‌کند. گره‌های پایین‌دستی مشترک این جریان‌ها هستند و به محض دریافت محرک (Trigger) لازم، کار خود را بلافاصله آغاز می‌کنند.

برای مثال، پردازش میکس صدا می‌تواند در همان لحظه‌ای که طرح چیدمان (Layout Plan) ایجاد شد شروع شود، بدون اینکه منتظر بماند تا رندر بصری به پایان برسد. این ساختار اجازه می‌دهد تا حجم کاری به‌جای انباشت خطی، روی چندین واحد پردازش گرافیکی (GPU) پخش شود. این امر از اشغال بی‌دلیل منابع جلوگیری می‌کند؛ یعنی GPU مربوط به صدا در حالی که رندر بصری در حال تکمیل است، بیکار نمی‌ماند. در نتیجه، زمان کل (Wall Time) کاهش می‌یابد زیرا کارها به‌جای صف کشیدن، به صورت موازی پخش می‌شوند. همچنین تأخیر p99 بهبود می‌یابد زیرا فشار معکوس (Backpressure) به‌جای تجمع پشت یک هماهنگ‌کننده، به‌طور شفاف در گذرگاه داده منتشر می‌شود.

پیاده‌سازی فنی گذرگاه داده

شرکت Shadow از یک MultimodalBus سبک برای مدیریت ارتباطات بین مراحل استفاده می‌کند. این گذرگاه اشیایی به نام StageEvent را مدیریت می‌کند که وضعیت کارهای خاص را در پنج مرحله کلیدی ردیابی می‌کنند:

• تجزیه پرامپت (prompt_parse)
• طرح چیدمان (layout_plan)
• رندر بصری (visual_render)
• میکس صدا (audio_mix)
• تجميع زیرنویس (caption_assemble)

هر StageEvent شامل jobId (شناسه کار)، stage (مرحله)، status (وضعیت: شروع شده، جزئی، کامل یا شکست‌خورده)، یک بافر اختیاری برای artefact (محصول)، metadata (به صورت Record<string, unknown>) و یک timestamp (برچسب زمانی عددی) است.

به دلیل جداسازی این گذرگاه از منطق سنتز، تیم توسعه می‌تواند بدون بازنویسی کارگران مدل (Model Workers)، زیرساخت انتقال داده را به NATS یا Redis Streams تغییر دهد. هر کارگر در این سیستم یک پردازش تک‌منظوره است که یک مرحله را مصرف کرده و رویدادها را به گذرگاه بازمی‌گرداند.

به عنوان مثال، یک visualRenderWorker مشترک مرحله layout_plan است. به محض تکمیل طرح، این کارگر یک رویداد «شروع شده» منتشر می‌کند. سپس متد renderStream(plan) مدل را فراخوانی می‌کند. با رسیدن هر فریم، به‌روزرسانی‌های «جزئی» شامل بافر فریم و متادیتای پیشرفت را منتشر می‌کند و در نهایت یک رویداد «کامل» ارسال می‌کند. این فرآیند تضمین می‌کند که کلاینت به‌جای یک جعبه سیاه، تصویری در حال شکل‌گیری را ببیند.

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

برای اینکه کاربر در طول تولید با یک «جعبه سیاه» مواجه نشود، Shadow از SSE برای ارسال به‌روزرسانی‌های یک‌طرفه (Unidirectional Push) استفاده می‌کند. این کار به کلاینت اجازه می‌دهد تصویری زنده از پیشرفت کار را دریافت کند. لایه HTTP در اینجا بسیار نازک نگه داشته شده و تنها مسئول قالب‌بندی انتقال و پیروی دقیق از استاندارد SSE است.

قالب‌بندی SSE و انتقال:
فریم‌ها با استفاده از تابع خاص sseFrame ساخته می‌شوند که فیلدهای id ،event و data را مدیریت می‌کند. telemetryRouter هدرهای خاصی را برای تضمین تحویل فوری تنظیم می‌کند:

• Content-Type: text/event-stream
• Cache-Control: no-cache, no-transform
• Connection: keep-alive
• X-Accel-Buffering: no

برای حفظ پایداری اتصال، سیستم چندین safeguard در سطح انتقال پیاده کرده است:

• ضربان قلب (Heartbeats): هر ۱۵ ثانیه یک خط کامنت : ping ارسال می‌شود تا از قطع شدن اتصالات بیکار توسط پروکسی‌ها جلوگیری شود.
• X-Accel-Buffering: هدر X-Accel-Buffering: no به Nginx دستور می‌دهد که تکه‌های داده (Chunks) را بلافاصله ارسال کند و آن‌ها را بافر نکند.
• سطل توکن (Token Buckets): برای جلوگیری از نشت حافظه (OOM) در سرور به‌دلیل کندی کلاینت‌ها (مانند مرورگرهای موبایل با اینترنت ضعیف)، یک TokenBucket نرخ جریان داده را برای هر اشتراک محدود می‌کند.

این سطل از منطق capacity (ظرفیت) و refillPerMs (پر شدن در هر میلی‌ثانیه) استفاده می‌کند. اگر کلاینت نتواند یک جریان تصویری ۳۰ مگابایتی را با سرعت کامل جذب کند، فریم‌های جزئی از مسیر انتقال حذف می‌شوند. در این حالت، سنتزکننده هرگز متوقف نمی‌شود، بلکه لایه انتقال خودش را کند می‌کند. بدون این مکانیزم، یک مشترک کند می‌توانست بافرهای داخلی را پر کرده و حافظه را تا حد کرش کردن نود افزایش دهد.

تحلیل خطا و تحلیل داده‌ها

در مدل استودیوی تاریک، خطاها نیز به عنوان «رویداد» تلقی می‌شوند. اگر یک کارگر به‌دلیل کمبود حافظه مدل (Model OOM) یا پارتیشن ذخیره‌سازی کرش کند، یک رویداد failed با کد خطای خاص منتشر می‌کند. این رویداد از همان گذرگاهی می‌رود که رندرهای موفق می‌روند و نیاز به نقاط بررسی سلامت (Health Endpoints) جداگانه را از بین می‌برد.

حالت‌های شکست رایج شناسایی شده عبارتند از:

• Model OOM: کارگر رویداد MODEL_OOM را منتشر می‌کند و هماهنگ‌کننده برای تلاش مجدد، مدل را به نسخه کوچک‌تری کاهش می‌دهد.
• Storage Partition: اگر قطعی شبکه بین کارگر و ذخیره‌ساز اشیاء رخ دهد، کارگر از استراتژی backoff نمایی استفاده می‌کند. اگر مهلت زمانی (Deadline) تمام شود، رویداد STORAGE_UNREACHABLE منتشر می‌شود.
• Policy Violation: این موارد به‌طور همزمان در لایه پذیرش رد شده و هرگز به سنتزکننده نمی‌رسند.

برای بهینه‌سازی بلندمدت، تمام رویدادها در یک پایگاه‌داده Postgres ذخیره می‌شوند. تیم از یک اسکیمای باریک در جدول job_telemetry برای ردیابی job_id ،stage ،status ،progress ،artefact_url ،error_code ،error_message و created_at (از نوع TIMESTAMPTZ) استفاده می‌کند.

آن‌ها ایندکس‌های خاصی روی (job_id, created_at) و (stage, created_at DESC) برای بهینه‌سازی تحلیل‌ها قرار داده‌اند. پرس‌وجوهای ساعتی برای محاسبه تأخیرهای p50، p95 و p99 برای مراحل خاص با استفاده از percentile_cont در گروه‌های مرتب شده بر اساس duration_ms اجرا می‌شوند. برای مثال، مدت زمان با استخراج epoch از تفاوت بین MAX(created_at) و MIN(created_at) برای یک job_id خاص در مرحله visual_render محاسبه می‌شود. هر چیزی که بیش از یک انحراف معیار جابجا شود، باعث فعال شدن هشدار در داشبوردهای داخلی می‌شود.

تحویل نهایی و پاک‌سازی

پس از تکمیل مرحله نهایی تجميع، سیستم داده‌های باینری را از طریق اتصال SSE پروکسی نمی‌کند. در عوض، محصولات را در ذخیره‌ساز اشیاء (Object Storage) می‌نویسد و لینک‌های امضا شده (Signed URLs) با TTL کوتاه را از طریق جریان SSE به عنوان رویدادهای complete به کلاینت ارسال می‌کند.

کلاینت برای هر وجه (Modality) رویدادهای جداگانه‌ای دریافت می‌کند (مانند visual_render و audio_mix) که هر کدام شامل status: complete و یک artefactUrl است. این کار تضمین می‌کند که اتصال SSE سبک بماند و تیم بتواند از CDNها برای کشینگ منطقه‌ای استفاده کند. مسیر تحویل و مسیر تله‌متری هیچ اشتراکی ندارند، به این معنی که یک اتصال SSE متوقف شده نمی‌تواند مانع دانلود واقعی رسانه تولید شده شود. سنتزکننده هرگز بایت‌ها را پروکسی نمی‌کند.

مدیریت چرخه عمر اشتراک:
هر اشتراک SSE منابعی را مصرف می‌کند، از جمله یک شنونده گذرگاه برای هر مرحله، یک تایمر ضربان قلب و یک اتصال TCP. شرکت Shadow این‌ها را از طریق یک SubscriptionRegistry مدیریت می‌کند تا تعداد کل مشترکین در هر نود را محدود کند.

اگر متد canAccept() در رجیستری مقدار false برگرداند، نقطه انتهایی SSE با کد 503 Service Unavailable و هدر Retry-After پاسخ می‌دهد. این کار کلاینت‌ها را مجبور می‌کند عقب‌نشینی کرده و نود دیگری را امتحان کنند. علاوه بر این، ضربان قلب ۱۵ ثانیه‌ای به عنوان تشخیص کلاینت‌های مرده عمل می‌کند؛ اگر سه ضربان قلب بدون تایید (ack) از سوکت زیرین بگذرد، اشتراک بسته شده و شنونده‌ها آزاد می‌شوند تا از نشت منابع جلوگیری شود.

جمع‌بندی نهایی

کل خط لوله از یک توالی سختگیرانه پیروی می‌کند:

1. کلاینت یک پرامپت را به /jobs ارسال (POST) می‌کند.
2. لایه پذیرش آن را اعتبارسنجی کرده و یک jobId برمی‌گرداند.
3. لایه پذیرش یک رویداد شروع prompt_parse در گذرگاه منتشر می‌کند، سپس تجزیه را اجرا کرده و رویداد تکمیل را با یک طرح تجزیه‌شده منتشر می‌کند.
4. کارگران چیدمان، بصری و صوتی مشترک پیش‌نیازهای خود شده و فریم‌های جزئی را منتشر می‌کنند.
5. تجميع زیرنویس محصولات تکمیل شده را جمع‌آوری کرده، در ذخیره‌ساز اشیاء می‌نویسد و رویدادهای تکمیل را با لینک‌های امضا شده منتشر می‌کند.
6. جریان SSE کلاینت تمام تغییرات را تا انتشار رویداد job_done حمل می‌کند.
7. تله‌متری همزمان با جریان رویدادها در Postgres ذخیره می‌شود.

این انضباط معماری تضمین می‌کند که مقیاس‌پذیری خطی باشد. افزودن کارگران بیشتر برای یک مرحله خاص، ظرفیت آن مرحله را بدون نیاز به تنظیم مجدد هماهنگ‌کننده مرکزی افزایش می‌دهد. با جداسازی سنتزکننده از شبکه و شبکه از مدل، Shadow سیستمی ساخته است که در آن تأخیر پیش‌بینی‌پذیر است و عیب‌یابی صرفاً به معنای بازپخش (Replay) یک لاگ از رویدادهاست.

گام بعدی شما

• اگر از معماری‌های Synchronous در اپلیکیشن‌های AI استفاده می‌کنید، مدل Event-driven را برای کاهش Tail Latency بررسی کنید.
• برای نمایش پیشرفت تولید محتوا به کاربر، به‌جای Polling، از Server-Sent Events (SSE) استفاده کنید.
• سیستم‌های مانیتورینگ خود را بر اساس توزیع Percentile (مانند p99) تنظیم کنید تا گلوگاه‌های پنهان را بیابید.

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