En vektor är en lista med tal. I modellen är varje token en vektor med 4096 tal, och en sådan vektor kan ses som en pil i ett rum med 4096 dimensioner.

Skalärprodukten multiplicerar två vektorer tal för tal och summerar:

Resultatet är ett enda tal som mäter hur mycket vektorerna pekar åt samma håll, skalat med deras längder.

Nästan allt i modellen är skalärprodukter:

• attention-scores: query · key
• logits: slutvektorn · en tokens rad i LM head
• varje utvärde i en matrismultiplikation

En viktmatris W [d_in, d_out] gör om en vektor med d_in tal till en med d_out tal. Varje utvärde är skalärprodukten mellan indatavektorn och en kolumn i W:

Varje kolumn fungerar som en detektor: utvärdet blir stort när x liknar kolumnens mönster.

Med flera rader, X [T, d_in], händer samma sak för varje rad oberoende av de andra:

Det är därför 7 tokens kan bearbetas på en gång: 7 rader mot samma W.

Två matriser efter varandra är bara en matris till:

Hundra lager utan något emellan vore alltså inte mäktigare än ett enda. Modellen skulle bara kunna rita räta linjer.

En aktiveringsfunktion mellan matriserna bryter det. ReLU är den enklaste:

Negativa värden blir 0, positiva släpps igenom. Varje neuron blir en detektor som antingen är av eller ger utslag. Summan av många sådana knäckar kan forma vilken kurva som helst.

Llama använder SiLU, en mjukare variant, men idén är densamma. Softmax i attention är modellens andra icke-linjäritet.

Modellen producerar godtyckliga tal (logits). Softmax gör om dem till positiva tal som summerar till 1:

• Exponentialen gör alla värden positiva och förstorar skillnader: en logit som är 2 högre får ungefär 7 gånger så hög sannolikhet.
• Bara skillnaderna mellan logits spelar roll. Lägg till 100 på alla och inget ändras.
• Skala alla logits med en faktor, så blir fördelningen skarpare eller plattare. Det är precis vad temperature gör.

Softmax används på två ställen: i attention (vilka positioner ska jag lyssna på?) och i slutet (vilken token kommer härnäst?).

Den viktigaste distinktionen i hela kursen:

• Vikter är modellens inlärda tal. De ligger fast i GPU-minnet och är desamma för alla frågor. De är programmet.
• Aktiveringar är mellanvärdena som räknas fram när en token passerar. De är tillståndet medan programmet körs.

I en tät modell används alla viktmatriser i sin helhet för varje token. Undantaget är embedding, som i stället är ett uppslag av en rad per token, vilket modul 2 visar. Det går alltså inte att se ”vilka vikter som aktiverades” av en fråga. Det som skiljer en fråga från en annan är aktiveringarna, och det är dem man studerar när man vill förstå vad modellen gör.

I en MoE-modell väljer en router några experter per token. Där kan man faktiskt se vilka viktblock som användes.

Byt token och modelltyp till höger.

Modellen räknar bara med tal. Texten måste delas i bitar som var och en har ett id i en fast vokabulär.

• Tecken för tecken ger korta vokabulärer men mycket långa sekvenser, och attention kostar mer ju längre sekvensen är.
• Hela ord ger korta sekvenser men en enorm vokabulär och inget sätt att hantera nya ord.
• Subword-tokens (BPE) är en kompromiss: vanliga ord blir en token, ovanliga delas upp.

Byte Pair Encoding tränas en gång innan modellen tränas: börja med enskilda bytes, hitta det vanligaste paret i träningstexten, slå ihop det till en ny token och upprepa tills vokabulären är full. Llama 3 har 128 256 tokens.

Efter modul 2 har vi en vektor per token, x [T, 4096]. Men varje vektor vet bara något om sin egen token. Vektorn för ”på” vet inte att det var en katt som satt.

För att gissa nästa token behöver sista positionen veta allt relevant om hela texten: vem som gör vad, var, och vad som brukar komma härnäst.

