우리가 관찰한 일반적인 패턴은 프로덕션 목적의 ML 모델을 빌드하고 배포하는 것이 서로 다른 팀, 일반적으로 ML 알고리즘 팀과 장치 운영 팀에서 수행된다는 것입니다. ML 팀은 모델 교육 및 평가를 처리하고 디바이스 팀은 모델을 프로덕션 환경으로 마이그레이션하는 일을 담당합니다.

이러한 분리는 부분적으로는 하드웨어 플랫폼과 소프트웨어 스택 모두에 대해 훈련과 추론이 갈라졌다는 사실 때문입니다. 과거에는 훈련과 서비스 모두를 위해 GPU 서버에서 Caffe를 사용했습니다. 오늘날 사람들은 훈련을 위해 강력한 도구와 서버를 사용한 다음 고도로 최적화된 런타임과 다양한 장치에 모델을 배포합니다. 모델 복잡성 및 하드웨어 제한으로 인해 배포 문제가 자주 발생하며 ML 팀은 일반적으로 이러한 문제를 해결하기 위해 장치 운영 팀의 피드백에 의존해야 합니다.

결과적으로 기계 학습 엔지니어(MLE)는 종종 자체 모델의 배포 가능성에 대한 매우 기본적인 통찰력이 부족합니다. 오늘날의 모델 배포는 종종 다양한 시스템과 환경에 걸쳐 있는 여러 Bash/Python 스크립트로 구성된 사내 구축 파이프라인입니다. 또한 모델 변환, 양자화, 성능 조정 및 정확도 검증을 위한 여러 오픈 소스 라이브러리 또는 공급업체별 툴킷이 포함됩니다. 클라우드 네이티브 Python 환경에서 모델을 개발하는 것과 비교할 때 유쾌한 경험은 아닙니다.

도구의 복잡성 외에도 성능 해석 가능성의 부족도 또 다른 문제입니다. 다운스트림 도구 체인의 보고서를 프로파일링하려면 종종 다음 TensorRT 예와 같이 이해하고 실행 가능한 모델 통찰력으로 변환하기 위해 도메인 지식이 필요합니다. 긴 모델 변환 파이프라인과 함께 ML 개발자가 자체 모델의 실제 성능 병목 현상을 식별하고 올바른 변경을 수행하기가 어렵습니다.

이러한 단점에도 불구하고 모델 설계 및 배포의 분리는 일반적으로 완전히 다른 기술 세트를 필요로 하기 때문에 여전히 업계의 표준입니다. "ML 전문가나 장치 전문가는 고사하고 이미 ML 전문가나 장치 전문가를 고용하는 것은 어렵습니다." 고객으로부터 계속해서 듣는 말입니다. 하지만 현재 ML 워크플로를 계속 용인해야 한다는 의미는 아닙니다.

Software 1.0에서는 한 엔지니어가 프로그램을 작성하고 다른 엔지니어가 컴파일한다고 상상하기 어렵습니다. 프로그래머는 어셈블리 및 연결과 같은 기본 단계에 대한 지식이 거의 또는 전혀 없는 상태에서 코드를 수정할 수 있는 의미 있는 통찰력을 얻을 수 있는 상태에서 코드를 직접 컴파일할 수 있습니다. 이러한 통찰력이 없으면 디버깅 프로세스는 서로의 언어를 사용하지 않는 두 엔지니어 사이에서 끝없는 앞뒤 이동이 될 수 있습니다.

지금까지 ML 모델의 배포를 지연시키는 가장 일반적인 문제는 다음과 같습니다.

1. 참을 수 없는 대기 시간/처리량
2. 지원되지 않는 연산자
3. 정확도 불일치

모델 배포 및 진단을 위한 간단하고 이해하기 쉬운 워크플로가 솔루션입니다. ML 엔지니어가 스스로 사용하고 이해할 수 있는 인터페이스는 생산성을 크게 향상시킵니다.

매우 강력한 ML 컴파일러를 구축하는 것은 솔루션의 일부일 뿐입니다. Software 2.0과 Software 1.0 사이에는 몇 가지 근본적인 차이점이 있기 때문 입니다 . 둘째, ML 모델은 기능을 보존하지 않는 연산자 교체를 허용하고 여전히 유사한 정확도를 유지할 수 있으므로 ML 개발자에게 더 많은 사용자 지정 유연성을 제공합니다. 하지만 자세한 내용은 다루지 않겠습니다. 배포를 위한 모델 사용자 지정에 대해 이야기하는 별도의 블로그가 있을 수 있기 때문입니다.

