Teljesítmény és késleltetés

Ez a cikk bemutatja, hogyan működik a késés és az átviteli sebesség az Azure OpenAI-val, és hogyan optimalizálhatja a környezetet a teljesítmény javítása érdekében.

Az átviteli sebesség és a késés ismertetése

Az alkalmazások méretezése során két alapvető fogalomra kell gondolni: (1) A rendszerszintű átviteli sebesség percenkénti jogkivonatokban (TPM) és (2) hívásonkénti válaszidőkben (más néven késésben) mérve.

Rendszerszintű átviteli sebesség

Ez az üzemelő példány teljes kapacitását vizsgálja – a percenkénti kérelmek számát és a feldolgozható összes jogkivonatot.

Normál üzemelő példány esetén az üzembe helyezéshez rendelt kvóta részben meghatározza az elérhető átviteli sebességet. A kvóta azonban csak az üzembe helyezésre irányuló hívások belépési logikáját határozza meg, és nem kényszeríti közvetlenül az átviteli sebességet. A hívásonkénti késés eltérései miatt előfordulhat, hogy nem éri el a kvótához hasonló átviteli sebességet. További információ a kvóta kezeléséről.

Kiépített üzembe helyezés esetén a rendszer meghatározott mennyiségű modellfeldolgozási kapacitást foglal le a végponthoz. A végponton elérhető átviteli sebesség a számítási feladat alakzatának tényezője, beleértve a bemeneti jogkivonat mennyiségét, a kimeneti mennyiséget, a hívási sebességet és a gyorsítótár-egyeztetési sebességet. Az egyidejű hívások és a feldolgozott összes jogkivonatok száma ezektől az értékektől függően változhat.

Az összes üzembe helyezési típus esetében a teljesítmény optimalizálásának kulcsfontosságú összetevője a rendszerszintű átviteli sebesség ismerete. Fontos figyelembe venni egy adott modell, verzió és számítási feladat kombinációjának rendszerszintű átviteli sebességét, mivel az átviteli sebesség ezen tényezők között eltérő lesz.

Rendszerszintű átviteli sebesség becslése

A TPM becslése Azure Monitor-metrikákkal

Egy adott számítási feladat rendszerszintű átviteli sebességének becslésére az egyik módszer az előzmény jogkivonatok használati adatainak használata. Az Azure OpenAI számítási feladatai esetében az összes előzményhasználati adat elérhető és megjeleníthető az Azure OpenAI-ban elérhető natív figyelési képességekkel. Az Azure OpenAI-számítási feladatok rendszerszintű átviteli sebességének becsléséhez két metrika szükséges: (1) Feldolgozott parancssori jogkivonatok és (2) generált befejezési jogkivonatok.

Kombinálva a feldolgozott parancssori jogkivonatok (bemeneti TPM) és a generált befejezési jogkivonatok (kimeneti TPM) metrikák a rendszerszintű átviteli sebesség becsült nézetét adják meg a tényleges számítási feladatok forgalma alapján. Ez a megközelítés nem veszi figyelembe a gyors gyorsítótárazás előnyeit, ezért konzervatív rendszerteljesítmény-becslés lesz. Ezek a metrikák egy többhetes időhorizontban minimális, átlagos és maximális összesítéssel elemezhetők 1 perces időszakokon keresztül. Javasoljuk, hogy többhetes időtávon elemezze ezeket az adatokat, hogy elegendő adatpont legyen az értékeléshez. Az alábbi képernyőképen egy példa látható az Azure Monitorban vizualizált feldolgozott parancssori jogkivonatok metrikájára, amely közvetlenül az Azure Portalon érhető el.

A TPM becslése a kérelemadatokból

