Liquid AI’s 100B Gamble: The Speed-First Architecture That Could Break the LLM Scaling Curse

Liquid AI’s 100B Gamble: The Speed-First Architecture That Could Break the LLM Scaling Curse

Liquid AI is teasing a 100B-parameter model that could flip the ‘bigger is better’ narrative. Here’s why speed-first architecture matters more than parameter count.

Liquid AI’s CEO Ramin Hasani dropped a poll on X asking the community what they want next: more sub-2B models, a 4B, a 30B, or a 100B MoE. The 362 votes split across options, but the signal is clear, Liquid AI is eyeing a 100B-parameter model. For a company that built its reputation on making 350M-parameter models scream on CPUs, this is a big deal.

The reaction from the AI community was predictable: excitement mixed with heavy skepticism. Some questioned whether Liquid AI even has the compute to train something that large. Others pointed out that a 100B MoE with low active parameters isn’t that different from a smaller dense model hardware-wise. Both takes miss the point.

Liquid AI isn’t trying to compete with GPT-5 or Claude 4 on raw benchmark scores. They’re trying to prove that speed and efficiency can be frontier features, not trade-offs. And they’ve got the receipts to back it up.

LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook
LFM2.5-DSpark achieves up to 3.2x faster inference across hardware from H100 GPUs to MacBooks.

The DSpark Pre-Game: Why Speed Is the New Benchmark

Two days before Hasani’s poll, Liquid AI dropped LFM2.5-DSpark, a speculative decoding system that delivers up to 3.2x faster inference across hardware from H100s to MacBooks. The numbers on an M4 Max MacBook Pro with FP16 GGUF weights tell the story:

  • LFM2.5-1.2B-Instruct: 2.54x mean speedup (138 → 350 tok/s)
  • LFM2.5-2.6B: 2.27x mean speedup (61 → 139 tok/s)

The architecture is clever. A parallel draft backbone proposes a block of tokens in one forward pass, a Markov-chain head adds dependency between neighboring tokens, and the target model verifies the whole block at once. Liquid AI’s prior 24B-parameter MoE model that redefined efficiency on consumer hardware showed they could scale this approach up.

But here’s the thing: the speedup varies by architecture. As Liquid AI admitted, LFM2.5-8B-A1B is the strongest case on the H100 and the weakest on device at 1.18x mean on M4 Max (90 → 106 tok/s). That traces to how mixture-of-experts models currently run on Metal in llama.cpp.

This is crucial context for the 100B question. If they can’t get MoE inference right on consumer hardware, a 100B MoE model becomes cloud-only, which defeats their entire edge-first philosophy.

The Compute Reality Check

Skeptics immediately raised the compute question. Training a 2-5B model takes vastly less compute than a 100B MoE model. Even with efficient architectures, the training token volume scales with global model parameters, not just active ones. Training a 100B-A5B MoE requires roughly 20x less compute than a dense 100B, but it’s still nowhere near the cost of a 5B dense model.

For context, GPT-4 reportedly cost over $100M to train. A 100B MoE is a fraction of that, but still a significant bet for a startup. That’s why the community response was mixed, people want the model but question the feasibility.

The counterargument: Qwen runs polls like this all the time and rarely delivers every variant. Even with Alibaba’s massive compute budget, they typically release 1-2 variants. So a poll doesn’t guarantee a 100B release.

But Liquid AI has a different playbook. They’ve consistently shipped compact, multimodal foundation models optimized for on-device performance. Their earlier 1.2B model and its contested efficiency claims sparked debates about whether speed claims hold up under scrutiny.

What a 100B Liquid Model Would Actually Mean

If Liquid AI does ship a 100B MoE, here’s what matters: not the parameter count, but the active parameter ratio. A 100B-A5B model would activate only 5B parameters per token, making it competitive with their existing LFM2.5-8B-A1B in terms of inference cost while offering significantly more capacity for knowledge storage.

The sweet spot for these models is the 100B-class range running on 128GB UMA devices, think Mac Studio, DGX Spark, RTX Pro 6000 rigs. Users currently point to DeepSeek-V4-Flash as the benchmark for this category, praising its ability to fit 1M context into 128GB with only 11GB KV cache. Liquid AI would need to match or beat that.

Community sentiment is cautiously optimistic. Many developers who’ve tested LFM2.5-2.6B report being surprised by its utility as a companion model alongside larger systems. The demonstration of Liquid AI’s 2.6B model running efficiently on mobile CPUs at 17 tok/s showed that speed-first isn’t just a talking point, it’s measurable progress.

The Real Question: Can Speed-First Scale?

Liquid AI has built its identity on models that run anywhere, phones, laptops, cars, embedded systems. Their LFM2.5 series spans from 230M to 8B parameters, all optimized for low latency and device-aware deployment. The official pitch: “frontier-grade intelligence at a fraction of the compute, on any hardware.”

A 100B model challenges that narrative in a fundamental way. You can’t fit a 100B MoE on a phone. Even on a Mac Studio, you’re looking at heavy quantization to make it work. So what’s the point?

The Strategic Answer

Positioning. Liquid AI needs to show they can compete at the frontier, even if their competitive advantage remains efficiency. A 100B model that runs at GPT-4-class speeds on consumer hardware would be a massive flex. It would prove that their architecture scaling rules don’t break down at larger sizes.

The Technical Answer

All-to-all communication and scheduling become nightmares at 100B scale. Training software for MoE at that size is a real engineering challenge. Liquid AI has a 93-person team on Hugging Face, including researchers like Jimmy T.H. Smith, Ramin Hasani, and Alexander Amini. They’re not short on talent.

What I’m Watching For

Three things will determine whether this 100B bet pays off:

First, the active parameter count. A 100B-A2B model would be genuinely revolutionary, frontier knowledge with tiny inference costs. A 100B-A30B model would be more traditional and less interesting.

Second, the hardware targets. If they optimize for consumer GPUs and unified memory systems, they’re playing a different game than OpenAI and Anthropic. If they’re building for cloud inference, they lose their edge.

Third, the quantization story. Their Q4_0 quantization-aware distillation work shows they care about edge deployment. A 100B model that runs at Q3 or Q4 on 128GB systems would fill a real gap between 30B-class models and cloud-only frontier systems.

The 100B model is coming eventually, that much seems clear. The question is whether Liquid AI can stay true to its speed-first philosophy at a scale that typically demands raw compute above all else.

The community’s response has been split. Some see the poll as a marketing ploy. Others welcome every 100B model into the fold, noting it’s virtually the perfect size for most premium consumer hardware setups. The truth is probably somewhere in between, a real technical bet that’s also designed to generate conversation.

One thing’s certain: if Liquid AI delivers a 100B model with DSpark-class inference speeds, the “bigger is better” crowd is going to have some uncomfortable questions to answer. And if they don’t deliver, they’ll face the same skepticism that’s greeted every efficiency-focused startup that dared to challenge the scaling laws.

Either way, the next few months are going to be very interesting for anyone who believes speed matters as much as scale.

Share:

Related Articles