Popraw wydajność modeli Falcona dzięki Amazon SageMaker | Usługi internetowe Amazona

Jaka jest optymalna platforma i konfiguracja do hostowania dużych modeli językowych (LLM) na potrzeby generujących tekst aplikacji AI? Pomimo mnóstwa opcji obsługi LLM, odpowiedź na to pytanie jest trudna ze względu na rozmiar modeli, różne architektury modeli, wymagania wydajnościowe aplikacji i nie tylko. The Amazon Sage Maker Kontener wnioskowania o dużym modelu (LMI). ułatwia obsługę LLM poprzez połączenie wielu różnych ram i technik, które optymalizują wdrażanie LLM. Kontener LMI ma potężny stos obsługujący zwany Obsługa DJL jest to agnostyk w stosunku do leżącego u podstaw LLM. Zapewnia parametry konfiguracyjne na poziomie systemu, które można dostroić w celu uzyskania najlepszej wydajności infrastruktury hostingowej dla danego LLM. Obsługuje również najnowsze optymalizacje, takie jak ciągłe dozowanie, znane również jako dozowanie iteracyjne lub kroczące, co zapewnia znaczną poprawę przepustowości.

We wcześniejszym pisaćpokazaliśmy, jak można wykorzystać kontener LMI do wdrożenia rodziny modeli Falcon w SageMaker. W tym poście pokazujemy, jak poprawić przepustowość i opóźnienia w obsłudze Falcona-40B za pomocą technik takich jak ciągłe przetwarzanie wsadowe. Zapewniamy także intuicyjną wiedzę na temat parametrów konfiguracyjnych dostarczanych przez kontener SageMaker LMI, co może pomóc w znalezieniu najlepszej konfiguracji dla rzeczywistej aplikacji.

Podstawy wnioskowania generującego tekst dla LLM

Przyjrzyjmy się najpierw kilku podstawowym zasadom wnioskowania dla LLM na potrzeby generowania tekstu.

Przejście do przodu, aktywacje i pamięć podręczna KV

Biorąc pod uwagę sekwencję wejściową tokenów, są one uruchamiane w a forward pass przez wszystkie warstwy LLM (jak Falcon), aby wygenerować następny token. A forward pass odnosi się do procesu przesyłania danych wejściowych przez sieć neuronową w celu wytworzenia wyniku. W przypadku generowania tekstu przejście do przodu obejmuje wprowadzenie początkowego materiału siewnego lub kontekstu do modelu języka i wygenerowanie kolejnego znaku lub tokenu w sekwencji. Aby wygenerować sekwencję tekstu, proces często przeprowadza się iteracyjnie, co oznacza, że ​​jest powtarzany dla każdego kroku lub pozycji w sekwencji wyjściowej. W każdej iteracji model generuje kolejny znak lub token, który staje się częścią wygenerowanego tekstu i proces ten trwa aż do wygenerowania żądanej długości tekstu.

Generowanie tekstu za pomocą modeli językowych, takich jak Falcon lub GPT autoregressive. Oznacza to, że model generuje jeden token na raz, warunkowując wcześniej wygenerowane tokeny. Innymi słowy, w każdej iteracji model przyjmuje wcześniej wygenerowany tekst jako dane wejściowe i przewiduje następny token na podstawie tego kontekstu. Jak wspomniano w vLLM: łatwa, szybka i tania obsługa LLM za pomocą PagedAttentionw tym procesie dekodowania autoregresyjnego wszystkie tokeny wejściowe do LLM generują tensory klucza uwagi i wartości, a tensory te są przechowywane w pamięci GPU w celu generowania kolejnych tokenów. Te buforowane tensory klucza i wartości są często określane jako KV cache.

Fazy ​​wstępnego wypełniania i dekodowania

W procesie dekodowania autoregresyjnego, takim jak ten stosowany przy generowaniu tekstu za pomocą modeli językowych, takich jak Falcon, zazwyczaj występują dwie główne fazy: prefill faza i decode faza. Fazy ​​te są kluczowe dla wygenerowania spójnego i odpowiedniego kontekstowo tekstu.

Faza wstępnego napełniania obejmuje:

