O seletor de raciocínio INSANO do Spark-X2.6-4B: 180 testes em uma GPU de 8 GB

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: Spark-X2.6-4B’s CRAZY Thinking Dial: 180 Tests on an 8GB GPU · Canal: Prompt Engineer 48 · 10:17 · Assistir no YouTube

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

Resumo

O vídeo avalia o Spark-X2.6-4B quantizado em 4 bits em uma GPU RTX 4060 de notebook com 8 GB de VRAM, comparando os modos de raciocínio none, low e high. Foram executadas 180 rodadas em 20 desafios de lógica, debugging, tool calling e seguimento de instruções. O modo low teve a maior taxa de acerto, enquanto high consumiu mais tokens sem melhorar os resultados gerais; none foi mais rápido e se saiu melhor nos testes de debugging. A recomendação do apresentador é usar low como padrão, none em tarefas simples e reservar high para casos em que low falhar, sempre com um limite de tokens.

Pontos-chave

• O teste comparou os modos none, low e high em 20 desafios, com três rodadas por desafio e por modo.
• A taxa de acerto geral foi de 80% em none, 90% em low e 88% em high.
• O modo high gerou quase seis vezes mais tokens do que none e não superou low em acertos nesta amostra.
• Em lógica, low e high acertaram 15 de 15 rodadas, enquanto none acertou 8 de 15.
• Em debugging, none acertou 15 de 15; low acertou 13 e high, 12.
• O modo de raciocínio não alterou a velocidade de geração nem o uso de memória; mais tokens significaram mais tempo de espera.
• O modelo falhou em produzir uma história com exatamente 50 palavras em todos os modos.
• O apresentador recomenda low como padrão, none para tarefas simples e high apenas quando low não for suficiente, com um limite de tokens.

Capítulos

Início	Capítulo	Resumo
00:00	O seletor de raciocínio e a configuração do teste	O apresentador introduz os modos de raciocínio do modelo, descreve a GPU usada e explica como a quantização afeta velocidade e memória.
02:50	Como funcionam os modos e os resultados gerais	O vídeo explica a diferença entre none, low e high e apresenta o desenho do teste, as taxas de acerto, o consumo de tokens e os tempos.
05:31	Resultados por categoria e análise das falhas	A comparação por categoria mostra em que tarefas o raciocínio ajudou, onde não fez diferença e quais erros surgiram nos desafios.
08:09	Velocidade, memória e uso no Ollama	O apresentador compara a configuração de raciocínio no Ollama e explica que os modos usam memória semelhante, mas variam no tempo conforme a quantidade de tokens.
09:12	Recomendações e limitações	O vídeo recomenda low como padrão, ressalva as limitações do experimento e convida o público a sugerir novos testes.

Citações

Com o raciocínio desligado, respondeu 50 em um terço de segundo. — 00:00

High gastou cerca de 45% mais tokens do que low e não trouxe nada a mais nesta amostra. — 04:27

Pensar por mais tempo só dá a um modelo pequeno mais espaço para se perder. — 06:35

Use low como padrão. — 09:12

Conceitos e entidades

• Spark-X2.6-4B (modelo): Modelo com cerca de 4,1 bilhões de parâmetros avaliado nos modos de raciocínio none, low e high.
• Ollama (ferramenta): Ferramenta usada para executar o modelo e configurar o modo de raciocínio.
• llama.cpp (ferramenta): Runtime mencionado como opção para executar o modelo localmente.
• Hugging Face (empresa): Plataforma onde o apresentador consulta o model card do Spark-X2.6-4B.
• X Open (empresa): Conta sob a qual o modelo foi publicado, segundo o vídeo.
• GGUF (conceito): Formato de arquivo de modelo usado na versão quantizada em 4 bits testada.
• quantização de 4 bits (conceito): Redução da precisão do modelo que permitiu executá-lo inteiramente na GPU do notebook.
• RTX 4060 (ferramenta): GPU de notebook com 8 GB de VRAM usada nos testes.
• token cap (conceito): Limite de tokens gerados usado para conter respostas excessivamente longas.

Tradução completa (pt-BR)

00:00 Fiz a um modelo de 4 bilhões de parâmetros uma clássica pergunta capciosa: um taco e uma bola custam juntos 1 dólar e 10 centavos, e o taco custa 1 dólar a mais. Quantos centavos custa a bola? Com o thinking desligado, ele respondeu 50 em um terço de segundo. Mesmo modelo, mesma pergunta: mudei uma chave para low, e ele escreveu a álgebra e respondeu cinco, que é o correto. E esse é o problema dos modelos locais pequenos em um laptop. Com o thinking desligado, eles são rápidos e às vezes erram com confiança. Com o thinking ligado, são mais inteligentes, mas cada token de thinking é tempo que você passa olhando para uma placa gráfica de 8 GB. O Spark X 2.64B diz que resolve isso com um seletor de três posições

