Orkestrer Ray-baserede maskinlærings-workflows ved hjælp af Amazon SageMaker | Amazon Web Services

Machine learning (ML) bliver mere og mere kompleks, efterhånden som kunder forsøger at løse flere og mere udfordrende problemer. Denne kompleksitet fører ofte til behovet for distribueret ML, hvor flere maskiner bruges til at træne en enkelt model. Selvom dette muliggør parallelisering af opgaver på tværs af flere noder, hvilket fører til accelererede træningstider, forbedret skalerbarhed og forbedret ydeevne, er der betydelige udfordringer ved effektivt at bruge distribueret hardware. Dataforskere skal løse udfordringer som dataopdeling, belastningsbalancering, fejltolerance og skalerbarhed. ML-ingeniører skal håndtere parallelisering, planlægning, fejl og genforsøg manuelt, hvilket kræver kompleks infrastrukturkode.

I dette indlæg diskuterer vi fordelene ved at bruge Ray , Amazon SageMaker til distribueret ML, og giv en trin-for-trin guide til, hvordan du bruger disse rammer til at bygge og implementere en skalerbar ML-workflow.

Ray, en open source distribueret computerramme, giver en fleksibel ramme for distribueret træning og servering af ML-modeller. Det abstraherer distribuerede systemdetaljer på lavt niveau gennem enkle, skalerbare biblioteker til almindelige ML-opgaver såsom dataforbehandling, distribueret træning, hyperparameterjustering, forstærkningsindlæring og modelservering.

SageMaker er en fuldt administreret service til opbygning, træning og implementering af ML-modeller. Ray integreres problemfrit med SageMaker-funktioner for at opbygge og implementere komplekse ML-arbejdsbelastninger, der er både effektive og pålidelige. Kombinationen af ​​Ray og SageMaker giver end-to-end-funktioner til skalerbare ML-arbejdsgange og har følgende fremhævede funktioner:

• Distribuerede aktører og parallelle konstruktioner i Ray forenkler udviklingen af ​​distribuerede applikationer.
• Ray AI Runtime (AIR) reducerer friktionen ved at gå fra udvikling til produktion. Med Ray og AIR kan den samme Python-kode skaleres problemfrit fra en bærbar computer til en stor klynge.
• SageMakers administrerede infrastruktur og funktioner som behandlingsjob, træningsjob og hyperparameterjusteringsjob kan bruge Ray-biblioteker nedenunder til distribueret databehandling.
• Amazon SageMaker-eksperimenter gør det muligt hurtigt at gentage og holde styr på forsøg.
• Amazon SageMaker Feature Store giver et skalerbart lager til lagring, hentning og deling af ML-funktioner til modeltræning.
• Trænede modeller kan lagres, versioneres og spores ind Amazon SageMaker Model Registry til styring og ledelse.

• Amazon SageMaker Pipelines gør det muligt at orkestrere end-to-end ML-livscyklussen fra dataforberedelse og træning til modelimplementering som automatiserede arbejdsgange.

Løsningsoversigt

Dette indlæg fokuserer på fordelene ved at bruge Ray og SageMaker sammen. Vi opretter et end-to-end Ray-baseret ML-workflow, orkestreret ved hjælp af SageMaker Pipelines. Workflowet omfatter parallel indlæsning af data i funktionslageret ved hjælp af Ray-aktører, dataforbehandling med Ray Data, træningsmodeller og hyperparameterjustering i skala ved hjælp af Ray Train og hyperparameteroptimering (HPO) tuning-job og til sidst modelevaluering og registrering af modellen i en modelregistrering.

Til vores data bruger vi et syntetisk boligdatasæt der består af otte funktioner (YEAR_BUILT, SQUARE_FEET, NUM_BEDROOM, NUM_BATHROOMS, LOT_ACRES, GARAGE_SPACES, FRONT_PORCHog DECK), og vores model vil forudsige PRICE af huset.

