Realiseer low-latency hosting voor op beslissingsboom gebaseerde ML-modellen op NVIDIA Triton Inference Server op Amazon SageMaker

Machine learning (ML)-modelimplementaties kunnen tegenwoordig zeer veeleisende prestatie- en latentievereisten hebben voor bedrijven. Use cases zoals fraudedetectie en advertentieplaatsing zijn voorbeelden waarbij milliseconden ertoe doen en cruciaal zijn voor zakelijk succes. Er moet worden voldaan aan strikte Service Level Agreements (SLA's) en een typisch verzoek kan meerdere stappen vereisen, zoals voorverwerking, gegevenstransformatie, logica voor modelselectie, modelaggregatie en naverwerking. Op grote schaal betekent dit vaak het handhaven van een enorm verkeersvolume met behoud van een lage latentie. Veelvoorkomende ontwerppatronen zijn onder meer seriële inferentiepijplijnen, ensembles (scatter-gather) en zakelijke logica-workflows, die resulteren in het realiseren van de volledige workflow van het verzoek als een Directed Acyclic Graph (DAG). Naarmate workflows echter complexer worden, kan dit leiden tot een toename van de algehele responstijden, wat op zijn beurt een negatieve invloed kan hebben op de eindgebruikerservaring en de bedrijfsdoelen in gevaar kan brengen. Triton kan deze use-cases aanpakken waarbij meerdere modellen in een pijplijn zijn samengesteld met input- en outputtensoren ertussen, zodat u deze workloads kunt aanpakken.

Terwijl u uw doelen evalueert met betrekking tot de gevolgtrekking van ML-modellen, kunnen veel opties worden overwogen, maar weinigen zijn zo capabel en bewezen als Amazon Sage Maker Met Triton Inference-server. SageMaker met Triton Inference Server is voor veel klanten een populaire keuze geweest, omdat het speciaal is gebouwd om de doorvoer en het hardwaregebruik te maximaliseren met een ultralage (eencijferige milliseconden) inferentielatentie. Het heeft een breed scala aan ondersteunde ML-frameworks (inclusief TensorFlow, PyTorch, ONNX, XGBoost en NVIDIA TensorRT) en infrastructuur-backends, waaronder NVIDIA GPU's, CPU's en AWS Inferentie. Bovendien is Triton Inference Server geïntegreerd met SageMaker, een volledig beheerde end-to-end ML-service, die realtime inferentieopties biedt voor modelhosting.

In dit bericht lopen we door het implementeren van een fraudedetectie-ensemble-workload naar SageMaker met Triton Inference Server.

Overzicht oplossingen

Het is voor elk project essentieel om een ​​lijst met vereisten en een schatting van de inspanning te hebben om de totale kosten van het project te benaderen. Het is belangrijk om het rendement op investering (ROI) in te schatten dat de beslissing van een organisatie ondersteunt. Enkele overwegingen waarmee u rekening moet houden bij het verplaatsen van een werklast naar Triton:

Inschatting van de inspanningen is essentieel bij softwareontwikkeling en de meting ervan is vaak gebaseerd op onvolledige, onzekere en ruisrijke invoer. ML-workloads zijn niet anders. Meerdere factoren zijn van invloed op een architectuur voor ML-inferentie, waarvan sommige inclusief:

• Wachttijdbudget aan clientzijde – Het specificeert de maximaal acceptabele wachttijd voor een inferentierespons aan de clientzijde, gewoonlijk uitgedrukt in percentielen. Voor workloads die een latentiebudget van bijna tientallen milliseconden vereisen, kunnen netwerkoverdrachten duur worden, dus het gebruik van modellen aan de rand zou beter passen.
• Distributiegrootte gegevenslading – Laadvermogen, vaak aangeduid als bericht lichaam, zijn de verzoekgegevens die van de client naar het model worden verzonden, evenals de responsgegevens die van het model naar de client worden verzonden. De grootte van de payload heeft vaak een grote impact op de latency en moet in overweging worden genomen.
• Data formaat – Dit specificeert hoe de payload naar het ML-model wordt verzonden. Formaat kan door mensen worden gelezen, zoals JSON en CSV, maar er zijn ook binaire formaten, die vaak gecomprimeerd en kleiner zijn. Dit is een afweging tussen compressie-overhead en overdrachtsgrootte, wat betekent dat CPU-cycli en latentie worden toegevoegd om te comprimeren of te decomprimeren, om bytes te besparen die via het netwerk worden overgedragen. Dit bericht laat zien hoe u zowel JSON- als binaire indelingen kunt gebruiken.
• Softwarestack en componenten vereist – Een stapel is een verzameling componenten die samenwerken om een ​​ML-toepassing te ondersteunen, inclusief besturingssysteem, runtimes en softwarelagen. Triton wordt geleverd met ingebouwde populaire ML-frameworks, genaamd backends, zoals ONNX, TensorFlow, FIL, OpenVINO, native Python en andere. U kunt ook een aangepaste backend voor uw eigen componenten van eigen bodem. Dit bericht gaat over een XGBoost-model en gegevensvoorverwerking, die we migreren naar respectievelijk de door NVIDIA geleverde FIL- en Python Triton-backends.

Al deze factoren zouden een cruciale rol moeten spelen bij het evalueren van hoe uw workloads presteren, maar in dit geval concentreren we ons op het werk dat nodig is om uw ML-modellen te verplaatsen naar SageMaker met Triton Inference Server. In het bijzonder gebruiken we een voorbeeld van een fraudedetectie-ensemble dat is samengesteld uit een XGBoost-model met preprocessing-logica geschreven in Python.

NVIDIA Triton Inference-server

Triton Inference Server is vanaf de grond af ontworpen om teams in staat te stellen getrainde AI-modellen te implementeren, uit te voeren en te schalen vanuit elk framework op GPU- of CPU-gebaseerde infrastructuur. Bovendien is het geoptimaliseerd om hoogwaardige inferentie op schaal te bieden met functies zoals dynamische batching, gelijktijdige uitvoeringen, optimale modelconfiguratie, modelensemble en ondersteuning voor streaming-invoer.

In het volgende diagram ziet u een voorbeeld van een NVIDIA Triton-ensemble-pijplijn.

Workloads moeten rekening houden met de mogelijkheden die Triton biedt samen met SageMaker-hosting om de aangeboden voordelen te maximaliseren. Triton ondersteunt bijvoorbeeld zowel HTTP als a C-API, die zorgen voor flexibiliteit en optimalisatie van het laadvermogen wanneer dat nodig is. Zoals eerder vermeld, ondersteunt Triton verschillende populaire frameworks uit de doos, waaronder TensorFlow, PyTorch, ONNX, XGBoost en NVIDIA TensorRT. Deze frameworks worden ondersteund via Triton-backends, en in het zeldzame geval dat een backend uw use case niet ondersteunt, Met Triton kunt u uw eigen implementeren en eenvoudig integreren.

Het volgende diagram toont een voorbeeld van de NVIDIA Triton-architectuur.

NVIDIA Triton op SageMaker

SageMaker-hosting services zijn de reeks SageMaker-functies die zijn bedoeld om de implementatie en bediening van modellen te vergemakkelijken. Het biedt een verscheidenheid aan opties voor het eenvoudig implementeren, automatisch schalen, bewaken en optimaliseren van ML-modellen die zijn afgestemd op verschillende gebruikssituaties. Dit betekent dat u uw implementaties kunt optimaliseren voor alle soorten gebruikspatronen, van permanent en altijd beschikbaar met serverloze opties tot tijdelijke, langlopende of batch-inferentiebehoeften.

Onder de SageMaker-hostingparaplu bevindt zich ook de set SageMaker-inference Deep Learning Containers (DLC's), die voorverpakt zijn met de juiste modelserversoftware voor hun overeenkomstige ondersteunde ML-framework. Hierdoor kunt u hoge inferentieprestaties bereiken zonder modelserverconfiguratie, wat vaak het meest complexe technische aspect is van modelimplementatie en in het algemeen geen deel uitmaakt van de vaardigheden van een datawetenschapper. Triton-inferentieserver is nu Beschikbaar op SageMaker DLC's.

Dit brede scala aan opties, modulariteit en gebruiksgemak van verschillende serveerframes maakt SageMaker en Triton een krachtige match.

NVIDIA FIL-backend-ondersteuning

Met de 22.05 versie release van Triton, ondersteunt NVIDIA nu forest-modellen die zijn getraind door verschillende populaire ML-frameworks, waaronder XGBoost, LightGBM, Scikit-learn en cuML. Wanneer u de FIL-backend voor Triton gebruikt, moet u ervoor zorgen dat de modelartefacten die u verstrekt, worden ondersteund. FIL ondersteunt bijvoorbeeld: model_type xgboost, xgboost_json, lightgbmof treelite_checkpoint, wat aangeeft of het geleverde model respectievelijk in XGBoost binair formaat, XGBoost JSON-formaat, LightGBM-tekstformaat of Treelite binair formaat is.

Deze backend-ondersteuning is essentieel voor ons om in ons voorbeeld te gebruiken, omdat FIL XGBoost-modellen ondersteunt. De enige overweging die u moet controleren, is ervoor te zorgen dat het model dat we implementeren binaire of JSON-indelingen ondersteunt.

Naast ervoor te zorgen dat u over het juiste modelformaat beschikt, moeten er nog andere overwegingen worden overwogen. De FIL-backend voor Triton biedt configureerbare opties voor ontwikkelaars om hun workloads af te stemmen en de prestaties van modelruns te optimaliseren. De configuratie dynamic_batching stelt Triton in staat verzoeken aan de clientzijde vast te houden en deze aan de serverzijde te batchen, om op efficiënte wijze de parallelle berekening van FIL te gebruiken om de hele batch samen af ​​te leiden. De optie max_queue_delay_microseconds biedt een faalveilige controle over hoe lang Triton wacht om een ​​batch te vormen. FIL wordt geleverd met Shapley-uitleg, die kan worden geactiveerd door de configuratie treeshap_output; Houd er echter rekening mee dat Shapley-uitvoer de prestaties schaadt vanwege de uitvoergrootte. Een ander belangrijk aspect is: storage_type om een ​​afweging te maken tussen geheugenvoetafdruk en runtime. Het gebruik van opslag als SPARSE kan bijvoorbeeld het geheugenverbruik verminderen, terwijl DENSE de prestaties van uw modeluitvoering kan verminderen ten koste van een hoger geheugengebruik. Het bepalen van de beste keuze voor elk van deze hangt af van uw werklast en uw latentiebudget, dus we raden aan om alle opties in de Veelgestelde vragen over FIL-backend en lijst met beschikbare configuraties in FIL.

Stappen om een ​​model op triton te hosten

Laten we eens kijken naar onze use-case voor fraudedetectie als voorbeeld van waar u rekening mee moet houden bij het verplaatsen van een werklast naar Triton.

Identificeer uw werklast

In dit geval hebben we een fraudedetectiemodel dat wordt gebruikt tijdens het afrekenproces van een retailklant. De inferentiepijplijn gebruikt een XGBoost-algoritme met voorverwerkingslogica die gegevensvoorbereiding voor voorverwerking omvat.

Identificeer huidige en beoogde prestatiestatistieken en andere doelen die van toepassing kunnen zijn

Het kan zijn dat uw end-to-end inferentietijd te lang duurt om acceptabel te zijn. Uw doel zou kunnen zijn om van een latentie van tientallen milliseconden naar een latentie van één cijfer te gaan voor hetzelfde aantal verzoeken en dezelfde doorvoer. U bepaalt dat het grootste deel van de tijd wordt besteed aan de voorverwerking van gegevens en het XGBoost-model. Andere factoren, zoals de grootte van het netwerk en de payload, spelen een minimale rol in de overhead die gepaard gaat met de end-to-end-inferentietijd.

Werk achteruit om te bepalen of Triton uw werklast kan hosten op basis van uw vereisten

Om te bepalen of Triton aan uw eisen kan voldoen, wilt u aandacht besteden aan twee belangrijke aandachtspunten. De eerste is om ervoor te zorgen dat Triton kan dienen met een acceptabele front-endoptie zoals HTTP of C API.

Zoals eerder vermeld, is het ook van cruciaal belang om te bepalen of Triton een backend ondersteunt die uw artefacten kan dienen. Triton ondersteunt een aantal backends die op maat zijn gemaakt om verschillende frameworks zoals PyTorch en TensorFlow te ondersteunen. Controleer of uw modellen worden ondersteund en of u het juiste modelformaat heeft dat Triton verwacht. Kijk hiervoor eerst welke modelformaten de Triton-backend ondersteunt. Hiervoor zijn in veel gevallen geen aanpassingen aan het model nodig. In andere gevallen moet uw model mogelijk naar een andere indeling worden getransformeerd. Afhankelijk van het bron- en doelformaat zijn er verschillende opties, zoals het transformeren van een Python augurk-bestand om het binaire checkpoint-formaat van Treelite te gebruiken.

Voor deze use case bepalen we de FIL-backend het XGBoost-model kan ondersteunen zonder dat er wijzigingen nodig zijn en dat we de Python-backend voor de voorbewerking. Met de ensemble-functie van Triton kunt u uw werklast verder optimaliseren door dure netwerkgesprekken tussen hosting-instanties te vermijden.

Maak een plan en schat de inspanning die nodig is om Triton te gebruiken voor hosting

Laten we het hebben over het plan om je modellen naar Triton te verhuizen. Elke Triton-implementatie vereist het volgende:

• Modelartefacten vereist door Triton-backends
• Triton-configuratiebestanden
• Een modelrepositorymap met de juiste structuur

We laten later in dit bericht een voorbeeld zien van hoe u deze implementatieafhankelijkheden kunt maken.

Voer het plan uit en valideer de resultaten

Nadat u de vereiste bestanden en artefacten in de goed gestructureerde modelrepository hebt gemaakt, moet u uw implementatie afstemmen en testen om te valideren dat u nu uw doelstatistieken hebt bereikt.

Op dit punt kunt u SageMaker Inferentie Aanbeveling om te bepalen welk type endpoint-instantie het beste voor u is op basis van uw vereisten. Daarnaast biedt Triton tools om build-optimalisaties te maken om betere prestaties te krijgen.

Implementatie

Laten we nu eens kijken naar de implementatiedetails. Hiervoor hebben we twee notitieboekjes gemaakt die een voorbeeld geven van wat je kunt verwachten. De eerste notitieboekje toont de training van het gegeven XGBoost-model, evenals de voorverwerkingslogica die wordt gebruikt voor zowel training als inferentietijd. De tweede notitieboekje laat zien hoe we de artefacten voorbereiden die nodig zijn voor implementatie op Triton.

Het eerste notitieblok toont een bestaand notitieboek dat uw organisatie heeft en dat gebruikmaakt van de VERSNELLINGEN suite van bibliotheken en de RAPIDS Conda-kernel. Deze instantie draait op een G4DN-instantietype dat wordt geleverd door AWS, dat GPU-versneld is door NVIDIA T4-processors te gebruiken.

Voorverwerkingstaken in dit voorbeeld profiteren van GPU-versnelling en maken intensief gebruik van de cuML- en cuDF-bibliotheken. Een voorbeeld hiervan is in de volgende code, waar we categorische labelcodering laten zien met behulp van cuML. We genereren ook een label_encoders.pkl bestand dat we kunnen gebruiken om de encoders te serialiseren en ze te gebruiken voor voorverwerking tijdens de inferentietijd.

De eerste notebook wordt afgesloten door ons XGBoost-model te trainen en de artefacten dienovereenkomstig op te slaan.

In dit scenario bestond de trainingscode al en zijn er geen wijzigingen nodig voor het model tijdens de training. Bovendien, hoewel we GPU-versnelling hebben gebruikt voor voorverwerking tijdens de training, zijn we van plan CPU's te gebruiken voor voorverwerking op het moment van inferentie. Later in de post leggen we meer uit.

Laten we nu naar de tweede notebook gaan en ons herinneren wat we nodig hebben voor een succesvolle Triton-implementatie.

Ten eerste hebben we de modelartefacten nodig die nodig zijn voor backends. De bestanden die we voor dit ensemble moeten maken, zijn onder meer:

• Artefacten voorbewerken (model.py, label_encoders.pkl)
• XGBoost-modelartefacten (xgboost.json)

De Python-backend in Triton vereist dat we een Conda-omgeving als afhankelijkheid gebruiken. In dit geval gebruiken we de Python-backend om de onbewerkte gegevens voor te verwerken voordat ze worden ingevoerd in het XGBoost-model dat wordt uitgevoerd in de FIL-backend. Hoewel we oorspronkelijk RAPIDS cuDF- en cuML-bibliotheken gebruikten om de gegevensvoorverwerking uit te voeren (zoals eerder vermeld met behulp van onze GPU), gebruiken we hier Pandas en Scikit-learn als voorverwerkingsafhankelijkheden voor inferentietijd (met behulp van onze CPU). We doen dit om drie redenen:

• Om te laten zien hoe u een Conda-omgeving voor uw afhankelijkheden kunt maken en hoe u deze kunt verpakken in de formaat verwacht door Triton's Python-backend.
• Door het preprocessing-model te laten zien dat draait in de Python-backend op de CPU, terwijl het XGBoost-model draait op de GPU in de FIL-backend, illustreren we hoe elk model in de ensemble-pipeline van Triton op een andere framework-backend kan draaien en op verschillende hardware met verschillende configuraties.
• Het laat zien hoe de RAPIDS-bibliotheken (cuDF, cuML) compatibel zijn met hun CPU-tegenhangers (Pandas, Scikit-learn). Op deze manier kunnen we laten zien hoe LabelEncoders gemaakt in cuML kan worden gebruikt in Scikit-learn en vice versa. Houd er rekening mee dat als u verwacht grote hoeveelheden gegevens in tabelvorm voor te verwerken tijdens de inferentietijd, u RAPIDS nog steeds kunt gebruiken om het te versnellen met GPU.

Bedenk dat we de hebben gemaakt label_encoders.pkl bestand in het eerste notitieblok. Er is niets anders te doen voor categoriecodering dan deze op te nemen in onze model.py bestand voor voorbewerking.

Om het model.py-bestand te maken dat vereist is door de Triton Python-backend, houden we ons aan de formattering vereist door de backend en voeg onze Python-logica toe om de binnenkomende tensor te verwerken en gebruik de label-encoder waarnaar eerder werd verwezen. U kunt de bekijken filet gebruikt voor voorbewerking.

Voor het XGBoost-model hoeft er niets meer te worden gedaan. We hebben het model getraind in de eerste notebook en Triton's FIL-backend vereist geen extra inspanning voor XGBoost-modellen.

Vervolgens hebben we de Triton-configuratiebestanden nodig. Elk model in het Triton-ensemble vereist een config.pbtxt het dossier. Daarnaast maken we ook een config.pbtxt bestand voor het ensemble als geheel. Deze bestanden stellen Triton in staat om metadata over het ensemble te kennen met informatie zoals de inputs en outputs die we verwachten, evenals hulp bij het definiëren van de DAG die aan het ensemble is gekoppeld.

Ten slotte, om een ​​model op Triton te implementeren, hebben we onze modelrepository-map nodig om de juiste mappenstructuur te hebben. Triton heeft specifieke vereisten voor de lay-out van modelrepository's. Binnen de directory van de modelrepository op het hoogste niveau heeft elk model zijn eigen subdirectory met de informatie voor het corresponderende model. Elke modeldirectory in Triton moet ten minste één numerieke subdirectory hebben die een versie van het model vertegenwoordigt. Voor onze use case zou de resulterende structuur er als volgt uit moeten zien.

Nadat we aan deze drie vereisten hebben voldaan, maken we een gecomprimeerd bestand als verpakking voor implementatie en uploaden dit naar: Amazon eenvoudige opslagservice (Amazone S3).

We kunnen nu een SageMaker-model maken vanuit de modelrepository die we in de vorige stap naar Amazon S3 hebben geüpload.

In deze stap bieden we ook de extra omgevingsvariabele SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, die de naam specificeert van het model dat door Triton moet worden geladen. De waarde van deze sleutel moet overeenkomen met de mapnaam in het modelpakket dat is geüpload naar Amazon S3. Deze variabele is optioneel in het geval van een enkel model. In het geval van ensemble-modellen moet deze sleutel worden opgegeven om Triton in SageMaker te laten opstarten.

Bovendien kunt u instellen: SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT en SAGEMAKER_TRITON_THREAD_COUNT voor het optimaliseren van het aantal threads. Beide configuratiewaarden helpen bij het afstemmen van het aantal threads dat op uw CPU's wordt uitgevoerd, zodat u mogelijk beter gebruik kunt maken door deze waarden te verhogen voor CPU's met een groter aantal kernen. In de meeste gevallen werken de standaardwaarden vaak goed, maar het kan de moeite waard zijn om te experimenteren om te zien of er meer efficiëntie kan worden behaald voor uw workloads.

Met het voorgaande model maken we een eindpuntconfiguratie waarin we het type en aantal exemplaren kunnen specificeren dat we in het eindpunt willen.

Ten slotte gebruiken we de voorgaande eindpuntconfiguratie om een ​​nieuw SageMaker-eindpunt te maken en te wachten tot de implementatie is voltooid. De status verandert in InService nadat de implementatie is gelukt.

Dat is het! Uw eindpunt is nu klaar om te testen en te valideren. Op dit moment wilt u misschien verschillende hulpprogramma's gebruiken om uw instantietypen en configuratie te optimaliseren voor de best mogelijke prestaties. De volgende afbeelding geeft een voorbeeld van de winst die kan worden behaald door de FIL-backend te gebruiken voor een XGBoost-model op Triton.

Samengevat

In dit bericht hebben we u begeleid bij het implementeren van een XGBoost-ensemble-workload naar SageMaker met Triton Inference Server. Het verplaatsen van workloads naar Triton op SageMaker kan een gunstig rendement op uw investering opleveren. Zoals bij elke adoptie van technologie, zijn een doorlichtingsproces en -plan van cruciaal belang, en we hebben een proces in vijf stappen uitgewerkt om u te begeleiden bij wat u moet overwegen bij het verplaatsen van uw workloads. Daarnaast zijn we diep in de stappen gedoken die nodig zijn om een ​​ensemble te implementeren dat gebruikmaakt van Python-preprocessing en een XGBoost-model op Triton op SageMaker.

SageMaker biedt de tools om het ongedifferentieerde zware werk uit elke fase van de ML-levenscyclus te verwijderen, waardoor de snelle experimenten en verkenningen die nodig zijn om uw modelimplementaties volledig te optimaliseren, mogelijk worden gemaakt. SageMaker-hostingondersteuning voor Triton Inference Server maakt workloads met lage latentie en hoge transacties per seconde (TPS) mogelijk.

U vindt de notitieboekjes die voor dit voorbeeld zijn gebruikt op GitHub.

---

Over de auteur

James Park is Solutions Architect bij Amazon Web Services. Hij werkt met Amazon.com aan het ontwerpen, bouwen en implementeren van technologische oplossingen op AWS, en heeft een bijzondere interesse in AI en machine learning. In zijn vrije tijd gaat hij graag op zoek naar nieuwe culturen, nieuwe ervaringen en blijft hij op de hoogte van de laatste technologische trends.

Jiahong Liu is Solution Architect in het Cloud Service Provider-team van NVIDIA. Hij helpt klanten bij het adopteren van machine learning en AI-oplossingen die gebruikmaken van NVIDIA Accelerated Computing om hun trainings- en inferentie-uitdagingen aan te pakken. In zijn vrije tijd houdt hij van origami, doe-het-zelfprojecten en basketbal.

Kshitiz Gupta is Solutions Architect bij NVIDIA. Hij vindt het leuk om cloudklanten te informeren over de GPU AI-technologieën die NVIDIA te bieden heeft en hen te helpen bij het versnellen van hun machine learning en deep learning-applicaties. Naast zijn werk houdt hij van hardlopen, wandelen en het spotten van dieren in het wild.

Bruno Aguiar de Melo is een Software Development Engineer bij Amazon.com, waar hij wetenschappelijke teams helpt bij het bouwen, implementeren en vrijgeven van ML-workloads. Hij is geïnteresseerd in instrumentatie en beheersbare aspecten binnen de ML-modellerings-/ontwerpfase die moeten worden overwogen en gemeten met het inzicht dat de uitvoeringsprestaties van modellen net zo belangrijk zijn als de kwaliteit van het model, met name in gebruiksgevallen met beperkte latentie. In zijn vrije tijd houdt hij van wijn, bordspellen en koken.

Eliuth Triana is een Developer Relations Manager bij NVIDIA. Hij verbindt productleiders, ontwikkelaars en wetenschappers van Amazon en AWS met NVIDIA-technologen en productleiders om Amazon ML/DL-workloads, EC2-producten en AWS AI-services te versnellen. Daarnaast is Eliuth een gepassioneerd mountainbiker, skiër en pokerspeler.