Kimi Vendor Verifier - verificação da exatidão de provedores de inferência

• O Kimi Vendor Verifier (KVV) é uma ferramenta pública criada para verificar desvios de implementação de inferência que surgem em diferentes infraestruturas após a implantação de modelos open source, permitindo distinguir limitações do próprio modelo de erros de engenharia
• Com base na API oficial, apresenta OCRBench 91.0, AIME2025 avg@32 98.4 e MMMU Pro Vision 78.8, além de divulgar junto as configurações de Temperature, TopP e MaxTokens de cada avaliação, bem como o arquivo de resultados da avaliação K2VV
• Ao investigar anomalias de benchmark relatadas pela comunidade, concluiu-se que muitas delas se originavam do uso incorreto de parâmetros de decodificação; no modo Thinking, foram aplicados Temperature 1.0 e TopP 0.95 de forma obrigatória, além de validação de reenvio de conteúdo
• O procedimento de verificação é estruturado para, após uma pré-verificação destinada a confirmar restrições de parâmetros, usar OCRBench, MMMU Pro, AIME2025, K2VV ToolCall e SWE-Bench para inspecionar pré-processamento de Vision, saídas longas, chamadas de ferramenta e até agentic coding
• Todo o workflow leva cerca de 15 horas em execução sequencial em dois servidores NVIDIA H20 com 8 GPUs, e a iniciativa busca ampliar a verificação com prioridade à exatidão por meio de leaderboard público e acesso antecipado

---

Reconstruindo a Chain of Trust

• O Kimi Vendor Verifier (KVV) foi projetado, junto com a publicação do código-fonte, para permitir que usuários de modelos open source verifiquem a exatidão da implementação de inferência
• Foi lançado ao mesmo tempo que o modelo Kimi K2.6, com a premissa de que apenas abrir o modelo não basta e que é necessário confirmar se ele funciona corretamente em ambientes diversos
• À medida que o ecossistema de modelos open source avança na divulgação de pesos e na diversificação de caminhos de implantação, fica evidente uma estrutura em que a capacidade de controle de qualidade diminui
• Se os usuários não conseguirem distinguir entre falhas de desempenho do próprio modelo e desvios de implementação de engenharia, a confiança no ecossistema open source pode ruir

Forma de resolver

• De anomalias individuais para um problema estrutural

  • Após a divulgação do K2 Thinking, a comunidade passou a enviar com frequência feedback sobre anomalias nas pontuações de benchmark
  • A investigação mostrou que uma parte considerável dos casos vinha do uso incorreto de parâmetros de decodificação
  • Como medida imediata de mitigação, foi criada uma primeira linha de defesa no nível da API
    • No modo Thinking, Temperature=1.0 e TopP=0.95 são obrigatórios
    • Foi aplicada validação obrigatória para verificar se o conteúdo de thinking está sendo retransmitido corretamente
  • Em certas avaliações do LiveBenchmark, foi observada uma grande diferença entre APIs de terceiros e a API oficial
  • Testes amplos com vários provedores de infraestrutura confirmaram que essas diferenças estão amplamente presentes

