Criei meu próprio Jev por US$ 3 (comparado ao original)

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 Built My Own Jev for $3 (vs the Real One) · Canal: Prompt Engineer 48 · 13:58 · Assistir no YouTube

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

Resumo

O vídeo mostra como o apresentador ajustou o fine-tuning de um modelo Qwen 3.5 de 4 bilhões de parâmetros para classificá-lo no estilo do Jev, usando Unsloth e uma GPU alugada por cerca de US$ 3. O modelo foi treinado com aproximadamente 38 mil exemplos e melhorou de 63% para 70,8% no benchmark geral, além de superar Jev no conjunto de perguntas mais parecido com os dados de treinamento. No entanto, Jev teve melhor resultado geral, melhor calibração e desempenho superior em perguntas novas de phishing. A comparação também aborda latência e custo, destacando que a vantagem econômica do modelo próprio depende do volume de decisões e do uso contínuo da GPU.

Pontos-chave

• Jev é apresentado como um modelo rápido de classificação que responde com uma opção e probabilidades para cada alternativa.
• O projeto usa Qwen 3.5 de 4 bilhões de parâmetros, treinado com cerca de 38 mil exemplos reunidos de vários conjuntos de dados.
• O treinamento usa Unsloth, LoRA e uma GPU Nvidia A40 alugada na RunPod.
• O modelo passou de 63% para 87,2% no teste interno após uma época de treinamento; no benchmark geral, obteve 70,8%.
• No conjunto de teste retido, o modelo próprio chegou a 85,8%, acima dos 80,6% de Jev.
• O fine-tuning reduziu o desempenho em phishing: o modelo caiu para 47,7%, enquanto Jev alcançou 64%.
• Jev teve melhor calibração geral, com erro de 0,11 contra 0,21 do modelo próprio.
• O modelo próprio foi mais rápido quando executado localmente no pod, mas Jev foi mais rápido na comparação feita a partir de um laptop pela internet.
• Segundo a estimativa do vídeo, uma GPU ativa continuamente pode tornar o modelo próprio mais barato acima de cerca de 20 mil decisões por hora.
• O modelo treinado e os scripts foram publicados no Hugging Face para que outras pessoas possam usá-los ou treiná-los com dados próprios.

Capítulos

Início	Capítulo	Resumo
00:00	O que é Jev e o plano do projeto	O apresentador compara uma resposta errada do modelo base com a resposta ajustada e explica o objetivo de criar uma alternativa própria ao Jev.
02:37	Preparação da GPU e dos dados	O vídeo mostra a configuração da GPU na RunPod, os scripts de instalação e a preparação de dezenas de milhares de exemplos de treinamento.
04:47	Treinamento e publicação do modelo	O apresentador mede o desempenho inicial, explica LoRA e as configurações de treinamento e relata os resultados após ajustar o modelo.
09:06	Comparação com Jev e benchmark	O modelo é servido por uma API e comparado com Jev em exemplos e em um benchmark que avalia precisão, calibração e latência.
12:20	Latência, custos e conclusão	O vídeo compara a latência pela internet e os custos estimados, e conclui que o modelo próprio pode ser útil para dados privados e casos de uso específicos.

Citações

Essa parte das probabilidades é muito importante, porque seu código pode decidir o que fazer quando o modelo não tem certeza. — 01:03

A velocidade não é o problema. O que temos de corrigir é a precisão. — 05:18

Um modelo pequeno só é tão bom quanto os dados que você fornece. — 11:46

Nosso modelo é open source. É seu. Você pode executá-lo offline e treiná-lo com seus próprios dados. — 13:27

Conceitos e entidades

• Jev (ferramenta): Modelo hospedado da Type Safe apresentado como um classificador rápido que retorna escolhas e probabilidades.
• TypeSafe (empresa): Empresa responsável pelo Jev, usado como referência na comparação.
• Qwen3.5 4B (modelo): Modelo pequeno usado como base para criar o classificador ajustado no estilo do Jev.
• Unsloth (ferramenta): Ferramenta de treinamento usada para ajustar o modelo com menor tempo e uso de memória.
• RunPod (ferramenta): Serviço usado para alugar uma GPU Nvidia A40 para o treinamento.
• NVIDIA A40 (modelo): GPU com 48 GB de VRAM usada na execução do treinamento.
• LoRA (conceito): Método de ajuste que adiciona adaptadores ao modelo, em vez de modificar todos os seus parâmetros.
• vLLM (ferramenta): Ferramenta usada para servir o modelo por meio de uma API compatível com a OpenAI.
• Hugging Face (empresa): Plataforma onde o vídeo publica o modelo ajustado, seu cartão e os resultados.
• Together (empresa): Organização cujo repo é clonado pelo script para preparar o conjunto de dados.

