Intel Arc krijgt eigen LLM-engine, terwijl Rust-builds en een oude IKE-daemon gerichte versnellingen krijgen

GRIMOIRE verkent een native inferencepad voor Intel Arc Pro B70, terwijl Headstart Rust/Cargo-workspaces eerder parallel wil laten werken door metadata los te trekken van function-body-checks. Daarnaast krijgt de oude IKE-daemon racoon2 een reeks concrete interoperabiliteits- en testverbeteringen.

Voor lokale inference is er ook een nieuwe M1-gerichte DwarfStar-fork met zelfgerapporteerde lange-contextcijfers. Die signalen zijn interessant, maar allemaal jong genoeg om eerst op de eigen hardware en taken te toetsen.

GRIMOIRE bouwt een smalle SYCL-engine voor Intel Arc Pro B70

GRIMOIRE is een experimentele LLM-runtime in C++ met SYCL en Level Zero, specifiek gericht op Intel Battlemage-GPU’s en in het bijzonder de Arc Pro B70. Het project implementeert zelf kernels voor onder meer attention, matrixvermenigvuldiging, quantized weights en mixture-of-experts, dus niet bovenop vLLM, PyTorch of OpenVINO.

De concrete aantrekkingskracht voor B70-bezitters is dat de maker voor Ornith-1.5-35B-A3B-MXFP4 175,25 tok/s decode bij één request noemt, en in een andere run 193,6 tok/s; bij acht gelijktijdige requests wordt maximaal 464,2 tok/s totaal gemeld. De repository bevat Docker-build- en serverinstructies, plus een OpenAI-achtige HTTP-server. Ondersteuning verschilt volgens de post wel per model en gewichtformaat.

Dit is geen algemene Intel-GPU-doorbraak. De cijfers zijn makersmetingen op één systeem, het project noemt zichzelf actief in ontwikkeling en er is geen onafhankelijke vergelijking met dezelfde prompt, quant, context en kwaliteitscontrole. Wie een B70 heeft, kan het vooral zien als een reproduceerbare proef: controleer eerst tokenpariteit, geheugenverbruik, modelondersteuning en gedrag onder concurrency voordat je een bestaande servingstack vervangt. Projectpost met benchmarks, status en Docker-route

Headstart laat afhankelijke Rust-crates eerder beginnen

Het experimentele Headstart splitst Rusts analyse in interfacecontrole en function bodies. Zodra rustc de interface kent, schrijft de patch een vroege .rmeta; Cargo kan afhankelijke crates dan al laten analyseren, terwijl de bodies van de dependency nog worden gecontroleerd. Voor cargo build wachten dependents nog vóór codegeneratie op de volledige metadata en geven ze hun jobslot tijdens dat wachten terug.

Dat is interessant voor brede Rust-workspaces met ongebruikte CPU-capaciteit tijdens een dependencyketen. De maker meet op 16 cores bij dertien echte projecten tot 54% snellere schone cargo check-runs en tot 42% snellere builds; met Rusts parallelle frontend zou er nog tot 25% bijkomen. Op vier cores vallen de winsten veel kleiner uit, bijvoorbeeld 24% voor een rust-analyzer-check en 13–15% voor de build. De patches bevatten ook scripts die diagnostics, exit-status en eindbinary tegen de normale route vergelijken.

De belangrijke ruil staat expliciet in het ontwerp: als een dependency-body faalt, kan downstreamanalyse weggegooid werk zijn; er is ook meer gelijktijdig geheugenverbruik. Dit zijn nog patches voor rustc en Cargo, geen upstreamfeature. Meet dus op een representatieve workspace — inclusief RAM-piek, incremental builds en foutpaden — in plaats van de hoogste clean-buildscore te extrapoleren. Repository, ontwerp en meetopzet · HN-discussie

racoon2 werkt NAT-T, IPv6 en regressietests bij

Een GSoC-project heeft werk aan racoon2 upstream gemerged in de gsoc2026-branch. Racoon2 is een IKEv1/IKEv2- en IPsec-policydaemon die het project wil moderniseren voor L2TP/IPsec- en IKEv2-servers op NetBSD en Linux, onder meer voor ingebouwde Windows-, iOS- en Android-clients.

De afgeronde wijzigingen zijn concreet: RFC-7383-fragmentatie voor beide IKE-versies, NAT-OA-verwerking, address substitution voor NAT-T, consistente wildcard-adressen, IPv6 standaard ingeschakeld, en proposal/policy-opbouw die beter aansluit bij wat een peer werkelijk voorstelt. Daarmee zouden NAT-clients niet langer extra, initiator-specifieke selectors nodig hebben om de selectorcontrole te passeren. Ook kwam er voor het eerst een zelfstandige unittestinfrastructuur die onder sanitizers draait.

Dat maakt een oud project beter testbaar en potentieel bruikbaarder, maar nog geen drop-in VPN-serveradvies. De bron noemt zelf een ontbrekende racoon2ctl, beperkte testdekking buiten de nieuwe code en nog geen volledige end-to-end-IPv6-test met echte tunnels en langlopende verbindingen. Behandel dit daarom als een relevante basis voor verdere interoperabiliteitstests, niet als bewijs dat elke client- en NAT-combinatie nu probleemloos werkt. NetBSD-verslag met wijzigingen en open punten · Lobsters-discussie

M1-fork van DwarfStar richt zich op vlakke Flash-Next-snelheid bij lange context

De middagupdate van vandaag beschreef DwarfStar als bewust smalle runtime. Een nieuwe fork voegt daar specifiek voor de M1 Max onder meer Metal-decoders voor ISTA-quants, M1-gerichte matvec-kernels, een vectorized indexer, overlappende SSD-read voor n-grams en behoud van turn-state aan toe.

De maker meldt op een M1 Max met 64 GB voor Qwen3.8 Flash Next Q2_0 44 tok/s bij 4K context, 38,8 bij 256K en 35,4 bij circa 398K; voor IQ3_XXS noemt hij 35,2 bij 4K en 31,7 bij 259K. In zijn vergelijking zou een opnieuw geprobeerd agentturn op 31K context daardoor van 109 seconden naar 0,3 seconde dalen, doordat de recurrente toestand niet opnieuw wordt geprefilled. De fork biedt hiervoor een dstar-launcher en een lokale OpenAI-/Anthropic-compatibele server.

Dat is een concrete ontwikkeling voor juist deze oudere Mac-generatie, maar alle cijfers komen van één auteur en één machine; bovendien vergelijkt hij verschillende modellen en quants. De route vraagt volgens de post 64 GB Mac-geheugen en kan voor zeer lange context ook een aangepaste macOS GPU-wired-memorylimiet vereisen. Test daarom naast decode vooral koude start, SSD-I/O, contextintegriteit, tokenpariteit en geheugenruimte voor de rest van je workflow. Post met code, kernels en meetdetails

Verder nog

• 5 KB assembly voor Gemma-2B: PULSAR-ASM is een open experiment dat FP16-inference voor Gemma-2B vrijwel geheel in platte x86-64-assembly zet: de maker noemt 5,2 KB machinecode, AVX2/F16C en 4,5–4,7 tok/s op een oudere quad-core-i5. Het doel is nadrukkelijk inzicht in de minimale runtimevoetafdruk, niet competitie met llama.cpp; de Python-harness verzorgt nog Windows-allocatie en threads. Projectpresentatie en beperkingen