Testei o novo decision model da Liquid em um laptop com 8 GB. Veja o que aconteceu

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: I Ran Liquid’s New Decision Model on an 8GB Laptop. Here’s What Happened. · Canal: Prompt Engineer 48 · 09:24 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos locais e open source, Modelos multimodais, Segurança de IA

Resumo

O vídeo testa o D13B da Liquid AI, um decision model que responde a perguntas estruturadas em uma única passagem, sem gerar tokens de saída. Em um laptop com GPU RTX 4060 e 8 GB, o modelo classificou mensagens de clientes, analisou imagens, avaliou comandos de shell e julgou uma resposta factual, com tempos baixos para tarefas de texto. Também foi testado em vários idiomas, mas falhou ao interpretar sarcasmo e tratou literalmente uma mensagem que expressava intenção de pedir reembolso. O vídeo compara quantizações e resultados de benchmark, e ressalta que o D13B não é um modelo de chat nem deve ser usado como única camada de segurança.

Pontos-chave

O D13B aceita texto, JSON ou imagens como estado e responde a perguntas do tipo sim/não, escolha entre opções ou pontuação em níveis ordenados.
As respostas estruturadas são produzidas em uma única passagem, sem texto de saída para analisar ou tokens gerados.
No laptop com GPU RTX 4060, três perguntas sobre mensagens de clientes levaram em média 83 ms com Q8.
O modelo identificou corretamente animais em uma imagem, comandos de shell perigosos e uma resposta incorreta sobre a capital da França.
Classificou mensagens em espanhol, hindi, japonês e alemão sem que o apresentador traduzisse o texto do cliente.
Falhou ao detectar a intenção de reembolso em uma mensagem sarcástica, embora tenha identificado a equipe de cobrança.
A quantização Q4_K_M reduziu a latência de três perguntas de 83 para 70 ms e o uso de VRAM de 4,5 GB para 3,3 GB.
O apresentador alerta que o teste de segurança foi pequeno e que o modelo não deve ser a única proteção de um agent.
O D13B não é um modelo de chat; o vídeo também recomenda ler a licença LFM 1.0 antes de usar o modelo.

Capítulos

Início	Capítulo	Resumo
00:01	O que é o D13B e como funciona	O apresentador explica os tipos de perguntas estruturadas, o funcionamento em uma única passagem e as opções para executar o modelo localmente.
02:06	Configuração local e testes com texto e imagens	O vídeo mostra a configuração no llama.cpp e testa classificação de mensagens de clientes, desempenho e reconhecimento de uma imagem.
04:11	Guardrails, avaliação e suporte a idiomas	O D13B é testado com comandos de shell, avaliação de respostas factuais e mensagens em vários idiomas.
06:48	Falha com sarcasmo e testes de desempenho	O modelo interpreta literalmente uma mensagem sarcástica, e o apresentador mede concorrência, entradas longas e o desempenho da quantização Q4_K_M.
08:23	Benchmarks, limitações e conclusão	O vídeo compara a pontuação do D13B com outros modelos, ressalta suas limitações e recomenda revisar a licença antes do uso.

Citações

Ele não escreveu nada: zero tokens de saída. — 00:01

A confiança nessa resposta é de apenas 0,34. — 03:11

Não estou dizendo que ele detecta tudo; por favor, não use isso como sua única camada de segurança. — 05:13

Se o seu pipeline depende de detectar intenção de reembolso, um sarcasmo como esse vai passar despercebido. — 06:48

Se você quer escrever ou explicar, esta é a ferramenta errada. — 08:53

Conceitos e entidades