Det är jobbet för resten av modellen: fylla varje tokens vektor med sammanhang, steg för steg, tills den sista räcker för att förutsäga fortsättningen.

Det som gör jobbet kallas en transformer. Nästa slides förklarar ordet, sedan hur den är byggd.

Modellen består av en enda konstruktion, ett block (kallas också lager), som upprepas. Antalet kallas L. Llama-3-8B har L = 32.

Alla block har samma ritning: först attention, sedan MLP. Men varje block har egna vikter, så de lär sig göra olika saker.

Varför stapla? Ett block kan bara göra en runda av ”hämta information från andra tokens, bearbeta den”. Många slutsatser kräver flera rundor i följd, där varje runda bygger på den förra.

Dra i reglaget och se vad fler block kostar och ger.

Varje token har en vektor med 4096 tal som följer med genom hela modellen. Den kallas residual stream, och vi skriver den x.

Tänk på den som ett anteckningsblock per token. Varje block i modellen läser blocket, räknar fram en kort anteckning och lägger till den. Ingen suddar ut det som redan står där.

Namnet kommer från residual connection: varje block räknar bara fram en korrigering, en rest, som läggs ovanpå. Själva vägen rakt igenom, där x passerar oförändrad, finns alltid kvar.

Det ger tre fördelar: information från tidiga block finns kvar till slutet, träning av djupa modeller blir stabil, och strömmen blir den naturliga platsen att mäta och påverka modellen.

Strömmen x har shape [T, 4096]: T rader, en per token, och 4096 tal per rad. Den shapen gäller efter embedding, efter varje block och efter final norm.

Det är ett medvetet val, och det möjliggör tre saker:

1. Block kan staplas. Det som kommer ut ur ett block passar rakt in i nästa.
2. Bidrag kan adderas. x + bidrag kräver att båda har samma shape.
3. Strömmen kan läsas var som helst. Efter vilket block som helst är det samma sorts vektor, vilket tolkningsmetoder utnyttjar.

Först i LM head, modellens sista matris, byter den form: från 4096 tal per rad till 128 256, ett tal per token i vokabulären. Mer om det i modul 4.

Problemet. Eftersom varje block adderar till strömmen växer x i storlek ju längre in i modellen man kommer. Attention och MLP fungerar däremot bäst om deras indata alltid har ungefär samma skala.

Lösningen är normalisering: skala om en vektor så att dess storlek (RMS) blir 1, utan att ändra riktningen. Formeln kommer på RMSNorm-sliden.

Var man normaliserar finns det två varianter av:

• Post-norm (originalet 2017): strömmen själv normaliseras efter varje addition.
• Pre-norm (Llama och de flesta moderna modeller): blocket normaliserar en kopia innan det läser. Strömmen själv lämnas orörd och får växa.

Pre-norm gör djupa modeller stabilare att träna, eftersom vägen rakt genom strömmen aldrig störs. Priset är att strömmen aldrig normaliseras under vägen, så den måste normaliseras en gång i slutet, före LM head. Det är final RMSNorm.

”Ett lager” i en transformer är inte en matris utan hela blocket. I Llama-3-8B innehåller varje lager sju viktmatriser och två viktvektorer, totalt drygt 218 miljoner parametrar.

Mellan vikterna finns steg som saknar vikter: RoPE, scores, softmax, SiLU och de två additionerna. De är fasta formler som är likadana i alla modeller av samma typ.

Klicka på en del i diagrammet för att se vad den gör, dess shape och vad den heter i en modellfil.

En modellfil (safetensors) är i grunden en ordbok: namn → tensor. Llama-3-8B innehåller 291 tensorer: 9 per lager gånger 32 lager, plus tre utanför lagren.

Alla 32 lager har exakt samma namn och shapes, bara lagrets nummer skiljer. Värdena är helt olika: varje lager har lärt sig sin egen del av jobbet. Därför kan samma kod köras i en loop, med en ny uppsättning vikter varje varv.

