Kjør ensemble ML-modeller på Amazon SageMaker

Modellimplementering i maskinlæring (ML) blir stadig mer kompleks. Du vil ikke bare distribuere én ML-modell, men store grupper av ML-modeller representert som ensemble-arbeidsflyter. Disse arbeidsflytene består av flere ML-modeller. Å produsere disse ML-modellene er utfordrende fordi du må overholde ulike krav til ytelse og ventetid.

Amazon SageMaker støtter enkeltforekomstensembler med Triton Inference Server. Denne funksjonen lar deg kjøre modellensembler som passer på en enkelt forekomst. Bak kulissene utnytter SageMaker Triton Inference Server for å administrere ensemblet på hver forekomst bak endepunktet for å maksimere gjennomstrømming og maskinvareutnyttelse med ultralav (ensifret millisekunder) inferensforsinkelse. Med Triton kan du også velge fra et bredt utvalg av støttede ML-rammeverk (inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, inkludert GPUer, CPUer og AWS slutning.

Med denne funksjonen på SageMaker kan du optimalisere arbeidsbelastningen din ved å unngå kostbar nettverksforsinkelse og høste fordelene av databehandling og datalokalitet for ensemble-inferensrørledninger. I dette innlegget diskuterer vi fordelene ved å bruke Triton Inference Server sammen med vurderinger om dette er det riktige alternativet for arbeidsmengden din.

Løsningsoversikt

Triton Inference Server er designet for å gjøre det mulig for team å distribuere, kjøre og skalere trente AI-modeller fra ethvert rammeverk på en hvilken som helst GPU- eller CPU-basert infrastruktur. I tillegg har den blitt optimert for å tilby høyytelses inferens i skala med funksjoner som dynamisk batching, samtidige kjøringer, optimal modellkonfigurasjon, modellensemble-funksjoner og støtte for streaming-innganger.

Arbeidsbelastninger bør ta hensyn til egenskapene som Triton gir for å sikre at modellene deres kan betjenes. Triton støtter en rekke populære rammeverk ut av esken, inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT. Triton støtter også ulike backends som kreves for at algoritmer skal fungere ordentlig. Du bør sørge for at modellene dine støttes av disse backends, og i tilfelle en backend ikke gjør det, lar Triton deg implementere din egen og integrere den. Du bør også bekrefte at algoritmeversjonen din støttes, samt sørge for at modellartefaktene er akseptable av den tilsvarende backend. For å sjekke om din spesifikke algoritme støttes, se Triton Inference Server Backend for en liste over egenstøttede backends vedlikeholdt av NVIDIA.

Det kan være noen scenarier der modellene eller modellensemblene dine ikke vil fungere på Triton uten å kreve mer innsats, for eksempel hvis det ikke finnes en egenstøttet backend for algoritmen din. Det er noen andre hensyn å ta i betraktning, for eksempel at nyttelastformatet kanskje ikke er ideelt, spesielt når nyttelaststørrelsen kan være stor for forespørselen din. Som alltid bør du validere ytelsen din etter å ha distribuert disse arbeidsbelastningene for å sikre at forventningene dine oppfylles.

La oss ta en modell for bildeklassifisering av nevrale nettverk og se hvordan vi kan akselerere arbeidsbelastningen vår. I dette eksemplet bruker vi NVIDIA DALI-backend for å akselerere forbehandlingen vår i sammenheng med vårt ensemble.

Lag Triton-modellensembler

Triton Inference Server forenkler distribusjonen av AI-modeller i stor skala. Triton Inference Server kommer med en praktisk løsning som forenkler bygging av for- og etterbehandlingsrørledninger. Triton Inference Server-plattformen gir ensembleplanleggeren, som du kan bruke til å bygge pipelining-ensemblemodeller som deltar i inferensprosessen samtidig som du sikrer effektivitet og optimaliserer gjennomstrømningen.

Triton Inference Server betjener modeller fra modelllager. La oss se på modelllageroppsettet for ensemblemodellen som inneholder DALI-forbehandlingsmodellen, TensorFlow inception V3-modellen og modellensemblekonfigurasjonen. Hver underkatalog inneholder depotinformasjon for de tilsvarende modellene. De config.pbtxt filen beskriver modellkonfigurasjonen for modellene. Hver katalog må ha én numerisk undermappe for hver versjon av modellen, og den drives av en spesifikk backend som Triton støtter.

NVIDIA DALI

For dette innlegget bruker vi NVIDIA Data Loading Library (DALI) som forbehandlingsmodell i vårt modellensemble. NVIDIA DALI er et bibliotek for datalasting og forhåndsbehandling for å akselerere dyplæringsapplikasjoner. Den gir en samling av optimaliserte byggeklosser for lasting og behandling av bilde-, video- og lyddata. Du kan bruke den som en bærbar drop-in-erstatning for innebygde datalastere og dataiteratorer i populære dyplæringsrammer.

Følgende kode viser modellkonfigurasjonen for en DALI-backend:

name: "dali"
backend: "dali"
max_batch_size: 256
input [
  {
    name: "DALI_INPUT_0"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "DALI_OUTPUT_0"
    data_type: TYPE_FP32
    dims: [ 299, 299, 3 ]
  }
]
parameters: [
  {
    key: "num_threads"
    value: { string_value: "12" }
  }
]

Inception V3-modell

For dette innlegget viser vi hvordan DALI brukes i et modellensemble med Inception V3. Den forhåndstrente Inception V3 TensorFlow-modellen er lagret i GraphDef-format som en enkelt fil med navn model.graphdef. De config.pbtxt filen har informasjon om modellnavnet, plattformen, max_batch_size, og input- og outputkontrakter. Vi anbefaler å stille inn max_batch_size konfigurasjon til mindre enn den opprinnelige V3-modellens batchstørrelse. Etikettfilen har klasseetiketter for 1,000 forskjellige klasser. Vi kopierer etikettene for startklassifiseringsmodellen til inception_graphdef katalogen i modelllageret. Etikettfilen inneholder 1,000 klasseetiketter av IMAGEnet klassifiseringsdatasett.

name: "inception_graphdef"
platform: "tensorflow_graphdef"
max_batch_size: 256
input [
  {
    name: "input"
    data_type: TYPE_FP32
    format: FORMAT_NHWC
    dims: [ 299, 299, 3 ]
  }
]
output [
  {
    name: "InceptionV3/Predictions/Softmax"
    data_type: TYPE_FP32
    dims: [ 1001 ]
    label_filename: "inception_labels.txt"
  }
]

Triton ensemble

Følgende kode viser en modellkonfigurasjon av en ensemblemodell for DALI-forbehandling og bildeklassifisering:

name: "ensemble_dali_inception"
platform: "ensemble"
max_batch_size: 256
input [
  {
    name: "INPUT"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "OUTPUT"
    data_type: TYPE_FP32
    dims: [ 1001 ]
  }
]
ensemble_scheduling {
  step [
    {
      model_name: "dali"
      model_version: -1
      input_map {
        key: "DALI_INPUT_0"
        value: "INPUT"
      }
      output_map {
        key: "DALI_OUTPUT_0"
        value: "preprocessed_image"
      }
    },
    {
      model_name: "inception_graphdef"
      model_version: -1
      input_map {
        key: "input"
        value: "preprocessed_image"
      }
      output_map {
        key: "InceptionV3/Predictions/Softmax"
        value: "OUTPUT"
      }
    }
  ]
}

Opprett et SageMaker-endepunkt

SageMaker-endepunkter tillate sanntids hosting der millisekunders responstid kreves. SageMaker tar på seg de udifferensierte tunge løft av modell hosting management og har muligheten til å automatisk skalere. I tillegg er det også gitt en rekke funksjoner, inkludert hosting av flere varianter av modellen din, A/B-testing av modellene dine, integrasjon med Amazon CloudWatch for å få observerbarhet av modellytelse, og overvåking for modelldrift.

La oss lage en SageMaker-modell fra modellartefaktene vi lastet opp til Amazon enkel lagringstjeneste (Amazon S3).

Deretter gir vi også en ekstra miljøvariabel: SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, som spesifiserer navnet på modellen som skal lastes av Triton. Verdien av denne nøkkelen skal samsvare med mappenavnet i modellpakken lastet opp til Amazon S3. Denne variabelen er valgfri i tilfeller der du bruker én enkelt modell. Når det gjelder ensemblemodeller, må denne nøkkelen spesifiseres for at Triton skal starte opp i SageMaker.

I tillegg kan du stille inn SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT og SAGEMAKER_TRITON_THREAD_COUNT for å optimalisere trådantallet.

container = {
    "Image": triton_image_uri,
    "ModelDataUrl": model_uri,
    "Environment": {"SAGEMAKER_TRITON_DEFAULT_MODEL_NAME": "ensemble_dali_inception"},
}
create_model_response = sm_client.create_model(
    ModelName=sm_model_name, ExecutionRoleArn=role, PrimaryContainer=container
)

Med den foregående modellen lager vi en endepunktkonfigurasjon der vi kan spesifisere typen og antall forekomster vi ønsker i endepunktet:

create_endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "InstanceType": instance_type,
            "InitialVariantWeight": 1,
            "InitialInstanceCount": 1,
            "ModelName": sm_model_name,
            "VariantName": "AllTraffic",
        }
    ],
)
endpoint_config_arn = create_endpoint_config_response["EndpointConfigArn"]

