A Red Hat AI egy GPU-n gyorsítja a prémium kéréseket
A Red Hat AI 3.5 prioritásalapú kiszolgálása közös GPU-készleten kezeli a chatbotok, a kötegelt feladatok és az ügynöki munkafolyamatok forgalmát. A Red Hat tesztjeiben a prémium kérések 95 százaléka fél másodpercen belül megkapta az első tokent NVIDIA H100 GPU-n, miközben a kötegelt kérések elutasítása 48 224-ről nullára csökkent.
- A Red Hat AI 3.5-ben általánosan elérhető a prioritásalapú kiszolgálás.
- A megoldás közös GPU-készleten kezeli az interaktív és kötegelt forgalmat.
- A Red Hat tesztjében a kötegelt kérések elutasítása 48 224-ről nullára csökkent.
- Az llm-d flow control a prioritás, a bérlő és a telítettség alapján állítja sorba a kéréseket.
- Hosszú válaszoknál a rendszer nem garantál teljes védelmet a prémium késleltetésnek.
Egy modell, eltérő teljesítményigények
A Red Hat október 20-án ismertetett megoldása arra épül, hogy ugyanaz a GPU-készlet többféle munkát szolgálhat ki. Egyetlen modellen futhat ügyfél-chatbot, dokumentumösszegző kötegelt feldolgozás, ügynöki RAG-munkafolyamat és belső copilot. Ezek teljesítményigénye azonban eltérő.
A chatbotnál az első token megjelenési ideje fontos, a kötegelt feldolgozásnál inkább az elvégzett munka és a költség számít. Egy ügynöki folyamat hosszabb ideig várhat, majd egyszerre több láncot indíthat. Ha a közös készlet minden kérést azonosan kezel, egy forgalmi csúcsban a kötegelt feladatok feltarthatják az interaktív kéréseket. A korábbi megközelítés külön GPU-készleteket méretezett minden munkatípus csúcsforgalmára, így az egyes készletek tartalék kapacitását nem lehetett egymás között megosztani.
A prioritást az llm-d flow control kezeli
A Red Hat AI 3.5-ben általánosan elérhető funkció az llm-d flow control rétegre épül. Az alkalmazásoknak nem kell új végpontot használniuk. Az üzemeltető egy Kubernetes InferenceObjective erőforrásban állítja be a munkaterhelések prioritását, a készlet telítettségi küszöbét és a méltányossági szabályt.
A kapu a hívó hitelesítő adatai alapján minden kérést prioritással és bérlővel lát el. Telítettség esetén először a legmagasabb prioritási sáv várakozó kérései következnek. Azonos sávon belül a rendszer váltogat a bérlők között, egy bérlő kiugró forgalma így nem szorítja ki a többieket. Egy bérlő sorában az érkezési sorrend érvényesül. A küszöb alatt a szabad kapacitást a rendszer nem tartja vissza.
Kevesebb elutasítás, kiszámíthatóbb várakozás
A Red Hat által közölt H100-as tesztben négy szint, Platinum, Gold, Silver és Bronze, közösen szolgálta a gpt-oss-20b modellt. Az új, konkurenciaszám-alapú érzékelővel a prémium, valós idejű kérések első tokenig mért ideje 364, illetve 430 milliszekundum volt, a Silver szinté 699 milliszekundum, a kötegelt Bronze munkaterhelésé pedig 3,0 másodperc.
A korábbi, kihasználtság-alapú érzékelővel ugyanezek az értékek 1,3, 1,5, 2,0 és 2,7 másodpercet tettek ki. A Red Hat szerint kötegelt forgalmi roham esetén flow control nélkül három futás alatt 48 224 darab 429-es, vagyis túl sok kérés hiba keletkezett. A prioritásalapú kezelésnél nem volt elutasítás, a kötegelt kérések sorba álltak és kivárták a sorukat.
A vállalat más GPU-kon is tesztelt. Négy NVIDIA A100 használatakor a prémium kérések első tokenig mért ideje minden vizsgált helyzetben 2,1 és 2,8 másodperc között maradt, miközben az alacsonyabb prioritású szint viselte a várakozást. Három prémium bérlő tesztjében az egyik 82 kéréses másodpercenkénti rohamánál a két visszafogottabb bérlő várakozási ideje körülbelül 17 milliszekundum maradt, a nagy forgalmú bérlőé 45 milliszekundum volt.
A megosztás csökkentheti a tartalék kapacitást
A Red Hat példája szerint három külön készlet, egyenként nyolc GPU-val és napi átlagosan 30 százalékos kihasználtsággal, összesen 24 GPU-t köt le nagyjából hét GPU-nyi munka elvégzésére. Közös készletben az alacsony prioritású kötegelt feladat kitöltheti az interaktív munkák által szabadon hagyott kapacitást, majd forgalmi csúcs idején várakozhat.
A módszer különösen akkor lehet releváns, ha interaktív és kötegelt munkák futnak ugyanazon a modellen, több csapat vagy ügyfél osztozik egy készleten, illetve több szolgáltatási szint használja ugyanazokat a GPU-kat. A Red Hat szerint ha minden forgalom azonos típusú, vagy a készlet soha nem telítődik, nincs szükség prioritásalapú kiszolgálásra. A szigorú prioritás miatt a tartós prémium terhelés hosszabb ideig visszatarthatja a kötegelt munkát. Több ezer tokenes válaszoknál a vezérlés már nem tud teljes védelmet adni a prémium késleltetésnek, ezért az ilyen ügynöki és gondolkodási munkafolyamatokat külön kell tesztelni.