PyTorch lagrar en linjär vikt som [ut, in]. Därför står det [1024, 4096] för k_proj, medan kursen skriver [4096, 1024] i flödesriktningen. Det är samma matris, transponerad.

Normaliseringen skalar varje tokens vektor så att dess RMS blir 1, och multiplicerar sedan med en inlärd vikt per dimension:

Utan normalisering skulle storleken på strömmen växa lager för lager, eftersom allt adderas. Attention och MLP vill ha indata i en stabil skala.

RMSNorm är en förenklad LayerNorm: ingen medelvärdessubtraktion och ingen bias. Billigare, och fungerar lika bra.

Tänk på residual stream som en tabell x [T, 4096]: en rad per token, en kolumn per dimension.

Attention flyttar information mellan rader. Varje token hämtar en viktad blandning från tidigare tokens. Det är så ”den” kan få veta något om ”Katten”.

MLP:n bearbetar en rad i taget. Den blandar om dimensionerna inom raden, men kan aldrig se andra rader. Alla rader går genom samma MLP-vikter, var för sig.

En detalj som är lätt att missa: även inne i attention arbetar viktmatriserna Wq, Wk, Wv och Wo rad för rad. Det enda steget som korsar rader är P · V.

Attention i sig vet inget om ordning. Llama roterar Q och K beroende på position innan de jämförs (Rotary Position Embedding).

Varje head-vektor om 128 dimensioner ses som 64 par. Par i roteras med vinkeln pos · θᵢ:

Tidiga par roterar snabbt och fångar närhet. Sena par roterar långsamt och skiljer på långa avstånd.

Shapes ändras inte. RoPE appliceras på Q och K, aldrig V, och K lagras roterad i KV-cachen.

Varje query jämförs med varje key via skalärprodukt. Det ger en matris per head:

Med GQA delar 4 query heads på samma K: head 0–3 använder KV-head 0, head 4–7 KV-head 1, och så vidare.

Masken gör att position i bara ser position 0..i. Det är det som gör modellen autoregressiv, och det är därför K och V för gamla positioner aldrig ändras.

S är T × T. Vid 32 000 tokens blir det en miljard tal per head och lager. FlashAttention räknar därför i block och skriver aldrig ut hela matrisen i minnet.

Vikterna i P används för att blanda ihop values:

Varje tokens utdata är en viktad summa av tidigare tokens values. Wo blandar ihop resultaten från alla heads och skriver till strömmen.

Klicka på ord till höger. Vikterna är handplockade för att visa idén, inte tagna ur en riktig modell.

Varje neuron i MLP:n är en kolumn i W_gate och en rad i W_down. Kolumnen i W_gate är ett mönster. Skalärprodukten med tokenens vektor avgör hur väl vektorn matchar mönstret.

En neuron som slår till skriver alltså sin egen riktning till strömmen. Med 14 336 neuroner per lager och 32 lager finns det plats för väldigt många sådana regler.

Slå på och av egenskaper i tokenens vektor till höger och se vilka neuroner som tänds.

Förenklad bild. Verkliga neuroner har sällan en ren mänsklig betydelse; de flesta reagerar på blandningar av många mönster, och ett begrepp sprids ofta över många neuroner (superposition).

Mer än två tredjedelar av modellen är MLP. Attention-vikterna är få, men attention-beräkningen växer med kontextlängden.

Eftersom strömmen har samma shape i alla lager kan man ta vilket mellanläge som helst och skicka det genom final norm och LM head, som om modellen slutade där. Tekniken kallas logit lens.

Resultatet visar hur förutsägelsen byggs upp:

• Tidigt liknar strömmen mest den egna tokenens embedding.
• Mitt i dyker grammatiskt rimliga fortsättningar upp.
• Sent har attention hämtat sammanhanget och MLP:erna dragit slutsatser, och rätt svar tar över.

Inget lager ”bestämmer” svaret. Varje lager knuffar fördelningen en bit, och summan av alla knuffar blir den slutliga.

