Öka slutledningsprestanda för Mixtral- och Llama 2-modeller med nya Amazon SageMaker-behållare | Amazon webbtjänster

I januari 2024, Amazon SageMaker lanserade en ny version (0.26.0) av Large Model Inference (LMI) Deep Learning Containers (DLC). Den här versionen erbjuder stöd för nya modeller (inklusive Mixture of Experts), prestanda- och användbarhetsförbättringar över slutledningsbackends, såväl som nya generationsdetaljer för ökad kontroll och förutsägbarhet (såsom orsaken till att generationen slutförts och sannolikheter för logg på tokennivå).

LMI DLCs erbjuder ett gränssnitt med låg kod som förenklar användning av toppmoderna inferensoptimeringstekniker och hårdvara. LMI låter dig tillämpa tensorparallellism; de senaste effektiva teknikerna för uppmärksamhet, batchning, kvantisering och minneshantering; token streaming; och mycket mer, genom att bara kräva modell-ID och valfria modellparametrar. Med LMI DLC:er på SageMaker kan du accelerera tid till värde för din generativ artificiell intelligens (AI) applikationer, avlastning av infrastrukturrelaterade tunga lyft och optimera stora språkmodeller (LLM) för den hårdvara du väljer för att uppnå bästa pris-prestanda i klassen.

I det här inlägget utforskar vi de senaste funktionerna som introduceras i den här utgåvan, undersöker prestandabenchmarks och ger en detaljerad guide om hur du distribuerar nya LLM:er med LMI DLC:er med hög prestanda.

Nya funktioner med LMI DLC:er

I det här avsnittet diskuterar vi nya funktioner över LMI-backends och går igenom några andra som är backend-specifika. LMI stöder för närvarande följande backends:

• LMI-Distribuerat bibliotek – Detta är AWS-ramverket för att köra slutledning med LLM, inspirerat av OSS, för att uppnå bästa möjliga latens och noggrannhet på resultatet
• LMI vLLM – Det här är AWS-backend-implementeringen av den minneseffektiva vLLM slutledningsbibliotek
• LMI TensorRT-LLM verktygslåda – Det här är AWS-backend-implementeringen av NVIDIA TensorRT-LLM, som skapar GPU-specifika motorer för att optimera prestanda på olika GPU:er
• LMI DeepSpeed – Det här är AWS-anpassningen av DeepSpeed, som lägger till sann kontinuerlig batchning, SmoothQuant-kvantisering och möjligheten att dynamiskt justera minnet under slutledning
• LMI NeuronX – Du kan använda detta för distribution på AWS Inferentia2 och AWS Trainium-baserade instanser, med äkta kontinuerlig batchning och speedups, baserat på AWS Neuron SDK

Följande tabell sammanfattar de nyligen tillagda funktionerna, både vanliga och backend-specifika.

Nya modeller stöds

Nya populära modeller stöds över backends, som Mistral-7B (alla backends), MoE-baserade Mixtral (alla backends utom Transformers-NeuronX) och Llama2-70B (Transformers-NeuronX).

Tekniker för kontextfönsterförlängning

Rotary Positional Embedding (RoPE)-baserad kontextskalning är nu tillgänglig på LMI-Dist, vLLM och TensorRT-LLM backends. RoPE-skalning möjliggör förlängning av en modells sekvenslängd under inferens till praktiskt taget vilken storlek som helst, utan behov av finjustering.

Följande är två viktiga överväganden när du använder RoPE:

• Modellförvirring – När sekvenslängden ökar, så kan modellens bryderi. Denna effekt kan delvis kompenseras genom att utföra minimal finjustering av ingångssekvenser större än de som användes i den ursprungliga träningen. För en fördjupad förståelse av hur RoPE påverkar modellkvalitet, se Förlängning av linan.
• Slutledningsprestanda – Längre sekvenslängder kommer att förbruka högre acceleratorns höga bandbreddsminne (HBM). Denna ökade minnesanvändning kan negativt påverka antalet samtidiga förfrågningar som din accelerator kan hantera.

Lade till generationsdetaljer

Du kan nu få två finkorniga detaljer om genereringsresultat:

