سرویس‌دهی تفکیک‌شده پیش‌پرکنی و رمزگشایی با NVIDIA Dynamo و llm-d

در سیستم‌های استاندارد استنتاج مدل‌های زبانی بزرگ، هر دو مرحله‌ی پیش‌پرکنی (Prefill) و رمزگشایی (Decode) روی یک پردازنده‌ی گرافیکی انجام می‌شوند. فاز پیش‌پرکنی به‌شدت متکی به توان پردازشی (Compute-bound) است، در حالی که فاز رمزگشایی وابسته به پهنای باند حافظه (Memory-bound) است. ترکیب هم‌زمان این دو بار کاری ناهمگون روی یک کارت، موجب هدررفت 20 تا 40 درصدی ظرفیت منابع گران‌قیمت سخت‌افزاری می‌شود.

سرویس‌دهی تفکیک‌شده (Disaggregated Serving) این گره کور را باز می‌کند؛ بدین صورت که بار پردازشی به دو استخر مجزا تقسیم شده و کش کلید-مقدار (KV Cache) با ارتباطات فوق سریع میان آن‌ها تبادل می‌شود. ابزارهایی مانند NVIDIA Dynamo و llm-d این معماری را وارد فاز عملیاتی کرده‌اند تا سازمان‌ها بدون نیاز به خرید کارت‌های جدید، خروجی بسیار بالاتری از زیرساخت‌های خود دریافت کنند.

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

پیش‌پرکنی (Prefill) متکی به توان پردازشی (Compute-bound) است و رمزگشایی (Decode) متکی به پهنای باند حافظه (Memory-bound). اجرای هر دو روی یک GPU باعث هدررفت یکی از این دو منبع می‌شود. معماری تفکیک‌شده (Disaggregation) این دو فاز را به استخرهای مجزا تقسیم می‌کند و کش کلید-مقدار (KV cache) را از طریق NIXL (با RDMA/InfiniBand یا در صورت نبود، طرح پشتیبان TCP) بین آن‌ها انتقال می‌دهد. NVIDIA Dynamo (معرفی‌شده در GTC 2025 و در وضعیت انتشار عمومی 1.0 GA) بالای لایه‌ی vLLM/SGLang/TRT-LLM می‌نشیند؛ بخش‌های Planner Profiler و SLA Planner در این ابزار، نسبت پیش‌پرکنی به رمزگشایی را به‌طور خودکار تنظیم می‌کنند تا با SLOها همگام شود. انویدیا اعدادی در همین حدود برای بهبود نرخ پردازش (Throughput) منتشر کرده است؛ گزارش سایت developer.nvidia.com (تاریخ 2025-06) بهبود تقریباً 6 برابری را برای مدل DeepSeek-R1 MoE روی سیستم GB200 NVL72 به همراه Dynamo در تاخیر متوسط نشان می‌دهد و صفحه‌ی محصول Dynamo (در developer.nvidia.com، بدون تاریخ) از افزایش نرخ پردازش MoE تا 50 برابر روی GB300 NVL72 به همراه Dynamo در مقایسه با Hopper می‌گوید. عدد «30 برابر» یک برآورد تجمیعی از سوی جامعه‌ی کاربری بر اساس گزارش‌های پشته‌ی کامل Blackwell + Dynamo + DeepSeek-R1 است؛ ما هیچ منبع دست‌اولی پیدا نکردیم که دقیقاً عدد 30 برابر را ذکر کرده باشد، بنابراین آن را صرفاً یک ادعای تقریبی در نظر بگیرید. پروژه‌ی llm-d (کاری از Red Hat و AWS) به‌صورت بومیِ کوبرنتیز اجرا می‌شود (Kubernetes-native): پیش‌پرکنی، رمزگشایی و مسیریاب در قالب سرویس‌های مستقل کوبرنتیز با HPA مجزا به ازای هر نقش پیاده شده‌اند. در نسخه 0.5 این پروژه قابلیت‌های تخلیه‌ی سلسله‌مراتبی کش KV، مسیریابی LoRA آگاه از کش، شبکه‌سازی UCCL و کاهش مقیاس تا صفر (Scale-to-zero) اضافه شده است. از نظر اقتصادی: تجمیع داخلی گزارش‌های چند مشتری نشان می‌دهد تغییر از سرویس‌دهی هم‌مکان (Colocated) به معماری تفکیک‌شده با Dynamo تحت یک SLA ثابت، 30 تا 40 درصد در هزینه‌های استنتاج مقیاس 2 میلیون دلاری صرفه‌جویی می‌کند (یعنی 600 تا 800 هزار دلار در سال)؛ البته این رقم صرفه‌جویی 600 تا 800 هزار دلاری حاصل ترکیب داده‌های داخلی است، نه یک مطالعه‌ی موردیِ واحد و منتشرشده، پس آن را معیاری برای درک مرتبه‌ی بزرگی بدانید، نه مرجعی برای استناد. پرامپت‌های کوتاه (کمتر از 512 توکن با خروجی کوتاه) هزینه‌ی انتقال را توجیه نمی‌کنند.

