Nanbeige 4.3-33B é incrível (no papel): testei em uma GPU alugada

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: Nanbeige4.3-33B Is CRAZY Good (On Paper): I Tested It on a Rented GPU · Canal: Prompt Engineer 48 · 09:57 · Assistir no YouTube

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

Resumo

O vídeo apresenta o Nanbeige 4.3-33B, um modelo open source de 33 bilhões de parâmetros cujos benchmarks publicados mostram resultados fortes em tarefas agentic. O apresentador aluga uma GPU de 96 GB, testa a execução do modelo e observa limites de memória para o context window, além de lentidão e excesso de raciocínio em perguntas simples. Em testes práticos, o modelo usa ferramentas corretamente, corrige bugs em um pequeno programa, cria um jogo funcional e recupera informações em até cerca de 95 mil tokens. A conclusão é que ele é pouco adequado para uma conversa individual em uma GPU, mas pode ser interessante para processamento em lote e várias tarefas paralelas.

Pontos-chave

O Nanbeige 4.3-33B tem 33 bilhões de parâmetros e exige cerca de 62 GB apenas para carregar os pesos em BFloat16.
Os benchmarks citados são resultados divulgados pelo próprio laboratório, sem reprodução independente pelo apresentador.
Uma GPU de 96 GB permitiu executar o modelo, mas não alcançar o context window anunciado de 512 mil tokens; o teste foi limitado a cerca de 95 mil.
Em perguntas simples, o modelo pode gastar muitos tokens pensando sem produzir uma resposta, mas o raciocínio pode ser desativado.
O modelo coordenou chamadas paralelas a ferramentas de clima e adiou o uso da calculadora até receber os resultados necessários.
Em um teste pequeno de programação, corrigiu três bugs e os testes passaram; também gerou um jogo Snake funcional em um arquivo HTML.
O teste de recuperação de passcode teve três acertos, até 94.867 tokens, mas não representa uma avaliação abrangente de long context.
O processamento paralelo aumentou a vazão total e, segundo a estimativa do apresentador, pode tornar o custo por token interessante para lotes e pipelines.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do modelo e dos benchmarks	O vídeo apresenta as alegações de desempenho do Nanbeige 4.3-33B, sua licença e as ressalvas sobre os benchmarks divulgados pelo laboratório.
02:35	Aluguel da GPU e configuração	O apresentador explica por que o modelo não cabe na GPU do laptop e descreve a escolha e a configuração de uma GPU alugada.
04:09	Testes de raciocínio, ferramentas e programação	O modelo é avaliado em perguntas simples, matemática, uma premissa falsa, tool calling e correção de bugs em um pequeno programa.
07:22	Long context e processamento paralelo	O apresentador testa a recuperação de informações em contextos longos e mede a vazão com várias solicitações simultâneas.
09:26	Recomendações e conclusão	O vídeo resume as configurações sugeridas, o custo do teste e os casos de uso mais promissores para o modelo.

Citações

A licença é Apache 2.0. Agora, o porém: são 33 bilhões de parâmetros. — 00:00

Três minutos pensando numa pergunta sobre hash map. — 04:40

Isso mostra que o loop funciona. Ele lê, age e verifica. — 06:14

Mesma placa, mesmo modelo, 24 vezes mais tokens de saída. — 07:52

Use o raciocínio quando ele realmente fizer diferença. — 09:26

Conceitos e entidades