D13B (modelo): Decision model da Liquid AI testado no vídeo para responder a perguntas estruturadas sobre texto, JSON ou imagens.
Liquid AI (empresa): Empresa responsável pelo D13B e pelos benchmarks internos citados no vídeo.
LFM 2.5 VL3B (modelo): Modelo a partir do qual o D13B foi pós-treinado, segundo o model card.
llama.cpp (ferramenta): Ferramenta usada para executar o D13B localmente por meio de uma versão que oferece suporte ao endpoint do decision model.
GGUF (repo): Formato e repositório de arquivos do modelo usados para executar versões quantizadas localmente.
Q8 (modelo): Quantização do D13B usada nos testes principais, com arquivo de 2,87 GB.
Q4_K_M (modelo): Quantização menor do D13B que reduziu o uso de VRAM e a latência nos testes relatados.
LFM 1.0 (conceito): Licença mencionada para o modelo, que o apresentador recomenda ler antes de colocá-lo em uso.
Decision Index 0.2.1 (conceito): Tabela de avaliação citada no vídeo, na qual o D13B obteve pontuação de 48,57.

Tradução completa (pt-BR)

00:01 Certo, neste vídeo vamos testar o D13B da Liquid AI. Como vocês podem ver aqui, enviei uma mensagem de cliente e três perguntas, e ele respondeu às três de uma só vez. Olhem esta linha: zero tokens de saída. Ele não escreveu nada: reembolso, sim, 0,99; equipe, cobrança, 0,98; pontuação de urgência — tudo em cerca de 80 milissegundos. E lembrem-se: tudo o que vocês estão vendo está rodando no meu sistema local, neste laptop com RTX 4060 da AGB. Então, vamos ver o que essa coisa realmente é e onde ela falha. Aqui está o

00:32 model card. O D13B é um decision model com 3,12 bilhões de parâmetros, pós-treinado a partir do LFM 2.5 VL3B, o que significa que também aceita imagens. Isso é importante, e o próprio model card diz isso: ele não é um modelo de chat e não escreve texto. O que você faz é fornecer um estado, que pode ser uma string, qualquer JSON ou uma imagem, e fazer perguntas nomeadas. Há três tipos: null, que é uma pergunta de sim ou não e retorna a probabilidade de sim; choice, em que você descreve as opções e ele retorna a escolha, além da probabilidade de cada opção; e

01:04 score, em que você fornece de dois a dez níveis ordenados e ele retorna um nível esperado com uma confiança. E tudo isso sai em uma única passagem forward. Então, não há JSON para extrair de um parágrafo, nem nova tentativa porque o modelo divagou, nem espera pelos tokens sendo transmitidos. Por que você iria querer isso? Se olhar a tabela de velocidade no model card, uma pergunta em uma RTX 4090 leva 8 milissegundos. Esse resultado é com a compilação ativada. Em uma Jetson Orin Nano, leva 50 milissegundos. Em um Apple M5 Pro, são 30. Esse é o tipo de coisa que você coloca na frente de

01:34 cada solicitação: um roteador, uma verificação de moderação, uma barreira de proteção, um juiz, porque custa quase nada. E o model card lista casos de uso como roteamento e triagem, classificação de intenção, reranking, LLM as a judge, pontuação e barreiras de proteção para agents. Vamos testar alguns deles por conta própria no meu laptop, não usando os números da tabela deles. Para rodar localmente, há um repo GGUF, e aqui estão os arquivos. Q8 tem 2,87 GB, Q4 KM tem 1,67 GB, e há um arquivo MM proj separado para

02:06 visão, com 583 MB em Q8. Também há arquivos BF16 e F16 de 5,4 GB, caso você tenha espaço. Uma coisa importante: isso não funciona com qualquer llama.cpp. O endpoint system one foi incorporado ao llama.cpp no pull request 29818, e usei a versão B115552, a compilação para Windows com CUDA 12.4. Se seu llama.cpp for mais antigo, atualize-o primeiro. O comando é simples: llama server -m com o arquivo Q8, –mmproj

02:37 com o arquivo mm proj, ngl 99, e ele carrega. No log, dá para ver que aparece “decision model type LFM2-D1” e que está escutando na porta 8080. Vamos enviar o primeiro exemplo. A mensagem é: “Fui cobrado duas vezes este mês. Por favor, reembolsem uma delas.” Três perguntas: o cliente está pedindo um reembolso? Isso é do tipo null. Qual equipe deve cuidar disso: cobrança, suporte técnico ou fraude? Isso é do tipo choice. E qual é a urgência? Três níveis: pode esperar até hoje ou está impedindo o cliente de prosseguir agora. E vocês podem ver a resposta. Reembolso

