Rezerwowanie przydzielonej przepustowości w interfejsach API Foundation Model

Ta strona wyjaśnia zarezerwowaną, provisionowaną przepustowość dla Foundation Model APIs: czym ona jest, kiedy z niej korzystać, jak dobrać rozmiar rezerwacji oraz jak tworzyć i zarządzać punktem końcowym, który z niej korzysta.

Czym jest zarezerwowana aprowizowana przepustowość?

Zarezerwowana aprowizowana przepustowość to opcja pojemnościowa dla interfejsów API usługi Azure Databricks Foundation Model APIs. Zamiast korzystać z wariantu rozliczanego za token, który korzysta ze wspólnej puli pojemności, rezerwujesz stałą ilość dedykowanej pojemności na określony czas. Mierzysz tę pojemność w jednostkach modelu, a Azure Databricks przechowuje ją dla ciebie przez cały czas trwania rezerwacji.

Ponieważ pojemność jest dedykowana i zarezerwowana z góry, przepustowość i opóźnienia pozostają stałe dla tej pojemności, nawet gdy ogólne zapotrzebowanie we współdzielonym modelu płatności za token jest wysokie. Ruch powyżej Twojej zarezerwowanej pojemności jest ograniczany przepustowościowo i nie jest obsługiwany automatycznie w modelu pay-per-token. Aby wysłać ten nadmiar do pay-per-token zamiast go odrzucać, skonfiguruj mechanizm awaryjny w usłudze modelu przed punktem końcowym. Zobacz Obsługuj ruch powyżej zarezerwowanej pojemności.

Kiedy używać zarezerwowanej aprowizowanej przepustowości

Zarezerwowana aprowizowana przepustowość jest zaprojektowana dla obciążeń wymagających gwarantowanej przepustowości, a nie dostępu do wspólnej puli opartej na najlepszych wysiłkach. Databricks zaleca to, gdy:

• Obsługujesz aplikację lub agenta krytycznego dla biznesu, gdzie funkcja w środowisku produkcyjnym zależy od modelu i nie może konkurować z innym ruchem o współdzieloną przepustowość.
• Potrzebujesz bardziej spójnej dostępności i czasu bezawaryjnej pracy niż we współdzielonym modelu płatności za token, więc duże zapotrzebowanie na wspólną pulę ma mniejszy wpływ na przepustowość.
• Skalujesz się do dużych lub utrzymujących się wolumenów przewidywalnego ruchu i osiągasz ograniczenia pojemności lub limitu szybkości dla płatności za token lub priorytetowej płatności za token.

Jeśli Twój ruch jest eksploracyjny lub o niskim wolumenie, zobacz pay-per-token lub priority pay-per-token.

Obsługiwane modele

Zarezerwowana aprowizowana przepustowość jest dostępna dla obsługiwanych modeli bazowych. Usługa Azure Databricks określa kwalifikowalność dla poszczególnych modeli, a w procesie tworzenia są wyświetlane tylko modele, które możesz zarezerwować.

Zarezerwowana przydzielona przepustowość jest dostępna dla następujących modeli:

Jak działa zarezerwowana aprowizowana przepustowość

Rezerwujesz pojemność w jednostkach modelowych. Jednostka modelu to jednostka aprowizowanej przepustowości, która określa, ile pracy Twój punkt końcowy może wykonać na minutę. Więcej jednostek modelu oznacza większą przepustowość zarezerwowaną dla Ciebie. Rezerwujesz jednostki modelowe w krokach po 50, zaczynając od minimum 50.

Rezerwację tworzysz, wybierając, ile jednostek modelu chcesz zarezerwować i na jak długo (okres). Azure Databricks zapewnia tę dedykowaną pojemność na cały okres. Punkt końcowy może mieć więcej niż jedną rezerwację jednocześnie, a jego całkowita zarezerwowana pojemność to suma jednostek modelu na aktywnych rezerwacjach.

Następujące terminy opisują elementy zarezerwowanego punktu końcowego z aprowizowaną przepustowością:

Zdecyduj, ile zarezerwować

To, ile jednostek modelu zarezerwujesz, zależy od Ciebie. Możesz przenieść cały zakres pracy na dedykowaną przepustowość lub zarezerwować mniej, a nadmiar przenieść do płatności za token z mechanizmem awaryjnym (zobacz Obsługa ruchu powyżej zarezerwowanej przepustowości):

