Verbetering van AI-inferentie: geavanceerde technieken en best practices

Wanneer het gaat om real-time AI-gedreven toepassingen zoals zelfrijdende auto’s of gezondheidsmonitoring, kan elke extra seconde die nodig is om een input te verwerken, ernstige gevolgen hebben. Real-time AI-toepassingen vereisen betrouwbare GPUs en verwerkingskracht, wat erg duur en kostbaar is geweest voor veel toepassingen – tot nu toe.

Door een optimalisatieproces voor inferentie te adopteren, kunnen bedrijven niet alleen de AI-efficiëntie maximaliseren, maar ook de energieverbruik en operationele kosten verlagen (tot 90%); de privacy en beveiliging verbeteren; en zelfs de tevredenheid van de klant verhogen.

Veelvoorkomende inferentieproblemen

Enkele van de meest voorkomende problemen waarmee bedrijven te maken krijgen bij het beheer van AI-efficiëntie, zijn onderbenutte GPU-clusters, standaard generieke modellen en een gebrek aan inzicht in de bijbehorende kosten.

Teams provisioneren vaak GPU-clusters voor piekbelasting, maar tussen 70 en 80 procent van de tijd zijn ze onderbenut omdat de workflows onevenwichtig zijn.

Bovendien kiezen teams standaard voor grote generieke modellen (GPT-4, Claude) zelfs voor taken die kunnen worden uitgevoerd op kleinere, goedkopere open-source modellen. De reden hiervoor is een gebrek aan kennis en een steile leercurve bij het bouwen van aangepaste modellen.

Ten slotte ontbreken bij ingenieurs vaak inzicht in de werkelijke kosten per verzoek, waardoor ze hoge rekeningen krijgen. Tools zoals PromptLayer, Helicone kunnen helpen om dit inzicht te bieden.

Door het ontbreken van controle over modelkeuze, batchen en benutting, kunnen de inferentiekosten exponentieel stijgen (tot 10 keer), waardoor resources verspild worden, de nauwkeurigheid beperkt wordt en de gebruikerservaring vermindert.

Energieverbruik en operationele kosten

Het uitvoeren van grotere LLM’s zoals GPT-4, Llama 3 70B of Mixtral-8x7B vereist aanzienlijk meer vermogen per token. Gemiddeld verbruikt 40 tot 50 procent van de energie die door een datacenter wordt gebruikt, de compute-apparatuur, en wordt 30 tot 40 procent besteed aan het koelen van de apparatuur.

Daarom is het voor een bedrijf dat inference 24/7 uitvoert, voordeliger om een on-premises-provider te overwegen in plaats van een cloud-provider, om te voorkomen dat ze een premiumprijs betalen en meer energie verbruiken.

Privacy en beveiliging

Volgens Cisco’s 2025 Data Privacy Benchmark Study, zijn “64% van de respondenten bezorgd over het onbewust delen van gevoelige informatie met het publiek of met concurrenten, maar bijna de helft geeft toe dat ze persoonlijke werknemer- of niet-publieke gegevens in GenAI-tools invoeren.” Dit verhoogt het risico op non-conformiteit als de gegevens onjuist worden gelogd of in de cache worden opgeslagen.

Een andere kans op risico is het uitvoeren van modellen over verschillende klantorganisaties op een gedeelde infrastructuur; dit kan leiden tot gegevenslekken en prestatieproblemen, en er is een extra risico dat de acties van een gebruiker andere gebruikers beïnvloeden. Daarom geven ondernemingen de voorkeur aan diensten die in hun eigen cloud worden geïmplementeerd.

Tevredenheid van de klant

Wanneer antwoorden langer dan een paar seconden duren om te verschijnen, laten gebruikers meestal af, waardoor ingenieurs overoptimale prestaties voor nul latentie nastreven. Bovendien presenteren toepassingen “obstakels zoals hallucinaties en onnauwkeurigheden die de brede impact en adoptie kunnen beperken”, volgens een Gartner-persbericht.

Bedrijfsvoordelen van het oplossen van deze problemen

Het optimaliseren van batchen, het kiezen van modellen van de juiste grootte (bijv. overschakelen van Llama 70B of gesloten bronmodellen zoals GPT naar Gemma 2B waar mogelijk) en het verbeteren van de benutting van de GPU, kan de inferentiekosten met 60 tot 80 procent verlagen. Het gebruik van tools zoals vLLM kan helpen, evenals het overschakelen naar een serverloze pay-as-you-go-model voor een spiky workflow.

Neem Cleanlab als voorbeeld. Cleanlab lanceerde de Trustworthy Language Model (TLM) om een betrouwbaarheidscore toe te voegen aan elke LLM-antwoord. Het is ontworpen voor hoge kwaliteit en verbeterde betrouwbaarheid, wat essentieel is voor ondernemingsapplicaties om ongecontroleerde hallucinaties te voorkomen. Voordat Inferless werd geïntroduceerd, ervoer Cleanlabs een toename van de GPU-kosten, omdat de GPUs zelfs draaiden wanneer ze niet actief werden gebruikt. Hun problemen waren typisch voor traditionele cloud-GPU-providers: hoge latentie, inefficiënt kostbeheer en een complexe omgeving om te beheren. Met serverloze inferentie verlaagden ze de kosten met 90 procent, terwijl ze de prestatieniveaus behielden. Bovendien gingen ze binnen twee weken live zonder extra engineeringskosten.

Optimaliseren van modelarchitectuur

Foundation-modellen zoals GPT en Claude worden vaak getraind voor generaliteit, niet voor efficiëntie of specifieke taken. Door open-source modellen niet aan te passen voor specifieke use-cases, verspillen bedrijven geheugen en verwerkingscapaciteit voor taken die deze schaal niet nodig hebben.

