Sdílet prostřednictvím


Co je zřízená propustnost?

Funkce zřízené propustnosti umožňuje zadat požadovanou propustnost v nasazení. Služba pak přidělí potřebnou kapacitu zpracování modelu a zajistí, že je pro vás připravená. Propustnost se definuje z hlediska zřízených jednotek propustnosti (PTU), což je normalizovaný způsob reprezentace propustnosti pro vaše nasazení. Každý pár verze modelu vyžaduje k nasazení a poskytování různých objemů propustnosti na PTU různé množství PTU.

Jaký typ zřízeného nasazení poskytuje?

  • Předvídatelný výkon: stabilní maximální latence a propustnost pro jednotné úlohy
  • Rezervovaná 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.

Nasazení Azure OpenAI je jednotka správy pro konkrétní model OpenAI. Nasazení poskytuje zákazníkům přístup k modelu pro odvozování a integruje další funkce, jako je moderování obsahu (viz dokumentace ke con režim stanu ration).

Poznámka:

Kvóta zřízené jednotky propustnosti (PTU) se liší od standardní kvóty v Azure OpenAI a ve výchozím nastavení není dostupná. Další informace o této nabídce získáte od týmu účtu Microsoft.

Jaký výsledek dostanete?

Téma Zřízené
Co je to? Poskytuje garantovanou propustnost při menších přírůstcích než stávající zřízená nabídka. Nasazení mají konzistentní maximální latenci pro danou verzi modelu.
Pro koho to je? Zákazníci, kteří chtějí garantovanou propustnost s minimální odchylkou latence.
Kvóta Zřízené jednotky propustnosti spravované pro daný model
Latence Maximální latence omezená z modelu. Celková latence je faktorem tvaru volání.
Využití Míra využití zřízeného spravovaného prostředí poskytovaná ve službě Azure Monitor
Odhad velikosti Poskytuje kalkulačku ve skriptu studio a srovnávací testy.

Návody získat přístup ke zřízení?

Abyste získali zřízenou propustnost, musíte mluvit se svým prodejním týmem Nebo týmem účtů Microsoftu. Pokud nemáte prodejní nebo obchodní tým, bohužel v tuto chvíli nemůžete zakoupit zřízenou propustnost.

Jaké modely a oblasti jsou k dispozici pro zřízenou propustnost?

Oblast gpt-4, 0613 gpt-4, 1106-Preview gpt-4, 0125-Preview gpt-4, turbo-2024-04-09 gpt-4o, 2024-05-13 gpt-4-32k, 0613 gpt-35-turbo, 1106 gpt-35-turbo, 0125
australiaeast
brazilsouth - - -
canadacentral - - - - -
canadaeast - - -
eastus -
eastus2 -
francecentral - -
Německo – středozápad - -
japaneast - - -
koreacentral - - -
northcentralus -
Norsko – východ - - - - -
polskocentral - -
Jižní Afrika – sever - - - -
Střed USA – jih
southindia -
swedencentral
switzerlandnorth
switzerlandwest - - - - - - -
uksouth -
westus
westus3

Poznámka:

Zřízená verze gpt-4 : turbo-2024-04-09 v současné době je omezena pouze na text.

Klíčové koncepty

Zřízené jednotky propustnosti

Zřízené jednotky propustnosti (PTU) jsou jednotky kapacity zpracování modelu, které si můžete rezervovat a nasadit pro zpracování výzev a generování dokončení. Minimální nasazení PTU, přírůstky a kapacita zpracování přidružené ke každé jednotce se liší podle typu modelu a verze.

Typy nasazení

Při nasazování modelu v Azure OpenAI je potřeba nastavit sku-name , aby byla zřízená a spravovaná. Určuje sku-capacity počet PTU přiřazených k nasazení.

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

Kvóta zřízené propustnosti představuje konkrétní množství celkové propustnosti, kterou můžete nasadit. Kvóta ve službě Azure OpenAI se spravuje na úrovni předplatného. Všechny prostředky Azure OpenAI v rámci předplatného sdílejí tuto kvótu.

Kvóta se zadává v jednotkách zřízené propustnosti a je specifická pro triplet (typ nasazení, model, oblast). Kvóta není zaměnitelná. To znamená, že nemůžete použít kvótu pro GPT-4 k nasazení GPT-3.5-Turbo.

