Inferentie met meerdere modellen uitvoeren en optimaliseren met Amazon SageMaker-eindpunten voor meerdere modellen

Amazon Sage Maker multi-model endpoint (MME) stelt u in staat om op kosteneffectieve wijze meerdere modellen in een enkel eindpunt te implementeren en te hosten en vervolgens het eindpunt horizontaal te schalen om schaal te bereiken. Zoals in de volgende afbeelding wordt geïllustreerd, is dit een effectieve techniek om multitenancy van modellen te implementeren binnen uw machine learning (ML)-infrastructuur. We hebben gezien dat SaaS-bedrijven (Software as a Service) deze functie gebruiken om hyperpersonalisatie toe te passen in hun ML-modellen en tegelijkertijd lagere kosten te realiseren.

Voor een algemeen overzicht van hoe MME werkt, bekijk de AWS Summit-video ML naar het volgende niveau schalen: duizenden modellen hosten op SageMaker. Voor meer informatie over de hypergepersonaliseerde, multi-tenant use-cases die MME mogelijk maakt, raadpleegt u: Hoe machine learning-inferentie te schalen voor SaaS-gebruikscasussen met meerdere tenants.

In de rest van dit bericht duiken we dieper in de technische architectuur van SageMaker MME en delen we best practices voor het optimaliseren van uw multi-model endpoints.

Gebruiksscenario's die het meest geschikt zijn voor MME

SageMaker-eindpunten met meerdere modellen zijn zeer geschikt voor het hosten van een groot aantal modellen die u kunt bedienen via een gedeelde servercontainer en u hoeft niet alle modellen tegelijkertijd te openen. Afhankelijk van de grootte van het geheugen van het eindpunt, kan een model af en toe uit het geheugen worden verwijderd ten gunste van het laden van een nieuw model om efficiënt geheugengebruik te maximaliseren. Daarom moet uw toepassing tolerant zijn voor incidentele latentiepieken op niet-geladen modellen.

MME is ook ontworpen voor co-hosting van modellen die hetzelfde ML-framework gebruiken, omdat ze de gedeelde container gebruiken om meerdere modellen te laden. Daarom, als u een mix van ML-frameworks in uw modelvloot heeft (zoals PyTorch en TensorFlow), is SageMaker dedicated endpoints of multi-container hosting een betere keuze.

Ten slotte is MME geschikt voor toepassingen die af en toe een vertraging van een koude start kunnen verdragen, omdat modellen bij de eerste aanroep worden geladen en niet vaak gebruikte modellen uit het geheugen kunnen worden verwijderd ten gunste van het laden van nieuwe modellen. Als u dus een combinatie van vaak en weinig gebruikte modellen hebt, kan een eindpunt met meerdere modellen dit verkeer efficiënt bedienen met minder resources en hogere kostenbesparingen.

We hebben ook enkele scenario's gezien waarin klanten een MME-cluster inzetten met voldoende totale geheugencapaciteit om in al hun modellen te passen, waardoor modeloffloads helemaal worden vermeden en toch kostenbesparingen worden gerealiseerd vanwege de gedeelde inferentie-infrastructuur.

Model serveerbakken

Wanneer u de SageMaker Inference Toolkit of een vooraf gebouwd SageMaker-model voor het serveren van een container gebruikt die compatibel is met MME, heeft uw container de Server voor meerdere modellen (JVM-proces) actief. De eenvoudigste manier om Multi Model Server (MMS) in uw modelserving-container op te nemen, is door gebruik te maken van SageMaker model serveercontainers compatibel met MME (zoek naar die met Job Type=inference en CPU/GPU=CPU). MMS is een open source, gebruiksvriendelijke tool voor het aanbieden van deep learning-modellen. Het biedt een REST API met een webserver om meerdere modellen op één host te bedienen en te beheren. Het is echter niet verplicht om MMS te gebruiken; je zou je eigen modelserver kunnen implementeren zolang het de implementeert API's vereist door MME.

