모델 제공

Red Hat OpenShift AI Cloud Service 1

Red Hat OpenShift AI Cloud Service에서 모델 제공

초록

Red Hat OpenShift AI Cloud Service에서 모델을 제공합니다. 숙련된 모델을 사용하면 지능형 애플리케이션에 테스트 및 구현할 수 있습니다.

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. 다중 모델 서비스 플랫폼 활성화

다중 모델 서비스 플랫폼을 사용하려면 먼저 플랫폼을 활성화해야 합니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 admin 그룹(예: rhoai-admins)의 일부입니다.
  • 클러스터 관리자가 ModelMesh 구성 요소를 사용하는 다중 모델 제공 플랫폼을 선택하는 기능을 비활성화하도록 OpenShift AI 대시보드 구성을 편집 하지 않았습니다. 자세한 내용은 대시보드 구성 옵션을 참조하십시오.

프로세스

  1. OpenShift AI 대시보드의 왼쪽 메뉴에서 설정클러스터 설정을 클릭합니다.
  2. 모델 제공 플랫폼 섹션을 찾습니다.
  3. Multi-model serving platform 확인란을 선택합니다.
  4. 변경 사항 저장을 클릭합니다.

2.1.2. 다중 모델 서비스 플랫폼에 대한 사용자 정의 모델 서비스 런타임 추가

모델 서비스 런타임은 지정된 모델 프레임워크 집합(즉, 형식)에 대한 지원을 추가합니다. 기본적으로 다중 모델 제공 플랫폼에는 OpenVINO 모델 서버 런타임이 포함됩니다. 그러나 이 런타임이 요구 사항을 충족하지 않는 경우(예: 특정 모델 형식을 지원하지 않음) 고유한 사용자 지정 런타임을 추가할 수 있습니다.

관리자는 Red Hat OpenShift AI 대시보드를 사용하여 사용자 지정 모델 제공 런타임을 추가하고 활성화할 수 있습니다. 그런 다음 다중 모델 제공 플랫폼에 대한 새 모델 서버를 만들 때 사용자 지정 런타임을 선택할 수 있습니다.

참고

OpenShift AI를 사용하면 고유한 사용자 지정 런타임을 추가할 수 있지만 런타임 자체를 지원하지는 않습니다. 사용자 지정 런타임을 올바르게 구성하고 유지 관리해야 합니다. 또한 사용자가 추가한 모든 사용자 지정 런타임을 사용할 수 있는지 확인해야 합니다.

사전 요구 사항

  • 관리자로 OpenShift AI에 로그인했습니다.
  • 프로젝트에 모델 서버를 추가하는 방법에 대해 잘 알고 있습니다. 사용자 지정 model-serving 런타임을 추가한 경우 런타임을 사용하도록 새 모델 서버를 구성해야 합니다.
  • kserve/modelmesh-serving 리포지토리에서 예제 런타임을 검토했습니다. 이러한 예제를 시작점으로 사용할 수 있습니다. 그러나 OpenShift AI에 배포하려면 각 런타임에 몇 가지 추가 수정이 필요합니다. 필요한 수정 사항은 다음 절차에 설명되어 있습니다.

    참고

    OpenShift AI에는 기본적으로 OpenVINO 모델 서버 런타임이 포함되어 있습니다. 이 런타임을 OpenShift AI에 추가할 필요가 없습니다.

프로세스

  1. OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.

    Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.

  2. 사용자 지정 런타임을 추가하려면 다음 옵션 중 하나를 선택합니다.

    • 기존 런타임(예: OpenVINO 모델 서버 런타임)으로 시작하려면 기존 런타임 옆에 있는 작업 메뉴( Cryostat)를 클릭한 다음 중복 을 클릭합니다.
    • 새 사용자 지정 런타임을 추가하려면 제공 런타임 추가 를 클릭합니다.
  3. Select the model serving platforms this runtime supports list, select Multi-model serving platform.

    참고

    다중 모델 제공 플랫폼은 REST 프로토콜만 지원합니다. 따라서 이 런타임에서 지원하는 API 프로토콜 선택에서 기본값을 변경할 수 없습니다.

  4. 선택 사항: 새 런타임을 시작한 경우(기존 런타임을 복제하지 않고) 다음 옵션 중 하나를 선택하여 코드를 추가합니다.

    • YAML 파일 업로드

      1. 파일 업로드 를 클릭합니다.
      2. 파일 브라우저에서 컴퓨터에서 YAML 파일을 선택합니다. 이 파일은 kserve/modelmesh-serving 리포지토리에서 다운로드한 예제 런타임 중 하나일 수 있습니다.

        포함된 YAML 편집기가 열리고 업로드한 파일의 내용이 표시됩니다.

    • 편집기에서 직접 YAML 코드를 입력합니다.

      1. 처음부터 시작을 클릭합니다.
      2. 포함된 편집기에서 YAML 코드를 직접 입력하거나 붙여넣습니다. 생성하는 YAML은 kserve/modelmesh-serving 리포지토리의 예제 런타임 중 하나에서 복사할 수 있습니다.
  5. 선택 사항: kserve/modelmesh-serving 리포지토리에 예제 런타임 중 하나를 추가하는 경우 다음 수정을 수행합니다.

    1. YAML 편집기에서 런타임의 kind 필드를 찾습니다. 이 필드의 값을 ServingRuntime 으로 업데이트합니다.
    2. kserve/modelmesh-serving 리포지토리의 kustomization.yaml 파일에서 추가할 런타임의 newNamenewTag 값을 기록해 둡니다. 이후 단계에서 이러한 값을 지정합니다.
    3. 사용자 지정 런타임의 YAML 편집기에서 containers.image 필드를 찾습니다.
    4. 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
  6. metadata.name 필드에서 추가하는 런타임 값이 고유해야 합니다(즉, 값이 이미 추가한 런타임과 일치하지 않음).
  7. 선택 사항: 추가하는 런타임에 사용자 정의 표시 이름을 구성하려면 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 필드의 값이 표시됩니다.

  8. 추가를 클릭합니다.

    Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 런타임이 자동으로 활성화되어 있는지 확인합니다.

  9. 선택 사항: 사용자 지정 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.

검증

  • 추가한 사용자 정의 모델 제공 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.

추가 리소스

2.1.3. 다중 모델 서비스 플랫폼용 모델 서버 추가

다중 모델 제공 플랫폼을 활성화한 경우 모델을 배포하도록 모델 서버를 구성해야 합니다. 대규모 데이터 집합과 함께 사용할 추가 컴퓨팅 성능이 필요한 경우 모델 서버에 가속기를 할당할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins )의 일부입니다.
  • 모델 서버를 추가할 수 있는 데이터 사이언스 프로젝트를 생성했습니다.
  • 다중 모델 서비스 플랫폼을 활성화했습니다.
  • 모델 서버에 사용자 지정 model-serving 런타임을 사용하려면 런타임을 추가하고 활성화했습니다. 사용자 지정 model-serving 런타임 추가 를 참조하십시오.
  • 모델 서버에서 GPU(그래픽 처리 장치)를 사용하려는 경우 OpenShift AI에서 GPU 지원을 활성화했습니다. OpenShift AI에서 GPU 지원 활성화를 참조하십시오.

프로세스

  1. OpenShift AI 대시보드의 왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 모델 서버를 구성할 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 다음 작업 중 하나를 수행합니다.

    • 플랫폼 타일을 제공하는 다중 모델이 표시되면 타일에서 모델 서버 추가 를 클릭합니다.
    • 타일이 표시되지 않으면 모델 서버 추가 버튼을 클릭합니다.

    모델 서버 추가 대화 상자가 열립니다.

  5. 모델 서버 이름 필드에 모델 서버의 고유 이름을 입력합니다.
  6. Serving 런타임 목록에서 OpenShift AI 배포에 설치 및 활성화된 모델 서비스 런타임을 선택합니다.

    참고

    모델 서버와 함께 사용자 지정 모델 서비스 런타임을 사용하고 GPU를 사용하려면 사용자 지정 런타임에서 GPU를 지원하고 이를 사용하도록 적절히 구성되어 있는지 확인해야 합니다.

  7. 배포할 모델 복제본 수 에서 값을 지정합니다.
  8. 모델 서버 크기 목록에서 값을 선택합니다.From the Model server size list, select a value.
  9. 선택 사항: 이전 단계에서 Custom 을 선택한 경우 모델 서버 크기 섹션에서 다음 설정을 구성하여 모델 서버 를 사용자 지정합니다.

    1. CPU 요청 필드에서 모델 서버와 함께 사용할 CPU 수를 지정합니다. 이 필드 옆에 있는 목록을 사용하여 코어 또는 밀리코어에 값을 지정합니다.
    2. CPU 제한 필드에서 모델 서버에 사용할 최대 CPU 수를 지정합니다. 이 필드 옆에 있는 목록을 사용하여 코어 또는 밀리코어에 값을 지정합니다.
    3. 메모리 요청 필드에서 모델 서버의 요청된 메모리를 기비바이트(Gi)로 지정합니다.
    4. 메모리 제한 필드에서 모델 서버의 최대 메모리 제한을 기가바이트(Gi)로 지정합니다.
  10. 선택 사항: 액셀러레이터 목록에서 가속기를 선택합니다.

    1. 이전 단계에서 가속기를 선택한 경우 사용할 가속기 수를 지정합니다.
  11. 선택 사항: 모델 경로 섹션에서 외부 경로 확인란을 통해 사용 가능한 배포된 모델 만들기 확인란을 선택하여 배포된 모델을 외부 클라이언트에서 사용할 수 있도록 합니다.
  12. 선택 사항: 토큰 권한 부여 섹션에서 모델 서버에 대한 토큰 인증 필요 확인란을 선택합니다. 토큰 인증 구성을 완료하려면 다음 작업을 수행합니다.

    1. 서비스 계정 이름 필드에 토큰이 생성될 서비스 계정 이름을 입력합니다. 모델 서버가 구성되면 생성된 토큰이 토큰 시크릿 필드에 생성되고 표시됩니다.
    2. 추가 서비스 계정을 추가하려면 서비스 계정 추가를 클릭하고 다른 서비스 계정 이름을 입력합니다.
  13. 추가를 클릭합니다.

    • 구성한 모델 서버는 모델 모델 서버 목록에 프로젝트의 모델 탭에 표시됩니다.
  14. 선택 사항: 모델 서버를 업데이트하려면 모델 서버 옆에 있는 작업 메뉴( Cryostat )를 클릭하고 모델 서버 편집을 선택합니다.

2.1.4. 모델 서버 삭제

모델을 호스팅하는 모델 서버가 더 이상 필요하지 않으면 데이터 사이언스 프로젝트에서 제거할 수 있습니다.

참고

모델 서버를 제거하면 해당 모델 서버에서 호스팅되는 모델도 제거됩니다. 따라서 애플리케이션에서 더 이상 모델을 사용할 수 없습니다.

사전 요구 사항

  • 데이터 사이언스 프로젝트 및 관련 모델 서버를 생성했습니다.
  • 모델을 더 이상 사용할 수 없는 모델에 액세스하는 애플리케이션에 대한 알림을 받았습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.

프로세스

  1. OpenShift AI 대시보드에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 모델 서버를 삭제할 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 삭제할프로젝트 옆에 있는 작업 메뉴( Cryostat )를 클릭한 다음 모델 서버 삭제 를 클릭합니다.

    모델 서버 삭제 대화 상자가 열립니다.

  5. 텍스트 필드에 모델 서버의 이름을 입력하여 삭제하려는지 확인합니다.
  6. 모델 서버 삭제를 클릭합니다.

