Gemelde Firebase-iOS-storing maakt dependencyrisico zichtbaar; lokale inference krijgt nieuwe geheugen- en RAG-paden

Een gemelde Firebase-storing trof iOS-apps die de SDK gebruiken; volgens de beperkte HN-draad was de situatie opgelost, maar konden klanten nog uren effect merken. Tegelijk verschijnen voor lokale AI twee nadrukkelijk experimentele bouwstenen: een andere manier om MTP en KV-cache bij lange context samen in geheugen te houden, en een RAG-opzet die lichte extractiemodellen met SQLite combineert.

Firebase-incident: controleer iOS-crashtelemetrie en dependencygedrag

Een nieuw HN-bericht meldde dat Firebase iOS-apps vanaf de ochtend konden crashen. In de volledige opgeslagen discussie staat vervolgens een verwijzing naar een als opgelost gemeld incident; een deelnemer schrijft dat effecten nog tot vier uur kunnen aanhouden. De gelinkte oorspronkelijke X-post was in deze crawl niet uitleesbaar en de draad bevat geen technische root cause, getroffen versies of onafhankelijke statuspagina. Daarom is dit geen bevestiging dat alle Firebase-diensten of alle iOS-versies geraakt waren.

Voor teams met Firebase in een iOS-app is het desondanks een praktisch signaal: controleer crash- en releasecijfers rond het incidentvenster, houd de gebruikte SDK-versie bij en beoordeel of remote configuratie, SDK-initialisatie of een providerfout een app bij start kan laten omvallen. Een dependency die in veel apps vroeg initialiseert verdient een gecontroleerd foutpad, ook wanneer de precieze oorzaak van deze melding nog niet vaststaat. HN-discussie en statusverwijzing

Adaptive KV-Cache Streaming V2 wil MTP bij 256K context betaalbaarder houden

Een ontwikkelaar presenteert een tweede versie van een llama.cpp-fork voor adaptive KV-cache streaming. De nieuwe aanpak laat de MTP-cache als logische attentionlaag meedraaien, houdt de historie in hostgeheugen en deelt GPU-pagina’s en werkruimte met de hoofdroute. Volgens de auteur voorkomt dat een afzonderlijke MTP-cache en -workspace als vaste extra VRAM-kosten optellen.

De gemelde meting op een RTX 5070 Ti met 16 GB is ongeveer 82 tok/s decode van 8K tot 72K context, 35 tok/s bij 144K, 30 bij 192K en 19 bij 256K, met MTP-draftlengte 3. De auteur schrijft dat de uitvoer van een test van 256 gegenereerde tokens identiek bleef aan de stock-kerneluitvoer. Dat is interessant voor lange lokale agentruns, omdat contextruimte vaak direct concurreert met speculative decoding.

Maar de resultaten zijn makersmetingen op één fork en één inputcorpus; de auteur noemt zelf een vermoedelijk gunstige acceptatiegraad op Wikipedia-tekst. De fork is bovendien niet bedoeld als één grote upstreamwijziging. Vergelijk dus op eigen hardware met MTP uit én aan, op repositorycontext en toolcalls, en meet naast decode ook prefill, VRAM-piek, acceptatiegraad en taakuitkomst. Projectpost met architectuur en sweep

Hillock kiest voor lichte extractie en een expliciete ‘ik weet het niet’-grens

Hillock v0.7 is een nieuw AGPL-3.0-project voor lokale RAG op krappe hardware. In plaats van een zware vector-DB en een LLM-pass voor documentextractie noemt de maker een combinatie van lichte bi-encoders voor subject-predicate-object-triples, SQLite met WAL en een hyperdimensionale similariteitscheck vóór een LLM-aanroep. De post claimt minder dan 1,2 GB VRAM tijdens extractie — of een CPU-only-route — en circa 1,5 GB RAM.

Het bruikbare ontwerpidee is de negatieve uitkomst: wanneer de opgeslagen graaf onvoldoende overlapt met de vraag, blokkeert Hillock volgens de auteur de LLM-call in plaats van een antwoord te laten gokken. Dat kan voor een lokale persoonlijke kennisbank nuttiger zijn dan een overtuigend maar niet-onderbouwd antwoord. Het is echter geen bewijs van ‘nul hallucinaties’: extractiefouten, verkeerde overeenkomstmaten en een onvolledige kennisgraaf blijven mogelijke foutenbronnen.

Wie dit wil proberen, kan het daarom het beste naast een bestaande RAG-pijplijn zetten met vragen die wel, deels en niet in de bronset staan. Meet retrieval-recall, foutieve weigeringen, bronverwijzingen en wat de generator doet wanneer de gate wél doorgaat — niet alleen het VRAM-verbruik. Projectaankondiging

Nvidia zet een zeer gespecialiseerd programmeermodel open

Nvidia heeft Nemotron-Labs-3-Competitive-Coding-550B-A55B-NVFP4 gepubliceerd: een checkpoint met 550 miljard parameters, waarvan 55 miljard actief, met maximaal 262K context. De modelkaart beschrijft een fine-tune op 477.642 synthetische reasoning-traces rond 22.000 competitieve-programmeerproblemen. De licentie is OpenMDW 1.1, dus niet zonder meer gelijk aan een permissieve open-source-licentie.

Nvidia meldt dat de combinatie van dit model met zijn iteratieve GenCorrect-strategie in één prospectieve run 535,4 van 600 scoorde op de IOI 2026-set. Die score lag volgens de kaart boven de genoemde gouden-grens en de hoogste menselijke score, maar de run zat buiten de officiële rangschikking en was één evaluatie. De inference-opstelling gebruikt bovendien kandidaatgeneratie, evaluatorfeedback en herhaling; dit is niet hetzelfde als een enkel antwoord van een algemene code-assistent.

Dat onderscheid is juist het interessante. Het checkpoint is volgens Nvidia bedoeld voor algoritmische problemen, code-redeneren en onderzoek naar test-time compute — niet voor algemene chat of productie-agents. De gedocumenteerde NVFP4-opstelling vraagt daarnaast Blackwell-GPU’s en een zware vLLM-configuratie. Zie het daarom als reproduceerbaar onderzoeksmateriaal voor evals en gespecialiseerde solver-runs, niet als een directe lokale vervanger voor een gewone coding agent. Modelkaart, evaluatiecontext en deploymentnotities · Reddit-discussie

Verder nog

• Godot krijgt een Conan-route voor native bibliotheken: godot-cpp 10 staat nu in ConanCenter; het Conan-artikel laat zien hoe je een GDExtension als gewone CMake-library bouwt en bijvoorbeeld flecs toevoegt. Dat kan cross-platform dependencybeheer vereenvoudigen, maar de HN-discussie wijst op een reëel Linux-randgeval: stem ABI en libstdc++-versionering af op de Godot-build waarmee je extension moet laden. Handleiding met voorbeeld · HN-discussie