재미있는 그림으로 살펴보는 케이서브의 ML 모델 서비스 알렉사 니콜 그리피시, 블룸버그

 

https://youtu.be/CIMQsOZra_U?si=sr3D74gjL2lq0UnP 

 

쿠버네티스는 컨트롤러 패턴을 구현하며, 컨트롤 플레인은 점선 안에 표현됩니다.
각 컴포넌트는 여러 하위 컴포넌트를 포함하며, 각 컴포넌트는 시스템의 다른 부분을 담당합니다.
따라서 API 서버는 일부 요청을 처리하는 프론트 엔드 역할을 합니다.

스케줄러는 노드의 스케줄링과 퇴거 등을 관리합니다.
마찬가지로 노드 자체에도 시스템이 원활하게 실행되도록 하는 구성 요소가 있습니다.
예를 들어, 트래픽을 위해 노드 간 통신을 허용하는 네트워크 프록시가 있습니다.

그리고 DNS와 같이 플러그인 가능한 다른 애드온도 있습니다.
따라서 쿠버네티스는 사용자 정의 리소스 정의를 생성할 수 있습니다.

대부분의 사용자는 이것과 커스텀 컨트롤러에 익숙할 것입니다.
이 두 가지를 결합하면 선언적 API 또는 원하는 상태 시스템을 얻을 수 있습니다.
이것이 바로 Kserve가 하는 일입니다.
쿠버네티스 API를 확장합니다.

 

저는 머신 러닝 엔지니어가 아니지만 머신 러닝 엔지니어와 밀접하게 협력하고 있습니다.
머신 러닝의 라이프사이클과 워크플로우의 몇몇 부분이 유사하다는 것을 알고 있습니다.
물론, 파이프라인 개발과 데이터 파이프라인 같은 것도 할 수 있습니다.
그리고 모델을 훈련시키기 위해 특정 데이터 세트가 필요한 훈련 구성 요소도 있습니다.

 

그리고 모델을 훈련한 후에는 추론 구성 요소가 있습니다.
따라서 이 모델을 라이브 머신러닝 알고리즘에 사용하여 일부 출력을 제공합니다.

 

 

 

이제 Kserve의 주요 구성 요소를 살펴보겠습니다.
물론 하위 계층에는 GPU, CPU와 같은 컴퓨팅 클러스터가 있고, 그 위에 우리가 실행하고 있는 Kubernetes가 있습니다.
그리고 이 선택적 레이어인 Knative와 Istio가 있습니다.
Knative는 오픈소스 커뮤니티 프로젝트입니다.
Kubernetes에 익숙하지 않은 경우, 서버리스 애플리케이션을 배포, 실행 및 관리하기 위한 구성 요소를 추가합니다.
오늘 선택 사항임에도 불구하고 이 부분에 대해 많이 이야기하는 이유는 실제로 Kserve의 사용 사례를 훨씬 더 흥미롭게 만들어준다고 생각하기 때문입니다.
그리고 수정, 제어, 트래픽 관리, 속도 제한과 같은 특정 기능을 통해 할 수 있는 일들이 있습니다.
그러니 앞으로 외계인 같은 것이 튀어나오는 것을 보게 된다면 제가 소개하는 Knative 컴포넌트라는 것을 알아두세요.
선택 사항이지만 있으면 좋겠네요.
또한 Istio는 마이크로서비스의 보안, 연결 및 모니터링에 중점을 둔 오픈소스 프로젝트입니다.
그리고 맨 위에는 Kserve가 있습니다.
앞서 말씀드린 것처럼 Kserve는 많은 일반적인 머신 러닝 프레임워크와 통합되어 있으며, 이에 대해서는 나중에 더 자세히 설명하겠습니다.

 