검증

  • 삭제한 모델 서버는 더 이상 프로젝트의 모델 탭에 표시되지 않습니다.

2.2. 배포된 모델 작업

2.2.1. 다중 모델 서비스 플랫폼을 사용하여 모델 배포

OpenShift AI에 숙련된 모델을 배포하여 지능형 애플리케이션에 테스트하고 구현할 수 있습니다. 모델을 배포하면 API를 사용하여 액세스할 수 있는 서비스로 사용할 수 있습니다. 이를 통해 데이터 입력을 기반으로 예측을 반환할 수 있습니다.

다중 모델 서비스 플랫폼을 활성화하면 플랫폼에 모델을 배포할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users)의 일부입니다.
  • 다중 모델 서비스 플랫폼을 활성화했습니다.
  • 데이터 사이언스 프로젝트를 생성하고 모델 서버를 추가했습니다.
  • S3 호환 오브젝트 스토리지에 액세스할 수 있습니다.
  • 배포하려는 모델의 경우 S3 호환 오브젝트 스토리지 버킷의 관련 폴더 경로를 알고 있습니다.

프로세스

  1. OpenShift AI 대시보드의 왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 모델을 배포할 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 모델 배포를 클릭합니다.
  5. 다음과 같이 모델 배포를 위한 속성을 구성합니다.

    1. 모델 이름 필드에 배포하려는 모델의 고유 이름을 입력합니다.
    2. 모델 프레임워크 목록에서 모델의 프레임워크를 선택합니다.

      참고

      모델 프레임워크 목록은 모델 서버를 구성할 때 지정한 model-serving 런타임에서 지원하는 프레임워크만 표시합니다.

    3. S3 호환 오브젝트 스토리지에서 배포할 모델의 위치를 지정하려면 다음 작업 세트 중 하나를 수행합니다.

      • 기존 데이터 연결 사용

        1. 기존 데이터 연결을 선택합니다.
        2. 이름 목록에서 이전에 정의한 데이터 연결을 선택합니다.
        3. 경로 필드에서 지정된 데이터 소스에 모델이 포함된 폴더 경로를 입력합니다.
      • 새 데이터 연결 사용

        1. 모델에 액세스할 수 있는 새 데이터 연결을 정의하려면 새 데이터 연결을 선택합니다.
        2. 이름 필드에 데이터 연결의 고유 이름을 입력합니다.
        3. 액세스 키 필드에 S3 호환 오브젝트 스토리지 공급자의 액세스 키 ID를 입력합니다.
        4. Secret 키 필드에 지정한 S3 호환 오브젝트 스토리지 계정의 시크릿 액세스 키를 입력합니다.
        5. Endpoint 필드에 S3 호환 오브젝트 스토리지 버킷의 끝점을 입력합니다.
        6. Region 필드에 S3 호환 오브젝트 스토리지 계정의 기본 리전을 입력합니다.
        7. Bucket 필드에 S3 호환 오브젝트 스토리지 버킷의 이름을 입력합니다.
        8. 경로 필드에 데이터 파일이 포함된 S3 호환 오브젝트 스토리지에 폴더 경로를 입력합니다.
    4. Deploy 를 클릭합니다.

검증

  • 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.

2.2.2. 배포된 모델 보기

작업 결과를 분석하려면 Red Hat OpenShift AI에 배포된 모델 목록을 볼 수 있습니다. 배포된 모델 및 해당 끝점의 현재 상태를 볼 수도 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.

프로세스

  1. OpenShift AI 대시보드에서 Model Serving 을 클릭합니다.

    배포된 모델 페이지가 열립니다.

    각 모델에 대해 페이지에는 모델 이름, 모델이 배포되는 프로젝트, 모델이 사용하는 model-serving 런타임, 배포 상태와 같은 세부 정보가 표시됩니다.

  2. 선택 사항: 지정된 모델의 경우 유추 끝점 열의 링크를 클릭하여 배포된 모델의 유추 끝점을 확인합니다.

검증

  • 이전에 배포된 데이터 사이언스 모델 목록은 배포된 모델 페이지에 표시됩니다.

2.2.3. 배포된 모델의 배포 속성 업데이트

이전에 배포된 모델의 배포 속성을 업데이트할 수 있습니다. 이를 통해 모델의 데이터 연결 및 이름을 변경할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • OpenShift AI에 모델을 배포했습니다.

프로세스

  1. OpenShift AI 대시보드에서 모델 제공 을 클릭합니다.

    배포된 모델 페이지가 열립니다.

  2. 업데이트할 배포 속성이 있는 모델 옆에 있는 작업 메뉴( )를 클릭하고 편집을 클릭합니다.

    모델 배포 대화 상자가 열립니다.

  3. 다음과 같이 모델의 배포 속성을 업데이트합니다.

    1. 모델 이름 필드에 모델의 고유 이름을 새로 입력합니다.
    2. 모델 프레임워크 목록에서 모델의 프레임워크를 선택합니다.

      참고

      모델 프레임워크 목록은 모델 서버를 구성할 때 지정한 model-serving 런타임에서 지원하는 프레임워크만 표시합니다.

    3. 모델의 위치를 지정하는 방법을 업데이트하려면 다음 작업 세트 중 하나를 수행합니다.

      • 이전에 기존 데이터 연결을 지정한 경우

        1. 경로 필드에서 지정된 데이터 소스에 모델이 포함된 폴더 경로를 업데이트합니다.
      • 이전에 새 데이터 연결을 지정한 경우

        1. 이름 필드에서 데이터 연결의 고유 이름을 업데이트합니다.
        2. Access 키 필드에서 S3 호환 오브젝트 스토리지 공급자의 액세스 키 ID를 업데이트합니다.
        3. Secret 키 필드에서 지정한 S3 호환 오브젝트 스토리지 계정의 시크릿 액세스 키를 업데이트합니다.
        4. Endpoint 필드에서 S3 호환 오브젝트 스토리지 버킷의 끝점을 업데이트합니다.
        5. Region 필드에서 S3 호환 오브젝트 스토리지 계정의 기본 리전을 업데이트합니다.
        6. Bucket 필드에서 S3 호환 오브젝트 스토리지 버킷의 이름을 업데이트합니다.
        7. 경로 필드에서 데이터 파일이 포함된 S3 호환 오브젝트 스토리지의 폴더 경로를 업데이트합니다.
    4. Deploy 를 클릭합니다.

검증

  • 업데이트된 배포 속성이 대시보드의 모델 Serving 페이지에 표시되는 모델입니다.

2.2.4. 배포된 모델 삭제

이전에 배포한 모델을 삭제할 수 있습니다. 이를 통해 더 이상 필요하지 않은 배포된 모델을 제거할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • 모델을 배포했습니다.

프로세스

  1. OpenShift AI 대시보드에서 모델 제공 을 클릭합니다.

    배포된 모델 페이지가 열립니다.

  2. 삭제할배포된 모델 옆에 있는 작업 메뉴( Cryostat )를 클릭하고 삭제 를 클릭합니다.

    배포된 모델 삭제 대화 상자가 열립니다.

  3. 텍스트 필드에 배포된 모델의 이름을 입력하여 삭제하려는지 확인합니다.
  4. 배포된 모델 삭제를 클릭합니다.

검증

  • 삭제한 모델은 배포 모델 페이지에 더 이상 표시되지 않습니다.

2.3. 다중 모델 제공 플랫폼에 대한 모델 서비스 런타임 메트릭 보기

클러스터 관리자가 다중 모델 서비스 플랫폼에 대한 모니터링을 구성한 후 관리자가 아닌 사용자는 OpenShift 웹 콘솔을 사용하여 ModelMesh 구성 요소의 모델 제공 런타임 지표를 볼 수 있습니다.

사전 요구 사항

프로세스

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 개발자 화면으로 전환합니다.
  3. 왼쪽 메뉴에서 모니터링 을 클릭합니다.
  4. 사용자 정의 프로젝트의 메트릭을 개발자(Red Hat OpenShift Dedicated)로 쿼리하거나 사용자 정의 프로젝트에 대한 메트릭을 개발자(AWS의 Red Hat OpenShift Service)로 쿼리하는 데 설명된 대로 웹 콘솔을 사용하여 modelmesh_* 지표에 대한 쿼리를 실행합니다.

2.4. 모델 성능 모니터링

2.4.1. 모델 서버의 모든 모델에 대한 성능 지표 보기

OpenShift AI에서는 모델 서버에 배포된 모든 모델에 대해 다음 메트릭을 모니터링할 수 있습니다.

이러한 메트릭에 대한 시간 범위 및 새로 고침 간격을 지정하여 최대 사용 시간이 있고 지정된 시간에 모델이 수행하는 방법을 결정하는 데 도움이 됩니다.

사전 요구 사항

  • Red Hat OpenShift AI를 설치했습니다.
  • OpenShift AI가 설치된 OpenShift 클러스터에서 사용자 워크로드 모니터링이 활성화됩니다.
  • OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • 다중 모델 서비스 플랫폼에 모델을 배포했습니다.

프로세스

  1. OpenShift AI 대시보드 탐색 메뉴에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 모니터링할 데이터 과학 모델이 포함된 프로젝트의 이름을 클릭합니다.
  3. 프로젝트 세부 정보 페이지에서 모델 탭을 클릭합니다.
  4. 관심 있는 모델 서버의 행에서 작업 메뉴( Cryostat)를 클릭한 다음 View model server metrics 를 선택합니다.
  5. 선택 사항: 모델 서버의 메트릭 페이지에서 다음 옵션을 설정합니다.

    • 시간 범위 - 메트릭을 추적하는 기간을 지정합니다. 이 값 중 하나를 선택할 수 있습니다. 1 시간, 24 시간, 7 일 및 30 일.
    • 새로 고침 간격 - 메트릭 페이지의 그래프가 새로 고쳐지는 빈도를 지정합니다(최신 데이터를 표시). 이 값 중 하나를 선택할 수 있습니다: 15 초, 30 초, 1 분, 5 분, 15 분, 30 분, 1 시간, 2 시간, 1 일.
  6. 아래로 스크롤하여 HTTP 요청, 평균 응답 시간, CPU 사용률 및 메모리 사용률에 대한 데이터 그래프를 봅니다.

검증

모델 서버의 메트릭 페이지에서 그래프는 성능 지표 데이터를 제공합니다.

2.4.2. 배포된 모델에 대한 HTTP 요청 메트릭 보기

다중 모델 제공 플랫폼에 배포된 특정 모델에 대해 실패했거나 성공한 HTTP 요청을 보여주는 그래프를 볼 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI를 설치했습니다.
  • OpenShift AI가 설치된 OpenShift 클러스터에서 사용자 워크로드 모니터링이 활성화됩니다.
  • 클러스터 관리자가 모델 Serving 페이지의 끝점 성능 탭을 숨기기 위해 OpenShift AI 대시보드 구성을 편집 하지 않았습니다. 자세한 내용은 대시보드 구성 옵션을 참조하십시오.
  • OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • 다중 모델 서비스 플랫폼에 모델을 배포했습니다.

