Paketera och distribuera klassiska ML och LLM enkelt med Amazon SageMaker, del 1: PySDK Improvements | Amazon webbtjänster

Amazon SageMaker är en helt hanterad tjänst som gör det möjligt för utvecklare och datavetare att snabbt och enkelt bygga, träna och distribuera modeller för maskininlärning (ML) i alla skala. SageMaker gör det enkelt att distribuera modeller i produktion direkt genom API-anrop till tjänsten. Modeller är förpackade i behållare för robusta och skalbara distributioner. Även om det ger olika ingångspunkter som SageMaker Python SDK, AWS SDK, SageMaker-konsolen och Amazon SageMaker Studio bärbara datorer för att förenkla processen att träna och distribuera ML-modeller i stor skala, letar kunder fortfarande efter bättre sätt att distribuera sina modeller för lekplatstestning och för att optimera produktionsinstallationer.

Vi lanserar två nya sätt att förenkla processen att paketera och distribuera modeller med SageMaker.

I det här inlägget presenterar vi den nya SageMaker Python SDK ModelBuilder erfarenhet, som syftar till att minimera inlärningskurvan för nya SageMaker-användare som datavetare, samtidigt som de hjälper erfarna MLOps-ingenjörer att maximera utnyttjandet av SageMakers värdtjänster. Det minskar komplexiteten i den initiala installationen och driftsättningen, och genom att ge vägledning om bästa praxis för att dra nytta av SageMakers fulla möjligheter. Vi tillhandahåller detaljerad information och GitHub-exempel för denna nya SageMaker-funktion.

Den andra nya lanseringen är att använda den nya interaktiva implementeringsupplevelsen i SageMaker Studio. Vi diskuterar detta i del 2.

Att distribuera modeller till en SageMaker-slutpunkt innebär en rad steg för att göra modellen redo att lagras på en SageMaker-slutpunkt. Detta innebär att få modellartefakterna i rätt format och struktur, skapa inferenskod och specificera väsentliga detaljer som modellbildens URL, Amazon enkel lagringstjänst (Amazon S3) placering av modellartefakter, serialiserings- och deserialiseringssteg och nödvändiga AWS identitets- och åtkomsthantering (IAM) roller för att underlätta lämpliga åtkomstbehörigheter. Efter detta kräver en slutpunktskonfiguration att man bestämmer slutledningstypen och konfigurerar respektive parametrar såsom instanstyper, antal och trafikfördelning mellan modellvarianter.

För att ytterligare hjälpa våra kunder när de använder SageMaker hosting, introducerade vi det nya ModelBuilder klass i SageMaker Python SDK, vilket ger följande viktiga fördelar när man distribuerar modeller till SageMaker-slutpunkter:

• Förenar implementeringsupplevelsen över ramar – Den nya upplevelsen ger ett konsekvent arbetsflöde för att distribuera modeller byggda med olika ramverk som PyTorch, TensorFlow och XGBoost. Detta förenklar driftsättningsprocessen.
• Automatiserar modelldistribution – Uppgifter som att välja lämpliga behållare, fånga beroenden och hantera serialisering/deserialisering är automatiserade, vilket minskar den manuella ansträngningen som krävs för distribution.
• Ger en smidig övergång från lokal till SageMaker värd slutpunkt – Med minimala kodändringar kan modeller enkelt övergå från lokal testning till implementering på en SageMaker-slutpunkt. Liveloggar gör felsökning sömlös.

Sammantaget SageMaker ModelBuilder förenklar och effektiviserar modellpaketeringsprocessen för SageMaker-inferens genom att hantera detaljer på låg nivå och tillhandahåller verktyg för testning, validering och optimering av slutpunkter. Detta förbättrar utvecklarnas produktivitet och minskar antalet fel.

I de följande avsnitten fördjupar vi oss i detaljerna i denna nya funktion. Vi diskuterar också hur man distribuerar modeller till SageMaker hosting med hjälp av ModelBuilder, vilket förenklar processen. Sedan går vi igenom några exempel för olika ramverk för att distribuera både traditionella ML-modeller och grundmodellerna som kraftgenererande AI använder fall.