• Kontekst początkowy – Faza wstępnego wypełniania rozpoczyna się od początkowego kontekstu lub tekstu początkowego dostarczonego przez użytkownika. Tym początkowym kontekstem może być zdanie, fraza lub nawet pojedyncze słowo. Ustawia punkt wyjścia do generowania tekstu i zapewnia kontekst dla tego, co będzie dalej.
• Kondycjonowanie modelu – Dostarczony kontekst służy do warunkowania modelu języka. Model przyjmuje ten kontekst jako dane wejściowe i generuje następny token (słowo lub znak) w sekwencji w oparciu o zrozumienie kontekstu.
• Generowanie tokenów – Model generuje jeden token na raz, przewidując, co będzie dalej w tekście. Token ten jest dołączany do kontekstu, skutecznie go rozszerzając.
• Proces iteracyjny – Proces generowania tokenów powtarzany jest iteracyjnie. Na każdym kroku model generuje token, biorąc pod uwagę zaktualizowany kontekst, który teraz obejmuje tokeny wygenerowane w poprzednich krokach.

Faza wstępnego napełniania trwa aż do spełnienia wcześniej określonego warunku zatrzymania. Warunkiem tym może być maksymalna długość wygenerowanego tekstu, konkretny token sygnalizujący koniec tekstu lub inne kryteria ustawione przez użytkownika lub aplikację.

Faza dekodowania obejmuje następujące elementy:

• Completion – Po fazie wstępnego wypełnienia masz częściowo wygenerowany tekst, który może być niekompletny lub w pewnym momencie obcięty. Faza dekodowania polega na uzupełnieniu tekstu tak, aby był spójny i poprawny gramatycznie.
• Kontynuacja od ostatniego żetonu – W fazie dekodowania model rozpoczyna się od ostatniego tokena wygenerowanego w fazie wstępnego napełniania. Używa tego tokenu jako kontekstu początkowego i generuje następny token, aby kontynuować tekst.
• Uzupełnianie iteracyjne – Podobnie jak w fazie wstępnego wypełnienia, proces generowania tokenów jest ponownie iteracyjny. Model generuje jeden token na raz, warunkując poprzednie tokeny w sekwencji.
• Stan zatrzymania – Faza dekodowania ma również warunek zatrzymania, który może być taki sam jak w fazie wstępnego wypełniania, np. osiągnięcie maksymalnej długości lub napotkanie tokenu końca tekstu. Po spełnieniu tego warunku proces generowania zostaje zatrzymany.

Połączenie faz wstępnego wypełniania i dekodowania umożliwia modelom autoregresyjnym generowanie tekstu, który opiera się na początkowym kontekście i tworzy spójne, istotne kontekstowo i kontekstowo spójne sekwencje tekstu.

Odnosić się do Rozproszony system obsługi modeli generatywnych opartych na transformatorach w celu uzyskania szczegółowego wyjaśnienia procesu.

Optymalizacja przepustowości przy użyciu dynamicznego dozowania

Do tej pory mówiliśmy tylko o jednym wejściu. W praktyce spodziewamy się obsługiwać wiele żądań przychodzących losowo od klientów aplikacji w celu wnioskowania jednocześnie lub w sposób rozłożony w czasie. W tradycyjny sposób podstawowe wsadowanie można wykorzystać do zwiększenia przepustowości i wykorzystania zasobów obliczeniowych procesora graficznego. Batch to efektywne łączenie numerycznych reprezentacji więcej niż jednego żądania w partii i wykonywanie równoległych przebiegów autoregresyjnych przejść do przodu. Inteligentne dozowanie odbywa się po stronie serwowania. Serwer DJLServing SageMaker LMI można skonfigurować tak, aby grupował wiele żądań i przetwarzał je równolegle, ustawiając następujące parametry w serwowanie.właściwości:

• max_batch_delay = 100 – Maksymalne opóźnienie agregacji wsadowej w milisekundach. Wartość domyślna to 100 milisekund.
• rozmiar_partii = 32 – Dynamiczna wielkość partii. Wartość domyślna to 1.

