Alibaba Cloud Service Mesh:Create a custom model serving runtime with ModelMesh

Pré-requisitos

Antes de começar, verifique se você tem:

• Um cluster do Container Service for Kubernetes (ACK) adicionado à sua instância do Service Mesh (ASM)

• Uma instância do ASM versão 1.18.0.134 ou posterior

Runtimes integrados

Antes de criar um runtime personalizado, verifique se já existe um runtime integrado compatível com o formato do seu modelo.

Se nenhum desses runtimes oferecer suporte ao seu framework ou se o pipeline de inferência exigir lógica personalizada, crie um runtime de serviço personalizado conforme descrito abaixo.

Como funciona

Um ServingRuntime (escopo de namespace) ou ClusterServingRuntime (escopo de cluster) define o modelo de pod para servir um ou mais formatos de modelo. Cada recurso especifica:

• A imagem de contêiner que executa o servidor de inferência

• Uma lista de formatos de modelo suportados

• Variáveis de ambiente para configuração do runtime

O ServingRuntime é uma CustomResourceDefinition (CRD) do Kubernetes. Assim, é possível criar runtimes reutilizáveis sem modificar o controlador do ModelMesh ou quaisquer recursos no namespace do controlador.

Para frameworks baseados em Python, a maneira mais rápida é estender o MLServer. O MLServer fornece a interface de serviço, você fornece a lógica do modelo e o ModelMesh gerencia o agendamento e o dimensionamento.

O fluxo de trabalho consiste em três etapas:

1. Implemente a classe do modelo estendendo a classe MLModel do MLServer.

2. Empacote a classe e suas dependências em uma imagem de contêiner.

3. Registre a imagem como um ServingRuntime no Kubernetes.

Etapa 1: Implementar a classe MLModel

Crie uma classe Python que herde da classe MLModel do MLServer. Implemente dois métodos:

• load() -- Inicializa o modelo (carrega pesos, aquece caches).

• predict() -- Executa a inferência em uma solicitação recebida.

from typing import List
from mlserver import MLModel, types
from mlserver.utils import get_model_uri

# List the filenames your model uses so MLServer can locate them.
WELLKNOWN_MODEL_FILENAMES = ["model.json", "model.dat"]

class CustomMLModel(MLModel):

    async def load(self) -> bool:
        model_uri = await get_model_uri(
            self._settings, wellknown_filenames=WELLKNOWN_MODEL_FILENAMES
        )
        # TODO: Load the model from model_uri and store it as an instance attribute.
        #       Example: self._model = joblib.load(model_uri)
        self.ready = True
        return self.ready

    async def predict(
        self, payload: types.InferenceRequest
    ) -> types.InferenceResponse:
        payload = self._check_request(payload)
        return types.InferenceResponse(
            model_name=self.name,
            model_version=self.version,
            outputs=self._predict_outputs(payload),
        )

    def _check_request(self, payload):
        # TODO: Validate the request -- check input tensor names, shapes, and types.
        return payload

    def _predict_outputs(self, payload) -> List[types.ResponseOutput]:
        # TODO: Extract input data from payload.
        # TODO: Run the data through your model's prediction logic.
        # TODO: Construct and return a list of ResponseOutput objects.
        outputs = []
        return outputs

Para mais exemplos, consulte a documentação de runtime personalizado do MLServer.

Etapa 2: Empacotar o runtime em uma imagem de contêiner

Agrupe a classe CustomMLModel, o MLServer e todas as dependências em uma imagem de contêiner.

Opção A: Usar a CLI do MLServer (recomendado)

O MLServer oferece o comando mlserver build para gerar uma imagem automaticamente. Para obter detalhes, veja Criando uma imagem personalizada.

Opção B: Escrever um Dockerfile

# Use a Python base image that matches your dependency requirements.
FROM python:3.8-slim-buster
RUN pip install mlserver

# Place your MLModel implementation on the Python path.
COPY --chown=${USER} ./custom_model.py /opt/custom_model.py
ENV PYTHONPATH=/opt/

# Set environment variables for ModelMesh compatibility.
# These can also be set in the ServingRuntime YAML, but embedding them here
# ensures consistent behavior during local testing.
ENV MLSERVER_MODELS_DIR=/models/_mlserver_models \
    MLSERVER_GRPC_PORT=8001 \
    MLSERVER_HTTP_PORT=8002 \
    MLSERVER_LOAD_MODELS_AT_STARTUP=false \
    MLSERVER_MODEL_NAME=dummy-model

