A Liquid AI lancou dois novos modelos de busca, LFM2.5-Embedding-350M e LFM2.5-ColBERT-350M, e o destaque e o tamanho: com 350 milhoes de parametros cada, ambos superam o maior Qwen3-Embedding-0.6B em busca multilingue. Eles sao os primeiros membros bidirecionais da familia LFM, construidos a partir do checkpoint LFM2.5-350M-Base que a Liquid lancou em marco, e estao ajustados para busca multilingue e cross-lingual rapida em 11 idiomas: arabe, alemao, ingles, espanhol, frances, italiano, japones, coreano, noruegues, portugues e sueco.

Os dois modelos seguem caminhos diferentes para a mesma tarefa. O LFM2.5-Embedding-350M e um bi-encoder denso: ele comprime um documento inteiro em um unico vetor de 1024 dimensoes, o que mantem o indice de busca pequeno e as consultas baratas. O LFM2.5-ColBERT-350M usa interacao tardia em vez disso, mantendo um vetor separado de 128 dimensoes para cada token e comparando uma consulta palavra por palavra no momento da busca. Essa comparacao em nivel de token tende a ser mais precisa e a generalizar melhor para topicos nos quais o modelo nao foi treinado, ao custo de um indice maior. Ter ambos em uma so familia permite que uma equipe escolha o compromisso que melhor se encaixa, ou use o bi-encoder barato para recuperar e o modelo ColBERT para reordenar.

Os numeros sustentam a afirmacao sobre o tamanho. No NanoBEIR Multilingual, um benchmark de busca pontuado por NDCG@10, o modelo ColBERT atinge media de 0.605 e o modelo de embedding 0.577 nos 11 idiomas, ambos a frente do Qwen3-Embedding-0.6B com 0.556, do anterior LFM2-ColBERT-350M com 0.540 e do gte-multilingual-base da Alibaba com 0.528. No MKQA-11, um teste de resposta a perguntas cross-lingual pontuado por Recall@20, os dois ficam em 0.694 e 0.691, novamente acima do Qwen3 com 0.638. As vitorias nao sao esmagadoras, mas um modelo de 350M superando um de 0.6B em busca multilingue e o tipo de resultado que importa quando voce paga por cada vetor que armazena e serve.

A velocidade e a outra metade do argumento. A Liquid relata um embedding de consulta em cerca de 7.3 milissegundos na mediana em uma CPU de MacBook M4 Max, e aproximadamente 1.5 milissegundos em uma GPU H100. Ambos os modelos suportam um contexto de 32.768 tokens, ajustado para 512 tokens em documentos, e chegam nos formatos padrao e GGUF para que rodem sob o llama.cpp. Como a empresa coloca, eles sao pequenos o suficiente para rodar em quase qualquer lugar. Ambos estao disponiveis agora no Hugging Face sob a LFM Open License v1.0.

Para quem constroi busca, essa combinacao e a parte interessante. A qualidade de busca costuma subir junto com o tamanho do modelo e a conta que vem com ele, entao espremer uma busca multilingue melhor em um modelo que cabe em um celular ou em uma unica CPU aponta para o sentido oposto: busca privada, no dispositivo e barata de servir, que nao recorre a uma API hospedada. As ressalvas merecem ser ditas com clareza. Estes sao modelos de busca e embedding, nao modelos de chat; os benchmarks sao o NanoBEIR e o MKQA, e nao a suite MTEB completa; e superar um modelo de 0.6B e uma vitoria real, porem estreita, nao um salto a frente dos maiores embedders comerciais. Ainda assim, a direcao e clara, e e a direcao para a qual a busca com modelos pequenos vem caminhando o ano todo.