Zasadniczo pokazuje to, że DJLServing będzie umieszczał żądania w kolejce przez 100 milisekund na raz lub jeśli liczba żądań w kolejce osiągnie określoną wielkość partii, partia zostanie zaplanowana na uruchomienie do backendu w celu wywnioskowania. Jest to tzw dynamic batching. Jest dynamiczny, ponieważ rozmiar partii może zmieniać się w zależności od partii w zależności od liczby żądań dodanych w tym czasie. Jednakże, ponieważ żądania mogą mieć różną charakterystykę (na przykład niektóre żądania mogą mieć kształt 20 znaków wejściowych i 500 znaków wyjściowych, podczas gdy inne mogą być odwrócone i zawierać 500 znaków wejściowych, ale tylko 20 znaków wyjściowych), niektóre żądania mogą zakończyć przetwarzanie szybciej niż inne w tej samej partii. Może to spowodować niedostateczne wykorzystanie procesora graficznego podczas oczekiwania, aż wszystkie żądania w locie w partii zakończą etap dekodowania, nawet jeśli w kolejce znajdują się dodatkowe żądania oczekujące na przetworzenie. Poniższy diagram ilustruje ten proces.

Optymalizacja wydajności przy użyciu ciągłego dozowania

Z continuous batching, znany również jako iterative or rolling wsadowe, wykorzystujemy różnice między etapami wstępnego wypełniania i dekodowania. Aby aktywować ciągłe przetwarzanie wsadowe, DJServing zapewnia następujące dodatkowe konfiguracje zgodnie z właściwościami serwowania:

• silnik=MPI – Zachęcamy do korzystania z silnika MPI do ciągłego dozowania.
• opcja.rolling_batch=auto lub lmi-dist – Zalecamy użycie opcji auto, ponieważ automatycznie wybierze ona najbardziej odpowiedni algorytm wsadowy kroczącej wraz z innymi optymalizacjami w przyszłości.
• opcja.max_rolling_batch_size=32 – ogranicza liczbę jednoczesnych żądań. Wartość domyślna to 32.

Dzięki ciągłemu przetwarzaniu wsadowemu stos obsługujący (DJLServing) nie czeka, aż wszystkie żądania w locie w partii zakończą etap dekodowania. Raczej w przerwach logicznych (na końcu jednej iteracji na etapie dekodowania) pobiera dodatkowe żądania oczekujące w kolejce, podczas gdy bieżąca partia jest nadal przetwarzana (stąd nazwa partia tocząca się). Sprawdza to oczekujące żądania na końcu każdej iteracji etapu dekodowania. Pamiętaj, że dla każdego żądania musimy przeprowadzić etap wstępnego wypełniania, po którym następuje sekwencyjny etap dekodowania. Ponieważ możemy przetwarzać wszystkie tokeny z początkowego monitu żądania równolegle na etapie wstępnego wypełniania, za każdym razem, gdy zostanie pobrane nowe żądanie, tymczasowo wstrzymujemy etap dekodowania żądań w locie wsadu — tymczasowo zapisujemy jego pamięć podręczną KV i aktywacje w pamięci i uruchom etap wstępnego wypełniania nowych żądań.

Rozmiar tej pamięci podręcznej można skonfigurować za pomocą następującej opcji:

Po zakończeniu wstępnego wypełniania łączymy nowe żądania i stare, wstrzymane żądania w nową, kroczącą partię, która może równolegle kontynuować etap dekodowania. Należy pamiętać, że stare wstrzymane żądania mogą kontynuować etap dekodowania w miejscu, w którym zostały przerwane, a nowe żądania rozpoczną się od pierwszego nowego tokena.

Być może już zdałeś sobie sprawę, że ciągłe przetwarzanie wsadowe to prawie podobne podejście, dzięki któremu w naturalny sposób porównujemy zadania w naszym codziennym życiu. Wiadomości, e-maile i powiadomienia telefoniczne (potencjalnie nowe żądania) przychodzą do nas w losowych momentach (analogicznie do wielu żądań przychodzących losowo, naprzemiennie w przypadku procesorów graficznych). To wszystko dzieje się, gdy zajmujemy się wykonywaniem zadań w locie – pisaniem e-maili, kodowaniem, uczestnictwem w spotkaniach (analogicznie do aktualnie przetwarzanych zadań w procesorach graficznych). Podczas przerw logicznych wstrzymujemy nasze zadania w locie i sprawdzamy powiadomienia, aby zdecydować, czy wymagane jest jakieś działanie z naszej strony, a jeśli tak, dodajemy je do naszych zadań w locie (rzeczywista partia krocząca) lub umieść to na liście rzeczy do zrobienia (kolejce).

