vLLM maakt DiffusionGemma-Jev bruikbaar; lokale Qwen-metingen en programmeerbare Intel-NPU’s leggen grenzen bloot

vLLM heeft een nightly-route aangekondigd waarmee DiffusionGemma-Jev getypeerde keuzes met een Jev-compatibele endpoint kan serveren. Tegelijk maken twee lokale Qwen-proeven het verschil zichtbaar tussen een maximale context die technisch past en een stack die ook op de eigen taken goed werkt. Voor low-levelbouwers laat npunlock bovendien zien dat Intel-NPU’s programmeerbare cores bevatten, maar alleen binnen een nog zeer smalle, experimentele compatibiliteitsgrens.

vLLM geeft DiffusionGemma-Jev een nightly-endpoint

vLLM meldt dat DiffusionGemma-Jev nu in vllm/vllm-openai:nightly draait, met een Jev-compatibele endpoint voor ja/nee-, meerkeuze- en scorevragen. De server seedt volgens de aankondiging een antwoordtemplate, laat alleen de antwoordslots ruisig en leest na één denoisingstap een kansverdeling uit. Daarmee is de concrete verandering dat een bestaande vLLM-serverroute deze vorm van begrensde beslissing kan uitproberen, in plaats van alleen een losse experimentele serverlaag.

Dat is een stap vooruit sinds de namiddagupdate van vrijdag 18 september, waar OpenJev nog afhankelijk was van een niet-gemergde vLLM-wijziging. Voor een agent met vaste routerings- of classificatievragen is vooral de API-compatibiliteit praktisch: je kunt een bestaande Jev-gerichte client tegen een lokale of eigen endpoint testen.

De beperking is wezenlijk. De aankondiging noemt geen onafhankelijke accuracy-, latency- of calibratievergelijking met kleine autoregressieve modellen en constrained decoding. De gerapporteerde ‘confidence’ is een verdeling over de vooraf geplaatste antwoordslots; dat bewijst niet dat de gekozen vraagvorm volledig is of dat een hoge score goed gecalibreerd is. Log daarom naast de gekozen optie de volledige verdeling, en kalibreer drempels op geaccepteerde uitkomsten uit je eigen workflow. vLLM-aankondiging en nightly-instructie · Google Gemma-deploymentpost

Twee RTX 5060 Ti’s halen 262K context — maar niet zonder prefill-ruil

Een gebruiker documenteert Qwen3.8-27B NVFP4 op twee RTX 5060 Ti-kaarten van 16GB, stock vLLM 0.30 en headless Ubuntu. Met FP8-KV-cache past volgens die meting de volledige 262.144-tokencontext met ongeveer 10K tokens marge. De auteur rapporteert circa 4.000 tok/s prefill bij korte prompts, 72 tok/s decode voor proza en 132 tok/s voor sterk gestructureerde uitvoer met MTP; video-invoer is uitgeschakeld.

Dit is vooral een nuttig tegengewicht voor losse piekgetallen. Bij circa 132K context noemt dezelfde auteur 56 tok/s voor proza en 103 tok/s voor gestructureerde output; het vullen van ongeveer 250K nieuwe tokens zou rond vier minuten duren. Prefix-caching kan dat voor een doorlopende agent- of chatsessie grotendeels vermijden, maar niet voor steeds nieuwe lange documenten. De gemelde 150W-limiet zegt hier vooral dat decode volgens de auteur geheugenbandbreedtegebonden bleef; er is geen ongecapte A/B-test.

Gebruik dit dus als reproduceerbaar startpunt voor precies deze hardwareklasse, niet als algemene prijs-prestatieclaim. Quant, MTP-acceptatie, promptsoort, PCIe-topologie en feitelijk beschikbare VRAM bepalen de uitkomst; ook andere gebruikers in de draad melden duidelijk lagere snelheden met llama.cpp bij volle context. Configuratie, meetnotities en discussie

Eén RTX 3060-test zet ultra-low-bit-quants naast echte taken

