إعادة التعبير / إعادة تشكيل المعلومات
Type: Learn
Languages: Python (stdlib, toy disaggregated-vs-colocated simulator)
Prerequisites: Phase 17 · 04 (Serving Engine Internals), Phase 17 · 08 (Inference Metrics)
Time: ~75 minutes
أهداف التعلم
- شرح لماذا تمتلك المكملات المسبقة والتشفير المعدل المختلفة لتخصيصات GPU المثلى وتحديد النفايات تحت التجميع.
- رسم الرسم البياني للهندسة المعمارية الممزقة: حوض التملأ مسبقًا، حوض فك الرمز، نقل KV عبر NIXL، جهاز توجيه.
- أسمي الحالة التي لا تؤدي فيها التقسيم إلى نتائج (التسجيلات القصيرة، والمخرجات القصيرة).
- تمييز NVIDIA Dynamo (المركز أعلاه) عن llm-d (Kubernetes-أصل) ويتطابق كل منهما مع سياق تشغيلي.
المشكلة
تقوم بتشغيل Llama 3.3 70B على 8 H100s. تحت عبء عمل مختلط (تلقيحات طويلة + خروجي قصير) ، فإن GPUs تتوقف أثناء فك التشغيل لأن معظم الحسابات تم إنفاقها على prefill. تحت عبء عمل مختلف (تلقيحات قصيرة + خروجي طويل) ، يحدث العكس. تعني prefill + decode الموضعة أنك تزيد من إمدادات كل منهما.
تأثير الميزانية: 20-40٪ من وقت GPU يضيع على الموارد الخطأ. كنت تشتري حاسوب H100 لتشغيل فك التشفير المرتبط بالذاكرة، أو شراء H100 HBM عرض النطاق لتشغيل الحاسوب المرتبط قبل التملأ. كلاهما هو نفايات مكلفة.
تقسم التقسيم المقبل والتشفير على مجموعات منفصلة بحجم كل عقدة زجاجة. ينقل مخزن KV من مجموعة المقبل إلى مجموعة تشفير عبر اتصال متبادل عالي النطاق الترددي.
المفهوم
لماذا تختلف عوارض الزجاجة
Prefill تشغيل المحول على استدعاء المدخل الكامل في واحد إلى الأمام. غالبة مضاعفات المصفوفة؛ مقيدة بالحساب. H100 FP8 يعطي ~ 2000 TFLOPS من التدفق المفيد. كفاءة البطاقة جيدة واحد إلى الأمام معالجة العديد من الرموز.
Decode توليد رمز واحد في وقت واحد ، قراءة الوزن الكامل في كل تكرار. مقيدة على عرض النطاق التذاكر. HBM3 يعطي ~ 3 TB / s. كفاءة البطاقة جيدة فقط عند التزامن العالي الوزن القراءة تعويض على جميع أنحاء البطاقة.
تحديد المواقع: تشتري وحدات عملة محلياً محسنة لكلتا الحالتين. H100 جيدة في كلتا الحالتين ولكن تكلفة نفسها في كلتا الحالتين. على نطاق واسع، تريد جمع ملء مسبق على H100 / محاسبة ثقيلة؛ جمع فك رموز على H200 / ذاكرة ثقيلة، أو مع كمية عددية.
الهندسة المعمارية
┌──────────────┐
Request → │ Router │ ───────────────────────┐
└──────┬───────┘ │
│ │
▼ (prompt only) │
┌──────────────┐ KV cache ┌───────▼──────┐
│ Prefill pool │ ─── NIXL ────► │ Decode pool │
│ (compute) │ │ (memory) │
└──────────────┘ └──────┬───────┘
│ tokens
▼
Clientنيكسل هو النقل بين العقدات من NVIDIA. يستخدم RDMA / InfiniBand عندما تكون متاحة ، والتكلفة TCP fallback خلاف ذلك. تأخر النقل حقيقي عادة 20-80 ms لخزن KV من عرض 4K-token على 70B FP8. هذا هو السبب في أن الطلبات القصيرة لا تبرر التقسيم: ضريبة النقل تتجاوز المدخرات.
دينامو مقابل إلم-د
NVIDIA Dynamo(إعلانات إدارة الأعمال العامة 2025، 1.0 GA):
- يجلس فوق VLLM، SGLang، TRT-LLM كموسيقي.
- المخطط الموضح يقيس عبء العمل، المخطط SLA تهيئ تلقائيًا prefill:decode ratios.
- القوه الصلبة، ومتوسعة Python.
- مكاسب التشغيل: تقارير NVIDIA 6x لـ DeepSeek-R1 MoE على GB200 NVL72 + Dynamo في نظام التأخير المتوسط (developer.nvidia.com، 2025-06) ؛ تقارير المجتمع "حتى 30x" على مجموعات Blackwell + Dynamo + DeepSeek-R1 الكاملة تفتقر إلى مصدر رئيسي واحد وينبغي التعامل معها على أنها توجيهية.
- GB300 NVL72 + Dynamo: ما يصل إلى 50x MoE throughput مقابل Hopper لكل صفحة منتج Dynamo (developer.nvidia.com، غير محددة).
llm-d(Red Hat + AWS، Kubernetes-أصل):
- إعداد / فك رموز / جهاز التوجيه كمخدمات Kubernetes المستقلة.
- HPA لكل دور مع أعمق الصف (مليئة) / إشارات استخدام KV (تفكيك)
topologyConstraint packDomain: rackحزم الاحتفاظ بالشكل المسبق + نقرات التفكيك على نفس الرف لنقل KV عالي النطاق الترددي.- llm-d 0.5 (2026): تخفيض KV الترتيبي، توجيه LoRA واعي التخزين، شبكة UCCL، مقياس إلى الصفر.
استخدم (دينامو) إذا أردت محركًا مديرًا على سطح الكتل، استخدم (إلم-د) إذا أردت أولياء من أصل (كوبيرنيتس) ومتعهدين بنظام (سي إن سي إف) البيئي.
الاقتصاد
المركب الداخلي (ليس هناك دراسة حالة واحدة نشرت مرساة ترتيب الكبيرة):
- 2 مليون دولار سنوياً في الإنفاق على الخدمة المخصصة
- لقد تم تحويلها إلى "مُفصلة" مع "دينامو".
- نفس حجم الطلب، نفس P99 تأخير SLA.
- المدخرات المبلغ عنها: $600K–$800 ألف دولار سنوياً (خفض بنسبة 3040٪).
- لا توجد أجهزة جديدة
نحن نجمع هذا الرقم من العديد من الإفصاحات العملاء بدلاً من دراسة حالة واحدة قابلة للنظر؛ أقرب نقطة بيانات نشرت هي 2x أسرع TTFT / 61% ارتفاع التوصيل مع Dynamo KV توجيه (baseten.co، 2025-10) ، و VAST + CoreWeave التوقعات 60130% المزيد من الرموز / $ عند 4060% KV معدل ضرب (vastdata.com، 2025-12). وتتأتي التوفيرات من الحجم الصحيح لكل حوض استحمام؛ تحميلات العمل الثقيلة التي يتم ملئها مسبقاً (RAG مع تعريفات 8K+) تستفيد أكثر من تلك المتوازنة.
متى لا يتم تفكيكها
- الإشارات < 512 رمزاً ومخرجات < 200 رمزاً: ضريبة التحويل تهيمن على الربح.
- مجموعة صغيرة (< 4 GPU): عدم كفاية تنوع المجموعة.
- لا يمكن للطاقم تشغيل مجموعتين من وحدات GPU مع تنمية لكل دور: Dynamo يساعد ولكن ليس على نحوٍ بسيط.
- لا توجد قناة RDMA: ضريبة نقل TCP أكثر ثقلًا.
الجهاز التوجيه يدمج مع المرحلة 17 · 11
الجهازات التوجهية المفصلة هي KV-Cache-aware (المرحلة 17 · 11). يقع طلب على مجموعة التشخيص التي تحتوي على مقدمة إذا لم تكن مطابقة، فإنه يتوجه إلى prefill → decode. معدل ضربات ومجموعة التشغيل يحدد الجهاز التوجهي المفصلة للتشخيص التشخيصي ما إذا كان هناك حاجة إلى إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إعادة إ إعادة إعادة إعادة إعادة إعادة إ إعادة إعادة إ إ إعادة إ إ إ إ إ إعادة إ إ إ إعادة إعادة إ إ إ إ إعادة إعادة إ إ إ إ إ إ إعادة إعادة إعادة إ إ إ إ إ إ إ إ إ إعادة إعادة إ إ إ إ إ إ إ إعادة
الـ (مؤسسة التكنولوجيا) على (بلاكويل) هي حيث الأرقام الحقيقية
يظهر GB300 NVL72 + Dynamo 50x MoE throughput على خطوط هوبر الأساسية. التوجيه الخبير MoE هو محاسبة ثقيلة على prefill ولكن ذاكرة ثقيلة على فك (مخزنات الخبراء) ، لذلك التقسيم هو فائدة مزدوجة. 2026 نموذج الحدود الخدمة هو MoE-dominant (DeepSeek-V3 ، مستقبل GPT-5 المتغيرات).
أرقام يجب أن تتذكر
أرقام المقاييس تتحرك NVIDIA و كومة الاستخدامات تحديث النتائج كل ربع. تحقق مرة أخرى قبل الاقتباس.
- DeepSeek-R1 على GB200 NVL72 + Dynamo: ~6x throughput vs baseline في نظام التأخير المتوسط (developer.nvidia.com، 2025-06) ؛ المطالبات المجتمعية "حتى 30x" على كومات Blackwell + Dynamo الكاملة هي مجموعات اتجاهية دون مصدر أساسي واحد.
- GB300 NVL72 + Dynamo: ما يصل إلى 50x MoE throughput مقابل Hopper (المطور.nvidia.com، غير محدد).
- مُركب التوفير (مُركب داخلي، لا دراسة حالة واحدة): $600-800K/year off a $2 مليون نفقات سنوية عند SLA ثابتة
- عتبة التقسيم: الإشارات > 512 رمزا + الخروج > 200 رمزا.
- نقل KV عبر NIXL: 20-80 ms لـ 4K-منتقل KV على 70B FP8.
استخدمها
code/main.pyيحاكي خدمة المشاركة مقابل الخدمة المجزئة. يبلغ عن التكلفة لكل طلب، والعرض المباشر.
أرسله
هذا الدرس يُنتجoutputs/skill-disaggregation-decider.md- بالنظر إلى عبء العمل والكلاستر، يقرر ما إذا كان يجب تفكيكها.
التمارين
- أركض
code/main.pyفي أي طول يسرع تفكيك يفوق التجميع؟ - تصميم حوض التملأ المسبق ومجمع فك الرمز لخدمة RAG مع طول المرفق الأول P99 8K، الخروج 300.
- دينامو مقابل إيلم-دي: اختر واحد لمحل كوبرنيتس خالص بدون تفضيل وقت تشغيل بايثون.
- حساب تكلفة نقل KV: 4K prefill على 70B FP8 = ~ 500 MB KV. عند RDMA 100 GB / ثانية، النقل = 5 ms. عند TCP 10 GB / ثانية = 50 ms. ما الذي يهم ل SLA الخاص بك؟
- تغير توجيه خبراء MoE أنماط وصول KV. كيف تتصرف التقسيم مع MoE التي تنشط خبراء مختلفين لكل رمز؟
الشروط الرئيسية
| Term | What people say | What it actually means |
|---|---|---|
| Disaggregated serving | "split prefill/decode" | Separate GPU pools for each phase |
| NIXL | "NVIDIA transport" | Dynamo's inter-node KV transfer (RDMA/TCP) |
| NVIDIA Dynamo | "the orchestrator" | Stack-above coordinator for vLLM/SGLang/TRT-LLM |
| llm-d | "Kubernetes native" | Red Hat + AWS K8s disaggregated stack |
| Planner Profiler | "Dynamo auto-config" | Measures workload, configures pool ratios |
| SLA Planner | "Dynamo policy" | Auto-rate-matches prefill:decode to meet SLOs |
packDomain: rack | "llm-d topology" | Pack prefill+decode on same rack for fast KV |
| UCCL | "unified collective" | llm-d 0.5 networking layer for scale-to-zero |
| MoE expert routing | "expert per token" | DeepSeek-V3 pattern; disaggregation helps |
المزيد من القراءة
- NVIDIA — Introducing Dynamo
- NVIDIA — Disaggregated LLM Inference on Kubernetes
- TensorRT-LLM Disaggregated Serving blog
- llm-d GitHub
- llm-d 0.5 release notes
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.