Tradução completa (pt-BR)

00:00 Certo, neste vídeo, vamos criar nosso próprio Jev. Você pode ver aqui que perguntei a um modelo Qwen comum de 4 bilhões: “Um cliente foi cobrado duas vezes. O que o cliente quer?” E ele responde: “Cancelar assinatura, 59,6%”. Está errado. Agora, depois do fine-tuning, para a mesma pergunta, ele responde: “Cobrança duplicada, 99,8%”. E vale lembrar que o treinamento inteiro foi feito em uma GPU alugada por cerca de US$ 3. Depois, vamos compará-lo com o Jev real, da Type Safe, tanto em inteligência quanto em latência. Então,

00:31 vamos fazer isso. Primeiro, o que é o Jev? Se você viu meus vídeos anteriores, já sabe. Mas, para quem é novo por aqui, o Jev é da Type Safe, e eles o chamam de modelo de sistema um. Modelo de sistema um significa pensamento rápido. Ele não escreve um poema para você. Não escreve parágrafos longos. Você fornece um estado, um texto e uma pergunta, e ele devolve uma resposta tipada. Pode ser sim ou não, uma pontuação ou uma escolha de uma lista. E, no blog, eles dizem que ele funciona em cerca de 70 a 500 milissegundos,

01:03 e o preço é de cerca de 4,2 centavos por milhão de tokens de entrada. Os tokens de saída são gratuitos. É muito barato. E, se você olhar a API aqui, ela é bem simples. Você envia um estado e uma pergunta com critérios — cobrança, suporte técnico, vendas — e ela retorna a opção escolhida, além da probabilidade de cada opção. Essa parte das probabilidades é muito importante, porque seu código pode decidir o que fazer quando o modelo não tem certeza. Agora, por que você iria querer ter o seu próprio? Vale lembrar que o Jev é um modelo hospedado. Você chama a API deles. Se quiser executá-lo na sua

01:33 própria GPU, manter seus dados privados ou simplesmente entender como essas coisas são feitas, você precisa da sua própria versão. E é exatamente isso que vamos fazer hoje. Então, aqui está o plano. Vamos pegar um modelo pequeno open source, o Qwen 3.5 4 bilhões, e ensiná-lo a se comportar como o Jev. Você fornece um estado, uma pergunta e opções, e ele responde com apenas uma letra — A, B ou C — além de uma probabilidade para cada opção. Para os dados de treinamento, precisamos de muitas perguntas desse tipo. Existe um pipeline de dados open source feito exatamente para isso, e vou colocar o link na descrição.

02:06 Ele reúne cerca de 38 mil perguntas de conjuntos de dados conhecidos: MultiNLI, que envolve apoiar, contradizer ou ficar neutro; BullQ, que é de sim ou não; e Banking 77, que consiste em escolher uma intenção bancária. Depois, temos classificação de notícias, análise de sentimento e muitas perguntas sobre políticas e redação. E cada pergunta é convertida para o mesmo formato: pergunta, estado, opções e uma letra como resposta. Para o treinamento, vou usar o Unsloth, que é gratuito e open source, em uma GPU do RunPod. Você pode conferir o link na descrição. Depois,

02:37 vamos enviar o modelo para o Hugging Face, para que você também possa usá-lo. E, por fim, vamos colocá-lo frente a frente com o Jev real. Então, etapa um: precisamos de uma GPU. Vou usar o RunPod. Escolho uma Nvidia A40, que tem 48 GB de VRAM e custa cerca de US$ 0,49 por hora. Você também pode usar uma 49D. Qualquer GPU com 24 GB ou mais serve. Vale lembrar que o seu notebook, ou o meu, tem uma 4060 de 8 GB. Um modelo de 4 bilhões tecnicamente cabe nela em formato de 4 bits,

