Ember-1 vs LFM2.5 2.6B Base: A Finished Behaviour Against a Raw Substrate

Neither Ember-1 nor LFM2.5 2.6B Base is a model you can pick up and use, and they are unusable for opposite reasons. Ember-1, published by Fireworks Research on 23 September 2026, is a specialized derivative of Moonshot AI's Kimi K3 that the lab retrained to reach K3's accuracy on roughly 40% fewer tokens — a finished behaviour, available only as a research preview on the vendor's own serverless platform, with no weights and no published price. LFM2.5 2.6B Base, published by Liquid AI on 4 August 2026, is a 2.69B-parameter pretrained checkpoint under the LFM Open License v1.0 that has not been instruction-tuned at all and will continue your text rather than answer your question — a raw substrate, downloadable today, deliberately unfinished. Reading them side by side is a good way to see the two arguments being made about where efficiency gains now come from.

The question both models are answering

Both releases assume the same premise: that the cheap wins from making a model bigger have largely been taken, and the interesting work has moved to how a model spends what it already has. The two labs answer that differently. Fireworks Research took an existing frontier model and changed its behaviour. Liquid AI built a small model from scratch and changed the scale. Neither is a new architecture story, and neither is trying to top a leaderboard.

Ember-1's answer: keep the model, retrain the behaviour

Ember-1 leaves Kimi K3's architecture alone and attacks one specific inefficiency. Reasoning models can burn more than 90% of their generated tokens on internal deliberation, and in a multi-turn agent loop those traces get replayed and re-billed on every subsequent turn — Fireworks Research describes the resulting context growth as roughly quadratic in the number of turns. The lab's claim is that K3's reasoning is longer than the task requires and that the excess can be removed without changing answers. It reports running more than 50 training experiments and over 200 evaluations on its own serverless training stack, and says reasoning length fell by 35–50% without accuracy loss across seven benchmarks and two customer production traffic sets. All of that is vendor-reported and unreproduced.

The results are uneven in a way the headline number hides. Ember-1's token reductions range from 51.9% on Terminal Bench 2.1 to 5.9% on τ-2 Bench Airline. In one customer's production coding A/B, output tokens fell from 49.3K to 29.9K while the score held at 0.753 against 0.751 — a 71.3% cut in reasoning tokens. That is a large effect on one workload shape and a nearly invisible one on another, which is what you would expect from a model trained to stop over-thinking rather than to think less.

LFM2.5 2.6B Base's answer: change the scale, keep the recipe

LFM2.5 2.6B Base is a different kind of bet. It is Liquid AI's hybrid architecture at small scale: 30 layers, of which 22 are dual-gated short-convolution blocks and 8 are grouped-query-attention layers, trained on roughly 34 trillion tokens across 16 languages, with a 131,072-token context window. The whole checkpoint is 2.69B dense parameters — small enough that the conversation about cost stops being about tokens and starts being about which single GPU you have spare.

What makes it unusual is what it deliberately does not do. There is no instruction tuning, which is the entire point of the "Base" suffix: hand it a question and it will continue text in the style of the question rather than answer it. Liquid AI's own model card recommends it for tasks requiring heavy fine-tuning. There is also no published evaluation of it, and that is not an oversight — evaluating a base checkpoint on instruction-following benchmarks would measure nothing, because the behaviour being measured has not been trained in yet.

The contrast, one line per dimension

• What it is — Ember-1: a retrained derivative of Kimi K3 with shortened reasoning. LFM2.5 2.6B Base: a from-scratch pretrained checkpoint with no instruction tuning.

• Parameters — Ember-1: undisclosed; inherited from Kimi K3. LFM2.5 2.6B Base: 2.69B dense.

• Weights — Ember-1: none published. LFM2.5 2.6B Base: available under the LFM Open License v1.0.

• Price — Ember-1: none published; benchmark dollars use Kimi K3's rate card. LFM2.5 2.6B Base: free to download; you supply the hardware.

• Context — Ember-1: not published for the preview. LFM2.5 2.6B Base: 131,072 tokens.

• Published evaluation — Ember-1: seven benchmarks and two A/B tests, all vendor-run. LFM2.5 2.6B Base: none, by design.

• What you get at the end — Ember-1: an endpoint that produces shorter reasoning at K3-level accuracy. LFM2.5 2.6B Base: a starting point whose behaviour is whatever you train into it.

Two different kinds of missing

The gaps in these two releases look symmetrical and are not. LFM2.5 2.6B Base's missing evaluation is a property of the artifact: a base checkpoint has no behaviour to score, and the missing instruction tuning is a documented feature rather than a shortfall. The absence does not create commercial uncertainty, because what you are buying is a file with a license attached, and the deliverable is complete the moment the download finishes.

Ember-1's missing pieces are genuinely unresolved. There is no published price, so the cost claim is arithmetic on Kimi K3's rate card rather than a rate you can budget against. There is no weight release, so the model cannot outlive the vendor's decision to keep serving it. And the access window is described as temporary: Fireworks Research frames its research releases as two-week serverless windows whose permanence depends on community demand. A preview that may not exist next month is a different proposition from a preview that is merely unproven, and the second customer A/B in the announcement — roughly 35% fewer tokens per task — tells you what the lab expects, not what will still be reachable in November.

That asymmetry is the honest answer to "which of these is more ready." Neither is ready in the sense of being a drop-in production dependency. LFM2.5 2.6B Base is finished as a raw material and unfinished as a model. Ember-1 is finished as a model and unfinished as a service.

What to do with each this quarter

If you have a fine-tuning pipeline and a narrow task with clean labels, LFM2.5 2.6B Base is the more predictable of the two. The checkpoint is small, the license is permissive, the architecture is designed to be efficient at inference, and the work of turning it into something useful — supervised fine-tuning, an evaluation set, a serving stack — is work you already own end to end. You will be running your own evals either way, because Liquid AI did not publish any.

If you have a hosted agent workload whose bill is dominated by reasoning tokens, Ember-1 addresses a real term in your cost equation, and it is worth the two weeks. The right test is shadow traffic against your incumbent: send a share of real requests to both, compare outputs, leave live results alone. That is also the advice independent critical coverage of the release gave, alongside a fair warning — compressing deliberation risks losing a step the model needed, and in an agent that shows up later as a wrong tool call rather than a wrong sentence.

Neither model is on OrcaRouter. If you want to test the pattern rather than these two artifacts — a small fine-tunable model and a large hosted reasoner in one pipeline — that is exactly what the routing DSL is for: compose several models into a single call and let each handle the part it is good at, behind one key and one bill. The comparison here is worth making at the architecture level even while both specific endpoints remain out of reach.

The trade, stated once

Ember-1 sells certainty of behaviour and uncertainty of supply: a model whose quality is argued carefully and whose availability is explicitly conditional. LFM2.5 2.6B Base sells certainty of supply and uncertainty of behaviour: a file you will always have and whose competence is entirely a function of the training you put into it. Teams with a serving problem and no training capacity should watch the preview and hope it becomes permanent. Teams with training capacity and a narrow task should download the base and stop waiting for anyone's roadmap.

What the pairing really shows is that "efficiency" has stopped meaning one thing. For Ember-1 it means fewer tokens at the same quality on somebody else's hardware. For LFM2.5 2.6B Base it means a small enough model that the hardware stops being somebody else's at all. Those are both good answers and they are not interchangeable.