• finish_reason – Detta ger anledningen till att generationen har slutförts, vilket kan vara att nå den maximala generationslängden, generera en end-of-sentence (EOS)-token eller generera en användardefinierad stopptoken. Den returneras med den senast streamade sekvensbiten.
• log_probs – Detta returnerar loggsannolikheten som tilldelas av modellen för varje token i den strömmade sekvensbiten. Du kan använda dessa som en grov uppskattning av modellens konfidens genom att beräkna den gemensamma sannolikheten för en sekvens som summan av log_probs av de individuella tokens, vilket kan vara användbart för att poängsätta och rangordna modellutdata. Tänk på att sannolikheter för LLM-token i allmänhet är översäkra utan kalibrering.

Du kan aktivera genereringsresultatutmatningen genom att lägga till details=True i din indatanyttolast till LMI, och lämna alla andra parametrar oförändrade:

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

Konsoliderade konfigurationsparametrar

Slutligen har LMI-konfigurationsparametrar också konsoliderats. För mer information om alla vanliga och backend-specifika installationskonfigurationsparametrar, se Stora modellinferenskonfigurationer.

LMI-Distribuerad backend

På AWS re:Invent 2023 lade LMI-Dist till nya, optimerade kollektiva operationer för att påskynda kommunikationen mellan GPU: er, vilket resulterar i lägre latens och högre genomströmning för modeller som är för stora för en enda GPU. Dessa kollektiv är tillgängliga exklusivt för SageMaker, för p4d-instanser.

Medan den tidigare iterationen endast stödde sharding över alla 8 GPU:er, introducerar LMI 0.26.0 stöd för en tensorparallellgrad på 4, i ett partiellt allt-till-alla-mönster. Detta kan kombineras med SageMaker slutledningskomponenter, med vilken du granulärt kan konfigurera hur många acceleratorer som ska allokeras till varje modell som används bakom en slutpunkt. Tillsammans ger dessa funktioner bättre kontroll över resursutnyttjandet av den underliggande instansen, vilket gör att du kan öka modellens multi-tenancy genom att vara värd för olika modeller bakom en slutpunkt, eller finjustera den sammanlagda genomströmningen av din distribution för att matcha din modell och trafikegenskaper.

Följande figur jämför direkt allt-till-alla med partiellt allt-till-alla.

TensorRT-LLM backend

NVIDIAs TensorRT-LLM introducerades som en del av den tidigare LMI DLC-utgåvan (0.25.0), vilket möjliggör toppmodern GPU-prestanda och optimeringar som SmoothQuant, FP8 och kontinuerlig batchning för LLM:er när du använder NVIDIA GPU:er.

TensorRT-LLM kräver att modeller kompileras till effektiva motorer innan de distribueras. LMI TensorRT-LLM DLC kan automatiskt hantera att kompilera en lista över modeller som stöds just-in-time (JIT), innan servern startas och modellen laddas för realtidsslutning. Version 0.26.0 av DLC utökar listan över modeller som stöds för JIT-kompilering, och introducerar modellerna Baichuan, ChatGLM, GPT2, GPT-J, InternLM, Mistral, Mixtral, Qwen, SantaCoder och StarCoder.

JIT-kompilering lägger till flera minuters overhead till slutpunktsprovisionering och skalningstid, så det rekommenderas alltid att kompilera din modell i förväg. För en guide om hur du gör detta och en lista över modeller som stöds, se TensorRT-LLM i förväg sammanställning av modeller handledning. Om din valda modell inte stöds ännu, se TensorRT-LLM manuell sammanställning av modeller handledning för att kompilera någon annan modell som stöds av TensorRT-LLM.

Dessutom exponerar LMI nu inbyggd TensorRT-LLM SmootQuant-kvantisering, med parametrar för att styra alfa- och skalningsfaktor efter token eller kanal. För mer information om relaterade konfigurationer, se TensorRT-LLM.

vLLM-backend

Den uppdaterade versionen av vLLM som ingår i LMI DLC har prestandaförbättringar på upp till 50 % som drivs av CUDA-grafläge istället för ivrigt läge. CUDA-grafer accelererar GPU-arbetsbelastningen genom att starta flera GPU-operationer på en gång istället för att starta dem individuellt, vilket minskar omkostnader. Detta är särskilt effektivt för små modeller när man använder tensorparallellism.