자, 이제 Kserve의 주요 기능 몇 가지를 소개하겠습니다.
0에서 0까지 스케일 업 및 스케일 다운이 가능합니다.
CPU 또는 GPU에 따라 요청 기반 자동 스케일링을 할 수 있습니다.
원하는 경우 요청 일괄 처리 기능도 제공합니다.
그리고 요청 및 응답 로깅도 가능합니다.
인증 및 권한 부여, 트래픽 관리, 분산 추적, 즉시 사용 가능한 메트릭을 통해 보안을 제공합니다.
다음은 그 중 몇 가지입니다.
그리고 나중에 데모를 통해 카나리아 롤아웃과 같은 롤아웃 전략도 제공할 것입니다.

다음은 Kserve의 주요 기능 중 일부에 불과합니다.
이제 실제로 어떻게 이를 달성할 수 있는지에 대해 이야기해 보겠습니다.

 

 

그럼 예측자에 대해 이야기해 보겠습니다.
앞서 일반 수익률과 같은 예측자에 대해 이야기했지만, 이번에는 KServe가 예측자의 단일 모델 사용 사례를 어떻게 향상시키는지 살펴보겠습니다.
먼저 초기화 컨테이너인 스토리지 이니셜라이저가 있습니다.
그러면 모델 스토리지에 도달합니다.
모델이 어디에 저장되어 있든 KServe에는 모델을 다운로드하고 서빙할 수 있는 여러 옵션이 있습니다.

이제 실행될 다른 두 가지는 Q프록시입니다.
이것은 Knative 구성 요소이므로 선택 사항이지만 최대 동시 요청이 구성된 Kserve 컨테이너로 요청을 라우팅합니다.

따라서 속도 제한을 제공합니다.
추론 서비스의 주요 부분은 앞서 설명한 모델과 모델 서버이며, 기본 제공되는 몇 가지를 쉽게 연결할 수 있을 뿐만 아니라 사용자 정의 모델 서버를 만들 수도 있습니다.

 

다음은 트랜스포머에 대해 이야기해 보겠습니다.
트랜스포머는 앞서 설명한 것처럼 일반적으로 전처리와 후처리에 사용됩니다.
그리고 또 다른 장점은 Kserve  의 Feast 기능 스토어와 같은 기능 보강을 위해 특정 기능을 쉽게 플러그인할 수 있다는 점입니다.
그리고 원한다면 자신만의 커스텀 트랜스포머를 만들 수도 있습니다.

 

 

이제 K Serve가 핵심 추론 컴포넌트를 어떻게 향상시키는지 더 잘 알게 되었으니 이제 컨트롤 플레인에 대해 논의해 보겠습니다.

컨트롤 플레인 슬라이드에서 기억하시겠지만, 컨트롤 플레인은 시스템의 상태를 처리합니다.

추론 서비스는 상태를 정의하며, Kserve 컨트롤러는 이를 조정하는 역할을 담당합니다.

원하는 상태에 도달했는지 확인합니다.

이어서 추론 서비스에 필요한 모든 리소스를 생성합니다.

다음은 Knative 서비스 관리의 리비전, 네트워크 라우팅 및 Knative 리비전 등이 있습니다.

이는 각 리비전을 직접 처리한 뒤 배포하는 것과 같습니다.

예를 들어, Knative가 없다면 왼쪽의 두 가지 옵션 없이 직접 배포만 가능하지만, 추가된 몇 가지 기능을 사용할 수 없습니다.

트래픽 흐름을 관찰하고 복제본을 확장하는 것을 넘어, 복제본을 관리하고 확장 및 축소를 처리하는 Knative 포드 오토스케일러 또는 수평 오토스케일러를 연결할 수 있습니다.

이에 따라 트랜스포머 파드와 예측자 파드 등이 생성됩니다.

이것은 방금 경험한 내용에 대한 높은 수준의 개요입니다.

다시 모델 스토리지가 나타납니다.

앞서 언급했듯이, Kserve에서 지원하는 모델 스토리지 유형에는 S3, URI, Azure, 퍼시스턴트 볼륨 클레임 등이 있습니다.

다음 버전에서는 더 많은 기능이 추가될 예정입니다.

더 많은 옵션이 추가되었습니다.

 

이것은 방금 설명한 내용을 더 광범위하게 보여주는 것과 같습니다.