Lär känna SageMaker ModelBuilder

Den nya ModelBuilder är en Python-klass fokuserad på att ta ML-modeller byggda med ramverk, som XGBoost eller PyTorch, och konvertera dem till modeller som är redo för driftsättning på SageMaker. ModelBuilder tillhandahåller en build() funktion, som genererar artefakter enligt modellservern, och en deploy() funktion för att distribuera lokalt eller till en SageMaker-slutpunkt. Introduktionen av denna funktion förenklar integrationen av modeller med SageMaker-miljön, vilket optimerar dem för prestanda och skalbarhet. Följande diagram visar hur ModelBuilder fungerar på hög nivå.

ModelBuilder klass

Smakämnen ModelBuilder klass ger olika alternativ för anpassning. Men för att distribuera rammodellen förväntar sig modellbyggaren bara modellen, input, output och roll:

class ModelBuilder( model, # model id or model object role_arn, # IAM role schema_builder, # defines the input and output mode, # select between local deployment and depoy to SageMaker Endpoints ...
)

SchemaBuilder

Smakämnen SchemaBuilder klass gör det möjligt för dig att definiera indata och utdata för din slutpunkt. Det tillåter schemabyggaren att generera motsvarande rangordningsfunktioner för att serialisera och deserialisera in- och utdata. Följande klassfil innehåller alla alternativ för anpassning:

class SchemaBuilder( sample_input: Any, sample_output: Any, input_translator: CustomPayloadTranslator = None, output_translator: CustomPayloadTranslator = None
)

Men i de flesta fall skulle bara provinmatning och -utgång fungera. Till exempel:

input = "How is the demo going?"
output = "Comment la démo va-t-elle?"
schema = SchemaBuilder(input, output)

Genom att tillhandahålla exempelinmatning och -utgång, SchemaBuilder kan automatiskt fastställa nödvändiga transformationer, vilket gör integrationsprocessen enklare. För mer avancerade användningsfall finns det flexibilitet att tillhandahålla anpassade översättningsfunktioner för både input och output, vilket säkerställer att mer komplexa datastrukturer också kan hanteras effektivt. Vi visar detta i följande avsnitt genom att använda olika modeller med olika ramverk ModelBuilder.

Erfarenhet av lokalt läge

I det här exemplet använder vi ModelBuilder för att distribuera XGBoost-modellen lokalt. Du kan använda Mode för att växla mellan lokal testning och distribution till en SageMaker-slutpunkt. Vi tränar först XGBoost-modellen (lokalt eller i SageMaker) och lagrar modellartefakterna i arbetskatalogen:

# Train the model
model = XGBClassifier()
model.fit(X_train, y_train)
model.save_model(model_dir + "/my_model.xgb")

Sedan skapar vi ett ModelBuilder-objekt genom att skicka det faktiska modellobjektet, den SchemaBuilder som använder provinmatnings- och utdataobjekten (samma indata och utdata som vi använde när vi tränade och testade modellen) för att sluta sig till den serialisering som behövs. Observera att vi använder Mode.LOCAL_CONTAINER för att ange en lokal distribution. Efter det ringer vi till SLUTRESULTAT funktion för att automatiskt identifiera den stödda rambehållarbilden samt skanna efter beroenden. Se följande kod:

model_builder_local = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, mode=Mode.LOCAL_CONTAINER
)
xgb_local_builder = model_builder_local.build()

Äntligen kan vi ringa deploy funktion i modellobjektet, som även ger liveloggning för enklare felsökning. Du behöver inte ange instanstyp eller antal eftersom modellen kommer att distribueras lokalt. Om du angav dessa parametrar kommer de att ignoreras. Denna funktion kommer att returnera prediktorobjektet som vi kan använda för att göra förutsägelser med testdata:

# note: all the serialization and deserialization is handled by the model builder.
predictor_local = xgb_local_builder.deploy(
# instance_type='ml.c5.xlarge',
# initial_instance_count=1
) # Make prediction for test data. predictor_local.predict(X_test)

Alternativt kan du också styra laddningen av modellen och förbearbetning och efterbearbetning med hjälp av InferenceSpec. Vi ger mer information senare i detta inlägg. Använder sig av LOCAL_CONTAINER är ett utmärkt sätt att testa ditt skript lokalt innan det distribueras till en SageMaker-slutpunkt.

Referera till modellbyggare-xgboost.ipynb exempel för att testa driftsättning både lokalt och till en SageMaker-slutpunkt med hjälp av ModelBuilder.

Distribuera traditionella modeller till SageMaker-slutpunkter

I följande exempel visar vi hur du använder ModelBuilder att distribuera traditionella ML-modeller.

XGBoost-modeller

I likhet med föregående avsnitt kan du distribuera en XGBoost-modell till en SageMaker-slutpunkt genom att ändra mode parameter när du skapar ModelBuilder objekt:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, mode=Mode.SAGEMAKER_ENDPOINT
)
xgb_builder = model_builder.build()
predictor = xgb_builder.deploy( instance_type='ml.c5.xlarge', initial_instance_count=1
)

Observera att när du distribuerar till SageMaker-slutpunkter måste du ange instanstypen och antalet instanser när du anropar deploy funktion.

Referera till modellbyggare-xgboost.ipynb exempel för att distribuera en XGBoost-modell.

Triton modeller

Du kan använda ModelBuilder att servera PyTorch-modeller på Triton Inference Server. För det måste du ange model_server parameter som ModelServer.TRITON, klara en modell och ha en SchemaBuilder objekt, som kräver exempelingångar och utdata från modellen. ModelBuilder tar hand om resten åt dig.

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(sample_input=sample_input, sample_output=sample_output), role_arn=execution_role, model_server=ModelServer.TRITON, mode=Mode.SAGEMAKER_ENDPOINT
) triton_builder = model_builder.build() predictor = triton_builder.deploy( instance_type='ml.g4dn.xlarge', initial_instance_count=1
)

Hänvisa till modellbyggare-triton.ipynb att distribuera en modell med Triton.

Hugging Face-modeller

I det här exemplet visar vi dig hur du distribuerar en förtränad transformatormodell från Hugging Face till SageMaker. Vi vill använda Hugging Face pipeline för att ladda modellen, så vi skapar en anpassad slutledningsspecifikation för ModelBuilder:

# custom inference spec with hugging face pipeline
class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return pipeline("translation_en_to_fr", model="t5-small") def invoke(self, input, model): return model(input) inf_spec = MyInferenceSpec()

Vi definierar också ingången och utmatningen av slutledningsarbetsbelastningen genom att definiera SchemaBuilder objekt baserat på modellens input och output:

schema = SchemaBuilder(value,output)

Sedan skapar vi ModelBuilder objekt och distribuera modellen på en SageMaker-slutpunkt enligt samma logik som visas i det andra exemplet:

builder = ModelBuilder( inference_spec=inf_spec, mode=Mode.SAGEMAKER_ENDPOINT, # you can change it to Mode.LOCAL_CONTAINER for local testing schema_builder=schema, image_uri=image,
)
model = builder.build( role_arn=execution_role, sagemaker_session=sagemaker_session,
)
predictor = model.deploy( initial_instance_count=1, instance_type='ml.g5.2xlarge'
)

Hänvisa till modellbyggare-huggingface.ipynb att distribuera en Hugging Face-pipelinemodell.

Distribuera grundmodeller till SageMaker-slutpunkter

I följande exempel visar vi hur du använder ModelBuilder att distribuera grundmodeller. Precis som de modeller som nämnts tidigare, är allt som krävs är modell-ID.

Kramar Face Hub

