Lokale AI krijgt snellere AMD-paden, maar privacycontroles verdienen aandacht

Een Reddit-onderzoek wijst erop dat huggingface_hub gebruikte coding-agenten als telemetrie-header kan meesturen wanneer een Hub-call plaatsvindt. Voor lokale AI is er ook praktisch nieuws: een Windows-compatibiliteitslaag voor CUDA-gerichte software op AMD en nieuwe metingen rond SSD-streaming en RDNA4-inferentie.

Check je lokale Hugging Face-keten

Een gebruiker meldt dat huggingface_hub een registry met agent-herkenningen ophaalt, omgevingsvariabelen afzet tegen onder meer Cursor, Copilot en Claude Code, en de gevonden agentnaam bij Hub-verzoeken meestuurt. Volgens de analyse kan dit ook gebeuren via afhankelijkheden zoals transformers, faster-whisper of diffusers, bijvoorbeeld wanneer een model op naam wordt geladen in plaats van vanaf een lokaal pad. De oorspronkelijke analyse bevat de genoemde cachelocatie en variabelen.

Dat is relevant voor wie lokaal draait om metadata binnen het eigen netwerk te houden. De melding is geen onafhankelijke security-audit en bewijst niet dat inhoud of credentials worden verstuurd; de auteur stelt juist dat het om toolchainmetadata gaat. Wel is het een goede aanleiding om uitgaand verkeer te inspecteren, lokale paden te gebruiken waar dat past en offline-instellingen vóór imports te testen.

CUDA-gerichte Windows-software op AMD: vroeg, maar bruikbaar signaal

Het project CUDA-for-AMD-Windows combineert ZLUDA met ROCm/HIP om CUDA-gerichte Windows-applicaties op AMD-GPU’s te draaien. De bijbehorende lokale-AI-discussie noemt een gemelde overhead van circa 3%, maar die claim is niet hier onafhankelijk gemeten; een reactie wijst bovendien op beperkte GPU-ondersteuning.

Waarom dit telt: veel lokale-AI-tooling veronderstelt CUDA. Een compatibiliteitslaag kan experimenten op geschikt AMD-hardware vereenvoudigen, maar is geen vervanging voor een volwassen AMD-stack. Test dus per applicatie en kaart; verwachtingen over brede compatibiliteit zijn voorbarig. Discussie op Hacker News.

Eén DGX Spark draait DeepSeek V4.1 Flash vanaf SSD — nog geen coding-workstation

DwarfStar kreeg volgens maker antirez SSD-streaming voor DeepSeek V4.1 Flash. Hij rapporteert ongeveer 9 tokens per seconde op één DGX Spark en circa 22 tok/s met twee Sparks via RDMA. In dezelfde thread noemt hij de enkele-Spark-opstelling hooguit bruikbaar voor vraag-en-antwoordwerk, niet voor coding, en zegt hij dat prefill nog een implementatieprobleem heeft. Meting en beperkingen.

Dat maakt dit vooral een interessant bewijs dat de modelgrootte via opslagstreaming te omzeilen is, niet een advies om hardware te kopen: de gemelde snelheid en prefill-beperking bepalen of een workflow werkelijk werkbaar is.

R9V-patch richt zich op stabielere RDNA4-streaming

De R9V-vork van vLLM meldt een update die crashes bij n-gram-SSD-streaming moet verhelpen, plus ondersteuning voor Q4_K_XL. De maker zegt de fix ongeveer twaalf uur te hebben belast zonder instabiliteit; op twee R9700’s met 128 GB RAM rapporteert hij rond 100 tok/s voor Qwen3.8 Flash Next IQ4_XS en 50 tok/s voor Q4_K_XL. Ook noemt hij prefill-metingen van 1.5k tok/s bij PP512 en 2.6k bij PP8192. Project en update.

Dit is een nuttige patch voor precies die RDNA4-configuratie, maar geen reproduceerbare vergelijking met andere hardware of quants. De stabiliteitsclaim komt van de maker zelf en Q4_K_XL zou nog fijnafstemming nodig hebben.

Signal werkt aan registratie zonder telefoonnummer

Signal beschrijft in zijn communityforum een route naar registratie zonder telefoonnummer met zero-knowledge proofs. In de HN-discussie komt ook naar voren dat betaalgegevens in sommige voorgestelde routes de anonimiteit alsnog kunnen beperken. Het relevante onderscheid: dit is aangekondigde functionaliteit, geen bewijs dat iedereen zich nu al nummerloos kan aanmelden. Forumdiscussie via Hacker News.

Voor privacygevoelige communicatie is het interessant omdat een telefoonnummer vaak een harde identiteitskoppeling is. De resterende betaal-, abuse-prevention- en metadatakeuzes bepalen echter hoeveel winst de uiteindelijke implementatie oplevert.

Zoom op Linux zou X11-clipboard proactief lezen

Een melding op Mastodon, besproken op Lobsters, stelt dat de Linux-desktopclient van Zoom het X11-klembord leest zonder expliciete gebruikersactie. In de discussie is onduidelijk of een functie als remote control daarbij actief was en of er een opt-out bestaat; behandel dit daarom als een te verifiëren securitysignaal, niet als vastgestelde exfiltratie. Melding en tegenspraak.

De praktische les is beperkter maar nuttig: X11 geeft processen traditioneel ruime toegang tot het klembord. Wie gevoelige gegevens kopieert, kan Zoom op een apart account of met beperktere permissies draaien en de gebruikte sessie/configuratie controleren.

Verder nog

• 128 GB VRAM voor circa $3.000: een thuisbouwer rapporteert met vier AMD V620’s en 256 GB DDR4 ongeveer 1.300 tok/s prefill en 70 tok/s generatie voor Qwen3.8-next-flash W4A16 op 128k+ context. Dat is één configuratie met fors stroomverbruik (gemeld: 700–900 W bij prefill), geen algemene prijs-prestatiebenchmark. Specificaties en meting.
• Ghostty 1.4 krijgt focus op energiegebruik: Mitchell Hashimoto zegt dat de aankomende 1.4 beter zou presteren dan concurrenten op energie; het beschikbare bewijs is vooralsnog een gebruikerservaring op een MacBook Pro, geen onafhankelijke benchmark. Thread.