Amazon SageMaker를 사용하여 Falcon 모델의 성능 개선 | 아마존 웹 서비스

텍스트 생성 생성 AI 애플리케이션을 위한 LLM(대형 언어 모델)을 호스팅하기 위한 최적의 프레임워크와 구성은 무엇입니까? LLM을 제공하기 위한 다양한 옵션에도 불구하고 모델 크기, 다양한 모델 아키텍처, 애플리케이션의 성능 요구 사항 등으로 인해 대답하기 어려운 질문입니다. 그만큼 아마존 세이지 메이커 LMI(대형 모델 추론) 컨테이너 LLM 배포를 최적화하는 다양한 프레임워크와 기술을 통합하여 LLM 서비스를 간편하게 제공합니다. LMI 컨테이너에는 다음과 같은 강력한 서비스 스택이 있습니다. DJL 서빙 이는 기본 LLM에 불가지론적입니다. 이는 특정 LLM에 대한 호스팅 인프라의 최상의 성능을 추출하기 위해 조정할 수 있는 시스템 수준 구성 매개변수를 제공합니다. 또한 반복 일괄 처리 또는 롤링 일괄 처리라고도 알려진 연속 일괄 처리와 같은 최신 최적화를 지원하여 처리량을 크게 향상시킵니다.

이전의 게시에서는 LMI 컨테이너를 사용하여 SageMaker에 Falcon 모델 제품군을 배포하는 방법을 보여주었습니다. 이 게시물에서는 연속 일괄 처리와 같은 기술을 사용하여 Falcon-40B 제공의 처리량과 대기 시간을 개선하는 방법을 보여줍니다. 또한 실제 애플리케이션에 가장 적합한 구성을 찾는 데 도움이 될 수 있는 SageMaker LMI 컨테이너에서 제공하는 구성 매개변수에 대한 직관적인 이해를 제공합니다.

LLM을 위한 텍스트 생성 추론의 기본

먼저 텍스트 생성을 위한 LLM 추론을 수행하는 방법에 대한 몇 가지 기본 사항을 살펴보겠습니다.

정방향 패스, 활성화 및 KV 캐시

토큰의 입력 순서가 주어지면, 토큰은 다음과 같이 실행됩니다. forward pass Falcon과 같은 LLM의 모든 계층에 걸쳐 다음 토큰을 생성합니다. ㅏ forward pass 입력 데이터가 신경망을 통해 전달되어 출력을 생성하는 프로세스를 말합니다. 텍스트 생성의 경우 정방향 전달에는 초기 시드 또는 컨텍스트를 언어 모델에 공급하고 시퀀스에서 다음 문자 또는 토큰을 생성하는 작업이 포함됩니다. 텍스트 시퀀스를 생성하기 위해 프로세스는 반복적으로 수행되는 경우가 많습니다. 즉, 출력 시퀀스의 각 단계 또는 위치에 대해 반복된다는 의미입니다. 각 반복에서 모델은 생성된 텍스트의 일부가 되는 다음 문자 또는 토큰을 생성하며, 이 프로세스는 원하는 길이의 텍스트가 생성될 때까지 계속됩니다.

Falcon 또는 GPT와 같은 언어 모델을 사용한 텍스트 생성은 autoregressive. 이는 모델이 이전에 생성된 토큰을 조건으로 하면서 한 번에 하나의 토큰을 생성한다는 것을 의미합니다. 즉, 각 반복에서 모델은 이전에 생성된 텍스트를 입력으로 사용하고 해당 컨텍스트를 기반으로 다음 토큰을 예측합니다. 에서 언급했듯이 vLLM: PagedAttention을 사용한 쉽고 빠르며 저렴한 LLM 서비스, 이 자동회귀 디코딩 프로세스에서 LLM에 대한 모든 입력 토큰은 어텐션 키 및 값 텐서를 생성하고 이러한 텐서는 다음 토큰을 생성하기 위해 GPU 메모리에 보관됩니다. 이러한 캐시된 키 및 값 텐서를 종종 텐서라고 합니다. KV cache.

프리필 및 디코드 단계

