Moonshot Kimi Blog→ original

Moonshot publica Kimi Vendor Verifier: 6 pruebas para verificar a los proveedores de K2.6

Con el lanzamiento de Kimi K2.6, Moonshot ha liberado el código de Kimi Vendor Verifier (KVV). Se trata de un conjunto de pruebas que comprueba si los proveedores externos ejecutan correctamente los pesos abiertos del modelo. El motivo fueron las discrepancias en los benchmarks entre la API oficial y las implementaciones de terceros. Unas se deben a parámetros de decodificación incorrectos y otras a errores de infraestructura. Las cifras de referencia de la API de Kimi son: OCRBench 91.0, AIME2025 98.4 y MMMU Pro Vision 78.8. La ejecución completa tarda unas 15 horas en dos servidores con 8 NVIDIA H20 cada uno. • Seis pruebas: desde los parámetros de la API hasta el código agéntico • SWE-Bench no se ha publicado por depender de un sandbox • Moonshot promete un leaderboard público de proveedores

Procesado por IA desde Moonshot Kimi Blog; editado por Hamidun News
Moonshot publica Kimi Vendor Verifier: 6 pruebas para verificar a los proveedores de K2.6
Fuente: Moonshot Kimi Blog. Collage: Hamidun News.
◐ Escuchar artículo

Junto con el modelo Kimi K2.6, Moonshot AI ha publicado en abierto Kimi Vendor Verifier (KVV), un conjunto de pruebas para comprobar con qué precisión reproducen los proveedores externos el comportamiento del modelo. La ejecución completa tarda unas 15 horas en dos servidores con ocho NVIDIA H20 cada uno. Los resultados de referencia de la API oficial de Kimi son 91.0 en OCRBench, 98.4 en AIME2025 (avg@32) y 78.8 en MMMU Pro Vision. Ahora cualquiera puede comparar su propio despliegue con ellos.

Cómo surgió el problema

Tras el lanzamiento de K2 Thinking, Moonshot empezó a recibir con regularidad quejas sobre resultados extraños en los benchmarks. El análisis mostró que una parte considerable de los casos se debía a parámetros de decodificación incorrectos. La primera línea de defensa se colocó en la API: en el modo Thinking se fijan de forma obligatoria Temperature=1.0 y TopP=0.95, y además se comprueba que el contenido de los «razonamientos» se devuelva correctamente en la solicitud.

Después aparecieron anomalías más sutiles. En una de las pruebas con LiveBenchmark, una API de terceros quedó claramente por detrás de la oficial. La revisión de distintos proveedores de infraestructura reveló que esa brecha aparece en todas partes. La conclusión del blog de Moonshot es esta: cuanto más libres son los pesos y más variados los canales de despliegue, peor se controla la calidad. Si el usuario no distingue un defecto del propio modelo de un error de implementación, la confianza en los modelos abiertos se desploma.

Las seis pruebas

El conjunto está diseñado para que cada prueba detecte una clase concreta de fallos:

  • Pre-Verification comprueba que la API respeta de verdad las restricciones sobre temperature, top_p y otros parámetros. Sin superar esta fase no se avanza.
  • OCRBench funciona como una prueba de humo de cinco minutos para el pipeline multimodal.
  • MMMU Pro verifica el preprocesamiento de imágenes con entradas visuales variadas.
  • AIME2025 exige una generación larga. Destapa errores del KV-cache y degradación por cuantización que las pruebas cortas no detectan.
  • K2VV ToolCall mide la estabilidad con que se activa la llamada a herramientas (F1) y la precisión del JSON Schema. En los agentes, los errores con herramientas se acumulan, por lo que conviene detectarlos pronto.
  • SWE-Bench evalúa código agéntico completo. No se incluyó en el código abierto porque depende de un sandbox.

Por separado, Moonshot trabaja con las comunidades de vLLM, SGLang y KTransformers para corregir las causas de fondo en los motores de inferencia, y no solo registrar los síntomas. Además, la compañía da a los proveedores acceso anticipado a los modelos antes del lanzamiento, para que puedan validar sus stacks. También promete un leaderboard público de proveedores. La idea es que la transparencia los obligue a vigilar la precisión.

Lo que cuesta verificar y qué hacer en la práctica

Moonshot ejecutó todo el proceso en dos servidores con 8 NVIDIA H20 cada uno, y la ejecución secuencial llevó unas 15 horas. Los scripts están optimizados para inferencia larga: incluyen salida en streaming, reintentos automáticos y reanudación desde un punto de control. Esto importa porque la ejecución de AIME2025, con un límite de unos 98 mil tokens, se interrumpe fácilmente por un fallo de red.

Los ajustes de referencia figuran en la tabla de resultados oficiales: Temperature 1.0, TopP 0.95 y límites de tokens de 16 384 para OCRBench, 98 304 para AIME2025 y 65 536 para MMMU Pro Vision.

Para los equipos que usan K2.6 a través de un proveedor externo, el orden de actuación es sencillo. Primero, ejecutar Pre-Verification; después, la prueba de humo con OCRBench, y solo a continuación lanzar las pruebas largas y costosas. Si los resultados se alejan de las referencias 91.0, 98.4 y 78.8, conviene buscar primero la causa en los parámetros de decodificación, la cuantización y el manejo del contexto largo. Las conclusiones sobre una debilidad del propio modelo deben dejarse para el final.

Para los proveedores, KVV ofrece una lista de comprobación lista para usar antes del lanzamiento. Moonshot reconoce, no obstante, que la cobertura de proveedores aún es incompleta y busca pruebas agénticas más ligeras. Sin ellas, SWE-Bench sigue siendo la verificación más estricta, pero también la que no se puede reproducir por cuenta propia.

ZK
Hamidun News
Noticias de AI sin ruido. Selección editorial diaria de más de 50 fuentes. Producto de Zhemal Khamidun, Head of AI en Alpina Digital.
✦ Unified AI Workspace

Access Frontier LLMs & Multimodal AI in One Workspace

Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.

Try NomadNet AI →Launch NomadNet Agent
¿Qué te parece?
Cargando comentarios…