• Zarezerwuj baseline i wyślij piki do mechanizmu rezerwowego. Zarezerwuj wystarczająco dużo jednostek modelu, by pokryć stały, codzienny ruch, i skonfiguruj mechanizm awaryjny, by skoki ruchu powyżej tego poziomu były rozliczane w modelu pay-per-token. Zobowiązujesz się do mniejszej przepustowości i płacisz za token tylko za nadmiar, w zamian za współdzieloną przepustowość w modelu best effort podczas tych skoków obciążenia.
• Zarezerwuj na czas szczytu. Zarezerwuj wystarczająco dużo jednostek modelu, aby pokryć najwyższe przewidywane obciążenie, tak aby całe obciążenie robocze działało na dedykowanej przepustowości. Daje to najbardziej spójne zachowanie, w zamian za większe zobowiązanie.

Tak czy inaczej, przekładasz swoje obciążenie na jednostki modelu za pomocą wbudowanego narzędzia Estimate model units w przepływie Create. Wprowadź oczekiwany kształt żądania, a estymator zwraca potrzebne jednostki modelu:

• Liczba żądań na minutę, jakiej się spodziewasz.
• Średnia liczba tokenów wejściowych na żądanie.
• Średnia liczba tokenów wyjściowych na żądanie.
• Oczekiwany współczynnik trafień pamięci podręcznej.

Aby określić wartość bazową, wpisz typowy ruch. Aby zarezerwować zasoby na okres szczytowego obciążenia, wprowadź oczekiwany największy ruch, którego się spodziewasz. Możesz uruchamiać estymator ile chcesz, zanim zatwierdzisz.

Zarezerwowana aprowizowana przepustowość w porównaniu do płatności za token

Zarezerwowana przepustowość i rozliczanie za token wzajemnie się uzupełniają, a nie wykluczają. Możesz zarezerwować dedykowaną pojemność dla głównego ruchu i skonfigurować mechanizm awaryjny z rozliczaniem za token dla wszystkiego poza zarezerwowaną pulą. Poniższa tabela pokazuje, gdzie każda opcja się mieści.

Jak działa cena

Opłata za zarezerwowaną aprowizowaną przepustowość jest naliczana na podstawie zarezerwowanej wydajności, a nie liczby wysyłanych żądań. Jesteś obciążany za cały okres rezerwacji na cały okres pobytu, niezależnie od tego, czy korzystasz z zarezerwowanej pojemności.

• Dłuższy okres wiąże się z niższą stawką za jednostkę niż krótszy.
• Gdy endpoint posiada rezerwacje o różnych okresach jednocześnie, każda jest wyceniana niezależnie według własnej stawki.
• Konkretne stawki zależą od modelu i terminu.

Zanim zaczniesz

Utworzenie zarezerwowanego punktu przepustowego

Tworzysz zarezerwowaną aprowizowaną przepustowość z Unity Gateway.

1. W Unity Gateway wybierz + Model.

2. Podaj nazwę usługi modelu.

3. Dla Destination wybierz provisioned throughput, a następnie wybierz link, aby utworzyć nowy punkt końcowy obsługi w obszarze roboczym. Otwiera się okno dialogowe Skonfiguruj punkt końcowy provisioned throughput.

   

4. Wybierz odpowiedni model bazowy.

5. Ustaw jednostki modelowe, w krokach po 50. Aby określić rozmiar puli, wybierz Oszacuj jednostki modelu, wprowadź oczekiwane obciążenie (żądania na minutę, średnie tokeny wejściowe i wyjściowe na jedno żądanie oraz oczekiwany wskaźnik trafień pamięci podręcznej), a estymator zwraca potrzebne jednostki modelu. Zobacz Jak zdecydować, ile zarezerwować.

   

6. Wybierz okres rezerwacji: 1 miesiąc lub 3 miesiące. Dłuższy okres wiąże się z niższą stopą procentową za jednostkę.

7. Przejrzyj jednostki modelu i warunek, a następnie stwórz endpoint. Azure Databricks zapewnia dedykowaną pojemność.

Widok i monitorowanie

