1. 비정형 데이터에 대한 제한 없음

머신 러닝의 현재 패러다임에서 성능과 능력은 컴퓨팅과 함께 확장되며, 컴퓨팅은 실제로 데이터 세트 크기와 모델 크기의 프록시입니다( Scaling Laws for Neural Language Models , Kaplan et. al.). 지난 몇 년 동안 이는 머신 러닝과 데이터 인프라가 구축되는 방식에 광범위한 변화를 가져왔습니다. 즉, 스토리지와 컴퓨팅의 분리, 비정형 데이터로 채워진 대규모 클라우드 네이티브 데이터 레이크의 구축, 행렬 곱셈을 매우 빠르게 수행할 수 있는 특수 하드웨어가 있습니다.

학습 데이터 세트 또는 데이터 세트의 개별 샤드가 시스템 메모리 및/또는 로컬 스토리지에서 사용 가능한 공간보다 더 많은 공간을 필요로 하는 경우 스토리지를 컴퓨팅에서 분리하는 것의 중요성이 극명하게 드러납니다. MinIO Object Store에 있는 데이터에서 학습하는 경우 학습 데이터 크기에 제한이 없습니다. MinIO가 단순성과 I/O 처리량에 중점을 두기 때문에 네트워크가 학습 속도와 GPU 활용에 대한 유일한 제한 요소가 됩니다.

MinIO는 모든 객체 저장소의 최상의 성능을 제공할 뿐만 아니라 모든 최신 머신 러닝 프레임워크와 호환됩니다. MinIO 객체 저장소는 또한 100% S3 API와 호환되므로 TorchData와 같은 친숙한 데이터 세트 유틸리티를 사용하여 온프레미스 또는 온디바이스 객체 저장소에 대해 ML 워크로드를 수행할 수 있습니다. S3 데이터파이프 . 소비 애플리케이션에 파일 시스템과 같은 기능이 필요한 경우 MinIO를 다음과 같은 개체 저장소 파일 인터페이스와 함께 사용할 수도 있습니다. 마운트포인트 S3 또는 S3FS 향후 블로그 게시물에서는 일부 공통 PyTorch 및 FairSeq 인터페이스(각각 Dataset 및 Task)의 사용자 정의 구현에서 MinIO Python SDK를 사용하여 모델 학습을 위한 '무제한' 학습 데이터와 높은 GPU 활용을 활성화할 것입니다.

성능과 최신 ML 스택과의 호환성을 넘어, 객체 저장소의 설계 선택, 즉 (1) 플랫 네임스페이스, (2) 전체 객체(및 메타데이터)를 가장 낮은 논리적 엔터티로 캡슐화, (3) 간단한 HTTP 동사 API는 객체 저장소가 방대한 비정형 데이터 레이크의 사실상 표준이 되는 데 기여했습니다. 머신 러닝의 최근 역사를 살펴보면 학습 데이터(그리고 어떤 의미에서는 모델 아키텍처 자체)가 덜 구조화되고 더 일반화되었음을 알 수 있습니다. 예전에는 모델이 주로 표 형식 데이터에서 학습되었습니다. 오늘날에는 일반 텍스트 단락에서 몇 시간 분량의 비디오에 이르기까지 훨씬 더 광범위한 범위가 있습니다. 모델 아키텍처와 ML 애플리케이션이 발전함에 따라 객체 저장소의 무상태, 스키마 없음, 결과적으로 확장 가능한 특성이 더욱 중요해지고 있습니다.

2. 모델 및 데이터세트를 위한 풍부한 메타데이터

MinIO Object Store의 디자인 선택으로 인해 모든 객체는 성능을 희생하거나 전용 메타데이터 서버를 사용할 필요 없이 풍부하고 스키마가 없는 메타데이터를 포함할 수 있습니다. 객체에 어떤 종류의 메타데이터를 추가하고 싶은지에 관해서는 상상력이 유일한 한계입니다. 그러나 ML 관련 객체에 특히 유용할 수 있는 몇 가지 아이디어는 다음과 같습니다.

모델 체크포인트 : 손실 함수 값, 학습에 걸린 시간, 학습에 사용된 데이터 세트.

데이터 세트의 경우: 쌍으로 구성된 인덱스 파일 이름(해당되는 경우), 데이터 세트 범주(학습, 검증, 테스트), 데이터 세트 형식에 대한 정보입니다.

이와 같은 매우 설명적인 메타데이터는 수십억 개의 개체에 걸쳐 이 메타데이터를 효율적으로 인덱싱하고 쿼리하는 기능과 결합하면 특히 강력할 수 있습니다. MinIO 엔터프라이즈 카탈로그 제공합니다. 예를 들어, "테스트됨"으로 태그된 모델 체크포인트나 특정 데이터 세트에서 훈련된 체크포인트를 쿼리할 수 있습니다.

3. 모델 및 데이터 세트는 사용 가능하고 감사 가능하며 버전 관리가 가능합니다.

