Splash vernieuwt M1-kernels; lokale agent- en cloudtooling krijgt nieuwe proefroutes

De M1-fork van Splash vervangt nu ook attention- en MoE-kernels, met opvallende maar nog zelfgerapporteerde winst voor lange agentcontext. Daarnaast verschijnen concrete lokale proefroutes voor agentharnesses, cloudemulatie en beslismodellen; bij alle drie blijft het zaak de claims op eigen taken en grenzen te testen.

Splash werkt M1-kernels bij voor attention en MoE

De communityfork splash-m1 heeft de twee resterende delen vervangen die volgens de maker nog op Apples MPP-matrixbibliotheek leunden: attention en de MoE-expertlagen van Qwen3.6-35B-A3B. De nieuwe kernels gebruiken op M1 eigen registertiles en simdgroup-matrixinstructies. Voor een 2021 M1 Max met 64GB meldt de auteur daardoor voor de 35B-A3B gemiddeld 144 tok/s op zijn vijf-prompttest, tegenover 99 tok/s in de vorige release; bij een koude 38K-prompt daalde de tijd tot eerste token volgens dezelfde meting van 106 naar 72 seconden.

Voor Qwen3.8-27B zit de winst vooral bij lange context: de auteur meldt rond 51K context 25 in plaats van 20 tok/s, en meet de attentionstap bij 176K context bijna twee keer zo snel. In één eigen vergelijking met oMLX en MTPLX rapporteert Splash 41,5 tok/s decode tegenover 19,8 en 25,9, met lagere gemeten energie per token. Prefill blijft volgens de maker juist het zwakkere punt: bij 44K tokens zouden de MLX-engines ongeveer 20% sneller zijn.

Dit is een inhoudelijk vervolg op de einde-dagupdate van gisteren: toen was er vooral een tweede M1-meting; nu zijn de lange-contextattention en MoE-lagen zelf aangepast en naast andere engines gezet. De kwaliteitscontrole — 54/54 op een eigen set woordproblemen en hoge top-1-tokenovereenkomst met de upstreamkernels — komt wel van dezelfde ontwikkelaar. Zie het daarom als een interessante build om met eigen koude prefill, lange sessies én uitkomstkwaliteit te vergelijken, niet als een algemene ranglijst voor M1-runtimes. Release, metingen en code

KoboldCpp bundelt nu een lichte lokale agentharness

KoboldCpp levert voortaan een ingebouwde agentharness mee, in te schakelen vanuit de GUI of met --agent. Volgens de maker heeft die negen ingebouwde tools en een systeemprompt van ongeveer 2K tokens inclusief toolbeschrijvingen. De harness kan ook MCP-tools uit een mcp.json inladen, AGENTS.md gebruiken en context comprimeren; voor toolgoedkeuring zijn modi aan, automatisch en uit beschikbaar.

Dat is praktisch voor wie een lokale, relatief kleine agentloop wil proberen zonder eerst OpenCode, Codex of een aparte orchestrator te configureren. De documentatie in de post noemt wel minstens 28K context en 8K generatieruimte, met 12GB VRAM als richtpunt voor een bruikbare ervaring. MCP-tools draaien volgens de maker op de KoboldCpp-server, terwijl eigen agenttools op de client draaien — een grens die je vóór gebruik moet begrijpen.

De komst van een checkbox verlaagt de installatiedrempel, maar verlaagt niet het risico van bestands- of tooltoegang. Laat automatische goedkeuring uit totdat mounts, werkdirectory, netwerk en rollback zijn afgebakend; een ingebouwde harness is geen sandbox. De maker waarschuwt bovendien voor een phishingdomein dat zich als KoboldCpp voordoet: haal releases daarom uitsluitend bij het officiële project op. Aankondiging en discussie

Floci belooft lokale cloudemulators zonder accounts of credentials

Floci positioneert zich als MIT-gelicentieerde verzameling lokale emulators voor AWS, Azure, GCP en OCI. De projectsite noemt voor de AWS-variant dezelfde poort als LocalStack, 119 diensten en een native binary; de andere varianten dekken volgens de site onder meer Azure Blob/Queue, GCS/Pub/Sub en OCI Object Storage/Queue. De bedoeling is een cloud-API lokaal te testen zonder account of echte sleutels — ook vanuit een coding agent.

