Introductie van de Amazon SageMaker Serverless Inference Benchmarking Toolkit

Amazon SageMaker Serverloze inferentie is een speciaal gebouwde inferentieoptie waarmee u gemakkelijk machine learning-modellen (ML) kunt implementeren en schalen. Het biedt een pay-per-use-model, dat ideaal is voor services waarbij eindpuntaanroepen niet vaak voorkomen en onvoorspelbaar zijn. In tegenstelling tot een realtime hosting-eindpunt, dat wordt ondersteund door een langlopende instantie, worden rekenresources voor serverloze eindpunten op aanvraag ingericht, waardoor het niet meer nodig is om instantietypen te kiezen of schaalbeleid te beheren.

De volgende architectuur op hoog niveau illustreert hoe een serverloos eindpunt werkt. Een client roept een eindpunt aan, dat wordt ondersteund door door AWS beheerde infrastructuur.

Serverloze eindpunten zijn echter gevoelig voor koude starts in de orde van seconden en zijn daarom meer geschikt voor intermitterende of onvoorspelbare workloads.

Om te helpen bepalen of een serverloos eindpunt de juiste implementatieoptie is vanuit het oogpunt van kosten en prestaties, hebben we de SageMaker Serverless Inferentie Benchmarking Toolkit, die verschillende eindpuntconfiguraties test en de meest optimale vergelijkt met een vergelijkbare realtime hostinginstantie.

In dit bericht introduceren we de toolkit en geven we een overzicht van de configuratie en output.

Overzicht oplossingen

U kunt de toolkit downloaden en installeren vanaf de GitHub repo. Aan de slag gaan is eenvoudig: installeer gewoon de bibliotheek, maak een SageMaker-model, en geef de naam van uw model op, samen met een op JSON-regels opgemaakt bestand met een voorbeeldset aanroepparameters, inclusief de hoofdtekst van de payload en het inhoudstype. Er wordt een gemaksfunctie geboden om een ​​lijst met voorbeeldaanroepargumenten te converteren naar een JSON-regelsbestand of een augurkbestand voor binaire payloads zoals afbeeldingen, video of audio.

Installeer de toolkit

Installeer eerst de benchmarking-bibliotheek in uw Python-omgeving met behulp van pip:

pip install sm-serverless-benchmarking

U kunt de volgende code uitvoeren vanuit een Amazon SageMaker Studio voorbeeld, SageMaker notebook-instantie, of een instantie met programmatische toegang naar AWS en de juiste AWS Identiteits- en toegangsbeheer (IAM)-machtigingen. De vereiste IAM-machtigingen zijn gedocumenteerd in de: GitHub repo. Raadpleeg voor aanvullende richtlijnen en voorbeeldbeleid voor IAM: Hoe Amazon SageMaker werkt met IAM. Deze code voert een benchmark uit met een standaardset parameters op een model dat een CSV-invoer verwacht met twee voorbeeldrecords. Het is een goede gewoonte om een ​​representatieve reeks voorbeelden te geven om te analyseren hoe het eindpunt presteert met verschillende invoerpayloads.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Bovendien kunt u de benchmark uitvoeren als een SageMaker Processing-taak, wat een betrouwbaardere optie kan zijn voor langerlopende benchmarks met een groot aantal aanroepen. Zie de volgende code:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Houd er rekening mee dat dit extra kosten met zich meebrengt voor het uitvoeren van een ml.m5.large SageMaker Processing-instantie voor de duur van de benchmark.

Beide methoden accepteren een aantal parameters om te configureren, zoals een lijst met geheugenconfiguraties om te benchmarken en het aantal keren dat elke configuratie wordt aangeroepen. In de meeste gevallen zouden de standaardopties als uitgangspunt moeten volstaan, maar raadpleeg de GitHub repo voor een volledige lijst en beschrijvingen van elke parameter.

Benchmarking-configuratie

Voordat we ingaan op wat de benchmark doet en welke output het produceert, is het belangrijk om een ​​paar belangrijke concepten te begrijpen als het gaat om het configureren van serverloze eindpunten.

Er zijn twee belangrijke configuratie-opties: MemorySizeInMB en MaxConcurrency. MemorySizeInMB configureert de hoeveelheid geheugen die aan de instantie wordt toegewezen en kan 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB of 6144 MB zijn. Het aantal vCPU's schaalt ook evenredig met de hoeveelheid toegewezen geheugen. De MaxConcurrency parameter past aan hoeveel gelijktijdige aanvragen een eindpunt kan verwerken. Met een MaxConcurrency van 1, kan een serverloos eindpunt slechts één verzoek tegelijk verwerken.

Samenvattend, de MemorySizeInMB parameter biedt een mechanisme voor verticale schaalbaarheid, waardoor u geheugen en computerbronnen kunt aanpassen om grotere modellen te bedienen, terwijl MaxConcurrency biedt een mechanisme voor horizontale schaalbaarheid, waardoor uw eindpunt meer gelijktijdige verzoeken kan verwerken.