اهداف یادگیری

• توضیح دهید چرا پیش‌پرکنی و رمزگشایی به تخصیص متفاوتی از منابع GPU نیاز دارند و میزان هدررفت در حالت هم‌مکان را ارزیابی کنید.
• معماری تفکیک‌شده را رسم کنید: استخر پیش‌پرکنی، استخر رمزگشایی، انتقال KV از طریق NIXL و مسیریاب.
• شرایطی را نام ببرید که معماری تفکیک‌شده در آن‌ها به‌صرفه نیست (پرامپت‌های کوتاه، خروجی‌های کوتاه).
• تفاوت بین NVIDIA Dynamo (لایه‌ی بالای پشته) و llm-d (بومیِ کوبرنتیز) را تشخیص دهید و هرکدام را به سناریوی عملیاتی مناسب خود متصل کنید.

صورت مسئله

فرض کنید Llama 3.3 70B را روی 8 پردازنده‌ی H100 اجرا می‌کنید. در یک بار کاریِ ترکیبی (پرامپت‌های طولانی + خروجی‌های کوتاه)، پردازنده‌های گرافیکی حین رمزگشایی بیکار می‌مانند، چون بیشتر توان پردازشی صرف فاز پیش‌پرکنی شده است. در بار کاری متفاوت (پرامپت‌های کوتاه + خروجی‌های طولانی)، برعکس این اتفاق می‌افتد. هم‌مکانیِ پیش‌پرکنی و رمزگشایی باعث می‌شود برای هر دو منبع مجبور به بیش‌تخصیص (Over-provisioning) شوید.

اثر روی بودجه: بین 20 تا 40 درصد از زمان GPU برای منبعِ اشتباه هدر می‌رود. شما توان پردازشی گران‌قیمت H100 را می‌خرید تا رمزگشایی متکی به حافظه را اجرا کنید، یا پهنای باند گران‌قیمت HBM در H100 را می‌خرید تا پیش‌پرکنی متکی به پردازش را اجرا کنید. هر دو سناریو اسراف سنگینی است.

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

مفاهیم پایه

چرا گلوگاه‌ها با هم تفاوت دارند؟

پیش‌پرکنی (Prefill) — اجرای ترنسفورمر روی کل پرامپت ورودی در یک گام فرآیند رو به جلو (Forward process). ضرب‌های ماتریسی بیشترین سهم را دارند؛ بنابراین کار متکی به توان پردازشی است. دقت FP8 روی H100 حدود 2000 ترافلاپس (TFLOPS) توان پردازشی مفید ارائه می‌دهد. کارایی دسته‌ای (Batch efficiency) در این فاز بالاست؛ چون یک گام رو به جلو توکن‌های زیادی را به‌طور هم‌زمان پردازش می‌کند.

رمزگشایی (Decode) — تولید توکن‌ها به صورت تک‌به‌تک، که در هر تکرار باید تمام وزن‌های مدل خوانده شوند. این فاز متکی به پهنای باند حافظه است. حافظه‌ی HBM3 تقریباً 3 ترابایت بر ثانیه پهنای باند فراهم می‌کند. کارایی دسته‌ای فقط در هم‌زمانی‌های بالا مناسب است؛ جایی که هزینه‌ی خواندن وزن‌ها روی کل دسته سرشکن می‌شود.

