De fleste har prøvet det: en frontier‑model, der skinner i demoen, men sprænger budgettet i drift. Pinterest valgte en anden vej. Ifølge VentureBeat fjernede de Qwen3‑VLs vision‑encoder og skiftede den ud med egne, præcomputede multimodale embeddings. Resultatet: cirka 90 procent lavere inferensomkostninger og omkring 30 procent bedre nøjagtighed – på en platform med cirka 620 millioner månedlige brugere. Det er ikke en laboratorietest.
Pointen er arkitektur, ikke hype. I stedet for at køre hver eneste billedforespørgsel gennem en tung multimodal model, flytter Pinterest arbejdet offline: precompute, indeksér, og lad en slankere runtime hente og kombinere svar hurtigere. Det matcher, hvad vi ser i praksis hos kunder med billedmængder i tocifrede millionklasser.
Hvad Pinterest helt konkret gjorde
VentureBeat beskriver, at Qwen3‑VL var basen for Pinterests shopping‑assistent, Navigator 1. Teamet fjernede vision‑encoderen og fine‑tunede modellen til at arbejde direkte på Pinterests egne multimodale embeddings. De embeddings opbygges og opdateres uden for modellen og føder konteksten ind ved inferens.
Ved at bruge egne embeddings kunne Pinterest blande billedindhold, pin‑metadata og brugersignaler i ét repræsentationslag. Det lag beregnes offline, opdateres løbende og ligger klar ved søgning eller anbefaling. Dermed undgår man at køre en vision‑encoder for hvert kald. Det ændrer driftsøkonomien fundamentalt.
Hvorfor det sparer penge
Frontier‑kald koster – i GPU‑tid, i tokens og i ventetid. VentureBeat citerer Pinterests CTO for, at per‑billede runtime‑encoding giver omkring 20× dårligere latency. Flyttes encoding ud af hot path, kan man batch’e, kvantisere og presse GPU‑udnyttelsen højt, mens resultater caches i et indeks.
Precompute flytter den dyre del til planlagt batch‑compute, hvor kapacitet er billigere og mere effektiv. I kørselstiden henter man embeddings, scorer kandidater og genererer et kort svar. ANN‑indeks og kvantisering hjælper yderligere. I vores erfaring betyder IOPS på embedding‑store og cache‑hit‑rate ofte mere end “flere GPU’er”.
Hvorfor nøjagtigheden steg
En lettere runtime kan godt blive mere præcis, når repræsentationen er domænetilpasset. Pinterest folder metadata, købssignaler og deres smagsgraf ind i embeddings. I discovery‑use cases slår datatilpasning ofte modelstørrelse. Vi har set det samme hos en retailkunde, hvor en lille reranker vandt over en større model, fordi embeddings bar butikkens taksonomier og attributter ind i scoringen.
VentureBeat beskriver smagsgrafen som et dynamisk kort over præferencer – ikke en social graf, men hvad brugeren faktisk foretrækker over tid. Det påvirker rangering mere end rene klikmønstre, som ofte er støjende.
Hvad Pinterest ofrede og de reelle tradeoffs
Precompute låser noget fleksibilitet. Nye signaler kræver re‑embedding eller retrain. Der er en initial regning for at bygge hele kataloget. Og realtidsændringer forplanter sig ikke øjeblikkeligt. Til gengæld falder marginalomkostningen pr. forespørgsel markant.
Der er også governance. Embeddings med brugerdata kræver versionsstyring, datapolitikker og sletteflows (GDPR). Vi har en kunde med over 100 millioner billeder, hvor vi byggede selektiv re‑embedding, så kun påvirkede rækker genberegnes. Ikke glamourøst, men det er det, der gør audits håndterbare.
Operativ drift i praksis
At fjerne vision‑laget er én ting; at drive det er en anden. Du skal have en stabil precompute‑pipeline (daglig eller ugentlig afhængigt af ændringstempo), versionsstyring af embeddings og målinger, der dækker p50 og p99 latency, GPU‑udnyttelse, throughput og fejlrate. AWS’ materiale om observability for LLM‑inferens rammer pointen her (relevant også uden SageMaker).
Vi kører typisk to spor i monitorering: 1) kvantitativt: GPU‑utilization, p50/p99 latency, memorytryk, indeks‑IOPS, cache‑hit‑rate, cost per 1.000 forespørgsler; 2) kvalitativt: offline relevansbenchmarks, sandkasse‑A/B og løbende stikprøver. Når begge spor peger samme vej, kan man trygt skrue på kvantisering og batchstørrelser.
Hvorfor det betyder noget for jer
Hvis du driver visuel søgning, discovery eller shopping i stor skala, er per‑request vision‑encoding sjældent bæredygtigt. Pinterest‑casen bekræfter en praktisk vej: precompute og proprietære embeddings gør multimodale funktioner økonomisk mulige. Det kræver nogle uger med ingeniørarbejde, men regnestykket tipper hurtigt, når kataloget når få millioner objekter.
Vi testede for nylig et tilsvarende setup hos en e‑commerce‑kunde med over 100 millioner billeder. Én produktkategori havde atypiske farvekoder i beskrivelser, hvilket skævvred resultaterne; til gengæld faldt gammel klik‑bias, og nye produkter rangerede tidligere. Ikke perfekt hele vejen – men netto vandt precompute på pris og svartid.
Sådan bygger man det uden at brænde budgettet
Kogt ned til en referencearkitektur: vælg/byg et embedding‑lag, der samler billede og metadata. Precompute i batch. Læg i et højtydende indeks. Hent kandidater via retrieval. Slut af med en let generativ eller klassisk reranker. Qwen3‑VL eller en anden base kan stadig indgå – bare ikke som flaskehals i vision‑delen.
Tre klassiske pengeslugere: 1) per‑request vision‑encoding, 2) dårlig batching/manglende kvantisering, 3) fravær af observability, så man overkompenserer med større modeller. Fiks de tre, og man nærmer sig Pinterests besparelsesniveau – uden at tallene nødvendigvis matcher én til én.
Praktisk tjekliste
- Data og etik: Kortlæg tilladte metadata, billedfelter og brugersignaler. Beslut slette‑/redigeringsflows.
- Embeddings: Vælg eller træn multimodale embeddings. Test mod jeres domæneord/attributter. Kvantisér hvis muligt.
- Precompute‑pipeline: Batch‑jobs med retry, versionering og delvis re‑embedding ved ændringer. Dagligt eller ugentligt.
- Indeks og retrieval: ANN‑indeks med høj IOPS. Mål recall og latency. Cache varme nøgler tæt på edge.
- Reranking og generering: Hold modellen lille. Kalibrér mod jeres egen relevansscore.
- Observability: Overvåg p50/p99 latency, GPU‑utilization, tokenforbrug, cache‑hit‑rate, indeks‑IOPS samt kvalitetsdrift på relevansbenchmarks.
- Drift og økonomi: Mål cost per 1.000 forespørgsler før/efter. Sæt SLO’er og alarms.
Begrænsninger og åbne spørgsmål
VentureBeat giver klare nøgletal, men uden fuld målemetodik. Det er uklart, hvilke workloads 90‑procents‑tallet dækker, og om det er ren inferens for et specifikt flow fremfor total TCO. Samme for ~30 procent i nøjagtighed: stærkt signal, men ikke en offentlig benchmark.
Licenser: VentureBeat peger på permissive licenser som muliggører for at tilpasse åbne vægte. Qwen3‑VLs licens kan variere på tværs af versioner, og vi har ikke set officiel dokumentation for præcis, hvordan man fjerner vision‑encoderen uden følgeeffekter. Gør egen due diligence.
Historisk linje og hvorfor Pinterest kunne gøre det
Ifølge VentureBeat har Pinterest i årevis arbejdet med åbne modeller til visuel søgning (BERT‑varianter, CLIP, Pin‑CLIP finjusteret til platformens data). Den disciplin omkring embeddings og datainfrastruktur gør forskellen. Det her er ikke fra nul til helteniveau på en sprint; det er lag på lag af domænespecifik repræsentation, der gradvist slår en generisk frontier‑model.
Lektien: unikke data skal ind i repræsentationen, ikke kun i prompts. Det er også Madrigals pointe i interviewet hos VentureBeat og flugter med vores erfaringer, når kunder kobler interne taksonomier og attributter direkte til embeddings – hvorefter en mindre model ofte træffer bedre valg.
Drift og kadence i hverdagen
Hvor ofte genberegnes embeddings? Oftere end man tror, sjældnere end man frygter. E‑commerce med sæsoner og kampagner ender ofte ugentligt (med ekstra kørsel før events). Langhale‑kataloger kan nøjes med månedlige jobs plus daglige inkrementer. En kunde startede daglige batch‑runs, men flyttede til hver tredje dag, fordi kvalitetsdrift først kunne måles meningsfuldt på den kadence.
Versionering er redningsvesten. Giv embeddingsæt semantiske versioner, log datakilder, og gem samplede nærmeste naboer pr. version. Små greb som at inkludere versionsnummer i indeksnøglen gør rollback udramatisk.
Hvor besparelserne typisk opstår
Tre tydelige gevinster: 1) fjern vision‑encoding fra hot path (den store), 2) kvantisér embeddings til 8 eller 4 bit uden mærkbar retrieval‑nedgang, 3) batch bedre i både precompute og scoring, så GPU‑udnyttelse stiger fra fx ~40 til ~70 procent. Det sænker både regningen og svartiden.
I to anonymiserede cases brugte vi cirka 4–8 ugers intensivt arbejde på at nå proof‑of‑value (dataflow, precompute, indeks og simpel reranker). Ikke gratis – men over 3–6 måneder blev indsatsen opvejet af lavere marginalomkostninger.
Hvor konkurrenterne vil gå hen
Modeludbydere vil svare med bedre vision‑encodere, lavere tokenpriser og indbyggede retrieval‑hooks. Cloud‑platforme vil tilbyde serverløse indeks og hybrid‑søgning. Fornuftigt alt sammen – men casen peger på, at ejerskab over repræsentationen og data er det egentlige våben, ikke nødvendigvis flere parametre.
Løsningen er ikke universel. Hvis use casen kræver helt åben generering på nye domæner, giver frontier‑kald stadig mening. Vi anbefaler ofte en hybrid: proprietære embeddings og retrieval til 80–90 procent af trafikken, frontier som fallback til outliers og frie samtaler. Pragmatisk, og det virker.
Det lille, men vigtige, eftersyn
Når man fjerner en vision‑encoder og kører på egne embeddings, skal inputformat, normalisering og tekst‑tokenisering være konsistente. Vi har tidligere ændret billedbeskæring i precompute og set nærmeste naboer glide et par procentpoint – p99 afslører det før brugerne gør. Små skævheder er uundgåelige; mål dem, ret dem, videre.
Husk: tallene i VentureBeat er stærke pejlemærker, ikke facit. Brug dem som retning, og mål på jeres egne workloads.