Siffrorna är påhittade för att visa mönstret. I verkliga modeller är de tidiga lagren ofta svåra att läsa med en ren logit lens, och varianter som tuned lens fungerar bättre.

• Temperature < 1 skärper fördelningen, > 1 plattar till den. Temperature 0 betyder greedy: ta alltid den största.
• Top-k klipper bort allt utom de k bästa.
• Top-p (nucleus) klipper adaptivt: när modellen är säker återstår få kandidater, när den är osäker många.

Logits efter ”Katten satt på” nedan är påhittade, men mekaniken är exakt den som körs.

Prefill kör hela prompten på en gång. T rader multipliceras med samma vikter, så varje byte som läses från minnet används för många beräkningar. Men prefill blir compute-bound först när T är stort nog: brytpunkten är samma kvot som kommer längre fram, ungefär 300 operationer per läst byte på en H100. En kort prompt är memory-bound den också.

Decode kör en token åt gången. Alla 16 GB vikter läses för att räkna en enda rad. GPU:n väntar nästan hela tiden på minnet (memory-bound).

Prefill bestämmer hur snabbt första token kommer. Decode bestämmer hur snabbt resten strömmar ut. Nästan allt en inference-motor gör handlar om att få decode att använda GPU:n bättre.

K och V för en position ändras aldrig efter att de räknats (causal mask). Så varför räkna om dem?

Utan cache räknar varje decode-steg om K och V för hela sekvensen. Med cache räknas bara den nya positionens K och V, som läggs till. Den nya tokenens query jämförs sedan mot alla sparade keys.

Cachen byter beräkning mot minne: varje token i varje sekvens tar plats i GPU-minnet i varje lager så länge sekvensen lever.

Bilden visar ett lager och ett KV head. I verkligheten finns cachen i alla 32 lager och för alla 8 KV heads.

Här körs en riktig transformer i din webbläsare: 2 lager, 2 heads, d = 16, med attention, causal mask, RMSNorm och MLP. Vikterna är slumpade, så texten blir nonsens. Mekaniken är däremot äkta.

Varje steg räknas på två sätt:

• Utan cache: hela sekvensen körs om från början.
• Med cache: bara den nya token körs, K och V för resten läses.

Jämför kolumnen längst till höger: skillnaden i logits är noll eller ren flyttalsavrundning. KV-cachen är ingen approximation.

Rutnätet visar den faktiska K-cachen i lager 0, head 0. En rad per position, och gamla rader ändras aldrig.

En konversation på 8 000 tokens tar alltså 1 GB cache. På en H100 med 80 GB, där 16 GB går till vikter, blir ungefär 50 GB över till cache, alltså runt 390 000 tokens totalt fördelat på alla samtidiga sekvenser.

Det är den här siffran som i praktiken bestämmer hur många användare en GPU kan betjäna samtidigt.

MLA (DeepSeek) cachar en komprimerad latent vektor i stället för K och V: 576 tal per token och lager.

När en inference-server har startat är GPU-minnet uppdelat i fyra delar med helt olika livslängd:

vLLM allokerar hela KV-poolen direkt vid start. nvidia-smi visar därför runt 90 % upptaget minne även när servern står helt stilla. Det är avsiktligt.

En större token-budget per steg kräver mer utrymme för aktiveringar, och då blir KV-poolen mindre. Allt som inte är vikter är en avvägning mellan de två.

En H100 läser ungefär 3,35 TB/s och räknar ungefär 990 TFLOPS i bf16. Kvoten är cirka 300: GPU:n måste göra 300 operationer per läst byte för att inte vänta på minnet.

Decode med en sekvens gör 2 operationer per parameter och läser 2 byte per parameter: kvoten 1. GPU:n står still 99 % av tiden.

Med B sekvenser i samma steg läses vikterna en gång men används B gånger. Genomströmningen ökar nästan linjärt tills beräkningen eller KV-minnet tar slut.

Idealiserad modell för Llama-3-8B i bf16 på en H100. Verkliga siffror ligger lägre, men formen stämmer.