Om du vill distribuera en grundmodell från Kramar Face Hub, allt du behöver göra är att klara av det förutbildade modell-ID:t. Till exempel distribuerar följande kodavsnitt meta-llama/Llama-2-7b-hf modell lokalt. Du kan ändra läget till Mode.SAGEMAKER_ENDPOINT att distribuera till SageMaker-slutpunkter.

model_builder = ModelBuilder( model="meta-llama/Llama-2-7b-hf", schema_builder=SchemaBuilder(sample_input, sample_output), model_path="/home/ec2-user/SageMaker/LoadTestResources/meta-llama2-7b", #local path where artifacts will be saved mode=Mode.LOCAL_CONTAINER, env_vars={ # Llama 2 is a gated model and requires a Hugging Face Hub token. "HUGGING_FACE_HUB_TOKEN": "<YourHuggingFaceToken>" }
)
model = model_builder.build()
local_predictor = model.deploy()

För gated modeller på Hugging Face Hub måste du begära åtkomst via Hugging Face Hub och använda den associerade nyckeln genom att skicka den som miljövariabel HUGGING_FACE_HUB_TOKEN. Vissa Hugging Face-modeller kan kräva pålitlig fjärrkod. Den kan också ställas in som en miljövariabel med hjälp av HF_TRUST_REMOTE_CODE. Som standard är ModelBuilder kommer att använda en Hugging Face Text Generation Inference (TGI) container som underliggande container för Hugging Face-modeller. Om du vill använda AWS Large Model Inference (LMI) behållare, kan du ställa in model_server parameter som ModelServer.DJL_SERVING när du konfigurerar ModelBuilder objekt.

Ett snyggt inslag av ModelBuilder är möjligheten att köra lokal justering av containerparametrarna när du använder LOCAL_CONTAINER läge. Denna funktion kan användas genom att helt enkelt köra tuned_model = model.tune().

Hänvisa till demo-modellbyggare-huggingface-llama2.ipynb att distribuera en Hugging Face Hub-modell.

SageMaker JumpStart

Amazon SageMaker JumpStart erbjuder även ett antal förutbildade foundationmodeller. Precis som processen att distribuera en modell från Hugging Face Hub krävs modell-ID. Att distribuera en SageMaker JumpStart-modell till en SageMaker-slutpunkt är lika enkelt som att köra följande kod:

model_builder = ModelBuilder( model="huggingface-llm-falcon-7b-bf16", schema_builder=SchemaBuilder(sample_input, sample_output), role_arn=execution_role
) sm_ep_model = model_builder.build() predictor = sm_ep_model.deploy()

För alla tillgängliga SageMaker JumpStart-modell-ID, se Inbyggda algoritmer med förtränad modellbord. Hänvisa till modellbyggare-jumpstart-falcon.ipynb att distribuera en SageMaker JumpStart-modell.

Slutledningskomponent

ModelBulder låter dig använda den nya inferenskomponentkapaciteten i SageMaker för att distribuera modeller. För mer information om inferenskomponenter, se Minska modellimplementeringskostnaderna med 50 % i genomsnitt genom att använda SageMakers senaste funktioner. Du kan använda slutledningskomponenter för distribution med ModelBuilder genom att specificera endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED i deploy() metod. Du kan också använda tune() metod, som hämtar det optimala antalet acceleratorer, och modifiera den vid behov.

resource_requirements = ResourceRequirements( requests={ "num_accelerators": 4, "memory": 1024, "copies": 1, }, limits={},
) goldfinch_predictor_2 = model_2.deploy( mode=Mode.SAGEMAKER_ENDPOINT, endpoint_type=EndpointType.INFERENCE_COMPONENT_BASED, ... )

Hänvisa till model-builder-inference-component.ipynb att distribuera en modell som en slutledningskomponent.

Anpassa ModelBuilder Class

Smakämnen ModelBuilder klass låter dig anpassa modellladdning med hjälp av InferenceSpec.