Den extra prestandan kommer vid en kompromiss med ökad GPU-minnesförbrukning. CUDA-grafläget är nu standard för vLLM-backend, så om du är begränsad till mängden tillgängligt GPU-minne kan du ställa in option.enforce_eager=True för att tvinga PyTorch ivrigt läge.

Transformers-NeuronX backend

Den uppdaterade utgåvan av NeuronX som ingår i LMI NeuronX DLC stöder nu modeller som har mekanismen för grupperad sökning, som Mistral-7B och LLama2-70B. Grupperad frågeuppmärksamhet är en viktig optimering av standardtransformatorns uppmärksamhetsmekanism, där modellen tränas med färre nyckel- och värdehuvuden än frågehuvuden. Detta minskar storleken på KV-cachen på GPU-minnet, vilket möjliggör större samtidighet och förbättrar pris-prestanda.

Följande figur illustrerar uppmärksamhetsmetoder för flera huvuden, grupperade frågor och flera frågor (källa).

Olika KV-cache-sharingstrategier är tillgängliga för att passa olika typer av arbetsbelastningar. För mer information om skärningsstrategier, se Stöd för Grouped-Query Attention (GQA).. Du kan aktivera din önskade strategi (shard-over-heads, till exempel) med följande kod:

option.group_query_attention=shard-over-heads

Dessutom introducerar den nya implementeringen av NeuronX DLC ett cache-API för TransformerNeuronX som möjliggör åtkomst till KV-cachen. Det låter dig infoga och ta bort KV-cache-rader från nya förfrågningar medan du lämnar batchade slutsatser. Innan detta API introducerades, beräknades KV-cachen om för alla nyligen tillagda förfrågningar. Jämfört med LMI V7 (0.25.0) har vi förbättrat latensen med mer än 33 % med samtidiga förfrågningar och stöder mycket högre genomströmning.

Att välja rätt backend

För att bestämma vilken backend som ska användas baserat på den valda modellen och uppgiften, använd följande flödesschema. För individuella användarhandböcker för backend tillsammans med modeller som stöds, se LMI Backend Användarguider.

Distribuera Mixtral med LMI DLC med ytterligare attribut

Låt oss gå igenom hur du kan distribuera Mixtral-8x7B-modellen med LMI 0.26.0-behållare och generera ytterligare detaljer som log_prob och finish_reason som en del av produktionen. Vi diskuterar också hur du kan dra nytta av dessa ytterligare attribut genom ett användningsfall för innehållsgenerering.

Den kompletta anteckningsboken med detaljerade instruktioner finns i GitHub repo.

Vi börjar med att importera biblioteken och konfigurera sessionsmiljön:

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

Du kan använda SageMaker LMI-behållare för att vara värd för modeller utan någon ytterligare slutledningskod. Du kan konfigurera modellservern antingen genom miljövariablerna eller en serving.properties fil. Alternativt kan du ha en model.py fil för eventuell för- eller efterbearbetning och en requirements.txt fil för eventuella ytterligare paket som måste installeras.

I det här fallet använder vi serving.properties fil för att konfigurera parametrarna och anpassa LMI-behållarens beteende. För mer information, se GitHub repo. Repoet förklarar detaljer om de olika konfigurationsparametrarna som du kan ställa in. Vi behöver följande nyckelparametrar:

• motor – Anger körtidsmotorn som DJL ska använda. Detta driver sönderdelningen och modellladdningsstrategin i acceleratorerna för modellen.
• option.model_id – Specificerar Amazon enkel lagringstjänst (Amazon S3) URI för den förtränade modellen eller modell-ID för en förtränad modell som finns i ett modellförråd på Kramande ansikte. I det här fallet tillhandahåller vi modell-ID för Mixtral-8x7B-modellen.
• option.tensor_parallel_degree – Ställer in antalet GPU-enheter som Accelerate behöver för att partitionera modellen. Den här parametern styr också antalet arbetare per modell som kommer att startas när DJL-serveringen körs. Vi sätter detta värde till max (max GPU på den aktuella maskinen).
• option.rolling_batch – Möjliggör kontinuerlig batchning för att optimera acceleratorutnyttjandet och den totala genomströmningen. För TensorRT-LLM-behållaren använder vi auto.
• option.model_loading_timeout – Ställer in timeoutvärdet för nedladdning och laddning av modellen för att tjäna slutledning.
• option.max_rolling_batch – Ställer in den maximala storleken på den kontinuerliga batchen, och definierar hur många sekvenser som kan bearbetas parallellt vid varje given tidpunkt.

