Liquid AI designed the LFM2.5 family to run locally on constrained edge devices, with fast, memory-efficient inference for embedded and on-device workloads. Liquid has also made broad hardware and inference-framework support a core part of the rollout.

NXP's i.MX 95 Applications Processor is one of those edge platforms, pairing a CPU with a dedicated eIQ® Neutron Neural Processing Unit (NPU) for on-device AI workloads. Although Liquid AI models could already run on the i.MX 95 SoC's CPU, there was no way to compile them onto its eIQ Neutron NPU.

Roofline enabled Liquid AI's models through its existing MLIR- and IREE-based compiler infrastructure for the i.MX 95 SoC. Because the eIQ Neutron NPU backend was already in place, Roofline could focus on supporting the new model architecture rather than rebuilding the hardware integration.

That existing compiler infrastructure enabled Roofline to get LFM2.5-230M running on the i.MX 95 SoC on the same day Liquid AI released it. LLM, VLM, and Mixture-of-Experts models from Liquid AI have since been validated on the platform, using heterogeneous execution across the CPU and NPU.

Key takeaways

• Day-0 model support: Roofline enabled LFM2.5-230M on the i.MX 95 SoC on the day Liquid AI released it, showing how existing compiler infrastructure can bring newly released models onto supported edge hardware without a fresh integration cycle.

• Validated in edge applications: The enablement was demonstrated in industrial and consumer-electronics scenarios running on the i.MX 95 SoC.

• MoE execution is functional today: Roofline successfully ran Liquid AI's LFM2-8B-A1B on the i.MX 95 SoC, establishing functional MoE support on the platform.

LFM2.5 needed a compiler path onto the eIQ Neutron NPU

Liquid AI designed LFM2.5 to push more capability into small models, so that constrained edge devices can run more sophisticated AI workloads without the memory and compute budget of a larger model. For the LFM2.5 release, Liquid extended pretraining from 10 trillion to 28 trillion tokens and significantly expanded its post-training pipeline with reinforcement learning. However, LFM2.5's model quality only reaches users if there's a deployment path onto the target hardware.

On the i.MX 95 SoC, the compiler stack has to map the model's operations onto the available compute resources, sending supported work to the eIQ Neutron NPU while compiling the remaining operations for the CPU.

LFM2.5's hybrid architecture also introduced new compiler requirements. The model interleaves convolution layers with transformer attention layers, which required Roofline to adapt its existing inference path to support the architecture. Without a compiler path onto the eIQ Neutron NPU, Liquid AI models on the i.MX 95 SoC would remain limited to CPU execution and could not use the SoC's dedicated AI accelerator.

llama.cpp, ExecuTorch, and similar deployment solutions rely on manually written kernels for each hardware target. That's why they're currently largely limited to CPU execution on hardware like the i.MX 95 SoC, and why adding that support would take several months of kernel-level engineering. In comparison, Roofline's compiler-based path required no NPU-specific development for LFM2.5.

Moving suitable AI workloads onto the eIQ Neutron NPU reduces CPU workload and lowers latency, freeing CPU resources for other workloads in an agentic application.

“At Liquid AI, we build efficient models. Edge hardware has limited memory and compute, so we pack as much capability as we can into a small footprint and rely on every bit of performance the silicon can give. On the i.MX 95 SoC, that means LFM2.5 runs across the CPU and Neutron NPU together, so our models run faster and leave headroom for the rest of the application, ready on NXP hardware from day one.”

- Felipe Benavides, Head of Partnerships, Liquid AI

Deployment of Liquid AI’s latest models builds on Roofline’s existing Neutron and MoE infrastructure

Roofline ran all three model categories in this release (LLM, VLM, and MoE) on the i.MX 95 SoC by building on infrastructure it had already put in place, without needing a new hardware integration project for each one.

• Roofline had already built heterogeneous CPU + eIQ Neutron NPU execution for LLMs on the i.MX 95 SoC. Once LFM2.5 could be compiled through the same infrastructure, its matrix multiplications used the existing eIQ Neutron NPU offload path without further NPU-backend development.

• The MoE work builds on Roofline's earlier compiler work on dynamic expert routing in IREE, demonstrated across models including LFM2-8B-A1B. That work identified NXP NPUs as a future hardware target; the i.MX 95 SoC validation extends that compiler path onto NXP hardware.

The model-specific work instead centred on accommodating LFM2.5's hybrid architecture, including its interleaved convolution and attention layers, and the resulting changes to Roofline's KV-cache implementation. That was an application-layer change to Roofline's inference stack; the compiler and NPU support required no further changes once the model could be compiled.

The work covers three model categories:

• LLM: LFM2.5-350M and LFM2.5-230M, compact text-generation models designed for efficient on-device inference.

• VLM: LFM2.5-VL-450M, a vision-language model for multimodal workloads.

• MoE: LFM2-8B-A1B, with 8.3B total parameters and 1.5B active parameters per token.

Roofline successfully ran LFM2-8B-A1B on the i.MX 95 SoC as a functional validation of MoE execution on the platform. For hardware teams, the result is a compiler stack that absorbs new model architectures without repeating NPU integration work for each one.

LFM2.5's hybrid architecture required a KV-cache change

One of the more specific engineering challenges came from LFM2.5's architecture.

Unlike the LLMs Roofline had previously enabled, LFM2.5 interleaves convolution layers with its attention layers. This hybrid architecture affected Roofline's implementation of the KV cache, an optimization used during autoregressive generation to avoid repeatedly recomputing attention state from earlier tokens.