هم‌مکانی آن‌ها: شما GPUهایی می‌خرید که برای هر دو کار بهینه باشند. H100 برای هر دو وظیفه عالی است اما در هر حال هزینه‌ی بالایی دارد. در مقیاس بالا، منطقی است که استخر پیش‌پرکنی روی H100 یا سیستم‌های پردازش‌محور قرار بگیرد و استخر رمزگشایی روی H200 (حافظه‌محور) یا سیستم‌هایی با کوانتیزه‌سازی تهاجمی اجرا شود.

معماری

            ┌──────────────┐
  Request → │    Router    │ ───────────────────────┐
            └──────┬───────┘                        │
                   │                                │
                   ▼ (prompt only)                  │
            ┌──────────────┐    KV cache    ┌───────▼──────┐
            │ Prefill pool │ ─── NIXL ────► │ Decode pool  │
            │  (compute)   │                │  (memory)    │
            └──────────────┘                └──────┬───────┘
                                                   │ tokens
                                                   ▼
                                                 Client

فناوری NIXL بستر انتقال بین‌گره‌ای انویدیا است. در صورت دسترسی از RDMA/InfiniBand استفاده می‌کند و در غیر این صورت به عنوان طرح پشتیبان سراغ TCP می‌رود. تاخیر انتقال محسوس است؛ برای کش KV یک پرامپت 4K روی مدل 70B با دقت FP8 این زمان معمولاً بین 20 تا 80 میلی‌ثانیه طول می‌کشد. به همین دلیل پرامپت‌های کوتاه تفکیک‌پذیری را توجیه نمی‌کنند: هزینه‌ی جابه‌جایی از سود حاصل بیشتر می‌شود.

مقایسه‌ی Dynamo و llm-d

NVIDIA Dynamo (معرفی در GTC 2025، نسخه‌ی 1.0 GA):

• به عنوان یک هماهنگ‌کننده (Orchestrator) بالای سر vLLM، SGLang و TRT-LLM قرار می‌گیرد.
• ماژول Planner Profiler بار کاری را می‌سنجد و SLA Planner نسبت پیش‌پرکنی به رمزگشایی را به‌صورت خودکار پیکربندی می‌کند.
• هسته‌ی اصلی به زبان Rust با قابلیت توسعه به زبان Python.
• ارقام بهبود نرخ پردازش: انویدیا افزایش 6 برابری را برای DeepSeek-R1 MoE روی GB200 NVL72 همراه با Dynamo در دامنه‌ی تاخیر متوسط گزارش کرده است (developer.nvidia.com، تاریخ 2025-06)؛ ادعاهای جامعه‌ی کاربری مبنی بر بهبود «تا 30 برابر» روی پشته‌ی کامل Blackwell + Dynamo + DeepSeek-R1 فاقد منبع موثق واحد است و باید صرفاً به عنوان یک تخمین در نظر گرفته شود.
• سیستم GB300 NVL72 به همراه Dynamo: بر اساس صفحه‌ی محصول Dynamo (developer.nvidia.com، بدون تاریخ) تا 50 برابر نرخ پردازش MoE بیشتر در برابر خط مبنای Hopper ارائه می‌دهد.

llm-d (محصول Red Hat و AWS، بومی کوبرنتیز):

• فازهای پیش‌پرکنی، رمزگشایی و مسیریاب در قالب سرویس‌های مستقل کوبرنتیز پیاده‌سازی می‌شوند.
• قابلیت HPA به ازای هر نقش بر اساس طول صف (برای پیش‌پرکنی) و میزان مصرف کش KV (برای رمزگشایی).
• دستور topologyConstraint packDomain: rack خوشه‌های پیش‌پرکنی و رمزگشایی را روی یک رک قرار می‌دهد تا انتقال KV با بیشترین پهنای باند انجام شود.
• در نسخه‌ی llm-d 0.5 (سال 2026): تخلیه‌ی سلسله‌مراتبی کش KV، مسیریابی LoRA آگاه از کش، شبکه‌سازی UCCL و کاهش مقیاس تا صفر اضافه شده است.