프로세스

  1. OpenShift AI 대시보드 탐색 메뉴에서 Model Serving 을 선택합니다.
  2. 배포 모델 페이지에서 관심 있는 모델을 선택합니다.
  3. 선택 사항: 끝점 성능 탭에서 다음 옵션을 설정합니다.

    • 시간 범위 - 메트릭을 추적하는 기간을 지정합니다. 이 값 중 하나를 선택할 수 있습니다. 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.1.1. components

  • KServe: 모든 유형의 모델에 대해 모델을 오케스트레이션하는 Kubernetes CRD(사용자 정의 리소스 정의)입니다. KServe에는 지정된 유형의 모델 서버 로드를 구현하는 모델 제공 런타임이 포함되어 있습니다. KServe는 배포 오브젝트, 스토리지 액세스 및 네트워킹 설정의 라이프사이클도 처리합니다.
  • Red Hat OpenShift Serverless: 모델을 서버리스 배포할 수 있는 클라우드 네이티브 개발 모델입니다. OpenShift Serverless는 오픈 소스 Knative 프로젝트를 기반으로 합니다.
  • Red Hat OpenShift Service Mesh: 트래픽 흐름을 관리하고 액세스 정책을 적용하는 서비스 메시 네트워킹 계층입니다. OpenShift Service Mesh는 오픈 소스 Istio 프로젝트를 기반으로 합니다.

3.1.2. 설치 옵션

단일 모델 제공 플랫폼을 설치하려면 다음과 같은 옵션이 있습니다.

자동 설치

OpenShift 클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 아직 생성하지 않은 경우 KServe 및 해당 종속 항목을 설치하도록 Red Hat OpenShift AI Operator를 구성할 수 있습니다.

자동 설치에 대한 자세한 내용은 KServe의 자동 설치 구성을 참조하십시오.

수동 설치

OpenShift 클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 이미 생성한 경우 KServe 및 해당 종속 항목을 설치하도록 Red Hat OpenShift AI Operator를 구성할 수 없습니다. 이 경우 KServe를 수동으로 설치해야 합니다.

수동 설치에 대한 자세한 내용은 KServe 수동 설치를 참조하십시오.

3.1.3. model-serving 런타임

KServe를 설치하면 OpenShift AI 대시보드를 사용하여 사전 설치 또는 사용자 지정 모델 제공 런타임을 사용하여 모델을 배포할 수 있습니다.

OpenShift AI에는 다음과 같은 KServe에 사전 설치된 런타임이 포함되어 있습니다.

  • 독립 실행형 TGIS 런타임
  • 복합 Cakeygent-TGIS 런타임
  • OpenVino Model Server
참고

3.1.4. 권한 부여

Authorino 를 단일 모델 제공 플랫폼의 권한 부여 공급자로 추가할 수 있습니다. 권한 부여 공급자를 추가하면 플랫폼에 배포하는 모델에 대한 토큰 권한 부여를 활성화할 수 있으므로 권한이 있는 당사자만 모델에 대한 유추 요청을 수행할 수 있습니다.

단일 모델 제공 플랫폼에서 Authorino를 권한 부여 공급자로 추가하려면 다음 옵션이 있습니다.

  • 클러스터에서 단일 모델 서비스 플랫폼의 자동 설치가 가능한 경우 Authorino를 자동화된 설치 프로세스의 일부로 포함할 수 있습니다.
  • 단일 모델 제공 플랫폼을 수동으로 설치해야 하는 경우 Authorino를 수동으로 구성해야 합니다.

단일 모델 제공 플랫폼의 설치 옵션 선택 지침은 설치 옵션을 참조하십시오.

3.1.5. 모니터링

단일 모델 제공 플랫폼에 대한 모니터링을 구성하고 Prometheus를 사용하여 사전 설치된 각 모델 제공 런타임에 대한 지표를 스크랩할 수 있습니다.

3.2. KServe 자동 설치 구성

OpenShift 클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 아직 생성하지 않은 경우 KServe 및 해당 종속 항목을 설치하도록 Red Hat OpenShift AI Operator를 구성할 수 있습니다.

중요

클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 생성한 경우 Red Hat OpenShift AI Operator는 KServe 및 해당 종속 항목을 설치할 수 없으며 설치가 진행되지 않습니다. 이 경우 수동 설치 지침에 따라 KServe를 설치해야 합니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
  • 클러스터에는 CPU 4개와 16GB 메모리가 있는 노드가 있습니다.
  • OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. 자세한 내용은 OpenShift CLI 설치(Red Hat OpenShift Dedicated) 또는 OpenShift CLI 설치 (AWS에 Red Hat OpenShift Service)를 참조하십시오.
  • Red Hat OpenShift Service Mesh Operator 및 종속 Operator가 설치되어 있습니다.

    참고

    KServe의 자동 설치를 활성화하려면 Red Hat OpenShift Service Mesh에 필요한 Operator 설치합니다. 추가 구성을 수행하거나 ServiceMeshControlPlane 리소스를 생성하지 마십시오.

  • Red Hat OpenShift Serverless Operator를 설치했습니다.

    참고

    KServe의 자동 설치를 활성화하려면 Red Hat OpenShift Serverless Operator 설치합니다. 추가 구성을 수행하거나 KNativeServing 리소스를 생성하지 마십시오.

  • 배포된 모델에 대한 토큰 승인을 활성화할 수 있도록 Authorino를 권한 부여 공급자로 추가하려면 Red Hat - Authorino Operator를 설치했습니다. Authorino Operator 설치를 참조하십시오.

프로세스

  1. OpenShift 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 웹 콘솔에서 Operator → 설치된 Operator 를 클릭한 다음 Red Hat OpenShift AI Operator를 클릭합니다.
  3. 다음과 같이 OpenShift Service Mesh를 설치합니다.

    1. DSC 초기화 탭을 클릭합니다.
    2. default-dsci 오브젝트를 클릭합니다.
    3. YAML 탭을 클릭합니다.
    4. spec 섹션에서 serviceMesh 구성 요소의 managementState 필드 값이 다음과 같이 Managed 로 설정되어 있는지 확인합니다.

      spec:
       applicationsNamespace: redhat-ods-applications
       monitoring:
         managementState: Managed
         namespace: redhat-ods-monitoring
       serviceMesh:
         controlPlane:
           metricsCollection: Istio
           name: data-science-smcp
           namespace: istio-system
         managementState: Managed
      참고

      기본적으로 serviceMesh 구성 요소에 지정된 istio-system 네임스페이스를 변경하지 마십시오. 기타 네임스페이스 값은 지원되지 않습니다.

    5. 저장을 클릭합니다.

      DSCInitialization 오브젝트에 추가한 구성에 따라 Red Hat OpenShift AI Operator는 OpenShift Service Mesh를 설치합니다.

  4. (Red Hat OpenShift Service on AWS만 해당): OpenShift 클러스터가 AWS(ROSA)에서 실행되는 경우 서비스 메시 컨트롤 플레인 구성 작업을 수행하는 데 추가 설정이 필요합니다. 이 설정을 추가하려면 다음과 같이 data- sizing-smcp 서비스 메시 컨트롤 플레인 오브젝트를 편집합니다.

    1. 웹 콘솔에서 Operator → 설치된 Operator 를 클릭한 다음 Red Hat OpenShift Service Mesh Operator를 클릭합니다.
    2. Istio Service Mesh Control Plane 탭을 클릭합니다.
    3. data-attr-smcp 오브젝트를 클릭합니다.
    4. YAML 탭을 클릭합니다.
    5. spec.security.identity 섹션에서 type 이라는 필드를 추가하고 다음과 같이 값을 third party 로 설정합니다.

       security:
          dataPlane:
            mtls: true
          identity:
            type: ThirdParty
    6. 저장을 클릭합니다.
  5. 다음과 같이 KServe 및 OpenShift Serverless를 모두 설치합니다.

    1. 웹 콘솔에서 Operator → 설치된 Operator 를 클릭한 다음 Red Hat OpenShift AI Operator를 클릭합니다.
    2. Data Science Cluster 탭을 클릭합니다.
    3. default-dsc DSC 오브젝트를 클릭합니다.
    4. YAML 탭을 클릭합니다.
    5. spec.components 섹션에서 표시된 대로 kserve 구성 요소를 구성합니다.

      spec:
       components:
         kserve:
           managementState: Managed
           serving:
             ingressGateway:
               certificate:
                 secretName: knative-serving-cert
                 type: SelfSigned
             managementState: Managed
             name: knative-serving
    6. 저장을 클릭합니다.

      이전 구성은 OpenShift Service Mesh에서 트래픽을 수신하기 위한 OpenShift Serverless의 수신 게이트웨이를 생성합니다. 이 구성에서 다음 세부 정보를 확인합니다.

      • 표시된 구성은 OpenShift 클러스터에 들어오는 트래픽을 보호하기 위해 자체 서명된 인증서를 생성하고 secretName 필드에 지정된 knative-serving-cert 시크릿에 인증서를 저장합니다. 자체 인증서를 제공하려면 secretName 필드의 값을 업데이트하여 시크릿 이름을 지정하고 type 필드의 값을 Provided 로 변경합니다.

        참고

        자체 인증서를 제공하는 경우 인증서에서 OpenShift 클러스터의 Ingress 컨트롤러에서 사용하는 도메인 이름을 지정해야 합니다. 다음 명령을 실행하여 이 값을 확인할 수 있습니다.

        $ oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}'

      • kserveserving 구성 요소 모두에 대해 managementState 필드의 값을 Managed 로 설정해야 합니다. kserve.managementStateManaged 로 설정하면 KServe의 자동 설치가 트리거됩니다. serving.managementStateManaged 로 설정하면 OpenShift Serverless의 자동 설치가 트리거됩니다. 그러나 kserve.managementStateManaged 로 설정되지 않은 경우 OpenShift Serverless 설치가 트리거되지 않습니다.