03:09 mas fica bem apertado, e eu levaria de 6 a 8 horas. Para este vídeo, vamos usar a nuvem. Agora estamos dentro do pod. Você pode ver que o Nvidia SMI mostra uma A40, com 46.000 MB, e que todos os arquivos do nosso projeto estão aqui. Vou deixar o link para todos esses arquivos na descrição. Há também um arquivo de configuração, o arquivo .env. Aqui está o modelo: seu token do Hugging Face, o nome do repo para onde o modelo será enviado e a chave da Type Safe para a comparação. Nunca compartilhe suas chaves reais. Só estou mostrando o modelo vazio

03:39 aqui. Etapa dois: criei um script, setup_pod.sh, que faz tudo para você. Vou mostrar o que tem dentro. Ele instala o UVI, um gerenciador rápido de pacotes Python. Depois, cria dois ambientes separados: um para treinamento com Unsloth e outro para servir com vLLM. Por que dois? Porque essas bibliotecas precisam de versões diferentes do PyTorch e, se você as colocar juntas, vão entrar em conflito. Então, mantenha-as separadas; isso evita muita dor de cabeça. A terceira parte clona o repo dev1 da Together e prepara o conjunto de dados. Ele

04:13 baixa o conjunto de dados de origem do Hugging Face e converte cada pergunta para o mesmo formato. Então, vou executar isso agora. Leva um tempinho, alguns minutos. Certo, pronto. Você pode ver que temos 37.842 perguntas de treinamento e 4.568 perguntas de teste. Vamos ver uma delas. O estado, aqui, é um parágrafo sobre contratos de zero hora. A pergunta é: “Preciso trabalhar com um contrato de zero hora?” As opções são A para não e B para sim. E a resposta correta é A. É isso. Esse é um exemplo de treinamento. O modelo vai ver 37 mil deles. Agora, antes de treinar qualquer coisa, eu queria ver quão bom é o

04:47 modelo comum. Então, servi o modelo 3.5 de 4 bilhões sem treinamento usando vLLM e fiz as nossas perguntas. Na primeira, o cliente diz: “Vocês cobraram meu cartão duas vezes em outubro”; depois, dizemos que foram 19,99 em cada cobrança, no mesmo dia. E as opções são cobrança duplicada, cancelar assinatura, cartão recusado ou nenhuma dessas. Você pode ver que o modelo base responde “cancelar assinatura”, com 59,6%. “Cobrança duplicada”, que é a resposta certa, recebe apenas meio por cento. Está completamente errado. Depois, uma pergunta fácil:

05:18 devoluções são permitidas em até 30 dias. A compra foi feita há 12 dias. Ainda está dentro do prazo? Sim, 99,4%. Então, as perguntas fáceis estão bem, mas as mais complicadas e as 10 perguntas não estão. Também executei o benchmark completo no modelo base: 747 perguntas no total, 63% no conjunto de teste separado do treinamento, 63,9% em e-mails de phishing, 60% em encaminhamento de chamados, 70,4%, e 70% em risco de uso de ferramentas. Ele já é rápido — cerca de 113 milissegundos por resposta. Então, velocidade não é o problema. O que precisamos corrigir é a

05:51 precisão. Vamos ver o script de treinamento. Não se preocupe, vou explicar cada parte com palavras simples. Primeiro, vamos carregar os modelos com Unsloth, usando FastModel.from_pretrained para o Qwen 3.5 de 4 bilhões. O Unsloth torna o treinamento cerca de duas vezes mais rápido e usa menos memória. Depois, adicionamos adaptação de baixa ordem, ou LoRA. O que é LoRA? Em vez de mudar todos os 4 bilhões de números dentro do modelo, acoplamos a ele uma pequena camada adaptadora. É como colar notas adesivas em um livro, em vez de reescrever o livro. Rank oito, alpha 16: algo pequeno e leve, que mantém o treinamento barato. Depois, os

06:24 dados. E aqui está o truque importante. Cada exemplo tem um prompt e uma resposta, e a resposta é apenas a letra. Definimos os rótulos para que os modelos aprendam somente com a letra da resposta. A parte da pergunta é mascarada com menos 100, então o modelo não tenta memorizar as perguntas; ele aprende apenas a escolher a letra certa. Depois, antes do treinamento, testamos o modelo base. Após o treinamento, testamos de novo. Assim, sempre temos um número de antes e outro de depois. E, então, as configurações de treinamento: taxa de aprendizado de 5e-5, uma época, tamanho de lote de oito e programação cossenoidal. E aqui está a questão: como obtemos

