Orkestrere Ray-baserte maskinlæringsarbeidsflyter ved hjelp av Amazon SageMaker | Amazon Web Services

Maskinlæring (ML) blir stadig mer kompleks ettersom kunder prøver å løse flere og mer utfordrende problemer. Denne kompleksiteten fører ofte til behovet for distribuert ML, der flere maskiner brukes til å trene en enkelt modell. Selv om dette muliggjør parallellisering av oppgaver på tvers av flere noder, noe som fører til akselererte treningstider, forbedret skalerbarhet og forbedret ytelse, er det betydelige utfordringer med å effektivt bruke distribuert maskinvare. Dataforskere må ta tak i utfordringer som datapartisjonering, lastbalansering, feiltoleranse og skalerbarhet. ML-ingeniører må håndtere parallellisering, planlegging, feil og gjenforsøk manuelt, noe som krever kompleks infrastrukturkode.

I dette innlegget diskuterer vi fordelene ved å bruke Ray og Amazon SageMaker for distribuert ML, og gi en trinn-for-trinn-veiledning for hvordan du bruker disse rammeverkene til å bygge og distribuere en skalerbar ML-arbeidsflyt.

Ray, et distribuert databehandlingsrammeverk med åpen kildekode, gir et fleksibelt rammeverk for distribuert opplæring og servering av ML-modeller. Den abstraherer distribuerte systemdetaljer på lavt nivå gjennom enkle, skalerbare biblioteker for vanlige ML-oppgaver som dataforbehandling, distribuert opplæring, hyperparameterinnstilling, forsterkningslæring og modellservering.

SageMaker er en fullstendig administrert tjeneste for å bygge, trene og distribuere ML-modeller. Ray integreres sømløst med SageMaker-funksjoner for å bygge og distribuere komplekse ML-arbeidsbelastninger som er både effektive og pålitelige. Kombinasjonen av Ray og SageMaker gir ende-til-ende-funksjoner for skalerbare ML-arbeidsflyter, og har følgende uthevede funksjoner:

• Distribuerte aktører og parallellitetskonstruksjoner i Ray forenkler utviklingen av distribuerte applikasjoner.
• Ray AI Runtime (AIR) reduserer friksjonen ved å gå fra utvikling til produksjon. Med Ray og AIR kan den samme Python-koden skaleres sømløst fra en bærbar datamaskin til en stor klynge.
• Den administrerte infrastrukturen til SageMaker og funksjoner som behandlingsjobber, treningsjobber og hyperparameterjusteringsjobber kan bruke Ray-biblioteker under for distribuert databehandling.
• Amazon SageMaker-eksperimenter gjør det mulig å gjenta og holde oversikt over forsøk.
• Amazon SageMaker Feature Store gir et skalerbart depot for lagring, henting og deling av ML-funksjoner for modelltrening.
• Trente modeller kan lagres, versjoneres og spores inn Amazon SageMaker modellregister for styring og ledelse.

• Amazon SageMaker-rørledninger tillater orkestrering av ende-til-ende ML-livssyklusen fra dataforberedelse og opplæring til modellimplementering som automatiserte arbeidsflyter.

Løsningsoversikt

Dette innlegget fokuserer på fordelene ved å bruke Ray og SageMaker sammen. Vi satte opp en ende-til-ende Ray-basert ML-arbeidsflyt, orkestrert ved hjelp av SageMaker Pipelines. Arbeidsflyten inkluderer parallell inntak av data i funksjonslageret ved hjelp av Ray-aktører, dataforbehandling med Ray Data, treningsmodeller og hyperparameterjustering i skala ved bruk av Ray Train og hyperparameteroptimalisering (HPO) tuningjobber, og til slutt modellevaluering og registrering av modellen i en modellregister.