검증

  • 다음과 같이 OpenShift Service Mesh 설치를 확인합니다.

    • 웹 콘솔에서 워크로드Pod 를 클릭합니다.
    • 프로젝트 목록에서 istio-system 을 선택합니다. OpenShift Service Mesh가 설치된 프로젝트입니다.
    • 서비스 메시 컨트롤 플레인, 수신 게이트웨이 및 송신 게이트웨이에 대해 실행 중인 Pod가 있는지 확인합니다. 이러한 Pod에는 다음 예에 표시된 이름 지정 패턴이 있습니다.

      NAME                                      		  READY     STATUS    RESTARTS   AGE
      istio-egressgateway-7c46668687-fzsqj      	 	  1/1       Running   0          22h
      istio-ingressgateway-77f94d8f85-fhsp9      		  1/1       Running   0          22h
      istiod-data-science-smcp-cc8cfd9b8-2rkg4  		  1/1       Running   0          22h
  • 다음과 같이 OpenShift Serverless 설치를 확인합니다.

    • 웹 콘솔에서 워크로드Pod 를 클릭합니다.
    • 프로젝트 목록에서 knative-serving 을 선택합니다. OpenShift Serverless가 설치된 프로젝트입니다.
    • 활성화, 자동 스케일러, 컨트롤러 및 도메인 매핑 Pod를 포함하여 knative-serving 프로젝트에 실행 중인 Pod와 Knative Istio 컨트롤러의 Pod(OpenShift Serverless 및 OpenShift Service Mesh의 통합을 제어하는 Pod)가 있는지 확인합니다. 예를 들면 다음과 같습니다.

      NAME                                     	READY     STATUS    RESTARTS  AGE
      activator-7586f6f744-nvdlb               	2/2       Running   0         22h
      activator-7586f6f744-sd77w               	2/2       Running   0         22h
      autoscaler-764fdf5d45-p2v98             	2/2       Running   0         22h
      autoscaler-764fdf5d45-x7dc6              	2/2       Running   0         22h
      autoscaler-hpa-7c7c4cd96d-2lkzg          	1/1       Running   0         22h
      autoscaler-hpa-7c7c4cd96d-gks9j         	1/1       Running   0         22h
      controller-5fdfc9567c-6cj9d              	1/1       Running   0         22h
      controller-5fdfc9567c-bf5x7              	1/1       Running   0         22h
      domain-mapping-56ccd85968-2hjvp          	1/1       Running   0         22h
      domain-mapping-56ccd85968-lg6mw          	1/1       Running   0         22h
      domainmapping-webhook-769b88695c-gp2hk   	1/1       Running   0         22h
      domainmapping-webhook-769b88695c-npn8g   	1/1       Running   0         22h
      net-istio-controller-7dfc6f668c-jb4xk    	1/1       Running   0         22h
      net-istio-controller-7dfc6f668c-jxs5p    	1/1       Running   0         22h
      net-istio-webhook-66d8f75d6f-bgd5r       	1/1       Running   0         22h
      net-istio-webhook-66d8f75d6f-hld75      	1/1       Running   0         22h
      webhook-7d49878bc4-8xjbr                 	1/1       Running   0         22h
      webhook-7d49878bc4-s4xx4                 	1/1       Running   0         22h
  • 다음과 같이 KServe 설치를 확인합니다.

    • 웹 콘솔에서 워크로드Pod 를 클릭합니다.
    • 프로젝트 목록에서 redhat-ods-applications 를 선택합니다. KServe를 포함하여 OpenShift AI 구성 요소가 설치된 프로젝트입니다.
    • 다음 예와 유사하게 프로젝트에 KServe 컨트롤러 관리자에 대해 실행 중인 Pod가 포함되어 있는지 확인합니다.

      NAME                                          READY   STATUS    RESTARTS   AGE
      kserve-controller-manager-7fbb7bccd4-t4c5g    1/1     Running   0          22h
      odh-model-controller-6c4759cc9b-cftmk         1/1     Running   0          129m
      odh-model-controller-6c4759cc9b-ngj8b         1/1     Running   0          129m
      odh-model-controller-6c4759cc9b-vnhq5         1/1     Running   0          129m

3.3. 수동으로 KServe 설치

Red Hat OpenShift Service Mesh Operator를 이미 설치하고 ServiceMeshControlPlane 리소스를 생성했거나 Red Hat OpenShift Serverless Operator를 설치하고 KNativeServing 리소스를 생성한 경우 Red Hat OpenShift AI Operator는 KServe 및 해당 종속 항목을 설치할 수 없습니다. 이 경우 KServe를 수동으로 설치해야 합니다.

중요

이 섹션의 절차에서는 KServe 및 해당 종속 항목을 새로 설치하는 방법을 보여주고 전체 설치 및 구성 참조로 사용됩니다. OpenShift Service Mesh 또는 OpenShift Serverless를 이미 설치 및 구성한 경우 모든 단계를 수행하지 않아도 될 수 있습니다. KServe를 사용하여 기존 구성에 적용할 업데이트가 확실하지 않은 경우 Red Hat 지원팀에 문의하십시오.

3.3.1. KServe 종속 항목 설치

KServe를 설치하기 전에 일부 종속성을 설치하고 구성해야 합니다. 특히 Red Hat OpenShift Service Mesh 및 Knative Serving 인스턴스를 생성한 다음 Knative Serving에 대한 보안 게이트웨이를 구성해야 합니다.

3.3.1.1. OpenShift Service Mesh 인스턴스 생성

다음 절차에서는 Red Hat OpenShift Service Mesh 인스턴스를 생성하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
  • 클러스터에는 CPU 4개와 16GB 메모리가 있는 노드가 있습니다.
  • OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치 (Red Hat OpenShift Dedicated) 또는 OpenShift CLI 설치 (AWS에 Red Hat OpenShift Service)를 참조하십시오.
  • Red Hat OpenShift Service Mesh Operator 및 종속 Operator가 설치되어 있습니다.

프로세스

  1. 터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
  2. Red Hat OpenShift Service Mesh에 필요한 네임스페이스를 생성합니다.

    $ oc create ns istio-system

    다음 출력이 표시됩니다.

    namespace/istio-system created
  3. 다음 콘텐츠를 사용하여 smcp.yaml 이라는 YAML 파일에 ServiceMeshControlPlane 오브젝트를 정의합니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: minimal
      namespace: istio-system
    spec:
      tracing:
        type: None
      addons:
        grafana:
          enabled: false
        kiali:
          name: kiali
          enabled: false
        prometheus:
          enabled: false
        jaeger:
          name: jaeger
      security:
        dataPlane:
          mtls: true
        identity:
          type: ThirdParty
      techPreview:
        meshConfig:
          defaultConfig:
            terminationDrainDuration: 35s
      gateways:
        ingress:
          service:
            metadata:
              labels:
                knative: ingressgateway
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
                - 8444
                - 8022

    YAML 파일의 값에 대한 자세한 내용은 Service Mesh Control Plane 구성 참조를 참조하십시오.

  4. 서비스 메시 컨트롤 플레인을 생성합니다.

    $ oc apply -f smcp.yaml

검증

  • 다음과 같이 서비스 메시 인스턴스 생성을 확인합니다.

    • OpenShift CLI에서 다음 명령을 입력합니다.

      $ oc get pods -n istio-system

      이전 명령은 istio-system 프로젝트에서 실행 중인 모든 포드를 나열합니다. OpenShift Service Mesh가 설치된 프로젝트입니다.

    • 서비스 메시 컨트롤 플레인, 수신 게이트웨이 및 송신 게이트웨이에 대해 실행 중인 Pod가 있는지 확인합니다. 이러한 Pod에는 다음과 같은 이름 지정 패턴이 있습니다.

      NAME                                          READY   STATUS   	  RESTARTS    AGE
      istio-egressgateway-7c46668687-fzsqj          1/1     Running     0           22h
      istio-ingressgateway-77f94d8f85-fhsp9         1/1     Running     0           22h
      istiod-data-science-smcp-cc8cfd9b8-2rkg4      1/1     Running     0           22h

3.3.1.2. Knative Serving 인스턴스 생성

다음 절차에서는 Knative Serving을 설치한 다음 인스턴스를 생성하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
  • 클러스터에는 CPU 4개와 16GB 메모리가 있는 노드가 있습니다.
  • OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치 (Red Hat OpenShift Dedicated) 또는 OpenShift CLI 설치 (AWS에 Red Hat OpenShift Service)를 참조하십시오.
  • Red Hat OpenShift Service Mesh 인스턴스를 생성 했습니다.
  • Red Hat OpenShift Serverless Operator를 설치했습니다.

프로세스

  1. 터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
  2. Knative Serving에 필요한 프로젝트(즉, 네임스페이스)가 있는지 확인합니다.

    $ oc get ns knative-serving

    프로젝트가 있는 경우 다음 예와 유사한 출력이 표시됩니다.

    NAME              STATUS   AGE
    knative-serving   Active   4d20h
  3. knative-serving 프로젝트 가 아직 없는 경우 생성합니다.

    $ oc create ns knative-serving

    다음 출력이 표시됩니다.

    namespace/knative-serving created
  4. 다음 콘텐츠를 사용하여 default-smm.yaml 이라는 YAML 파일에 ServiceMeshMember 오브젝트를 정의합니다.

    apiVersion: maistra.io/v1
    kind: ServiceMeshMember
    metadata:
      name: default
      namespace: knative-serving
    spec:
      controlPlaneRef:
        namespace: istio-system
        name: minimal
  5. istio-system 네임스페이스에서 ServiceMeshMember 오브젝트를 생성합니다.

    $ oc apply -f default-smm.yaml

    다음 출력이 표시됩니다.

    servicemeshmember.maistra.io/default created
  6. 다음 콘텐츠를 사용하여 knativeserving-istio.yaml 이라는 YAML 파일에 KnativeServing 오브젝트를 정의합니다.

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
      annotations:
        serverless.openshift.io/default-enable-http2: "true"
    spec:
      workloads:
        - name: net-istio-controller
          env:
            - container: controller
              envVars:
                - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
                  value: 'true'
        - annotations:
            sidecar.istio.io/inject: "true" 1
            sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
          name: activator
        - annotations:
            sidecar.istio.io/inject: "true"
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
          name: autoscaler
      ingress:
        istio:
          enabled: true
      config:
        features:
          kubernetes.podspec-affinity: enabled
          kubernetes.podspec-nodeselector: enabled
          kubernetes.podspec-tolerations: enabled

    이전 파일은 KnativeServing 오브젝트에 대한 CR(사용자 정의 리소스)을 정의합니다. CR은 각 활성화자 및 자동 스케일러 Pod에 다음 작업도 추가합니다.

    1
    Pod에 Istio 사이드카를 삽입합니다. 이렇게 하면 Pod가 서비스 메시의 일부가 됩니다.
    2
    Istio 사이드카를 활성화하여 Pod에 대한 HTTP 활동 및 준비 상태 프로브를 다시 작성할 수 있습니다.
    참고

    Knative 서비스의 사용자 정의 도메인을 구성하는 경우 TLS 인증서를 사용하여 매핑된 서비스를 보호할 수 있습니다. 이렇게 하려면 TLS 시크릿을 생성한 다음 생성한 TLS 시크릿을 사용하도록 DomainMapping CR을 업데이트해야 합니다. 자세한 내용은 Red Hat OpenShift Serverless 설명서의 TLS 인증서를 사용하여 매핑된 서비스 보안 을 참조하십시오.

  7. 지정된 knative-serving 네임스페이스에 KnativeServing 오브젝트를 생성합니다.

    $ oc apply -f knativeserving-istio.yaml

    다음 출력이 표시됩니다.

    knativeserving.operator.knative.dev/knative-serving created

검증

  • istio-system 네임스페이스에서 기본 ServiceMeshMemberRoll 오브젝트를 검토합니다.

    $ oc describe smmr default -n istio-system

    ServiceMeshMemberRoll 오브젝트 설명에서 Status.Members 필드를 찾아 knative-serving 네임스페이스가 포함되어 있는지 확인합니다.

  • 다음과 같이 Knative Serving 인스턴스 생성을 확인합니다.

    • OpenShift CLI에서 다음 명령을 입력합니다.

      $ oc get pods -n knative-serving

      이전 명령은 knative-serving 프로젝트에서 실행 중인 모든 Pod를 나열합니다. 이는 Knative Serving 인스턴스를 생성한 프로젝트입니다.

    • 활성화, 자동 스케일러, 컨트롤러 및 도메인 매핑 Pod를 포함하여 knative-serving 프로젝트에 실행 중인 Pod와 OpenShift Serverless 및 OpenShift Service Mesh의 통합을 제어하는 Knative Istio 컨트롤러의 Pod가 있는지 확인합니다. 예를 들면 다음과 같습니다.

      NAME                                     	READY       STATUS    	RESTARTS   	AGE
      activator-7586f6f744-nvdlb               	2/2         Running   	0          	22h
      activator-7586f6f744-sd77w               	2/2         Running   	0          	22h
      autoscaler-764fdf5d45-p2v98             	2/2         Running   	0          	22h
      autoscaler-764fdf5d45-x7dc6              	2/2         Running   	0          	22h
      autoscaler-hpa-7c7c4cd96d-2lkzg          	1/1         Running   	0          	22h
      autoscaler-hpa-7c7c4cd96d-gks9j         	1/1         Running   	0          	22h
      controller-5fdfc9567c-6cj9d              	1/1         Running   	0          	22h
      controller-5fdfc9567c-bf5x7              	1/1         Running   	0          	22h
      domain-mapping-56ccd85968-2hjvp          	1/1         Running   	0          	22h
      domain-mapping-56ccd85968-lg6mw          	1/1         Running   	0          	22h
      domainmapping-webhook-769b88695c-gp2hk   	1/1         Running     0          	22h
      domainmapping-webhook-769b88695c-npn8g   	1/1         Running   	0          	22h
      net-istio-controller-7dfc6f668c-jb4xk    	1/1         Running   	0          	22h
      net-istio-controller-7dfc6f668c-jxs5p    	1/1         Running   	0          	22h
      net-istio-webhook-66d8f75d6f-bgd5r       	1/1         Running   	0          	22h
      net-istio-webhook-66d8f75d6f-hld75      	1/1         Running   	0          	22h
      webhook-7d49878bc4-8xjbr                 	1/1         Running   	0          	22h
      webhook-7d49878bc4-s4xx4                 	1/1         Running   	0          	22h