%%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

Vi paketerar serving.properties konfigurationsfilen i tar.gz-formatet, så att den uppfyller SageMakers värdkrav. Vi konfigurerar DJL LMI-behållaren med tensorrtllm som backend-motor. Dessutom anger vi den senaste versionen av behållaren (0.26.0).

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

Därefter laddar vi upp den lokala tarballen (som innehåller serving.properties konfigurationsfil) till ett S3-prefix. Vi använder bild-URI för DJL-behållaren och Amazon S3-platsen till vilken modellen som serverar artefakter tarball laddades upp, för att skapa SageMaker-modellobjektet.

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
)

Som en del av LMI 0.26.0 kan du nu använda ytterligare två finkorniga detaljer om den genererade utdata:

• log_probs – Detta är loggsannolikheten som tilldelas av modellen för varje token i den streamade sekvensbiten. Du kan använda dessa som en grov uppskattning av modellens konfidens genom att beräkna den gemensamma sannolikheten för en sekvens som summan av loggsannolikheterna för de individuella tokens, vilket kan vara användbart för att poängsätta och rangordna modellutdata. Tänk på att sannolikheter för LLM-token i allmänhet är översäkra utan kalibrering.
• finish_reason – Detta är anledningen till att generationen är klar, vilket kan vara att nå den maximala generationslängden, generera en EOS-token eller generera en användardefinierad stopptoken. Detta returneras med den senast streamade sekvensen.

Du kan aktivera dessa genom att passera "details"=True som en del av din input till modellen.

Låt oss se hur du kan generera dessa detaljer. Vi använder ett exempel på innehållsgenerering för att förstå deras tillämpning.

Vi definierar en LineIterator helper class, som har funktioner för att lätt hämta bytes från en svarsström, buffra dem och bryta ner bufferten i rader. Tanken är att servera bytes från bufferten samtidigt som man hämtar fler bytes från strömmen asynkront.

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

Generera och använd token-sannolikhet som en ytterligare detalj

Överväg ett användningsfall där vi genererar innehåll. Specifikt har vi i uppdrag att skriva ett kort stycke om fördelarna med att träna regelbundet för en livsstilsfokuserad webbplats. Vi vill generera innehåll och producera en indikativ poäng för det förtroende som modellen har för det genererade innehållet.

Vi anropar modellens slutpunkt med vår prompt och fångar det genererade svaret. Vi sätter "details": True som en körtidsparameter i ingången till modellen. Eftersom loggsannolikheten genereras för varje utdatatoken, lägger vi till de individuella loggsannolikheterna till en lista. Vi fångar också den fullständiga genererade texten från svaret.

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']

För att beräkna den övergripande konfidenspoängen, beräknar vi medelvärdet av alla individuella tokensannolikheter och får sedan exponentialvärdet mellan 0 och 1. Detta är vårt antagna totala konfidenspoäng för den genererade texten, vilket i det här fallet är ett stycke om fördelarna regelbunden träning.

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

Detta var ett exempel på hur du kan skapa och använda log_prob, i samband med ett användningsfall för innehållsgenerering. På samma sätt kan du använda log_prob som mått på konfidenspoäng för klassificeringsanvändningsfall.

Alternativt kan du använda den för den övergripande utgångssekvensen eller poängsättning på meningsnivå för att utvärdera påverkan av parametrar som temperatur på den genererade utgången.

Generera och använd slutförklaring som en ytterligare detalj

Låt oss bygga på samma användningsfall, men den här gången får vi i uppdrag att skriva en längre artikel. Dessutom vill vi se till att utdata inte trunkeras på grund av problem med generationslängden (max tokenlängd) eller på grund av att stopptokens påträffas.

För att åstadkomma detta använder vi finish_reason attribut som genereras i utgången, övervaka dess värde och fortsätt generera tills hela utgången genereras.

