Evidence at a glance
The Real-Time Hurdle Is Returning on Time
On October 22, 2026, Liquid AI announced RIPL, short for Real-time Inference Pipeline, an inference engine for Liquid Foundation Models, or LFMs. It is aimed at online requests in areas such as search, recommendation, and payment risk scoring. The stated goal is to return a complete response quickly after a request arrives, rather than optimize the speed of only one stage of generation. Liquid AI says RIPL is available for enterprise GPU deployments and serves LFM2.5 models ranging from about 230 million to 2.6 billion parameters.
The announcement addresses a practical trade-off. Latency-sensitive services often use gradient-boosted trees or other conventional models, while general-purpose generative model serving is more commonly suited to tasks that can tolerate longer waits. RIPL is trying to change whether teams can put generation into an online path without relaxing its response-time budget. That is a useful goal to examine, but “under 50 milliseconds” cannot be understood independently of input length, output length, and model size.
End-to-End Optimization Is the Claim; the Internals Remain Unclear
Liquid AI describes RIPL as optimizing the end-to-end path from request arrival to completed response, including under continuously arriving traffic. For an online system, that measure is closer to the user experience than tokens per second alone, because queuing and request handling can affect total response time. However, the public material does not explain RIPL's scheduling, batching, caching, or kernel implementation. It is not possible to infer which particular technique accounts for the reported speedups.
The serving engine is not the only possible source of performance. LFM2.5 models use hybrid architectures. The LFM2.5-1.2B has 16 layers, including 10 double-gated convolution blocks and 6 GQA blocks. The 2.6B model has 30 layers, with 22 convolution blocks and 8 GQA blocks. MarkTechPost also reports that Liquid AI showed the same LFM2.5-350M running on RIPL and vLLM, an attempt to separate some engine effects from model differences. The report does not provide the numerical results of that comparison.
The Benchmarks Show an Advantage, Not an Engine-Only Contest
The main published comparison measures end-to-end p95 latency on a single NVIDIA B200 under open-loop Poisson arrivals. The LFM models run on RIPL, while the comparison models run on vLLM. For a short request, the 1.2B LFM processes 32 input tokens and generates 32 output tokens at 1,000 requests per second with a p95 of 34.6 milliseconds. The corresponding result for Qwen3.5-0.8B is 498 milliseconds, a gap of about 14.4 times. This is a specific case that comes in below 50 milliseconds, not a promise that applies to every request.
Longer requests produce different latency and a different budget picture. With 256 input tokens, 128 output tokens, and 400 requests per second, the 1.2B LFM reaches a p95 of 155.8 milliseconds, compared with 4,431 milliseconds for the baseline, a gap of about 28.4 times. The larger 2.6B model records 76.4 milliseconds for 32 input and 32 output tokens at 1,000 requests per second, versus 586.8 milliseconds for its baseline. At 256 input and 128 output tokens, with 300 requests per second, the figures are 449.1 and 2,499 milliseconds. Those gaps are about 7.7 and 5.6 times, respectively, and show again that low latency on short inputs does not guarantee a 50-millisecond response for longer requests.
Workload Budgets Must Be Read Alongside Request Shape
Liquid AI lists six real-time workloads with budgets ranging from 20 to 150 milliseconds. Its examples include search intent classification with 128 input tokens, one output token, and a 20-millisecond budget; search reranking with about 1,000 input tokens, one output token, and a 30-millisecond budget; and payment risk scoring with 512 input tokens, 16 output tokens, and a 50-millisecond budget. Credit decisioning is listed at 8K input tokens, 64 output tokens, and 150 milliseconds. Image alt text involves a 512-by-512 image and text input, with a 100-millisecond budget. These examples make “real time” more concrete by tying it to request shape, but they are vendor-provided workload mappings, not independent validation of every use case.
The stated deployment hardware includes NVIDIA H100, H200, B200, and RTX PRO 6000 GPUs. The disclosed benchmark results, however, were measured on a single B200, so the same numbers should not be assumed for other GPUs. Liquid AI has also said that Shopify runs LFM inference below 20 milliseconds on production search-enhancement traffic. That partnership was mentioned in 2025, and the available material does not show that it uses RIPL. LFM weights use the LFM Open License, but that does not make the serving engine open: RIPL is a closed engine for enterprise deployments, and its pricing has not been disclosed.
Treat It as a Candidate Serving Stack, Not a Universal SLA
The reported gaps of 14.4 to 28.4 times change both the model and the inference engine, so the full difference cannot be attributed to RIPL. Model architecture, parameter count, and serving software can all affect latency. Liquid AI has mentioned a same-model comparison across engines, but has not published figures that outside teams can inspect. The main results are vendor-reported, with no independent replication in the available material and no same-conditions comparison against SGLang or TensorRT-LLM. For a technical lead, the figures justify further testing, but not an immediate production-stack replacement.
A more defensible evaluation starts with a narrow task whose request shape and latency budget are clear, then runs shadow traffic using real input lengths, arrival rates, and a target p95. If the question is how much the RIPL engine itself contributes, hold the model, hardware, input and output shapes, and load constant while changing only the serving engine. Measure output quality and resource cost alongside latency. If the question is whether a generative model can replace a conventional one, include quality, failure modes, and business outcomes in the comparison. The actionable conclusion today is that RIPL offers another candidate path for serving selected LFMs in real time. Fifty milliseconds remains a target to pursue for particular workloads, not a condition-free product guarantee.