3.3.1.3. Knative Serving의 보안 게이트웨이 생성

Knative Serving 인스턴스와 서비스 메시 간의 트래픽을 보호하려면 Knative Serving 인스턴스에 대한 보안 게이트웨이를 생성해야 합니다.

다음 절차에서는 OpenSSL을 사용하여 와일드카드 인증서 및 키를 생성한 다음 이를 사용하여 Knative Serving의 로컬 및 수신 게이트웨이를 생성하는 방법을 보여줍니다.

중요

게이트웨이를 구성할 때 지정할 자체 와일드카드 인증서와 키가 있는 경우 이 절차의 11 단계로 건너뛸 수 있습니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
  • OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치 (Red Hat OpenShift Dedicated) 또는 OpenShift CLI 설치 (AWS에 Red Hat OpenShift Service)를 참조하십시오.
  • Red Hat OpenShift Service Mesh 인스턴스를 생성 했습니다.
  • Knative Serving 인스턴스를 생성 했습니다.
  • 와일드카드 인증서 및 키를 생성하려는 경우 OpenSSL을 다운로드하여 설치했습니다.

프로세스

  1. 터미널 창에서 클러스터 관리자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <admin_username> -p <password>
    중요

    게이트웨이를 구성할 때 지정할 자체 와일드카드 인증서와 키가 있는 경우 이 절차의 11 단계로 건너뜁니다.

  2. 환경 변수를 설정하여 게이트웨이의 와일드카드 인증서 및 키 생성에 대한 기본 디렉터리를 정의합니다.

    $ export BASE_DIR=/tmp/kserve
    $ export BASE_CERT_DIR=${BASE_DIR}/certs
  3. 환경 변수를 설정하여 OpenShift 클러스터의 Ingress 컨트롤러에서 사용하는 공통 이름을 정의합니다.

    $ export COMMON_NAME=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}' | awk -F'.' '{print $(NF-1)"."$NF}')
  4. 환경 변수를 설정하여 OpenShift 클러스터의 Ingress 컨트롤러에서 사용하는 도메인 이름을 정의합니다.

    $ export DOMAIN_NAME=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
  5. 이전에 설정한 환경 변수를 기반으로 인증서 생성에 필요한 기본 디렉터리를 생성합니다.

    $ mkdir ${BASE_DIR}
    $ mkdir ${BASE_CERT_DIR}
  6. 와일드카드 인증서 생성에 대한 OpenSSL 구성을 생성합니다.

    $ cat <<EOF> ${BASE_DIR}/openssl-san.config
    [ req ]
    distinguished_name = req
    [ san ]
    subjectAltName = DNS:*.${DOMAIN_NAME}
    EOF
  7. 루트 인증서를 생성합니다.

    $ openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 \
    -subj "/O=Example Inc./CN=${COMMON_NAME}" \
    -keyout $BASE_DIR/root.key \
    -out $BASE_DIR/root.crt
  8. 루트 인증서에서 서명한 와일드카드 인증서를 생성합니다.

    $ openssl req -x509 -newkey rsa:2048 \
    -sha256 -days 3560 -nodes \
    -subj "/CN=${COMMON_NAME}/O=Example Inc." \
    -extensions san -config ${BASE_DIR}/openssl-san.config \
    -CA $BASE_DIR/root.crt \
    -CAkey $BASE_DIR/root.key \
    -keyout $BASE_DIR/wildcard.key  \
    -out $BASE_DIR/wildcard.crt
    
    $ openssl x509 -in ${BASE_DIR}/wildcard.crt -text
  9. 와일드카드 인증서를 확인합니다.

    $ openssl verify -CAfile ${BASE_DIR}/root.crt ${BASE_DIR}/wildcard.crt
  10. 스크립트에서 생성한 와일드카드 키 및 인증서를 새 환경 변수로 내보냅니다.

    $ export TARGET_CUSTOM_CERT=${BASE_CERT_DIR}/wildcard.crt
    $ export TARGET_CUSTOM_KEY=${BASE_CERT_DIR}/wildcard.key
  11. 선택 사항: 자체 와일드카드 키 및 인증서를 새 환경 변수로 내보내려면 다음 명령을 입력합니다.

    $ export TARGET_CUSTOM_CERT=<path_to_certificate>
    $ export TARGET_CUSTOM_KEY=<path_to_key>
    참고

    제공하는 인증서에서는 OpenShift 클러스터의 Ingress 컨트롤러에서 사용하는 도메인 이름을 지정해야 합니다. 다음 명령을 실행하여 이 값을 확인할 수 있습니다.

    $ oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}'

  12. 와일드카드 인증서 및 키에 설정한 환경 변수를 사용하여 istio-system 네임스페이스에 TLS 시크릿을 생성합니다.

    $ oc create secret tls wildcard-certs --cert=${TARGET_CUSTOM_CERT} --key=${TARGET_CUSTOM_KEY} -n istio-system
  13. 다음 콘텐츠를 사용하여 gateways.yaml YAML 파일을 생성합니다.

    apiVersion: v1
    kind: Service 1
    metadata:
      labels:
        experimental.istio.io/disable-gateway-port-translation: "true"
      name: knative-local-gateway
      namespace: istio-system
    spec:
      ports:
        - name: http2
          port: 80
          protocol: TCP
          targetPort: 8081
      selector:
        knative: ingressgateway
      type: ClusterIP
    ---
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: knative-ingress-gateway 2
      namespace: knative-serving
    spec:
      selector:
        knative: ingressgateway
      servers:
        - hosts:
            - '*'
          port:
            name: https
            number: 443
            protocol: HTTPS
          tls:
            credentialName: wildcard-certs
            mode: SIMPLE
    ---
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
     name: knative-local-gateway 3
     namespace: knative-serving
    spec:
     selector:
       knative: ingressgateway
     servers:
       - port:
           number: 8081
           name: https
           protocol: HTTPS
         tls:
           mode: ISTIO_MUTUAL
         hosts:
           - "*"
    1
    Knative 로컬 게이트웨이의 istio-system 네임스페이스에서 서비스를 정의합니다.
    2
    knative-serving 네임스페이스 에서 수신 게이트웨이를 정의합니다. 게이트웨이는 이 절차의 앞부분에서 생성한 TLS 시크릿을 사용합니다. 수신 게이트웨이는 Knative에 대한 외부 트래픽을 처리합니다.
    3
    knative-serving 네임스페이스에서 Knative의 로컬 게이트웨이를 정의합니다.
  14. gateways.yaml 파일을 적용하여 정의된 리소스를 생성합니다.

    $ oc apply -f gateways.yaml

    다음 출력이 표시됩니다.

    service/knative-local-gateway created
    gateway.networking.istio.io/knative-ingress-gateway created
    gateway.networking.istio.io/knative-local-gateway created

검증

  • 생성한 게이트웨이를 검토합니다.

    $ oc get gateway --all-namespaces

    다음 예와 같이 knative-serving 네임스페이스에 생성한 로컬 및 수신 게이트웨이가 표시되는지 확인합니다.

    NAMESPACE         	NAME                      	AGE
    knative-serving   	knative-ingress-gateway   	69s
    knative-serving     knative-local-gateway     	2m

3.3.2. KServe 설치

KServe의 수동 설치를 완료하려면 Red Hat OpenShift AI Operator를 설치하는 Red Hat OpenShift AI 애드온을 설치해야 합니다. 그런 다음 Operator를 사용하여 KServe를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.
  • 클러스터에는 CPU 4개와 16GB 메모리가 있는 노드가 있습니다.
  • OpenShift CLI(명령줄 인터페이스)를 다운로드하여 설치했습니다. OpenShift CLI 설치 (Red Hat OpenShift Dedicated) 또는 OpenShift CLI 설치 (AWS에 Red Hat OpenShift Service)를 참조하십시오.
  • Red Hat OpenShift Service Mesh 인스턴스를 생성 했습니다.
  • Knative Serving 인스턴스를 생성 했습니다.
  • Knative Serving에 대한 보안 게이트웨이가 생성되어 있습니다.
  • OpenShift 클러스터에 Red Hat OpenShift AI 애드온을 설치했습니다. 그러면 Red Hat OpenShift AI Operator가 설치되고 기본 DataScienceCluster 개체가 생성됩니다.

프로세스

  1. OpenShift 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 웹 콘솔에서 Operator → 설치된 Operator 를 클릭한 다음 Red Hat OpenShift AI Operator를 클릭합니다.
  3. KServe 설치의 경우 다음과 같이 OpenShift Service Mesh 구성 요소를 구성합니다.

    1. DSC 초기화 탭을 클릭합니다.
    2. default-dsci 오브젝트를 클릭합니다.
    3. YAML 탭을 클릭합니다.
    4. spec 섹션에서 다음과 같이 serviceMesh 구성 요소를 추가하고 구성합니다.

      spec:
       serviceMesh:
         managementState: Unmanaged
    5. 저장을 클릭합니다.
  4. KServe를 설치하려면 다음과 같이 KServe 및 OpenShift Serverless 구성 요소를 구성합니다.

    1. 웹 콘솔에서 Operator → 설치된 Operator 를 클릭한 다음 Red Hat OpenShift AI Operator를 클릭합니다.
    2. Data Science Cluster 탭을 클릭합니다.
    3. default-dsc DSC 오브젝트를 클릭합니다.
    4. YAML 탭을 클릭합니다.
    5. spec.components 섹션에서 다음과 같이 kserve 구성 요소를 구성합니다.

      spec:
       components:
         kserve:
           managementState: Managed
    6. kserve 구성 요소 내에서 제공 구성 요소를 추가하고 다음과 같이 구성합니다.

      spec:
       components:
         kserve:
           managementState: Managed
           serving:
             managementState: Unmanaged
    7. 저장을 클릭합니다.

3.3.3. 수동으로 인증 공급자 추가

Authorino 를 단일 모델 제공 플랫폼의 권한 부여 공급자로 추가할 수 있습니다. 권한 부여 공급자를 추가하면 플랫폼에 배포하는 모델에 대한 토큰 권한 부여를 활성화할 수 있으므로 권한이 있는 당사자만 모델에 대한 유추 요청을 수행할 수 있습니다.