Nanbeige 4.3-33B (modelo): Modelo de 33 bilhões de parâmetros testado no vídeo, com licença Apache 2.0 e foco em tarefas agentic.
Nanbeige (empresa): Laboratório descrito no vídeo como parte da plataforma chinesa de recrutamento Boss Zhipin.
Boss Zhipin (empresa): Plataforma chinesa de recrutamento associada ao laboratório Nanbeige.
Terminal-Bench 2.1 (conceito): Benchmark em que um agent precisa realizar tarefas dentro de uma linha de comando.
Qwen (modelo): Família de modelos usada como comparação nos resultados de benchmark apresentados.
vLLM (ferramenta): Ferramenta usada para servir o modelo na GPU alugada.
RunPod (empresa): Serviço usado pelo apresentador para alugar uma GPU e executar o modelo.
RTX Pro 6000 (ferramenta): GPU de 96 GB escolhida para executar o modelo durante os testes.
BFloat16 (conceito): Formato de precisão dos pesos mencionado no cálculo de memória necessário para carregar o modelo.
KV cache (conceito): Memória usada pelo modelo para manter informações da conversa, cujo consumo limita o context window disponível.

Tradução completa (pt-BR)

00:00 No Terminal Bench 2.1, um benchmark em que um agent de IA precisa realmente trabalhar dentro de uma linha de comando, este novo modelo open source marca 80,9. O modelo Qwen com o qual ele é comparado marca 73, e a licença é Apache 2.0. Agora, o porém: esse modelo tem 33 bilhões de parâmetros. Só para carregá-lo são necessários 62 GB. A placa de vídeo do meu laptop tem oito. Então, neste momento, as pessoas que conseguem usar agents tão bons são, em sua maioria, aquelas que os alugam por token. Este é o Nanbeige 4.3 33B. Então, aluguei uma GPU, carreguei o modelo e tentei quebrá-lo. Vou mostrar o que funcionou, o que não funcionou e uma coisa que o model

00:31 card não conta para você. >> [música] >> Aqui está o model card. A Nanbeige é um laboratório dentro da Boss Zhipin, uma plataforma chinesa de recrutamento, e este é o principal modelo deles, criado para ser um professor. A ideia é treinar um modelo grande e forte e, depois, usá-lo para destilar modelos menores. Eles já disseram que um student 3B está a caminho. Por que você deveria se importar com um modelo professor, mesmo que nunca vá executá-lo? Porque muitos dos modelos pequenos que você pode executar em casa são treinados a partir de modelos grandes. Um student 3B desse professor é pequeno o bastante para caber numa placa de vídeo comum. Então, mesmo que

01:01 o 33B esteja fora do seu alcance, talvez o que ele ensina não esteja. Os arquivos contam mais do que o marketing. É uma arquitetura Llama padrão, com 52 camadas, oito cabeças de key-value, pesos Bfloat16 e uma context window declarada de 512.000 tokens. Licença Apache 2.0. Então, não há termos de uso estranhos para ler. Agora, os benchmarks, e quero deixar claro que todos os números desta tabela são do próprio laboratório. Eu não os executei. Eles dizem que todos os modelos foram avaliados com o maior nível de esforço de raciocínio e que este modelo foi executado com o raciocínio preservado ativado.

01:32 Nas linhas de programação agentic, ele lidera no Terminal Bench 2.1: 80,9 contra 73 do Qwen. Deep SWE: 65,5 contra 42,5. É uma diferença grande, se ela se mantiver fora da configuração deles. O segundo bloco é o que eles chamam de tarefas de colaboração agentic no estilo de escritório. Automation Bench: 54,2 contra 38,3; Job Bench: 44,8 contra 34,5; e YC Bench, em que um modelo administra uma startup simulada: ele termina com cerca de 1,02 milhão de dólares, contra 641.000 do Qwen. Mas leia a tabela inteira. No Stribench Pro, perde

02:03 por 60,3 a 61,7. No GDP Val, perde. E no GPQA Diamond, o Gemma vence por 91,3 a 89,5. É forte, mas não imbatível, e gosto que o model card mostre também as derrotas. Mais uma coisa antes de você confiar em qualquer um desses resultados: leia as notas de rodapé. O model card diz que todos os modelos usam o mesmo harness em cada benchmark, o que é justo. Mas o Terminal Bench usa um harness, o Deep SWE usa outro e o NL2Repo é executado pelo Claude Code. O laboratório escolheu essas configurações, e ainda não vi uma reprodução independente. Por isso quis testá-lo por conta própria. Então, por que não simplesmente executá-lo aqui? Deixe-me mostrar: este é meu laptop, com uma RTX 4060 e 8 GB de