A rendszerszintű átviteli sebesség becsült értékének második megközelítése a jogkivonat-használati adatok API-kérési adatokból való gyűjtését foglalja magában. Ez a módszer részletesebb megközelítést biztosít a számítási feladatok alakzatának kérésenkénti megértéséhez. A kérésenkénti jogkivonat-használati adatok és a kérésmennyiség percenkénti kérelmekben (RPM) mért egyesítésével megbecsülhető a rendszerszintű átviteli sebesség. Fontos megjegyezni, hogy a jogkivonatok használati információinak a kérések és a kérelemmennyiség közötti konzisztenciájára vonatkozó feltételezések hatással lesznek a rendszer átviteli sebességére vonatkozó becslésre. A jogkivonat-használat kimeneti adatai egy adott Azure OpenAI-szolgáltatás csevegés-befejezési kérésének API-válaszadataiban találhatók.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [...],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Ha egy adott számítási feladatra vonatkozó összes kérés egységes, az API-válaszadatokból származó parancssori jogkivonatok és befejezési jogkivonatok megszorozhatók a becsült RPM-sel az adott számítási feladat bemeneti és kimeneti TPM-jének azonosítása érdekében.

Rendszerszintű átviteli sebesség becsléseinek használata

Miután egy adott számítási feladatra becsülte a rendszerszintű átviteli sebességet, ezek a becslések felhasználhatók a standard és a kiépített üzemelő példányok méretére. Standard üzemelő példányok esetén a bemeneti és kimeneti TPM-értékek kombinálhatók az adott üzemelő példányhoz rendelendő teljes TPM becsléséhez. A kiépített üzemelő példányok esetében a kérelem jogkivonatának használati adatai, illetve a bemeneti és kimeneti TPM-értékek felhasználhatók az adott számítási feladat támogatásához szükséges PTU-k számának becslésére az üzembehelyezési kapacitás kalkulátorának használatával.

Íme néhány példa a GPT-4o minimodellre:

A PTU-k száma nagyjából lineárisan skálázható a hívási sebességgel, ha a számítási feladatok eloszlása állandó marad.

Késés: A hívásonkénti válaszidők

Ebben a kontextusban a késés magas szintű definíciója az az idő, a amennyi a modell válaszának visszakéréséhez szükséges. A befejezési és csevegési befejezési kérelmek esetében a késés nagyban függ a modell típusától, a parancssorban lévő tokenek számától és a létrehozott tokenek számától. Általánosságban elmondható, hogy minden egyes parancssori jogkivonat kevés időt ad a létrehozott növekményes jogkivonatokhoz képest.

Ezekkel a modellekkel nehéz lehet megbecsülni a hívásonkénti várható késést. A befejezési kérelem késése négy elsődleges tényezőtől függően változhat: (1) a modell, (2) a jogkivonatok száma a parancssorban, (3) a létrehozott tokenek száma és (4) az üzembe helyezési & rendszer teljes terhelése. Az egy és a három gyakran a teljes idő fő közreműködői. A következő szakasz részletesen ismerteti a nagy nyelvi modell következtetési hívásának anatómiáját.

A teljesítmény javítása

Számos tényezőt szabályozhat az alkalmazás hívásonkénti késésének javítása érdekében.

A modell kiválasztása

A késés a használt modelltől függően változik. Azonos kérés esetén elvárhatja, hogy a különböző modellek eltérő késéssel rendelkezzenek a csevegés befejezésére irányuló híváshoz. Ha a használati esethez a leggyorsabb válaszidővel rendelkező legalacsonyabb késési modellek szükségesek, javasoljuk a legújabb GPT-4o minimodellt.

Létrehozási méret és maximális jogkivonatok

Amikor befejező kérelmet küld az Azure OpenAI-végpontnak, a bemeneti szöveg jogkivonatokká alakul, amelyeket aztán a rendszer elküld az üzembe helyezett modellnek. A modell megkapja a bemeneti jogkivonatokat, majd megkezdi a válasz előállítását. Ez egy iteratív szekvenciális folyamat, egyszerre egy token. Egy másik módja annak, hogy úgy gondolja, hogy olyan, mint egy hurok a n tokens = n iterations. A legtöbb modell esetében a válasz generálása a folyamat leglassabb lépése.

A kérelem időpontjában a rendszer a kért generációméretet (max_tokens paramétert) használja a generáció méretének kezdeti becsléseként. A teljes méret létrehozásához szükséges számítási időt a modell a kérelem feldolgozásakor lefoglalja. A létrehozás befejezése után a fennmaradó kvóta felszabadul. A jogkivonatok számának csökkentésének módjai:

• Állítsa be a paramétert max_tokens az egyes hívásokon a lehető legkisebbre.
• Állítsa be a leállítási sorozatokat a további tartalom generálásának megakadályozása érdekében.
• Kevesebb válasz létrehozása: A best_of &n paraméterek jelentősen növelhetik a késést, mert több kimenetet hoznak létre. A leggyorsabb válasz érdekében ne adja meg ezeket az értékeket, vagy állítsa őket 1 értékre.

Összefoglalva, a kérésenként létrehozott jogkivonatok számának csökkentése csökkenti az egyes kérések késését.

Streamelés

A kérések beállításával stream: true a szolgáltatás azonnal visszaadja a jogkivonatokat, amint elérhetővé válnak, ahelyett, hogy megvárja a jogkivonatok teljes sorozatának létrehozását. Nem változtatja meg az összes jogkivonat beszerzésének idejét, de csökkenti az első válasz idejét. Ez a megközelítés jobb felhasználói élményt nyújt, mivel a végfelhasználók a generálás során elolvashatják a választ.

A streamelés nagy hívások esetén is hasznos, amelyek feldolgozása hosszú időt vesz igénybe. Számos ügyfél és közvetítő réteg időtúllépést használ az egyes hívásokhoz. Előfordulhat, hogy az ügyféloldali időtúllépések miatt a hosszú generációs hívások megszakadnak. Az adatok visszaküldésével biztosíthatja a növekményes adatok fogadását.

Példák a streamelés használatára:

Csevegőrobotok és beszélgetési felületek.

A streamelés hatással van az észlelt késésre. Ha engedélyezve van a streamelés, a jogkivonatok azonnal vissza lesznek osztva az adattömbökbe, amint elérhetők. A végfelhasználók számára ez a megközelítés gyakran úgy érzi, hogy a modell gyorsabban válaszol, annak ellenére, hogy a kérés teljesítésének teljes ideje változatlan marad.

Példák arra, ha a streamelés kevésbé fontos:

Hangulatelemzés, nyelvfordítás, tartalomgenerálás.

Sok olyan használati eset van, amikor tömeges feladatot hajt végre, ahol csak a kész eredmény érdekli, nem pedig a valós idejű válasz. Ha a streamelés le van tiltva, nem fog jogkivonatokat kapni, amíg a modell nem fejezte be a teljes választ.

Tartalomszűrés

Az Azure OpenAI tartalmaz egy tartalomszűrési rendszert , amely az alapmodellek mellett működik. Ez a rendszer úgy működik, hogy egyszerre futtatja a parancssort és a befejezést egy besorolási modell együttesén keresztül, amelynek célja a káros tartalom kimenetének észlelése és megakadályozása.

A tartalomszűrési rendszer észleli és műveletet hajt végre a potenciálisan káros tartalmak meghatározott kategóriáiban mind a bemeneti kérésekben, mind a kimeneti befejezésekben.

A tartalomszűrés hozzáadása növeli a biztonságot, de a késést is. Sok olyan alkalmazás van, ahol ez a teljesítménybeli kompromisszum szükséges, azonban vannak bizonyos alacsonyabb kockázatú használati esetek, ahol érdemes lehet megvizsgálni a tartalomszűrők letiltását a teljesítmény javítása érdekében.

További információ az alapértelmezett tartalomszűrési szabályzatok módosításának kéréséről.

A számítási feladatok elkülönítése

Ha különböző számítási feladatokat kever ugyanazon a végponton, az negatívan befolyásolhatja a késést. Ennek az az oka, hogy (1) a következtetés során kötegelve vannak, és a rövid hívások hosszabb befejezésekre várhatnak, és (2) a hívások keverése csökkentheti a gyorsítótár találati sebességét, mivel mindketten ugyanazon a helyen versenyeznek. Ha lehetséges, javasoljuk, hogy minden számítási feladathoz külön üzemeljen.

Prompt Size

