Mi a kiosztott átviteli sebesség?
Megjegyzé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.
- 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). A globális kiépített üzemelő példányok ugyanazokban az Azure OpenAI-erőforrásokban érhetők el, mint az összes többi üzembe helyezési típus, de lehetővé teszik az Azure globális infrastruktúrájának használatát, hogy dinamikusan irányíthassa a forgalmat az adatközpontba az egyes kérések legjobb rendelkezésre állásával. Hasonlóképpen, az adatzóna által kiépített üzemelő példányok ugyanabban az erőforrásban is elérhetők, mint az összes többi üzembe helyezési típus, de lehetővé teszi az Azure globális infrastruktúrájának kihasználását, hogy dinamikusan irányítsa a forgalmat a Microsoft által megadott adatzónán belüli adatközpontba, a lehető legjobb rendelkezésre állással az egyes kérésekhez.
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ég, globális kiosztott felügyelt átviteli sebességegység vagy régiónként hozzárendelt adatzóna kiosztott felügyelt átviteli sebességegysége. A kvóta bármely elérhető Azure OpenAI-modellben használható. |
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 V2-mérték. |
Méret becslése | Méretezési kalkulátor az Azure AI Foundryben. |
Gyorsítótárazás kérése | Támogatott modellek esetén a gyorsítótárazott bemeneti jogkivonatok akár 100%-át is kedvezményesen használjuk. |
Az üzemelő példányok által pTU-nként lekérhető átviteli sebesség (tokenek percenként vagy TPM) a bemeneti és kimeneti jogkivonatok függvénye a percben. A kimeneti jogkivonatok létrehozása több feldolgozást igényel, mint a bemeneti jogkivonatok. Az alábbi táblázatban megadott modellek esetében az 1 kimeneti jogkivonat 3 bemeneti jogkivonatnak számít a TPM/PTU-korlát felé. A szolgáltatás dinamikusan kiegyensúlyozza a bemeneti és kimeneti költségeket, így a felhasználóknak nem kell meghatározott bemeneti és kimeneti korlátokat beállítaniuk. Ez a megközelítés azt jelenti, hogy az üzembe helyezés rugalmas a számítási feladatok alakzatának ingadozásaival szemben.
A méretezési munka egyszerűsítése érdekében az alábbi táblázat a megadott modellek PTU-nkénti TPM-jét vázolja fel. A kimeneti jogkivonatok PTU-korlátonkénti TPM-re gyakorolt hatásának megértéséhez használja a 3 bemeneti jogkivonatot 1 kimeneti token arányra. Az Azure OpenAI kapacitáskalkulátorában részletesen megismerheti, hogy a bemeneti és kimeneti jogkivonatok eltérő arányai milyen hatással vannak a számítási feladatokhoz szükséges átviteli sebességre. A táblázat a szolgáltatásiszint-szerződés (SLA) késési célértékeit is megjeleníti modellenként. Az Azure OpenAI szolgáltatás SLA-jával kapcsolatos további információkért tekintse meg az online szolgáltatások szolgáltatásszint-szerződéseit (SLA) ismertető oldalt.
Téma | gpt-4o | gpt-4o-mini |
---|---|---|
Globális adatzóna kiépített minimális üzembe helyezése | 15 | 15 |
Globális adatzóna kiépített méretezési növekménye | 5 | 5 |
Regionális kiépített minimális üzembe helyezés | 50 | 25 |
Regionális kiosztott méretezési növekmény | 50 | 25 |
Bemeneti TPM/PTU | 2500 | 37,000 |
Késési célérték | 25 token másodpercenként | 33 token másodpercenként |
A teljes listát az Azure OpenAI szolgáltatás az Azure AI Foundry portál kalkulátorában találja.
Megjegyzés
A globálisan kiépített és az adatzóna által kiépített üzemelő példányok jelenleg csak a gpt-4o és a gpt-4o-mini modellek esetében támogatottak. A modell rendelkezésre állásával kapcsolatos további információkért tekintse át a modellek dokumentációját.
Ha kiépített üzembe helyezést hoz létre az Azure AI Foundryben, a Központi telepítés létrehozása párbeszédpanelen az üzembe helyezés típusa az adott számítási feladat adatfeldolgozási igényeitől függően a globálisan kiépített, a Kiépített DataZone által felügyelt vagy a regionális kiépített központi telepítési típusra állítható be.
Ha kiépített üzembe helyezést hoz létre az Azure OpenAI-ban CLI-n vagy API-n keresztül, az sku-name
adott számítási feladathoz szükséges adatfeldolgozási igénytől függően lehet beállítani GlobalProvisionedManaged
DataZoneProvisionedManaged
ProvisionedManaged
azokat. Ha az alábbi Azure CLI-példaparancsot egy másik üzembehelyezési típushoz szeretné igazítani, egyszerűen frissítse a paramétert az sku-name
üzembe helyezni kívánt telepítési típusnak megfelelően.
az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4o \
--model-version 2024-08-06 \
--model-format OpenAI \
--sku-capacity 15 \
--sku-name GlobalProvisionedManaged
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ótáként kapják meg az előfizetést. Minden kvóta egy adott régióra vonatkozik, és meghatározza az adott előfizetésben és régióban lévő központi telepítésekhez hozzárendelhető maximális számú PTU-t.
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.
A kiépített üzemelő példányok esetében az új kvóta az Azure AI Foundryben a kiépített felügyelt átviteli egység nevű kvótaelemként jelenik meg. Globális kiépített üzemelő példányok esetén az új kvóta az Azure AI Foundryben jelenik meg globális kiosztott felügyelt átviteli sebességegység nevű kvótaelemként. Az adatzóna kiépített üzemelő példányai esetében az új kvóta az Azure AI Foundryben jelenik meg a Data Zone Provisioned Managed Throughput Unit nevű kvótaelemként. Az Öntödei kvóta panelen a kvótaelem kibontása megjeleníti az egyes kvóták használatához hozzájáruló üzemelő példányokat.
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 a Kvóta kérése hivatkozáson keresztül kérhetnek kvótát. Ez a hivatkozás az Azure AI Foundry kijelölt üzembehelyezési típusú kvóta lapjainak jobb oldalán található. Az űrlap lehetővé teszi az ügyfél számára, hogy növelje a megadott PTU-kvótát egy adott régióban. 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.
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.
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 a korlátozás 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.
Az üzembe helyezésükhöz szükséges kapacitás megkereséséhez használja a kapacitás API-t vagy az Azure AI Foundry üzembe helyezési felületét a kapacitás rendelkezésre állásával kapcsolatos valós idejű információk biztosításához.
Az Azure AI Foundryben az üzembe helyezési felület azonosítja, ha egy régió nem rendelkezik a modell üzembe helyezéséhez szükséges kapacitással. Ez a kívánt modellt, verziót és PTU-k számát vizsgálja. Ha a kapacitás nem érhető el, a felület egy másik régióba irányítja a felhasználókat.
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 segítségével programozott módon azonosíthatja egy adott modell maximális méretű üzembe helyezését. Az API mind a kvótát, mind a szolgáltatási kapacitást figyelembe veszi 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 az Azure AI Foundry felhasználói élménye figyelembe veszi a kvóta rendelkezésre állását az üzemelő példányok létrehozására szolgáló alternatív régiók visszaadásakor.
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. Az átviteli sebességről PTU-kra való konvertálás a teljesítmény- és késési dokumentációnkban ismertetett előzmény jogkivonat-használati adatokkal vagy hívási alakzatok becslésével (bemeneti jogkivonatok, kimeneti jogkivonatok és kérések percenként) közelíthető meg. 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
- GPT-4o és újabb modellek esetén a PTU-nkénti TPM külön van beállítva a bemeneti és kimeneti jogkivonatokhoz. A régebbi modellek esetében 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 a rétegzés azt jelenti, hogy ezeknek a hívási alakzatoknak az eloszlása fontos a teljes átviteli sebesség szempontjából. A 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 kiépített üzemelő példányok hozzárendelt mennyiségű modellfeldolgozási kapacitást biztosítanak egy adott modell futtatásához.
Az összes kiépített üzembehelyezési típus esetében, ha a kapacitás túllépi a kapacitást, az API 429 HTTP-állapothibát ad vissza. Ez a gyors válasz 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ával kezelhetik az adott kéréseket. A szolgáltatás mindaddig visszaadja a 429 HTTP-állapotkódot, amíg a kihasználtság 100% alá nem csökken.
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. Az összes kiépített üzembehelyezési típus úgy van 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).
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.
Az összes kiépített üzembehelyezési típus esetében 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.
A kiépített üzemelő példányok esetében 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 kipukkanását. A magas szintű logika a következő:
Minden ügyfél rendelkezik egy beállított kapacitással, amelyet egy üzembe helyezés során használhat fel
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%-otb. 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, a cacehd-jogkivonatok és a hívásban megadottak
max_tokens
kombinálásával. Az ügyfelek a gyorsítótárazott jogkivonatok méretétől függően akár 100%-os kedvezményt is kaphatnak a parancssori jogkivonataikra. Ha amax_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 azmax_tokens
érték a lehető legközelebb van a valódi generációs mérethez.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.
A teljes kihasználtság folyamatosan csökken az üzembe helyezett PTU-k száma alapján.
Megjegyzé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.
Az egyidejű hívások száma az egyes hívások alakjától függ (parancssor mérete, max_tokens
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 a kapacitáskalkulátorban modellezheti egy adott hívásalakzat percenkénti maximális kéréseit. Ha a rendszer kevesebbet hoz létre, mint a paraméterhez max_tokens
beállított kimeneti jogkivonatok száma, akkor a kiépített üzembe helyezés további kéréseket fogad el.
Régió | gpt-4o, 2024-05-13 | gpt-4o, 2024-08-06 | gpt-4o-mini, 2024-07-18 |
---|---|---|---|
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 | ✅ | ✅ | ✅ |
spaincentral | ✅ | ✅ | ✅ |
swedencentral | ✅ | ✅ | ✅ |
switzerlandnorth | ✅ | ✅ | ✅ |
svájcwest | ✅ | ✅ | ✅ |
uaenorth | ✅ | ✅ | ✅ |
uksouth | ✅ | ✅ | ✅ |
westeurope | ✅ | ✅ | ✅ |
westus | ✅ | ✅ | ✅ |
westus3 | ✅ | ✅ | ✅ |
Megjegyzés
A Verzió kiépített verziója gpt-4
: turbo-2024-04-09
jelenleg csak szövegre korlátozódik.