Sdílet prostřednictvím

Co je vyhrazená propustnost?

Poznámka:

Tento dokument se týká portálu Microsoft Foundry (Classic).

🔄 Pokud používáte nový portál, přepněte na dokumentaci Microsoft Foundry (nová).

Poznámka:

Tento dokument se týká portálu Microsoft Foundry (nový).

Návod

Další informace o nedávných změnách nabídky zřízené propustnosti najdete v článku aktualizace .

Nabídka Microsoft Foundry pro přidělenou propustnost je typ nasazení modelu, který vám umožňuje určit, jakou propustnost požadujete pro nasazení modelu. Foundry pak přidělí potřebnou kapacitu zpracování modelu a zajistí, že je pro vás připravená. Zřízenou propustnost, kterou jste požadovali, můžete použít v různých portfoliech modelů, které se prodávají přímo v Azure. Mezi tyto modely patří modely Azure OpenAI a nově představené vlajkové modelové řady, jako jsou Azure DeepSeek, Azure Grok, Azure Llama a další.

Zřízená propustnost poskytuje:

  • Širší volba modelu na nejnovějších vlajkových modelech
  • Flexibilita pro změnu modelů a nasazení s určenou kvótou zajištěné propustnosti
  • Výrazné slevy a možnost zvýšit využití rezervací s flexibilnější volbou rezervace
  • Předvídatelný výkon díky zajištění stabilní maximální latence a propustnosti pro jednotné úlohy.
  • Přidělená kapacita zpracování: Nasazení konfiguruje propustnost. Po nasazení je propustnost dostupná bez ohledu na to, jestli se používá.
  • Úspora nákladů: Úlohy s vysokou propustností můžou přinést úsporu nákladů oproti spotřebě založené na tokenech.

Návod

Kdy použít zřízenou propustnost

Měli byste zvážit přechod ze standardních nasazení na zřízená nasazení propustnosti, pokud máte dobře definované, předvídatelné požadavky na propustnost a latenci. K tomu obvykle dochází, když je aplikace připravená pro produkční prostředí nebo je už nasazená v produkčním prostředí a rozumí očekávanému provozu. To umožňuje uživatelům přesně předpovídat požadovanou kapacitu a vyhnout se neočekávané fakturaci. Nasazení zajištěné propustnosti jsou také užitečná pro aplikace s požadavky citlivými na latenci a potřebu provozu v reálném čase.

Klíčové koncepty

Následující části popisují klíčové koncepty, o které byste měli vědět při použití nabídky zřízené propustnosti.

Zřízené jednotky propustnosti (PTU)

Jednotky předem nastavené propustnosti (PTU) jsou obecné jednotky kapacity zpracování modelu, které můžete použít k nastavení velikosti předem nasazených systémů, abyste dosáhli požadované propustnosti pro zpracování vstupů a generování výstupů. Zřízené jednotky propustnosti se udělují předplatnému jako kvóta a používají se k definování nákladů. Každá kvóta je specifická pro oblast a definuje maximální počet PTU, který lze přiřadit k nasazením v daném předplatném a oblasti.

Správa nákladů v rámci sdílené rezervace PTU

Pomocí funkce PTU můžete bezproblémově spravovat náklady na modely Foundry v rámci sdílené rezervace PTU. Požadované jednotky PTU pro výkon nasazení a propustnosti jsou ale dynamicky přizpůsobené zvoleným modelům. Další informace o nákladech na PTU a bodech latence modelu najdete v tématu Vysvětlení nákladů spojených s PTU.

Stávající rezervace PTU se automaticky upgradují, aby zákazníkům mohly zajistit vyšší efektivitu a úsporu nákladů při nasazování modelů Foundry. Předpokládejme například, že máte existující rezervaci PTU se zakoupenými 500 PTU. Pro modely Azure OpenAI používáte 300 jednotek a rozhodnete se také použít PTU k nasazení Azure DeepSeek, Azure Llama nebo jiných modelů s funkcí PTU v modelech Foundry.

  • Pokud použijete zbývajících 200 PTU pro DeepSeek-R1, 200 PTU automaticky sdílí slevu za rezervaci a celkové využití rezervace je 500 PTU.

  • Pokud použijete 300 PTU pro DeepSeek-R1, poté se pro 200 PTU automaticky uplatní sleva za rezervaci, zatímco 100 PTU překročí rezervaci a jsou účtovány hodinovou sazbou DeepSeek-R1.

