O Modelo Passou. A Configuração de Serving Quebrou Ele.

Um praticante que assina como thr3e no fórum Level1Techs rodou os mesmos pesos de modelo em várias configurações de serving e viu uma configuração de precisão do cache KV quebrar tool calling de forma permanente. Do post de 16 de agosto de 2026: “Enough top-tokens got flipped during tool calls, we let them play out and while BF16 was fine, int8 kv-cache eventually managed to recover, int4 did not!” O autor descreve o caso como “a completely reproducible tool calling error”.

Nada no modelo mudou. Os pesos eram idênticos. O que mudou foi a precisão com que o cache KV guarda o estado de atenção durante a inferência, um valor definido por uma flag de deploy.

Seu processo de compras governa qual modelo você adquire. Sua revisão de segurança governa quais dados ele enxerga. Sua suíte de avaliação governa se ele passa. Nenhum desses processos governa a configuração de serving, e é exatamente ali que essa falha mora.

O Que a Medição Mostra de Fato

A metodologia merece atenção antes dos achados, porque um post de fórum carrega menos peso que um estudo revisado por pares, e a razão para confiar neste é a documentação do método.

O setup: uma RTX PRO 6000 Blackwell, um build nightly do vLLM fixado, execução eager, CUDA graphs, prefix caching e MTP todos desligados, prefill em chunks de 2k tokens, e logits de vocabulário completo capturados em BF16 a cada 32 tokens de prompt ao longo de uma janela de 96k. O controle de repetibilidade entre GPUs devolveu resultados idênticos bit a bit. Esse último detalhe separa uma medição de uma anedota. O autor provou que o rig produz os mesmos números duas vezes antes de comparar qualquer coisa.

Cinco configurações entraram no bakeoff: referência em BF16, o release oficial em FP8, INT8 W8A16, o NVFP4 da NVIDIA e AWQ W4A16. A dispersão foi grande. Segundo o post, “Nvidia’s release comes in dead last hitting ~50% token flips by the time we reach 88k context”.

Esse número pertence especificamente ao NVFP4, último entre cinco. Ele descreve aquele release. Tratá-lo como propriedade da quantização de 4 bits como classe seria a lição errada. O AWQ W4A16 também é de 4 bits e ficou em outro lugar nessa métrica.

A falha qualitativa é a parte que deveria preocupar quem roda agentes. Tanto o NVFP4 quanto o AWQ W4A16 “failed to properly close their tool calls and botched Cisco command line syntax (the correct command was show arp)”. Uma tool call malformada rompe o contrato com o sistema que estava esperando por ela. Do lado de baixo, isso aparece como indisponibilidade.

Uma observação sobre os modelos: o trabalho de quantização e backend de atenção nesse post usa o Qwen3.6-27B, e uma comparação de fine-tune mais adiante usa o Qwen3.8-27B. Dois modelos, duas perguntas.

O Fluxo de Aprovação Que Não Existe

Desenhe o caminho que um modelo percorre até produção e marque cada ponto em que um humano assina alguma coisa.

A escolha do modelo passa por avaliação de fornecedor, checagem de licença, às vezes um questionário de segurança. Mudanças de prompt são versionadas e, numa operação madura, avaliadas. Fine-tunes têm um treinamento com dono e linhagem de dataset. Mudanças de retrieval passam por revisão porque alguém é dono do índice.

Depois existe um conjunto de valores que altera materialmente a saída do modelo e não passa por nada disso:

Precisão do cache KV. O INT4 do caso acima. Uma flag na configuração de serving, escolhida em geral para caber mais sessões simultâneas na mesma VRAM.
Formato de quantização dos pesos. FP8, INT8, NVFP4, AWQ W4A16. Normalmente definido por quem baixou o artefato que coube na GPU, e os cinco formatos do bakeoff se comportam de maneiras diferentes entre si.
Backend de atenção. O kernel que implementa a atenção. Trocado por um bump de versão, uma variável de ambiente, ou um default de biblioteca que mudou sem aviso.

Cada um deles é uma mudança de modelo em todo sentido que o usuário percebe. Nenhum gera um diff que um revisor leia. Um upgrade de dependência pode mover os três de uma vez.