Falcon과 같은 언어 모델을 사용하여 텍스트 생성에 사용되는 것과 같은 자동 회귀 디코딩 프로세스에는 일반적으로 두 가지 주요 단계가 있습니다. prefill 단계와 decode 단계. 이러한 단계는 일관되고 상황에 맞는 텍스트를 생성하는 데 중요합니다.

사전 채우기 단계에는 다음이 포함됩니다.

• 초기 컨텍스트 – 미리 채우기 단계는 사용자가 제공한 초기 컨텍스트 또는 시드 텍스트로 시작됩니다. 이 초기 컨텍스트는 문장, 구 또는 심지어 단일 단어일 수도 있습니다. 이는 텍스트 생성의 시작점을 설정하고 다음에 나올 내용에 대한 컨텍스트를 제공합니다.
• 모델 조건화 – 제공된 컨텍스트는 언어 모델을 조건화하는 데 사용됩니다. 모델은 이 컨텍스트를 입력으로 사용하고 컨텍스트에 대한 이해를 바탕으로 시퀀스의 다음 토큰(단어 또는 문자)을 생성합니다.
• 토큰 생성 – 모델은 한 번에 하나의 토큰을 생성하여 텍스트에서 다음에 올 내용을 예측합니다. 이 토큰은 컨텍스트에 추가되어 효과적으로 확장됩니다.
• 반복 프로세스 – 토큰 생성 과정이 반복적으로 반복됩니다. 각 단계에서 모델은 업데이트된 컨텍스트를 고려하면서 토큰을 생성하며, 여기에는 이제 이전 단계에서 생성된 토큰이 포함됩니다.

사전 충전 단계는 미리 결정된 중지 조건이 충족될 때까지 계속됩니다. 이 조건은 생성된 텍스트의 최대 길이, 텍스트 끝을 알리는 특정 토큰 또는 사용자나 애플리케이션이 설정한 기타 기준일 수 있습니다.

디코드 단계에는 다음이 포함됩니다.

• 완성 – 미리 채우기 단계 후에는 일부 지점에서 불완전하거나 잘릴 수 있는 부분적으로 생성된 텍스트가 있습니다. 디코드 단계에서는 텍스트를 일관되고 문법적으로 정확하도록 완성하는 작업을 담당합니다.
• 마지막 토큰에서 계속 – 디코드 단계에서는 사전 채우기 단계에서 생성된 마지막 토큰부터 모델이 시작됩니다. 이 토큰을 초기 컨텍스트로 사용하고 텍스트를 계속하기 위해 다음 토큰을 생성합니다.
• 반복 완료 – 사전 채우기 단계와 마찬가지로 토큰 생성 프로세스는 다시 반복됩니다. 모델은 한 번에 하나의 토큰을 생성하여 시퀀스의 이전 토큰을 조건으로 합니다.
• 정지상태 – 디코드 단계에는 최대 길이에 도달하거나 텍스트 끝 토큰이 발생하는 등 사전 채우기 단계와 동일할 수 있는 중지 조건도 있습니다. 이 조건이 충족되면 생성 프로세스가 중지됩니다.

사전 채우기 단계와 디코드 단계의 조합을 통해 자동 회귀 모델은 초기 컨텍스트를 기반으로 일관되고, 컨텍스트에 적합하며, 컨텍스트에 따라 일관된 텍스트 시퀀스를 생성하는 텍스트를 생성할 수 있습니다.

인용하다 Transformer 기반 생성 모델을 위한 분산 서비스 시스템 자세한 과정 설명을 위해.

동적 일괄 처리를 사용하여 처리량 최적화

지금까지 우리는 단일 입력에 대해서만 이야기했습니다. 실제로 우리는 추론을 위해 애플리케이션 클라이언트로부터 무작위로 들어오는 여러 요청을 동시에 또는 시차를 두고 처리할 것으로 예상합니다. 전통적인 방식에서는 기본 일괄 처리를 사용하여 GPU의 컴퓨팅 리소스 활용도와 처리량을 높일 수 있습니다. 일괄 처리는 일괄 처리에서 둘 이상의 요청에 대한 수치 표현을 효과적으로 결합하고 자동 회귀 정방향 전달의 병렬 실행을 수행하는 것입니다. 이 지능형 일괄 처리는 서비스 측에서 수행됩니다. SageMaker LMI의 DJLServing 서버는 다음 매개변수를 설정하여 여러 요청을 일괄 처리하여 병렬로 처리하도록 구성할 수 있습니다. 서빙.속성:

• max_batch_delay = 100 – 일괄 집계에 대한 최대 지연(밀리초)입니다. 기본값은 100밀리초입니다.
• 배치 _ 크기 = 32 – 동적 배치 크기입니다. 기본값은 1입니다.

이는 기본적으로 DJLServing이 한 번에 100밀리초 동안 요청을 대기열에 추가하거나 대기열에 있는 요청 수가 지정된 배치 크기에 도달하면 추론을 위해 백엔드에서 일괄 처리가 실행되도록 예약된다는 것을 보여줍니다. 이것은 다음과 같이 알려져 있습니다. dynamic batching. 해당 기간 동안 추가된 요청 수에 따라 일괄 처리 크기가 일괄적으로 변경될 수 있으므로 동적입니다. 그러나 요청의 특성이 다를 수 있기 때문에(예를 들어 일부 요청은 입력 토큰 20개와 ​​출력 토큰 500개의 형태일 수 있는 반면, 다른 요청은 입력 토큰 500개, 출력 토큰 20개로 반전될 수 있음) 일부 요청은 동일한 배치에서 다른 것보다 빠르게 처리를 완료합니다. 이로 인해 대기열에서 처리를 기다리는 추가 요청이 있더라도 배치의 모든 진행 중인 요청이 디코드 단계를 완료하기를 기다리는 동안 GPU의 활용도가 낮아질 수 있습니다. 다음 다이어그램은 이 프로세스를 보여줍니다.

연속 일괄 처리를 사용하여 처리량 최적화

와 continuous batching, 또한 ~으로 알려진 iterative or rolling 일괄 처리에서는 사전 채우기 단계와 디코드 단계 간의 차이점을 활용합니다. 지속적인 일괄 처리를 활성화하기 위해 DJServing은serving.properties에 따라 다음과 같은 추가 구성을 제공합니다.

• 엔진=MPI – 연속 일괄 처리에는 MPI 엔진을 사용하는 것이 좋습니다.
• 옵션.롤링_배치=auto 또는 lmi-dist – auto를 사용하면 향후 다른 최적화와 함께 가장 적절한 롤링 배치 알고리즘을 자동으로 선택하므로 사용하는 것이 좋습니다.
• option.max_rolling_batch_size=32 – 동시 요청 수를 제한합니다. 기본값은 32입니다.

연속 일괄 처리를 사용하면 제공 스택(DJLServing)은 일괄 처리의 모든 진행 중인 요청이 디코딩 단계를 완료할 때까지 기다리지 않습니다. 오히려 논리적 중단 시(디코드 단계에서 한 번의 반복이 끝날 때) 현재 일괄 처리가 계속 처리되는 동안 대기열에서 대기 중인 추가 요청을 가져옵니다(따라서 이름은 롤링 배치). 디코딩 단계의 각 반복이 끝날 때 보류 중인 요청을 확인합니다. 각 요청에 대해 사전 채우기 단계를 실행한 다음 순차 디코드 단계를 실행해야 한다는 점을 기억하세요. 사전 채우기 단계에서 요청의 초기 프롬프트에서 모든 토큰을 병렬로 처리할 수 있기 때문에 새 요청이 들어올 때마다 배치 진행 중인 요청의 디코드 단계를 일시적으로 일시 중지합니다. 즉, KV 캐시를 임시로 저장합니다. 메모리에서 활성화하고 새 요청의 사전 채우기 단계를 실행합니다.

이 캐시의 크기는 다음 옵션을 사용하여 구성할 수 있습니다.

사전 채우기가 완료되면 새로운 요청과 이전에 일시 중지된 요청을 새로운 롤링 배치에 결합하여 디코딩 단계를 병렬로 진행할 수 있습니다. 이전에 일시 중지된 요청은 중단된 디코드 단계를 계속할 수 있으며 새 요청은 첫 번째 새 토큰에서 시작됩니다.