Strona szczegółów punktu końcowego zawiera sekcję Aktywna konfiguracja z nagłówkiem Zarezerwowana aprowizowana przepustowość, która zawiera listę zarezerwowanych jednostek modelu oraz okres obowiązywania, datę wygaśnięcia i status każdej rezerwacji. Gdy punkt końcowy ma wiele skumulowanych rezerwacji wynikających ze skalowania lub uaktualnień, są one wyświetlane jako lista.

Zakładka Metryki pokazuje standardową telemetrię serwowania, w tym żądania na minutę, liczbę błędów, opóźnienia (p50, p90, p95 i p99), liczbę tokenów oraz czas do pierwszego tokena, dzięki czemu możesz obserwować zużycie i decydować, kiedy skalować.

Zwiększ pojemność

Aby dodać wydajność, otwórz Edytuj>Dodaj wydajność, wprowadź liczbę jednostek modelu do dodania (w krokach po 50) i wybierz termin. To tworzy nową rezerwację nakładającą się na Twoje istniejące rezerwacje. Nie modyfikuje ani nie przerywa tego, co już masz. Na stronie szczegółów wyświetlana jest każda rezerwacja, a każda z nich wygasa zgodnie z własnym harmonogramem.

Wygaśnięcie

• Po wygaśnięciu zarezerwowana pula przepada. Ruch jest wtedy obsługiwany jak każdy ruch powyżej Twojej zarezerwowanej pojemności: trafia do skonfigurowanego mechanizmu zapasowego pay-per-token lub podlega ograniczeniu szybkości, jeśli nie masz mechanizmu zapasowego. Zobacz Obsługuj ruch powyżej zarezerwowanej pojemności.
• Aby zachować zarezerwowaną pojemność po zakończeniu okresu, utwórz nową rezerwację przed wygaśnięciem obecnej. Zobacz Zwiększanie pojemności.
• Wygasłe rezerwacje pozostają widoczne dzięki wygasłemu identyfikatorowi i są zachowywane, a nie usuwane.

Obsługuj ruch przekraczający zarezerwowaną pojemność

Zarezerwowany punkt końcowy z aprowizowaną przepustowością obsługuje ruch wyłącznie z Twojej zarezerwowanej przepustowości. Azure Databricks nie kieruje nadmiaru automatycznie do pay-per-token. Gdy ruch przekracza Twoją zarezerwowaną przepustowość, czy to w wyniku nagłego skoku ruchu, czy wygaśnięcia rezerwacji, te żądania są odrzucane z błędem przekroczenia limitu liczby żądań.

Aby nadal obsługiwać ten ruch nadmiarowy, skonfiguruj mechanizm rezerwowy w usłudze modelu Unity Gateway przed swoim punktem końcowym. Ustaw punkt końcowy z zarezerwowaną aprowizowaną przepustowością jako główny cel i punkt końcowy płatności za token lub priorytetowy punkt końcowy płatności za token jako opcję zapasową. Gdy zarezerwowany punkt końcowy zwraca błąd limitu liczby żądań, usługa modelu ponawia próbę wykonania żądania względem zapasowego punktu docelowego, więc obciążenie robocze nadal działa, a płacisz za każdy token tylko w przypadku nadmiarowego ruchu.

Kroki konfiguracji znajdziesz w sekcji Konfiguruj routing i mechanizmy awaryjne dla modeli.

Ograniczenia

• W bieżącej wersji można utworzyć jeden punkt końcowy zarezerwowanej aprowizowanej przepustowości dla każdego modelu i dla każdego obszaru roboczego.
• Rezerwacje są opłacane z góry i obowiązują przez cały okres rezerwacji. Nie możesz anulować rezerwacji w trakcie procesu.
• Nie możesz usunąć punktu końcowego, który ma aktywną rezerwację, dopóki rezerwacja się nie zakończy.
• Użytkownicy bez MANAGE do modelu widzą widoki tylko do odczytu.

Więcej informacji o limitach interfejsów API modeli bazowych znajdziesz w dokumencie Limity i przydziały interfejsów API modeli bazowych.

Dodatkowe zasoby

• Priorytetowe rozliczanie za token dla interfejsów API modeli podstawowych
• Dokumentacja interfejsu API REST modelu podstawowego
• uprawnienia modelu podstawowego w Unity Catalog
• API bazowego modelu Databricks