De kosten voor het gebruik van een eindpunt worden grotendeels bepaald door de geheugengrootte en er zijn geen kosten verbonden aan het verhogen van de maximale gelijktijdigheid. Er is echter een accountlimiet per regio voor maximale gelijktijdigheid voor alle eindpunten. Verwijzen naar SageMaker-eindpunten en quota's voor de laatste limieten.

Benchmarking-uitgangen

Daarom is het doel van het benchmarken van een serverloos eindpunt het bepalen van de meest kosteneffectieve en betrouwbare instelling voor de geheugengrootte en de minimale maximale gelijktijdigheid die uw verwachte verkeerspatronen aankan.

Standaard voert de tool twee benchmarks uit. De eerste is een stabiliteitsbenchmark, die een eindpunt implementeert voor elk van de opgegeven geheugenconfiguraties en elk eindpunt aanroept met de geleverde voorbeeldpayloads. Het doel van deze benchmark is om de meest effectieve en stabiele MemorySizeInMB-instelling te bepalen. De benchmark legt de aanroeplatenties vast en berekent de verwachte kosten per aanroep voor elk eindpunt. Vervolgens vergelijkt het de kosten met een vergelijkbaar realtime hosting-exemplaar.

Wanneer de benchmarking is voltooid, genereert de tool verschillende outputs in de gespecificeerde result_save_path directory met de volgende directorystructuur:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

De benchmarking_report directory bevat een geconsolideerd rapport met alle samenvattingsresultaten die we in dit bericht schetsen. Aanvullende mappen bevatten onbewerkte en tussenliggende uitvoer die u kunt gebruiken voor aanvullende analyses. Verwijs naar de GitHub repo voor een meer gedetailleerde beschrijving van elk uitvoerartefact.

Laten we een paar feitelijke benchmarking-outputs bekijken voor een eindpunt dat een MobileNetV2 TensorFlow-model met computervisie bedient. Als u dit voorbeeld wilt reproduceren, raadpleegt u de voorbeeld notitieboekjes map in de GitHub-opslagplaats.

De eerste output in het geconsolideerde rapport is een samenvattende tabel met de minimale, gemiddelde, gemiddelde en maximale latentiestatistieken voor elk MemorySizeInMB succesvolle configuratie van de geheugengrootte. Zoals in de volgende tabel wordt weergegeven, is de gemiddelde aanroeplatentie (invocation_latency_mean) bleef verbeteren toen de geheugenconfiguratie werd verhoogd tot 3072 MB, maar stopte daarna met verbeteren.

Naast de beschrijvende statistieken op hoog niveau, wordt een grafiek verstrekt die de distributie van latentie toont zoals waargenomen door de client voor elk van de geheugenconfiguraties. Nogmaals, we kunnen vaststellen dat de 1024 MB-configuratie niet zo performant is als de andere opties, maar er is geen wezenlijk verschil in prestatie in configuraties van 2048 en hoger.

Amazon Cloud Watch metrische gegevens die aan elke eindpuntconfiguratie zijn gekoppeld, worden ook verstrekt. Een belangrijke statistiek hier is: ModelSetupTime, die meet hoe lang het duurde om het model te laden wanneer het eindpunt in koude toestand werd aangeroepen. De statistiek wordt mogelijk niet altijd in het rapport weergegeven omdat een eindpunt in een warme staat wordt gelanceerd. EEN cold_start_delay para meter is beschikbaar voor het specificeren van het aantal seconden slaap voordat de benchmark wordt gestart op een geïmplementeerd eind punt. Als u deze parameter instelt op een hoger getal, zoals 600 seconden, wordt de kans op een aanroep van de koude toestand groter en is de kans groter dat deze statistiek wordt vastgelegd. Bovendien is het veel waarschijnlijker dat deze statistiek wordt vastgelegd met de benchmark voor gelijktijdige aanroep, die we later in deze sectie bespreken.

De volgende tabel toont de metrische gegevens die zijn vastgelegd door CloudWatch voor elke geheugenconfiguratie.

De volgende grafiek toont de prestatie- en kostenafwegingen van verschillende geheugenconfiguraties. Eén regel toont de geschatte kosten van het 1 miljoen keer aanroepen van het eindpunt, en de andere toont de gemiddelde latentie van reacties. Deze metrische gegevens kunnen u helpen beslissen welke eindpuntconfiguratie het meest kosteneffectief is. In dit voorbeeld zien we dat de gemiddelde latentie na 2048 MB afvlakt, terwijl de kosten blijven stijgen, wat aangeeft dat voor dit model een geheugenconfiguratie van 2048 het meest optimaal zou zijn.

