Ubicloud mostra como corrigir a precisão de tool calls no vLLM

A Ubicloud serviu o Kimi K2.6 com vLLM 0.28 e mediu, no benchmark K2VV ToolCall da Moonshot AI, que só 92% das tool calls seguiam o schema. Na prática, 2 de cada 25 chamadas falhavam. Em fluxos de agentes com várias interações, cada falha joga mensagem de erro no contexto, derruba a qualidade e ainda custa mais, porque o agente precisa tentar de novo.

A causa é a natureza probabilística do modelo, que não roda compilador nem type checker. Ele pode gerar search_web quando a ferramenta se chama web_search, ou city_name quando o schema pede location. O constrained decoding resolve isso mascarando, a cada passo, os tokens inválidos. O vLLM usa structural tags da biblioteca XGrammar, que define o caminho válido: início da chamada, nome da tool, índice, início dos argumentos, JSON restrito ao schema e fim da chamada. Segundo a Ubicloud, o overhead é desprezível.

Houve um desvio no caminho. Depois que o recurso entrou no vLLM v0.25, a Ubicloud migrou do seu fork para o upstream e viu a precisão cair para 91%. A implementação estava correta, mas o vLLM passou a deixá-lo desligado por padrão, por ser um motor agnóstico a modelos. A flag --tool-strict-level permite ativá-lo, e o recurso saiu como flag de servidor no vLLM 0.31. Com ele, a empresa chegou a 100% de schema accuracy em Kimi e DeepSeek (o texto cita DeepSeek V4 Flash).

Para quem opera inferência própria de modelos open-weight, a leitura é que a qualidade percebida depende do motor e das flags, não só do modelo. Se o resultado em produção destoa dos benchmarks, vale checar o padrão do servidor antes de culpar o modelo. E 100% de schema accuracy garante chamada bem formada, não chamada útil, então ainda é preciso avaliar a decisão do agente.