Testei o Drex V1.5 da Nace.AI localmente (llama.cpp, Q4_K_M e demonstrações reais)

Ver no idioma original →

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 Nace.AI’s Drex v1.5 Locally (llama.cpp, Q4_K_M, Real Demos) · Canal: Prompt Engineer 48 · 07:32 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Cibersegurança e segurança de software, Inferência e otimização de modelos, Modelos locais e open source

Resumo

O vídeo apresenta o Drex V1.5, um decision model de 9 bilhões de parâmetros que retorna probabilidades em vez de gerar texto. O apresentador compila uma versão modificada do llama.cpp e executa o modelo em um laptop com GPU de 8 GB, após quantizá-lo para Q4_K_M. Demonstra o uso do modelo em tickets de suporte, detecção de phishing, análise de avaliações e perguntas sobre documentos longos. Também compara alguns resultados com os números publicados e ressalta que não verificou se a versão Q4_K_M mantém todas as respostas das versões BF16 e Q8_0.

Pontos-chave

• O Drex V1.5 recebe um estado em texto ou JSON e perguntas tipadas; retorna probabilidades por opção, sem gerar texto.
• As perguntas aceitam os tipos choice, null (sim ou não) e score (uma escala ordenada).
• O modelo tem 9 bilhões de parâmetros e é baseado na arquitetura Qwen 3.5; os pesos BF16 ocupam cerca de 18 GB.
• A versão Q8_0 de 9,5 GB não funcionou de forma utilizável no laptop; a quantização Q4_K_M reduziu o arquivo para 5,6 GB.
• O apresentador executou o modelo em uma GPU de 8 GB com llama.cpp modificado e demonstrou o uso em tickets de suporte.
• Em outras demonstrações, o modelo identificou uma mensagem de phishing, avaliou uma análise de produto e respondeu perguntas sobre o texto do model card.
• Uma consulta com contexto longo levou 113 segundos porque outro processo ocupava cerca de 5 GB de VRAM; esse tempo não representa o desempenho normal do modelo.
• O vídeo alerta que o servidor se vincula a 127.0.0.1 e não tem autenticação, recomendando adicionar proteção antes de expô-lo.
• O apresentador não comparou diretamente as respostas da quantização Q4_K_M com as versões BF16 e Q8_0.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do Drex V1.5	O vídeo introduz o modelo e mostra uma resposta probabilística a um ticket de suporte executada localmente.
02:06	Compilação e quantização local	O apresentador descreve a versão modificada do llama.cpp, os limites de memória e a quantização Q4_K_M.
03:17	Demonstrações com tickets e conteúdo	O modelo é testado com tickets, uma mensagem suspeita, uma avaliação de produto e perguntas sobre um texto longo.
05:26	Resultados publicados e segurança do servidor	O vídeo contextualiza os benchmarks e tempos divulgados, comenta a ausência de autenticação e apresenta resultados de jogos.
06:59	Limites da comparação e conclusão	O apresentador ressalta que não verificou a equivalência entre Q4_K_M e outras versões e resume a execução local.

Citações

Ele não escreveu uma única palavra. — 00:00

Ele não gera texto. Cada pergunta exige uma passagem forward. — 00:31

As probabilidades mostram essa divisão, que é justamente o propósito de um modelo que fornece números, e não uma frase. — 04:55

Não interprete o meu número como se fosse o número do modelo. — 05:26

Não executei essa comparação, então não posso dizer que meu Q4_K_M corresponda a ela em todos os casos. — 06:59

Conceitos e entidades

• Drex V1.5 (modelo): Decision model de 9 bilhões de parâmetros que responde a perguntas com probabilidades para opções especificadas.
• Nace.AI (empresa): Empresa associada ao Drex V1.5 e aos resultados publicados no model card.
• Qwen3.5 (modelo): Arquitetura-base indicada para o Drex V1.5.
• llama.cpp (ferramenta): Projeto usado para compilar e executar localmente o servidor do modelo.
• Q4_K_M (conceito): Formato de quantização usado para reduzir o arquivo do modelo a cerca de 5,6 GB.
• Q8_0 (conceito): Formato quantizado do modelo, cujo arquivo baixado pelo apresentador tinha 9,5 GB.
• Hugging Face (ferramenta): Plataforma onde o apresentador consulta a página e os arquivos do modelo.

Tradução completa (pt-BR)

