Open-sourcebasics versnellen; FreeToken-fork en hardware-RNG-signaal vragen om gerichte tests

Daniel Lemire rapporteert nieuwe, soms forse snelheidswinsten in libraries als ada, fast_float, simdjson, simdutf en CRoaring — op één vaste Xeon-testmachine en met uiteenlopende auteurs. Voor lokale inference is een FreeToken-fork interessanter als waarschuwing dan als kant-en-klaar recept: hij voegt nieuwe modelpaden toe, maar MTP was in de gedocumenteerde 2×3090-proef netto trager.

Ook een HN-discussie over AMD’s RDRAND laat zien waarom hardware-RNG-aanroepers de successtatus niet mogen negeren. En een KV-cachegraft die modelgedrag zonder gewichtswijziging wil omschakelen is technisch interessant, maar voor security geen controlelaag.

Zes mature libraries krijgen meetbare versnellingen

Daniel Lemire bundelt een zomer aan optimalisaties in veelgebruikte open-sourcebibliotheken. Hij bouwde daarvoor elke commit opnieuw en benchmarkte op één Intel Xeon Gold 6548N, relatief aan augustus 2024. De resultaten zijn concreet, maar geen universele snelheidsclaims: hardware, invoercorpus en versie bepalen hier sterk mee.

Een paar opvallende cijfers uit die reeks: Go-Roaring zou voor sommige iterators 4,5–5,9× sneller zijn geworden; ada ging op een corpus van 100.000 URL’s in zes weken van 0,54 naar 1,28 GB/s; fast_float meldde 43% respectievelijk 70% winst op twee bestanden. Voor de C++26-reflectieroute van simdjson noemt hij 1,6× en 2,1× snellere serialisatie op twee JSON-corpora; simdutf zou ASCII-validatie van 83 naar 160 GB/s hebben gebracht.

De relevante les is niet dat AI automatisch code sneller maakt. Lemire zegt zelf dat hij per bijdrage niet kan vaststellen hoeveel AI erbij betrokken was; de gebruikte technieken waren volgens hem bekend. Wel lijkt het goedkoper te zijn geworden om veel optimalisatiehypotheses uit te proberen. Voor teams die deze libraries indirect via Node.js, databases, compilers of browsers gebruiken, is dat reden om na een upgrade eigen representatieve workloads te meten — vooral waar parsing een zichtbaar deel van CPU-tijd is. Overzicht en meetcontext

FreeToken-fork verbreedt modelpaden, maar MTP verliest in de eerste proef

Een nieuwe, Apache-2.0-gelicentieerde FreeToken-fork bouwt voort op de route die we in de middagupdate van zondag bespraken: experts van grote MoE-modellen kunnen naar host-RAM of NVMe, terwijl CPU en GPU samenwerken. De fork voegt volgens de maker onder meer DeepSeek V4.1 Flash, Qwen3.8 Flash Next met vision via image_url, tensor-parallel laden en een MTP-draftpad toe.

De eerste meting is vooral nuttig als tegenwicht voor de aanname dat speculative decoding altijd helpt. Op twee RTX 3090’s, met Flash Next in NVFP4 en expert-offload, rapporteert de maker bij 256 outputtokens circa 48,0 tok/s greedy zonder MTP, maar 21,5 tok/s met MTP, ondanks ongeveer 56% acceptatie. In een meer gelijkgetrokken eager-configuratie noemt de post wél ongeveer 1,5× winst (17,2 tegenover 11,4 tok/s); CUDA Graphs en scheduling veranderen de vergelijking dus wezenlijk.

Dat maakt de fork interessant voor wie deze specifieke modelgeneratie op oudere consumenten-GPU’s wil onderzoeken, maar niet als drop-in productieadvies. De resultaten zijn zelf gerapporteerd, er is maar één machineprofiel en de maker noemt de fork expliciet ruw. Bovendien staat de Engram-tabel van DeepSeek V4.1 volgens de post standaard op schijf: plan dus ook opslag, niet alleen VRAM. Fork, configuratie en meetopzet