그리고 이것을 좋아하는 이유는 Kubedl Tree라는 커맨드 라인 도구를 사용하기 때문인데, 각 상자의 내용을 자세히 들여다보지는 않겠지만, 분홍색은 istio, 진한 파란색은 API가 Kserve, 그리고 회색은 API가 Knative를 의미하는 것이 정말 유용하다고 생각합니다.

각 리소스에 대한 자세한 설명은 하지 않겠지만, 특히 생성되는 모든 리소스를 파악하는 것이 도움이 될 것 같습니다.
그런 다음 각 리소스를 설명하거나 살펴보고 설정이 무엇인지 확인할 수 있습니다.
Kserve가 어떻게 작동하는지 이해하는 데 매우 유용하다고 생각했습니다.

 

자, 이제 컨트롤 플레인에 대해 논의했으므로 데이터 플레인에 대해 조금 이야기해 보겠습니다.
이제 퀘스트 경로를 따라가 봅시다.

인공지능 애플리케이션을 만들었습니다.
트랜스포머 서비스에 접속합니다.

그리고 변압기 포드에 도달합니다.
이제 준비가 되었습니다.

Q프록시를 호출하고, 트랜스포머 포드를 호출한 다음, 전처리를 수행하고, 예측 서비스에 연결한 다음, 예측 포드에 연결하고, 그 다음 Q프록시를 호출하여 모델을 실행합니다.

추론이 수행될 것입니다.

자, 이것이 데이터 플레인입니다.

 

이제 방금 추론 그래프를 추가한 흥미로운 부분에 대해 이야기해 보겠습니다.

따라서 추론 서비스는 KServe를 통해 체인 파이프라인으로 구성할 수 있으며, 이는 매우 멋지고 유용합니다.

이 새로운 기능을 통해 다양한 방식으로 체인을 형성할 수 있습니다.

KServe 기여자들이 정말 열심히 작업했습니다.

그래서 여러분이 사용할 수 있는 몇 가지 모드를 소개하겠습니다.

시퀀스 노드를 사용하면 시퀀스에서 두 개의 추론 서비스를 연결할 수 있습니다.

스위치 노드라는 모드를 사용하면 사용자가 조건에 따라 요청을 처리할 추론 서비스를 선택할 수 있습니다.

스플리터 노드는 사용자가 가중치 분포를 사용하여 여러 추론 서비스 간에 트래픽을 분배할 수 있게 합니다.

또한 앙상블 노드를 사용하여 사용자가 여러 모델에 요청을 동시에 라우팅할 수 있습니다.

새롭게 추가된 몇 가지 기능을 소개했습니다.

네, 흥미롭습니다.

 

Kserve의 또 다른 중요한 특징은 모든 서빙 런타임에서 표준화된 추론 프로토콜을 사용한다는 점으로, 이로 인해 추론 서비스와의 대화 방식을 변경할 필요 없이 TensorFlow에서 PyTorch로 쉽게 전환할 수 있습니다.

따라서 사용자는 테스트와 벤치마킹을 매우 쉽게 할 수 있습니다.

사용자는 필요에 따라 모델을 전환하여 사용할 수 있다는 것이 매우 좋습니다.

여기에 귀여운 애니메이션이 있네요.

안녕하세요, KServe 표준 추론 프로토콜을 보시죠? 그리고 건강 서버 모델 메타데이터와 추론을 위한 표준 엔드포인트가 있다고 말합니다.

그는 이렇게 말했습니다, 좋아요, 어떻게 대화할 수 있을까요? Http 또는 GRPC가 KServe 가 지원하는 것이니까요.

 

자, 여기에 데이터 플레인 플러그인이 몇 가지 있습니다.

앞서 말했듯이, 핵심 추론 부분에는 트랜스포머와 예측자가 있습니다.

하지만 때로는 여기에 몇 가지 구성 요소와 플러그인을 추가해야 설명 작업을 수행할 수 있습니다.