For våre data bruker vi et syntetisk boligdatasett som består av åtte funksjoner (YEAR_BUILT, SQUARE_FEET, NUM_BEDROOM, NUM_BATHROOMS, LOT_ACRES, GARAGE_SPACES, FRONT_PORCHog DECK) og vår modell vil forutsi PRICE av huset.

Hvert trinn i ML-arbeidsflyten er delt inn i diskrete trinn, med sitt eget skript som tar inn- og utdataparametere. I neste avsnitt fremhever vi nøkkelkodebiter fra hvert trinn. Hele koden finner du på aws-samples-for-ray GitHub-depot.

Forutsetninger

For å bruke SageMaker Python SDK og kjøre koden knyttet til dette innlegget, trenger du følgende forutsetninger:

Ta inn data i SageMaker Feature Store

Det første trinnet i ML-arbeidsflyten er å lese kildedatafilen fra Amazon enkel lagringstjeneste (Amazon S3) i CSV-format og ta det inn i SageMaker Feature Store. SageMaker Feature Store er et spesialbygd depot som gjør det enkelt for team å opprette, dele og administrere ML-funksjoner. Det forenkler funksjonsoppdagelse, gjenbruk og deling, noe som fører til raskere utvikling, økt samarbeid innen kundeteam og reduserte kostnader.

Å ta inn funksjoner i funksjonslageret inneholder følgende trinn:

1. Definer en funksjonsgruppe og lag funksjonsgruppen i funksjonsbutikken.
2. Forbered kildedataene for funksjonslageret ved å legge til et hendelsestidspunkt og registrerings-ID for hver rad med data.
3. Ta inn de forberedte dataene i funksjonsgruppen ved å bruke Boto3 SDK.

I denne delen fremhever vi bare trinn 3, fordi dette er delen som involverer parallell prosessering av inntaksoppgaven ved hjelp av Ray. Du kan se hele koden for denne prosessen i GitHub repo.

De ingest_features metoden er definert i en klasse kalt Featurestore. Merk at Featurestore klasse er dekorert med @ray.remote. Dette indikerer at en forekomst av denne klassen er en Ray-skuespiller, en tilstandsfull og samtidig beregningsenhet i Ray. Det er en programmeringsmodell som lar deg lage distribuerte objekter som opprettholder en intern tilstand og kan nås samtidig av flere oppgaver som kjører på forskjellige noder i en Ray-klynge. Skuespillere gir en måte å administrere og innkapsle den foranderlige tilstanden, noe som gjør dem verdifulle for å bygge komplekse, tilstandsfulle applikasjoner i en distribuert setting. Du kan spesifisere ressurskrav i aktører også. I dette tilfellet vil hver forekomst av FeatureStore klasse vil kreve 0.5 CPUer. Se følgende kode:

@ray.remote(num_cpus=0.5)
class Featurestore: def ingest_features(self,feature_group_name, df, region): """ Ingest features to Feature Store Group Args: feature_group_name (str): Feature Group Name data_path (str): Path to the train/validation/test data in CSV format. """ ...

Du kan samhandle med skuespilleren ved å ringe remote operatør. I den følgende koden sendes ønsket antall skuespillere inn som et input-argument til manuset. Dataene blir deretter partisjonert basert på antall aktører og sendt til de eksterne parallelle prosessene for å bli lagt inn i funksjonslageret. Du kan ringe get på objektreferen for å blokkere utførelsen av gjeldende oppgave til fjernberegningen er fullført og resultatet er tilgjengelig. Når resultatet er tilgjengelig, ray.get vil returnere resultatet, og utførelsen av gjeldende oppgave vil fortsette.

import modin.pandas as pd
import ray df = pd.read_csv(s3_path)
data = prepare_df_for_feature_store(df)
# Split into partitions
partitions = [ray.put(part) for part in np.array_split(data, num_actors)]
# Start actors and assign partitions in a loop
actors = [Featurestore.remote() for _ in range(args.num_actors)]
results = [] for actor, partition in zip(actors, input_partitions): results.append(actor.ingest_features.remote( args.feature_group_name, partition, args.region ) ) ray.get(results)

