Az AWS két GPU-csomóponton futtatná a nagy nyelvi modellek inferenciáját

Külön GPU kapja az előfeldolgozást és a generálást

Az AWS 2026. október 12-én közzétett bemutatója szerint a Ray LLM Deep Learning Containerrel egy nagy nyelvi modell két GPU-alapú csomóponton szolgálható ki az Amazon Elastic Kubernetes Service, vagyis az Amazon EKS segítségével. Az egyik csomópont a prefill fázist végzi, amely a teljes bemeneti promptot feldolgozza és felépíti a kulcsérték-gyorsítótárat, a másik pedig a decode fázisban tokenenként állítja elő a választ.

A két fázis szétválasztása azért lehet hasznos, mert eltérő hardveres jellemzőket igényelnek. A prefill számításigényes, míg a decode elsősorban a memória-sávszélességtől függ. Ha ugyanazon a GPU-n futnak, a hosszú promptok feldolgozása zavarhatja a már folyamatban lévő válaszok generálását. A külön csomópontokra helyezett fázisok egymástól függetlenül skálázhatók.

Előre összeállított AWS-konténer a teljes inferenciás veremhez

Az AWS Deep Learning Containers előre elkészített, teljesítményre optimalizált Docker-képek. A vállalat ezekben egyesíti a keretrendszert, annak függőségeit és a GPU-szoftveres környezetet, majd a kiadás előtt együtt ellenőrzi az összetevőket. Az AWS szerint ezzel csökkenthető annak szükségessége, hogy a felhasználóknak maguknak kelljen összeállítaniuk a kompatibilis függőségi láncot és hibakeresniük a verzióeltéréseket.

A Ray LLM DLC a többcsomópontos nyelvimodell-kiszolgálást célozza. Az inferenciamotorként a vLLM-et, a kiszolgálási réteghez a Ray Serve HTTP-funkcióját, a kulcsérték-gyorsítótár csomópontok közötti továbbításához pedig az NVIDIA Inference Transfer Libraryt, vagyis a NIXL-t tartalmazza. A nagy sávszélességű kommunikációhoz az Elastic Fabric Adapter, az EFA veremét használja, benne a libfabric és az aws-ofi-nccl összetevőkkel.

A beépített alkalmazásépítőnek köszönhetően a teljes kiszolgálóalkalmazás YAML-konfigurációként adható meg. A build_pd_openai_app segéd a prefill és a decode beállításait összeköti, és egy OpenAI-kompatibilis végpont mögé helyezi őket. Az AWS bemutatója szerint ehhez nem kell kezelőosztályt, modellarchívumot vagy egyedi konténert készíteni.

Amazon EKS, Ray és EFA egy közös architektúrában

A bemutatott telepítés egy VPC-ben futó EKS-fürtöt használ, privát alhálózatokkal és NAT Gatewayen keresztüli kimenő hozzáféréssel. Egy CPU-alapú m7i.xlarge rendszer-csomópont futtatja a rendszerfeladatokat, a KubeRay operátort és a Ray head podot. Két g6.8xlarge GPU-csomópont szolgálja ki a Ray munkafolyamatait, külön a prefill és a decode fázist.

A KubeRay figyeli az alkalmazott RayService-erőforrást, és automatikusan összeköti a headet a munkacsomópontokkal. A Ray Serve a két GPU-csomóponton helyezi el a megfelelő telepítéseket. A prefill során létrejövő kulcsérték-gyorsítótár NIXL-en keresztül jut el a decode csomópontjára, az EFA libfabric-alapú háttérprogramját használva.

A GPU-csomópontokat egyetlen Availability Zone-ra kell korlátozni, mert az EFA nem képes Availability Zone-ok között működni. A példához AWS-fiók, legalább két g6.8xlarge példányhoz elegendő kvóta, valamint az AWS CLI, a kubectl, az eksctl, a Helm és az envsubst szükséges.

Mit jelent ez a felhasználóknak?

A megoldás azoknak a feladatoknak lehet releváns, amelyeknél egy modell túl nagy egyetlen GPU számára, egy példány teljesítménye nem elegendő, vagy a kiszolgálás két fázisát külön szeretnék kezelni. Az AWS példái között szerepel a visszakereséssel bővített generálás, a dokumentum-összefoglalás és az ügynökalapú alkalmazások.

A szétválasztásnak van egy technikai feltétele: a prefill során felépített gyorsítótárat gyorsan kell átadni a decode csomópontnak, különben az adatátvitel csökkentheti az elérhető előnyt. A Ray LLM DLC ezt az átvitelt NIXL-lel és EFA-val kezeli, miközben az alkalmazás egyetlen OpenAI-kompatibilis végponton keresztül érhető el.