Unsloth zet DeepSeek lokaal in; Plex-aanvallen en Mercury 3 vragen om eigen tests

Unsloth maakt DeepSeek-V4.1-Flash-1017 lokaal inzetbaar op systemen met veel RAM, maar de benodigde SSD-streaming en beta-status maken dit geen gewone desktopupgrade. Urgenter is Plex: een onderzoeker zag een keten voor oudere servers in het wild misbruikt worden voor cryptomining en proxysoftware. Ook Mercury 3 presenteert een snelle nieuwe inference-aanpak, maar de sterke kwaliteitsclaims komen vooralsnog van de maker.

Unsloth brengt DeepSeek-V4.1-Flash-1017 naar 1-bit en SSD

Unsloth 0.1.909-beta voegt een lokale route toe voor DeepSeek-V4.1-Flash-1017. Volgens de releasenotes past de 552B-parameter-MoE met 16B actieve parameters bij 1-bit-quantisatie in ongeveer 125 GB geheugen, zolang de Engram-tabel op SSD blijft; de 4-bit-route vraagt circa 300 GB. De release bevat daarnaast alpha-ondersteuning voor FSDP2 bij LoRA, QLoRA en full fine-tuning, en een MCP-commando om Claude Code, Codex of Cursor aan de lokale omgeving te koppelen.

Dat is een concrete vervolgontwikkeling op de ochtendupdate van vrijdag, die Unsloth 0.1.908-beta behandelde: toen ging het om routing en promptcache voor lokale codingagents; nu komt er een specifieke, zeer grote DeepSeek-route plus gedistribueerde training bij. Het verschil met de modelrelease zelf is ook praktisch: DeepSeek-V4.1-Flash-1017 werd al zaterdagmiddag aangekondigd, maar Unsloth voegt een eigen runtime- en desktopintegratie toe.

De geheugen- en kwaliteitscijfers zijn projectclaims. Wie dit test, moet naast tokensnelheid vooral meten wat SSD-streaming doet met prefill, lange context, gelijktijdige requests en foutgedrag. Voor MCP-gestuurde agents blijven modeldownloads, datasets en trainingsacties echte privileges: koppel zo’n server niet zonder rechten-, netwerk- en opslaggrenzen aan een gewone werkmachine.

Unsloth 0.1.909-beta: volledige releasenotes

Oudere Plex-servers worden volgens honeypotonderzoek actief misbruikt

Een securityonderzoeker meldt exploitatie in het wild van een kwetsbaarhedenketen voor oudere Plex Media Server-versies. De keten bestaat volgens het verslag uit CVE-2026-96652, -96654, -96655 en -96656. Plex had op 1 september een belangrijke update voor versie 1.43.2 en ouder gemeld; de onderzoeker zette vervolgens een kwetsbare honeypot op en zag vanaf 17 oktober exploitpogingen.

De waargenomen payloads bevatten volgens de auteur een cryptominer en later ook myawesomeproxy, software die extern gebruik van de internetverbinding mogelijk maakt. De auteur deelt netwerksporen, hashes en detectieregels, maar dit blijft observatie uit één eigen honeypot; het bewijst niet hoeveel installaties zijn geraakt of welke varianten overal worden gebruikt. Een HN-reactie stelt dat de getroffen oudere versie al in augustus is gepatcht.

Voor beheerders is de actie helder: inventariseer Plex Media Server, update wanneer een oude versie draait en zet de beheer- of streamingdienst niet onnodig open naar internet. Controleer bij een publiek bereikbare oude installatie ook op onverwachte processen, uitgaand verkeer en containers. De bron onderbouwt geen universele schoonmaakprocedure voor een al gecompromitteerde host.

Onderzoeksverslag met CVE’s, waarnemingen en indicators · HN-discussie

Mercury 3 belooft diffusion-inference op hoge snelheid, maar onafhankelijke vergelijking ontbreekt

Inception introduceert Mercury 3, een commercieel diffusion-based taalmodel met een contextvenster van één miljoen tokens. De maker claimt 1.068 tokens per seconde op NVIDIA-GPU’s, 4–8× de snelheid van GPT-6 Luna en Claude Haiku 5.5, en een API die compatibel is met OpenAI. De tijdelijke introductieprijs is volgens Inception $0,10 per miljoen inputtokens en $0,35 per miljoen outputtokens.

De technische inzet is interessant voor agenten: diffusion-modellen genereren volgens de maker via iteratieve denoising in parallel in plaats van strikt token voor token. Inceptions eigen proef op vijftig Mind2Web-navigatietaken meldt 50% succes voor Mercury 3; het bedrijf positioneert het daarom voor browseragents, realtime search, tutoring en support.

Dit zijn allemaal leveranciersmetingen en partnerverklaringen. In de HN-discussie wordt terecht gevraagd naar prestaties bij andere reasoning-instellingen en naar tijd tot taakvoltooiing; die vergelijking staat niet in de beschikbare aankondiging. Zie Mercury 3 daarom als een interessante API-kandidaat voor latencygevoelige flows, niet als aangetoonde vervanger voor een bestaand model. Test met eigen tools, foutkosten, lange context en volledige agentlooptijd.

Inception: Mercury 3, prijzen en eigen evaluaties · HN-discussie

CERN en Mistral willen één foundationmodel voor colliderfysica verkennen