00:35 — none, low e high. Então, aqui vai a única pergunta que me interessa: aumentar esse seletor realmente vale os tokens? Executei 20 desafios avaliados nos três modos, três vezes cada. São 180 execuções neste laptop, e vou mostrar cada falha. >> [música] >> Primeiro, o que é isso? Este é o cartão do modelo no Hugging Face: Spark X 2.64B, publicado pela conta X Open, licença Apache 2.0, cerca de 4,1 bilhões de parâmetros. Os autores dizem que ele mantém exatamente a mesma arquitetura do Spark X

01:07 2.5, e que os ganhos vêm de um pós-treinamento melhor. A proposta deles são modelos pequenos para agents no dispositivo, uso de ferramentas para programação e contexto longo. E foi esta afirmação que me fez querer testá-lo: orçamento de thinking controlável, em três níveis — none, low e high. Eles dizem que isso permite equilibrar a qualidade do raciocínio com a latência e o custo. Também publicaram estes gráficos de benchmark, comparando-o com QN 3.59B e modelos Gemma. Esses números foram informados pelos desenvolvedores. Não os reproduzi, então considere-os uma alegação dos autores, não um resultado meu. Uma checagem de fatos sobre o resumo de que parti: ele dizia que a data de lançamento original não está estabelecida, e posso confirmar isso. O repositório foi

01:39 criado em 19 de outubro e atualizado pela última vez em 21 de outubro. Isso é o histórico do repositório, não uma data oficial de lançamento. Agora, minha máquina consegue executá-lo? Esta é uma GPU de laptop RTX 4060 com 8 GB de memória de vídeo. Esse é todo o orçamento para o modelo e para tudo em que ele pensa. O cartão do modelo diz para executá-lo com Ollama usando Spark LLM/Spark X 2.64B. Baixei exatamente essa tag. Mas dê uma olhada primeiro na página da tag. A tag padrão tem 8,2 GB. É o modelo completo de 16 bits. Ele funciona, mas veja o que o Ollama informa: 9,5 GB no contexto padrão. Divisão de 49% na CPU e 51% na GPU. Ele gerou cerca de oito tokens por segundo. A opção melhor é o repo oficial de GGUF. O arquivo Q4 KM tem cerca de 3,5 GB. Totalmente na GPU, ele gera cerca de 60 tokens por segundo. Isso é aproximadamente oito vezes mais rápido, embora eu esteja comparando dois tempos de execução. Foi o que usei em todo o resto. Você precisa de um tempo de execução recente. O cartão do modelo recomenda a compilação 10828 ou posterior do llama.cpp e o Ollama 0.34 ou posterior. Estou usando versões mais recentes dos dois. Carregado com um contexto de 16.000 tokens, o modelo ocupa cerca de 3,5 GB de memória de vídeo. Exatamente 3.543 MB.

02:15 Ele cabe com folga. Veja como o seletor funciona de verdade; é mais simples do que eu esperava. Este é o template de chat que vem com o modelo. Se o thinking estiver desligado, o template termina o prompt com uma tag de fechamento de thinking. O modelo começa a resposta como se já tivesse terminado de pensar. Então, none não é uma versão preguiçosa do thinking. Ele pula completamente a etapa de thinking. Se o thinking estiver ligado, a única diferença entre low e high é uma frase no system prompt. Agora, o sistema é chamado com thinking effort igual a low ou high, e high é o padrão.

02:50 Vale a pena saber disso porque significa que o orçamento é uma sugestão que o modelo segue, não um limite rígido. O único limite rígido nas minhas execuções foi meu próprio limite de tokens, ao qual voltarei. Aqui está o teste: 20 desafios, cinco em cada uma de quatro categorias. Depuração de Python com erros, tool calling, quebra-cabeças de lógica e cumprimento de instruções de formatação exata. Nada é avaliado por mim lendo as respostas. As respostas de depuração são código que executo contra testes. As chamadas de ferramentas são analisadas, e os argumentos são verificados. As perguntas de lógica exigem o número final exato. As regras de formatação são verificadas por código. Usei as configurações do cartão do modelo.

