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

 (kimi.com)
3 points par GN⁺ 2026-04-23 | 2 commentaires | Partager sur WhatsApp
  • 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

À lire aussi

2 commentaires

 
ng0301 2026-04-23

J’espère vraiment que ce projet va bien marcher.
 
GN⁺ 2026-04-23
Avis sur Hacker News
  • J’aime bien cette idée. Cela semble pouvoir exercer une pression sociale assez efficace pour pousser les fournisseurs d’inférence à corriger des problèmes de longue date. Par exemple, AWS Bedrock a un défaut critique dans sa stack de serving des modèles K2 et K2.5 de Kimi : dans 20 % à 30 % des tentatives où un appel d’outil devrait être émis, la conversation se termine silencieusement sans aucune sortie de tokens. Du coup, AWS devient de fait sans intérêt comme fournisseur d’inférence sérieux pour Kimi, et semble pousser les utilisateurs vers les modèles Anthropic, plus chers, pour des performances similaires sur les tâches agentiques
  • Le modèle de menace que j’en retiens semble viser surtout à empêcher les dégradations de performance accidentelles, pas à couvrir les acteurs malveillants. Par exemple, si un fournisseur louche prétend exécuter le tout dernier meilleur modèle mais utilise en réalité un modèle moins cher et moins performant pour empocher la différence, ce type de test risque de peu aider. S’il détecte qu’il est en phase de test, il peut faire en sorte que cela fonctionne correctement uniquement à ce moment-là, comme dans le scandale des émissions de Volkswagen
    • Des fournisseurs comme OpenRouter choisissent par défaut le fournisseur le moins cher, et s’il est moins cher, c’est souvent parce qu’il applique une quantification excessive et du tuning pour privilégier le débit à la qualité. Donc cela ressemble à une tentative de Kimi d’empêcher des fournisseurs low cost de nuire à la marque en ne représentant pas fidèlement les performances du modèle
    • Même ne détecter que la dérive accidentelle a déjà beaucoup de valeur. C’est presque la même idée que les tests de régression de performance en CI : on ne les utilise pas parce qu’on s’attend à ce que quelqu’un casse volontairement le système, mais pour détecter des problèmes ordinaires, du genre une dépendance mise à jour qui fait chuter le débit de 15 %. Si quelqu’un contourne volontairement la vérification, on est dans une situation juridiquement assez différente du simple fait de déployer discrètement une quantification moins chère
    • Oui et non, selon moi. Si l’acteur est vraiment malveillant, l’inquiétude est justifiée. Mais ce mécanisme transforme la situation de « quantifier le modèle sans le signaler n’est pas forcément une fraude évidente » en « faire passer la vérification avec un modèle, puis traiter les vraies requêtes clients avec un autre, c’est une fraude intentionnelle ». J’imagine qu’il existe beaucoup d’acteurs semi-malveillants prêts à aller jusqu’au premier cas, mais pas au second
    • Cela ressemble à un défi assez pertinent pour ce genre de systèmes. Par exemple, cela me fait penser au cas où fromtier labs sert des modèles quantifiés sous forte charge
  • C’était aussi un vrai problème dans nos benchmarks. Il faut se méfier des fournisseurs OpenRouter qui ne précisent pas leur niveau de quantification, ou qui utilisent un niveau plus bas que prévu. OpenRouter propose bien des options de configuration à ce sujet, mais cela réduit souvent fortement le choix. Indépendamment de cela, même chez les meilleurs fournisseurs, Kimi-K2-thinking s’est montré plutôt décevant et lent dans nos benchmarks, même s’il était intéressant et utile du point de vue de la température et de la variété. En revanche, Kimi K2.6 semble pour l’instant être le nouveau leader open source. Une évaluation agentique est également en cours, et le benchmark de raisonnement de code en one-shot est déjà prêt
    • OpenRouter a une option exacto qui permet de privilégier des fournisseurs de meilleure qualité pour certains modèles. Je me demande si tu as déjà constaté un avantage en l’utilisant. Et comme Kimi K2 utilise de l’int4 à la fois pour l’entraînement et l’inférence, en lisant cette discussion, je me dis que différents créateurs de gguf peuvent faire des conversions différentes, ce qui pourrait aussi affecter la qualité
  • Un test qui tourne 15 heures sur du matériel haut de gamme n’est pas facile à reproduire ni à faire évoluer. Cela dit, il touche juste sur une inquiétude très répandue à travers de nombreux services cloud : ce que j’ai pingé n’est pas forcément ce que je reçois réellement
    • Selon mon interprétation, la première cible de ce test n’est pas l’utilisateur, mais le vendeur lui-même. S’il est long et complet, c’est, je pense, pour donner au vendeur confiance dans la qualité de son hébergement en propre
    • Je pense qu’il suffit de lancer toute la suite une première fois pour chaque vendeur, puis de faire tourner les différentes parties toutes les deux ou quatre semaines en imitant des schémas d’usage ordinaires. Cela permettrait de garder l’évaluation à jour dans le temps
  • Ravi que ce type d’outil existe. Les fournisseurs d’inférence changent souvent discrètement le niveau de quantification, et la plupart des utilisateurs ne vérifient même pas. Un vérificateur standard publié par le créateur du modèle est probablement ce qui s’approche le plus de la bonne réponse, et j’aimerais que d’autres labos fassent quelque chose de similaire
  • Le billet connexe de fireworks.ai expliquant pourquoi ce type de vérificateur est nécessaire quand on exploite des modèles à poids ouverts vaut aussi le détour : quality-first with kimi k2p5
  • Il est notable que, comme Anthropic, Moonshot soit aussi un fournisseur de modèles qui limite l’ajustement des paramètres d’échantillonnage. Cela dit, j’aime bien l’idée même du vendor verifier
    • Je me demande ce que signifie exactement ici « limiter l’ajustement des paramètres d’échantillonnage »
    • Si le post-entraînement a été fait avec certains paramètres d’échantillonnage, il me semble logique d’aligner l’usage réel sur les paramètres appris
  • Je trouve que c’est vraiment une excellente idée. J’exploite la passerelle IA Glama, et j’ai vu certains fournisseurs tiers mentir ouvertement à propos de la quantification, au point de tous les retirer du catalogue. Pouvoir vérifier les fournisseurs serait une grande amélioration, parce que cela permettrait de proposer avec plus de confiance une configuration de fournisseurs plus diversifiée
  • J’ai peur que, si les vendeurs commencent à optimiser pour les 6 benchmarks KVV, on finisse par mesurer uniquement la conformité au KVV plutôt que la fidélité réelle du modèle. Je me demande s’il existe une stratégie de rotation pour éviter cela