따라서 이 예제에서는 예측 지점을 선택하는 대신 설명을 선택하고 예측을 선택한 다음 여러 설명자를 사용할 수 있습니다.

기본적으로 제 이해에 따르면, 설명자는 '내 모델이 특정 인스턴스에 대해 왜 이런 예측을 했는가'라고 말하는 것입니다. 따라서 이미지가 있고 그 이미지를 개로 정의하면 이미지의 어떤 부분이 그 결과를 만드는 데 가장 관련이 있는지 설명합니다.

그게 바로 여러분이 가질 수 있는 한 가지입니다.

배처는 Q프록시와 KServe 컨테이너 사이에 위치한 사이드카입니다.

최대 지연 시간 및 최대 배치 크기 등을 설정할 수 있습니다.

모니터 및 로거 플러그인도 추가할 수 있습니다.

따라서 비동기 페이로드 로깅을 통해 들어오는 요청의 분포를 모니터링할 수 있습니다.

다음 슬라이드에서는 몇 가지 디텍터에 대해 설명하겠습니다.

알림을 연결할 수도 있고, 사진을 찍는 사람들도 볼 수 있습니다.

나중에 참고하고 싶으시다면, 이 내용을 업로드해두었으니 확인하세요.

참고하고 싶으시다면, 사이트에 올려두었습니다.

 

이제 모니터와 로거의 작동 방식에 대해 잠깐 이야기해 보겠습니다.

브로커는 이벤트를 소비자에게 라우팅합니다.

따라서 이벤트를 메시지 덤퍼 서비스로 전달하는 트리거를 가질 수 있습니다.

그리고 클라우드 이벤트나 Knative와 같은 트리거에 따라 메트릭을 덤프하도록 비동기 페이로드 로깅을 설정할 수 있습니다.

그리고 모델을 신뢰하기 위해 탐지기로 들어오는 요청을 모니터링할 수 있습니다.

즉, 탐지기는 수신 요청의 분포가 학습 데이터의 참조 분포와 다른지 확인합니다.

예를 들어, 이상치 탐지기는 분포에서 벗어난 단일 인스턴스에 플래그를 지정하며, 편향 탐지기, 악의적으로 수정된 입력에 대한 적대적 탐지기와 같은 것을 가질 수 있습니다.

이 모든 것을 통해 알림을 연결하여 추론 서비스에 대한 우수한 관찰 가능성을 확보할 수 있습니다.

 

자, 몇 가지 모델 서비스 런타임에 대해 조금 논의했지만 여러 가지가 있으며, KServe는 계속해서 더 많은 지원을 추가하고 있어 즉시 사용할 수 있습니다.

예를 들어, 트라이던트 추론 서버, Torch 서버, sklearn, XGBoost를 사용할 수 있으며, TensorFlow, Torch Script, PyTorch, ONNX 및 XGBoost와 함께 사용할 수 있습니다.

따라서 많은 옵션이 있고 더 많은 옵션이 제공되고 있어, 데이터 사이언티스트는 서빙 런타임을 연결하기만 하면 추론 서비스를 매우 쉽게 시작할 수 있습니다.

 

그럼 실제로 어떻게 보일까요? 원하는 경우 서빙 런타임을 정의할 수 있습니다.

YAML에서 모델 형식을 정의할 수 있습니다.

이것은 매우 기본적인 인퍼런스 서비스와 같습니다.

이것이 YAML의 모습입니다.

예를 들어, SK라는 sklearn 모델을 사용하고 있다고 정의할 수 있습니다.

그리고 여기서부터 새로운 형식인 V2 형식에서 KServe는 사용자가 실행 중인 서빙 런타임의 모델을 유추할 수 있습니다.

정의할 필요는 없지만 원한다면 정의할 수 있습니다.

그러면 이게 무슨 일을 할까요? 서빙 런타임이라는 커스텀 리소스를 생성합니다.

오른쪽에 생성된 커스텀 리소스를 볼 수 있습니다.

이렇게 하면 사용자가 직접 설정할 필요 없이 자동으로 생성되므로 원하는 대로 구성할 수 있습니다.

 