Hvert trin i ML-workflowet er opdelt i diskrete trin med sit eget script, der tager input- og outputparametre. I næste afsnit fremhæver vi nøglekodestykker fra hvert trin. Den fulde kode kan findes på aws-samples-for-ray GitHub-lager.

Forudsætninger

For at bruge SageMaker Python SDK og køre koden, der er knyttet til dette indlæg, skal du have følgende forudsætninger:

Indtag data i SageMaker Feature Store

Det første trin i ML-arbejdsgangen er at læse kildedatafilen fra Amazon Simple Storage Service (Amazon S3) i CSV-format og indtag det i SageMaker Feature Store. SageMaker Feature Store er et specialbygget lager, der gør det nemt for teams at oprette, dele og administrere ML-funktioner. Det forenkler opdagelse, genbrug og deling af funktioner, hvilket fører til hurtigere udvikling, øget samarbejde inden for kundeteams og reducerede omkostninger.

Indlæsning af funktioner i funktionslageret indeholder følgende trin:

1. Definer en feature-gruppe og opret featuregruppen i feature-butikken.
2. Forbered kildedataene til funktionslageret ved at tilføje et hændelsestidspunkt og registrerings-id for hver række data.
3. Indtag de forberedte data i funktionsgruppen ved at bruge Boto3 SDK.

I dette afsnit fremhæver vi kun trin 3, fordi dette er den del, der involverer parallel bearbejdning af indtagelsesopgaven ved hjælp af Ray. Du kan gennemgå den fulde kode for denne proces i GitHub repo.

indtag_funktioner metode er defineret inde i en klasse kaldet Featurestore. Bemærk, at Featurestore klasse er indrettet med @ray.remote. Dette indikerer, at en instans af denne klasse er en Ray-skuespiller, en tilstandsfuld og samtidig beregningsenhed i Ray. Det er en programmeringsmodel, der giver dig mulighed for at oprette distribuerede objekter, der opretholder en intern tilstand, og som kan tilgås samtidigt af flere opgaver, der kører på forskellige noder i en Ray-klynge. Skuespillere giver en måde at styre og indkapsle den foranderlige tilstand, hvilket gør dem værdifulde til at bygge komplekse, statelige applikationer i en distribueret setting. Du kan også angive ressourcekrav i aktører. I dette tilfælde vil hver forekomst af FeatureStore klasse kræver 0.5 CPU'er. 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 interagere med skuespilleren ved at ringe til remote operatør. I den følgende kode sendes det ønskede antal skuespillere ind som input-argument til scriptet. Dataene opdeles derefter baseret på antallet af aktører og videregives til de eksterne parallelle processer for at blive indlæst i feature-lageret. Du kan ringe get på objektreferen for at blokere udførelsen af ​​den aktuelle opgave, indtil fjernberegningen er færdig, og resultatet er tilgængeligt. Når resultatet foreligger, ray.get vil returnere resultatet, og udførelsen af ​​den aktuelle opgave vil fortsætte.

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 til træning, validering og test

I dette trin bruger vi Ray Dataset til effektivt at opdele, transformere og skalere vores datasæt som forberedelse til maskinlæring. Ray Dataset giver en standard måde at indlæse distribuerede data i Ray, der understøtter forskellige lagersystemer og filformater. Det har API'er til almindelige ML-dataforbehandlingsoperationer som parallelle transformationer, blanding, gruppering og aggregeringer. Ray Dataset håndterer også operationer, der kræver stateful opsætning og GPU-acceleration. Det integreres problemfrit med andre databehandlingsbiblioteker som Spark, Pandas, NumPy og mere, samt ML-frameworks som TensorFlow og PyTorch. Dette gør det muligt at bygge end-to-end datapipelines og ML workflows oven på Ray. Målet er at gøre distribueret databehandling og ML nemmere for praktikere og forskere.

Lad os se på dele af de scripts, der udfører denne dataforbehandling. Vi starter med at indlæse dataene fra feature store:

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 opdeler og skalerer derefter data ved hjælp af abstraktioner på højere niveau, der er tilgængelige 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 testdatasæt gemmes i Amazon S3 og vil blive videregivet som inputparametre til efterfølgende trin.

