Hy-Memory-30B-A3B stille release: Tencent zette een geheugenschrijver op Hugging Face zonder lanceringsbericht

Hy-Memory-30B-A3B is een mixture-of-experts-model met 30 miljard parameters van het Hunyuan-team dat geen vragen beantwoordt. Het schrijft geheugen. Het bepaalt wat een langdurig draaiende agent moet onthouden, hoe precies dat geformuleerd moet worden, en hoe een nieuw feit een oud feit moet overschrijven in een persistente geheugenbank — de stap die elk agent-framework tot nu toe aan een general-purpose chatmodel heeft overgelaten. De gewichten zijn op 15 oktober 2026 op Hugging Face verschenen, het technische rapport volgde dezelfde dag onder arXiv 2610.22196, de GitHub-repository ging die middag open en de tag v1.0.0 werd op 16 oktober uitgebracht. Op het moment van schrijven registreert de repository nul downloads en een like-aantal in de enkele cijfers op de modelkaart. Er is geen lanceringspagina van de leverancier, geen prijsstelling, geen gehost endpoint en geen aankondiging die we buiten de README van het project zelf hebben kunnen vinden. Benchmarks verouderen en prijzen bewegen; het faalregister niet: de gedocumenteerde AI-incidenten en agentstoringen achter modellen in deze klasse zijn verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernstgraad, betrouwbaarheidsclassificatie en betwist-markering heeft.

Dat is de eerlijke vorm van deze release: een paper, een repo, een checkpoint en een evaluatietabel die beweert Claude Opus 5 te verslaan. Alles hieronder is ofwel rechtstreeks uit de repository gelezen of gelabeld als de eigen ongeverifieerde bewering van de leverancier. Niets hiervan is door een derde partij gereproduceerd, omdat niets hiervan door een derde partij is uitgevoerd.

Wat er daadwerkelijk in de repository zit, en wat niet

De controleerbare feiten, elk op één regel:

• Model — tencent/Hy-Memory-30B-A3B, gepubliceerd onder Apache 2.0, getagd als Engels en Chinees.

• Grootte — in totaal 30B parameters, ongeveer 3B actief per token, wat het achtervoegsel A3B betekent.

• Architectuur — 48 lagen, waarvan 1 een dense feed-forwardblok is en 47 sparse MoE-blokken; 128 experts per blok met top-8-routering plus één gedeelde expert; verborgen grootte 2.048; tussenbreedte van experts 768; 32 attention-heads tegenover 4 key-value-heads met query-key-normalisatie; een sigmoid-router met een expert-biasterm.

• Context — 262.144 posities uit het configuratiebestand, met een RoPE-basis van 11.158.840.

• Voetafdruk — 51 safetensors-shards met een totaal van ongeveer 60,1 GB in BF16.

• Geserveerd met — vLLM, getest tegen v0.31.0, achter een OpenAI-compatibel endpoint. De kaart noemt geen andere runtime en geen inferenceprovider.

• Niet aanwezig — er is geen GGUF, geen FP8- of NVFP4-build, geen fine-tune, geen kwantisatie en geen enkele afgeleide in de Hugging Face-zoekindex. Het team heeft één BF16-checkpoint op één precisie uitgebracht.

Die laatste regel is belangrijker dan hij op het eerste gezicht lijkt. Het Granite-team bracht FP8-, MXFP4-, NVFP4- en GGUF-builds van Granite 4.2 30B binnen enkele dagen na de basisgewichten uit. Liquid AI levert een Q4_K_M GGUF van LFM2.5-24B-A2B van 14,5 GB. Die leveranciers vertellen je waar zij verwachten dat het model draait. Een BF16-checkpoint van 60 GB zonder kwantisatiepad vertelt je dat deze is bedoeld voor wie de GPU's al heeft — hoogstwaarschijnlijk de mensen die op schaal geheugeninfrastructuur draaien, precies het publiek dat de modelkaart noemt.

Waar het model eigenlijk voor bedoeld is

Het onderscheid tussen een geheugenschrijver en een agent is de hele kern van deze release, en het is gemakkelijk te missen omdat de modelkaart leest als elke andere modelkaart.