03:11 0,99; equipe de cobrança, com 0,984; e suporte técnico, 0,01. Fraude fica em meio por cento. Agora, a pontuação de urgência é 0,76 em uma escala de 0 a 2. E, se olharem as probabilidades, elas estão distribuídas: 34% pode esperar, 56% hoje, 10% impedindo o cliente. E a confiança para essa resposta é de apenas 0,34. Então, isso me diz que o modelo está em dúvida, e posso criar uma regra: se a confiança for menor que 0,5, encaminhe para uma pessoa. O uso indica 154

03:41 tokens de entrada, zero tokens de saída. Mas essa resposta pode ter sido um caso de sorte. Então, escrevi um pequeno script em Python e fiz 60 chamadas com aquecimento, alternando entre cinco mensagens de clientes diferentes, com três perguntas em uma única passagem. A mediana é de 83 milissegundos em Q8, e a mais lenta das 60, no percentil 95, é de 87. Com uma pergunta, a mediana é de 23 milissegundos. Então, comparem com o model card: uma 4090, com três perguntas, leva 21 milissegundos. Meu laptop é cerca de quatro vezes mais lento que isso, mas ainda não chega a

04:11 um décimo de segundo. Para um modelo com 3 bilhões de parâmetros em uma GPU de laptop com 8 GB, estou satisfeito com esse resultado. Agora, a imagem. Esta é a mesma foto do readme, com dois gatos em um sofá. O estado é apenas uma linha de texto dizendo que é uma foto para um pedido de hospedagem de animais, e a imagem é enviada como base64. As perguntas são: quais animais — gatos, cachorros ou pássaros? Eles estão em um sofá? E quantos: um, dois ou três ou mais? Gatos, 0,989; sofá, 0,963;

04:41 dois, 0,979. A contagem está correta. Levou 533 milissegundos, com 831 tokens de entrada e, mais uma vez, zero tokens de saída. É mais lento do que com texto, como esperado, porque a imagem precisa passar primeiro pelo codificador de visão. Agora, eu queria muito testar este caso, porque é o uso de barreira de proteção para agents. Forneço um comando de shell como estado e faço duas perguntas: isso destruiria dados? E quão arriscado é? Inofensivo, precisa de revisão ou perigoso? A última camada na pasta dos meus projetos

05:13 é inofensiva, 0,968; rm -rf / sem preserve root é perigoso, 0,978; e git push force origin main é perigoso, 0,965, com destruição de dados em 0,86. Cada um desses resultados chegou em 60 a 90 milissegundos. Então, você pode colocar isso na frente das chamadas de ferramentas de um agent e bloquear qualquer coisa cuja probabilidade de perigo ultrapasse um limite que você escolher. Mas lembrem-se: são quatro comandos. Não estou dizendo que isso detecta tudo, então, por favor, não usem isso como sua única camada de segurança. Mais

05:45 um caso: LLM as a judge. O estado é um objeto JSON: pergunta, qual é a capital da França? Resposta, Lyon, porque é a maior cidade. E pergunto: a resposta está factualmente correta? Ele retorna 0,058 e, na pontuação de qualidade, coloca 95% no nível chamado “errado”. Essa é a resposta correta, e levou 82 milissegundos. O model card lista 16 idiomas, então vamos testar isso. As mesmas três perguntas, o mesmo script, mas agora o cliente escreve em espanhol: “Me cobraron dos veces este mes”. Reembolso, 0,989; equipe de cobrança, 0,983. Depois, a mesma

06:17 frase em hindi, e vocês podem ver o texto em devanágari aqui. Reembolso, 0,987; cobrança, 0,982. Japonês: reembolso, 0,987; cobrança, 0,982. Japonês: reembolso, 0,987; cobrança, 0,984. E uma mensagem em alemão que diz que o aplicativo trava toda vez que abro as configurações. Reembolso é 0,026; equipe…