02:35 memória de vídeo. Só os pesos, em precisão de 16 bits, ocupam cerca de 62 GB. Nem chega perto, então a solução é alugar uma GPU. A regra que uso é: pesos mais uma margem para o cache KV, que é a memória que o modelo usa para se lembrar da conversa. O model card não informa um mínimo, apenas mostra um exemplo de execução com quatro GPUs. Então, para simplificar, eu queria uma placa grande: 96 GB. Aqui estão os dados de capacidade ao vivo da API do Runpod, não fui eu que os digitei. A A100 tem 80 GB, o que deixa cerca de 18 GB para o cache: fica apertado. A RTX Pro 6000 tem 96 GB e era a que aparecia com bastante disponibilidade. Foi essa que escolhi. Agora, sobre o preço,

03:06 para ser honesto, o catálogo mostrava US$ 1,69 por hora. Quando criei o pod, a resposta indicou US$ 2,49. Isso é quase 50% a mais do que o valor anunciado. Mantive a escolha porque havia disponibilidade, mas confira a resposta da criação, não o preço da lista. As configurações são simples: uma imagem PyTorch, 220 GB de disco para caberem os pesos, a porta 22 para SSH e a porta 8000 para a API. Conectei, executei nvidia-smi e lá estava: 97.887 MB. A configuração foi rápida. Instalei o vLLM versão 0.32 e baixei 62 GB de

03:38 pesos em menos de 2 minutos. Depois, tentei executá-lo com uma context window de 131.000 tokens, e ele travou. A parte interessante é o erro. Nesse comprimento, o cache precisa de 26 GB e, depois de carregar os pesos, eu só tinha 21,4. O vLLM estimou que o máximo que essa placa consegue comportar é cerca de 108.000 tokens. Portanto, não dá para usar a context window de 512K em uma única placa, não em BFloat16. E eu poderia ter previsto esse travamento com uma calculadora. Para cada token, o cache armazena uma key e um value para 52 camadas, oito cabeças e 128 números cada,

04:09 dois bytes por número. Isso dá cerca de 208 kilobytes por token. Multiplicado por 131.000 tokens, são 26 GB. Em 512K, passa de 100. Então, reiniciei com 106.000. Funcionou, e o cache comporta 108.000 tokens: o suficiente, por pouco. Tudo daqui em diante é executado nessa configuração. Lembre-se do número 95.000. Vamos chegar a ele. Primeiro, um teste de velocidade. Pedi uma explicação de 300 palavras sobre como uma hash map lida com colisões. Simples. Ele gerou 21,8 tokens por segundo, o que é normal para um modelo denso de 33B, já que cada token lê todos os 62 GB. Mas veja o que

04:40 aconteceu. Ele usou os 4.000 tokens do meu limite só para pensar. Nunca escreveu a resposta. Três minutos pensando numa pergunta sobre hash maps. Este é um modelo de raciocínio por padrão. E, em perguntas fáceis, ele pensa demais. Dá para desativar isso, e fiz isso mais tarde. Segundo teste: uma questão de matemática. Quantos pares ordenados de números de 1 a 100 têm a² mais b² divisível por 7? Ele respondeu 196 em pouco menos de 27 segundos. Conferi por conta própria. Os quadrados módulo 7 só podem ser 0, 1, 2 ou 4. Então, a soma só é 0 quando ambos são múltiplos de 7. Há 14 múltiplos. 14 × 14 = 196. Correto?

05:12 E foram apenas 592 tokens. Então, pensar nem sempre demora. Terceiro: uma pegadinha. Perguntei como usar a função quantum sort do módulo create do Python para ordenar. Essa função não existe, e uma ordenação em tempo constante é impossível de qualquer forma. Você teria que ler a lista. Ele percebeu as duas coisas. Disse que não existe quantum sort no iterate, mostrou uma verificação de uma linha que comprova isso e me deu a função sorted normal. Mais uma coisa que ele acertou: disse que o tempo constante só funciona se a lista já estiver ordenada. É esse tipo de honestidade que eu quero. A seguir, tool calling. Isso importa porque agents dependem disso para funcionar. Dei a ele duas ferramentas, uma de consulta de clima

