当行业注意力集中在更大参数、更强榜单时，Liquid AI 选择从推理链路本身要速度：为自家 LFM 系列模型配套一个专用推理引擎 RIPL。

发生了什么

Liquid AI 发布了 RIPL，定位是为 LFM 模型服务的实时推理引擎。官方给出的对比是：在单张 NVIDIA B200 上运行 LFM2.5-1.2B，其 p95 延迟比在 vLLM 上运行 Qwen3.5-0.8B 低 14.4 到 28.4 倍。标题中的「Sub-50 ms」即该引擎面向的延迟目标区间。

需要说明的是，这是一组厂商自测数据，对比对象并非同尺寸模型（1.2B 对 0.8B），推理框架也不同（RIPL 对 vLLM），因此不能直接读作「模型更强」。它真正说明的是：当模型架构与推理引擎被联合设计时，端到端延迟可以出现数量级的差距。

为什么重要

过去两年，推理优化的主流路径是通用引擎（vLLM、TensorRT-LLM、SGLang 等）加通用模型，双方各自演进、彼此适配。这条路降低了部署门槛，但也意味着引擎要为大量模型架构做妥协，模型设计也往往不考虑特定硬件的执行特征。

Liquid AI 走的是另一条路：LFM 本身基于其线性/状态空间混合架构，与 Transformer 的计算模式不同，而 RIPL 是围绕这套架构专门写的。软硬协同、模型与引擎同源，是它能拿到低 p95 延迟的结构性原因。p95 而非平均延迟尤其值得注意——它衡量的是尾部体验，直接对应实时交互中用户感知到的卡顿。

影响与看点

对开发者而言，这类引擎的价值在于把「实时」从营销词变成可工程化的指标。语音对话、实时字幕、端侧助手、游戏 NPC 等场景对首字延迟和尾部抖动极其敏感，几十毫秒的差距会直接改变产品形态是否成立。

对行业而言，值得关注三点：一是专用推理栈是否会成为小模型厂商的标配护城河，从而把竞争从参数规模转向「模型+引擎+硬件」的整体交付；二是第三方能否复现这组数字，尤其是不同 batch、不同上下文长度下的表现；三是 RIPL 是否只服务自家模型，若保持封闭，其生态天花板会明显受限。

一句判断：小模型的竞争正在从「跑分」转向「交付形态」，谁掌握推理栈，谁就掌握实时场景的入场券。