06:48 Vamos tentar fazer o modelo falhar. Esta é uma mensagem sarcástica: “Ah, ótimo, mais um teste grátis que cobra no meu cartão. Obrigado por nada, não estou nem um pouco pedindo um reembolso, jamais.” Uma pessoa lê isso e entende que o cliente está irritado com uma cobrança, mas o modelo retorna reembolso, 0,02. Então, interpretou a frase literalmente. Acerta a equipe: cobrança. Mas, se seu pipeline depende da intenção de pedir reembolso, um sarcasmo desses vai passar despercebido. Portanto, é algo que você deve testar com suas próprias mensagens antes de confiar no modelo. Em seguida, iniciei o llama server com quatro slots. Então, eu

07:20 enviei 64 solicitações com quatro workers ao mesmo tempo. Isso terminou em 5,57 segundos, o que dá 11,5 solicitações por segundo, com três perguntas em cada uma. A mediana por solicitação sobe para 178 milissegundos porque elas estão compartilhando a GPU. Depois, testei uma entrada longa: criei um registro de chat fictício com 3.040 tokens e um pedido de reembolso bem no final. O modelo encontrou o pedido: reembolso, 0,98, em 511 milissegundos. O model card informa 102 milissegundos para um estado de 3,4 mil tokens em uma 4090. Então, meu laptop é cerca de cinco vezes mais lento nesse caso, e

07:51 Ainda meio segundo. Agora, o modelo Q4: rodei o mesmo script no Q4KM. As cinco mensagens de texto deram a mesma escolha de equipe que no Q8, e as probabilidades de reembolso são 0,99 e 0,991 na primeira. Os gatos voltaram como gatos, e a latência para duas ou três perguntas cai de 83 para 70 milissegundos. A VRAM usada vai de 4,5 gigabytes para 3,3. Isso inclui o projetor de visão e quatro slots, com contexto de 32K. Então, se você está com pouca memória, o Q4KM parece a escolha sensata

08:23 Agora, vou ser direto sobre os números da tabela Decision Index 0.2.1: o D13B marca 48,57. O Qwen 12B, que tem quatro vezes o tamanho, marca 50,02. Então, ele não está em primeiro lugar nessa tabela. Está à frente do Decider de 36 bilhões, que marca 47,11, e do JPT de 9,7 bilhões, com 46,89. Então, o que dá para dizer é que ele é o melhor abaixo de 10 bilhões nesse índice, como diz o cartão. E estes são os benchmarks internos da Liquid. Eles o pontuaram com

08:53 o avaliador oficial, mas isso não é uma submissão ao placar, e minhas cinco mensagens — quatro comandos e uma mensagem sarcástica — também não são um benchmark. A pontuação de conhecimento é 23,8, a coluna mais fraca da tabela. E, de novo, ele não é um modelo de chat. Se você quer escrever ou explicar, esta é a ferramenta errada. A licença é LFM 1.0. Então, leia-a antes de colocar qualquer coisa em produção. Neste vídeo, vimos como o D13B responde a perguntas digitadas em uma única passagem, com zero tokens de saída, e leva de 70 a 83 milissegundos para três perguntas em um

09:24 laptop com 8 GB. Acertou os gatos, acertou a barreira de proteção, acertou em hindi e japonês e errou no teste de sarcasmo, que também mostrei para vocês. Se tiver interesse, pode experimentar no seu próprio sistema. Os links estão na descrição, e me contem o que escreveram com ele. Agradeço à Liquid AI pelo modelo. Vejo vocês em outro vídeo. Confiram o próximo vídeo.

Transcrição original

[00:01] All right, in this video we are going to test D13B from Liquid AI and you can see right here that I sent it one customer message and three questions and it answered all three in one pass. Look at this line, output tokens zero. [music] It did not write anything, refund yes, 0.99, team billing 0.98, urgency [music] score all in about 80 milliseconds. Now mind you, everything you’re seeing is running on my local system, [music] this AGB’s RTX 4060 laptop. So, let’s go ahead and see what this thing really is and where it breaks. So, here’s the