Další informace o úsporách nákladů s rezervacemi PTU najdete v tématu Úspora nákladů pomocí rezervací zřízené propustnosti Microsoft Foundry.

Typy nasazení

Při vytváření zřízeného nasazení v Foundry můžete typ nasazení v dialogovém okně Vytvořit nasazení nastavit na globální zřízenou propustnost, zřízenou propustnost zón dat nebo místní zřízenou propustnost v závislosti na potřebách zpracování dat pro danou úlohu.

Při vytváření zřízeného nasazení v Foundry prostřednictvím rozhraní příkazového řádku nebo rozhraní API můžete nastavit sku-name na GlobalProvisionedManaged, DataZoneProvisionedManaged nebo ProvisionedManaged v závislosti na potřebě zpracování dat pro danou úlohu.

Typ nasazení název SKU v příkazovém řádku
Globální zřízená propustnost GlobalProvisionedManaged
Zřízená propustnost datové zóny Spravovaná Datová Zóna Zajištěná
Regionální zřízená propustnost ProvisionovanýSpravovaný

Pokud chcete přizpůsobit následující ukázkový příkaz Azure CLI jinému typu nasazení, aktualizujte sku-name parametr tak, aby odpovídal typu nasazení, který chcete nasadit.

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

Transparentnost kapacity

Modely prodané přímo v Azure jsou vysoce vyhledávanými službami, ve kterých může poptávka zákazníků překročit kapacitu GPU služby. Microsoft se snaží poskytnout kapacitu pro všechny žádané regiony a modely, ale vyčerpání kapacity v regionu je vždy možností. Toto omezení může omezit schopnost některých zákazníků vytvořit nasazení požadovaného modelu, verze nebo počtu PTU v požadované oblasti – i když mají v této oblasti dostupnou kvótu. Obecně řečeno:

  • Kvóta omezuje maximální počet PTU, který je možné nasadit v předplatném a oblasti, a nezaručuje dostupnost kapacity.
  • Kapacita se přiděluje v době nasazení a uchovává se tak dlouho, dokud nasazení existuje. Pokud není dostupná kapacita služby, nasazení selže.
  • Zákazníci používají informace o dostupnosti kvóty nebo kapacity v reálném čase k výběru vhodné oblasti pro svůj scénář s potřebnou kapacitou modelu.
  • Snížení měřítka nebo odstranění nasazení uvolní kapacitu zpět do oblasti. Není zaručeno, že kapacita bude dostupná, pokud by bylo nasazení rozšířeno nebo znovu vytvořeno později.

Pokyny k regionální kapacitě

Pokud chcete najít kapacitu potřebnou pro jejich nasazení, použijte rozhraní API kapacity nebo prostředí nasazení Foundry k poskytování informací o dostupnosti kapacity v reálném čase.

Ve Foundry prostředí nasazení identifikuje, kdy oblast nemá kapacitu potřebnou k nasazení modelu. Tím se podíváte na požadovaný model, verzi a počet PTU. Pokud není kapacita dostupná, prostředí uživatele nasměruje na výběr alternativní oblasti.

Podrobnosti o prostředí nasazení najdete v úvodní příručce Foundry Provisioned.

Rozhraní API kapacit modelu lze použít k programové identifikaci maximální velikosti nasazení zadaného modelu. API bere v úvahu jak kvótu, tak kapacitu služby v dané oblasti.

Pokud není dostupná přijatelná oblast pro podporu požadovaného modelu, verze nebo PTU, zákazníci můžou vyzkoušet také následující kroky:

  • Pokuste se o nasazení s menším počtem PTU.
  • Pokuste se o nasazení v jiném okamžiku. Změny dostupnosti kapacity se dynamicky mění na základě poptávky zákazníků a vyšší kapacita se může později zpřístupnit.
  • Ujistěte se, že je kvóta dostupná ve všech přijatelných oblastech. Rozhraní API pro kapacity modelu a prostředí Foundry zvažují dostupnost kvót při vracení alternativních oblastí pro vytvoření nasazení.

