Liquid AI发布RIPL推理引擎：LFM延迟降至50毫秒内

Liquid AI 推出 RIPL，一款面向 LFM 系列模型的实时推理引擎。官方数据显示，在单张 B200 上，LFM2.5-1.2B 在 RIPL 上的 p95 延迟比 Qwen3.5-0.8B 在 vLLM 上低 14.4 至 28.4 倍。这个倍数差距指向一个被长期忽视的问题：通用推理框架的效率天花板，可能正在成为小模型落地的真正瓶颈。

Liquid AI发布RIPL推理引擎

RIPL 解决了什么问题

大模型推理优化近两年的主线是吞吐量——如何在单卡上塞进更多请求、把每 token 成本压到最低。vLLM 的 PagedAttention、连续批处理等技术正是围绕这一目标演化而来。但实时交互场景的需求方向不同：用户等待首字的时间、语音对话的响应间隔、Agent 工具调用的往返延迟，衡量的都是 p95 甚至 p99 尾部延迟，而非平均吞吐。

Liquid AI 选择在这个方向上做专用引擎，逻辑是自洽的。LFM 系列本身就是为边缘和端侧设计的小参数模型，1.2B 的体量决定了它不可能靠堆算力取胜，只能靠推理路径的极致压缩。RIPL 的命名暗示了「实时推理管线」的定位，与通用框架「先通用、再优化」的路线形成对照。

p95 延迟与尾部延迟：在性能测试中，p95 延迟指 95% 的请求所达到的延迟上限，即只有 5% 的请求比它更慢。相比平均延迟，p95/p99 更能反映用户体验的稳定性——实时交互中，用户对偶尔的卡顿极其敏感，尾部延迟直接决定产品是否“跟手”。这也是 RIPL 与 vLLM 优化目标分道扬镳的根本原因：vLLM 追求吞吐量最大化，而实时场景必须优先压缩长尾。

KV Cache 管理：KV Cache 是自回归生成时缓存历史 Key/Value 张量的机制，避免每步重复计算。其内存布局和调度策略对延迟影响巨大：通用框架为支持动态批处理常采用分页式管理（如 PagedAttention），而低延迟引擎可能选择更紧凑的预分配或原地更新策略，以减少内存碎片和调度开销。这解释了为何专用引擎能在小模型上取得倍数优势。

14 倍差距从哪里来

需要先看清对比的构造：双方模型规模不同（1.2B vs 0.8B），框架不同（RIPL vs vLLM），硬件相同（单张 B200）。这意味着 14.4–28.4 倍的 p95 延迟优势不能简单归因于引擎本身——模型架构、量化策略、KV Cache 管理方式都可能贡献了差异。

但即便如此，这个量级仍然值得重视。在 50 毫秒以内的延迟区间，每降低 10 毫秒都对应着不同的产品形态：语音助手能否做到自然打断、实时翻译能否跟上说话节奏、端侧 Agent 能否在用户察觉之前完成工具调用。通用框架在这类场景下往往需要牺牲批处理效率来换取延迟，而专用引擎可以从头为单请求低延迟设计调度策略。

一个合理的推测是，RIPL 在批大小、算子融合和内存布局上做了针对 LFM 结构的裁剪。小模型的计算密度低，通用框架的调度开销占比会被放大，这是专用引擎容易取得倍数优势的地方。

算子融合与批大小裁剪：算子融合指将多个细粒度计算（如矩阵乘、激活、归一化）合并为单一内核，减少内核启动与显存读写开销。小模型计算密度低，单个算子耗时短，调度开销占比被放大，融合收益反而更显著。同时，实时引擎通常将批大小压到 1 或极小值，避免排队延迟，但需重新设计内存布局以维持利用率——这正是专用引擎针对 LFM 结构裁剪的切入点。

小模型推理的框架分化

这则发布透露出一个更宏观的信号：推理框架正在从「一个 vLLM 打天下」走向按场景分化。云端高吞吐、端侧低延迟、实时交互、离线批处理，各自的技术约束差异太大，通用框架的抽象层反而成为负担。

Liquid AI 的路径与 Groq 的 LPU、Cerebras 的 wafer-scale 思路有相似之处——都是通过软硬协同把特定负载推到极限。区别在于 RIPL 是纯软件引擎，可以跑在现有 GPU 上，部署门槛低得多。对于想在 B200 或类似硬件上跑实时小模型的团队，这提供了一个 vLLM 之外的可选项。

当然，专用引擎的代价是生态锁定。RIPL 目前只服务 LFM 系列，模型选择范围远小于 vLLM 支持的开放模型库。是否值得为延迟优势接受这种绑定，取决于具体产品对响应时间的敏感程度。

软硬协同与纯软件引擎：Groq 的 LPU 和 Cerebras 的 wafer-scale 引擎均属软硬一体方案，通过定制芯片把特定负载推到极限，但部署门槛高、灵活性差。RIPL 则是纯软件引擎，可运行于现有 GPU，以算法和调度优化换取低延迟，代价是只适配 LFM 系列。这种分层意味着推理优化正从“唯硬件论”转向“场景定义软件”，团队可根据延迟敏感度和硬件条件选择不同路径。

谁应该关注

实时语音交互、端侧 Agent、需要严格 SLA 的在线服务，是 RIPL 最直接的目标场景。如果产品对 p95 延迟的要求在 100 毫秒以内，通用框架的调优空间往往已经见底，专用引擎的倍数优势才有实际意义。反之，如果业务以吞吐和成本为核心指标，vLLM 生态的成熟度和模型覆盖面仍然是更稳妥的选择。

Liquid AI 用一组对比数字把「专用推理引擎」这个品类重新推到台前。接下来值得观察的是：RIPL 是否会开放对其他模型的支持，以及 vLLM 等通用框架是否会跟进针对尾部延迟的专项优化。