[00:32] model card. D13B is a decision model, 3.12 [music] billion parameters post trained from LFM 2.5 VL3B, which means it also takes images. Now, this is important and the card says [music] it itself. It is not a chat model and it does not write text. What you do is you give it a state that can be a string, any JSON, [music] or an image and you give it named questions. There are three types, null, which is a yes or no, and it gives you the probability of yes, [music] choice, where you describe the options and it gives you the pick plus the probability for every option, and

[01:04] score, where you give two to 10 ordered levels [music] and it gives you an expected level with a confidence. And all of that comes out of one forward pass. So, there’s no JSON to parse out of a paragraph, no retry because it rambled, and no waiting for tokens to stream. Now, why would you want this? If you look at the speed table on the card, one question on an RTX 4090 is 8 milliseconds. That one is with compile [music] turned on. On a Jetson Orin Nano, it is 50 milliseconds. On an Apple M5 Pro, it is 30. So, this is the kind of thing you put in front [music] of

[01:34] every request, a router, a moderation check, a guardrail, a judge, because it costs you almost nothing. And the card lists [music] use cases like routing and triage, intent classification, reranking, LLM as a judge, scoring, [music] and agent guardrails. We are going to test a few of those ourselves on my laptop, not on [music] their table. So, for running it locally, there is a GGUF repo and here are the files. [music] Q8 is 2.87 GB, Q4 KM is 1.67 GB, and there is a separate MM proj file for

[02:06] vision. 583 MB at Q8. There are also BF16 [music] and F16 files at 5.4 GB if you have the room. Now, one thing [music] to note, this does not work with just any llama.cpp. The system one endpoint was merged into llama.cpp in pull request [music] 29818 and I used release B115552, the [music] Windows CUDA 12.4 build. If your llama.cpp is older, update it first. The command is simple. llama server -m with the Q8 file, –mmproj

[02:37] [music] with the mm proj file, ngl 99 and it loads. You can see in the log it says decision [music] model type LFM2-D1 and it is listening on port 8080. Let’s go ahead and send the first one. The message is, “I was [music] charged twice this month. Please refund one of them.” Three questions, is the customer asking for a refund? That is a null. Which team should handle this? Billing, technical, or fraud? That is a choice. [music] And how urgent is this? Three levels, can wait today, blocking the customer now. And you can see the answer. Refund

[03:11] 0.99 team billing with 0.984 and technical is 0.01. Fraud is half a percent. [music] Now urgency, the score is 0.76 on a scale of 0 to 2. And if you look at the probabilities, it is spread [music] out. 34% can wait, 56% today, 10% blocking. And the confidence for that one is only 0.34. >> [music] >> So it tells me it is unsure and I can write a rule if confidence is under >> [music] >> 0.5, send it to a human usage. Says 154

[03:41] input [music] tokens, zero output tokens. Now that one call can be a lucky one. [music] So I wrote a small Python script and did 60 warm calls rotating over five different customer messages with three questions in one pass. The median is 83 milliseconds [music] on Q8 and the slowest of the 60, the 95th percentile is 87. [music] With one question, the median is 23 milliseconds. So, compare that to the card, a 4090 [music] with three questions is 21 milliseconds. My laptop is about four times slower [music] than that and it is still not

[04:11] even a tenth of a second. For a 3 billion parameter model on an 8GB laptop GPU, I’m happy with that. Next, the image. This is the same photo from the readme, two cats on a sofa. State is [music] just a line of text saying it is a photo for a pet sitting request and the image goes in as base 64. [music] Questions, which animals, cats, dogs, or birds? Are they on a sofa? And how many, one, two, or three, or more? Cats, 0.989, [music] sofa, 0.963,

[04:41] two, 0.979. The count [music] is right. It took 533 milliseconds with 831 input tokens and again, zero output tokens. Slower than text [music] as expected because the image has to go through the vision encoder first. Now, this one I really wanted to try [music] because it is the agent guardrail use case. I give it a shell command as the state and ask [music] two questions. Would this destroy data and how risky is it? Harmless, needs review, [music] or dangerous? Last layer on my projects

