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

Mi a kiosztott átviteli sebesség?

Feljegyzés

A kiosztott átviteli sebességre vonatkozó ajánlat legutóbbi változásairól további információt a frissítési cikkben talál.

Az Azure AI Foundry által kiosztott átviteli sebesség egy olyan modelltelepítési típus, amely lehetővé teszi a modell üzembe helyezéséhez szükséges átviteli sebesség megadását. Az Azure AI Foundry ezután lefoglalja a szükséges modellfeldolgozási kapacitást, és biztosítja, hogy készen áll az Ön számára. A kért kiosztott átviteli sebességet számos olyan modellportfólión használhatja , amelyeket közvetlenül az Azure értékesít. Ezek a modellek közé tartoznak az Azure OpenAI-modellek és az újonnan bevezetett zászlóshajó modellcsaládok, például az Azure DeepSeek, az Azure Grok, az Azure Llama és még sok más az Azure AI Foundry-modelleken belül.

A kiosztott átviteli sebesség a következőt biztosítja:

  • Szélesebb modellválaszték a legújabb zászlóshajó modellek esetében
  • Rugalmasság a modellek és a telepítések közötti váltáshoz a megadott kiosztott átviteli sebességkvótával.
  • Jelentős kedvezmények és a foglalás kihasználtságának növelése rugalmasabb foglalásválasztással
  • Kiszámítható teljesítmény az egységes számítási feladatok stabil maximális késésének és átviteli sebességének biztosításával.
  • Lefoglalt 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.

Jótanács

Mikor érdemes használni a kiosztott átviteli sebességet?

Fontolja meg a szabványos telepítésekről a kiépített átviteli sebesség szerinti telepítésekre való átállást, ha jól meghatározott, kiszámítható átviteli sebességre és késési követelményekre van szüksége. Ez általában akkor fordul elő, ha az alkalmazás készen áll az éles használatra, vagy már üzembe van helyezve az éles környezetben, és tisztában van a várt forgalommal. Így a felhasználók pontosan előre jelezhetik a szükséges kapacitást, és elkerülhetik a váratlan számlázást. A kiépített átviteli sebesség üzembe helyezések olyan alkalmazások esetében is hasznosak, amelyek valós idejű/késésre érzékeny követelményeket támasztanak.

Fő fogalmak

Az alábbi szakaszok a kiosztott átviteli sebességre vonatkozó ajánlat használatakor figyelembe vehető legfontosabb fogalmakat ismertetik.

Kiosztott átviteli egységek (PTU)

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. Az előfizetéshez rendelt átviteli egységek kvótaként kerülnek kiosztásra, és a költségek meghatározására szolgálnak. 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 PTU-értéket.

Költségkezelés megosztott PTU-foglalás alatt

A PTU képességével zökkenőmentesen kezelheti a Foundry Modellek költségeit egy megosztott PTU-foglalás alatt. Az üzembe helyezéshez és az átviteli teljesítményhez szükséges PTU-egységek azonban dinamikusan a kiválasztott modellekre vannak szabva. A PTU-költségekről és a modell késési pontjairól további információt a PTU-hoz kapcsolódó költségek ismertetése című témakörben talál.

A meglévő PTU-foglalások automatikusan frissülnek, hogy az ügyfelek fokozott hatékonyságot érjenek el és költségeket takarítsanak meg a Foundry modellek üzembe helyezésekor. Tegyük fel például, hogy van egy meglévő PTU-foglalása, amely 500 PTU-ból áll. 300 egységet használ az Azure OpenAI-modellekhez, és a PTU használatával is üzembe helyezheti az Azure DeepSeek, az Azure Llama vagy más PTU-képességgel rendelkező modelleket a Foundry Modelleken.

  • Ha a fennmaradó 200 PTU-t használja a DeepSeek-R1-hez, a 200 PTU automatikusan megosztja a foglalási kedvezményt, és a teljes foglalási igénye 500 PTU.

  • Ha 300 PTU-t használ a DeepSeek-R1-hez, akkor 200 PTU automatikusan részesül a foglalási kedvezményben, míg 100 PTU túllépi a foglalást, és a DeepSeek-R1 óránkénti díjával számoljuk fel.

A PTU-foglalások költségeinek megtakarításáról a Költségek mentése a Microsoft Azure AI Foundry által kiépített átviteli sebesség-foglalásokkal című témakörben olvashat.

Üzembehelyezési típusok

Ha kiépített üzembe helyezést hoz létre az Azure AI Foundryben, az üzembe helyezési típus a "Központi telepítés létrehozása" párbeszédpanelen az adott számítási feladat adatfeldolgozási igényeitől függően a globális kiosztott átviteli sebesség, az adatzóna kiosztott átviteli sebessége vagy a regionális kiosztott átviteli sebesség üzembe helyezésének típusára állítható be.

Ha az Azure AI Foundry-ben CLI vagy API segítségével hozol létre kiépített üzembe helyezést, az sku-name beállítása az adott számítási feladat adatfeldolgozási igényeitől függően lehet GlobalProvisionedManaged, DataZoneProvisionedManaged vagy ProvisionedManaged.

Üzembe helyezés típusa termékváltozat neve a parancssori felületen
Globális kiosztott átviteli sebesség GlobalProvisionedManaged
Adatzóna kiosztott átviteli sebessége DataZónaElőkészítettKezelt
Regionális kiosztott átviteli sebesség ProvízionáltKezelt