AMD-RDRAND-discussie lijkt vooral een statusbit-probleem

Een hooggeplaatste HN-draad over AMD’s random-instructie begon met de stelling dat RDRAND geen nul zou kunnen leveren. De opgeslagen reacties nuanceren dat scherp. Twee deelnemers melden reproductie op Zen 2 bij rdrand16, maar een andere analyse stelt dat nulwaarden wel voorkomen: de carry flag (CF) wordt soms op fout gezet, waarna de aanroeper volgens de instructiespecificatie opnieuw moet proberen.

Een gedeeld testprogramma draaide een miljard 16-bit-aanroepen en telde 15.312 gevallen met CF=0; die hadden allemaal waarde nul. Dezelfde reactie meldt dat de geldige waarden — dus na uitsluiting van die mislukte aanroepen — uniform leken. Dat is geen onafhankelijke AMD-bevestiging en ook geen bewijs voor alle Zen-generaties of wrappers, maar het onderscheid is praktisch: wie het statusbit negeert en de registerinhoud toch gebruikt, kan een artefact als willekeurige nul behandelen.

Gebruik daarom geen ruwe hardware-instructie als directe applicatie-API zonder de foutsemantiek te volgen en retries af te handelen. Voor cryptografisch gevoelige code blijft een goed onderhouden OS-CSPRNG de verstandige laag; deze draad is geen reden om daar zelf omheen te programmeren. HN-discussie met test en tegenlezing

Een KV-graft is verwisselbaar modelgedrag, geen safety-grens

Het nieuwe project phantom-kv traint een kleine bank key/value-tensors en plaatst die als voorafgaande toestand in de KV-cache, zonder de modelgewichten te wijzigen. Volgens de maker kun je de graft per request laden of verwijderen; de basisgewichten blijven dan byte-identiek. Het project positioneert dit als een alternatief voor permanente weight edits of runtime-hooks.

Technisch is vooral die scheiding tussen checkpoint en gedrag interessant: een kleine, verwisselbare toestand kan in theorie ook voor legitieme persona-, stijl- of domeinexperimenten dienen. Maar de beschikbare demo’s en evaluaties komen volledig van de maker. Die meldt zelf dat het effect in lange sessies na grofweg 2–4K tokens afneemt. In de discussie ontstaat bovendien terecht debat of dit functioneel dichter bij een vooraf berekende soft prompt ligt dan bij een fundamenteel nieuw veiligheidsmodel.

Voor security volgt daar juist een beperking uit: als een cacheblob gedrag kan sturen buiten de zichtbare tekstlaag, moet die blob als uitvoerbare modelconfiguratie worden beheerd — met herkomst, hashes, toegangscontrole en evaluaties. Hij mag nooit een vervanging zijn voor sandboxing, capabilities of authorisatie rond tools. Project en technische toelichting

Verder nog

2× RTX 3090 met volledige Qwen-context: een gebruiker rapporteert met stock vLLM 0.29, tensor parallelism 2 en een Red Hat INT4-quant voor Qwen3.8-27B ruim 70 tok/s single-stream decode, ruim 160 tok/s bij concurrency en meer dan 10.000 tok/s prefill; de opzet zou de volledige 262K-context kunnen dragen. De cijfers komen uit één zelfbeheerde configuratie en echte taakkwaliteit is niet geëvalueerd, maar de exacte flags en hardware maken dit een bruikbaar reproduceerbaar startpunt voor Ampere-bezitters. Configuratie en meetnotities
Supra2-IMG: klein open text-to-image-experiment: de maker publiceert een 100M-parameter DiT-model en claimt 256×256-generatie in ongeveer twee seconden op GPU en twintig seconden op CPU, na training op één H100. Dat is een opvallend laagdrempelige footprint als het reproduceert, maar “state-of-the-art”-kwaliteit is uitsluitend een makerclaim en er is nog geen onafhankelijke vergelijking in de beschikbare context. Aankondiging en model-link