Bij gebruik als onderdeel van het MME-platform worden alle voorspellings-, laad- en ontlaad-API-aanroepen naar MMS of uw eigen modelserver gekanaliseerd via de MME-datavlakcontroller. API-aanroepen van de data plane-controller worden alleen via de lokale host gedaan om ongeautoriseerde toegang van buiten de instantie te voorkomen. Een van de belangrijkste voordelen van MMS is dat het een gestandaardiseerde interface mogelijk maakt voor het laden, lossen en oproepen van modellen met compatibiliteit met een breed scala aan deep learning-frameworks.

Geavanceerde configuratie van MMS

Als u ervoor kiest om MMS te gebruiken voor modelserving, overweeg dan de volgende geavanceerde configuraties om de schaalbaarheid en doorvoer van uw MME-instanties te optimaliseren.

Verhoog de parallelliteit van gevolgtrekkingen per model

MMS maakt een of meer Python-werkprocessen per model op basis van de waarde van de standaard_werknemers_per_model configuratieparameter. Deze Python-workers behandelen elk individueel verzoek tot gevolgtrekking door alle preprocessing-, voorspellings- en postverwerkingsfuncties uit te voeren die u verstrekt. Voor meer informatie, zie de aangepaste service handler GitHub-opslagplaats.

Het hebben van meer dan één modelwerker vergroot het parallellisme van voorspellingen die door een bepaald model kunnen worden gediend. Wanneer echter een groot aantal modellen wordt gehost op een instantie met een groot aantal CPU's, moet u een belastingstest van uw MME uitvoeren om de optimale waarde voor default_workers_per_model om uitputting van geheugen of CPU-bronnen te voorkomen.

Ontwerp voor verkeerspieken

Elk MMS-proces binnen een eindpuntinstantie heeft een aanvraagwachtrij die kan worden geconfigureerd met de job_queue_size parameter (standaard is 100). Dit bepaalt het aantal verzoeken dat MMS in de wachtrij plaatst wanneer alle werkprocessen bezet zijn. Gebruik deze parameter om de reactiesnelheid van uw endpoint-instanties te verfijnen nadat u het optimale aantal werkers per model hebt bepaald.

In een optimale verhouding werknemer per model, zou de standaardwaarde van 100 in de meeste gevallen voldoende moeten zijn. Voor die gevallen waarin verzoekverkeer naar het eindpunt ongebruikelijk piekt, kunt u de grootte van de wachtrij verkleinen als u wilt dat het eindpunt niet snel de controle doorgeeft aan de toepassing of de wachtrij vergroten als u wilt dat het eindpunt de piek absorbeert .

Maximaliseer geheugenbronnen per instantie

Bij gebruik van meerdere werkprocessen per model, laadt elk werkproces standaard zijn eigen kopie van het model. Dit kan het beschikbare exemplaargeheugen voor andere modellen verminderen. U kunt het geheugengebruik optimaliseren door een enkel model tussen werkprocessen te delen door de configuratieparameter in te stellen preload_model=waar. Hier ruilt u verminderd parallellisme in inferentie (vanwege een enkele modelinstantie) met meer geheugenefficiëntie. Deze instelling, samen met meerdere werkprocessen, kan een goede keuze zijn voor gebruiksgevallen waarbij de modellatentie laag is, maar u zwaardere voor- en naverwerking (gedaan door de werkprocessen) per gevolgtrekkingsverzoek hebt.

Waarden instellen voor geavanceerde MMS-configuraties

MMS gebruikt een bestand config.properties om configuraties op te slaan. MMS gebruikt de volgende volgorde om dit config.properties-bestand te zoeken:

1. Indien de MMS_CONFIG_FILE omgevingsvariabele is ingesteld, laadt MMS de configuratie van de omgevingsvariabele.
2. Indien de --mms-config parameter wordt doorgegeven aan MMS, laadt het de configuratie van de parameter.
3. Als er een config.properties in de huidige map waar de gebruiker MMS start, laadt het de config.properties bestand uit de huidige werkdirectory.

Als geen van het bovenstaande is opgegeven, laadt MMS de ingebouwde configuratie met standaardwaarden.

Het volgende is een voorbeeld van een opdrachtregel van het starten van MMS met een expliciet configuratiebestand:

multi-model-server --start --mms-config /home/mms/config.properties

Belangrijkste statistieken om de prestaties van uw eindpunt te bewaken