05:43 e uma calculadora, e pedi o clima de Tóquio e Paris e, depois, a diferença multiplicada por três. Ele não acionou tudo de uma vez. Chamou a ferramenta de clima para Tóquio e Paris em paralelo e esperou para usar a calculadora, porque ela precisa dos resultados primeiro. Esse raciocínio sobre dependências está correto. Mas vou ser franco: só testei esse primeiro turno, não um ciclo completo. Então, para a tarefa agentic de verdade, criei um pequeno arquivo Python com três bugs, um arquivo de teste e dei a ele um shell. Os bugs eram um desconto dividido por 10 em vez de 100, um total que ignorava a quantidade e a escolha do item mais vendido pelo preço unitário. Ele executou quatro etapas: leu os arquivos, reescreveu-os, percebeu que o Pytest não estava

06:14 instalado e executou o teste de outra forma; depois, resumiu as três correções. Executei o Pytest por conta própria depois: três testes passaram. Agora, as limitações, para ser honesto: isto é um exemplo simples. Três bugs num arquivo pequeno não chegam nem perto do Terminal Bench. Mostra que o ciclo funciona. Ele lê, age e verifica. Não prova o resultado de 80,9. Depois, o teste de estresse: pedi um jogo completo de snake em um único arquivo HTML, com pontuação, velocidade aumentando a cada cinco comidas, recorde salvo no navegador e reinício com a barra de espaço. Isso levou 22 minutos e 27.969 tokens, dos quais 17.000 foram usados para pensar. Mas, quando terminou, abri o arquivo e o jogo simplesmente funcionou, sem

06:44 erros no console. Agora, veja: este é o jogo que ele escreveu, e as teclas foram pressionadas por um script meu para que eu pudesse filmar. O código tem a linha de local storage para o recorde e o aumento de velocidade a cada cinco comidas. Não testei todas as regras, mas ele funciona. Está bem acabado e foi feito de uma só vez.

07:22 Em seguida, contexto longo. Escondi uma senha em meio a um monte de texto de preenchimento e pedi que ele a recuperasse com 22.000 tokens. Ele a encontrou com 71.000, encontrou com 94.867 tokens. Essa é a terceira vez em três tentativas, e a resposta levou 44 segundos no caso mais longo. Mas um teste de agulha no palheiro é o teste de contexto longo mais fácil que existe, e só pude chegar a 95.000, não a 512.000. Então, isso mostra que ele se sai bem até esse ponto, nada além disso. Agora, a parte que mudou minha opinião: até aqui, tudo foi com um usuário por vez, a 22 tokens por segundo. Então enviei

07:52 oito solicitações de uma vez, com o thinking desligado: 157 tokens por segundo no total. Depois, 32 solicitações de uma vez: 534 tokens por segundo, com a mesma placa e o mesmo modelo; 24 vezes mais saída, porque os pesos são lidos uma vez e compartilhados entre todas elas. Faça as contas comigo. 534 tokens por segundo dão cerca de 1,9 milhão de tokens por hora. A US$ 2,49, isso dá aproximadamente US$ 1,30 por milhão de tokens de saída. Essa é minha estimativa aproximada para histórias curtas, não para trabalho com agents, mas ela mostra para quem este modelo serve. Então, aqui vai meu veredito. Se você quer uma única janela de chat privada em uma única GPU, este modelo é lento e pensa demais. 22 tokens por