Udfør modeltræning og hyperparameteroptimering

Med vores data forbehandlet og klar til modellering, er det tid til at træne nogle ML-modeller og finjustere deres hyperparametre for at maksimere prædiktiv ydeevne. Vi bruger XGBoost-Ray, en distribueret backend til XGBoost bygget på Ray, der gør det muligt at træne XGBoost-modeller på store datasæt ved at bruge flere noder og GPU'er. Det giver enkle drop-in-erstatninger til XGBoosts tog- og forudsigelses-API'er, mens den håndterer kompleksiteten af ​​distribueret datastyring og træning under motorhjelmen.

For at muliggøre fordeling af træningen over flere noder, bruger vi en hjælperklasse ved navn RayHelper. Som vist i følgende kode, bruger vi ressourcekonfigurationen af ​​træningsjobbet og vælger den første vært som hovedknudepunkt:

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 bruge værtsoplysningerne til at beslutte, hvordan Ray skal initialiseres på hver af træningsjob-forekomsterne:

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 et træningsjob startes, kan en Ray-klynge initialiseres ved at kalde start_ray() metode på en instans af RayHelper:

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

Så bruger vi XGBoost-træneren fra XGBoost-Ray til træning:

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)

Bemærk, at mens du instansierer trainer, vi passerer RayParams, som tager antallet af skuespillere og antallet af CPU'er pr. skuespillere. XGBoost-Ray bruger denne information til at fordele træningen på tværs af alle de noder, der er knyttet til Ray-klyngen.

Vi opretter nu et XGBoost-estimatorobjekt baseret på SageMaker Python SDK og bruger det til HPO-jobbet.

Organiser de foregående trin ved hjælp af SageMaker Pipelines

For at opbygge en ende-til-ende skalerbar og genbrugelig ML-workflow skal vi bruge et CI/CD-værktøj til at orkestrere de foregående trin i en pipeline. SageMaker Pipelines har direkte integration med SageMaker, SageMaker Python SDK og SageMaker Studio. Denne integration giver dig mulighed for at oprette ML-arbejdsgange med en brugervenlig Python SDK og derefter visualisere og administrere din arbejdsgang ved hjælp af SageMaker Studio. Du kan også spore historikken for dine data i pipeline-udførelsen og udpege trin til cachelagring.

SageMaker Pipelines opretter en Directed Acyclic Graph (DAG), der inkluderer trin, der er nødvendige for at opbygge en ML-arbejdsgang. Hver pipeline er en række indbyrdes forbundne trin, der er orkestreret af dataafhængigheder mellem trin, og kan parametreres, så du kan angive inputvariabler som parametre for hver kørsel af pipelinen. SageMaker Pipelines har fire typer pipeline-parametre: ParameterString, ParameterInteger, ParameterFloatog ParameterBoolean. I dette afsnit parametriserer vi nogle af inputvariablerne og opsætter trin-cache-konfigurationen:

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 behandlingstrin: et til SageMaker Feature Store-indtagelse, det andet til dataforberedelse. Dette skulle ligne de tidligere trin beskrevet tidligere. Den eneste nye kodelinje er ProcessingStep efter trinenes definition, som giver os mulighed for at tage behandlingsjobkonfigurationen og inkludere den som et pipelinetrin. Vi specificerer yderligere afhængigheden af ​​dataforberedelsestrinnet af SageMaker Feature Store-indtagelsestrinnet. 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 skal vi tilføje en definition af for at opbygge et modeltrænings- og tuningtrin TuningStep efter modeltræningstrinnets kode for at give os mulighed for at køre SageMaker hyperparametertuning som et trin 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])