06:57 probabilidades como as do Jev? Quando o modelo está prestes a responder, ele tem uma pontuação para cada token possível. Basta olhar as pontuações das letras A, B, C e D e convertê-las em porcentagens com softmax. Assim, obtemos a probabilidade completa de cada opção gratuitamente, em uma única etapa. Não é preciso gerar nenhum texto. No final, salvamos o modelo, incorporamos o LoRA a ele e o enviamos para o Hugging Face com uma linha: push_to_hub_merged. Agora, antes de gastar horas, sempre faça um teste rápido. Treinei o modelo com apenas 200 exemplos, só para garantir que nada

07:28 trava. E, sinceramente, isso me salvou, porque da primeira vez ele travou por causa de uma configuração que a nova versão do Transformer removeu. Então, corrigimos e executamos de novo. E dá para ver que funciona de ponta a ponta. Ele carrega, testa, treina, testa de novo e mescla o modelo. Com apenas 200 exemplos, a pontuação não muda muito. Na verdade, caiu um pouquinho, o que é normal. Precisamos dos dados completos. Então, agora vamos ao que interessa: todos os 37.840 exemplos, uma época. Vou iniciar agora. Isso com certeza vai levar algum tempo. Na A40, levou

08:01 cerca de 4 horas e 40 minutos para 7.300 etapas. Enquanto isso, se você olhar para a perda aqui, ela começa em 0,35 e cai para cerca de 0,13. E a linha laranja, que mostra a perda nas perguntas com que o modelo nunca foi treinado, cai para cerca de 0,1. Uma perda menor significa que o modelo está ficando melhor em escolher a letra certa. O pod inteiro, incluindo a configuração, o treinamento e todos os testes, ficou ativo por cerca de 6 horas, então deu cerca de US$ 3 no total. E tudo é totalmente open source no Sloth, para rodar na sua própria GPU. Todos os arquivos são seus. E, quando o treinamento termina, ele testa

08:34 a si mesmo de novo. Antes, 72,6%; depois, 87,2%. É um salto bem grande para uma época. E veja as questões mais difíceis. A questão sobre políticas passou de 53% para 95%, e as questões de roteamento, de 55% para 88%. Depois, ele faz o upload automaticamente para o Hugging Face. Aqui está o modelo no Hugging Face: prompt48/myjeff4b. Dá para ver o cartão do modelo com os resultados de antes e depois, as pontuações por conjunto de dados e o código para copiar e colar novamente. Depois, há o modelo completo mesclado para VLLM e a versão separada do adaptador LoRA, caso você

09:06 queira continuar o treinamento. Então, qualquer pessoa já pode usar isso. Agora, vamos disponibilizá-lo. Estou usando VLLM, que fornece uma API compatível com OpenAI. Assim, qualquer código que se comunique com OpenAI também pode se comunicar com o nosso modelo. Um comando: bash serve.sh. Ele baixa o modelo do Hugging Face e o carrega na GPU. Aí esperamos até aparecer que está saudável e pronto. No RunPod, se expusermos a porta 8000, recebemos uma URL pública e podemos chamá-lo do nosso laptop ou aplicativo. Agora, chegou a hora da verdade. As mesmas perguntas

09:39 que o modelo base errou: a cobrança duplicada. Nosso modelo responde “cobrança duplicada”, com 99,8%. Muito bom. Antes, era meio por cento. Agora, vamos perguntar ao nosso modelo e ao Jeff, lado a lado. Para a cobrança duplicada, Jeff também responde “cobrança duplicada”, com 100%, e nosso modelo, com 99,8%. Veja o tempo. O nosso leva 105 milissegundos, e Jeff, 232 milissegundos. E, vale lembrar, o nosso está rodando na mesma máquina aqui, então não há internet no meio. Já vou mostrar a comparação justa de compensação. Sentimento. Os fones de ouvido

10:10 têm um som fantástico e encaixam perfeitamente. Adorei. O nosso responde “muito positivo”, com 95%, e um pouco de “positivo”. Jeff responde “muito positivo”, com 100%. Pergunta de sim ou não. O museu fecha às segundas-feiras. Ele abre às segundas-feiras? O nosso responde “não”, com 99,9%, e Jeff responde “não”, com 100%. Então, nos exemplos simples, os dois acertam, mas alguns exemplos não provam nada. Precisamos do teste grande. Por isso, criei um script de benchmark com 747 perguntas: 360 do conjunto de teste separado, que o modelo nunca viu durante o treinamento

