Kimi Vendor Verifier - Vérifier l’exactitude des fournisseurs d’inférence

• Kimi Vendor Verifier (KVV) est un outil public conçu pour vérifier les écarts d’implémentation de l’inférence qui apparaissent sur différentes infrastructures après le déploiement d’un modèle open source, afin de distinguer les limites du modèle lui-même des erreurs d’ingénierie
• Sur la base de l’API officielle, il affiche OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8, et publie également les réglages Temperature, TopP, MaxTokens de chaque évaluation ainsi que les fichiers de résultats d’évaluation K2VV
• L’enquête menée sur les anomalies de benchmark signalées par la communauté a montré qu’une grande partie provenait d’un mauvais usage des paramètres de décodage ; en mode Thinking, Temperature 1.0 et TopP 0.95 sont imposés, avec une vérification de la retransmission correcte du contenu
• La procédure de validation repose sur une pré-vérification des contraintes de paramètres, puis sur des contrôles via OCRBench, MMMU Pro, AIME2025, K2VV ToolCall, SWE-Bench, etc., couvrant le prétraitement Vision, les sorties longues, l’appel d’outils et jusqu’au code agentique
• L’ensemble du workflow nécessite environ 15 heures en exécution séquentielle sur deux serveurs NVIDIA H20 8-GPU, et l’équipe veut favoriser la diffusion d’une validation axée sur l’exactitude grâce à un leaderboard public et à un accès anticipé

---

Reconstruire une chaîne de confiance (Chain of Trust)

• Avec la publication du code source de Kimi Vendor Verifier (KVV), l’outil a été conçu pour permettre aux utilisateurs de modèles open source de vérifier l’exactitude de l’implémentation de l’inférence
• Il a été publié en même temps que le modèle Kimi K2.6 ; publier le modèle seul ne suffit pas, il faut aussi vérifier qu’il fonctionne correctement dans des environnements variés
• À mesure que l’écosystème des modèles open source publie les poids et multiplie les voies de déploiement, une structure apparaît où la capacité de contrôle qualité diminue
• Si les utilisateurs ne peuvent pas distinguer une défaillance de performance du modèle lui-même d’un écart d’implémentation technique, la confiance envers l’écosystème open source peut s’effondrer

Méthode de résolution

• Des anomalies individuelles vers un problème structurel

  • Depuis la publication de K2 Thinking, la communauté a fréquemment remonté des retours concernant des anomalies dans les scores de benchmark
  • L’enquête a montré qu’une part importante des cas provenait d’un mauvais usage des paramètres de décodage
  • Une première ligne de défense a été immédiatement mise en place au niveau API
    • En mode Thinking, Temperature=1.0 et TopP=0.95 sont imposés
    • Une vérification obligatoire s’assure que le contenu thinking est correctement retransmis
  • Sur certaines évaluations LiveBenchmark, un écart important a été observé entre des API tierces et l’API officielle
  • Des tests étendus auprès de divers fournisseurs d’infrastructure ont confirmé que ces écarts étaient largement répandus

• Procédure de validation et exploitation

  • Publication des scores de benchmark de référence de l’API officielle
    • Précision OCRBench : 91.0
    • AIME2025 avg@32 : 98.4
    • Précision MMMU Pro Vision : 78.8
  • Les paramètres d’évaluation sont également indiqués
    • Pour les trois évaluations, Temperature 1.0 et TopP 0.95 sont utilisés
    • MaxTokens : OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
  • Un lien vers les fichiers de résultats d’évaluation K2VV de l’API Kimi est fourni, avec mention de leur usage pour le calcul du score F1
  • Mise en place d’une étape de Pre-Verification
    • Vérification que les contraintes de paramètres API comme temperature et top_p sont correctement imposées
    • Les évaluations de benchmark ne sont lancées qu’après réussite de tous les tests
  • Utilisation d’OCRBench
    • Sert de smoke test de 5 minutes pour les pipelines multimodaux
  • Utilisation de MMMU Pro
    • Vérifie le prétraitement des entrées Vision via divers tests d’entrées visuelles
  • Utilisation de AIME2025
    • Sert de stress test pour les sorties longues
    • Permet de détecter des bugs de cache KV et des baisses de performance liées à la quantification qui n’apparaissent pas dans les benchmarks courts
  • Utilisation de K2VV ToolCall
    • Mesure la cohérence du déclenchement (F1) et l’exactitude du JSON Schema
    • Permet une détection précoce avant l’accumulation d’erreurs d’outils dans les agents
  • Utilisation de SWE-Bench
    • Sert de test complet de code agentique
    • N’est pas open source en raison de dépendances au sandbox
  • Travail mené avec les communautés vLLM, SGLang et KTransformers
  • L’objectif n’est pas seulement de détecter les symptômes, mais de corriger les causes profondes
  • Au lieu d’attendre les plaintes après déploiement, un accès anticipé est fourni aux fournisseurs d’infrastructure
  • Chaque fournisseur peut ainsi valider sa propre stack avant que les utilisateurs ne rencontrent des problèmes
  • Un leaderboard public des résultats des vendors sera maintenu dans la durée
  • Cette transparence est conçue pour inciter les vendors à donner la priorité à l’exactitude
  • La validation du workflow complet d’évaluation est terminée
    • Utilisation de deux serveurs NVIDIA H20 8-GPU
    • Environ 15 heures en exécution séquentielle
  • Des optimisations de script ont été appliquées pour les scénarios d’inférence longue durée
    • inférence en streaming
    • retries automatiques
    • mécanisme de reprise sur checkpoint inclus
  • Le principe affirmé est que, puisque les poids sont publiés, le savoir-faire nécessaire pour les exécuter correctement doit lui aussi être rendu public
  • Extension de la couverture des vendors et exploration de tests agentiques plus légers en cours