Encode‑Prefill‑Decode diszaggregálás: mikor gyorsítja a multimodális modellek kiállítását

Az Encode‑Prefill‑Decode (EPD) diszaggregálás egy olyan inferencia‑optimalizációs technika multimodális modellekhez, amely szétválasztja a látás‑enkóder (encode) szakaszt az LLM prefill és decode szakaszaitól. Ez akkor hoz előnyt, ha a kérések képeket vagy videót tartalmaznak, a kimenet rövid‑közepes hosszúságú, illetve a modell MoE vagy kvantizált. A bemutatott mérések szerint az NVIDIA Dynamoval kombinálva EPD akár 5× gyorsabb TTFT‑et (time to first token) és 7× gyorsabb end‑to‑end válaszidőt eredményezhet bizonyos terhelési minták mellett.

Dynamo egy nyílt forrású inferencia‑keretrendszer elosztott környezetekhez, amely támogatja az EPD diszaggregálást: az enkóder és a PD (prefill+decode) munkafolyamatokat külön skálázható szakaszokra bontja. Dedikált enkóder‑worker‑ök jobb batchelést, memóriakitöltést és áteresztőképességet tesznek lehetővé.

Az aggregált és az EPD kiszolgálás közti különbség

Aggregált kiszolgálásnál ugyanaz a worker végzi a média előfeldolgozást, a ViT‑forwardt és az LLM prefill+decode‑ot. Ha a médiafeldolgozás aránya alacsony, ez egyszerű és jól működő felépítés. Ha azonban a kérések több képet vagy videót tartalmaznak, a ViT előfeldolgozása több száz milliszekundumot is igénybe vehet. Mivel az enkóder és az LLM ugyanazon GPU‑n osztozik, egy média‑nehéz kérés késleltetheti a saját prefilljét és versenyezhet más prefill/decode munkákkal. Kevert forgalom esetén a szöveg‑only kérések is várakozhatnak multimodális kérések miatt, még ha nem is igényelnek vision enkódolást.

Dynamo EPD implementációja külön kezeli az enkóder és a PD worker szerepköröket; az enkóder workerök látás‑beágyazásokat (embeddings) állítanak elő, amelyeket NIXL (NVIDIA Inference Transfer Library) használatával továbbítanak a PD workeröknek. Ez lehetővé teszi a független batchelést, skálázást és ütemezést.

Három enkóder‑elhelyezési topológia

• Aggregált: minden GPU egyetlen aggregált workert futtat, amely kezel minden fázist ugyanabban a scheduling domainben.
• Colocated enkóder: egy GPU‑n egy vagy több enkóder worker fut egy PD worker mellett. A GPU erőforrást megosztva külön sorokkal és batch‑szabályozással jobb kihasználtság érhető el egy homogén klaszterben; a látásmodell viszonylag könnyű, így dedikált GPU az enkódernek alulhasználttá válhat.
• Disaggregated (heterogén) enkóder: az enkóder munkát egy alacsonyabb költségű GPU‑rétegen futtatják (pl. RTX 6000D), míg a PD workerök a nagyobb GB200 GPU‑kon mennek. Az enkóder‑tier NIXL‑lel továbbítja az embeddingeket a PD‑tier felé. A vizsgálat nem foglalkozott homogén, disaggregált megoldással, mert az általában alulmaradt a colocated topológiával.

A hardver elérhetősége és a munka jellegzetessége határozza meg, hogy érdemes‑e külön enkóderre áttérni.

Mely tényezők határozzák meg az EPD előnyeit?

Az EPD hatékonysága attól függ, hogyan oszlik meg a munka a ViT forward, LLM prefill és decode között. Az EPD akkor a leghasznosabb, ha a vision enkódolás számottevő részt képvisel a kérés feldolgozási idejéből:

• Input média‑terhelés: több kép, nagyobb felbontás vagy videó több vizuális tokennel jelentősen növeli az enkóder munkát. Ilyenkor az enkóder skálázása megakadályozhatja az enkóder‑szűk keresztmetszetet.
• Output sequence length (OSL): hosszú kimeneteknél a decode idő dominál, így bár a TTFT javulhat, az end‑to‑end javulás csökken.
• Modell mérete / precizitás: a ViT számítása viszonylag állandó, míg az LLM számítása csökken kisebb vagy kvantizált modelleknél. Kis, MoE és alacsony precizitású modellek nagyobb arányban profitálnak.
• Kevert forgalom: ha szöveg és multimodális kérések keverednek, az EPD megakadályozza, hogy a text-only kérések a ViT‑feldolgozásra várjanak.

A jó teljesítményjavulás csak akkor jön létre, ha az enkóder munkamennyisége elég nagy ahhoz, hogy kompenzálja a worker‑koordináció és embedding‑átvitel overheadjét.

Mérések és tesztkörnyezet

A mérési eredmények túlnyomó része Qwen3.5 122B A10B NVFP4 modellel készült, kivéve a precizitás‑ablációkat. Hardverként négy NVIDIA GB200 GPU‑t használtak, és disaggregált esetben további RTX 6000D GPU‑kat az enkóder réteghez. Átviteli rétegként NIXL‑t futtattak UCX RC/TCP Ethernet felett, csúcs 20 Gbps méréssel. A Dynamo frontendnél engedélyezték a párhuzamos média‑dekódolást. A jóput SLO inter‑token latency (ITL) < 100 ms volt.

Kép‑nehéz példa

10 kép/kérés (képenként max 256 token), OSL 1024 beállítással a következőket tapasztalták:

• Colocated enkóder: TTFT 58%‑kal csökkent az aggregálthoz képest.
• Heterogén (disaggregated) enkóder: TTFT 50%‑kal csökkent.

Az end‑to‑end javulás mérsékelt volt, mert OSL 1024 esetén a decode idő jelentősen hozzájárul a teljes késleltetéshez, amit az enkóder szétválasztása nem rövidít meg. A heterogén topológia ugyanakkor 70%‑kal több forgalmat tudott kiszolgálni azonos latency SLO mellett, mert enkóder‑kapacitást adtak hozzá anélkül, hogy a GB200‑erőforrást növelték volna.

Kép‑terhelés és OSL hatása

5–50 kép közötti vizsgálatoknál (kép × token költség megtartva) az aggregált beállításnál a TTFT és az end‑to‑end késleltetés erősen romlott a vizuális tokenek növekedésével, míg mindkét EPD topológia teljesítménye viszonylag stabil maradt. OSL‑t változtatva (128–2048) öt kép mellett: a TTFT nagyrészt változatlan maradt, de a decode dominanciája miatt az end‑to‑end javulás csökkent; a heterogén EPD előnye 20.3%‑ról 5.2%‑ra szűkült, a colocated EPD pedig nagy OSL mellett akár teljesítmény‑regressziót mutatott (például 5×128 képnél OSL 2048 esetén −2.5%).

Modellméret és precizitás hatása

Model‑méret abláció Qwen3.5 4B, 9B és 27B konfigurációkon: a ViT paraméteraránya csökkent 7.2%‑ról (4B) 4.7%‑ra (9B) és 1.7%‑ra (27B). A colocated EPD ugyanakkor a következő same‑SLO goodput arányokat érte el az aggregálthoz képest: 2.62× (4B), 1.50× (9B) és 0.65× (27B). Tehát nagyobb, sűrű modelleknél az EPD haszna csökken, és egy ponton már nem éri meg.

A precizitás hatását mérve: amikor a ViT és az LLM is BF16‑on futott, a colocated EPD 1.78× goodputot adott az aggregálthoz képest; az aktív LLM‑súlyok NVFP4‑re kvantálása után ez az arány 2.64×‑re nőtt. Az NVFP4 felgyorsítja az LLM prefillt és decode‑ot, míg a ViT BF16 maradt, így az enkóder arányosan nagyobb részt képvisel a teljes futásidőben — ami több lehetőséget ad az EPD‑nek.

