Liquid AI has announced RIPL, a new inference pipeline that delivers complete responses from its Foundation Models in under 50 milliseconds. The system maintains this speed even when handling continuous traffic at peak capacity. For developers, the instruction is straightforward: replace traditional gradient-boosted trees with generative models without exceeding existing latency budgets.
Technical specifications
- Engine: Serves LFM2.5 models ranging from 230M to 2.6B parameters.
- Hardware: Runs on enterprise deployments using NVIDIA H100, H200, B200, and RTX PRO 6000 GPUs. Benchmarks were conducted on a single B200 unit.
- Performance: Liquid AI reports p95 latency improvements of between 5.6 and 28.4 times compared to Qwen3.5 running on vLLM.
- Best result: The LFM2.5-1.2B model achieved 155.8 ms p95 latency against 4,431 ms for Qwen3.5-0.8B, a 28.4x gap using a 256 token input and 128 token output configuration.
- Worst result: The LFM2.5-2.6B model showed only a 5.6x improvement (449.1 ms vs 2,499 ms). Achieving sub-50 ms response times is not possible with longer requests.
The problem
Most serving stacks are designed for large batches and long-running agent tasks where a few seconds per request is acceptable. Search ranking, fraud detection, and payment authorisation require answers in milliseconds. Liquid AI states that teams often default to classical models for these tasks because LLM serving is too slow. RIPL is built to remove that trade-off.
How the engine works
Liquid AI describes RIPL as an optimisation of the full path from request arrival to completed response. In several workloads, the company plotted the same model, LFM2.5-350M, on both vLLM and RIPL. RIPL’s p95 line sits well below the vLLM line in each case. That isolates part of the gain to the engine, not just the model architecture.
The LFM2.5 models themselves are hybrids. LFM2.5-1.2B-Instruct has 16 layers: 10 double-gated convolution blocks and 6 GQA blocks. LFM2.5-2.6B has 30 layers: 22 convolution blocks and 8 GQA blocks.
Latency benchmarks
Liquid measured p95 end-to-end latency under open-loop Poisson arrivals on one B200. LFMs ran on RIPL. Baselines, including MiniCPM5 and Granite 4.2, ran on vLLM.
| Workload | Load | LFM2.5 on RIPL (p95) | Qwen3.5 on vLLM (p95) | Gap |
|---|---|---|---|---|
| 1B class, 32 in → 32 out | 1,000 req/s | 34.6 ms (1.2B) | 498 ms (0.8B) | 14.4x |
| 1B class, 256 in → 128 out | 400 req/s | 155.8 ms (1.2B) | 4,431 ms (0.8B) | 28.4x |
| 2B class, 32 in → 32 out | 1,000 req/s | 76.4 ms (2.6B) | 586.8 ms (2B) | 7.7x |
| 2B class, 256 in → 128 out | 300 req/s | 449.1 ms (2.6B) | 2,499 ms (2B) | 5.6x |
Source: Liquid AI blog, Figure 2. Sealf-reported.
Liquid AI also mapped six real-time workloads against fixed budgets:
- Adtech query rewriting: 32 in, 32 out, 50 ms budget, LFM2.5-350M.
- Search intent classification: 128 in, 1 out, 20 ms budget.
- Search reranking: 1k in, 1 out, 30 ms budget.
- Payments risk scoring: 512 in, 16 out, 50 ms budget, LFM2.5-1.2B.
- Credit decisioning: 8k in, 64 out, 150 ms budget.
- Image alt text: 512×512 image and 64 tokens in, 16 out, 100 ms budget, LFM2.5-VL-450M.
Competitor comparison
| Feature | LFM2.5-1.2B on RIPL | Qwen3.5-0.8B on vLLM | LFM2.5-2.6B on RIPL | Qwen3.5-2B on vLLM |
|---|---|---|---|---|
| Parameters | 1.17B | 0.8B | 2.69B | 2B |
| Context | 32,768 | 262,144 | 131,072 | 262,144 |
| License (weights) | LFM Open License v1.0 | Apache 2.0 | LFM Open License v1.0 | Apache 2.0 |
| Modality | Text | Text, image, video | Text | Text, image, video |
| Default mode | Instruct | Non-thinking | Always reasons | Non-thinking |
| Serving engine | RIPL (enterprise) | vLLM (open source) | RIPL (enterprise) | vLLM (open source) |
| p95, 32→32 | 34.6 ms | 498 ms | 76.4 ms | 586.8 ms |
| p95, 256→128 | 155.8 ms | 4,431 ms | 449.1 ms | 2,499 ms |
Production use
Yes, according to Liquid AI. Shopify is deploying LFMs across latency-sensitive commerce workloads. In search enhancement, LFMs run with sub-20 ms inference on production traffic. According to Liquid AI’s blog, they use about 50% fewer parameters than alternatives and deliver 2 to 10x faster inference.
What it means
For teams building commerce or financial tools, the change is practical. You can now run generative models inside the tight loops of payment processing or ad serving without waiting for a separate classical model. The speed gain comes from the engine architecture and the model’s hybrid convolution blocks. This allows developers to keep the latency budget while switching to more flexible models.