Dessutom kan du styra nyttolast och svar serialisering och deserialisering och anpassa förbearbetning och efterbearbetning med CustomPayloadTranslator. Dessutom, när du behöver utöka våra förbyggda behållare för modelldistribution på SageMaker, kan du använda ModelBuilder att hantera modellförpackningsprocessen. I det här följande avsnittet ger vi mer information om dessa funktioner.

InferensSpec

InferensSpec erbjuder ett extra lager av anpassning. Det låter dig definiera hur modellen laddas och hur den ska hantera inkommande slutledningsförfrågningar. Genom InferenceSpec, kan du definiera anpassade laddningsprocedurer för dina modeller och kringgå standardladdningsmekanismerna. Denna flexibilitet är särskilt fördelaktig när man arbetar med icke-standardiserade modeller eller anpassade slutledningsledningar. Invoke-metoden kan anpassas, vilket ger dig möjlighet att skräddarsy hur modellen bearbetar inkommande förfrågningar (för- och efterbearbetning). Denna anpassning kan vara väsentlig för att säkerställa att slutledningsprocessen överensstämmer med modellens specifika behov. Se följande kod:

class InferenceSpec(abc.ABC): @abc.abstractmethod def load(self, model_dir: str): pass @abc.abstractmethod def invoke(self, input_object: object, model: object): pass

Följande kod visar ett exempel på hur den här klassen används:

class MyInferenceSpec(InferenceSpec): def load(self, model_dir: str): return // model object def invoke(self, input, model): return model(input)

CustomPayloadTranslator

När SageMaker-slutpunkter anropas skickas data via HTTP-nyttolaster med olika MIME-typer. Till exempel måste en bild som skickas till slutpunkten för slutledning konverteras till byte på klientsidan och skickas via HTTP-nyttolasten till slutpunkten. När slutpunkten tar emot nyttolasten måste den deserialisera bytesträngen tillbaka till den datatyp som förväntas av modellen (även känd som deserialisering på serversidan). Efter att modellen är klar med prediktionen måste resultaten serialiseras till bytes som kan skickas tillbaka via HTTP-nyttolasten till användaren eller klienten. När klienten tar emot svarsbytedata måste den utföra deserialisering på klientsidan för att konvertera bytedata tillbaka till det förväntade dataformatet, såsom JSON. Åtminstone du måste konvertera data för följande (som numrerat i följande diagram):

1. Serialisering av slutledningsbegäran (hanteras av klienten)
2. Deserialisering av slutledningsbegäran (hanteras av servern eller algoritmen)
3. Anropa modellen mot nyttolasten
4. Skickar tillbaka nyttolasten
5. Serialisering av slutledningssvar (hanteras av servern eller algoritmen)
6. Deserialisering av slutledningssvar (hanteras av klienten)

Följande diagram visar processen för serialisering och deserialisering under anropsprocessen.

I följande kodavsnitt visar vi ett exempel på CustomPayloadTranslator när ytterligare anpassning behövs för att hantera både serialisering och deserialisering på klient- respektive serversidan:

from sagemaker.serve import CustomPayloadTranslator # request translator
class MyRequestTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on client side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the input payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on server side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object # response translator class MyResponseTranslator(CustomPayloadTranslator): # This function converts the payload to bytes - happens on server side def serialize_payload_to_bytes(self, payload: object) -> bytes: # converts the response payload to bytes ... ... return //return object as bytes # This function converts the bytes to payload - happens on client side def deserialize_payload_from_stream(self, stream) -> object: # convert bytes to in-memory object ... ... return //return in-memory object

I demo-model-builder-pytorch.ipynb notebook, visar vi hur man enkelt distribuerar en PyTorch-modell till en SageMaker-slutpunkt med hjälp av ModelBuilder med CustomPayloadTranslator och InferenceSpec klass.

Etappmodell för utbyggnad

Om du vill iscensätta modellen för slutledning eller i modellregistret kan du använda model.create() or model.register(). Den aktiverade modellen skapas på tjänsten och sedan kan du distribuera senare. Se följande kod:

