Mi a kiosztott átviteli sebesség?

Feljegyzés

Az Azure OpenAI kiépített ajánlata 2024. augusztus 12-én jelentős frissítéseket kapott, beleértve a vásárlási modell Azure-szabványokhoz való igazítását és a modellfüggetlen kvótára való áttérést. Erősen ajánlott, hogy a dátum előtt előkészített ügyfelek olvassák el az Azure OpenAI által kiépített augusztusi frissítést , hogy többet tudjanak meg ezekről a változásokról.

A kiosztott átviteli sebesség lehetővé teszi az üzembe helyezéshez szükséges átviteli sebesség megadását. A szolgáltatás ezután lefoglalja a szükséges modellfeldolgozási kapacitást, és biztosítja, hogy készen áll az Ön számára. Az átviteli sebesség a kiosztott átviteli egységek (PTU) szempontjából van definiálva, amely az üzembe helyezés átviteli sebességének normalizált módja. Az egyes modellverzió-párok üzembe helyezéséhez és PTU-nként eltérő átviteli sebesség biztosításához különböző mennyiségű PTU szükséges.

Mit biztosít a kiépített üzembehelyezési típus?

• Kiszámítható teljesítmény: stabil maximális késés és átviteli sebesség egységes számítási feladatokhoz.
• Fenntartott feldolgozási kapacitás: Az üzembe helyezés konfigurálja az átviteli sebesség mennyiségét. Az üzembe helyezés után az átviteli sebesség elérhető, függetlenül attól, hogy használatban van-e.
• Költségmegtakarítás: A nagy átviteli sebességű számítási feladatok költségmegtakarítást és jogkivonatalapú használatot biztosíthatnak.

Az Azure OpenAI-üzemelő példány egy adott OpenAI-modell felügyeleti egysége. Az üzembe helyezés lehetővé teszi az ügyfelek számára a modellhez való hozzáférést a következtetéshez, és további funkciókat integrál, például a tartalommoderálást (lásd a con sátormód ration dokumentációját).

Mi lesz az eredmény?

Téma	Kiépítve
Mi ez?	Garantált átviteli sebességet biztosít a meglévő kiosztott ajánlatnál kisebb lépésekben. Az üzemelő példányok konzisztens maximális késéssel rendelkeznek egy adott modellverzió esetében.
Kinek szól?	Azok az ügyfelek, akik minimális késési eltéréssel szeretnék garantálni az átviteli sebességet.
Kvóta	Kiépített felügyelt átviteli egységek egy adott modellhez.
Késés	A modellből korlátozott maximális késés. Az általános késés a hívás alakzatának tényezője.
Kihasználtság	Az Azure Monitorban megadott kiépített felügyelt kihasználtsági mérték.
Méret becslése	A studio & benchmarking szkriptben megadott kalkulátor.

Milyen modellek és régiók érhetők el a kiosztott átviteli sebességhez?

Régió	gpt-4, 0613	gpt-4, 1106-Preview	gpt-4, 0125-Preview	gpt-4, turbo-2024-04-09	gpt-4o, 2024-05-13	gpt-4o-mini, 2024-07-18	gpt-4-32k, 0613	gpt-35-turbo, 1106	gpt-35-turbo, 0125
ausztráliaeast	✅	✅	✅	✅	✅	-	✅	✅	✅
brazilsouth	✅	✅	✅	-	✅	-	✅	✅	-
canadacentral	✅	-	-	-	-	-	✅	-	✅
canadaeast	✅	✅	-	✅	✅	✅	-	✅	-
eastus	✅	✅	✅	✅	✅	✅	✅	✅	✅
eastus2	✅	✅	✅	✅	✅	✅	✅	✅	✅
francecentral	✅	✅	✅	-	✅	-	✅	-	✅
germanywestcentral	✅	✅	✅	✅	✅	-	✅	✅	-
japaneast	-	✅	✅	✅	✅	-	-	-	✅
koreacentral	✅	-	-	✅	✅	-	✅	✅	-
northcentralus	✅	✅	✅	✅	✅	✅	✅	✅	✅
norwayeast	✅	-	✅	-	-	-	✅	-	-
lengyelországcentral	✅	✅	✅	-	-	-	✅	✅	✅
southafricanorth	✅	✅	-	✅	-	-	✅	✅	-
USA déli középső régiója	✅	✅	✅	✅	✅	-	✅	✅	✅
southindia	✅	✅	✅	-	✅	-	✅	✅	✅
swedencentral	✅	✅	✅	✅	✅	✅	✅	✅	✅
switzerlandnorth	✅	✅	✅	✅	✅	-	✅	✅	✅
svájcwest	-	-	-	-	-	-	-	-	✅
uksouth	✅	✅	✅	✅	✅	-	✅	✅	✅
westus	✅	✅	✅	✅	✅	-	✅	✅	✅
westus3	✅	✅	✅	✅	✅	-	✅	✅	✅

