Az NVIDIA ellenőrzött Kubernetes-környezetet készített a Dynamohoz

Az NVIDIA AI Cluster Runtime validált receptekkel csomagolja az NVIDIA Dynamo elosztott következtetési keretrendszert és a működéséhez szükséges Kubernetes-infrastruktúrát. A cél egy ismételhető, ellenőrizhető alap biztosítása a GPU-kon futó modellkiszolgáláshoz.
- Az AICR validált receptekben csomagolja az NVIDIA Dynt és Kubernetes-függőségeit.
- A Dynamo-recept 1.4.2-es dynamo-platform chartot tartalmaz.
- A rendszer TCP-t használ a kérésekhez, ZMQ-t a KV-cache eseményeihez.
- A Dynamo két Kuberneteses útválasztási módot támogat.
- Az AICR ötlépéses folyamattal telepíti és ellenőrzi a futtatási környezetet.
A modelltelepítés önmagában nem elég
Az NVIDIA Developer október 30-án ismertette, hogyan lehet a Dynt Kubernetes-környezetben előkészíteni és ellenőrizni az NVIDIA AI Cluster Runtime, röviden AICR segítségével. A Dynamo olyan elosztott következtetési keretrendszer, amely több GPU-s munkafolyamat között hangolja össze a modellek kiszolgálását.
A Kubernetesre telepített modellhez azonban a DynamoGraphDeployment csak a futtatási gráfot írja le. A teljes környezethez illeszkedő GPU-illesztőprogramokra, erőforrás-allokációra, ütemezésre, hálózati konfigurációra és monitorozásra is szükség van. Az NVIDIA szerint ezeknek a függőségeknek a kézi összehangolása időt vehet el a modell viselkedésének, a kiszolgálási teljesítménynek és az alkalmazásintegrációnak a tesztelésétől.
Az AICR ezeket a feltételeket validált receptekben rögzíti. A receptek egy adott környezethez és terheléshez tartozó konfigurációt, rögzített komponensverziókat, kompatibilitási feltételeket és ellenőrzési lépéseket tartalmaznak.
Milyen összetevőket tartalmaz a Dynamo-recept?
Az AICR Dynamo-receptje a Dynamo mellett a klaszter működéséhez szükséges infrastruktúrát is csomagolja. A dynamo-platform chart 1.4.2-es verziója tartalmazza a Dynamo operátort, a Dynamo futtatási képfájljait és az nvidia.com/v1beta1 DynamoGraphDeployment egyéni erőforrás-definíciót. Ez a korábbi v1alpha1 API-verziót váltja.
A GPU-k kezeléséhez a recept az NVIDIA GPU Operatort és a Node Feature Discoveryt használja. A Kubernetes-native Dynamic Resource Allocation, vagyis a DRA révén a GPU-k kioszthatók a munkafolyamatoknak. Az ütemezéshez a KAI Scheduler, az összetett következtetési munkafolyamatok összehangolásához pedig a Grove kapcsolódik.
A csomag része továbbá az NVSentinel és a Nodewright a csomópontok állapotjelzéseihez, ahol ezt a kiválasztott recept támogatja, valamint a Prometheus stack a klaszter-, gyorsító- és Dynamo-metrikák gyűjtéséhez. A Kubernetes Gateway API és az Endpoint Picker Plugin, vagyis az EPP-alapú bejövő forgalomhoz az agentgateway és a Gateway API erőforrásai állnak rendelkezésre.
Az NVIDIA szerint a recept a komponensverziók mellett konfigurációs értékeket, csomópontválasztókat, tolerációkat, ellenőrzőösszegeket és validációs elvárásokat is rögzít. Ez teszi reprodukálhatóbbá a telepítést.
KV-cache alapú útválasztás kétféle módon
A Dynamo 1.4-es verziójától a frontendek, a munkások, az opcionális Gateway API Inference Extension, röviden GAIE, az EPP és más szolgáltatások Kubernetes-erőforrásokon keresztül találják meg egymást. Az AICR alapértelmezett útvonala ezért már nem használ NATS-ot, és a dynamo-platform chart sem telepíti azt alapértelmezés szerint. Azok a telepítések, amelyeknek szükségük van rá, opcionálisan bekapcsolhatják.
A hosszú, ügynökalapú munkamenetekben a rendszerprompt, az eszközleírások, a beszélgetési előzmények és az eszközök eredményei miatt hosszú token-előtagok ismétlődhetnek. Ha ezek nincsenek a kiválasztott munkás GPU-memóriájában, a rendszernek újra kell dolgoznia az előző tokeneket. A Dynamo ezért azokat a munkásokat részesíti előnyben, amelyek már rendelkeznek a megfelelő KV-blokkokkal.
A Dynamo 1.4.2 alapértelmezett AICR Kubernetes-útvonala TCP-t használ a kérések továbbítására, a KV-cache eseményeihez pedig ZMQ-t. A vLLM-munkások helyi ZMQ-kibocsátón keresztül küldik a nyers eseményeket, a Dynamo futtatási környezete pedig normalizálja és továbbítja ezeket a saját eseménysíkjára.
A Kubernetesben két útválasztási lehetőség érhető el. Az első a Dynamo Frontend routere, amely a kérést tokenizálja, majd az előtagok átfedése és az aktuális terhelés alapján választ munkást. Ez a modellhez tartozó saját végpontokhoz illik, és a két megoldás közül ez igényli a legkisebb kiszolgálási topológiát. A frontend egy Kubernetes Service mögött futtatható, a forrás szerint ez a leginkább kipróbált éles kiszolgálási lehetőség.
A második megoldás a Kubernetes Gateway API-t használja a bejövő forgalomhoz, a Dynamo EPP pedig a végpont kiválasztásához. Az AICR mindkét topológiához szállítja és validálja a Dynamo futtatási környezetét.
Ötlépéses telepítési folyamat
Az AICR a futtatási környezet előkészítését elkülöníti az alkalmazás telepítésétől. A folyamat első lépése a klaszter pillanatképének elkészítése, ezt követi a Dynamo következtetési receptjének létrehozása és a telepítési csomag előállítása.
Ezután a runtime Helmfile vagy GitOps segítségével telepíthető. Az utolsó lépés a telepített környezet validálása, még az alkalmazási munkaterhelések telepítése előtt. Így a platformcsapat ellenőrizheti, hogy a GPU-kezelés, az erőforráskiosztás, az ütemezés, a csomópontok állapotjelzései és a metrikagyűjtés megfelelően működik-e.
A fejlesztők ennek eredményeként egységesebb alapot kapnak a modellek kiszolgálásához és az alkalmazások teszteléséhez. Az NVIDIA a Dynamo, az AICR és az NVIDIA DSX AI Factory Slack közösség felfedezését javasolja a további használathoz és gyakorlati műhelymunkákhoz.
NVIDIA Developer: Build a Validated Kubernetes Runtime for NVIDIA Dynamo

