Ember-1 kort redeneerwerk in; Naive en Strix openen nieuwe lokale inferencepaden

Fireworks zet Ember-1 naast Kimi K3 als serverless-preview die reasoning korter moet maken zonder kwaliteit te verliezen; de onderbouwing komt vooralsnog volledig van de maker. Voor lokale inference zijn er twee scherp afgebakende nieuwe routes: Naive-N0.5-Flash met sparse attention en Strix Llama voor één Ryzen-AI-configuratie.

Een klein Qwen-experiment laat bovendien zien dat een logitstraf voor woorden die op heroverwegen wijzen mogelijk zowel tokens als fouten terugdringt. Dat is interessant om te reproduceren, maar nog verre van een algemene instelling.

Ember-1 wil dezelfde Kimi K3-kwaliteit met minder reasoningtokens leveren

Fireworks Research brengt Ember-1 uit als Research Preview op zijn Serverless-platform. Het model is volgens de aankondiging gebouwd op Kimi K3 en post-getraind om overbodige redenering weg te snijden. Fireworks claimt ongeveer 40% minder tokens bij gelijkblijvende kwaliteit; het model is dus geen open checkpoint dat je lokaal kunt draaien.

Dat kan voor meerstapsagents relevant zijn, omdat eerdere redeneeruitvoer bij volgende beurten opnieuw in de context belandt. Fireworks zegt dat het K3’s kwaliteit in zeven benchmarks en in twee productie-A/B-tests benadert of behoudt, met bij die laatste ongeveer 35% minder tokens per taak. In de gepubliceerde tabellen varieert de besparing tegenover K3 op maximale reasoningstand per benchmark; op SWE-bench Verified staat Ember bijvoorbeeld iets lager in pass rate (92,2 versus 93,2%), terwijl het op enkele andere eigen vergelijkingen hoger uitkomt.

De claims zijn afkomstig van Fireworks, inclusief de klanttests, gekozen benchmarks en kostencalculatie. De dienst is bovendien voorlopig expliciet een twee weken durende preview, waarna voortzetting volgens de maker van vraag afhangt. Behandel dit daarom als een concrete kandidaat voor een eigen, gelogde A/B-test op taken met veel toolcalls — meet afronding, retries, wall-clock en totale kosten, niet alleen outputtokens. Aankondiging, tabellen en deploymentstatus · HN-discussie

Naive-N0.5-Flash combineert MoE met uitsluitend lokale of sparse attention

NaiveAI heeft de MIT-gelicentieerde gewichten en inferencecode voor Naive-N0.5-Flash gepubliceerd. Het is een MoE met 309 miljard totale en 15,5 miljard actieve parameters, gericht op code en AI-R&D. De onderscheidende architectuur combineert 39 sliding-window-attentionlagen met negen DeepSeek Sparse Attention-lagen; volgens de modelkaart zijn er geen full-attentionlagen. De opgegeven native contextlengte is één miljoen tokens.

De ontwerpkeuze is technisch interessant: sliding-window attention houdt de decodekost per token begrensd, terwijl DSA een indexer de volledige geschiedenis laat scannen en vervolgens slechts een selectie van maximaal 2.048 tokens aan de backbone geeft. De volledige KV-cache blijft dus bestaan; ‘sparse’ betekent hier niet dat lang contextgebruik gratis wordt. NaiveAI meldt 3,25 biljoen tokens aan aanvullende training om de MiMo-V2.5-basis aan die nieuwe attentionstructuur aan te passen.

Voor zelf hosten is dit vooralsnog een zware route: de FP8-gewichten nemen volgens de modelkaart circa 315 GB in en vereisen FP8-capabele NVIDIA-GPU’s, plus extra geheugen voor inference. De maker claimt met de eigen NaiveRT-runtime tot 2.000 tok/s in een ‘Ultrafast’-modus, maar die snelheid en de getoonde coding- en agentresultaten zijn eigen metingen met een specifieke Claude Code-harness. De open gewichten maken verificatie mogelijk; verwacht niet dat dit een directe optie is voor gewone lokale hardware. Modelkaart, gewichten en code · Reddit-discussie

