Vi presenterar Amazon SageMaker Serverless Inference Benchmarking Toolkit

Amazon SageMaker Serverless Inference är ett specialbyggt inferensalternativ som gör det enkelt för dig att distribuera och skala modeller för maskininlärning (ML). Den tillhandahåller en betal-per-användningsmodell, som är idealisk för tjänster där slutpunktsanrop är sällsynta och oförutsägbara. Till skillnad från en realtidsvärdslutpunkt, som backas upp av en långvarig instans, tillhandahålls beräkningsresurser för serverlösa slutpunkter på begäran, vilket eliminerar behovet av att välja instanstyper eller hantera skalningspolicyer.

Följande högnivåarkitektur illustrerar hur en serverlös slutpunkt fungerar. En klient anropar en slutpunkt, som backas upp av AWS-hanterad infrastruktur.

Serverlösa slutpunkter är dock benägna att kallstarta i storleksordningen sekunder och är därför mer lämpade för intermittenta eller oförutsägbara arbetsbelastningar.

För att hjälpa till att avgöra om en serverlös slutpunkt är rätt distributionsalternativ ur ett kostnads- och prestandaperspektiv, har vi utvecklat SageMaker Serverless Inference Benchmarking Toolkit, som testar olika slutpunktskonfigurationer och jämför den mest optimala med en jämförbar realtidsvärdinstans.

I det här inlägget introducerar vi verktygslådan och ger en översikt över dess konfiguration och utgångar.

Lösningsöversikt

Du kan ladda ner verktygslådan och installera den från GitHub repo. Det är enkelt att komma igång: installera bara biblioteket, skapa en SageMaker modell, och ange namnet på din modell tillsammans med en JSON-radformaterad fil som innehåller en exempeluppsättning anropsparametrar, inklusive nyttolastkroppen och innehållstypen. En bekvämlighetsfunktion tillhandahålls för att konvertera en lista med exempel på anropsargument till en JSON-linjefil eller en pickle-fil för binära nyttolaster som bilder, video eller ljud.

Installera verktygslådan

Installera först benchmarking-biblioteket i din Python-miljö med hjälp av pip:

pip install sm-serverless-benchmarking

Du kan köra följande kod från en Amazon SageMaker Studio exempel, SageMaker anteckningsbok instans, eller någon instans med programmatisk åtkomst till AWS och lämpligt AWS identitets- och åtkomsthantering (IAM) behörigheter. De erforderliga IAM-behörigheterna finns dokumenterade i GitHub repo. För ytterligare vägledning och exempelpolicyer för IAM, se Hur Amazon SageMaker fungerar med IAM. Den här koden kör ett benchmark med en standarduppsättning parametrar på en modell som förväntar sig en CSV-ingång med två exempelposter. Det är en god praxis att tillhandahålla en representativ uppsättning exempel för att analysera hur slutpunkten presterar med olika nyttolaster.

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)

Dessutom kan du köra riktmärket som ett SageMaker-bearbetningsjobb, vilket kan vara ett mer tillförlitligt alternativ för längre riktmärken med ett stort antal anrop. Se följande kod:

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

Observera att detta kommer att medföra extra kostnader för att köra en ml.m5.large SageMaker Processing-instans under hela riktmärket.

Båda metoderna accepterar ett antal parametrar att konfigurera, till exempel en lista över minneskonfigurationer som ska jämföras och antalet gånger varje konfiguration kommer att anropas. I de flesta fall bör standardalternativen räcka som utgångspunkt, men hänvisa till GitHub repo för en komplett lista och beskrivningar av varje parameter.

Benchmarking-konfiguration

Innan du fördjupar dig i vad riktmärket gör och vilka utdata det producerar, är det viktigt att förstå några nyckelbegrepp när det gäller att konfigurera serverlösa slutpunkter.

Det finns två viktiga konfigurationsalternativ: MemorySizeInMB och MaxConcurrency. MemorySizeInMB konfigurerar mängden minne som allokeras till instansen och kan vara 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB eller 6144 MB. Antalet vCPU:er skalas också proportionellt mot mängden minne som allokerats. De MaxConcurrency parametern justerar hur många samtidiga förfrågningar en slutpunkt kan betjäna. Med en MaxConcurrency av 1 kan en serverlös slutpunkt endast behandla en enda begäran åt gången.

För att sammanfatta MemorySizeInMB parameter ger en mekanism för vertikal skalbarhet, vilket gör att du kan justera minne och beräkningsresurser för att tjäna större modeller, medan MaxConcurrency tillhandahåller en mekanism för horisontell skalbarhet, vilket gör att din slutpunkt kan behandla fler samtidiga förfrågningar.

