A gyakorlati tapasztalat szerint egy kiképzett neurális háló deployolása nem csupán az egyes operátorok GPU-kernelre fordítása: ez egy kompilációs feladat, ahol több, egymással összefüggő döntés határozza meg a végeredményt. Az NVIDIA TensorRT motorépítésekor egyszerre kell meghozni döntéseket a gráf-IR transzformációkról, fusionről, implementációválasztásról, memória-elhelyezésről és kvantálásról — ezt a folyamatot schedulingnek nevezik. Különböző scheduling választások megőrizhetik a modell szemantikáját, ugyanakkor nagyon eltérő inferencia‑teljesítményt adhatnak, ezért a scheduling központi szerepet játszik a deep learning kompilerek optimalizációjában.
Miért nem elég egyetlen, univerzális stratégia?
Nincs olyan egyetemes scheduling-stratégia, amely minden modellre és telepítési környezetre optimális lenne. Egyes transzformációk vagy kernelek, amelyek egy hálózatot gyorsítanak, egy másikat lassíthatnak; egy lokálisan gyors kernel rosszul léphet kölcsönhatásba fusionnel, tenzorelrendezéssel vagy a graf egészére gyakorolt memóriatrafikkal. Aggresszív optimalizációk, például csökkentett pontosságú (reduced-precision) kernelek jobb throughputot adhatnak, de veszélyeztethetik az alkalmazás által elvárt numerikus pontosságot.
Ezek a hatások gyakran csak a teljes engine felépítése és mérése után válnak nyilvánvalóvá, így a helyes stratégia előrejelzése egyre nehezebb.
Motiváció: a séf analógia
A szerzők egy analógiával érzékeltetik a problémát: egy séfnek van egy remek alapreceptje, amely három törzsvendégnek megfelel (különböző fűszerezési preferenciákkal). Ha érkezik egy negyedik vendég, akinek más az ízpreferenciája, a fix receptrendszer vagy csalódást okoz, vagy az egyik vendégnek rontja az élményt. A skálázható megoldás az, hogy az alapételt megtartják, de a fűszerezés konfigurálható, és az új vendégnek kóstolóvariánsokat kínálnak, majd megtartják a számára megfelelőt.
Ezt lefordítva a fordító‑kompilálásra: TensorRT a séf, a megosztott pipeline az alaprecept, a konfigurálható fordítóbeállítások a fűszerek, és az elkészült engine a kész étel. Minden ONNX vagy más frontend-model (például PyTorch) egy-egy vendégnek felel meg; a teljesítményhangolás a kóstoltatás, az end-to-end teljesítmény pedig a vendég elégedettsége.
A heuristikák korlátai és a három problémás forma
Hagyományosan a TensorRT belső KPI‑modellekből származó heuristikákat épít be az alap scheduling‑be: mérnökök azonosítanak gyorsítható mintázatokat, és ezek alapján szabályokat kódolnak. Ahogy a modellek és a hardverkörnyezetek sokszínűsége nő, ez a megközelítés skálázódási problémába ütközik. A jellegzetes hibák:
- Heurisztika‑burjánzás: minden új modell‑specifikus szabály növeli a kölcsönhatások számát, a kód karbantartása nehezebb lesz, és egy javítás egyik modellcsaládnál regressziót okozhat másoknál.
- Teljesítmény–pontosság összefonódás: csökkentett pontosságú optimizációk gyorsabbak lehetnek, de numerikus eltérések léphetnek fel, amelyek meghaladják az alkalmazás tűréshatárát; magasabb precizitás gyakran lassabb.
- Teljesítmény testreszabhatósága: ami egy modell‑GPU párosnál jól működik, egy másiknál rosszabb lehet; minden sikeres választ univerzálissá alakítani nehézkes.
Ezekre a korlátokra a tuning nyújthat skálázható kiegészítést.
Absztrakt matematikai modell — mi adható és hogyan választhatunk
A poszt részletesen felépít egy formális modellt a fordító teljesítményéről, hogy elválasszon két alapvető kérdést: milyen executabléket képes a fordító létrehozni egy modellhez, és hogyan választ ezek közül a legjobbat.
- Modell és modell‑tér: legyen m egy modell, M a vizsgált modellek halmaza. A modell lehet ONNX gráf, TensorRT API‑ból létrehozott háló vagy PyTorch frontend — bármilyen olyan reprezentáció, amely meghatározza a számítást.
- Megoldás és megoldás‑tér: egy adott modell különböző schedulingok mellett különböző megoldásokat (s) eredményezhet; ezek halmaza legyen S. Egy megoldás lehet maga a TensorRT engine vagy egy sor GPU kernelből álló bináris.
- Determinizmus elve: ha a determinisztikus program és a teljes végrehajtási környezet rögzített, akkor a lefutási idő is meghatározott (a valós méréseknél zaj jelenik meg, amit gyakran gausszi zajként modelleznek; a sokszori mérés átlaga a rejtett középérték maximum‑likelihood becslése).
- Lefutási idő függvény: legyen T : S → R+ egy függvény, amely minden megoldáshoz hozzárendeli a jellemző futási időt adott környezetben.
A poszt két algoritmikus szereplőt vezet be:
- Builder algoritmus B: a modellből kiindulva egy megengedett megoldáshalmazt állít elő, amely kielégíti az alkalmazás által megadott pontossági tűrést (ε). Formálisan B : M → 2^S, és ideális esetben a B(m) halmaz tartalmazza az optimális, leggyorsabb megoldást s*‑t.
- Searching algoritmus A: a kandidátushalmazból kiválaszt egy megoldást, A : 2^S → S; ideálisan A kiválasztja a legkisebb T(s)‑t.
A valóságban a keresőal algoritmusok nem mindig optimálisak két okból: egyrészt heurisztikák megszűrhetnek potenciálisan jó taktikákat még a teljes motorépítés előtt, másrészt a lokális kernelprofilozás és a teljes engine‑es futtatás környezetében eltérések lehetnek (például NVIDIA Blackwell GPU‑k adaptív grid méretezése miatt), így a külön‑külön mért kernelidők összege nem feltétlenül adja vissza az end‑to‑end futási időt.
A (A,B) párt tekinthetjük a kompilátor megvalósításának — ahol B a build route, A pedig a kiválasztó algoritmus. Bár egy bruteforce A* elméletben képes lenne mindig megtalálni az optimális s*‑t az adott kandidátushalmazból, a gyakorlatban az építési idő és költség miatt kompromisszumokra lehet szükség.
A Global Performance Tuner (GPT): testreszabható build utak és pontosságtudatos keresés
A TensorRT 11.1‑ben bevezetett Global Performance Tuner (GPT) kiindulópontja az, hogy a build route‑ok legyenek konfigurálhatók. Ahelyett, hogy egyetlen fix útvonalból próbálnának mindent megoldani (ami heurisztika‑burjánzáshoz vezet), a rendszer több alternatív build route‑ot kínál:
- Pontosságtudatos hangolás: az end‑to‑end numerikus elfogadhatóságot (a referencia‑kimenettel és egy ε tűréssel összehasonlítva) korlátozásként alkalmazza a teljesítmény‑keresés során.
- Testreszabható build route: a fordítási útvonal paraméterezhető, hogy a scheduling döntések igazodjanak az adott modellhez és telepítési környezethez.
- Nagy megoldás‑tér: a cél egy gazdag, megvalósítható megoldáshalmaz felépítése, majd a leggyorsabb, az ε‑tartományba eső megoldás kiválasztása.
Formálisan a GPT egy build‑útvonal családot ℬ = {B1, B2, …, Bn} hoz létre, és a keresőalgoritmus a különböző route‑ok unionjából választja ki a legkisebb futási idővel rendelkező, pontossági feltételeknek megfelelő s*‑t:
s* = A(B1(m) ∪ B2(m) ∪ … ∪ Bn(m))
Így a GPT a korábbi, fix‑heurisztikás megközelítést kiegészíti: nem próbál minden sikeres beállítást beépíteni egyetlen univerzális stratégiába, hanem bővíti az elérhető build útvonalakat és mérésen alapuló, pontosságtudatos kiválasztást végez.
Következtetések és továbblépés
A Global Performance Tuner koncepciója a poszt szerint a scheduling problémát két szinten oldja meg: (1) a builder‑t teszi testreszabhatóvá úgy, hogy különböző build route‑okat ad a rendszerhez, és (2) a keresést az end‑to‑end pontossági feltételre és mért futási időre alapozza. Ez a megközelítés csökkenti a heurisztikák burjánzásából és a teljesítmény–pontosság összefonódásából fakadó problémákat, és skálázhatóbb módon teszi lehetővé TensorRT testreszabását sokféle modellre és hardverre.
A poszt második része ígérete szerint az algoritmus és architektúra részletes tervezését, valamint a használati javaslatokat ismerteti; a dokumentáció további gyakorlati részleteket tartalmaz a Global Performance Tuner használatához.
(Használt fogalmak: ONNX, PyTorch, NVIDIA TensorRT, TensorRT 11.1, NVIDIA Blackwell GPU.)