머신 러닝 모델과 해당 데이터 세트가 점점 더 중요한 자산이 되면서, 이러한 자산을 내결함성, 감사 및 버전 관리가 가능한 방식으로 저장하고 관리하는 것이 그만큼 중요해졌습니다.

데이터 세트와 이를 학습하는 모델은 시간, 엔지니어링 노력, 그리고 돈의 힘든 노력으로 얻은 귀중한 자산입니다. 따라서 애플리케이션의 액세스를 방해하지 않는 방식으로 보호되어야 합니다. MinIO의 bitrot 검사 및 erasure 코딩과 같은 인라인 작업과 다중 사이트, 액티브-액티브 복제와 같은 기능은 이러한 객체의 규모에 따른 복원력을 보장합니다.

특히 생성 AI의 경우, 제공되는 특정 모델을 학습하는 데 사용된 데이터 세트의 버전을 아는 것은 환각 및 기타 모델 오동작을 디버깅할 때 유용합니다. 모델 체크포인트가 적절하게 버전 관리되면 이전에 제공된 체크포인트 버전으로의 빠른 롤백을 신뢰하기가 더 쉬워집니다. MinIO Object Store를 사용하면 바로 이러한 이점을 개체에 사용할 수 있습니다.

4. 자체 서비스 인프라

MinIO 객체 저장소는 기본적으로 귀하 또는 귀하의 조직이 제어하는 객체 저장소입니다. 사용 사례가 프로토타입, 보안, 규제 또는 경제적 목적 , 제어는 공통적인 스레드입니다. 따라서 훈련된 모델 체크포인트가 객체 저장소에 있는 경우 추론 또는 소비를 위한 모델 제공 작업에 대한 제어력이 더 커집니다.

이전 게시물에서 , 우리는 모델 파일을 객체 저장소에 저장하는 것의 이점과 PyTorch의 TorchServe 추론 프레임워크로 직접 제공하는 방법을 살펴보았습니다. 그러나 이는 완전히 모델과 프레임워크에 독립적인 전략입니다.

하지만 이게 왜 중요할까요? 타사 모델 저장소의 네트워크 지연이나 중단으로 인해 추론을 위해 모델이 제공되기가 느리거나 전혀 사용할 수 없게 될 수 있습니다. 게다가 추론 서버가 확장되고 모델 체크포인트를 정기적으로 가져와야 하는 프로덕션 환경에서는 이 문제가 더 심해질 수 있습니다. 가장 안전하고/또는 가장 중요한 상황에서는 가능한 한 인터넷을 통한 타사 종속성을 피하는 것이 가장 좋습니다. MinIO를 프라이빗 또는 하이브리드 클라우드 객체 저장소로 사용하면 이러한 문제를 완전히 피할 수 있습니다.

마무리 생각

이 네 가지 이유는 결코 완전한 목록이 아닙니다. 개발자와 조직은 개발 용이성부터 초경량 풋프린트까지 다양한 이유로 AI 워크로드에 MinIO Object Storage를 사용합니다.

이 게시물의 시작 부분에서 우리는 AI를 위한 고성능 객체 저장소 채택의 원동력에 대해 다루었습니다. 확장 법칙이 유지되든 아니든, 조직과 그들의 AI 워크로드는 항상 사용 가능한 최고의 I/O 처리량 성능의 혜택을 누릴 것이라는 것은 확실합니다. 게다가, 우리는 개발자들이 사용하기 어려운 API와 '그냥 작동하지 않는 ' 소프트웨어를 결코 요구하지 않을 것이라고 확신할 수 있습니다. 이러한 가정이 유지되는 미래에서는 고성능 객체 저장소가 바로 길입니다.

이 글을 읽고 있는 모든 아키텍트와 엔지니어링 의사결정권자에게, 여기에 언급된 모범 사례 중 다수는 자동화하여 AI/ML 워크플로를 더 간단하고 확장 가능하게 만드는 방식으로 개체 저장소를 활용할 수 있습니다. 이는 모든 최신 MLOps 도구 세트를 사용하여 수행할 수 있습니다. AI/ML SME Keith Pijanowski는 이러한 도구 중 다수를 살펴보았습니다. MLOps 도구에 대한 자세한 내용은 블로그 사이트에서 Kubeflow, MLflow 및 MLRun을 검색하세요. 그러나 이러한 MLOps 도구가 조직에 적합하지 않고 신속하게 시작해야 하는 경우 이 게시물에 나와 있는 기술은 MinIO로 AI/ML 워크플로를 관리하기 시작하는 가장 좋은 방법입니다.

개발자(또는 궁금해하는 사람들 🙂)를 위해 향후 블로그 게시물에서는 '제한 없음'의 학습 데이터와 적절한 GPU 활용을 목표로 객체 저장소를 활용하는 ML 프레임워크를 적용하는 과정을 처음부터 끝까지 살펴보겠습니다.

읽어주셔서 감사합니다. 유익했기를 바랍니다! 언제나 그렇듯이, 질문이 있으면 저희에 가입하세요. 슬랙 채널 또는 다음 주소로 메모를 남겨주세요. 안녕하세요@min.io .