De belangrijkste statistieken die u kunnen helpen bij het optimaliseren van uw MME, zijn meestal gerelateerd aan het CPU- en geheugengebruik en de latentie van gevolgtrekkingen. De metrische gegevens op instantieniveau worden verzonden door MMS, terwijl de latentiestatistieken afkomstig zijn van de MME. In deze sectie bespreken we de typische statistieken die u kunt gebruiken om uw MME te begrijpen en te optimaliseren.

Statistieken op eindpuntinstantieniveau (MMS-statistieken)

Van de lijst met MMS-statistieken, CPUUtilization en MemoryUtilization kunnen u helpen evalueren of uw instantie of het MME-cluster de juiste grootte heeft. Als beide statistieken percentages tussen 50-80% hebben, heeft uw MME de juiste maat.

Doorgaans is een laag CPU-gebruik en een hoog geheugengebruik een indicatie van een over-provisioned MME-cluster, omdat dit aangeeft dat niet vaak aangeroepen modellen niet worden verwijderd. Dit kan zijn vanwege een hoger dan optimaal aantal eindpuntinstanties dat is ingericht voor de MME en daarom is er een hoger dan optimaal totaalgeheugen beschikbaar voor modellen die niet vaak worden gebruikt om in het geheugen te blijven. Omgekeerd betekent bijna 100% gebruik van deze metrische gegevens dat uw cluster onvoldoende is ingericht, dus u moet uw beleid voor automatisch schalen van clusters aanpassen.

Statistieken op platformniveau (MME-statistieken)

Van de volledige lijst met MME-statistieken, een belangrijke statistiek die u kan helpen de latentie van uw inferentieverzoek te begrijpen, is ModelCacheHit. Deze statistiek toont de gemiddelde verhouding van aanroepverzoeken waarvoor het model al in het geheugen is geladen. Als deze verhouding laag is, geeft dit aan dat uw MME-cluster onvoldoende is ingericht omdat er waarschijnlijk niet genoeg totale geheugencapaciteit in het MME-cluster is voor het aantal unieke modelaanroepen, waardoor modellen vaak uit het geheugen worden verwijderd.

Lessen uit het veld en strategieën voor het optimaliseren van MME

We hebben de volgende aanbevelingen gezien van enkele van de grootschalige toepassingen van MME bij een aantal klanten.

Horizontaal schalen met kleinere instanties is beter dan verticaal schalen met grotere instanties

Mogelijk ondervindt u beperking van modelaanroepen bij het uitvoeren van hoge verzoeken per seconde (RPS) op minder eindpuntinstanties. Er zijn interne limieten voor het aantal aanroepen per seconde (laad- en losbewerkingen die gelijktijdig op een instantie kunnen plaatsvinden), en daarom is het altijd beter om een ​​groter aantal kleinere instanties te hebben. Als u een groter aantal kleinere instanties uitvoert, betekent dit een hogere totale totale capaciteit van deze limieten voor het eindpunt.

Een ander voordeel van horizontaal schalen met kleinere instanties is dat u het risico verkleint dat de CPU- en geheugenbronnen van de instantie worden uitgeput bij het uitvoeren van MMS met hogere niveaus van parallellisme, samen met een groter aantal modellen in het geheugen (zoals eerder in dit bericht beschreven).

Geselen vermijden is een gedeelde verantwoordelijkheid

Slaan in MME is wanneer modellen vaak uit het geheugen worden verwijderd en opnieuw worden geladen vanwege onvoldoende geheugen, hetzij in een individuele instantie of op aggregaat in het cluster.

Vanuit een gebruiksperspectief moet u de individuele endpoint-instances op de juiste grootte en de totale grootte van het MME-cluster op de juiste grootte zetten om ervoor te zorgen dat er voldoende geheugencapaciteit beschikbaar is per instance en ook voor het cluster voor uw gebruiksgeval. De routervloot van het MME-platform zal ook de cachehit maximaliseren.

Wees niet agressief met het inpakken van te veel modellen op minder, grotere geheugeninstanties

Geheugen is niet de enige bron op de instantie waarvan u op de hoogte moet zijn. Andere bronnen zoals CPU kunnen een beperkende factor zijn, zoals te zien is in de volgende testresultaten. In sommige andere gevallen hebben we ook andere kernelbronnen waargenomen, zoals proces-ID's die op een instantie zijn uitgeput, vanwege een combinatie van te veel modellen die worden geladen en het onderliggende ML-framework (zoals TensorFlow) dat per model threads voortbrengt die veelvouden waren van beschikbare vCPU's.