03:21 Temperatura um, top P 0,95. Cada desafio foi executado nos três modos, e repeti o conjunto inteiro três vezes porque, com temperatura um, uma única execução é uma aposta. A geração foi limitada a 6.144 tokens. São 60 execuções por modo, 180 no total, uma solicitação por vez, então os tempos são confiáveis. Tive, sim, que descartar uma tentativa anterior, em que dois dos meus próprios executores se sobrepuseram no mesmo servidor, e refazer tudo do zero. Aqui estão primeiro os totais: com thinking none, 48 de 60 corretas; low, 54; high, 53. Isso dá 80%, 90% e 88%. Low e high

03:51 ficaram a um teste de diferença, com três execuções cada e temperatura um. Eu não chamaria isso de diferença. O custo é que fica desproporcional. Nas 60 execuções, none gerou cerca de 12.000 tokens; low gerou 48.000, quase quatro vezes mais; high, 69.000, quase seis vezes mais. Em tempo, none levou 5 minutos no total, low levou 23 e high, 36 minutos. Uma pergunta típica é bem mais tranquila. O tempo mediano é de cerca de 1 segundo com none e de 4 a 5 segundos com low ou high. As médias são puxadas para cima por algumas execuções de thinking muito longas. Então, high gastou cerca de 45% mais tokens

04:27 do que low e não trouxe nenhum ganho extra nesta amostra. Aqui está uma maneira mais justa de ver o custo: dividir os tokens pelo número de respostas corretas. None gastou cerca de 250 tokens por resposta correta; low, cerca de 885; high, cerca de 1.300. É isso que uma resposta certa realmente custa em cada modo. Mais uma coisa sobre esse seletor. Tenho 60 pares correspondentes: o mesmo desafio na mesma rodada, uma vez em low e outra em high. High pensou por mais tempo 39 vezes, low pensou por mais tempo 17 vezes, e em quatro casos o tempo foi igual. Então, high tende a gerar mais thinking, mas não é uma garantia.

05:00 E aqui está o tempo de espera em números claros. Execuções que levaram mais de 30 segundos: três com none, 11 com low e 17 com high. São essas execuções lentas que compõem as médias. Agora, a grade completa. Cada desafio, cada modo, três execuções cada. Em 12 dos 20 desafios, o resultado foi três de três em todos os modos. O thinking não fez diferença alguma nesses casos. Tudo o que é interessante está nas outras oito linhas, então vamos analisá-las. Agora, em que situações o thinking realmente ajuda? Vou separar por categoria. Cada célula é de um total de 15 execuções. Lógica é a vencedora clara. None acertou oito de 15; low e

05:31 high acertaram todas as 15. Para quebra-cabeças de raciocínio, vale claramente a pena usar thinking. Seguir instruções ficou estável: 12 de 15 nos três modos. O thinking não mudou nada, e já vou mostrar o motivo. Tool calling: 13 para none, 14 para low e high. Um único teste fez a diferença, e também vou mostrar esse caso. O restante dos testes de ferramentas merece uma observação. Pedir a hora e a previsão do tempo em Tóquio exige duas chamadas de ferramenta ao mesmo tempo, e todos os modos acertaram nas três execuções. Uma pergunta factual simples não deve acionar nenhuma ferramenta, e todos os modos acertaram isso nas três execuções. Uma execução de ferramenta usou, em média, 24

06:03 tokens com none, 60 com low e 97 com high. Para tool calling, none basta. E a depuração me surpreendeu. None acertou 15 de 15, low acertou 13 e high, 12. O thinking não ajudou aqui e, nesta amostra, até atrapalhou um pouco. Não é exatamente que o thinking tenha escrito código pior. Nas três falhas de high, em duas as execuções ficaram sem tokens enquanto ainda estavam pensando, e em uma o código escrito nunca termina. As duas falhas de low foram correções simplesmente erradas. Pensar por mais tempo só dá a um modelo pequeno mais espaço para se desviar. E é na depuração que a conta de tokens fica maior. Uma execução de depuração levou, em média,

06:35 72 tokens com none, 1.100 com low e 2.500 com high. Então, o modo que acertou 15 de 15 também foi, de longe, o mais barato. Vamos analisar as falhas palavra por palavra. Taco e bola: com o thinking desligado, a resposta inteira do modelo é 50. Outra execução respondeu 10. Nas três execuções, none nunca acertou. Low e high acertaram todas as vezes porque primeiro escrevem a álgebra. O problema das ovelhas, em que todas menos nove fogem, conta a mesma história. Com o thinking desligado, ele respondeu oito ou 10, nunca nove. Com o thinking ligado, resolveu

