Lad os være ærlige. De fleste RAG‑projekter dør ikke af prompts. De dør af hukommelse. En ny open‑source spiller, turbovec, prøver at ændre regnestykket: et Rust‑baseret vektorindeks med Python‑bindings, bygget på Googles TurboQuant. Ifølge hovedkilden kan et 10‑millioners korpus presses fra omtrent 31 GB (float32) til nær 4 GB med bevaret recall i praksis. Oveni ligger der en målt hastighedsfordel på ARM i benchmarks, der sammenligner mod FAISS.
Hvis tallene holder i jeres miljø, flytter det grænsen for hvem der kan køre RAG on prem på fornuftig hardware. Det er den korte version. Resten er det, der afgør, om I får gevinsten i hænderne – eller ej.
RAM er den skjulte stopklods
Vector search er motoren i de fleste RAG‑pipeliner. Hukommelsen skalerer simpelt: N × d × bytes. For 10.000.000 vektorer ved 768 dimensioner i float32: 10e6 × 768 × 4 ≈ 30,7 GB rå data før indeks‑overhead. MarkTechPost runder til 31 GB for en 10M float32‑opsætning – det matcher regnestykket.
Vi har set det i felten. En offentlig enhed i Danmark måtte skrinlægge et ellers fornuftigt dokumentsøg‑setup, fordi dev‑maskinerne havde 16 GB RAM, og serverrummet var lukket for nye kasser. Beslutningen blev taget i et mødelokale med flad kaffe og en hylende ventilator. Ikke uenighed om metode – bare RAM‑virkelighed.
TurboQuant kort fortalt
Turbovec bygger på TurboQuant fra Google Research: en data‑oblivious kvantisering uden træning og uden passes over data. Den bruger et analytisk greb til at sætte kvantiseringsgrænser i stedet for at træne en codebook med k‑means. Ifølge kilden ligger forvrængningen inden for cirka 2,7× af Shannons teoretiske nedre grænse – ambitiøst for en træningsfri metode.
Hvorfor betyder det noget? Fordi man normalt skal sample data, træne en codebook og holde den ved lige, når korpuset vokser eller skifter domæne. Det er driftspauser og scripts, der har det med at knække i weekenden. TurboQuant skærer meget af den cyklus væk.
De fire trin i TurboQuant
Turbovec eksponerer TurboQuant via en kort pipeline, som beskrevet i kilden:
- Normalisering: hver vektor gøres til enhedsretning; normen gemmes separat (én float pr. vektor).
- Fast, tilfældig ortogonal rotation: samme rotation for alle vektorer, så hver koordinatefter rotation får en kendt fordeling i høj dimension.
- Lloyd–Max skalar‑kvantisering: optimale grænser/centroids kan forudberegnes analytisk for fx 2‑ eller 4‑bit – uden data‑passes.
- Bit‑packing: de kvantiserede koordinater pakkes kompakt. Eksemplet i artiklen: en 1536‑dim vektor krymper fra 6.144 bytes i FP32 til 384 bytes ved 2‑bit – 16×.
Ved søgning roteres forespørgslen én gang ind i samme rum, og scoringen bruger SIMD‑intrinsics: NEON på ARM og AVX‑512BW eller AVX2 på x86. Der nævnes nibble‑split lookups for throughput – den slags mikro‑optimering betyder faktisk noget på ARM.
Hvad leverer turbovec konkret
Kernen er skrevet i Rust og udstilles med Python‑bindings. Installation beskrives som en almindelig pip‑pakke, API’et som klassisk: opret indeks, tilføj vektorer, søg, persistér til disk. Det afgørende er tallene. MarkTechPost sammenligner recall mod FAISS’ PQ‑baseline (LUT256, nbits=8, float32 LUT). TurboQuant og FAISS ligger inden for 0–1 point i R@1 for OpenAI‑embeddings ved d=1536 og d=3072 og konvergerer mod 1,0 ved k=4–8. For GloVe ved d=200 halter TurboQuant i R@1 med 3–6 point, men lukker hullet ved højere k.
På hastighed viser ARM‑tests (Apple M3 Max) en fordel på 12–20 procent mod FAISS IndexPQFastScan. På x86 (Sapphire Rapids) vinder turbovec i alle 4‑bit‑konfigurationer med 1–6 procent og ligger tæt på uafgjort i 2‑bit single‑threaded. I to 2‑bit multitrådede opsætninger taber den 2–4 procent til FAISS, som ifølge artiklen udnytter en AVX‑512 VBMI‑vej bedre. Små forskelle, men konsekvente i de viste setups.
Påstandene holder – med forbehold
Benchmark‑opsætningen fremgår tydeligt: 100K vektorer, 1.000 queries, k=64, median over fem kørsler. Det er pænt, men single‑source. ARM‑/x86‑tallene og 10M → ~4 GB‑projektionen bør reproduceres på egne data og egen hardware, før man beslutter arkitektur.
En kort, målbar replikeringsplan vi selv ville køre:
- Datasæt og skala: 100K, 1M og (hvis muligt) 10M vektorer.
- Dimensioner: d=200, 768, 1536, 3072 med jeres faktiske embedding‑familie.
- Hardware: én ARM‑node (fx M3) og én nyere x86 med og uden AVX‑512 til sammenligning; noter trådantal.
- Byg: dokumentér build‑flags, SIMD‑vej (NEON, AVX2/AVX‑512BW), container‑base og Python/Rust versioner.
- Metrikker: R@1/R@5, p50/p95‑latency, throughput og memory‑footprint pr. indeksvariant.
Hvorfor det betyder noget for on prem
Komprimering ændrer hardwarebudgettet. Hvis I realistisk kan hente ~8× i jeres opsætning (det varierer med embeddings og queries), flyttes et 10M‑indeks fra store RAM‑servere til en kraftig arbejdsstation. For små teams kan POC’er køre lokalt uden OOM. I drift kan færre noder og lavere standby‑forbrug være nok til at få on‑prem tilbage i spil.
ARM‑fordelen er ikke bare en fodnote. Mange kører blandede CPU‑flåder. Hvis turbovec er 12–20 procent hurtigere på ARM hos jer, kan det være nok til at bruge en M‑serie Mac mini eller ARM‑edge som søgeknude i et privat net. Det lyder småt. Det føles ikke småt, når man jagter 80 ms p50.
Hvad vi har oplevet i felten
Vi har haft cases, hvor int8‑kvantisering og disk‑backed ANN skar hukommelsen med en faktor ~10 uden mærkbar forskel i retrieval‑kvalitet hos brugerne. En anden case: et sekretariat, der droppede lokal drift alene pga. float32‑kravet. Begge peger samme vej. Færre bits giver plads til at prøve idéer, før arkitekturen låses.
Og en lille note fra et nicheprojekt: Vi så tydeligt fald i recall på domænespecifikke embeddings under 256 dimensioner, når vi kvantiserede for hårdt. Ikke generelt – bare en påmindelse om at A/B‑teste på eget datasæt.
Tradeoffs man skal kende
Kvantisering kan koste mere i små dimensioner og ved visse embedding‑familier. MarkTechPost viser allerede en større udfordring ved GloVe d=200. Hvis jeres pipeline bruger lave dimensioner eller skæve fordelinger, så test bredt på k‑værdier og ikke kun R@1. K=4–16 siger ofte mere om brugeroplevelsen.
SIMD er afgørende for de lovede hastigheder. NEON på ARM og AVX2/AVX‑512BW på x86 gør forskellen. Uden dem mister man meget af gevinsten. Tjek build‑flags og container‑baser, og attester instruction set i CI, før I ruller ud. Vi har set containere bygge mod en for bred baseline og falde tilbage til langsomme kodeveje på ældre Xeons.
Disk, latency og tunge queries
Selv med aggressive bits er 10M poster meget. Bruger I disk‑backed ANN som sikkerhedsnet, så budgettér p95/p99‑latency. Kvantisering reducerer RAM, men ændrer ikke I/O‑loven for diske. Overvej read‑ahead, varme segmenter og prefetch af candidate‑lister, især når samtidige queries rammer samme shard.
Opdateringer af korpus er en anden detalje. TurboQuant kræver ingen retræning, og det er en gave i drift. Ved større domæneskift kan det dog give mening at regenerere rotation/packing for et nyt snapshot for at hente de sidste procenter i recall. Ikke retræningsmyte – bare sund vedligehold.
Implementeringscheckliste til et hurtigt POC‑forløb
- Definér succeskriterier: 2–3 kernemetrikker. Typisk R@1 og R@5, end‑to‑end p50/p95 og memory‑footprint.
- Lav et repræsentativt datasæt: mindst 100K vektorer og 500–1.000 queries der ligner jeres trafik.
- Byg to baselines: nuværende stack (FAISS/Milvus i FP32/FP16/int8) og turbovec i 2‑bit og 4‑bit.
- Mål på jeres maskiner: én ARM‑node og én x86‑node, hvis I har blandede profiler. Notér instruction sets og tråd‑affinitet.
- Test flere k‑værdier: k=1, 4, 8, 16. Samme ground truth til sammenligning. Gem queries og svar.
- Planlæg fallback: behold et lille FP16‑indeks til hårde queries eller cold‑start. Rute 5–10 procent af trafikken dertil efter en heuristik.
- Overvågning: log per‑request latency, recall‑proxy (fx klikrate/brugervalg) og memory‑usage. Sæt alarmer før produktion.
- Reproducerbare builds: pin Rust‑ og Python‑afhængigheder, attester SIMD‑flavor i CI, signer artefakter og gem SBOM.
Hvordan det skifter beslutningerne i arkitekturen
Når man kan få 8–16× komprimering uden træning, bliver RAG mindre låst til sky‑RAM. On prem med få noder rykker tættere på. Hybrid‑mønstre hvor indekset ligger tæt på data og inference kører i skyen, giver mere mening. Og små teams kan køre fuld lokal POC med samme semantik som produktion.
Cost‑styringen bliver også enklere: ingen codebook at træne og versionere, færre pipeline‑trin, lavere risiko for, at en ny korpusversion kræver rebuild midt i en release. Hold dog øje med værste queries og domæneskift – de er kanariefugle.
FAISS, træning og hvad vi sammenligner med
FAISS’ Product Quantization kræver normalt codebook‑træning (k‑means) på et repræsentativt sample – sådan virker PQ. Det er en stærk baseline, især med LUT256/FastScan‑varianter. MarkTechPost bruger netop den opsætning som reference. Sammenligningen er teknisk fair, men FAISS har mange varianter og optimeringer – i nogle workloads kan en anden FAISS‑sti vinde.
Hvis I allerede kører FAISS, er migration ikke alt‑eller‑intet. Kør et sideløbende turbovec‑indeks og spejl 10–20 procent af trafikken en periode. Gating‑kriterier: max −1 point i R@1/R@5, p50/p95 må ikke forværres, og memory‑målet skal nås. Når metrikkerne holder over fx to uger, tager man næste skridt.
Sikkerhed og supply chain
Nye native biblioteker i produktion kræver byggedisciplin. Det gælder turbovec som enhver anden Rust/Python‑pakke. Den nylige runde af supply‑chain‑hændelser med forgiftede VS Code‑udvidelser, npm‑pakker og et Python‑SDK er en påmindelse om basale kontroller: attestation, reproducible builds og klare regler for, hvem der må opgradere native afhængigheder hvornår.
Praktiske kontroller: pin versioner, brug isolerede build‑miljøer, gem SBOM, kræv attest for CPU‑instruktionssæt og kør statisk analyse før pakker får adgang til produktionsnettet. Kedeligt arbejde – der betaler sig den dag auditten spørger, hvorfor en binær kunne alt for meget.
Modenhed og driftsrisiko
Inden produktion: tjek repo‑aktivitet, release‑tags, testdækning, issues og om der er CI til binære artefakter. Notér OS‑støtte (fx Windows) og eventuelle kendte byggeproblemer i Rust/Python‑kæden. Hvis noget halter, så planlæg en konservativ rollout med spejlet trafik og tydelige rollback‑mekanismer.
Hvor er hullerne – og hvilke tests mangler
Vi mangler uafhængige benchmarks på større skalaer og med flere embedding‑typer. Vi mangler også mere klarhed om release‑modenhed og vedligehold. Kør derfor konkrete tests, fx:
- GloVe d=200: kvantisér og mål R@1/R@5 ved k=1/4/8/16; noter delta mod FAISS PQ.
- Multitrådet 2‑bit på ældre x86 uden AVX‑512: mål throughput og p95 for at fange evt. degradering.
- Store korpora: 1M og 10M for at se memory‑/latency‑kurver, ikke kun 100K‑snapshot.
- Query‑blandinger: korte vs. lange queries; domænespecifik semantik vs. generiske embeddings.
Vores vurdering lige nu
Signalet er stærkt: træningsfri, data‑oblivious kvantisering med recall tæt på FAISS PQ og en håndgribelig ARM‑fordel i de viste tests. For teams med RAM‑pres er det værd at prøve nu – især med OpenAI‑lignende embeddings i højere dimensioner, hvor TurboQuant ser ud til at trives bedst i kildens tal.
Det mest positive er hvor lidt friktion API og build‑flow ser ud til at have. Men vær forsigtig i lave dimensioner, i stærkt domænespecifik semantik og i multitrådede 2‑bit‑workloads på x86, hvor FAISS kan have en mikrofordel. Man opdager først forskellen, når man sidder med det i hænderne.
