A qualidade que você obtém de um modelo de código aberto não depende só do modelo
Quando a Ubicloud começou a servir o Kimi K2.6 com o motor de inferência vLLM, os números pareciam razoáveis à primeira vista: o modelo respondia rápido, consumia GPUs de forma eficiente e entregava resultados coerentes. Mas havia um problema silencioso que só aparecia sob pressão — apenas 92% das chamadas de ferramenta eram válidas. Isso significa que, a cada 25 tentativas, duas falhavam porque o modelo gerava um JSON malformado, um nome de parâmetro errado ou um schema que simplesmente não correspondia ao que o código de orquestração esperava.
Para uma aplicação de chat tradicional, 92% soa como sucesso. Para um agente de IA autônomo que precisa executar múltiplas chamadas em sequência, é uma falha crítica. Cada tool call inválido gera contexto incorreto, que leva a mais tool calls errados, e o modelo entra em espiral de confusão — o que os engenheiros da Ubicloud chamam de "contexto nonsensical".
O que a Ubicloud descobriu, e publicou em 20 de outubro de 2026, é que o motor de inferência importa tanto quanto o modelo para a experiência final do usuário. E a solução — uma técnica chamada constrained decoding, que o próprio vLLM introduziu como recurso oficial na versão 0.31 — pode mudar a relação entre provedores open-weight e os modelos que servem.
Por que tool-calling quebra tão frequentemente
Aqui está o paradoxo: modelos como o Kimi K2 foram treinados especificamente para fazer tool calls com alta fidelidade. Durante o treinamento, eles viram milhares de exemplos de chamadas de ferramentas sintéticas em diversos formatos. Quando você roda o modelo na API original da Moonshot AI, a taxa de sucesso é próxima de 100%. Mas quando você roda o mesmo modelo com o vLLM — um dos engines de inferência mais populares para modelos open-source — a taxa cai significativamente.
A Ubicloud isolou o problema até o nível do token. O que acontece é que o modelo, ao gerar uma chamada de ferramenta, precisa seguir um schema JSON que foi fornecido no prompt. Mas como os LLMs são probabilísticos — eles não executam um compilador nem um type checker — o modelo pode gerar um nome de ferramenta que existe no conjunto de treino, mas não está na lista atual. Um campo chamado `city_name` quando o schema espera `location`. Um bloco JSON envolto em markdown code blocks quando o parser não espera isso.
O problema se complica quando você combina modelos diferentes. O blog da vLLM documentou um caso similar ao testar o Kimi K2 no próprio vLLM: a taxa de sucesso inicial caiu abaixo de 20%. Os três problemas identificados foram: o parâmetro `add_generation_prompt` sendo descartado silenciosamente porque o tokenizer do Kimi o declarava via `**kwargs`, o que o vLLM ignora por segurança; um campo `content` vazio quebrando a formatação do prompt; e um parser de tool-call IDs tão rígido que rejeitava IDs válidos em edge cases.
Cada um desses problemas foi corrigido individualmente — com contribuições direto ao time da Moonshot AI e PRs enviados ao vLLM. O resultado final foi de 83,57% de F1 score, longe dos 100% da API nativa. Mas ainda não era suficiente para workloads agênticos de produção.
O que é constrained decoding e por que ele importa
O constrained decoding é uma técnica de decodificação que força o modelo a gerar apenas tokens que são sintaticamente válidos de acordo com um schema. Em vez de deixar o modelo gerar livremente e depois tentar validar o resultado, o constrained decoding atua no nível do tokenizer: a cada passo, ele restringe o vocabulário de tokens permitidos ao que é compatível com o schema JSON da ferramenta.
Imagine que você está ditando algo para alguém, mas em vez de deixar a pessoa falar qualquer coisa, você dá a ela uma lista de palavras exatas que ela pode usar em cada posição. É exatamente isso que o constrained decoding faz com o JSON: em vez de "gere um objeto JSON válido", ele diz "a próxima palavra deve ser essa, e essa, e essa".
A Ubicloud testou o constrained decoding com o Kimi K2.6 e o DeepSeek V4 Flash no benchmark K2VV ToolCall da Moonshot AI — um benchmark de 2.000 requests que mede tanto quando o modelo decide chamar uma ferramenta quanto se a chamada está sintaticamente correta. Com o constrained decoding ativado, ambos os modelos atingiram 100% de schema accuracy. O número exato que a API nativa alcançava.
Isso não é apenas uma vitória técnica. É uma mudança de paradigma na forma como pensamos sobre a qualidade de modelos open-source. Historicamente, a suposição era que a diferença entre a API de um fornecedor e a versão open-weight era marginal. Mas a Ubicloud mostra que, para workloads agênticos, a diferença é visível e mensurável.
O que isso significa para o ecossistema
A história do tool-calling no vLLM revela algo que poucos estavam dispostos a admitir: a infraestrutura de inferência não é neutra. Dois deployments do mesmo modelo, com as mesmas weights, podem produzir resultados drasticamente diferentes dependendo do motor de inferência, do parser de tool-calls e das configurações de decoding.
Para empresas que estão construindo agentes de IA com modelos open-source, isso é uma lição prática de que a escolha do engine de inferência é tão crítica quanto a escolha do modelo. Se você está servindo o Kimi K2.6, o DeepSeek V4 Flash ou qualquer outro modelo com capacidades agênticas robustas, rodar sem constrained decoding pode estar custando até 8% de sucesso em chamadas de ferramenta — e isso é só a primeira rodada.
O constrained decoding ainda tem limitações: há bugs de interação com outros recursos do vLLM, e nem todos os modelos suportam a feature nativamente. Mas a trajetória é clara — à medida que os engines de inferência amadurecem, a linha entre a API nativa e o deploy open-weight deve se tornar cada vez mais indistinguível.
O que fica é a constatação de que, no mundo dos LLMs, a qualidade que chega ao usuário final é o produto do modelo, do engine, do parser e do schema — e otimizar apenas um desses elementos não é mais suficiente.
Fontes: Ubicloud, vLLM Blog, GitHub — vLLM Issue
✓ Fontes independentes cruzadas e verificadas antes da publicação
