Azure의 AI 워크로드를 위한 애플리케이션 플랫폼
효율성, 운영 보안 및 안정성을 최대화할 수 있도록 AI 워크로드가 배포되는 애플리케이션 호스팅 플랫폼을 신중하게 고려해야 합니다.
이 디자인 영역에서는 AI 워크로드와 관련이 있을 수 있는 여러 유형의 애플리케이션을 다룹니다.
- EDA(예비 데이터 분석)
- 모델 학습 및 미세 조정
- 추론
이 문서에서는 비즈니스 요구 사항을 충족하기 위해 이러한 각 기능에 가장 적합한 플랫폼을 선택하기 위한 지침을 제공합니다. 이러한 모든 함수에 적용할 수 있는 일반적인 권장 사항도 있습니다.
권장 사항
다음은 이 문서에 제공된 권장 사항의 요약입니다.
추천 | 설명 |
---|---|
도구를 다시 사용합니다. | 먼저 AI 워크로드에 다시 사용할 수 있는지 여부를 이해하기 위해 이미 사용하는 도구를 평가합니다. 필요한 기능을 지원하고 안정성, 보안, 비용 및 성능에 대한 요구 사항을 충족할 수 있는 경우 새 도구를 도입하는 것은 비용과 노력의 가치가 없을 수 있습니다. |
데이터 및 배포하려는 지역에 대한 규정 준수 요구 사항을 고려합니다. | 규정 준수 요구 사항을 충족하기 위해 배포하는 지역을 제한하거나 워크로드의 일부를 서로 격리해야 할 수 있습니다. 이 정보를 사용하여 디자인 단계에 들어가면 나중에 다시 디자인할 필요가 없도록 보호할 수 있습니다. |
건물을 최소화합니다. | 패치 및 기타 유지 관리와 같이 사용자 고유의 솔루션을 빌드하는 데 발생하는 운영 부담을 최소화하려면 PaaS(Platform as a Service) 또는 SaaS(Software as a Service) 솔루션을 고려합니다. 새 기술에 필요한 2일차 부담을 최소화하면 채택이 간소화됩니다. 많은 AI 함수가 복잡하므로 사용자 고유의 플랫폼을 빌드하지 않는 것이 좋습니다. |
할당량 및 한도를 이해합니다. | PaaS 또는 SaaS 솔루션을 사용하도록 디자인할 때 적용되는 할당량 또는 제한을 이해합니다. 높은 트래픽 수요를 충족하기 위해 스케일 아웃하는 기능은 할당량 또는 제한의 영향을 받을 수 있으므로 해당 위험을 최소화하기 위해 디자인을 조정해야 할 수 있습니다. |
동일한 지역에 배포합니다. | 대기 시간을 줄이고 디자인을 간소화하기 위해 동일한 지역에 모든 관련 리소스를 배포해 봅니다. |
안전한 배포를 연습합니다. | 일반적으로 AI 워크로드에 대한 API는 사용자 환경의 다른 API와 동일하게 처리해야 합니다. 모든 API는 게이트웨이 뒤에 배치되어야 하며 모든 코드는 다른 모든 코드 자산과 동일한 안전한 배포 사례 로 처리해야 합니다. |
실험을 통해 성능 벤치마크를 설정합니다. | 모든 AI 워크로드는 다르며 필요한 컴퓨팅의 양은 사용 사례에 따라 달라집니다. 철저한 벤치마크 테스트를 수행하여 워크로드에 가장 적합한 컴퓨팅의 양과 유형을 결정합니다. 이 가이드는 플랫폼을 선택하는 데 도움이 되지만 벤치마크 테스트 후에 워크로드에 적합한 SKU만 알 수 있습니다. |
EDA 플랫폼에 대한 고려 사항
EDA는 데이터 과학자가 모델링 또는 통계 분석을 수행하기 전에 수행하는 일반적인 예비 함수입니다. 따라서 개발 단계로 간주될 수 있습니다. 즉, 안정성 및 성능에 대한 목표가 프로덕션 리소스에 대한 목표보다 훨씬 낮을 수 있으며 생산성 유지가 더 중요한 요소입니다.
이 섹션에서는 EDA 플랫폼 솔루션을 선택할 때 고려해야 할 기능에 대한 지침을 제공합니다.
기능 요구 사항
EDA 플랫폼을 평가할 때 다음 질문을 고려합니다.
플랫폼이 일시적인 사용을 지원하나요?
플랫폼은 일시적인 작업 영역 및 컴퓨팅을 지원해야 합니다. 즉, 필요한 리소스를 사용하지 않을 때 중지할 수 있어야 합니다. 이 기능은 비용을 제어하는 데 도움이 됩니다. EDA 작업은 일반적으로 대화형이므로 사용자는 VM을 시작하고 작업을 실행할 때 중지할 수 있어야 합니다.
플랫폼이 컴퓨팅 선택성을 지원하나요?
플랫폼은 필요에 따라 GPU에 대한 주문형 액세스를 사용하도록 설정하고 플랫폼 크기를 조정하는 데 도움이 되는 다양한 컴퓨팅 옵션을 제공해야 합니다.
플랫폼이 MLflow를 지원하나요?
EDA 플랫폼을 사용하면 실험을 추적하기 위해 MLflow와 통합할 수 있는 기술을 선택할 수 있어야 합니다. MLflow는 다음과 같은 이점을 제공하므로 모델 개발, 배포 및 관리 프로토콜로 사용하는 것이 좋습니다.
- 실험 추적. MLflow를 사용하면 매개 변수, 메트릭 및 아티팩트 기록을 통해 실험을 추적할 수 있습니다. 이 기능은 다양한 데이터 전처리 단계와 기능 엔지니어링 기술 및 모델 성능에 미치는 영향을 추적할 수 있도록 EDA 중에 필수적입니다.
- 재현성. MLflow는 실험의 모든 세부 정보를 기록하기 때문에 결과를 재현할 수 있도록 지원하며, 이는 결과의 유효성을 검사하는 데 중요합니다.
- 데이터 및 모델 버전 관리. MLflow는 데이터 세트 및 모델의 버전 관리를 지원하므로 다양한 버전의 데이터 변환 및 테스트된 모델을 보다 쉽게 관리할 수 있습니다.
- 공동 작업. MLflow는 데이터 과학자가 실험과 결과를 공유할 수 있는 중앙 집중식 플랫폼을 제공하여 공동 작업 및 지식 공유를 용이하게 합니다.
비기능적 요구 사항
다음 질문도 고려합니다.
플랫폼이 비용을 제어하는 데 어떻게 도움이 될 수 있나요?
플랫폼은 데이터 과학자가 일정 요구 사항에 따라 작업을 수행할 수 있도록 해야 하지만 비용 기대치를 충족할 수 있도록 적절한 크기여야 합니다.
플랫폼에 대해 어떤 보안 요구 사항을 따라야 합니까?
EDA 단계에서 사용되는 데이터는 프로덕션 데이터일 수 있으며, 프로덕션 사례를 따라 해당 데이터를 보호하고 플랫폼을 모니터링해야 합니다. 이를 위해 플랫폼은 다음을 포함하여 필요한 모든 보안 제어를 지원해야 합니다.
- 액세스 및 권한 부여.
- 미사용 및 전송 중 암호화
- 지역 데이터 보호 요구 사항.
- 로깅 및 감사 기능을 비롯한 강력한 모니터링 및 경고 기능
- 컨테이너 이미지, 데이터 및 코드 자산에 대한 중앙 집중식 리포지토리에 대한 프라이빗 네트워킹 액세스
도구
팀 수준 파일 공유가 있는 Azure Machine Learning 컴퓨팅 인스턴스를 EDA 플랫폼으로 사용합니다. 한 가지 예외는 팀 또는 조직이 Databricks의 GPU 지원 컴퓨팅 클러스터와 같은 적절한 호스팅 플랫폼을 이미 사용하고 있는 경우입니다. 이 경우 해당 플랫폼에 유지하는 것이 더 적절할 수 있습니다.
참고 항목
필요한 경우가 아니면 전체 EDA 플랫폼을 빌드하지 마세요. GPU 최적화 컴퓨팅은 비용이 많이 들며 사용 사례에 필요하지 않은 경우 적절하지 않습니다.
모델 학습 및 미세 조정 플랫폼에 대한 고려 사항
모델 학습 및 미세 조정으로 이동하면 해당 활동에 필요한 계산 집약적 작업에 대해 고성능 GPU 최적화 컴퓨팅이 필요할 수 있습니다. 이 작업의 대부분은 백그라운드에서 발생하기 때문에 일반적으로 안정성은 성능만큼 중요하지 않습니다. 높은 안정성이 요구 사항인 경우 가용성 영역 또는 지역에 워크로드를 분산해야 하는지 여부를 평가합니다. 높은 안정성은 모델 새로 고침이 자주 업데이트될 때 더욱 중요해지며, 더 엄격한 일정에 따라 학습을 완료해야 합니다. RTO는 선택한 안정성 디자인을 결정해야 합니다.
이 섹션의 지침은 모델 학습 및 미세 조정 모두에 적용됩니다. 이러한 함수에 대해 별도의 플랫폼을 사용하도록 강제하지 않는 한 단일 플랫폼을 사용해야 합니다.
기능 요구 사항
모델 학습 및 미세 조정에 대한 플랫폼을 평가할 때 다음 질문을 고려합니다.
플랫폼이 일시적인 사용을 지원하나요?
EDA 활동과 마찬가지로 모델 학습 및 미세 조정은 일반적으로 풀타임으로 실행되지 않으므로 비용을 제어하는 데 사용되지 않을 때 중지할 수 있는 플랫폼을 사용해야 합니다. 그러나 EDA와 달리 모델 학습은 일반적으로 일괄 처리 프로세스이므로 일괄 처리가 실행될 때만 컴퓨팅이 필요하며 다음 실행까지 종료할 수 있습니다.
플랫폼이 오케스트레이션을 제공하나요?
모델 학습 및 미세 조정을 위해 컴퓨팅을 관리하는 데 필요한 복잡성 때문에 오케스트레이터를 사용하는 것이 좋습니다.
사용자 환경의 기존 기술이 솔루션의 일부가 될 수 있나요?
기존 데이터 플랫폼에 Azure Databricks와 같은 기계 학습 기능이 있는 경우 데이터 변환 및 기능 엔지니어링, 학습, 미세 조정 및 Machine Learning의 다른 단계와 같은 특정 단계에 사용할 수 있습니다. 기술을 결합하면 이상적으로 적합하지 않을 수 있는 함수에 대해 데이터 플랫폼을 사용하는 데 관련된 비용과 복잡성을 최소화할 수 있습니다.
비기능적 요구 사항
이 질문도 고려합니다.
비용과 성능 간의 절충 가능한 절충은 무엇인가요?
고성능 GPU 최적화 컴퓨팅 요구 사항을 고려하여 학습 및 미세 조정을 광범위하게 테스트하고 벤치마킹하여 성능과 비용 간의 균형을 맞추는 이상적인 SKU를 결정해야 합니다.
도구
일괄 처리 컴퓨팅을 지원하는 오케스트레이션 기능을 제공하므로 모델 학습 및 미세 조정 플랫폼에 Azure Machine Learning을 사용하는 것이 좋습니다. 평가할 두 가지 컴퓨팅 옵션이 있습니다.
- 서버리스 컴퓨팅 은 시끄러운 인접 효과를 허용할 수 있는 짧고 드물게 실행되는 데 적합합니다. 표준 가격 책정 또는 스폿 가격을 선택할 수 있습니다. 스폿 가격은 매우 중단 가능한 학습에만 권장됩니다. 전임 작업에는 서버리스 컴퓨팅을 사용하지 마세요. 비용은 빠르게 확대될 수 있습니다.
- 컴퓨팅 클러스터를 사용하면 사용 가능한 하드웨어를 크게 제어할 수 있으며 병렬 또는 분산 학습을 위해 조정됩니다.
참고 항목
기본 모델의 경우 모델 호스팅 플랫폼을 선택하면 미세 조정 옵션이 제한될 수 있습니다. 예를 들어 모델 호스팅에 Azure OpenAI 서비스를 사용하면 기본 제공 Azure OpenAI 미세 조정 기능으로 미세 조정 옵션이 제한됩니다.
모델 호스팅 및 추론 플랫폼에 대한 고려 사항
모델 호스팅 및 추론 함수는 AI 워크로드의 서비스 계층을 구성합니다. 이러한 함수는 사용하는 소프트웨어와 관련된 엔드포인트를 사용하여 수행됩니다. NVIDIA Triton, TorchServe 및 TensorFlow Serving와 같은 모델 서비스 소프트웨어 솔루션은 기본적으로 API를 사용하여 모델을 앞세우고 솔루션과 관련된 기능을 추가하는 Python SDK입니다. 선택한 소프트웨어에 따라 호스팅 플랫폼을 선택하거나 선택한 호스팅 플랫폼에 따라 소프트웨어를 선택할 수 있습니다.
Azure OpenAI에서 사용할 수 있는 큰 언어 모델과 같이 미리 패키지된 모델에서 SaaS 또는 PaaS 솔루션을 사용하는 경우 서비스 소프트웨어를 선택할 기회가 거의 없거나 전혀 없습니다. 대신 사용하는 서비스는 API를 제공합니다. 이렇게 하면 모델 배포를 만드는 프로세스의 유연성이 감소하여 장점과 단점을 제공할 수 있습니다. 예를 들어 워크로드의 개발 프로세스를 간소화할 수 있습니다. 반면에 애플리케이션에서 모델을 호출하고 상호 작용하는 방법에 대한 유연성이 줄어듭니다.
기본적으로 서비스 계층에 대한 API는 마이크로 서비스이므로 환경의 다른 마이크로 서비스에 대해 따르는 이러한 API에 대해 동일한 사례를 따라야 합니다. 컨테이너화되고, 다른 서비스에서 대량 처리되며, 다른 서비스 및 API와 독립적인 고유한 수명 주기가 있어야 합니다. 그러나 계층 API를 제공하는 경우 일반적으로 기존 API보다 훨씬 더 많은 GPU 기반 컴퓨팅 성능과 더 큰 컨테이너 이미지가 필요합니다.
이 섹션에서는 모델 호스팅 및 추론 플랫폼을 선택할 때 고려해야 할 기능에 대한 지침을 제공합니다.
기능 요구 사항
모델 호스팅 및 추론에 대한 플랫폼을 평가할 때 다음 질문을 고려합니다.
워크로드에 일괄 처리 또는 온라인 추론이 필요한가요?
추론 엔드포인트는 일괄 처리 또는 온라인 추론 프로세스에 사용되며 추론 메서드는 올바른 호스팅 플랫폼을 결정하는 데 도움이 됩니다. 일괄 처리 추론은 일시적 사용을 지원하고 컴퓨팅을 사용하지 않을 때 종료할 수 있도록 하는 플랫폼에서 호스트되는 것이 가장 좋습니다. 온라인 추론은 탄력적 컴퓨팅 사용률을 지원하는 플랫폼에서 가장 적합하며, 지정된 시간에 부하에 따라 자동으로 크기가 조정됩니다.
플랫폼이 추적 기능을 지원하나요?
추적성은 워크로드에 사용되는 모델의 무결성을 유지하는 데 중요합니다. 현재 버전, 배포한 사용자, 배포된 시기 및 모델의 데이터 계보와 같은 모델에 대한 정보를 알고 있는 것이 중요합니다.
컨테이너 레지스트리의 이미지에 의미 있는 태그를 적용하여 모델 호스팅 서비스가 팀에서 쉽게 식별할 수 있는 특정 버전을 가져오도록 합니다. 이 방법은 오래되었거나 잘못된 모델이 프로덕션에서 사용되는 위험을 줄여 데이터 거버넌스에 도움이 됩니다.
호스팅 플랫폼이 중앙 집중식 리소스가 되나요?
많은 조직에서 자신의 워크로드에 대해 서로 다른 팀에서 사용하는 중앙 집중식 모델 호스팅 플랫폼을 사용합니다. 호스팅 플랫폼이 중앙 집중식인 경우 차지백에 대한 지원이 필요한지 여부를 고려해야 합니다. 이 기능을 사용하면 팀 및 워크로드별로 플랫폼 사용률을 추적할 수 있습니다.
비기능적 요구 사항
다음 질문도 고려합니다.
플랫폼의 안정성 요구 사항은 무엇인가요?
서비스 계층 API는 프로덕션 리소스이므로 중요도 등급과 일치하는 다른 워크로드 흐름에 적용하는 것과 동일한 안정성 요구 사항을 적용해야 합니다. 중요도에 고가용성이 필요한 경우 호스팅 플랫폼은 가용성 영역 또는 다중Region 디자인을 지원해야 합니다.
플랫폼에 필요한 네트워킹 컨트롤은 무엇인가요?
플랫폼에 대한 보호를 제공하기 위해 프라이빗 네트워킹 또는 송신 방화벽이 필요한지 여부를 결정합니다.
플랫폼의 ID 및 액세스 보안 요구 사항은 무엇인가요?
엔드포인트에 필요한 ID 및 액세스 제어를 결정합니다. 기본 RBAC(역할 기반 액세스 제어) 또는 ID 및 액세스 플랫폼에 대한 기본 제공 지원(예: Microsoft Entra ID)이 필요한지 고려합니다.
플랫폼에서 지원하는 모니터링 기능은 무엇인가요?
엔드포인트에 필요한 모니터링 기능을 결정합니다. 플랫폼에 따라 로그 및 메트릭에 대한 액세스가 제한되어 활동을 감사하거나 오작동을 감지하는 기능이 제한될 수 있습니다.
플랫폼의 성능 요구 사항은 무엇인가요?
유추 대기 시간은 일반적인 문제이며 플랫폼별로 성능 프로필이 다릅니다. 유틸리티 모델을 사용하는 서버리스 및 PaaS 서비스는 시끄러운 인접 문제의 영향을 받을 수 있으며 처리량 보장이 없는 경우가 많습니다. 반면, 동일한 플랫폼은 사전 구매 모델에서 보장된 처리량을 제공하는 자체 호스팅 옵션을 제공할 수 있습니다. 더 예측 가능한 대기 시간 동작을 위해 Kubernetes에서 자체 호스팅을 고려할 수도 있습니다.
Azure OpenAI와 같이 성능에 영향을 줄 수 있는 서비스 제한 및 할당량에 유의하세요. 종종 이러한 할당량 및 한도는 용량 요구를 충족하도록 적극적으로 설정되므로 플랫폼 선택이 필요한 성능을 제공하지 않는 경우 인스턴스 간에 컴퓨팅 수요를 분산하기 위한 전략을 채택해야 할 수 있습니다.
고급 아키텍처는 여러 배포를 결합하여 워크로드의 대량에 대한 고정 처리량을 달성하고 보다 유연한 컴퓨팅을 위한 버스팅 기능을 달성할 수 있습니다.
도구
일괄 유추
Databricks와 같은 모델 호스팅을 지원하는 플랫폼에 있는 데이터에 대해 추론을 수행하는 경우 추론에 해당 플랫폼을 사용하는 것이 좋습니다. 유추 컴퓨팅을 데이터 플랫폼에서 수행하는 다른 함수와 격리해야 합니다.
기본 모델에는 Azure OpenAI Batch API를 사용하는 것이 좋습니다.
기본이 아닌 모델의 경우 다음 권장 사항을 고려합니다.
다음 시나리오에 Azure Machine Learning 일괄 처리 엔드포인트를 사용하는 것이 좋습니다.
여러 파일에 분산되어 있고 짧은 대기 시간이 필요하지 않은 큰 데이터 세트에서 추론을 수행해야 합니다.
대규모 데이터 세트에 대해 장기 실행 일괄 처리 작업을 수행해야 하며 병렬 처리를 활용할 수 있습니다.
일괄 처리를 위해 파이프라인 구성 요소를 배포해야 합니다.
분산 데이터 처리를 위해 Spark 작업을 실행해야 하는 경우 Azure Synapse Analytics, Databricks 또는 Machine Learning 서버리스 Spark 컴퓨팅을 사용하는 것이 좋습니다.
이러한 시나리오가 적용되지 않는 경우 Machine Learning 일괄 처리 엔드포인트를 사용하는 것이 좋습니다.
온라인 추론
플랫폼 PaaS 및 서버리스 솔루션을 첫 번째 단계로 평가합니다. 이러한 서비스는 일반적으로 디자인을 단순화하고 운영 부담을 최소화하기 때문에 채택 및 관리하기 가장 쉽습니다. 예를 들어 Azure OpenAI는 기본 모델에 적합합니다.
- Azure OpenAI 또는 다른 기본 모델 호스팅 솔루션을 사용하는 경우에도 Azure Machine Learning 서버리스 API를 사용하여 엔드포인트 액세스를 집계하는 것이 좋습니다.
PaaS 또는 서버리스 솔루션이 적합하지 않은 경우 관리형 컴퓨팅 클러스터를 사용하는 Machine Learning을 고려합니다. Machine Learning에서 관리하는 컴퓨팅은 A/B 테스트, 디버깅 및 강력한 감사에 대한 트래픽 분할 및 미러링을 지원합니다. 컴퓨팅은 서비스에서 관리되므로 모델을 자체 호스팅할 때 2일차 작업이 더 쉽습니다. 또한 관리형 컴퓨팅은 다양한 컴퓨팅 구성 및 크기 조정 기능을 제공합니다.
Machine Learning 또는 다른 컨테이너 기반 플랫폼에 연결된 AKS(Azure Kubernetes Service) 클러스터에서 모델을 자체 호스팅하도록 선택하는 경우 예측 가능한 성능을 달성하고 보안을 최적화하기 위해 노드 풀을 클러스터의 다른 API 또는 다른 워크로드와 격리해야 합니다. 비용을 절감하려면 AI 워크로드 함수 이외의 다른 작업에 GPU 기반 또는 GPU 최적화 컴퓨팅을 사용하지 마십시오. 대신 테스트를 통해 성능 기준을 설정하고 컴퓨팅 크기를 조정하여 과도하게 프로비저닝하지 않고 성능 요구 사항을 충족합니다.
Azure 데이터 과학 Virtual Machine과 같은 IaaS(Infrastructure as a Service) 솔루션을 사용하여 모델을 자체 호스팅할 수도 있습니다.
오케스트레이션 플랫폼에 대한 고려 사항
AI 워크로드 애플리케이션 플랫폼의 컨텍스트에서 오케스트레이션은 Machine Learning 및 Azure AI Studio의 프롬프트 흐름과 같은 도구를 나타냅니다. 이러한 도구는 많은 일반적인 워크플로 기능을 자동화하여 AI 애플리케이션의 전체 개발 주기를 간소화하도록 설계되었습니다.
비기능적 요구 사항
클라우드 자산의 다른 모든 프로덕션 워크로드와 마찬가지로 오케스트레이션 도구를 평가할 때 다음을 고려해야 합니다.
안정성, 보안 및 모니터링. 오케스트레이션 도구는 프로덕션 워크로드에 대한 안정성, 보안 및 모니터링 표준을 준수해야 합니다.
성능. 오케스트레이션 도구에는 GPU 최적화 또는 GPU 기반 컴퓨팅이 필요하지 않으며 범용 SKU를 고려합니다.
비용 최적화. 오케스트레이션 도구는 항상 사용되며, 탄력적 컴퓨팅 옵션을 고려하여 사용률을 최소화합니다.
도구
프롬프트 흐름과 같은 상용 솔루션을 선호합니다. LangChain 또는 의미 체계 커널과 같은 도구를 사용하여 사용자 지정 호스팅을 살펴보기 전에 해당 기능이 오케스트레이션 요구 사항과 일치하는지 확인합니다.
컴퓨팅 인스턴스를 사용하는 Machine Learning의 프롬프트 흐름 또는 자체 호스팅을 사용하는 AKS와 같은 솔루션에 대한 호스트 엔드포인트입니다.