# IA local precisa tratar velocidade e protocolo como um só problema

> As atualizações de 2 de agosto do llama.cpp conectam previsão especulativa, chamadas de ferramenta e telemetria: desempenho útil depende de contratos que sobrevivam à execução.

- Author: Elzo Brito
- Language: pt-BR
- Published: 2026-08-02
- Canonical URL: https://elzobrito.com/blog/ia-local-precisa-tratar-velocidade-e-protocolo-como-um-so-problema/
- Translation: https://elzobrito.com/en/blog/local-ai-must-treat-speed-and-protocol-as-one-problem/

---
Uma demonstração rápida de um modelo local não basta para torná-lo útil em um produto. Ele precisa gerar tokens depressa, interpretar corretamente quando deve chamar uma ferramenta e deixar sinais confiáveis para que alguém possa medir o que aconteceu. Três atualizações sucessivas do [llama.cpp em 2 de agosto](https://github.com/ggml-org/llama.cpp/releases/tag/b10229) tornam essa dependência mais concreta.

O projeto incorporou suporte a uma forma de previsão especulativa para DeepSeekV4, ajustou o parser de chamadas de ferramenta do Qwen3 e corrigiu um erro que podia impedir a gravação de dados de profiling no backend OpenCL. São mudanças diferentes, mas apontam para a mesma lição: velocidade, protocolo e observabilidade não são camadas independentes quando a IA sai do laboratório.

## Acelerar é propor e conferir

A mudança [DeepSeekV4 MTP + DSpark](https://github.com/ggml-org/llama.cpp/pull/25784), liberada no build b10228, adiciona suporte ao cabeçalho DSpark e trabalho inicial para *multi-token prediction* (MTP), uma técnica de decodificação especulativa. Em vez de o modelo principal calcular cada próximo token sozinho, um componente auxiliar propõe vários; o modelo principal os verifica e aceita apenas os que concordam.

O detalhe importante está no próprio aviso do autor: os checkpoints recentes citados não trazem MTP, apenas o cabeçalho DSpark. Portanto, MTP não deve ser presumido como recurso de qualquer modelo DeepSeekV4. Para um checkpoint DSpark compatível, o autor registrou medições próprias em um DGX Spark que reduzem o tempo agregado de seu conjunto de nove solicitações de 102,15 para 55,95 segundos. É evidência de uma configuração específica, não uma promessa de ganho universal.

Isso muda a pergunta prática de quem opera IA local. Não basta perguntar se a previsão especulativa está ligada. É preciso verificar qual checkpoint carrega o componente necessário, quantos rascunhos são aceitos e se o tipo de tarefa mantém esse aproveitamento. Uma sugestão que o modelo principal rejeita ainda consumiu trabalho.

## Uma chamada de ferramenta não pode depender de pontuação perfeita

No build b10227, o [parser especializado para Qwen3](https://github.com/ggml-org/llama.cpp/pull/26252) passou a reconhecer um caso observado pelos mantenedores: alguns modelos podem emitir `<tool_call>` logo após a seção de raciocínio, sem o delimitador de encerramento que o servidor esperava. A atualização também trata modelos antigos que às vezes omitem a marca de abertura e permite argumentos em ordens diferentes.

Isso não dá novas ferramentas ao modelo. Ele altera a ponte entre o texto que o modelo produz e a ação estruturada que o software executa. Antes, uma variação de formatação podia virar texto comum, quebrar uma chamada válida ou exigir regras mais restritivas no amostrador de gramática. Agora, o parser aceita mais formas esperadas sem confundir o fim do raciocínio com uma instrução perdida.

Há uma consequência de engenharia: compatibilidade com ferramentas não é somente expor uma função em JSON. Ela depende de tokens de controle, delimitadores, gramática e tolerância a variações do modelo. Atualizar pesos sem testar esse caminho completo é testar apenas metade do agente.

## Medir também é parte da entrega

O build b10229 corrige a contagem de referências durante a inicialização OpenCL. Sem o incremento, o contador podia terminar em valor negativo e pular parte da limpeza, incluindo a escrita de dados de profiling quando esse recurso estava habilitado. A [correção](https://github.com/ggml-org/llama.cpp/pull/26162) é pequena, mas seu efeito é fácil de reconhecer: uma execução pode parecer funcionar enquanto perde o registro necessário para entender seu custo.

Profiling não muda a resposta gerada. Ele permite saber onde o tempo foi gasto, comparar versões e decidir se uma otimização realmente deslocou o gargalo. Se essa evidência desaparece ao encerrar o programa, a equipe fica com uma impressão de desempenho, não com uma medição reproduzível.

As três mudanças formam um teste simples para qualquer atualização de inferência local:

1. O caminho rápido funciona com os pesos e o hardware reais?
2. As saídas estruturadas chegam à camada que toma ações?
3. As métricas sobrevivem até o fim da execução?

Uma IA local madura não é a que apenas produz uma resposta depressa. É a que consegue propor trabalho sem desperdiçá-lo, transformar saída em ação sem adivinhar o protocolo e deixar evidência suficiente para que a próxima decisão seja melhor que a anterior.