Kostnaden för att driva en slutpunkt bestäms till stor del av minnesstorleken, och det finns ingen kostnad förknippad med att öka den maximala samtidigheten. Det finns dock en kontogräns per region för maximal samtidighet över alla slutpunkter. Hänvisa till SageMaker slutpunkter och kvoter för de senaste gränserna.

Benchmarking utgångar

Med tanke på detta är målet med benchmarking av en serverlös slutpunkt att bestämma den mest kostnadseffektiva och tillförlitliga minnesstorleksinställningen och den minsta max samtidighet som kan hantera dina förväntade trafikmönster.

Som standard kör verktyget två riktmärken. Det första är ett stabilitetsriktmärke, som distribuerar en slutpunkt för var och en av de angivna minneskonfigurationerna och anropar varje slutpunkt med de medföljande exempelnyttolasterna. Målet med detta riktmärke är att bestämma den mest effektiva och stabila MemorySizeInMB-inställningen. Riktmärket fångar anropslatenserna och beräknar den förväntade kostnaden per anrop för varje slutpunkt. Den jämför sedan kostnaden mot en liknande värdinstans i realtid.

När benchmarkingen är klar genererar verktyget flera utgångar i det angivna result_save_path katalog med följande katalogstruktur:

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

Smakämnen benchmarking_report katalogen innehåller en konsoliderad rapport med alla sammanfattande resultat som vi beskriver i det här inlägget. Ytterligare kataloger innehåller råa och mellanliggande utdata som du kan använda för ytterligare analyser. Referera till GitHub repo för en mer detaljerad beskrivning av varje utdataartefakt.

Låt oss undersöka några faktiska benchmarking-utgångar för en slutpunkt som tjänar en datorvision MobileNetV2 TensorFlow-modell. Om du vill återge det här exemplet, se exempel anteckningsböcker katalogen i GitHub-repo.

Den första utgången i den konsoliderade rapporten är en sammanfattande tabell som ger minimi-, medel-, medel- och maximal latensvärden för varje MemorySizeInMB lyckad konfiguration av minnesstorlek. Som visas i följande tabell är den genomsnittliga anropsfördröjningen (invocation_latency_mean) fortsatte att förbättras när minneskonfigurationen ökades till 3072 MB, men slutade förbättras därefter.

Utöver den beskrivande statistiken på hög nivå tillhandahålls ett diagram som visar fördelningen av latens som observerats från klienten för var och en av minneskonfigurationerna. Återigen kan vi observera att 1024 MB-konfigurationen inte är lika prestanda som de andra alternativen, men det finns inte någon väsentlig skillnad i prestanda i konfigurationer från 2048 och uppåt.

amazoncloudwatch mätvärden associerade med varje slutpunktskonfiguration tillhandahålls också. Ett nyckelmått här är ModelSetupTime, som mäter hur lång tid det tog att ladda modellen när ändpunkten anropades i kallt tillstånd. Mätvärdet kanske inte alltid visas i rapporten eftersom en slutpunkt lanseras i ett varmt tillstånd. A cold_start_delay parametern är tillgänglig för att ange antalet sekunder att vila innan riktmärket startas på en distribuerad slutpunkt. Om du ställer in den här parametern på ett högre antal, till exempel 600 sekunder, bör sannolikheten för en kall tillståndsanrop öka och chanserna att fånga detta mått ökar. Dessutom är det mycket mer sannolikt att detta mått fångas med riktmärket för samtidig anrop, som vi diskuterar senare i det här avsnittet.

Följande tabell visar mätvärdena som fångats av CloudWatch för varje minneskonfiguration.

Nästa diagram visar prestanda och kostnadsavvägningar för olika minneskonfigurationer. En rad visar den beräknade kostnaden för att anropa slutpunkten 1 miljon gånger, och den andra visar den genomsnittliga svarslatensen. Dessa mätvärden kan informera ditt beslut om vilken slutpunktskonfiguration som är mest kostnadseffektiv. I det här exemplet ser vi att den genomsnittliga latensen planar ut efter 2048 MB, medan kostnaden fortsätter att öka, vilket indikerar att för denna modell skulle en minnesstorlekskonfiguration på 2048 vara mest optimal.

