Qwen Flash Next naar 64GB-Macs, plus nuchtere tests op 16GB en 4GB

DwarfStar meldt Qwen3.8 Flash Next-ondersteuning voor 64GB-Macs via Metal, met SSD-opslag voor n-grams. Los daarvan laten tests op een RTX 4080 en een 4GB-laptop-GPU zien dat context, quantisatie en runtime minstens zo bepalend zijn als de modelnaam.

Qwen Flash Next krijgt een Metal-pad voor 64GB-Macs

DwarfStar ondersteunt volgens maker antirez nu Qwen3.8 Flash Next op Macs met 64GB geheugen. De gemelde snelheid is 50–70 tok/s generatie en meer dan 1.400 tok/s prefill; n-grams staan daarbij op SSD. Vooralsnog is dit uitsluitend een Metal-implementatie. Aankondiging en metingen.

Dit bouwt voort op de ochtendupdate van vandaag, waarin dezelfde tool nog DeepSeek V4.1 Flash vanaf SSD op DGX Spark demonstreerde. De nieuwe stap is dus niet een andere uitleg van die release, maar ondersteuning voor een ander model en platform. Interessant voor 64GB-Mac-bezitters die Flash Next lokaal willen proberen; de cijfers komen wel van de maker en zeggen nog niets over latentiepercentielen, geheugengebruik of kwaliteit.

100K context op 16GB: MTP helpt in één RTX-4080-test

Een gebruiker testte Qwen3.8 27B op een RTX 4080 met 16GB, ExLlamaV3 en 102.400 daadwerkelijke inputtokens. Zonder MTP rapporteert die 33,68 tok/s generatie; met vaste MTP k=2 en Q6-draftcache 56,48 tok/s. Prefill zakte in die vergelijking van 1.028,7 naar 980,2 tok/s. Configuratie en resultaten.

Dat maakt MTP hier een relevante knop voor lange agenttranscripten, maar geen algemene belofte: de test gebruikt een 3,0-bpw-quant, één runtime, twee requests en een nagenoeg volle VRAM-buffer. De auteur zag bovendien weinig geheugenwinst van Q4 tegenover Q6 voor de draftcache. Kopieer dus vooral de meetopzet en test eigen prompts, in plaats van de 68%-winst als verwacht resultaat te behandelen.

Een 4GB-laptop-GPU blijft bruikbaar — met smalle claims

Een test van circa twintig modellen op een laptop-RTX 2050 met 3,4GB bruikbare VRAM noemt NeoHorse-1-4B, een Qwen3.8-4B-variant en MiniCPM5-2B als bruikbare keuzes. De auteur draait ze volledig op de GPU met Vulkan, gequantiseerde KV-cache en flash attention, en meet ongeveer 32, 32 en 39 tok/s generatie. Test en flags.

De praktische waarde zit in de complete, beperkte configuratie: modelgewichten rond 2,5–2,8GB en expliciete cache-quantisatie. De eigen medische-fysica-, kennis- en codeproeven zijn geen onafhankelijke benchmark; vooral de conclusie over hallucinaties is daarom slechts een ervaringssignaal. Toch is het een bruikbaar tegenwicht voor configuraties die alleen op 16 of 24GB beginnen.

OpenArch wil architectuurcode leesbaar maken, maar is nog ruw

OpenArch verzamelt PyTorch-implementaties van onder meer Llama, Qwen, DeepSeek, Gemma, Kimi en GPT-OSS als leesbare referentie tussen paper en implementatie. Dat is vooral nuttig voor wie wil begrijpen waarom een nieuw model soms extra werk vraagt in inference-engines, bijvoorbeeld bij sparse MoE-lagen.

Niet verwarren met een complete train- of servingstack: de maker omschrijft het zelf als rauwe architectuurimplementaties. In de HN-discussie werd bovendien een fout in de Kimi-K2-MoE-routering gemeld, die de maker bevestigde. Het is daarmee interessant studiemateriaal, maar nog geen basis om modelgedrag of prestaties te valideren.

Verder nog

Meta Neural Band als Mac-controller: Show HN-project Kinesis leest sEMG-data van Meta’s band en koppelt gebaren aan onder meer desktopwissels, Mission Control en volume. De maker testte slechts één exemplaar; bovendien is onduidelijk hoe duurzaam toegang buiten Meta’s bedoelde ecosysteem blijft.
Guix en buildcaches: een beginnersverslag over Guix benadrukt een praktisch verschil met kanaalgebaseerde Nix-workflows: een verse commit kan lokaal compileren als de substitute build-farm nog geen binary heeft. Relevant voor reproduceerbare omgevingen waar onverwachte bronbuilds niet acceptabel zijn.
Een forge als statische site: deze verkenning combineert git-hosting met statische generatie. De discussie wijst op een reële trade-off: een browsergitclient over het dumb protocol kan trager zijn en meer serverdruk geven dan het smart protocol.