Autoskalowanie SageMaker TTS zastępuje zgadywane cele zmierzonymi limitami
AWS opublikował przykład autoskalowania SageMaker TTS, który zastępuje zgadywane progi pomiarami endpointu, jednocześnie ujawniając ograniczenia, których automatyzacja nie jest w stanie usunąć. Opublikowany 22 października poradnik wdraża Kokoro-82M — model text-to-speech przekształcający tekst w dźwięk — w niestandardowym kontenerze. Jego kluczowe pytanie dotyczy pojemności: ile pracy może przyjąć instancja, podczas gdy uruchamia się kolejna?
Przykład wprowadza użyteczne rozróżnienie między konfiguracją automatycznego skalowania a potwierdzeniem, że jego ustawienia odpowiadają danemu obciążeniu. Cel poziomu usług, czyli SLO, definiuje obietnicę dotyczącą opóźnień. Współbieżność określa liczbę żądań oczekujących lub wykonywanych jednocześnie. Połączenie tych pomiarów daje zespołom infrastruktury uzasadniony próg, choć nie gwarantuje nieprzerwanej obsługi podczas każdego skoku ruchu.
Stawia to planowanie pojemności oparte na pomiarach w kontrze do znanego podejścia: wyboru pozornie wiarygodnego celu wykorzystania zasobów i dostosowywania go po incydentach. Amazon Polly stanowi punkt odniesienia dla zarządzanej usługi mowy, podczas gdy ten przykład dotyczy zespołów obsługujących własny model. Zachowują one kontrolę nad wdrożeniem, ale ponoszą też konsekwencje niewystarczającej pojemności. Presja spada na inżynierów, którzy muszą uzasadnić zarówno responsywność, jak i utrzymywaną stale infrastrukturę.
AWS zamienia ustawienie skalowania w testowalne twierdzenie
Zmianą jest opublikowany proces pomiarowy, a nie nowa obietnica, że automatyczne skalowanie eliminuje potrzebę planowania pojemności.
W swoim poradniku skalowania TTS AWS opisuje dwa kluczowe pomiary. Q_max określa najwyższą przetestowaną współbieżność na instancję, która spełnia cel opóźnienia. T_total obejmuje czas reakcji wykorzystywany przy planowaniu dodatkowej pojemności.
Opisane wdrożenie korzysta z instancji ml.g5.xlarge. Najwyższy poziom współbieżności spełniający wymagania wynosi 50 żądań przy celu 3 000 milisekund. Kolejny testowany poziom, 60, kończy się niepowodzeniem. Według AWS są to wyniki zależne od konkretnego obciążenia, a nie zalecane ustawienia domyślne dla każdego endpointu mowy.
To rozróżnienie zmienia sposób, w jaki recenzent powinien odczytywać konfigurację infrastruktury. Próg zwykle wygląda jak instrukcja dla kontrolera. Tutaj stanowi również twierdzenie o zaobserwowanym zachowaniu. Osoba recenzująca wdrożenie może zapytać, który test potwierdza to twierdzenie i czy nadal opisuje on działającą usługę.
Różnica ma znaczenie, gdy konfiguracja istnieje dłużej niż jej pierwotne założenia. Aktualizacja modelu może pozostawić politykę skalowania bez zmian. Modyfikacja kontenera może zmienić obsługę żądań bez zmiany nazwy endpointu. Zobowiązanie dotyczące opóźnień może zostać zaostrzone, podczas gdy stary cel pozostanie na miejscu.
W takich okolicznościach znane ustawienie staje się mylące. Jego obecność sugeruje, że ktoś już rozstrzygnął kwestię pojemności. W rzeczywistości stojące za nim dowody mogą opisywać inne wdrożenie. Pomiary dają zespołom sposób na podważenie tej pozornej pewności.
Wartość informacyjna tej wiadomości wynika więc z połączenia testowania z decyzjami wdrożeniowymi. AWS przedstawia konkretny przykład przekształcania zachowania endpointu w dane wejściowe dla polityki. Czytelnicy powinni oceniać go jako operacyjną implementację referencyjną, a nie niezależnie ustanowiony branżowy punkt odniesienia.
Istnieje również ograniczenie tego, co ustala przedstawiona drabina współbieżności. Poziom spełniający wymagania, po którym następuje poziom niespełniający wymagań, wyznacza granice testowanego limitu. Nie identyfikuje każdego możliwego punktu pracy pomiędzy nimi. Traktowanie wyniku jako przetestowanego limitu zachowuje to rozróżnienie, nie osłabiając jego praktycznej wartości.
Dla menedżerów inżynieryjnych bezpośrednia konsekwencja dotyczy jakości przeglądu. Zatwierdzenie konfiguracji skalowania powinno obejmować więcej niż sprawdzenie, czy automatyczne skalowanie jest włączone. Recenzent potrzebuje wystarczających dowodów, aby zrozumieć znaczenie celu, obciążenie, które go wyznaczyło, oraz to, co pozostaje poza jego zakresem.
To twierdzenie jest węższe niż obietnica uniwersalnej optymalizacji. Jest też bardziej użyteczne, gdy incydent zmusza zespół do wyjaśnienia, dlaczego infrastruktura zachowała się zgodnie z konfiguracją.
Niestandardowe wdrożenie mowy przenosi ryzyko pojemności na operatora
Kontrola nad modelem mowy oznacza odpowiedzialność za zachowanie systemu otaczającego ten model.
Karta modelu Kokoro opisuje model o otwartych wagach, z 82 milionami parametrów i wagami licencjonowanymi na zasadach Apache. Czyni go to konkretnym kandydatem dla zespołów oceniających wdrożenia, które obsługują samodzielnie. Opisy jakości i efektywności zawarte w karcie modelu pozostają deklaracjami wydawcy, a nie ustaleniami potwierdzonymi przez to ćwiczenie skalowania.
Sam wybór modelu nie może rozstrzygnąć decyzji produkcyjnej. Aplikacja potrzebuje też przewidywalnych odpowiedzi, użytecznej obsługi błędów oraz pojemności, która pojawia się, zanim popyt przeciąży usługę. Te wymagania należą do systemu obsługującego model.
Rozważmy hipotetycznego asystenta głosowego obsługującego zapytanie klienta. Generowanie mowy rozpoczyna się po tym, jak inne komponenty aplikacji wykorzystały już część budżetu odpowiedzi. Późna odpowiedź może sprawiać wrażenie awarii, nawet jeśli dźwięk ostatecznie nadejdzie i brzmi akceptowalnie.
Rozważmy teraz hipotetyczną usługę narracji przetwarzającą materiały w tle. To samo opóźnienie może być akceptowalne, jeśli zadanie zostanie ukończone przed terminem dostarczenia. Aplikacje te mogą używać podobnej technologii syntezy, a jednocześnie wymagać odmiennych polityk infrastrukturalnych.
Porównanie pokazuje, dlaczego ogólny cel skalowania daje ograniczone wskazówki. Operator musi zdecydować, jakie doświadczenie użytkownika obiecuje wdrożenie. Dopiero wtedy pomiar wydajności może odpowiedzieć, czy system wspiera tę obietnicę.
Procesor graficzny, czyli GPU, przyspiesza obliczenia modelu, lecz poziom jego aktywności jest pośrednim sygnałem doświadczenia użytkownika. Zajęty akcelerator nie wyjaśnia, jak długo oczekiwało konkretne żądanie. Niewykorzystany akcelerator nie dowodzi, że każde żądanie otrzymało odpowiedź w odpowiednim czasie.
W przypadku autoskalowania SageMaker TTS wywiera to presję na kilka ról. Inżynierowie platformowi potrzebują użytecznego sygnału sterującego. Twórcy aplikacji potrzebują jasno określonego zachowania, gdy pojemność się wyczerpie. Właściciele produktu potrzebują zobowiązania dotyczącego opóźnień, które odpowiada rzeczywistym doświadczeniom użytkowników.
Zespoły finansowe stoją przed drugą stroną tej samej decyzji. Dodatkowa stale utrzymywana pojemność tworzy ciągłe zobowiązanie zasobowe. Jej usunięcie przenosi większą odpowiedzialność na zdolność systemu do wykrywania popytu i odzyskiwania sprawności. Żadna z tych decyzji nie staje się neutralna tylko dlatego, że kontroler wykonuje ją automatycznie.
Istotną alternatywą jest synteza zarządzana. Zarządzana usługa mowy Amazon obsługuje generowanie mowy dla aplikacji takich jak czytniki wiadomości, platformy edukacyjne i narzędzia dostępności. Stanowi to alternatywę wdrożeniową, ale nie przesądza o przewadze jakości ani opóźnień nad Kokoro.
Rzetelne porównanie powinno zbadać, kto odpowiada za poszczególne obowiązki. Zespół wybierający niestandardowe wdrożenie potrzebuje powodu, by zaakceptować pracę operacyjną obok kontroli nad modelem. Przykład AWS pomaga uwidocznić część tej pracy.
Dlatego ta historia wykracza poza specjalistów od infrastruktury. Kupujący w przedsiębiorstwach oceniający funkcję mowy powinni pytać, jak dostawca radzi sobie ze zmianami popytu. Demonstracja modelu odpowiada na pytanie, czy można wygenerować mowę. Pozostawia jednak otwartą kwestię pojemności.
Autoskalowanie SageMaker TTS łączy współbieżność z czasem odzyskiwania pojemności
Limit współbieżności nabiera znaczenia operacyjnego, gdy polityka uwzględnia również czas, po którym dodatkowa pojemność zaczyna pomagać.
Przykład benchmarkingu w repozytorium raportuje zmierzony czas skalowania w górę wynoszący około 260 sekund. Plan dopuszcza około 320 sekund po dodaniu osobno ograniczonego marginesu na wykrycie.
Te wielkości zasługują na odrębne nazwy. Wymuszony pomiar skalowania w górę omija proces wykrywania przez politykę. Dodanie marginesu wspiera planowanie, lecz nie czyni z tego marginesu zaobserwowanego wyniku end-to-end.
Przeprowadzony przykład prowadzi do celu skalowania w górę na poziomie 37,5 współbieżnych żądań oraz progu skalowania w dół wynoszącego 25. Skalowanie w górę dodaje pojemność; skalowanie w dół ją usuwa. Różnica oddziela warunki tych przeciwstawnych działań.
Z tego rozdzielenia wynika ważna konsekwencja. Najwyższy akceptowalny punkt pracy niekoniecznie jest właściwym momentem na wezwanie pomocy. Jeśli nowa pojemność potrzebuje czasu, aby się pojawić, istniejąca flota musi nadal obsługiwać pracę w czasie reakcji.
Ten przedział tworzy centralny mechanizm tej historii. Planowanie pojemności musi łączyć stan usługi z szybkością jej reakcji. Kontroler może prawidłowo wykryć presję, a mimo to zareagować zbyt późno dla żądań, które już oczekują.
Dla czytelnika oceniającego politykę użyteczne pytanie dotyczy okresu pośredniego. Co dzieje się po pojawieniu się warunku skalowania, ale zanim dodatkowa pojemność poprawi działanie usługi? Konfiguracja, która odpowiada tylko na pytanie, kiedy dodać instancję, pozostawia ten okres niewyjaśniony.
To samo rozumowanie dotyczy usuwania pojemności. Decyzja o skalowaniu w dół zmienia obciążenie obsługiwane przez pozostałą flotę. Jeśli popyt powróci, zanim zastępcza pojemność stanie się użyteczna, system musi pochłonąć to odwrócenie sytuacji.
Cooldown, czyli okres ograniczający powtarzanie działań skalujących, może wpływać na to zachowanie. Dłuższe oczekiwanie nie tworzy jednak mocy przetwarzania. Zmienia moment, w którym kontroler działa ponownie. Mylenie tych efektów sprawia, że polityka wygląda na bezpieczniejszą, niż uzasadniają to jej zasoby bazowe.
To również miejsce, w którym cenna staje się odtwarzalność. Ponowne wyliczenie wyników polityki na podstawie zapisanych pomiarów pozwala recenzentom odróżnić arytmetykę od założeń. Mogą sprawdzić, czy wynik wynika z danych wejściowych, bez uznawania każdego z nich za uniwersalnie obowiązujący.
To rozróżnienie powinno kształtować dyskusje techniczne. Inżynier może zgodzić się, że obliczenie jest poprawne, jednocześnie kwestionując zakładany wzrost ruchu. Menedżer produktu może zaakceptować pomiar, lecz podważyć, czy wybrany cel opóźnienia pasuje do aplikacji.
Takie spory poprawiają decyzję, ponieważ wskazują jej rzeczywiste źródło. Bez tego rozdzielenia zespoły często dyskutują o końcowym progu, jakby był on odizolowaną preferencją. Podejście pomiarowe ujawnia zależności, które za nim stoją.
Mechanizm ten wspiera zatem bardziej precyzyjny kontrakt operacyjny. Wdrożenie ma przetestowaną granicę obciążenia, planowany czas reakcji i warunki zmiany wielkości floty. Razem elementy te wyjaśniają więcej niż sam procent wykorzystania zasobów.
Nadal opisują jednak model usługi. Walidacja produkcyjna musi ustalić, na ile ten model odpowiada ruchowi, który otrzymuje aplikacja.
Założenie dotyczące nagłego wzrostu pozostaje decyzją biznesową
Pomiar zachowania endpointu ogranicza niepewność, ale operator nadal wybiera, jakie zmiany popytu usługa powinna wytrzymać.
Model pojemności projektu capacity model wyraźnie oddziela przyjęte założenia od zmierzonych danych wejściowych. Cel opóźnienia i współczynnik skoku należą do kategorii założeń. Współczynnik skoku opisuje oczekiwane zwielokrotnienie ruchu w czasie reakcji mechanizmu skalowania.
Przy współczynniku skoku wynoszącym 1,25 przykład rezerwuje zapas względem progu, wykorzystując część przetestowanej granicy współbieżności. Udokumentowane równania prowadzą do podanych wartości skalowania w górę i w dół. Obliczenie to wyraża przyjęte założenie; nie potwierdza niezależnie przyszłego popytu.
To zastrzeżenie zapobiega zbyt szerokiemu rozumieniu określenia „zmierzona polityka”. Punkt końcowy może dostarczać dowodów dotyczących swojego zachowania podczas testu. Nie może decydować, jakie ryzyko biznesowe organizacja powinna zaakceptować.
Planowane wdrożenie dobrze ilustruje tę różnicę. Działania marketingowe mogą uzasadniać oczekiwanie nietypowego popytu, ale same w sobie nie dostarczają wiarygodnego wzorca napływu żądań. Planowanie infrastruktury nadal wymaga oceny, jak bardzo ten popyt będzie skoncentrowany.
Ruch historyczny również wymaga interpretacji. Usługa może dysponować rozległymi danymi z typowego użytkowania, lecz nie mieć dowodów dotyczących nowo wprowadzonej funkcji. Dane pozostają użyteczne, ale ich znaczenie zależy od tego, czy nowe obciążenie przypomina stare.
Ten sam problem pojawia się, gdy zmienia się charakter popytu, a nie jego wolumen. Aplikacja głosowa może otrzymywać teksty o różnej długości lub inne wzorce interakcji. Niezmieniona liczba żądań nie dowodzi niezmienionego obciążenia.
Są to analityczne konsekwencje podejścia pomiarowego, a nie dodatkowe ustalenia wynikające z opisanego przez AWS uruchomienia. Wyjaśniają, dlaczego zmierzone dane wejściowe wymagają kontekstu. Liczba bez warunków testu może stać się kolejnym nieuzasadnionym ustawieniem domyślnym.
Model pojemności jasno wskazuje też, że cel opóźnienia pomaga określić akceptowalny wynik współbieżności. Zmiana obietnicy zmienia pytanie, na które test musi odpowiedzieć. Zespół nie może zakładać, że dawna granica pozostaje ważna po zaostrzeniu zobowiązania dotyczącego czasu odpowiedzi.
Dla operatorów praktyczna konsekwencja dotyczy odpowiedzialności. Ktoś musi odpowiadać za założenie dotyczące ruchu, a ktoś za cel widoczny dla użytkownika. Pozostawienie któregokolwiek z nich w sferze domysłów sprawia, że końcowa konfiguracja może wyglądać na bardziej miarodajną, niż jest decyzja leżąca u jej podstaw.
Dla kupujących konsekwencja dotyczy próśb o dowody. Pytanie, czy dostawca stosuje automatyczne skalowanie, mówi niewiele. Pytanie, jaki wzorzec ruchu przetrwała jego usługa, prowadzi do bardziej informatywnej rozmowy.
Automatyczne skalowanie SageMaker TTS staje się zatem sposobem organizowania odpowiedzialności w takim samym stopniu, jak przydzielania zasobów. Pomaga rozdzielić to, co system zmierzył, co operator założył oraz co aplikacja obiecała.
To rozdzielenie powinno pozostać widoczne, gdy wyniki trafiają do pulpitów monitorujących lub dokumentów planistycznych. Precyzyjny próg może przesłonić niepewność, jeśli znikną otaczające go założenia. Zachowanie tych założeń przy wyniku pozwala zachować znaczenie pomiaru.
Pozostaje pytanie, czy wynikowa polityka zachowuje się bezpiecznie, gdy popyt rzeczywiście się zmienia. Własne ostrzeżenia przykładu pokazują, dlaczego to pytanie wymaga odrębnych dowodów.
Przykład ujawnia ryzyka, których arytmetyka progów nie usunie
Uzasadnionemu progowi nadal może towarzyszyć wdrożenie akceptujące istotne kompromisy w zakresie niezawodności.
Przeanalizowany przykład zgłasza ostrzeżenia dotyczące odporności na skoki obciążenia i stabilności skalowania w dół. Te ostrzeżenia są ważne, ponieważ określają zakres działania polityki. Powinny towarzyszyć konfiguracji, a nie znikać z jej publicznego podsumowania.
Kolejka, czyli praca oczekująca na wykonanie, może tymczasowo zapewnić miejsce dla popytu. Nie zapewnia jednak dodatkowej szybkości przetwarzania. Rezerwowanie pojemności kolejki nie może więc dowieść, że obciążona instancja będzie wystarczająco szybko opróżniać napływającą pracę przez cały okres skoku.
To rozróżnienie przypomina różnicę między pomieszczeniem kolejki a jej obsługą. Więcej miejsca oczekiwania może zapobiec natychmiastowemu odrzuceniu, pozostawiając jednocześnie nieakceptowalny czas oczekiwania. W przypadku aplikacji głosowych użytkownik odczuwa opóźnienie niezależnie od tego, gdzie wewnętrznie znajduje się żądanie.
Poważna ocena powinna w konsekwencji analizować zarówno udane odpowiedzi, jak i odrzucone zadania. Raportowanie opóźnienia wyłącznie dla ukończonych żądań może przedstawiać niepełny obraz usługi. System, który odrzuca trudne żądania, musi uwzględniać takie wyniki w ocenie swojej niezawodności.
Skalowanie w dół wprowadza inne ryzyko koncentracji. Usunięcie pojemności przenosi odpowiedzialność na to, co pozostaje. Jeżeli ten transfer natychmiast odtwarza warunki wymagające rozszerzenia, kontroler może naprzemiennie podejmować przeciwstawne decyzje.
Istotne pytanie dotyczy stabilności przy liczebności floty, z której usługa faktycznie korzysta. Polityka zachowująca się akceptowalnie w okresach dużego obciążenia może nadal działać niezręcznie w okresach spokojnych. Niski ruch nie czyni automatycznie każdej redukcji pojemności nieszkodliwą.
Te kwestie ograniczają także interpretację pomyślnej kontroli konfiguracji. Potwierdzenie, że wdrożone ustawienia odpowiadają planowi, dowodzi spójności. Nie dowodzi, że plan spełnia wszystkie wymagania produkcyjne.
Implementacja przykładowa opisuje siebie jako demonstrację wartości, a nie system gotowy do produkcji. Jej dokumentacja wskazuje również znane zalecenie dotyczące przypiętej zależności PyTorch. To ujawnienie tworzy konkretny obowiązek weryfikacji, zanim zespoły dostosują kontener do środowiska produkcyjnego.
Aktualizacja zależności rodzi następnie kolejne pytanie operacyjne. Poprawka bezpieczeństwa może zmienić środowisko programowe stanowiące podstawę wyniku wydajnościowego. Właściwą reakcją jest sprawdzenie, czy istniejące pomiary nadal uzasadniają politykę.
Nie jest to argument przeciwko publikowaniu implementacji referencyjnych. Jawnie opisane ograniczenia ułatwiają ocenę przykładu. Pozwalają czytelnikom odróżnić użyteczny projekt od kompletnej usługi produkcyjnej.
Przeanalizowane tu dowody nie potwierdzają również niezależnego odtworzenia zgłoszonych pomiarów na żywo. Implementacja i dokumentacja AWS dostarczają materiału możliwego do sprawdzenia, lecz pochodzą z tego samego źródłowego przedsięwzięcia. Odtworzenie obliczenia różni się od odtworzenia zachowania punktu końcowego.
Neutralna interpretacja powinna zachować to rozróżnienie. Dostępny materiał wspiera analizę podejścia i deklarowanych wyników. Nie uzasadnia twierdzeń o uniwersalnych oszczędnościach, gwarantowanym opóźnieniu ani przewadze nad zarządzanymi alternatywami do syntezy mowy.
Dla decydentów najsilniejszą cechą jest widoczność kompromisów. Polityka raportująca swoje słabości daje zespołom coś konkretnego do zbadania. Niewyjaśnione ustawienie domyślne oferuje mniej pomocy, gdy zachowanie produkcyjne odbiega od oczekiwań.
Obserwuj odtwarzalność, odzyskiwanie po skokach i dyscyplinę wydań
Kolejne użyteczne dowody dotyczą powtarzalnego zachowania, realistycznych zmian popytu oraz tego, czy pomiary pozostają powiązane z wydaniami oprogramowania.
W nadchodzących miesiącach pierwszym sygnałem wartym obserwacji jest niezależne odtworzenie w różnych warunkach wdrożeniowych. Użyteczny raport wskazywałby obciążenie, wersję oprogramowania, konfigurację instancji oraz cel opóźnienia obok wyników.
Dokładne odtworzenie liczb AWS nie byłoby jedynym istotnym rezultatem. Inne wyniki z jasnym wyjaśnieniem również wzmocniłyby zaufanie do podejścia. Pokazałyby, że proces rozróżnia wdrożenia, zamiast jedynie odtwarzać z góry ustaloną odpowiedź.
Niewyjaśniona zmienność osłabiłaby zaufanie do przenośności konkretnego progu. Zwiększyłaby znaczenie czasu trwania testu, wyboru obciążenia i warunków środowiskowych. Reakcją powinno być dochodzenie, a nie uśrednianie niezgodnych wyników w nowe ustawienie domyślne.
Drugim sygnałem jest odzyskiwanie po skoku sterowane polityką. Najsilniejsza walidacja śledziłaby popyt od momentu jego wzrostu przez wykrycie, dodanie pojemności i przywrócenie usługi. Taka obserwacja obejmowałaby okres, który wymuszony test skalowania w górę częściowo omija.
Takie dowody powinny uwzględniać czas oczekiwania i nieudane żądania obok opóźnienia udanych odpowiedzi. Powinny też zachowywać kształt napływającego obciążenia. W przeciwnym razie podsumowanie może ukryć dokładne warunki, które ułatwiły lub utrudniły odzyskanie sprawności.
Skuteczna obsługa skoków wzmocniłaby argument, że wybrany zapas odpowiada potrzebom aplikacji. Powtarzające się przeciążenie w okresie reakcji osłabiłoby ten wniosek, nawet gdyby kontroler ostatecznie osiągnął odpowiednią wielkość floty.
Trzecim sygnałem jest dyscyplina wydań. Zespoły powinny wykazać, że zmiany modelu, kontenera i obsługi wywołują przegląd dowodów dotyczących pojemności. Proces pomiarowy staje się cenniejszy, gdy nadal działa po początkowym wdrożeniu.
Nie wymaga to, aby każda zmiana dawała ten sam wynik. Wymaga możliwego do prześledzenia wyjaśnienia, gdy wynik się zmienia. Wolniejsze wydanie może nadal być akceptowalne, jeśli poprawia inny wymóg, a polityka floty zostanie odpowiednio dostosowana.
Zachowanie tej historii ułatwia również ponowne wykorzystanie wiedzy operacyjnej. Inżynierowie potrzebują uzasadnienia starego progu, gdy oceniają jego zastąpienie. Zespoły organizujące takie materiały mogą korzystać z przeszukiwalnej bazy wiedzy inżynierskiej, aby połączyć zapisy testów, decyzje dotyczące wydań i ustalenia z incydentów.
Przed przyjęciem przykładu poproś swój zespół o zebranie dowodów stojących za jego obecnym punktem końcowym syntezy mowy. Określ obietnicę dotyczącą opóźnienia, obciążenie użyte do jej przetestowania oraz czas, jakiego dodatkowa pojemność potrzebuje, zanim zacznie pomagać. Porównaj te zapisy z modelem i kontenerem faktycznie działającymi w środowisku. Następnie sprawdź, co dzieje się podczas wzrostu popytu i po usunięciu pojemności. Uwzględnij w dyskusji odrzucone żądania obok udanych odpowiedzi. Automatyczne skalowanie SageMaker TTS zapewnia konkretny punkt wyjścia do takiego przeglądu, ale jego ustawienia wymagają dowodów z Twojego wdrożenia. Który obecny próg Twój zespół potrafi wyjaśnić za pomocą odtwarzalnego pomiaru, a który nadal opiera się na założeniu, którego nikt ostatnio nie przetestował?