Dat is relevant voor agentwerk omdat een testomgeving zonder cloudcredentials zowel kosten als exfiltratieoppervlak kan verkleinen. Floci claimt dat sommige diensten zoals Lambda, RDS, Redis en Kafka echte onderliggende engines gebruiken; het biedt ook voorbeelden voor SDK’s, Terraform/OpenTofu en CI. Maar deze zijn allemaal projectclaims. ‘Protocol fidelity’ of een geslaagde lokale test is geen garantie dat IAM, netwerkgedrag, managed-serviceeigenaardigheden en productieconfiguratie identiek zijn.

Gebruik zo’n emulator dus als snelle eerste laag, met contracttests of een afgeschermde echte omgeving als tweede laag. De kleine HN-discussie noemt precies die open vraag: geschikt voor ontwikkeling en tests betekent niet vanzelf dat het een migratiepad weg van een cloudprovider is. Floci · HN-discussie

Laya Studio probeert beslismodellen eerst zonder finetuning te specialiseren

Een nieuw Apache-2.0-project, Laya Studio, wil voor afgebakende classificatie- en routeringstaken eerst bestaande representaties van Laya benutten in plaats van basisgewichten te trainen. De tool genereert volgens de maker voorbeelden plus gescheiden validatie- en testsets, probeert onder meer prototypes, centroids, contrastieve richtingen en activation steering, en exporteert de gekozen specialisatie als klein artefact. Ondersteund zijn de PyTorch-variant en laya-mlx op Apple Silicon.

De interessante ontwerpkeuze is dat negatieve resultaten worden bewaard en dat de geëxporteerde specialisatie in een nieuw proces wordt teruggeladen. Daarmee adresseert het project ten minste een veelvoorkomend probleem bij snelle demo-evaluaties: testvoorbeelden die ongemerkt in de fit of prompt belanden. De auteur zegt ook expliciet embeddingmethoden en werkelijke interventies in hidden states niet op één hoop te gooien.

Dit is geen bewijs dat een taalmodel al een goede beslisgrens voor je domein bezit. De voorbeelden en evaluaties worden binnen hetzelfde project gegenereerd, en er staan geen onafhankelijke domeinmetingen in de beschikbare context. Voor gevoelige classificaties zijn eigen gelabelde documenten, vaste hold-outs en foutanalyse dus belangrijker dan een mooie Studio-score. Projectaankondiging

Webchecker voor Postgres-migraties maakt lockrisico zichtbaar, maar kent je database niet

De nieuwe browsertool safe-not-safe parseert een Postgres-migratie met libpg_query als WebAssembly en probeert per statement een direct oordeel te geven: veilig of niet veilig. Volgens de maker ontstond het uit migratiereviews bij een platformteam dat veel productteams ondersteunde; de tool is dus vooral bedoeld als snelle eerste check vóór een schemawijziging in CI of review belandt.

Dat kan nuttig zijn voor voor de hand liggende gevaarlijke DDL, maar de HN-discussie levert meteen de belangrijkste beperking: of een typewijziging een no-op of een exclusief gelockte table rewrite oplevert, kan afhangen van het bestaande schema en de actuele staat. Ook foreign keys, tabelgrootte, backfills en een compatibele applicatierollout zitten niet volledig in één SQL-statement.

Gebruik de checker daarom als lintregel, niet als vrijbrief. Een echte productiebeoordeling vraagt nog steeds schema-introspectie, een representatieve stagingdatabase en een rolloutplan dat oud en nieuw schema tijdelijk kan dragen. Tool · HN-discussie

Verder nog

• Qwengram krijgt een 2B-variant: sinds de namiddagupdate van gisteren heeft de maker naast de 0,8B-versie een 2B-model toegevoegd dat volgens hem met hetzelfde externe PLE-geheugen 3,7–4% lagere perplexity haalt. Dat is een nieuwe modelartefact- en meetupdate, maar nog steeds geen onafhankelijke taak- of latency-evaluatie. Update in de experimentpost