연속 일괄 처리는 일상 생활에서 작업을 자연스럽게 병렬화하는 것과 거의 유사한 접근 방식이라는 것을 이미 알고 계실 것입니다. 무작위로 들어오는 메시지, 이메일, 전화 알림(잠재적으로 새로운 요청)이 있습니다(GPU에 대해 무작위로 시차를 두고 들어오는 여러 요청과 유사). 이 모든 일은 이메일 작성, 코딩, 회의 참여(현재 GPU에서 처리 중인 작업과 유사) 등 기내 작업을 완료하는 동안 발생합니다. 논리적인 휴식 시간에 우리는 진행 중인 작업을 일시 중지하고 알림을 확인하여 우리 측에 필요한 조치가 있는지 결정하고, 필요한 경우 이를 진행 중인 작업(실제 롤링 배치)에 추가합니다. 할 일 목록(큐)에 넣으세요.

종합해 보기: GPU의 메모리 활용에 대해 생각하는 방법

비즈니스 사용 사례에 가장 비용 효과적인 구성을 확인하려면 모델을 로드 테스트하는 것이 좋습니다. 이해를 돕기 위해 모델이 로드되고 연속 요청이 롤링 배치로 처리될 때 GPU의 메모리 공간을 시각화해 보겠습니다. 이 게시물에서는 각각 40GB의 메모리를 갖춘 NVIDIA A5G GPU가 설치된 G10 인스턴스 유형 인스턴스 중 하나에 Falcon-24B 모델을 로드한다고 가정합니다. V3, A4 및 H5 GPU 시리즈와 함께 제공되는 p100, p100 및 p100 인스턴스 유형에도 비슷한 이해가 적용됩니다.

다음은 Falcon-40B를 제공하는 데 필요한 총 메모리의 대략적인 값을 가져오는 개요입니다.

• 모형 크기 = 모델 매개변수 수(Falcon-40B의 경우 40억 개) x 매개변수당 4바이트(FP32의 경우) = 160GB
• 추론을 위해 Falcon-40B를 로드하는 데 필요한 대략적인 총 메모리 = 모델 크기(=160GB) + KV 캐시(Attention Cache)(=*20GB) + ML 프레임워크에 의한 추가 메모리 오버헤드(약 2GB)

Falcon-40B의 경우 모델을 bfloat16(2바이트) 데이터 형식으로 양자화하여 압축하면 모델 크기는 약 80GB가 됩니다. 보시다시피 이는 하나의 가속기 장치가 지원하는 메모리보다 여전히 크기 때문에 특수한 모델 파티셔닝(샤딩) 기술을 채택해야 합니다. 텐서 병렬 처리 (TP) 여러 가속기 장치에 걸쳐 모델에 접근하고 분할합니다. 5.24개의 A4G GPU 장치가 있는 g10xlarge를 선택했다고 가정해 보겠습니다. 다음과 같이 DJLServing(serving.properties)을 구성하면 80GB의 모델 가중치가 4개의 GPU 모두에 균등하게 분배될 것으로 예상할 수 있습니다.

와 tensor_parallel_degree 4로 설정하면 단일 요청이 처리되기 전에도 20GB GPU 메모리 중 약 24GB(약 84%)가 이미 사용됩니다. GPU의 나머지 16%는 들어오는 요청에 대한 KV 캐시에 사용됩니다. 비즈니스 시나리오와 해당 대기 시간 및 처리량 요구 사항에 따라 남은 메모리는 2~3GB이면 충분할 수 있습니다. 그렇지 않은 경우 인스턴스 크기를 GPU가 5.48개 있고 tensor_parallel_degree가 8로 설정된 g8xlarge로 늘릴 수 있습니다. 이 경우 각 GPU의 사용 가능한 10GB 메모리 중 약 24GB만 모델 가중치에 활용되며 우리는 활성화 및 KV 캐시를 위해 남은 GPU의 약 60%가 필요합니다. 직관적으로 이 구성을 통해 더 높은 처리량을 얻을 수 있음을 알 수 있습니다. 또한 이제 버퍼가 더 크기 때문에 max_rolling_batch_prefill_tokens 및 max_rolling_batch_size 처리량을 더욱 최적화하기 위한 매개변수입니다. 이 두 매개변수는 함께 모델에 대한 활성화 사전 채우기 및 KV 캐시의 사전 할당을 제어합니다. GPU 메모리에 KV 캐시에 대한 버퍼가 충분하다고 가정할 때 이 두 매개변수의 숫자가 클수록 처리량이 더 커집니다.

