Popraw wartościowe badania dzięki asynchronicznym punktom końcowym wnioskowania Hugging Face i Amazon SageMaker

Wielu naszych klientów AWS świadczy usługi badawcze, analityczne i biznesowe. Ten rodzaj badań i wywiadu biznesowego umożliwia klientom końcowym wyprzedzanie rynków i konkurentów, identyfikowanie możliwości rozwoju i proaktywne rozwiązywanie problemów. Na przykład niektórzy z naszych klientów z sektora usług finansowych przeprowadzają badania dotyczące akcji, funduszy hedgingowych i firm zarządzających inwestycjami, aby pomóc im zrozumieć trendy i zidentyfikować strategie portfelowe. W branży zdrowotnej coraz większa część badań zdrowotnych opiera się obecnie na informacjach. Duża część badań obejmuje analizę danych, które początkowo zostały zebrane w celach diagnostycznych, leczniczych lub innych projektach badawczych, a obecnie są wykorzystywane do nowych celów badawczych. Te formy badań nad zdrowiem doprowadziły do ​​skutecznej profilaktyki pierwotnej w celu uniknięcia nowych przypadków, profilaktyki wtórnej w celu wczesnego wykrywania oraz profilaktyki w celu lepszego leczenia chorób. Wyniki badań nie tylko poprawiają jakość życia, ale także pomagają zmniejszyć wydatki na opiekę zdrowotną.

Klienci mają tendencję do przyswajania informacji ze źródeł publicznych i prywatnych. Następnie stosują ustalone lub niestandardowe modele przetwarzania języka naturalnego (NLP), aby podsumować i zidentyfikować trend oraz wygenerować spostrzeżenia na podstawie tych informacji. Modele NLP wykorzystywane do tego typu zadań badawczych dotyczą dużych modeli i zazwyczaj obejmują długie artykuły, które należy podsumować z uwzględnieniem wielkości korpusu oraz dedykowane punkty końcowe, które obecnie nie są zoptymalizowane pod względem kosztów. Aplikacje te otrzymują dużą ilość ruchu przychodzącego o różnych porach dnia.

Wierzymy, że klienci odnieśliby ogromne korzyści z możliwości skalowania do zera i zwiększania możliwości wnioskowania w miarę potrzeb. Optymalizuje to koszty badań i nadal nie wpływa negatywnie na jakość wniosków. W tym poście omówiono sposób przytulania twarzy Amazon Sage Maker wnioskowanie asynchroniczne może pomóc w osiągnięciu tego celu.

Możesz tworzyć modele podsumowań tekstu za pomocą wielu platform głębokiego uczenia się, takich jak TensorFlow, PyTorch i Apache MXNet. Modele te zazwyczaj zawierają duży ładunek wejściowy składający się z wielu dokumentów tekstowych o różnej wielkości. Zaawansowane modele głębokiego uczenia się wymagają intensywnego przetwarzania wstępnego przed wnioskowaniem o modelu. Czas przetwarzania może wynosić nawet kilka minut, co eliminuje opcję uruchamiania wnioskowania w czasie rzeczywistym poprzez przekazywanie ładunków przez interfejs API HTTP. Zamiast tego musisz asynchronicznie przetwarzać ładunki wejściowe ze składnicy obiektów, np Usługa Amazon Simple Storage (Amazon S3) z automatycznym kolejkowaniem i predefiniowanym progiem współbieżności. System powinien móc odbierać powiadomienia o statusie i redukować niepotrzebne koszty poprzez czyszczenie zasobów po zakończeniu zadań.

SageMaker pomaga badaczom danych i programistom szybko przygotowywać, budować, szkolić i wdrażać wysokiej jakości modele uczenia maszynowego (ML), łącząc szeroki zestaw funkcji stworzonych specjalnie z myślą o uczeniu maszynowym. SageMaker zapewnia najbardziej zaawansowane kontenery obsługujące modele typu open source dla XGBoost (pojemnik, SDK), Nauka Scikit (pojemnik, SDK), PyTorch (pojemnik, SDK), Przepływ Tensorowy (pojemnik, SDK) i Apache MXNet (pojemnik, SDK).