CERN en Mistral hebben een intentieverklaring getekend voor een strategisch partnerschap rond AI voor wetenschap. Het eerste doel is een pretrained Large Physics Model voor colliderfysica, getraind op miljarden gesimuleerde proton-protonbotsingen van de LHC. Het beoogde model moet meerdere taken ondersteunen, van reconstructie en deeltjesidentificatie tot het signaleren van onverwachte patronen en detectorontwerp.

De relevantie zit in de verschuiving van losse gespecialiseerde ML-stappen naar een mogelijke gedeelde modelbasis over de reconstructieketen. CERN wijst op ongeveer één exabyte aan opgeslagen LHC-data en een verwachte vertienvoudiging van botsingen met de HL-LHC rond 2030. De samenwerking is bovendien een concreet Europees AI-infrastructuursignaal, niet alleen een modelaankondiging.

Maar het gaat nadrukkelijk om ambitie en onderzoek: er is geen model, trainingsset, licentie, evaluatie of tijdpad voor externe gebruikers aangekondigd. Ook is nog niet aangetoond dat één foundationmodel gespecialiseerde methoden in echte fysica-analyses kan vervangen of verbeteren. Lees dit als een langlopend onderzoeksprogramma waarvoor reproduceerbaarheid, validatie en toegang tot de resultaten nog open vragen zijn.

CERN en Mistral over de intentieverklaring en het beoogde model · HN-discussie

KiviDB probeert Redis-compatibiliteit met ingebouwde vectorzoektocht

Het nieuwe KiviDB is een in Rust geschreven, multi-threaded in-memory database die RESP2 en RESP3 spreekt en daardoor bestaande Redis-clients kan gebruiken. Het project biedt ook Redis Stack-achtige FT.*-commando’s voor full-text- en vectorzoektocht, snapshots, een optionele append-only file en optionele Lua- en TLS-builds. De standaardpoort is 6380, zodat het naast een bestaande Redis-installatie kan draaien.

De repository publiceert scripts en een afgebakende benchmark op twee AWS Graviton3 bare-metalservers: bij gepipeline-de GETs met 100-bytewaarden meldt KiviDB 21,2 miljoen operaties per seconde, tegenover 9,1 miljoen voor Dragonfly en 2,4 miljoen voor Redis 8.10. Zonder pipelining lag Dragonfly in diezelfde test juist iets voor. Bij vectorzoektocht daalt KiviDB bij hogere ef volgens de tabel achter Dragonfly, terwijl de indexopbouw ook langzamer is.

Dat maakt het vooral een kandidaat voor een afgebakende proef, niet een drop-in productiekeuze op basis van één throughputgetal. De maker erkent in de HN-discussie dat er nog geen onafhankelijke verificatie is, dat niet alle datatypes en commands in de benchmark zitten en dat vergelijkingen met onder meer Valkey en Kvrocks nog onvolledig zijn. Controleer ook de AGPL-3.0-licentie, replicatie-, failover- en herstelgedrag, en wees voorzichtig met io_uring in containers: Docker kan die standaard blokkeren, waarna KiviDB naar Tokio terugvalt.

KiviDB: compatibiliteit, configuratie en benchmarkmethode · HN-discussie over ontbrekende vergelijkingen

Wine verschijnt als experimentele OpenBSD-port voor 64-bit Windows-software

Een voorstel voor de OpenBSD-portsboom brengt Wine naar OpenBSD. De kernoplossing emuleert de %gs-prefix, omdat OpenBSD gsbase niet op dezelfde manier kan zetten als Wine verwacht. Volgens de indiener is tientallen 64-bit Windows-programma’s getest, waaronder games; als lichtgewicht proef wordt Notepad++ genoemd.

De grens is groot: WoW64 werkt niet, dus 32-bit Windows-programma’s doen vooralsnog niets. De ingebouwde Wine-tests zijn ook uitgeschakeld omdat zij X-servertoegang vereisen en sommige hangen. De auteur adviseert testers daarom een aparte, niet-geprivilegieerde gebruiker te gebruiken en noemt het zelf software op eigen risico.

Dit is interessant voor OpenBSD-gebruikers die incidenteel 64-bit Windows-software willen proberen, maar geen stabiele compatibiliteitslaag. Een HN-reactie meldt dat Wine-upstream huiverig is om OpenBSD-onderhoud op zich te nemen en dat de %gs-emulatie vermoedelijk niet upstream kan. De port kan dus een lokale patchset blijven met bijbehorende onderhoudslast.

OpenBSD-portsvoorstel met grenzen en teststatus · HN-discussie over upstreaming

Verder nog

• Ming-3.0 opent vijf speechmodellen: Ant Group kondigt vijf modellen in drie families aan: TTS, audio-understanding/toolgebruik en ASR. De Flash-audiovariant heeft volgens de post 126B parameters waarvan 6,5B actief zijn; de beschikbare aankondiging bevat nog geen modelkaart, licentie of onafhankelijke evaluatie. Aankondiging
• Lokale DeepSeek-meting op Apple Silicon: een gebruiker meldt ongeveer 35 tok/s decode voor DeepSeek V4.1 Flash bij 3-bit mixed quantization op een 256GB M5 Ultra Mac Studio; een reply noemt voor LocalCode ongeveer 48 tok/s decode en 3.500 tok/s prefill. Dit zijn losse praktijkmetingen zonder gedeelde prompt, runtimeconfiguratie of kwaliteitscontrole, dus hooguit een aanwijzing dat de modelgrootte nu lokaal wordt uitgeprobeerd. Gebruikerspost · reply met tweede meting