모델 제공
Red Hat OpenShift AI Self-Managed 모델 제공
초록
1장. 모델 서비스 정보 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift AI에서 숙련된 모델을 제공하면 OpenShift 클러스터에 모델을 배포하여 이를 테스트하고 지능형 애플리케이션에 통합할 수 있습니다. 모델을 배포하면 API를 사용하여 액세스할 수 있는 서비스로 사용할 수 있습니다. 이를 통해 API 호출을 통해 제공하는 데이터 입력을 기반으로 예측 사항을 반환할 수 있습니다. 이 프로세스를 모델 유추라고 합니다. OpenShift AI에서 모델을 제공할 때 배포된 모델에 액세스할 수 있는 유추 엔드포인트가 대시보드에 표시됩니다.
OpenShift AI는 다음과 같은 모델 서비스 플랫폼을 제공합니다.
- 단일 모델 제공 플랫폼
- 대용량 언어 모델(LLM)과 같은 대규모 모델을 배포하기 위해 OpenShift AI에는 KServe 구성 요소를 기반으로 하는 단일 모델 제공 플랫폼이 포함되어 있습니다. 각 모델은 자체 모델 서버에서 배포되므로 단일 모델 제공 플랫폼은 증가된 리소스가 필요한 대규모 모델을 배포, 모니터링, 확장 및 유지 관리하는 데 도움이 됩니다.
- 다중 모델 서비스 플랫폼
- 소규모 및 중간 규모의 모델을 배포하기 위해 OpenShift AI에는 ModelMesh 구성 요소를 기반으로 하는 다중 모델 제공 플랫폼이 포함되어 있습니다. 다중 모델 제공 플랫폼에서는 동일한 모델 서버에 여러 모델을 배포할 수 있습니다. 배포된 각 모델은 서버 리소스를 공유합니다. 이러한 접근 방식은 제한된 컴퓨팅 리소스 또는 포드가 있는 OpenShift 클러스터에서 유용할 수 있습니다.
2장. 소규모 및 중간 규모의 모델 제공 링크 복사링크가 클립보드에 복사되었습니다!
소규모 및 중간 규모의 모델을 배포하기 위해 OpenShift AI에는 ModelMesh 구성 요소를 기반으로 하는 다중 모델 제공 플랫폼이 포함되어 있습니다. 다중 모델 제공 플랫폼에서 동일한 모델 서버에서 여러 모델을 배포하고 서버 리소스를 공유할 수 있습니다.
2.1. 모델 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
2.1.1. 다중 모델 서비스 플랫폼 활성화 링크 복사링크가 클립보드에 복사되었습니다!
다중 모델 서비스 플랫폼을 사용하려면 먼저 플랫폼을 활성화해야 합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 클러스터 관리자가 ModelMesh 구성 요소를 사용하는 다중 모델 제공 플랫폼을 선택하는 기능을 비활성화하도록 OpenShift AI 대시보드 구성을 편집 하지 않았습니다. 자세한 내용은 대시보드 구성 옵션을 참조하십시오.
프로세스
- OpenShift AI 대시보드의 왼쪽 메뉴에서 설정 → 클러스터 설정을 클릭합니다.
- 모델 제공 플랫폼 섹션을 찾습니다.
- Multi-model serving platform 확인란을 선택합니다.
- 변경 사항 저장을 클릭합니다.
2.1.2. 다중 모델 서비스 플랫폼에 대한 사용자 정의 모델 서비스 런타임 추가 링크 복사링크가 클립보드에 복사되었습니다!
모델 서비스 런타임은 지정된 모델 프레임워크 세트 및 해당 프레임워크에서 지원하는 모델 형식에 대한 지원을 추가합니다. 기본적으로 다중 모델 제공 플랫폼에는 OpenVINO 모델 서버 런타임이 포함됩니다. 기본 런타임이 특정 모델 형식 지원 등 요구 사항을 충족하지 않는 경우 자체 사용자 지정 런타임을 추가할 수도 있습니다.
관리자는 Red Hat OpenShift AI 대시보드를 사용하여 사용자 지정 모델 제공 런타임을 추가하고 활성화할 수 있습니다. 그런 다음 다중 모델 제공 플랫폼에 대한 새 모델 서버를 만들 때 사용자 지정 런타임을 선택할 수 있습니다.
Red Hat은 사용자 지정 런타임을 지원하지 않습니다. 사용자가 추가한 모든 사용자 지정 런타임을 사용하고 올바르게 구성 및 유지 관리를 수행할 수 있는지 확인해야 합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 프로젝트에 모델 서버를 추가하는 방법에 대해 잘 알고 있습니다. 사용자 지정 model-serving 런타임을 추가한 경우 런타임을 사용하도록 새 모델 서버를 구성해야 합니다.
kserve/modelmesh-serving 리포지토리에서 예제 런타임을 검토했습니다. 이러한 예제를 시작점으로 사용할 수 있습니다. 그러나 OpenShift AI에 배포하려면 각 런타임에 몇 가지 추가 수정이 필요합니다. 필요한 수정 사항은 다음 절차에 설명되어 있습니다.
참고OpenShift AI에는 기본적으로 OpenVINO 모델 서버 런타임이 포함되어 있습니다. 이 런타임을 OpenShift AI에 추가할 필요가 없습니다.
프로세스
OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.
Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.
사용자 지정 런타임을 추가하려면 다음 옵션 중 하나를 선택합니다.
- 기존 런타임(예: OpenVINO 모델 서버 런타임)으로 시작하려면 기존 런타임 옆에 있는 작업 메뉴( Cryostat)를 클릭한 다음 중복 을 클릭합니다.
- 새 사용자 지정 런타임을 추가하려면 제공 런타임 추가 를 클릭합니다.
Select the model serving platforms this runtime supports list, select Multi-model serving platform.
참고다중 모델 제공 플랫폼은 REST 프로토콜만 지원합니다. 따라서 이 런타임에서 지원하는 API 프로토콜 선택에서 기본값을 변경할 수 없습니다.
선택 사항: 새 런타임을 시작한 경우(기존 런타임을 복제하지 않고) 다음 옵션 중 하나를 선택하여 코드를 추가합니다.
YAML 파일 업로드
- 파일 업로드 를 클릭합니다.
파일 브라우저에서 컴퓨터에서 YAML 파일을 선택합니다. 이 파일은 kserve/modelmesh-serving 리포지토리에서 다운로드한 예제 런타임 중 하나일 수 있습니다.
포함된 YAML 편집기가 열리고 업로드한 파일의 내용이 표시됩니다.
편집기에서 직접 YAML 코드를 입력합니다.
- 처음부터 시작을 클릭합니다.
- 포함된 편집기에서 YAML 코드를 직접 입력하거나 붙여넣습니다. 생성하는 YAML은 kserve/modelmesh-serving 리포지토리의 예제 런타임 중 하나에서 복사할 수 있습니다.
선택 사항: kserve/modelmesh-serving 리포지토리에 예제 런타임 중 하나를 추가하는 경우 다음 수정을 수행합니다.
-
YAML 편집기에서 런타임의
kind필드를 찾습니다. 이 필드의 값을ServingRuntime으로 업데이트합니다. -
kserve/modelmesh-serving 리포지토리의 kustomization.yaml 파일에서 추가할 런타임의
newName및newTag값을 기록해 둡니다. 이후 단계에서 이러한 값을 지정합니다. -
사용자 지정 런타임의 YAML 편집기에서
containers.image필드를 찾습니다. kustomization.yaml 파일에 명시된 값에 따라
newName:newTag형식의containers.image필드 값을 업데이트합니다. 몇 가지 예가 표시되어 있습니다.- NVIDIA Triton Inference Server
-
image: nvcr.io/nvidia/tritonserver:23.04-py3 - Seldon Python MLServer
-
이미지: seldonio/mlserver:1.3.2 - TorchServe
-
이미지: pytorch/torchserve:0.7.1-cpu
-
YAML 편집기에서 런타임의
-
metadata.name필드에서 추가하는 런타임 값이 고유해야 합니다(즉, 값이 이미 추가한 런타임과 일치하지 않음). 선택 사항: 추가하는 런타임에 사용자 정의 표시 이름을 구성하려면
metadata.annotations.openshift.io/display-name필드를 추가하고 다음 예와 같이 값을 지정합니다.apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: mlserver-0.x annotations: openshift.io/display-name: MLServer참고런타임에 대한 사용자 정의 표시 이름을 구성하지 않으면 OpenShift AI에
metadata.name필드의 값이 표시됩니다.추가를 클릭합니다.
Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 런타임이 자동으로 활성화되어 있는지 확인합니다.
- 선택 사항: 사용자 지정 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
검증
- 추가한 사용자 정의 모델 제공 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.
2.1.3. 다중 모델 서비스 플랫폼에 대해 테스트 및 검증된 모델 제공 런타임 추가 링크 복사링크가 클립보드에 복사되었습니다!
사전 설치되어 사용자 지정 모델 제공 런타임 외에도 Red Hat 테스트 및 검증된 모델 제공 런타임(예: NVIDIA Triton Inference Server )을 사용하여 요구 사항을 지원할 수도 있습니다. Red Hat 테스트 및 검증된 런타임에 대한 자세한 내용은 Red Hat OpenShift AI에 대한 테스트 및 검증된 런타임을 참조하십시오.
Red Hat OpenShift AI 대시보드를 사용하여 NVIDIA Triton 유추 서버 런타임을 추가 및 활성화한 다음 다중 모델 서비스 플랫폼에 대한 새 모델 서버를 생성할 때 런타임을 선택할 수 있습니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 프로젝트에 모델 서버를 추가하는 방법에 대해 잘 알고 있습니다. 테스트 및 검증된 모델 서비스 런타임을 추가한 후에는 런타임을 사용하도록 새 모델 서버를 구성해야 합니다.
프로세스
OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.
Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.
- 테스트 및 검증된 런타임을 추가하려면 Add serving runtime 을 클릭합니다.
Select the model serving platforms this runtime supports list, select Multi-model serving platform.
참고다중 모델 제공 플랫폼은 REST 프로토콜만 지원합니다. 따라서 이 런타임에서 지원하는 API 프로토콜 선택에서 기본값을 변경할 수 없습니다.
- 처음부터 시작을 클릭합니다.
포함된 편집기에 다음 YAML 코드를 직접 입력하거나 붙여넣습니다.
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: annotations: enable-route: "true" name: modelmesh-triton labels: opendatahub.io/dashboard: "true" spec: annotations: opendatahub.io/modelServingSupport: '["multi"x`x`]' prometheus.kserve.io/path: /metrics prometheus.kserve.io/port: "8002" builtInAdapter: env: - name: CONTAINER_MEM_REQ_BYTES value: "268435456" - name: USE_EMBEDDED_PULLER value: "true" memBufferBytes: 134217728 modelLoadingTimeoutMillis: 90000 runtimeManagementPort: 8001 serverType: triton containers: - args: - -c - 'mkdir -p /models/_triton_models; chmod 777 /models/_triton_models; exec tritonserver "--model-repository=/models/_triton_models" "--model-control-mode=explicit" "--strict-model-config=false" "--strict-readiness=false" "--allow-http=true" "--allow-grpc=true" ' command: - /bin/sh image: nvcr.io/nvidia/tritonserver@sha256:xxxxx name: triton resources: limits: cpu: "1" memory: 2Gi requests: cpu: "1" memory: 2Gi grpcDataEndpoint: port:8001 grpcEndpoint: port:8085 multiModel: true protocolVersions: - grpc-v2 - v2 supportedModelFormats: - autoSelect: true name: onnx version: "1" - autoSelect: true name: pytorch version: "1" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: tensorrt version: "7" - autoSelect: false name: xgboost version: "1" - autoSelect: true name: python version: "1"-
metadata.name필드에서 추가하는 런타임 값이 이미 추가한 런타임 값과 일치하지 않는지 확인합니다. 선택 사항: 추가하는 런타임에 사용자 정의 표시 이름을 사용하려면
metadata.annotations.openshift.io/display-name필드를 추가하고 다음 예와 같이 값을 지정합니다.apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: modelmesh-triton annotations: openshift.io/display-name: Triton ServingRuntime참고런타임에 대한 사용자 정의 표시 이름을 구성하지 않으면 OpenShift AI에
metadata.name필드의 값이 표시됩니다.생성을 클릭합니다.
Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 런타임이 자동으로 활성화되어 있는지 확인합니다.
- 선택 사항: 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
검증
- 추가한 model-serving 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.
2.1.4. 다중 모델 서비스 플랫폼용 모델 서버 추가 링크 복사링크가 클립보드에 복사되었습니다!
다중 모델 제공 플랫폼을 활성화한 경우 모델을 배포하도록 모델 서버를 구성해야 합니다. 대규모 데이터 집합과 함께 사용할 추가 컴퓨팅 성능이 필요한 경우 모델 서버에 가속기를 할당할 수 있습니다.
OpenShift AI 2.16에서 Red Hat은 모델 제공을 위해 NVIDIA 및 AMD GPU 액셀러레이터만 지원합니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 모델 서버를 추가할 수 있는 데이터 사이언스 프로젝트를 생성했습니다.
- 다중 모델 서비스 플랫폼을 활성화했습니다.
- 모델 서버에 사용자 지정 model-serving 런타임을 사용하려면 런타임을 추가하고 활성화했습니다. 사용자 지정 model-serving 런타임 추가 를 참조하십시오.
- 모델 서버에서 GPU(그래픽 처리 장치)를 사용하려는 경우 OpenShift AI에서 GPU 지원을 활성화했습니다. NVIDIA GPU를 사용하는 경우 NVIDIA GPU 활성화를 참조하십시오. AMD GPU를 사용하는 경우 AMD GPU 통합을 참조하십시오.
프로세스
OpenShift AI 대시보드의 왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
모델 서버를 구성할 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
다음 작업 중 하나를 수행합니다.
- 플랫폼 타일을 제공하는 다중 모델이 표시되면 타일에서 모델 서버 추가 를 클릭합니다.
- 타일이 표시되지 않으면 모델 서버 추가 버튼을 클릭합니다.
모델 서버 추가 대화 상자가 열립니다.
- 모델 서버 이름 필드에 모델 서버의 고유 이름을 입력합니다.
Serving 런타임 목록에서 OpenShift AI 배포에 설치 및 활성화된 모델 서비스 런타임을 선택합니다.
참고모델 서버와 함께 사용자 지정 모델 서비스 런타임을 사용하고 GPU를 사용하려면 사용자 지정 런타임에서 GPU를 지원하고 이를 사용하도록 적절히 구성되어 있는지 확인해야 합니다.
- 배포할 모델 복제본 수 에서 값을 지정합니다.
- 모델 서버 크기 목록에서 값을 선택합니다.From the Model server size list, select a value.
선택 사항: 이전 단계에서 Custom 을 선택한 경우 모델 서버 크기 섹션에서 다음 설정을 구성하여 모델 서버 를 사용자 지정합니다.
- CPU 요청 필드에서 모델 서버와 함께 사용할 CPU 수를 지정합니다. 이 필드 옆에 있는 목록을 사용하여 코어 또는 밀리코어에 값을 지정합니다.
- CPU 제한 필드에서 모델 서버에 사용할 최대 CPU 수를 지정합니다. 이 필드 옆에 있는 목록을 사용하여 코어 또는 밀리코어에 값을 지정합니다.
- 메모리 요청 필드에서 모델 서버의 요청된 메모리를 기비바이트(Gi)로 지정합니다.
- 메모리 제한 필드에서 모델 서버의 최대 메모리 제한을 기가바이트(Gi)로 지정합니다.
선택 사항: 액셀러레이터 목록에서 가속기를 선택합니다.
- 이전 단계에서 가속기를 선택한 경우 사용할 가속기 수를 지정합니다.
- 선택 사항: 모델 경로 섹션에서 외부 경로 확인란을 통해 사용 가능한 배포된 모델 만들기 확인란을 선택하여 배포된 모델을 외부 클라이언트에서 사용할 수 있도록 합니다.
선택 사항: 토큰 권한 부여 섹션에서 모델 서버에 대한 토큰 인증 필요 확인란을 선택합니다. 토큰 인증 구성을 완료하려면 다음 작업을 수행합니다.
- 서비스 계정 이름 필드에 토큰이 생성될 서비스 계정 이름을 입력합니다. 모델 서버가 구성되면 생성된 토큰이 토큰 시크릿 필드에 생성되고 표시됩니다.
- 추가 서비스 계정을 추가하려면 서비스 계정 추가를 클릭하고 다른 서비스 계정 이름을 입력합니다.
추가를 클릭합니다.
- 구성한 모델 서버는 모델 및 모델 서버 목록에 프로젝트의 모델 탭에 나타납니다.
- 선택 사항: 모델 서버를 업데이트하려면 모델 서버 옆에 있는 작업 메뉴( Cryostat )를 클릭하고 모델 서버 편집을 선택합니다.
2.1.5. 모델 서버 삭제 링크 복사링크가 클립보드에 복사되었습니다!
모델을 호스팅하는 모델 서버가 더 이상 필요하지 않으면 데이터 사이언스 프로젝트에서 제거할 수 있습니다.
모델 서버를 제거하면 해당 모델 서버에서 호스팅되는 모델도 제거됩니다. 따라서 애플리케이션에서 더 이상 모델을 사용할 수 없습니다.
사전 요구 사항
- 데이터 사이언스 프로젝트 및 관련 모델 서버를 생성했습니다.
- 모델을 더 이상 사용할 수 없는 모델에 액세스하는 애플리케이션에 대한 알림을 받았습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다.
프로세스
OpenShift AI 대시보드에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
모델 서버를 삭제할 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
삭제할프로젝트 옆에 있는 작업 메뉴( Cryostat )를 클릭한 다음 모델 서버 삭제 를 클릭합니다.
모델 서버 삭제 대화 상자가 열립니다.
- 텍스트 필드에 모델 서버의 이름을 입력하여 삭제하려는지 확인합니다.
- 모델 서버 삭제를 클릭합니다.
검증
- 삭제한 모델 서버는 더 이상 프로젝트의 모델 탭에 표시되지 않습니다.
2.2. 배포된 모델 작업 링크 복사링크가 클립보드에 복사되었습니다!
2.2.1. 다중 모델 서비스 플랫폼을 사용하여 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift AI에 숙련된 모델을 배포하여 지능형 애플리케이션에 테스트하고 구현할 수 있습니다. 모델을 배포하면 API를 사용하여 액세스할 수 있는 서비스로 사용할 수 있습니다. 이를 통해 데이터 입력을 기반으로 예측을 반환할 수 있습니다.
다중 모델 서비스 플랫폼을 활성화하면 플랫폼에 모델을 배포할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예:
rhoai-users)의 일부입니다. - 다중 모델 서비스 플랫폼을 활성화했습니다.
- 데이터 사이언스 프로젝트를 생성하고 모델 서버를 추가했습니다.
- S3 호환 오브젝트 스토리지에 액세스할 수 있습니다.
- 배포하려는 모델의 경우 S3 호환 오브젝트 스토리지 버킷의 관련 폴더 경로를 알고 있습니다.
프로세스
OpenShift AI 대시보드의 왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
모델을 배포할 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
- 모델 배포를 클릭합니다.
다음과 같이 모델 배포를 위한 속성을 구성합니다.
- 모델 이름 필드에 배포하려는 모델의 고유 이름을 입력합니다.
모델 프레임워크 목록에서 모델의 프레임워크를 선택합니다.
참고모델 프레임워크 목록은 모델 서버를 구성할 때 지정한 model-serving 런타임에서 지원하는 프레임워크만 표시합니다.
S3 호환 오브젝트 스토리지에서 배포할 모델의 위치를 지정하려면 다음 작업 세트 중 하나를 수행합니다.
기존 연결을 사용하려면 다음을 수행합니다.
- 기존 연결을 선택합니다.
- 이름 목록에서 이전에 정의한 연결을 선택합니다.
- 경로 필드에서 지정된 데이터 소스에 모델이 포함된 폴더 경로를 입력합니다.
새 연결 사용
- 모델에 액세스할 수 있는 새 연결을 정의하려면 새 연결을 선택합니다.
연결 추가 모달에서 연결 유형을 선택합니다. S3 호환 오브젝트 스토리지 및 URI 옵션은 사전 설치된 연결 유형입니다. OpenShift AI 관리자가 이를 추가한 경우 추가 옵션을 사용할 수 있습니다.
연결 추가 양식은 선택한 연결 유형과 관련된 필드를 사용하여 열립니다.
- 연결 세부 정보 필드를 입력합니다.
(선택 사항) 구성 매개변수 섹션에서 런타임 매개변수를 사용자 지정합니다.
- 배포된 모델의 작동 방식을 정의하도록 추가 제공 런타임 인수 의 값을 수정합니다.
- 추가 환경 변수 의 값을 수정하여 모델의 환경에서 변수를 정의합니다.
- Deploy 를 클릭합니다.
검증
- 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.
2.2.2. 배포된 모델 보기 링크 복사링크가 클립보드에 복사되었습니다!
작업 결과를 분석하려면 Red Hat OpenShift AI에 배포된 모델 목록을 볼 수 있습니다. 배포된 모델 및 해당 끝점의 현재 상태를 볼 수도 있습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다.
프로세스
OpenShift AI 대시보드에서 Model Serving 을 클릭합니다.
배포된 모델 페이지가 열립니다.
각 모델에 대해 페이지에는 모델 이름, 모델이 배포되는 프로젝트, 모델이 사용하는 model-serving 런타임, 배포 상태와 같은 세부 정보가 표시됩니다.
- 선택 사항: 지정된 모델의 경우 유추 끝점 열의 링크를 클릭하여 배포된 모델의 유추 끝점을 확인합니다.
검증
- 이전에 배포된 데이터 사이언스 모델 목록은 배포된 모델 페이지에 표시됩니다.
2.2.3. 배포된 모델의 배포 속성 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
이전에 배포된 모델의 배포 속성을 업데이트할 수 있습니다. 예를 들어 모델의 연결 및 이름을 변경할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - OpenShift AI에 모델을 배포했습니다.
프로세스
OpenShift AI 대시보드에서 Model Serving 을 클릭합니다.
배포된 모델 페이지가 열립니다.
업데이트할 배포 속성이 있는 모델 옆에 있는 작업 메뉴( )를 클릭하고 편집을 클릭합니다.
모델 편집 대화 상자가 열립니다.
다음과 같이 모델의 배포 속성을 업데이트합니다.
- 모델 이름 필드에 모델의 고유 이름을 새로 입력합니다.
- 모델 서버 목록에서 모델의 모델 서버를 선택합니다.
모델 프레임워크 목록에서 모델의 프레임워크를 선택합니다.
참고모델 프레임워크 목록은 모델 서버를 구성할 때 지정한 model-serving 런타임에서 지원하는 프레임워크만 표시합니다.
- 선택적으로 기존 연결을 지정하거나 새 연결을 생성하여 연결을 업데이트합니다.
- Redeploy 를 클릭합니다.
검증
- 업데이트된 배포 속성이 대시보드의 모델 Serving 페이지에 표시되는 모델입니다.
2.2.4. 배포된 모델 삭제 링크 복사링크가 클립보드에 복사되었습니다!
이전에 배포한 모델을 삭제할 수 있습니다. 이를 통해 더 이상 필요하지 않은 배포된 모델을 제거할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 모델을 배포했습니다.
프로세스
OpenShift AI 대시보드에서 모델 제공 을 클릭합니다.
배포된 모델 페이지가 열립니다.
삭제할배포된 모델 옆에 있는 작업 메뉴( Cryostat )를 클릭하고 삭제 를 클릭합니다.
배포된 모델 삭제 대화 상자가 열립니다.
- 텍스트 필드에 배포된 모델의 이름을 입력하여 삭제하려는지 확인합니다.
- 배포된 모델 삭제를 클릭합니다.
검증
- 삭제한 모델은 배포 모델 페이지에 더 이상 표시되지 않습니다.
2.3. 다중 모델 서비스 플랫폼에 대한 모니터링 구성 링크 복사링크가 클립보드에 복사되었습니다!
다중 모델 제공 플랫폼에는 ModelMesh 구성 요소에 대한 모델 및 모델 서버 메트릭이 포함되어 있습니다. ModelMesh는 자체 메트릭 세트를 생성하고 이를 제공하기 위해 기본 모델 제공 런타임에 의존하지 않습니다. ModelMesh가 생성하는 메트릭 세트에는 모델 요청 속도 및 타이밍, 모델 로드 및 언로드 속도, 시간 및 크기, 내부 대기열 지연, 용량 및 사용량, 캐시 상태 및 최근 사용된 모델에 대한 메트릭이 포함됩니다. 자세한 내용은 ModelMesh 메트릭 을 참조하십시오.
모니터링을 구성한 후 ModelMesh 구성 요소에 대한 메트릭을 볼 수 있습니다.
사전 요구 사항
- OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
- OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치를 참조하십시오.
- 사용자 정의 워크플로우를 모니터링하기 위한 구성 맵을 생성하는 방법을 알고 있습니다. 이 절차에서는 유사한 단계를 수행합니다.
- OpenShift에서 사용자 정의 프로젝트에 대한 모니터링을 활성화하는 방법을 알고 있습니다. 이 절차에서는 유사한 단계를 수행합니다.
-
메트릭을 모니터링할 사용자에게
monitoring-rules-view역할을 할당 했습니다.
프로세스
터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>다음 콘텐츠를 사용하여
uwm-cm-conf.yaml이라는 YAML 파일에ConfigMap오브젝트를 정의합니다.apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheus: logLevel: debug retention: 15duser-workload-monitoring-config오브젝트는 사용자 정의 프로젝트를 모니터링하는 구성 요소를 구성합니다. 보존 시간이 권장 15일의 값으로 설정되어 있는지 확인합니다.구성을 적용하여
user-workload-monitoring-config오브젝트를 생성합니다.$ oc apply -f uwm-cm-conf.yaml다음 콘텐츠를 사용하여
uwm-cm-enable.yaml이라는 YAML 파일에 다른ConfigMap오브젝트를 정의합니다.apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: truecluster-monitoring-config오브젝트를 사용하면 사용자 정의 프로젝트를 모니터링할 수 있습니다.구성을 적용하여
cluster-monitoring-config오브젝트를 생성합니다.$ oc apply -f uwm-cm-enable.yaml
2.4. 다중 모델 제공 플랫폼에 대한 모델 서비스 런타임 메트릭 보기 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자가 다중 모델 서비스 플랫폼에 대한 모니터링을 구성한 후 관리자가 아닌 사용자는 OpenShift 웹 콘솔을 사용하여 ModelMesh 구성 요소의 모델 제공 런타임 지표를 볼 수 있습니다.
사전 요구 사항
- 클러스터 관리자가 다중 모델 서비스 플랫폼에 대한 모니터링을 구성했습니다.
-
monitoring-rules-view역할이 할당되었습니다. 자세한 내용은 사용자 정의 프로젝트에 대한 모니터링을 구성할 수 있는 사용자 권한 부여를 참조하십시오. - OpenShift 웹 콘솔에서 프로젝트 메트릭을 모니터링하는 방법에 대해 잘 알고 있습니다. 자세한 내용은 프로젝트 메트릭 모니터링을 참조하십시오.
프로세스
- OpenShift 웹 콘솔에 로그인합니다.
- 개발자 화면으로 전환합니다.
- 왼쪽 메뉴에서 모니터링 을 클릭합니다.
-
프로젝트 지표 모니터링에 설명된 대로 웹 콘솔을 사용하여
modelmesh_*메트릭에 대한 쿼리를 실행합니다.
2.5. 모델 성능 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
다중 모델 제공 플랫폼에서는 모델 서버에 배포된 모든 모델 및 모델 서버에 배포된 특정 모델에 대한 성능 지표를 볼 수 있습니다.
2.5.1. 모델 서버의 모든 모델에 대한 성능 지표 보기 링크 복사링크가 클립보드에 복사되었습니다!
모델 서버에 배포된 모든 모델에 대해 다음 메트릭을 모니터링할 수 있습니다.
- 5분당 HTTP 요청 - 서버의 모든 모델에 대해 실패하거나 성공한 HTTP 요청 수입니다.
- 평균 응답 시간(ms) - 서버의 모든 모델의 경우 요청에 응답하는 데 모델 서버가 걸리는 평균 시간입니다.
- CPU 사용률(%) - 서버의 모든 모델에서 현재 사용 중인 CPU 용량의 백분율입니다.
- 메모리 사용률(%) - 서버의 모든 모델에서 현재 사용 중인 시스템 메모리의 백분율입니다.
이러한 메트릭에 대한 시간 범위 및 새로 고침 간격을 지정하여 최대 사용 시간이 있고 지정된 시간에 모델이 수행하는 방법을 결정하는 데 도움이 됩니다.
사전 요구 사항
- Red Hat OpenShift AI를 설치했습니다.
- OpenShift AI가 설치된 OpenShift 클러스터에서 사용자 워크로드 모니터링이 활성화됩니다.
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 다중 모델 서비스 플랫폼에 모델을 배포했습니다.
프로세스
OpenShift AI 대시보드 탐색 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
- 모니터링할 데이터 과학 모델이 포함된 프로젝트의 이름을 클릭합니다.
- 프로젝트 세부 정보 페이지에서 모델 탭을 클릭합니다.
- 관심 있는 모델 서버의 행에서 작업 메뉴( Cryostat)를 클릭한 다음 View model server metrics 를 선택합니다.
선택 사항: 모델 서버의 메트릭 페이지에서 다음 옵션을 설정합니다.
- 시간 범위 - 메트릭을 추적하는 기간을 지정합니다. 이 값 중 하나를 선택할 수 있습니다. 1 시간, 24 시간, 7 일 및 30 일.
- 새로 고침 간격 - 메트릭 페이지의 그래프가 새로 고쳐지는 빈도를 지정합니다(최신 데이터를 표시). 이 값 중 하나를 선택할 수 있습니다: 15 초, 30 초, 1 분, 5 분, 15 분, 30 분, 1 시간, 2 시간, 1 일.
- 아래로 스크롤하여 5분당 HTTP 요청의 데이터 그래프, 평균 응답 시간, CPU 사용률, 메모리 사용률을 확인합니다.
검증
모델 서버의 메트릭 페이지에서 그래프는 성능 지표에 대한 데이터를 제공합니다.
2.5.2. 배포된 모델에 대한 HTTP 요청 메트릭 보기 링크 복사링크가 클립보드에 복사되었습니다!
다중 모델 제공 플랫폼에 배포된 특정 모델에 대해 실패했거나 성공한 HTTP 요청을 보여주는 그래프를 볼 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI를 설치했습니다.
- OpenShift AI가 설치된 OpenShift 클러스터에서 사용자 워크로드 모니터링이 활성화됩니다.
다음 대시보드 구성 옵션은 다음과 같이 기본값으로 설정됩니다.
disablePerformanceMetrics:false disableKServeMetrics:false자세한 내용은 대시보드 구성 옵션을 참조하십시오.
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 다중 모델 서비스 플랫폼에 모델을 배포했습니다.
프로세스
- OpenShift AI 대시보드 탐색 메뉴에서 Model Serving 을 선택합니다.
- 배포 모델 페이지에서 관심 있는 모델을 선택합니다.
선택 사항: 끝점 성능 탭에서 다음 옵션을 설정합니다.
- 시간 범위 - 메트릭을 추적하는 기간을 지정합니다. 이 값 중 하나를 선택할 수 있습니다. 1 시간, 24 시간, 7 일 및 30 일.
- 새로 고침 간격 - 메트릭 페이지의 그래프가 새로 고쳐지는 빈도를 지정합니다(최신 데이터를 표시). 이 값 중 하나를 선택할 수 있습니다: 15 초, 30 초, 1 분, 5 분, 15 분, 30 분, 1 시간, 2 시간, 1 일.
검증
끝점 성능 탭에는 모델의 HTTP 메트릭 그래프가 표시됩니다.
3장. 대규모 모델 제공 링크 복사링크가 클립보드에 복사되었습니다!
대용량 언어 모델(LLM)과 같은 대규모 모델을 배포하기 위해 Red Hat OpenShift AI에는 KServe 구성 요소를 기반으로 하는 단일 모델 제공 플랫폼이 포함되어 있습니다. 각 모델은 자체 모델 서버에서 배포되므로 단일 모델 제공 플랫폼은 증가된 리소스가 필요한 대규모 모델을 배포, 모니터링, 확장 및 유지 관리하는 데 도움이 됩니다.
3.1. 단일 모델 제공 플랫폼 정보 링크 복사링크가 클립보드에 복사되었습니다!
대용량 언어 모델(LLM)과 같은 대규모 모델을 배포하기 위해 OpenShift AI에는 KServe 구성 요소를 기반으로 하는 단일 모델 제공 플랫폼이 포함되어 있습니다. 각 모델은 자체 모델 서버에 배포되므로 단일 모델 제공 플랫폼은 증가된 리소스가 필요한 대규모 모델을 배포, 모니터링, 확장 및 유지 관리하는 데 도움이 됩니다.
3.2. components 링크 복사링크가 클립보드에 복사되었습니다!
- KServe: 모든 유형의 모델에 대해 모델을 오케스트레이션하는 Kubernetes CRD(사용자 정의 리소스 정의)입니다. KServe에는 지정된 유형의 모델 서버 로드를 구현하는 모델 제공 런타임이 포함되어 있습니다. KServe는 배포 오브젝트, 스토리지 액세스 및 네트워킹 설정의 라이프사이클도 처리합니다.
- Red Hat OpenShift Serverless: 모델을 서버리스 배포할 수 있는 클라우드 네이티브 개발 모델입니다. OpenShift Serverless는 오픈 소스 Knative 프로젝트를 기반으로 합니다.
- Red Hat OpenShift Service Mesh: 트래픽 흐름을 관리하고 액세스 정책을 적용하는 서비스 메시 네트워킹 계층입니다. OpenShift Service Mesh는 오픈 소스 Istio 프로젝트를 기반으로 합니다.
3.3. 설치 옵션 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼을 설치하려면 다음과 같은 옵션이 있습니다.
- 자동 설치
OpenShift 클러스터에서
ServiceMeshControlPlane또는KNativeServing리소스를 아직 생성하지 않은 경우 KServe를 설치하고 종속 항목을 구성하도록 Red Hat OpenShift AI Operator를 구성할 수 있습니다.자동 설치에 대한 자세한 내용은 KServe의 자동 설치 구성을 참조하십시오.
- 수동 설치
OpenShift 클러스터에서
ServiceMeshControlPlane또는KNativeServing리소스를 이미 생성한 경우 KServe를 설치하고 종속 항목을 구성하도록 Red Hat OpenShift AI Operator를 구성할 수 없습니다. 이 경우 KServe를 수동으로 설치해야 합니다.수동 설치에 대한 자세한 내용은 KServe 수동 설치를 참조하십시오.
3.4. 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
Authorino 를 단일 모델 제공 플랫폼의 권한 부여 공급자로 추가할 수 있습니다. 권한 부여 공급자를 추가하면 플랫폼에 배포하는 모델에 대한 토큰 권한 부여를 활성화할 수 있으므로 권한이 있는 당사자만 모델에 대한 유추 요청을 수행할 수 있습니다.
단일 모델 제공 플랫폼에서 Authorino를 권한 부여 공급자로 추가하려면 다음 옵션이 있습니다.
- 클러스터에서 단일 모델 서비스 플랫폼의 자동 설치가 가능한 경우 Authorino를 자동화된 설치 프로세스의 일부로 포함할 수 있습니다.
- 단일 모델 제공 플랫폼을 수동으로 설치해야 하는 경우 Authorino를 수동으로 구성해야 합니다.
단일 모델 제공 플랫폼의 설치 옵션 선택 지침은 설치 옵션을 참조하십시오.
3.5. 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼에 대한 모니터링을 구성하고 Prometheus를 사용하여 사전 설치된 각 모델 제공 런타임에 대한 지표를 스크랩할 수 있습니다.
3.6. model-serving 런타임 링크 복사링크가 클립보드에 복사되었습니다!
model-serving 런타임을 사용하여 단일 모델 서비스 플랫폼에서 모델을 제공할 수 있습니다. model-serving 런타임 구성은 ServingRuntime 및 InferenceService CRD(사용자 정의 리소스 정의)에 의해 정의됩니다.
3.6.1. ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
ServingRuntime CRD는 모델 배포 및 관리를 위한 환경인 제공 런타임을 생성합니다. 다양한 형식의 모델을 동적으로 로드 및 언로드하는 Pod용 템플릿을 생성하고 요청을 유추하기 위해 서비스 끝점도 노출합니다.
다음 YAML 구성은 KServe model-serving 런타임의 vLLM ServingRuntime 의 예입니다. 구성에는 다양한 플래그, 환경 변수 및 명령줄 인수가 포함됩니다.
apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
annotations:
opendatahub.io/recommended-accelerators: '["nvidia.com/gpu"]'
openshift.io/display-name: vLLM ServingRuntime for KServe
labels:
opendatahub.io/dashboard: "true"
name: vllm-runtime
spec:
annotations:
prometheus.io/path: /metrics
prometheus.io/port: "8080"
containers :
- args:
- --port=8080
- --model=/mnt/models
- --served-model-name={{.Name}}
command:
- python
- '-m'
- vllm.entrypoints.openai.api_server
env:
- name: HF_HOME
value: /tmp/hf_home
image:
quay.io/modh/vllm@sha256:8a3dd8ad6e15fe7b8e5e471037519719d4d8ad3db9d69389f2beded36a6f5b21
name: kserve-container
ports:
- containerPort: 8080
protocol: TCP
multiModel: false
supportedModelFormats:
- autoSelect: true
name: vLLM
- 1
- 런타임과 함께 사용할 권장 가속기입니다.
- 2
- 제공 런타임이 표시되는 이름입니다.
- 3
- Prometheus에서 모니터링을 위한 지표를 스크랩하는 데 사용하는 끝점입니다.
- 4
- 모니터링을 위해 Prometheus에서 메트릭을 스크랩하는 데 사용하는 포트입니다.
- 5
- 모델 파일이 런타임 컨테이너에 저장되는 위치 경로입니다.
- 6
- 런타임 컨테이너 사양 내에서
{{.Name}}템플릿 변수로 지정된 모델 이름을 런타임 환경에 전달합니다.{{.Name}}변수는InferenceService메타데이터 오브젝트의spec.predictor.name필드에 매핑됩니다. - 7
- 런타임 컨테이너를 시작하는 entrypoint 명령입니다.
- 8
- 제공 런타임에서 사용하는 런타임 컨테이너 이미지입니다. 이 이미지는 사용된 가속기의 유형에 따라 다릅니다.
- 9
- 런타임이 단일 모델 제공에 사용되도록 지정합니다.
- 10
- 런타임에서 지원하는 모델 형식을 지정합니다.
3.6.2. InferenceService 링크 복사링크가 클립보드에 복사되었습니다!
InferenceService CRD는 유추 쿼리를 처리하고 모델에 전달한 다음 유추 출력을 반환하는 서버 또는 유추 서비스를 생성합니다.
유추 서비스는 다음 작업도 수행합니다.
- 모델의 위치와 형식을 지정합니다.
- 모델을 제공하는 데 사용되는 제공 런타임을 지정합니다.
- gRPC 또는 REST 유추에 대해 passthrough 경로를 활성화합니다.
- 배포된 모델에 대한 HTTP 또는 gRPC 끝점을 정의합니다.
다음 예제에서는 vLLM 런타임을 사용하여 granite 모델을 배포할 때 생성되는 InferenceService YAML 구성 파일을 보여줍니다.
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
annotations:
openshift.io/display-name: granite
serving.knative.openshift.io/enablePassthrough: 'true'
sidecar.istio.io/inject: 'true'
sidecar.istio.io/rewriteAppHTTPProbers: 'true'
name: granite
labels:
opendatahub.io/dashboard: 'true'
spec:
predictor:
maxReplicas: 1
minReplicas: 1
model:
modelFormat:
name: vLLM
name: ''
resources:
limits:
cpu: '6'
memory: 24Gi
nvidia.com/gpu: '1'
requests:
cpu: '1'
memory: 8Gi
nvidia.com/gpu: '1'
runtime: vLLM ServingRuntime for KServe
storage:
key: aws-connection-my-storage
path: models/granite-7b-instruct/
tolerations:
- effect: NoSchedule
key: nvidia.com/gpu
operator: Exists
3.7. 지원되는 model-serving 런타임 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift AI에는 사전 설치된 여러 모델 제공 런타임이 포함되어 있습니다. 사전 설치된 model-serving 런타임을 사용하여 런타임을 직접 수정하거나 정의하지 않고도 모델 서비스를 시작할 수 있습니다. 사용자 지정 런타임을 추가하여 모델을 지원할 수도 있습니다.
사용자 지정 런타임을 추가하는 방법에 대한 자세한 내용은 단일 모델 제공 플랫폼에 대한 사용자 지정 모델 제공 런타임 추가를 참조하십시오.
| 이름 | 설명 | 내보낸 모델 형식 |
|---|---|---|
| KServe (1)에 대한 Cainitiatort text Generation Inference Server (Caikit-TGIS) ServingRuntime | Cakeygent 형식으로 모델을 제공하기 위한 복합 런타임 | Ca#159t text Generation |
| KServe 용 카피네트 Standalone ServingRuntime (2) | 작업 포함을 위한 Cakeygent embeddings 형식으로 모델을 제공하는 런타임 | Ca#159t Embeddings |
| OpenVino Model Server | Intel 아키텍처에 최적화된 모델을 제공하기 위한 확장 가능한 고성능 런타임 | PyTorch, TensorFlow, OpenVINO IR, PaddlePaddle, MXNet, Caffe, Kaldi |
| KServe (3)용 텍스트 생성 유추 서버(TGIS) Standalone ServingRuntime | TGI 지원 모델을 제공하는 런타임 | PyTorch 모델 형식 |
| KServe의 vLLM ServingRuntime | 대규모 언어 모델을 위한 높은 처리량 및 메모리 효율적인 추론 및 제공 런타임 | |
| Gaudi 액셀러레이터가 KServe에 지원되는 vLLM ServingRuntime | Intel Gaudi 액셀러레이터를 지원하는 높은 처리량 및 메모리 효율적인 추론 및 제공 런타임 | |
| KServe의 vLLM ROCm ServingRuntime | AMD GPU 액셀러레이터를 지원하는 높은 처리량 및 메모리 효율적인 추론 및 제공 런타임 |
- Comuppletion-TGIS 런타임은 T GIS (Chill Generation Inference Server) 를 기반으로 합니다. 이 런타임을 사용하려면 모델을 Caroutet 형식으로 변환해야 합니다. 예를 들어 caovnt-tgis-serving 리포지토리의 cakeyt 형식으로의 Hugging faces Hub 모델 변환을 참조하십시오.
- Ca#159t Standalone 런타임은 Caovnt NLP를 기반으로 합니다. 이 런타임을 사용하려면 모델을 Cakeygent 포함 형식으로 변환해야 합니다. 예를 들어 텍스트 포함 모듈에 대한 테스트를 참조하십시오.
- text Generation Inference Server (TGIS) 는 Hugging Cryostat TGI 의 초기 포크를 기반으로 합니다. Red Hat은 TGI 모델을 지원하기 위해 독립형 TGIS 런타임을 계속 개발할 예정입니다. 현재 OpenShift AI 버전에서 모델이 호환되지 않는 경우 향후 버전에 지원이 추가될 수 있습니다. 그동안 고유한 사용자 지정 런타임을 추가하여 TGI 모델을 지원할 수도 있습니다. 자세한 내용은 단일 모델 제공 플랫폼의 사용자 지정 모델 서비스 런타임 추가를 참조하십시오.
| 이름 | 기본 프로토콜 | Additonal 프로토콜 | 모델 메시 지원 | 단일 노드 OpenShift 지원 | 배포 모드 |
|---|---|---|---|---|---|
| KServe의 Cainitiatort text Generation Inference Server (Caikit-TGIS) ServingRuntime | REST | gRPC | 없음 | 제공됨 | 원시 및 서버리스 |
| KServe 용 카피네트 Standalone ServingRuntime | REST | gRPC | 없음 | 제공됨 | 원시 및 서버리스 |
| OpenVino Model Server | REST | 없음 | 제공됨 | 제공됨 | 원시 및 서버리스 |
| KServe용 텍스트 생성 유추 서버(TGIS) Standalone ServingRuntime | gRPC | 없음 | 없음 | 제공됨 | 원시 및 서버리스 |
| KServe의 vLLM ServingRuntime | REST | 없음 | 없음 | 제공됨 | 원시 및 서버리스 |
| Gaudi 액셀러레이터가 KServe에 지원되는 vLLM ServingRuntime | REST | 없음 | 없음 | 제공됨 | 원시 및 서버리스 |
| KServe의 vLLM ROCm ServingRuntime | REST | 없음 | 없음 | 제공됨 | 원시 및 서버리스 |
3.8. 테스트 및 검증된 모델 제공 런타임 링크 복사링크가 클립보드에 복사되었습니다!
테스트 및 검증된 런타임은 특정 버전의 OpenShift AI에 대해 테스트 및 검증된 모델 제공 런타임의 커뮤니티 버전입니다.
Red Hat은 새로운 OpenShift AI 버전이 있을 때마다 테스트 및 검증된 런타임의 현재 버전을 테스트합니다. OpenShift AI 릴리스 사이클 중간에 테스트 및 검증된 새 버전의 런타임이 릴리스되는 경우 향후 릴리스에서 테스트 및 검증됩니다.
테스트 및 검증된 런타임 및 호환 버전 목록은 OpenShift AI 릴리스 노트 에서 확인할 수 있습니다.
테스트 및 검증된 런타임은 Red Hat에서 직접 지원하지 않습니다. 사용자가 추가한 테스트 및 검증된 런타임을 사용하고 올바르게 구성 및 유지 관리할 수 있는 권한이 있는지 확인해야 합니다.
자세한 내용은 OpenShift AI에서 테스트 및 검증된 런타임 을 참조하십시오.
| 이름 | 설명 | 내보낸 모델 형식 |
|---|---|---|
| NVIDIA Triton Inference Server | 애플리케이션에서 빠르고 확장 가능한 AI를 위한 오픈 소스 추론 지원 소프트웨어. | TensorRT, TensorFlow, PyTorch, ONNX, OpenVINO, Python, RAPIDS FIL 등 |
| 이름 | 기본 프로토콜 | Additonal 프로토콜 | 모델 메시 지원 | 단일 노드 OpenShift 지원 | 배포 모드 |
|---|---|---|---|---|---|
| NVIDIA Triton Inference Server | gRPC | REST | 제공됨 | 제공됨 | 원시 및 서버리스 |
3.9. 유추 끝점 링크 복사링크가 클립보드에 복사되었습니다!
이 예제에서는 유추 끝점을 사용하여 모델을 쿼리하는 방법을 보여줍니다.
모델을 배포할 때 토큰 권한 부여를 활성화한 경우 Authorization 헤더를 추가하고 토큰 값을 지정합니다.
3.9.1. KServe를 위한 Cainitiatort TGIS ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
-
:443/api/v1/task/text-generation -
:443/api/v1/task/server-streaming-text-generation
명령 예
curl --json '{"model_id": "<model_name__>", "inputs": "<text>"}' https://<inference_endpoint_url>:443/api/v1/task/server-streaming-text-generation -H 'Authorization: Bearer <token>'
3.9.2. KServe 용 카피네트 Standalone ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
여러 모델을 제공하는 경우 /info/models 또는 :443 cactlplanet.runtime.info.InfoService/GetModelsInfo 를 쿼리하여 제공된 모델 목록을 볼 수 있습니다.
REST 끝점
-
/api/v1/task/embedding -
/api/v1/task/embedding-tasks -
/api/v1/task/sentence-similarity -
/api/v1/task/sentence-similarity-tasks -
/api/v1/task/rerank -
/api/v1/task/rerank-tasks -
/info/models -
/info/version -
/info/runtime
gRPC 끝점
-
:443 caikit.runtime.Nlp.NlpService/EmbeddingTaskPredict -
:443 caikit.runtime.Nlp.NlpService/EmbeddingTasksPredict -
:443 caikit.runtime.Nlp.NlpService/SentenceSimilarityTaskPredict -
:443 caikit.runtime.Nlp.NlpService/SentenceSimilarityTasksPredict -
:443 caikit.runtime.Nlp.NlpService/RerankTaskPredict -
:443 caikit.runtime.Nlp.NlpService/RerankTasksPredict -
:443 caikit.runtime.info.InfoService/GetModelsInfo -
:443 caikit.runtime.info.InfoService/GetRuntimeInfo
기본적으로 Cakeygent Standalone Runtime은 REST 엔드포인트를 노출합니다. gRPC 프로토콜을 사용하려면 사용자 정의 Cakeygent Standalone ServingRuntime을 수동으로 배포합니다. 자세한 내용은 단일 모델 제공 플랫폼의 사용자 지정 모델 서비스 런타임 추가를 참조하십시오.
예제 매니페스트는 canit -tgis-serving GitHub 리포지토리에서 사용할 수 있습니다.
REST
curl -H 'Content-Type: application/json' -d '{"inputs": "<text>", "model_id": "<model_id>"}' <inference_endpoint_url>/api/v1/task/embedding -H 'Authorization: Bearer <token>'
gRPC
grpcurl -d '{"text": "<text>"}' -H \"mm-model-id: <model_id>\" <inference_endpoint_url>:443 caikit.runtime.Nlp.NlpService/EmbeddingTaskPredict -H 'Authorization: Bearer <token>'
3.9.3. KServe 용 TGIS Standalone ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
-
:443 fmaas.GenerationService/Generate :443 fmaas.GenerationService/GenerateStream참고TGIS 독립 실행형 런타임의 끝점을 쿼리하려면 OpenShift AI
텍스트 생성유추 리포지토리의 proto 디렉터리에 파일을 다운로드해야 합니다.
명령 예
grpcurl -proto text-generation-inference/proto/generation.proto -d '{"requests": [{"text":"<text>"}]}' -H 'Authorization: Bearer <token>' -insecure <inference_endpoint_url>:443 fmaas.GenerationService/Generate
3.9.4. OpenVino Model Server 링크 복사링크가 클립보드에 복사되었습니다!
-
/v2/models/<model-name>/infer
명령 예
curl -ks <inference_endpoint_url>/v2/models/<model_name>/infer -d '{ "model_name": "<model_name>", "inputs": [{ "name": "<name_of_model_input>", "shape": [<shape>], "datatype": "<data_type>", "data": [<data>] }]}' -H 'Authorization: Bearer <token>'
3.9.5. KServe의 vLLM ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
-
:443/version -
:443/docs -
:443/v1/models -
:443/v1/chat/completions -
:443/v1/completions -
:443/v1/embeddings -
:443/tokenize :443/detokenize참고- vLLM 런타임은 OpenAI REST API와 호환됩니다. vLLM 런타임에서 지원하는 모델 목록은 지원되는 모델을 참조하십시오.
- vLLM에 삽입된 유추 엔드포인트를 사용하려면 vLLM에서 지원하는 포함 모델을 사용해야 합니다. 유전 모델에는 임베딩 끝점을 사용할 수 없습니다. 자세한 내용은 vLLM의 포함 모델 지원을 참조하십시오.
vLLM v0.5.5부터
/v1/chat/completions엔드포인트를 사용하여 모델을 쿼리하는 동안 채팅 템플릿을 제공해야 합니다. 모델에 사전 정의된 채팅 템플릿이 포함되어 있지 않은 경우 example과 같이chat-template명령줄 매개 변수를 사용하여 사용자 지정 vLLM 런타임에 채팅 템플릿을 지정할 수 있습니다. <CHAT_TEMPLATE>를 템플릿 경로로 바꿉니다.containers: - args: - --chat-template=<CHAT_TEMPLATE>여기에서 또는
/apps/data/template아래의 vLLM 이미지로 사용할 수 있는 채팅 템플릿을 사용할 수 있습니다.자세한 내용은 templates를 참조하십시오.
표시된 경로에 표시된 대로 단일 모델 제공 플랫폼은 OpenShift 라우터의 HTTPS 포트(일반적으로 포트 443)를 사용하여 외부 API 요청을 처리합니다.
명령 예
curl -v https://<inference_endpoint_url>:443/v1/chat/completions -H "Content-Type: application/json" -d '{ "messages": [{ "role": "<role>", "content": "<content>" }] -H 'Authorization: Bearer <token>'
3.9.6. Gaudi 액셀러레이터가 KServe에 지원되는 vLLM ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
KServe의 vLLM ServingRuntime을 참조하십시오.
3.9.7. KServe의 vLLM ROCm ServingRuntime 링크 복사링크가 클립보드에 복사되었습니다!
KServe의 vLLM ServingRuntime을 참조하십시오.
3.9.8. NVIDIA Triton Inference Server 링크 복사링크가 클립보드에 복사되었습니다!
REST 끝점
-
v2/models/[/versions/<model_version>]/infer -
v2/models/<model_name>[/versions/<model_version>] -
v2/health/ready -
v2/health/live -
v2/models/<model_name>[/versions/]/ready -
v2
ModelMesh는 다음 REST 끝점을 지원하지 않습니다.
-
v2/health/live -
v2/health/ready -
v2/models/<model_name>[/versions/]/ready
명령 예
curl -ks <inference_endpoint_url>/v2/models/<model_name>/infer -d '{ "model_name": "<model_name>", "inputs": [{ "name": "<name_of_model_input>", "shape": [<shape>], "datatype": "<data_type>", "data": [<data>] }]}' -H 'Authorization: Bearer <token>'
gRPC 끝점
-
:443 inference.GRPCInferenceService/ModelInfer -
:443 inference.GRPCInferenceService/ModelReady -
:443 inference.GRPCInferenceService/ModelMetadata -
:443 inference.GRPCInferenceService/ServerReady -
:443 inference.GRPCInferenceService/ServerLive -
:443 inference.GRPCInferenceService/ServerMetadata
명령 예
grpcurl -cacert ./openshift_ca_istio_knative.crt -proto ./grpc_predict_v2.proto -d @ -H "Authorization: Bearer <token>" <inference_endpoint_url>:443 inference.GRPCInferenceService/ModelMetadata
3.10. KServe 배포 모드 정보 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 모델 서버리스 배포를 허용하는 클라우드 네이티브 개발 모델인 Red Hat OpenShift Serverless 를 사용하여 KServe와 함께 단일 모델 서비스 플랫폼에 모델을 배포할 수 있습니다. OpenShift Serverless는 오픈 소스 Knative 프로젝트를 기반으로 합니다. 또한 서버리스 모드는 Red Hat OpenShift Serverless Operator에 따라 다릅니다.
또는 Red Hat OpenShift Serverless Operator에 의존하지 않는 원시 배포 모드를 사용할 수 있습니다. 원시 배포 모드를 사용하면 Deployment,Service,Ingress, Horizontal Pod Autoscaler 와 같은 Kubernetes 리소스가 포함된 모델을 배포할 수 있습니다.
KServe 원시 배포 모드를 사용하여 머신 러닝 모델을 배포하는 것은 제한된 가용성 기능입니다. 제한된 가용성은 Red Hat AI Business Unit의 특정 승인에서만 해당 기능에 대한 지원을 설치하고 받을 수 있음을 의미합니다. 이러한 승인이 없으면 해당 기능은 지원되지 않습니다. 또한 이 기능은 단일 노드 OpenShift의 자체 관리형 배포에서만 지원됩니다.
이러한 배포 모드를 각각 사용하는 데에는 장단점이 있습니다.
3.10.1. 서버리스 모드 링크 복사링크가 클립보드에 복사되었습니다!
이점:
요청 볼륨에 따라 자동 스케일링을 활성화합니다.
- 들어오는 요청을 수신할 때 리소스가 자동으로 확장됩니다.
- 리소스 사용량을 최적화하고 최대 시간 동안 성능을 유지 관리합니다.
Knative를 사용하여 0으로 스케일링을 지원합니다.
- 들어오는 요청이 없을 때 리소스를 완전히 축소할 수 있습니다.
- 유휴 리소스를 실행하지 않고 비용을 절감합니다.
단점:
사용자 지정 제한 사항이 있습니다.
- 서버리스는 여러 볼륨을 마운트할 때와 같이 Knative로 제한됩니다.
스케일링을 위해 Knative에 대한 종속성:
- 기존의 확장 방법과 비교하여 설정 및 관리의 복잡성이 추가로 도입되었습니다.
3.10.2. 원시 배포 모드 링크 복사링크가 클립보드에 복사되었습니다!
이점:
Deployment,Service,Ingress,Horizontal Pod Autoscaler와 같은 Kubernetes 리소스로 배포를 활성화합니다.- Kubernetes 리소스를 완전히 제어하여 배포 설정의 세부 사용자 지정 및 구성을 수행할 수 있습니다.
Knative 제한 사항의 잠금 해제(예: 여러 볼륨을 마운트할 수 없음)
- 복잡한 구성 또는 여러 스토리지 마운트가 필요한 애플리케이션에 유용합니다.
단점:
자동 확장을 지원하지 않습니다.
- 유휴 상태일 때 리소스를 제로로 자동 축소하는 것은 지원하지 않습니다.
- 낮은 트래픽 기간 동안 비용이 증가할 수 있습니다.
- 확장을 수동으로 관리해야 합니다.
3.11. KServe 원시 배포 모드를 사용하여 단일 노드 OpenShift에 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift에서 KServe 원시 배포 모드를 사용하여 머신 러닝 모델을 배포할 수 있습니다. 원시 배포 모드는 Knative보다 여러 볼륨을 마운트하는 기능과 같은 몇 가지 이점을 제공합니다.
단일 노드 OpenShift에서 KServe 원시 배포 모드를 사용하여 머신 러닝 모델을 배포하는 것은 제한된 가용성 기능입니다. 제한된 가용성은 Red Hat AI Business Unit의 특정 승인에서만 해당 기능에 대한 지원을 설치하고 받을 수 있음을 의미합니다. 이러한 승인이 없으면 해당 기능은 지원되지 않습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
- OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
- CPU가 4개 이상이고 메모리가 16GB인 노드가 있는 OpenShift 클러스터를 생성했습니다.
- RHOAI(Red Hat OpenShift AI) Operator를 설치했습니다.
- OpenShift CLI(명령줄 인터페이스)를 설치했습니다. OpenShift CLI(명령줄 인터페이스) 설치에 대한 자세한 내용은 OpenShift CLI 시작하기를 참조하십시오.
- KServe를 설치했습니다.
- S3 호환 오브젝트 스토리지에 액세스할 수 있습니다.
- 배포하려는 모델의 경우 S3 호환 오브젝트 스토리지 버킷의 관련 폴더 경로를 알고 있습니다.
- Cakeygent-TGIS 런타임을 사용하려면 모델을 Cafindt 형식으로 변환했습니다. 예를 들어 caovnt-tgis-serving 리포지토리의 cakeyt 형식으로의 Hugging faces Hub 모델 변환을 참조하십시오.
- 모델 서버에서 GPU(그래픽 처리 장치)를 사용하려는 경우 OpenShift AI에서 GPU 지원을 활성화했습니다. NVIDIA GPU를 사용하는 경우 NVIDIA GPU 활성화를 참조하십시오. AMD GPU를 사용하는 경우 AMD GPU 통합을 참조하십시오.
- vLLM 런타임을 사용하려면 OpenShift AI에서 GPU 지원을 활성화하고 클러스터에 Node Feature Discovery Operator를 설치 및 구성했습니다. 자세한 내용은 Node Feature Discovery Operator 설치 및 NVIDIA GPU 활성화를 참조하십시오.
프로세스
명령줄 터미널을 열고 클러스터 관리자로 OpenShift 클러스터에 로그인합니다.
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>기본적으로 OpenShift는 네트워크 트래픽 관리에 서비스 메시를 사용합니다. KServe 원시 배포 모드에 서비스 메시가 필요하지 않으므로 Red Hat OpenShift Service Mesh를 비활성화합니다.
Red Hat OpenShift Service Mesh를 비활성화하려면 다음 명령을 입력합니다.
$ oc edit dsci -n redhat-ods-operatorYAML 편집기에서 다음과 같이
serviceMesh구성 요소의managementState값을Removed로 변경합니다.spec: components: serviceMesh: managementState: Removed- 변경 사항을 저장합니다.
프로젝트를 생성합니다.
$ oc new-project <project_name> --description="<description>" --display-name="<display_name>"프로젝트 생성에 대한 자세한 내용은 프로젝트 작업을 참조하십시오.
데이터 과학 클러스터를 생성합니다.
- Red Hat OpenShift 웹 콘솔 관리자 보기에서 Operator → 설치된 Operator를 클릭한 다음 Red Hat OpenShift AI Operator를 클릭합니다.
- Data Science Cluster 탭을 클릭합니다.
- Create DataScienceCluster 버튼을 클릭합니다.
- Configure via field에서 YAML 보기 라디오 버튼을 클릭합니다.
YAML 편집기의
spec.components섹션에서 다음과 같이kserve구성 요소를 구성합니다.kserve: defaultDeploymentMode: RawDeployment managementState: Managed serving: managementState: Removed name: knative-serving- 생성을 클릭합니다.
보안 파일을 생성합니다.
명령줄 터미널에서 보안을 포함할 YAML 파일을 생성하고 다음 YAML 코드를 추가합니다.
apiVersion: v1 kind: Secret metadata: annotations: serving.kserve.io/s3-endpoint: <AWS_ENDPOINT> serving.kserve.io/s3-usehttps: "1" serving.kserve.io/s3-region: <AWS_REGION> serving.kserve.io/s3-useanoncredential: "false" name: <Secret-name> stringData: AWS_ACCESS_KEY_ID: "<AWS_ACCESS_KEY_ID>" AWS_SECRET_ACCESS_KEY: "<AWS_SECRET_ACCESS_KEY>"중요연결이 끊긴 배포에 머신 학습 모델을 배포하는 경우
metadata.annotations섹션에serving.kserve.io/s3-verifyssl: '0'을 추가합니다.- 파일 이름 secret.yaml 을 사용하여 파일을 저장합니다.
secret.yaml 파일을 적용합니다.
$ oc apply -f secret.yaml -n <namespace>
서비스 계정을 생성합니다.
서비스 계정을 포함할 YAML 파일을 생성하고 다음 YAML 코드를 추가합니다.
apiVersion: v1 kind: ServiceAccount metadata: name: models-bucket-sa secrets: - name: s3creds서비스 계정에 대한 자세한 내용은 서비스 계정 이해 및 생성을 참조하십시오.
- 파일 이름 serviceAccount.yaml 을 사용하여 파일을 저장합니다.
serviceAccount.yaml 파일을 적용합니다.
$ oc apply -f serviceAccount.yaml -n <namespace>
제공 런타임에 대한 YAML 파일을 만들어 모델 예측을 제공할 컨테이너 이미지를 정의합니다. 다음은 OpenVino Model Server를 사용하는 예입니다.
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: ovms-runtime spec: annotations: prometheus.io/path: /metrics prometheus.io/port: "8888" containers: - args: - --model_name={{.Name}} - --port=8001 - --rest_port=8888 - --model_path=/mnt/models - --file_system_poll_wait_seconds=0 - --grpc_bind_address=0.0.0.0 - --rest_bind_address=0.0.0.0 - --target_device=AUTO - --metrics_enable image: quay.io/modh/openvino_model_server@sha256:6c7795279f9075bebfcd9aecbb4a4ce4177eec41fb3f3e1f1079ce6309b7ae45 name: kserve-container ports: - containerPort: 8888 protocol: TCP multiModel: false protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: openvino_ir version: opset13 - name: onnx version: "1" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: paddle version: "2" - autoSelect: true name: pytorch version: "2"- 위의 OpenVINO 모델 서버 예제를 사용하는 경우 YAML 코드의 자리 표시자에 필요한 올바른 값을 삽입해야 합니다.
- 적절한 파일 이름으로 파일을 저장합니다.
서빙 런타임이 포함된 파일을 적용합니다.
$ oc apply -f <serving run time file name> -n <namespace>
InferenceService CR(사용자 정의 리소스)을 생성합니다. InferenceService CR을 포함할 YAML 파일을 생성합니다. 이전에 사용된 OpenVINO 모델 서버 예제를 사용하여 해당 YAML 코드는 다음과 같습니다.
apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: annotations: serving.knative.openshift.io/enablePassthrough: "true" sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" serving.kserve.io/deploymentMode: RawDeployment name: <InferenceService-Name> spec: predictor: scaleMetric: minReplicas: 1 scaleTarget: canaryTrafficPercent: serviceAccountName: <serviceAccountName> model: env: [] volumeMounts: [] modelFormat: name: onnx runtime: ovms-runtime storageUri: s3://<bucket_name>/<model_directory_path> resources: requests: memory: 5Gi volumes: []YAML 코드에서 다음 값이 올바르게 설정되어 있는지 확인합니다.
-
serving.kserve.io/deploymentMode에는RawDeployment값이 포함되어야 합니다. -
modelFormat에는onnx와 같은 모델 형식의 값이 포함되어야 합니다. -
StorageUri에는 모델 s3 스토리지디렉터리의 값(예:s3://<bucket_name>/<model_directory_path> )이 포함되어야 합니다. -
런타임에는 제공
런타임이름(예:ovms-runtime)의 값이 포함되어야 합니다.
-
- 적절한 파일 이름으로 파일을 저장합니다.
InferenceService CR을 포함하는 파일을 적용합니다.
$ oc apply -f <InferenceService CR file name> -n <namespace>
모든 Pod가 클러스터에서 실행 중인지 확인합니다.
$ oc get pods -n <namespace>출력 예:
NAME READY STATUS RESTARTS AGE <isvc_name>-predictor-xxxxx-2mr5l 1/1 Running 2 165m console-698d866b78-m87pm 1/1 Running 2 165m모든 Pod가 실행 중인지 확인한 후 서비스 포트를 로컬 머신으로 전달합니다.
$ oc -n <namespace> port-forward pod/<pod-name> <local_port>:<remote_port><
namespace> , <pod-name> , <local_port> , <remote_port>(이는 모델 서버 포트(예:8888)를 배포에 적합한 값으로 교체해야 합니다.
검증
-
선호하는 클라이언트 라이브러리 또는 도구를 사용하여 요청을
localhost유추 URL로 보냅니다.
3.12. 단일 모델 제공 플랫폼을 사용하여 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼에서 각 모델은 자체 모델 서버에 배포됩니다. 이를 통해 증가된 리소스가 필요한 대규모 모델을 배포, 모니터링, 확장 및 유지 관리할 수 있습니다.
3.12.1. 단일 모델 제공 플랫폼 활성화 링크 복사링크가 클립보드에 복사되었습니다!
KServe를 설치하면 Red Hat OpenShift AI 대시보드를 사용하여 단일 모델 제공 플랫폼을 활성화할 수 있습니다. 대시보드를 사용하여 플랫폼의 모델 제공 런타임을 활성화할 수도 있습니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- KServe를 설치했습니다.
- 클러스터 관리자가 KServe 구성 요소를 사용하는 단일 모델 제공 플랫폼을 선택하는 기능을 비활성화하도록 OpenShift AI 대시보드 구성을 편집 하지 않았습니다. 자세한 내용은 대시보드 구성 옵션을 참조하십시오.
프로세스
다음과 같이 플랫폼을 제공하는 단일 모델을 활성화합니다.
- 왼쪽 메뉴에서 설정 → 클러스터 설정을 클릭합니다.
- 모델 제공 플랫폼 섹션을 찾습니다.
- 프로젝트에 단일 모델 제공 플랫폼을 활성화하려면 단일 모델 제공 플랫폼 확인란을 선택합니다.
- 변경 사항 저장을 클릭합니다.
다음과 같이 단일 모델 제공 플랫폼에 대해 사전 설치된 런타임을 활성화합니다.
OpenShift AI 대시보드의 왼쪽 메뉴에서 설정 → Serving 런타임 을 클릭합니다.
Serving 런타임 페이지에는 사전 설치된 런타임 및 사용자가 추가한 모든 사용자 지정 런타임이 표시됩니다.
사전 설치된 런타임에 대한 자세한 내용은 지원되는 런타임 을 참조하십시오.
사용할 런타임을 Enabled 로 설정합니다.
단일 모델 제공 플랫폼은 이제 모델 배포에 사용할 수 있습니다.
3.12.2. 단일 모델 제공 플랫폼에 대한 사용자 정의 모델 서비스 런타임 추가 링크 복사링크가 클립보드에 복사되었습니다!
모델 서비스 런타임은 지정된 모델 프레임워크 세트 및 해당 프레임워크에서 지원하는 모델 형식에 대한 지원을 추가합니다. OpenShift AI에 포함된 사전 설치된 런타임 을 사용할 수 있습니다. 기본 런타임이 요구 사항을 충족하지 않는 경우 자체 사용자 지정 런타임을 추가할 수도 있습니다. 예를 들어 TGIS 런타임에서 TGI(Hurgging Cryostat Generation Inference) 에서 지원하는 모델 형식을 지원하지 않는 경우 사용자 지정 런타임을 생성하여 모델에 대한 지원을 추가할 수 있습니다.
관리자는 OpenShift AI 인터페이스를 사용하여 사용자 지정 모델 제공 런타임을 추가하고 활성화할 수 있습니다. 그런 다음 단일 모델 제공 플랫폼에 모델을 배포할 때 사용자 지정 런타임을 선택할 수 있습니다.
Red Hat은 사용자 지정 런타임을 지원하지 않습니다. 사용자가 추가한 모든 사용자 지정 런타임을 사용하고 올바르게 구성 및 유지 관리를 수행할 수 있는지 확인해야 합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 사용자 지정 런타임을 빌드하고 Quay 와 같은 컨테이너 이미지 리포지토리에 이미지를 추가했습니다.
프로세스
OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.
Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.
사용자 지정 런타임을 추가하려면 다음 옵션 중 하나를 선택합니다.
- 기존 런타임(예: KServe의 경우 TGIS Standalone ServingRuntime)으로 시작하려면 기존 런타임 옆에 있는 작업 메뉴(예: TGIS Standalone ServingRuntime)를 클릭한 다음 중복 을 클릭합니다.
- 새 사용자 지정 런타임을 추가하려면 제공 런타임 추가 를 클릭합니다.
- Select the model serving platforms this runtime supports list, select Single-model serving platform.
- Select the API protocol this runtime supports list에서 지원하는 REST 또는 gRPC 를 선택합니다.
선택 사항: 새 런타임을 시작한 경우(기존 런타임을 복제하지 않고) 다음 옵션 중 하나를 선택하여 코드를 추가합니다.
YAML 파일 업로드
- 파일 업로드 를 클릭합니다.
파일 브라우저에서 컴퓨터에서 YAML 파일을 선택합니다.
포함된 YAML 편집기가 열리고 업로드한 파일의 내용이 표시됩니다.
편집기에서 직접 YAML 코드를 입력합니다.
- 처음부터 시작을 클릭합니다.
- 포함된 편집기에서 YAML 코드를 직접 입력하거나 붙여넣습니다.
참고대부분의 경우 사용자 지정 런타임을 생성하려면
ServingRuntime사양의env섹션에 새 또는 사용자 지정 매개변수를 추가해야 합니다.추가를 클릭합니다.
Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 사용자 지정 런타임이 자동으로 활성화되어 있는지 확인합니다. 런타임을 생성할 때 지정한 API 프로토콜이 표시됩니다.
- 선택 사항: 사용자 지정 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
검증
- 추가한 사용자 정의 모델 제공 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.
3.12.3. 단일 모델 제공 플랫폼에 대해 테스트 및 검증된 모델 제공 런타임 추가 링크 복사링크가 클립보드에 복사되었습니다!
사전 설치되어 사용자 지정 모델 제공 런타임 외에도 Red Hat 테스트 및 검증된 모델 제공 런타임(예: NVIDIA Triton Inference Server )을 사용하여 요구 사항을 지원할 수도 있습니다. Red Hat 테스트 및 검증된 런타임에 대한 자세한 내용은 Red Hat OpenShift AI에 대한 테스트 및 검증된 런타임을 참조하십시오.
Red Hat OpenShift AI 대시보드를 사용하여 단일 모델 제공 플랫폼에 대해 NVIDIA Triton 유추 서버 런타임을 추가하고 활성화할 수 있습니다. 그런 다음 단일 모델 제공 플랫폼에 모델을 배포할 때 런타임을 선택할 수 있습니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
프로세스
OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.
Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.
- 제공 런타임 추가를 클릭합니다.
- Select the model serving platforms this runtime supports list, select Single-model serving platform.
- Select the API protocol this runtime supports list에서 지원하는 REST 또는 gRPC 를 선택합니다.
처음부터 시작을 클릭합니다.
REST API 프로토콜을 선택한 경우 포함된 편집기에 다음 YAML 코드를 직접 입력하거나 붙여넣습니다.
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: triton-kserve-rest labels: opendatahub.io/dashboard: "true" spec: annotations: prometheus.kserve.io/path: /metrics prometheus.kserve.io/port: "8002" containers: - args: - tritonserver - --model-store=/mnt/models - --grpc-port=9000 - --http-port=8080 - --allow-grpc=true - --allow-http=true image: nvcr.io/nvidia/tritonserver@sha256:xxxxx name: kserve-container resources: limits: cpu: "1" memory: 2Gi requests: cpu: "1" memory: 2Gi ports: - containerPort: 8080 protocol: TCP protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: tensorrt version: "8" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: onnx version: "1" - name: pytorch version: "1" - autoSelect: true name: triton version: "2" - autoSelect: true name: xgboost version: "1" - autoSelect: true name: python version: "1"gRPC API 프로토콜을 선택한 경우 포함된 편집기에 다음 YAML 코드를 직접 입력하거나 붙여넣습니다.
apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: triton-kserve-grpc labels: opendatahub.io/dashboard: "true" spec: annotations: prometheus.kserve.io/path: /metrics prometheus.kserve.io/port: "8002" containers: - args: - tritonserver - --model-store=/mnt/models - --grpc-port=9000 - --http-port=8080 - --allow-grpc=true - --allow-http=true image: nvcr.io/nvidia/tritonserver@sha256:xxxxx name: kserve-container ports: - containerPort: 9000 name: h2c protocol: TCP volumeMounts: - mountPath: /dev/shm name: shm resources: limits: cpu: "1" memory: 2Gi requests: cpu: "1" memory: 2Gi protocolVersions: - v2 - grpc-v2 supportedModelFormats: - autoSelect: true name: tensorrt version: "8" - autoSelect: true name: tensorflow version: "1" - autoSelect: true name: tensorflow version: "2" - autoSelect: true name: onnx version: "1" - name: pytorch version: "1" - autoSelect: true name: triton version: "2" - autoSelect: true name: xgboost version: "1" - autoSelect: true name: python version: "1" volumes: - emptyDir: null medium: Memory sizeLimit: 2Gi name: shm
-
metadata.name필드에서 추가하는 런타임 값이 이미 추가한 런타임 값과 일치하지 않는지 확인합니다. 선택 사항: 추가하는 런타임에 사용자 정의 표시 이름을 사용하려면
metadata.annotations.openshift.io/display-name필드를 추가하고 다음 예와 같이 값을 지정합니다.apiVersion: serving.kserve.io/v1alpha1 kind: ServingRuntime metadata: name: kserve-triton annotations: openshift.io/display-name: Triton ServingRuntime참고런타임에 대한 사용자 정의 표시 이름을 구성하지 않으면 OpenShift AI에
metadata.name필드의 값이 표시됩니다.생성을 클릭합니다.
Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 런타임이 자동으로 활성화되어 있는지 확인합니다. 런타임을 생성할 때 지정한 API 프로토콜이 표시됩니다.
- 선택 사항: 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
검증
- 추가한 model-serving 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.
3.12.4. 단일 모델 제공 플랫폼에 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼을 활성화하면 사전 설치 또는 사용자 정의 모델 제공 런타임을 활성화하고 플랫폼에 모델을 배포할 수 있습니다.
text Generation Inference Server (TGIS) 는 Hugging Cryostat TGI 의 초기 포크를 기반으로 합니다. Red Hat은 TGI 모델을 지원하기 위해 독립형 TGIS 런타임을 계속 개발할 예정입니다. 현재 OpenShift AI 버전에서 모델이 작동하지 않으면 향후 버전에 지원이 추가될 수 있습니다. 그동안 TGI 모델을 지원하기 위해 자체 사용자 지정 런타임을 추가할 수도 있습니다. 자세한 내용은 단일 모델 제공 플랫폼의 사용자 지정 모델 서비스 런타임 추가를 참조하십시오.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - KServe를 설치했습니다.
- 단일 모델 제공 플랫폼을 활성화했습니다.
- 배포된 모델에 대해 토큰 권한 부여 및 외부 모델 경로를 활성화하기 위해 권한 부여 공급자로 Authorino를 추가했습니다. 자세한 내용은 단일 모델 제공 플랫폼에 대한 권한 부여 공급자 추가를 참조하십시오.
- 데이터 과학 프로젝트를 생성했습니다.
- S3 호환 오브젝트 스토리지에 액세스할 수 있습니다.
- 배포하려는 모델의 경우 S3 호환 오브젝트 스토리지 버킷의 관련 폴더 경로를 알고 있습니다.
- Cakeygent-TGIS 런타임을 사용하려면 모델을 Cafindt 형식으로 변환했습니다. 예를 들어 caovnt-tgis-serving 리포지토리의 cakeyt 형식으로의 Hugging faces Hub 모델 변환을 참조하십시오.
- 모델 서버에서 GPU(그래픽 처리 장치)를 사용하려는 경우 OpenShift AI에서 GPU 지원을 활성화했습니다. NVIDIA GPU를 사용하는 경우 NVIDIA GPU 활성화를 참조하십시오. AMD GPU를 사용하는 경우 AMD GPU 통합을 참조하십시오.
- vLLM 런타임을 사용하려면 OpenShift AI에서 GPU 지원을 활성화하고 클러스터에 Node Feature Discovery Operator를 설치 및 구성했습니다. 자세한 내용은 Node Feature Discovery Operator 설치 및 NVIDIA GPU 활성화를참조하십시오.
- KServe 런타임을 위한 Gaudi 액셀러레이터 지원과 함께 vLLM ServingRuntime 을 사용하려면 OpenShift AI에서 하이브리드 처리 단위(HPU)에 대한 지원을 활성화했습니다. 여기에는 Intel Gaudi AI 액셀러레이터 설치 및 가속기 프로파일 구성이 포함됩니다. 자세한 내용은 OpenShift용 Gaudi 설정 및 액셀러레이터 작업을 참조하십시오.
KServe 런타임에 vLLM ROCm ServingRuntime 을 사용하려면 OpenShift AI에서 AMD GPU(그래픽 처리 단위)에 대한 지원을 활성화했습니다. 여기에는 AMD GPU Operator 설치 및 가속기 프로파일 구성이 포함됩니다. 자세한 내용은 OpenShift에 AMD GPU Operator 배포 및 액셀러레이터 작업을 참조하십시오.
참고OpenShift AI 2.16에서 Red Hat은 model serving을 위해 NVIDIA GPU, Intel Gaudi, AMD GPU 액셀러레이터를 지원합니다.
RHEL AI 모델을 배포하려면 다음을 수행합니다.
- KServe 런타임에 vLLM ServingRuntime을 활성화했습니다.
- Red Hat 컨테이너 레지스트리에서 모델을 다운로드하여 S3 호환 오브젝트 스토리지에 업로드했습니다.
프로세스
왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
모델을 배포할 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
다음 작업 중 하나를 수행합니다.
- 플랫폼 타일을 제공하는 단일 모델이 표시되면 타일에 모델 배포를 클릭합니다.
- 타일이 표시되지 않으면 모델 배포 버튼을 클릭합니다.
모델 배포 대화 상자가 열립니다.
- 모델 배포 이름 필드에 배포 중인 모델의 고유 이름을 입력합니다.
- Serving 런타임 필드에서 활성화된 런타임을 선택합니다.
- 모델 프레임워크(이름 - 버전) 목록에서 값을 선택합니다.
- 배포할 모델 서버 복제본 수에서 값을 지정합니다.In the Number of model server replicas to deploy field, specify a value.
- 모델 서버 크기 목록에서 값을 선택합니다.From the Model server size list, select a value.
다음 옵션은 클러스터에서 가속기 지원을 활성화하고 가속기를 생성한 경우에만 사용할 수 있습니다.
- 액셀러레이터 목록에서 가속기 를 선택합니다.
- 이전 단계에서 가속기를 선택한 경우 수의 가속기 필드에 사용할 가속기의 수 를 지정합니다.
- 선택 사항: 모델 경로 섹션에서 외부 경로 확인란을 통해 사용 가능한 배포된 모델 만들기 확인란을 선택하여 배포된 모델을 외부 클라이언트에서 사용할 수 있도록 합니다.
배포된 모델에 대한 유추 요청에 대한 토큰 권한 부여가 필요한 경우 다음 작업을 수행합니다.
- 토큰 권한 부여 필요 를 선택합니다.
- 서비스 계정 이름 필드에 토큰이 생성될 서비스 계정 이름을 입력합니다.
모델의 위치를 지정하려면 다음 작업 세트 중 하나를 수행합니다.
기존 연결을 사용하려면 다음을 수행합니다.
- 기존 연결을 선택합니다.
- 이름 목록에서 이전에 정의한 연결을 선택합니다.
경로 필드에서 지정된 데이터 소스에 모델이 포함된 폴더 경로를 입력합니다.
중요OpenVINO 모델 서버 런타임에는 모델 경로를 지정하는 방법에 대한 특정 요구 사항이 있습니다. 자세한 내용은 OpenShift AI 릴리스 노트의 알려진 문제 RHOAIENG-3025 를 참조하십시오.
새 연결 사용
모델에 액세스할 수 있는 새 연결을 정의하려면 새 연결을 선택합니다.
연결 추가 모달에서 연결 유형을 선택합니다. S3 호환 오브젝트 스토리지 및 URI 옵션은 사전 설치된 연결 유형입니다. OpenShift AI 관리자가 이를 추가한 경우 추가 옵션을 사용할 수 있습니다.
연결 추가 양식은 선택한 연결 유형과 관련된 필드를 사용하여 열립니다.
연결 세부 정보 필드를 작성합니다.
중요연결 유형이 S3 호환 오브젝트 스토리지인 경우 데이터 파일이 포함된 폴더 경로를 제공해야 합니다. OpenVINO 모델 서버 런타임에는 모델 경로를 지정하는 방법에 대한 특정 요구 사항이 있습니다. 자세한 내용은 OpenShift AI 릴리스 노트의 알려진 문제 RHOAIENG-3025 를 참조하십시오.
(선택 사항) 구성 매개변수 섹션에서 런타임 매개변수를 사용자 지정합니다.
- 배포된 모델의 작동 방식을 정의하도록 추가 제공 런타임 인수 의 값을 수정합니다.
추가 환경 변수 의 값을 수정하여 모델의 환경에서 변수를 정의합니다.
구성 매개 변수 섹션에는 사용 가능한 경우 사전 정의된 제공 런타임 매개변수가 표시됩니다.
참고특정 값을 설정해야 하므로, 포트 또는 모델 제공 런타임 인수를 수정하지 마십시오. 이러한 매개 변수를 덮어쓰면 배포가 실패할 수 있습니다.
- Deploy 를 클릭합니다.
검증
- 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.
3.12.5. KServe에 대한 시간 제한 설정 링크 복사링크가 클립보드에 복사되었습니다!
대규모 모델을 배포하거나 KServe를 사용하여 노드 자동 스케일링을 사용하는 경우 KNative Serving 세트가 설정된 기본 progress-deadline 이 10분이므로 모델이 배포되기 전에 작업이 시간 초과될 수 있습니다.
KNative Serving을 사용하는 Pod를 배포하는 데 10분 이상 걸리면 Pod가 자동으로 실패로 표시될 수 있습니다. 이는 S3 호환 오브젝트 스토리지에서 가져오는 데 10분 이상 걸리는 대규모 모델을 배포하거나 GPU 노드의 사용을 줄이기 위해 노드 자동 스케일링을 사용하는 경우 발생할 수 있습니다.
이 문제를 해결하려면 애플리케이션에 대한 KServe InferenceService 에서 사용자 지정 progress-deadline 을 설정할 수 있습니다.
사전 요구 사항
- OpenShift 클러스터에 대한 네임스페이스 편집 액세스 권한이 있어야 합니다.
프로세스
- 클러스터 관리자로 OpenShift 콘솔에 로그인합니다.
- 모델을 배포한 프로젝트를 선택합니다.
- 관리자 화면에서 홈 → 검색을 클릭합니다.
-
Resources 드롭다운 메뉴에서
InferenceService를 검색합니다. spec.predictor.annotations에서 새 시간 초과로serving.knative.dev/progress-deadline을 수정합니다.apiVersion: serving.kserve.io/v1alpha1 kind: InferenceService metadata: name: my-inference-service spec: predictor: annotations: serving.knative.dev/progress-deadline: 30m참고KServe
InferenceService에서progress-deadline을 KNative Service 오브젝트에 다시 복사할 수 있도록spec.predictor.annotations수준에서progress-deadline을 설정해야 합니다.
3.12.6. 배포된 model-serving 런타임의 매개변수 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
특정 모델을 배포하거나 기존 모델 배포를 개선하기 위해 기본 매개변수 이외의 추가 매개변수가 필요할 수 있습니다. 이러한 경우 기존 런타임의 매개 변수를 배포 요구에 맞게 수정할 수 있습니다.
런타임의 매개 변수를 사용자 정의하면 선택한 모델 배포에만 영향을 미칩니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 단일 모델 제공 플랫폼에 모델을 배포했습니다.
프로세스
OpenShift AI 대시보드의 왼쪽 메뉴에서 Model Serving 을 클릭합니다.
배포된 모델 페이지가 열립니다.
사용자 지정할 모델 이름 옆에 있는 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
구성 매개 변수 섹션에는 사용 가능한 경우 사전 정의된 제공 런타임 매개변수가 표시됩니다.
구성 매개변수 섹션에서 런타임 매개변수를 사용자 지정합니다.
- 배포된 모델의 작동 방식을 정의하도록 추가 제공 런타임 인수 의 값을 수정합니다.
추가 환경 변수 의 값을 수정하여 모델의 환경에서 변수를 정의합니다.
참고특정 값을 설정해야 하므로, 포트 또는 모델 제공 런타임 인수를 수정하지 마십시오. 이러한 매개 변수를 덮어쓰면 배포가 실패할 수 있습니다.
- 런타임 매개변수 사용자 지정을 완료한 후 Redeploy 를 클릭하여 변경 사항을 사용하여 모델을 저장하고 배포합니다.
검증
- 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.
설정한 인수 및 변수가 다음 방법 중 하나로
spec.predictor.model.args및spec.predictor.model.env에 표시되는지 확인합니다.- OpenShift 콘솔에서 InferenceService YAML 확인.
OpenShift CLI에서 다음 명령을 사용합니다.
oc get -o json inferenceservice <inferenceservicename/modelname> -n <projectname>
3.12.7. 사용자 지정 가능한 모델 제공 런타임 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
기존 모델 서비스 런타임의 매개 변수를 배포 요구 사항에 맞게 수정할 수 있습니다.
지원되는 각 제공 런타임의 매개변수에 대한 자세한 내용은 다음 표를 참조하십시오.
| 런타임 제공 | 리소스 |
|---|---|
| NVIDIA Triton Inference Server | |
| KServe의 Cainitiatort text Generation Inference Server (Caikit-TGIS) ServingRuntime | |
| KServe 용 카피네트 Standalone ServingRuntime | |
| OpenVino Model Server | |
| KServe용 텍스트 생성 유추 서버(TGIS) Standalone ServingRuntime | |
| KServe의 vLLM ServingRuntime |
3.12.8. 모델 스토리지에 OCI 컨테이너 사용 링크 복사링크가 클립보드에 복사되었습니다!
S3 버킷 또는 URI에 모델을 저장하는 대신 OCI(Open Container Initiative) 컨테이너에 모델을 업로드할 수 있습니다. 모델 스토리지에 OCI 컨테이너를 사용하면 다음과 같은 이점을 얻을 수 있습니다.
- 동일한 모델을 여러 번 다운로드하지 않도록 하여 시작 시간을 줄입니다.
- 로컬에서 다운로드한 모델 수를 줄임으로써 디스크 공간 사용량을 줄입니다.
- 사전 패치된 이미지를 허용하여 모델 성능을 개선합니다.
모델 스토리지에 OCI 컨테이너를 사용하려면 다음 작업이 포함됩니다.
- OCI 이미지에 모델 저장
- OCI 이미지에서 모델 배포
모델 스토리지에 OCI 컨테이너를 사용하는 것은 현재 Red Hat OpenShift AI 2.16에서 기술 프리뷰 기능으로 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. Red Hat은 프로덕션 환경에서 사용하는 것을 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
3.12.8.1. OCI 이미지에 모델 저장 링크 복사링크가 클립보드에 복사되었습니다!
OCI 이미지에 모델을 저장할 수 있습니다. 다음 절차에서는 ONNX 형식으로 MobileNet v2-7 모델을 저장하는 예제를 사용합니다.
사전 요구 사항
- ONNX 형식의 모델이 있습니다. 이 절차의 예제에서는 ONNX 형식의 MobileNet v2-7 모델을 사용합니다.
- Podman 툴을 설치했습니다.
프로세스
로컬 시스템의 터미널 창에서 OCI 이미지를 생성하는 데 필요한 모델 및 지원 파일을 모두 저장할 임시 디렉터리를 생성합니다.
cd $(mktemp -d)임시 디렉터리 내에
models폴더를 생성합니다.mkdir -p models/1참고이 예제 명령은 OpenVINO 모델 버전 관리를 위해 번호가 지정된 하위 디렉터리가 필요하므로
1디렉터리를 지정합니다. OpenVINO를 사용하지 않는 경우 OCI 컨테이너 이미지를 사용하기 위해1하위 디렉터리를 생성할 필요가 없습니다.모델 및 지원 파일을 다운로드합니다.
DOWNLOAD_URL=https://github.com/onnx/models/raw/main/validated/vision/classification/mobilenet/model/mobilenetv2-7.onnx curl -L $DOWNLOAD_URL -O --output-dir models/1/트리명령을 사용하여 모델 파일이 예상대로 디렉터리 구조에 있는지 확인합니다.treetree명령은 다음 예와 유사한 디렉터리 구조를 반환해야 합니다.. ├── Containerfile └── models └── 1 └── mobilenetv2-7.onnxContainerfile이라는 Docker 파일을 생성합니다.참고-
쉘을 제공하는 기본 이미지를 지정합니다. 다음 예에서
ubi9-micro는 기본 컨테이너 이미지입니다. KServe는 쉘을 사용하지 않는 쉘을 제공하지 않는 빈 이미지를 지정할 수 없습니다. KServe는 쉘을 사용하여 모델 서버에 액세스할 수 있도록 하기 때문입니다. - 복사된 모델 파일의 소유권을 변경하고 루트 그룹에 읽기 권한을 부여하여 모델 서버가 파일에 액세스할 수 있는지 확인합니다. OpenShift는 임의의 사용자 ID 및 root 그룹 ID로 컨테이너를 실행합니다.
FROM registry.access.redhat.com/ubi9/ubi-micro:latest COPY --chown=0:0 models /models RUN chmod -R a=rX /models # nobody user USER 65534-
쉘을 제공하는 기본 이미지를 지정합니다. 다음 예에서
podman build명령을 사용하여 OCI 컨테이너 이미지를 생성하여 레지스트리에 업로드합니다. 다음 명령은 Quay를 레지스트리로 사용합니다.참고리포지토리가 프라이빗인 경우 컨테이너 이미지를 업로드하기 전에 레지스트리에 인증되었는지 확인합니다.
podman build --format=oci -t quay.io/<user_name>/<repository_name>:<tag_name> . podman push quay.io/<user_name>/<repository_name>:<tag_name>
3.12.8.2. OCI 이미지에 저장된 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
OCI 이미지에 저장된 모델을 배포할 수 있습니다.
다음 절차에서는 OpenVINO 모델 서버의 OCI 이미지에 저장된 ONNX 형식으로 MobileNet v2-7 모델을 배포하는 예제를 사용합니다.
기본적으로 KServe에서 모델은 클러스터 외부에 노출되며 권한 부여로 보호되지 않습니다.
사전 요구 사항
- OCI 이미지의 모델 저장에 설명된 대로 OCI 이미지에 모델을 저장했습니다.
- 개인 OCI 리포지토리에 저장된 모델을 배포하려면 이미지 가져오기 보안을 구성해야 합니다. 이미지 가져오기 보안 생성에 대한 자세한 내용은 이미지 가져오기 보안 사용을 참조하십시오.
- OpenShift 클러스터에 로그인되어 있습니다.
프로세스
모델을 배포할 프로젝트를 생성합니다.
oc new-project oci-model-exampleOpenShift AI Applications 프로젝트
kserve-ovms템플릿을 사용하여ServingRuntime리소스를 생성하고 새 프로젝트에서 OpenVINO 모델 서버를 구성합니다.oc process -n redhat-ods-applications -o yaml kserve-ovms | oc apply -f -kserve-ovms라는ServingRuntime이 생성되었는지 확인합니다.oc get servingruntimes명령은 다음과 유사한 출력을 반환해야 합니다.
NAME DISABLED MODELTYPE CONTAINERS AGE kserve-ovms openvino_ir kserve-container 1m모델이 개인 또는 공용 OCI 리포지토리에서 저장되는지 여부에 따라
InferenceServiceYAML 리소스를 생성합니다.공용 OCI 리포지토리에 저장된 모델의 경우
InferenceServiceYAML 파일을 다음 값으로 생성하여 <user_name> , <> , <repository_nametag_name>을 해당 환경과 관련된 값으로 바꿉니다.apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: sample-isvc-using-oci spec: predictor: model: runtime: kserve-ovms # Ensure this matches the name of the ServingRuntime resource modelFormat: name: onnx storageUri: oci://quay.io/<user_name>/<repository_name>:<tag_name> resources: requests: memory: 500Mi cpu: 100m # nvidia.com/gpu: "1" # Only required if you have GPUs available and the model and runtime will use it limits: memory: 4Gi cpu: 500m # nvidia.com/gpu: "1" # Only required if you have GPUs available and the model and runtime will use it프라이빗 OCI 리포지토리에 저장된 모델의 경우 다음 예와 같이
spec.predictor.imagePullSecrets필드에 가져오기 보안을 지정하는InferenceServiceYAML 파일을 생성합니다.apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: sample-isvc-using-private-oci spec: predictor: model: runtime: kserve-ovms # Ensure this matches the name of the ServingRuntime resource modelFormat: name: onnx storageUri: oci://quay.io/<user_name>/<repository_name>:<tag_name> resources: requests: memory: 500Mi cpu: 100m # nvidia.com/gpu: "1" # Only required if you have GPUs available and the model and runtime will use it limits: memory: 4Gi cpu: 500m # nvidia.com/gpu: "1" # Only required if you have GPUs available and the model and runtime will use it imagePullSecrets: # Specify image pull secrets to use for fetching container images, including OCI model images - name: <pull-secret-name>InferenceService리소스를 생성한 후 KServe는storageUri필드에서 참조하는 OCI 이미지에 저장된 모델을 배포합니다.
검증
배포 상태를 확인합니다.
oc get inferenceservice
명령은 배포된 모델의 URL 및 준비 상태 등 정보가 포함된 출력을 반환해야 합니다.
3.12.9. vLLM에서 가속기 사용 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift AI는 NVIDIA, AMD 및 Intel Gaudi 액셀러레이터를 지원합니다. OpenShift AI에는 가속기를 지원하는 사전 설치된 모델 제공 런타임도 포함되어 있습니다.
3.12.9.1. NVIDIA GPU 링크 복사링크가 클립보드에 복사되었습니다!
KServe 런타임용 vLLM ServingRuntime 을 사용하여 NVIDIA 그래픽 처리 장치(GPU)로 모델을 제공할 수 있습니다. 런타임을 사용하려면 OpenShift AI에서 GPU 지원을 활성화해야 합니다. 여기에는 클러스터에 Node Feature Discovery Operator 설치 및 구성이 포함됩니다. 자세한 내용은 Node Feature Discovery Operator 설치 및 NVIDIA GPU 활성화를 참조하십시오.
3.12.9.2. Intel Gaudi 액셀러레이터 링크 복사링크가 클립보드에 복사되었습니다!
KServe 런타임을 Gaudi 액셀러레이터와 함께 vLLM ServingRuntime을 사용하여 Intel Gaudi 액셀러레이터로 모델을 제공할 수 있습니다. 런타임을 사용하려면 OpenShift AI에서 하이브리드 처리 지원(HPU) 지원을 활성화해야 합니다. 여기에는 Intel Gaudi AI 액셀러레이터 설치 및 가속기 프로파일 구성이 포함됩니다. 자세한 내용은 OpenShift용 Gaudi 설정 및 액셀러레이터 프로필 작업을 참조하십시오.
권장 vLLM 매개변수, 환경 변수, 지원되는 구성 등에 대한 자세한 내용은 Intel® Gaudi® AI Accelerators의 vLLM 을 참조하십시오.
3.12.9.3. AMD GPU 링크 복사링크가 클립보드에 복사되었습니다!
KServe 런타임용 vLLM ROCm ServingRuntime 을 사용하여 AMD GPU가 있는 모델을 제공할 수 있습니다. 런타임을 사용하려면 OpenShift AI에서 AMD GPU(그래픽 처리 단위)에 대한 지원을 활성화해야 합니다. 여기에는 AMD GPU Operator 설치 및 가속기 프로파일 구성이 포함됩니다. 자세한 내용은 OpenShift에 AMD GPU Operator 배포 및 액셀러레이터 프로필 작업을 참조하십시오.
3.12.10. vLLM 모델 사용자 지정-serving 런타임 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 KServe 런타임의 vLLM ServingRuntime 에 추가 플래그 또는 환경 변수를 추가하여 Cryostat 제품군을 배포해야 할 수 있습니다.
다음 절차에서는 L declarationa, Granite 또는 Mistral 모델을 배포하도록 vLLM 모델 사용자 지정을 설명합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- Llana 모델 배포를 위해 메타-일마-3 모델을 오브젝트 스토리지에 다운로드했습니다.
- Granite 모델 배포를 위해 granite-7b-instruct 또는 granite-20B-code-instruct 모델을 오브젝트 스토리지에 다운로드했습니다.
- Mistral 모델 배포를 위해 mistral-7B-Instruct-v0.3 모델을 오브젝트 스토리지에 다운로드했습니다.
- KServe 런타임에 vLLM ServingRuntime을 활성화했습니다.
- OpenShift AI에서 GPU 지원을 활성화하고 클러스터에 Node Feature Discovery Operator를 설치 및 구성했습니다. 자세한 내용은 Node Feature Discovery Operator 설치 및 NVIDIA GPU 활성화를참조하십시오.
프로세스
- 단계에 따라 단일 모델 제공 플랫폼에서 모델 배포에 설명된 대로 모델을 배포합니다.
- Serving 런타임 필드에서 KServe에 대해 vLLM ServingRuntime을 선택합니다.
meta-llama-3 모델을 배포하는 경우 구성 매개변수 섹션에서 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
–-distributed-executor-backend=mp1 --max-model-len=61442 granite-7B-instruct 모델을 배포하는 경우 구성 매개변수 섹션에서 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
--distributed-executor-backend=mp1 - 1
- 분산 모델 작업자의 다중 처리로 백엔드를 설정합니다.
granite-20B-code-instruct 모델을 배포하는 경우 구성 매개변수 섹션에서 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
--distributed-executor-backend=mp1 –-tensor-parallel-size=42 --max-model-len=64483 mistral-7B-Instruct-v0.3 모델을 배포하는 경우 구성 매개변수 섹션에서 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
--distributed-executor-backend=mp1 --max-model-len=153442 - Deploy 를 클릭합니다.
검증
- 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.
granite 모델의 경우 다음 예제 명령을 사용하여 배포된 모델에 대한 API 요청을 확인합니다.
curl -q -X 'POST' \ "https://<inference_endpoint_url>:443/v1/chat/completions" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d "{ \"model\": \"<model_name>\", \"prompt\": \"<prompt>", \"max_tokens\": <max_tokens>, \"temperature\": <temperature> }"
3.13. 여러 GPU 노드를 사용하여 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
대용량 언어 모델(LLM)과 같은 대규모 모델을 처리하기 위해 여러 GPU 노드에 모델을 배포합니다.
다음 절차에서는 vLLM 서비스 프레임워크를 사용하여 여러 GPU 노드에서 Red Hat OpenShift AI 모델을 제공하는 방법을 보여줍니다. 다중 노드 유추는 vllm-multinode-runtime 사용자 지정 런타임을 사용합니다. vllm-multinode-runtime 런타임에서는 KServe 런타임의 VLLM ServingRuntime과 동일한 이미지를 사용하며 다중 GPU 유추에 필요한 정보도 포함합니다.
여러 GPU 노드를 사용하여 모델을 배포하는 것은 현재 Red Hat OpenShift AI에서 기술 프리뷰 기능으로만 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. Red Hat은 프로덕션 환경에서 사용하는 것을 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원범위를 참조하십시오.
사전 요구 사항
- OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
- OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치를 참조하십시오.
Node Feature Discovery Operator, NVIDIA GPU Operator와 같은 GPU 유형에 대해 Operator를 활성화했습니다. 가속기 활성화에 대한 자세한 내용은 가속기 활성화를 참조하십시오.
-
NVIDIA GPU (
nvidia.com/gpu)를 사용하고 있습니다. -
ServingRuntime또는InferenceService를 통해 GPU 유형을 지정했습니다.ServingRuntime에 지정된 GPU 유형이InferenceService에 설정된 것과 다른 경우 두 GPU 유형이 모두 리소스에 할당되어 오류가 발생할 수 있습니다.
-
NVIDIA GPU (
- 클러스터에서 KServe를 활성화했습니다.
-
설정에 하나의 헤드 Pod만 있습니다.
InferenceService의min_replicas또는max_replicas설정을 사용하여 복제본 수를 조정하지 마십시오. 추가 헤드 Pod를 생성하면 Cryostat 클러스터에서 제외될 수 있습니다. - RWX(ReadWriteMany) 액세스 모드로 설정 및 구성된 PVC(영구 볼륨 클레임)가 있습니다.
프로세스
터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>모델 배포를 위한 네임스페이스를 선택하거나 만듭니다. 예를 들어 다음 명령을 실행하여
kserve-demo네임스페이스를 생성할 수 있습니다.oc new-project kserve-demo대상 네임스페이스에서 모델 스토리지를 위한 PVC를 생성하고 스토리지 클래스의 이름을 지정합니다. 스토리지 클래스는 파일 스토리지여야 합니다.
참고PVC를 이미 구성한 경우 이 단계를 건너뛸 수 있습니다.
kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: granite-8b-code-base-pvc spec: accessModes: - ReadWriteMany volumeMode: Filesystem resources: requests: storage: 50Gi storageClassName: __<fileStorageClassName>__모델을 PVC에 다운로드합니다. 예를 들면 다음과 같습니다.
apiVersion: v1 kind: Pod metadata: name: download-granite-8b-code labels: name: download-granite-8b-code spec: volumes: - name: model-volume persistentVolumeClaim: claimName: granite-8b-code-claim restartPolicy: Never initContainers: - name: fix-volume-permissions image: quay.io/quay/busybox@sha256:xxxxx command: ["sh"] args: ["-c", "mkdir -p /mnt/models/granite-8b-code-base && chmod -R 777 /mnt/models"] volumeMounts: - mountPath: "/mnt/models/" name: model-volume containers: - resources: requests: memory: 40Gi name: download-model imagePullPolicy: IfNotPresent image: quay.io/modh/kserve-storage-initializer@sha256:xxxxx args: - 's3://$<bucket_name>/granite-8b-code-base/' - /mnt/models/granite-8b-code-base env: - name: AWS_ACCESS_KEY_ID value: <id> - name: AWS_SECRET_ACCESS_KEY value: <secret> - name: BUCKET_NAME value: <bucket_name> - name: S3_USE_HTTPS value: "1" - name: AWS_ENDPOINT_URL value: <AWS endpoint> - name: awsAnonymousCredential value: 'false' - name: AWS_DEFAULT_REGION value: <region> volumeMounts: - mountPath: "/mnt/models/" name: model-volumevllm-multinode-runtime사용자 지정 런타임을 생성합니다.oc process vllm-multinode-runtime-template -n redhat-ods-applications|oc apply -n kserve-demo -f -다음
InferenceService구성을 사용하여 모델을 배포합니다.apiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: annotations: serving.kserve.io/deploymentMode: RawDeployment serving.kserve.io/autoscalerClass: external name: granite-8b-code-base-pvc spec: predictor: model: modelFormat: name: vLLM runtime: vllm-multinode-runtime storageUri: pvc://granite-8b-code-base-pvc/granite-8b-code-base workerSpec: {}다음 구성을
InferenceService에 추가할 수 있습니다.-
workerSpec.tensorParallelSize: 노드당 사용되는 GPU 수를 결정합니다. 헤드 및 작업자 노드 배포 리소스의 GPU 유형 수가 자동으로 업데이트됩니다.workerSpec.tensorParallelSize의 값이1이상이어야 합니다. -
workerSpec.pipelineParallelSize: 배포에 관련된 노드 수를 결정합니다. 이 변수는 헤드 및 작업자 노드를 모두 포함하여 총 노드 수를 나타냅니다.workerSpec.pipelineParallelSize의 값이2이상이어야 합니다.
-
검증
여러 GPU 노드에 모델을 배포하도록 환경을 설정하려면 GPU 리소스 상태, InferenceService 상태, ray 클러스터 상태를 확인하고 모델에 요청을 보냅니다.
GPU 리소스 상태를 확인합니다.
헤드 및 작업자 노드의 Pod 이름을 검색합니다.
# Get pod name podName=$(oc get pod -l app=isvc.granite-8b-code-base-pvc-predictor --no-headers|cut -d' ' -f1) workerPodName=$(oc get pod -l app=isvc.granite-8b-code-base-pvc-predictor-worker --no-headers|cut -d' ' -f1) oc wait --for=condition=ready pod/${podName} --timeout=300s # Check the GPU memory size for both the head and worker pods: echo "### HEAD NODE GPU Memory Size" kubectl exec $podName -- nvidia-smi echo "### Worker NODE GPU Memory Size" kubectl exec $workerPodName -- nvidia-smi샘플 응답
+-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.90.07 Driver Version: 550.90.07 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA A10G On | 00000000:00:1E.0 Off | 0 | | 0% 33C P0 71W / 300W |19031MiB / 23028MiB <1>| 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ ... +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.90.07 Driver Version: 550.90.07 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA A10G On | 00000000:00:1E.0 Off | 0 | | 0% 30C P0 69W / 300W |18959MiB / 23028MiB <2>| 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+<1> 및 <2> 값을 확인하여 모델이 올바르게 로드되었는지 확인합니다. 모델이 로드되지 않은 경우 이러한 필드의 값은
0MiB입니다.
다음 명령을 사용하여
InferenceService의 상태를 확인합니다.참고기술 프리뷰에서는 유추를 위해 포트 전달만 사용할 수 있습니다.
oc wait --for=condition=ready pod/${podName} -n $DEMO_NAMESPACE --timeout=300s export MODEL_NAME=granite-8b-code-base-pvc샘플 응답
NAME URL READY PREV LATEST PREVROLLEDOUTREVISION LATESTREADYREVISION AGE granite-8b-code-base-pvc http://granite-8b-code-base-pvc.default.example.com모델을 유추할 수 있는지 확인하려면 요청을 보냅니다.Send a request to the model to confirm that the model is available for inference:
oc wait --for=condition=ready pod/${podName} -n vllm-multinode --timeout=300s oc port-forward $podName 8080:8080 & curl http://localhost:8080/v1/completions \ -H "Content-Type: application/json" \ -d "{ 'model': "$MODEL_NAME", 'prompt': 'At what temperature does Nitrogen boil?', 'max_tokens': 100, 'temperature': 0 }"
3.14. 단일 모델 제공 플랫폼에 배포된 모델에 대한 추론 요청 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼을 사용하여 모델을 배포할 때 API 요청을 사용하여 액세스할 수 있는 서비스로 모델을 사용할 수 있습니다. 이를 통해 데이터 입력을 기반으로 예측을 반환할 수 있습니다. API 요청을 사용하여 배포된 모델과 상호 작용하려면 모델의 유추 끝점을 알아야 합니다.
또한 토큰 승인을 활성화하여 유추 끝점을 보호하는 경우 유추 요청에 이를 지정할 수 있도록 권한 부여 토큰에 액세스하는 방법을 알아야 합니다.
3.14.1. 배포된 모델의 권한 부여 토큰 액세스 링크 복사링크가 클립보드에 복사되었습니다!
토큰 권한 부여를 활성화하여 모델 유추 엔드포인트를 보호하는 경우 유추 요청에 지정할 수 있도록 권한 부여 토큰에 액세스하는 방법을 알아야 합니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 단일 모델 제공 플랫폼을 사용하여 모델을 배포했습니다.
프로세스
OpenShift AI 대시보드에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
배포된 모델이 포함된 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
모델 및 모델 서버 목록에서 모델의 섹션을 확장합니다.
권한 부여 토큰은 토큰 권한 부여 섹션의 토큰 시크릿 필드에 표시됩니다.
-
선택 사항: 유추 요청에 사용할 권한 부여 토큰을 복사하려면 토큰 값 옆에 있는 복사 버튼(
)을 클릭합니다.
3.14.2. 배포된 모델의 유추 끝점에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
배포된 모델에 대한 유추 요청을 만들려면 사용 가능한 유추 엔드포인트에 액세스하는 방법을 알아야 합니다.
지원되는 런타임 및 예제 명령과 함께 사용할 경로 목록은 유추 끝점을 참조하십시오.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - 단일 모델 제공 플랫폼을 사용하여 모델을 배포했습니다.
- 배포된 모델에 대한 토큰 권한 부여를 활성화한 경우 연결된 토큰 값이 있습니다.
프로세스
OpenShift AI 대시보드에서 Model Serving 을 클릭합니다.
모델의 유추 끝점은 유추 끝점 필드에 표시됩니다.
- 모델에서 수행하려는 동작에 따라(및 모델이 해당 작업을 지원하는 경우) 유추 끝점을 복사한 다음 URL 끝에 경로를 추가합니다.
- 배포된 모델에 API 요청을 만들려면 끝점을 사용합니다.
3.15. 단일 모델 제공 플랫폼에 대한 모니터링 구성 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼에는 KServe 구성 요소의 지원되는 런타임에 대한 메트릭이 포함되어 있습니다. KServe는 자체 메트릭을 생성하지 않으며 기본 model-serving 런타임을 사용하여 제공합니다. 배포된 모델에 사용 가능한 지표 세트는 모델 제공 런타임에 따라 다릅니다.
KServe의 런타임 메트릭 외에도 OpenShift Service Mesh에 대한 모니터링을 구성할 수도 있습니다. OpenShift Service Mesh 메트릭은 메시의 구성 요소 간 종속성 및 트래픽 흐름을 이해하는 데 도움이 됩니다.
사전 요구 사항
- OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
- OpenShift Service Mesh 및 Knative Serving 인스턴스를 생성하고 KServe를 설치했습니다.
- OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치를 참조하십시오.
- 사용자 정의 워크플로우를 모니터링하기 위한 구성 맵을 생성하는 방법을 알고 있습니다. 이 절차에서는 유사한 단계를 수행합니다.
- OpenShift에서 사용자 정의 프로젝트에 대한 모니터링을 활성화하는 방법을 알고 있습니다. 이 절차에서는 유사한 단계를 수행합니다.
-
메트릭을 모니터링할 사용자에게
monitoring-rules-view역할을 할당 했습니다.
프로세스
터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.
$ oc login <openshift_cluster_url> -u <admin_username> -p <password>다음 콘텐츠를 사용하여
uwm-cm-conf.yaml이라는 YAML 파일에ConfigMap오브젝트를 정의합니다.apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheus: logLevel: debug retention: 15duser-workload-monitoring-config오브젝트는 사용자 정의 프로젝트를 모니터링하는 구성 요소를 구성합니다. 보존 시간이 권장 15일의 값으로 설정되어 있는지 확인합니다.구성을 적용하여
user-workload-monitoring-config오브젝트를 생성합니다.$ oc apply -f uwm-cm-conf.yaml다음 콘텐츠를 사용하여
uwm-cm-enable.yaml이라는 YAML 파일에 다른ConfigMap오브젝트를 정의합니다.apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | enableUserWorkload: truecluster-monitoring-config오브젝트를 사용하면 사용자 정의 프로젝트를 모니터링할 수 있습니다.구성을 적용하여
cluster-monitoring-config오브젝트를 생성합니다.$ oc apply -f uwm-cm-enable.yamlServiceMonitor및PodMonitor오브젝트를 생성하여 다음과 같이 서비스 메시 컨트롤 플레인에서 지표를 모니터링합니다.다음 콘텐츠를 사용하여
istiod-monitor.yamlYAML 파일을 생성합니다.apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: istiod-monitor namespace: istio-system spec: targetLabels: - app selector: matchLabels: istio: pilot endpoints: - port: http-monitoring interval: 30s지정된
istio-system네임스페이스에ServiceMonitorCR을 배포합니다.$ oc apply -f istiod-monitor.yaml다음 출력이 표시됩니다.
servicemonitor.monitoring.coreos.com/istiod-monitor created다음 콘텐츠를 사용하여
istio-proxies-monitor.yamlYAML 파일을 생성합니다.apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: istio-proxies-monitor namespace: istio-system spec: selector: matchExpressions: - key: istio-prometheus-ignore operator: DoesNotExist podMetricsEndpoints: - path: /stats/prometheus interval: 30s지정된
istio-system네임스페이스에PodMonitorCR을 배포합니다.$ oc apply -f istio-proxies-monitor.yaml다음 출력이 표시됩니다.
podmonitor.monitoring.coreos.com/istio-proxies-monitor created
3.16. 단일 모델 제공 플랫폼에 대한 모델 제공 런타임 메트릭 보기 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자가 단일 모델 서비스 플랫폼에 대한 모니터링을 구성한 경우 관리자가 아닌 사용자는 OpenShift 웹 콘솔을 사용하여 KServe 구성 요소의 모델 제공 런타임 지표를 볼 수 있습니다.
사전 요구 사항
- 클러스터 관리자가 단일 모델 제공 플랫폼에 대한 모니터링을 구성했습니다.
-
monitoring-rules-view역할이 할당되었습니다. 자세한 내용은 사용자 정의 프로젝트에 대한 모니터링을 구성할 수 있는 사용자 권한 부여를 참조하십시오. - OpenShift 웹 콘솔에서 프로젝트 메트릭을 모니터링하는 방법에 대해 잘 알고 있습니다. 자세한 내용은 프로젝트 메트릭 모니터링을 참조하십시오.
프로세스
- OpenShift 웹 콘솔에 로그인합니다.
- 개발자 화면으로 전환합니다.
- 왼쪽 메뉴에서 모니터링 을 클릭합니다.
프로젝트 지표 모니터링에 설명된 대로 웹 콘솔을 사용하여 model-serving 런타임 지표에 대한 쿼리를 실행합니다. OpenShift Service Mesh와 관련된 메트릭에 대한 쿼리를 실행할 수도 있습니다. 몇 가지 예가 표시되어 있습니다.
다음 쿼리는 vLLM 런타임으로 배포된 모델의 일정 기간 동안 성공적인 유추 요청 수를 표시합니다.
sum(increase(vllm:request_success_total{namespace=${namespace},model_name=${model_name}}[${rate_interval}]))참고특정 vLLM 메트릭은 배포된 모델에서 유추 요청을 처리한 후에만 사용할 수 있습니다. 이러한 메트릭을 생성하고 보려면 먼저 모델에 대한 유추 요청을 수행해야 합니다.
다음 쿼리는 독립 실행형 TGIS 런타임으로 배포된 모델의 일정 기간 동안 성공적인 유추 요청 수를 표시합니다.
sum(increase(tgi_request_success{namespace=${namespace}, pod=~${model_name}-predictor-.*}[${rate_interval}]))다음 쿼리는 Cakeygent Standalone 런타임으로 배포된 모델의 일정 기간 동안 성공적인 유추 요청 수를 표시합니다.
sum(increase(predict_rpc_count_total{namespace=${namespace},code=OK,model_id=${model_name}}[${rate_interval}]))다음 쿼리는 OpenVINO 모델 서버 런타임으로 배포된 모델의 일정 기간 동안 성공적인 유추 요청 수를 표시합니다.
sum(increase(ovms_requests_success{namespace=${namespace},name=${model_name}}[${rate_interval}]))
3.17. 모델 성능 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼에서 플랫폼에 배포된 특정 모델에 대한 성능 지표를 볼 수 있습니다.
3.17.1. 배포된 모델의 성능 지표 보기 링크 복사링크가 클립보드에 복사되었습니다!
단일 모델 제공 플랫폼에 배포된 특정 모델에 대해 다음 메트릭을 모니터링할 수 있습니다.
- 요청 수 - 특정 모델에 대해 실패하거나 성공한 요청 수입니다.
- 평균 응답 시간(ms) - 요청에 응답하는 데 특정 모델이 걸리는 평균 시간입니다.
- CPU 사용률(%) - 현재 특정 모델에서 사용하는 모델 복제본당 CPU 제한의 백분율입니다.
- 메모리 사용률(%) - 특정 모델에서 사용하는 모델 복제본당 메모리 제한의 백분율입니다.
이러한 메트릭에 대한 시간 범위 및 새로 고침 간격을 지정하여 최대 사용 시간이 있고 지정된 시간에 모델을 수행하는 방법을 결정할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI를 설치했습니다.
- 클러스터 관리자가 OpenShift 클러스터에서 사용자 정의 프로젝트에 대해 UWM(사용자 워크로드 모니터링)을 활성화했습니다. 자세한 내용은 사용자 정의 프로젝트에 대한 모니터링 활성화 및 단일 모델 제공 플랫폼에 대한 모니터링 구성 을 참조하십시오.
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. 다음 대시보드 구성 옵션은 다음과 같이 기본값으로 설정됩니다.
disablePerformanceMetrics:false disableKServeMetrics:false자세한 내용은 대시보드 구성 옵션을 참조하십시오.
사전 설치된 런타임을 사용하여 단일 모델 서비스 플랫폼에 모델을 배포했습니다.
참고메트릭은 사전 설치된 model-serving 런타임 또는 사전 설치된 런타임에서 중복되는 사용자 지정 런타임을 사용하여 배포된 모델에 대해서만 지원됩니다.
프로세스
OpenShift AI 대시보드 탐색 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
- 모니터링할 데이터 과학 모델이 포함된 프로젝트의 이름을 클릭합니다.
- 프로젝트 세부 정보 페이지에서 모델 탭을 클릭합니다.
- 관심 있는 모델을 선택합니다.
끝점 성능 탭에서 다음 옵션을 설정합니다.
- 시간 범위 - 메트릭을 추적하는 기간을 지정합니다. 이 값 중 하나를 선택할 수 있습니다. 1 시간, 24 시간, 7 일 및 30 일.
- 새로 고침 간격 - 메트릭 페이지의 그래프가 새로 고쳐지는 빈도를 지정합니다(최신 데이터를 표시). 이 값 중 하나를 선택할 수 있습니다: 15 초, 30 초, 1 분, 5 분, 15 분, 30 분, 1 시간, 2 시간, 1 일.
- 아래로 스크롤하여 요청 수, 평균 응답 시간, CPU 사용률 및 메모리 사용률에 대한 데이터 그래프를 봅니다.
검증
끝점 성능 탭에는 모델에 대한 메트릭 그래프가 표시되어 있습니다.
3.18. model-serving 런타임 최적화 링크 복사링크가 클립보드에 복사되었습니다!
선택적으로 OpenShift AI에서 사용할 수 있는 사전 설치된 모델 서비스 런타임을 개선하여 최적화된 추론, 대기 시간 감소, 미세 조정된 리소스 할당과 같은 추가 이점과 기능을 활용할 수 있습니다.
3.18.1. 추측 디코딩 및 다중 모드 유추 활성화 링크 복사링크가 클립보드에 복사되었습니다!
대용량 언어 모델( LLM)에 대한 추론 시간을 최적화하는 병렬 처리 기술인 추측 디코딩을 사용하도록 KServe 런타임에 vLLM ServingRuntime 을 구성할 수 있습니다.
또한 VLM(Vision- language models)에 대한 추론을 지원하도록 런타임을 구성할 수도 있습니다. VLM은 시각적 데이터와 텍스트 데이터를 모두 통합하는 멀티모달 모델의 하위 집합입니다.
다음 절차에서는 투기 디코딩 및 다중 모드 유추를 위한 KServe 런타임의 vLLM ServingRuntime 을 사용자 정의하는 방법을 설명합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
- 초안 모델로 추측 디코딩에 vLLM 모델 서비스 런타임을 사용하는 경우 원래 모델과 스펙티브 모델을 S3 호환 오브젝트 스토리지 내의 동일한 폴더에 저장했습니다.
프로세스
- 단계에 따라 단일 모델 제공 플랫폼의 Depyoing 모델에 설명된 대로 모델을 배포합니다.
- Serving 런타임 필드에서 KServe 런타임의 vLLM ServingRuntime을 선택합니다.
프롬프트에서 n-grams를 일치시켜 추측 디코딩을 위해 vLLM 모델-serving 런타임을 구성하려면 구성 매개변수 섹션의 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
--speculative-model=[ngram] --num-speculative-tokens=<NUM_SPECULATIVE_TOKENS> --ngram-prompt-lookup-max=<NGRAM_PROMPT_LOOKUP_MAX> --use-v2-block-manager<
NUM_SPECULATIVE_TOKENS> 및 <NGRAM_PROMPT_LOOKUP_MAX>를 사용자 값으로 바꿉니다.참고유추 처리량은 n-gram로 추측하는 데 사용되는 모델에 따라 다릅니다.
초안 모델을 사용하여 추측 디코딩을 위해 vLLM 모델 제공 런타임을 구성하려면 구성 매개변수 섹션에서 추가 제공 런타임 인수 아래에 다음 인수를 추가합니다.
--port=8080 --served-model-name={{.Name}} --distributed-executor-backend=mp --model=/mnt/models/<path_to_original_model> --speculative-model=/mnt/models/<path_to_speculative_model> --num-speculative-tokens=<NUM_SPECULATIVE_TOKENS> --use-v2-block-manager-
<
path_to_speculative_model> 및 <path_to_original_model>을 speculative model 및 original model의 경로로 S3 호환 오브젝트 스토리지의 경로로 바꿉니다. -
&
lt;NUM_SPECULATIVE_TOKENS>를 사용자 값으로 바꿉니다.
-
<
다중 모드 추론에 대한 vLLM 모델 서비스 런타임을 구성하려면 구성 매개변수 섹션의 추가 제공 런타임 아래에 다음 인수를 추가합니다.
--trust-remote-code참고신뢰할 수 있는 소스의 모델에는
--trust-remote-code인수만 사용하십시오.- Deploy 를 클릭합니다.
검증
추측 디코딩을 위해 vLLM 모델-serving 런타임을 구성한 경우 다음 예제 명령을 사용하여 배포된 모델에 대한 API 요청을 확인합니다.
curl -v https://<inference_endpoint_url>:443/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer <token>"다중 모드 유추를 위해 vLLM 모델 서비스 런타임을 구성한 경우 다음 예제 명령을 사용하여 배포된 VLM(Vuality- language)에 대한 API 요청을 확인합니다.
curl -v https://<inference_endpoint_url>:443/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer <token>" -d '{"model":"<model_name>", "messages": [{"role":"<role>", "content": [{"type":"text", "text":"<text>" }, {"type":"image_url", "image_url":"<image_url_link>" } ] } ] }'
3.19. 성능 최적화 및 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
3.19.1. Cryostat 기반 애플리케이션에 대한 GPU 요구 사항 확인 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift AI에서 호스팅되는 LLM( Large Language Model)에서 제공하는 애플리케이션의 GPU를 선택할 때 고려해야 할 몇 가지 요인이 있습니다.
다음 지침은 모델의 크기 및 예상 사용량에 따라 애플리케이션의 하드웨어 요구 사항을 결정하는 데 도움이 됩니다.
-
메모리 추정 요구 사항: 엄지엄 규칙의 일반적인 규칙은
N매개 변수가 16비트 정확도로 있는 모델에는 약2N바이트의 GPU 메모리가 필요하다는 것입니다. 예를 들어 8billion-parameter 모델에는 약 16GB의 GPU 메모리가 필요하지만 70-billion-parameter 모델에는 약 140GB가 필요합니다. 정량화: 메모리 요구 사항을 줄이고 처리량을 높이기 위해 INT8, FP8 또는 INT4와 같은 하위 조각 형식으로 모델을 로드하거나 실행할 수 있습니다. 이렇게 하면 모델 정확도가 약간 감소하는 대신 메모리 풋프린트를 줄일 수 있습니다.
참고KServe 모델의 vLLM ServingRuntime 은 여러 정량화 방법을 지원합니다. 지원되는 구현 및 호환 하드웨어에 대한 자세한 내용은 정량화 커널에 대한 지원 하드웨어를 참조하십시오.
- 키-값 캐시를 위한 추가 메모리: 모델 가중치 외에도 GPU 메모리는 요청 수와 각 요청의 시퀀스 길이에 따라 증가하는 attention key-value (KV) 캐시를 저장해야 합니다. 이는 특히 대규모 모델의 실시간 애플리케이션의 성능에 영향을 미칠 수 있습니다.
권장 GPU 구성:
- 소규모 모델 (1B-8B 매개변수): 범위의 모델의 경우 일반적으로 24GB의 메모리가 있는 GPU로 적은 수의 동시 사용자를 지원할 수 있습니다.
중간 모델 (10B-34B 매개변수):
- 20B 매개변수 미만의 모델에는 최소 48GB의 GPU 메모리가 필요합니다.
- 20B - 34B 매개변수 사이의 모델에는 단일 GPU에서 최소 80GB 이상의 메모리가 필요합니다.
- Large Models (70B parameters): 이 범위의 모델은 수십 개의 병렬 처리 기술을 사용하여 여러 GPU에 분산되어야 할 수 있습니다. 텐서 병렬 처리를 통해 모델은 여러 GPU에 걸쳐서 토큰 간 대기 시간을 개선하고 KV 캐시에 대한 추가 메모리를 확보하여 최대 배치 크기를 늘릴 수 있습니다. 텐서 병렬 처리는 GPU가 NVLink와 같은 빠른 상호 연결을 가질 때 가장 잘 작동합니다.
- 매우 큰 모델 (405B 매개변수): 매우 큰 모델의 경우 메모리 요구 사항을 줄이기 위해 정량화하는 것이 좋습니다. 여러 GPU에 파이프라인 병렬 처리를 사용하거나 두 서버에 걸쳐 모델을 배포할 수도 있습니다. 이 방법을 사용하면 단일 서버의 메모리 제한을 초과할 수 있지만 최적의 성능을 위해 서버 간 통신을 신중하게 관리해야 합니다.
최상의 결과를 얻으려면 더 작은 모델로 시작한 다음 필요에 따라 더 큰 모델로 확장되며 병렬 처리 및 정량화와 같은 기술을 사용하여 성능 및 메모리 요구 사항을 충족할 수 있습니다.
3.19.2. text-summarization 및 retrieval-augmented generation (RAG) 애플리케이션에 대한 성능 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
텍스트 사용량 및 RAG 애플리케이션은 물론 사용자가 업로드한 대용량 문서를 처리하는 Cryostat 기반 서비스를 고려해야 하는 추가 요인이 있습니다.
- 입력 순서: 각 사용자 쿼리에 업로드된 문서와 같은 많은 컨텍스트가 포함된 경우 일반적인 채팅 애플리케이션보다 입력 시퀀스 길이가 상당히 길 수 있습니다. 더 긴 입력 시퀀스 길이는 미리 채우기 시간을 늘립니다. 이 경우 모델이 응답을 생성하기 전에 초기 입력 시퀀스를 처리하는 데 걸리는 시간이 늘어남에 따라 TTFT(Time-to-First-Token) 가 증가할 수 있습니다. 더 긴 TTFT는 애플리케이션의 응답에 영향을 미칠 수 있습니다. 사용자 환경을 최적화하려면 이러한 대기 시간을 최소화합니다.
- KV 캐시 사용: 긴 시퀀스에는 KV(키 값) 캐시에 더 많은 GPU 메모리가 필요합니다. KV 캐시는 중간 관심 데이터를 저장하여 생성 중에 모델 성능을 향상시킵니다. 요청당 KV 캐시 사용률이 높은 경우 충분한 GPU 메모리가 있는 하드웨어 설정이 필요합니다. 이는 각 요청이 총 메모리 로드에 추가되므로 여러 사용자가 동시에 모델을 쿼리하는 경우 특히 중요합니다.
- 최적의 하드웨어 구성: 응답성을 유지하고 메모리 병목 현상을 방지하려면 충분한 메모리가 있는 GPU 구성을 선택합니다. 예를 들어 단일 24GB GPU에서 8B 모델을 실행하는 대신 더 큰 GPU(예: 48GB 또는 80GB)에 배포하거나 여러 GPU에 분산하면 KV 캐시에 더 많은 메모리 헤드룸을 제공하고 토큰 간 대기 시간을 줄임으로써 성능을 향상시킬 수 있습니다. 수십 개의 병렬 처리를 통한 다중 GPU 설정은 메모리 요구 사항을 관리하고 더 큰 입력 시퀀스의 효율성을 개선하는 데 도움이 될 수 있습니다.
요약하면 문서 기반 애플리케이션에 대한 최적의 응답성 및 확장성을 보장하기 위해 GPU 메모리 용량이 높은 하드웨어에 우선 순위를 지정하고 긴 입력 시퀀스 및 KV 캐싱의 증가된 메모리 요구 사항을 처리하기 위해 다중 GPU 구성도 고려해야 합니다.
3.19.3. 유추 성능 지표 링크 복사링크가 클립보드에 복사되었습니다!
대기 시간,처리량 및 비용 100만 개 토큰은 유추하는 동안 모델의 응답 생성 효율성을 평가할 때 고려해야 할 주요 지표입니다. 이러한 메트릭은 모델의 유추 성능에 대한 포괄적인 보기를 제공하며 다양한 사용 사례에 대한 속도, 효율성 및 비용 균형을 유지할 수 있습니다.
3.19.3.1. latency 링크 복사링크가 클립보드에 복사되었습니다!
대기 시간은 대화형 또는 실시간 사용 사례에 중요하며 다음 메트릭을 사용하여 측정됩니다.
- time-to-First-Token (TTFT) : 초기 요청과 첫 번째 토큰 생성 사이의 지연 시간 (밀리초)입니다. 이 메트릭은 스트리밍 응답에 중요합니다.
- 토큰 간 대기 시간(ITL): 첫 번째 이후 각 후속 토큰을 생성하는 데 밀리초로, 스트리밍과 관련된 시간(밀리초) 입니다.
- TPOT(Time-Per-Output-Token): 스트리밍 이외의 요청의 경우 출력 순서에서 각 토큰을 생성하는 데 걸리는 평균 시간(밀리초)입니다.
3.19.3.2. 처리량 링크 복사링크가 클립보드에 복사되었습니다!
처리량 은 모델 서버의 전반적인 효율성을 측정하고 다음 메트릭으로 표시됩니다.
- Second (TPS): 모든 활성 요청에서 초당 생성된 총 토큰 수입니다.
- 초당 요청(RPS): 초당 처리된 요청 수입니다. RPS는 응답 시간과 마찬가지로 시퀀스 길이에 민감합니다.
3.19.3.3. 토큰당 비용 링크 복사링크가 클립보드에 복사되었습니다!
100만개의 토큰당 비용이 생성되는 비용을 표시하여 모델 추론의 비용 효율성을 측정합니다. 이 메트릭은 모델 배포의 경제적 가능성과 확장성을 모두 평가하는 데 도움이 됩니다.
3.19.4. 메모리 부족 오류 해결 링크 복사링크가 클립보드에 복사되었습니다!
어떤 경우에는 사용된 모델 및 하드웨어 가속기에 따라 TGIS 메모리 자동 튜닝 알고리즘은 긴 시퀀스를 처리하는 데 필요한 GPU 메모리 양을 과소평가할 수 있습니다. 이러한 오류로 인해 모델 서버의 Compute Unified Architecture (CUDA) 메모리 부족(OOM) 오류 응답이 발생할 수 있습니다. 이러한 경우 다음 절차에 설명된 대로 TGIS 모델 제공 런타임에서 매개변수를 업데이트하거나 추가해야 합니다.
사전 요구 사항
- OpenShift AI 관리자 권한이 있는 사용자로 OpenShift AI에 로그인했습니다.
프로세스
OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.
Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.
모델을 배포하는 데 사용한 런타임에 따라 다음 작업 중 하나를 수행합니다.
- KServe 런타임에 사전 설치된 TGIS Standalone ServingRuntime을 사용한 경우 런타임을 복제하여 사용자 지정 버전을 생성한 다음 이 절차의 나머지 부분을 따릅니다. 사전 설치된 TGIS 런타임 중복에 대한 자세한 내용은 단일 모델 제공 플랫폼의 사용자 지정 모델 제공 런타임 추가를 참조하십시오.
사용자 지정 TGIS 런타임을 이미 사용 중인 경우 런타임 옆에 있는 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.
포함된 YAML 편집기가 열리고 사용자 정의 model-serving 런타임 내용이 표시됩니다.
BATCH_SAFETY_MARGIN환경 변수를 추가하거나 업데이트하고 값을 30으로 설정합니다. 마찬가지로ESTIMATE_MEMORY_BATCH_SIZE환경 변수를 추가하거나 업데이트하고 값을 8로 설정합니다.spec: containers: env: - name: BATCH_SAFETY_MARGIN value: 30 - name: ESTIMATE_MEMORY_BATCH value: 8참고BATCH_SAFETY_MARGIN매개변수는 OOM 조건을 피하기 위해 사용 가능한 GPU 메모리의 백분율을 설정합니다.BATCH_SAFETY_MARGIN의 기본값은20입니다.ESTIMATE_MEMORY_BATCH_SIZE매개 변수는 메모리 자동 튜닝 알고리즘에 사용되는 배치 크기를 설정합니다.ESTIMATE_MEMORY_BATCH_SIZE의 기본값은16입니다.업데이트를 클릭합니다.
Serving 런타임 페이지가 열리고 설치된 런타임 목록이 표시됩니다. 업데이트된 사용자 정의 모델 제공 런타임이 표시되는지 확인합니다.
매개변수 업데이트를 적용하기 위해 모델을 재배포하려면 다음 작업을 수행합니다.
- OpenShift AI 대시보드에서 Model Serving > Deployed Models 를 클릭합니다.
- 재배포할 모델을 찾고 모델 옆에 있는 작업 메뉴( Cryostat)를 클릭하고 삭제 를 선택합니다.
- 단일 모델 제공 플랫폼에서 모델 배포에 설명된 대로 모델을 재배포합니다.
검증
- 모델 서버에서 성공적으로 응답이 수신되고 더 이상 CUDA OOM 오류가 표시되지 않습니다.
3.20. NVIDIA NIM 모델 제공 플랫폼 정보 링크 복사링크가 클립보드에 복사되었습니다!
NVIDIA NIM 추론 서비스를 사용하여 NVIDIA NIM 모델 제공 플랫폼에서 모델을 배포할 수 있습니다.
NVIDIA AI Enterprise의 일부인 NVIDIA NIM은 클라우드, 데이터 센터 및 워크스테이션 전반에 걸쳐 고성능 AI 모델 추론을 안전하고 안정적으로 배포하도록 설계된 일련의 마이크로서비스입니다.
3.20.1. NVIDIA NIM 모델 제공 플랫폼 활성화 링크 복사링크가 클립보드에 복사되었습니다!
관리자는 Red Hat OpenShift AI 대시보드를 사용하여 NVIDIA NIM 모델 서비스 플랫폼을 활성화할 수 있습니다.
이전에 OpenShift AI 2.14 또는 2.15에서 NVIDIA NIM 모델 서비스를 활성화한 다음 최신 버전으로 업그레이드한 경우 NVIDIA NGC API 키를 다시 입력하여 NVIDIA NIM 모델 제공 플랫폼을 다시 활성화합니다.
사전 요구 사항
- Red Hat OpenShift AI에 관리자로 로그인했습니다.
- 단일 모델 제공 플랫폼을 활성화했습니다. 사전 설치된 런타임을 활성화할 필요가 없습니다. 단일 모델 제공 플랫폼 활성화에 대한 자세한 내용은 단일 모델 제공 플랫폼 활성화를 참조하십시오.
다음 OpenShift AI 대시보드 구성이 활성화되어 있습니다.
disableNIMModelServing: false자세한 내용은 대시보드 구성 옵션을 참조하십시오.
- OpenShift AI에서 GPU 지원을 활성화했습니다. 자세한 내용은 NVIDIA GPU 활성화를 참조하십시오.
- NVIDIA Cloud Account(NCA)를 보유하고 있으며 NVIDIA GPU Cloud(NGC) 포털에 액세스할 수 있습니다. 자세한 내용은 NVIDIA GPU Cloud 사용자 가이드를 참조하십시오.
- NCA 계정이 NVIDIA AI Enterprise Viewer 역할과 연결되어 있습니다.
- NGC 포털에서 NGC API 키를 생성했습니다. 자세한 내용은 NGC API 키를 참조하십시오.
프로세스
- OpenShift AI에 로그인합니다.
- OpenShift AI 대시보드의 왼쪽 메뉴에서 애플리케이션 → 탐색을 클릭합니다.
- 탐색 페이지에서 NVIDIA NIM 타일을 찾습니다.
- 애플리케이션 타일에서 사용을 클릭합니다.
- NGC API 키를 입력한 다음 Submit 을 클릭합니다.
검증
- 활성화한 NVIDIA NIM 애플리케이션이 사용됨 페이지에 표시됩니다.
3.20.2. NVIDIA NIM 모델 제공 플랫폼에 모델 배포 링크 복사링크가 클립보드에 복사되었습니다!
NVIDIA NIM 모델 제공 플랫폼을 활성화하면 플랫폼에 NVIDIA에 최적화된 모델을 배포할 수 있습니다.
사전 요구 사항
- Red Hat OpenShift AI에 로그인했습니다.
-
OpenShift AI 그룹을 사용하는 경우 OpenShift의 사용자 그룹 또는 관리자 그룹(예:
rhoai-users또는rhoai-admins)의 일부입니다. - NVIDIA NIM 모델 제공 플랫폼을 활성화했습니다.
- 데이터 과학 프로젝트를 생성했습니다.
- OpenShift AI에서 GPU(그래픽 처리 단위)에 대한 지원이 활성화되어 있습니다. 여기에는 Node Feature Discovery Operator 및 NVIDIA GPU Operator 설치가 포함됩니다. 자세한 내용은 Node Feature Discovery Operator 설치 및 NVIDIA GPU 활성화를 참조하십시오.
프로세스
왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.
Data Science Projects 페이지가 열립니다.
모델을 배포할 프로젝트의 이름을 클릭합니다.
프로젝트 세부 정보 페이지가 열립니다.
- 모델 탭을 클릭합니다.
모델 섹션에서 다음 작업 중 하나를 수행합니다.
- NVIDIA NIM 모델 서비스 플랫폼 타일에서 타일 에서 NVIDIA NIM 선택을 클릭한 다음 모델 배포를 클릭합니다.
- 이전에 NVIDIA NIM 모델 제공 유형을 선택한 경우 모델 페이지에는 배포 모델 버튼과 함께 오른쪽 상단에 NVIDIA 모델 서비스가 활성화됩니다. 계속하려면 배포 모델을 클릭합니다.
모델 배포 대화 상자가 열립니다.
다음과 같이 모델 배포를 위한 속성을 구성합니다.
- 모델 배포 이름 필드에 배포에 대한 고유한 이름을 입력합니다.
- NVIDIA NIM 목록에서 배포하려는 NVIDIA NIM 모델을 선택합니다. 자세한 내용은 지원 모델을 참조하십시오.
- NVIDIA NIM 스토리지 크기 필드에서 NVIDIA NIM 모델을 저장하도록 생성될 클러스터 스토리지 인스턴스의 크기를 지정합니다.
- 배포할 모델 서버 복제본 수에서 값을 지정합니다.In the Number of model server replicas to deploy field, specify a value.
- 모델 서버 크기 목록에서 값을 선택합니다.From the Model server size list, select a value.
액셀러레이터 목록에서 가속기 를 선택합니다.
액셀러레이터 필드가 표시됩니다.
- 수 의 가속기 필드에서 사용할 가속기의 수를 지정합니다. 기본값은 1입니다.
- Deploy 를 클릭합니다.
검증
- 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.