Financiële marktdeelnemers worden geconfronteerd met een overdaad aan informatie die hun beslissingen beïnvloedt, en sentimentanalyse onderscheidt zich als een nuttig hulpmiddel om de relevante en zinvolle feiten en cijfers te onderscheiden. Hetzelfde nieuws kan echter een positieve of negatieve invloed hebben op de aandelenkoersen, wat een uitdaging vormt voor deze taak. Sentimentanalyse en andere taken voor natuurlijke taalprogrammering (NLP) beginnen vaak met vooraf getrainde NLP-modellen en implementeren fijnafstemming van de hyperparameters om het model aan te passen aan veranderingen in de omgeving. Op transformator gebaseerde taalmodellen zoals BERT (Bidirectionele transformatoren voor taalbegrip) hebben de mogelijkheid om woorden of zinnen vast te leggen binnen een grotere context van gegevens, en maken de classificatie van het nieuwssentiment mogelijk gezien de huidige toestand van de wereld. Om rekening te houden met veranderingen in de economische omgeving, moet het model opnieuw worden verfijnd wanneer de gegevens beginnen te drijven of de voorspellingsnauwkeurigheid van het model begint te verslechteren.
Hyperparameteroptimalisatie is zeer veeleisend voor deep learning-modellen. De architectonische complexiteit neemt toe wanneer voor een trainingsrun van een enkel model meerdere GPU's nodig zijn. In dit bericht gebruiken we de Gewichten en afwijkingen (W&B) Sweeps-functie en Amazon Elastic Kubernetes-service (Amazon EKS) om deze uitdagingen aan te pakken. Amazon EKS is een zeer beschikbare beheerde Kubernetes-service die instanties automatisch schaalt op basis van belasting, en is zeer geschikt voor het uitvoeren van gedistribueerde trainingsworkloads.
In onze oplossing implementeren we een hyperparameter-rasterzoekopdracht op een EKS-cluster voor het afstemmen van een bert-base-cased-model voor het classificeren van positief of negatief sentiment voor koppen van beursgegevens. De code is te vinden op de GitHub repo.
Overzicht oplossingen
In dit bericht presenteren we een overzicht van de oplossingsarchitectuur en bespreken we de belangrijkste componenten. Meer specifiek bespreken we het volgende:
- Een EKS-cluster opzetten met een schaalbaar bestandssysteem
- PyTorch-modellen trainen met TorchElastic
- Waarom het W&B-platform de juiste keuze is voor experimenten met machine learning (ML) en hyperparameter grid search
- Een oplossingsarchitectuur die W&B integreert met EKS en TorchElastic
Voorwaarden
Om de oplossing te volgen, moet u kennis hebben van PyTorch, gedistribueerde data parallel (DDP) training en Kubernetes.
Zet een EKS-cluster op met een schaalbaar bestandssysteem
Een manier om aan de slag te gaan met Amazon EKS is aws-do-eks, Dit is een open-sourceproject dat gebruiksvriendelijke en configureerbare scripts en tools biedt om EKS-clusters in te richten en gedistribueerde trainingstaken uit te voeren. Dit project is gebouwd volgens de principes van de Kader doen: eenvoud, intuïtiviteit en productiviteit. Een gewenst cluster kan eenvoudig worden geconfigureerd met behulp van de eks.conf bestand en gestart door het uitvoeren van de eks-creëren.sh script. Gedetailleerde instructies zijn te vinden in de GitHub-repository voor aws-do-eks.
Het volgende diagram illustreert de EKS-clusterarchitectuur.
Enkele handige tips bij het maken van een EKS-cluster met aws-do-eks:
- Zorg ervoor
CLUSTER_REGIONin conf is hetzelfde als uw standaardregio wanneer u aws configureert. - Het maken van een EKS-cluster kan tot 30 minuten duren. We raden aan om een aws-do-eks-container te maken zoals de GitHub-repo suggereert om consistentie en eenvoud te garanderen, omdat de container alle benodigde tools heeft, zoals kubectl, aws cli, eksctl, enzovoort. Dan kun je de container tegenkomen en rennen
./eks-create.shom de cluster te starten. - Tenzij u Spot-exemplaren opgeeft in conf, worden instanties op verzoek gemaakt.
- U kunt aangepaste AMI's of specifieke zones voor verschillende instantietypen opgeven.
- De
./eks-create.shscript maakt de VPC, subnetten, groepen voor automatisch schalen, het EKS-cluster, de bijbehorende knooppunten en alle andere benodigde resources. Hierdoor wordt één exemplaar van elk type gemaakt. Dan./eks-scale.shzal uw knooppuntgroepen schalen naar de gewenste grootte. - Nadat het cluster is gemaakt, AWS Identiteits- en toegangsbeheer (IAM)-rollen worden gegenereerd met Amazon EKS-gerelateerd beleid voor elk instantietype. Er kan beleid nodig zijn om toegang te krijgen Amazon eenvoudige opslagservice (Amazon S3) of andere services met deze rollen.
- De volgende zijn veelvoorkomende redenen waarom de
./eks-create.shscript kan een fout geven:- Knooppuntgroepen kunnen niet worden gemaakt vanwege onvoldoende capaciteit. Controleer de beschikbaarheid van instanties in de aangevraagde regio en uw capaciteitslimieten.
- Een specifiek instantietype is mogelijk niet beschikbaar of wordt niet ondersteund in een bepaalde zone.
- Het maken van het EKS-cluster AWS CloudFormatie stapels worden niet correct verwijderd. Controleer de actieve CloudFormation-stacks om te zien of het verwijderen van de stack is mislukt.
Er is een schaalbaar gedeeld bestandssysteem nodig zodat meerdere rekenknooppunten in het EKS-cluster gelijktijdig toegang hebben. In dit bericht gebruiken we Amazon elastisch bestandssysteem (Amazon EFS) als een gedeeld bestandssysteem dat elastisch is en een hoge doorvoer biedt. De scripties binnen aws-do-eks/Container-Root/eks/deployment/csi/ instructies geven om Amazon EFS op een EKS-cluster te koppelen. Nadat het cluster is gemaakt en de knooppuntgroepen zijn geschaald naar het gewenste aantal exemplaren, kunt u de actieve pods bekijken met kubectl get pod -A. Hier de aws-node-xxxx, kube-proxy-xxxx en nvidia-device-plugin-daemonset-xxxx pods worden uitgevoerd op elk van de drie rekenknooppunten en we hebben één systeemknooppunt in de naamruimte van het kube-systeem.
Voordat u doorgaat met het maken en koppelen van een EFS-volume, moet u ervoor zorgen dat u zich in de naamruimte van het kube-systeem bevindt. Zo niet, dan kunt u dit wijzigen met de volgende code:
Bekijk dan de running pods met kubectl get pod -A.
De efs-creëren.sh script maakt het EFS-volume en koppelt doelen in elk subnet en het persistente volume. Dan zal een nieuw EFS-volume zichtbaar zijn op de Amazon EFS-console.
Voer vervolgens de ./implementeren.sh script om de systeem-ID van de EFS-bestanden op te halen, een EFS-CSI-stuurprogramma op elke knooppuntgroep te implementeren en het persistente EFS-volume te koppelen met behulp van de efs-sc.yaml en efs-pv.yaml manifest bestanden. U kunt valideren of een persistent volume is aangekoppeld door te controleren kubectl get pv. Je kunt ook rennen kubectl apply -f efs-share-test.yaml, die een efs-share-test-pod zal laten draaien in de standaard naamruimte. Dit is een testpod die "hallo van EFS" schrijft in de /shared-efs/test.txt bestand. Je kunt een pod tegenkomen met behulp van kubectl exec -it <pod-name> -- bash. Om gegevens van Amazon S3 naar Amazon EFS te verplaatsen, efs-data-prep-pod.yaml geeft een voorbeeld van een manifestbestand, uitgaande van a data-prep.sh script bestaat in een Docker-image die gegevens kopieert van Amazon S3 naar Amazon EFS.
Als uw modeltraining een hogere doorvoer nodig heeft, Amazon FSx voor Luster is misschien een betere optie.
Train PyTorch-modellen met TorchElastic
Voor deep learning-modellen die trainen op hoeveelheden gegevens die te groot zijn om in het geheugen van een enkele GPU te passen, Gedistribueerde gegevens parallel (PyTorch DDP) maakt de sharding van grote trainingsgegevens in minibatches over meerdere GPU's en instanties mogelijk, waardoor de trainingstijd wordt verkort.
TorchElastic is een PyTorch-bibliotheek die is ontwikkeld met een native Kubernetes-strategie die fouttolerantie en elasticiteit ondersteunt. Bij het trainen op Spot-instanties moet de training fouttolerant zijn en kunnen worden hervat vanaf het tijdperk waar de rekenknooppunten vertrokken toen de Spot-instanties voor het laatst beschikbaar waren. Elasticiteit zorgt voor de naadloze toevoeging van nieuwe rekenresources wanneer deze beschikbaar zijn of verwijdering van resources wanneer ze elders nodig zijn.
De volgende afbeelding illustreert de architectuur voor DistributedDataParallel met TorchElastic. TorchElastic voor Kubernetes bestaat uit twee componenten: TorchElastic Kubernetes Controller en de parameterserver (etcd). De controller is verantwoordelijk voor het bewaken en beheren van de trainingstaken, en de parameterserver houdt de trainingstaakmedewerkers bij voor gedistribueerde synchronisatie en peer-discovery.
W&B-platform voor ML-experimenten en zoeken naar hyperparameterrasters
W&B helpt ML-teams sneller betere modellen te bouwen. Met slechts een paar regels code kun je direct je modellen debuggen, vergelijken en reproduceren - architectuur, hyperparameters, git commits, modelgewichten, GPU-gebruik, datasets en voorspellingen - terwijl je samenwerkt met je teamgenoten.
W&B Sweeps is een krachtige tool om hyperparameteroptimalisatie te automatiseren. Hiermee kunnen ontwikkelaars de hyperparameter-zoekstrategie instellen, inclusief rasterzoeken, willekeurig zoeken of Bayesiaans zoeken, en het zal automatisch elke trainingsrun implementeren.
Om W&B gratis uit te proberen, meldt u zich aan bij Gewichten en afwijkingen, Of bezoek de W&B AWS Marketplace-vermelding.
Integreer W&B met Amazon EKS en TorchElastic
De volgende afbeelding illustreert de end-to-end processtroom voor het orkestreren van meerdere DistributedDataParallel-trainingsruns op Amazon EKS met TorchElastic op basis van een W&B sweep-configuratie. Concreet zijn de betrokken stappen:
- Verplaats gegevens van Amazon S3 naar Amazon EFS.
- Laad en verwerk gegevens met W&B.
- Bouw een Docker-image met de trainingscode en alle benodigde afhankelijkheden en push de image vervolgens naar Amazon ECR.
- Implementeer de TorchElastic-controller.
- Maak een W&B sweep-configuratiebestand met alle hyperparameters die moeten worden geveegd en hun bereiken.
- Maak een yaml-manifestsjabloonbestand dat invoer uit het sweep-configuratiebestand haalt.
- Maak een Python-taakcontrollerscript dat N trainingsmanifestbestanden maakt, één voor elke trainingsuitvoering, en verzendt de taken naar het EKS-cluster.
- Resultaten visualiseren op het W&B platform.
In de volgende paragrafen doorlopen we elke stap in meer detail.
Verplaats gegevens van Amazon S3 naar Amazon EFS
De eerste stap is het verplaatsen van trainings-, validatie- en testgegevens van Amazon S3 naar Amazon EFS, zodat alle EKS-rekenknooppunten er toegang toe hebben. De s3_efs map bevat de scripts om gegevens van Amazon S3 naar Amazon EFS te verplaatsen. Volgens de Kader doen, hebben we een standaard Dockerfile nodig die een container maakt met een data-prep.sh script, bouwen.sh script en push.sh script om de afbeelding te bouwen en naar Amazon ECR te pushen. Nadat een Docker-image naar Amazon ECR is gepusht, kunt u de efs-data-prep-pod.yaml manifest-bestand (zie de volgende code), dat u kunt uitvoeren zoals kubectl apply -f efs-data-prep-pod.yaml om het data-prep.sh-script in een pod uit te voeren:
apiVersion: v1
kind: ConfigMap
metadata
name: efs-data-prep-map
data:
S3_BUCKET:<S3 Bucket URI with data>
MOUNT_PATH: /shared-efs
---
apiVersion: v1
kind: Pod
metadata:
name: efs-data-prep-pod
spec:
containers:
- name: efs-data-prep-pod
image: <Path to Docker image in ECR>
envFrom:
- configMapRef:
name: efs-data-prep-map
command: ["/bin/bash"]
args: ["-c", "/data-prep.sh $(S3_BUCKET) $(MOUNT_PATH)"]
volumeMounts:
- name: efs-pvc
mountPath: /shared-efs
volumes:
- name: efs-pvc
persistentVolumeClaim:
claimName: efs-claim
restartPolicy: Never
Laad en verwerk gegevens met W&B
Het proces voor het indienen van een voorverwerkingstaak lijkt sterk op de voorgaande stap, op een paar uitzonderingen na. In plaats van een data-prep.sh-script moet u waarschijnlijk een Python-taak uitvoeren om de gegevens voor te verwerken. De preprocess-map bevat de scripts om een preprocessing-taak uit te voeren. De pre-process_data.py script voert twee taken uit: het neemt de onbewerkte gegevens op in Amazon EFS en splitst deze op in trein- en testbestanden, waarna het de gegevens toevoegt aan het W&B-project.
Bouw een Docker-image met trainingscode
hoofd.py laat zien hoe u DistributedDataParallel-training implementeert met TorchElastic. Voor compatibiliteit met W&B is het standaardpraktijk om toe te voegen WANDB_API_KEY als een omgevingsvariabele en voeg toe wandb.login() helemaal aan het begin van de code. Naast de standaardargumenten (aantal tijdperken, batchgrootte, aantal werknemers voor de datalader), moeten we doorgeven wandb_project naam en sweep_id .
In de main.py-code, de run() functie slaat de end-to-end pijplijn op voor de volgende acties:
- Wandb initialiseren op knooppunt 0 voor het loggen van resultaten
- Het vooraf getrainde model laden en de optimalisatie instellen
- Initialisatie van aangepaste trainings- en validatiegegevensladers
- Checkpoints laden en opslaan in elk tijdperk
- De tijdperken doorlopen en de trainings- en validatiefuncties aanroepen
- Nadat de training is voltooid, worden voorspellingen uitgevoerd op de opgegeven testset
De trainings-, validatie-, aangepaste gegevenslader- en sorteerfuncties hoeven niet te worden gewijzigd om resultaten in W&B te loggen. Voor een gedistribueerde trainingsopstelling moeten we het volgende codeblok toevoegen om in te loggen op het knooppunt 0-proces. Hier zijn args de parameters voor de trainingsfunctie naast de sweep-ID en de W&B-projectnaam:
if local_rank == 0: wandb.init(config=args, project=args.wandb_project) args = wandb.config do_log = True
else: do_log = False
Voor meer informatie over W&B en gedistribueerde training, zie Registreer gedistribueerde trainingsexperimenten.
In het main() functie, kunt u de functie run() aanroepen zoals weergegeven in de volgende code. Hier de wandb.agent is de orkestrator van de sweep, maar omdat we meerdere trainingstaken parallel uitvoeren op Amazon EKS, moeten we specificeren count = 1:
wandb.require("service") wandb.setup() if args.sweep_id is not None: wandb.agent(args.sweep_id, lambda: run(args), project=args.wandb_project, count = 1) else: run(args=args)
De Dockerfile installeert de benodigde afhankelijkheden voor PyTorch, HuggingFace en W&B, en specificeert een Python-oproep naar torch.distributed.run als een ingangspunt.
Implementeer een TorchElastic-controller
Voorafgaand aan de training moeten we een TorchElastic Controller voor Kubernetes implementeren, die een aangepaste Kubernetes-resource ElasticJob beheert om TorchElastic-workloads op Kubernetes uit te voeren. We implementeren ook een pod waarop de etcd-server draait door het script uit te voeren implementeren.sh. Het wordt aanbevolen om de etcd-server te verwijderen en opnieuw op te starten bij het herstarten van een nieuwe trainingstaak.
W&B sweep-configuratie
Nadat we het cluster en de container hadden ingesteld, hebben we meerdere runs parallel opgezet met iets andere parameters om de prestaties van ons model te verbeteren. W&B veegt zal dit soort verkenning automatiseren. We hebben een configuratiebestand opgezet waarin we de zoekstrategie, de te monitoren statistiek en de te verkennen parameters definiëren. De volgende code toont een voorbeeld van een sweep-configuratiebestand:
method: bayes
metric: name: val_loss goal: minimize
parameters: learning_rate: min: 0.001 max: 0.1
optimizer: values: ["adam", "sgd"]
Voor meer informatie over het configureren van uw sweeps, volgt u de W&B Sweeps Snelstartgids.
Maak een train.yaml-sjabloon
De volgende code is een voorbeeld van de sjabloon train.yaml die we moeten maken. De Python-taakcontroller gebruikt deze sjabloon en genereert één training .yaml-bestand voor elke run in de hyperparameter grid-zoekopdracht. Enkele belangrijke aandachtspunten zijn:
- De
kubernetes.io/instance-typewaarde neemt de naam over van het instantietype van de EKS-rekenknooppunten. - De args-sectie bevat alle parameters die de py-code als argumenten opneemt, inclusief het aantal tijdperken, batchgrootte, aantal gegevensladerwerkers,
sweep_id, wandb-projectnaam, locatie van het checkpoint-bestand, locatie van de datadirectory, enzovoort. - De
--nproc_per_nodeennvidia.com/gpuwaarden nemen het aantal GPU's in dat u voor training wilt gebruiken. In de volgende configuratie hebben we bijvoorbeeld p3.8xlarge als de EKS-rekenknooppunten, die 4 Nvidia Tesla V100 GPU's hebben, en in elke trainingsrun gebruiken we 2 GPU's. We kunnen zes trainingsruns parallel starten die alle beschikbare 12 GPU's zullen uitputten, waardoor een hoog GPU-gebruik wordt gegarandeerd.
apiVersion: elastic.pytorch.org/v1alpha1
kind: ElasticJob
metadata: name: wandb-finbert-baseline #namespace: elastic-job
spec: # Use "etcd-service:2379" if you already apply etcd.yaml rdzvEndpoint: etcd-service:2379 minReplicas: 1 maxReplicas: 128 replicaSpecs: Worker: replicas: 1 restartPolicy: ExitCode template: apiVersion: v1 kind: Pod spec: nodeSelector: node.kubernetes.io/instance-type: p3.8xlarge containers: - name: elasticjob-worker image: <path to docker image in ECR> imagePullPolicy: Always env: - name: NCCL_DEBUG value: INFO # - name: NCCL_SOCKET_IFNAME # value: lo # - name: FI_PROVIDER # value: sockets args: - "--nproc_per_node=2" - "/workspace/examples/huggingface/main.py" - "--data=/shared-efs/wandb-finbert/" - "--epochs=1" - "--batch-size=16" - "--workers=6" - "--wandb_project=aws_eks_demo" - "--sweep_id=jba9d36p" - "--checkpoint-file=/shared-efs/wandb-finbert/job-z74e8ix8/run-baseline/checkpoint.tar" resources: limits: nvidia.com/gpu: 2 volumeMounts: - name: efs-pvc mountPath: /shared-efs - name: dshm mountPath: /dev/shm volumes: - name: efs-pvc persistentVolumeClaim: claimName: efs-claim - name: dshm emptyDir: medium: Memory
Maak een taakcontroller voor rasterzoeken
Het script run-grid.py is de belangrijkste orkestrator die een TorchElastic training .yaml-sjabloon en W&B sweep-configuratiebestand opneemt, meerdere trainingsmanifestbestanden genereert en deze indient.
Visualiseer de resultaten
We hebben een EKS-cluster opgezet met drie p3.8xlarge instanties met elk 4 Tesla V100 GPU's. We hebben zes parallelle runs opgezet met elk 2 GPU's, terwijl we de leersnelheid en gewichtsvervalparameters voor de Adam-optimizer varieerden. Elke individuele trainingsrun zou ongeveer 25 minuten duren, dus het hele hyperparameterraster zou in 25 minuten kunnen worden geveegd als het parallel werkt, in plaats van 150 minuten als het opeenvolgend werkt. Indien gewenst kan voor elke trainingsronde een enkele GPU worden gebruikt door de --nproc_per_node en nvidia.com/gpu waarden in de training .yaml-sjabloon.
TorchElastic implementeert elasticiteit en fouttolerantie. In dit werk gebruiken we On-Demand-instanties, maar een cluster van Spot-instanties kan worden gegenereerd met een paar wijzigingen in de EKS-configuratie. Als een instantie op een later tijdstip beschikbaar komt en moet worden toegevoegd aan de trainingspool terwijl de training bezig is, hoeven we alleen maar de training .yaml-template bij te werken en deze opnieuw in te dienen. De rendez-vous-functionaliteit van TorchElastic zal de nieuwe instantie dynamisch in de trainingstaak assimileren.
Zodra de Grid Search Job Controller actief is, kunt u alle zes Kubernetes-taken zien met kubectl get pod -A. Er is één taak per trainingsrun en elke taak heeft één werker per knooppunt. Om de logs voor elke pod te zien, kunt u logs volgen met behulp van kubectl logs -f <pod-name>. kubetail geeft tegelijkertijd de logboeken van alle pods voor elke trainingstaak weer. Bij de start van de netbeheerder krijg je een link naar het W&B platform waar je de voortgang van alle opdrachten kunt bekijken.
De volgende grafiek met parallelle coördinaten visualiseert alle zoekacties in het raster met betrekking tot de testnauwkeurigheid in één plot, inclusief de runs die niet zijn voltooid. We hebben de hoogste testnauwkeurigheid met een leersnelheid van 9.1e-4 en gewichtsverval van 8.5e-3.
Het volgende dashboard visualiseert alle zoekacties in het raster samen voor alle statistieken.
Opruimen
Het is belangrijk om resources na de training van het model af te bouwen om kosten te vermijden die gepaard gaan met het uitvoeren van inactieve instanties. Met elk script dat bronnen creëert, GitHub repo biedt een overeenkomend script om ze te verwijderen. Om onze setup op te schonen, moeten we het EFS-bestandssysteem verwijderen voordat we het cluster verwijderen, omdat het is gekoppeld aan een subnet in de VPC van het cluster. Om het EFS-bestandssysteem te verwijderen, voert u de volgende opdracht uit (vanuit de efs map):
Merk op dat hiermee niet alleen het persistente volume wordt verwijderd, maar ook het EFS-bestandssysteem en dat alle gegevens op het bestandssysteem verloren gaan. Wanneer deze stap is voltooid, verwijdert u het cluster met behulp van het volgende script in het ex map:
Hiermee worden alle bestaande pods verwijderd, het cluster verwijderd en de in het begin gemaakte VPC verwijderd.
Conclusie
In dit bericht hebben we laten zien hoe u een EKS-cluster met Weights & Biases kunt gebruiken om het zoeken naar hyperparameterrasters voor deep learning-modellen te versnellen. Met Weights & Biases en Amazon EKS kun je meerdere trainingsruns parallel orkestreren om tijd en kosten te besparen om je deep learning-model te verfijnen. We hebben de gepubliceerd GitHub repo, die u stapsgewijze instructies geeft om een EKS-cluster te maken, Weights & Biases en TorchElastic in te stellen voor parallelle training met gedistribueerde gegevens, en een kickstart voor het zoeken naar rasters met één klik op Amazon EKS.
Over de auteurs
Ankur Srivastava is Sr. Solutions Architect in het ML Frameworks-team. Hij richt zich op het helpen van klanten met zelfbeheerde gedistribueerde training en inferentie op schaal op AWS. Zijn ervaring omvat industrieel voorspellend onderhoud, digitale tweelingen, probabilistische ontwerpoptimalisatie en heeft zijn doctoraatsstudies van Werktuigbouwkunde aan de Rice University en postdoctoraal onderzoek van het Massachusetts Institute of Technology afgerond.
Thomas Kapel is een Machine Learning Engineer bij Weights and Biases. Hij is verantwoordelijk voor het live en up-to-date houden van de repository www.github.com/wandb/examples. Hij bouwt ook content over MLOPS, toepassingen van W&B in industrieën en fun deep learning in het algemeen. Eerder gebruikte hij deep learning om kortetermijnprognoses voor zonne-energie op te lossen. Hij heeft een achtergrond in stedenbouw, combinatorische optimalisatie, transporteconomie en toegepaste wiskunde.
Scott Juang is de directeur van Allianties bij Weights & Biases. Voorafgaand aan W&B leidde hij een aantal strategische allianties bij AWS en Cloudera. Scott studeerde materiaalkunde en heeft een passie voor hernieuwbare energie.
Ilan Gleiser is een Principal Global Impact Computing Specialist bij AWS en leidt de circulaire economie, verantwoorde AI en ESG-bedrijven. Hij is Expert Advisor Digital Technologies for Circular Economy bij de Verenigde Naties. Voorafgaand aan AWS leidde hij AI Enterprise Solutions bij Wells Fargo. Hij was 10 jaar hoofd van Morgan Stanley's Algorithmic Trading Division in San Francisco.
Ana Simoes is Principal ML Specialist bij AWS en richt zich op GTM-strategie voor startups in de opkomende technologieruimte. Ana heeft verschillende leidinggevende functies gehad bij startups en grote bedrijven zoals Intel en eBay, waar ze ML-inferentie en taalgerelateerde producten leidde. Ana heeft een Masters in Computational Linguistics en een MBA van Haas/UC Berkeley, en was gastonderzoeker in Linguistics aan Stanford. Ze heeft een technische achtergrond in AI en Natural Language Processing.
- Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
- Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
- Bron: https://aws.amazon.com/blogs/machine-learning/accelerate-hyperparameter-grid-search-for-sentiment-analysis-with-bert-models-using-weights-biases-amazon-eks-and-torchelastic/