[05:13] folder, harmless, 0.968, >> [music] >> rm -rf / with no preserve root, dangerous, 0.978, and git push force origin main, dangerous, 0.965, and destroy data [music] at 0.86. Each of these came back in 60 to 90 milliseconds. So, you can put this in front of an agent’s tool calls and block anything where the danger probability crosses >> [music] >> a line you pick. Mind you, this is four commands. I’m not claiming it catches everything, so please do not use this as [music] your only safety layer. One

[05:45] more, LLM as a judge. The state is a JSON object question, what is the capital of France? Answer, Lyon, because it is the biggest [music] city. And I ask, is the answer factually correct? It says 0.058, and on the quality score it puts 95% on the level called wrong. That is the correct call, and it took 82 [music] milliseconds. The card lists 16 languages, so let me test that. Same three questions, same script, but now the customer writes in Spanish, [music] they charged me twice this month, refund 0.989, team billing 0.983, then the same

[06:17] sentence in Hindi, and you can see the Devanagari text right here. Refund 0.987, billing 0.982, [music] Japanese refund 0.987, billing 0.982, Japanese refund 0.987, billing 0.984, and a German message that says the app crashes every time [music] I open settings. Refund is 0.026, team >> [music] >> So, I did not translate anything, and I did not change a single question. The question stayed in English, and the customer writes in whatever [music] language they want. Now, let me try to

[06:48] break it. This is a message with sarcasm. Oh, great, another free trial that charges my card. Thanks for nothing, totally not asking for a [music] refund, I would never. A person reads that and knows this customer is angry about a charge, and the model [music] says refund 0.02. So, it took the sentence literally. It does get the team [music] right, billing. But, if your pipeline depends on refund intent, sarcasm like this will slip [music] through. So, that is something you want to test with your own messages before you trust it. Next, load Lama server [music] started with four slots. So, I

[07:20] sent 64 requests with four workers at the same time. That finished in 5.57 seconds, [music] which is 11.5 requests per second with three questions each. The median per request goes up to 178 milliseconds because they’re sharing the GPU. And then a long input, I built a fake [music] chat log of 3,040 tokens with a refund request at the very end. It found [music] it, refund 0.98 in 511 milliseconds. The card says 102 milliseconds for a 3.4 thousand [music] token state on a 4090. So, my laptop is about five times slower there and it is

[07:51] still half a second. Now, the Q4 model, I ran [music] the exact same script on Q4KM. All five text messages gave the same team choice as Q8 and the refund probabilities are 0.99 and 0.991 on the first one. The cats came back as [music] cats and two three question latency drops from 83 to 70 milliseconds and the VRAM used goes [music] from 4.5 gigabytes to 3.3. That includes the vision projector and four slots >> [music] >> at 32K context. So, if you’re short on memory, Q4KM looks like the sensible

[08:23] pick. Now, let me be straight about the numbers on [music] the decision index 0.2.1 table, D13B scores 48.57. Win now 12B, which is four times the size, scores [music] 50.02. So, it is not number one on that table. It is ahead of the 36 billion Decider, [music] which is 47.11 and the 9.7 billion JPT at 46.89. So, what you can say is it is the best under 10 billion on this index [music] as the card says. And these are Liquid’s own internal benchmarks. They scored it with

[08:53] the official scorer, but it is [music] not a leaderboard submission and my five messages, four commands and one sarcastic message are [music] not a benchmark either. The knowledge score is 23.8, which is the weakest column on the table. And again, it is [music] not a chat model. If you wanted to write or explain, this is the wrong tool. License is LFM 1.0. [music] So, read it before you ship anything. So, in this video, we have seen how D13B answers [music] typed questions in a single pass with zero output tokens, 70 to 83 [music] milliseconds for three questions on an

[09:24] 8GB laptop. Correct on the cats, correct on the guardrail, correct in Hindi and Japanese and wrong on the sarcasm test, which I showed you, too. If you’re interested, you can go ahead and try this on [music] your own system. The links are in the description and let me know what you wrote with it. Credit [music] to Liquid AI for the model. I’ll see you in another one. Check out the next video.