Podsumowując: jak myśleć o wykorzystaniu pamięci procesorów graficznych

Zaleca się przetestowanie modelu pod obciążeniem, aby sprawdzić, która konfiguracja jest najbardziej opłacalna w przypadku użycia biznesowego. Aby to zrozumieć, zwizualizujmy zużycie pamięci procesorów graficznych podczas ładowania modelu i przetwarzania kolejnych żądań w sposób ciągły. Na potrzeby tego wpisu załóżmy, że ładujemy model Falcon-40B na jedną z instancji typu G5, która jest zainstalowana z procesorami graficznymi NVIDIA A10G, każda z 24 GB pamięci. Należy zauważyć, że podobne zrozumienie ma zastosowanie do typów instancji p3, p4 i p5, które są dostarczane z seriami procesorów graficznych V100, A100 i H100.

Poniżej znajduje się przegląd uzyskiwania przybliżonej wartości całkowitej pamięci wymaganej do obsługi Falcona-40B:

• Rozmiar modelu = Liczba parametrów modelu (40 miliardów dla Falcon-40B) x 4 bajty na parametr (dla FP32) = 160 GB
• Przybliżona całkowita pamięć wymagana do załadowania Falcona-40B w celu wnioskowania = Rozmiar modelu (=160 GB) + KV Cache (Attention Cache) (=*20 GB) + Dodatkowe obciążenie pamięci przez ML Frameworks (około 2 GB)

W przypadku Falcona-40B, jeśli skompresujemy model poprzez kwantyzację do typu danych bfloat16 (2 bajty), rozmiar modelu wyniesie około 80 GB. Jak widać, jest to wciąż więcej niż pamięć obsługiwana przez jedno urządzenie akceleracyjne, dlatego musimy zastosować technikę partycjonowania modelu (shardingu) ze specjalnym równoległość tensorowa (TP) i dzieli model na wiele urządzeń akceleracyjnych. Załóżmy, że wybraliśmy g5.24xlarge, który posiada 4 urządzenia GPU A10G. Jeśli skonfigurujemy DJLServing (serving.properties) w następujący sposób, możemy spodziewać się, że 80 GB wagi modelu zostanie równo podzielone na wszystkie 4 procesory graficzne:

Z tensor_parallel_degree ustawiona na 4, około 20 GB z 24 GB pamięci GPU (około 84%) jest już wykorzystane nawet przed przetworzeniem pojedynczego żądania. Pozostałe 16% procesora graficznego zostanie wykorzystane do pamięci podręcznej KV dla przychodzących żądań. Możliwe, że w przypadku Twojego scenariusza biznesowego oraz wymagań dotyczących opóźnień i przepustowości 2–3 GB pozostałej pamięci będzie więcej niż wystarczające. Jeśli nie, możesz zwiększyć rozmiar instancji do g5.48xlarge, która ma 8 procesorów graficznych i używa tensor_parallel_ Degree ustawionego na 8. W takim przypadku tylko około 10 GB dostępnej pamięci 24 GB każdego procesora graficznego jest wykorzystywane do ważenia modeli i my mieć około 60% pozostałego procesora graficznego do aktywacji i pamięci podręcznej KV. Intuicyjnie widzimy, że taka konfiguracja może pozwolić nam na uzyskanie większej przepustowości. Dodatkowo, ponieważ mamy teraz większy bufor, możemy zwiększyć max_rolling_batch_prefill_tokens i max_rolling_batch_size parametrów w celu dalszej optymalizacji przepustowości. Razem te dwa parametry będą kontrolować wstępną alokację wstępnych wypełnień aktywacyjnych i pamięci podręcznej KV dla modelu. Większa liczba tych dwóch parametrów będzie powiązana z większą przepustowością, zakładając, że masz wystarczający bufor dla pamięci podręcznej KV w pamięci GPU.

Ciągłe przetwarzanie wsadowe za pomocą PagedAttention

PagedAttention to nowy algorytm optymalizacji opracowany przez Uniwersytet Kalifornijski w Berkeley, który usprawnia ciągły proces przetwarzania wsadowego, umożliwiając nieciągłość pamięci podręcznej uwagi (pamięci podręcznej KV) poprzez alokację pamięci w stronach lub blokach o stałym rozmiarze. Inspiracją są koncepcje pamięci wirtualnej i stronicowania stosowane w systemach operacyjnych.