10:41 e mais três benchmarks criados por outras pessoas para o Jeff: 300 e-mails de phishing, 60 casos de risco de ferramentas. Depois, temos 27 chamados de suporte. Nosso modelo nunca foi treinado com esses dados. Então, é um teste justo fora da distribuição. Para cada pergunta, registramos se a resposta está correta, as probabilidades e o tempo que levou. Certo, aqui estão os resultados. No geral, o modelo base fica em 63%, o nosso modelo em 70,8% e Jeff em 75,5%. Então, melhoramos bastante, mas Jeff ainda está na frente. Mas este é o nosso modelo. E agora veja os resultados um por um. No conjunto de teste separado, o nosso fica em 85,8%, e Jeff, em 80,6%. Então, no tipo de pergunta com que treinamos, na verdade superamos Jeff. Em risco de ferramentas, o nosso fica em 88,3%, e Jeff, em 91,7%. Bem perto. No roteamento de chamados, o nosso fica em 88,9%, e Jeff acerta todos os 27, com 100% de acerto. Phishing: este é interessante. Nosso modelo base ficou em 60%, e o nosso modelo caiu para 47,7%. Jeff fica em 64%, então o fine-tuning piorou o desempenho em phishing. Por quê? Nunca treinamos com perguntas de segurança nem sobre e-mails

11:14 um. No conjunto de teste reservado, o nosso ficou em 85,8 e o Jeff, em 80,6. Então, no tipo de perguntas em que treinamos, na verdade superamos o Jeff. Risco de ferramentas: o nosso ficou em 88,3 e o Jeff, em 91,7. Muito próximos. Roteamento de tickets: o nosso ficou em 88,9, e o Jeff acertou os 27, com 100% de acerto. Phishing — este é interessante. Nosso modelo base ficou em 60%, e nosso modelo caiu para 47,7%. O Jeff ficou em 64, então o fine-tuning piorou o desempenho em phishing. Por quê? Nunca treinamos com nenhum conteúdo de segurança ou e-mail

11:46 e, por isso, o modelo ficou muito bom no tipo de pergunta que usamos e um pouco pior no que era um tipo novo. Então, é muito importante saber que um modelo pequeno só é tão bom quanto os dados que você fornece. Se você quer detectar phishing e ter exemplos de phishing, precisa adicionar exemplos de phishing aos dados de treinamento. Agora, a calibração. Ela mede se, quando o modelo diz que tem 90% de certeza, ele acerta 90% das vezes. Quanto menor, melhor. Nosso erro de calibração é 0,21, e o de Jeff é 0,11. Então, as probabilidades de Jeff são mais confiáveis. Vale lembrar que treinei Jeff com um método especial, feito especificamente para isso, enquanto nós fizemos

12:20 apenas fine-tuning, então isso é esperado. E, quanto à latência, vale lembrar que esse benchmark foi executado no pod, então nosso modelo está no localhost, enquanto Jeff acessa pela internet. Isso não é justo com Jeff, então rodei o teste de novo em um laptop, com os dois acessando pela internet. No pod, o nosso levou 118 milissegundos, e Jeff, 269; mas, no meu laptop, o nosso levou 461, e Jeff, 357. Então, pela internet, Jeff é, na verdade, mais rápido. Na maior parte do tempo, o que faz diferença é o proxy do RunPod no meio. O modelo em si leva cerca de 100 milissegundos, então, se você o executar perto do seu aplicativo, no mesmo servidor, ele é muito rápido. E o custo: Jeff cobra 4,2 centavos por

12:54 milhão de tokens de entrada, o que deu cerca de 2,3 centavos por mil decisões. O nosso, com uma GPU de 49 centavos, saiu por cerca de 0,4 centavo por decisão. Mas, se a GPU ficar ociosa, você ainda paga 49 centavos por hora. Então, a regra simples é: se você toma mais de cerca de 20.000 decisões por hora em um pod ligado 24 horas por dia, 7 dias por semana, seu próprio modelo custa menos. Abaixo disso, Jeff sai mais barato, ou você pode usar uma opção sem servidor. Então, qual é o veredito? Por cerca de US$ 3, levamos o Gwen de 63% para 70% e, no nosso próprio tipo de pergunta,