권한 부여 공급자로 작성자를 수동으로 추가하려면 Red Hat - Authorino Operator를 설치하고 Authorino 인스턴스를 생성한 다음 인스턴스를 사용하도록 OpenShift Service Mesh 및 KServe 구성 요소를 구성해야 합니다.

중요

권한 부여 공급자를 수동으로 추가하려면 OpenShift Service Mesh 인스턴스를 구성해야 합니다. OpenShift Service Mesh 인스턴스가 지원되는 상태로 유지되도록 하려면 이 섹션에 표시된 업데이트 만듭니다.

사전 요구 사항

  • Authorino를 인증 공급자로 추가하고 수동 설치를 적절한 옵션으로 확인하는 옵션을 검토했습니다. 권한 부여 공급자 추가를 참조하십시오.
  • OpenShift Service Mesh를 포함하여 KServe 및 해당 종속 항목을 수동으로 설치했습니다. KServe 수동 설치를 참조하십시오.
  • KServe를 수동으로 설치할 때 serviceMesh 구성 요소의 managementState 필드 값을 Unmanaged 로 설정합니다. 이 설정은 Authorino를 수동으로 추가하는 데 필요합니다. KServe 설치를 참조하십시오.

3.3.3.1. Red Hat Authorino Operator 설치

권한 부여 공급자로 Autorino를 추가하려면 OpenShift 클러스터에 Red Hat - Authorino Operator를 설치해야 합니다.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 권한이 있습니다.

프로세스

  1. OpenShift 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
  3. OperatorHub 페이지의 키워드로 필터링 필드에 Red Hat - Authorino 를 입력합니다.
  4. Red Hat - Authorino Operator를 클릭합니다.
  5. Red Hat - Authorino Operator 페이지에서 Operator 정보를 확인한 다음 설치를 클릭합니다.
  6. Operator 설치 페이지에서 업데이트 채널,버전,설치 모드,설치된 네임스페이스업데이트 승인 의 기본값을 유지합니다.
  7. 설치를 클릭합니다.

검증

  • OpenShift 웹 콘솔에서 Operator → 설치된 Operator 를 클릭하고 Red Hat - Authorino Operator에 다음 상태 중 하나가 표시되는지 확인합니다.

    • 설치 - 설치가 진행 중입니다. 성공으로 변경될 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다.
    • succeeded - 설치에 성공합니다.

3.3.3.2. Authorino 인스턴스 생성

OpenShift 클러스터에 Red Hat - Authorino Operator를 설치한 경우 Authorino 인스턴스를 생성해야 합니다.

사전 요구 사항

프로세스

  1. 새 터미널 창을 엽니다.
  2. 다음과 같이 OpenShift CLI(명령줄 인터페이스)에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  3. Authorino 인스턴스를 설치할 네임스페이스를 생성합니다.

    $ oc new-project <namespace_for_authorino_instance>
    참고

    자동화된 설치 프로세스는 Authorino 인스턴스에 대해 redhat-ods-applications-auth-provider 라는 네임스페이스를 생성합니다. 수동 설치에 동일한 네임스페이스 이름을 사용하는 것이 좋습니다.

  4. 기존 OpenShift Service Mesh 인스턴스에 Authorino 인스턴스의 새 네임스페이스를 등록하려면 다음 콘텐츠를 사용하여 새 YAML 파일을 생성합니다.

      apiVersion: maistra.io/v1
      kind: ServiceMeshMember
      metadata:
        name: default
        namespace: <namespace_for_authorino_instance>
      spec:
        controlPlaneRef:
          namespace: <namespace_for_service_mesh_instance>
          name: <name_of_service_mesh_instance>
  5. YAML 파일을 저장합니다.
  6. 클러스터에 ServiceMeshMember 리소스를 생성합니다.

    $ oc create -f <file_name>.yaml
  7. Authorino 인스턴스를 구성하려면 다음 예와 같이 새 YAML 파일을 생성합니다.

      apiVersion: operator.authorino.kuadrant.io/v1beta1
      kind: Authorino
      metadata:
        name: authorino
        namespace: <namespace_for_authorino_instance>
      spec:
        authConfigLabelSelectors: security.opendatahub.io/authorization-group=default
        clusterWide: true
        listener:
          tls:
            enabled: false
        oidcServer:
          tls:
            enabled: false
  8. YAML 파일을 저장합니다.
  9. 클러스터에 Authorino 리소스를 생성합니다.

    $ oc create -f <file_name>.yaml
  10. Authorino 배포를 패치하여 Istio 사이드카를 삽입하여 Authorino 인스턴스를 OpenShift Service Mesh 인스턴스의 일부로 만듭니다.

    $ oc patch deployment <name_of_authorino_instance> -n <namespace_for_authorino_instance> -p '{"spec": {"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"true"}}}} }'

검증

  • Authorino 인스턴스가 다음과 같이 실행되고 있는지 확인합니다.

    1. 다음 예와 같이 Authorino 인스턴스에 대해 생성한 네임스페이스에서 실행 중인 Pod(및 컨테이너)를 확인합니다.

      $ oc get pods -n redhat-ods-applications-auth-provider -o="custom-columns=NAME:.metadata.name,STATUS:.status.phase,CONTAINERS:.spec.containers[*].name"
    2. 출력이 다음 예와 유사한지 확인합니다.

      NAME                         STATUS    CONTAINERS
      authorino-6bc64bd667-kn28z   Running   authorino,istio-proxy

      예제에 표시된 대로 Authorino 인스턴스에 대해 실행 중인 단일 Pod가 있습니다. Pod에는 Authorino용 컨테이너와 사용자가 삽입한 Istio 사이드카에 대한 컨테이너가 있습니다.

3.3.3.3. Authorino를 사용하도록 OpenShift Service Mesh 인스턴스 구성

Authorino 인스턴스를 생성한 경우 Authorino를 권한 부여 공급자로 사용하도록 OpenShift Service Mesh 인스턴스를 구성해야 합니다.

중요

OpenShift Service Mesh 인스턴스가 지원되는 상태로 유지되도록 하려면 다음 절차에 표시된 구성 업데이트 만듭니다.

사전 요구 사항

  • Authorino 인스턴스를 생성하고 OpenShift Service Mesh 인스턴스에서 Authorino 인스턴스의 네임스페이스를 등록했습니다.
  • OpenShift Service Mesh 인스턴스를 수정할 수 있는 권한이 있습니다. OpenShift Service Mesh 인스턴스 생성을 참조하십시오.

프로세스

  1. 터미널 창에서 OpenShift Service Mesh 인스턴스를 업데이트할 권한이 있는 사용자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  2. 다음 콘텐츠를 사용하여 새 YAML 파일을 생성합니다.

    spec:
     techPreview:
       meshConfig:
         extensionProviders:
         - name: redhat-ods-applications-auth-provider
           envoyExtAuthzGrpc:
             service: <name_of_authorino_instance>-authorino-authorization.<namespace_for_authorino_instance>.svc.cluster.local
             port: 50051
  3. YAML 파일을 저장합니다.
  4. oc patch 명령을 사용하여 YAML 파일을 OpenShift Service Mesh 인스턴스에 적용합니다.

    $ oc patch smcp <name_of_service_mesh_instance> --type merge -n <namespace_for_service_mesh_instance> --patch-file <file_name>.yaml
    중요

    OpenShift Service Mesh 인스턴스에서 다른 확장 공급자를 아직 지정하지 않은 경우에만 패치로 표시된 구성을 적용할 수 있습니다. 다른 확장 공급자를 이미 지정한 경우 구성을 추가하려면 ServiceMeshControlPlane 리소스를 수동으로 편집해야 합니다.

검증

  • 다음과 같이 Authorino 인스턴스가 OpenShift Service Mesh 구성에서 확장 공급자로 추가되었는지 확인합니다.

    1. OpenShift Service Mesh 인스턴스의 ConfigMap 오브젝트를 검사합니다.

      $ oc get configmap istio-<name_of_service_mesh_instance> -n <namespace_for_service_mesh_instance> --output=jsonpath={.data.mesh}
    2. Authorino 인스턴스가 확장 공급자로 성공적으로 추가되었음을 보여주는 다음 예와 유사한 출력이 표시되는지 확인합니다.

      defaultConfig:
        discoveryAddress: istiod-data-science-smcp.istio-system.svc:15012
        proxyMetadata:
          ISTIO_META_DNS_AUTO_ALLOCATE: "true"
          ISTIO_META_DNS_CAPTURE: "true"
          PROXY_XDS_VIA_AGENT: "true"
        terminationDrainDuration: 35s
        tracing: {}
      dnsRefreshRate: 300s
      enablePrometheusMerge: true
      extensionProviders:
      - envoyExtAuthzGrpc:
          port: 50051
          service: authorino-authorino-authorization.opendatahub-auth-provider.svc.cluster.local
        name: opendatahub-auth-provider
      ingressControllerMode: "OFF"
      rootNamespace: istio-system
      trustDomain: null%

3.3.3.4. KServe에 대한 권한 부여 구성

Authorino를 사용하도록 단일 모델 제공 플랫폼을 구성하려면 모델을 배포할 때 생성되는 KServe 예측기 Pod에 적용되는 글로벌 AuthorizationPolicy 리소스를 생성해야 합니다. 또한 모델에 대한 유추 요청을 할 때 발생하는 여러 네트워크 홉을 고려하려면 유추 요청에 포함된 처음에 HTTP 호스트 헤더를 지속적으로 재설정하는 EnvoyFilter 리소스를 생성해야 합니다.

사전 요구 사항

  • Authorino 인스턴스를 생성하고 이를 사용하도록 OpenShift Service Mesh를 구성했습니다.
  • 클러스터에서 KServe 배포를 업데이트할 수 있는 권한이 있습니다.
  • OpenShift Service Mesh 인스턴스가 생성된 프로젝트에 리소스를 추가할 수 있는 권한이 있습니다. OpenShift Service Mesh 인스턴스 생성을 참조하십시오.

프로세스

  1. 터미널 창에서 KServe 배포를 업데이트할 권한이 있는 사용자로 OpenShift 클러스터에 로그인하지 않은 경우 다음 예와 같이 OpenShift CLI에 로그인합니다.

    $ oc login <openshift_cluster_url> -u <username> -p <password>
  2. 다음 콘텐츠를 사용하여 새 YAML 파일을 생성합니다.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: kserve-predictor
    spec:
      action: CUSTOM
      provider:
         name: redhat-ods-applications-auth-provider 1
      rules:
         - to:
              - operation:
                   notPaths:
                      - /healthz
                      - /debug/pprof/
                      - /metrics
                      - /wait-for-drain
      selector:
         matchLabels:
            component: predictor
    1
    지정한 이름은 OpenShift Service Mesh 인스턴스에 추가한 확장 공급자의 이름과 일치해야 합니다.
  3. YAML 파일을 저장합니다.
  4. OpenShift Service Mesh 인스턴스의 네임스페이스에 AuthorizationPolicy 리소스를 생성합니다.

    $ oc create -n <namespace_for_service_mesh_instance> -f <file_name>.yaml
  5. 다음 콘텐츠를 사용하여 다른 새 YAML 파일을 생성합니다.

    apiVersion: networking.istio.io/v1alpha3
    kind: EnvoyFilter
    metadata:
      name: activator-host-header
    spec:
      priority: 20
      workloadSelector:
        labels:
          component: predictor
      configPatches:
      - applyTo: HTTP_FILTER
        match:
          listener:
            filterChain:
              filter:
                name: envoy.filters.network.http_connection_manager
        patch:
          operation: INSERT_BEFORE
          value:
            name: envoy.filters.http.lua
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
              inlineCode: |
               function envoy_on_request(request_handle)
                  local headers = request_handle:headers()
                  if not headers then
                    return
                  end
                  local original_host = headers:get("k-original-host")
                  if original_host then
                    port_seperator = string.find(original_host, ":", 7)
                    if port_seperator then
                      original_host = string.sub(original_host, 0, port_seperator-1)
                    end
                    headers:replace('host', original_host)
                  end
                end

    표시된 EnvoyFilter 리소스는 처음에 임의 추론 요청에 포함된 HTTP 호스트 헤더를 지속적으로 재설정합니다.

  6. OpenShift Service Mesh 인스턴스의 네임스페이스에 EnvoyFilter 리소스를 생성합니다.

    $ oc create -n <namespace_for_service_mesh_instance> -f <file_name>.yaml