Zgodnie z vLLM na papierze pamięć podręczna uwagi każdej sekwencji tokenów jest podzielona na bloki i mapowana na bloki fizyczne za pomocą tabeli bloków. Podczas obliczania uwagi jądro PagedAttention może używać tabeli bloków do wydajnego pobierania bloków z pamięci fizycznej. Powoduje to znaczną redukcję marnowania pamięci i pozwala na większy rozmiar partii, większe wykorzystanie procesora graficznego i wyższą przepustowość.

Porównanie wydajności

Aby zapewnić skuteczne testowanie obciążenia konfiguracji wdrożenia, zaleca się rozpoczęcie od rozważenia scenariusza biznesowego i jasnego zdefiniowania charakterystyki danych wejściowych i wyjściowych dla aplikacji opartej na LLM. Na przykład, jeśli pracujesz nad przypadkiem użycia podsumowania call center, dane wejściowe mogą składać się z większego tekstu, na przykład transkrypcji czatu między agentem obsługi klienta a klientem o długości 500 znaków, ale dane wyjściowe mogą być stosunkowo mniejsze, około 100 tokeny, reprezentujące podsumowanie transkrypcji. Z drugiej strony, jeśli pracujesz nad scenariuszem generowania kodu, dane wejściowe mogą zawierać zaledwie 15 tokenów, np. „napisz wydajną implementację w Pythonie opisującą wszystkie zasoby EC2, w tym paginację”, ale wynik może być znacznie większe, sięgające 500 żetonów. Ważne jest również rozważenie, czy osiągnięcie mniejszych opóźnień czy maksymalizacja przepustowości jest najwyższym priorytetem w konkretnym scenariuszu.

Po uzyskaniu wszechstronnego zrozumienia scenariusza biznesowego możesz przeanalizować i określić optymalną konfigurację dla swojego środowiska hostingowego. W tym kontekście środowisko hostingowe obejmuje różne kluczowe elementy, w tym typ instancji i inne parametry konfiguracyjne, takie jak tensor_parallel_stopień, max_rolling_batch_size, max_rolling_batch_prefill_tokens, i więcej. Naszym celem jest zidentyfikowanie najskuteczniejszej konfiguracji spełniającej nasze wymagania dotyczące czasu reakcji, przepustowości i jakości wyjściowej modelu.

W naszej analizie porównaliśmy wydajność, aby zilustrować zalety ciągłego dozowania w porównaniu z tradycyjnym dozowaniem dynamicznym. Użyliśmy konfiguracji wyszczególnionych w poniższej tabeli w plikuserving.properties do dynamicznego przetwarzania wsadowego i iteracyjnego przetwarzania wsadowego przy użyciu kontenera LMI w programie SageMaker.

Dynamiczne dozowanie	Ciągłe dozowanie	Ciągłe dozowanie z PagedAttention
silnik = Python opcja.model_id=tiiuae/falcon-40b opcja.tensor_parallel_ Degree=8 opcja.dtyp=fp16 rozmiar_partii=4 max_batch_delay=100 opcja.trust_remote_code = prawda	silnik = MPI opcja.model_id = {{s3_url}} opcja.trust_remote_code = prawda opcja.tensor_parallel_stopień = 8 opcja.max_rolling_batch_size = 32 opcja.rolling_batch = auto opcja.dtyp = fp16 opcja.max_rolling_batch_prefill_tokens = 1024 opcja.paged_attention = Fałsz	silnik = MPI opcja.model_id = {{s3_url}} opcja.trust_remote_code = prawda opcja.tensor_parallel_stopień = 8 opcja.max_rolling_batch_size = 32 opcja.rolling_batch = auto opcja.dtyp = fp16 opcja.max_rolling_batch_prefill_tokens = 1024 opcja.paged_attention = Prawda

Obie konfiguracje zostały porównane dla Falcona-40B z typem danych FP16 wdrożonym na ml.g5.48xlarge w kilku różnych scenariuszach, które reprezentują aplikacje w świecie rzeczywistym:

• Mała liczba tokenów wejściowych i duża liczba generowanych tokenów – W tym scenariuszu liczba tokenów wejściowych została ustalona na 32 i wygenerowano 128 nowych tokenów