Het uiteindelijke resultaat van de benchmark voor kosten en stabiliteit is een aanbevolen geheugenconfiguratie, samen met een tabel waarin de kosten van het gebruik van een serverloos eindpunt worden vergeleken met een vergelijkbare SageMaker-hostinginstantie. Op basis van de verzamelde gegevens heeft de tool vastgesteld dat de configuratie van 2048 MB de meest optimale is voor dit model. Hoewel de 3072-configuratie ongeveer 10 milliseconden betere latentie biedt, gaat dat gepaard met een kostenstijging van 30%, van $ 4.55 naar $ 5.95 per 1 miljoen verzoeken. Bovendien laat de output zien dat een serverloos eindpunt een besparing tot 88.72% zou opleveren ten opzichte van een vergelijkbare realtime hosting-instantie wanneer er minder dan 1 miljoen maandelijkse aanroepverzoeken zijn, en zelfs na 8.5 miljoen verzoeken een realtime eindpunt breekt.

Het tweede type benchmark is optioneel en test verschillende MaxConcurency instellingen onder verschillende verkeerspatronen. Deze benchmark wordt meestal uitgevoerd met de optimale MemorySizeInMB configuratie van de stabiliteitsbenchmark. De twee belangrijkste parameters voor deze benchmark is een lijst met: MaxConcurency instellingen om te testen, samen met een lijst met client-multipliers, die het aantal gesimuleerde gelijktijdige clients bepalen waarmee het eindpunt wordt getest.

Door bijvoorbeeld de concurrency_benchmark_max_conc parameter tot [4, 8] en concurrency_num_clients_multiplier tot [1, 1.5, 2] worden twee eindpunten gelanceerd: één met MaxConcurency van 4 en de andere 8. Elk eindpunt wordt vervolgens gebenchmarkt met een (MaxConcurency x multiplier) aantal gesimuleerde gelijktijdige clients, wat voor het eindpunt met een gelijktijdigheid van 4 zich vertaalt in testbenchmarks met 4, 6 en 8 gelijktijdige clients.

De eerste output van deze benchmark is een tabel met de latentiestatistieken, beperkingsuitzonderingen en transacties per seconde-statistieken (TPS) die aan elke MaxConcurrency configuratie met verschillende aantallen gelijktijdige clients. Deze statistieken helpen bij het bepalen van de juiste MaxConcurrency instelling om de verwachte verkeersbelasting af te handelen. In de volgende tabel kunnen we zien dat een eindpunt dat is geconfigureerd met een maximale gelijktijdigheid van 8, tot 16 gelijktijdige clients kon verwerken met slechts twee beperkingsuitzonderingen van de 2,500 aanroepen met een gemiddelde van 24 transacties per seconde.

De volgende reeks uitgangen biedt een grafiek voor elk MaxConcurrency instelling die de verdeling van latentie onder verschillende belastingen toont. In dit voorbeeld kunnen we zien dat een eindpunt met a MaxConcurrency instelling van 4 was in staat om met succes alle verzoeken te verwerken met maximaal 8 gelijktijdige clients met een minimale toename van de aanroeplatentie.

De uiteindelijke uitvoer biedt een tabel met CloudWatch-statistieken voor elk MaxConcurrency configuratie. In tegenstelling tot de vorige tabel die de verdeling van latentie voor elke geheugenconfiguratie toont, die mogelijk niet altijd de koude start toont ModelSetupTime statistiek, is het veel waarschijnlijker dat deze statistiek in deze tabel wordt weergegeven vanwege het grotere aantal aanroepverzoeken en een grotere MaxConcurrency.

Conclusie

In dit bericht hebben we de SageMaker Serverless Inference Benchmarking Toolkit geïntroduceerd en een overzicht gegeven van de configuratie en output. De tool kan u helpen een beter geïnformeerde beslissing te nemen met betrekking tot serverloze inferentie door verschillende configuraties te testen met realistische verkeerspatronen. Probeer de benchmarking-toolkit met uw eigen modellen om zelf de prestaties en kostenbesparingen te zien die u kunt verwachten door een serverloos eindpunt te implementeren. Raadpleeg de GitHub repo voor aanvullende documentatie en voorbeeldnotitieboekjes.

Extra middelen

Over de auteurs

Simon Zamarin is een AI / ML Solutions Architect die zich voornamelijk richt op het helpen van klanten om waarde uit hun data-assets te halen. In zijn vrije tijd brengt Simon graag tijd door met familie, leest hij sci-fi en werkt hij aan verschillende doe-het-zelfprojecten.

Dhawal Patel is Principal Machine Learning Architect bij AWS. Hij heeft met organisaties, variërend van grote ondernemingen tot middelgrote startups, gewerkt 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 om hoogwaardige modelinferentie op SageMaker te realiseren.

Rishabh Ray Chaudhury is een Senior Product Manager bij Amazon SageMaker, gericht op machine learning inferentie. Hij is gepassioneerd door het innoveren en bouwen van nieuwe ervaringen voor machine learning-klanten op AWS om hun workloads te helpen schalen. In zijn vrije tijd houdt hij van reizen en koken. Je vindt hem op LinkedIn.