Förbättring av AI-inferens: Avancerade tekniker och bästa praxis

När det gäller realtidsbaserade AI-drivna applikationer som självkörande bilar eller hälsovårdövervakning, kan en extra sekund för att bearbeta en inmatning ha allvarliga konsekvenser. Realtidsbaserade AI-applikationer kräver tillförlitliga GPU:er och bearbetningskraft, vilket har varit mycket dyrt och kostnadsförbjudande för många applikationer – tills nu.

Genom att anta en optimerad inferensprocess kan företag inte bara maximera AI-effektiviteten, utan också minska energiförbrukning och driftskostnader (med upp till 90%); förbättra sekretess och säkerhet; och sogar förbättra kundnöjdheten.

Vanliga inferensproblem

Några av de vanligaste problemen som företag står inför när det gäller att hantera AI-effektivitet inkluderar outnyttjade GPU-kluster, standard till allmänna modeller och brist på insikt i associerade kostnader.

Team tilldelar ofta GPU-kluster för toppbelastning, men mellan 70 och 80 procent av tiden är de outnyttjade på grund av ojämn arbetsflöde.

Dessutom väljer team standard till stora allmänna modeller (GPT-4, Claude) även för uppgifter som kan köras på mindre, billigare öppen källkodsmodeller. Anledningarna? En brist på kunskap och en brant inlärningskurva med att bygga anpassade modeller.

Slutligen saknar ingenjörer vanligtvis insikt i den faktiska kostnaden för varje begäran, vilket leder till dyra räkningar. Verktyg som PromptLayer, Helicone kan hjälpa till att ge denna insikt.

Med brist på kontroll över modellval, batchning och utnyttjande kan inferenskostnader öka exponentiellt (med upp till 10 gånger), slösa resurser, begränsa noggrannhet och försämra användarupplevelsen.

Energiförbrukning och driftskostnader

Att köra större LLM:er som GPT-4, Llama 3 70B eller Mixtral-8x7B kräver avsevärt mer kraft per token. I genomsnitt utgör 40 till 50 procent av den energi som används av ett datacenter den energi som krävs för att driva datorkomponenter, med ytterligare 30 till 40 procent av energin tilldelad för att kyla utrustningen.

Därför är det för ett företag som kör inferens i realtid dygnet runt mer fördelaktigt att överväga en lokal leverantör i stället för en molntjänstleverantör för att undvika att betala en premiumkostnad och förbruka mer energi.

Sekretess och säkerhet

Enligt Ciscos 2025 Data Privacy Benchmark Study, “64% av respondenterna är oroliga för att oavsiktligt dela känslig information offentligt eller med konkurrenter, men nästan hälften medger att de matar in personlig anställd eller icke-offentlig data i GenAI-verktyg.” Detta ökar risken för bristande regelefterlevnad om datan loggas eller cachelagras på ett olämpligt sätt. En annan möjlighet till risk är att köra modeller över olika kundorganisationer på en delad infrastruktur; detta kan leda till dataintrång och prestandaproblem, och det finns en ökad risk för att en användares åtgärder påverkar andra användare. Företag föredrar därför vanligtvis tjänster som distribueras i deras moln.

Kundnöjdhet

När svar tar mer än några sekunder att visas, hoppar användare vanligtvis av, vilket stöder ingenjörernas ansträngningar att överoptimera för noll fördröjning. Dessutom presenterar applikationer “hinder som hallucinationer och felaktigheter som kan begränsa den breda påverkan och antagandet”, enligt en Gartner-pressmeddelande.

Företagsfördelar med att hantera dessa problem

Att optimera batchning, välja rätt storleksmodeller (t.ex. byta från Llama 70B eller slutna källkodsmodeller som GPT till Gemma 2B där det är möjligt) och förbättra GPU-utnyttjande kan minska inferensräkningarna med mellan 60 och 80 procent. Att använda verktyg som vLLM kan hjälpa, liksom att byta till en serverlös betala-per-användningsmodell för ett spikigt arbetsflöde.

Ta Cleanlab som exempel. Cleanlab lanserade Trustworthy Language Model (TLM) för att lägga till en tillförlitlighetspoäng till varje LLM-svar. Det är utformat för högkvalitativa utdata och förbättrad tillförlitlighet, vilket är avgörande för företagsapplikationer för att förhindra oövervakade hallucinationer. Innan Inferless upplevde Cleanlabs ökade GPU-kostnader, eftersom GPU:er kördes även när de inte användes aktivt. Deras problem var typiska för traditionella molnbaserade GPU-leverantörer: hög latens, ineffektiv kostnadshantering och en komplex miljö att hantera. Med serverlös inferens minskade de kostnaderna med 90 procent samtidigt som de upprätthöll prestandanivåerna. Viktigare var att de gick live inom två veckor utan några extra ingenjörsöverhuvudkostnader.

Optimering av modellarkitektur

Grundmodeller som GPT och Claude är ofta utbildade för allmänhet, inte effektivitet eller specifika uppgifter. Genom att inte anpassa öppen källkodsmodeller för specifika användningsfall slösar företag bort minne och beräkningstid för uppgifter som inte behöver den skalan.