I když se snažíme zajistit, aby byla kvóta nasaditelná, nepředstavuje kvótu záruku dostupnosti základní kapacity. Služba přiřazuje kapacitu během operace nasazení a pokud je kapacita nedostupná, nasazení selže s chybou kvůli výpadku kapacity.

Určení počtu PTU potřebných pro úlohu

PTU představují množství kapacity zpracování modelu. Podobně jako v počítači nebo databázích budou různé úlohy nebo požadavky na model spotřebovávat různé objemy základní kapacity zpracování. Převod z charakteristik obrazce volání (velikost výzvy, velikost generování a rychlost volání) na PTU je složitý a nelineární. Pokud chcete tento proces zjednodušit, můžete pomocí kalkulačky kapacity Azure OpenAI určit velikost konkrétních obrazců úloh.

Několik důležitých informací na vysoké úrovni:

  • Generace vyžadují větší kapacitu než výzvy.
  • Větší volání jsou pro výpočty postupně dražší. Například 100 volání s velikostí výzvy 1000 tokenů bude vyžadovat menší kapacitu než 1 volání s 100 000 tokeny na příkazovém řádku. To také znamená, že rozdělení těchto obrazců volání je důležité v celkové propustnosti. Vzorce provozu s širokou distribucí, která zahrnuje některé velmi velké volání, můžou mít nižší propustnost na PTU než užší distribuci se stejnými průměrnými velikostmi tokenů výzvy a dokončení.

Jak funguje výkon využití

Zřízená nasazení poskytují přidělené množství kapacity zpracování modelu pro spuštění daného modelu.

Při překročení kapacity v nasazeních spravovaných službou Provisioned-Managed rozhraní API okamžitě vrátí chybu stavu HTTP 429. To uživateli umožňuje rozhodovat se, jak spravovat provoz. Uživatelé můžou žádosti přesměrovat na samostatné nasazení, na standardní instanci s průběžnými platbami nebo využít strategii opakování ke správě dané žádosti. Služba bude dál vracet stavový kód HTTP 429, dokud využití klesne pod 100 %.

Jak můžu monitorovat kapacitu?

Metrika zřízeného využití spravovaného prostředí V2 ve službě Azure Monitor měří dané využití nasazení na 1minutových přírůstcích. Zřízená spravovaná nasazení jsou optimalizovaná, aby se zajistilo, že se akceptovaná volání zpracovávají s konsis režim stanu l čas zpracování (skutečná kompletní latence závisí na charakteristikách volání).

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

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

retry-after Hlavičky retry-after-ms a hlavičky v odpovědi vám řeknou, že je čas čekat, než se přijme 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 máte v pořádku delší latenci volání, implementujte logiku opakování na straně klienta. Tato možnost poskytuje nejvyšší propustnost na PTU. Klientské knihovny Azure OpenAI zahrnují integrované funkce pro zpracování opakovaných pokusů.

Jak se služba rozhodne, kdy odeslat 429?

V nabídce Zřízené spravované se každá žádost 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í. To je na rozdíl od nasazení s průběžným platbami, která mají vlastní chování omezování rychlosti na základě odhadovaného zatížení provozu. U nasazení s průběžným platbami to může vést k vygenerování http 429 před překročením definovaných hodnot kvót, pokud provoz není rovnoměrně distribuovaný.

U zřízených spravovaných prostředků používáme variantu algoritmu pro únik kbelíků, abychom zachovali využití nižší než 100 % a umožnili tak určité nárůsty 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 provedení žá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 doručení požadavku kombinováním tokenů výzvy a zadaných max_tokens ve volání. max_tokens Pokud parametr není zadaný, služba odhadne 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 teď známe skutečné náklady na výpočetní prostředky volání. Abychom zajistili přesné účtování, opravíme využití pomocí následující logiky:

    a. Pokud je skutečný > odhad, přidá se rozdíl do využití nasazení b. Pokud se skutečný < odhad odečte, rozdíl se odečte.

  4. Celkové využití se snižuje 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 %. Nárůsty se možná za 100 % povolují v krátkých obdobích, ale v průběhu času je provoz omezený na 100% využití.

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é můžete dosáhnout, závisí na obrazci každého volání (velikost výzvy, max_token parametr atd.). Služba bude nadále přijímat 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 generuje méně než počet tokenů vzorkování, jako je max_token, přijme více požadavků.

Další kroky