Nu kan du svara på den praktiska frågan: hur många användare klarar en GPU, och hur snabbt går det för var och en?

1. Får vikterna plats? Parametrar × byte per parameter.
2. Hur stor blir KV-poolen? 90 % av minnet minus vikter minus ca 5 GB.
3. Hur många sekvenser ryms? Poolen delat med KV per sekvens.
4. Hur långt blir ett decode-steg? Bytes att läsa (vikter + all aktiv KV) delat med minnesbandbredden.

Steg 3 ger gränsen för samtidighet. Steg 4 ger ITL för alla i batchen.

Modellen är idealiserad (H100-liknande bandbredd, inga köer, alla sekvenser lika långa). Använd den för storleksordningar och för att se vilken resurs som tar slut först.

Färre bitar per vikt betyder färre bytes att läsa per decode-steg och plats för mer KV-cache.

• Weight-only int4 (AWQ, GPTQ): vikter lagras med 4 bitar plus en skalfaktor per grupp om till exempel 128 vikter. Kerneln packar upp till bf16 i farten. Bra för memory-bound decode.
• FP8 (W8A8): både vikter och aktiveringar i 8 bitar. På H100 räknar tensorkärnorna dubbelt så snabbt i FP8, så även prefill blir snabbare.
• FP8 KV-cache: halverar cachen, alltså dubbelt så många tokens i minnet.

Priset är lite precision. Int4 har bara 16 nivåer per grupp, så skalfaktorn måste väljas klokt.

Routern är bara en liten linjär matris, tränad tillsammans med resten. Ingen säger åt den vad experterna ska kunna.

I praktiken blir specialiseringen mest syntaktisk, som indentering, interpunktion och vissa funktionsord, snarare än ämnen som ”biologi”. En load balancing-loss under träningen ser till att experterna används ungefär lika mycket över en batch.

Varje lager har egna experter och egen router. En token tar en egen väg genom alla lager.

• MHA: ett KV head per query head. Störst cache.
• GQA: grupper av query heads delar KV (Llama 3, Mistral, Qwen).
• MQA: ett enda KV head för alla.
• MLA (DeepSeek-V2/V3): K och V komprimeras till en latent vektor som cachas, och packas upp vid behov.
• Sliding window: vissa lager ser bara de senaste W tokens, så deras cache slutar växa. Gemma 2 och 3 varvar lokala lager med globala.

Jämförelsen till höger använder 32 lager och d = 4096 för alla, för att isolera effekten av själva attention-varianten.

Full attention tittar på alla tidigare positioner. Det gör prefill kvadratisk i T och låter KV-cachen växa linjärt med kontexten — 128 KiB per token i Llama-3-8B.

Många nyare modeller blandar i stället: de flesta lager har ett fönster, några få är globala. Kvaliteten blir nästan densamma till en bråkdel av cachen.

Räkna på det: vid 32 000 tokens kostar Llama-3 cirka 4 GiB per sekvens, medan en modell med 4 globala lager och fönster 4 096 klarar sig på ungefär 0,9 GiB — och prefill slipper räkna 32 000² positioner i 28 av lagren.

Tre varianter man möter i praktiken:

• Lokalt fönster: varje token ser bara de senaste w tokens (Mistral, 4 096).
• Blandat lokal/global: de flesta lager lokala, några få globala (Gemma 2 och 3, gpt-oss).
• Attention sinks: de första tokens behålls alltid i cachen, eftersom modellen använder dem som avlastningsplats för uppmärksamhet (StreamingLLM).

Siffrorna i resten av kursen gäller Llama-3, som är helt global. Möter du en hybridmodell får du räkna KV-cachen lager för lager — formeln är densamma, men antalet positioner skiljer.

Två saker växer med kontexten:

• KV-cachen växer linjärt. 128 000 tokens i Llama-3-8B är 16 GB, lika mycket som vikterna.
• Attention-beräkningen per token växer linjärt, och för hela prefill kvadratiskt.