Een Reddit-gebruiker vergeleek op een RTX 3060 met 12GB VRAM ISTA-DASLab GSQ-RCO-IQ3-XXS met ByteShape IQ3-XXS voor Qwen3.8-27B. ByteShape is volgens de post ongeveer 500MB kleiner en positioneert zich via lage KL-afwijking van BF16. In deze ene opstelling lukte een 3D-voxelopdracht met GSQ in één run onder 55K tokens, terwijl ByteShape na ongeveer drie pogingen en meer dan 98K tokens nog niet klaar was; de auteur meldt een vergelijkbare teleurstelling bij webontwikkeling.

Dat is geen bewijs dat ByteShape in het algemeen onbruikbaar is, maar wel een concreet nieuw praktijkpunt naast score- of divergentiecijfers: een compact checkpoint kan op een lange, productieve taak veel extra output en herstelvragen veroorzaken. ByteShape reageert in de discussie dat deze quant aan de lage kwaliteitskant zit, maar volgens eigen coding- en toolcallingbenchmarks goed scoorde. Beide kanten hebben gelijk in de beperkte zin dat hun metingen verschillende taken en opzetten betreffen.

Wie op circa 3 bit per gewicht moet werken, kan hier vooral een testregel uit halen: vergelijk quants op dezelfde hardware met dezelfde contextlimiet én meet voltooide taken, aantal herstelbeurten en outputtokens. Eén KL-getal of één creatieve taak is onvoldoende. Test, discussie en reactie van ByteShape

npunlock maakt custom C-kernels op één Intel-NPU-profiel mogelijk

npunlock reconstrueert een pad om eigen C-code te compileren en als kernel in een Intel-NPU-grafiek te draaien. Volgens de documentatie zijn Intel’s ACT-SHAVE-cores programmeerbaar, maar biedt de publieke softwarestack normaal alleen graph-level programmering. Het project laat onder meer FP32-GELU, FP16-varianten en onafhankelijke gemengde branches zien; de maker noemt ongebruikelijke operators, numeriek gevoelige FP32-implementaties en kernel-fusie als beoogde toepassingen.

Dat is interessant voor ontwikkelaars die een Intel Core Ultra-NPU niet uitsluitend via bestaande OpenVINO-operators willen benaderen. De grens is echter zeer strak: alleen Windows x64, Meteor Lake met NPU3720, statische shapes, bekende tensorlayouts en compatibele carriers zijn gevalideerd. Voor custom compilatie is bovendien MoviTools nodig uit een oude OEM-driverbundel; die propriëtaire afhankelijkheid wordt niet door het project verspreid. Linux en nieuwere NPU-generaties zijn hypotheses, geen ondersteunde platformen.

Zie dit dus als een inspecteerbaar low-level experiment, niet als een portable NPU-backend. Test output eerst tegen een host-oracle en leg driver- en firmwareversies vast voordat je custom operators in een productiepad zet. Projectdocumentatie · HN-discussie

Verder nog

• FoxDev Studio wil Visual FoxPro 9 langer laten leven: deze nieuwe Rust/WebAssembly-runtime en IDE opent volgens de makers bestaande projecten, formulieren en DBF-data zonder conversiestap, biedt een brug voor 32-bit-.fll-libraries en heft zelf de 2GB-bestands-offsetgrens op. De nightly is echter een unsigned prerelease; reports ontbreken nog. Een grotere DBF kan bovendien een eenrichtingsdeur worden voor het oude Visual FoxPro. De HN-discussie wijst daarnaast op risico’s van de bestaande DBC/DBF-architectuur met schrijfbare stored procedures; dat is geen FoxDev-audit, maar wel reden om legacy-datatoegang en rechten apart te beoordelen. Project · HN-discussie
• ‘Jev in 25 Lines’ is vooral een nuttige grensdemonstratie: een expliciet als parodie aangeduid artikel leest de logits van een lokaal Qwen-GGUF uit voor drie antwoordlabels en normaliseert ze tot kansen. Het laat zien hoe weinig code nodig is voor een vaste-keuzerouter, maar niet hoe je die betrouwbaar calibreert of format- en redeneerfouten opvangt. In de HN-discussie wordt terecht gewezen op tokenisatie, prose-tendensen van chatmodellen en ontbrekende latency-/foutvergelijkingen. Gebruik bij zo’n aanpak constrained output en een eigen evalset. Artikel · HN-discussie