자, 지금까지 설명한 단일 모델 서빙에 대해 이야기해 보겠습니다.

기본적으로 각 파드에는 하나의 모델이 있습니다. 따라서 안전을 위해 각 파드의 복제본이 하나 이상 실행 중일 것입니다.

만약 모델이 5개라면 어떻게 될까요? 적어도 10개의 파드가 실행 중이지만 변압기도 있을 것입니다.

그리고 각 복제본마다 다른 복제본이 하나씩 있을 것입니다.

따라서 각 모델마다 적어도 4개의 파드가 실행 중일 것입니다.

보시다시피, 이것은 아마도 5개의 모델에 대해 괜찮을 것입니다.

모델이 100개나 1000개라면 어떻게 될까요? 당연히 확장성이 떨어지고 비용이 많이 들겠죠.

그래서 쿠버네티스에는 클러스터당 최대 파드 제한도 있습니다.

따라서 110, 100과 같은 베스트 프랙티스가 있습니다.

또한 IP 주소 제한이 있어 최대 4096개까지만 사용할 수 있습니다.

따라서 이 사용 사례에서 한 번에 실행되는 모델은 약 1024개입니다.

 

 

우리가 더 잘할 수 있는 것이 있다면, 바로 멀티모델 서빙입니다.

멀티모델 서빙은 방금 설명한 케이스의 서버가 직면할 세 가지 유형의 제한을 해결하기 위해 설계되었습니다.

컴퓨팅 리소스 제한, 파드당 하나의 모델만 실행할 수 있는 오버헤드, 최대 파드 제한, 최대 IP 주소 제한 등이 있습니다.

하지만 이 구조조차도 하나의 단일 서빙 런타임에 여러 모델을 실행할 수 있는 제한이 있습니다.

이 구조의 경우 각 복제본은 동일한 모델 세트를 가지고 있어야 합니다.

이해하셨죠?

CBA와 BCD, 각 파드에는 몇 개의 모델만 있을 수 있으며, 그것들을 정의해야 합니다.

따라서 이 경우에도 대규모로 실행을 시작하고 모델이 많으면 여전히 몇 가지 제한 사항에 직면하게 됩니다.

하지만 걱정하지 마세요. 저희 기여자들이 대용량, 고밀도 사용 사례를 위한 더 나은 솔루션을 찾기 위해 매우 열심히 노력하고 있습니다.

 

그리고 우리는 이를 모델 메시를 사용한 멀티모델 서빙이라고 부릅니다.

알겠죠? 따라서 많은 수의 모델이 배포되어 있다고 가정해 보겠습니다.

이 사용 사례의 예로 뉴스 분류 서비스를 들 수 있습니다.

모든 유형의 뉴스 카테고리에 대한 모델이 있을 수 있으며, 개인정보 보호 및 보안상의 이유로 사용자 수준에서 모델을 훈련해야 할 수도 있습니다.

많은 작은 실행 모델이 있네요.

따라서 이 사용 사례에서 많은 모델을 사용하면 더 정확하고 좋은 결과를 얻을 수 있습니다.

하지만 이 정도 규모의 추론 서비스를 Kubernetes 클러스터에서 실행할 때 방금 논의한 많은 문제에 직면하게 될 것입니다.

또 다른 사용 사례로 신경망 기반 모델이 GPU에 가장 적합하다고 가정해 보겠습니다. 하지만 GPU는 일반적으로 비싸며 이러한 모델을 많이 실행하는 데는 많은 비용이 듭니다.

따라서 여기서 설명할 모델 메시를 사용하는 것이 일반적으로 좋은 옵션입니다.

모델 메시를 사용한 멀티모델 서빙은 이 문제에 대한 해결책이며, 추론 서비스를 확장할 수 있어 모델당 평균 리소스 오버헤드가 감소하여 비용 효율성이 높아집니다.

그리고 클러스터에 배포할 수 있는 모델 수는 더 이상 최대 파드 제한과 IP 주소 제한에 의해 제한되지 않습니다.