1. Wnioskowanie w czasie rzeczywistym punkty końcowe są odpowiednie dla obciążeń, które muszą być przetwarzane przy wymaganiach małych opóźnień, rzędu ms do sekund.
2. Transformacja wsadowa jest idealny do prognozowania offline na dużych partiach danych.
3. Wnioskowanie bezserwerowe Amazon SageMaker (w trybie podglądu i niezalecany w przypadku obciążeń produkcyjnych w chwili pisania tego tekstu) to specjalnie zaprojektowana opcja wnioskowania, która ułatwia wdrażanie i skalowanie modeli uczenia maszynowego. Inferencja bezserwerowa jest idealna w przypadku obciążeń, w których występują okresy bezczynności pomiędzy gwałtownymi ruchami i toleruje zimny start.
4. Wnioskowanie asynchroniczne punkty końcowe kolejkują żądania przychodzące. Idealnie nadają się do obciążeń, w których rozmiary żądań są duże (do 1 GB), a czas przetwarzania wnioskowania jest rzędu minut (do 15 minut). Wnioskowanie asynchroniczne pozwala zaoszczędzić na kosztach poprzez automatyczne skalowanie liczby wystąpień do zera, gdy nie ma żadnych żądań do przetworzenia.

Omówienie rozwiązania

W tym poście wdrażamy a Model PEGASUSA który został wstępnie przeszkolony do wykonywania podsumowań tekstu Przytulanie Twarzy do Usługi hostingowe SageMaker. Dla uproszczenia używamy modelu z Hugging Face. Jednak możesz dostroić model w oparciu o niestandardowy zestaw danych. Możesz także wypróbować inne modele dostępne w sklepie Przytulanie twarzy Model Hub. Udostępniamy również asynchroniczny punkt końcowy wnioskowania, który obsługuje ten model, z którego można uzyskać prognozy.

Procedura obsługi wnioskowania punktu końcowego wnioskowania asynchronicznego oczekuje artykułu jako ładunku wejściowego. Podsumowaniem tekstu artykułu jest wynik. Wyniki są przechowywane w bazie danych w celu analizy trendów lub przesyłane w dół do dalszych analiz. Ta dalsza analiza pozwala na uzyskanie wglądu w dane, które są pomocne w badaniach.

Pokazujemy, jak asynchroniczne punkty końcowe wnioskowania umożliwiają posiadanie zdefiniowanych przez użytkownika powiadomień o współbieżności i zakończeniu. Konfigurujemy automatyczne skalowanie instancji za punktem końcowym, aby skalować w dół do zera, gdy ruch spadnie, i skalować z powrotem w miarę zapełniania się kolejki żądań.

Używamy również Amazon Cloud Watch metryki do monitorowania rozmiaru kolejki, całkowitego czasu przetwarzania i przetworzonych wywołań.

Na poniższym diagramie przedstawiono kroki wymagane podczas wykonywania wnioskowania przy użyciu asynchronicznego punktu końcowego wnioskowania.

1. Nasi wstępnie przeszkoleni PEGASUS Model ML jest najpierw hostowany w punkcie końcowym skalowania.
2. Użytkownik przesyła artykuł, który ma zostać podsumowany, do wiadra wejściowego S3.
3. Punkt końcowy wnioskowania asynchronicznego jest wywoływany przy użyciu interfejsu API.
4. Po zakończeniu wnioskowania wynik jest zapisywany w wyjściowym zasobniku S3.
5. An Usługa prostego powiadomienia Amazon Do użytkownika wysyłane jest powiadomienie (Amazon SNS), informujące go o zakończonym sukcesie lub porażce.

Utwórz asynchroniczny punkt końcowy wnioskowania

Tworzymy asynchroniczny punkt końcowy wnioskowania podobny do hostowanego punktu końcowego w czasie rzeczywistym. Kroki obejmują utworzenie modelu SageMaker, a następnie skonfigurowanie punktu końcowego i wdrożenie punktu końcowego. Różnica między tymi dwoma typami punktów końcowych polega na tym, że konfiguracja punktu końcowego wnioskowania asynchronicznego zawiera plik AsyncInferenceConfig Sekcja. Tutaj określamy ścieżkę wyjściową S3 dla wyników wywołania punktu końcowego i opcjonalnie dołączamy tematy SNS do powiadomień o powodzeniu i niepowodzeniu. Określamy również maksymalną liczbę jednoczesnych wywołań na instancję, określoną przez klienta. Zobacz następujący kod:

AsyncInferenceConfig={ "OutputConfig": { "S3OutputPath": f"s3://{bucket}/{bucket_prefix}/output", # Optionally specify Amazon SNS topics for notifications "NotificationConfig": { "SuccessTopic": success_topic, "ErrorTopic": error_topic, } }, "ClientConfig": { "MaxConcurrentInvocationsPerInstance": 2 #increase this value up to throughput peak for ideal performance } }

Aby uzyskać szczegółowe informacje na temat interfejsu API umożliwiającego utworzenie konfiguracji punktu końcowego na potrzeby wnioskowania asynchronicznego, zobacz Utwórz punkt końcowy wnioskowania asynchronicznego.

Wywołaj punkt końcowy wnioskowania asynchronicznego

Poniższy zrzut ekranu przedstawia krótki artykuł, którego używamy jako ładunku wejściowego:

Poniższy kod przesyła artykuł jako plik input.json plik do Amazon S3:

sm_session.upload_data( input_location, bucket=sm_session.default_bucket(), key_prefix=prefix, extra_args={"ContentType": "text/plain"})

Używamy identyfikatora URI Amazon S3 do wejściowego pliku ładunku, aby wywołać punkt końcowy. Obiekt odpowiedzi zawiera lokalizację wyjściową w Amazon S3, aby pobrać wyniki po zakończeniu:

response = sm_runtime.invoke_endpoint_async(EndpointName=endpoint_name, InputLocation=input_1_s3_location)
output_location = response['OutputLocation']

Poniższy zrzut ekranu przedstawia przykładowe podsumowanie wyników:

Aby uzyskać szczegółowe informacje na temat interfejsu API umożliwiającego wywołanie asynchronicznego punktu końcowego wnioskowania, zobacz Wywołaj punkt końcowy wnioskowania asynchronicznego.

Kolejkuj żądania wywołania ze współbieżnością zdefiniowaną przez użytkownika

Punkt końcowy wnioskowania asynchronicznego automatycznie umieszcza w kolejce żądania wywołania. Jest to w pełni zarządzana kolejka z różnymi metrykami monitorowania i nie wymaga dalszej konfiguracji. Używa MaxConcurrentInvocationsPerInstance parametr w poprzedniej konfiguracji punktu końcowego, aby przetwarzać nowe żądania z kolejki po zakończeniu poprzednich żądań. MaxConcurrentInvocationsPerInstance to maksymalna liczba jednoczesnych żądań wysłanych przez klienta SageMaker do kontenera modelu. Jeśli nie zostanie podana żadna wartość, SageMaker wybierze dla Ciebie optymalną wartość.

Automatyczne skalowanie wystąpień w asynchronicznym punkcie końcowym wnioskowania

Ustawiamy politykę automatycznego skalowania z minimalną pojemnością wynoszącą zero i maksymalną pojemnością wynoszącą pięć instancji. W przeciwieństwie do punktów końcowych hostowanych w czasie rzeczywistym, punkty końcowe wnioskowania asynchronicznego obsługują skalowanie wystąpień do zera poprzez ustawienie minimalnej pojemności na zero. Używamy ApproximateBacklogSizePerInstance metryka konfiguracji zasad skalowania z zaległościami w kolejce docelowej wynoszącymi pięć na instancję w celu dalszego skalowania. Ustawiamy okres odnowienia ScaleInCooldown do 120 sekund i ScaleOutCooldown do 120 sekund. Wartość dla ApproximateBacklogSizePerInstance jest wybierany na podstawie natężenia ruchu i wrażliwości na prędkość skalowania. Im szybsze skalowanie, tym mniejsze koszty poniesiesz, ale tym bardziej prawdopodobne, że będziesz musiał ponownie skalować w górę, gdy napłyną nowe żądania. Im wolniej będziesz skalować, tym więcej poniesiesz kosztów, ale jest mniej prawdopodobne, że będziesz mieć prośba przychodzi, gdy jesteś niedostatecznie skalowany.

client = boto3.client('application-autoscaling') # Common class representing Application Auto Scaling for SageMaker amongst other services resource_id='endpoint/' + endpoint_name + '/variant/' + 'variant1' # This is the format in which application autoscaling references the endpoint response = client.register_scalable_target(
ServiceNamespace='sagemaker', #
ResourceId=resource_id,
ScalableDimension='sagemaker:variant:DesiredInstanceCount',
MinCapacity=0,
MaxCapacity=5
) response = client.put_scaling_policy(
PolicyName='Invocations-ScalingPolicy',
ServiceNamespace='sagemaker', # The namespace of the AWS service that provides the resource.
ResourceId=resource_id, # Endpoint name
ScalableDimension='sagemaker:variant:DesiredInstanceCount', # SageMaker supports only Instance Count
PolicyType='TargetTrackingScaling', # 'StepScaling'|'TargetTrackingScaling'
TargetTrackingScalingPolicyConfiguration={ 'TargetValue': 5.0, # The target value for the metric. 'CustomizedMetricSpecification': { 'MetricName': 'ApproximateBacklogSizePerInstance', 'Namespace': 'AWS/SageMaker', 'Dimensions': [{'Name': 'EndpointName', 'Value': endpoint_name }], 'Statistic': 'Average',
}, 'ScaleInCooldown': 120, # ScaleInCooldown - The amount of time, in seconds, after a scale-in activity completes before another scale in activity can start. 'ScaleOutCooldown': 120 # ScaleOutCooldown - The amount of time, in seconds, after a scale-out activity completes before another scale out activity can start.
# 'DisableScaleIn': True|False - indicates whether scale in by the target tracking policy is disabled.
# If the value is true, scale-in is disabled and the target tracking policy won't remove capacity from the scalable resource.
}
)