Jak můžu monitorovat kapacitu?

Metrika Provisioned-Managed Utilization V2 ve službě Azure Monitor měří využití daného nasazení na přírůstcích po jedné minutě. Všechny zřízené typy nasazení jsou optimalizovány tak, aby se zajistilo, že přijatá volání jsou zpracovávána s konzistentním časem zpracování modelu (skutečná end-to-end latence závisí na charakteristikách volání).

Jak funguje výkon využití

Nasazení s přidělenou kapacitou poskytují určené množství kapacity pro zpracování a spuštění konkrétního modelu.

Ve všech zřízených typech nasazení vrátí rozhraní API při překročení kapacity chybu stavu HTTP 429. Rychlá odpověď uživateli umožňuje rozhodovat se, jak spravovat provoz. Uživatelé můžou žádosti přesměrovat do samostatného nasazení, do standardní instance nasazení nebo ke správě daného požadavku použít strategii opakování. Služba nadále vrací stavový kód HTTP 429, dokud využití klesne pod 100 %.

Co mám dělat, když obdržím odpověď 429?

Odpověď 429 není chybou, ale je součástí návrhu, který uživatelům říká, že dané nasazení je plně využité v určitém okamžiku. Poskytnutím rychlé odpovědi na selhání máte kontrolu nad tím, jak tyto situace řídit způsobem, který nejlépe vyhovuje požadavkům vaší aplikace.

Hlavičky retry-after-ms a retry-after v odpovědi vám řeknou, jak dlouho čekat, než bude přijato další volání. Způsob zpracování této odpovědi závisí na požadavcích vaší aplikace. Tady je několik aspektů:

  • Můžete zvážit přesměrování provozu na jiné modely, nasazení nebo prostředí. Tato možnost je řešením s nejnižší latencí, protože akce se dá provést, jakmile obdržíte signál 429. Nápady na efektivní implementaci tohoto vzoru najdete v tomto příspěvku komunity.
  • Pokud vám nevadí delší latence pro jednotlivé hovory, implementujte logiku opakování na straně klienta. Tato možnost poskytuje nejvyšší propustnost na PTU. Klientské knihovny Foundry zahrnují integrované funkce pro zpracování opakovaných pokusů.

Jak se služba rozhodne, kdy odeslat 429?

Ve všech zřízených typech nasazení se každý požadavek vyhodnocuje jednotlivě podle velikosti výzvy, očekávané velikosti generování a modelu, aby bylo možné určit očekávané využití. Toto chování je na rozdíl od standardních nasazení, která mají vlastní nastavení omezení rychlosti založené na odhadovaném zatížení provozu. U standardních nasazení může toto vlastní chování omezování rychlosti vést k chybám HTTP 429 před překročením definovaných hodnot kvót, pokud provoz není rovnoměrně distribuovaný.

Pro zřízená nasazení používáme variantu algoritmu děravého kbelíku, abychom zachovali využití pod 100 % a umožnili tak určitý nárazový růst provozu. Logika vysoké úrovně je následující:

  1. Každý zákazník má nastavenou kapacitu, kterou může využít při nasazení.

  2. Při podání žádosti:

    a. Pokud je aktuální využití vyšší než 100 %, vrátí služba kód 429 s retry-after-ms hlavičkou nastavenou na čas, dokud využití klesne pod 100 %

    b) V opačném případě služba odhaduje přírůstkovou změnu využití vyžadovanou k poskytování požadavku kombinací tokenů výzvy, odečtením jakýchkoli tokenů uložených v mezipaměti a zadané max_tokens při volání. Zákazník může získat až 100% slevu na "prompt" tokeny v závislosti na velikosti svých uložených tokenů v mezipaměti. max_tokens Pokud parametr není zadaný, služba odhaduje hodnotu. Tento odhad může vést k nižší souběžnosti, než se čekalo, když je počet generovaných tokenů malý. Pokud chcete zajistit nejvyšší souběžnost, ujistěte se, že max_tokens je hodnota co nejblíže velikosti skutečné generace.

  3. Po dokončení požadavku nyní známe skutečné náklady na výpočet volání. Abychom zajistili přesné účtování, opravíme využití pomocí následující logiky:

    a. Pokud je skutečný > hodnotou odhadnut, rozdíl se přidá k využití nasazení.

    b) Pokud je skutečná hodnota < vyšší než odhadovaná, rozdíl se odečte.

  4. Celkové využití se dekrementuje nepřetržitě na základě počtu nasazených PTU.