13:27 chegamos a superar Jeff, mas, no geral, Jeff ainda está na frente. Ele é mais bem calibrado e lida muito melhor com tipos de pergunta totalmente novos, como phishing. Jeff foi treinado com um método especial para produzir probabilidades calibradas e é um serviço de produção. Assim, você não precisa gerenciar nenhuma GPU. Nosso modelo é open source. Ele é seu. Você pode executá-lo offline e treiná-lo com seus próprios dados. Se você o treinar com as perguntas da sua empresa, com certeza terá resultados melhores no seu caso de uso. Então, neste vídeo, vimos como podemos criar nosso próprio Jeff, um classificador rápido de sistema um

13:58 com Unsloth em uma GPU alugada, enviá-lo para o Hugging Face e compará-lo com o Jeff de verdade. O modelo e todos os scripts estão linkados na descrição. Vá em frente e experimente. Me conte como foi. O conjunto de dados e o link da ferramenta estão na descrição. Vejo vocês no próximo vídeo.

Transcrição original

[00:00] All right, in this video, we will build our own Jev. So, you can see here I asked a plain Qwen 4 billion model, “A customer got charged twice. What does the customer want?” And it says, “Cancel subscription, 59.6%.” That’s wrong. Now, after fine-tuning the same question, “Duplicate charge, 99.8%.” And mind you, the whole thing was trained on a rented GPU for about $3, and then we’re going to compare it against the real Jev from Type Safe uh both in intelligence and latency. So,

[00:31] let’s go ahead and do this. So, first, what is Jev? If you have seen my earlier videos, you already know this. But for those who are new, Jev is from Type Safe, and they call it a system one model. System one model means fast thinking. It doesn’t write you a poem. It does not write long paragraphs. You give it a piece of state, some text, and a question, and it gives you back a type answer. That can be a yes or no, a score, or a pick from a list. And you can see on the blog, they say it run uh it runs in about 70 to 500 milliseconds,

[01:03] and the price is about 4.2 cents per million input tokens. And the output tokens are free. That’s really cheap. And if you look at the API here, it’s very simple. You send a state, a question with criteria, billing, technical, sales, and it returns the choice plus the probability for each option. That probability part is really important because your code can decide what to do when the model is not sure. Now, why would you want your own? Mind you that Jev is a hosted model. You call their API. If you want to run it on your

[01:33] own GPU, keep your data private, or just understand how these things are made, you need your own version. And this is exactly what we are going to do today. So, here’s the plan. We take a small open model, Qwen 3.5 4 billion, and we teach it to behave like Jev. You give it state, a question, and options, and it answers you just one letter, A, B, C, plus a probability for each option. For the training data, we need lots of questions of this type. There is an open data set pipeline for exactly this, and I will put the link in the description.

[02:06] It pulls around 38,000 questions from well-known data sets, multi NLI, which is support, contradict, or neutral. BullQ, which is a yes or no. Banking 77, which is picking a banking intent. Then we have news classification, sentiment, and there’s a lot of policy and writing questions. And every question is converted into the same format, which is question, state, options, and one letter as the answer. And for training, I’m going to use Unsloth, which is free and open source, on a RunPod GPU. You can check the link in the description. Then

[02:37] we push the model to Hugging Face, so that you can go ahead and use this as well. And finally, we put it head-to-head against the real Jeff. So, step one, we need a GPU. I’m going to use RunPod. I pick an Nvidia A40, which has 48 GB of VRAM, and it costs about $0.49 an hour. You can use 49D as well. Anything with 24 GB or more works. Now, mind you, your own laptop, or my own laptop, has an 8 GB 4060. A 4 billion model can technically fit on a in 4-bit

[03:09] format on that, but it’s really tight, and it’d take me about 6 to 8 hours. For this video, we go ahead with the cloud. So, we are inside the pod now. You can see Nvidia SMI says A40, 46,000 MB, and there are all the files in our project. I will leave the link to all these files in the description. And there’s one setting file, the .env file. Here is the template, your Hugging Face token, the repo name where the model will be uploaded, and the type safe key for the comparison. Never share your real keys. I’m only showing the empty template

[03:39] here. Step two, I’ve made one script, setup_pod.sh, and that does everything for you. Let me show you what’s inside. It installs UVI, which is a fast Python package manager. Then it creates two separate environments, one for training with Unsloth and for serving another for serving with vLLM. Now, why two? Because they’re these libraries want different versions of PyTorch, and if you put them together, they will fight with each other. So, keep them separate, it saves you a lot of headache. And then the third part, it clones the dev1 repo from Together and builds the dataset. It