اگر یک هماهنگ‌کننده‌ی مدیریت‌شده بالای پشته‌ی فعلی می‌خواهید، Dynamo را انتخاب کنید. اگر دنبال اجزای سازنده‌ی (Primitives) بومی کوبرنتیز هستید و روی اکوسیستم CNCF سرمایه‌گذاری کرده‌اید، سراغ llm-d بروید.

جنبه‌های اقتصادی

ترکیب داده‌های درون‌سازمانی (نه یک مطالعه‌ی موردی تکی؛ به عنوان یک مبنا برای مرتبه‌ی بزرگی):

• هزینه‌ی سالانه‌ی استنتاج: 2 میلیون دلار در معماری هم‌مکان.
• مهاجرت به معماری تفکیک‌شده با Dynamo.
• با همان حجم درخواست و همان SLA تاخیر در چارک 99 (P99).
• صرفه‌جویی گزارش‌شده: 600 تا 800 هزار دلار در سال (کاهش 30 تا 40 درصدی).
• بدون خرید سخت‌افزار جدید.

ما این رقم را از گزارش‌های چند مشتری مختلف استخراج کرده‌ایم، نه از یک مطالعه‌ی منتشرشده؛ نزدیک‌ترین آمارهای رسمی عبارت‌اند از گزارش Baseten مبنی بر 2 برابر شدن سرعت زمان تا اولین توکن (TTFT) و 61 درصد نرخ پردازش بالاتر با مسیریابی KV در Dynamo (در baseten.co، تاریخ 2025-10)، و پیش‌بینی VAST + CoreWeave از 60 تا 130 درصد توکن بیشتر به ازای هر دلار در نرخ برخورد (Hit rate) کشِ 40 تا 60 درصدی (در vastdata.com، تاریخ 2025-12). این سود مالی از تعیین اندازه‌ی دقیق هر استخر به دست می‌آید؛ کارهای متکی به پیش‌پرکنی (مانند RAG با پیشوندهای 8K توکن به بالا) بسیار بیشتر از بارهای کاری متوازن سود می‌برند.

چه زمان‌هایی نباید تفکیک کنیم؟

• پرامپت‌های کمتر از 512 توکن و خروجی‌های کمتر از 200 توکن: جریمه‌ی تاخیر انتقال بر منافع آن می‌چربد.
• خوشه‌های کوچک (کمتر از 4 پردازنده‌ی گرافیکی): تنوع کافی برای تفکیک به استخرهای مجزا وجود ندارد.
• ناتوانی تیم در نگهداری عملیاتی دو استخر GPU با مقیاس‌پذیری مجزا: هرچند Dynamo کار را ساده می‌کند، اما پیاده‌سازی و مدیریت آن خالی از دردسر نیست.
• نبود شبکه‌ی RDMA: در این حالت جریمه‌ی انتقال از طریق TCP سنگین‌تر خواهد بود.

یکپارچگی مسیریاب با فاز 17 · 11

مسیریاب‌ها در سیستم‌های تفکیک‌شده نسبت به کش KV هوشمند هستند (Phase 17 · 11). درخواست جدید به سمت استخر رمزگشایی هدایت می‌شود که پیشوند موردنظر را در حافظه دارد؛ در صورت عدم تطابق، جریان کاری به صورت «پیش‌پرکنی → رمزگشایی» پیش می‌رود. نرخ برخورد کش و تفکیک معماری هم‌افزایی دارند؛ مسیریاب آگاه از کش مشخص می‌کند که آیا اصلاً نیازی به اجرای فاز پیش‌پرکنی هست یا خیر.

قدرت اصلی معماری MoE روی Blackwell مشخص می‌شود

سیستم GB300 NVL72 به همراه Dynamo افزایش 50 برابری در نرخ پردازش MoE را نسبت به خطوط مبنای Hopper نشان می‌دهد. در مدل‌های MoE، مسیریابی خبره‌ها (Expert routing) در فاز پیش‌پرکنی نیازمند توان پردازشی بالا و در فاز رمزگشایی متکی به حافظه است (به خاطر کش خبره‌ها)، در نتیجه تفکیک‌پذیری سودی دوچندان می‌سازد. از سال 2026 بخش عمده‌ی سرویس‌دهی مدل‌های پیشرو مبتنی بر MoE است (نظیر DeepSeek-V3 و نسخه‌های بعدی GPT-5).