Roofline updated its KV-cache implementation to account for the convolutional layers while bringing LFM2.5 onto the Neutron execution path.

“LFM2.5 has convolution layers interleaved with the attention layers you normally see in LLMs, which is one of the things that makes the architecture fast. Enabling it required a small extension to our LLM integration layer.”

- Juan Pisula, Edge AI Engineer, Roofline

One agentic blueprint, two application areas

Liquid positions LFM2.5 for on-device deployment across application areas like industrial and consumer electronics, where fast, private, on-device inference matters most.

The i.MX 95 SoC enablement was demonstrated in two applications that combined two Liquid AI models with different modalities: a vision-language model and a language model working together, compiled once and reused for two different jobs. The VLM interprets visual input locally and passes it to the LLM, which turns that input into an actionable response through fast on-device processing. The two applications below reuse that same blueprint for different use cases.

Industrial safety demo: swapping the LLM for a faster Liquid model

In the industrial safety demo, a vision-language model analyses a CCTV camera frame showing a factory incident, such as a fire. The VLM describes the scene, and that output is passed to an LLM that generates code or commands to trigger an appropriate response, such as activating sprinklers and sounding an alarm.

This demo makes the case for flexible model deployment at the edge: swapping Qwen3-0.6B for Liquid AI’s LFM2.5-230M reduced time-to-first-token from approximately 2.05 seconds to 0.90 seconds and increased decode throughput from 4.73 to 27.61 tokens per second, while keeping the same LFM2.5-VL-450M vision model and application pipeline.

Consumer electronics demo: Reusing the same setup for a different application

The home-appliance demo shows a smart washing machine running a full multimodal workflow on the i.MX 95 SoC. LFM2.5-VL-450M provides visual intelligence, while LFM2.5-230M acts as the orchestration agent controlling the machine. Both models are fully compiled and execute across the CPU and eIQ Neutron NPU.

This application used the same compiled blueprint moved directly into a new embedded, agentic application in a compute- and memory-constrained environment where local inference is valuable for responsive device control.

LFM2.5's small models hit responsive on-device decode speeds

Inference speed and memory efficiency are central to Liquid AI's positioning for LFM2.5. Liquid benchmarked the family on prefill speed, decode speed, and memory use, presenting those characteristics as key to local and embedded deployment.

The results below test that same deployment premise on NXP's i.MX 95 SoC, comparing heterogeneous execution across six CPU cores and the eIQ Neutron NPU, evaluated at 128 prefill tokens and 128 decode tokens.

* LFM2.5-VL-450M was evaluated with an additional 24 image tokens at 128×192 resolution.

At 19.6–28.0 tokens per second, LFM2.5-350M and LFM2.5-230M decode well above the threshold researchers consider sufficient for real-time reading. A 2025 NeurIPS study on inference energy measurement puts the point at which output keeps pace with most reading and listening speeds at roughly 10 tokens per second, and LFM2.5-350M and LFM2.5-230M clear that by around 2x and 3x, respectively.

For developers evaluating small models for the i.MX 95 SoC, the results show that the efficiency Liquid designed into LFM2.5 translates into decode speeds fast enough for responsive, on-device applications when deployed across the CPU and eIQ Neutron NPU.

From model release to edge deployment

The significance of this work is broader than support for another model family. Liquid AI is building LFM2.5 around broad on-device availability, which depends on reaching the accelerators already deployed across edge platforms without a fresh integration project for every model and hardware combination.

On the i.MX 95 SoC, Roofline provided that path through its existing compiler infrastructure. For developers working with Liquid AI models, that opens access to NXP’s safe, secure, and power-efficient edge platform across industrial, automotive, commercial IoT, medical, and network applications. Liquid AI models can now use the eIQ Neutron NPU across LLM, VLM, and MoE architectures without a new hardware-specific integration for each model.

For developers building on the i.MX 95, that provides:

• Broader model coverage: Liquid AI's LLM, VLM, and MoE models can be brought onto NXP's edge platform through Roofline's compiler stack.

• A practical small-model option: LFM2.5-230M and LFM2.5-350M decode well above the threshold researchers consider sufficient for real-time reading, so small doesn't come at the cost of responsiveness.

• A reusable compiler foundation: Roofline can extend the same Neutron backend as new model architectures introduce additional compiler requirements.

This mirrors Liquid AI's own deployment strategy, which emphasizes support across multiple inference frameworks and accelerator targets, including CPUs, GPUs, and NPUs. For developers building with Liquid AI models, that expands the hardware they can target without waiting for model-specific support on each platform.

For chip vendors and device builders like NXP, it means a newly released model can run well on their hardware from day one, which is a real factor in whether developers pick that SoC over a competitor's when building new disruptive AI products.

Next steps

Roofline is now optimizing its sparse MoE path to move from functional enablement toward stronger performance on edge hardware. The current LFM2-8B-A1B implementation established that the model can run end to end on the i.MX 95. The next phase is to make that path more efficient, creating a stronger foundation for MoE performance on the platform.

Roofline is also extending this enablement to NXP's Ara240 Discrete Neural Processing Unit (DNPU) over the coming months. The Ara240 targets real-time generative AI, LLM, and VLM execution on AI-enabled compute and embedded systems, giving developers a high-performance, lower-latency hardware option for more demanding workloads than i.MX 95 SoC's eIQ Neutron NPU currently supports.

As Liquid AI expands the LFM family, Roofline is positioned to extend support across new models without repeating the hardware integration work from scratch.