08:24 segundo não é nada agradável. Se você quer um mecanismo auto-hospedado para processamento em lote, agents ou um pipeline, ele é muito interessante. Um guia rápido para decidir: se você tem uma placa de jogos comum, com 24 GB ou menos, não tente usar o modelo completo; espere pelo modelo student de 3B ou teste por conta própria as versões quantizadas pela comunidade. Se você tem uma placa grande de servidor, ele roda, mas espere cerca de 20 tokens por segundo por usuário. E, se você tem muito trabalho paralelo, como um lote de tickets ou agents rodando lado a lado, é aí que o preço por token fica interessante. O que eu não testei: não reproduzi nenhum dos benchmarks deles, não experimentei as 36 versões quantizadas pela comunidade

08:56 listadas na página e não passei de 95 mil tokens. Se você testar as versões quantizadas em uma placa menor, conte nos comentários o que descobrir. O que eu provei: ele roda em uma placa de 196 GB, segue tool calls, corrige bugs reais, escreveu um jogo funcional e identificou uma premissa falsa. Para um modelo com licença Apache, isso é um resultado concreto. Se quiser executá-lo por conta própria, aqui estão as recomendações da placa: temperatura 1.0 para trabalho com agents e ferramentas, 0.6 para raciocínio e chat; ative preserve thinking para ciclos de agent com várias interações e desative para chats normais. Peça o formato de tool call em XML e

09:26 sirva-o com o parser de raciocínio do Qwen 3 e o parser de ferramentas do Qwen 3 quarter, que foi exatamente o que fiz. Uma lição dos meus próprios testes: uma pergunta curta como essa, sobre hash map, não precisa de thinking. A placa tem uma opção para ativar o thinking e, nos testes em lote, eu a desativei. Uma história de 400 palavras custou então cerca de 600 tokens, não milhares. Use o thinking onde ele realmente vale a pena. O custo foi de cerca de 50 minutos de uso do pod a US$ 2,49 por hora, ou seja, cerca de US$ 2,10, e encerrei o pod. Aqui está a lista de pods: vazia. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o

09:57 link está na descrição. Então, o que devo testar nele em seguida? Uma versão quantizada em uma placa pequena ou um benchmark de programação de verdade? Conte nos comentários. Obrigado por assistir, e até o próximo vídeo.

Transcrição original

[00:00] On Terminal Bench 2.1, a benchmark where an AI agent has to actually work inside a command line, this new open model scores 80.9. The Qwen model it’s compared against scores 73, and the license is Apache 2.0. Now, the catch. This thing is 33 billion parameters. Just loading it takes 62 GB. My laptop’s graphics card has eight. So, right now the people who get to use agents this good are mostly the people renting them by the token. This is Nanbei Ge 4.3 33B. So, I rented a GPU, loaded it, and tried to break it. I’ll show you what worked, what didn’t, and one thing the model

[00:31] card does not tell you. >> [music] >> Here’s the model card. Nanbei Ge is a lab inside Boss Zhipin, a Chinese recruiting platform, and this is their flagship built as a teacher. The idea is you train one big strong model, then use it to distill smaller ones. They’ve already said a 3B student is coming. Why should you care about a teacher model, even if you never run it? Because many of the small models you can run at home are trained from big ones. A 3B student of this teacher is small enough to fit on a normal graphics card. So, even if

[01:01] 33B is out of reach, what it teaches might not be. The files tell you more than the marketing. It’s a plain Llama architecture, 52 layers, eight key value heads, Bfloat16 weights, and a claimed context window of 512,000 tokens. License Apache 2.0. So, no weird usage terms to read. Now, the benchmarks, and I want to be clear every number on this table is the lab’s own. I did not run these. They say all models were evaluated at their highest thinking effort, and this one ran with preserved thinking switched on.

[01:32] On the agentic coding rows, it leads Terminal Bench 2.1 80.9 against Qwen’s 73. Deep SWE 65.5 against 42.5. That’s a big gap if it holds up outside their setup. The second block is what they call agentic co-work office-style tasks. Automation Bench 54.2 against 38.3, Job Bench 44.8 against 34.5, and YC Bench, where a model runs a simulated startup, it ends with about 1.02 million dollars against 641,000 for QN. But, read the whole table. On Stribench Pro, it loses

