AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

이 게시물의 축약 버전은 2024년 3월 19일 The New Stack에 게재되었습니다. 엔터프라이즈 인공 지능에는 차별적 모델과 생성적 모델이라는 두 가지 주요 모델 유형이 있습니다. 판별 모델은 데이터를 분류하거나 예측하는 데 사용되는 반면, 생성 모델은 새로운 데이터를 생성하는 데 사용됩니다. 제너레이티브 AI(Generative AI)가 최근 뉴스를 장악하고 있음에도 불구하고 조직은 여전히 두 가지 유형의 AI를 모두 추구하고 있습니다. 차별적 AI는 보다 효율적으로 운영하고 추가 수익원을 추구하려는 조직에게 여전히 중요한 이니셔티브로 남아 있습니다. 이러한 다양한 유형의 AI에는 공통점이 많지만 동시에 AI 데이터 인프라를 구축할 때 고려해야 할 중요한 차이점이 있습니다. 조직은 비즈니스 인텔리전스, 데이터 분석, 데이터 과학과 같은 워크로드를 스스로 관리하도록 방치하면서 AI 및 AI 전용 인프라를 구축해서는 안 됩니다. 비즈니스 인텔리전스, 데이터 분석, 데이터 과학, 차별적 AI, 생성적 AI 등 조직의 모든 요구 사항을 지원하는 완전한 데이터 인프라를 구축하는 것이 가능합니다. 다른 게시물에서는 비즈니스 인텔리전스, 데이터 분석, 데이터 과학 및 AI/ML의 요구 사항을 충족할 수 있는 최신 데이터레이크에 대한 참조 아키텍처를 제시했습니다. 최신 Datalake 참조 아키텍처를 검토하고 AI/ML 워크로드 지원을 위한 기능을 강조해 보겠습니다. 현대적인 데이터레이크 참조 아키텍처의 기반이 될 최신 데이터레이크를 정의하는 것부터 시작해 보겠습니다. 이 아키텍처는 "재활용"되지 않고 광범위하게 적용할 수 있는 엔지니어링 첫 번째 원칙을 반영합니다. Modern Datalake는 절반은 데이터 웨어하우스이고 절반은 데이터 레이크이며 모든 것에 객체 스토리지를 사용합니다. 개체 스토리지는 데이터 레이크에 저장되는 구조화되지 않은 데이터를 위한 것이므로 데이터 레이크에 개체 스토리지를 사용하는 것은 매우 합리적입니다. 그러나 데이터 웨어하우스에 개체 스토리지를 사용하는 것이 이상하게 들릴 수도 있지만 이러한 방식으로 구축된 데이터 웨어하우스는 차세대 데이터 웨어하우스를 나타냅니다. 이는 Netflix, Uber 및 Databricks가 작성한 OTF(Open Table Format Spec)를 통해 가능하며, 이를 통해 데이터 웨어하우스 내에서 객체 스토리지를 원활하게 사용할 수 있습니다. OTF는 Apache Iceberg, Apache Hudi 및 Delta Lake입니다. Netflix, Uber 및 Databricks가 각각 저작했습니다. 시장에 데이터 요구 사항을 처리할 수 있는 제품이 없었기 때문입니다. 기본적으로 이들이 서로 다른 방식으로 수행하는 작업은 개체 스토리지(MinIO) 위에 구축할 수 있는 데이터 웨어하우스를 정의하는 것입니다. 개체 스토리지는 다른 스토리지 솔루션이 제공할 수 없는 확장 가능한 용량과 고성능의 조합을 제공합니다. 이는 최신 사양이기 때문에 파티션 진화, 스키마 진화, 제로 복사 분기 등 기존 데이터 웨어하우스에는 없는 고급 기능을 갖추고 있습니다. 마지막으로 데이터 웨어하우스는 객체 스토리지로 구축되었으므로 이미지, 비디오 파일, 오디오 파일 및 문서와 같은 구조화되지 않은 데이터에 대해 동일한 객체 저장소를 사용할 수 있습니다. 구조화되지 않은 데이터는 일반적으로 업계에서 데이터 레이크라고 부르는 곳에 저장됩니다. 데이터 레이크와 데이터 웨어하우스 모두의 기반으로 객체 저장소를 사용하면 모든 데이터를 보관할 수 있는 솔루션이 탄생합니다. 정형 스토리지는 OTF 기반 데이터 웨어하우스에 상주하고, 비정형 스토리지는 데이터 레이크에 상주합니다. 동일한 MinIO 인스턴스를 두 가지 모두에 사용할 수 있습니다. MinIO에서는 OTF 기반 데이터 웨어하우스와 데이터 레이크의 조합을 Modern Datalake라고 부르며, 이를 모든 AI/ML 워크로드의 기반으로 봅니다. 데이터가 수집, 저장, 처리, 변환되는 곳입니다. 차별적인 AI(지도 학습, 비지도 학습, 강화 학습)를 사용하는 훈련 모델에는 데이터 웨어하우스에 있을 수 있는 구조화된 데이터를 처리할 수 있는 스토리지 솔루션이 필요한 경우가 많습니다. 반면, LLM(대형 언어 모델)을 교육하는 경우 Data Lake에서 원시 및 처리된 형식으로 구조화되지 않은 데이터 또는 문서를 관리해야 합니다. : 원천 최신 Datalake 참조 아키텍처 이 게시물은 다양한 AI/ML 워크로드를 지원하는 AI/ML용 최신 Datalake 참조 아키텍처 영역에 중점을 둡니다. 이러한 기능 영역은 아래에 나열되어 있습니다. 위에는 Modern Datalake의 시각적 설명이 나와 있습니다. 이러한 기능 영역을 찾을 수 있는 레이어가 강조 표시되었습니다. 차별적 AI 구조화되지 않은 데이터를 위한 스토리지 반구조화된 데이터용 스토리지 데이터 웨어하우스의 제로 카피 분기 생성 AI 벡터 데이터베이스를 사용하여 사용자 정의 코퍼스 구축 문서 파이프라인 구축 검색 증강 생성(RAG) 대규모 언어 모델 미세 조정 LLM 정확도 측정 기계 학습 작업 또한 이 게시물에서는 GPU의 현재 상태와 GPU가 AI 데이터 인프라에 어떤 영향을 미치는지 살펴봅니다. 또한 인프라를 구축하는 방법과 인프라를 구축하지 않는 방법을 보여주는 몇 가지 시나리오도 살펴보겠습니다. 마지막으로, 이 게시물에서는 자체 AI 데이터 인프라 구축에 대한 몇 가지 권장 사항을 제시합니다. GPU의 현재 상태 배고픈 GPU 문제 객체 스토리지 강화 두 조직의 이야기 AI 데이터 인프라 구축 계획 차별적 AI 판별 AI 모델에는 훈련을 위해 모든 유형의 데이터가 필요합니다. 이미지 분류 및 음성 인식 모델은 이미지 및 오디오 파일 형태의 비정형 데이터를 사용합니다. 반면, 사기 탐지 및 의료 진단 모델은 구조화된 데이터를 기반으로 예측을 수행합니다. 차별적 AI에 필요한 데이터를 저장하고 조작하기 위해 Modern Datalake 내에서 사용할 수 있는 옵션을 살펴보겠습니다. 구조화되지 않은 데이터를 위한 스토리지 구조화되지 않은 데이터는 Data Lake에 상주하며 모델 교육 및 테스트에 사용될 수 있습니다. 메모리에 들어갈 수 있는 훈련 세트는 훈련 이전(에포크 루프가 시작되기 전)에 로드될 수 있습니다. 그러나 훈련 세트가 크고 메모리에 맞지 않는 경우 훈련 전에 객체 목록을 로드하고 에포크 루프에서 각 배치를 처리하는 동안 실제 객체를 검색해야 합니다. 고속 네트워크 및 고속 디스크 드라이브를 사용하여 데이터 레이크를 구축하지 않으면 데이터 레이크에 부담을 줄 수 있습니다. 메모리에 들어갈 수 없는 데이터로 모델을 교육하는 경우 100GB 네트워크와 NVMe 드라이브로 데이터 레이크를 구축하는 것을 고려해보세요. 반구조화된 데이터용 스토리지 Parquet 파일, AVRO 파일, JSON 파일, 심지어 CSV 파일과 같은 반구조화된 파일을 저장하기 위해 Modern Datalake 내에서 사용할 수 있는 몇 가지 옵션이 있습니다. 가장 쉬운 방법은 Data Lake에 저장하고 구조화되지 않은 개체를 로드하는 것과 같은 방식으로 로드하는 것입니다. 이러한 반구조화된 파일의 데이터가 Modern Datalake가 지원하는 다른 워크로드(비즈니스 인텔리전스, 데이터 분석 및 데이터 과학)에 필요하지 않은 경우 이것이 최선의 선택입니다. 또 다른 옵션은 이러한 파일을 다른 워크로드가 사용할 수 있는 데이터 웨어하우스에 로드하는 것입니다. 데이터가 데이터 웨어하우스에 로드되면 다음을 사용할 수 있습니다. 당신의 데이터로. 실험 수행을 위한 Zero Copy Branching 데이터 웨어하우스의 제로 카피 분기 기능 엔지니어링은 모델을 훈련하는 데 사용되는 데이터 세트를 개선하는 기술입니다. OTF 기반 데이터 웨어하우스가 갖고 있는 매우 매끄러운 기능은 Zero-copy 분기입니다. 이를 통해 Git 저장소 내에서 코드를 분기할 수 있는 것과 동일한 방식으로 데이터를 분기할 수 있습니다. 이름에서 알 수 있듯이 이 기능은 데이터의 복사본을 만드는 것이 아니라 데이터 웨어하우스를 구현하는 데 사용되는 공개 테이블 형식의 메타데이터 계층을 사용하여 데이터의 고유한 복사본 모양을 생성합니다. 데이터 과학자는 브랜치를 실험할 수 있습니다. 실험이 성공하면 다른 데이터 과학자가 사용할 수 있도록 브랜치를 기본 브랜치에 다시 병합할 수 있습니다. 실험이 성공하지 못하면 분기를 삭제할 수 있습니다. 생성 AI Scikit-Learn으로 구축된 소형 모델, PyTorch 또는 TensorFlow로 구축된 사용자 정의 신경망, Transformer 아키텍처 기반의 대규모 언어 모델 등 모든 모델은 입력으로 숫자가 필요하고 출력으로 숫자를 생성합니다. 이 단순한 사실은 단어를 숫자(또는 앞으로 살펴보겠지만 벡터)로 변환해야 하는 생성적 AI에 관심이 있는 경우 AI/ML 인프라에 몇 가지 추가 요구 사항을 부과합니다. 회사의 독점 지식이 포함된 개인 문서를 사용하여 LLM에서 생성된 답변을 향상시키려는 경우 생성 AI 솔루션은 훨씬 더 복잡해집니다. 이러한 향상은 검색 증강 생성(Retrieval Augmented Generation) 또는 LLM 미세 조정의 형태로 이루어질 수 있습니다. 이 섹션에서는 이러한 모든 기술(단어를 숫자로 변환, RAG 및 미세 조정)과 이것이 AI 인프라에 미치는 영향에 대해 설명합니다. 먼저 Custom Corpus를 구축하는 방법과 위치를 논의해 보겠습니다. 벡터 데이터베이스를 사용하여 사용자 정의 코퍼스 만들기 Generative AI에 대해 진지하게 생각한다면 맞춤형 코퍼스가 조직을 정의해야 합니다. 누구도 가지고 있지 않은 지식이 담긴 문서로, 진실되고 정확한 정보만을 담고 있어야 합니다. 또한 사용자 정의 코퍼스는 벡터 데이터베이스로 구축되어야 합니다. 벡터 데이터베이스는 문서의 숫자 표현인 벡터 임베딩과 함께 문서에 대한 액세스를 색인화, 저장 및 제공합니다. (이렇게 하면 위에서 설명한 숫자 문제가 해결됩니다.) 벡터 데이터베이스는 의미론적 검색을 용이하게 합니다. 이를 수행하는 방법에는 많은 수학적 배경 지식이 필요하고 복잡합니다. 그러나 의미 검색은 개념적으로 이해하기 쉽습니다. "인공 지능"과 관련된 모든 내용을 논의하는 모든 문서를 찾고 싶다고 가정해 보겠습니다. 기존 데이터베이스에서 이를 수행하려면 "인공 지능"에 대한 가능한 모든 약어, 동의어 및 관련 용어를 검색해야 합니다. 귀하의 쿼리는 다음과 같습니다. SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ... 수동 유사성 검색은 힘들고 오류가 발생하기 쉬울 뿐만 아니라 검색 자체도 매우 느립니다. 벡터 데이터베이스는 아래와 같은 요청을 받아 더 빠르고 정확하게 쿼리를 실행할 수 있습니다. 검색 증강 생성(Retrieval Augmented Generation)을 사용하려면 의미론적 쿼리를 빠르고 정확하게 실행하는 능력이 중요합니다. { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } } 사용자 정의 코퍼스에 대한 또 다른 중요한 고려 사항은 보안입니다. 문서에 대한 접근은 원본 문서에 대한 접근 제한을 준수해야 합니다. (인턴이 아직 월스트리트에 공개되지 않은 CFO의 재무 결과에 액세스할 수 있다면 안타까운 일입니다.) 벡터 데이터베이스 내에서 원본 콘텐츠의 액세스 수준과 일치하도록 인증을 설정해야 합니다. 이는 벡터 데이터베이스를 조직의 ID 및 액세스 관리 솔루션과 통합하여 수행할 수 있습니다. 기본적으로 벡터 데이터베이스는 구조화되지 않은 데이터를 저장합니다. 따라서 Data Lake를 스토리지 솔루션으로 사용해야 합니다. 문서 파이프라인 구축 불행하게도 대부분의 조직에는 깨끗하고 정확한 문서가 담긴 단일 저장소가 없습니다. 오히려 문서는 다양한 형식의 다양한 팀 포털을 통해 조직 전체에 분산되어 있습니다. 결과적으로 사용자 정의 코퍼스를 구축하는 첫 번째 단계는 Generative AI에 사용하도록 승인된 문서만 가져와 벡터 데이터베이스에 배치하는 파이프라인을 구축하는 것입니다. 대규모 글로벌 조직의 경우 이는 잠재적으로 Generative AI 솔루션에서 가장 어려운 작업일 수 있습니다. 팀이 포털에 초안 형식의 문서를 두는 것이 일반적입니다. 무엇이 될 수 있는지에 대해 무작위로 생각하는 문서가 있을 수도 있습니다. 이러한 문서는 비즈니스를 정확하게 나타내지 않으므로 사용자 정의 자료의 일부가 되어서는 안 됩니다. 불행하게도 이러한 문서를 필터링하려면 수동 작업이 필요합니다. 문서 파이프라인은 또한 문서를 텍스트로 변환해야 합니다. 다행히도 몇몇 오픈 소스 라이브러리에서는 다양한 일반 문서 형식에 대해 이 작업을 수행할 수 있습니다. 또한 문서 파이프라인은 문서를 벡터 데이터베이스에 저장하기 전에 작은 세그먼트로 나누어야 합니다. 이는 나중에 섹션에서 설명할 검색 증강 생성에 이러한 문서를 사용할 때 프롬프트 크기에 대한 제한 때문입니다. 대규모 언어 모델 미세 조정 대규모 언어 모델을 미세 조정할 때 사용자 정의 코퍼스의 정보를 사용하여 조금 더 훈련합니다. 이는 도메인별 LLM을 얻는 좋은 방법이 될 수 있습니다. 이 옵션을 사용하려면 사용자 정의 코퍼스에 대한 미세 조정을 수행하기 위해 컴퓨팅이 필요하지만 처음부터 모델을 훈련하는 것만큼 집약적이지는 않으며 적당한 시간 내에 완료할 수 있습니다. 도메인에 일상적으로 사용되지 않는 용어가 포함되어 있는 경우 미세 조정을 통해 LLM 응답의 품질을 향상시킬 수 있습니다. 예를 들어, 의학 연구, 환경 연구, 자연 과학과 관련된 모든 문서를 사용하는 프로젝트는 미세 조정을 통해 이점을 얻을 수 있습니다. 미세 조정은 문서에서 발견된 매우 구체적인 언어를 가져와 모델의 파라메트릭 매개변수에 적용합니다. 이 접근 방식을 결정하기 전에 미세 조정의 장점과 단점을 이해해야 합니다. 단점 미세 조정에는 컴퓨팅 리소스가 필요합니다. 설명이 불가능합니다. 코퍼스가 발전함에 따라 정기적으로 새로운 데이터로 미세 조정해야 합니다. 환각이 걱정됩니다. 문서 수준의 보안은 불가능합니다. 장점 LLM은 미세 조정을 통해 사용자 정의 코퍼스로부터 지식을 얻습니다. 추론 흐름은 RAG보다 덜 복잡합니다. 미세 조정은 비즈니스 언어에 대해 LLM을 가르치는 좋은 방법이지만 대부분의 LLM에는 수십억 개의 매개 변수가 포함되어 있고 데이터가 이러한 모든 매개 변수에 분산되므로 데이터가 희석됩니다. 미세 조정의 가장 큰 단점은 문서 수준의 인증이 불가능하다는 것입니다. 문서가 미세 조정에 사용되면 해당 정보는 모델의 일부가 됩니다. 사용자의 인증 수준에 따라 이 정보를 제한하는 것은 불가능합니다. 추론 시 사용자 정의 데이터와 파라메트릭 데이터를 결합하는 기술을 살펴보겠습니다. 검색 증강 생성(RAG) 검색 증강 생성(RAG)은 질문에서 시작하는 기술입니다. 벡터 데이터베이스를 사용하여 질문을 추가 데이터와 결합한 다음 콘텐츠 생성을 위해 질문과 데이터를 LLM에 전달합니다. RAG를 사용하면 품질 문서 모음에서 관련 텍스트 조각을 보내 LLM을 교육하므로 교육이 필요하지 않습니다. 질문 답변 작업을 사용하면 다음과 같이 작동합니다. 사용자가 애플리케이션의 사용자 인터페이스에서 질문합니다. 귀하의 애플리케이션은 질문, 특히 질문에 포함된 단어를 선택하고 벡터 데이터베이스를 사용하여 고품질 문서 모음에서 상황에 맞는 텍스트 조각을 검색합니다. 이 스니펫과 원래 질문은 LLM으로 전송됩니다. 이 전체 패키지 - 질문과 스니펫(컨텍스트)을 프롬프트라고 합니다. LLM은 이 정보를 사용하여 답변을 생성합니다. 이것은 어리석은 일처럼 보일 수 있습니다. 이미 답(스니펫)을 알고 있다면 왜 LLM을 사용합니까? 이는 실시간으로 발생하며 목표는 복사하여 연구에 붙여넣을 수 있는 텍스트를 생성하는 것입니다. 사용자 정의 코퍼스의 정보를 통합하는 텍스트를 생성하려면 LLM이 필요합니다. 이는 미세 조정보다 더 복잡합니다. 그러나 추론 시 벡터 데이터베이스에서 문서(또는 문서 조각)가 선택되므로 사용자 인증을 구현할 수 있습니다. 문서의 정보는 모델의 파라메트릭 매개변수의 일부가 되지 않습니다. RAG의 장점과 단점은 다음과 같습니다. 단점 추론 흐름은 더 복잡합니다. 장점 LLM은 사용자 정의 말뭉치로부터 직접적인 지식을 갖고 있습니다. 설명이 가능합니다. 미세 조정이 필요하지 않습니다. 환각은 크게 감소하며 벡터 데이터베이스 쿼리의 결과를 검사하여 제어할 수 있습니다. 권한을 구현할 수 있습니다. MLOps(기계 학습 작업) MLOps의 중요성을 더 잘 이해하려면 모델 생성을 기존 애플리케이션 개발과 비교하는 것이 도움이 됩니다. 애플리케이션에 새로운 기능을 추가하는 새로운 마이크로서비스 구현과 같은 기존 애플리케이션 개발은 사양 검토부터 시작됩니다. 새로운 데이터 구조나 기존 데이터 구조에 대한 변경 사항이 먼저 설계됩니다. 코딩이 시작되면 데이터 디자인이 변경되어서는 안 됩니다. 그런 다음 서비스가 구현되고 코딩이 이 프로세스의 주요 활동입니다. 단위 테스트와 엔드투엔드 테스트도 코딩됩니다. 이러한 테스트를 통해 코드에 결함이 없으며 사양이 올바르게 구현되었음을 입증합니다. 전체 애플리케이션을 배포하기 전에 CI/CD 파이프라인을 통해 자동으로 실행할 수 있습니다. 모델을 만드는 것과 훈련하는 것은 다릅니다. 원시 데이터와 필요한 예측을 이해하는 것이 첫 번째 단계입니다. ML 엔지니어는 신경망을 구현하거나 알고리즘을 설정하기 위해 일부 코드를 작성해야 하지만 코딩이 주요 활동은 아닙니다. 반복적인 실험이 주요 활동입니다. 실험 중에 데이터 설계, 모델 설계 및 사용된 매개변수가 모두 변경됩니다. 모든 실험 후에 모델이 훈련된 대로 수행되는 방식을 보여주는 측정항목이 생성됩니다. 검증 세트 및 테스트 세트에 대한 모델 성능에 대한 메트릭도 생성됩니다. 이러한 측정항목은 모델의 품질을 입증하는 데 사용됩니다. 모델을 애플리케이션에 통합할 준비가 되면 패키징하고 배포해야 합니다. Machine Learning Operations의 약자인 MLOps는 이러한 차이점을 해결하기 위한 일련의 사례 및 도구입니다. 실험 추적 및 협업은 MLOP와 가장 관련된 기능이지만 오늘날 업계의 최신 MLOP 도구는 훨씬 더 많은 작업을 수행할 수 있습니다. 예를 들어 실험을 위한 런타임 환경을 제공할 수 있으며, 애플리케이션에 통합할 준비가 되면 모델을 패키징하고 배포할 수 있습니다. 다음은 현재 MLOps 도구에 있는 기능의 상위 집합입니다. 이 목록에는 지원 및 데이터 통합과 같이 고려해야 할 다른 사항도 포함되어 있습니다. - MLOps 기술과 기능은 지속적으로 발전하고 있습니다. 주요 업체의 지원을 받아 도구가 지속적으로 개발되고 개선되는 도구를 원합니다. 주요 업체의 지원 - 실험에서는 구조화된 데이터와 구조화되지 않은 데이터가 많이 생성됩니다. 이상적으로는 데이터 웨어하우스와 데이터 레이크에 저장할 수 있습니다. 그러나 최신 데이터레이크를 탄생시킨 Open Table Formats 이전에도 많은 MLOps 도구가 있었기 때문에 대부분은 구조화된 데이터를 위한 별도의 솔루션을 갖게 될 것입니다. 최신 Datalake 통합 - 각 실험의 데이터세트, 모델, 하이퍼파라미터 및 측정항목을 추적합니다. 실험 추적은 또한 반복성을 촉진해야 합니다. 실험 추적 - 팀 구성원이 모든 ML 엔지니어가 실행한 모든 실험의 결과를 볼 수 있습니다. 협업 촉진 - 다른 프로그래밍 환경에서 액세스할 수 있도록 모델을 패키징합니다. 모델 패키징 - 조직의 공식 환경에 모델을 배포합니다. 모델을 기존 CI/CD 파이프라인에 통합하는 방법을 찾았다면 이 방법이 필요하지 않습니다. 모델 제공 - 모든 모델의 모든 버전을 유지 관리합니다. 모델 레지스트리 - 일부 도구는 클러스터에서 실험을 실행하기 위해 함수나 모델을 컨테이너화된 서비스로 배포할 수 있는 방식으로 코드에 주석을 추가할 수 있는 기능을 제공합니다. 서버리스 기능 - 일부 MLOps 도구는 완전한 엔드 투 엔드 기능을 제공하는 것을 목표로 하며 원시 데이터를 검색하고 저장하기 위한 파이프라인을 구축할 수 있는 기능을 갖추고 있습니다. 이미 데이터 파이프라인이 있는 경우에는 필요하지 않습니다. 데이터 파이프라인 기능 - 서버리스 기능을 방향성 비순환 그래프로 조정하는 기능입니다. 또한 학습 파이프라인을 예약하고 실행할 수 있습니다. 교육 파이프라인 기능 AI 데이터 인프라에 GPU가 미치는 영향 체인은 가장 약한 링크만큼 강력하며 AI/ML 인프라는 가장 느린 구성 요소만큼 빠릅니다. GPU를 사용하여 기계 학습 모델을 훈련하는 경우 약한 링크가 스토리지 솔루션이 될 수 있습니다. 그 결과는 우리가 "GPU 부족 문제"라고 부르는 것입니다. GPU 부족 문제는 네트워크 또는 스토리지 솔루션이 GPU를 완전히 활용할 수 있을 만큼 빠르게 훈련 로직에 훈련 데이터를 제공할 수 없을 때 발생합니다. 증상은 꽤 분명합니다. GPU를 모니터링하면 GPU가 완전히 활용되는 데 결코 가까워지지 않는다는 것을 알 수 있습니다. 훈련 코드를 계측한 경우 총 훈련 시간이 IO에 의해 좌우된다는 것을 알 수 있습니다. 불행하게도 이 문제로 고민하고 있는 사람들에게는 나쁜 소식이 있습니다. GPU가 점점 빨라지고 있습니다. 이 문제가 앞으로 몇 년 동안 어떻게 더 악화될 것인지 이해하기 위해 GPU의 현재 상태와 이를 통해 이루어지고 있는 몇 가지 발전을 살펴보겠습니다. GPU의 현재 상태 GPU가 점점 빨라지고 있습니다. 원시 성능이 향상될 뿐만 아니라 메모리와 대역폭도 증가합니다. Nvidia의 최신 GPU의 세 가지 특징을 살펴보겠습니다. , 그리고 . A100 H100 H200 GPU 성능 메모리 메모리 대역폭 A100 624테라플롭 40GB 1,555GB/초 H100 1,979테라플롭스 80GB 3.35TB/초 H200 1,979테라플롭스 141GB 4.8TB/초 참고: 위 표에서는 A100용 PCIe(Peripheral Component Interconnect Express) 소켓 솔루션과 H100 및 H200용 SXM(Server PCI Express Module) 소켓 솔루션에 맞는 통계를 사용합니다. A100에 대한 SXM 통계는 존재하지 않습니다. 성능과 관련하여 부동 소수점 16 Tensor Core 통계가 비교에 사용됩니다. 위의 통계에 대한 몇 가지 비교 관찰은 주목할 가치가 있습니다. 먼저 H100과 H200은 동일한 성능(1,979 TFLOPS)을 갖고 있어 A100보다 3.17배 향상됐다. H100은 A100보다 두 배 많은 메모리를 갖고 있으며 메모리 대역폭도 비슷한 양만큼 증가했습니다. 그렇지 않으면 GPU가 스스로 고갈될 것입니다. H200은 무려 141GB의 메모리를 처리할 수 있으며 메모리 대역폭도 다른 GPU에 비해 비례적으로 증가했습니다. 이러한 각 통계를 더 자세히 살펴보고 이것이 머신러닝에 어떤 의미인지 논의해 보겠습니다. - 테라플롭(TFLOP)은 초당 1조(10^12) 부동 소수점 연산을 의미합니다. 이는 1 뒤에 0이 12개 있는 1입니다(1,000,000,000,000). 모델 교육 중에 발생하는 부동 소수점 연산에는 간단한 텐서 수학과 손실 함수(그라디언트라고도 함)에 대한 1차 파생이 포함되므로 TFLOP를 기가바이트 단위의 IO 수요와 동일시하기가 어렵습니다. 그러나 상대적인 비교는 가능합니다. 위의 통계를 보면 둘 다 1,979 TFLOPS로 성능을 발휘하는 H100과 H200이 3배 더 빠르다는 것을 알 수 있습니다. 다른 모든 것이 따라잡을 수 있다면 잠재적으로 데이터를 3배 더 빠르게 소비할 수 있습니다. 성능 - 비디오 RAM 또는 그래픽 RAM이라고도 합니다. GPU 메모리는 시스템의 주 메모리(RAM)와 분리되어 있으며 그래픽 카드에서 수행되는 집약적인 그래픽 처리 작업을 처리하도록 특별히 설계되었습니다. GPU 메모리는 모델을 훈련할 때 배치 크기를 결정합니다. 과거에는 학습 로직이 CPU에서 GPU로 이동하면 배치 크기가 감소했습니다. 그러나 GPU 메모리가 용량 측면에서 CPU 메모리를 따라잡으면 GPU 훈련에 사용되는 배치 크기가 늘어납니다. 성능과 메모리 용량이 동시에 증가하면 결과적으로 1GB의 훈련 데이터가 더 빠르게 처리되는 더 큰 요청이 발생합니다. GPU 메모리 - GPU 메모리 대역폭을 메모리와 계산 코어를 연결하는 "고속도로"로 생각하십시오. 단위 시간당 전송할 수 있는 데이터의 양을 결정합니다. 고속도로가 넓어지면 주어진 시간에 더 많은 자동차가 지나갈 수 있는 것처럼, 메모리 대역폭이 높을수록 메모리와 GPU 간에 더 많은 데이터가 이동할 수 있습니다. 보시다시피, 이러한 GPU의 설계자는 메모리에 비례하여 각 새 버전의 메모리 대역폭을 늘렸습니다. 따라서 칩의 내부 데이터 버스는 병목 현상이 발생하지 않습니다. 메모리 대역폭 모델 훈련을 위한 객체 스토리지 강화 GPU 부족 문제가 발생하는 경우 100GB 네트워크 및 NVMe 드라이브 사용을 고려하십시오. ㅏ 이러한 구성으로 MinIO를 사용하면 기성 NVMe SSD의 노드가 32개뿐이어서 GET에서 325GiB/s, PUT에서 165GiB/s를 달성했습니다. 최근 벤치마크 컴퓨팅 세계가 발전하면서 서버 구성에는 500GB 이상의 DRAM이 포함되는 경우가 많습니다. 대규모 배포를 처리하는 경우, 초고밀도 NVMe 드라이브를 사용하는 경우에도 서버 수에 해당 서버의 DRAM을 곱하면 인스턴스당 수 TB에 달하는 경우가 종종 있습니다. 해당 DRAM 풀은 분산된 공유 메모리 풀로 구성될 수 있으며 대규모 IOPS 및 처리량 성능을 요구하는 워크로드에 이상적입니다. 결과적으로 우리는 Enterprise 및 Enterprise Lite 고객이 이 공유 메모리 풀을 활용하여 GPU 교육과 같은 핵심 AI 워크로드의 성능을 더욱 향상시키는 동시에 전체 지속성을 유지하도록 인프라를 구성할 수 있도록 MinIO 캐시를 구축했습니다. D램 가격이 폭락했다 두 조직의 이야기 결론적인 사고 실험으로 AI/ML 여정에서 매우 다른 접근 방식을 취하는 두 조직의 이야기를 들려드리겠습니다. 조직 #1에는 "반복적 개선" 문화가 있습니다. 그들은 모든 큰 계획이 더 작고 관리하기 쉬운 프로젝트로 나눌 수 있다고 믿습니다. 이러한 소규모 프로젝트는 이전 프로젝트의 결과를 바탕으로 점점 더 복잡해지는 문제를 해결하는 방식으로 계획됩니다. 그들은 또한 각 프로젝트가 비즈니스에 가치를 제공하는 방식으로 구성된 이러한 소규모 프로젝트를 좋아합니다. 그들은 비즈니스를 위한 새로운 기능 없이 인프라 개선이나 소프트웨어 현대화에만 전념하는 프로젝트가 예산을 관리하는 경영진에게 별로 인기가 없다는 사실을 발견했습니다. 결과적으로 그들은 생성적 AI 개념 증명을 위해 고급 스토리지 어플라이언스와 컴퓨팅 클러스터를 요청하는 것이 인프라 개선과 새로운 소프트웨어 기능을 조율하는 최선의 방법이 아니라는 것을 알게 되었습니다. 오히려 그들은 성장에 따라 확장할 수 있는 인프라 제품으로 작게 시작할 것입니다. 간단한 AI 모델로 시작하여 MLOP 도구를 마련하고 기존 DevOps 팀 및 CI/CD 파이프라인과 협력하는 방법을 파악할 수 있습니다. 조직 #2에는 "빛나는 개체" 문화가 있습니다. 최신 아이디어가 업계에 들어오면 먼저 그 기술적 위력을 입증하기 위해 가장 주목받는 과제를 해결합니다. 그들은 이러한 프로젝트가 내부 및 외부 모두에서 매우 눈에 띄는 것을 발견했습니다. 뭔가 고장나면 똑똑한 사람들이 언제든지 고칠 수 있습니다. 조직 #1은 주요 전자상거래 사이트에 대한 추천 모델을 작업하는 동시에 AI 데이터 인프라의 일부를 구축하여 첫 번째 프로젝트를 구성했습니다. 추천 모델은 훈련하기가 비교적 간단했습니다. 파일 공유에 이미 존재하는 데이터 세트를 사용하는 판별 모델입니다. 그러나 이 프로젝트가 끝날 무렵 팀은 소규모이지만 확장 가능한 Modern Datalake를 구축하고 MLOP 도구를 구현했으며 모델 교육 및 배포를 위한 몇 가지 모범 사례를 마련했습니다. 모델이 복잡하지 않더라도 여전히 사이트에 많은 효율성을 추가했습니다. 그들은 이러한 긍정적인 결과를 생성 AI 솔루션이 될 다음 프로젝트에 대한 자금 조달에 사용했습니다. 조직 #2는 제품에 대한 고객 질문에 답변하는 전자상거래 사이트용 챗봇을 구축했습니다. 대규모 언어 모델은 상당히 복잡합니다. 팀은 미세 조정 또는 검색 증강 생성에 익숙하지 않았습니다. 따라서 이 프로젝트의 모든 엔지니어 주기는 가파른 학습 곡선을 빠르게 넘어가는 데 중점을 두었습니다. 모델이 완성되었을 때 별다른 결과는 나오지 않았지만 괜찮은 결과가 나왔습니다. 안타깝게도 배포를 위한 MLOps 도구가 없었기 때문에 사전 프로덕션 및 프로덕션 환경에 수동으로 사이드로드해야 했습니다. 이로 인해 DevOps 팀과 약간의 마찰이 발생했습니다. 모델 자체에도 생산 과정에서 몇 가지 안정성 문제가 있었습니다. 실행 중인 클러스터에는 생성적 AI 워크로드를 위한 컴퓨팅이 충분하지 않았습니다. 심각도 1 호출이 몇 건 있었는데, 이로 인해 트래픽이 많은 상황에서도 LLM이 실패하지 않도록 클러스터가 긴급하게 강화되었습니다. 프로젝트가 끝난 후 회고를 통해 AI로 성공하려면 인프라를 강화해야 한다고 결정했습니다. AI/ML 데이터 인프라 구축 계획 위의 단편 소설은 두 가지 극단적인 상황에 대한 간단한 서술입니다. AI 모델 구축(차별적 모델과 생성적 모델 모두)은 기존 소프트웨어 개발과 크게 다릅니다. AI/ML 작업을 대기열에 넣을 때 이 점을 고려해야 합니다. 아래 그래픽은 이전 섹션에서 설명한 이야기를 시각적으로 묘사한 것입니다. AI 데이터 인프라 우선 접근 방식과 모델 우선 접근 방식을 나란히 비교한 것입니다. 위의 이야기에서 볼 수 있듯이 인프라 우선 접근 방식을 위한 아래의 각 벽돌은 독립형 프로젝트일 필요는 없습니다. 조직은 인프라가 구축되는 동안 AI를 제공할 수 있는 창의적인 방법을 찾아야 합니다. 이는 AI의 모든 가능성을 이해하고 간단하게 시작한 다음 점점 복잡해지는 AI 프로젝트를 선택함으로써 수행할 수 있습니다. 결론 이 게시물에서는 AI/ML을 위한 최신 Datalake 참조 아키텍처를 구축하기 위해 기업과 협력한 경험을 간략하게 설명합니다. 이는 다양한 AI 접근 방식의 핵심 구성 요소, 주요 구성 요소 및 장단점을 식별합니다. 기본 요소는 객체 저장소 위에 구축된 최신 데이터 레이크입니다. 객체 저장소는 수백 페타바이트, 종종 엑사바이트에 달하는 대규모 성능을 제공할 수 있어야 합니다. 이 참조 아키텍처를 따르면 사용자는 AI 및 ML을 대상으로 하면서 모든 OLAP 워크로드에서 동일한 성능을 발휘하는 유연하고 확장 가능한 데이터 인프라를 구축할 수 있을 것으로 기대합니다. 구성 부품에 대한 구체적인 권장 사항을 얻으려면 주저하지 말고 저에게 연락해 주세요. . keith@min.io