[04:13] downloads the source dataset from Hugging Face and converts each question into the same format. So, I’m going to go ahead and run this. This does need some time, a few minutes. All right, done. You can see 37,842 training questions and 4,568 test questions. Let’s look at one of them. So, here the state is a paragraph about zero-hour contracts. The question is, do I have to work on zero-hour contract? And the options are A for no, B for yes. And the correct answer is A. That’s it. That’s one training example. The model will see 37,000 of these. Now, before we train anything, I wanted to see how good the

[04:47] plain model is. So, I served the untrained 3.5 4 billion with vLLM and asked for our questions. First one, the customer says, you charged my card twice for October uh then we say 19.99 both on the same day. And the options are duplicate charge, cancel subscription, card decline, or none. And you can see the base model says cancel subscription 59.6% duplicate charge, which is the right answer, gets only half a percent. That’s completely wrong. Then an easy

[05:18] one, returns are allowed within 30 days. The purchase was 12 days ago. Is it within the window? Yes, 99.4% so easy questions are fine, tricky and 10 questions are not. And I also ran the full benchmark on the base model 747 questions overall 63% on the held-out test set 63.9 fishing email 60, ticket routing 70.4, and tool risk 70. It’s already uh and it’s already fast about 113 milliseconds per answer. So, speed is not the problem. Accuracy is what we

[05:51] have to fix. So, let’s look at the training script, and don’t worry, I’ll explain every part in simple words. First, we’ll load the models with Unsloth model or fast model {dot} from pre-trained Gwen 3.54 billion. Unsloth makes the training around two times faster and uses less memory. Then, we add low-rank adaptation or LoRA. What is LoRA? Instead of changing all 4 billion numbers inside the model, we attach a small adapter layer and those. It’s like adding sticky notes to a book instead of rewriting the book. Rank eight, alpha 16, small and light, which keeps training cheap. Then, the

[06:24] data. And here’s the important trick. Each example has a prompt and a completion where the completion is just the letter. We set the labels, so the models only learn from the answer letter. The question part is masked with minus 100, so the model is not trying to memorize the questions, and it only learns to pick the right letter. Then, before training, we test the base model. After training, uh we test again. So, we always have a before and after number. And then, the training settings. Learning rate is 5e-5, one epoch, batch size is eight, cosine schedule. And here’s the part. How do we get

[06:57] probabilities like Jeff? When the model is about to answer, it has a score for every possible token. We just look at the scores for the letters A, B, C, D and turn them into percentage with softmax. So, we get the full probability for every option for free in one single step. No need to generate any text. And at the end, we save the model, merge the LoRA into it, and push it to Hugging Face with one line, push to hub merge. Now, before spending hours, always do a smoke test. I trained it on only 200 examples just to make sure that nothing

[07:28] crashes. And honestly, this saved me because the first time it crashed on a setting that the new version of Transformer removed. So, fix, run again. And you can see uh it works end to end. It loads, tests, trains, tests again, and merges the model. With only 200 examples, score doesn’t move much. It actually went a little bit down, which is normal. We need the full data. So, now the real deal, all 37,840 examples, one epoch. I’m going to go ahead and start it. This will definitely take some time. On the A40, it took

[08:01] about 4 hours 40 minutes for 7,300 steps. In the meantime, if you look at the loss here, it starts showing 0.35 and goes down to around 0.13. And the orange line, the loss on question is never trained on, goes down to about 0.1. Lower loss means the model is getting better at picking the right letter. The whole pod, including setup, training, and all the test was up for about 6 hours, so about $3 in total. And And everything is fully open on Sloth on your own GPU. You own every file. And when training finishes, it tests again

[08:34] itself. Before, uh 72.6% after 87.2%. That’s a really big jump for one epoch. And look at the tricky ones. The policy question went from 53 to 95% and the routing questions from 55 to 88. And then it uploads to Hugging Face automatically. So, here is the model on Hugging Face, prompt48 /myjeff4b. You can see the model card with the after and before results, the per data scores, and the copy-paste code again. Then the full merged model from VLLM and the separate LoRA adapter version if you