• Procedimento de verificação e operação

  • Divulgação de métricas de benchmark com base na API oficial
    • Acurácia de OCRBench: 91.0
    • AIME2025 avg@32: 98.4
    • Acurácia de MMMU Pro Vision: 78.8
  • Os valores de configuração das avaliações também são informados
    • Nos três itens, são usados Temperature 1.0 e TopP 0.95
    • O MaxTokens é 16384 para OCRBench, 98304 para AIME2025 e 65536 para MMMU Pro Vision
  • É fornecido o link para o arquivo de resultados da avaliação K2VV da API Kimi, indicado para cálculo de pontuação F1
  • Há uma etapa de Pre-Verification
    • Verifica se restrições de parâmetros da API, como temperature e top_p, estão sendo corretamente impostas
    • A avaliação de benchmark só prossegue depois que todos os testes forem aprovados
  • Uso de OCRBench
    • Atua como smoke test de 5 minutos para pipelines multimodais
  • Uso de MMMU Pro
    • Verifica o pré-processamento de entradas de Vision por meio de diversos testes com entradas visuais
  • Uso de AIME2025
    • Atua como teste de estresse para saídas longas
    • Detecta bugs de KV cache e queda de desempenho por quantização que benchmarks curtos não revelam
  • Uso de K2VV ToolCall
    • Mede consistência de acionamento (F1) e exatidão de JSON Schema
    • Permite detecção antecipada antes que erros de ferramenta se acumulem em agentes
  • Uso de SWE-Bench
    • Atua como teste completo de agentic coding
    • Não será open-sourced devido à dependência de sandbox
  • Trabalho conjunto com as comunidades de vLLM, SGLang e KTransformers
  • O objetivo não é apenas detectar sintomas, mas corrigir as causas-raiz
  • Em vez de esperar reclamações após a implantação, os provedores de infraestrutura recebem acesso antecipado
  • Isso permite que cada provedor valide sua própria stack antes que os usuários enfrentem problemas
  • Está prevista a manutenção contínua de um leaderboard público para os resultados dos vendors
  • A proposta é que essa transparência leve os vendors a elevar a prioridade dada à exatidão
  • A validação de todo o workflow de avaliação foi concluída
    • Com uso de dois servidores NVIDIA H20 com 8 GPUs
    • Em execução sequencial, o processo leva cerca de 15 horas
  • Foram aplicadas otimizações aos scripts para cenários de inferência de longa duração
    • Inferência por streaming
    • Retry automático
    • Inclusão de mecanismo de retomada por checkpoint
  • Foi explicitado o princípio de que, assim como os pesos são públicos, o conhecimento necessário para executá-los corretamente também deve ser público
  • Estão em andamento a ampliação da cobertura de vendors e a busca por testes de agentic mais leves

[ng0301]

Tomara muito que esse projeto dê certo.

[GN⁺]

Comentários no Hacker News

• Gostei da ideia. Parece que isso pode ser uma forma bem eficaz de pressão social para fazer os provedores de inferência corrigirem problemas antigos. Por exemplo, o AWS Bedrock tem uma falha crítica na stack de serving dos modelos K2 e K2.5 da Kimi, em que 20% a 30% das tentativas que deveriam emitir chamadas de ferramenta simplesmente encerram a conversa em silêncio, sem saída de tokens. Com isso, a AWS praticamente deixa de ter utilidade como provedora séria de inferência para a Kimi, e parece acabar empurrando os usuários para os modelos da Anthropic, mais caros, para obter desempenho semelhante em tarefas agentic
  • Pelo que vejo, isso não é novidade; é algo que a Kimi já vem fazendo há meses. Já existiam o K2 Vendor Verifier e o Kimi Vendor Verifier, inclusive antes do lançamento do K2.5 e do K2.6
• Pelo que entendi, o modelo de ameaça aqui é mais para evitar degradação de desempenho por engano, não para cobrir agentes maliciosos. Por exemplo, se algum provedor suspeito disser que está rodando o melhor modelo mais recente, mas na prática usar um modelo mais barato e pior para embolsar a diferença, esse tipo de teste talvez não ajude muito. Se ele detectar que está sendo testado, pode simplesmente se comportar direito só naquele momento, como no escândalo de emissões da Volkswagen
  • Provedores como o OpenRouter basicamente escolhem o provedor mais barato, e muitas vezes ele é barato justamente porque usa quantização excessiva e tuning voltados para throughput em vez de qualidade. Então isso parece ser uma tentativa da Kimi de evitar que provedores de baixíssimo custo prejudiquem a marca ao não representarem corretamente o desempenho do modelo
  • Mesmo que só pegue drift acidental, já tem muito valor. A ideia é praticamente a mesma de um teste de regressão de desempenho em CI, e não foi feita esperando que alguém vá quebrar tudo de propósito. Normalmente serve para pegar problemas comuns, tipo atualizar uma dependência e de repente perder 15% de throughput. Se alguém estiver tentando burlar a checagem de propósito, isso já vira uma situação bem diferente, inclusive do ponto de vista jurídico, de apenas entregar discretamente uma quantização mais barata
  • Acho que sim e não. Se for um agente realmente malicioso, a preocupação faz sentido. Mas esse mecanismo muda a situação de "quantizar o modelo sem avisar não é fraude óbvia" para "passar na verificação com um modelo e atender as requisições reais dos clientes com outro", o que já é fraude intencional. Parece provável que existam muitos players meio mal-intencionados dispostos a fazer a primeira coisa, mas não a segunda
  • Isso parece um desafio bem interessante para esses sistemas. Por exemplo, lembra casos em que a fromtier labs serve modelos quantizados sob alta carga
