BentoML 기능과 구성

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

BentoML을 모델을 API로 감싸는 도구라고만 이해하면 요청 처리, 여러 모델의 연결, 실행 환경과 배포 패키지의 역할이 빠진다. 모델 파일을 읽은 뒤 어떤 서비스를 만들고 운영할지에 관한 기능으로 나누어 정리했다.

이 글은 최신 공식 문서의 기능을 살펴보는 참고 글이다. BentoML을 기존 AML 실습 환경에 추가 설치하거나 두 도구를 반드시 함께 쓰도록 바꾸는 내용은 아니다. 책의 예전 Service와 Runner 예제, 최신 클래스 기반 Service API는 버전을 구분해 읽는다.

기본 구성 단위

모델 버전, Bento 버전과 deployment는 같은 식별자가 아니다. 모델은 그대로여도 API 코드나 의존성을 바꾸면 다른 서비스 패키지가 될 수 있다.

기능 지도

일부 설정은 프레임워크에서 정의하더라도 실제 자원 배치나 자동 확장은 배포 플랫폼이 수행한다. 로컬 실행과 BentoCloud, 직접 운영하는 컨테이너 환경을 동일한 운영 방식으로 보지 않는다.

기능과 인터페이스의 연결

같은 기능 이름이어도 버전에 따라 인자와 구성 방식이 달라질 수 있다. 이 글의 개념을 확인한 뒤 실제로 사용할 SDK 버전의 예제로 연결할 부분이다.

모델 로딩과 Model Store

Model Store는 BentoML이 관리하는 모델 저장 공간이다. 모델을 저장하거나 가져오고, tag로 특정 모델을 참조할 수 있다. 모델 파일의 가져오기와 내보내기, BentoCloud로의 push와 pull 같은 관리 경로도 제공한다.

Hugging Face 같은 외부 모델을 참조하는 경로도 있다. 모델 참조를 선언한 것과 실제 추론 라이브러리로 파일을 읽는 것은 다르다. 모델의 가중치, tokenizer, 전처리 정보와 의존성이 함께 맞아야 한다.

최신 문서는 BentoModel이나 HuggingFaceModel을 Service의 클래스 범위에 선언해 모델 의존성을 식별하도록 설명한다. 임의의 위치에서 파일을 읽었다고 패키징 과정이 그 모델을 항상 발견한다고 가정하지 않는다.

모델 출처의 인증, 다운로드 경로, 라이선스와 사용 범위도 확인할 대상이다. 저장소에서 모델을 찾았다는 사실과 운영에서 사용할 권한이 있다는 사실은 다르다.

Service와 API

Service는 모델을 읽고 실행하는 코드를 외부 요청과 연결한다. 최신 API는 클래스에 Service를 정의하고, 공개할 메서드를 API로 지정하는 방식을 사용한다.

예를 들어 이미지 분류 서비스는 이미지 읽기, 크기 변경, 모델 예측, 클래스 이름 변환을 하나의 호출로 묶을 수 있다. 이런 처리 중 무엇을 모델 패키지 안에 넣고 무엇을 서비스 코드에 둘지는 별도의 설계 결정이다.

Python 타입과 Pydantic 모델, NumPy나 DataFrame 같은 ML 데이터 타입으로 입력과 출력을 표현할 수 있다. 이 정보는 검증과 API 문서 및 클라이언트의 계약에 연결된다.

타입 검사가 정상이어도 값의 의미가 맞는 것은 아니다. 이미지 크기, 허용 범위, 요청 크기와 업무 규칙은 실제 서비스에 맞춰 정할 부분이다.

여러 모델과 서비스의 조합

한 요청에서 여러 모델을 사용할 수 있다. 하나의 Service 안에서 여러 모델을 실행하거나, 별도 Service를 의존성으로 연결해 순서대로 또는 병렬로 호출할 수 있다.

예를 들어 문서를 임베딩하고 검색 결과로 답변을 생성하는 흐름을 서비스로 구성할 수 있다. 이것이 학습 데이터 준비, 학습과 승인까지 포함한 전체 MLOps 파이프라인을 대신하는 것은 아니다.

동시 처리와 자원 사용

Worker는 Service의 코드를 실행하는 프로세스다. Worker 수와 동시에 처리할 요청 수, replica 수는 구분한다.

Worker를 늘리면 모델이 프로세스마다 로딩되어 메모리 사용이 늘 수 있다. async 함수를 사용한다고 CPU나 GPU 연산 자체가 자동으로 빨라지는 것도 아니다.

자원 요구를 코드에 표시하는 것과 실제 인프라의 자원 제한을 적용하는 것은 다르다. BentoCloud에서는 해당 플랫폼의 배치와 확장 설정을 사용하고, 직접 운영하는 환경에서는 컨테이너나 클러스터의 설정도 함께 확인한다.

배칭과 비동기 작업

기능 이름에 batch나 async가 들어가더라도 해결하는 문제는 다르다.

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 기능을 이해하기 위해 기존 가상환경에 최신 BentoML이나 다른 MLflow 버전을 함께 설치하도록 바꾸지는 않았다.

기능을 연결해 볼 사례

서빙 프레임워크를 사용해도 서비스 계약과 운영 책임은 남는다. 기능을 많이 사용하는 것보다 모델, 서비스 패키지와 실제 실행의 관계를 다시 설명할 수 있는지가 중요했다.

참고 자료

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

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