Forbered data for opplæring, validering og testing

I dette trinnet bruker vi Ray Dataset for å effektivt dele, transformere og skalere datasettet vårt som forberedelse til maskinlæring. Ray Dataset gir en standard måte å laste distribuerte data inn i Ray, og støtter ulike lagringssystemer og filformater. Den har API-er for vanlige ML-dataforbehandlingsoperasjoner som parallelle transformasjoner, stokking, gruppering og aggregering. Ray Dataset håndterer også operasjoner som krever stateful setup og GPU-akselerasjon. Den integreres jevnt med andre databehandlingsbiblioteker som Spark, Pandas, NumPy og mer, samt ML-rammeverk som TensorFlow og PyTorch. Dette gjør det mulig å bygge ende-til-ende datapipelines og ML-arbeidsflyter på toppen av Ray. Målet er å gjøre distribuert databehandling og ML enklere for praktikere og forskere.

La oss se på deler av skriptene som utfører denne dataforbehandlingen. Vi starter med å laste inn dataene fra funksjonsbutikken:

def load_dataset(feature_group_name, region): """ Loads the data as a ray dataset from the offline featurestore S3 location Args: feature_group_name (str): name of the feature group Returns: ds (ray.data.dataset): Ray dataset the contains the requested dat from the feature store """ session = sagemaker.Session(boto3.Session(region_name=region)) fs_group = FeatureGroup( name=feature_group_name, sagemaker_session=session ) fs_data_loc = fs_group.describe().get("OfflineStoreConfig").get("S3StorageConfig").get("ResolvedOutputS3Uri") # Drop columns added by the feature store # Since these are not related to the ML problem at hand cols_to_drop = ["record_id", "event_time","write_time", "api_invocation_time", "is_deleted", "year", "month", "day", "hour"] ds = ray.data.read_parquet(fs_data_loc) ds = ds.drop_columns(cols_to_drop) print(f"{fs_data_loc} count is {ds.count()}") return ds

Vi deler deretter og skalerer data ved å bruke abstraksjoner på høyere nivå som er tilgjengelige fra ray.data bibliotek:

def split_dataset(dataset, train_size, val_size, test_size, random_state=None): """ Split dataset into train, validation and test samples Args: dataset (ray.data.Dataset): input data train_size (float): ratio of data to use as training dataset val_size (float): ratio of data to use as validation dataset test_size (float): ratio of data to use as test dataset random_state (int): Pass an int for reproducible output across multiple function calls. Returns: train_set (ray.data.Dataset): train dataset val_set (ray.data.Dataset): validation dataset test_set (ray.data.Dataset): test dataset """ # Shuffle this dataset with a fixed random seed. shuffled_ds = dataset.random_shuffle(seed=random_state) # Split the data into train, validation and test datasets train_set, val_set, test_set = shuffled_ds.split_proportionately([train_size, val_size]) return train_set, val_set, test_set def scale_dataset(train_set, val_set, test_set, target_col): """ Fit StandardScaler to train_set and apply it to val_set and test_set Args: train_set (ray.data.Dataset): train dataset val_set (ray.data.Dataset): validation dataset test_set (ray.data.Dataset): test dataset target_col (str): target col Returns: train_transformed (ray.data.Dataset): train data scaled val_transformed (ray.data.Dataset): val data scaled test_transformed (ray.data.Dataset): test data scaled """ tranform_cols = dataset.columns() # Remove the target columns from being scaled tranform_cols.remove(target_col) # set up a standard scaler standard_scaler = StandardScaler(tranform_cols) # fit scaler to training dataset print("Fitting scaling to training data and transforming dataset...") train_set_transformed = standard_scaler.fit_transform(train_set) # apply scaler to validation and test datasets print("Transforming validation and test datasets...") val_set_transformed = standard_scaler.transform(val_set) test_set_transformed = standard_scaler.transform(test_set) return train_set_transformed, val_set_transformed, test_set_transformed