Strategia wsadowa	Przepustowość (tokeny/s)	Opóźnienie p90 (s)
Dynamiczne dozowanie	5.53	58.34
Ciągłe dozowanie	56.04	4.74
Ciągłe dozowanie z PagedAttention	59.18	4.76

• Duże dane wejściowe przy niewielkiej liczbie generowanych tokenów – Tutaj ustalamy liczbę tokenów wejściowych na 256 i zachęcamy LLM do podsumowania danych wejściowych do 32 tokenów

Strategia wsadowa	Przepustowość (tokeny/s)	Opóźnienie p90 (s)
Dynamiczne dozowanie	19.96	59.31
Ciągłe dozowanie	46.69	3.88
Ciągłe dozowanie z PagedAttention	44.75	2.67

Widzimy, że ciągłe przetwarzanie wsadowe za pomocą PagedAttention zapewnia 10-krotnie większą poprawę przepustowości w scenariuszu 1 i 2.3-krotnie w scenariuszu 2 w porównaniu do korzystania z dynamicznego przetwarzania wsadowego w SageMaker podczas korzystania z kontenera LMI.

Wnioski

W tym poście przyjrzeliśmy się, jak LLM wykorzystują pamięć i wyjaśniliśmy, jak ciągłe przetwarzanie wsadowe poprawia przepustowość przy użyciu kontenera LMI w SageMaker. Zademonstrowaliśmy zalety ciągłego dozowania dla Falcon-40B przy użyciu kontenera LMI w SageMaker, pokazując wyniki testów porównawczych. Kod znajdziesz na stronie GitHub repo.

---

O autorach

Abhi Śiwaditya jest starszym architektem rozwiązań w AWS, współpracującym ze strategicznymi globalnymi organizacjami korporacyjnymi w celu ułatwienia przyjęcia usług AWS w obszarach takich jak sztuczna inteligencja, przetwarzanie rozproszone, sieci i pamięć masowa. Specjalizuje się w głębokim uczeniu się w domenach przetwarzania języka naturalnego (NLP) i wizji komputerowej. Abhi pomaga klientom w efektywnym wdrażaniu wysokowydajnych modeli uczenia maszynowego w ekosystemie AWS.

Dawal Patel jest głównym architektem uczenia maszynowego w AWS. Pracował z organizacjami od dużych przedsiębiorstw po średniej wielkości start-upy w zakresie problemów związanych z przetwarzaniem rozproszonym i sztuczną inteligencją. Koncentruje się na uczeniu głębokim, w tym w domenach NLP i Computer Vision. Pomaga klientom uzyskać wnioskowanie o wysokiej wydajności modelu w SageMaker.

Pinak Panigrahi współpracuje z klientami w celu tworzenia rozwiązań opartych na uczeniu maszynowym w celu rozwiązywania strategicznych problemów biznesowych w AWS. Kiedy nie jest zajęty uczeniem maszynowym, można go spotkać na spacerze, czytaniu książki lub oglądaniu sportu.

Abhi Sodhani zajmuje stanowisko starszego architekta rozwiązań AI/ML w AWS, gdzie specjalizuje się w oferowaniu klientom wiedzy technicznej i wskazówek dotyczących generatywnych rozwiązań AI i ML. Jego głównym celem jest pomaganie firmom Digital Native w wykorzystaniu pełnego potencjału technologii generatywnej AI i ML, umożliwiając im skuteczne osiąganie celów biznesowych. Oprócz wysiłków zawodowych Abhi wykazuje silną pasję do zajęć intelektualnych, takich jak czytanie, a także angażuje się w działania promujące dobre samopoczucie fizyczne i psychiczne, takie jak joga i medytacja.

QingLan jest inżynierem rozwoju oprogramowania w AWS. Pracował nad kilkoma wymagającymi produktami w Amazon, w tym wysokowydajnymi rozwiązaniami wnioskowania ML i wysokowydajnym systemem rejestrowania. Zespół Qing z powodzeniem uruchomił pierwszy model miliarda parametrów w Amazon Advertising z wymaganym bardzo niskim opóźnieniem. Qing posiada dogłębną wiedzę na temat optymalizacji infrastruktury i akceleracji Deep Learning.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/