Clover brengt block-diffusion naar open MoE’s; Deepthink schaalt lokale agenten op

Clover-35B-A3B-Preview brengt block-diffusion naar een open tekstmodel met een MoE-ruggengraat, maar de eerste release is vooral een experimenteel server- en onderzoeksobject. Deepthink zet daartegenover in op veel parallelle lokale agentloops; de spectaculaire scores komen vooralsnog uitsluitend uit de eigen kleine proef.

Clover probeert tekst in blokken parallel af te ronden

DiffuSpace heeft Clover-35B-A3B-Preview uitgebracht, een open tekstmodel dat is afgeleid van Qwen3.6-35B-A3B. Het heeft 35 miljard parameters, waarvan volgens de modelkaart ongeveer 3 miljard per token actief zijn, en een contextvenster van 128K tokens. Het afwijkende zit in de generatie: in plaats van alleen telkens het volgende token te kiezen, start Clover een blok gemaskeerde tokens en vult het de meest zekere posities parallel in. Het standaardblok telt 32 tokens.

Dat maakt Clover interessant als experimentele route naast gewone autoregressieve inference: block-diffusion kan andere latency- en throughputruilen opleveren, terwijl de MoE-ruggengraat de actieve berekening begrenst. De release noemt ook eigen paden voor self-speculative decoding in SGLang en llama.cpp. De modelkaart waarschuwt echter dat zeer lange antwoorden soms repetitief worden; daarom staan er standaard penalties en een oplopende voorkeur voor het einde van antwoord en denkfase aan.

‘Open’ betekent hier niet meteen lichtgewicht. De BF16-gewichten vragen volgens de documentatie circa 69 GB GPU-geheugen, exclusief inferencetoestand. Bovendien kunnen de Hugging Face- en SGLang-paden door numerieke verschillen andere tekst produceren bij ogenschijnlijk gelijke instellingen. Test dit dus eerst op een concrete taak met een vaste contextlengte en meet niet alleen tok/s, maar ook herhaling, outputkwaliteit en kosten per afgeronde taak. De gepubliceerde benchmarkpositie is een claim van de maker.

Modelkaart: architectuur, block-diffusion en inzetvereisten · Reddit-discussie

Deepthink maakt test-time scaling lokaal, maar tegen een forse tokenrekening

Het open-sourceproject Deepthink organiseert meerdere onafhankelijke aanpakken voor één probleem als takken: agents werken parallel, kunnen elkaars werk via een gedeeld bord inzien en worden volgens de auteur door een harness voortgezet, gesnoeid of van strategie veranderd. De maker positioneert dit als lokaal te draaien variant van test-time scaling voor moeilijke taken.

De eigen proef met Gemma4-35B en Qwen3.8-27B meldt flinke sprongen op 15 BrokenArxiv-opgaven en acht DeepSWE-taken, maar gebruikte daarbij rond 200 miljoen tokens per probleem. Dat maakt de centrale ruil helder: je koopt mogelijk betere zoekdekking en meer verificatierondes met veel inference, wachttijd en energie. De auteur noemt zelf looptijden van circa 50 minuten tot 30 uur, afhankelijk van diepte en inferentiesnelheid.

Dat is vooral interessant voor afgebakende, dure taken waarbij een onafhankelijke oplossing of controle werkelijk waarde toevoegt. Het is geen bewijs dat een agentzwerm op gewone ontwikkeltaken beter of goedkoper is dan één goede agent: de gerapporteerde resultaten komen van de maker, op kleine sets en zonder vergelijking met frontiermodellen. Reproduceer met eigen taken, houd een budgetplafond aan en beoordeel eindartefacten en tests — niet alleen het aantal gegenereerde redeneringstokens.

Projectaankondiging, opzet en eigen resultaten

Survival LLM koppelt offline zoeken aan controleerbare bronpassages

Survival LLM bundelt een lokaal taalmodel met een offline bibliotheek van onder meer medische naslagwerken, overheidsrichtlijnen, reparatiehandleidingen en Wikipedia. Het interessante ontwerpdetail is niet de belofte van een noodchatbot, maar dat antwoorden de geraadpleegde artikelen en gemarkeerde passages tonen. Versie 0.3.4 voegt een instelbaar redeneerbudget toe en probeert opnieuw te antwoorden met de beste gevonden artikelen wanneer een eerdere zoekactie zonder antwoord eindigde.

De maker rapporteert op 22 verduisterings- en EHBO-vragen 21 correcte hoofdpunten voor een Qwen3.8-27B-configuratie en 14 voor een Granite-8B-configuratie. Dat is een eigen, kleine evaluatie en geen veiligheidscertificering; de applicatie zegt zelf dat kleinere modellen meer fouten maken. De HN-discussie onderstreept een verstandige grens: gebruik het model hoogstens om relevante passages te vinden en controleer die bron zelf, zeker bij medische of veiligheidskritische vragen.

Ook offline heeft een materiële prijs. De volledige bibliotheek is volgens de projectpagina 9 GB download en 19 GB geïnstalleerd, naast het model; een MacBook Pro zou tijdens antwoorden rond 100 W gebruiken. Een e-reader of geprinte handleiding blijft dus een robuustere noodvoorziening. Maar als lokale zoek- en leeslaag voor eigen handleidingen en openbare bronnen is de combinatie van bronverwijzing en offline werking concreet nuttiger dan een antwoord zonder herleidbaarheid.

Survival LLM: bibliotheek, hardwarekeuze en versie 0.3.4 · HN-discussie over broncontrole en hallucinaties

Call Graph Analyzer zoekt paniekpaden door dependencies heen

Call Graph Analyzer (CGA) is een nieuwe Rust-tool die vanuit gemonomorfiseerde MIR een callgraph opbouwt en daarmee functies aanwijst die in het gecompileerde programma kunnen panieken. Anders dan een simpele zoekactie naar panic! kan die analyse ook paniekpaden uit de standaardbibliotheek en dependencies zien. Dat is praktisch voor embedded software, extern bereikbare services of firmwarepaden waar een onverwachte panic een beschikbaarheidsprobleem kan worden.

De makers kiezen nadrukkelijk niet voor de onhaalbare eis ‘nul panics’. Veel aannames kun je niet zinvol tot bovenaan elke callstack als Result doorgeven. Het doel is zicht krijgen op onbedoelde paniekpaden en regressies daarop; herstelmechanismen zoals redundantie, watchdogs of een recovery image blijven nodig.

CGA heeft ook scherpe grenzen. Omdat het als rustc-driver aan een specifieke nightly-compiler hangt, kan zijn callgraph afwijken van de binary die je normaal bouwt. MIR-analyse gebeurt bovendien vóór optimalisaties, wat false positives kan geven, en een run is volgens de makers grofweg twee- tot driemaal zo langzaam als cargo check. Zie het daarom als een extra CI- of reviewcontrole voor kritieke crates, niet als formeel bewijs dat een release niet kan crashen.

Technische uitleg: MIR-aanpak, alternatieven en beperkingen · Lobsters-discussie

Verder nog

• Securitytriage is zelf een supply-chainknelpunt: een Gentoo-maintainer beschrijft hoe grote aantallen meldingen, CVE’s en scannerwaarschuwingen downstreams soms tot nutteloze version bumps of stabilisaties dwingen, zelfs wanneer een kwetsbare dependency al is ontbundeld. Het is een persoonlijk essay, geen meting van de hele sector, maar de praktische vraag is terecht: zorg voor onderhoudbare securitybranches en kleine backports in plaats van fixes te verpakken met een grote feature- of API-sprong. Essay · Lobsters-discussie