De behandlede tog-, validerings- og testdatasettene lagres i Amazon S3 og vil bli sendt som inngangsparametere til påfølgende trinn.

Utfør modelltrening og hyperparameteroptimalisering

Med dataene våre forhåndsbehandlet og klar for modellering, er det på tide å trene noen ML-modeller og finjustere hyperparametrene deres for å maksimere prediktiv ytelse. Vi bruker XGBoost-Ray, en distribuert backend for XGBoost bygget på Ray som gjør det mulig å trene XGBoost-modeller på store datasett ved å bruke flere noder og GPUer. Det gir enkle drop-in-erstatninger for XGBoosts tog- og prediksjons-APIer mens den håndterer kompleksiteten til distribuert dataadministrasjon og opplæring under panseret.

For å muliggjøre distribusjon av treningen over flere noder, bruker vi en hjelpeklasse kalt RayHelper. Som vist i følgende kode bruker vi ressurskonfigurasjonen til treningsjobben og velger den første verten som hovednoden:

class RayHelper(): def __init__(self, ray_port:str="9339", redis_pass:str="redis_password"): .... self.resource_config = self.get_resource_config() self.head_host = self.resource_config["hosts"][0] self.n_hosts = len(self.resource_config["hosts"])

Vi kan bruke vertsinformasjonen til å bestemme hvordan vi skal initialisere Ray på hver av treningsjobben:

def start_ray(self): head_ip = self._get_ip_from_host() # If the current host is the host choosen as the head node # run `ray start` with specifying the --head flag making this is the head node if self.resource_config["current_host"] == self.head_host: output = subprocess.run(['ray', 'start', '--head', '-vvv', '--port', self.ray_port, '--redis-password', self.redis_pass, '--include-dashboard', 'false'], stdout=subprocess.PIPE) print(output.stdout.decode("utf-8")) ray.init(address="auto", include_dashboard=False) self._wait_for_workers() print("All workers present and accounted for") print(ray.cluster_resources()) else: # If the current host is not the head node, # run `ray start` with specifying ip address as the head_host as the head node time.sleep(10) output = subprocess.run(['ray', 'start', f"--address={head_ip}:{self.ray_port}", '--redis-password', self.redis_pass, "--block"], stdout=subprocess.PIPE) print(output.stdout.decode("utf-8")) sys.exit(0)

Når en treningsjobb startes, kan en Ray-klynge initialiseres ved å ringe start_ray() metode på en forekomst av RayHelper:

if __name__ == '__main__': ray_helper = RayHelper() ray_helper.start_ray() args = read_parameters() sess = sagemaker.Session(boto3.Session(region_name=args.region))

Vi bruker da XGBoost-treneren fra XGBoost-Ray til trening:

def train_xgboost(ds_train, ds_val, params, num_workers, target_col = "price") -> Result: """ Creates a XGBoost trainer, train it, and return the result. Args: ds_train (ray.data.dataset): Training dataset ds_val (ray.data.dataset): Validation dataset params (dict): Hyperparameters num_workers (int): number of workers to distribute the training across target_col (str): target column Returns: result (ray.air.result.Result): Result of the training job """ train_set = RayDMatrix(ds_train, 'PRICE') val_set = RayDMatrix(ds_val, 'PRICE') evals_result = {} trainer = train( params=params, dtrain=train_set, evals_result=evals_result, evals=[(val_set, "validation")], verbose_eval=False, num_boost_round=100, ray_params=RayParams(num_actors=num_workers, cpus_per_actor=1), ) output_path=os.path.join(args.model_dir, 'model.xgb') trainer.save_model(output_path) valMAE = evals_result["validation"]["mae"][-1] valRMSE = evals_result["validation"]["rmse"][-1] print('[3] #011validation-mae:{}'.format(valMAE)) print('[4] #011validation-rmse:{}'.format(valRMSE)) local_testing = False try: load_run(sagemaker_session=sess) except: local_testing = True if not local_testing: # Track experiment if using SageMaker Training with load_run(sagemaker_session=sess) as run: run.log_metric('validation-mae', valMAE) run.log_metric('validation-rmse', valRMSE)