07:05 72 tokens com nenhum, 1.100 com baixo e 2.500 com alto. Então, o modo que acertou 15 de 15 também foi, de longe, o mais barato. Vamos analisar as falhas palavra por palavra. No problema do taco e da bola, com o pensamento desativado, a resposta inteira do modelo é 50. Em outra execução, ele respondeu 10. Em três execuções, o modo nenhum nunca acertou. Os modos baixo e alto acertaram todas as vezes porque primeiro escrevem a álgebra. O problema do fazendeiro, em que todas as ovelhas, menos nove, fogem, é a mesma história. Com o pensamento desativado, ele respondeu oito ou 10, nunca nove. Com o pensamento ativado, resolveu.

07:35 sempre. Agora, o oposto: uma busca binária quebrada. No modo alto, o modelo pensou por cerca de 17.000 caracteres, atingiu meu limite de tokens e retornou uma resposta vazia. O modo baixo resolveu este problema três de três vezes. O modo alto resolveu uma vez. Depois, tem este: escrever uma história com exatamente 50 palavras. Zero de nove em todos os modos. Com o pensamento desligado, ele nem sequer parou. Ficou divagando por 1.400 até escrever coisas como: “Espera, precisa ter exatamente 50. Deixa eu contar direito.” Os modos baixo e alto ficaram sem tokens enquanto contavam. Então, um modelo de 4 bilhões não consegue contar palavras na própria

08:09 cabeça, e pensar não resolve isso. Um teste com ferramenta precisa de uma observação honesta. Pedi arquivos Python que começassem com test underscore. Ele usou um padrão test*.py ou test.py. É parecido, mas mais abrangente do que pedi, e meu avaliador marcou como errado. Você poderia considerar que passou. Mantive minha avaliação rigorosa, e digo que a velocidade é a mesma nos três modos: cerca de 60 tokens por segundo. Isso significa que o tempo depende apenas dos tokens. Se o modo alto pensar pelo dobro do tempo, você espera pelo dobro do tempo. Nada mais muda. A memória também é a mesma: cerca de 3,5 GB, qualquer que seja o modo, com aquele contexto de 16.000 tokens.

08:41 Você não precisa de uma placa maior para o modo alto. Precisa de mais paciência. Se você usa Ollama, o mesmo seletor existe. Testei com o modelo de 4 bits. Com think definido como false, ele respondeu em seis tokens e disse 10, que estava errado. Com think low, foram 92 tokens e a resposta certa. Com think high, 120 tokens, também certo. Na API, esse é o campo think. False, low ou high. Defini-lo como true se comporta como high, o que corresponde ao template, em que high é o padrão.

09:12 Uma coisa prática daquela tela anterior: o Ollama carregou o modelo completo com um contexto de 65.000 tokens, e esse contexto também consome memória. Reduzi-lo é a primeira coisa que eu tentaria se quisesse fazer a versão grande caber melhor. Não testei o quanto isso ajuda, então é uma sugestão, não um resultado. Então, você deveria aumentar o nível de pensamento? Eis o que essas 180 execuções mostram. Use low como padrão. Ele corrigiu todas as armadilhas de lógica e usou cerca de 70% dos tokens que high usou. Use nenhum para coisas que devem ser instantâneas: chamadas de ferramentas, pequenos consertos de código, formatação. Foi de longe o mais rápido e, no meu teste, foi adequado para depuração, mas não confie nele para uma pergunta capciosa ou um problema com enunciado. Use high apenas quando low falhar e coloque um limite de tokens, porque foi no high que vi as execuções saírem do controle. E eis o que isso não pode dizer a você. Um: quantização de 4 bits. 20 testes que eu mesmo escrevi, três execuções de cada com temperatura um, um avaliador rigoroso, e os gráficos de benchmark do fornecedor continuam sendo apenas afirmações do fornecedor. Não executei nenhum deles novamente. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. Se quiser que eu teste as outras quantizações do Spark

09:46 ou compare isso com um modelo maior, me conte nos comentários. Até a próxima.

10:17 quantizações ou comparar isso com um modelo maior, me conte nos comentários. Até a próxima.

Transcrição original

[00:00] I asked a 4-billion parameter model, a classic trick question, a bat and a ball cost a dollar 10 together, and the bat cost a dollar more. How many cents is the ball? With thinking off, it answered 50 in a third of a second. Same model, same question, I flip one switch to low, and it writes out the algebra and says five, which is correct. And that is the problem with small local models on a laptop. Thinking off is fast and sometimes confidently wrong. Thinking on is smarter, but every thinking token is time you spend staring at an 8-GB graphics card. Spark X 2.64B says it fixes that with a three-position