Vi definierar en slutledningsfunktion som tar en nyttolast-ingång och anropar SageMaker-slutpunkten, strömmar tillbaka ett svar och bearbetar svaret för att extrahera genererad text. Nyttolasten innehåller prompttexten som indata och parametrar som max tokens och detaljer. Svaret läses i en ström och bearbetas rad för rad för att extrahera de genererade textsymbolerna till en lista. Vi extraherar detaljer som finish_reason. Vi anropar inferensfunktionen i en loop (kedjade förfrågningar) samtidigt som vi lägger till mer sammanhang varje gång, och spårar antalet genererade tokens och antalet förfrågningar som skickas tills modellen är klar.

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}")

Som vi kan se, även om max_new_token parametern är inställd på 256, använder vi attributet finish_reason detail som en del av utdata för att koppla flera förfrågningar till slutpunkten, tills hela utdata genereras.

På samma sätt, baserat på ditt användningsfall, kan du använda stop_reason att upptäcka otillräcklig utdatasekvenslängd specificerad för en given uppgift eller oavsiktligt slutförande på grund av en mänsklig stoppsekvens.

Slutsats

I det här inlägget gick vi igenom version 0.26.0 av AWS LMI-behållaren. Vi lyfte fram viktiga prestandaförbättringar, stöd för nya modeller och nya användarvänlighetsfunktioner. Med dessa funktioner kan du bättre balansera kostnads- och prestandaegenskaper samtidigt som du ger dina slutanvändare en bättre upplevelse.

För att lära dig mer om LMI DLC-funktioner, se Modellparallellism och stor modellinferens. Vi är glada över att se hur du använder dessa nya funktioner från SageMaker.

Om författarna

João Moura är Senior AI/ML Specialist Solutions Architect på AWS. João hjälper AWS-kunder – från små startups till stora företag – att utbilda och distribuera stora modeller effektivt, och mer brett bygga ML-plattformar på AWS.

Rahul Sharma är Senior Solutions Architect på AWS och hjälper AWS-kunder att designa och bygga AI/ML-lösningar. Innan han började på AWS har Rahul tillbringat flera år inom finans- och försäkringssektorn och hjälpt kunder att bygga data- och analytiska plattformar.

Qing Lan är en mjukvaruutvecklingsingenjör i AWS. Han har arbetat med flera utmanande produkter i Amazon, inklusive högpresterande ML-slutledningslösningar och högpresterande loggsystem. Qings team lanserade framgångsrikt den första miljardparametermodellen i Amazon Advertising med mycket låg latens som krävs. Qing har djupgående kunskaper om infrastrukturoptimering och Deep Learning-acceleration.

Jian Sheng är en mjukvaruutvecklingsingenjör på Amazon Web Services som har arbetat med flera viktiga aspekter av maskininlärningssystem. Han har varit en viktig bidragsgivare till SageMaker Neo-tjänsten, med fokus på kompilering av djupinlärning och optimering av ramverkskörning. På senare tid har han riktat sina ansträngningar och bidragit till att optimera maskininlärningssystemet för slutledning av stora modeller.

Tyler Österberg är en mjukvaruutvecklingsingenjör på AWS. Han är specialiserad på att skapa högpresterande maskininlärningsupplevelser inom SageMaker. På senare tid har hans fokus varit på att optimera prestandan för Inferentia Deep Learning Containers på SageMaker-plattformen. Tyler utmärker sig i att implementera effektiva värdlösningar för stora språkmodeller och förbättra användarupplevelsen med hjälp av banbrytande teknologi.

Rupinder Grewal är Senior AI/ML Specialist Solutions Architect med AWS. Han fokuserar för närvarande på servering av modeller och MLOps på Amazon SageMaker. Innan denna roll arbetade han som maskininlärningsingenjör med att bygga och vara värdmodeller. Utanför jobbet tycker han om att spela tennis och cykla på bergsstigar.

Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning inklusive NLP- och Computer Vision-domäner. Han hjälper kunder att uppnå högpresterande modellslutningar på SageMaker.

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

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/boost-inference-performance-for-mixtral-and-llama-2-models-with-new-amazon-sagemaker-containers/