Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga / Notatka
Aby uzyskać więcej informacji na temat najnowszych zmian w ofercie aprowizowanej przepływności, zobacz artykuł dotyczący aktualizacji , aby uzyskać więcej informacji.
Oferta aprowizowanej przepływności usługi Azure AI Foundry to typ wdrożenia modelu, który umożliwia określenie wymaganej przepływności we wdrożeniu modelu. Usługa Azure AI Foundry przydziela następnie niezbędną pojemność przetwarzania modelu i zapewnia, że jest gotowa. Możesz użyć przydzielonej przepustowości żądanej w ramach zróżnicowanego portfolio modeli sprzedawanych bezpośrednio przez Azure. Modele te obejmują modele usługi Azure OpenAI i nowo wprowadzone flagowe rodziny modeli, takie jak Azure DeepSeek, Azure Grok, Azure Llama i inne w ramach modeli usługi Azure AI Foundry.
Aprowizowana przepływność zapewnia:
- Szerszy wybór modeli w najnowszych flagowych modelach
- Elastyczność przełączania modeli i wdrożeń przy użyciu podanego aprowizowanego limitu przydziału przepływności
- Znaczące rabaty i możliwość zwiększenia wykorzystania rezerwacji dzięki bardziej elastycznemu wyborowi rezerwacji
- Przewidywalna wydajność dzięki zapewnieniu stabilnego maksymalnego opóźnienia i przepływności dla jednolitych obciążeń.
- Przydzielona pojemność przetwarzania: wdrożenie konfiguruje ilość przepływności. Po wdrożeniu przepływność jest dostępna niezależnie od tego, czy jest używana, czy nie.
- Oszczędności kosztów: obciążenia o wysokiej przepływności mogą zapewnić oszczędności kosztów w porównaniu do konsumpcji opartej na tokenach.
Wskazówka
- Możesz skorzystać z większej oszczędności w przypadku zakupu rezerwacji aprowizowanej przepływności rozwiązania Microsoft Azure AI Foundry.
- Aprowizowana przepływność jest dostępna jako następujące typy wdrożeń: aprowizowana globalnie, strefa danych aprowizowana i aprowizowana regionalnie.
Kiedy należy używać aprowizowanej przepływności
Należy rozważyć przejście z wdrożeń standardowych do wdrożeń aprowizowanej przepływności, jeśli masz dobrze zdefiniowane, przewidywalne wymagania dotyczące przepływności i opóźnień. Zazwyczaj dzieje się tak, gdy aplikacja jest gotowa do produkcji lub jest już wdrożona w środowisku produkcyjnym i istnieje wiedza na temat oczekiwanego ruchu. Dzięki temu użytkownicy mogą dokładnie prognozować wymaganą pojemność i unikać nieoczekiwanych rozliczeń. Wdrożenia z zarezerwowaną przepustowością są również przydatne dla aplikacji, które mają wymagania dotyczące pracy w czasie rzeczywistym lub wrażliwe na opóźnienia.
Najważniejsze pojęcia
W poniższych sekcjach opisano kluczowe pojęcia, które warto znać podczas korzystania ze świadczenia przepustowości.
Aprowizowanie jednostek przepływności (PTU)
Jednostki aprowizowanego przepustowości (PTU) to ogólne jednostki wydajności przetwarzania modelu, których można użyć do rozmiaru aprowizowanych wdrożeń, aby zapewnić wymaganą przepustowość dla przetwarzania poleceń i generowania zakończeń. Jednostki przepustowości są przydzielane subskrypcji jako limit i używane do definiowania kosztów. Każdy limit jest specyficzny dla regionu i definiuje maksymalną liczbę jednostek PTU, które można przypisać do wdrożeń w tej subskrypcji i regionie.
Zarządzanie kosztami w kontekście wspólnej rezerwacji PTU
Funkcja PTU umożliwia bezproblemowe zarządzanie kosztami Modeli Foundry w ramach wspólnej rezerwacji PTU. Jednak wymagane jednostki PTU do wdrażania i wydajności przepustowości są dynamicznie dostosowywane do wybranych modeli. Aby dowiedzieć się więcej na temat kosztów jednostek PTU i punktów opóźnienia modelu, zobacz Omówienie kosztów związanych z PTU.
Istniejące rezerwacje PTU są automatycznie uaktualniane w celu zwiększenia wydajności i oszczędności kosztów klientów podczas wdrażania modeli rozwiązania Foundry. Załóżmy na przykład, że masz istniejącą rezerwację na 500 zakupionych jednostek PTU. Używasz 300 jednostek dla modeli Azure OpenAI i wybierasz również użycie PTU do wdrażania modeli Azure DeepSeek, Azure Llama lub innych modeli ze zdolnością PTU na platformie Foundry Models.
Jeśli używasz pozostałych 200 PTU dla DeepSeek-R1, 200 PTU automatycznie dzieli rabat na rezerwację, a łączne użycie rezerwacji wynosi 500 PTU.
Jeśli używasz 300 PTU dla DeepSeek-R1, 200 PTU współdzieli rabat na rezerwację automatycznie, podczas gdy 100 PTU przekracza rezerwację i naliczana jest stawka godzinowa DeepSeek-R1.
Aby dowiedzieć się więcej na temat oszczędzania kosztów dzięki rezerwacjam jednostek PTU, zobacz Oszczędzanie kosztów za pomocą rezerwacji aprowizowanej przepływności rozwiązania Microsoft Azure AI Foundry.
Typy wdrożeń
Podczas tworzenia aprowizowanego wdrożenia w narzędziu Azure AI Foundry typ wdrożenia w oknie dialogowym "Tworzenie wdrożenia" można ustawić na globalną aprowizowaną przepływność, aprowizowaną przepływność strefy danych lub typ wdrożenia aprowizowanej przepływności regionalnej w zależności od potrzeb przetwarzania danych dla danego obciążenia.
Podczas tworzenia aprowizowanego wdrożenia w Azure AI Foundry przy użyciu CLI lub interfejsu API można ustawić sku-name
na GlobalProvisionedManaged
, DataZoneProvisionedManaged
lub ProvisionedManaged
, w zależności od potrzeb dotyczących przetwarzania danych dla danego obciążenia.
Typ wdrożenia | sku-name w interfejsie wiersza polecenia |
---|---|
Globalna zarezerwowana przepustowość | GlobalProvisionedManaged |
Aprowizowana przepływność strefy danych | DataZoneProvisionedManaged |
Regionalnie przydzielona przepustowość | Udostępniony zarządzany |
Aby dostosować następujące przykładowe polecenie interfejsu wiersza polecenia platformy Azure do innego typu wdrożenia, zaktualizuj sku-name
parametr, aby był zgodny z typem wdrożenia, który chcesz wdrożyć.
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
Przejrzystość wydajności
Modele sprzedawane bezpośrednio przez platformę Azure to bardzo poszukiwane usługi, w których zapotrzebowanie klientów może przekroczyć pojemność procesora GPU usługi. Firma Microsoft stara się zapewnić pojemność dla wszystkich regionów i modeli na żądanie, ale sprzedaż w regionie jest zawsze możliwa. To ograniczenie może ograniczyć zdolność niektórych klientów do utworzenia wdrożenia żądanego modelu, wersji lub liczby jednostek PTU w wybranym regionie, mimo że mają dostępny przydział w tym regionie. Ogólnie rzecz biorąc:
- Limit przydziału powoduje ograniczenie maksymalnej liczby jednostek PTU, które można wdrożyć w subskrypcji i regionie, i nie gwarantuje dostępności pojemności.
- Pojemność jest przydzielana w czasie wdrażania i jest przechowywana tak długo, jak istnieje wdrożenie. Jeśli pojemność usługi jest niedostępna, wdrożenie zakończy się niepowodzeniem.
- Klienci używają informacji w czasie rzeczywistym na temat dostępności limitu przydziału/pojemności, aby wybrać odpowiedni region dla swojego scenariusza z niezbędną pojemnością modelu.
- Skalowanie w dół lub usuwanie wdrożenia zwalnia pojemność z powrotem do regionu. Nie ma gwarancji, że pojemność będzie dostępna, jeśli wdrożenie zostanie przeskalowane w górę lub utworzone ponownie później.
Wskazówki dotyczące pojemności regionalnej
Aby znaleźć pojemność potrzebną do ich wdrożeń, użyj interfejsu API pojemności lub środowiska wdrażania rozwiązania Azure AI Foundry, aby zapewnić informacje w czasie rzeczywistym dotyczące dostępności pojemności.
W rozwiązaniu Azure AI Foundry środowisko wdrażania określa, kiedy region nie ma pojemności wymaganej do wdrożenia modelu. Dotyczy to pożądanego modelu, wersji i liczby PTU. Jeśli pojemność jest niedostępna, system przekierowuje użytkowników do wyboru alternatywnego regionu.
Szczegółowe informacje na temat środowiska wdrażania można znaleźć w przewodniku Wprowadzenie do usługi Azure AI Foundry Provisioned.
Interfejs API pojemności modelu może służyć do programowego identyfikowania maksymalnego rozmiaru wdrożenia określonego modelu. Interfejs API uwzględnia zarówno limit przydziału, jak i pojemność usługi w regionie.
Jeśli akceptowalny region nie jest dostępny do obsługi żądanego modelu, wersji i/lub jednostki PTU, klienci mogą również spróbować wykonać następujące czynności:
- Próba wdrożenia z mniejszą liczbą PTU.
- Próba wdrożenia w innym czasie. Dostępność pojemności zmienia się dynamicznie na podstawie zapotrzebowania klientów, a większa pojemność może stać się dostępna później.
- Upewnij się, że limit przydziału jest dostępny we wszystkich akceptowalnych regionach. Interfejs API pojemności modelu i środowisko usługi Azure AI Foundry uwzględniają dostępność limitu przydziału w zwracaniu alternatywnych regionów do tworzenia wdrożenia.
Jak mogę monitorować pojemność?
Metryka aprowizowanego zarządzanego wykorzystania V2 w usłudze Azure Monitor mierzy wykorzystanie danego wdrożenia w przyrostach 1-minutowych. Wszystkie dostarczone typy wdrożeń są zoptymalizowane, aby zapewnić, że zaakceptowane wywołania są przetwarzane z zachowaniem spójnego czasu przetwarzania modelu (rzeczywiste opóźnienie całkowite zależy od charakterystyki wywołania).
Jak działa wydajność wykorzystania
Aprowidowane wdrożenia zapewniają przydzieloną ilość pojemności przetwarzania modelu w celu uruchomienia danego modelu.
We wszystkich typach wdrożeń aprowizowanych po przekroczeniu pojemności interfejs API zwraca błąd stanu HTTP 429. Szybka odpowiedź umożliwia użytkownikowi podejmowanie decyzji dotyczących zarządzania ruchem. Użytkownicy mogą przekierowywać żądania do oddzielnego wdrożenia, do standardowego wystąpienia wdrożenia lub zastosować strategię ponawiania prób do obsługiwania danego żądania. Usługa nadal zwraca kod stanu HTTP 429, dopóki wykorzystanie spadnie poniżej 100%.
Co należy zrobić, gdy otrzymuję odpowiedź 429?
Odpowiedź 429 nie jest błędem, ale zamiast tego jest częścią projektu informującego użytkowników, że dane wdrożenie jest w pełni wykorzystywane w danym momencie. Zapewniając szybką odpowiedź na niepowodzenia, masz kontrolę nad sposobem obsługi tych sytuacji w sposób, który najlepiej odpowiada wymaganiom aplikacji.
Nagłówki retry-after-ms
i retry-after
w odpowiedzi informują o czasie oczekiwania przed zaakceptowaniem następnego wywołania. Sposób obsługi tej odpowiedzi zależy od wymagań aplikacji. Oto kilka zagadnień:
- Możesz rozważyć przekierowanie ruchu do innych modeli, wdrożeń lub środowisk. Ta opcja jest rozwiązaniem o najniższym opóźnieniu, ponieważ akcję można podjąć natychmiast po otrzymaniu sygnału 429. Aby dowiedzieć się, jak skutecznie zaimplementować ten wzorzec, zobacz ten wpis społeczności.
- Jeśli nie przeszkadzają Ci dłuższe opóźnienia podczas wywołań, zaimplementuj logikę ponawiania po stronie klienta. Ta opcja zapewnia najwyższą przepływność na jednostkę PTU. Biblioteki klienta usługi Azure AI Foundry obejmują wbudowane funkcje do obsługi ponownych prób.
Jak usługa decyduje, kiedy wysłać 429?
We wszystkich typach wdrożeń przygotowanych każde żądanie jest oceniane indywidualnie na podstawie rozmiaru zapytań, oczekiwanego rozmiaru generacji i modelu, w celu określenia spodziewanego wykorzystania. To zachowanie jest w przeciwieństwie do wdrożeń standardowych, które mają dostosowane ograniczenia szybkości na podstawie szacowanego obciążenia ruchu. W przypadku standardowych wdrożeń, niestandardowe ograniczanie szybkości może prowadzić do generowania błędów HTTP 429 przed przekroczeniem zdefiniowanych wartości limitu, jeśli ruch nie jest równomiernie rozłożony.
W przypadku wdrożeń z aprowizacją używamy odmiany algorytmu przeciekającego kubełka, aby zachować wykorzystanie poniżej 100%, umożliwiając pewien wzrost ruchu. Logika wysokiego poziomu jest następująca:
Każdy klient ma określoną pojemność, którą może wykorzystać we wdrożeniu
Po wysłaniu żądania:
a. Gdy bieżące wykorzystanie przekracza 100%, usługa zwraca kod 429 z nagłówkiem
retry-after-ms
, który jest ustawiony na czas, w którym wykorzystanie spadnie poniżej 100%.b. W przeciwnym razie usługa szacuje przyrostową zmianę wykorzystania, która jest wymagana do obsługi żądania, poprzez połączenie aktywnych tokenów, mniej tokenów w pamięci podręcznej, oraz określonego parametru
max_tokens
w wywołaniu. Klient może otrzymać do 100% rabatu na swoje tokeny sugestyjne, w zależności od rozmiaru ich zachowanych tokenów.max_tokens
Jeśli parametr nie jest określony, usługa szacuje wartość. To oszacowanie może prowadzić do obniżenia współbieżności niż oczekiwano, gdy liczba rzeczywistych wygenerowanych tokenów jest mała. Aby osiągnąć najwyższą współbieżność, upewnij się, że wartośćmax_tokens
jest jak najbliższa rzeczywistej wielkości generacji.Po zakończeniu żądania mamy już wiedzę na temat rzeczywistego kosztu obliczeń związanych z tym wywołaniem. Aby zapewnić dokładną księgowość, poprawmy wykorzystanie przy użyciu następującej logiki:
a. Jeśli szacowany jest rzeczywisty > , różnica jest dodawana do wykorzystania wdrożenia.
b. Jeśli szacowana wartość rzeczywista < , różnica jest odejmowana.
Całkowite wykorzystanie jest zmniejszane w stałym tempie na podstawie liczby wdrożonych jednostek PTU.
Uwaga / Notatka
Połączenia są akceptowane, dopóki wykorzystanie osiągnie 100%. Przebicia nieco ponad 100% mogą być dozwolone w krótkich okresach, ale z upływem czasu twój ruch jest ograniczony do 100% wykorzystania.
Ile współbieżnych wywołań można mieć we wdrożeniu?
Liczba współbieżnych wywołań, które można osiągnąć, zależy od kształtu każdego wywołania (rozmiar monitu, max_tokens
parametr itp.). Usługa nadal akceptuje wywołania, dopóki wykorzystanie nie osiągnie 100%. Aby określić przybliżoną liczbę wywołań współbieżnych, można wymodelować maksymalne żądania na minutę dla określonego kształtu wywołania w kalkulatorze pojemności. Jeśli system generuje mniej niż liczba tokenów wyjściowych ustawionych dla parametru max_tokens
, aprowizowane wdrożenie będzie akceptować więcej żądań.
Przydzielona przepływność dla modeli sprzedawanych bezpośrednio przez Azure
W tej sekcji wymieniono modele Foundry, które obsługują zdolność do aprowizowanej przepustowości. Możesz użyć swojego limitu PTU i rezerwacji PTU dla modeli przedstawionych w tabeli.
Poniżej przedstawiono kilka ważnych wniosków z tabeli:
Wersja modelu nie jest uwzględniona w tej tabeli. Sprawdź wersję obsługiwaną dla każdego modelu po wybraniu opcji wdrożenia w portalu usługi Azure AI Foundry.
Opcja wdrażania aprowizowanej przepływności w regionie różni się w zależności od lokalizacji.
Nowe modele sprzedawane bezpośrednio przez platformę Azure są wprowadzane z opcją globalnego wdrażania przepustowości. Opcja przydzielania strefy danych pojawi się później.
PtU są zarządzane regionalnie i według typu oferty. Kwota PTU i wszelkie rezerwacje muszą znajdować się w regionie i typie (globalna, strefa danych, regionalna), którego chcesz użyć.
Spillover to opcjonalna funkcja, która zarządza wahaniami ruchu w przypadku wdrożeń z zarezerwowaną przepustowością. Aby uzyskać więcej informacji na temat rozlewania, zobacz Zarządzanie ruchem przy użyciu funkcji rozlewania dla aprowizowanych wdrożeń (wersja zapoznawcza).
Rodzina modeli | Nazwa modelu | Globalne przydzielenie zasobów | Przygotowana strefa danych | Zapewnienie regionalne | Funkcja przenikania |
---|---|---|---|---|---|
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 | ✅ | ||||
DeepSeek-R1-0528 | ✅ |
Dostępność regionu dla możliwości aprowizowanej przepływności
- Globalna aprowizowana przepływność
- Przydzielona przepustowość obszaru danych
- Aprowizowana przepływność regionalna
Globalna zapewniona dostępność modelu przepustowości
Region |
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 31.01.2025 |
o1 17-12-2024 |
gpt-4o 13.05.2024 |
gpt-4o 2024-08-06 |
gpt-4o 20.11.2024 |
gpt-4o-mini 18.07.2024 |
DeepSeek-R1 | DeepSeek-V3-0324 | DeepSeek-R1-0528 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
AustraliaEast | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Brazylia Południe | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
wschód Kanady | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
eastus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
eastus2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
francecentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Niemcy Zachodnio-Środkowe | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
północne Włochy | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
japaneast | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
koreacentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
northcentralus | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Norwegia Wschód | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
polandcentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
southafricanorth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
southcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
południowo-wschodnia Azja | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
południowe Indie | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Hiszpania Centralna | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
swedencentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Szwajcaria Północ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Szwajcaria Zachód | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
uaenorth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
uksouth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Europa Zachodnia | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
westus | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
westus3 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Uwaga / Notatka
Przygotowana wersja gpt-4
Wersja:turbo-2024-04-09
jest obecnie ograniczona tylko do tekstu.