Nieuwere GPU-chips zoals H100 zijn snel en efficiënt. Deze zijn vooral belangrijk bij het uitvoeren van grote operaties zoals videogeneratie of AI-gerelateerde taken. Meer CUDA-kernen verhogen de verwerkingsnelheid en overtreffen kleinere GPUs; NVIDIA’s Tensor-kernen zijn ontworpen om deze taken te versnellen op grote schaal.

GPU-geheugen is ook belangrijk bij het optimaliseren van modelarchitectuur, omdat grote AI-modellen aanzienlijke ruimte vereisen. Deze extra geheugenruimte stelt de GPU in staat om grotere modellen uit te voeren zonder de snelheid te compromitteren. Omgekeerd lijdt de prestatie van kleinere GPUs met minder VRAM, omdat ze gegevens naar een langzamere systeem-RAM verplaatsen.

Enkele voordelen van het optimaliseren van modelarchitectuur zijn tijds- en geldbesparingen. Ten eerste kan het overschakelen van een dichte transformatie naar LoRA-geoptimaliseerde of FlashAttention-gebaseerde varianten tussen 200 en 400 milliseconden per query van de responstijd schrappen, wat cruciaal is in chatbots en gaming, bijvoorbeeld. Bovendien hebben gequantificeerde modellen (zoals 4-bit of 8-bit) minder VRAM nodig en draaien ze sneller op goedkopere GPUs.

Op lange termijn bespaart het optimaliseren van modelarchitectuur geld op inferentie, omdat geoptimaliseerde modellen kunnen worden uitgevoerd op kleinere chips.

Het optimaliseren van modelarchitectuur omvat de volgende stappen:

• Quantificatie — vermindering van precisie (FP32 → INT4/INT8), geheugen besparen en verwerkingscapaciteit versnellen
• Snoeien — verwijderen van minder nuttige gewichten of lagen (gestructureerd of ongestructureerd)
• Destillatie — trainen van een kleinere “student”-model om de output van een groter model na te bootsen

Modelgrootte comprimeren

Kleinere modellen betekenen snellere inferentie en minder dure infrastructuur. Grote modellen (13B+, 70B+) vereisen dure GPUs (A100s, H100s), hoge VRAM en meer vermogen. Het comprimeren ervan stelt ze in staat om te draaien op goedkopere hardware, zoals A10s of T4s, met veel lagere latentie.

Gecomprimeerde modellen zijn ook cruciaal voor het uitvoeren van inferentie op apparaten (telefoons, browsers, IoT), omdat kleinere modellen het mogelijk maken om meer gelijktijdige verzoeken te serveren zonder de infrastructuur te schalen. In een chatbot met meer dan 1.000 gelijktijdige gebruikers, kon een team door te schakelen van een 13B naar een 7B gecomprimeerd model, meer dan twee keer zoveel gebruikers per GPU serveren zonder latentiesprongen.

Gebruik van gespecialiseerde hardware

Algemene CPU’s zijn niet ontworpen voor tensoroperaties. Gespecialiseerde hardware zoals NVIDIA A100s, H100s, Google TPUs of AWS Inferentia kan snellere inferentie (tussen 10 en 100 keer) bieden voor LLM’s met betere energoefficiëntie. Het schrappen van zelfs 100 milliseconden per verzoek kan een verschil maken bij het verwerken van miljoenen verzoeken per dag.

Overweeg dit hypothetische voorbeeld:

Een team voert LLaMA-13B uit op standaard A10-GPUs voor hun interne RAG-systeem. De latentie is ongeveer 1,9 seconden en ze kunnen niet veel batchen vanwege VRAM-beperkingen. Ze schakelen over naar H100s met TensorRT-LLM, Enable FP8 en geoptimaliseerde aandachtkernel, en verhogen de batchgrootte van 8 naar 64. Het resultaat is het verlagen van de latentie tot 400 milliseconden met een vijfvoudige toename van de doorvoer.

Als gevolg hiervan kunnen ze vijf keer zoveel verzoeken serveren op hetzelfde budget en ingenieurs vrijmaken van het navigeren door infrastructuurbottlenecks.

Evaluatie van implementatieopties

Verschillende processen vereisen verschillende infrastructuur; een chatbot met 10 gebruikers en een zoekmachine die een miljoen queries per dag verwerkt, hebben verschillende behoeften. Alles in de cloud doen (bijv. AWS Sagemaker) of DIY-GPU-servers zonder de kosten-prestatieverhouding te evalueren, leidt tot verspilde uitgaven en een slechte gebruikerservaring. Houd er rekening mee dat als u zich vroeg commit aan een gesloten cloudprovider, het later migreren van de oplossing pijnlijk is. Echter, vroeg evalueren met een pay-as-you-go-structuur biedt opties voor later.

Evaluatie omvat de volgende stappen:

• Modellatentie en -kosten benchmarken over platforms: voer A/B-tests uit op AWS, Azure, lokale GPU-clusters of serverloze tools om te repliceren.
• Koude startprestaties meten: dit is vooral belangrijk voor serverloze of gebeurtenisgestuurde workloads, omdat modellen sneller laden.
• Observatie en schaalbeperkingen evalueren: beoordeel de beschikbare metrics en identificeer wat de maximale queries per seconde is voordat de prestaties afnemen.
• Compliancetoetsen ondersteunen: bepaal of u geo-gebonden gegevensregels of auditlogs kunt afdwingen.
• Totale eigendomskosten schatten. Dit moet GPU-uren, opslag, bandbreedte en overhead voor teams omvatten.

De bodemlijn

Inferentie stelt bedrijven in staat om hun AI-prestaties te optimaliseren, het energieverbruik en de kosten te verlagen, de privacy en beveiliging te behouden en de klanten tevreden te houden.