Een agentframework — Mem0, MemOS, Hy-Memory, EverMemOS — staat tussen een gesprek en een persistente opslag. Bij elke beurt moet iets de inkomende uitwisseling lezen, beslissen welke fragmenten het waard zijn om te bewaren, ze zo formuleren dat ze later terug te vinden zijn, en ze afstemmen op wat al is opgeslagen. Vandaag de dag is dat iets een frontier-chatmodel met een frameworkspecifieke prompt eraan vastgeschroefd. De manier waarop de paper het probleem framed, is kosten en overdraagbaarheid: een algemeen model achter een geheugenprompt is duur om bij elke beurt te draaien, en een schrijver die is afgestemd op het protocol van één framework, gaat niet zonder meer over naar dat van een ander.

Hy-Memory-30B-A3B is getraind om die schrijver te zijn binnen drie frameworks tegelijk — Mem0, MemOS en het eigen Hy-Memory van het project — over chat-, werk- en codeerscenario's — en wordt vervolgens getest op een vierde, EverMemOS, dat volledig buiten de training is gehouden. De achtergehouden testopstelling is de interessantste ontwerpbeslissing in het paper. Cross-framework-transfer is de bewering waarop het hele model rust, en één framework achterhouden is hoe je dat zou testen als je er serieus over wilde zijn.

Het model wordt aangestuurd met reasoning_effort: "no_think" en temperatuur 0.0 in de eigen quickstart van het project, wat een veelzeggende standaardinstelling is. Een schrijver hoeft niet te beraadslagen; hij moet deterministisch en goedkoop zijn, want hij wordt bij elke afzonderlijke beurt aangeroepen.

De tweefasige training, in eenvoudige bewoordingen

De kaart beschrijft de methode als Memory On-Policy Distillation, gevolgd door Attributed Memory Reinforcement Learning, en in de tweede fase ligt de bijdrage van het artikel.

In de eerste fase geeft een leraar dense supervisie op geheugentoestanden die de student zelf heeft geproduceerd — on-policy, dus de student wordt gecorrigeerd op zijn eigen fouten in plaats van op de trajectorieën van een leraar. In de tweede fase bouwt het framework geheugenbanken op uit rollouts, scoort ze chunk voor chunk, en draagt de geselecteerde bank vooruit over vensters in plaats van deze tussen vensters te resetten. Die doorgifte is het deel dat de training afgestemd houdt op hoe het model daadwerkelijk wordt ingezet, waarbij een bank nooit leeg is en elke schrijfactie bovenop alles wat eerder is geschreven terechtkomt. Credit wordt toegekend op chunk-niveau, met een expliciete straf voor overopslag — een schrijver die alles behoudt is nutteloos, dus de beloning moet dat meerekenen.

Niets daarvan is onafhankelijk geverifieerd. Het is een coherente beschrijving van een trainingsmethode, gepubliceerd samen met een repository die de code bevat, wat meer is dan waar de meeste claims op de dag van release mee komen.

De evaluatie, gelezen zoals die gelezen moet worden

Hier is de kop, en hier is alles wat er mis is met het klakkeloos aannemen ervan.

• Hy-Memory-30B-A3B — 55,49 macro-gemiddelde over vier harnesses.

• Claude Opus 5 — 54.62.

• DeepSeek V4.1 Flash — 53,64.

• Hy3 — 51,63.

• Qwen3.6-35B-A3B — 50.37.

• Qwen3-30B-A3B — 44.37.

Een 3B-actieve specialist die een frontier-model met 0,87 punt verslaat op een geheugentaak is een aannemelijk resultaat — de taak is smal en de specialist is ervoor getraind, hetzelfde argument dat kleine codecompletion-modellen concurrerend maakt bij het bewerken van één bestand. Maar de kanttekeningen zijn cruciaal. Elke benchmark in de hoofdmatrix draait op een vaste substeekproef van 20% in plaats van de volledige set. De evaluatie verandert alleen de writer en houdt de harness, prompts, retrievalconfiguratie, antwoordmodel en judge constant, wat het juiste experimentele ontwerp is, maar het ontwerp en de harness zijn van het project zelf. De spreiding per harness is ook groter dan het macro-gemiddelde doet vermoeden: het model leidt op Mem0 met 54,02 en op Hy-Memory met 60,55, en zijn MemOS-resultaat van 50,51 ligt 0,01 punt boven de 50,50 van Claude Opus 5 — een nek-aan-nekrace die als overwinning wordt gepresenteerd. Zijn sterkste cijfer, 56,89 op de achtergehouden EverMemOS-harness, is het cijfer dat het meest zou tellen als het gereproduceerd zou worden, en het cijfer dat niemand heeft geprobeerd te reproduceren.

