RIPL da Liquid AI: os 50 ms existem, mas a comparação com o vLLM mede outra coisa

A Liquid AI (abre em nova aba) anunciou em 22 de outubro o RIPL, sigla de Real-time Inference Pipeline. A promessa cabe numa linha: respostas geradas completas, de ponta a ponta, em menos de 50 ms, mantidas mesmo com tráfego contínuo em pico. A promessa se sustenta, mas só para requisições do tamanho de um telegrama. E a comparação de até 28,4 vezes contra o vLLM (abre em nova aba), que vai dominar as manchetes, mede algo diferente do que aparenta. Minha tese é que o RIPL é um produto sério para um nicho real, e que o número escolhido para vendê-lo diz mais sobre fila do que sobre motor.

O que foi medido, exatamente

Os números são da própria Liquid, publicados na Figura 2 do post de lançamento. A MarkTechPost os tabulou com a ressalva necessária: são autodeclarados. O cenário usou uma única B200, chegadas em regime aberto seguindo uma distribuição de Poisson e latência p95 de ponta a ponta. Os LFMs rodaram no RIPL. Os modelos de comparação, Qwen3.5 e também MiniCPM5 e Granite 4.2, rodaram no vLLM.

O método merece crédito. Benchmark em regime fechado, em que o cliente espera a resposta antes de mandar a próxima requisição, esconde a fila: o sistema nunca recebe mais do que consegue atender. Tráfego de busca ou de autorização de pagamento não espera ninguém terminar. Poisson aberto com p95, em vez de média, é a escolha de quem conhece o problema. A Liquid descreve esse problema no próprio post: a infraestrutura de serving atual foi feita para modelos genéricos, lotes grandes e fluxos agênticos longos, em que alguns segundos por requisição são aceitáveis. Em ranking de busca, recomendação e decisão de fraude, não são.

O sub-50 ms tem formato de telegrama

Das quatro linhas da tabela, uma fica abaixo de 50 ms: o LFM2.5-1.2B com 32 tokens de entrada e 32 de saída. No mesmo formato curto, o 2.6B marca 76,4 ms. Quando a requisição sobe para 256 → 128, o 1.2B vai a 155,8 ms, três vezes o número do título. A MarkTechPost diz isso sem rodeio: o sub-50 ms não se sustenta em requisições mais longas.

Trinta e dois tokens de saída dão algumas palavras. Bastam para uma consulta reescrita, um rótulo, uma decisão binária com justificativa curta, um score. Não bastam para um parágrafo de atendimento ao cliente. Isso não é defeito, porque a Liquid mira justamente busca, anúncios, fraude, recomendações e pagamentos. O desenvolvedor que lê "respostas completas em 50 ms" só precisa acrescentar mentalmente o adjetivo que falta: curtas.

Motor ou modelo: a pergunta que os números não respondem

A pergunta técnica que importa é quanto do ganho vem do RIPL e quanto vem da arquitetura LFM, que a Liquid vende desde o início como mais eficiente que transformers do mesmo porte. Com os números divulgados, ela não tem resposta, e isso decorre do desenho do teste. Cada barra do gráfico muda duas variáveis ao mesmo tempo: o modelo e o motor. Segundo o anúncio, o RIPL serve LFM2.5 de 230M a 2.6B parâmetros. Não roda Qwen. E entre as comparações publicadas não aparece um LFM servido pelo vLLM. Falta a linha que isolaria o motor.

O mais perto que a empresa chega disso está na conta oficial no X. A thread de lançamento traz um número que não aparece no gráfico do blog:

Hoje anunciamos o Liquid RIPL (real-time inference pipeline), nosso motor de inferência de latência ultrabaixa, construído para colocar LFMs diretamente no caminho da requisição de cargas de trabalho em tempo real como busca, anúncios, fraude, recomendações e pagamentos: respostas geradas completas de ponta a ponta em menos de 50 ms; mantém baixa latência sob pico de carga contínuo; LFMs ficam até 20x mais rápidos no RIPL; o RIPL suporta LFMs multimodais; o RIPL também suporta o d1, nossos modelos de decisão! O RIPL otimiza o caminho inteiro, da chegada da requisição até uma resposta gerada completa. À medida que o tráfego aumenta, sua vantagem de desempenho é maior nas requisições mais lentas. Vamos ver alguns casos de uso em produção:

— Liquid AI (@liquidai), 22 de out. de 2026, no X

"Até 20x mais rápidos" em relação a quê? O post não diz. Se a referência for o próprio LFM rodando no vLLM, a maior parte do ganho é do motor, e a comparação com o Qwen exagera menos do que parece. Se for outra coisa, a questão continua aberta. A frase que mais explica o gráfico é a penúltima: a vantagem cresce com o tráfego e aparece nas requisições mais lentas.