[09:06] want to train further. So, anyone can go ahead and use this right now. Now, let’s serve it. I’m using VLLM, which gives you an OpenAI compatible API. So, any code that talks to OpenAI can talk to our model as well. One command, bash serve.sh, it downloads the model from Hugging Face and loads it on the GPU. And we say and we wait until it says healthy, and then we are ready. And on RunPod, if we expose port 8000, you get a public URL, and you can go ahead and call it from your laptop or your app. Now, the moment of truth. Same questions

[09:39] that the base model got wrong, the double charge, and our model says duplicate charge 99.8%. That’s really good. Earlier, it was half a percent. Now let’s ask our model and type save Jeff side side by side. For the double charge, Jeff also says duplicate charge 100% and our model says 99.8. Look at the time. Ours is 105 milliseconds and Jeff is 232 milliseconds. And mind you, ours is running on the same machine here as so no internet in between. I’ll show you the fair compensation comparison in a moment. Sentiment. The headphones

[10:10] sound fantastic and fit perfectly. I love them. Ours says very positive 95% with a little bit of positive. Jeff says very positive 100%. Yes no question. The museum is closed on Monday. Is it open on Monday? Ours says no 99.9% and Jeff says 100% no. So on the simple examples, both get it right, but a few examples prove nothing. We need the big test. So I went ahead and made a benchmark script with 747 questions, 360 from the held out test set which the model never saw

[10:41] it training. Then three benchmark made by other people for Jeff, 300 fishing emails, 60 tool risk cases. Then we have 27 support tickets. Our model was never trained on those. So it’s a fair out of distribution test. Now for every question, we record is it correct, the probabilities, and the time it took. All right, here are the results. Overall, the base model is 63% our model is 70.8% and Jeff is 75.5%. So we improved a lot, but Jeff is still ahead. But this is our model. And now look at look at it one by

[11:14] one. On the held out test set, ours is 85.8 and Jeff is 80.6. So on the type of questions we trained on, we actually beat Jeff. Tool risk, ours is 88.3 and Jeff is 91.7. Really close. Ticket routing, ours is 88.9 and Jeff gets all 27 right and it’s 100% correct. Fishing, this is interesting one. Our base model was 60% and our model went down to 47.7%. Jeff is 64, so fine-tuning made it worse on fishing. Why? We never trained on any security or email

[11:46] questions, so the model got really good at our sort of questions and a bit worse at what was the new type. So, it’s really important to know a small model is only as good as the data you give. If you want fishing detection and fishing examples, uh you have to add fishing examples to the training data. Now, calibration. This measures when the model says 90% sure, it’s right 90% age of the time. Lower is better. Our calibration error is 0.21 and Jeff is 0.11. So, Jeff’s probabilities are more honest. Mind you, I trained Jeff with a special method just for this and we did

[12:20] just fine-tuning, so this is expected. And latency, mind you, this benchmark ran on the pod, so our model is on localhost and Jeff goes over the internet. That’s not fair for Jeff, so I ran it again from a laptop where both goes over the internet. On the pod, ours was 118 milliseconds and Jeff was 269, but from my laptop, ours was 461 and Jeff was 357. So, over the internet, Jeff is actually faster. Most of the time, it’s the run pod proxy in between. The model itself takes around 100 milliseconds, so if you run it close to your app on the same server, it’s really fast. And cost, Jeff is 4.2 cents per

[12:54] million input token, which came to about 2.3 cents per thousand decisions. Ours on a 49 cent and our GPU came to around 0.4 cents per but if the GPU sits idle, you’ll still pay 49 cents every hour. So, the simple rule, if you make more than around 20,000 decisions an hour on a 24/7 pod, your own model is cheaper. Below that, Jeff is cheaper or you can go serverless. So, what’s the verdict? For about $3, we took Gwen from 63% to 70% and on our own type of questions it

[13:27] even beat Jeff, but overall Jeff is still ahead. It’s better calibrated and handles brand new questions types like fishing much better. Jeff is trained on a special method for calibrated probabilities and it’s a production service. So it don’t manage any GPU. Our model is open. It’s yours. You can run it offline and train it on your own data. If you train it on your company’s question, you definitely get better results on your use case. So in this video we have seen how we can build our own Jeff, a fast system one classifier

[13:58] with Unsloth on a rented GPU, push it to Hugging Face and compare it with the real Jeff. The model and all the scripts are linked in the description. Go ahead and try this out. Let me know how it goes. Data set and tool link are in the description. I will see you in this next one.