Liquid AI launches RIPL to serve small language models in under 50 ms

What Liquid AI announced

On 22 October 2026 Liquid AI announced Liquid RIPL, short for Real-time Inference Pipeline. It is a serving engine for the company's own Liquid Foundation Models, or LFMs, designed to sit directly inside a live request, such as a search query or a card payment, rather than in a background job.

Liquid's central claim is that RIPL returns complete generated responses end to end in under 50 milliseconds, and keeps doing so while traffic arrives continuously at peak load. That is a very different target from most large language model serving, where a response that takes a few seconds is considered fine.

RIPL is not open source and is not a public API. Liquid says it is available today for enterprise deployments of LFMs on NVIDIA GPUs, and invites companies with a hard latency budget to contact its sales team. The launch post also links an interactive latency calculator.

The problem RIPL is meant to solve

Search ranking, product recommendations, fraud checks and payment authorizations all have to answer in milliseconds. Even small delays show up as friction, such as a slower checkout that loses sales. Liquid argues that this is why those systems still lean on fast but less capable methods such as gradient-boosted trees or small embedding models, and why generative models have mostly stayed out of the hot path.

Serving stacks such as vLLM are tuned for throughput: large batches, long contexts and agent workflows. That design is efficient for chat and coding agents, but tail latency, the slowest few percent of requests, can balloon under steady load. RIPL is pitched as an engine that optimizes the whole path from request arrival to finished answer for a small model, instead of maximizing tokens per second.

The approach fits Liquid's broader strategy of small, efficient models. AI Lookout has covered the company's LFM2.5 24B-A2B on-device agent model and its D1 Ultra decision model, both aimed at running fast on modest hardware.

Which models and GPUs it supports

According to Liquid's launch materials as summarized by MarkTechPost, RIPL serves LFM2.5 models from 230 million to 2.6 billion parameters, plus the LFM2.5-VL-450M vision model in one of the sample workloads. Supported enterprise hardware includes NVIDIA H100, H200, B200 and RTX PRO 6000 GPUs. Liquid's benchmark runs used a single B200.

The LFM2.5 models are hybrids rather than pure transformers. LFM2.5-1.2B-Instruct has 16 layers, 10 of them double-gated convolution blocks and 6 grouped-query attention blocks. LFM2.5-2.6B has 30 layers, 22 convolution blocks and 8 attention blocks. Fewer attention layers mean less memory traffic per token, which helps at small batch sizes where latency matters most.

The weights for these models are published under Liquid's own LFM Open License v1.0, not Apache 2.0. The engine that makes them fast in production is the paid enterprise piece.

Liquid's latency numbers

Liquid measured p95 end-to-end latency, the time within which 95% of requests finish, under open-loop Poisson arrivals. That means requests keep arriving at a set average rate whether or not earlier ones have finished, which is closer to real traffic than sending one request at a time.

The company's blog says LFM2.5-1.2B on RIPL showed 14.4 to 28.4 times lower p95 latency than Qwen3.5-0.8B on vLLM across two workloads, and LFM2.5-2.6B showed 5.6 to 7.7 times lower latency than Qwen3.5-2B. The underlying chart values, as transcribed by MarkTechPost, are 34.6 ms against 498 ms for short 32-token requests at 1,000 requests per second, and 155.8 ms against 4,431 ms for 256-in, 128-out requests at 400 requests per second.

For the 2B class the reported figures are 76.4 ms against 586.8 ms at 1,000 requests per second for short requests, and 449.1 ms against 2,499 ms at 300 requests per second for longer ones. In other words, the sub-50 ms headline holds for short requests on the smaller models, not for every request shape.

Liquid also plots the same model, LFM2.5-350M, on vLLM and on RIPL. RIPL's p95 line sits below vLLM's in each workload shown, which suggests part of the gain comes from the engine and not only from the model architecture.

Six workloads with fixed budgets

To make the pitch concrete, Liquid maps six real-time tasks to fixed latency budgets. Ad-tech query rewriting with 32 tokens in and 32 out gets 50 ms on LFM2.5-350M. Search intent classification gets 20 ms for 128 tokens in and one out, and search reranking gets 30 ms for 1,000 tokens in and one out.

Payments risk scoring, with 512 tokens in and 16 out, gets 50 ms on LFM2.5-1.2B. Credit decisioning, with 8,000 tokens in and 64 out, gets 150 ms. Image alt text, from a 512 by 512 image plus 64 tokens to 16 tokens out, gets 100 ms on LFM2.5-VL-450M.

Several of those tasks produce one token, effectively a label or a score. That is where a small generative model can replace a classical classifier while keeping the same latency budget, and it is the main use case Liquid is selling.

Shopify and production use

Liquid names one production customer. It says Shopify is deploying LFMs across latency-sensitive commerce workloads, with sub-20 ms inference on real production traffic for search enhancement. Liquid adds that LFMs with about 50% fewer parameters outperform alternatives there while delivering 2 to 10 times faster inference.

The blog's wording links Shopify to LFMs in general and says they work well "especially when paired" with engines like RIPL. It does not clearly say Shopify's search traffic runs on RIPL itself. Shopify has been building commerce infrastructure for AI agents, including the Shop MCP catalog and checkout tools, so fast small models in its search path fit that direction.

For teams running open serving stacks, the comparison point is projects such as llm-d 1.0 with priority queues, which add scheduling controls on top of vLLM rather than replacing it.

What the numbers do not show

Every number in the launch is Liquid's own. We did not run RIPL, which is not publicly available, and we did not reproduce the vLLM baselines. Baseline settings matter a lot for tail latency: batch limits, scheduler options and quantization can change vLLM's p95 substantially, and the public post does not list all of them.

The comparison also mixes engine and model. Qwen3.5 models are multimodal and support far longer contexts than the LFM2.5 checkpoints, and the 2.6B LFM is described as always reasoning. Comparing different models on different engines tells buyers what the full stack can do, but not which part deserves the credit.

Quality is the other gap. Latency charts show how fast an answer comes back, not whether it is as good as the classifier or ranker it would replace. Liquid points to the Shopify deployment for that, but it has not published task-quality numbers for RIPL workloads.

What to watch next

Watch for independent benchmarks against tuned vLLM, SGLang or TensorRT-LLM setups, for pricing and deployment terms, and for more named customers in payments, ads or search. Also watch whether Liquid extends RIPL to its larger models or to non-NVIDIA hardware, and whether Shopify says publicly which engine serves its LFM traffic.