Flash Next haalt miljoen-tokenmeting op Strix Halo; lokale beslismodellen en herkomstbewijzen krijgen scherpere grenzen

Halogen 0.12.0 laat in één 128GB-Strix-Halo-test zien dat Qwen3.8 Flash Next bij een miljoen tokens context sneller decodeert, maar de koude prefill blijft bijna achttien minuten duren. Tegelijk verschijnen met Von en een kleine Doom-proef nieuwe, lokale meetpunten voor Jev-achtige beslismodellen: lage latency en taakprestatie blijken verschillende eigenschappen. Voor beeldprovenance biedt ZK-JPEG een interessant bewijs-pad, maar het bepaalt nog niet welke beeldbewerkingen geloofwaardig zijn.

Flash Next op 1M context: sneller decode, nog steeds een dure koude start

Halogen 0.12.0 claimt een regressie bij diepe context te hebben gerepareerd voor Qwen3.8 Flash Next op een Ryzen AI Max+ 395 met 128GB geheugen. In een vergelijking op dezelfde machine, sessie en prompts meldt de auteur bij 1.004.581 tokens 38,3 tok/s decode, tegenover 27,3 in 0.11.10. De koude prefill zou stijgen van 790 naar 937 tok/s, maar duurt daarmee nog altijd 17,9 minuten. Een vervolgbeurt die de promptcache gebruikt, zou volgens dezelfde post na ongeveer 0,55 seconde aan de eerste token beginnen. Meting, configuratie en release-notes

Dit is een concrete stap na de ochtendupdate van woensdag 16 september, die een 64GB-Mac-route met SSD-expertstreaming beschreef: hier gaat het om een nieuwe Halogen-versie, een 128GB-APU en specifiek gemeten miljoen-tokencontext. De praktische les is dubbel. Voor sessies die lang blijven leven kan cachehergebruik de initiële kost verbergen; voor eenmalige agenttaken of vaak wisselende context maakt een prefill van bijna achttien minuten dit geen interactieve oplossing.

De cijfers zijn nog geen algemene Strix-Halo-benchmark: de 1M- en 262k-metingen zijn elk één koude aanvraag, met greedy decoding en een specifieke configuratie (HALOGEN_ROPE_YARN=4, HALOGEN_CTX=1048576). De auteur vraagt expliciet om reproducties. Behandel de update dus als een bruikbaar testrecept, niet als vaststaande performancegarantie.

Von en Doom-test maken de Jev-ruil meetbaar, niet beslist

Von presenteert zich als een open, 395M-parameter ‘System One’-alternatief voor Jev dat op CPU met 1–2GB geheugen draait en volgens de maker in 25–300 ms antwoordt. In reacties is er al een belangrijke grens: een onafhankelijke gebruiker wijst erop dat Von slechts 512 tokens context heeft, waar Jev in diens praktijk veel langere beslissingen verwerkt. Aankondiging, model en discussie

Een afzonderlijke proef laat Jev, Laya, een gefinetunede ModernCE en Qwen3.5-4B via tekstuele spelstatussen acties kiezen in twee ViZDoom-scenario’s. Over acht seeds per controller rapporteert de auteur voor Jev gemiddeld 5,63 kills in Defend the Center, tegenover 1,25 voor Laya en ModernCE; de gemeten mediane call-latency is respectievelijk 117,3, 16,2 en 7,6 ms. In Health Gathering liggen de overlevingstijden dichter bij elkaar. Opzet, tabellen en video

Dit is een inhoudelijke vervolg op de namiddagupdate van vrijdag 18 september, die Laya en OpenJev als vroege lokale alternatieven besprak. Er ligt nu zowel een nieuw compact model als een test met vaste speladapter, vaste acties en meerdere seeds. Maar een Doom-controller meet geen routing, moderation of rubric scoring, en Jev draaide via een gehoste API terwijl de andere modellen lokaal liepen. Gebruik dit daarom om eigen foutkosten, contextlengte en latencybudget te testen — niet om één algemene winnaar uit te roepen.

RSA-896 gefactoriseerd met GPU-vloot, zonder nieuwe RSA-doorbraak

Een project meldt de factorisatie van RSA-896 door CADO-NFS naar GPU’s te porten en ongebruikte capaciteit te orkestreren. Volgens de toelichting draaide de klus maximaal op 2.048 GPU’s, in totaal ongeveer dertig GPU-jaren verdeeld over tien dagen. De auteur benadrukt dat hiervoor geen nieuw factorisatie-algoritme is gevonden en dat het geen nieuwe bedreiging voor ingezette sleutels oplevert. Projectdetails in de HN-discussie

Dat laatste voorbehoud is belangrijker dan de spectaculaire capaciteit: het resultaat bewijst vooral dat bestaande number-field-sieve-software en infrastructuur op een GPU-vloot te combineren zijn. Het verandert niet zomaar de cryptografische veiligheidsmarge van actuele sleutels. De discussie corrigeert bovendien de omschrijving ‘exponentieel’: de general number field sieve is subexponentieel. Zonder onafhankelijke reproductie of volledige kostenanalyse is dit vooral een technisch orkestratie-experiment, geen migratie-advies voor cryptografie.

ZK-JPEG wil toegestane beeldbewerkingen aantoonbaar maken

ZK-JPEG onderzoekt zero-knowledge-bewijzen voor JPEG-bewerking en -compressie. Het doel is niet een ongewijzigd bestand bewaren, maar aantonen dat een afbeelding via een toegestane familie van transformaties is ontstaan zonder noodzakelijk alle tusseninformatie prijs te geven. Daarmee sluit het aan op de provenancevraag uit de ochtendupdate van woensdag 16 september, maar verschuift de technische focus van ondertekende opname naar controleerbare nabewerking. Paper en HN-discussie

Dat kan interessant zijn voor workflows waarin compressie, formaatwijziging, kleurcorrectie of een zichtbaar gemaakte overlay wel mogen, maar herkomstsignalen niet helemaal verloren mogen gaan. De zware open vraag is beleidsmatig: welke transformaties accepteer je? Een HN-reactie wijst terecht erop dat een brede transformatiefamilie óók misbruikbaar kan zijn; een andere suggereert dat een echte toepassing een beperkte allowlist nodig heeft.

Het systeem is dus geen bewijs dat de afgebeelde gebeurtenis werkelijk plaatsvond, en ook geen kant-en-klaar contentbeleid. De beschikbare context onderbouwt nog geen robuuste implementatie, interoperabiliteit of aanvalsevaluatie. Zie het als een veelbelovende bouwsteen voor een expliciet dreigingsmodel, niet als een algemeen echtheidslabel.

Verder nog

• Bestandssystemen onder minder standaard workloads: een openbare benchmarkreeks vergelijkt Btrfs, ZFS en bcachefs buiten klassieke microbenchmarks. De auteur meldt 593 runs, maar erkent dat de hoofdreeks gedeelde GitHub-runners gebruikt en dus vooral verhoudingen, geen absolute MB/s, kan tonen; bare-metalmetingen bestaan nog slechts beperkt. Interessant als bron voor eigen workloadideeën, niet als definitieve filesystemranglijst. Methode en discussie