Olvasás angol nyelven

Megosztás a következőn keresztül:


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.

Mit nyújtanak a kiépített üzembehelyezési típusok?

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

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

PTU-nkénti átviteli sebesség az egyes modellekhez

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.

Fő fogalmak

Üzembehelyezési típusok

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

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

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.

Modellfüggetlen kvóta diagramja több Azure OpenAI-modell számára elérhető PTUs-készlettel.

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.

Képernyőkép az Azure OpenAI-hoz kiépített kvóta felhasználói felületéről.

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

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

Regionális kapacitásra vonatkozó útmutató

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

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.

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

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?

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

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

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.

Diagram, amely bemutatja, hogyan lesznek hozzáadva a későbbi hívások a kihasználtsághoz.

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

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

Globálisan kiosztott felügyelt modell rendelkezésre állása

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.

Következő lépések