Vulkan-training zonder CUDA, en de harness als agentbottleneck

Een nieuw Rust/Vulkan-project wil training én inference voor veel transformerarchitecturen zonder CUDA of PyTorch mogelijk maken, maar is nog ver van een bewezen vervanger. Tegelijk laat een proef met een 4B-model voor Postgres-plannen zien dat offline optimalisatie iets anders is dan een live queryplanner. En een nieuwe analyse onderstreept dat de harness van een coding agent vaak mede bepaalt hoeveel context, kosten en fouten een model produceert.

Vulkan als experimenteel alternatief voor CUDA-training

Hierarchos Native combineert Rust en Vulkan voor native training en inference van volgens de maker 143 transformerarchitecturen (224 modeltype-namen inclusief aliases). De backend omvat onder meer forward/backward passes, AdamW, LoRA/PEFT, attention en KV-cache, safetensors en Hugging Face-import. De nadruk ligt op tekstmodellen; multimodale torens zijn niet automatisch gedekt.

Dat is interessant voor AMD-, Intel- en geïntegreerde GPU’s, waar de ML-tooling vaak alsnog rond CUDA is georganiseerd. Maar dit is nadrukkelijk nog geen PyTorch- of CUDA-vervanger: de maker vraagt om onafhankelijke hardwaretests en benchmarks, en zegt zelf dat architectuurondersteuning niet elke configuratie valideert. Zie het dus als een veelbelovend portabiliteitsexperiment, niet als een productiekeuze. Projectaankondiging

Een 4B-model optimaliseert queryplannen, maar niet zomaar live Postgres

Een experiment traint een 4B-model om queryplannen voor join-zware SQL sneller te maken. De auteur meldt een geometrisch gemiddelde versnelling van 1,81× en 44,7% lagere opgetelde latency; voor het verzamelen van demonstraties was volgens de discussie ongeveer 95 uur op twee H100’s plus API-verbruik nodig.

De interessante gedachte is een gespecialiseerd model dat vóór uitvoering een afgebakend planningsprobleem aanpakt. De grenzen zijn echter cruciaal: de besproken test gebruikt een read-only workload op een 8GB-dataset die in geheugen past, met opgewarmde queries en beperkt shared_buffers. Ook tellen planningstijd, veranderende statistieken en kosten van hertraining mee in een echte database. Dit is dus geen reden om de optimizer van een productie-Postgres te vervangen, maar wel een bruikbare onderzoeksvraag voor stabiele, herhaalbare workloads. Artikel · HN-discussie

Coding agents: meet de harness, niet alleen het model

HarnessTax onderzoekt hoeveel de omringende agentharness uitmaakt voor coding agents. De relevante variabelen zijn breder dan een systeemprompt: uitvoerloop, toolinterface, contextbeheer, feedback, delegatie en parallelisme bepalen samen hoeveel tokens een taak kost en hoe vaak edits of toolcalls misgaan.

Dat sluit aan bij de lokale agentervaringen die we eerder bespraken, maar voegt een gerichte vergelijking toe: een model/provider-combinatie die voor één harness is geoptimaliseerd, is niet automatisch de beste combinatie. De discussie plaatst daar meteen een beperking bij: ‘harness’ wordt soms te ruim gebruikt, terwijl subagents, gelijktijdigheid en providermiddleware afzonderlijke factoren zijn. Neem een ranking dus niet als algemene kwaliteitsranglijst; meet op eigen repositories zowel taakuitkomst als wall-clock-tijd, contextverbruik en herstelwerk. Onderzoek · HN-discussie

Ternary LLMs onder de 1,58-bitgrens blijven onderzoekswerk

Een nieuwe paper beschrijft ternary LLMs met een effectieve opslag onder 1,58 bit per gewicht; de HN-discussie vat het mechanisme samen als het benutten van veel voorkomende nulgewichten, tot circa 1,48 bit. Ternary gewichten zijn aantrekkelijk omdat de vermenigvuldigingen in principe neerkomen op optellen, aftrekken of niets doen.

Voor lokale en edge-inference is dat potentieel belangrijker dan alleen een kleinere download: het kan ook om eenvoudiger rekenwerk gaan. Maar de winst is niet automatisch verliesvrij. In de discussie wordt terecht gewezen op het verschil tussen opslagbits en behouden nuttige informatie, en op de noodzaak van quantization-aware training en soms hogere precisie in delen van de training. Wacht dus op reproduceerbare kwaliteits- én runtimemetingen op gewone hardware voordat je dit als nieuwe lokale standaard behandelt. Paper · HN-discussie

Verder nog

• GGUF-fit berekenen uit headers: Local Model Explorer leest volgens de maker GGUF-headers uit, neemt context en KV-cache mee en genereert een llama-server-commando voor de gekozen hardware. Dat is handiger dan parametergetallen gokken, vooral bij MoE; snelheid voorspelt de tool niet. Tool
• OpenSpec voor agentwerk: OpenSpec biedt een configureerbare spec-workflow rond AI-coding. In de discussie lopen ervaringen uiteen: expliciete artefacten kunnen richting geven, maar kunnen ook reviewwerk verplaatsen naar veel gegenereerde markdown. Houd de spec dus klein genoeg om door mensen te blijven lezen. Project · HN-discussie