Aby uzyskać szczegółowe informacje na temat interfejsu API do automatycznego skalowania punktu końcowego wnioskowania asynchronicznego, zobacz Automatyczne skalowanie punktu końcowego wnioskowania asynchronicznego.

Skonfiguruj powiadomienia z punktu końcowego wnioskowania asynchronicznego

Tworzymy dwa osobne tematy SNS dla powiadomień o powodzeniu i błędach dla każdego wyniku wywołania punktu końcowego:

sns_client = boto3.client('sns')
response = sns_client.create_topic(Name="Async-Demo-ErrorTopic2")
error_topic = response['TopicArn']
response = sns_client.create_topic(Name="Async-Demo-SuccessTopic2")
success_topic = response['TopicArn']

Inne opcje powiadomień obejmują okresowe sprawdzanie wyników segmentu S3 lub używanie powiadomień segmentu S3 do inicjowania AWS Lambda funkcja przesyłania plików. Powiadomienia SNS są zawarte w sekcji konfiguracji punktu końcowego, jak opisano wcześniej.

Aby uzyskać szczegółowe informacje na temat konfigurowania powiadomień z punktu końcowego wnioskowania asynchronicznego, zobacz Sprawdź wyniki prognoz.

Monitoruj punkt końcowy wnioskowania asynchronicznego

Monitorujemy punkt końcowy wnioskowania asynchronicznego za pomocą wbudowanych dodatkowych metryk CloudWatch specyficznych dla wnioskowania asynchronicznego. Na przykład monitorujemy długość kolejki w każdej instancji za pomocą ApproximateBacklogSizePerInstance i całkowita długość kolejki z ApproximateBacklogSize.

Pełną listę wskaźników można znaleźć w artykule Monitorowanie punktów końcowych wnioskowania asynchronicznego.

Możemy zoptymalizować konfigurację punktu końcowego, aby uzyskać najbardziej opłacalną instancję o wysokiej wydajności. Możemy na przykład użyć instancji z Amazon Elastic Inference lub AWS Inferentia. Możemy także stopniowo zwiększać poziom współbieżności aż do szczytowej przepustowości, dostosowując inne parametry serwera modelowego i kontenera.

Wykresy CloudWatcha

Symulowaliśmy ruch wynoszący 10,000 XNUMX żądań wnioskowania napływających w pewnym okresie do punktu końcowego wnioskowania asynchronicznego z włączoną funkcją automatycznego skalowania opisaną w poprzedniej sekcji.

Poniższy zrzut ekranu przedstawia metryki instancji przed rozpoczęciem napływu żądań. Zaczynamy od działającego punktu końcowego z zerową uruchomioną instancją:

Poniższy wykres pokazuje, w jaki sposób BacklogSize i BacklogSizePerInstance metryki zmieniają się wraz z rozpoczęciem automatycznego skalowania, a obciążenie punktu końcowego jest współdzielone przez wiele instancji, które zostały udostępnione w ramach procesu automatycznego skalowania.

Jak pokazano na poniższym zrzucie ekranu, liczba instancji wzrosła wraz ze wzrostem liczby wnioskowań:

Poniższy zrzut ekranu pokazuje, jak skalowanie przywraca punkt końcowy do stanu początkowego zerowych działających instancji:

Sprzątać

Po zakończeniu wszystkich żądań możemy usunąć punkt końcowy w podobny sposób, jak usuwa się punkty końcowe hostowane w czasie rzeczywistym. Należy zauważyć, że jeśli ustawimy minimalną pojemność punktów końcowych wnioskowania asynchronicznego na zero, po skalowaniu do zera nie będą naliczane żadne opłaty za wystąpienia.

Jeśli włączyłeś automatyczne skalowanie dla punktu końcowego, przed usunięciem punktu końcowego pamiętaj o wyrejestrowaniu punktu końcowego jako skalowalnego celu. Aby to zrobić, uruchom następujący kod:

response = client.deregister_scalable_target(ServiceNamespace='sagemaker',ResourceId='resource_id',ScalableDimension='sagemaker:variant:DesiredInstanceCount')

Pamiętaj, aby usunąć punkt końcowy po użyciu, ponieważ zostanie naliczona opłata za instancje użyte w tej wersji demonstracyjnej.

sm_client.delete_endpoint(EndpointName=endpoint_name)

Musisz także usunąć obiekty S3 i tematy SNS. Jeśli utworzyłeś inne zasoby AWS do wykorzystania i podjęcia działań związanych z powiadomieniami SNS, możesz je również usunąć.

Wnioski

W tym poście zademonstrowaliśmy, jak wykorzystać nową funkcję wnioskowania asynchronicznego z SageMaker do przetwarzania typowego dużego ładunku wejściowego, który jest częścią zadania podsumowującego. Na potrzeby wnioskowania wykorzystaliśmy model z Hugging Face i wdrożyliśmy go w asynchronicznym punkcie końcowym wnioskowania. Wyjaśniliśmy typowe wyzwania związane z ruchem impulsowym, długim czasem przetwarzania modelu i dużymi ładunkami związanymi z analityką badawczą. Wrodzona zdolność punktu końcowego wnioskowania asynchronicznego do zarządzania kolejkami wewnętrznymi, predefiniowanymi limitami współbieżności, konfigurowaniem powiadomień o odpowiedzi i automatycznym skalowaniem do zera pomogły nam stawić czoła tym wyzwaniom. Pełny kod tego przykładu jest dostępny na stronie GitHub.

Aby rozpocząć korzystanie z wnioskowania asynchronicznego SageMaker, sprawdź Wnioskowanie asynchroniczne.

O autorach

Dinesha Kumara Subramaniego jest starszym architektem rozwiązań w zespole UKIR SMB z siedzibą w Edynburgu w Szkocji. Specjalizuje się w sztucznej inteligencji i uczeniu maszynowym. Dinesh lubi współpracować z klientami z różnych branż, aby pomagać im w rozwiązywaniu problemów z usługami AWS. Poza pracą uwielbia spędzać czas z rodziną, grać w szachy i cieszyć się muzyką różnych gatunków.

Raghu Ramesza jest architektem rozwiązań ML w zespole usług Amazon SageMaker. Koncentruje się na pomaganiu klientom w budowaniu, wdrażaniu i migracji obciążeń produkcyjnych ML do SageMaker na dużą skalę. Specjalizuje się w uczeniu maszynowym, sztucznej inteligencji i wizji komputerowej. Posiada tytuł magistra informatyki na UT Dallas. W wolnym czasie lubi podróżować i fotografować.

• Coinsmart. Najlepsza w Europie giełda bitcoinów i kryptowalut.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. DARMOWY DOSTĘP.
• CryptoJastrząb. Radar Altcoin. Bezpłatna wersja próbna.
• Źródło: https://aws.amazon.com/blogs/machine-learning/improve-high-value-research-with-hugging-face-and-amazon-sagemaker-asynchronous-inference-endpoints/