Poznámka:

Volání se přijímají, dokud využití nedosáhne 100 %. V krátkých obdobích mohou být povoleny výkyvy nad 100%, ale postupem času je váš provoz omezen na využití 100%.

Diagram znázorňující přidání následných volání do využití

Kolik souběžných volání můžu mít v nasazení?

Počet souběžných volání, kterých můžete dosáhnout, závisí na charakteristikách každého volání (velikost výzvy, max_tokens parametry atd.). Služba nadále přijímá volání, dokud využití nedosáhne 100 %. Pokud chcete určit přibližný počet souběžných volání, můžete v kalkulačce kapacity vymodelovat maximální počet požadavků za minutu pro určitý obrazec volání. Pokud systém vygeneruje méně než počet výstupních tokenů nastavených pro max_tokens parametr, bude zřízené nasazení přijímat více požadavků.

Možnost zřízené propustnosti pro modely prodané přímo v Azure

Tato část obsahuje seznam modelů Foundry, které podporují zřízenou propustnost. Můžete použít kvótu PTU a rezervaci PTU napříč modely zobrazenými v tabulce.

Tady jsou některé důležité poznatky z tabulky:

  • Verze modelu není součástí této tabulky. Při výběru možnosti nasazení na portálu Foundry zkontrolujte verzi podporovanou pro každý model.

  • Možnost nasazení místní zřízené propustnosti se liší podle oblasti.

  • Nové modely prodané přímo prostřednictvím Azure jsou nejprve připojeny s možností nasazení globální zřízené propustnosti. Možnost Poskytnutá zóna dat bude dostupná později.

  • PTU se spravují regionálně a podle typu nabídky. Kvóta PTU a všechny rezervace musí být v oblasti a formátu (globální, zóna dat, regionální), kterou chcete použít.

  • Přelití je volitelná funkce, která spravuje kolísání provozu ve zřízených nasazeních. Další informace o přelévání najdete v tématu Správa provozu s přeléváním pro zřízená nasazení.

Modelová řada Název modelu Globálně zajištěno Zřízená datová zóna Zajištěno regionálně Funkce přelivu
Azure OpenAI GPT 5 ✅ ✅ ✅
Gpt 4.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 ✅
DeepSeek-R1-0528 ✅

Dostupnost oblastí pro zřízenou propustnost

Globální dostupnost modelu zřízené propustnosti

Oblast gpt-5.1, 2025-11-13 gpt-5.1-codex, 2025-11-13 gpt-5, 2025-08-07 gpt-5-mini, 2025-08-07 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-01-31 o1, 2024-12-17 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o, 2024-11-20 gpt-4o-mini, 2024-07-18
Austrálie - východ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Jižní Brazílie ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
kanadacentral ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
východní Kanada ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
centrálus ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Eastus ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
eastus2 ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
franciecentral ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Německo – středozápad ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
itálie sever ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
japaneast ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
koreacentral ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
northcentralus ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Norsko – východ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
polskocentral ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Jižní Afrika – sever ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
southcentralus ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
jihovýchodní Asie ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Jižní Indie ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
SpainCentral ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Sweden Central ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Švýcarsko – sever ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
Švýcarsko západ ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uaenorth ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
uksouth ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
západní evropa ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅
westus3 ✅ - ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅

Poznámka:

Poskytnutá verze gpt-4Verze:turbo-2024-04-09 je v současné době omezena pouze na text.

Související obsah

  • Last updated on