Mi a kiosztott átviteli sebesség?

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).

Feljegyzés

A kiépített átviteli egység (PTU) kvótája eltér az Azure OpenAI standard kvótájától, és alapértelmezés szerint nem érhető el. Ha többet szeretne megtudni erről az ajánlatról, forduljon a Microsoft-fiók csapatához.

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.

Hogyan hozzáférést kap a kiépítetthez?

A kiosztott átviteli sebesség beszerzéséhez a Microsoft értékesítési/fiókcsapatával kell beszélnie. Ha nincs értékesítési/fiókcsapata, sajnos jelenleg nem vásárolhat kiosztott átviteli sebességet.

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-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

Kiosztott átviteli egységek

A kiosztott átviteli egységek (PTU) a modellfeldolgozó kapacitás egységei, amelyeket lefoglalhat és üzembe helyezhet a kérések feldolgozásához és a befejezések létrehozásához. 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.

Üzembehelyezési típusok

Amikor üzembe helyez egy modellt az Azure OpenAI-ban, be kell állítania a sku-name kiépített-felügyelt állapotot. 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

A kiosztott átviteli sebességkvóta az üzembe helyezhető teljes átviteli sebesség meghatározott mennyiségét jelöli. Az Azure OpenAI szolgáltatás kvótái az előfizetés szintjén kezelhetők. Az előfizetés összes Azure OpenAI-erőforrása osztozik ezen a kvótán.

A kvóta a kiosztott átviteli egységekben van megadva, és egy (üzembe helyezési típus, modell, régió) hármasra vonatkozik. A kvóta nem cserélhető fel. Ez azt jelenti, hogy a GPT-4-hez nem használhat kvótát a GPT-3.5-Turbo telepítéséhez.

Bár minden kísérletet megteszünk annak biztosítására, hogy a kvóta üzembe helyezhető legyen, a kvóta nem jelenti a mögöttes kapacitás rendelkezésre állásának garanciát. A szolgáltatás kapacitást rendel hozzá az üzembe helyezési művelet során, és ha a kapacitás nem érhető el, az üzembe helyezés kapacitáson kívüli hibával meghiúsul.

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őiből (prompt size, generation size and call rate) a PTU-kká történő konvertálása összetett és nem lineá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 lesz szükség, mint 1 hívás, és 100 000 token szerepel 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 nagyon nagy hívásokat tartalmazó széles elosztással rendelkező 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 a http 429-eket a megadott kvótaértékek túllépése előtt generálhatja, 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. A kipukkadások valamivel több mint 100%, talán rövid időszakokban engedélyezettek, de idővel a forgalom 100%-os kihasználtságon van leképezve.

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