[00:35] dial, none, low, and high. So, here’s the only question I care about. Does turning that dial up actually earn its tokens? I ran 20 graded challenges in all three modes three times each. That’s 180 runs on this laptop, and I’ll show you every failure. >> [music] >> First, what is it? This is the model card on Hugging Face, Spark X 2.64B, published under the X Open account, Apache 2.0 license, about 4.1 billion parameters. The authors say it keeps exactly the same architecture as Spark X

[01:07] 2.5, and that the gains come from better post-training. Their pitch is small models for on-device agents, coding tool use, and long context. And this is the line that made me want to test it. Controllable thinking budget, three levels, none, low, high. They say it lets you balance reasoning quality against latency and cost. They also published these benchmark charts comparing it with QN 3.59B and Gemma models. Those numbers are developer reported. I did not reproduce them, so treat them as the authors claim, not my result. One fact check on the brief I started from, it said the original release date isn’t established, and I can confirm that. The repository was

[01:39] created on October 19th and last updated on October 21st. That’s repository history, not an official release date. Now, can my machine run it? This is an RTX 4060 laptop GPU with 8 GB of video memory. That is the whole budget for the model and for everything it thinks about. The model card says to run it with Ollama, run Spark LLM/Spark X 2.64B. I pulled that exact tag. Look at the tag page first though. That default tag is 8.2 GB. It’s the full 16-bit model. It runs, but look at what Ollama reports. 9.5 GB at its default context. Split 49% on the CPU and 51% on the GPU. It

[02:15] generated about eight tokens a second. The better option is the official GGUF repo. The Q4 KM file is about 3 and 1/2 GB. Fully on the GPU, it generates around 60 tokens a second. That’s roughly eight times faster though I’m comparing two run times. It’s what I used for everything else. You do need a recent run time. The card says llama.cpp build 10828 or later and Ollama 0.34 or later. I’m on newer builds of both. Loaded with a 16,000 token context, the model takes about 3 and 1/2 GB of video memory. 3,543 MB to

[02:50] be exact. It fits comfortably. Here’s how the dial actually works and it’s simpler than I expected. This is the chat template that ships with the model. If thinking is switched off, the template ends the prompt with a close thing tag. The model starts its answer as if it has already finished thinking. So none isn’t a lazy version of thinking. It skips the thinking step entirely. If thinking is on, the only difference between low and high is one sentence in the system prompt. Now the system is invoked with thinking effort equals low or high and high is the default.

[03:21] That’s worth knowing because it means the budget is a suggestion the model follows, not a hard limit. The only hard limit in my runs was my own token cap, which I’ll come back to. Here’s the test. 20 challenges, five each in four categories. Debugging broken Python, calling tools, logic puzzles, and following exact formatting instructions. Nothing is graded by me reading answers. Debugging answers are code that I execute against tests. Tool calls are parsed and the arguments are checked. Logic questions need the exact final number. Formatting rules are checked in code. I used the settings from the model card.

[03:51] Temperature one, top P 0.95. Each challenge ran in all three modes and I repeated the whole set three times because at temperature one, a single run is a the flip. Generation was capped at 6,144 tokens. That’s 60 runs per mode, 180 in total, one request at a time, so the timings are clean. I did have to throw away an earlier attempt where two of my own runners overlapped on the same server and redo it from scratch. Here are the totals first with thinking none 48 of 60 correct, low 54, high 53. That’s 80%, 90%, and 88%. Low and high

[04:27] are one test apart with three runs each at temperature one. I would not call that a difference. The cost is where it gets lopsided. Across all 60 runs, none generated about 12,000 tokens, low generated 48,000, almost four times as many, high generated 69,000, nearly six times. In time, none took 5 minutes in total, low took 23, high took 36 minutes. The typical question is much calmer. Median time is about 1 second with none and 4 to 5 seconds with low or high. The averages are dragged up by a handful of very long thinking runs. So, high spent about 45% more tokens

[05:00] than low and bought nothing extra in this sample. Here’s a fairer way to see the cost. Divide the tokens by the number of correct answers. None spent about 250 tokens per correct answer, low spent about 885, high spent about 1,300. That is what a right answer actually costs you in each mode. One more thing about that dial. I have 60 matched pairs, the same challenge in the same pass, once on low and once on high. High thought longer 39 times, low thought longer 17 times, and four were equal. So, high is a lean toward more thinking, not a guarantee.