PagedAttention을 사용한 지속적인 일괄 처리

PagedAttention은 UC Berkeley에서 개발한 새로운 최적화 알고리즘으로, 고정 크기 페이지 또는 블록에 메모리를 할당하여 Atttention 캐시(KV 캐시)가 비연속적이 되도록 하여 연속 일괄 처리 프로세스를 개선합니다. 이는 운영 체제에서 사용되는 가상 메모리 및 페이징 개념에서 영감을 받았습니다.

당 vLLM 논문에서는 각 토큰 시퀀스의 어텐션 캐시를 블록으로 분할하고 블록 테이블을 통해 물리적 블록에 매핑합니다. Attention을 계산하는 동안 PagedAttention 커널은 블록 테이블을 사용하여 물리적 메모리에서 블록을 효율적으로 가져올 수 있습니다. 그 결과 메모리 낭비가 크게 줄어들고 배치 크기가 커지고 GPU 활용도가 높아지며 처리량이 높아집니다.

성능 비교

배포 구성의 효과적인 로드 테스트를 보장하려면 비즈니스 시나리오를 고려하고 LLM 기반 응용 프로그램의 입력 및 출력 특성을 명확하게 정의하는 것부터 시작하는 것이 좋습니다. 예를 들어 콜센터 요약 사용 사례를 작업하는 경우 입력은 고객 서비스 상담원과 고객 간의 500토큰 채팅 기록과 같은 더 큰 텍스트로 구성될 수 있지만 출력은 약 100 정도로 비교적 작을 수 있습니다. 성적표의 요약을 나타내는 토큰입니다. 반면, 코드 생성 시나리오에서 작업하는 경우 입력은 "페이지 매김을 포함하여 모든 EC15 리소스를 설명하기 위해 Python으로 효율적인 구현을 작성합니다"와 같이 토큰 2개만큼 짧을 수 있지만 출력은 훨씬 더 많을 수 있습니다. 더 커지면 500개 토큰에 도달합니다. 특정 시나리오에서는 대기 시간을 낮추거나 처리량을 최대화하는 것이 최우선 순위인지 고려하는 것도 중요합니다.

비즈니스 시나리오를 포괄적으로 이해한 후에는 호스팅 환경에 대한 최적의 구성을 분석하고 결정할 수 있습니다. 이러한 맥락에서 호스팅 환경은 인스턴스 유형 및 기타 구성 매개변수를 포함한 다양한 핵심 요소를 포함합니다. 텐서_병렬_정도, max_rolling_batch_size, max_rolling_batch_prefill_tokens, 그리고 더. 우리의 목표는 응답 시간, 처리량 및 모델 출력 품질 요구 사항을 지원하는 가장 효과적인 설정을 식별하는 것입니다.

분석에서는 기존 동적 일괄 처리에 비해 연속 일괄 처리의 이점을 설명하기 위해 성능을 벤치마킹했습니다. SageMaker에서 LMI 컨테이너를 사용하여 동적 일괄 처리 및 반복 일괄 처리를 위해serving.properties에서 다음 표에 자세히 설명된 구성을 사용했습니다.

동적 배칭	연속 배치	PagedAttention을 사용한 연속 일괄 처리
엔진=파이썬 option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 배치_크기=4 max_batch_delay=100 option.trust_remote_code = true	엔진 = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = 자동 option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention=거짓	엔진 = MPI option.model_id = {{s3_url}} option.trust_remote_code = true option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = 자동 option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention=참

두 가지 구성은 실제 애플리케이션을 나타내는 몇 가지 다른 시나리오에서 ml.g40xlarge에 배포된 FP16 데이터 유형을 사용하여 Falcon-5.48B에 대해 벤치마킹되었습니다.

• 다수의 토큰이 생성되는 소수의 입력 토큰 – 이 시나리오에서는 입력 토큰 수가 32개로 고정되었으며 128개의 새 토큰이 생성되었습니다.