model_builder = ModelBuilder( model=model, schema_builder=SchemaBuilder(X_test, y_pred), role_arn=execution_role, )
deployable_model = model_builder.build() deployable_model.create() # deployable_model.register() for model registry

Använd anpassade behållare

SageMaker tillhandahåller förbyggda Docker-bilder för dess inbyggda algoritmer och de stödda ramverken för djupinlärning som används för träning och slutledning. Om en förbyggd SageMaker-behållare inte uppfyller alla dina krav, kan du utöka den befintliga bilden för att tillgodose dina behov. Genom att utöka en förbyggd bild kan du använda de medföljande djupinlärningsbiblioteken och inställningarna utan att behöva skapa en bild från grunden. För mer information om hur man utökar de förbyggda behållarna, se SageMaker-dokumentet. ModelBuilder stöder användningsfall när du tar med dina egna containrar som utökas från våra förbyggda Docker-containrar.

För att använda din egen containerbild i det här fallet måste du ställa in fälten image_uri och model_server när man definierar ModelBuilder:

model_builder = ModelBuilder( model=model, # Pass in the actual model object. its "predict" method will be invoked in the endpoint. schema_builder=SchemaBuilder(X_test, y_pred), # Pass in a "SchemaBuilder" which will use the sample test input and output objects to infer the serialization needed. role_arn=execution_role, image_uri=image_uri, # REQUIRED FOR BYOC: Passing in image hosted in personal ECR Repo model_server=ModelServer.TORCHSERVE, # REQUIRED FOR BYOC: Passing in model server of choice mode=Mode.SAGEMAKER_ENDPOINT, dependencies={"auto": True, "custom": ["protobuf==3.20.2"]}
)

Här, den image_uri kommer att vara behållarbilden ARN som lagras i ditt kontos Amazon Elastic Container Registry (Amazon ECR) arkiv. Ett exempel visas som följer:

# Pulled the xgboost:1.7-1 DLC and pushed to personal ECR repo
image_uri = "<your_account_id>.dkr.ecr.us-west-2.amazonaws.com/my-byoc:xgb"

När image_uri är inställd, under ModelBuilder byggprocessen, kommer den att hoppa över automatisk upptäckt av bilden när bildens URI tillhandahålls. Om model_server inte är inställt i ModelBuilder får du ett valideringsfelmeddelande, till exempel:

ValueError: Model_server must be set when image_uri is set. Supported model servers: {<ModelServer.TRITON: 5>, <ModelServer.DJL_SERVING: 4>, <ModelServer.TORCHSERVE: 1>}

Från och med publiceringen av detta inlägg, ModelBuilder stödjer att ta med egna containrar som är förlängda från vår förbyggda DLC-containerbilder eller behållare byggda med modellen servrar som Djupt Java-bibliotek (DJL), Text Generation Inference (TGI), TorchServeoch Triton slutledningsserver.

Anpassade beroenden

När du kör ModelBuilder.build(), som standard fångar den automatiskt din Python-miljö i en requirements.txt fil och installerar samma beroende i behållaren. Men ibland kommer din lokala Python-miljö i konflikt med miljön i behållaren. ModelBuilder ger dig ett enkelt sätt att ändra de infångade beroendena för att fixa sådana beroendekonflikter genom att låta dig tillhandahålla dina anpassade konfigurationer i ModelBuilder. Observera att detta endast är för TorchServe och Triton med InferenceSpec. Du kan till exempel ange beroenden för indataparametrar, som är en Python-ordbok, i ModelBuilder enligt följande:

dependency_config = { "auto" = True, "requirements" = "/path/to/your/requirements.txt" "custom" = ["module>=1.2.3,<1.5", "boto3==1.16.*", "some_module@http://some/url"]
} ModelBuilder( # Other params dependencies=dependency_config,
).build()

Vi definierar följande fält:

• bil – Om du ska försöka automatiskt fånga beroenden i din miljö.
• krav – En sträng på vägen till din egen requirements.txt fil. (Detta är valfritt.)
• beställnings – En lista över alla andra anpassade beroenden som du vill lägga till eller ändra. (Detta är valfritt.)