OmniML 에서는 하드웨어와 ML 도구 체인을 연구하는 번거로움 없이 엔지니어가 ML 모델을 배포하고 프로파일링할 수 있는 내부 도구를 구축하는 것으로 시작했습니다. 우리는 곧 그러한 도구의 성능 향상을 깨달았습니다. 또한 정보가 풍부한 이 통합 인터페이스를 통해 인간과 알고리즘 모두 훌륭한 모델 최적화 기회를 열 수 있습니다. 따라서 이러한 기능은 이제 OmniML의 제품인 Omnimizer 및 Omnimizer Enterprise 에서 공식적으로 사용할 수 있습니다 .

Omnimizer — 통합 모델 최적화 및 배포 플랫폼

Omnimizer 는 주로 PyTorch 모델을 설계하고 교육하는 ML 엔지니어를 위해 설계되었습니다. 설계 결함을 식별하고 생산 시간을 단축하는 데 도움이 됩니다.

Omnimizer는 PyTorch 네이티브 및 클라우드 네이티브 인터페이스를 제공하여 대상 하드웨어에서 모델을 빠르게 테스트합니다. 사용자는 높은 수준의 배포 구성을 지정한 다음 OmniML 호스팅 장치 클라우드에 요청을 보내기만 하면 됩니다. 전체 대기 시간, 계층별 대기 시간 및 배포 오류(있는 경우)를 포함한 주요 배포 정보는 비 하드웨어 전문가가 이해할 수 있는 가장 간단한 방법으로 다시 보고됩니다.

Omnimizer를 사용하면 기기의 정확도를 원본 모델과 쉽게 비교할 수 있습니다. 모델과 데이터를 다른 장치로 전송하고, 다른 OS 및 도구 체인에 익숙해지고, 체계적이지 않고 버그가 많은 스크립트를 유지 관리하는 번거로움을 제거합니다. 다음 예에서 사용자는 PyTorch와 유사한 인터페이스에서 모델 출력을 얻을 수 있으며 실제 추론은 서버급 GPU 또는 스마트폰과 같은 원격 장치에서 발생합니다.

Omnimizer는 소프트웨어 라이브러리일 뿐만 아니라 성능 세부 정보를 탐색하고 모델 정보를 공유하며 배포 환경을 재현할 수 있는 사용자 친화적인 인터페이스를 제공하는 MLOps 플랫폼입니다. 사용자는 배포 단계를 보고, 벤치마크된 대기 시간을 얻고, 하드웨어에서 모델을 더 잘 이해할 수 있습니다.

Omnimizer Enterprise — AI 하드웨어의 잠재력을 최대한 발휘

모델 배포 및 최적화를 지원하는 커뮤니티 버전과 비교할 때 엔터프라이즈 버전은 NAS(Neural Architecture Search)에 대한 수년간의 연구를 기반으로 자동화된 모델 최적화 와 엔터프라이즈 요구에 대한 광범위한 사용자 정의를 제공합니다.

NAS는 항상 검색 공간 및 프록시 작업 설계에 대한 깊은 전문 지식이 필요한 비용이 많이 드는 프로세스로 간주되었습니다. Omnimizer를 사용하면 모든 사용자가 NAS를 적용하여 대상 하드웨어에 맞게 모델을 사용자 지정할 수 있습니다. 이 프로세스에는 단 몇 줄의 코드 변경, 낮은 교육 비용이 필요하며 가장 중요한 것은 모델 설계 및 하드웨어 성능의 전문가가 될 필요가 없다는 것입니다.

Omnimizer는 오픈 소스 리포지토리와 쉽게 통합할 수 있으며 수동 최적화가 거의 없이 기성품 모델을 가속화할 수 있습니다. 지금까지 OmniML과 그 고객은 NVIDIA 및 Qualcomm 플랫폼에서 1.2~6.8배의 속도 향상을 시연했습니다. 이러한 리포지토리는 기업 사용자에게 예시로 공개됩니다.

• YOLO-X (객체 감지)
• EfficientDet (객체 감지)
• YOLO-P (자율주행을 위한 멀티태스킹 모델)
• DDRNet (시맨틱 분할)
• ResNet (이미지 분류)
• DD3D (3D 물체 감지)
• RAFT (옵티컬 플로우)
• DistilBERT (기계 번역)

옴니마이저를 사용해 보세요!

Omnimizer 베타가 출시되었습니다. 지금 OmniML 웹사이트 에 가입하고 워크플로 최적화를 시작하세요!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.