Det slutliga resultatet av kostnads- och stabilitetsriktmärket är en rekommenderad minneskonfiguration, tillsammans med en tabell som jämför kostnaden för att driva en serverlös slutpunkt med en jämförbar SageMaker-värdinstans. Baserat på insamlade data, fastställde verktyget att 2048 MB-konfigurationen är den mest optimala för denna modell. Även om 3072-konfigurationen ger ungefär 10 millisekunder bättre latens, kommer det med en kostnadsökning på 30 %, från $4.55 till $5.95 per 1 miljon förfrågningar. Dessutom visar resultatet att en serverlös slutpunkt skulle ge besparingar på upp till 88.72 % mot en jämförbar värdinstans i realtid när det finns färre än 1 miljon månatliga anropsbegäranden, och bryter jämnt med en realtidsslutpunkt efter 8.5 miljoner förfrågningar.

Den andra typen av benchmark är valfri och testar olika MaxConcurency inställningar under olika trafikmönster. Detta riktmärke körs vanligtvis med det optimala MemorySizeInMB konfiguration från stabilitetsriktmärket. De två nyckelparametrarna för detta riktmärke är en lista över MaxConcurency inställningar att testa tillsammans med en lista över klientmultiplikatorer, som bestämmer antalet simulerade samtidiga klienter som slutpunkten testas med.

Till exempel genom att ställa in concurrency_benchmark_max_conc parameter till [4, 8] och concurrency_num_clients_multiplier till [1, 1.5, 2] startas två slutpunkter: en med MaxConcurency av 4 och de andra 8. Varje slutpunkt benchmarkeras sedan med en (MaxConcurency x multiplikator) antal simulerade samtidiga klienter, vilket för slutpunkten med en samtidighet på 4 översätts till belastningstestriktmärken med 4, 6 och 8 samtidiga klienter.

Den första utgången av detta riktmärke är en tabell som visar latensmätvärden, begränsningsundantag och transaktioner per sekund mätvärden (TPS) som är associerade med varje MaxConcurrency konfiguration med olika antal samtidiga klienter. Dessa mätvärden hjälper till att avgöra lämpligt MaxConcurrency inställning för att hantera den förväntade trafikbelastningen. I följande tabell kan vi se att en slutpunkt konfigurerad med en maximal samtidighet på 8 kunde hantera upp till 16 samtidiga klienter med endast två strypande undantag av 2,500 24 anrop som gjordes med i genomsnitt XNUMX transaktioner per sekund.

Nästa uppsättning utgångar tillhandahåller ett diagram för varje MaxConcurrency inställning som visar fördelningen av latens under olika belastningar. I det här exemplet kan vi se att en slutpunkt med a MaxConcurrency inställningen 4 kunde framgångsrikt behandla alla förfrågningar med upp till 8 samtidiga klienter med en minimal ökning av anropslatens.

Den slutliga utgången ger en tabell med CloudWatch-statistik för varje MaxConcurrency konfiguration. Till skillnad från föregående tabell som visar fördelningen av latens för varje minneskonfiguration, som kanske inte alltid visar kallstarten ModelSetupTime mått, är det mycket mer sannolikt att det här värdet visas i den här tabellen på grund av det större antalet anropsbegäranden och ett större MaxConcurrency.

Slutsats

I det här inlägget introducerade vi SageMaker Serverless Inference Benchmarking Toolkit och gav en översikt över dess konfiguration och utgångar. Verktyget kan hjälpa dig att fatta ett mer välgrundat beslut när det gäller serverlös slutledning genom att ladda olika konfigurationer med realistiska trafikmönster. Prova benchmarking-verktygslådan med dina egna modeller för att själv se vilken prestanda och kostnadsbesparing du kan förvänta dig genom att distribuera en serverlös slutpunkt. Vänligen se GitHub repo för ytterligare dokumentation och exempel på anteckningsböcker.

Ytterligare resurser

Om författarna

Simon Zamarin är en AI / ML-lösningsarkitekt vars huvudsakliga fokus är att hjälpa kunder att extrahera värde från sina datatillgångar. På sin fritid tycker Simon om att spendera tid med familjen, läsa sci-fi och arbeta med olika DIY-husprojekt.

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 datorseende domäner. Han hjälper kunder att uppnå högpresterande modellslutledning på SageMaker.

Rishabh Ray Chaudhury är en Senior Product Manager hos Amazon SageMaker, med fokus på maskininlärning. Han brinner för att förnya och bygga nya upplevelser för maskininlärningskunder på AWS för att hjälpa till att skala deras arbetsbelastning. På fritiden tycker han om att resa och laga mat. Du kan hitta honom på LinkedIn.