Behandel het allemaal als door de leverancier gerapporteerd. Niet als verdacht — als niet gereproduceerd, wat iets anders is. Een model dat gisteren is uitgebracht met een repo en een paper heeft het recht verdiend om getest te worden, niet het recht om geloofd te worden.

Die pagina is de enige primaire bron voor de hele release. Er is geen blogpost, geen aankondiging van de leverancier en geen artikel van een derde partij om het tegen te controleren.

Wat nog onbevestigd is, ronduit gezegd.

• Er bestaat geen enkele onafhankelijke benchmark, van welke aard dan ook. Niets op Artificial Analysis, geen arena-plaatsing, geen door derden uitgevoerde harness-run.

• Geen reproductie van de cross-harness-tabel. Met name het achtergehouden EverMemOS-resultaat is een enkele leveranciersrun.

• Geen kostencijfer uit de praktijk. Geheugenschrijfacties zijn een hoogfrequente workload met korte output, maar niemand heeft tokens per schrijfactie of kosten per gesprek voor dit model gepubliceerd.

• Geen kwantisatie, dus geen gemeten geheugengebruik onder 60 GB.

• Geen bewijs over wat het doet wanneer het geheugenframework zijn protocol wijzigt — het artikel test overdracht tussen frameworks, niet tussen versies van één framework.

• Of het team van plan is het te hosten. De kaart vermeldt dat het model niet door enige inferentieprovider is geïmplementeerd, en niets in de repo wijst erop dat er een gehoste endpoint zit aan te komen.

Als je het wilt uitvoeren, en waar een router past

Realistisch gezien is dit een beslissing over self-hosting. Het pad in de kaart is vLLM 0.31.0 achter een OpenAI-compatibele API, wat betekent dat het model in een bestaande harness past met alleen een base-URL-wijziging. Dat is het goedkope deel. Het dure deel is dat een BF16-checkpoint van 60 GB zonder gekwantiseerde tegenhanger serieuze hardware nodig heeft voordat het ook maar één geheugen schrijft.

Het is de moeite waard om precies te zijn over wat een router hier wel en niet doet. Hy-Memory-30B-A3B staat niet in de catalogus van OrcaRouter en wij hosten het niet — de route ernaartoe is de checkpoint en je eigen GPU's. Wat een router dekt, is de andere helft van de harness. Een geheugenschrijver wordt naast een antwoordmodel aangeroepen, en het antwoordmodel is meestal een gehost frontier-model dat de bank terugleest en antwoordt. OrcaRouter geeft je één API-sleutel voor 200+ gehoste modellen tegen 0% opslag, zodat prijsverlagingen van providers dezelfde dag worden doorgegeven, met automatische failover als een backend degradeert. De routing-DSL is het stuk dat specifiek bij deze architectuur past: het stelt een zelfgehost endpoint en een gehost endpoint samen tot één aanroep, precies de vorm van een geheugensysteem — een goedkope specialist op het schrijfpad, een frontier-model op het leespad, één sleutel voor beide.

Het patroon is het waard om te bouwen, zelfs voordat je de writer draaiende hebt, omdat het identiek is of het schrijfpad nu Hy-Memory-30B-A3B is of een algemeen model met een geheugenprompt. De router maakt het niet uit welke, en het later omwisselen van de een voor de ander zou een aanpassing in de routeringstabel moeten zijn in plaats van een herschrijving.

Wat te kijken

Drie dingen zouden dit van een paper naar een product brengen. Een gekwantiseerde build: een FP8- of Q4-checkpoint is het verschil tussen een datacentermodel en een model dat iemand op een werkstation kan evalueren, en het ontbreken ervan is veruit het grootste obstakel voor iedereen die de cijfers wil controleren. Een onafhankelijke harness-run: de held-out transferclaim van EverMemOS is de hele these, en die verdient een test door iemand die er geen belang bij heeft. En een gehoste endpoint: niet omdat selfhosting verkeerd is, maar omdat het eigen ontwerp van het model — deterministisch, no-think, korte outputs, bij elke beurt aangeroepen — een natuurlijke fit voor een API is, en het ontbreken ervan suggereert dat het team dit ziet als infrastructuur die het uitlevert aan mensen die al infrastructuur draaien.

Tot dan is de juiste instelling degene die de release zelf uitnodigt. Lees de repo, voer de quickstart uit op welke hardware je ook hebt, en beschouw de tabel als een hypothese.