Merk at mens du instansierer trainer, vi passerer RayParams, som tar antall skuespillere og antall CPUer per skuespillere. XGBoost-Ray bruker denne informasjonen til å fordele treningen på tvers av alle nodene knyttet til Ray-klyngen.

Vi oppretter nå et XGBoost-estimatorobjekt basert på SageMaker Python SDK og bruker det til HPO-jobben.

Ordne de foregående trinnene ved å bruke SageMaker Pipelines

For å bygge en ende-til-ende skalerbar og gjenbrukbar ML-arbeidsflyt, må vi bruke et CI/CD-verktøy for å orkestrere de foregående trinnene i en pipeline. SageMaker Pipelines har direkte integrasjon med SageMaker, SageMaker Python SDK og SageMaker Studio. Denne integrasjonen lar deg lage ML-arbeidsflyter med en brukervennlig Python SDK, og deretter visualisere og administrere arbeidsflyten din ved hjelp av SageMaker Studio. Du kan også spore historikken til dataene dine i pipeline-utførelsen og angi trinn for caching.

SageMaker Pipelines oppretter en Directed Acyclic Graph (DAG) som inkluderer trinn som trengs for å bygge en ML-arbeidsflyt. Hver rørledning er en serie sammenkoblede trinn orkestrert av dataavhengigheter mellom trinnene, og kan parameteriseres, slik at du kan angi inngangsvariabler som parametere for hver kjøring av rørledningen. SageMaker Pipelines har fire typer rørledningsparametere: ParameterString, ParameterInteger, ParameterFloatog ParameterBoolean. I denne delen parametriserer vi noen av inngangsvariablene og setter opp konfigurasjonen for trinnbufring:

processing_instance_count = ParameterInteger( name='ProcessingInstanceCount', default_value=1
)
feature_group_name = ParameterString( name='FeatureGroupName', default_value='fs-ray-synthetic-housing-data'
)
bucket_prefix = ParameterString( name='Bucket_Prefix', default_value='aws-ray-mlops-workshop/feature-store'
)
rmse_threshold = ParameterFloat(name="RMSEThreshold", default_value=15000.0) train_size = ParameterString( name='TrainSize', default_value="0.6"
)
val_size = ParameterString( name='ValidationSize', default_value="0.2"
)
test_size = ParameterString( name='TestSize', default_value="0.2"
) cache_config = CacheConfig(enable_caching=True, expire_after="PT12H")

Vi definerer to behandlingstrinn: ett for SageMaker Feature Store-inntak, det andre for dataforberedelse. Dette skal ligne veldig på de tidligere trinnene beskrevet tidligere. Den eneste nye kodelinjen er ProcessingStep etter trinnenes definisjon, som lar oss ta prosesseringsjobbkonfigurasjonen og inkludere den som et pipelinetrinn. Vi spesifiserer videre avhengigheten av dataforberedelsestrinnet på SageMaker Feature Store-inntakstrinnet. Se følgende kode:

feature_store_ingestion_step = ProcessingStep( name='FeatureStoreIngestion', step_args=fs_processor_args, cache_config=cache_config
) preprocess_dataset_step = ProcessingStep( name='PreprocessData', step_args=processor_args, cache_config=cache_config
)
preprocess_dataset_step.add_depends_on([feature_store_ingestion_step])

Tilsvarende, for å bygge et modelltrenings- og tuning-trinn, må vi legge til en definisjon av TuningStep etter modelltreningstrinnets kode for å tillate oss å kjøre SageMaker hyperparameterinnstilling som et trinn i pipelinen:

