Liquid 推出面向低延迟推理的 RIPL

Liquid AI 发布的 RIPL，想把生成模型放进搜索、风控和支付这类在线请求链路，在毫秒级预算内返回完整答案。它的吸引力不在于长篇生成，而在于让一些过去交给传统模型的短任务，多一个生成模型选项。

但「低于 50 ms」有明确边界：单张 B200 上，短输入、短输出的部分配置达标；请求变长后，p95 会升到数百毫秒。读这组数据，关键是分清引擎收益、模型差异，以及厂商自测的适用范围。

低于 50 ms，究竟测的是什么

RIPL 全称 Real-time Inference Pipeline，服务于 Liquid Foundation Models（LFMs）。它面向企业部署，支持 NVIDIA H100、H200、B200 和 RTX PRO 6000，覆盖参数量从 230M 到 2.6B 的 LFM2.5 模型。

它强调的是端到端延迟：从请求到达到完整响应生成结束。对于分类、查询改写、风险评分，这比「多久开始吐出第一个 token」更有意义，因为下游通常要等完整结果才能继续。

原文报告的是 p95，即约 95% 的请求在这个时间内完成。测试在单张 B200 上进行，采用开放环泊松到达：请求按设定速率持续进入，不会等上一条完成后才发送下一条。因此，它也在考察持续流量下的排队情况。

低于 50 ms 是特定工作负载的成绩，不能当成所有请求的延迟承诺。

最大 28.4 倍差距，不能全部算给引擎

Liquid AI 给出的主要对比如下。输入、输出长度均以 token 计，LFM2.5 使用 RIPL，Qwen3.5 使用 vLLM。

模型对比	输入→输出	负载	LFM2.5 p95	Qwen3.5 p95	差距
1.2B 对 0.8B	32→32	1,000 req/s	34.6 ms	498 ms	14.4 倍
1.2B 对 0.8B	256→128	400 req/s	155.8 ms	4,431 ms	28.4 倍
2.6B 对 2B	32→32	1,000 req/s	76.4 ms	586.8 ms	7.7 倍
2.6B 对 2B	256→128	300 req/s	449.1 ms	2,499 ms	5.6 倍

差距确实大，但这里同时换了模型和服务引擎。更接近引擎对照的是另一组测试：同一个 LFM2.5-350M 分别跑在 RIPL 和 vLLM 上，多个负载中 RIPL 的 p95 都更低。不过，原文没有给出这部分的具体数值。

模型结构也不同。LFM2.5-1.2B-Instruct 共 16 层，包括 10 个双门控卷积块和 6 个 GQA 块；LFM2.5-2.6B 共 30 层，包括 22 个卷积块和 8 个 GQA 块。GQA 是分组查询注意力，二者都采用卷积与注意力混合结构。

比较对象的能力也不完全一致：LFM 两款是文本模型，Qwen 两款支持文本、图像和视频；默认模式分别涉及 Instruct、Always reasons 和 Non-thinking。参数量也不是严格对齐，实际为 1.17B 对 0.8B、2.69B 对 2B。测试基线还包括 MiniCPM5 和 Granite 4.2，但原文没有列出它们的完整成绩。

因此，这些数字支持「这套模型与引擎组合在指定负载下更快」，还不足以单独证明 RIPL 普遍比 vLLM 快多少。

它更适合短决策，而不是长回答

Liquid AI 列出的六类任务，能帮助理解产品边界：

任务	输入→输出	延迟预算
广告查询改写	32→32	50 ms
搜索意图分类	128→1	20 ms
搜索重排	1k→1	30 ms
支付风险评分	512→16	50 ms
信贷决策	8k→64	150 ms
图片替代文本	512×512 图片及 64 token→16	100 ms

其中，查询改写使用 LFM2.5-350M，支付风险评分使用 LFM2.5-1.2B，图片任务使用 LFM2.5-VL-450M。表里的数字是任务预算，不能直接当成每项任务已经测得的延迟。

这些任务的共同点是输出短、结果直接参与下一步决策。它们与聊天窗口里生成几百字回答的需求不同。

生产案例来自 Shopify。据 Liquid AI 披露，Shopify 正在延迟敏感的商业场景部署 LFMs，生产搜索流量中的推理低于 20 ms；相较替代方案，参数量约少 50%，推理快 2 到 10 倍。但原文没有明确替代方案、结果质量，以及该延迟是否包含完整业务链路，不能直接与前面的端到端 p95 等同。

我的判断

我认同它把注意力放在完整响应和持续流量上。同步请求链路真正关心的是结果什么时候可用，平均速度很容易掩盖尾部排队。

但「用生成模型替换梯度提升树，还能保住延迟预算」目前更像产品主张。原文没有给出与梯度提升树的准确率、成本和稳定性对照，也没有说明输出异常如何处理。对风控、支付这类任务，速度只是准入条件之一。

选型还要看能力和部署条件。两款 LFM 的上下文长度分别是 32,768、131,072，Qwen 两款均为 262,144；LFM 权重采用 LFM Open License v1.0，Qwen 权重采用 Apache 2.0。RIPL 则是企业专用的闭源引擎，不能按开源 vLLM 的获取方式预期。

全部性能数字均由 Liquid AI 自报，原文没有独立复现或同等效果下的成本对照。

能拿来做什么

• 如果 Node 服务要同步调用模型做查询改写或意图分类，可以先固定输入上限、输出长度和延迟预算，再判断这类小模型方案是否值得评估。
• 压测时保留持续到达的请求，测完整响应的 p95，并检查超时和排队情况，避免只凭单次请求或首 token 速度做决定。
• 对已有分类器或梯度提升树的任务，把结果质量、推理成本和异常输出处理一起纳入比较。只有速度数据，还不足以支持替换。
• 如果团队在评估 RIPL，要求查看相同模型在 RIPL 与 vLLM 上的具体配置和成绩，再用自己的请求长度与流量复测。