Grafen visar hur stor andel av beräkningen per genererad token som går till attention mot kontexten. Vid korta prompts är det försumbart. Vid 128K dominerar det.

För att modellen ska fungera på längre kontext än den tränats på skalas RoPE-frekvenserna om (position interpolation, YaRN). Llama 3.1 gick från 8K till 128K på det sättet, kombinerat med fortsatt träning.

Arkitekturen är densamma. Skillnaden är att modellen tränats med RL att skriva ut ett långt resonemang innan svaret, ofta inom taggar som <think>…</think>.

För inference betyder det:

• Nästan all tid går till decode, som är den dyraste fasen per token.
• KV-cachen växer med resonemanget, så färre sekvenser ryms samtidigt.
• max_tokens måste räcka för både tänkande och svar.
• vLLM kan dela upp utdata i resonemang och svar med --reasoning-parser.

Det är också här loopar gör ont: en modell som upprepar sig bränner decode-steg tills taket nås.

Före vLLM reserverade servrar ofta ett sammanhängande minnesområde per request, stort nog för max längd. Men ingen vet i förväg hur långt svaret blir.

Resultatet var att det mesta av KV-minnet var reserverat men tomt. Färre requests fick plats, batcharna blev små och GPU:n gick på tomgång.

PagedAttention-pappret (2023) mätte att befintliga system bara använde 20–40 % av KV-minnet till faktiska tokens.

vLLM delar KV-minnet i block om ett fast antal tokens (16 som standard). Varje sekvens har en block table som översätter logiska block till fysiska, precis som virtuellt minne i ett operativsystem.

• Ett nytt block tilldelas först när det förra är fullt. Spillet blir högst ett halvfullt block per sekvens.
• Blocken behöver inte ligga intill varandra. Attention-kerneln slår upp dem via block table.
• Block kan delas mellan sekvenser: grunden för prefix caching.

Varje fullt block får en hash av sitt innehåll och föregående blocks hash. Två requests med samma början får därför samma hashkedja.

När en ny request kommer slår schedulern upp hasharna i tur och ordning. Träffade block återanvänds med en referensräknare, och bara resten behöver prefill.

Systemprompter, few-shot-exempel och långa konversationer, där varje ny tur börjar med hela historiken, blir därmed nästan gratis att prefilla igen.

Bara fulla block cachas. Avslutade requests block stannar kvar i cachen och evictas (LRU) först när minnet behövs.

Statisk batching: en batch körs tills den längsta sekvensen är klar. Platser för sekvenser som blivit klara står tomma.

Continuous batching: schedulern bestämmer batchen på nytt i varje steg. En plats som blir ledig fylls direkt av nästa request i kön.

Eftersom decode är memory-bound kostar ett steg nästan lika mycket oavsett hur många platser som används. Varje tom plats är därför bortkastad kapacitet.

Förenklat: 4 platser, prefill räknas som ett steg, siffran i rutan är requestens nummer.

Varje steg har en budget: max_num_batched_tokens. Schedulern fyller den i ordning:

1. En token till varje request i decode.
2. Återstående budget till prefill, uppdelad i chunks om prompten är för lång.

En lång prompt på 5 000 tokens tar därför tre steg med max_num_batched_tokens = 2048 (2048 + 2048 + 904) i stället för att blockera allt i ett. Decode-requests får sin token i varje steg, och ITL hålls jämn.

Prefill och decode i samma steg använder också GPU:n bättre: prefill-tokens ger räknearbete åt ett steg som annars mest läser minne.

Prefill och decode har olika flaskhalsar: prefill är compute-bound (när prompten är stor nog), decode är memory-bound. Körs båda på samma GPU:er stör en lång prompt alla som väntar på nästa token — ITL spikar precis när en ny request kommer in.

Disaggregering delar upp dem: några GPU:er kör bara prefill, andra bara decode, och KV-cachen flyttas mellan dem. Decode-poolen får då jämn takt, oavsett hur prompterna ser ut.