검증

  • AuthorizationPolicy 리소스가 성공적으로 생성되었는지 확인합니다.

    $ oc get authorizationpolicies -n <namespace_for_service_mesh_instance>

    다음 예와 유사한 출력이 표시되는지 확인합니다.

    NAME               AGE
    kserve-predictor   28h
  • EnvoyFilter 리소스가 성공적으로 생성되었는지 확인합니다.

    $ oc get envoyfilter -n <namespace_for_service_mesh_instance>

    다음 예와 유사한 출력이 표시되는지 확인합니다.

    NAME                                          AGE
    activator-host-header                         28h

3.4. 단일 모델 제공 플랫폼에 대한 권한 부여 공급자 추가

Authorino 를 단일 모델 제공 플랫폼의 권한 부여 공급자로 추가할 수 있습니다. 권한 부여 공급자를 추가하면 플랫폼에 배포하는 모델에 대한 토큰 권한 부여를 활성화할 수 있으므로 권한이 있는 당사자만 모델에 대한 유추 요청을 수행할 수 있습니다.

Authorino를 권한 부여 공급자로 추가하는 데 사용하는 방법은 단일 모델 제공 플랫폼을 설치하는 방법에 따라 다릅니다. 플랫폼의 설치 옵션은 다음과 같습니다.

자동 설치

OpenShift 클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 아직 생성하지 않은 경우 KServe 및 해당 종속 항목을 설치하도록 Red Hat OpenShift AI Operator를 구성할 수 있습니다. Authorino를 자동화된 설치 프로세스의 일부로 포함할 수 있습니다.

Authorino를 포함한 자동 설치에 대한 자세한 내용은 KServe의 자동 설치 구성을 참조하십시오.

수동 설치

OpenShift 클러스터에서 ServiceMeshControlPlane 또는 KNativeServing 리소스를 이미 생성한 경우 KServe 및 해당 종속 항목을 설치하도록 Red Hat OpenShift AI Operator를 구성할 수 없습니다. 이 경우 KServe를 수동으로 설치해야 합니다. Authorino를 수동으로 설정해야 합니다.

Authorino를 포함한 수동 설치에 대한 자세한 내용은 KServe 수동 설치를 참조하십시오.

3.5. 단일 모델 제공 플랫폼을 사용하여 모델 배포

단일 모델 제공 플랫폼에서 각 모델은 자체 모델 서버에 배포됩니다. 이를 통해 증가된 리소스가 필요한 대규모 모델을 배포, 모니터링, 확장 및 유지 관리할 수 있습니다.

중요

단일 모델 제공 플랫폼을 사용하여 자체 서명된 SSL 인증서를 사용하는 S3 호환 스토리지에서 모델을 배포하려면 OpenShift 클러스터에 CA(인증 기관) 번들을 설치해야 합니다. 자세한 내용은 인증서 작업을 참조하십시오.

3.5.1. 단일 모델 제공 플랫폼 활성화

KServe를 설치하면 Red Hat OpenShift AI 대시보드를 사용하여 단일 모델 제공 플랫폼을 활성화할 수 있습니다. 대시보드를 사용하여 플랫폼의 모델 제공 런타임을 활성화할 수도 있습니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 admin 그룹(예: rhoai-admins)의 일부입니다.
  • KServe를 설치했습니다.
  • 클러스터 관리자가 KServe 구성 요소를 사용하는 단일 모델 제공 플랫폼을 선택하는 기능을 비활성화하도록 OpenShift AI 대시보드 구성을 편집 하지 않았습니다. 자세한 내용은 대시보드 구성 옵션을 참조하십시오.

프로세스

  1. 다음과 같이 플랫폼을 제공하는 단일 모델을 활성화합니다.

    1. 왼쪽 메뉴에서 설정클러스터 설정을 클릭합니다.
    2. 모델 제공 플랫폼 섹션을 찾습니다.
    3. 프로젝트에 단일 모델 제공 플랫폼을 활성화하려면 단일 모델 제공 플랫폼 확인란을 선택합니다.
    4. 변경 사항 저장을 클릭합니다.
  2. 다음과 같이 단일 모델 제공 플랫폼에 대해 사전 설치된 런타임을 활성화합니다.

    1. OpenShift AI 대시보드의 왼쪽 메뉴에서 설정Serving 런타임 을 클릭합니다.

      Serving 런타임 페이지에는 사용자가 추가한 모든 사용자 정의 런타임과 다음과 같은 사전 설치된 런타임이 표시됩니다.

      • KServe를 위한 Cainitiatort TGIS ServingRuntime
      • OpenVino Model Server
      • KServe 용 TGIS Standalone ServingRuntime
    2. 사용할 런타임을 Enabled 로 설정합니다.

      단일 모델 제공 플랫폼은 이제 모델 배포에 사용할 수 있습니다.

3.5.2. 단일 모델 제공 플랫폼에 대한 사용자 정의 모델 서비스 런타임 추가

모델 서비스 런타임은 지정된 모델 프레임워크 집합(즉, 형식)에 대한 지원을 추가합니다. OpenShift AI에 포함된 사전 설치된 런타임 을 사용하거나 자체 사용자 지정 런타임을 추가하는 옵션이 있습니다. 이는 사전 설치된 런타임이 요구 사항을 충족하지 않는 경우에 유용합니다. 예를 들어 TGIS 런타임에서 TGI (TGI) 에서 지원하는 특정 모델 형식을 지원하지 않는 경우가 있습니다. 이 경우 사용자 지정 런타임을 생성하여 모델에 대한 지원을 추가할 수 있습니다.

관리자는 OpenShift AI 인터페이스를 사용하여 사용자 지정 모델 제공 런타임을 추가하고 활성화할 수 있습니다. 그런 다음 단일 모델 제공 플랫폼에 모델을 배포할 때 사용자 지정 런타임을 선택할 수 있습니다.

참고

OpenShift AI를 사용하면 고유한 사용자 지정 런타임을 추가할 수 있지만 런타임 자체를 지원하지는 않습니다. 사용자 지정 런타임을 올바르게 구성하고 유지 관리해야 합니다. 또한 사용자가 추가한 모든 사용자 지정 런타임을 사용할 수 있는지 확인해야 합니다.

사전 요구 사항

  • 관리자로 OpenShift AI에 로그인했습니다.
  • 사용자 지정 런타임을 빌드하고 Quay 와 같은 컨테이너 이미지 리포지토리에 이미지를 추가했습니다.

프로세스

  1. OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.

    Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.

  2. 사용자 지정 런타임을 추가하려면 다음 옵션 중 하나를 선택합니다.

    • 기존 런타임(예: KServe의 경우 TGIS Standalone ServingRuntime)으로 시작하려면 기존 런타임 옆에 있는 작업 메뉴(예: TGIS Standalone ServingRuntime)를 클릭한 다음 중복 을 클릭합니다.
    • 새 사용자 지정 런타임을 추가하려면 제공 런타임 추가 를 클릭합니다.
  3. Select the model serving platforms this runtime supports list, select Single-model serving platform.
  4. Select the API protocol this runtime supports list에서 지원하는 REST 또는 gRPC 를 선택합니다.
  5. 선택 사항: 새 런타임을 시작한 경우(기존 런타임을 복제하지 않고) 다음 옵션 중 하나를 선택하여 코드를 추가합니다.

    • YAML 파일 업로드

      1. 파일 업로드 를 클릭합니다.
      2. 파일 브라우저에서 컴퓨터에서 YAML 파일을 선택합니다.

        포함된 YAML 편집기가 열리고 업로드한 파일의 내용이 표시됩니다.

    • 편집기에서 직접 YAML 코드를 입력합니다.

      1. 처음부터 시작을 클릭합니다.
      2. 포함된 편집기에서 YAML 코드를 직접 입력하거나 붙여넣습니다.
    참고

    대부분의 경우 사용자 지정 런타임을 생성하려면 ServingRuntime 사양의 env 섹션에 새 또는 사용자 지정 매개변수를 추가해야 합니다.

  6. 추가를 클릭합니다.

    Serving 런타임 페이지가 열리고 설치된 업데이트된 런타임 목록이 표시됩니다. 추가한 사용자 지정 런타임이 자동으로 활성화되어 있는지 확인합니다. 런타임을 생성할 때 지정한 API 프로토콜이 표시됩니다.

  7. 선택 사항: 사용자 지정 런타임을 편집하려면 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.

검증

  • 추가한 사용자 정의 모델 제공 런타임은 Serving 런타임 페이지에 활성화된 상태로 표시됩니다.

3.5.3. 단일 모델 제공 플랫폼에 모델 배포

단일 모델 제공 플랫폼을 활성화하면 사전 설치 또는 사용자 정의 모델 제공 런타임을 활성화하고 플랫폼에 모델을 배포할 수 있습니다.

참고

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를 설치했습니다.
  • 단일 모델 제공 플랫폼을 활성화했습니다.
  • 데이터 과학 프로젝트를 생성했습니다.
  • S3 호환 오브젝트 스토리지에 액세스할 수 있습니다.
  • 배포하려는 모델의 경우 S3 호환 오브젝트 스토리지 버킷의 관련 폴더 경로를 알고 있습니다.
  • Cakeygent-TGIS 런타임을 사용하려면 모델을 Cafindt 형식으로 변환했습니다. 예를 들어 caovnt-tgis-serving 리포지토리의 cakeyt 형식으로의 Hugging faces Hub 모델 변환을 참조하십시오.
  • 모델 서버에서 GPU(그래픽 처리 장치)를 사용하려는 경우 OpenShift AI에서 GPU 지원을 활성화했습니다. OpenShift AI에서 GPU 지원 활성화를 참조하십시오.