Vi bruker denne endepunktkonfigurasjonen til å opprette et nytt SageMaker-endepunkt og venter på at distribusjonen er ferdig. Statusen endres til InService når distribusjonen er vellykket.

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name
)
endpoint_arn = create_endpoint_response["EndpointArn"]

Inferens nyttelast

Inndata nyttelastbildet går gjennom forbehandlings-DALI-rørledningen og brukes i ensembleplanleggeren levert av Triton Inference Server. Vi konstruerer nyttelasten som skal sendes til slutningsendepunktet:

payload = {
    "inputs": [
        {
            "name": "INPUT",
            "shape": rv2.shape,
            "datatype": "UINT8",
            "data": rv2.tolist(),
        }
    ]
}

Ensemble slutning

Når vi kjører endepunktet, kan vi bruke eksempelbildet til å utføre en slutningsforespørsel ved å bruke JSON som nyttelastformat. For inferensforespørselsformatet bruker Triton KFServing fellesskapsstandard inferensprotokoller.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name, ContentType="application/octet-stream", Body=json.dumps(payload)
)
print(json.loads(response["Body"].read().decode("utf8")))

Med binary+json format, må vi spesifisere lengden på forespørselens metadata i overskriften for å tillate Triton å analysere den binære nyttelasten korrekt. Dette gjøres ved å bruke en tilpasset Content-Type-overskrift application/vnd.sagemaker-triton.binary+json;json-header-size={}.