00:00 Oi, sou engenheiro de prompts. Neste vídeo, vamos analisar o Drex V1.5, um decision model que responde com probabilidades, e vou executá-lo no meu próprio laptop com 8 GB. Certo. Neste vídeo, vamos conhecer o Drex V1.5, um modelo de 9 bilhões de parâmetros da Nace AI. E você pode ver que, quando envio um chamado de suporte, ele retorna “cobrança” com probabilidade de 0,986, sem escrever uma única palavra. Vale lembrar que tudo aqui está rodando no meu sistema local, neste laptop com GPU de 8 GB que tenho aqui, por meio de um servidor llama que eu mesmo criei. Vamos lá

00:31 e testar. Esta é a página do modelo no Hugging Face: Nace AI/Drex V1.5. Se você olhar aqui, verá que ele é descrito como um decision model. Você fornece um estado, que pode ser texto ou JSON, e perguntas tipadas, e ele retorna uma probabilidade para cada opção. Ele não gera texto. Cada pergunta exige uma passagem forward. Há três tipos de pergunta: choice, em que você nomeia as opções; null, que é uma pergunta de sim ou não e fornece uma

01:02 probabilidade de sim; e score, que é uma escala ordenada, começando pelo menor valor. Ele é baseado na arquitetura Qwen 3.5 de 9 bilhões, com 32 camadas, pesos BF16 e cerca de 18 GB em disco. Ele tem um pequeno arquivo head.pt, de apenas 8 MB, e é esse head que calcula a pontuação de cada opção. A principal alegação no cartão é que ele fica em primeiro lugar entre os modelos com menos de 10 bilhões de parâmetros no decision index, com 0,311 e uma pontuação de 58,08. Há uma segunda tabela no cartão para

01:32 contexto longo. De 8.000 a 32.000 tokens, ele apresenta 89,5% de precisão. E de 32.000 a 128.000 tokens, 93,4%. Se você truncar as mesmas entradas para 8.000 tokens, esses valores caem para 76,5% e 78%. Então, o cartão está dizendo que a entrada longa é o que importa aqui. Agora, se você abrir a aba de arquivos, verá quatro partes safetensors, com cerca de 4,9, 5, 4,9 e 3 GB, totalizando cerca de 17,9 GB. Isso não cabe na minha placa de 8 GB.

02:06 Também há um fork no GitHub, Nace AI/llama, na branch drex v1.5. A descrição diz que ele adiciona um endpoint post/v1/system e encaminha a solicitação para um servidor llama da branch drex v1.5 do llama.cpp deles. E, ao executar um llama create, ele detecta os tensores de ponteiro no GGUF e marca o modelo como decision, em vez de completion. Então, o que fiz foi clonar a branch drex v1.5 do llama.cpp deles e compilar o llama server com CUDA para minha RTX 4060. A compilação levou vários minutos.

02:45 Depois, baixei o GGUF Q8_0 deles, que tem 9,5 GB, e aqui vai a parte sincera. Iniciei com 26 camadas na GPU, e o sistema ficou sem memória do host. Com 10 camadas, ele carregou, mas minha primeira solicitação levou 334 segundos porque o laptop estava usando memória virtual. Então, isso não é utilizável. O que você pode fazer é quantizá-lo por conta própria. Executei o quantize do llama.cpp com Q4_K_M. Levou cerca de 135 segundos, e o arquivo passou de 9,5 para 5,6 GB. Agora, o

03:17 conjunto todo fica na GPU, e inicio o servidor com embedding ativado, pooling none e contexto de 16384. Certo, primeira demonstração. O chamado diz: “Fui cobrado duas vezes pelo mesmo pedido. Por favor, reembolsem o pagamento extra.” Três perguntas: para qual equipe o cliente pede um reembolso e qual é a urgência? Você pode ver que a equipe é “cobrança”, com 0,986; reembolso fica em 0,992; e a urgência é “urgente”, com 0,418, enquanto “em breve” fica em 0,305. Então,

03:51 nesse caso, ele não está confiante, e tudo bem. Uma cobrança duplicada não é uma interrupção do serviço. Agora, altero o chamado para: “A página de checkout retorna um erro 500 para todos os clientes desde as 9h40.” A equipe passa a ser “técnica”, com 0,958. Reembolso cai para 0,006, e a urgência é “urgente”, com 0,949. As mesmas três perguntas, um estado diferente, e os números mudam como seria de esperar. Em seguida, dou a ele um e-mail que diz: “Sua conta será suspensa em 24 horas. Clique neste link e informe

