Tin brengt BM25 naar Postgres; lokale AI krijgt scherpe praktijkmetingen voor Apple Silicon en Bonsai 2

PlanetScale presenteert Tin, een full-text-searchuitbreiding voor Postgres met BM25 en uitgebreide querymogelijkheden, maar zonder volledig open kern. Voor lokale AI zijn er tegelijk bruikbare realitychecks: Splash belooft hoge decode-snelheid op recente Macs met een gesloten modelpad, terwijl een nieuwe Bonsai 2-test vooral extra agenttijd en outputtokens meet.

Tin wil Postgres-search dichter bij een zoekengine brengen

PlanetScale introduceert Tin, een full-text-searchuitbreiding voor Postgres. Volgens de toelichting biedt die onder meer BM25-scoring met geoptimaliseerde top-k, instelbare scoring, boosting per expressie, span-/proximityqueries, termposities, negatieve expressies en highlighting. De praktische aantrekkingskracht is dat zoekdata niet als aparte tsvector-kopie hoeft te worden bijgehouden. Aankondiging · HN-discussie

Dat is interessant voor applicaties die nu Postgres als bron van waarheid gebruiken maar voor relevantere tekstzoektocht een tweede systeem overwegen. Het vervangt geen evaluatie: stemming, indexgrootte, schrijfgedrag, ranking en querytaal bepalen of het voor een eigen corpus beter uitpakt dan ingebouwde FTS of een externe index.

De belangrijke grens zit in de openheid. In de HN-discussie wordt genoemd dat niet alle lagen open zijn, met risico op afhankelijkheid van een leverancier; een betrokken ontwikkelaar stelt daartegenover dat Tin wel bijdragen aan Postgres, LLVM en pgrx heeft teruggeleverd. Dat debat verandert niets aan de operationele vraag: controleer licentie, exportpad en welke componenten je zelf kunt draaien vóór je een zoeklaag erop bouwt.

Splash zet een smal, snel pad op Apple Silicon neer

Inco Splash wordt aangekondigd als open-source inference-engine voor recente Apple-Silicon-Macs. De post noemt voor een specifieke Qwen3.8-27B-variant tot 144 tok/s op een M5 Max, plus integraties met onder meer Claude Code, Codex, OpenCode en LM Studio. De gebruikte modelgewichten zijn volgens de toelichting vlak op 4 bit gequantiseerd en de KV-cache op INT8. Aankondiging en discussie

Dat is vooral relevant voor lokaal agentwerk op Macs, waar decode-snelheid snel de beperkende factor wordt zodra taken uitwaaieren naar subagents. Maar beschouw de 144 tok/s als een leverancierscijfer voor die ene machine, quant en engine — niet als een vergelijkbare Ollama-, MLX- of algemene Qwen-score.

Ook de keuzevrijheid is nu beperkt: in de beschikbare discussie wordt gewezen op ondersteuning voor slechts twee eigen modellen, geen MLX- of GGUF-pad en een eis van M3 of nieuwer. Dat maakt Splash vooralsnog een specialistische route om naast een bestaande runtime te testen, niet een algemene vervanger. De Apache-2.0-licentie maakt inspectie van de engine mogelijk, maar zegt op zichzelf niets over de herleidbaarheid van alle kernels, drafters of snelheidsclaims.

Bonsai 2 verliest in één agentproef vooral tijd

Er is een concreet nieuw datapunt sinds de einde-dagupdate van gisteren, die Bonsai 2 al naast andere Qwen3.8-quants zette. Een gebruiker vergelijkt nu Bonsai PQ2 van 6,42 GiB met Qwen3.8-27B IQ3_XXS van 10,18 GiB op vier UI-generatietaken, met hetzelfde llama-server-binaire bestand. Beide voltooiden de vier taken en de vaste assertions, maar IQ3 finishte volgens de gepubliceerde logs in 8:00 tegen 24:09, met 27.197 tegenover 84.176 outputtokens. De gewogen decode was 83,59 tegenover 64,91 tok/s. Testopzet, resultaten en repository

