Innhold Vis
Hvis du kjører kvantiserte AI-modeller lokalt på Nvidia-kort, er ExLlamaV3 1.0 en oppdatering det er verdt å merke seg. Den første stabile 1.0-utgaven kom 14. juli 2026 med nye CUDA-kjerner, færre avhengigheter, bedre støtte for flere GPU-er og store hastighetsøkninger i enkelte oppsett.
Dette er ikke en ny AI-modell. ExLlamaV3 er motoren som laster og kjører modellene, omtrent i samme del av verktøykassen som llama.cpp og vLLM. Forskjellen er at ExLlamaV3 er tett rettet mot moderne forbruker-GPU-er og sitt eget EXL3-format for kvantisering.
Det mest interessante er derfor ikke versjonsnummeret. Det er at mye av arbeidet skjer under panseret: mindre styr med installasjon, mer effektiv bruk av GPU-en og bedre håndtering av modeller som må fordeles over flere kort. På noen maskiner er forbedringen beskjeden. På andre er den temmelig voldsom.
Hva er ExLlamaV3 1.0?
ExLlamaV3 1.0 er den første stabile hovedversjonen av et open source-bibliotek for kvantisering og inferens av lokale språkmodeller. Det offisielle GitHub-prosjektet beskriver støtte for blant annet kontinuerlig batching, spekulativ dekoding med blant annet DFlash, 2-8-biters KV-cache, multimodale modeller, LoRA og tensor-parallell kjøring.
Biblioteket bruker EXL3, et kvantiseringsformat basert på QTIP. Enkelt forklart handler kvantisering om å pakke modellvektene med færre bits slik at modellen krever mindre minne og kan kjøres raskere. ExLlamaV3-utvikleren skriver at mindre modeller kan konverteres på noen minutter, mens modeller på 70 milliarder parametere eller mer kan bruke noen timer på ett RTX 4090 eller tilsvarende.
Det betyr ikke at EXL3 automatisk er riktig format for alle. Har du allerede et godt GGUF-oppsett i llama.cpp, støtte for CPU-offloading du er avhengig av eller AMD-maskinvare, bør du ikke rive ned alt fordi en ny versjon har fått et rundt tall. ExLlamaV3s egen dokumentasjon har fortsatt ROCm-støtte på listen over det som mangler, og installasjonen krever PyTorch med CUDA 12.4 eller nyere.
Hvor mye raskere er den nye versjonen?
Hastighetsøkningen varierer fra nesten ingenting til over 100 prosent i utviklerens målinger. I den tekniske gjennomgangen med måleresultater går Qwen 3.6 27B på RTX 3090 fra 29 til 50 tokens i sekundet ved 3,00 bpw når den nye standard-codebooken mul1 brukes. Det tilsvarer 72 prosent raskere dekoding.
Samme tabell viser Gemma 4 31B på RTX 3090 fra 24 til 40 tokens i sekundet, en økning på 67 prosent. Llama 3.1 8B ved 3,00 bpw går fra 89 til 134 tokens i sekundet, eller 51 prosent. På den andre siden finnes kombinasjoner som bare får noen få prosent bedre ytelse. Ett tall oppsummerer med andre ord ikke denne utgaven.
Målingene er heller ikke en uavhengig test. De er gjort av utvikleren med én GPU om gangen, greedy decoding og tom kontekst for dekoding. Prefill er målt med en prompt på 4 000 tokens. Små modeller får dessuten uforholdsmessig store utslag fordi nye C++- og CUDA-graph paths fjernet en CPU-flaskehals på testmaskinen med Threadripper 7960X. Resultatene viser hva som er mulig, ikke hva alle får hjemme.
Hvorfor får RTX 3090 så store forbedringer?
De største gevinstene kommer særlig fra oppdaterte GEMM-kjerner og en ny INT8 GEMV-kjerne. Ifølge utviklerens forklaring hjelper dette ekstra mye på Ampere og Blackwell, der høy minnebåndbredde møter mer begrenset regnekapasitet. RTX 3090 er Ampere, mens RTX 5090 tilhører Blackwell-generasjonen.
Ada-kort som RTX 4090 får også forbedringer, men utvikleren beskriver utslagene som mer beskjedne fordi balansen mellom minnebåndbredde og regnekapasitet i Nvidia-kjernene allerede er bedre. Det er en nyttig påminnelse: Nyere og dyrere maskinvare får ikke nødvendigvis den største prosentvise gevinsten av en programvareoppdatering.
Den nye mul1-codebooken spiller også en rolle. Den er nå standard, og den nye INT8-kjernen støtter bare mul1. Derfor viser tabellene både den eldre mcg-varianten og mul1. Sammenligner du egne resultater, må du kontrollere modell, bitrate, codebook, kontekst og GPU. Ellers sammenligner du fort epler med et skjermkort og lurer på hvorfor tallene ikke stemmer.
Hva er nytt i attention og KV-cache?
En ny attention-kjerne kvantiserer KV-cache direkte mens den brukes. Tidligere måtte midlertidige cache-tensorer i FP16 klargjøres for attention-steget. Den ekstra jobben ga en forsinkelse. I v1.0.0 skriver utvikleren at denne kostnaden er borte, og at kvantisert cache i modeller med mye KV-data i enkelte tilfeller kan øke ytelsen.
KV-cache lagrer informasjon fra tidligere tokens, slik at modellen ikke trenger å beregne hele samtalen på nytt for hvert nye ord. Lang kontekst gjør denne cachen stor. Når den kan lagres med 2-8 bits og brukes uten den gamle forsinkelsen, blir det lettere å spare GPU-minne uten å betale like mye i fart.
Attention-kjernen får også dobbel input for sliding window attention-lag og støtte for attention sinks. I tillegg har alle attention- og GDN-moduler fått en graph path. Dette er detaljer de fleste aldri trenger å konfigurere manuelt, men det er nettopp slike detaljer som avgjør om en lokal modell føles rask eller som en kaffepause med terminalvindu.
Blir det enklere å installere og vedlikeholde?
Ja, v1.0.0 fjerner behovet for flash-attention-2 og xformers som avhengigheter. Den offisielle utgivelsesloggen viser også at causal_conv1d ikke lenger trengs, fordi ExLlamaV3 har fått en egen conv1d-kjerne. Færre eksterne deler betyr færre versjonskonflikter og mindre feilsøking.
Formatron-konflikten med pydantic håndteres nå internt, slik at pydantic ikke må låses til en eldre versjon. Byggingen av utvidelsen er også gjort raskere ved å dele den i flere kompileringsenheter. Dette gir kanskje ikke like spennende skjermbilder som en dobling i tokens per sekund, men installasjonsproblemer er ofte det som avgjør om et lokalt verktøy faktisk blir brukt.
GitHub-utgivelsen inneholder flere titalls ferdigbygde wheel-filer for ulike kombinasjoner av Python, PyTorch, CUDA, Linux og Windows. Det finnes også en pakke på PyPI, men den inneholder ikke en ferdigkompilert utvidelse. Da trenger du CUDA-verktøy og vanlige byggeavhengigheter lokalt. Den anbefalte veien for den som er usikker, er derfor å velge en ferdig wheel som passer miljøet.
Hva betyr bedre støtte for flere GPU-er?
Tensor-parallell støtte er utvidet til de fleste modellarkitekturene, inkludert Gemma 4. Det betyr at beregningene kan fordeles over flere GPU-er samtidig, i stedet for at kortene bare brukes som separate minnebeholdere. For store modeller som ikke får plass på ett kort, kan dette være forskjellen mellom et eksperiment og et brukbart oppsett.
ExLlamaV3 støtter også expert parallelism for MoE-modeller og har fått en ny scheduler for MoE-kjerner. Utvikleren sier at dette særlig forbedrer prefill på store, sparse modeller. GPT-OSS og NemotronH er samtidig lagt til som nye arkitekturer, mens den offisielle modellisten omfatter alt fra Llama og Mistral til Gemma, Qwen, GLM og MiniMax.
Den praktiske serverdelen håndteres normalt gjennom TabbyAPI. ExLlamaV3-prosjektet anbefaler dette som backend, og TabbyAPI gir et OpenAI-kompatibelt API med modellnedlasting, batching, tool calling og støtte for chat-maler. Det gjør at en lokal EXL3-modell kan kobles til klienter som allerede snakker OpenAI-formatet, uten at hvert program trenger en egen ExLlama-integrasjon.
Støttelisten er bred, men ikke alle arkitekturer har nøyaktig de samme mulighetene. Den offisielle tabellen skiller blant annet mellom multimodal støtte og tensor-parallell støtte for hver modellfamilie. Gemma 4 har begge deler, men E2B- og E4B-variantene er foreløpig unntatt. Dette er verdt å sjekke før du laster ned en stor kvantisering og oppdager at akkurat varianten din faller utenfor. «Modellen støttes» og «hele oppsettet mitt støttes» er tross alt to forskjellige setninger.
Bør du bytte til ExLlamaV3 nå?
Har du Nvidia-GPU, modeller som får plass i GPU-minnet og lyst til å presse mer ytelse ut av kvantiserte modeller, er v1.0.0 absolutt verdt en kontrollert test. Ampere-eiere har den tydeligste grunnen til å prøve. Bruk samme modell, prompt, kontekst og sampling som i dagens oppsett, og mål både prefill og dekoding før du bestemmer deg.
Har du AMD, er svaret foreløpig nei. Er arbeidsflyten bygd rundt GGUF og CPU-offloading, er dette heller ikke et rett-fram bytte. Da må gevinsten være stor nok til å forsvare et annet modellformat og en annen backend. Lokal AI har allerede mer enn nok bevegelige deler. Det er ingen premie for å legge til fem nye bare fordi GitHub har fått en grønn «Latest»-etikett.
Diskusjonen i LocalLLaMA viser også det vanlige spriket: noen rapporterer svært høy fart, mens andre ser mindre forskjell eller mer ujevn oppførsel enn i llama.cpp-varianter. Det er normalt for en fersk 1.0-utgave med mange arkitekturer og maskinvarekombinasjoner. Jeg ville behandlet dette som en lovende produksjonsklar milepæl som fortsatt må testes mot ditt eget oppsett.
Ofte stilte spørsmål
Er ExLlamaV3 det samme som en AI-modell?
Nei. ExLlamaV3 er et bibliotek som kvantiserer, laster og kjører lokale språkmodeller. Selve modellen kan for eksempel være Llama, Gemma, Mistral eller Qwen. ExLlamaV3 er motoren under, mens EXL3 er formatet som brukes til å pakke modellvektene.
Fungerer ExLlamaV3 1.0 på AMD-kort?
Ikke gjennom offisiell ROCm-støtte ennå. Prosjektets dokumentasjon oppgir fortsatt ROCm som noe som mangler, mens installasjonen er basert på PyTorch og CUDA 12.4 eller nyere. I praksis er denne utgaven rettet mot Nvidia-GPU-er.
Kan ExLlamaV3 brukes med et OpenAI-kompatibelt API?
Ja. Prosjektet anbefaler TabbyAPI som server. Den tilbyr et OpenAI-kompatibelt API, kontinuerlig batching, modellnedlasting, chat-maler og tool calling. Dermed kan mange eksisterende klienter kobles til en lokal modell uten en egen protokoll.
Gir ExLlamaV3 1.0 alltid dobbelt så høy fart?
Nei. Utviklerens målinger spenner fra svært små forbedringer til over 100 prosent, avhengig av modell, bitrate, codebook og GPU. Testene er heller ikke uavhengige. Du må måle med ditt eget oppsett før du kan si hvor stor gevinsten faktisk er.
