Kör llama.cpp-modeller direkt i Transformers — utan extra kod

xAI uppger: Grok 4.7 hårdare att jailbreaka och bättre på kod

xAI lanserar Grok 4.7 med en ny, större basmodell tränad på längre och svårare uppgifter. Modellen toppar LatchBios biosafety-benchmark och förbättrar resultaten på CursorBench — till oförändrat pris jämfört med Grok 4.6.

Grok 4.7 är vår mest kapabla modell för kodning och kunskapsarbete. Den arbetar längre på svåra uppgifter, kontrollerar sitt eget arbete noggrannare och levererar våra bäst kalibrerade säkerhetsskydd hittills.

xAI (officiell annonsering)

xAI har släppt Grok 4.7, en uppdaterad modell för kodning och kunskapsarbete. Modellen bygger på en ny, större basmodell jämfört med Grok 4.6 och har tränats med längre reinforcement learning på en uppgiftsmix som fokuserar på problem som tar många timmar att slutföra. På CursorBench 4.0 når Grok 4.7 46,3 procent mot 40,4 procent för föregångaren, enligt xAI. Priset är oförändrat: 2 dollar per miljon input-tokens och 6 dollar per miljon output-tokens.

Det som sticker ut utöver kodprestandan är säkerhetsprofilen. xAI uppger att Grok 4.7 är den starkaste modell de testat på refusals och jailbreak-motstånd, och att modellen toppar LatchBios biosafety-benchmark med 62,4 procent. Förmågan att verifiera sitt eget arbete och hantera längre kontext är också förbättrad — ett direkt svar på att agentiska arbetsflöden kräver att modellen håller ihop resonemang över längre tidshorisonter utan att tappa tråden.

För den som redan bygger med Grok 4.6 via API är uppgraderingen kostnadsneutral. Frågan är om förbättringarna på CursorBench och biosafety-benchmarks översätts till märkbar skillnad i verkliga koduppgifter — det är något som bara praktisk testning kan avgöra.

Tokenizers v1: upp till hundra gånger snabbare — och GPU:n slipper vänta

Hugging Face lanserar tokenizers v1 med dramatiskt förbättrad prestanda. Tokenisering har blivit en flaskhals när modeller accelereras och datasets växer — v1 producerar identiska token-ID:n som v0.23 men kan vara tiotals till hundra gånger snabbare.

Era GPU:er ska aldrig sitta och vänta på att CPU:n ska bli klar med tokeniseringen.

Hugging Face

Hugging Face har släppt tokenizers v1, en omskriven version av biblioteket med fokus på prestanda. Enligt Hugging Face är v1 ofta tio till hundra gånger snabbare än v0.23. API:et är oförändrat och v1 producerar identiska token-ID:n — det är alltså en ren prestandauppgradering utan migrationskostnader för befintliga pipelines.

Bakgrunden är att tokenisering länge inte var en flaskhals: modellerna var långsammare än förbehandlingssteget. Det har förändrats. När inferenshastigheten ökar och träningsdatasets växer till miljarder tokens börjar CPU-bunden tokenisering hålla tillbaka GPU-utnyttjandet. Tokeniseringsprocessen sker i fyra steg — normalisering, pre-tokenisering, modellsteg (BPE används av åtta av tio modeller i Hugging Faces mätning) och post-processing — och v1 optimerar hela kedjan.

Hugging Face skriver också att omskrivningen är tänkt att göra tokenizers till ett bibliotek som är värt att bidra till, vilket antyder att projektet tidigare inte prioriterats tillräckligt. För svenska AI-utvecklare och ML-ingenjörer som kör stora träningsjobb eller högtrafik-API:er är uppgraderingen direkt relevant: byt ut tokenizers-versionen och mät om CPU-steget fortfarande är en flaskhals i er pipeline.

Liquid AI: vision-language-modell tre gånger snabbare med speculative decoding

Liquid AI lanserar DSpark, en draft-modell för vision-language-modellen LFM2.5-VL-3B. Med speculative decoding uppger Liquid AI upp till 3,13 gånger snabbare dekodning på Apple M5 Max och 2,66 gånger på H100 — utan försämrad utdatakvalitet.

Liquid AI lanserar DSpark som en experimentell release för LFM2.5-VL-3B, en vision-language-modell på tre miljarder parametrar. DSpark är en draft-modell på 280 miljoner parametrar — en ökning på 8,9 procent ovanpå basmodellen — med en förenklad attention-only arkitektur i fyra lager. Tekniken bygger på speculative decoding, där draft-modellen genererar förslag som den större modellen sedan verifierar, vilket minskar antalet dyra forward passes.

Prestandasiffrorna är enligt Liquid AI: 3,13 gånger snabbare dekodning på Apple M5 Max, 2,66 gånger på H100 GPU och 2,62 gånger förbättrad end-to-end-latens. Stöd finns från dag ett för llama.cpp, MLX-VLM och SGLang — de tre ramverk som dominerar lokal och serverbaserad deployment av kompakta modeller.

Speculative decoding för vision-language-modeller är fortfarande ett relativt ungt område, och DSpark är märkt som experimentell. Men för svenska AI-utvecklare och ML-ingenjörer som optimerar VLM-deployment — oavsett om det gäller on-device-applikationer på Apple Silicon eller serverbaserade tjänster på H100 — är hastighetsvinsterna tillräckligt stora för att motivera ett test. Kompatibiliteten med etablerade ramverk sänker tröskeln ytterligare.

Google: krypterat långtidsminne för AI — inte ens Google kan läsa det

Google presenterar en ny arkitektur för Private AI Compute som ger AI-assistenter persistent minne över sessioner, med end-to-end-kryptering där nycklarna aldrig lämnar användarens enhet. Lösningen ska kombinera kontinuitet med dataskydd på on-device-nivå.

Google presenterar ett persistent memory-lager för sin Private AI Compute-plattform. Systemet använder hardware-enforced secure enclaves i molnet för temporär dekryptering under bearbetning, men krypteringsnycklarna förblir enbart på användarens personliga enheter. Enligt Google Private AI Compute Team är datan oåtkomlig även för Google självt. Lösningen adresserar ett grundläggande problem med stateless AI-system, där all kontext raderas efter varje session.

Spänningen mellan AI-assistenternas nytta och dataintegritet har länge varit olöst. Persistent minne gör assistenter mer användbara — de kan komma ihåg preferenser, tidigare uppgifter och pågående projekt — men kräver att data lagras i molnet, vilket skapar integritetsrisker. Googles arkitektur försöker lösa detta genom att separera beräkning (i molnet, i en secure enclave) från nyckelhantering (på enheten). Det är en teknisk kompromiss snarare än ett fullständigt on-device-system, men det är ett steg mot att göra molnbaserat AI-minne mer acceptabelt ur ett integritetsperspektiv.

Vad betyder det för dig: om du bygger AI-applikationer med persistent kontext kan Googles arkitektur bli en referensmodell för hur man hanterar långtidsminne utan att kompromissa med användarnas dataskyddskrav — särskilt relevant i EU-sammanhang där GDPR ställer höga krav på dataminimering och kontroll.