Om samma modul anges på flera ställen, custom kommer att ha högsta prioritet då requirementsoch auto kommer att ha lägsta prioritet. Låt oss till exempel säga att under autodetektering, ModelBuilder känner av numpy==1.25Och en requirements.txt fil tillhandahålls som anger numpy>=1.24,<1.26. Dessutom finns det ett anpassat beroende: custom = ["numpy==1.26.1"]. I detta fall, numpy==1.26.1 kommer att väljas när vi installerar beroenden i behållaren.

Städa upp

När du är klar med att testa modellerna, som en bästa praxis, radera slutpunkten för att spara kostnader om slutpunkten inte längre behövs. Du kan följa Städa upp avsnitt i var och en av demo-anteckningsböckerna eller använd följande kod för att ta bort modellen och slutpunkten som skapats av demon:

predictor.delete_model()
predictor.delete_endpoint()

Slutsats

Den nya SageMaker ModelBuilder-möjligheten förenklar processen att distribuera ML-modeller i produktion på SageMaker. Genom att hantera många av de komplexa detaljerna bakom kulisserna, minskar ModelBuilder inlärningskurvan för nya användare och maximerar utnyttjandet för erfarna användare. Med bara några rader kod kan du distribuera modeller med inbyggda ramverk som XGBoost, PyTorch, Triton och Hugging Face, såväl som modeller från SageMaker JumpStart till robusta, skalbara slutpunkter på SageMaker.

Vi uppmuntrar alla SageMaker-användare att prova denna nya funktion genom att hänvisa till ModelBuilder dokumentationssida. ModelBuilder är tillgängligt nu för alla SageMaker-användare utan extra kostnad. Dra fördel av detta förenklade arbetsflöde för att få dina modeller att distribueras snabbare. Vi ser fram emot att höra hur ModelBuilder accelererar din modellutvecklingslivscykel!

Speciellt tack till Sirisha Upadhyayala, Raymond Liu, Gary Wang, Dhawal Patel, Deepak Garg och Ram Vegiraju.

Om författarna

Melanie Li, PhD, är en Senior AI/ML Specialist TAM vid AWS baserad i Sydney, Australien. Hon hjälper företagskunder att bygga lösningar med hjälp av toppmoderna AI/ML-verktyg på AWS och ger vägledning om arkitektur och implementering av ML-lösningar med bästa praxis. På fritiden älskar hon att utforska naturen och umgås med familj och vänner.

Marc Karp är en ML-arkitekt med Amazon SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att designa, distribuera och hantera ML-arbetsbelastningar i stor skala. På fritiden tycker han om att resa och utforska nya platser.

Sam Edwards, är en molningenjör (AI/ML) på AWS Sydney specialiserad på maskininlärning och Amazon SageMaker. Han brinner för att hjälpa kunder att lösa problem relaterade till arbetsflöden för maskininlärning och skapa nya lösningar för dem. Utanför jobbet tycker han om att spela racketsporter och att resa.

Raghu Ramesha är senior ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserar på att hjälpa kunder att bygga, distribuera och migrera ML-produktionsarbetsbelastningar till SageMaker i stor skala. Han är specialiserad på domäner för maskininlärning, AI och datorseende och har en magisterexamen i datavetenskap från UT Dallas. På fritiden tycker han om att resa och fotografera.

Shiva Raaj Kotini arbetar som huvudproduktchef i Amazon SageMakers produktportfölj. Han fokuserar på modelldistribution, prestandajustering och optimering i SageMaker för slutledning.

Mohan Gandhi är senior mjukvaruingenjör på AWS. Han har varit med AWS de senaste 10 åren och har arbetat med olika AWS-tjänster som EMR, EFA och RDS. För närvarande fokuserar han på att förbättra SageMaker Inference Experience. På fritiden tycker han om vandring och maraton.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/package-and-deploy-classical-ml-and-llms-easily-with-amazon-sagemaker-part-1-pysdk-improvements/