Hy-Memory-30B-A3B vs LFM2.5-24B-A2B: Two Sparse Specialists, Only One of Them Runs on Your Machine

Hy-Memory-30B-A3B and LFM2.5-24B-A2B are the same idea built by two companies who disagree about who is going to run it. Both are sparse mixture-of-experts models in the mid-20-billion range with two to three billion parameters active per token — the Hunyuan team's memory writer at 30B total and roughly 3B active, open-sourced on October 15, 2026; Liquid AI's on-device agent model at 24.0B total and 2.45B active, shipped October 13, 2026. Liquid shipped a Q4_K_M GGUF at 14.5 GB and a quantisation-aware-trained build at 13.6 GB beside the full-precision weights. The team shipped one 60.1 GB BF16 checkpoint and no quantised alternative at all. What the numbers cannot tell you is whether any of it has gone wrong in the field: the documented AI incidents and agent failures around models in this class are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

That difference in packaging is not an accident of scheduling, and reading it correctly tells you more about the two models than either benchmark table does. It also happens to be the reason these two are usually compared for the wrong reason — people see "small sparse MoE" on both cards and assume they are competing for the same deployment slot. They are not. One wants to be inside the agent framework on your laptop. The other wants to be inside a memory pipeline on your server, and the two jobs barely overlap.

The one thing they genuinely share

Both are sparse. Both hold a large parameter count resident and read a small slice of it per token. That is the entire architectural overlap, and it is worth stating what sparsity does and does not buy, because it is the most consistently misunderstood property in this size class.

A 24B-A2B checkpoint does not fit in 2.45 billion parameters' worth of memory. Every parameter in the file has to be loadable; what the active count buys is throughput per token, not footprint. Liquid's own card is straightforward about this — the model is a 24-billion-parameter checkpoint, and running it means holding 24 billion parameters somewhere. Anyone who reads "2.45B active" and reaches for a small machine is going to have a bad afternoon. The same applies to Hy-Memory-30B-A3B's 3B active figure against its 60 GB BF16 file.

Beyond that shared property the two diverge on almost every axis that matters.

Notice what that repository is. A vendor that publishes a separate GGUF repository is stating, in the most concrete way available, that models it ships are meant to be downloaded and run on hardware somebody already owns. The commit history on it is two commits long and days old — this is not an afterthought bolted onto a nine-month-old release.

Specs, side by side, with the packaging row included

• Total / active parameters — Hy-Memory-30B-A3B 30B total, ~3B active vs LFM2.5-24B-A2B 24.0B total, 2.45B active.

• Layer construction — 48 layers for Hy-Memory-30B-A3B, one dense block and 47 MoE blocks with 128 experts at top-8 routing plus a shared expert; LFM2.5-24B-A2B runs 40 layers, 30 of them double-gated short-convolution blocks and 10 grouped-query attention, with 64 experts per MoE block at top-4 routing.

• Context — 262,144 positions for Hy-Memory-30B-A3B vs 131,072 for LFM2.5-24B-A2B, which is itself up from 32K in the previous generation.

• Weight footprint — 60.1 GB across 51 BF16 shards vs 48 GB in BF16, with a Q4_K_M GGUF at 14.5 GB and a QAT QAD-Q4_0 at 13.6 GB.

• Licence — Apache 2.0 for Hy-Memory-30B-A3B vs the LFM1.0 licence for LFM2.5-24B-A2B, which is a custom grant rather than an OSI-approved one and worth a read before commercial deployment.

• Training corpus — 36T tokens across 16 languages at a 128,000-token vocabulary for LFM2.5-24B-A2B; the Hy-Memory card specifies English and Chinese and does not publish a token count for Hy-Memory-30B-A3B.

• Documented purpose — memory writing inside Mem0, MemOS, Hy-Memory and (held out) EverMemOS versus on-device agents with reasoning traces, tool calling and agentic reinforcement learning inside real harnesses.

• Quantisation published by the vendor — none vs four formats.

Note the last row again. Liquid AI published GGUF, FP8, ONNX and MLX-4bit builds of LFM2.5-24B-A2B within days of the base weights, and the community added more. That is a vendor saying, in the most concrete way available, that this model is meant to be downloaded and run locally. The Hy-Memory release says the opposite without ever stating it: one precision, one format, 60 GB, and a card that names vLLM 0.31.0 as the way to serve it.