اعدادی که باید به خاطر بسپارید

نتایج بنچمارک‌ها تغییر می‌کنند؛ انویدیا و توسعه‌دهندگان پشته‌های استنتاج در هر فصل آمارهای به‌روز منتشر می‌کنند. همیشه پیش از استناد، آن‌ها را بازبینی کنید.

• مدل DeepSeek-R1 روی GB200 NVL72 به همراه Dynamo: حدود 6 برابر نرخ پردازش بیشتر در مقایسه با خط مبنا در دامنه‌ی تاخیر متوسط (developer.nvidia.com، تاریخ 2025-06)؛ ادعای جامعه‌ی کاربری برای بهبود «تا 30 برابر» روی پشته‌های کامل Blackwell + Dynamo صرفاً ارقامی تقریبی و بدون منبع موثق واحد است.
• سیستم GB300 NVL72 با Dynamo: تا 50 برابر نرخ پردازش بالاتر در مدل‌های MoE نسبت به Hopper (developer.nvidia.com، بدون تاریخ).
• مبنای صرفه‌جویی اقتصادی (برآورد داده‌های داخلی، نه یک مطالعه‌ی موردیِ واحد): 600 تا 800 هزار دلار در سال از بودجه‌ی 2 میلیون دلاری سالانه تحت SLA ثابت.
• آستانه‌ی به‌صرفه بودن تفکیک: پرامپت‌های بزرگ‌تر از 512 توکن به‌همراه خروجی‌های بیشتر از 200 توکن.
• انتقال KV از طریق NIXL: حدود 20 تا 80 میلی‌ثانیه برای کش KV یک پرامپت 4K روی 70B با دقت FP8.

استفاده از ابزارهای واقعی

فایل code/main.py سناریوهای سرویس‌دهی هم‌مکان و تفکیک‌شده را شبیه‌سازی می‌کند. این کد نرخ پردازش، هزینه به ازای هر درخواست و نقطه‌ی تلاقی طول پرامپت را گزارش می‌دهد.

خروجی این درس

این درس فایل outputs/skill-disaggregation-decider.md را تولید می‌کند؛ ابزاری که با دریافت بار کاری و مشخصات خوشه، به‌صرفه بودن تفکیک معماری را ارزیابی و تعیین می‌کند.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. تفکیک معماری دقیقاً در چه طولی از پرامپت نسبت به حالت هم‌مکان برتری پیدا می‌کند؟
2. استخرهای پیش‌پرکنی و رمزگشایی را برای یک سرویس RAG طراحی کنید که طول پیشوند در چارک 99 (P99) آن برابر با 8K توکن و طول خروجی 300 توکن باشد.
3. میان Dynamo و llm-d دست به انتخاب بزنید: برای سازمانی که زیرساخت کاملاً مبتنی بر کوبرنتیز دارد و وابستگی خاصی به محیط اجرای Python ندارد، کدام مناسب‌تر است؟
4. هزینه‌ی جابه‌جایی KV را محاسبه کنید: 4K توکن پیش‌پرکنی روی مدل 70B با دقت FP8 حدود 500 مگابایت کش KV می‌سازد. در شبکه‌ی RDMA با سرعت 100 گیگابایت بر ثانیه، انتقال 5 میلی‌ثانیه زمان می‌برد. در شبکه‌ی TCP با سرعت 10 گیگابایت بر ثانیه این زمان به 50 میلی‌ثانیه می‌رسد. این اختلاف چه تاثیری بر SLA شما می‌گذارد؟
5. مسیریابی خبره‌ها در مدل‌های MoE الگوی دسترسی به KV را دگرگون می‌کند. معماری تفکیک‌شده در مواجهه با مدل MoE که به ازای هر توکن خبره‌های متفاوتی را فعال می‌کند چگونه رفتار خواهد کرد؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• NVIDIA — Introducing Dynamo
• NVIDIA — Disaggregated LLM Inference on Kubernetes
• TensorRT-LLM Disaggregated Serving blog
• llm-d GitHub
• llm-d 0.5 release notes