BentoML 기능과 구성

✎ 이 문서 수정하기 GitHub에서 수정

BentoML은 모델 API, 요청 처리, 모델 조합, 환경과 패키징을 다룬다.

이 글은 최신 공식 문서의 기능 안내다. AML 실습 환경에 BentoML을 추가하지 않으며, 예전 Service, Runner와 최신 클래스 기반 API를 버전별로 구분한다.

기본 구성 단위

모델 버전과 Bento, deployment 버전은 다르다. 코드나 의존성이 바뀌면 모델이 같아도 패키지가 달라진다.

기능 지도

자원 배치와 자동 확장은 플랫폼 책임이다. 로컬, BentoCloud와 자체 운영은 다르다.

기능과 인터페이스의 연결

API 인자와 구성은 SDK 버전별로 다르다.

모델 로딩과 Model Store

Model Store는 모델 저장, 가져오기와 tag 기반 참조를 제공한다. 파일 import/export와 BentoCloud push/pull도 지원한다.

Hugging Face 등 외부 모델도 참조할 수 있지만 선언만으로 추론 파일을 읽지는 않는다. 가중치, tokenizer, 전처리 정보와 의존성을 맞춰야 한다.

최신 문서는 BentoModel, HuggingFaceModel을 Service 클래스에 선언해 의존성을 식별한다. 임의 경로 파일이 자동 패키징된다고 가정하지 않는다.

모델 출처의 인증, 다운로드, 라이선스, 사용 범위를 확인한다. 저장소에 있다는 사실이 운영 사용 권한을 뜻하지는 않는다.

Service와 API

Service는 모델 코드를 외부 요청에 연결한다. 최신 API는 클래스에 Service를, 공개 메서드에 API를 정의한다.

이미지 분류 Service는 이미지 로딩, 크기 조정, 예측, 클래스명 변환을 한 호출로 묶는다. 각 처리를 모델 패키지와 서비스 코드 중 어디에 둘지는 설계에 달렸다.

Python, Pydantic, NumPy, DataFrame 타입으로 입출력을 표현해 검증, API 문서와 클라이언트 계약에 연결한다.

타입 외에 이미지 크기, 허용 범위, 요청 크기와 업무 규칙을 검증한다.

여러 모델과 서비스의 조합

문서 임베딩과 검색 결과 기반 답변 생성도 서비스로 묶을 수 있지만, 데이터 준비, 학습, 승인을 포함한 MLOps 파이프라인을 대체하지 않는다.

동시 처리와 자원 사용

Worker는 Service 실행 프로세스다. Worker, 동시 요청과 replica 수는 서로 다른 값이다.

Worker 증가는 프로세스별 모델 로딩으로 메모리를 늘릴 수 있다. async는 CPU, GPU 연산을 자동 가속하지 않는다.

코드의 자원 표시는 인프라 제한이 아니므로 배포 설정도 확인한다.

배칭과 비동기 작업

Adaptive batching은 모델의 묶음 입력 처리가 필요하다. 최대 크기와 지연에 따라 처리량과 대기 시간이 절충되며 입력, 출력 순서도 확인한다.

Async task는 장기 추론을 제출하고 ID로 상태, 결과를 조회한다. 결과 보존, 취소와 재시도 조건을 정한다.

로컬 task 큐와 임시 저장소는 개발용 메모리 기반이며 재시작 후 유지되지 않는다.

AML batch endpoint와 BentoCloud 배치 작업은 adaptive batching과 다르다. 런타임 요청 묶음과 데이터 묶음 비동기 실행은 별개다.

Streaming과 웹 기능 연동

Streaming은 텍스트, 오디오 결과를 순차 전달한다. LLM 토큰을 점진적으로 보내거나 ASGI와 결합해 WebSocket을 구성할 수 있다.

첫 응답 시간, 연결 종료, 취소와 중간 오류도 정의한다. 전송 시작 후 오류는 단일 JSON 오류와 다르게 처리할 수 있다.

서비스 연결만으로 스트리밍이 자동 조합되지는 않으므로 입출력 계약을 확인한다.

실행 환경, Bento와 컨테이너

런타임은 Python 버전, 패키지, 운영체제, 시스템 패키지와 빌드 작업을 포함한다. 공식 문서는 Python SDK의 Image와 기존 bentofile.yaml 구성을 구분한다.

    flowchart LR
    accTitle: BentoML 모델과 서비스의 배포 단위
    accDescr: 구체 모델 참조와 Service 코드, 실행 환경을 Bento 패키지로 구성한다. 이를 컨테이너 이미지로 만들어 직접 운영하거나 BentoCloud 배포에 연결한다.
    M["구체 모델 참조"] --> B["Bento"]
    S["Service 코드와 API"] --> B
    E["의존성과 실행 설정"] --> B
    B --> I["컨테이너 이미지"]
    I --> P["컨테이너 실행 플랫폼"]
    B --> C["BentoCloud deployment"]
  

Python, 시스템 라이브러리 차이는 결과와 로딩에 영향을 준다. 모델뿐 아니라 서비스 코드, 환경, 패키지 버전 조합도 기록한다.

필요한 파일만 패키징하고 .bentoignore와 빌드 범위를 확인한다. 자격 증명, 고객 데이터는 이미지에서 제외하고 비밀은 배포 환경의 비밀 관리로 전달한다.

운영 관측

BentoML은 메트릭과 OpenTelemetry tracing을 구성할 수 있지만 수집 지점과 저장, 분석 시스템은 별개다.

Prometheus와 Grafana로 메트릭을 분석하거나 trace를 별도 수집기에 보낼 수 있다. 제공 기능과 대상, sampling, 전송 경로 설정은 구분한다.

가용성과 속도는 예측 품질을 보장하지 않으므로 정답 평가, 데이터 변화, 업무 성과를 별도로 본다.

bentoml.monitor는 입력, 예측, 정답을 수집해 분석 저장소와 연결할 수 있다. API 추가만으로 드리프트 판단과 대응 정책이 검증되지는 않는다.

입출력 관측에서는 민감 정보의 수집 범위와 보존 기간을 정한다.

BentoML과 BentoCloud의 경계

BentoCloud는 최소, 최대 replica, scale-to-zero, 동시 요청 기반 확장과 외부 큐를 제공한다. 다른 환경에 이 동작이 자동 적용되지는 않는다.

요청 대기, 콜드 스타트, 최대 replica를 함께 고려한다. Replica 0이 모든 비용이나 데이터를 없애지는 않는다.

MLflow와 연결할 때의 흐름

관리 단위가 다른 MLflow와 BentoML의 관계를 기록한다.

공식 예제는 MLflow 모델을 BentoML Model Store와 Service에서 사용한다. AML 모델 연결에는 인증, 접근, 버전 선택을 별도 구성한다.

01~06편은 AML 관리형 추론 경로이며 최신 BentoML이나 다른 MLflow 버전을 추가 설치하지 않는다.

기능을 연결해 볼 사례

서빙 프레임워크를 써도 서비스 계약과 운영 책임은 남는다. 모델, 패키지, 실행의 관계를 설명할 수 있어야 한다.

참고 자료

• Service와 API
• 모델 로딩과 관리
• 입력과 출력 타입
• 여러 모델의 조합
• Worker와 요청 처리
• Adaptive batching
• Async task
• Streaming
• 런타임 환경
• 패키징과 컨테이너
• 서비스 메트릭
• 모니터링과 추론 데이터 수집
• Tracing
• BentoCloud의 동시 처리와 자동 확장
• MLflow 연동
• BentoCloud 배포

MLflow 기능과 구성, 시리즈 목차, 01. 로컬 실습 시작