이 글은 2장 두 개의 글 중 두 번째 글로, 책 전반에 걸쳐 사용될 MLOps 및 LLMOps 도구들을 간략하게 소개합니다.

자세한 설명은 11장에서 다루며, 여기에서는 각 도구의 용도와 핵심 기능을 중심으로 설명합니다. 각 도구의 설치 및 설정 방법은 자세히 다루지 않고, Docker를 사용하여 로컬 환경에서 전체 인프라를 빠르게 실행하는 방법을 제시합니다.

모델을 파인튜닝 하려다 보니, 대규모 언어 모델(LLM)의 전체 수명 주기를 효율적으로 관리하고 최적화하는 LLMOps를 다룰 수 밖에 없습니다.  내용을 읽고 정리하다 보니 세미나 참여자들이 ‘헉’하고 포기할 수 있을 수도 있다는 생각이 들었습니다. 

저는 기초 모델이 점점 강화되는 상황에서 파인튜닝 보다는 검색증강생성으로 기존 모델과 연합하는 방법을 더 선호합니다. 우선 세미나 책 내용에 충실하고 Twin 개발은 파인튜닝 하지 않을 수도 있으니, 포기하고 싶어지면, ‘이런 것들이 필요 하고, 이런 것은 이런 것을 하는 구나’ 정도로 정리하고 나아가세요~

모델 레지스트리 – Hugging Face

모델 레지스트리는 머신러닝 모델의 라이프사이클 전반을 관리하는 중앙 집중식 저장소입니다. 모델 자체뿐만 아니라 메타데이터, 버전 히스토리, 성능 지표 등을 저장하여 모델에 대한 단일 정보 출처 역할을 합니다.

Hugging Face를 모델 레지스트리로 사용하는 이유:

저자는 Hugging Face를 모델 레지스트리로 사용하여 책 독자들과 미세 조정된 LLM Twin 모델을 쉽게 공유할 수 있습니다. 또한, Hugging Face의 모델 레지스트리 인터페이스를 따름으로써 Unsloth(미세 조정), SageMaker(추론) 등 LLM 생태계의 다른 프레임워크와 쉽게 통합할 수 있습니다.

미세 조정된 LLM 모델 위치:

• TwinLlama 3.1 8B (미세 조정 후):
  •  https://huggingface.co/mlabonne/TwinLlama-3.1-8B
• TwinLlama 3.1 8B DPO (선호도 정렬 후):
  • https://huggingface.co/mlabonne/TwinLlama-3.1-8B-DPO

ZenML – MLOps 플랫폼

ZenML은 다양한 클라우드 환경에서 재현 가능하고 관리하기 쉬운 ML 파이프라인을 구축할 수 있도록 지원하는 MLOps 플랫폼입니다.

ZenML은 ML 파이프라인의 오케스트레이션, 아티팩트 관리, 메타데이터 관리를 위한 강력한 기능을 제공합니다. @pipeline과 @step 데코레이터를 사용하여 파이프라인과 스텝을 정의하고, 모듈화된 코드 구조를 통해 코드의 재사용성과 유지보수성을 높일 수 있습니다. ZenML 대시보드를 통해 파이프라인 실행 상황을 모니터링하고, 각 스텝의 상세 정보를 확인할 수 있습니다.

핵심 기능 및 장점:

• 재현 가능한 워크플로: Jupyter Notebook에서의 실험적 연구를 프로덕션 환경으로 쉽게 전환할 수 있도록 돕습니다. 버전 관리, 실험 재현, 복잡한 워크플로 관리, 학습 및 배포 간의 연결, 메타데이터 추적 등의 문제를 해결합니다.
• ML 파이프라인 오케스트레이션: ML 파이프라인을 구성하고 관리하는 기능을 제공합니다. 파이프라인의 출력을 저장하고 버전을 관리하며, 아티팩트에 메타데이터를 연결하여 가시성을 높입니다.
• 스택(Stack) 개념: ZenML은 특정 클라우드 플랫폼에 종속되지 않습니다. 스택 개념을 통해 다양한 클라우드 서비스(오케스트레이터, 컴퓨팅 엔진, 원격 저장소, 컨테이너 레지스트리 등)를 연결하여 사용할 수 있습니다. 예를 들어, AWS SageMaker, S3, ECR을 사용하는 AWS 스택을 사용할 수 있으며, 필요에 따라 Google Cloud Storage나 Azure로 쉽게 전환 가능합니다. 이를 통해 인프라와 코드를 분리하여 유연성을 높입니다.
• 간편한 사용: Python 코드는 사용하는 인프라에 구애받지 않고 작성할 수 있습니다. ZenML이 인프라 관련 세부 사항을 처리하기 때문에, 개발자는 코드 로직에 집중할 수 있습니다.
• 로컬 및 클라우드 배포: poetry install을 통해 로컬 디버깅 서버를 설치할 수 있으며, 11장에서는 AWS에 ML 파이프라인을 배포하기 위한 클라우드 서버리스 옵션을 설명합니다.

ZenML을 오케스트레이터로 사용하여 ML 파이프라인을 구축하는 방법