Nya GPU-chippar som H100 är snabba och effektiva. Dessa är särskilt viktiga när man kör stora skalaoperationer som videogenerering eller AI-relaterade uppgifter. Fler CUDA-kärnor ökar bearbetningshastigheten, överträffar mindre GPU:er; NVIDIA:s Tensor-kärnor är utformade för att accelerera dessa uppgifter i skala.

GPU-minne är också viktigt för att optimera modellarkitektur, eftersom stora AI-modeller kräver betydande utrymme. Detta extra minne möjliggör för GPU:en att köra större modeller utan att kompromissa med hastigheten. Omvänt lider prestandan för mindre GPU:er som har mindre VRAM, eftersom de flyttar data till en långsammare system-RAM.

Flera fördelar med att optimera modellarkitektur inkluderar tids- och pengabesparingar. Först kan man genom att byta från täta transformerare till LoRA-optimerade eller FlashAttention-baserade varianter skära av mellan 200 och 400 millisekunder från svarstiden per fråga, vilket är avgörande i chattbotar och spel, till exempel. Dessutom behöver kvantifierade modeller (som 4-bitars eller 8-bitars) mindre VRAM och körs snabbare på billigare GPU:er.

På lång sikt sparar optimering av modellarkitektur pengar på inferens, eftersom optimerade modeller kan köras på mindre chip.

Optimering av modellarkitektur omfattar följande steg:

• Kvantifiering — minskning av precision (FP32 → INT4/INT8), sparar minne och påskyndar beräkningstid
• Beskärning — borttagning av mindre användbara vikter eller lager (strukturerade eller ostrukturerade)
• Destillering — utbildning av en mindre “elev”-modell för att härma utdata från en större

Komprimering av modellstorlek

Mindre modeller betyder snabbare inferens och mindre dyra infrastrukturer. Stora modeller (13B+, 70B+) kräver dyra GPU:er (A100, H100), hög VRAM och mer kraft. Komprimering av dem möjliggör att de kan köras på billigare hårdvara, som A10 eller T4, med mycket lägre latens.

Komprimerade modeller är också avgörande för att köra på enheten (telefoner, webbläsare, IoT) inferens, eftersom mindre modeller möjliggör tjänsten av fler samtidiga förfrågningar utan att skala upp infrastrukturen. I en chattbot med mer än 1 000 samtidiga användare gjorde övergången från en 13B till en 7B-komprimerad modell att teamet kunde betjäna mer än dubbelt så många användare per GPU utan latensspikar.

Användning av specialiserad hårdvara

Allmänna CPU:er är inte utformade för tensoroperationer. Specialiserad hårdvara som NVIDIA A100, H100, Google TPUs eller AWS Inferentia kan erbjuda snabbare inferens (mellan 10 och 100 gånger) för LLM:er med bättre energieffektivitet. Att skära av även 100 millisekunder per begäran kan göra en skillnad när man bearbetar miljontals begäranden dagligen.

Överväg detta hypotetiska exempel:

Ett team kör LLaMA-13B på standard A10-GPU:er för sitt interna RAG-system. Latensen är runt 1,9 sekunder, och de kan inte batcha mycket på grund av VRAM-begränsningar. Så de byter till H100 med TensorRT-LLM, aktiverar FP8 och optimerad uppmärksamhetskernel, ökar batchstorleken från åtta till 64. Resultatet är att skära ner latensen till 400 millisekunder med en femfaldig ökning av genomströmningen.
Som ett resultat kan de betjäna begäranden fem gånger på samma budget och frigöra ingenjörer från att navigera i infrastrukturflaskhalsar.

Utvärdering av distributionsalternativ

Olika processer kräver olika infrastrukturer; en chattbot med 10 användare och en sökmotor som betjänar en miljon frågor per dag har olika behov. Att gå all-in på molnet (t.ex. AWS Sagemaker) eller DIY-GPU-servrar utan att utvärdera kostnad-prestandaförhållanden leder till slösad utgift och dålig användarupplevelse. Observera att om du åtar dig en molntjänstleverantör i förväg är det smärtsamt att migrera lösningen senare. Men att utvärdera tidigt med en betala-per-användningsstruktur ger dig alternativ längre fram.

Utvärdering omfattar följande steg:

• Benchmark modelllatens och kostnad över plattformar: Kör A/B-tester på AWS, Azure, lokala GPU-kluster eller serverlösa verktyg för att replikera.
• Mät kallstartprestanda: Detta är särskilt viktigt för serverlösa eller händelsestyrda arbetsflöden, eftersom modeller laddas snabbare.
• Utvärdera observerbarhet och skalningsbegränsningar: Utvärdera tillgängliga mått och identifiera vad den maximala frågefrekvensen per sekund är innan degradering.
• Kontrollera regelefterlevnadsstöd: Bestäm om du kan verkställa geobundna dataregler eller granskningsloggar.
• Uppskatta den totala ägandekostnaden. Detta bör inkludera GPU-timmar, lagring, bandbredd och overhead för team.

Slutsatsen

Inferens möjliggör för företag att optimera sin AI-prestanda, minska energiförbrukning och kostnader, upprätthålla sekretess och säkerhet och hålla kunder nöjda.