Feljegyzés

A Verzió kiépített verziója gpt-4 : turbo-2024-04-09 jelenleg csak szövegre korlátozódik.

Fő fogalmak

Üzembehelyezési típusok

Ha kiépített üzembe helyezést hoz létre az Azure OpenAI Studióban, az Üzembe helyezés létrehozása párbeszédpanelen az üzembe helyezés típusa kiépített-felügyelt.

Ha kiépített üzembe helyezést hoz létre az Azure OpenAI-ban CLI-vel vagy API-val, be kell állítania a sku-name kiépített-felügyelt példányt. Az sku-capacity üzembe helyezéshez rendelt PTU-k számát adja meg.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged 

Kvóta

Kiosztott átviteli egységek

A kiosztott átviteli egységek (PTU) a modellfeldolgozó kapacitás általános egységei, amelyekkel méretezhetők a kiépített üzemelő példányok a kérések feldolgozásához és a befejezések létrehozásához szükséges átviteli sebesség eléréséhez. A kiosztott átviteli egységek kvótaként kapják meg az előfizetést regionális alapon, amely meghatározza az adott előfizetésben és régióban található központi telepítésekhez hozzárendelhető maximális számú PTU-t.

Modellfüggetlen kvóta

A más Azure OpenAI-ajánlatok által használt Tokens Per Minute (TPM) kvótától eltérően a PTU-k modellfüggetlenek. A PTU-k használatával bármilyen támogatott modellt/verziót üzembe helyezhet a régióban.

Az új kvóta az Azure OpenAI Studióban egy kiépített felügyelt átviteli egység nevű kvótaelemként jelenik meg. A Studio Kvóta panelen a kvótaelem kibontásával megjelennek a kvóta használatához hozzájáruló üzemelő példányok.

PTU-kvóta beszerzése

A PTU-kvóta alapértelmezés szerint számos régióban elérhető. Ha további kvóta szükséges, az ügyfelek további kvótát kérhetnek az Azure OpenAI Studio kiépített felügyelt átviteliegység-kvótaelemétől jobbra található Kvóta kérése hivatkozáson keresztül. Az űrlap lehetővé teszi az ügyfél számára, hogy növelje a PTU-kvótát egy adott régióra vonatkozóan. Az ügyfél a kérelem jóváhagyása után e-mailt kap a mellékelt címről, általában két munkanapon belül.

Modellenkénti PTU-minimumok

Az egyes egységekhez társított minimális PTU-üzembe helyezés, növekmények és feldolgozási kapacitás a modell típusa és verziója szerint változik.

Kapacitás átláthatósága

Az Azure OpenAI egy rendkívül keresett szolgáltatás, ahol az ügyféligények meghaladhatják a szolgáltatás GPU-kapacitását. A Microsoft arra törekszik, hogy minden igény szerinti régiónak és modellnek biztosítson kapacitást, de egy régió értékesítése mindig lehetőség. Ez korlátozhatja egyes ügyfelek azon képességét, hogy létrehozzák a kívánt modell, verzió vagy PTU-k számát egy kívánt régióban – még akkor is, ha kvótájuk elérhető az adott régióban. Általában:

• A kvóta korlátozza az előfizetésben és régióban üzembe helyezhető PTU-k maximális számát, és nem garantálja a kapacitás rendelkezésre állását.
• A kapacitás az üzembe helyezéskor van lefoglalva, és mindaddig tart, amíg az üzembe helyezés létezik. Ha a szolgáltatáskapacitás nem érhető el, az üzembe helyezés sikertelen lesz
• Az ügyfelek valós idejű információkat használnak a kvóta/kapacitás rendelkezésre állásáról, hogy kiválasszanak egy megfelelő régiót a forgatókönyvükhöz a szükséges modellkapacitással
• Az üzembe helyezési kapacitás leskálázása vagy törlése visszaengedi a kapacitást a régióba. Nincs garancia arra, hogy a kapacitás elérhető lesz, ha az üzembe helyezést később felskálázják vagy újra létrehozták.

Regionális kapacitásra vonatkozó útmutató

