Forbedring af AI-inferens: Avancerede teknikker og bedste praksis

Når det kommer til realtids AI-drevne applikationer som selvkørende biler eller sundhedsmonitorering, kan selv et ekstra sekund til at behandle en input have alvorlige konsekvenser. Realtime AI-applikationer kræver pålidelige GPU’er og processorkraft, hvilket har været meget dyrt og omkostningsprohibiterende for mange applikationer – indtil nu.

Ved at antage en optimeret inferensproces kan virksomheder ikke kun maksimere AI-effektivitet; de kan også reducere energiforbrug og driftsomkostninger (op til 90%); forbedre privatliv og sikkerhed; og endda forbedre kundetilfredshed.

Almindelige inferensproblemer

Nogle af de mest almindelige problemer, som virksomheder står over for, når det kommer til at håndtere AI-effektivitet, omfatter underudnyttede GPU-kluster, standard til generelle formål modeller og mangel på indsigt i tilhørende omkostninger.

Holdene provisionerer ofte GPU-kluster for peak belastning, men mellem 70 og 80 procent af tiden er de underudnyttede på grund af uregelmæssige arbejdsprocesser.

Derudover vælger holdene standard til store generelle formål modeller (GPT-4, Claude) selv for opgaver, der kunne køre på mindre, billigere open source-modeller. Årsagen? Mangel på viden og en stejl læringskurve med opbygning af brugerdefinerede modeller.

Endelig mangler ingeniørerne typisk indsigt i den reelle omkostning for hver anmodning, hvilket fører til store regninger. Værktøjer som PromptLayer, Helicone kan hjælpe med at give denne indsigt.

Med mangel på kontroller over modelvalg, batchning og udnyttelse kan inferensomkostninger stige eksponentielt (op til 10 gange), spilde ressourcer, begrænse nøjagtighed og formindske brugeroplevelsen. 

Energiforbrug og driftsomkostninger

Kørsel af større LLM’er som GPT-4, Llama 3 70B eller Mixtral-8x7B kræver betydeligt mere kraft pr. token. I gennemsnit udgør 40 til 50 procent af den energi, der bruges af et datacenter, computing-udstyr, med yderligere 30 til 40 procent til afkøling af udstyret.

Derfor er det for en virksomhed, der kører rundt om uret for inferens i stor skala, mere fordelagtigt at overveje en on-premises-udbyder i stedet for en cloud-udbyder for at undgå at betale en premiumpris og forbruge mere energi.

Privatliv og sikkerhed

Ifølge Cisco’s 2025 Data Privacy Benchmark Study, “64% af respondentende bekymrer sig om ufrivilligt at dele følsomme oplysninger offentligt eller med konkurrenter, men næsten halvdelen indrømmer at indtaste personlige medarbejder- eller ikke-offentlige data i GenAI-værktøjer.” Dette øger risikoen for non-compliance, hvis dataene ikke er logget eller cachelagt korrekt. 

En anden mulighed for risiko er at køre modeller på tværs af forskellige kundeorganisationer på en fælles infrastruktur; dette kan føre til dataleaks og ydeevneproblemer, og der er en tilføjet risiko for, at en brugers handlinger påvirker andre brugere. Derfor foretrækker virksomheder generelt tjenester, der er udviklet i deres eget cloud.

Kundetilfredshed

Når svarene tager mere end få sekunder at dukke op, dropper brugerne typisk af, hvilket understøtter ingeniørernes indsats for at overoptimerere for nul ventetid. Derudover præsenterer applikationerne “hinder såsom hallucinationer og ukorrekte oplysninger, der kan begrænse den bredere indvirkning og antagelse,” ifølge en Gartner pressemeddelelse.

Forretningsmæssige fordele ved at håndtere disse problemer

Optimering af batchning, valg af rette størrelse modeller (f.eks. skifte fra Llama 70B eller lukkede kilde modeller som GPT til Gemma 2B, hvor det er muligt) og forbedring af GPU-udnyttelse kan reducere inferensregninger med mellem 60 og 80 procent. Brug af værktøjer som vLLM kan hjælpe, ligesom skift til en serverless pay-as-you-go-model for en spids arbejdsproces. 

Tag Cleanlab som eksempel. Cleanlab lancerede Trustworthy Language Model (TLM) for at tilføje en tillidsscore til hver LLM-svar. Det er designet til højkvalitetsudgang og forbedret pålidelighed, hvilket er kritisk for virksomhedsapplikationer for at forhindre ukontrollerede hallucinationer. Før Inferless oplevede Cleanlabs øgede GPU-omkostninger, da GPU’er kørte, selv når de ikke var aktivt i brug. Deres problemer var typiske for traditionelle cloud GPU-udbydere: høj ventetid, ineffektiv omkostningsstyring og et komplekst miljø at styre. Med serverless inferens reducerede de omkostningerne med 90 procent, mens de opretholdt performancesniveauet. Endnu vigtigere var, at de gik live inden for to uger uden yderligere ingeniørarbejdsomkostninger.

Optimering af modelarkitektur

Foundation-modeller som GPT og Claude er ofte trænet for almenhed, ikke effektivitet eller specifikke opgaver. Ved ikke at tilpasse open source-modeller til specifikke brugstilfælde spilder virksomheder hukommelse og beregnings tid for opgaver, der ikke kræver den skala.