Flytten kostar tid och bandbredd. Det lönar sig bara med snabb interconnect (NVLink eller RDMA) och när ITL-kraven är hårda. I vLLM slås det på med --kv-transfer-config; det är en funktion för stora installationer, inte för en enskild GPU.

Vad man vinner och betalar:

Mellanlagret kostar också: en request väntar på att hela KV-cachen är framme innan decode börjar. Är kontexten lång och länken långsam försvinner vinsten.

När modellen inte får plats på en GPU, eller ska gå snabbare, delas varje viktmatris mellan GPU:erna.

• Column parallel (qkv, gate_up): varje GPU får en del av utdatakolumnerna. Attention delas per head: med TP = 2 får varje GPU 16 query heads och 4 KV heads.
• Row parallel (o_proj, down): varje GPU har en del av indata och räknar en delsumma. En all-reduce summerar delsummorna.

Två all-reduce per lager, alltså 64 per forward pass i Llama-3-8B. Det kräver snabba länkar som NVLink, och TP används därför främst inom en server.

Varje GPU håller bara sina heads KV-cache. TP = 2 ger alltså dubbelt så mycket totalt KV-minne.

Decode är memory-bound: att verifiera 5 tokens i ett forward pass kostar nästan lika lite som att generera 1. Speculative decoding utnyttjar det.

1. Ett billigt förslag ger k tokens: en liten draft-modell, n-gram från prompten, EAGLE-huvuden eller modellens egna MTP-lager.
2. Stora modellen kör alla k positioner i ett pass, som en mini-prefill.
3. Förslag accepteras från vänster tills första avvikelsen. Där används stora modellens egen token vid greedy; med sampling dras ersättaren i stället ur residualfördelningen normalize(max(0, p − q)), och just det steget ger exakt stora modellens fördelning.

Med sampling används rejection sampling: acceptera med sannolikhet min(1, p/q). Utfallet har då exakt samma fördelning som stora modellen ensam.

En LoRA-adapter är två små matriser per vikt: B [d, r] och A [r, d] med rang r, typiskt 8–64. Basmodellen ligger orörd och delas av alla adaptrar.

vLLM kör många adaptrar mot samma basmodell samtidigt. Requests med olika adaptrar hamnar i samma batch, och kernels applicerar rätt adapter per request — en GPU kan alltså betjäna många kunder som var och en har sin egen finjusterade variant.

Priset är litet extra arbete per token när många adaptrar blandas i samma batch, och att kvaliteten aldrig blir bättre än basmodellens. Adaptern ändrar beteende och stil, inte kunskaper.

Så startar man det:

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --enable-lora \
  --max-loras 16 \
  --lora-modules kod=./adapter-kod \
                 skriv=./adapter-skriv

Varje request namnger sin adapter i model-fältet (till exempel "kod"). Servern håller bara --max-loras adaptrar aktiva åt gången och lastar in fler vid behov.

LoRA-adaptern adderas till den frysta vikten; inga shapes ändras, så en adapter kan flyttas mellan maskiner och slås ihop med basmodellen om man vill ha en egen fil.

En vanlig och väl underbyggd hypotes är att modellen representerar begrepp som riktningar i residual stream: ”det här är kod”, ”det här är ett nekande”, ”nu upprepar jag mig”.

Man hittar en sådan riktning genom att köra två grupper av exempel, med och utan egenskapen, och ta skillnaden mellan medelvärdena av aktiveringarna i ett lager:

En linear probe är samma idé tränad som en klassificerare: om en linjär gräns skiljer grupperna åt finns informationen linjärt i strömmen.

När riktningen är hittad kan man ingripa i strömmen under körning, med en hook i valda lager:

Steering knuffar modellen mot eller bort från begreppet.

Ablation tar bort komponenten längs r̂ helt. Allt annat i vektorn lämnas orört, men just den signalen kan inte läsas av senare lager.

Dra i reglagen och se vad som händer med x och dess projektion på r̂.