Strix Llama brengt Flash Next naar één Windows-APU-profiel

Strix Llama 0.3.0 is een MIT-gelicentieerde, gepatchte llama.cpp-runtime met installer voor precies één combinatie: Ryzen AI Max+ 395 met 128 GB gedeeld geheugen, Radeon 8060S en Windows. De runtime richt zich uitsluitend op Qwen3.8-Flash-Next en biedt een lokale OpenAI-compatibele API, een chatapp, promptcheckpoints en gelijktijdige gesprekken.

De maker rapporteert met een UD-IQ4_XS-quant van circa 94 GB en speculative decoding 44,9 tok/s decode na een korte prompt en 35,8 tok/s na 86K context; bij een 95,6K-prompt zou prefill 1.217 tok/s halen. Zonder MTP noemt dezelfde post 26,4 respectievelijk 22,7 tok/s. De runtime gebruikt aangepaste kernels voor de matrixcores en de sparse attention van het model, en controleert per release onder meer top-5-tokenkansen, perplexity en enkele langdurige praktijktests.

Dat is een nuttig, reproduceerbaar runtime-experiment voor wie exact deze APU bezit, maar geen algemene AMD- of Windows-benchmark. De code ondersteunt geen andere GPU’s, Macs of NVIDIA, vereist 96 GB als GPU-geheugen in de BIOS en is op één model toegespitst. Ook de prestatie- en kwaliteitschecks zijn door de maker uitgevoerd. Vergelijk daarom vooral koude prefill, lange-contextgedrag en eigen agenttaken met je bestaande stack. Release, installatie en meetmethode

Kleine Qwen-proef: penalty op ‘overthinking’-woorden verdient een eigen eval

Een gebruiker testte in llama.cpp een negatieve logitbias van 2 op tokens als wait, maybe, perhaps, actually en rethink. Op vijftig willekeurige MATH-500-vragen met Qwen3.5-4B rapporteert de post hogere accuracy én minder reasoningtokens bij alle vijf geteste precisies: BF16 ging van 74% naar 84% met 19,4% minder reasoningtokens; Q4_K_M van 60% naar 66%; Q2_K van 12% naar 24%.

Dat sluit aan bij het idee dat modellen soms in onproductieve heroverwegingen blijven hangen, maar het experiment bewijst nog niet dat deze tokenlijst de oorzaak raakt. Het gaat om één model, slechts vijftig vragen, een enkele benchmark en een handgekozen set token-IDs die aan precies deze tokenizer gekoppeld is. Een reactie noemt terecht het risico op stille regressie buiten benchmarks.

Wie dit probeert, houdt de wijziging daarom klein en test minstens naast wiskunde ook eigen code-, toolcall- en open-vraagtaken. Log naast score en tokenverbruik ook fouttypen, afgebroken redeneringen en gedrag bij meertalige prompts. Een hogere benchmarkscore is geen reden om de aanpak blindelings in een agentprofiel te zetten. Experiment en volledige tokenlijst

Verder nog

• Imp brengt DSPy-achtige programmaoptimalisatie naar Elixir: de experimentele eerste Hex-release definieert getypeerde LLM-stappen, evaluaties en optimizers voor de BEAM. Agents kunnen als OTP-processen draaien, met events, deadlines en een autorisatiecallback voor tools; MCP-tools zijn pas bruikbaar na expliciete goedkeuring. Dat maakt het interessant voor Elixir-applicaties die modelruns al als superviseerbare processen willen behandelen. Maar Imp 0.5 noemt zijn API veranderlijk en mist nog grootschalige benchmarkvalidatie; ook in de kleine HN-discussie is de praktische meerwaarde van DSPy-achtige optimalisatie niet onomstreden. Project en documentatie · HN-discussie