tuning_step = TuningStep( name="HPTuning", tuner=tuner, inputs={ "train": TrainingInput( s3_data=preprocess_dataset_step.properties.ProcessingOutputConfig.Outputs[ "train" ].S3Output.S3Uri, content_type="text/csv" ), "validation": TrainingInput( s3_data=preprocess_dataset_step.properties.ProcessingOutputConfig.Outputs[ "validation" ].S3Output.S3Uri, content_type="text/csv" ) }, cache_config=cache_config,
)
tuning_step.add_depends_on([preprocess_dataset_step])

Etter tuning-trinnet velger vi å registrere den beste modellen i SageMaker Model Registry. For å kontrollere modellkvaliteten implementerer vi en minimumskvalitetsport som sammenligner den beste modellens objektive metrikk (RMSE) mot en terskel definert som rørledningens inngangsparameter rmse_threshold. For å gjøre denne evalueringen oppretter vi et annet behandlingstrinn for å kjøre en evalueringsmanus. Resultatet av modellevalueringen vil bli lagret som en egenskapsfil. Eiendomsfiler er spesielt nyttige når du analyserer resultatene av et behandlingstrinn for å bestemme hvordan andre trinn skal kjøres. Se følgende kode:

# Specify where we'll store the model evaluation results so that other steps can access those results
evaluation_report = PropertyFile( name='EvaluationReport', output_name='evaluation', path='evaluation.json',
) # A ProcessingStep is used to evaluate the performance of a selected model from the HPO step. # In this case, the top performing model is evaluated. evaluation_step = ProcessingStep( name='EvaluateModel', processor=evaluation_processor, inputs=[ ProcessingInput( source=tuning_step.get_top_model_s3_uri( top_k=0, s3_bucket=bucket, prefix=s3_prefix ), destination='/opt/ml/processing/model', ), ProcessingInput( source=preprocess_dataset_step.properties.ProcessingOutputConfig.Outputs['test'].S3Output.S3Uri, destination='/opt/ml/processing/test', ), ], outputs=[ ProcessingOutput( output_name='evaluation', source='/opt/ml/processing/evaluation' ), ], code='./pipeline_scripts/evaluate/script.py', property_files=[evaluation_report],
)

Vi definerer en ModelStep for å registrere den beste modellen i SageMaker Model Registry i vår pipeline. I tilfelle den beste modellen ikke består vår forhåndsbestemte kvalitetssjekk, spesifiserer vi i tillegg en FailStep for å sende ut en feilmelding:

register_step = ModelStep( name='RegisterTrainedModel', step_args=model_registry_args
) metrics_fail_step = FailStep( name="RMSEFail", error_message=Join(on=" ", values=["Execution failed due to RMSE >", rmse_threshold]),
)

Deretter bruker vi en ConditionStep for å vurdere om modellregistreringstrinnet eller feiltrinnet bør tas neste gang i pipelinen. I vårt tilfelle vil den beste modellen bli registrert hvis dens RMSE-score er lavere enn terskelen.

# Condition step for evaluating model quality and branching execution
cond_lte = ConditionLessThanOrEqualTo( left=JsonGet( step_name=evaluation_step.name, property_file=evaluation_report, json_path='regression_metrics.rmse.value', ), right=rmse_threshold,
)
condition_step = ConditionStep( name='CheckEvaluation', conditions=[cond_lte], if_steps=[register_step], else_steps=[metrics_fail_step],
)

Til slutt orkestrerer vi alle de definerte trinnene i en pipeline:

pipeline_name = 'synthetic-housing-training-sm-pipeline-ray'
step_list = [ feature_store_ingestion_step, preprocess_dataset_step, tuning_step, evaluation_step, condition_step ] training_pipeline = Pipeline( name=pipeline_name, parameters=[ processing_instance_count, feature_group_name, train_size, val_size, test_size, bucket_prefix, rmse_threshold ], steps=step_list
) # Note: If an existing pipeline has the same name it will be overwritten.
training_pipeline.upsert(role_arn=role_arn)