프로세스

  1. 왼쪽 메뉴에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 모델을 배포할 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 다음 작업 중 하나를 수행합니다.

    • 플랫폼 타일을 제공하는 단일 모델이 표시되면 타일에 모델 배포를 클릭합니다.
    • 타일이 표시되지 않으면 모델 배포 버튼을 클릭합니다.

    모델 배포 대화 상자가 열립니다.

  5. 모델 이름 필드에 배포하려는 모델의 고유 이름을 입력합니다.
  6. Serving 런타임 필드에서 활성화된 런타임을 선택합니다.
  7. 모델 프레임워크 목록에서 값을 선택합니다.
  8. 배포할 모델 복제본 수 에서 값을 지정합니다.
  9. 모델 서버 크기 목록에서 값을 선택합니다.From the Model server size list, select a value.
  10. 배포된 모델에 대한 유추 요청에 대한 토큰 권한 부여가 필요한 경우 다음 작업을 수행합니다.

    1. 토큰 권한 부여 필요 를 선택합니다.
    2. 서비스 계정 이름 필드에 토큰이 생성될 서비스 계정 이름을 입력합니다.
  11. 모델의 위치를 지정하려면 다음 작업 세트 중 하나를 수행합니다.

    • 기존 데이터 연결 사용

      1. 기존 데이터 연결을 선택합니다.
      2. 이름 목록에서 이전에 정의한 데이터 연결을 선택합니다.
      3. 경로 필드에서 지정된 데이터 소스에 모델이 포함된 폴더 경로를 입력합니다.

        중요

        OpenVINO 모델 서버 런타임에는 모델 경로를 지정하는 방법에 대한 특정 요구 사항이 있습니다. 자세한 내용은 OpenShift AI 릴리스 노트의 알려진 문제 RHOAIENG-3025 를 참조하십시오.

    • 새 데이터 연결 사용

      1. 모델에 액세스할 수 있는 새 데이터 연결을 정의하려면 새 데이터 연결을 선택합니다.
      2. 이름 필드에 데이터 연결의 고유 이름을 입력합니다.
      3. 액세스 키 필드에 S3 호환 오브젝트 스토리지 공급자의 액세스 키 ID를 입력합니다.
      4. Secret 키 필드에 지정한 S3 호환 오브젝트 스토리지 계정의 시크릿 액세스 키를 입력합니다.
      5. Endpoint 필드에 S3 호환 오브젝트 스토리지 버킷의 끝점을 입력합니다.
      6. Region 필드에 S3 호환 오브젝트 스토리지 계정의 기본 리전을 입력합니다.
      7. Bucket 필드에 S3 호환 오브젝트 스토리지 버킷의 이름을 입력합니다.
      8. 경로 필드에 데이터 파일이 포함된 S3 호환 오브젝트 스토리지에 폴더 경로를 입력합니다.

        중요

        OpenVINO 모델 서버 런타임에는 모델 경로를 지정하는 방법에 대한 특정 요구 사항이 있습니다. 자세한 내용은 OpenShift AI 릴리스 노트의 알려진 문제 RHOAIENG-3025 를 참조하십시오.

  12. Deploy 를 클릭합니다.

검증

  • 배포된 모델이 프로젝트의 모델 탭과 상태 열에 확인 표시를 사용하여 대시보드의 모델 Serving 페이지에 표시되는지 확인합니다.

3.6. 단일 모델 제공 플랫폼에 배포된 모델에 대한 추론 요청

단일 모델 제공 플랫폼을 사용하여 모델을 배포할 때 API 요청을 사용하여 액세스할 수 있는 서비스로 모델을 사용할 수 있습니다. 이를 통해 데이터 입력을 기반으로 예측을 반환할 수 있습니다. API 요청을 사용하여 배포된 모델과 상호 작용하려면 모델의 유추 끝점을 알아야 합니다.

또한 토큰 승인을 활성화하여 유추 끝점을 보호하는 경우 유추 요청에 이를 지정할 수 있도록 권한 부여 토큰에 액세스하는 방법을 알아야 합니다.

3.6.1. 배포된 모델의 권한 부여 토큰 액세스

토큰 권한 부여를 활성화하여 모델 유추 엔드포인트를 보호하는 경우 유추 요청에 지정할 수 있도록 권한 부여 토큰에 액세스하는 방법을 알아야 합니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • 단일 모델 제공 플랫폼을 사용하여 모델을 배포했습니다.

프로세스

  1. OpenShift AI 대시보드에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 배포된 모델이 포함된 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 모델 및 모델 서버 목록에서 모델의 섹션을 확장합니다.

    권한 부여 토큰은 토큰 권한 부여 섹션의 토큰 시크릿 필드에 표시됩니다.

  5. 선택 사항: 유추 요청에 사용할 권한 부여 토큰을 복사하려면 토큰 값 옆에 있는 복사 버튼( osd copy )을 클릭합니다.

3.6.2. 배포된 모델의 유추 끝점에 액세스

배포된 모델에 대한 유추 요청을 만들려면 사용 가능한 유추 엔드포인트에 액세스하는 방법을 알아야 합니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 사용자 그룹 또는 관리자 그룹(예: rhoai-users 또는 rhoai-admins)의 일부입니다.
  • 단일 모델 제공 플랫폼을 사용하여 모델을 배포했습니다.
  • 배포된 모델에 대한 토큰 권한 부여를 활성화한 경우 연결된 토큰 값이 있습니다.

프로세스

  1. OpenShift AI 대시보드에서 Data Science Projects 를 클릭합니다.

    Data Science Projects 페이지가 열립니다.

  2. 배포된 모델이 포함된 프로젝트의 이름을 클릭합니다.

    프로젝트 세부 정보 페이지가 열립니다.

  3. 모델 탭을 클릭합니다.
  4. 모델 및 모델 서버 목록에서 모델의 섹션을 확장합니다.

    모델의 유추 끝점은 유추 끝점 필드에 표시됩니다.

  5. 모델에서 수행할 작업에 따라(및 모델이 해당 작업을 지원하는 경우), 표시된 추론 끝점을 복사한 다음 URL 끝에 다음 경로 중 하나를 추가합니다.

    KServe를 위한 Cainitiatort TGIS ServingRuntime

    • :443/api/v1/task/text-generation
    • :443/api/v1/task/server-streaming-text-generation

    KServe 용 TGIS Standalone ServingRuntime

    • :443 fmaas.GenerationService/Generate
    • :443 fmaas.GenerationService/GenerateStream

      참고

      TGIS 독립 실행형 런타임의 끝점을 쿼리하려면 IBM text-generation-inference 리포지토리의 proto 디렉터리에 파일을 다운로드해야 합니다.

    OpenVino Model Server

    • /v2/models/<model-name>/infer

    표시된 경로에 표시된 대로 단일 모델 제공 플랫폼은 OpenShift 라우터의 HTTPS 포트(일반적으로 포트 443)를 사용하여 외부 API 요청을 처리합니다.

  6. 다음 예제 명령에 표시된 대로 끝점을 사용하여 배포된 모델에 API 요청을 수행합니다.

    KServe를 위한 Cainitiatort TGIS ServingRuntime

    curl --json '{"model_id": "<model_name>", "inputs": "<text>"}' https://<inference_endpoint_url>:443/api/v1/task/server-streaming-text-generation -H 'Authorization: Bearer <token>'  1
    1
    모델을 배포할 때 토큰 권한 부여를 활성화한 경우에만 인증 헤더를 추가하고 토큰 값을 지정해야 합니다.

    KServe 용 TGIS Standalone ServingRuntime

    grpcurl -proto text-generation-inference/proto/generation.proto -d '{"requests": [{"text":"<text>"}]}' -H 'mm-model-id: <model_name>' -H 'Authorization: Bearer <token>' -insecure <inference_endpoint_url>:443 fmaas.GenerationService/Generate  1
    1
    모델을 배포할 때 토큰 권한 부여를 활성화한 경우에만 인증 헤더를 추가하고 토큰 값을 지정해야 합니다.

    OpenVino Model Server

    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>'  1
    1
    모델을 배포할 때 토큰 권한 부여를 활성화한 경우에만 인증 헤더를 추가하고 토큰 값을 지정해야 합니다.

3.7. 단일 모델 제공 플랫폼에 대한 모델 제공 런타임 메트릭 보기

클러스터 관리자가 단일 모델 서비스 플랫폼에 대한 모니터링을 구성한 경우 관리자가 아닌 사용자는 OpenShift 웹 콘솔을 사용하여 KServe 구성 요소의 모델 제공 런타임 지표를 볼 수 있습니다.

사전 요구 사항

프로세스

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 개발자 화면으로 전환합니다.
  3. 왼쪽 메뉴에서 모니터링 을 클릭합니다.
  4. 사용자 정의 프로젝트의 메트릭을 개발자(Red Hat OpenShift Dedicated)로 쿼리하거나 사용자 정의 프로젝트에 대한 메트릭을 개발자(AWS의 Red Hat OpenShift Service)로 쿼리하는 데 설명된 대로 웹 콘솔을 사용하여 cakeygent _*, tgi_* ovms_* 모델-serving 런타임 메트릭에 대한 쿼리를 실행합니다. OpenShift Service Mesh와 관련된 istio_* 메트릭에 대한 쿼리를 실행할 수도 있습니다.

추가 리소스

3.8. 단일 모델 제공 플랫폼에서 성능 튜닝

특정 성능 문제를 해결하려면 유추 서비스 또는 모델 제공 런타임의 매개변수를 조정해야 할 수 있습니다.

3.8.1. 메모리 부족 오류 해결

어떤 경우에는 사용된 모델 및 하드웨어 가속기에 따라 TGIS 메모리 자동 튜닝 알고리즘은 긴 시퀀스를 처리하는 데 필요한 GPU 메모리 양을 과소평가할 수 있습니다. 이러한 오류로 인해 모델 서버의 Compute Unified Architecture (CUDA) 메모리 부족(OOM) 오류 응답이 발생할 수 있습니다. 이러한 경우 다음 절차에 설명된 대로 TGIS 모델 제공 런타임에서 매개변수를 업데이트하거나 추가해야 합니다.

사전 요구 사항

  • Red Hat OpenShift AI에 로그인했습니다.
  • 특수 OpenShift AI 그룹을 사용하는 경우 OpenShift에서 admin 그룹(예: rhoai-admins)의 일부입니다.

프로세스

  1. OpenShift AI 대시보드에서 설정 > Serving 런타임 을 클릭합니다.

    Serving 런타임 페이지가 열리고 이미 설치 및 활성화된 모델 제공 런타임이 표시됩니다.

  2. 모델을 배포하는 데 사용한 런타임에 따라 다음 작업 중 하나를 수행합니다.

    • KServe 런타임에 사전 설치된 TGIS Standalone ServingRuntime을 사용한 경우 런타임을 복제하여 사용자 지정 버전을 생성한 다음 이 절차의 나머지 부분을 따릅니다. 사전 설치된 TGIS 런타임 중복에 대한 자세한 내용은 단일 모델 제공 플랫폼의 사용자 지정 모델 제공 런타임 추가를 참조하십시오.
    • 사용자 지정 TGIS 런타임을 이미 사용 중인 경우 런타임 옆에 있는 작업 메뉴( Cryostat)를 클릭하고 편집을 선택합니다.

      포함된 YAML 편집기가 열리고 사용자 정의 model-serving 런타임 내용이 표시됩니다.

  3. 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 입니다.

  4. 업데이트를 클릭합니다.

    Serving 런타임 페이지가 열리고 설치된 런타임 목록이 표시됩니다. 업데이트된 사용자 정의 모델 제공 런타임이 표시되는지 확인합니다.

  5. 매개변수 업데이트를 적용하기 위해 모델을 재배포하려면 다음 작업을 수행합니다.

    1. OpenShift AI 대시보드에서 Model Serving > Deployed Models 를 클릭합니다.
    2. 재배포할 모델을 찾고 모델 옆에 있는 작업 메뉴( Cryostat)를 클릭하고 삭제 를 선택합니다.
    3. 단일 모델 제공 플랫폼에서 모델 배포에 설명된 대로 모델을 재배포합니다.

검증

  • 모델 서버에서 성공적으로 응답이 수신되고 더 이상 CUDA OOM 오류가 표시되지 않습니다.

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.