[02:03] 60.3 to 61.7. On GDP Val, it loses. And on GPQA Diamond, Gemma beats it 91.3 to 89.5. It’s strong, not unbeatable, and I like that the card shows its own losses. One more thing before you trust any of this, read the footnotes. The card says every model gets the same harness on each benchmark, which is fair. But, terminal bench uses one harness, deep sway in another, and NL2 repo runs through cloud code. The lab picked those setups, and I haven’t seen an independent reproduction yet. That’s why I wanted to test it myself. So, why not just run it here? Let me show you, this is my laptop, an RTX 4060 with 8 GB of

[02:35] video memory. The weights alone in 16-bit precision are about 62 GB. It isn’t close, so it’s a rented GPU. The rule I use is weights plus headroom for the KV cache, which is the memory the model uses to remember your conversation. The model card doesn’t give a minimum, only a serve example with four GPUs. So, I wanted one big card to keep it simple, 96 GB. Here’s the live capacity data from Runpod’s API, not typed by me. The A100 has 80 GB, which leaves roughly 18 for the cache, tight. The RTX Pro 6000 has 96, and it was the one showing high stock. That’s the one I picked. Now, price

[03:06] honesty, the catalog said $1.69 an hour. When I created the pod, the response said $2.49. That’s almost 50% more than the quote. I kept it because the stock was there, but check the create response, not the list price. Settings are simple, a PyTorch image, 220 GB of disk so the weights fit, port 22 for SSH, and port 8000 for the API. I connected, ran nvidia-smi, and there it is, 97,887 MB. Setup was fast. I installed vLLM version 0.32, and downloaded 62 GB of

[03:38] weights in under 2 minutes. Then, I tried to serve it at 131,000 tokens of context, and it crashed. The error is the interesting part. At that length, the cache needs 26 GB, and after loading the weights, I only had 21.4. vLLM estimated the most this card can hold is about 108,000 tokens. So, the 512K context not on one card, not in BFloat16. And I could have predicted that crash with a calculator. For every token, the cache stores a key and a value for 52 layers, eight heads, 128 numbers each,

[04:09] two bytes per number. That’s about 208 kilobytes per token. Times 131,000 tokens is 26 GB bytes. At 512K, it’s over 100. So, I relaunched at 106,000. It came up and the cache holds 108,000 tokens, just enough. Everything after this runs on that setup. Remember the number 95,000. We’re going to hit it. First test speed. I asked it for a 300-word explanation of how a hash map handles collisions. Simple. It generated 21.8 tokens per second, which is normal for a dense 33B model since every token reads all 62 GB. But look at what

[04:40] happened. It spent all 4,000 tokens, my limit, just thinking. It never wrote the answer. 3 minutes of thinking for a hash map question. This is a thinking model by default. And on easy questions, it overthinks. You can turn it off, and I did later. Second test, a math question. How many ordered pairs of numbers from 1 to 100 have a squared plus b squared divisible by 7? It answered 196 in just under 27 seconds. I checked that myself. Squares mod 7 can only be 0, 1, 2, or 4. So, the sum is 0 only when both are multiples of 7. 14 multiples. 14 * 14 196. Correct?

[05:12] And it took only 592 tokens. So, thinking isn’t always long. Third, a trap. I asked it how to use the quantum sort function from Python’s create module to sort in That function doesn’t exist, and a constant time sort is impossible anyway. You’d have to read the list. It caught both. It said there’s no quantum sort in iterate, showed a one-line check that proves it, and gave me the normal sorted function. One more thing it did right. It said that constant time only works if the list already sorted. That’s the kind of honesty I want. Next, tool calling. This matters because agents live or die on it. I gave it two tools, a weather