• Isso também foi um problema real nos nossos benchmarks. Entre os provedores do OpenRouter, é bom tomar cuidado com os que não informam o nível de quantização ou usam um nível inferior ao esperado. O OpenRouter até oferece opções de configuração relacionadas a isso, mas aí muitas vezes as opções ficam bem mais limitadas. Fora isso, mesmo usando os melhores provedores, o Kimi-K2-thinking foi um tanto decepcionante e lento nos nossos benchmarks, embora tenha sido interessante e útil em termos de temperatura e variação. Já o Kimi K2.6, até agora, parece ser o novo líder open source. Também estamos rodando avaliações agentic, e o benchmark de raciocínio para coding em one-shot já está pronto
  • O OpenRouter tem a opção exacto para preferir provedores de maior qualidade em modelos específicos. Fico curioso se você já viu vantagem em usar isso. Além disso, o Kimi K2 usa int4 tanto no treinamento quanto na inferência, então, vendo essa discussão, dá a impressão de que diferentes criadores de gguf podem converter de formas diferentes e isso acabar afetando a qualidade
• Acho que um teste que roda por 15 horas em hardware de alto desempenho não é algo fácil de reproduzir nem de escalar. Ainda assim, ele toca muito bem numa preocupação disseminada em vários serviços de nuvem: a questão central é que aquilo para o qual eu dei ping pode não ser de fato aquilo que estou recebendo
  • Pela minha leitura, o primeiro alvo desse teste é mais o próprio fornecedor do que o usuário. Entendi que ele é longo e abrangente justamente para dar ao fornecedor confiança na qualidade do próprio hosting
  • Dá para rodar a suíte completa uma vez por fornecedor no começo e depois ir executando as partes em rotação a cada 2 ou 4 semanas, imitando padrões normais de uso. Assim, a avaliação pode continuar atualizada ao longo do tempo
• Fico feliz que isso exista. Provedores de inferência frequentemente trocam silenciosamente o nível de quantização, e a maioria dos usuários nem verifica. Um verificador padrão lançado pelo criador do modelo parece a abordagem mais correta, e seria ótimo se outros laboratórios também lançassem algo parecido
• Também vale a leitura do texto relacionado da fireworks.ai explicando por que esse tipo de verificador é necessário ao operar modelos de pesos abertos: quality-first with kimi k2p5
• É notável que, depois da Anthropic, a Moonshot também seja uma provedora de modelos que restringe o ajuste de parâmetros de sampling. Ainda assim, gosto da ideia de um vendor verifier em si
  • Fiquei curioso sobre o que significa exatamente "restringir o ajuste de parâmetros de sampling" aqui
  • Se o pós-treinamento foi feito com determinados parâmetros de sampling, acho razoável que o uso real também siga os parâmetros com que foi treinado
• Achei isso uma ideia realmente excelente. Eu opero o gateway de IA Glama, e já vi alguns provedores terceirizados mentindo descaradamente sobre quantização, a ponto de eu remover todos da lista. Se eu puder verificar os provedores, vou conseguir oferecer uma composição bem mais diversa de provedores com muito mais confiança, o que parece uma grande melhoria
• Minha preocupação é que, se os fornecedores começarem a se otimizar para os 6 benchmarks do KVV, no fim estaremos medindo apenas conformidade com o KVV, e não fidelidade ao modelo. Fico curioso se existe alguma estratégia de rotação pensada para evitar isso