Efter tuning-trinnet vælger vi at registrere den bedste model i SageMaker Model Registry. For at kontrollere modelkvaliteten implementerer vi en minimumskvalitetsgate, der sammenligner den bedste models objektive metrik (RMSE) med en tærskel, der er defineret som pipelinens inputparameter rmse_threshold. For at udføre denne evaluering opretter vi endnu et behandlingstrin for at køre en evalueringsmanuskript. Resultatet af modelevalueringen vil blive gemt som en ejendomsfil. Egenskabsfiler er særligt nyttige, når man analyserer resultaterne af et behandlingstrin for at beslutte, hvordan andre trin skal kø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 at registrere den bedste model i SageMaker Model Registry i vores pipeline. I tilfælde af at den bedste model ikke består vores forudbestemte kvalitetstjek, specificerer vi desuden en FailStep for at udsende en fejlmeddelelse:

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]),
)

Dernæst bruger vi en ConditionStep for at vurdere, om modelregistreringstrinnet eller fejltrinnet skal tages næste gang i pipelinen. I vores tilfælde vil den bedste model blive registreret, hvis dens RMSE-score er lavere end tærsklen.

# 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 sidst orkestrerer vi alle de definerede trin 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 pipeline kan visualiseres og udføres direkte i SageMaker Studio, eller udføres ved at kalde execution = training_pipeline.start(). Følgende figur illustrerer rørledningens flow.

Derudover kan vi gennemgå linjen af ​​artefakter genereret af pipeline-udfø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)

Implementer modellen

Efter at den bedste model er registreret i SageMaker Model Registry via en pipeline-kørsel, implementerer vi modellen til et slutpunkt i realtid ved at bruge de fuldt administrerede modelimplementeringsfunktioner i SageMaker. SageMaker har andre modelimplementeringsmuligheder for at imødekomme behovene i forskellige use cases. For detaljer henvises til Implementer modeller til slutninger når du vælger den rigtige løsning til din use case. Lad os først få modellen registreret i SageMaker Model Registry:

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

Modellens nuværende status er PendingApproval. Vi skal indstille dens status til Approved før implementering:

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
)

Ryd op

Når du er færdig med at eksperimentere, skal du huske at rydde op i ressourcerne for at undgå unødvendige afgifter. For at rydde op skal du slette realtidsslutpunktet, modelgruppen, pipeline og funktionsgruppen ved at kalde API'erne Slet slutpunkt, Slet ModelPackageGroup, DeletePipelineog DeleteFeatureGroup, henholdsvis og luk alle SageMaker Studio notebook-forekomster.

Konklusion

Dette indlæg demonstrerede en trin-for-trin gennemgang af, hvordan man bruger SageMaker Pipelines til at orkestrere Ray-baserede ML-arbejdsgange. Vi demonstrerede også SageMaker Pipelines evne til at integrere med tredjeparts ML-værktøjer. Der er forskellige AWS-tjenester, der understøtter Ray-arbejdsbelastninger på en skalerbar og sikker måde for at sikre fremragende ydeevne og driftseffektivitet. Nu er det din tur til at udforske disse kraftfulde egenskaber og begynde at optimere dine maskinlæringsarbejdsgange med Amazon SageMaker Pipelines og Ray. Tag handling i dag og frigør det fulde potentiale i dine ML-projekter!

---

Om forfatteren

Raju Rangan er Senior Solutions Architect hos Amazon Web Services (AWS). Han arbejder med regeringssponserede enheder og hjælper dem med at bygge AI/ML-løsninger ved hjælp af AWS. Når du ikke roder med cloud-løsninger, vil du fange ham hænge ud med familien eller smadre birdies i et livligt spil badminton med vennerne.

Sherry Ding er senior AI/ML-specialistløsningsarkitekt hos Amazon Web Services (AWS). Hun har stor erfaring med maskinlæring med en ph.d.-grad i datalogi. Hun arbejder hovedsageligt med kunder i den offentlige sektor om forskellige AI/ML-relaterede forretningsudfordringer, og hjælper dem med at accelerere deres maskinlæringsrejse på AWS Cloud. Når hun ikke hjælper kunder, nyder hun udendørsaktiviteter.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• BlockOffsets. Modernisering af miljømæssig offset-ejerskab. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/orchestrate-ray-based-machine-learning-workflows-using-amazon-sagemaker/