De volgende prestatietest toont een voorbeeld van CPU-beperking die van invloed is op de latentie van het model. In deze test produceerde een enkel exemplaar-eindpunt met een groot exemplaar, terwijl het meer dan genoeg geheugen had om alle vier de modellen in het geheugen te houden, relatief slechtere modellatenties onder belasting in vergelijking met een eindpunt met vier kleinere exemplaren.

latentie van enkelvoudig eindpuntmodel

CPU- en geheugengebruik van één instantie eindpunt

latentie van het eindpuntmodel van vier instanties

vier instanties eindpunt CPU & geheugengebruik

Om zowel prestaties als kostenefficiëntie te bereiken, moet u uw MME-cluster de juiste grootte geven met een groter aantal kleinere instanties die u in totaal de optimale geheugen- en CPU-capaciteit geven, terwijl u relatief goedkoop bent met minder maar grotere geheugeninstanties.

Mentaal model voor het optimaliseren van MME

Er zijn vier belangrijke statistieken waarmee u altijd rekening moet houden bij het bepalen van de juiste maat voor uw MME:

• Het aantal en de grootte van de modellen
• Het aantal unieke modellen dat op een bepaald moment wordt aangeroepen
• Het instantietype en de grootte
• Het aantal exemplaren achter het eindpunt

Begin met de eerste twee punten, omdat ze de derde en vierde informeren. Als er zich bijvoorbeeld niet genoeg instanties achter het eindpunt bevinden voor het aantal of de grootte van de unieke modellen die u heeft, zal het totale geheugen voor het eindpunt laag zijn en ziet u een lagere cache-hitratio en geselen op het eindpuntniveau omdat de MME zal regelmatig modellen in en uit het geheugen laden en verwijderen.

Evenzo, als de aanroepen voor unieke modellen hoger zijn dan het totale geheugen van alle instanties achter het eindpunt, ziet u een lagere cachehit. Dit kan ook gebeuren als de omvang van instances (met name de geheugencapaciteit) te klein is.

Verticaal schalen met echt grote geheugeninstanties kan ook tot problemen leiden, want hoewel de modellen in het geheugen passen, kunnen andere bronnen zoals CPU- en kernelprocessen en threadlimieten uitgeput raken. Laad test horizontale schaling in pre-productie om het optimale aantal en de grootte van instanties voor uw MME te krijgen.

Samengevat

In dit bericht heb je een dieper inzicht gekregen in het MME-platform. Je hebt geleerd voor welke technische use cases MME geschikt is en je hebt de architectuur van het MME-platform bekeken. Je hebt een dieper inzicht gekregen in de rol van elk onderdeel binnen de MME-architectuur en van welke onderdelen je direct invloed kunt uitoefenen op de prestaties. Ten slotte heeft u dieper ingegaan op de configuratieparameters die u kunt aanpassen om MME te optimaliseren voor uw gebruiksscenario en de metrische gegevens die u moet controleren om optimale prestaties te behouden.

Om aan de slag te gaan met MME, review Amazon SageMaker Multi-Model Endpoints met XGBoost en Host meerdere modellen in één container achter één eindpunt.

Over de auteur

Syed Jaffry is Principal Solutions Architect bij AWS. Hij werkt met een reeks bedrijven van middelgrote organisaties, grote ondernemingen, financiële diensten en ISV's om hen te helpen kostenefficiënte en schaalbare AI/ML-applicaties in de cloud te bouwen en te exploiteren.

Saurabh Trikande is Senior Product Manager voor Amazon SageMaker Inference. Hij heeft een passie voor het werken met klanten en wordt gemotiveerd door het doel om machine learning te democratiseren. Hij richt zich op kernuitdagingen met betrekking tot het inzetten van complexe ML-applicaties, multi-tenant ML-modellen, kostenoptimalisaties en het toegankelijker maken van de inzet van deep learning-modellen. In zijn vrije tijd houdt Saurabh van wandelen, leren over innovatieve technologieën, TechCrunch volgen en tijd doorbrengen met zijn gezin.