Disaggregation Is a Thousand-GPU Problem
🇬🇧 English
Every major inference framework shipped prefill-decode disaggregation this year. NVIDIA built it into Dynamo. SGLang made it the default for large-scale deployments. v LLM added a KV connector API to support it natively.
The consensus is forming fast: split your prefill and decode onto separate GPU pools, and throughput improves. The consensus is wrong for most teams. Doubleword's analysis shows that a balanced disaggregated deployment matches colocated throughput, but at small GPU counts the rounding losses dominate: you can't allocate fractional GPUs, so the specialization gains get eaten by incomplete worker utilization.
The practical benefit at that scale is independent SLO tuning, not throughput. A June 2025 study evaluating hundreds of thousands of design points found that disaggregation is most effective for prefill-heavy traffic patterns and larger models. For the mixed-traffic workloads most teams actually run, queueing and inter-node KV cache transfer dominated end-to-end latency.
The teams that disaggregated moved the bottleneck. They didn't remove it. I ran into this on an inference workload serving a mid-size classification model.
TPOT spiked under bursty traffic, and the first instinct was to separate prefill from decode. Instead, I enabled chunked prefill on the same GPU pool. TPOT stabilized.
The problem was scheduling interference, and chunked prefill handled it without adding a network hop. Chunked prefill breaks long prefill requests into smaller chunks and interleaves them with decode batches on the same GPU. No separate node pools.
No KV cache transfer over the network. No P: D ratio to tune. TNG Technology Consulting measured a 50 percent increase in total token throughput using standard v LLM with chunked prefill enabled.
The decode batches still ran between prefill chunks on the same hardware, but the scheduling interference dropped to a level most production workloads can tolerate. For workloads below roughly 50 requests per second with moderate prompt lengths, that bound is tight enough.
🇸🇦 العربية
التفكيك مشكلة ألف وحدة معالجة رسومات: متى يعمل
أطلقت كل أطر الاستدلال الرئيسية تفكيك التعبئة المسبقة والفك هذا العام. قامت NVIDIA ببنائه في Dynamo. جعلته SGLang الافتراضي للنشر واسع النطاق. أضافت v LLM واجهة برمجة تطبيقات لموصل KV لدعمه أصليًا. يتشكل الإجماع بسرعة: قسّم التعبئة المسبقة والفك على مجموعات GPU منفصلة، ويتحسن الإنتاجية. هذا الإجماع خاطئ لمعظم الفرق. يظهر تحليل Doubleword أن النشر المفكك المتوازن يطابق الإنتاجية المشتركة، ولكن مع أعداد صغيرة من وحدات GPU تهيمن خسائر التقريب: لا يمكنك تخصيص وحدات GPU كسور، لذا تُلتهم مكاسب التخصص بسبب الاستخدام غير الكامل للعمال. الفائدة العملية على هذا النطاق هي ضبط SLO المستقل، وليس الإنتاجية. وجدت دراسة يونيو 2025 التي قيمت مئات الآلاف من نقاط التصميم أن التفكيك أكثر فعالية لأنماط حركة المرور الثقيلة بالتعبئة المسبقة والنماذج الأكبر. بالنسبة لأحمال العمل المختلطة التي تشغلها معظم الفرق فعليًا، سيطرت قائمة الانتظار ونقل ذاكرة التخزين المؤقت KV بين العقد على زمن الوصول من طرف إلى طرف. الفرق التي فككت نقلت عنق الزجاجة. لم تزله. واجهت هذا في حمل عمل استدلال يخدم نموذج تصنيف متوسط الحجم. ارتفع TPOT تحت حركة المرور المتدفقة، وكان الغريزة الأولى هي فصل التعبئة المسبقة عن الفك. بدلاً من ذلك، قمت بتمكين التعبئة المسبقة المقسمة على نفس مجموعة GPU. استقر TPOT. كانت المشكلة هي تداخل الجدولة، وتعاملت التعبئة المسبقة المقسمة معها دون إضافة قفزة شبكة. تقسم التعبئة المسبقة المقسمة طلبات التعبئة المسبقة الطويلة إلى أجزاء أصغر وتقحمها مع دفعات الفك على نفس وحدة GPU. لا مجموعات عقد منفصلة. لا نقل ذاكرة التخزين المؤقت KV عبر الشبكة. لا نسبة P:D لضبطها. قاست TNG Technology Consulting زيادة بنسبة 50 في المائة في إجمالي إنتاجية الرموز باستخدام v LLM القياسية مع تمكين التعبئة المسبقة المقسمة. لا تزال دفعات الفك تعمل بين أجزاء التعبئة المسبقة على نفس الأجهزة، لكن تداخل الجدولة انخفض إلى مستوى يمكن لمعظم أحمال عمل الإنتاج تحمله. بالنسبة لأحمال العمل التي تقل عن حوالي 50 طلبًا في الثانية بأطوال مطالبات معتدلة، فإن هذا الحد ضيق بما يكفي.
متى يكون تفكيك التعبئة المسبقة والفك مفيدًا؟
التفكيك أكثر فعالية لأنماط حركة المرور الثقيلة بالتعبئة المسبقة والنماذج الأكبر والنشر بمئات وحدات GPU. بالنسبة لأحمال العمل المختلطة على نطاقات أصغر، غالبًا ما تتجاوز تكلفة قائمة الانتظار ونقل ذاكرة التخزين المؤقت KV مكاسب الإنتاجية.
🇧🇩 বাংলা
ডিসঅ্যাগ্রিগেশন একটি হাজার-GPU সমস্যা: এটি কখন কাজ করে
প্রতিটি প্রধান ইনফারেন্স ফ্রেমওয়ার্ক এই বছর প্রিফিল-ডিকোড ডিসঅ্যাগ্রিগেশন প্রকাশ করেছে। NVIDIA এটি Dynamo-তে নির্মাণ করেছে। SGLang এটি বৃহৎ পরিসরের স্থাপনার জন্য ডিফল্ট করেছে। v LLM এটি নেটিভভাবে সমর্থন করার জন্য একটি KV সংযোগকারী API যুক্ত করেছে। ঐকমত্য দ্রুত গঠিত হচ্ছে: আপনার প্রিফিল এবং ডিকোডকে পৃথক GPU পুলে বিভক্ত করুন, এবং থ্রুপুট উন্নত হবে। এই ঐকমত্যটি বেশিরভাগ দলের জন্য ভুল। Doubleword-এর বিশ্লেষণ দেখায় যে একটি ভারসাম্যপূর্ণ ডিসঅ্যাগ্রিগেটেড স্থাপনা কো-লোকেটেড থ্রুপুটের সাথে মেলে, কিন্তু ছোট GPU গণনার ক্ষেত্রে রাউন্ডিং ক্ষতিগুলি আধিপত্য করে: আপনি ভগ্নাংশ GPU বরাদ্দ করতে পারবেন না, তাই বিশেষীকরণ লাভগুলি অসম্পূর্ণ কর্মী ব্যবহার দ্বারা গ্রাস করা হয়। সেই স্কেলে ব্যবহারিক সুবিধা হল স্বাধীন SLO টিউনিং, থ্রুপুট নয়। ২০২৫ সালের জুনের একটি গবেষণায় লক্ষ লক্ষ ডিজাইন পয়েন্ট মূল্যায়ন করে পাওয়া গেছে যে ডিসঅ্যাগ্রিগেশন প্রিফিল-ভারী ট্রাফিক প্যাটার্ন এবং বৃহত্তর মডেলগুলির জন্য সবচেয়ে কার্যকর। বেশিরভাগ দল যে মিশ্র-ট্রাফিক ওয়ার্কলোডগুলি আসলে চালায়, সেগুলির জন্য সারি এবং ইন্টার-নোড KV ক্যাশ স্থানান্তর এন্ড-টু-এন্ড লেটেন্সির উপর আধিপত্য করেছে। যে দলগুলি ডিসঅ্যাগ্রিগেট করেছে সেগুলি বাধাটি স্থানান্তরিত করেছে। তারা এটি সরায়নি। আমি একটি মধ্যম আকারের শ্রেণীবিভাজন মডেল পরিবেশনকারী একটি ইনফারেন্স ওয়ার্কলোডে এটির মুখোমুখি হয়েছি। বার্স্টি ট্রাফিকের অধীনে TPOT বেড়ে গেছে, এবং প্রথম প্রবৃত্তি ছিল প্রিফিলকে ডিকোড থেকে আলাদা করা। পরিবর্তে, আমি একই GPU পুলে চাঙ্কড প্রিফিল সক্ষম করেছি। TPOT স্থিতিশীল হয়েছে। সমস্যাটি ছিল সিডিউলিং হস্তক্ষেপ, এবং চাঙ্কড প্রিফিল একটি নেটওয়ার্ক হপ যোগ না করেই এটি পরিচালনা করেছে। চাঙ্কড প্রিফিল দীর্ঘ প্রিফিল অনুরোধগুলিকে ছোট টুকরোতে ভাগ করে এবং সেগুলিকে একই GPU-তে ডিকোড ব্যাচের সাথে ইন্টারলিভ করে। কোনো পৃথক নোড পুল নেই। নেটওয়ার্কের মাধ্যমে কোনো KV ক্যাশ স্থানান্তর নেই। টিউন করার জন্য কোনো P:D অনুপাত নেই। TNG Technology Consulting চাঙ্কড প্রিফিল সক্ষম সহ মানক v LLM ব্যবহার করে মোট টোকেন থ্রুপুটে ৫০ শতাংশ বৃদ্ধি পরিমাপ করেছে। ডিকোড ব্যাচগুলি এখনও একই হার্ডওয়্যারে প্রিফিল টুকরোগুলির মধ্যে চলছিল, কিন্তু সিডিউলিং হস্তক্ষেপ একটি স্তরে নেমে গেছে যা বেশিরভাগ প্রোডাকশন ওয়ার্কলোড সহ্য করতে পারে। প্রায় ৫০ অনুরোধ প্রতি সেকেন্ডের নিচে এবং মাঝারি প্রম্পট দৈর্ঘ্যের সাথে ওয়ার্কলোডগুলির জন্য, সেই সীমাটি যথেষ্ট টাইট।
প্রিফিল-ডিকোড ডিসঅ্যাগ্রিগেশন কখন উপকারী?
ডিসঅ্যাগ্রিগেশন প্রিফিল-ভারী ট্রাফিক প্যাটার্ন, বৃহত্তর মডেল এবং শত শত GPU সহ স্থাপনার জন্য সবচেয়ে কার্যকর। ছোট স্কেলে মিশ্র-ট্রাফিক ওয়ার্কলোডগুলির জন্য, সারি এবং KV ক্যাশ স্থানান্তর ওভারহেড প্রায়ই থ্রুপুট লাভকে ছাড়িয়ে যায়।
🇩🇪 Deutsch
Disaggregation ist ein Problem mit tausend GPUs: Wann es funktioniert
Jedes große Inferenz-Framework hat dieses Jahr Prefill-Decode-Disaggregation ausgeliefert. NVIDIA hat es in Dynamo integriert. SGLang hat es zum Standard für groß angelegte Bereitstellungen gemacht. v LLM hat eine KV-Connector-API zur nativen Unterstützung hinzugefügt.
Der Konsens bildet sich schnell: Teilen Sie Ihren Prefill und Decode auf separate GPU-Pools auf, und der Durchsatz verbessert sich. Dieser Konsens ist für die meisten Teams falsch. Doublewords Analyse zeigt, dass eine ausgewogene disaggregierte Bereitstellung den colokierten Durchsatz erreicht, aber bei kleinen GPU-Anzahlen dominieren die Rundungsverluste: Sie können keine gebrochenen GPUs zuweisen, sodass die Spezialisierungsgewinne durch unvollständige Worker-Auslastung aufgezehrt werden.
Der praktische Nutzen in diesem Maßstab ist die unabhängige SLO-Optimierung, nicht der Durchsatz. Eine Studie vom Juni 2025, die Hunderttausende von Designpunkten bewertete, fand heraus, dass Disaggregation für prefill-lastige Verkehrsmuster und größere Modelle am effektivsten ist. Für die Mixed-Traffic-Workloads, die die meisten Teams tatsächlich ausführen, dominierten Queuing und KV-Cache-Transfer zwischen Knoten die End-to-End-Latenz.
Die Teams, die disaggregierten, haben den Flaschenhals verschoben. Sie haben ihn nicht beseitigt. Ich bin bei einer Inferenz-Workload, die ein mittelgroßes Klassifikationsmodell bediente, darauf gestoßen.
TPOT stieg unter Burst-Traffic, und der erste Instinkt war, Prefill von Decode zu trennen. Stattdessen aktivierte ich Chunked Prefill auf demselben GPU-Pool. TPOT stabilisierte sich.
Das Problem war Scheduling-Interferenz, und Chunked Prefill hat es ohne einen zusätzlichen Netzwerk-Hop gehandhabt. Chunked Prefill zerlegt lange Prefill-Anfragen in kleinere Chunks und verschachtelt sie mit Decode-Batches auf derselben GPU. Keine separaten Knoten-Pools.
Kein KV-Cache-Transfer über das Netzwerk. Kein P:D-Verhältnis zu optimieren. TNG Technology Consulting maß eine 50-prozentige Steigerung des gesamten Token-Durchsatzes mit Standard-v LLM und aktiviertem Chunked Prefill.
Die Decode-Batches liefen weiterhin zwischen Prefill-Chunks auf derselben Hardware, aber die Scheduling-Interferenz fiel auf ein Niveau, das die meisten Produktions-Workloads tolerieren können. Für Workloads unterhalb von etwa 50 Anfragen pro Sekunde mit moderaten Prompt-Längen ist diese Grenze eng genug.
Wann ist Prefill-Decode-Disaggregation vorteilhaft?
Disaggregation ist am effektivsten für prefill-lastige Verkehrsmuster, größere Modelle und Bereitstellungen mit Hunderten von GPUs. Für Mixed-Traffic-Workloads in kleineren Maßstäben überwiegen oft die Queuing- und KV-Cache-Transfer-Overheads die Durchsatzgewinne.
🇪🇸 Español
La desagregación es un problema de mil GPUs: cuándo funciona
Cada framework de inferencia importante envió desagregación prefill-decode este año. NVIDIA la integró en Dynamo. SGLang la hizo predeterminada para despliegues a gran escala. v LLM añadió una API de conector KV para soportarla nativamente.
El consenso se está formando rápidamente: divide tu prefill y decode en pools de GPU separados, y el throughput mejora. El consenso es incorrecto para la mayoría de los equipos. El análisis de Doubleword muestra que un despliegue desagregado equilibrado iguala el throughput colocalizado, pero con recuentos pequeños de GPU las pérdidas por redondeo dominan: no puedes asignar GPUs fraccionarias, por lo que las ganancias de especialización son consumidas por la utilización incompleta de los workers.
El beneficio práctico a esa escala es el ajuste independiente de SLO, no el throughput. Un estudio de junio de 2025 que evaluó cientos de miles de puntos de diseño encontró que la desagregación es más efectiva para patrones de tráfico intensivos en prefill y modelos más grandes. Para las cargas de tráfico mixto que la mayoría de los equipos ejecutan realmente, la cola y la transferencia de caché KV entre nodos dominaron la latencia de extremo a extremo.
Los equipos que desagregaron movieron el cuello de botella. No lo eliminaron. Me encontré con esto en una carga de trabajo de inferencia que servía un modelo de clasificación de tamaño mediano.
El TPOT se disparó bajo tráfico en ráfagas, y el primer instinto fue separar el prefill del decode. En su lugar, habilité el prefill fragmentado en el mismo pool de GPU. El TPOT se estabilizó.
El problema era la interferencia de programación, y el prefill fragmentado lo manejó sin añadir un salto de red. El prefill fragmentado divide las solicitudes de prefill largas en fragmentos más pequeños y los intercala con lotes de decode en la misma GPU. Sin pools de nodos separados.
Sin transferencia de caché KV por la red. Sin proporción P:D que ajustar. TNG Technology Consulting midió un aumento del 50 por ciento en el throughput total de tokens usando v LLM estándar con prefill fragmentado habilitado.
Los lotes de decode todavía se ejecutaron entre fragmentos de prefill en el mismo hardware, pero la interferencia de programación cayó a un nivel que la mayoría de las cargas de trabajo de producción pueden tolerar. Para cargas de trabajo por debajo de aproximadamente 50 solicitudes por segundo con longitudes de prompt moderadas, ese límite es lo suficientemente ajustado.
¿Cuándo es beneficiosa la desagregación prefill-decode?
La desagregación es más efectiva para patrones de tráfico intensivos en prefill, modelos más grandes y despliegues con cientos de GPUs. Para cargas de tráfico mixto a escalas más pequeñas, la sobrecarga de cola y transferencia de caché KV a menudo supera las ganancias de throughput.
🇫🇷 Français
La désagrégation est un problème de mille GPU : quand ça marche
Chaque framework d'inférence majeur a livré la désagrégation prefill-decode cette année. NVIDIA l'a intégré dans Dynamo. SGLang l'a rendu par défaut pour les déploiements à grande échelle. v LLM a ajouté une API de connecteur KV pour le prendre en charge nativement.
Le consensus se forme rapidement : séparez votre prefill et votre decode sur des pools de GPU distincts, et le débit s'améliore. Le consensus est faux pour la plupart des équipes. L'analyse de Doubleword montre qu'un déploiement désagrégé équilibré correspond au débit colocalisé, mais avec de petits nombres de GPU, les pertes d'arrondi dominent : vous ne pouvez pas allouer des GPU fractionnels, donc les gains de spécialisation sont consommés par une utilisation incomplète des workers.
L'avantage pratique à cette échelle est le réglage indépendant des SLO, pas le débit. Une étude de juin 2025 évaluant des centaines de milliers de points de conception a révélé que la désagrégation est plus efficace pour les modèles de trafic lourds en prefill et les modèles plus grands. Pour les charges de travail à trafic mixte que la plupart des équipes exécutent réellement, la file d'attente et le transfert de cache KV entre nœuds ont dominé la latence de bout en bout.
Les équipes qui ont désagrégé ont déplacé le goulot d'étranglement. Ils ne l'ont pas éliminé. J'ai rencontré cela sur une charge de travail d'inférence servant un modèle de classification de taille moyenne.
Le TPOT a augmenté sous un trafic en rafale, et le premier instinct a été de séparer le prefill du decode. Au lieu de cela, j'ai activé le prefill fragmenté sur le même pool de GPU. Le TPOT s'est stabilisé.
Le problème était l'interférence de planification, et le prefill fragmenté l'a géré sans ajouter de saut réseau. Le prefill fragmenté divise les longues requêtes de prefill en morceaux plus petits et les entrelace avec les lots de decode sur le même GPU. Pas de pools de nœuds séparés.
Pas de transfert de cache KV sur le réseau. Pas de ratio P:D à régler. TNG Technology Consulting a mesuré une augmentation de 50 pour cent du débit total de tokens en utilisant v LLM standard avec prefill fragmenté activé.
Les lots de decode continuaient de s'exécuter entre les morceaux de prefill sur le même matériel, mais l'interférence de planification est tombée à un niveau que la plupart des charges de travail de production peuvent tolérer. Pour les charges de travail inférieures à environ 50 requêtes par seconde avec des longueurs de prompt modérées, cette borne est suffisamment stricte.
Quand la désagrégation prefill-decode est-elle bénéfique ?
La désagrégation est plus efficace pour les modèles de trafic lourds en prefill, les modèles plus grands et les déploiements avec des centaines de GPU. Pour les charges de travail à trafic mixte à plus petite échelle, la file d'attente et la surcharge de transfert de cache KV l'emportent souvent sur les gains de débit.
🇮🇳 हिन्दी
डिसअग्रीगेशन एक हजार-GPU समस्या है: यह कब काम करता है
हर प्रमुख इंफरेंस फ्रेमवर्क ने इस वर्ष प्रीफिल-डिकोड डिसअग्रीगेशन जारी किया। NVIDIA ने इसे Dynamo में बनाया। SGLang ने इसे बड़े पैमाने पर तैनाती के लिए डिफ़ॉल्ट बनाया। v LLM ने इसे मूल रूप से समर्थन देने के लिए KV कनेक्टर API जोड़ा। आम सहमति तेजी से बन रही है: अपने प्रीफिल और डिकोड को अलग GPU पूल पर विभाजित करें, और थ्रूपुट में सुधार होगा। यह आम सहमति अधिकांश टीमों के लिए गलत है। Doubleword का विश्लेषण दिखाता है कि एक संतुलित डिसअग्रीगेटेड तैनाती को-लोकेटेड थ्रूपुट से मेल खाती है, लेकिन छोटी GPU संख्या पर राउंडिंग हानि हावी होती है: आप आंशिक GPU आवंटित नहीं कर सकते, इसलिए विशेषज्ञता लाभ अपूर्ण वर्कर उपयोग से खा जाते हैं। उस पैमाने पर व्यावहारिक लाभ स्वतंत्र SLO ट्यूनिंग है, थ्रूपुट नहीं। जून 2025 के एक अध्ययन ने लाखों डिज़ाइन बिंदुओं का मूल्यांकन करते हुए पाया कि डिसअग्रीगेशन प्रीफिल-भारी ट्रैफ़िक पैटर्न और बड़े मॉडलों के लिए सबसे प्रभावी है। अधिकांश टीमें जो वास्तव में मिश्रित-ट्रैफ़िक वर्कलोड चलाती हैं, उनके लिए कतारबद्धि और इंटर-नोड KV कैश ट्रांसफर ने एंड-टू-एंड विलंबता पर हावी किया। जिन टीमों ने डिसअग्रीगेशन किया, उन्होंने बाधा को स्थानांतरित कर दिया। उन्होंने इसे हटाया नहीं। मुझे यह एक इंफरेंस वर्कलोड पर मिला जो एक मध्यम आकार के वर्गीकरण मॉडल की सेवा कर रहा था। बर्स्टी ट्रैफ़िक के तहत TPOT बढ़ गया, और पहली प्रवृत्ति प्रीफिल को डिकोड से अलग करना था। इसके बजाय, मैंने उसी GPU पूल पर चंक्ड प्रीफिल सक्षम किया। TPOT स्थिर हो गया। समस्या शेड्यूलिंग हस्तक्षेप थी, और चंक्ड प्रीफिल ने बिना नेटवर्क हॉप जोड़े इसे संभाला। चंक्ड प्रीफिल लंबे प्रीफिल अनुरोधों को छोटे टुकड़ों में तोड़ता है और उन्हें उसी GPU पर डिकोड बैचों के साथ इंटरलीव करता है। कोई अलग नोड पूल नहीं। नेटवर्क पर कोई KV कैश ट्रांसफर नहीं। ट्यून करने के लिए कोई P:D अनुपात नहीं। TNG Technology Consulting ने चंक्ड प्रीफिल सक्षम चंक्ड प्रीफिल के साथ मानक v LLM का उपयोग करके कुल टोकन थ्रूपुट में 50 प्रतिशत की वृद्धि मापी। डिकोड बैच अभी भी उसी हार्डवेयर पर प्रीफिल टुकड़ों के बीच चलते थे, लेकिन शेड्यूलिंग हस्तक्षेप एक स्तर पर गिर गया जिसे अधिकांश प्रोडक्शन वर्कलोड सहन कर सकते हैं। लगभग 50 अनुरोध प्रति सेकंड से नीचे और मध्यम प्रॉम्प्ट लंबाई वाले वर्कलोड के लिए, वह सीमित पर्याप्त रूप से कसी हुई है।
प्रीफिल-डिकोड डिसअग्रीगेशन कब लाभकारी है?
डिसअग्रीगेशन प्रीफिल-भारी ट्रैफ़िक पैटर्न, बड़े मॉडलों और सैकड़ों GPU वाली तैनाती के लिए सबसे प्रभावी है। छोटे पैमाने पर मिश्रित-ट्रैफ़िक वर्कलोड के लिए, कतारबद्धि और KV कैश ट्रांसफर ओवरहेड अक्सर थ्रूपुट लाभ से अधिक होते हैं।
🇮🇩 Bahasa Indonesia
Disagregasi adalah Masalah Seribu GPU: Kapan Ini Berfungsi
Setiap kerangka inferensi utama merilis disagregasi prefill-decode tahun ini. NVIDIA membangunnya ke dalam Dynamo. SGLang menjadikannya default untuk penyebaran skala besar. v LLM menambahkan API konektor KV untuk mendukungnya secara native.
Konsensus terbentuk dengan cepat: pisahkan prefill dan decode Anda ke dalam pool GPU terpisah, dan throughput meningkat. Konsensus ini salah untuk sebagian besar tim. Analisis Doubleword menunjukkan bahwa penyebaran terdisagregasi yang seimbang cocok dengan throughput colokasi, tetapi pada jumlah GPU kecil kerugian pembulatan mendominasi: Anda tidak dapat mengalokasikan GPU fraksional, sehingga keuntungan spesialisasi dimakan oleh pemanfaatan pekerja yang tidak lengkap.
Manfaat praktis pada skala itu adalah penyetelan SLO independen, bukan throughput. Studi Juni 2025 yang mengevaluasi ratusan ribu titik desain menemukan bahwa disagregasi paling efektif untuk pola lalu lintas yang berat prefill dan model yang lebih besar. Untuk beban kerja lalu lintas campuran yang sebenarnya dijalankan oleh sebagian besar tim, antrian dan transfer cache KV antar node mendominasi latensi end-to-end.
Tim yang melakukan disagregasi memindahkan hambatan. Mereka tidak menghilangkannya. Saya menemui ini pada beban kerja inferensi yang melayani model klasifikasi berukuran sedang.
TPOT melonjak di bawah lalu lintas bursty, dan insting pertama adalah memisahkan prefill dari decode. Sebagai gantinya, saya mengaktifkan chunked prefill pada pool GPU yang sama. TPOT stabil.
Masalahnya adalah interferensi penjadwalan, dan chunked prefill menanganinya tanpa menambah hop jaringan. Chunked prefill memecah permintaan prefill yang panjang menjadi potongan-potongan yang lebih kecil dan menyelipkannya di antara batch decode pada GPU yang sama. Tidak ada pool node terpisah.
Tidak ada transfer cache KV melalui jaringan. Tidak ada rasio P:D untuk disetel. TNG Technology Consulting mengukur peningkatan 50 persen dalam throughput token total menggunakan v LLM standar dengan chunked prefill diaktifkan.
Batch decode masih berjalan di antara potongan prefill pada perangkat keras yang sama, tetapi interferensi penjadwalan turun ke tingkat yang dapat ditoleransi oleh sebagian besar beban kerja produksi. Untuk beban kerja di bawah kira-kira 50 permintaan per detik dengan panjang prompt sedang, batas itu cukup ketat.
Kapan disagregasi prefill-decode bermanfaat?
Disagregasi paling efektif untuk pola lalu lintas yang berat prefill, model yang lebih besar, dan penyebaran dengan ratusan GPU. Untuk beban kerja lalu lintas campuran pada skala yang lebih kecil, overhead antrian dan transfer cache KV sering kali melebihi keuntungan throughput.
🇯🇵 日本語
ディスアグリゲーションは千GPUの問題:いつ機能するか
主要な推論フレームワークはすべて今年プレフィル・デコードディスアグリゲーションを出荷した。NVIDIAはそれをDynamoに組み込んだ。SGLangは大規模デプロイメントのデフォルトにした。v LLMはネイティブにサポートするためのKVコネクタAPIを追加した。コンセンサスは急速に形成されている:プレフィルとデコードを別々のGPUプールに分割すれば、スループットが向上する。このコンセンサスはほとんどのチームにとって間違っている。Doublewordの分析は、バランスの取れたディスアグリゲートされたデプロイメントがコロケーションのスループットに匹敵することを示しているが、GPU数が少ない場合、丸め損失が支配的になる:分数のGPUを割り当てることはできないため、特殊化の利益は不完全なワーカー利用率に食い潰される。そのスケールでの実用的な利益はスループットではなく、独立したSLOチューニングである。数十万の設計ポイントを評価した2025年6月の研究で、ディスアグリゲーションはプレフィル中心のトラフィックパターンとより大きなモデルに最も効果的であることが分かった。ほとんどのチームが実際に実行する混合トラフィックのワークロードでは、キューイングとノード間KVキャッシュ転送がエンドツーエンドのレイテンシを支配していた。ディスアグリゲーションを採用したチームはボトルネックを移動させた。それを取り除いたのではない。私は中規模の分類モデルを提供する推論ワークロードでこれに遭遇した。バーストトラフィック下でTPOTが急増し、最初の直感はプレフィルをデコードから分離することだった。代わりに、同じGPUプールでチャンク化プレフィルを有効にした。TPOTは安定した。問題はスケジューリング干渉であり、チャンク化プレフィルはネットワークホップを追加せずにそれを処理した。チャンク化プレフィルは長いプレフィルリクエストをより小さなチャンクに分割し、同じGPU上のデコードバッチとインターリーブする。別のノードプールはない。ネットワーク経由のKVキャッシュ転送はない。チューニングするP:D比率はない。TNG Technology Consultingは、チャンク化プレフィルを有効にした標準のv LLMを使用して、総トークンスループットの50%増加を測定した。デコードバッチは同じハードウェア上のプレフィルチャンク間でまだ実行されていたが、スケジューリング干渉はほとんどの本番ワークロードが許容できるレベルに低下した。プロンプト長が中程度で1秒あたり約50リクエスト以下のワークロードでは、その境界は十分にタイトである。
プレフィル・デコードディスアグリゲーションはいつ有益ですか?
ディスアグリゲーションはプレフィル中心のトラフィックパターン、より大きなモデル、および数百のGPUを持つデプロイメントに最も効果的です。より小規模な混合トラフィックワークロードでは、キューイングとKVキャッシュ転送のオーバーヘッドがスループットの利益を上回ることがよくあります。
🇧🇷 Português
Desagregação é um problema de mil GPUs: quando funciona
Toda grande estrutura de inferência lançou desagregação prefill-decode este ano. A NVIDIA a integrou no Dynamo. A SGLang a tornou o padrão para implantações em grande escala.
A v LLM adicionou uma API de conector KV para suportá-la nativamente. O consenso está se formando rapidamente: divida seu prefill e decode em pools de GPU separados, e a taxa de transferência melhora. O consenso está errado para a maioria das equipes.
A análise da Doubleword mostra que uma implantação desagregada equilibrada corresponde à taxa de transferência colocalizada, mas com pequenas contagens de GPU as perdas de arredondamento dominam: você não pode alocar GPUs fracionários, então os ganhos de especialização são consumidos pela utilização incompleta dos workers. O benefício prático nessa escala é o ajuste independente de SLO, não a taxa de transferência. Um estudo de junho de 2025 avaliando centenas de milhares de pontos de design descobriu que a desagregação é mais eficaz para padrões de tráfego pesados em prefill e modelos maiores.
Para as cargas de trabalho de tráfego misto que a maioria das equipes realmente executa, o enfileiramento e a transferência de cache KV entre nós dominaram a latência de ponta a ponta. As equipes que desagregaram moveram o gargalo. Elas não o removeram.
Eu me deparei com isso em uma carga de trabalho de inferência servindo um modelo de classificação de médio porte. O TPOT disparou sob tráfego em rajadas, e o primeiro instinto foi separar o prefill do decode. Em vez disso, ativei o prefill em pedaços no mesmo pool de GPUs.
O TPOT se estabilizou. O problema era interferência de agendamento, e o prefill em pedaços lidou com isso sem adicionar um salto de rede. O prefill em pedaços divide requisições longas de prefill em pedaços menores e os intercala com lotes de decode na mesma GPU.
Sem pools de nós separados. Sem transferência de cache KV pela rede. Sem proporção P:D para ajustar.
A TNG Technology Consulting mediu um aumento de 50 por cento na taxa de transferência total de tokens usando v LLM padrão com prefill em pedaços ativado. Os lotes de decode ainda eram executados entre pedaços de prefill no mesmo hardware, mas a interferência de agendamento caiu para um nível que a maioria das cargas de trabalho de produção pode tolerar. Para cargas de trabalho abaixo de aproximadamente 50 requisições por segundo com comprimentos de prompt moderados, esse limite é suficientemente restrito.
Quando a desagregação prefill-decode é benéfica?
A desagregação é mais eficaz para padrões de tráfego pesados em prefill, modelos maiores e implantações com centenas de GPUs. Para cargas de trabalho de tráfego misto em escalas menores, a sobrecarga de enfileiramento e transferência de cache KV muitas vezes supera os ganhos de taxa de transferência.
🇷🇺 Русский
Дезагрегация — это задача для тысячи GPU: когда она работает
Каждый основной фреймворк вывода выпустил дезагрегацию prefill-decode в этом году. NVIDIA встроила её в Dynamo. SGLang сделала её стандартом для крупномасштабных развёртываний. v LLM добавила API KV-коннектора для нативной поддержки. Консенсус формируется быстро: разделите prefill и decode на отдельные пулы GPU, и пропускная способность улучшится. Этот консенсус ошибочен для большинства команд. Анализ Doubleword показывает, что сбалансированное дезагрегированное развёртывание соответствует пропускной способности при совместном размещении, но при небольших количествах GPU потери округления доминируют: вы не можете выделить дробные GPU, поэтому выигрыш от специализации поглощается неполной утилизацией воркеров. Практическая выгода при таком масштабе — независимая настройка SLO, а не пропускная способность. Исследование июня 2025 года, оценившее сотни тысяч точек проектирования, показало, что дезагрегация наиболее эффективна для трафика с тяжёлым prefill и более крупных моделей. Для смешанного трафика, который большинство команд фактически запускают, очереди и межузловая передача кэша KV доминировали в сквозной задержке. Команды, которые внедрили дезагрегацию, переместили узкое место. Они не устранили его. Я столкнулся с этим в рабочей нагрузке вывода, обслуживающей модель классификации среднего размера.
TPOT резко возрос при пульсирующем трафике, и первым побуждением было разделить prefill и decode. Вместо этого я включил chunked prefill в том же пуле GPU. TPOT стабилизировался. Проблемой была интерференция планирования, и chunked prefill решил её без добавления сетевого перехода. Chunked prefill разбивает длинные запросы prefill на более мелкие фрагменты и чередует их с пакетами decode на том же GPU. Никаких отдельных пулов узлов. Никакой передачи кэша KV по сети. Никакого соотношения P:D для настройки.
TNG Technology Consulting измерила 50-процентное увеличение общей пропускной способности токенов при использовании стандартного v LLM с включённым chunked prefill. Пакеты decode по-прежнему выполнялись между фрагментами prefill на том же оборудовании, но интерференция планирования снизилась до уровня, который большинство рабочих нагрузок в продакшене могут tolerate. Для рабочих нагрузок ниже примерно 50 запросов в секунду с умеренной длиной промптов эта граница достаточно тесная.
Когда дезагрегация prefill-decode выгодна?
Дезагрегация наиболее эффективна для трафика с тяжёлым prefill, более крупных моделей и развёртываний с сотнями GPU. Для смешанного трафика в меньших масштабах накладные расходы очереди и передачи кэша KV часто превышают выигрыш в пропускной способности.
🇨🇳 简体中文
解耦是一个千GPU级别的问题:它何时有效
今年,每个主要推理框架都推出了预填充-解码解耦。NVIDIA将其内置于Dynamo中。SGLang将其作为大规模部署的默认选项。v LLM添加了KV连接器API以原生支持它。共识正在快速形成:将预填充和解码拆分到不同的GPU池上,吞吐量就会提升。这个共识对大多数团队来说是错误的。Doubleword的分析表明,平衡的解耦部署可以匹配同置部署的吞吐量,但在GPU数量较少时,舍入损失占主导地位:你无法分配分数个GPU,因此专业化增益被不完整的工作器利用率所吞噬。在这种规模下的实际好处是独立的SLO调优,而不是吞吐量。2025年6月一项评估了数十万个设计点的研究发现,解耦对于预填充密集型流量模式和较大模型最为有效。对于大多数团队实际运行的混合流量工作负载,排队和节点间KV缓存传输主导了端到端延迟。那些采用解耦的团队只是转移了瓶颈。他们并没有消除它。我在一个服务于中型分类模型的推理工作负载上遇到了这个问题。在突发流量下TPOT飙升,第一反应是将预填充与解码分离。相反,我在同一个GPU池上启用了分块预填充。TPOT稳定了。问题在于调度干扰,而分块预填充在不增加网络跳数的情况下解决了它。分块预填充将长预填充请求分解为更小的块,并将它们与同一GPU上的解码批次交错执行。没有单独的节点池。没有通过网络进行KV缓存传输。没有需要调优的P:D比例。TNG Technology Consulting测量到,在标准v LLM上启用分块预填充后,总令牌吞吐量增加了50%。解码批次仍然在同一硬件上的预填充块之间运行,但调度干扰降低到了大多数生产工作负载可以容忍的水平。对于每秒大约50个请求以下、提示长度适中的工作负载,这个界限已经足够紧凑。
预填充-解码解耦何时有益?
解耦对于预填充密集型流量模式、较大模型以及拥有数百个GPU的部署最为有效。对于较小规模的混合流量工作负载,排队和KV缓存传输开销通常超过吞吐量增益。