Essa é a mesma superfície que A Diferença do Harness atacou pelo lado oposto. Lá, manter o modelo fixo e mudar o scaffolding levou um benchmark de 42% para 78%. Aqui, manter modelo e scaffolding fixos e mudar uma flag numérica na camada de serving remove uma capacidade. A lição chega pelas duas pontas: o artefato que você aprovou é uma fração pequena do sistema que responde aos seus usuários.

Por Que a Demo Passa Mesmo Assim

Essas mudanças passam despercebidas porque o teste de aceitação costuma ser uma demo, e uma demo é incapaz de detectá-las.

Raluca Budiu, do Nielsen Norman Group, resumiu o problema em uma linha em agosto de 2026: “One good output demonstrates that a system can perform a task. It does not show how often or how reliably the system will do so.”

O artigo dela separa duas fontes de variabilidade que uma execução única funde numa impressão só. “Test-input variability” é a dispersão entre perguntas diferentes. “Run-to-run variability” é a dispersão entre execuções repetidas da mesma pergunta. Uma demo amostra um ponto de cada distribuição e reporta isso como o comportamento do sistema.

O exemplo discriminante do NN/g vale levar para qualquer conversa de compra. O Sistema A acerta 8 de 10 perguntas em toda execução. O Sistema B acerta cada uma das 10 perguntas em 4 de 5 execuções. As médias são idênticas em 80%. São dois produtos diferentes. O A erra de forma previsível em duas coisas específicas, que você contorna com roteamento. O B erra de forma imprevisível em tudo, o que é bem mais difícil de sustentar em produção.

O NN/g propõe um mínimo trabalhado: 10 perguntas representativas, cada uma executada 5 vezes, totalizando 50 respostas, reportadas como média com intervalo de confiança e uma medida de consistência. O próprio artigo diz que esses números são “not universal recommendations”. Trate-os como formato a copiar, e calibre suas próprias contagens.

Volte agora ao resultado do INT4. Uma falha de tool calling que aparece em contexto longo é justamente o modo de falha que sobrevive a uma demo e morre em produção. Um prompt curto rodado uma vez nunca chega a 88k tokens.

O Argumento de Custo Piora Tudo

A quantização é escolhida por um motivo legítimo. Precisão menor faz caber mais modelo ou mais sessões simultâneas na mesma GPU, e GPU é a linha de custo que todo mundo é cobrado para reduzir.

Então a mudança chega com uma justificativa de custo anexada, que é a forma mais eficaz de atravessar uma revisão sem escrutínio técnico. Fizemos o mesmo argumento sobre gasto em Variância de Custo, Não Teto de Gastos: um teto sobre a média esconde a distribuição que de fato quebra as coisas. Reduzir precisão aplica esse padrão à qualidade. A resposta média continua boa. A cauda perde tool calls.

Faça Isto Agora

Escreva a configuração de serving que você roda em produção hoje. Especificamente: o formato de quantização dos pesos, a precisão do cache KV e o backend de atenção, com versões. Se ninguém na sua organização consegue produzir esses três valores em menos de uma hora, você desconhece qual modelo está atendendo seus usuários.

Depois coloque esses três valores sob o mesmo controle de mudança que o nome do modelo. Um pull request, um dono nomeado, e uma reexecução da sua avaliação antes de a flag se mover. Se a sua avaliação é uma demo, o formato do NN/g é o ponto de partida: um conjunto de entradas representativas, execuções repetidas e uma dispersão reportada no lugar de um exemplo reportado. Inclua ao menos um caso de tool calling em contexto longo, porque foi ali que o resultado do INT4 apareceu e prompts curtos passam por cima dele.

Os pesos que você aprovou e o modelo com que seus usuários conversam são duas coisas distintas até que você escreva a segunda em algum lugar.

Fontes

Level1Techs Forums. “Why your local LLM feels dumber than it is.” Agosto de 2026.
Nielsen Norman Group. “One AI Output Is an Example, Not an Evaluation.” Agosto de 2026.

A Victorino coloca a superfície de deploy de um sistema de IA sob a mesma governança do modelo que aparece na nota fiscal: contato@victorino.com.br | www.victorino.com.br