04:24 sua senha e OTP.” É phishing? 0,9994. O que o filtro de e-mail deve fazer? Bloquear, com 0,987. Colocar em quarentena, com 0,013. E essa resposta saiu em menos de um segundo. Depois, uma avaliação de produto: “A bateria dura 2 dias. A tela rachou depois de uma queda de 1 pé. O suporte levou 3 semanas.” A avaliação de sentimento numa escala de 5 pontos resulta em 1,65, com “misto” em 0,617. Menção ao suporte: 0,996; e a principal

04:55 reclamação é durabilidade, com 0,55, e suporte, com 0,45. Então, neste caso, há uma divisão, e as probabilidades mostram isso, que é justamente o objetivo de um modelo que fornece números, e não uma frase. Para uma entrada mais longa, passei ao modelo o próprio texto do cartão, com 4.389 tokens. O documento diz que o servidor HTTP exige um cabeçalho de autorização por padrão? 0,045, o que está correto. O cartão diz que nenhum cabeçalho é necessário. Ele diz que o

05:26 modelo gera texto livre? 0,002. Qual é a arquitetura base? Qwen, com 0,9999. Vale lembrar que essa execução levou 113 segundos na minha máquina porque outro processo estava ocupando cerca de 5 GB da minha memória de vídeo. Do lado deles, eles relatam uma mediana de 0,65 segundo para 8K a 32K tokens em uma A10G. Então, não interprete meu número como sendo o número do modelo. Agora, a alegação dos 58,08

05:58 vem da execução da própria Nace com o kit oficial. O Jeff 130 Town 0 marcou 57,296, e o Bespoke Nimble marcou 57,29; o próprio cartão diz que esses três estão dentro da faixa de empate de 0,9 ponto do quadro de classificação. No benchmark Jeff, o Drex obtém 86,2% e o Jeff, 87,0%. O servidor se vincula a 127.0.0.1 e não tem autenticação. Então, adicione isso antes de expô-lo. A licença é NACE AI OpenRAIL-M para o modelo e

06:29 Apache 2.0 para o código. Também há um gráfico do Game Arena no cartão. Oito jogos do OpenSpiel, com 32 partidas em cada um contra o Jeff. Ele informa 122 vitórias, 47 empates e 87 derrotas, o que corresponde a 56,8%, e o cartão diz que o Drex supera o Jeff em 20 dos 37 benchmarks. Portanto, em 17, não supera. Além disso, os números que mostrei vieram de uma quantização de quatro bits que fiz a partir do arquivo de oito bits deles. O cartão diz que as versões BF16 e Q8_0 deles deram as mesmas respostas que o servidor Python. Não fiz essa comparação, então não posso afirmar que meu Q4_K_M corresponda a ele em todos os casos. Então, neste vídeo vimos como compilar o servidor llama do Drex V1.5, quantizar o GGUF para 5,6 GB e enviar a ele chamados, um e-mail e uma avaliação usando um laptop com 8 GB. Se tiver interesse, você também pode testar isso no seu próprio sistema e me contar como foi. O modelo é NACE AI/Drex V1.5.

06:59 Vejo você em outro vídeo. Confira o próximo. O link para a página do modelo e para o fork no GitHub está na descrição. Obrigado por assistir, e até o próximo vídeo.

07:32 Vejo vocês em outro vídeo. Confira o próximo vídeo. O link da página do modelo e do fork no GitHub está na descrição. Obrigado por assistir, e vejo vocês no próximo.

Transcrição original

[00:00] Hi, I’m prompt engineer. In this video, we look at Drex V1.5, a decision model that answers with probabilities, and I run it on my own 8GB’s laptop. All right. In this video, we will see Drex V1.5, a 9 billion parameter model from Nays AI. And you can see that when I send it a support ticket, it comes back with billing at 0.986, and it did not write a single word. Now, mind you that everything here is running on my local system, this 8GB GPU GPU laptop that I have here through a llama server I built myself. Let’s go ahead

[00:31] and test this out. So, this is the model page on Hugging Face, Nays AI/Drex V1.5. If you look here, it says it’s a decision model. You give it a state, which can be text or JSON, and typed questions, and it returns a probability for each option. It does not generate text. Each question takes one forward pass. There are three question types: choice, where you name the options, null, which is a yes or no and gives you a

[01:02] probability of yes, and score, which is an ordered scale, lowest first. It’s built on the Qwen 3.5 9 billion architecture, 32 layers, BF16 weights, about 18 GB’s on disk. It has a small head.pt file, only 8 MB’s, and that head is what scores each option. The headline claim on the card is number one under 10 billion parameters on decision index 0.311 with a score of 58.08. There is a second table on the card for