Den foregående pipelinen kan visualiseres og kjøres direkte i SageMaker Studio, eller utføres ved å ringe execution = training_pipeline.start(). Følgende figur illustrerer rørledningens strømning.

I tillegg kan vi gjennomgå avstamningen av artefakter generert av pipeline-utførelsen.

from sagemaker.lineage.visualizer import LineageTableVisualizer viz = LineageTableVisualizer(sagemaker.session.Session())
for execution_step in reversed(execution.list_steps()): print(execution_step) display(viz.show(pipeline_execution_step=execution_step)) time.sleep(5)

Distribuer modellen

Etter at den beste modellen er registrert i SageMaker Model Registry via en pipeline-kjøring, distribuerer vi modellen til et sanntidsendepunkt ved å bruke de fullstendig administrerte modelldistribusjonsmulighetene til SageMaker. SageMaker har andre modelldistribusjonsalternativer for å møte behovene til forskjellige brukstilfeller. For detaljer, se Distribuer modeller for slutninger når du velger riktig alternativ for din brukssituasjon. Først, la oss få modellen registrert i SageMaker Model Registry:

xgb_regressor_model = ModelPackage( role_arn, model_package_arn=model_package_arn, name=model_name
)

Modellens nåværende status er PendingApproval. Vi må sette dens status til Approved før distribusjon:

sagemaker_client.update_model_package( ModelPackageArn=xgb_regressor_model.model_package_arn, ModelApprovalStatus='Approved'
) xgb_regressor_model.deploy( initial_instance_count=1, instance_type='ml.m5.xlarge', endpoint_name=endpoint_name
)

Rydd opp

Når du er ferdig med å eksperimentere, husk å rydde opp i ressursene for å unngå unødvendige kostnader. For å rydde opp, slett sanntidsendepunktet, modellgruppen, rørledningen og funksjonsgruppen ved å ringe API-ene Slett endepunkt, SlettModelPackageGroup, DeletePipelineog DeleteFeatureGroup, henholdsvis, og slå av alle SageMaker Studio-notebook-forekomster.

konklusjonen

Dette innlegget demonstrerte en trinnvis gjennomgang av hvordan du bruker SageMaker Pipelines til å orkestrere Ray-baserte ML-arbeidsflyter. Vi demonstrerte også evnen til SageMaker Pipelines til å integrere med tredjeparts ML-verktøy. Det finnes ulike AWS-tjenester som støtter Ray-arbeidsbelastninger på en skalerbar og sikker måte for å sikre utmerket ytelse og operasjonell effektivitet. Nå er det din tur til å utforske disse kraftige egenskapene og begynne å optimalisere arbeidsflytene dine for maskinlæring med Amazon SageMaker Pipelines og Ray. Ta handling i dag og lås opp det fulle potensialet til ML-prosjektene dine!

---

om forfatteren

Raju Rangan er Senior Solutions Architect hos Amazon Web Services (AWS). Han jobber med statlig sponsede enheter, og hjelper dem med å bygge AI/ML-løsninger ved hjelp av AWS. Når du ikke fikser med skyløsninger, vil du se ham henge med familien eller knuse birdies i et livlig spill badminton med venner.

Sherry Ding er en senior AI/ML-spesialistløsningsarkitekt hos Amazon Web Services (AWS). Hun har lang erfaring innen maskinlæring med doktorgrad i informatikk. Hun jobber hovedsakelig med kunder i offentlig sektor på ulike AI/ML-relaterte forretningsutfordringer, og hjelper dem med å akselerere sin maskinlæringsreise på AWS Cloud. Når hun ikke hjelper kunder, liker hun utendørsaktiviteter.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• BlockOffsets. Modernisering av eierskap for miljøkompensasjon. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/orchestrate-ray-based-machine-learning-workflows-using-amazon-sagemaker/