Annak érdekében, hogy a felhasználók megtalálják az üzemelő példányaikhoz szükséges kapacitást, az ügyfelek egy új API-t és Studio-felületet fognak használni, amellyel valós idejű információkat biztosíthatnak.

Az Azure OpenAI Studióban az üzembe helyezési felület azonosítja, ha egy régió nem képes támogatni a kívánt modellt, verziót és PTU-k számát, és szükség esetén egy másik régió kiválasztására irányítja a felhasználót.

Az új üzembe helyezési felülettel kapcsolatos részletek az Azure OpenAI kiépített első lépések útmutatójában találhatók.

Az új modellkapacitási API arra is használható, hogy programozott módon azonosítsa egy adott modell maximális méretű üzembe helyezését, amely minden régióban létrehozható a kvóta rendelkezésre állása alapján az előfizetésben és a szolgáltatási kapacitásban a régióban.

Ha egy elfogadható régió nem érhető el a vágymodell, a verzió és/vagy a PTU-k támogatásához, az ügyfelek az alábbi lépéseket is kipróbálhatják:

• Próbálja meg az üzembe helyezést kisebb számú PTU-val.
• Próbálja meg az üzembe helyezést egy másik időpontban. A kapacitás rendelkezésre állása dinamikusan változik az ügyféligények alapján, és később további kapacitások is elérhetővé válhatnak.
• Győződjön meg arról, hogy a kvóta minden elfogadható régióban elérhető. A modellkapacitási API és a Studio tapasztalata figyelembe veszi a kvóta rendelkezésre állását az üzembe helyezés létrehozásához használt alternatív régiók visszaadásakor.

A számítási feladatokhoz szükséges PTU-k számának meghatározása

A PTU-k a modell feldolgozási kapacitását képviselik. A számítógéphez vagy az adatbázisokhoz hasonlóan a modell különböző számítási feladatai vagy kérései különböző mennyiségű mögöttes feldolgozási kapacitást használnak fel. A hívásalakzat jellemzőiről (parancssori méret, létrehozási méret és hívási sebesség) a PTU-kra való konvertálás összetett és nemlineáris. A folyamat egyszerűsítése érdekében az Azure OpenAI kapacitáskalkulátorával méretezheti az egyes számítási feladatok alakzatait.

Néhány magas szintű szempont:

• A generációk több kapacitást igényelnek, mint a kérések
• A nagyobb hívások egyre drágábbak a számításhoz. Például 100 1000 jogkivonatos parancssori mérettel rendelkező híváshoz kevesebb kapacitásra van szükség, mint egy híváshoz, amely 100 000 tokent jelenít meg a parancssorban. Ez azt is jelenti, hogy ezeknek a hívási alakzatoknak az eloszlása fontos az általános átviteli sebesség szempontjából. A széles elosztású, nagyon nagy hívásokat tartalmazó forgalmi minták PTU-nként alacsonyabb átviteli sebességet tapasztalhatnak, mint egy keskenyebb, azonos parancssori és befejezési jogkivonat-mérettel rendelkező disztribúció.

A kihasználtság működése

A kiépített üzemelő példányok hozzárendelt mennyiségű modellfeldolgozási kapacitást biztosítanak egy adott modell futtatásához.

A kiépített felügyelt üzemelő példányokban a kapacitás túllépésekor az API azonnal 429 HTTP-állapothibát ad vissza. Ez lehetővé teszi a felhasználó számára, hogy döntéseket hozzon a forgalom kezeléséről. A felhasználók átirányíthatják a kéréseket egy külön üzembe helyezésre, egy normál használatalapú fizetéses példányra, vagy újrapróbálkozásos stratégiát használhatnak egy adott kérés kezeléséhez. A szolgáltatás mindaddig visszaadja a 429 HTTP-állapotkódot, amíg a kihasználtság 100% alá nem csökken.

Hogyan monitorozhatom a kapacitást?

Az Azure Monitor kiépített felügyelt kihasználtság V2 metrikája egy adott üzembe helyezés kihasználtságát 1 perces lépésekben méri. A kiépített felügyelt üzemelő példányok úgy vannak optimalizálva, hogy az elfogadott hívások konstansokkal legyenek feldolgozva sátormód l feldolgozási idővel (a tényleges végpontok közötti késés a hívás jellemzőitől függ).

Mit tegyek, ha 429-választ kapok?

A 429-válasz nem hiba, hanem annak a tervnek a része, amely azt jelzi a felhasználóknak, hogy egy adott üzembe helyezés egy adott időpontban teljes mértékben kihasználva van. A gyors feladatmegoldással szabályozhatja, hogyan kezelheti ezeket a helyzeteket úgy, hogy az a legjobban megfeleljen az alkalmazás követelményeinek.