Kevert forgalom

Sok termelési környezetben vegyes a forgalom (szöveg + multimodális). Aggregált esetben egy batchben multimodális kérés jelenléte miatt minden prefill workernek előbb a média előfeldolgozást és ViT forwardot kell végrehajtania, így a text‑only kérések is várhatnak. EPD esetén az enkódolás külön poolban fut; a frontend a prefill workerökhöz irányítja a kéréseket, de csak a multimodális kérés indít enkóder hívást, így a text‑only kérések megkezdhetik a prefillt várakozás nélkül.

Mérés 50:50 vegyes forgalomnál, OSL 128 mellett, aggregated vs colocated EPD:

• Text‑kérések átlagos TTFT: 92.3 ms → 53.3 ms (42.2% csökkenés).
• Kép‑kérések átlagos TTFT: 289.9 ms → 200.6 ms (30.8% csökkenés).

A text‑kérések jobban profitálnak, mert az enkóder által okozott head‑of‑line blokkolás eltűnik.

Mikor válasszuk melyik topológiát?

• Ha a vision enkódolás jelentős részt tesz ki (sok kép, rövid‑közepes kimenet, kis vagy kvantizált modellek, kevert forgalom), akkor EPD általában előnyös.
• Ha a média feldolgozás könnyű vagy nagyon hosszú dekódolások dominálnak, az aggregált kiszolgálás maradhat jobb választás.
• Homogén klaszterben a colocated enkóder gyakran jobb, mert nem kell külön GPU‑t fenntartani az enkóder munkának. Heterogén hardver esetén érdemes külön enkóder‑tier (alacsonyabb költségű GPUkon) futtatni.

Megjegyzés: vLLM és SGLang roadmapjai is tartalmaznak EPD‑támogatás fejlesztéseket.

Kiegészítő Dynamo‑lehetőségek az EPD mellett

• Párhuzamos média‑dekódolás (--frontend‑decoding): a media letöltést és dekódolást a frontend végzi, csökkentve az enkóder latencyt. Egy enkóder‑only benchmarkon 30×256 beállítással egy GB200‑on két encode workerrel az átlagos enkóder‑kérés késleltetése 281.3 ms‑ról 207.0 ms‑re csökkent (‑26%), P99: 752.1 ms → 581.7 ms (‑23%).
• Embedding cache: a kiszámolt embeddingeket CPU DRAM‑ban tárolja, így ismétlődő média nem kerül újra enkódolásra.
• Multimodális KV routing: a média tartalmat is hashelve a router olyan workerökre irányítja a kéréseket, amelyek már rendelkeznek a releváns KV blokkokkal.

Összegzés

EPD diszaggregálás erőteljes eszköz lehet multimodális inferencia szolgálásakor, különösen kép‑nehéz forgalom, rövid‑közepes kimenet és kisebb/kvantizált modellek esetén. A konkrét előnyök azonban függnek az input média‑terheléstől, OSL‑tól, modellmérettől, kvantizációtól és a rendelkezésre álló hardvertől. A Dynamo tesztekben példáként 10 kép/kérés és OSL 1024 esetén TTFT‑csökkenés 50–58% volt, kevert forgalomnál a text‑kérések TTFT‑je 42.2%‑kal javult, és a heterogén réteg 70%‑kal nagyobb goodputot tett lehetővé azonos SLO mellett. A döntésnél érdemes mérlegelni az enkóder‑átviteli overheadet és a decode‑idő dominanciáját; további optimalizációk (frontend decoding, embedding cache, KV routing) együttesen csökkenthetik a teljes pipeline idejét.

Köszönetnyilvánítás

Köszönet Roger Wang (Inferact) visszajelzéseiért, valamint az NVIDIA csapatának: Alexandre Milesi, Ayush Agarwal, Guan Luo, Indrajit Bhosale, J Wyman, Kris Hung, Krishnan Prashanth, Qi Wang és Zhongdao Ren munkájáért a Dynamo multimodalitás‑támogatás fejlesztésében.