Ha a következő Azure CLI-példaparancsot egy másik üzembehelyezési típushoz szeretné igazítani, frissítse a sku-name paramétert az ü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

Kapacitás átláthatósága

A közvetlenül az Azure által értékesített modellek rendkívül keresett szolgáltatások, 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 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 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 meghiúsul.
  • 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áztá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 PTU kívánt modelljét, verzióját és számát vizsgálja. Ha a kapacitás nem érhető el, a felület arra utasítja a felhasználókat, hogy válasszanak ki egy másik régiót.

Az üzembe helyezési felülettel kapcsolatos részletek az Azure AI Foundry üzembe helyezési útmutatójában találhatók.

A 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 kívánt modell, verzió és/vagy PTU 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.

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

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. A gyors válasz lehetővé teszi, hogy a felhasználó 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 szabványos üzembehelyezési 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.

Mit tegyek, ha 429-választ kapok?

A 429-válasz nem hiba, hanem a terv része, amely azt jelzi a felhasználóknak, hogy egy adott üzembe helyezés teljes mértékben kihasználva van egy adott időpontban. 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 AI Foundry ügyfélkódtárai 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ípusban a rendszer minden kérést egyenként értékel ki a parancssori méret, a várható generációs méret és a modell alapján a várható kihasználtság meghatározásához. Ez a viselkedés ellentétben áll a szabványos üzemelő példányokkal, amelyek egyéni sebességkorlátozó viselkedéssel rendelkeznek a becsült forgalmi terhelés alapján. Normál üzemelő példányok esetén ez az egyéni sebességkorlátozási viselkedés 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 gyorsítótárazott 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 folyamatos ütemben csökken az üzembe helyezett PTU számától függően.

Feljegyzés

A hívások addig fogadhatók, amíg a kihasználtság eléri a 100%-ot. Rövid időszakokra meghaladó 100% terhelési csúcsok megengedettek lehetnek, de idővel a forgalmad korlátozódik 100% kihasználtságra.

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.

Kiépített átviteli sebesség a közvetlenül az Azure által értékesített modellekhez

Ez a szakasz a kiosztott átviteli sebességet támogató öntödei modelleket sorolja fel. A PTU-kvótát és a PTU-foglalást a táblázatban látható modellek között használhatja.

Az alábbi pontok néhány fontos szempontot mutatnak be a táblázatból:

  • A modell verziója nem szerepel a táblázatban. Az Azure AI Foundry portálon az üzembe helyezési lehetőség kiválasztásakor ellenőrizze az egyes modellek által támogatott verziót.

  • A regionális átviteli kapacitás üzembe helyezési lehetősége régiónként változó.

  • A közvetlenül az Azure által értékesített új modelleket először globálisan kiosztott átviteli sebesség üzembe helyezési lehetőséggel készítik el. Az adattér provisionált opciója később válik elérhetővé.

  • A PTU-t regionálisan és ajánlattípusok szerint kezelik. A PTU-kvótának és a foglalásoknak a használni kívánt régióban és formában kell lenniük (globális, adatzóna, regionális).

  • A spillover egy opcionális funkció, amely kezeli a forgalom ingadozásait a kiosztott telepítéseken. További információért az átterhelésről tekintse meg a forgalom kezelése előre beállított telepítéseknél (előzetes verzió) című témakört.

Modellcsalád Modell neve Globálisan biztosított Kiépített adatzóna Regionális ellátás Átáramló jellemző
Azure OpenAI Gpt4.1 ✅ ✅ ✅ ✅
Gpt 4.1 mini ✅ ✅ ✅ ✅
Gpt 4.1 nano ✅ ✅ ✅ ✅
Gpt 4o ✅ ✅ ✅ ✅
Gpt 4o mini ✅ ✅ ✅ ✅
Gpt 3.5 Turbo ✅ ✅ ✅ ✅
o1 ✅ ✅ ✅ ✅
O3 mini ✅ ✅ ✅ ✅
O4 mini ✅ ✅ ✅ ✅
Azure DeepSeek DeepSeek-R1 ✅
DeepSeek-V3-0324 ✅

A kiosztott átviteli sebesség képesség régiónkénti rendelkezésre állása

Globális kiosztott átviteli sebességmodell rendelkezésre állása

Régió o3
2025-04-16		 o4-mini
2025-04-16		 gpt-4.1
2025-04-14		 gpt-4.1 nano
2025-04-14		 gpt-4.1-mini
2025-04-14		 o3-mini
2025. január 31.		 o1
2024. 12. 17.		 gpt-4o
2024.05.13		 gpt-4o
2024-08-06		 gpt-4o
2024-11-20		 gpt-4o-mini
2024. július 18.		 DeepSeek-R1 DeepSeek-V3-0324
ausztráliaeast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Brazília déli régiója ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Kanada keleti része ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
francecentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Németország Közép-Nyugat ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Olaszország északa ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ ✅ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norvégia keleti része ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
lengyelországcentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southafricanorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
USA déli középső régiója ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Délkelet-Ázsia ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Dél-India ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
spaincentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Swedencentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Svájc észak ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
svájcwest ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westeurope ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ ✅ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Feljegyzés

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

Kapcsolódó tartalom