A retry-after-ms válasz fejlécei és retry-after fejlécei jelzik, hogy mennyi időt kell várni a következő hívás elfogadása előtt. A válasz kezelése az alkalmazás követelményeitől függ. Íme néhány szempont:

• Érdemes lehet átirányítani a forgalmat más modellekre, üzemelő példányokra vagy szolgáltatásokra. Ez a beállítás a legalacsonyabb késésű megoldás, mert a művelet a 429-jel beérkezése után azonnal végrehajtható. A minta hatékony megvalósításával kapcsolatos ötletekért tekintse meg ezt a közösségi bejegyzést.
• Ha nem bánja a hosszabb hívásonkénti késéseket, implementálja az ügyféloldali újrapróbálkozás logikáját. Ez a beállítás a PTU-nkénti legnagyobb átviteli sebességet biztosítja. Az Azure OpenAI-ügyfélkódtárak beépített képességeket tartalmaznak az újrapróbálkozások kezeléséhez.

Hogyan dönti el a szolgáltatás, hogy mikor küldjön 429-et?

A kiépített-felügyelt ajánlatban a rendszer minden kérést egyenként értékel ki a kérés mérete, a várható generációs méret és a modell alapján a várható kihasználtság meghatározásához. Ez ellentétben áll a használatalapú fizetéses üzemelő példányokkal, amelyek egyéni sebességkorlátozó viselkedéssel rendelkeznek a becsült forgalmi terhelés alapján. Használatalapú fizetéses üzemelő példányok esetén ez HTTP 429-hibákhoz vezethet a megadott kvótaértékek túllépése előtt, ha a forgalom nem egyenletesen oszlik el.

Kiépített felügyelt esetén a kiszivárgott gyűjtő algoritmusának egy változatával 100% alatt tartjuk a kihasználtságot, miközben lehetővé tesszük a forgalom némi felpezsdülését. A magas szintű logika a következő:

1. Minden ügyfél rendelkezik egy beállított kapacitással, amelyet egy üzembe helyezés során használhat fel

2. Kérés esetén:

   a. Ha az aktuális kihasználtság meghaladja a 100%-ot, a szolgáltatás egy 429-et ad vissza, amelynek retry-after-ms fejléce arra az időre van beállítva, amíg a kihasználtság nem éri el a 100%-ot

   b. Ellenkező esetben a szolgáltatás megbecsüli a kérés kiszolgálásához szükséges kihasználtság növekményes módosítását a parancssori jogkivonatok és a hívásban megadottak max_tokens kombinálásával. Ha a max_tokens paraméter nincs megadva, a szolgáltatás megbecsül egy értéket. Ez a becslés a vártnál alacsonyabb egyidejűséget eredményezhet, ha a ténylegesen létrehozott jogkivonatok száma kicsi. A legmagasabb egyidejűség érdekében győződjön meg arról, hogy az max_tokens érték a lehető legközelebb van a valódi generációs mérethez.

3. Amikor egy kérés befejeződik, már tudjuk a hívás tényleges számítási költségét. A pontos könyvelés érdekében a kihasználtságot az alábbi logikával javítjuk ki:

   a. Ha a tényleges > becsült érték, akkor a rendszer hozzáadja a különbséget az üzembe helyezés kihasználtságához b. Ha a tényleges < becslés, akkor a különbség kivonódik.

4. A teljes kihasználtság folyamatosan csökken az üzembe helyezett PTU-k száma alapján.

Feljegyzés

A hívások addig fogadhatók, amíg a kihasználtság eléri a 100%-ot. Rövid időszakokban az alig több mint 100%-os adatkitörések engedélyezettek, de idővel a forgalom kihasználtsága 100%-os.

Hány egyidejű hívás lehet az üzemelő példányomon?

Az egyidejű hívások száma az egyes hívások alakjától függ (parancssor mérete, max_token paraméter stb.). A szolgáltatás addig fogadja a hívásokat, amíg a kihasználtság eléri a 100%-ot. Az egyidejű hívások hozzávetőleges számának meghatározásához modellezheti egy adott hívásalakzat percenkénti maximális kéréseit a kapacitáskalkulátorban. Ha a rendszer kevesebb mintavételi jogkivonatot hoz létre, mint a max_token, több kérést fogad el.

Következő lépések

• Tudnivalók a kiépített üzembe helyezések előkészítési lépéseiről
• Üzembe helyezési átviteli egységek (PTU) – első lépések útmutatója