[05:31] And here’s the waiting in plain numbers. Runs that took more than 30 seconds, three with none, 11 with low, and 17 with high. Those slow runs are what the averages are made of. Now, the full grid. Every challenge, every mode, three runs each. 12 of the 20 challenges were three out of three in every mode. Thinking made no difference to them at all. Everything interesting is in the other eight rows, so let’s go through them. Now, where does thinking actually help? Let me split it by category. Each cell is out of 15 runs. Logic is the clear winner. None got eight of 15, low and

[06:03] high both got all 15. For reasoning puzzles, thinking is clearly worth it. Instruction following is a flat line, 12 out of 15 in all three modes. Thinking didn’t move it, and I’ll show you why in a moment. Tool calling, 13 for none, 14 for low and high. That’s a single test making the difference, and I’ll show you that one, too. The rest of the tool tests are worth a note. Asking for the time and the weather in Tokyo needs two tool calls at once, and every mode got that three times out of three. A simple factual question should not trigger a tool at all, and every mode had that back three out of three. A tool run average 24

[06:35] tokens with none, 60 with low, and 97 with high. For tool calling, none is enough. And debugging surprised me. None got 15 out of 15, low got 13, high got 12. Thinking did not help here, and in this sample, it even hurt a little. The thinking didn’t write worse code, exactly. High’s three misses, two ran out of tokens while still thinking, and one wrote code that never finishes. Low’s two misses were plain wrong fixes. Longer thinking just gives a small model more room to wander. And debugging is where the token bill is biggest. An average debugging run took

[07:05] 72 tokens with none, 1,100 with low, and 2,500 with high. So, the mode that got 15 out of 15 was also the cheapest by wide margin. Let’s look at the failures word for word. Bat and ball, thinking off, the model’s whole answer is 50. Another run said 10. Across three runs, none never got it. Low and high got it every time because they write the algebra out first. The farmer puzzle, where all but nine sheep run away, is the same story. With thinking off, it said eight or 10, never nine. With thinking on, it solved it

[07:35] every time. Now, the opposite, a broken binary search. In high mode, the model thought for about 17,000 characters, hit my token cap, and returned an empty answer. Low solved this one three times out of three. High solved it once. Then there’s this one, write a story of exactly 50 words. Zero out of nine in every mode. With thinking off, it didn’t even stop. It rambled for 1,400 to writing things like, “Wait, need exactly 50. Let me count properly.” Low and high ran out of tokens counting. So, a 4-billion model can’t count words in its

[08:09] head, and thinking doesn’t fix that. One tool test needs an honest note. I asked for Python files starting with test underscore. It used a pattern test star.py or star test star.py. That’s close, but looser than I asked, and my grader marked it wrong. You might call it a pass. I kept my strict grading, and I’m telling you speed is the same in all three modes, about 60 tokens a second. That means time is just tokens. If high thinks twice as long, you wait twice as long. Nothing else changes. Memory is the same, too, about 3 and 1/2

[08:41] GB, whichever mode at that 16,000 token context. You don’t need a bigger card for high. You need more patience. If you use Ollama, the same dial exists. I tested it with the 4-bit model. With think set to false, it answered in six tokens and said 10 wrong. With think low, 92 tokens and the right answer. With think high, 120 tokens, also right. In the API, that’s the think field. False, low, or high. Setting it to true behaves like high, which matches the template where high is the default.

[09:12] One practical thing from that earlier screen, Ollama loaded the full model with a context of 65,000 tokens, and that context takes memory, too. Shrinking it is the first thing I’d try if you want the big version to fit better. I haven’t tested how much it helps, so that’s a suggestion, not a result. So, should you turn thinking up? Here’s what these 180 runs say. Use low as your default. It fixed every logic trap, and it used about 70% of the tokens that high did. Use none for things that should be instant, tool calls, short code fixes, formatting. It was by far the fastest, and in my test, it it was fine on

[09:46] debugging, but don’t trust it on a trick question or a word problem. Use high only when low fails, and put a token cap on it because high is where I saw the runaways. And here’s what this can’t tell you. One, 4-bit quantization. 20 tests I wrote myself, three runs each at temperature one, one strict grader, and the vendor’s benchmark charts are still the vendor’s claim. I didn’t rerun any of them. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. If you want me to test the other spark

[10:17] quantizations or push this against a bigger model, tell me in the comments. See you in the next one.