Por que seu LLM local parece mais burro: drift da stack de inferência

Hospede um modelo open-weight e, mais cedo ou mais tarde, você se depara com a mesma confusão: supostamente é o mesmo modelo que todo mundo está elogiando na internet, mas na sua máquina ele toma decisões piores, pula passos óbvios e, de vez em quando, quebra um fluxo de agente sem motivo aparente. Os suspeitos de sempre — prompt ruim, hardware fraco, uma quantização agressiva demais — levam a culpa. Uma investigação recente em nível de logits aponta para um culpado mais silencioso que fica abaixo de todos eles: a sua própria stack de inferência. Se o lado da configuração ainda é novidade para você, nosso guia sobre rodar o Qwen localmente cobre o básico da instalação; este teste trata do que silenciosamente dá errado depois da instalação.

O usuário thr3e do fórum Level1Techs rodou um teste punitivo com o Qwen3.6-27B em uma GPU RTX PRO 6000 Blackwell, capturando logits de vocabulário completo em mais de 100.000 tokens. A configuração é a chave para entender por que isso importa: os mesmos pesos, a mesma GPU, o mesmo prompt — e apenas uma configuração de inferência alterada. O resultado foi que o modelo escolheu tokens diferentes em pontos críticos de decisão e, em pelo menos um rastreamento, executou comandos errados em um roteador Cisco real porque uma tool call mirou a interface errada.

Onde o drift realmente vive

Logits são um produto puramente aritmético: multiplicações de matrizes, atenção e ativações empilhadas em números de ponto flutuante. Os mesmos pesos com a mesma entrada deveriam — em teoria — produzir logits idênticos. Na prática, a precisão de ponto flutuante, a ordem de acumulação e os conjuntos de instruções do hardware introduzem pequenas diferenças numéricas. Quando essas diferenças são grandes o suficiente para inverter o token de maior probabilidade, dois deployments “idênticos” começam a se comportar como modelos diferentes.

O thr3e isolou três fontes desse drift:

Backends de atenção. O vLLM oferece três backends de atenção completa para o Qwen3.6-27B: FlashAttention 2, Flash Inference e Triton Attention. Trocar apenas o backend — nada mais — produziu inversões de Top-1: o token de greedy-decoding divergiu do baseline. Em uma falha rastreada, o FlashAttention 2 resolveu uma interface de roteador Cisco como GigabitEthernet0/1/4 em vez de GigabitEthernet0/0/1.201, e então executou mais dois comandos errados com base nesse erro.
Precisão do KV-cache. Mantendo os pesos em BF16 e fixando o backend no Triton, o teste variou apenas a quantização do KV-cache: BF16, INT8 e INT4. O INT4 fez a taxa de inversões de Top-1 disparar em contexto longo e levou as tool calls a um ponto sem recuperação. O INT8 também invertia, mas eventualmente se recuperava. Apenas o BF16 permaneceu estável do início ao fim.
Controles de reprodutibilidade. Execuções repetidas do mesmo backend foram idênticas bit a bit, até o último hidden state — então a divergência é puramente produto de quais kernels CUDA executam a matemática do prefill, não de aleatoriedade ou throttling térmico.

A carga de trabalho importou tanto quanto os achados: era um fluxo real de agente com ~100k tokens e múltiplas tool calls, deliberadamente ausente de qualquer benchmark público ou conjunto de treinamento, de modo que ninguém havia feito tuning ou calibração de quantização contra ele.

O modelo não é o produto. A stack é.

Pense como um motor. Dois carros com o mesmo bloco de motor podem parecer completamente diferentes dependendo do ponto de ignição, do mapeamento de combustível e do ajuste do escapamento. Os pesos abertos são o bloco do motor; sua stack de deployment com 734 pacotes é o ajuste fino. Mude um pacote, um caminho de kernel CUDA, uma decisão de quantização — e o mesmo “motor” roda com uma personalidade diferente. O lado positivo é igualmente útil: uma stack oficial bem calibrada pode fazer um modelo de nível médio superar um local não calibrado — a mesma lógica por trás de por que o Qwen3.8-Flash foi adicionado ao Qwen Office com a maioria das cargas de trabalho em um tier padrão.

Isso reformula todo o debate sobre pesos abertos. A API oficial não é apenas uma camada de conveniência; é a implementação de referência de um modelo, com uma stack fixa e calibrada que produziu os números de benchmark que você lê por aí. Um deployment local é uma aproximação montada à mão dessa referência — e cada camada, dos kernels de atenção à precisão do KV-cache até a config NCCL multi-GPU, pode divergir dela. Em contextos longos, as diferenças se acumulam até o modelo tomar uma decisão errada com toda a confiança exatamente no momento que importa.

O que isso significa para equipes

Várias consequências práticas decorrem disso:

“Mesmo modelo, avaliações diferentes” é um artefato de medição. Quando uma equipe diz que um modelo é brilhante e outra o chama de quebrado, ambas podem estar certas — a divergência pode estar nas stacks, não no modelo ou no prompt.
A confiabilidade de agentes em modelos self-hosted é limitada pelo drift da stack. Tool calls são exatamente onde um único token invertido causa dano real, e é por isso que cargas de agente em modelos locais parecem instáveis de formas que o chat nunca parece.
Quantização agora é uma decisão de negócio, não um truque de memória. KV-cache INT4 é ok para chat curto e perigoso para execuções de agente em contexto longo. A economia tem um preço de confiabilidade que você só descobre depois de uma falha.
Motores de inferência fazem parte da especificação do modelo. vLLM, kernels e escolha de backend pertencem ao changelog do modelo, não à nota de rodapé.

O que fazer antes de confiar em um modelo local

Congele sua stack. Fixe o motor de inferência, o backend de atenção e a versão do CUDA. Trate “funcionou na minha máquina” como uma afirmação com versão, não como uma verdade geral.
Teste com seus próprios rastros longos de agente. Execute exatamente os fluxos de tool call dos quais você depende, com comprimentos de contexto de produção, antes de rotear trabalho real por um modelo self-hosted.
Mantenha KV-cache BF16 para qualquer coisa com tool calls. Se precisar quantizar, valide com seus próprios rastros propensos a falhas — não com um benchmark estático.
Exija notas de reprodutibilidade. Quando o lançamento de um modelo reivindicar um benchmark, pergunte qual stack o produziu. Se a resposta for vaga, presuma que o número não se transfere para a sua máquina.
Prefira a API quando a tarefa importa. Use o local para caminhos críticos de latência ou privacidade; use a stack oficial calibrada para os críticos de correção.

O thr3e está empacotando o harness de teste e o dataset para distribuição pública, para que qualquer pessoa possa reproduzir as medições no próprio hardware. Esse é o instinto certo: até que a reprodutibilidade bit a bit se torne parte normal de como fazemos deploy e avaliamos deployments locais, “seu modelo local é mais burro” continuará sendo um mistério que, na verdade, é só aritmética.