그렇다면 이것은 무엇을 의미할까요? 기본적으로 요청을 라우팅하는 메시가 있고, 스토리지 초기화를 대체하는 풀러가 있습니다.

스토리지 이니셜라이저에는 니트 컨테이너가 와서 모델을 가져온 다음 떠나는 기능이 있습니다.

이제 우리는 필요에 따라 지속적으로 모델을 가져오는 롱런 사이드카인 풀러를 가질 수 있습니다.

 

아주 간단한 사용 사례입니다.

물론 복제본은 하나 이상 더 있을 것입니다.

이것은 서로 다른 파드에서 여러 모델을 실행하거나 동일한 서빙 런타임의 서로 다른 레플리카를 가질 수 있다는 것을 보여줍니다.

따라서 모델 서버 X와 왼쪽 파드는 모델 A, B 또는 C를 가질 수 있으며,

오른쪽 파드는 모델 서버 X에서 실행되는 다른 수의 모델을 가질 수 있습니다.

알겠죠? 이제 간단하거나 매우 짧은 데모가 있습니다.

 

어디 보자, 이것은 추론 서비스를 설정하는 예시입니다.

이것은 추론 서비스를 설정하는 방법에 대한 주요 예시 중 하나입니다.

네, 저는 CaseServe Context라는 네임스페이스를 만든 다음 방금 보여드린 것과 매우 유사한 추론 서비스를 위해 Sklearn YAML 중 하나를 설정했습니다.

문제를 일으키고 싶지 않았기 때문에 이미 적용해 두었거나, 문제가 생길 때까지 기다렸다가 이미 실행 중이라는 것을 보여줍니다.

그리고 여기서는 다른 리소스를 확인하고 있습니다.

이것이 추론 서비스 리소스입니다.

준비된 것을 볼 수 있습니다.

True.

최신은 트래픽의 100%가 그곳으로 가고 있다는 것을 의미합니다.

포트 포워딩을 하고 예측 결과를 얻기 위해 예측자에게 요청을 보내려고 인그레스 게이트웨이를 설정하고 있습니다.

좋아요, 포트 포워딩을 하고 인그레스 포트를 설정했습니다.

여기에 제 입력이 있습니다.

추론 서비스에 제출할 아주 간단한 입력입니다.

이제 curl을 사용하면 예측 아래에 답변이 표시됩니다.

다음으로 보여드리는 것은 KServe의 기능 중 하나인 카나리아 롤아웃을 사용하는 간단한 예제입니다.

이제 카나리아 트래픽 퍼센티지를 10으로 추가하겠습니다.

YAML에 주석을 달았으니 이제 적용하겠습니다.

이제 구성이 완료되었습니다.

따라서 트래픽의 10%가 새 버전으로 라우팅되고 90%는 이전 버전에 남는다는 것을 알 수 있습니다.

이제 확인해보니 이전 버전에서 90%, 최신 버전에서 10%의 트래픽이 준비된 것을 볼 수 있습니다.

그리고 이를 제거하면 이 버전을 100% 트래픽으로 승격할 수 있고, 시간 때문에 이 버전을 승격할 수 있습니다.

오, 그래요.

좋아요, 이제 괜찮아요.

자, 작은 데모가 있었는데 정말 빠르게 멋진 새 기능이 많이 나옵니다.

 

시간이 많지 않아서 이 정도만 말씀드릴게요, 웹사이트에 가시면 이 모든 기능들을 보실 수 있고, KSErve에도 나열되어 있는 기능들이 있으니 꼭 확인해보세요.

이 작업을 위해 애써주신 모든 분들께 축하드립니다.

많은 사람들이 많은 노력을 기울인 것을 알고 있으며, Kserve 기여자 덕분에 이 커뮤니티에 참여할 수 있는 훌륭한 커뮤니티가 되었습니다.

 

가입한 것이 정말 좋았고 즐거운 시간을 보내고 있습니다.

 

네, 여기 블룸버그가 참여할 다른 대화도 있습니다.

 

