머신 러닝(ML) 모델 배포는 오늘날 비즈니스에 매우 까다로운 성능 및 대기 시간 요구 사항을 가질 수 있습니다. 사기 탐지 및 광고 배치와 같은 사용 사례는 밀리초가 중요하고 비즈니스 성공에 중요한 예입니다. 엄격한 SLA(서비스 수준 계약)를 충족해야 하며 일반적인 요청에는 사전 처리, 데이터 변환, 모델 선택 논리, 모델 집계 및 사후 처리와 같은 여러 단계가 필요할 수 있습니다. 규모에서 이것은 종종 짧은 대기 시간을 유지하면서 엄청난 양의 트래픽을 유지하는 것을 의미합니다. 일반적인 디자인 패턴에는 직렬 추론 파이프라인, 앙상블(산란-수집) 및 비즈니스 논리 워크플로가 포함되며, 이를 통해 요청의 전체 워크플로를 DAG(방향성 비순환 그래프)로 실현합니다. 그러나 워크플로가 더 복잡해지면 전체 응답 시간이 늘어나 최종 사용자 경험에 부정적인 영향을 미치고 비즈니스 목표를 위태롭게 할 수 있습니다. Triton은 입력 및 출력 텐서가 연결된 파이프라인에서 여러 모델이 구성되어 이러한 워크로드를 처리하는 데 도움이 되는 이러한 사용 사례를 해결할 수 있습니다.
ML 모델 추론과 관련하여 목표를 평가할 때 많은 옵션을 고려할 수 있지만 다음과 같이 유능하고 입증된 옵션은 거의 없습니다. 아마존 세이지 메이커 과 트리톤 추론 서버. Triton Inference Server가 포함된 SageMaker는 매우 낮은(한 자리 밀리초) 추론 대기 시간으로 처리량과 하드웨어 활용도를 극대화하도록 특별히 제작되었기 때문에 많은 고객에게 인기 있는 선택이었습니다. 지원되는 광범위한 ML 프레임워크(TensorFlow, PyTorch, ONNX, XGBoost 및 NVIDIA TensorRT 포함)와 NVIDIA GPU, CPU 및 AWS 인 페렌 시아. 또한 Triton Inference Server는 완전 관리형 종단 간 ML 서비스인 SageMaker와 통합되어 모델 호스팅을 위한 실시간 추론 옵션을 제공합니다.
이 게시물에서는 Triton Inference Server를 사용하여 SageMaker에 사기 탐지 앙상블 워크로드를 배포하는 방법을 안내합니다.
솔루션 개요
프로젝트의 총 비용을 대략적으로 계산하려면 모든 프로젝트에 요구 사항 목록과 노력 추정치가 있어야 합니다. 조직의 결정을 뒷받침하는 투자 수익(ROI)을 추정하는 것이 중요합니다. 워크로드를 Triton으로 이동할 때 고려해야 할 몇 가지 고려 사항은 다음과 같습니다.
노력 추정은 소프트웨어 개발의 핵심이며 측정은 종종 불완전하고 불확실하며 잡음이 많은 입력을 기반으로 합니다. ML 워크로드도 다르지 않습니다. 여러 요인이 ML 추론 아키텍처에 영향을 미칩니다., 그 중 일부는 다음과 같습니다.
- 클라이언트 측 지연 시간 예산 – 일반적으로 백분위수로 표시되는 추론 응답에 대한 클라이언트 측 왕복 최대 허용 대기 시간을 지정합니다. 수십 밀리초에 가까운 대기 시간 예산이 필요한 워크로드의 경우 네트워크 전송에 비용이 많이 들 수 있으므로 에지에서 모델을 사용하는 것이 더 적합합니다.
- 데이터 페이로드 분포 크기 – 페이로드(종종 이라고 함) 메시지 본문는 클라이언트에서 모델로 전송된 요청 데이터와 모델에서 클라이언트로 전송된 응답 데이터입니다. 페이로드 크기는 종종 대기 시간에 큰 영향을 미치므로 이를 고려해야 합니다.
- 데이터 형식 – 페이로드가 ML 모델로 전송되는 방식을 지정합니다. 형식은 JSON 및 CSV와 같이 사람이 읽을 수 있지만 종종 압축되고 크기가 작은 바이너리 형식도 있습니다. 이것은 압축 오버헤드와 전송 크기 사이의 균형입니다. 즉, 네트워크를 통해 전송되는 바이트를 저장하기 위해 압축 또는 압축 해제에 CPU 주기와 대기 시간이 추가됩니다. 이 게시물은 JSON 및 바이너리 형식을 모두 활용하는 방법을 보여줍니다.
- 필요한 소프트웨어 스택 및 구성 요소 – 스택은 운영 체제, 런타임 및 소프트웨어 계층을 포함하여 ML 애플리케이션을 지원하기 위해 함께 작동하는 구성 요소 모음입니다. Triton에는 널리 사용되는 ML 프레임워크가 내장되어 있습니다. 백엔드, ONNX, TensorFlow, FIL, OpenVINO, 기본 Python 등과 같은. 당신은 또한 작성할 수 있습니다 커스텀 백엔드 자체 제작 구성 요소를 위해. 이 게시물에서는 NVIDIA에서 제공한 FIL 및 Python Triton 백엔드로 각각 마이그레이션하는 XGBoost 모델 및 데이터 사전 처리에 대해 설명합니다.
이러한 모든 요소는 워크로드 수행 방식을 평가하는 데 중요한 역할을 해야 하지만 이 사용 사례에서는 Triton Inference Server를 사용하여 SageMaker에서 호스팅할 ML 모델을 이동하는 데 필요한 작업에 중점을 둡니다. 특히, Python으로 작성된 전처리 로직이 있는 XGBoost 모델로 구성된 사기 탐지 앙상블의 예를 사용합니다.
NVIDIA Triton 추론 서버
Triton Inference Server는 처음부터 팀이 GPU 또는 CPU 기반 인프라의 모든 프레임워크에서 훈련된 AI 모델을 배포, 실행 및 확장할 수 있도록 설계되었습니다. 또한 동적 일괄 처리, 동시 실행, 최적 모델 구성, 모델 앙상블 및 스트리밍 입력 지원과 같은 기능을 통해 대규모 고성능 추론을 제공하도록 최적화되었습니다.
다음 다이어그램은 NVIDIA Triton 앙상블 파이프라인의 예를 보여줍니다.
워크로드는 제공되는 이점을 극대화하기 위해 SageMaker 호스팅과 함께 Triton이 제공하는 기능을 고려해야 합니다. 예를 들어 Triton은 HTTP뿐만 아니라 C API, 필요할 때 페이로드 최적화와 유연성을 허용합니다. 앞서 언급했듯이 Triton은 TensorFlow, PyTorch, ONNX, XGBoost 및 NVIDIA TensorRT를 포함하여 기본적으로 몇 가지 인기 있는 프레임워크를 지원합니다. 이러한 프레임워크는 Triton 백엔드를 통해 지원되며 백엔드가 사용 사례를 지원하지 않는 드문 경우입니다. Triton을 사용하면 자신의 것을 구현하고 쉽게 통합할 수 있습니다..
다음 다이어그램은 NVIDIA Triton 아키텍처의 예를 보여줍니다.
SageMaker의 NVIDIA Triton
SageMaker 호스팅 서비스는 모델 배포 및 서비스를 더 쉽게 만드는 것을 목표로 하는 SageMaker 기능 세트입니다. 다양한 사용 사례에 맞게 조정된 ML 모델을 쉽게 배포, 자동 확장, 모니터링 및 최적화할 수 있는 다양한 옵션을 제공합니다. 즉, 영구적이고 서버리스 옵션과 함께 항상 사용 가능한 것부터 일시적, 장기 실행 또는 일괄 추론 요구 사항에 이르기까지 모든 유형의 사용 패턴에 대해 배포를 최적화할 수 있습니다.
SageMaker 호스팅 우산 아래에는 지원되는 해당 ML 프레임워크에 대한 적절한 모델 서버 소프트웨어와 함께 사전 패키지된 SageMaker 추론 DLC(딥 러닝 컨테이너) 세트도 있습니다. 이를 통해 모델 배포의 가장 복잡한 기술적 측면이며 일반적으로 데이터 과학자의 기술에 속하지 않는 모델 서버 설정 없이 높은 추론 성능을 얻을 수 있습니다. Triton 추론 서버는 현재 가능 SageMaker DLC에서.
다양한 서빙 프레임워크의 이러한 광범위한 옵션, 모듈성 및 사용 용이성은 SageMaker와 Triton을 강력한 일치로 만듭니다.
NVIDIA FIL 백엔드 지원
와 더불어 Triton의 22.05 버전 릴리스, NVIDIA는 이제 XGBoost, LightGBM, Scikit-learn 및 cuML을 비롯한 여러 인기 있는 ML 프레임워크로 훈련된 포리스트 모델을 지원합니다. Triton용 FIL 백엔드를 사용할 때 제공하는 모델 아티팩트가 지원되는지 확인해야 합니다. 예를 들어 FIL은 다음을 지원합니다. model_type xgboost, xgboost_json, lightgbm및 treelite_checkpoint, 제공된 모델이 XGBoost 바이너리 형식인지, XGBoost JSON 형식인지, LightGBM 텍스트 형식인지, Treelite 바이너리 형식인지 각각 나타냅니다.
이 백엔드 지원은 FIL이 XGBoost 모델을 지원하기 때문에 이 예제에서 사용하는 데 필수적입니다. 확인해야 할 유일한 고려 사항은 배포하는 모델이 바이너리 또는 JSON 형식을 지원하는지 확인하는 것입니다.
적절한 모델 형식이 있는지 확인하는 것 외에도 다른 고려 사항을 고려해야 합니다. Triton용 FIL 백엔드는 개발자가 워크로드를 조정하고 모델 실행 성능을 최적화할 수 있는 구성 가능한 옵션을 제공합니다. 구성 dynamic_batching FIL의 병렬 계산을 효율적으로 사용하여 전체 배치를 함께 추론하기 위해 Triton이 클라이언트 측 요청을 보유하고 서버 측에서 일괄 처리할 수 있습니다. 옵션 max_queue_delay_microseconds Triton이 배치를 형성하기 위해 대기하는 시간에 대한 안전 장치 제어를 제공합니다. FIL은 구성에 의해 활성화될 수 있는 Shapley 설명자와 함께 제공됩니다. treeshap_output; 그러나 Shapley 출력은 출력 크기로 인해 성능이 저하된다는 점을 염두에 두어야 합니다. 또 다른 중요한 측면은 storage_type 메모리 풋프린트와 런타임 사이의 균형을 맞추기 위해. 예를 들어 스토리지를 SPARSE로 사용하면 메모리 소비를 줄일 수 있는 반면 DENSE는 메모리 사용을 높이는 대신 모델 실행 성능을 낮출 수 있습니다. 이들 각각에 대한 최선의 선택을 결정하는 것은 워크로드와 대기 시간 예산에 따라 다르므로 모든 옵션을 자세히 살펴보는 것이 좋습니다. FIL 백엔드 FAQ 그리고 FIL에서 사용 가능한 구성 목록.
triton에서 모델을 호스팅하는 단계
워크로드를 Triton으로 이동할 때 고려해야 할 사항의 예로 사기 탐지 사용 사례를 살펴보겠습니다.
워크로드 식별
이 사용 사례에서는 소매 고객의 결제 프로세스 중에 사기 감지 모델이 사용되었습니다. 추론 파이프라인은 전처리를 위한 데이터 준비를 포함하는 전처리 로직과 함께 XGBoost 알고리즘을 사용하고 있습니다.
현재 및 목표 성과 측정항목과 적용될 수 있는 기타 목표 식별
엔드 투 엔드 추론 시간이 너무 길어 수용할 수 없을 수도 있습니다. 목표는 동일한 요청 볼륨 및 각 처리량에 대해 수십 밀리초의 대기 시간에서 한 자릿수 대기 시간으로 전환하는 것일 수 있습니다. 데이터 사전 처리 및 XGBoost 모델에서 대부분의 시간을 소비한다고 결정합니다. 네트워크 및 페이로드 크기와 같은 기타 요소는 종단 간 추론 시간과 관련된 오버헤드에서 최소한의 역할을 합니다.
Triton이 요구 사항에 따라 워크로드를 호스팅할 수 있는지 확인하기 위해 역으로 작업
Triton이 귀하의 요구 사항을 충족할 수 있는지 확인하려면 두 가지 주요 관심 영역에 주의를 기울여야 합니다. 첫 번째는 Triton이 HTTP 또는 C API와 같은 허용 가능한 프런트 엔드 옵션을 제공할 수 있도록 하는 것입니다.
이전에 언급했듯이 Triton이 아티팩트를 제공할 수 있는 백엔드를 지원하는지 확인하는 것도 중요합니다. Triton은 다음을 지원합니다. 백엔드 PyTorch 및 TensorFlow와 같은 다양한 프레임워크를 지원하도록 맞춤 제작되었습니다. 모델이 지원되고 Triton이 기대하는 적절한 모델 형식이 있는지 확인하십시오. 이렇게 하려면 먼저 Triton 백엔드가 지원하는 모델 형식을 확인하십시오. 많은 경우 모델을 변경할 필요가 없습니다. 다른 경우에는 모델을 다른 형식으로 변환해야 할 수 있습니다. 소스 및 대상 형식에 따라 변환과 같은 다양한 옵션이 존재합니다. Treelite의 바이너리 체크포인트 형식을 사용하는 Python 피클 파일.
이 사용 사례의 경우 다음을 결정합니다. FIL 백엔드 변경할 필요 없이 XGBoost 모델을 지원할 수 있으며 파이썬 백엔드 전처리를 위해. Triton의 앙상블 기능을 사용하면 호스팅 인스턴스 간의 비용이 많이 드는 네트워크 호출을 방지하여 워크로드를 더욱 최적화할 수 있습니다.
계획을 세우고 호스팅에 Triton을 사용하는 데 필요한 노력을 추정합니다.
모델을 Triton으로 이전할 계획에 대해 이야기해 보겠습니다. 모든 Triton 배포에는 다음이 필요합니다.
- Triton 백엔드에 필요한 모델 아티팩트
- 트리톤 구성 파일
- 적절한 구조의 모델 저장소 폴더
이 게시물의 뒷부분에서 이러한 배포 종속성을 만드는 방법의 예를 보여줍니다.
계획 실행 및 결과 검증
적절하게 구조화된 모델 리포지토리에 필요한 파일과 아티팩트를 생성한 후에는 배포를 조정하고 테스트하여 이제 대상 메트릭에 도달했는지 확인해야 합니다.
이 시점에서 다음을 사용할 수 있습니다. SageMaker 추론 추천자 요구 사항에 따라 가장 적합한 엔드포인트 인스턴스 유형을 결정합니다. 또한 Triton은 더 나은 성능을 얻기 위해 빌드 최적화를 수행하는 도구를 제공합니다.
실시
이제 구현 세부 사항을 살펴보겠습니다. 이를 위해 우리는 예상할 수 있는 것의 예를 제공하는 두 개의 노트북을 준비했습니다. 그만큼 첫 번째 노트북 주어진 XGBoost 모델의 훈련과 훈련 및 추론 시간 모두에 사용되는 전처리 로직을 보여줍니다. 그만큼 두 번째 노트북 Triton에 배포하는 데 필요한 아티팩트를 준비하는 방법을 보여줍니다.
첫 번째 노트북은 조직에서 사용하는 기존 노트북을 보여줍니다. 여울 라이브러리 모음과 RAPIDS Conda 커널. 이 인스턴스는 NVIDIA T4 프로세서를 사용하여 GPU 가속화된 AWS에서 제공하는 G4DN 인스턴스 유형에서 실행됩니다.
이 예의 전처리 작업은 GPU 가속의 이점을 얻고 cuML 및 cuDF 라이브러리를 많이 사용합니다. 이에 대한 예는 cuML을 사용하여 범주형 레이블 인코딩을 표시하는 다음 코드에 있습니다. 우리는 또한 생성 label_encoders.pkl 인코더를 직렬화하고 추론 시간 동안 전처리에 사용할 수 있는 파일입니다.
첫 번째 노트북은 XGBoost 모델을 훈련하고 그에 따라 아티팩트를 저장하는 것으로 끝납니다.
이 시나리오에서는 훈련 코드가 이미 존재하고 훈련 시 모델을 변경할 필요가 없습니다. 또한 훈련 중 전처리를 위해 GPU 가속을 사용했지만 추론 시 전처리를 위해 CPU를 사용할 계획입니다. 나중에 포스트에서 자세히 설명드리겠습니다.
이제 두 번째 노트북으로 이동하여 성공적인 Triton 배포에 필요한 사항을 기억해 보겠습니다.
먼저 백엔드에 필요한 모델 아티팩트가 필요합니다. 이 앙상블을 위해 생성해야 하는 파일은 다음과 같습니다.
- 전처리 아티팩트(
model.py,label_encoders.pkl) - XGBoost 모델 아티팩트(
xgboost.json)
Triton의 Python 백엔드를 사용하려면 Conda 환경을 종속성으로 사용해야 합니다. 이 경우 Python 백엔드를 사용하여 원시 데이터를 FIL 백엔드에서 실행 중인 XGBoost 모델에 공급하기 전에 사전 처리합니다. 원래 RAPIDS cuDF 및 cuML 라이브러리를 사용하여 데이터 사전 처리를 수행했지만(이전에 GPU를 사용하여 참조) 여기에서는 Pandas 및 Scikit-learn을 추론 시간에 대한 사전 처리 종속성으로 사용합니다(CPU 사용). 우리는 다음 세 가지 이유로 이를 수행합니다.
- 종속성을 위한 Conda 환경을 만드는 방법과 이를 패키지로 묶는 방법을 보여주기 위해 예상되는 형식 Triton의 Python 백엔드에 의해.
- XGBoost 모델이 FIL 백엔드의 GPU에서 실행되는 동안 CPU의 Python 백엔드에서 실행되는 전처리 모델을 보여줌으로써 Triton의 앙상블 파이프라인의 각 모델이 어떻게 다른 프레임워크 백엔드에서 실행되고 다른 하드웨어에서 다른 하드웨어에서 실행될 수 있는지 보여줍니다. 구성.
- RAPIDS 라이브러리(cuDF, cuML)가 CPU 대응 라이브러리(Pandas, Scikit-learn)와 어떻게 호환되는지 강조합니다. 이렇게 하면
LabelEncoderscuML에서 생성된 것은 Scikit-learn에서 사용할 수 있으며 그 반대의 경우도 마찬가지입니다. 추론 시간 동안 많은 양의 테이블 형식 데이터를 사전 처리할 것으로 예상되는 경우 여전히 RAPIDS를 사용하여 GPU 가속을 사용할 수 있습니다.
우리가 만든 것을 기억하십시오. label_encoders.pkl 첫 번째 노트북의 파일입니다. 카테고리 인코딩을 위해 할 일이 없습니다. model.py 전처리용 파일.
Triton Python 백엔드에 필요한 model.py 파일을 생성하기 위해 다음을 준수합니다. 백엔드에 필요한 포맷 들어오는 텐서를 처리하고 앞에서 참조한 레이블 인코더를 사용하는 Python 논리를 포함합니다. 당신은 검토 할 수 있습니다 파일 전처리에 사용됩니다.
XGBoost 모델의 경우 더 이상 수행할 필요가 없습니다. 우리는 첫 번째 노트북에서 모델을 훈련했으며 Triton의 FIL 백엔드는 XGBoost 모델에 대한 추가 노력이 필요하지 않습니다.
다음으로 Triton 구성 파일이 필요합니다. Triton 앙상블의 각 모델에는 다음이 필요합니다. config.pbtxt 파일. 또한, 우리는 또한 config.pbtxt 앙상블 전체를 위한 파일입니다. 이러한 파일을 통해 Triton은 앙상블과 관련된 DAG를 정의하는 데 도움이 될 뿐만 아니라 우리가 예상하는 입력 및 출력과 같은 정보로 앙상블에 대한 메타데이터를 알 수 있습니다.
마지막으로 Triton에 모델을 배포하려면 적절한 폴더 구조를 가진 모델 리포지토리 폴더가 필요합니다. Triton에는 모델 리포지토리 레이아웃에 대한 특정 요구 사항이 있습니다. 최상위 모델 리포지토리 디렉터리 내에서 각 모델에는 해당 모델에 대한 정보가 포함된 자체 하위 디렉터리가 있습니다. Triton의 각 모델 디렉토리에는 모델 버전을 나타내는 숫자 하위 디렉토리가 하나 이상 있어야 합니다. 우리의 사용 사례의 경우 결과 구조는 다음과 같아야 합니다.
이 세 가지 전제 조건이 충족되면 배포를 위한 패키징으로 압축 파일을 만들고 업로드합니다. 아마존 단순 스토리지 서비스 (아마존 S3).
이제 이전 단계에서 Amazon S3에 업로드한 모델 리포지토리에서 SageMaker 모델을 생성할 수 있습니다.
이 단계에서는 추가 환경 변수도 제공합니다. SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, Triton이 로드할 모델의 이름을 지정합니다. 이 키의 값은 Amazon S3에 업로드된 모델 패키지의 폴더 이름과 일치해야 합니다. 이 변수는 단일 모델의 경우 선택 사항입니다. 앙상블 모델의 경우 Triton이 SageMaker에서 시작하려면 이 키를 지정해야 합니다.
또한 다음을 설정할 수 있습니다. SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT 및 SAGEMAKER_TRITON_THREAD_COUNT 스레드 수를 최적화하기 위해. 두 구성 값 모두 CPU에서 실행 중인 스레드 수를 조정하는 데 도움이 되므로 코어 수가 많은 CPU에 대해 이러한 값을 증가시켜 활용도를 높일 수 있습니다. 대부분의 경우 기본값이 잘 작동하는 경우가 많지만 작업 부하에 대해 추가 효율성을 얻을 수 있는지 실험해 볼 가치가 있습니다.
이전 모델을 사용하여 엔드포인트에서 원하는 인스턴스의 유형과 수를 지정할 수 있는 엔드포인트 구성을 생성합니다.
마지막으로 이전 끝점 구성을 사용하여 새 SageMaker 끝점을 만들고 배포가 완료될 때까지 기다립니다. 상태가 다음으로 변경됩니다. InService 배포가 성공한 후.
그게 다야! 이제 엔드포인트를 테스트 및 검증할 준비가 되었습니다. 이 시점에서 가능한 최고의 성능을 얻기 위해 인스턴스 유형과 구성을 최적화하는 데 도움이 되는 다양한 도구를 사용할 수 있습니다. 다음 그림은 Triton의 XGBoost 모델에 FIL 백엔드를 사용하여 얻을 수 있는 이득의 예를 제공합니다.
요약
이 게시물에서는 Triton Inference Server를 사용하여 SageMaker에 XGBoost 앙상블 워크로드를 배포하는 과정을 안내했습니다. SageMaker의 Triton으로 워크로드를 이동하면 투자 수익을 얻을 수 있습니다. 기술 채택과 마찬가지로 심사 프로세스와 계획이 핵심이며 워크로드를 이동할 때 고려해야 할 사항을 안내하는 XNUMX단계 프로세스를 자세히 설명했습니다. 또한 SageMaker의 Triton에서 Python 사전 처리 및 XGBoost 모델을 사용하는 앙상블을 배포하는 데 필요한 단계에 대해 자세히 설명합니다.
SageMaker는 ML 수명 주기의 각 단계에서 차별화되지 않은 무거운 작업을 제거하는 도구를 제공하여 모델 배포를 완전히 최적화하는 데 필요한 빠른 실험 및 탐색을 촉진합니다. Triton Inference Server에 대한 SageMaker 호스팅 지원은 짧은 대기 시간, 높은 TPS(초당 트랜잭션) 워크로드를 가능하게 합니다.
이 예제에 사용된 노트북은 다음에서 찾을 수 있습니다. GitHub의.
저자,
제임스 파크 Amazon Web Services의 솔루션 아키텍트입니다. 그는 Amazon.com과 협력하여 AWS에서 기술 솔루션을 설계, 구축 및 배포하며 특히 AI 및 기계 학습에 관심이 있습니다. 여가 시간에 그는 새로운 문화, 새로운 경험을 찾고 최신 기술 동향을 파악하는 것을 즐깁니다.
리우 지아 홍 NVIDIA 클라우드 서비스 제공업체 팀의 솔루션 설계자입니다. 그는 교육 및 추론 문제를 해결하기 위해 NVIDIA 가속 컴퓨팅을 활용하는 기계 학습 및 AI 솔루션을 채택하는 고객을 지원합니다. 여가 시간에는 종이접기, DIY 프로젝트, 농구를 즐깁니다.
크시티즈 굽타 NVIDIA의 솔루션 아키텍트입니다. 그는 NVIDIA가 제공해야 하는 GPU AI 기술에 대해 클라우드 고객을 교육하고 기계 학습 및 딥 러닝 애플리케이션을 가속화하도록 지원하는 것을 즐깁니다. 일 외에는 달리기, 하이킹, 야생 동물 관찰을 즐깁니다.
브루노 아기아르 데 멜로 Amazon.com의 소프트웨어 개발 엔지니어로 과학 팀이 ML 워크로드를 구축, 배포 및 릴리스하도록 지원합니다. 그는 특히 지연 시간이 제한된 사용 사례에서 모델 실행 성능이 모델 품질 성능만큼 중요하다는 통찰력으로 고려하고 측정해야 하는 ML 모델링/설계 단계 내의 계측 및 제어 가능한 측면에 관심이 있습니다. 여가 시간에는 와인, 보드 게임, 요리를 즐깁니다.
엘리우스 트리아나 NVIDIA의 개발자 관계 관리자입니다. 그는 Amazon 및 AWS 제품 리더, 개발자 및 과학자를 NVIDIA 기술자 및 제품 리더와 연결하여 Amazon ML/DL 워크로드, EC2 제품 및 AWS AI 서비스를 가속화합니다. 또한 Eliuth는 열정적인 산악 자전거 타는 사람, 스키 선수 및 포커 플레이어입니다.