Bár a parancssori méret kisebb hatással van a késésre, mint a generálási méret, ez befolyásolja a teljes időt, különösen akkor, ha a méret nagy lesz.

Kötegelés

Ha több kérelmet küld ugyanarra a végpontra, a kéréseket egyetlen hívásba kötheti. Ez csökkenti a szükséges kérések számát, és a forgatókönyvtől függően javíthatja az általános válaszidőt. Javasoljuk, hogy tesztelje ezt a módszert, hogy ellenőrizze, segít-e.

Az átviteli sebesség mérése

Javasoljuk, hogy két mértékkel mérje meg az üzemelő példány teljes átviteli sebességét:

• Hívások percenként: A percenként indított API-következtetési hívások száma. Ez az Azure-monitorban mérhető az Azure OpenAI-kérések metrikája és a ModelDeploymentName szerinti felosztás használatával
• Összes jogkivonat percenként: Az üzembe helyezés által percenként feldolgozott tokenek teljes száma. Ide tartoznak a parancssori és a létrehozott jogkivonatok. Ez gyakran tovább oszlik az üzembe helyezési teljesítmény mélyebb megértése érdekében történő mérésre. Ez az Azure-Monitorban a feldolgozott következtetési jogkivonatok metrikával mérhető.

További információ az Azure OpenAI szolgáltatás monitorozásáról.

Hívásonkénti késés mérése

Az egyes hívásokhoz szükséges idő attól függ, hogy mennyi ideig tart a modell olvasása, a kimenet létrehozása és a tartalomszűrők alkalmazása. Az idő mérésének módja eltérő lesz, ha streamelést használ, vagy nem. Minden esetben más-más mértéket javasolunk.

További információ az Azure OpenAI szolgáltatás monitorozásáról.

Nem streamelés:

• Teljes körű kérelemidő: A nem streamelt kérelmek teljes válaszának létrehozásához szükséges teljes idő az API-átjáró által mért módon. Ez a szám a parancssori és a generációs méret növekedésével nő.

Streaming:

• Válaszidő: A streamelési kérelmek javasolt késési (válaszképességi) mértéke. A PTU és a PTU által felügyelt üzemelő példányokra vonatkozik. Az API-átjáró által mért idő, amely alatt az első válasz megjelenik, miután a felhasználó egy kérést küld. Ez a szám a kérés méretének növekedésével és/vagy a találatok méretének csökkentésével nő.
• Átlagos jogkivonat-létrehozási idő az első jogkivonattól az utolsó jogkivonatig, osztva a létrehozott jogkivonatok számával az API-átjáró által mért értékekkel. Ez méri a válaszlétrehozás sebességét, és a rendszer terhelésének növekedésével együtt nő. A streamelési kérelmekhez javasolt késési mérték.

Összegzés

• Modell késése: Ha a modell késése fontos Önnek, javasoljuk, hogy próbálja ki a GPT-4o minimodellt.

• Alacsonyabb maximális jogkivonatok: Az OpenAI azt észlelte, hogy még azokban az esetekben is, amikor a létrehozott tokenek teljes száma hasonló, a maximális tokenparaméterhez beállított magasabb értékkel rendelkező kérés nagyobb késéssel fog rendelkezni.

• Alacsonyabb összes létrehozott jogkivonat: Minél kevesebb jogkivonat jön létre, annál gyorsabb lesz a teljes válasz. Ne feledje, hogy ez olyan, mint egy hurok a n tokens = n iterations. Csökkentse a generált tokenek számát, és az általános válaszidő ennek megfelelően javulni fog.

• Streamelés: A streamelés engedélyezése hasznos lehet a felhasználói elvárások bizonyos helyzetekben történő kezeléséhez azáltal, hogy lehetővé teszi a felhasználó számára a modellre adott válasz megjelenítését ahelyett, hogy várnia kellene az utolsó jogkivonat elkészültéig.

• A tartalomszűrés javítja a biztonságot, de hatással van a késésre is. Értékelje ki, hogy valamelyik számítási feladatnak hasznát venné-e a módosított tartalomszűrési szabályzat.