관심이 있으시다면 여기 커리어 페이지 링크도 있습니다.

KServe에 대해 배우기 위한 여정에 함께 해주셔서 감사합니다.

이제 알렉사에게 질문할 게 있나요? 여기 하나.

마이크를 넘겨드릴게요.

블룸버그에서 AI는 어떤 용도로 사용하나요? 자산 가격 예측, 뉴스 분석, 아니면 이런 핫한 것들인가요? 네.

질문은 블룸버그에서 AI를 어떤 용도로 사용하느냐는 것이었습니다. 블룸버그는 금융 서비스 회사로서 뉴스와 같은 많은 일에 AI를 사용합니다.

뉴스가 하나의 사용 사례입니다.

네, 금융 모델이 많죠.

셀던 코어와 KF 서빙 또는 케이서빙을 사용하는 것의 차이점에 대해 다시 한 번 설명해 주시겠어요? 셀던 코어입니다.

셀던 코어 알죠?

쿠버네티스 API를 사용하여 배포 및 AI 모델을 실행할 수도 있습니다.

Okay.

그래.

그래서 질문은 셀던 코어와 Kserve의 차이점이 무엇인가요? 거의 없습니다.

셀던 코어.

Okay.

죄송합니다.

드물게 코어와 Kserve.

좋은 질문이네요.

좋은 답변을 드릴 수 있도록 오프라인으로 전환하는 게 어떨까요? 안녕하세요, 대화 고마워요.

그런데 메시와 관련하여 말씀하신 멀티모달 사용 사례에 대해 질문이 있습니다.

이 경우 요청이 들어올 때마다 런타임에 모델을 가져오는 건가요, 아니면 요청이 들어오는 순간에 가져오는 건가요, 아니면 어떻게 작동하나요? 그렇게 보이거든요.

알겠어요.

이니셜라이저가 풀러 같은 것으로 대체된다고 하셨죠?

파드가 올라갈 때 또는 예측을 위해 API 요청이 들어올 때 그런 일이 발생하나요? 네.

모델 메시에서 스토리지 이니셜라이저와 풀러의 차이점에 대한 질문이었습니다.

모델 메시에서 스토리지 이니셜라이저는 오래 실행되는 사이드카인 풀러로 대체되어 해당 모델을 치는 동안 필요에 따라 모델을 끌어올 수 있습니다.

네.

안녕.

트랜스포머에 대해 말씀해 주셨는데, 제가 최근에 탐구하고 있던 것이 그래프 자체에 전처리 단계를 추가하는 것이었습니다.

Kserve에서도 가능한가요? 죄송하지만 전처리 단계를 무엇에 추가 할 수 있습니까? 모델 자체에 전처리 단계를 추가하는 것입니다.

텐서플로우 변환 같은 거요.

Kserve로도 가능한가요? 조금 더 자세히 설명해 주시겠어요? 네.

Kserve를 사용하면 트랜스포머에서 사전 및 사후 처리를 할 수 있습니다.

기본 제공되는 것 중 일부를 사용할 수도 있고, 직접 사용자 정의할 수도 있습니다.

프리 프로세서에 사용할 수 있는 몇 가지 옵션이 있습니다.

강연해줘서 고마워요.

0에 대한 스케일링에 대해 얘기했군요.

그래.

꼭 저걸 사용해야 하나요? 예를 들어, 모두가 항상 가동하기를 원하는 애플리케이션이 있거나 미션 크리티컬한 애플리케이션인 경우 어떨까요? 설정이 가능한가요, 아니면 반드시 그렇게 해야 하나요? 네, 물론이죠.

스케일을 0으로 설정하는 것은 구성할 수 있습니다.

리소스를 절약하고 싶을 때도 있지만, 다른 미션 크리티컬한 작업의 경우에는 그렇지 않을 수도 있고, 다운되었을 때 파드가 시작되는 지연 시간을 감당할 수 없는 경우도 있습니다.

이러한 사용 사례의 경우, 스칼라 제로나 항상 가동되던 것을 사용하고 싶지 않을 것입니다.