Lokale agentstacks krijgen scherpere fallbackgrenzen, terwijl CPU- en speculatiepaden nieuwe praktijkcijfers tonen

Oh My Pi heeft zijn lokale modelconfiguratie aangepast, maar de belangrijkere les zit in de fallback: zonder allowlist kan een lokale agent bij een mislukte modelresolutie alsnog een beschikbare cloudprovider kiezen. Tegelijk verschijnen er twee vroege performancepaden: n-gram-speculatie voor Bonsai 2 op een RTX 4090 en een CPU-PR voor gekwantiseerde matrixvermenigvuldiging. Beide zijn interessant, maar nog geen algemene snelheidsbelofte.

Oh My Pi vraagt nu om expliciet lokale modelgrenzen

De handleiding voor Oh My Pi (omp) beschrijft wijzigingen vanaf versie 18.2.7 voor eigen inference-servers. Wie een lokaal Qwen-model eerder onder providernaam local had geconfigureerd, moet die naam wijzigen: omp heeft nu zelf een provider voor kleine on-device modellen. Voor eigen Qwen 3.8-providers moet bovendien qwenTemplateReasoningEffort: true in de compatibiliteitslaag staan; zonder die instelling zou de chattemplate op xhigh kunnen uitkomen in plaats van het bedoelde effortniveau te ontvangen.

Operationeel belangrijker is de fallbacklogica. Volgens de documentatie stopt omp niet noodzakelijk wanneer een rolmodel niet resolveert of models.yml niet goed parseert: het kan een bekende provider als standaard kiezen, of uiteindelijk het eerste bruikbare model. De auteur beschrijft daarbij een eigen test waarin een aanwezige Bedrock-token een prompt naar Claude Opus 5.5 stuurde. Een enabledModels-allowlist, bijvoorbeeld alleen voor de eigen gateway, moet dat voorkomen en omp laten stoppen als er geen toegestaan model beschikbaar is.

Dat is een concrete aanvulling op de namiddagupdate van donderdag 17 september, die omp vooral als lokaal-cache- en contextoptimalisatieverhaal behandelde. Voor een lokale coding-agent is ‘OpenAI-compatibel’ dus niet genoeg als privacygrens: test met een requestlogger welke endpoint werkelijk wordt geraakt, maak toegestane providers expliciet en controleer projectlokale configuratie die een allowlist kan vervangen. De beschreven configuratie geldt voor omp en de genoemde versies, niet automatisch voor andere agentclients. Handleiding en configuratievoorbeelden · Reddit-discussie

NInfer combineert Bonsai 2 met n-gram-drafts — winst zit in herhaling

Een ontwikkelaar publiceert een Windows/CUDA-pad voor Ternary Bonsai 2 27B in NInfer, met MTP en daarbovenop n-gram-speculatie. De n-gramcache koppelt de laatste acht tokens aan eerder vervolg; bij terugkerende uitvoer — zoals code-edits, JSON, toolcalls of paden — kan de runtime volgens de auteur meer concepttokens per verificatiestap voorstellen. Bij vrije proza zou de toevoeging niets opleveren, maar ook niet vertragen.

Op één RTX 4090 meldt de maker voor Bonsai 250 tok/s bij editachtige prompts met MTP, oplopend tot 532 tok/s met n-gram-drafts; voor proza blijft de gerapporteerde snelheid 167 tok/s. De build is specifiek gericht op sm_89 en dus niet een algemeen Windows-recept. De auteur noemt verder 6,1 GB gewichten, maximaal 262K context en een OpenAI-/Anthropic-compatibele server, maar de gerapporteerde 45-taak-evaluatie en snelheden zijn volledig eigen metingen.

Dit is vooral een nieuwe runtime- en workloadbevinding, geen rehabilitatie van Bonsai als universeel agentmodel. Eerdere dekking liet al zien dat de kleine footprint op langere taken duur kan uitpakken in tijd en output. Meet daarom op eigen prompts zowel herhaalrijke edits als niet-repetitieve analyse, met identieke decode-instellingen; alleen de piek voor een diff zegt weinig over een complete agentsessie. Meetopzet, code en beperkingen