What each was trained to do, and why it isn't the same job

LFM2.5-24B-A2B is an agent. Liquid positions it as a fast, private executor that always reasons before answering and calls tools well — its published tool-use and instruction-following numbers are the strongest part of its table, with IFEval at 96.75 and IFBench at 74.69 among the standouts. The company's own guidance is candid about the weakness: do not point it at knowledge-heavy questions on its own, pair it with retrieval or web search instead. That is a model built to act, with its knowledge deliberately outsourced.

Hy-Memory-30B-A3B does not act at all. It reads a conversation and writes memory. Its inputs are exchanges and its outputs are structured records — the Hy-Memory quickstart asks it for a JSON object containing a list of self-contained memory strings, run at temperature 0.0 with reasoning switched off. Where LFM2.5-24B-A2B is judged on whether it completed a task, Hy-Memory-30B-A3B is judged on whether the bank it wrote produced a better answer later. The evaluation is downstream of the model, which is why the Hy-Memory table compares writers rather than models — every row changes the writer and holds the answer model, judge, retrieval config and prompts fixed.

The evidence gap, which is not symmetrical

Both sets of numbers are the vendor's own. But they are not equally useful.

Liquid AI ran its own model against baselines in the same vLLM environment and published the rows — the LFM2.5-24B-A2B card includes direct comparisons against Qwen3.6-35B-A3B and other models, on the same harness, which makes the relative shape of the table at least internally consistent. Its claims are auditable in the sense that anyone with the GGUF can attempt to reproduce them on modest hardware this week.

The Hy-Memory evaluation is designed differently and is harder to check. The main matrix runs on a fixed 20% subsample of each benchmark rather than the full set, which is a defensible choice for cost and an indefensible one if you want to lean on small margins. And small margins are what the headline rests on: 55.49 macro average for Hy-Memory-30B-A3B against 54.62 for Claude Opus 5 is a gap of 0.87 of a point. On the MemOS harness the gap is 0.01 — 50.51 against 50.50. Meanwhile the vertex of the claim, the 56.89 on the held-out EverMemOS harness, is the single result most worth testing and the one nobody has run.

Neither vendor has an independent score for these two models. For LFM2.5-24B-A2B that is a two-day-old inconvenience. For Hy-Memory-30B-A3B it compounds with the hardware problem: you cannot casually reproduce a 60 GB BF16 model's numbers the way you can re-run a 14.5 GB GGUF.

If your agent needs both a memory and a mouth

The practical reading is that these two are complements in a system, not rivals in a bake-off, and the deployment split falls out naturally.

A memory writer fires on every turn with short outputs — a high-frequency, low-complexity, must-be-deterministic workload. An on-device agent executor is invoked when there is a task to do, needs to plan and call tools, and benefits from running near the data. A team building a private agent stack with no third-party calls could plausibly want the write path and the act path to be two different small models, each doing the one thing it was trained for, both running locally.

That is where the router question lands. OrcaRouter is one API key across 200+ hosted models at 0% markup, and its routing DSL composes multiple models into a single call — which is the mechanism that lets a locally served writer and a hosted frontier model answer as one endpoint, with automatic failover when a backend degrades. To be exact about what applies here: neither Hy-Memory-30B-A3B nor LFM2.5-24B-A2B is in our catalogue and we host neither. The route to both is the checkpoint and your own hardware. What a router covers is the read path and the planning around it, and the ability to swap which model fills a slot without changing the calling code.

Worth doing before you need it. The routing table is cheap to write now and expensive to retrofit once an agent framework has hard-coded endpoints in ten places.

That card is the fair summary of the difference. Liquid AI's own line is that LFM2.5-24B-A2B is built to run where the user is. The Hy-Memory team never makes an equivalent claim, and the 60 GB file behind Hy-Memory-30B-A3B does the opposite.

Which to pick up first

If you want to see a sparse mid-size model running on your own hardware this week, LFM2.5-24B-A2B is the obvious first stop — the download is 14.5 GB, the licence needs reading, and the tool-calling numbers are the part of its table most likely to matter to you.

If your agent has a memory problem that grows with every conversation, Hy-Memory-30B-A3B is aimed squarely at it, and there is nothing else quite like it in the open. Budget for the hardware before you budget for the time.