[05:43] lookup and a calculator, and asked for Tokyo and Paris weather, then the difference times three. It didn’t fire everything at once. It called the weather tool for Tokyo and Paris in parallel and held the calculator back because the calculator needs the results first. That’s correct dependency reasoning. I’ll be straight though, I only tested this first turn, not a full loop. So, the real agent task, I made a tiny Python file with three bugs and a test file and gave it a shell. The bugs were a discount divided by 10 instead of a 100, a total that ignored quantity, and a top item picked by unit price. It ran four steps, read the files, rewrote them, noticed that Pytest wasn’t

[06:14] installed and ran the test another way, then summed up the three fixes. I ran Pytest myself afterwards, three passed. Now, honest limits, this is a toy. Three bugs in a tiny file is nowhere near Terminal Bench. It shows the loop works. It reads, acts, checks. It doesn’t prove the 80.9. Then the stress test, I asked for a complete snake game in one HTML file with scoring speed increasing every five foods, a high score saved in the browser, and restart on space. This took 22 minutes, 27,969 tokens, and 17,000 of them were thinking. But when it finished, I opened the file and the game just worked, no

[06:44] console errors. Now watch, this is the game it wrote and the key presses are scripted by me, so I could film it. The code has the local storage line for the high score and the speed step every five foods. I didn’t test every rule, but it runs. It looks polished and it’s one shot.

[07:22] Next, long context. I hid a passcode inside a pile of filler text and asked for it back at 22,000 tokens. It found it at 71,000, found it at 94,867 tokens, found it. That’s three out of three and it answered in 44 seconds at the longest. But a needle test is the easiest long context test there is and I could only go to 95,000 not 512. So this tells you it holds up to there, nothing more. Now the part that changed my mind, everything so far was one user at a time, 22 tokens a second. So I sent

[07:52] eight requests at once with thinking off, 157 tokens per second total. Then 32 requests at once, 534 tokens per second, same card, same model, 24 times the output because the weights get read once and shared across all of them. Do the math with me. 534 tokens a second is about 1.9 million tokens an hour. At $2.49, that’s roughly $1.30 per million output tokens. That’s my back of the envelope for short stories, not agent work, but it shows who this model is for. So here’s my verdict. If you want one private chat window on one GPU, this is slow and it overthinks. 22 tokens a

[08:24] second is not fun. If you want a self-hosted engine for batches, agents, or a pipeline, it’s very interesting. Quick decision guide, if you’ve got a normal gaming card, 24 GB or less, don’t try the full model, wait for the 3B student, or test the community quantized versions yourself. If you have one big server card, it runs, but expect around 20 tokens a second per user. And if you have lots of parallel work like a batch of tickets or agents running side by side, that’s where the price per token gets interesting. What I didn’t test, I didn’t reproduce any of their benchmarks, I didn’t try the 36 community quantized versions

[08:56] listed on the page, and I didn’t go past 95K tokens. If you try the quantized ones on a smaller card, tell me what you find. What I did prove, it runs on 196 gig card, it follows tool calls, it fixes real bugs, it wrote a working game, and it caught a false premise. For an Apache license model, that’s a real result. If you want to run it yourself, here’s what the card recommends. Temperature 1.0 for agent and tool work, 0.6 for reasoning and chat, turn on preserve thinking for multi-turn agent loops, and turn it off for normal chat. Ask for the XML tool call format and

[09:26] serve it with the Qwen 3 reasoning parser and the Qwen 3 quarter tool parser, which is exactly what I did. One lesson from my own tests, a short question like that, hash map one doesn’t need thinking at all. The card has an enable thinking switch and for the batch tests I flipped it off. A 400-word story then cost around 600 tokens, not thousands. Use thinking where it earns its keep. The cost about 50 minutes of pod time at $2.49 an hour, so around $2.10, and I terminated the pod. Here’s the pod list, empty. If you’re looking for a cheap and reliable GPUs, I use RunPod, and the

[09:57] link is in the description. So, what should I test on this next? A quantized version on a small card or a real coding benchmark? Tell me in the comments. Thanks for watching, and I’ll see you in the next one.