Verbeter de inferentieprestaties voor Mixtral- en Llama 2-modellen met nieuwe Amazon SageMaker-containers | Amazon-webservices

In januari 2024, Amazon Sage Maker een nieuwe versie gelanceerd (0.26.0) van Large Model Inference (LMI) Deep Learning Containers (DLC's). Deze versie biedt ondersteuning voor nieuwe modellen (waaronder Mixture of Experts), prestatie- en bruikbaarheidsverbeteringen in de inferentie-backends, evenals nieuwe generatiedetails voor meer controle en verklaarbaarheid van voorspellingen (zoals de reden voor voltooiing van de generatie en logkansen op tokenniveau).

LMI DLC's bieden een low-code-interface die het gebruik van de modernste inferentie-optimalisatietechnieken en hardware vereenvoudigt. Met LMI kunt u tensor-parallellisme toepassen; de nieuwste technieken voor efficiënte aandacht, batching, kwantisering en geheugenbeheer; tokenstreaming; en nog veel meer, door alleen de model-ID en optionele modelparameters te vereisen. Met LMI DLC's op SageMaker kunt u de time-to-value voor uw generatieve kunstmatige intelligentie (AI) applicaties, ontlast infrastructuurgerelateerd zwaar werk en optimaliseer grote taalmodellen (LLM's) voor de hardware van uw keuze om de beste prijs-kwaliteitverhouding in zijn klasse te bereiken.

In dit bericht verkennen we de nieuwste functies die in deze release zijn geïntroduceerd, onderzoeken we prestatiebenchmarks en bieden we een gedetailleerde handleiding voor het implementeren van nieuwe LLM's met LMI DLC's met hoge prestaties.

Nieuwe functies met LMI DLC's

In deze sectie bespreken we nieuwe functies in LMI-backends, en gaan we dieper in op enkele andere functies die backend-specifiek zijn. LMI ondersteunt momenteel de volgende backends:

• LMI-gedistribueerde bibliotheek – Dit is het AWS-framework om gevolgtrekkingen uit te voeren met LLM's, geïnspireerd op OSS, om de best mogelijke latentie en nauwkeurigheid van het resultaat te bereiken
• LMI vLLM – Dit is de AWS-backend-implementatie van geheugenefficiënt vLLM gevolgtrekking bibliotheek
• LMI TensorRT-LLM-toolkit – Dit is de AWS-backend-implementatie van NVIDIA TensorRT-LLM, dat GPU-specifieke motoren creëert om de prestaties op verschillende GPU's te optimaliseren
• LMI DeepSpeed – Dit is de AWS-aanpassing van diepe snelheid, wat echte continue batching, SmoothQuant-kwantisering en de mogelijkheid toevoegt om het geheugen dynamisch aan te passen tijdens inferentie
• LMI NeuronX – U kunt dit gebruiken voor implementatie op AWS Inferentie2 en AWS Trainium-gebaseerde instances, met echte continue batching en versnellingen, gebaseerd op de AWS Neuron-SDK

De volgende tabel geeft een samenvatting van de nieuw toegevoegde functies, zowel algemeen als backend-specifiek.

Nieuwe modellen ondersteund

Nieuwe populaire modellen worden ondersteund via backends, zoals Mistral-7B (alle backends), de MoE-gebaseerde Mixtral (alle backends behalve Transformers-NeuronX) en Llama2-70B (Transformers-NeuronX).

Technieken voor het uitbreiden van contextvensters

Op Rotary Positional Embedding (RoPE) gebaseerde contextschaling is nu beschikbaar op de LMI-Dist-, vLLM- en TensorRT-LLM-backends. RoPE-schaling maakt de uitbreiding van de reekslengte van een model tijdens inferentie mogelijk tot vrijwel elke grootte, zonder dat er fijnafstemming nodig is.

Hier volgen twee belangrijke overwegingen bij het gebruik van RoPE:

• Modelverbijstering – Naarmate de lengte van de reeks toeneemt, dat kan ook de modellen verwarring. Dit effect kan gedeeltelijk worden gecompenseerd door minimale fijnafstemming uit te voeren op invoerreeksen die groter zijn dan die welke in de oorspronkelijke training werden gebruikt. Voor een diepgaand begrip van hoe RoPE de modelkwaliteit beïnvloedt, raadpleegt u Verlenging van de RoPE.
• Inferentieprestaties – Langere reekslengtes zullen het hoge bandbreedtegeheugen (HBM) van de hogere versneller verbruiken. Dit verhoogde geheugengebruik kan een negatief effect hebben op het aantal gelijktijdige verzoeken dat uw accelerator kan verwerken.

Genereringsdetails toegevoegd

U kunt nu twee gedetailleerde details krijgen over de generatieresultaten:

• finish_reden – Dit geeft de reden voor de voltooiing van de generatie, die het bereiken van de maximale generatielengte kan zijn, het genereren van een einde-van-zin-token (EOS) of het genereren van een door de gebruiker gedefinieerd stop-token. Het wordt geretourneerd met het laatste gestreamde reeksfragment.
• log_probs – Dit retourneert de logwaarschijnlijkheid die door het model is toegewezen voor elk token in het gestreamde reeksfragment. U kunt deze gebruiken als een ruwe schatting van de betrouwbaarheid van het model door de gezamenlijke waarschijnlijkheid van een reeks te berekenen als de som van de log_probs van de individuele tokens, wat handig kan zijn voor het scoren en rangschikken van modeluitvoer. Houd er rekening mee dat de LLM-tokenkansen over het algemeen te zelfverzekerd zijn zonder kalibratie.

U kunt de uitvoer van generatieresultaten inschakelen door details=True toe te voegen aan uw invoerpayload aan LMI, waarbij alle andere parameters ongewijzigd blijven:

payload = {“inputs”:“your prompt”,
“parameters”:{max_new_tokens”:256,...,“details”:True}
}

Geconsolideerde configuratieparameters

Ten slotte zijn ook de LMI-configuratieparameters geconsolideerd. Zie voor meer informatie over alle algemene en backend-specifieke implementatieconfiguratieparameters Configuraties voor grote modelinferentie.

LMI-gedistribueerde backend

Op AWS re:Invent 2023 heeft LMI-Dist nieuwe, geoptimaliseerde collectieve operaties toegevoegd om de communicatie tussen GPU's te versnellen, wat resulteert in een lagere latentie en hogere doorvoer voor modellen die te groot zijn voor een enkele GPU. Deze collectieven zijn exclusief beschikbaar voor SageMaker, voor p4d-instanties.

Terwijl de vorige iteratie alleen sharding over alle 8 GPU's ondersteunde, introduceert LMI 0.26.0 ondersteuning voor een tensor parallelle graad van 4, in een gedeeltelijk alles-tot-alles patroon. Dit kan gecombineerd worden met SageMaker-inferentiecomponenten, waarmee u gedetailleerd kunt configureren hoeveel versnellers moeten worden toegewezen aan elk model dat achter een eindpunt wordt geïmplementeerd. Samen bieden deze functies betere controle over het resourcegebruik van het onderliggende exemplaar, waardoor u de multi-tenancy van modellen kunt vergroten door verschillende modellen achter één eindpunt te hosten, of de totale doorvoer van uw implementatie kunt afstemmen op uw model- en verkeerskenmerken.

De volgende afbeelding vergelijkt directe alles-op-alles met gedeeltelijke alles-op-alles.

TensorRT-LLM-backend

NVIDIA's TensorRT-LLM werd geïntroduceerd als onderdeel van de vorige LMI DLC-release (0.25.0), waardoor ultramoderne GPU-prestaties en optimalisaties zoals SmoothQuant, FP8 en continue batching voor LLM's mogelijk zijn bij gebruik van NVIDIA GPU's.

TensorRT-LLM vereist dat modellen vóór implementatie in efficiënte motoren worden gecompileerd. De LMI TensorRT-LLM DLC kan automatisch just-in-time (JIT) een lijst met ondersteunde modellen samenstellen, voordat de server wordt gestart en het model wordt geladen voor realtime gevolgtrekking. Versie 0.26.0 van de DLC breidt de lijst met ondersteunde modellen voor JIT-compilatie uit, met de introductie van Baichuan-, ChatGLM-, GPT2-, GPT-J-, InternLM-, Mistral-, Mixtral-, Qwen-, SantaCoder- en StarCoder-modellen.

JIT-compilatie voegt enkele minuten overhead toe aan de inrichting en schaaltijd van eindpunten, dus het wordt altijd aanbevolen om uw model van tevoren te compileren. Voor een handleiding over hoe u dit kunt doen en een lijst met ondersteunde modellen, zie TensorRT-LLM-tutorial voor het vooraf compileren van modellen. Als uw geselecteerde model nog niet wordt ondersteund, raadpleegt u TensorRT-LLM handleiding voor het handmatig compileren van modellen om elk ander model te compileren dat wordt ondersteund door TensorRT-LLM.

Bovendien maakt LMI nu native TensorRT-LLM SmootQuant-kwantisering mogelijk, met parameters om de alfa- en schaalfactor per token of kanaal te regelen. Voor meer informatie over de gerelateerde configuraties, zie TensorRT-LLM.

vLLM-backend

De bijgewerkte versie van vLLM, opgenomen in LMI DLC, biedt prestatieverbeteringen tot 50%, mogelijk gemaakt door de CUDA-grafiekmodus in plaats van de enthousiaste modus. CUDA-grafieken versnellen de GPU-werklast door meerdere GPU-bewerkingen in één keer te starten in plaats van ze afzonderlijk te starten, waardoor de overhead wordt verminderd. Dit is vooral effectief voor kleine modellen bij gebruik van tensorparallellisme.

De extra prestaties gaan gepaard met een afweging van extra GPU-geheugenverbruik. De CUDA-grafiekmodus is nu standaard voor de vLLM-backend, dus als u beperkt bent in de hoeveelheid beschikbaar GPU-geheugen, kunt u option.enforce_eager=True om de PyTorch-gretige-modus te forceren.

Transformers-NeuronX-backend

De bijgewerkte versie van NeuronX opgenomen in de LMI NeuronX DLC ondersteunt nu modellen die beschikken over het aandachtsmechanisme voor gegroepeerde zoekopdrachten, zoals Mistral-7B en LLama2-70B. Aandacht voor gegroepeerde query's is een belangrijke optimalisatie van het standaardmechanisme voor de aandacht van transformatoren, waarbij het model wordt getraind met minder sleutel- en waardekoppen dan querykoppen. Dit verkleint de grootte van de KV-cache op GPU-geheugen, waardoor een grotere gelijktijdigheid mogelijk is en de prijs-prestatieverhouding verbetert.

De volgende afbeelding illustreert aandachtsmethoden met meerdere koppen, gegroepeerde query's en multi-query-aandachtsmethoden ((bron)).

Er zijn verschillende KV-cache-shardingstrategieën beschikbaar voor verschillende soorten werklasten. Zie voor meer informatie over shardingstrategieën Ondersteuning voor gegroepeerde query-aandacht (GQA).. U kunt uw gewenste strategie inschakelen (shard-over-heads, bijvoorbeeld) met de volgende code:

option.group_query_attention=shard-over-heads

Bovendien introduceert de nieuwe implementatie van NeuronX DLC een cache-API voor TransformerNeuronX die toegang tot de KV-cache mogelijk maakt. Hiermee kunt u KV-cacherijen uit nieuwe verzoeken invoegen en verwijderen terwijl u batchgewijze gevolgtrekkingen uitvoert. Voordat deze API werd geïntroduceerd, werd de KV-cache opnieuw berekend voor nieuw toegevoegde verzoeken. Vergeleken met LMI V7 (0.25.0) hebben we de latentie met meer dan 33% verbeterd bij gelijktijdige verzoeken en ondersteunen we een veel hogere doorvoer.

Het selecteren van de juiste backend

Gebruik het volgende stroomdiagram om te beslissen welke backend u wilt gebruiken op basis van het geselecteerde model en de geselecteerde taak. Voor individuele backend-gebruikershandleidingen en ondersteunde modellen, zie LMI Backend-gebruikershandleidingen.

Implementeer Mixtral met LMI DLC met extra attributen

Laten we eens kijken hoe u het Mixtral-8x7B-model met LMI 0.26.0-container kunt implementeren en aanvullende details kunt genereren, zoals log_prob en finish_reason als onderdeel van de uitvoer. We bespreken ook hoe u kunt profiteren van deze extra kenmerken via een gebruiksscenario voor het genereren van inhoud.

Het volledige notitieboekje met gedetailleerde instructies is verkrijgbaar in de GitHub repo.

We beginnen met het importeren van de bibliotheken en het configureren van de sessieomgeving:

import boto3
import sagemaker 
import json 
import io 
import numpy as np 
from sagemaker import Model, image_uris, serializers, deserializers 

role = sagemaker.get_execution_role() # execution role for the endpoint 
session = sagemaker.session.Session() # sagemaker session for interacting with different AWS APIs 
region = session._region_name # region name of the current SageMaker Studio environment

U kunt SageMaker LMI-containers gebruiken om modellen te hosten zonder aanvullende inferentiecode. U kunt de modelserver configureren via de omgevingsvariabelen of via een serving.properties bestand. Optioneel kunt u een model.py bestand voor eventuele voor- of nabewerking en requirements.txt bestand voor eventuele aanvullende pakketten die moeten worden geïnstalleerd.

In dit geval gebruiken wij de serving.properties -bestand om de parameters te configureren en het gedrag van de LMI-container aan te passen. Voor meer details, zie de GitHub repo. In de repository worden details uitgelegd van de verschillende configuratieparameters die u kunt instellen. We hebben de volgende sleutelparameters nodig:

• machine – Specificeert de runtime-engine die DJL moet gebruiken. Dit drijft de sharding- en de modellaadstrategie in de versnellers voor het model aan.
• optie.model_id – Specificeert de Amazon eenvoudige opslagservice (Amazon S3) URI van het vooraf getrainde model of de model-ID van een vooraf getraind model dat wordt gehost in een modelrepository op Gezicht knuffelen. In dit geval geven we de model-ID voor het Mixtral-8x7B-model op.
• optie.tensor_parallel_degree – Stelt het aantal GPU-apparaten in waarover Accelerate het model moet verdelen. Deze parameter bepaalt ook het aantal werkers per model dat zal worden opgestart wanneer DJL-servering wordt uitgevoerd. Wij stellen deze waarde in op max (maximale GPU op de huidige machine).
• optie.rolling_batch – Maakt continue batching mogelijk om het gebruik van de versneller en de algehele doorvoer te optimaliseren. Voor de TensorRT-LLM-container gebruiken we auto.
• optie.model_loading_timeout – Stelt de time-outwaarde in voor het downloaden en laden van het model voor gevolgtrekking.
• optie.max_rolling_batch – Stelt de maximale grootte van de continue batch in, waarbij wordt gedefinieerd hoeveel reeksen op een bepaald moment parallel kunnen worden verwerkt.

%%writefile serving.properties 
engine=MPI 
option.model_id=mistralai/Mixtral-8x7B-v0.1 
option.tensor_parallel_degree=max 
option.max_rolling_batch_size=32 
option.rolling_batch=auto 
option.model_loading_timeout = 7200

Wij verpakken de serving.properties configuratiebestand in het tar.gz-formaat, zodat het voldoet aan de hostingvereisten van SageMaker. We configureren de DJL LMI-container met tensorrtllm als de backend-engine. Daarnaast specificeren we de nieuwste versie van de container (0.26.0).

image_uri = image_uris.retrieve(
   framework="djl-tensorrtllm",
   region=sess.boto_session.region_name,
   version="0.26.0"
)

Vervolgens uploaden we de lokale tarball (met de serving.properties configuratiebestand) naar een S3-voorvoegsel. We gebruiken de afbeeldings-URI voor de DJL-container en de Amazon S3-locatie waarnaar het tarball-model met artefacten is geüpload om het SageMaker-modelobject te maken.

model = Model(image_uri=image_uri, model_data=code_artifact, role=role) 

instance_type = "ml.p4d.24xlarge" 
endpoint_name = sagemaker.utils.name_from_base("mixtral-lmi-model") 

model.deploy(
   initial_instance_count=1,
   instance_type=instance_type,
   endpoint_name=endpoint_name,
   container_startup_health_check_timeout=1800
)

Als onderdeel van LMI 0.26.0 kunt u nu twee aanvullende gedetailleerde details over de gegenereerde uitvoer gebruiken:

• log_probs – Dit is de logwaarschijnlijkheid die door het model is toegewezen voor elk token in het gestreamde reeksfragment. U kunt deze gebruiken als een ruwe schatting van de betrouwbaarheid van het model door de gezamenlijke waarschijnlijkheid van een reeks te berekenen als de som van de logwaarschijnlijkheden van de individuele tokens, wat handig kan zijn voor het scoren en rangschikken van modeluitvoer. Houd er rekening mee dat de LLM-tokenkansen over het algemeen te zelfverzekerd zijn zonder kalibratie.
• finish_reden – Dit is de reden voor het voltooien van de generatie. Dit kan het bereiken van de maximale generatielengte zijn, het genereren van een EOS-token of het genereren van een door de gebruiker gedefinieerd stop-token. Dit wordt geretourneerd met het laatste gestreamde reeksfragment.

U kunt deze inschakelen door te passeren "details"=True als onderdeel van uw inbreng in het model.

Laten we eens kijken hoe u deze details kunt genereren. We gebruiken een voorbeeld van het genereren van inhoud om de toepassing ervan te begrijpen.

We definiëren een LineIterator helper-klasse, die functies heeft om lui bytes uit een antwoordstroom op te halen, deze te bufferen en de buffer in lijnen op te splitsen. Het idee is om bytes uit de buffer te serveren terwijl er asynchroon meer bytes uit de stream worden opgehaald.

class LineIterator:
    def __init__(self, stream):
        # Iterator to get bytes from stream 
        self.byte_iterator = iter(stream)  
        # Buffer stream bytes until we get a full line
        self.buffer = io.BytesIO()  
        # Track current reading position within buffer
        self.read_pos = 0

   def __iter__(self):
        # Make class iterable 
        return self

    def __next__(self):
        while True:
           # Seek read position within buffer
           self.buffer.seek(self.read_pos)  
           # Try reading a line from current position
           line = self.buffer.readline()
           # If we have a full line
           if line and line[-1] == ord('n'):
               # Increment reading position past this line
               self.read_pos += len(line)  
               # Return the line read without newline char
               return line[:-1] 
           # Fetch next chunk from stream  
           try:
               chunk = next(self.byte_iterator)
           # Handle end of stream 
           except StopIteration:
               # Check if we have any bytes still unread
               if self.read_pos < self.buffer.getbuffer().nbytes:
                   continue
               # If not, raise StopIteration
               raise
           # Add fetched bytes to end of buffer
           self.buffer.seek(0, io.SEEK_END)  
           self.buffer.write(chunk['PayloadPart']['Bytes'])

Genereer en gebruik tokenwaarschijnlijkheid als extra detail

Overweeg een gebruiksscenario waarbij we inhoud genereren. Concreet hebben we de taak om een ​​korte paragraaf te schrijven over de voordelen van regelmatig sporten voor een op levensstijl gerichte website. We willen inhoud genereren en een indicatieve score weergeven van het vertrouwen dat het model heeft in de gegenereerde inhoud.

We roepen het modeleindpunt aan met onze prompt en leggen het gegenereerde antwoord vast. Wij zetten "details": True als runtimeparameter binnen de invoer van het model. Omdat de logwaarschijnlijkheid voor elk uitvoertoken wordt gegenereerd, voegen we de individuele logwaarschijnlijkheden toe aan een lijst. We leggen ook de volledige gegenereerde tekst uit het antwoord vast.

sm_client = boto3.client("sagemaker-runtime")

# Set details: True as a runtime parameter within the input.
body = {"inputs": prompt, "parameters": {"max_new_tokens":512, "details": True}}
resp = sm_client.invoke_endpoint_with_response_stream(EndpointName=endpoint_name, Body=json.dumps(body), ContentType="application/json")
event_stream = resp['Body']

overall_log_prob = []

for line in LineIterator(event_stream):
    resp = json.loads(line)
    if resp['token'].get('text') != None:
        token_log_prob = resp['token']['log_prob']
        overall_log_prob.append(token_log_prob)
    elif resp['generated_text'] != None:
        generated_text= resp['generated_text']

Om de algehele betrouwbaarheidsscore te berekenen, berekenen we het gemiddelde van alle individuele tokenkansen en verkrijgen vervolgens de exponentiële waarde tussen 0 en 1. Dit is onze afgeleide algehele betrouwbaarheidsscore voor de gegenereerde tekst, in dit geval een paragraaf over de voordelen van regelmatig sporten.

print(generated_text) 
overall_score=np.exp(np.mean(overall_log_prob)) 
print(f"nnOverall confidence score in the generated text: {overall_score}")

Dit was een voorbeeld van hoe je kunt genereren en gebruiken log_prob, in de context van een gebruiksscenario voor het genereren van inhoud. Op dezelfde manier kunt u gebruiken log_prob als maatstaf voor de betrouwbaarheidsscore voor gebruiksscenario's voor classificatie.

Als alternatief kunt u het gebruiken voor de algehele uitvoervolgorde of het scoren op zinsniveau om het effect van parameters zoals temperatuur op de gegenereerde uitvoer te evalueren.

Genereer en gebruik de afwerkingsreden als extra detail

Laten we voortbouwen op dezelfde use case, maar deze keer hebben we de taak een langer artikel te schrijven. Daarnaast willen we ervoor zorgen dat de uitvoer niet wordt afgekapt vanwege problemen met de generatielengte (max. tokenlengte) of omdat er stoptokens worden aangetroffen.

Om dit te bereiken maken wij gebruik van de finish_reason attribuut gegenereerd in de uitvoer, controleer de waarde ervan en ga door met genereren totdat de volledige uitvoer is gegenereerd.

We definiëren een inferentiefunctie die een payload-invoer gebruikt en het SageMaker-eindpunt aanroept, een antwoord terugstuurt en het antwoord verwerkt om de gegenereerde tekst te extraheren. De payload bevat de prompttekst als invoer en parameters zoals max. tokens en details. Het antwoord wordt in een stroom gelezen en regel voor regel verwerkt om de gegenereerde teksttokens in een lijst te extraheren. We extraheren details zoals finish_reason. We roepen de inferentiefunctie in een lus aan (gekoppelde verzoeken), terwijl we elke keer meer context toevoegen, en volgen het aantal gegenereerde tokens en het aantal verzonden verzoeken totdat het model is voltooid.

def inference(payload):
    # Call SageMaker endpoint and get response stream
    resp = sm_client.invoke_endpoint_with_response_stream(EndpointName=endpoint_name, Body=json.dumps(payload), ContentType="application/json")
    event_stream = resp['Body']
    text_output = []
    for line in LineIterator(event_stream):
        resp = json.loads(line) 
        # Extract text tokens if present
        if resp['token'].get('text') != None:
            token = resp['token']['text']
            text_output.append(token)  
            print(token, end='')
        # Get finish reason if details present
        if resp.get('details') != None:
            finish_reason = resp['details']['finish_reason']
            # Return extracted output, finish reason and token length
            return payload['inputs'] + ''.join(text_output), finish_reason, len(text_output)

# set details: True as a runtime parameter within the input.
payload = {"inputs": prompt,  "parameters": {"max_new_tokens":256, "details": True}} 

finish_reason = "length"
# Print initial output 
print(f"Output: {payload['inputs']}", end='')  
total_tokens = 0
total_requests = 0
while finish_reason == 'length':
    # Call inference and get extracts
    output_text, finish_reason, out_token_len = inference(payload)
    # Update payload for next request
    payload['inputs'] = output_text 
    total_tokens += out_token_len
    total_requests += 1
# Print metrics
print(f"nntotal tokens generated: {total_tokens} ntotal requests sent: {total_requests}")

Zoals we kunnen zien, ook al is de max_new_token parameter is ingesteld op 256, gebruiken we het detailattribuut finish_reason als onderdeel van de uitvoer om meerdere verzoeken aan het eindpunt te koppelen, totdat de volledige uitvoer is gegenereerd.

Op dezelfde manier kunt u, op basis van uw gebruiksscenario, gebruiken stop_reason om onvoldoende uitvoerreekslengte te detecteren die is opgegeven voor een bepaalde taak of onbedoelde voltooiing als gevolg van een menselijke stopreeks.

Conclusie

In dit bericht hebben we de v0.26.0-release van de AWS LMI-container doorgenomen. We hebben belangrijke prestatieverbeteringen, nieuwe modelondersteuning en nieuwe bruikbaarheidsfuncties benadrukt. Met deze mogelijkheden kunt u de kosten en prestatiekenmerken beter in evenwicht brengen en tegelijkertijd uw eindgebruikers een betere ervaring bieden.

Voor meer informatie over de LMI DLC-mogelijkheden raadpleegt u Modelparallelisme en grote modelinferentie. We zijn benieuwd hoe u deze nieuwe mogelijkheden van SageMaker gebruikt.

Over de auteurs

Joao Moura is een Senior AI/ML Specialist Solutions Architect bij AWS. João helpt AWS-klanten – van kleine startups tot grote ondernemingen – grote modellen efficiënt op te leiden en in te zetten, en breder ML-platforms op AWS te bouwen.

Rahul Sharma is een Senior Solutions Architect bij AWS en helpt AWS-klanten bij het ontwerpen en bouwen van AI/ML-oplossingen. Voordat hij bij AWS kwam, heeft Rahul een aantal jaren in de financiële en verzekeringssector doorgebracht, waar hij klanten hielp bij het bouwen van data- en analytische platforms.

Qing Lan is een Software Development Engineer bij AWS. Hij heeft aan verschillende uitdagende producten in Amazon gewerkt, waaronder hoogwaardige ML-inferentieoplossingen en een hoogwaardig logsysteem. Het team van Qing lanceerde met succes het eerste miljard-parametermodel in Amazon Advertising met een zeer lage latentie vereist. Qing heeft diepgaande kennis over de optimalisatie van de infrastructuur en de versnelling van Deep Learning.

Jian Sheng is een Software Development Engineer bij Amazon Web Services die aan verschillende belangrijke aspecten van machine learning-systemen heeft gewerkt. Hij heeft een belangrijke bijdrage geleverd aan de SageMaker Neo-service, met de nadruk op deep learning-compilatie en framework-runtime-optimalisatie. Onlangs heeft hij zijn inspanningen gericht en bijgedragen aan het optimaliseren van het machine learning-systeem voor gevolgtrekking van grote modellen.

Tyler Osterberg is een softwareontwikkelingsingenieur bij AWS. Hij is gespecialiseerd in het creëren van hoogwaardige machine learning-inferentie-ervaringen binnen SageMaker. Recentelijk lag zijn focus op het optimaliseren van de prestaties van Inferentia Deep Learning Containers op het SageMaker-platform. Tyler blinkt uit in het implementeren van performante hostingoplossingen voor grote taalmodellen en het verbeteren van gebruikerservaringen met behulp van de allernieuwste technologie.

Rupinder Grewal is een Senior AI/ML Specialist Solutions Architect bij AWS. Momenteel richt hij zich op het serveren van modellen en MLOps op Amazon SageMaker. Voorafgaand aan deze rol werkte hij als Machine Learning Engineer bij het bouwen en hosten van modellen. Buiten zijn werk speelt hij graag tennis en fietst hij op bergpaden.

Dhawal Patel is een Principal Machine Learning Architect bij AWS. Hij heeft gewerkt met organisaties variërend van grote ondernemingen tot middelgrote startups aan problemen met betrekking tot gedistribueerde computing en kunstmatige intelligentie. Hij richt zich op Deep learning inclusief NLP en Computer Vision domeinen. Hij helpt klanten bij het bereiken van high-performance modelinferentie op SageMaker.

Raghu Ramesha is een Senior ML Solutions Architect bij het Amazon SageMaker Service-team. Hij richt zich op het helpen van klanten bij het op grote schaal bouwen, implementeren en migreren van ML-productieworkloads naar SageMaker. Hij is gespecialiseerd in machine learning, AI en computer vision-domeinen, en heeft een masterdiploma in computerwetenschappen van UT Dallas. In zijn vrije tijd houdt hij van reizen en fotografie.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/machine-learning/boost-inference-performance-for-mixtral-and-llama-2-models-with-new-amazon-sagemaker-containers/