[01:32] long context. From 8,000 to 32,000 tokens, it reports 89.5% accuracy. And from 32,000 to 128,000 tokens, 93.4%. And if you truncate the same inputs to 8,000 tokens, those drop to 76.5 and 78%. So, the card is saying the long input is the thing that matters here. Now, if you open the files tab, you can see four safetensors shards, about 4.9, 5, 4.9, and 3 GB, and the total is about 17.9 GB. That will not fit on my 8 GB card.

[02:06] There is also a GitHub fork nice AI/llama branch drex v1.5. The description says it adds a post/v1/system on endpoint, and it forwards that to a llama server from the drex v1.5 branch of their llama.cpp. And when you do a llama create, it detects the pointer tensors in the GGUF and marks the model as decision instead of completion. So, what I did is clone the drex v1.5 branch of their llama.cpp and build llama server with CUDA for my RTX 4060. That took several minutes of compiling.

[02:45] Then I downloaded their Q8_0 GGUF, which is 9.5 GB, and here’s the honest part. I started it with 26 layers on the GPU, and it ran out of host memory. With 10 layers, it loaded, but my first request took 334 seconds because the laptop was paging. So, that is not usable. What you can do is quantize it yourself. I ran llama.cpp quantize with Q4KM. It took about 135 seconds, and the file came down from 9.5 to 5.6 GB. Now, the

[03:17] whole thing sits on the GPU, and I start the server with embedding on, pooling none, and 16384 context. Okay, first demo. The ticket says, “I was charged twice for the same order. Please refund the extra payment.” Three questions: Which team does the customer ask for a refund, and how urgent? You can see that team is billing at 0.986, refund is 0.992, and urgency lands on urgent at 0.418 with soon at 0.305. So,

[03:51] that one is not confident, and that is fine. A double charge is not an outage. Now, I change the ticket to checkout page returns a 500 error for every customer since 9:40. Team goes to technical at 0.958. Refund drops to 0.006, and urgency is urgent at 0.949. The same three questions, different state, and the numbers move the way you would expect. Next, I give it an email that says your account will be suspended in 24 hours. Click this link and enter

[04:24] your password and OTP. Is it fishing? 0.9994. What should the mail filter do? Block at 0.987. Quarantine at 0.013. And this one answered in under a second. Then a product review. Battery last 2 days. Screen cracked after 1-ft drop. Support took 3 weeks. Sentiment on a 5-point scale comes out as 1.65 with mixed at 0.617. Mention support 0.996, and the main

[04:55] complaint durability at 0.55 and support at 0.45. So, here it is split, and the probabilities show you that, which is the whole point of a model that gives you numbers and not a sentence. For a longer input, I passed the model card text itself, 4,389 tokens. Does the document say the HTTP server requires an authorization header by default? 0.045, which is correct. The card says no header is required. Does it say the

[05:26] model generates free-form text? 0.002. Which base architecture? Qwen at 0.9999. Mind you, this one took 113 seconds on my machine because another process was holding about 5 GB of my video memory. On their side, they report 0.65 seconds median at 8K to 32K tokens on an A10G. So, do not read my number as the model’s number. Now, the claims the 58.08

[05:58] comes from NACE’s own run of the official kit. Jeff 130 town 0 is at 57.296 and bespoke nimble is at 57.29 and the card itself says those three are inside the board’s 0.9 point tie band. On Jeff bench, Drex gets 86.2% and Jeff gets 87.0. The server binds to 127.0001 and has no authentication. So, add that before you expose it and the license is NACE AI open rail M for the model and

[06:29] Apache 2.0 for the Kev code. There’s also a game arena chart on the card. Eight open spiel games, 32 games each against Jeff. It reports 122 wins, 47 draws, and 87 losses, which is 56.8% and the card says Drex beats Jeff on 20 of the 37 benchmarks. So, on 17 it does not. Also, the numbers I showed you came from a four-bit quantization that I made from their eight-bit file. The card says

[06:59] their BF16 and Q80 versions gave the same answers as the Python server. I did not run that comparison, so I cannot tell you my Q4KM matches it everywhere. So, in this video we have seen how we can build the Drex V15 llama server, quantize the G GUF to 5.6 GB, and send it tickets, an email, and a review on an 8GB laptop. If you’re interested, you can go ahead and try this out on your own system as well and let me know how it goes. The model is NACE AI/Drex V155.

[07:32] I’ll see you in another one. Check out the next video. The model page and the GitHub fork are linked in the description. Thanks for watching and I’ll see you in the next one.