llama.cpp-PR richt CPU-prefill op tiled INT8-matrixwerk

Een nog open pull request voor llama.cpp voegt een tiled mul_mat-pad voor K-quants toe. Volgens de PR worden quants uitgepakt naar maximaal 256×256 INT8-tiles, waarna microkernels 16×16-tiles verwerken. De veranderingen omvatten onder meer VNNI-repacking, AVX2-optimalisaties en fixes voor ARM- en Windows-builds.

De meegeleverde benchmarks claimen 3–6× versnelling voor grote matrixvermenigvuldigingen, met break-even rond 4096×64 maal 64×4096. De cruciale tegenhanger staat in dezelfde bron: voor GEMV noemt de auteur ongeveer 80% van de eerdere performance, dus netto verlies. Dat onderscheid is relevant voor lokale CPU-serving: prefill en decode hebben niet automatisch dezelfde bottleneck.

De code is een PR, geen uitgebrachte llama.cpp-versie, en de fout- en performancecijfers zijn afkomstig uit de bijdrage zelf. Wie CPU-promptverwerking belangrijk vindt, kan dit hooguit als testkandidaat volgen: vergelijk dezelfde quant, promptlengtes en CPU-features met de hoofdbranch en houd decode apart van prefill. Pull request en benchmarknotities · Reddit-signaal

Onafhankelijke Flash Next-test bevestigt vooral Swifts tokenruil

Swift 1.5 voor Qwen3.8 Flash Next was al onderdeel van de einde-dagupdate van donderdag. Een nieuwe communitytest geeft nu een afzonderlijk datapunt voor precies die Flash-Next-variant: op 107 Aider-codinggevallen rapporteert de auteur 41,1% first-try en 86,9% retry-pass voor Swift, tegenover 40,2% en 90,7% voor het basismodel. De auteur noemt het verschil bij deze set niet statistisch significant.

De gemelde efficiencyruil is groter: Swift gebruikte mediaan 6.991 tokens en 608 seconden per geval, tegen 17.646 tokens en 1.542 seconden voor de basisvariant. Bij de twintig tokenzwaarste gevallen loste Swift volgens de post 16 op tegenover 17 voor de basis, met 29% van diens tokengebruik. Vooral C++ had in deze test meer verliezen dan Python en JavaScript.

Dit ondersteunt de richting van de oorspronkelijke Swift-claim — minder overdenken kan tijd besparen — maar is geen bewijs van gelijke kwaliteit in andere repositories, talen of agentharnesses. Zie het als een goede aanleiding om naast task pass-rate ook retries, wall-clock en tokenbudget in een eigen coding-eval te loggen. Testopzet en resultaten

Verder nog

• Ling Tiny 3.0 op CPU-only: een gebruiker meldt dat de 8B-MoE met 1B actieve parameters in llama.cpp op een laptop uit 2017 met een 7e-generatie i5 en 8GB RAM rond 10 tok/s draaide en na circa twintig minuten via een agentloop een eenvoudig netwerkscanscript afrondde. Dat is één ervaringsverslag, zonder reproduceerbare eval of energie- en kwaliteitsmeting, maar wel een bruikbaar signaal dat kleine actieve MoE’s op oude CPU’s praktisch te proberen zijn. Praktijkpost
• C versus Rust als AI-doeltaal: een X-discussie tussen Armin Ronacher en antirez stelt dat agents C gemakkelijker zouden schrijven en controleren dan Rust. Daar staat juist Rusts compiler- en geheugensafety tegenover; de thread levert geen benchmark of security-evaluatie. Neem er hooguit één procesles uit: gegenereerde code verandert de noodzaak van harde taal- en runtimegaranties niet. Discussie