• ZenML의 오케스트레이션 기능: ZenML은 @pipeline 데코레이터로 파이프라인을, @step 데코레이터로 스텝을 정의합니다. 파이프라인은 여러 스텝을 포함하는 상위 수준의 함수입니다. digital_data_etl 파이프라인 예제를 통해 데이터베이스 쿼리 및 링크 크롤링 스텝을 포함하는 파이프라인 구현 방법을 보여줍니다. poetry poe run-digital-data-etl 명령어로 파이프라인을 실행할 수 있습니다.
• ZenML 대시보드: ZenML 대시보드(http://127.0.0.1:8237/)를 통해 파이프라인 실행 상황(성공, 실패, 실행 중), 사용된 스택, 각 스텝의 출력 및 인사이트를 시각적으로 확인할 수 있습니다. 파이프라인 실행은 DAG(Directed Acyclic Graph) 형태로 표시됩니다.
• ZenML 스텝 정의: get_or_create_user 함수를 예로 들어 @step 데코레이터를 사용하여 ZenML 스텝을 정의하는 방법을 보여줍니다. 스텝은 독립적인 함수로 구성되며, ZenML 파이프라인 내에서 여러 스텝을 결합하여 복잡한 워크플로를 구축할 수 있습니다.
• 코드 모듈화: ZenML과 코드를 분리하기 위해 애플리케이션 및 도메인 로직을 llm_engineering 모듈에 캡슐화하고, ZenML 관련 코드는 pipelines 및 steps 폴더에 별도로 관리합니다. 이를 통해 ZenML을 다른 오케스트레이터로 쉽게 교체하거나 다른 용도로 애플리케이션 로직을 재사용할 수 있습니다.
• 아티팩트 직렬화: ZenML 스텝에서 반환되는 값은 직렬화 가능해야 합니다. ZenML은 기본 데이터 유형으로 변환 가능한 대부분의 객체를 직렬화할 수 있지만, UUID와 같이 ZenML에서 기본적으로 지원하지 않는 유형은 확장하여 지원해야 할 수 있습니다.

 ZenML에서 아티팩트와 메타데이터를 관리

ZenML은 아티팩트와 메타데이터를 사용하여 ML 파이프라인의 출력을 효율적으로 관리하고 추적합니다. 메타데이터를 통해 아티팩트에 대한 풍부한 정보를 제공하고, 버전 관리 및 공유 기능을 통해 실험 재현 및 모델 배포를 용이하게 합니다. 코드에서 수동으로 메타데이터를 추가하고, ZenML 대시보드 또는 CLI를 통해 아티팩트에 액세스할 수 있습니다.

• 아티팩트(Artifact): ML 라이프사이클에서 생성되는 모든 파일(데이터셋, 모델, 체크포인트, 로그 등)을 의미합니다. 실험 재현 및 모델 배포에 필수적이며, 버전 관리되고 공유 가능하며 메타데이터가 연결되어 있습니다.
• 메타데이터(Metadata): 아티팩트에 대한 추가 정보를 제공합니다. 데이터셋의 경우 크기, 훈련/테스트 분할 비율, 레이블 유형 등의 정보를 포함할 수 있습니다. 이는 아티팩트의 내용을 실제로 다운로드하지 않고도 이해하는 데 도움이 됩니다.
• digital_data_etl 파이프라인 예시: crawled_links 아티팩트의 메타데이터에는 크롤링된 도메인, 링크 수, 성공 여부 등의 정보가 포함됩니다.
• instruct_datasets 아티팩트 예시: LLM Twin 모델 미세 조정에 사용되는 instruct_datasets 아티팩트의 메타데이터에는 데이터 카테고리 수, 저장 크기, 훈련/테스트 샘플 수 등의 정보가 포함됩니다. 이 메타데이터는 코드에서 수동으로 추가됩니다.
• 메타데이터 추가 방법: get_step_context().add_output_metadata() 함수를 사용하여 아티팩트의 메타데이터를 추가할 수 있습니다.
• 아티팩트 액세스: ZenML 대시보드나 CLI를 통해 아티팩트의 UUID를 확인하고, Client().get_artifact_version() 함수를 사용하여 특정 버전의 아티팩트를 다운로드하고 액세스할 수 있습니다.

ZenML 파이프라인을 실행하고 구성하는 방법

tools/run.py 파일을 통해 CLI 명령어로 ZenML 파이프라인을 실행하고, poe 명령어를 통해 간소화된 실행을 지원합니다. YAML 설정 파일을 사용하여 파이프라인의 매개변수를 런타임에 구성하고, 재현성을 보장합니다.

• run.py 파일: ZenML 파이프라인을 실행하기 위한 CLI 인터페이스를 제공합니다. --run-etl, --no-cache, --etl-config-filename 등의 옵션을 사용하여 파이프라인을 실행하고, 캐시를 사용할지 여부와 설정 파일을 지정할 수 있습니다. 예를 들어, Maxime의 콘텐츠를 크롤링하려면 다음 명령어를 사용합니다.

• poe 명령어: run.py의 기능을 poe 명령어로 래핑하여 프로젝트와의 상호 작용을 간소화합니다.

• YAML 설정 파일: 파이프라인의 매개변수를 YAML 파일(digital_data_etl_maxime_labonne.yaml 등)에 정의하고, with_options() 함수를 사용하여 런타임에 파이프라인에 주입합니다. 이를 통해 코드를 수정하지 않고도 파이프라인을 구성하고, 입력 매개변수를 추적하여 재현성을 보장합니다.
• 다른 오케스트레이터: Airflow, Prefect, Metaflow, Dagster, Argo Workflows, Kubeflow 등 다른 오케스트레이터도 언급하지만, ZenML은 사용 편의성, 기능, 비용 측면에서 최상의 균형을 제공하고, 스택 기능을 통해 클라우드 플랫폼 종속성을 제거한다는 점을 강조합니다.

Comet ML – 머신러닝 모델 학습 과정에서 실험 관리를 위한 도구

Comet ML은 다양한 지표(학습 및 평가 손실, 기울기 규범 등)와 시스템 메트릭(GPU, CPU, 메모리 사용량 등)을 기록하여 실험 결과를 비교하고 최적의 모델을 선택하는 데 도움을 줍니다.

• 실험 추적 도구의 중요성: 머신러닝 모델 학습은 반복적이고 실험적인 과정입니다. 여러 실험을 병렬로 실행하고, 정의된 지표를 기반으로 비교하여 최적의 모델을 선택해야 합니다. 실험 추적 도구는 이러한 과정을 지원합니다.
• Comet ML의 기능: Comet ML은 학습 및 평가 손실, 기울기 규범 등의 지표와 GPU, CPU, 메모리 사용량과 같은 시스템 메트릭을 기록합니다. 이를 통해 실험 결과를 비교하고, 자원 사용량을 분석하고, 잠재적인 병목 현상을 파악할 수 있습니다. 하이퍼파라미터도 기록하여 다양한 설정을 비교할 수 있습니다.
• Comet ML 사용: 책에서는 Comet ML의 온라인 버전을 무료로 사용합니다. LLM Twin 모델 미세 조정 실험 결과는 다음 링크에서 공개적으로 확인할 수 있습니다: https://www.comet.com/mlabonne/llm-twin-training/view/new/panels
• 다른 실험 추적 도구: W&B, MLflow, Neptune 등 다른 실험 추적 도구도 있지만, Comet ML은 사용 편의성과 직관적인 인터페이스가 장점입니다.

LLM 애플리케이션의 프롬프트를 모니터링하기 위한 도구 – Opik

일반적인 로깅 도구로는 프롬프트를 효과적으로 모니터링하기 어렵기 때문에, 특화된 도구가 필요합니다.

Opik은 LLM 애플리케이션의 프롬프트를 효과적으로 모니터링하고 디버깅하기 위한 오픈소스 도구입니다. 단순하고 직관적인 인터페이스를 제공하며, 무료로 사용할 수 있다는 장점이 있습니다. 다른 프롬프트 모니터링 도구와 비교하여 사용 편의성이 뛰어나다는 점이 강조됩니다.

• 프롬프트 모니터링의 어려움: 프롬프트는 복잡하고 비정형적인 체인으로 구성되기 때문에, 일반적인 로깅 도구로는 효과적인 모니터링이 어렵습니다. LLM 애플리케이션과의 상호 작용에서 여러 프롬프트와 출력이 연속적으로 발생하며, 이러한 추적(trace)을 효과적으로 관리하고 디버깅하기 위한 특수한 도구가 필요합니다.
• Opik의 장점: Opik은 Comet에서 개발한 오픈소스 도구로, 단순성과 사용 편의성을 중시합니다. 프롬프트 추적을 위한 직관적인 대시보드를 제공하여 디버깅과 모니터링을 용이하게 합니다. 서버리스 옵션도 제공하며, 무료로 사용할 수 있습니다. (https://github.com/comet-ml/opik)
• 다른 프롬프트 모니터링 도구: Langfuse (오픈소스, https://langfuse.com), Galileo (유료), LangSmith (유료, https://www.langchain.com/langsmith) 등이 있지만, Opik이 사용 편의성 측면에서 우수합니다.

벡터 데이터베이스 –  Qdrant

저자는 다양한 벡터 데이터베이스를 고려했지만, 성능, 기능, 안정성, 그리고 장기적인 사용 가능성을 고려하여 Qdrant를 선택했습니다. Qdrant는 GenAI 애플리케이션에 적합한 선택이며, 다른 벡터 데이터베이스와의 자세한 비교는 외부 자료를 참고할 수 있습니다.

• Qdrant의 장점: Qdrant는 인기 있고 강력하며 기능이 풍부한 벡터 데이터베이스입니다. 성능(RPS, 지연 시간, 색인 시간)이 뛰어나며, X, Disney, Microsoft, Discord, Johnson & Johnson 등 주요 기업에서 사용하고 있습니다. 장기간 사용될 가능성이 높습니다. (https://qdrant.tech/)
• Qdrant의 용도: MongoDB에서 처리 및 변환된 데이터를 GenAI(Generative AI)에서 사용할 수 있도록 저장하는 데 사용됩니다.
• 다른 벡터 데이터베이스: Milvus, Redis, Weaviate, Pinecone, Chroma, pgvector 등 다른 벡터 데이터베이스도 있지만, Qdrant가 성능과 기능 면에서 최상의 균형을 제공합니다. 자세한 비교는 https://superlinked.com/vector-db-comparison 에서 확인할 수 있습니다.

AWS 계정 설정, 액세스 키 생성, AWS CLI 구성 방법

AWS 계정 생성 및 IAM 사용자 설정에 대한 자세한 내용은 AWS 공식 문서를 참조하도록 안내하고, 액세스 키 관리 및 보안, AWS CLI 설치 및 구성 방법을 설명합니다. 또한, .env 파일에 AWS 자격 증명을 설정하는 방법과 AWS 사용 비용에 대한 주의 사항을 포함합니다.

1. AWS 계정 생성: AWS 공식 문서 (https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html)를 참조하여 AWS 계정을 생성합니다.
2. IAM 사용자 생성 및 액세스 키 생성: AWS 공식 문서 (https://docs.aws.amazon.com/streams/latest/dev/setting-up.html, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)를 참조하여 관리자 권한을 가진 IAM 사용자를 생성하고 액세스 키를 생성합니다. 생성된 액세스 키는 안전하게 보관해야 합니다.
3. AWS CLI 설치 및 구성: AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 설치하고, aws configure 명령어를 사용하여 생성한 액세스 키로 구성합니다. (https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-files.html)
4. .env 파일 설정: .env 파일에 AWS 지역, 액세스 키 ID, 시크릿 액세스 키를 설정합니다.
5. AWS 사용 비용: AWS Free Tier를 초과하는 서비스 사용 시 비용이 발생합니다. SageMaker 사용 시 비용이 상당할 수 있으며, 정기적으로 청구 내역을 확인하고, 필요시 비용 경고를 설정해야 합니다. (https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)

AWS SageMaker -머신러닝 모델을 학습하고 배포하기 위한 AWS의 완전 관리형 머신러닝 서비스

• SageMaker의 정의: AWS SageMaker는 개발자와 데이터 과학자가 머신러닝 모델을 대규모로 구축, 학습 및 배포할 수 있도록 하는 완전 관리형 머신러닝 서비스입니다. 기반 인프라를 AWS가 관리하므로 사용자는 고품질 모델 개발에 집중할 수 있습니다.
• SageMaker의 용도 (본 책에서): GPU 클러스터를 사용하여 학습 파이프라인을 미세 조정하고 운영하며, 사용자 정의 LLM Twin 모델을 전 세계 어디에서나 실시간으로 액세스할 수 있는 REST API로 배포하는 데 사용됩니다.

SageMaker를 선택한 이유

책에서는 LLM 엔지니어링의 모든 측면을 다루기 위해 SageMaker를 선택했습니다. Bedrock은 빠른 프로토타이핑에는 적합하지만, 모델 배포에 필요한 모든 엔지니어링 과정을 보여주는 것이 책의 목표이기 때문에 SageMaker의 높은 사용자 지정 기능이 필요했습니다. SageMaker는 완전한 관리형 서비스와 사용자 지정 사이의 균형을 제공합니다.

• Amazon Bedrock: 서버리스 LLM 배포 솔루션. 사용 편의성이 높고, API 호출을 통해 미리 학습된 모델에 액세스할 수 있습니다. 하지만 사용 가능한 모델이 제한적이며, 사용자 지정 옵션이 제한적입니다. 단순한 API 호출 기반 가격 모델을 사용합니다.
• AWS SageMaker: ML 모델 구축, 학습 및 배포를 위한 포괄적인 플랫폼. 높은 수준의 사용자 지정이 가능하지만, 비용 관리가 복잡하고, 사용자는 머신러닝 및 클라우드 플랫폼에 대한 전문 지식을 필요로 합니다. pay-as-you-go 가격 모델을 사용합니다. 사용하지 않는 리소스에 대해서도 비용이 발생할 수 있습니다.
• EKS/ECS: 더 높은 수준의 사용자 지정과 비용 절감을 위해서는 EKS(Kubernetes) 또는 ECS를 사용할 수 있습니다.

2장 내용을 차 교수에게 전달했습니다.