Dette er forskjellig fra å bruke en Inference-Header-Content-Length header på en frittstående Triton-server fordi egendefinerte overskrifter ikke er tillatt i SageMaker.

Tritonclient-pakken gir verktøymetoder for å generere nyttelasten uten å måtte vite detaljene i spesifikasjonen. Vi bruker følgende metoder for å konvertere slutningsforespørselen vår til et binært format, som gir lavere forsinkelser for slutninger. Se GitHub bærbare for implementeringsdetaljer.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name,
    ContentType="application/vnd.sagemaker-triton.binary+json;json-header-size={}".format(
        header_length
    ),
    Body=request_body,
)

konklusjonen

I dette innlegget viste vi frem hvordan du kan produsere modellensembler som kjører på en enkelt forekomst på SageMaker. Dette designmønsteret kan være nyttig for å kombinere enhver forbehandlings- og etterbehandlingslogikk sammen med slutningsforutsigelser. SageMaker bruker Triton til å kjøre ensemble-inferensen på en enkelt beholder på en instans som støtter alle større rammeverk.

For flere eksempler på Triton-ensembler på SageMaker, se GitHub repo. Prøv det!

Om forfatterne

James Park er løsningsarkitekt hos Amazon Web Services. Han jobber med Amazon.com for å designe, bygge og distribuere teknologiløsninger på AWS, og har en spesiell interesse for AI og maskinlæring. På fritiden liker han å oppsøke nye kulturer, nye opplevelser og holde seg oppdatert med de nyeste teknologitrendene.

Vikram Elango er senior AI/ML spesialistløsningsarkitekt hos Amazon Web Services, basert i Virginia, USA. Vikram hjelper finans- og forsikringsbransjens kunder med design og tankeledelse med å bygge og distribuere maskinlæringsapplikasjoner i stor skala. Han er for tiden fokusert på naturlig språkbehandling, ansvarlig AI, inferensoptimalisering og skalering av ML på tvers av bedriften. På fritiden liker han å reise, gå fotturer, lage mat og campe med familien.

Saurabh Trikande er senior produktsjef for Amazon SageMaker Inference. Han brenner for å jobbe med kunder og er motivert av målet om å demokratisere maskinlæring. Han fokuserer på kjerneutfordringer knyttet til distribusjon av komplekse ML-applikasjoner, multi-tenant ML-modeller, kostnadsoptimaliseringer og å gjøre distribusjon av dyplæringsmodeller mer tilgjengelig. På fritiden liker Saurabh å gå tur, lære om innovative teknologier, følge TechCrunch og tilbringe tid med familien.