# Point MLServer to your class so the implementation field is optional
# in model settings.
ENV MLSERVER_MODEL_IMPLEMENTATION=custom_model.CustomMLModel

CMD ["mlserver", "start", "${MLSERVER_MODELS_DIR}"]

Compile e envie a imagem:

docker build -t <your-registry>/<your-image-name>:<tag> .
docker push <your-registry>/<your-image-name>:<tag>

Substitua os seguintes espaços reservados pelos valores reais:

Etapa 3: Criar o ServingRuntime

Defina um recurso ServingRuntime que aponte para sua imagem de contêiner e declare os formatos de modelo suportados.

apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
  name: <custom-runtime-name>          # Example: my-model-server-0.x
spec:
  supportedModelFormats:
    - name: <model-format-name>        # Example: my-model
      version: "1"
      autoSelect: true
  multiModel: true
  grpcDataEndpoint: port:8001
  grpcEndpoint: port:8085
  containers:
    - name: mlserver
      image: <your-image>              # The image built in Step 2
      env:
        - name: MLSERVER_MODELS_DIR
          value: "/models/_mlserver_models/"
        - name: MLSERVER_GRPC_PORT
          # Must match grpcDataEndpoint above.
          value: "8001"
        - name: MLSERVER_HTTP_PORT
          # Default is 8080, which conflicts with ModelMesh internal ports.
          value: "8002"
        - name: MLSERVER_LOAD_MODELS_AT_STARTUP
          # ModelMesh manages model loading; disable MLServer's built-in loader.
          value: "false"
        - name: MLSERVER_MODEL_NAME
          # Dummy name prevents MLServer from erroring when no models are loaded yet.
          value: dummy-model
        - name: MLSERVER_HOST
          # Bind to localhost so MLServer only listens inside the pod.
          value: "127.0.0.1"
        - name: MLSERVER_GRPC_MAX_MESSAGE_LENGTH
          # Unlimited (-1) because ModelMesh enforces its own message size limits.
          value: "-1"
      resources:
        requests:
          cpu: 500m
          memory: 1Gi
        limits:
          cpu: "5"
          memory: 1Gi
  builtInAdapter:
    serverType: mlserver
    runtimeManagementPort: 8001
    memBufferBytes: 134217728
    modelLoadingTimeoutMillis: 90000

Preencha os espaços reservados com os valores adequados:

Aplique o recurso:

kubectl apply -f <serving-runtime>.yaml

Após a criação do recurso, o runtime personalizado aparece na implantação do ModelMesh e fica pronto para servir modelos correspondentes ao formato declarado.

Etapa 4: Implantar um modelo

Crie um InferenceService para implantar um modelo no runtime personalizado. O InferenceService é o principal recurso que o KServe e o ModelMesh usam para gerenciar endpoints de modelo.

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: my-model-sample
  namespace: modelmesh-serving
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
spec:
  predictor:
    model:
      modelFormat:
        name: my-model                 # Must match the format declared in the ServingRuntime
      runtime: my-model-server         # Optional: explicitly select the runtime
      storage:
        key: localMinIO
        path: sklearn/mnist-svm.joblib

Campos principais:

Aplique o recurso:

kubectl apply -f <inference-service>.yaml

Verifique se o modelo está pronto:

kubectl get inferenceservice my-model-sample -n modelmesh-serving

Saída esperada:

NAME              URL   READY   AGE
my-model-sample         True    1m

A coluna READY exibe True após o ModelMesh concluir o carregamento do modelo no runtime personalizado.

Depuração

Se o runtime personalizado falhar ao carregar modelos ou retornar erros de inferência, ative o log de depuração adicionando estas variáveis de ambiente ao ServingRuntime:

env:
  - name: MLSERVER_DEBUG
    value: "true"
  - name: MLSERVER_MODEL_PARALLEL_WORKERS
    # Set to 0 to disable parallel workers, which simplifies log output.
    value: "0"

Consulte os logs do pod do runtime para obter mensagens de erro detalhadas:

kubectl logs -n modelmesh-serving <pod-name> -c mlserver

Próximos passos

• Saiba mais sobre runtimes personalizados do ModelMesh Serving na documentação upstream.

• Explore os exemplos de runtime personalizado do MLServer para conhecer padrões adicionais.