배치 전략	처리량(토큰/초)	대기 시간 p90(초)
동적 배칭	5.53	58.34
연속 배치	56.04	4.74
PagedAttention을 사용한 연속 일괄 처리	59.18	4.76

• 소수의 토큰이 생성되는 대규모 입력 – 여기서는 입력 토큰 수를 256개로 고정하고 LLM이 입력을 32개 토큰으로 요약하도록 유도합니다.

배치 전략	처리량(토큰/초)	대기 시간 p90(초)
동적 배칭	19.96	59.31
연속 배치	46.69	3.88
PagedAttention을 사용한 연속 일괄 처리	44.75	2.67

PagedAttention을 사용한 지속적인 배치 처리는 LMI 컨테이너를 사용하는 동안 SageMaker에서 동적 배치 처리를 사용하는 것과 비교하여 시나리오 10에서 1배, 시나리오 2.3에서 2배 더 높은 처리량 향상을 제공하는 것을 확인할 수 있습니다.

결론

이 게시물에서는 LLM이 메모리를 사용하는 방법을 살펴보고 SageMaker에서 LMI 컨테이너를 사용하여 연속 일괄 처리가 처리량을 향상시키는 방법을 설명했습니다. 벤치마크 결과를 보여줌으로써 SageMaker에서 LMI 컨테이너를 사용하여 Falcon-40B에 대한 연속 일괄 처리의 이점을 입증했습니다. 코드는 다음에서 찾을 수 있습니다. GitHub 레포.

---

저자에 관하여

아비 시바디티야 인공 지능, 분산 컴퓨팅, 네트워킹 및 스토리지와 같은 영역에서 AWS 서비스 채택을 촉진하기 위해 전략적 글로벌 기업 조직과 협력하는 AWS의 수석 솔루션 설계자입니다. 그의 전문성은 자연어 처리(NLP) 및 컴퓨터 비전 영역의 딥 러닝에 있습니다. Abhi는 고객이 AWS 에코시스템 내에서 고성능 기계 학습 모델을 효율적으로 배포할 수 있도록 지원합니다.

다왈 파텔 AWS의 수석 기계 학습 설계자입니다. 그는 분산 컴퓨팅 및 인공 지능과 관련된 문제에 대해 대기업에서 중견 스타트업에 이르는 다양한 조직과 협력했습니다. 그는 NLP 및 Computer Vision 도메인을 포함한 딥 러닝에 중점을 둡니다. 그는 고객이 SageMaker에서 고성능 모델 추론을 달성하도록 돕습니다.

피낙 파니그라히 고객과 협력하여 AWS의 전략적 비즈니스 문제를 해결하기 위한 기계 학습 기반 솔루션을 구축합니다. 기계 학습에 전념하지 않을 때에는 하이킹을 하거나, 책을 읽거나, 스포츠 경기를 관람합니다.

아비 소다니 AWS에서 수석 AI/ML 솔루션 아키텍트 직책을 맡고 있으며, 여기서 그는 고객에게 Generative AI 및 ML 솔루션에 대한 기술 전문 지식과 지침을 제공하는 것을 전문으로 합니다. 그의 주요 초점은 디지털 기반 비즈니스가 생성 AI 및 ML 기술의 잠재력을 최대한 실현하여 비즈니스 목표를 효과적으로 달성할 수 있도록 지원하는 것입니다. 전문적인 노력 외에도 Abhi는 독서와 같은 지적 활동뿐만 아니라 요가, 명상과 같은 신체적, 정신적 웰빙을 촉진하는 활동에 참여하는 것에 대한 강한 열정을 보여줍니다.

칭란 AWS의 소프트웨어 개발 엔지니어입니다. 그는 고성능 ML 추론 솔루션 및 고성능 로깅 시스템을 포함하여 Amazon에서 여러 도전적인 제품을 작업해 왔습니다. Qing의 팀은 요구되는 매우 짧은 지연 시간으로 Amazon Advertising에서 첫 번째 XNUMX억 매개변수 모델을 성공적으로 출시했습니다. Qing은 인프라 최적화 및 딥 러닝 가속화에 대한 심층 지식을 보유하고 있습니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/