Nye GPU-chips som H100 er hurtige og effektive. Disse er især vigtige, når der køres store skalaoperationer som video-generering eller AI-relaterede opgaver. Flere CUDA-kerner øger proceshastigheden og overgår mindre GPU’er; NVIDIA’s (NVDA ) Tensor-kerner er designet til at accelerere disse opgaver i stor skala.

GPU-hukommelse er også vigtig for at optimere modelarkitektur, da store AI-modeller kræver betydelig plads. Denne ekstra hukommelse giver GPU’en mulighed for at køre større modeller uden at gå på kompromis med hastigheden. Omvendt lider performances af mindre GPU’er med mindre VRAM, da de flytter data til en langsommere systemhukommelse.

Flere fordele ved at optimere modelarkitektur omfatter tids- og pengebesparelse. Først kan skift fra tæt transformer til LoRA-optimeret eller FlashAttention-baseret variant reducere svartiden med mellem 200 og 400 millisekunder pr. forespørgsel, hvilket er afgørende i chatbots og gaming, for eksempel. Derudover har kvantificerede modeller (som 4-bit eller 8-bit) mindre VRAM og kører hurtigere på billigere GPU’er. 

På lang sigt besparelse af modelarkitektur penge på inferens, da optimerede modeller kan køre på mindre chip.

Optimering af modelarkitektur omfatter følgende trin:

• Kvantificering — reducerer præcision (FP32 → INT4/INT8), besparelse af hukommelse og accelerere beregningstid
• Pruning — fjernelse af mindre nyttige vægte eller lag (struktureret eller ustruktureret)
• Distillation — træning af en mindre “elev”-model til at efterligne output fra en større model 

Komprimering af modelstørrelse

Mindre modeller betyder hurtigere inferens og mindre dyrt infrastruktur. Store modeller (13B+, 70B+) kræver dyre GPU’er (A100s, H100s), høj VRAM og mere kraft. Komprimering af dem giver mulighed for at køre på billigere hardware, som A10s eller T4s, med meget lavere ventetid. 

Komprimerede modeller er også kritiske for at køre på enhed (mobiltelefoner, browsere, IoT) inferens, da mindre modeller giver mulighed for at betjene flere samtidige anmodninger uden at skalere infrastruktur. I en chatbot med mere end 1.000 samtidige brugere giver skift fra en 13B til en 7B komprimeret model en mulighed for at betjene mere end dobbelt så mange brugere pr. GPU uden ventetids-spids.

Udnyttelse af specialiseret hardware

Almindelige formål CPU’er er ikke bygget til tensor-operationer. Specialiseret hardware som NVIDIA A100s, H100s, Google TPUs eller AWS Inferentia kan tilbyde hurtigere inferens (mellem 10 og 100 gange) for LLM’er med bedre energi-effektivitet. At reducere selv 100 millisekunder pr. anmodning kan gøre en forskel, når der behandles millioner af anmodninger dagligt.

Overvej følgende hypotetisk eksempel:

Et hold kører LLaMA-13B på standard A10 GPU’er for deres interne RAG-system. Ventetiden er omkring 1,9 sekunder, og de kan ikke batche meget på grund af VRAM-begrænsninger. Så de skifter til H100s med TensorRT-LLM, aktiverer FP8 og optimerer attention-kernen, øger batch-størrelsen fra otte til 64. Resultatet er at reducere ventetiden til 400 millisekunder med en femdobling af gennemløb.
Derved kan de betjene anmodninger fem gange på samme budget og frigøre ingeniører fra at navigere i infrastruktur-bottlenecks.

Evaluering af implementeringsmuligheder

Forskellige processer kræver forskellige infrastrukturer; en chatbot med 10 brugere og en søgemaskine, der betjener millioner af forespørgsler pr. dag, har forskellige behov. At gå all-in på cloud (f.eks. AWS Sagemaker) eller DIY GPU-servere uden at evaluere omkostnings-ydelsesforhold fører til spild af penge og dårlig brugeroplevelse. Bemærk, at hvis du binder dig tidligt til en lukket cloud-udbyder, er det smertefuldt at migrere løsningen senere. Men tidlig evaluering med en pay-as-you-go-struktur giver dig muligheder længere nede ad vejen.

Evaluering omfatter følgende trin:

• Benchmark model-ventetid og omkostning på tværs af platforme: Kør A/B-tests på AWS, Azure, lokale GPU-kluster eller serverless-værktøjer for at replikere.
• Mål kold start-performance: Dette er især vigtigt for serverless eller event-drevne workloads, fordi modellerne loader hurtigere. 
• Vurder overvågning og skaleringsbegrænsninger: Evaluér tilgængelige metrikker og identificer, hvad maksimum antal forespørgsler pr. sekund er, før de degraderer.
• Tjek omkostningsstøtte: Bestem, om du kan gennemtvinge geo-bundne dataregler eller audit-logs.
• Estimer samlet ejeromkostning. Dette skal omfatte GPU-timer, lagring, båndbredde og overhead for hold.

Det endelige punkt

Inferens giver virksomheder mulighed for at optimere deres AI-ydelse, reducere energiforbrug og omkostninger, opretholde privatliv og sikkerhed og holde kunderne tilfredse.