Dat is nuttiger dan alleen een footprintvergelijking: bij een agent telt de totale doorlooptijd vaak zwaarder dan de bestandsgrootte. De auteur wijst zelf op een cruciale asymmetrie: IQ3 draaide met MTP, Bonsai niet en gebruikte modified n-gram speculative decoding. De meting is dus geen zuivere uitspraak dat ternary gewichten de oorzaak zijn, en vier taken vormen geen algemene benchmark.

De praktische conclusie is bescheiden: Bonsai kan voor een harde VRAM-limiet nog steeds interessant zijn, maar meet naast score en tok/s ook uitgevoerde stappen, outputvolume en wall-clock-tijd op eigen taken. Een kleinere quant die drie keer zoveel tekst produceert, is niet vanzelf goedkoper of sneller.

Een 16GB-Mac-bouwverslag maakt contextkosten tastbaar

Een ontwikkelaar documenteert zes dagen bouwen aan een lokale assistent op een M1 Pro met 16GB, Gemma 4 en Ollama. De bruikbaarste bevinding gaat over prefix-caching: een veranderlijke datum bovenaan de systeemprompt maakte iedere vervolgvraag opnieuw duur; door datum, retrieval en herinneringen in een blok bij de gebruikersbeurt te zetten, daalde de gemelde tijd tot eerste token van ongeveer 1,8–2,0 naar 0,4–0,5 seconde. Bouwverslag en meetdetails

Ook de geheugenroute is concreet. Twee modellen bleken niet tegelijk resident ondanks lagere cijfers in ollama ps, omdat embeddingtabellen ook hostgeheugen vragen. Daarnaast groeide een automatisch geheugen naar 109 feiten en kostte volledige injectie circa 2.300 tokens per beurt; selectie van de dichtstbijzijnde tien feiten bracht dat volgens de auteur naar ongeveer 150 tokens.

Dit is één stack en een kleine eigen testset, geen algemene Gemma- of Ollama-evaluatie. Maar de ontwerpregels zijn goed te toetsen: houd een cachebaar prefix stabiel, plaats variabele context buiten dat prefix, en maak opgeslagen ‘feiten’ zichtbaar en verwijderbaar. De auteur rapporteert bovendien dat een testinstructie abusievelijk als permanente voorkeur werd opgeslagen — precies het soort fout waarvoor een geheugenlaag een UI en regressietests nodig heeft.

OpenAI beschrijft modelhulp bij chip-bring-up, niet autonoom chipontwerp

IEEE Spectrum beschrijft hoe OpenAI interne modellen zou hebben ingezet rond Jalapeño, een eigen AI-chip. Nadat eerste chips uit de foundry kwamen, liet het team volgens het artikel modellen software voor benchmarks optimaliseren. Voor één DeepSeek multi-head-latent-attention-kernel zou de benutting van 0,31% naar 88,94% van het theoretische compute-/bandbreedteplafond zijn gegaan in ongeveer 40 uur; OpenAI noemt dat reproduceerbaar. Artikel · HN-discussie

Dit is geen bewijs dat een model zelfstandig een chip heeft ontworpen of hardwarecorrectheid heeft bewezen. Het beschreven werk gaat juist over software en kernels ná silicon bring-up — een gebied waar veel iteraties tegen meetbare benchmarks mogelijk zijn. Dat maakt het wel een relevant voorbeeld van een sneller feedbackcircuit tussen nieuwe hardware en bruikbare inference-software.

De cijfers komen uit het artikel en van OpenAI; er is in de beschikbare context geen onafhankelijke reproductie. In de HN-discussie wordt bovendien terecht onderscheid gemaakt tussen codeoptimalisatie binnen een chipproject en de veel zwaardere taak van hardwareverificatie. Lees dit dus als een case study voor benchmarkgestuurde kernelengineering, niet als een algemene betrouwbaarheidsgarantie voor AI in hardwareontwikkeling.

Verder nog

• Best-of-N is geen gratis nauwkeurigheid: Sebastian Raschka publiceert een nieuwe uitleg over inference scaling met temperatuur, top-p, multinomial sampling, self-consistency en best-of-N. Hij noemt daarbij meer dan 2× nauwkeurigheidswinst, maar verduidelijkt in een reactie dat die concrete demonstratie een vast model van 0,6B betreft. Zie het als een leerzame techniek om op eigen taken te meten, met extra latency en tokenkosten als directe ruil. Thread en video