O 28,4x é retrato de uma fila

Um modelo de 0.8B gerando 128 tokens numa B200 não leva 4,4 segundos por falta de capacidade de computação. Um p95 de 4.431 ms em regime aberto tem cara de fila: requisições chegando mais rápido do que o sistema dá conta e esperando a vez. Passado o ponto de saturação, a latência em regime aberto não se estabiliza e continua subindo enquanto o teste durar. Nesse trecho da curva, a diferença entre dois sistemas depende menos da qualidade de cada um e mais da distância entre a carga escolhida e o joelho da curva do mais fraco.

As cargas da tabela variam por cenário: 1.000, 400 e 300 requisições por segundo. Quem as escolheu foi a Liquid. Não vejo má-fé nisso, porque todo benchmark escolhe um ponto de operação. Mas o 28,4x descreve aquele ponto, não uma constante do RIPL. Os números divulgados também não detalham versão do vLLM, limites de lote, prefill em blocos ou uso de CUDA graphs, parâmetros que mudam bastante onde o joelho cai. Um engenheiro que já opera vLLM em produção vai querer ver essas configurações antes de concordar com qualquer multiplicador.

O melhor argumento a favor da Liquid

O contraponto mais forte é que ninguém compra o motor separado do modelo. Quem tem 50 ms de orçamento no caminho de uma busca compra a pilha inteira: modelo, motor e GPU. Se o LFM2.5-1.2B no RIPL segura 34,6 ms de p95 a 1.000 requisições por segundo numa única B200, com qualidade suficiente, separar o mérito do motor e o do modelo vira curiosidade acadêmica. E a comparação não foi montada a favor da Liquid no tamanho dos modelos: o LFM é maior que o rival nas duas classes (1.2B contra 0.8B, 2.6B contra 2B) e ainda assim responde mais rápido.

Há também um cliente em produção. A Shopify (abre em nova aba) fechou em novembro de 2025 um acordo plurianual e milionário para licenciar LFMs em busca e num sistema de recomendação generativo desenvolvido em conjunto. A primeira implantação completa uma busca em menos de 20 ms. Mikhail Parakhin, CTO da Shopify, disse na época: "Já vi muitos modelos. Ninguém mais está entregando inferência abaixo de 20 ms em cargas reais como esta." O post do RIPL retoma o caso e afirma que a Shopify está colocando LFMs em produção em várias cargas de comércio sensíveis à latência.

O argumento é bom, mas tem dois furos. O primeiro: a Shopify participou da Série A de US$ 250 milhões da Liquid em dezembro de 2024. É cliente e também acionista. O depoimento tem valor, mas não equivale a uma auditoria independente. O segundo: foi a própria Liquid que escolheu comparar com o vLLM, e essa moldura leva o leitor a concluir que o motor dela é melhor. Para quem já roda vLLM e quer manter a liberdade de escolher modelo, a decisão é exatamente motor contra motor, e sobre isso os números publicados não dizem nada.

O que o anúncio deixa de fora

Segundo a MarkTechPost, o RIPL é fechado e restrito a clientes corporativos. A Liquid diz que ele está disponível para implantações enterprise de LFMs em GPUs NVIDIA como H100, H200, B200 e RTX PRO 6000. Não há preço público. A página da calculadora estima latência a partir dos dados medidos para o modelo e o formato de requisição escolhidos, e termina num "fale conosco". O anúncio não menciona CPU nem edge. Tem uma ironia aí: o rodapé da empresa fala em levar a inteligência a qualquer lugar, e o motor lançado, por ora, mora em GPU de data center.

O anúncio também não trata de idiomas. Para quem pensa em busca ou classificação em português, a qualidade de modelos entre 230M e 2.6B parâmetros nessa língua é uma pergunta que a Liquid não respondeu e que precisa ser testada com dados próprios antes de qualquer contrato. O mesmo vale para custo: o lançamento fala de latência sob carga, não de custo por requisição.

Onde fico

O RIPL tenta resolver um problema para o qual o vLLM não foi feito, e a Liquid identificou bem esse problema. Motores otimizados para throughput tratam a cauda da distribuição como efeito colateral. O RIPL trata a cauda como o produto, e isso tem valor real para fraude, busca e pagamentos. Mas os números do lançamento precisam ser lidos pelo que são. O 28,4x compara um vLLM operando além da saturação com uma pilha que ainda não chegou nela. Os 50 ms valem para 32 tokens. Quem tem carga curta, volume alto e paciência para testar em português deve pedir à Liquid um piloto com tráfego próprio. Quem quer saber se o RIPL é um motor melhor que o vLLM vai ter de esperar o único benchmark que a empresa ainda não mostrou: LFM contra LFM, mudando só o motor.