Verificador de proveedores de Kimi - Verificación de la exactitud del proveedor de inferencia

 (kimi.com)
3 puntos por GN⁺ 2026-04-23 | 2 comentarios | Compartir por WhatsApp
  • Kimi Vendor Verifier (KVV) es una herramienta pública diseñada para verificar las desviaciones en la implementación de inferencia que surgen en distintas infraestructuras tras el despliegue de modelos de código abierto, permitiendo distinguir entre las limitaciones propias del modelo y los errores de ingeniería
  • Con base en la API oficial, presenta OCRBench 91.0, AIME2025 avg@32 98.4, MMMU Pro Vision 78.8, y además publica en conjunto la configuración de Temperature, TopP y MaxTokens de cada evaluación, junto con el archivo de resultados de evaluación de K2VV
  • Al investigar anomalías de benchmark reportadas por la comunidad, concluyeron que una parte importante se debía al uso incorrecto de parámetros de decodificación; en modo Thinking, además, se aplica la imposición de Temperature 1.0 y TopP 0.95, junto con verificación de reenvío correcto del contenido
  • El procedimiento de verificación sigue una estructura que, tras una validación previa para confirmar restricciones de parámetros, utiliza OCRBench, MMMU Pro, AIME2025, K2VV ToolCall y SWE-Bench, entre otros, para revisar preprocesamiento de Vision, salidas extensas, llamadas a herramientas y hasta agentic coding
  • El flujo de trabajo completo toma unas 15 horas en ejecución secuencial sobre dos servidores NVIDIA H20 de 8 GPU, y mediante un leaderboard público y acceso anticipado busca impulsar la adopción de una verificación centrada en la exactitud

Reconstrucción de la cadena de confianza (Chain of Trust)

  • Con la publicación del código fuente de Kimi Vendor Verifier (KVV), se diseñó para que los usuarios de modelos de código abierto puedan verificar la exactitud de la implementación de inferencia
  • Se lanzó al mismo tiempo que el modelo Kimi K2.6, y se plantea que publicar el modelo por sí solo no basta, sino que también hace falta confirmar que funciona correctamente en distintos entornos
  • A medida que en el ecosistema de modelos abiertos avanza la publicación de pesos y se diversifican las vías de despliegue, queda en evidencia una estructura en la que disminuye la capacidad de control de calidad
  • Si los usuarios no pueden distinguir entre fallas de desempeño del propio modelo y desviaciones de implementación de ingeniería, la confianza en el ecosistema de código abierto podría colapsar

Forma de resolverlo

  • De anomalías individuales a un problema estructural

    • Tras la publicación de K2 Thinking, la comunidad comenzó a enviar con frecuencia comentarios sobre anomalías en puntajes de benchmark
    • La investigación confirmó que muchos de esos casos se originaban en el uso incorrecto de parámetros de decodificación
    • Como medida de mitigación inmediata, se estableció una primera línea de defensa a nivel API
      • En modo Thinking se imponen Temperature=1.0 y TopP=0.95
      • Se aplica una verificación obligatoria para asegurar que el contenido thinking se reenvíe correctamente
    • En ciertas evaluaciones de LiveBenchmark se observaron grandes diferencias entre APIs de terceros y la API oficial
    • Tras probar ampliamente a distintos proveedores de infraestructura, confirmaron que esas diferencias existen de forma generalizada

  • Procedimiento de verificación y operación

    • Publicación de métricas de benchmark con base en la API oficial
      • Precisión de OCRBench: 91.0
      • AIME2025 avg@32: 98.4
      • Precisión de MMMU Pro Vision: 78.8
    • También se especifican las configuraciones de evaluación
      • En los tres casos se usan Temperature 1.0 y TopP 0.95
      • MaxTokens: OCRBench 16384, AIME2025 98304, MMMU Pro Vision 65536
    • Se proporciona el enlace al archivo de resultados de evaluación K2VV de la API de Kimi, indicando que se usa para calcular la puntuación F1
    • Se opera una etapa de Pre-Verification
      • Verifica que se apliquen correctamente las restricciones de parámetros de API como temperature y top_p
      • Solo después de pasar todas las pruebas se ejecutan las evaluaciones de benchmark
    • Uso de OCRBench
      • Cumple la función de prueba rápida de 5 minutos para pipelines multimodales
    • Uso de MMMU Pro
      • Verifica el preprocesamiento de entradas Vision mediante pruebas con diversas entradas visuales
    • Uso de AIME2025
      • Funciona como prueba de estrés para salidas extensas
      • Detecta bugs de KV cache y degradación de rendimiento por cuantización que no aparecen en benchmarks cortos
    • Uso de K2VV ToolCall
      • Mide la consistencia de activación (F1) y la exactitud de JSON Schema
      • Permite detectar de forma temprana errores de herramientas antes de que se acumulen en agentes
    • Uso de SWE-Bench
      • Cumple el rol de prueba integral de agentic coding
      • No se libera como código abierto debido a dependencias de sandbox
    • Se trabaja junto con las comunidades de vLLM, SGLang y KTransformers
    • No se limita a detectar síntomas, sino que apunta a corregir la causa raíz
    • En lugar de esperar reclamos tras el despliegue, se ofrece acceso anticipado a proveedores de infraestructura
    • Así, cada proveedor puede verificar su propio stack antes de que los usuarios enfrenten problemas
    • Está previsto mantener de forma continua un leaderboard público de resultados por proveedor
    • Esto se diseñó para que dicha transparencia eleve la prioridad de la exactitud entre los proveedores
    • Se completó la validación del flujo de evaluación completo
      • Se usaron dos servidores NVIDIA H20 de 8 GPU
      • En ejecución secuencial, tomó aproximadamente 15 horas
    • Se aplicaron optimizaciones a los scripts para escenarios de inferencia prolongada
      • Inferencia en streaming
      • Reintentos automáticos
      • Mecanismo de reanudación por checkpoints incluido
    • Se deja explícito el principio de que, así como los pesos se publican, también debe publicarse el conocimiento para ejecutarlos correctamente
    • Siguen trabajando en ampliar la cobertura de proveedores y en explorar pruebas de agentic más ligeras

Lecturas relacionadas

2 comentarios

 
ng0301 2026-04-23

Ojalá que este proyecto salga realmente bien.
 
GN⁺ 2026-04-23
Comentarios de Hacker News
  • Me gusta esta idea. Parece que podría ser una forma bastante efectiva de presión social para obligar a los proveedores de inferencia a corregir problemas viejos. Por ejemplo, AWS Bedrock tiene una falla crítica en el stack de serving de los modelos K2 y K2.5 de Kimi, donde en el 20%~30% de los intentos que deberían emitir llamadas a herramientas la conversación simplemente termina en silencio sin salida de tokens. Así que AWS queda prácticamente inutilizable como proveedor de inferencia serio para Kimi, y da la impresión de que empuja a los usuarios hacia modelos de Anthropic más caros para obtener un rendimiento similar en tareas de agentes
  • El modelo de amenaza que entiendo aquí parece orientado a evitar degradaciones de rendimiento accidentales, no necesariamente a cubrir actores maliciosos. Por ejemplo, si algún proveedor sospechoso dice que corre el mejor modelo más reciente pero en realidad usa uno más barato y de peor rendimiento para quedarse con la diferencia, este tipo de prueba quizá no ayudaría mucho. Si detectan que están siendo evaluados, podrían hacer que solo en ese momento funcione bien, como en el escándalo de emisiones de Volkswagen
    • Proveedores como OpenRouter básicamente eligen al proveedor más barato, y muchas veces es barato porque tiene cuantización excesiva y tuning orientado al throughput más que a la calidad. Así que esto parece un intento de kimi por evitar que proveedores de saldo dañen la marca al no representar bien el rendimiento del modelo
    • Incluso si solo detecta drift accidental, ya tiene mucho valor. Es casi la misma idea que las pruebas de regresión de rendimiento en CI, y no se usa pensando en que alguien lo vaya a sabotear a propósito. Normalmente sirve para detectar problemas comunes, como que una actualización de dependencia baje el throughput un 15%. Si alguien evade deliberadamente la inspección, eso ya es una situación legalmente bastante distinta de simplemente servir en silencio una cuantización más barata
    • Sí y no. Si realmente hablamos de un actor malicioso, la preocupación es válida. Pero este mecanismo cambia la situación de “cuantizar el modelo sin avisar no necesariamente es un fraude evidente” a “pasar la validación con un modelo y atender a clientes reales con otro”, lo cual ya es fraude intencional. Probablemente haya muchos jugadores medio maliciosos dispuestos a hacer lo primero, pero no tanto lo segundo
    • Parece un reto bastante bueno para este tipo de sistemas. Por ejemplo, me hace pensar en casos donde fromtier labs sirve modelos cuantizados bajo alta carga
  • Esto también fue un problema real en nuestros benchmarks. Hay que tener cuidado con los proveedores de OpenRouter que no especifican su nivel de cuantización o usan uno más bajo de lo esperado. OpenRouter sí ofrece opciones de configuración para eso, pero entonces muchas veces se reduce bastante el abanico de opciones. Aun así, incluso usando los mejores proveedores, Kimi-K2-thinking fue algo decepcionante y lento en nuestros benchmarks, aunque resultó interesante y útil en términos de temperatura y variación. En cambio, Kimi K2.6 por ahora parece ser el nuevo líder open source. También estamos corriendo evaluaciones de agentes, y el benchmark de razonamiento para one-shot coding ya está listo
    • OpenRouter tiene la opción exacto para preferir proveedores de mayor calidad en ciertos modelos. Me pregunto si has visto beneficios al usarla. Además, como Kimi K2 supuestamente usa int4 tanto en entrenamiento como en inferencia, al ver esta discusión me da la impresión de que distintos creadores de gguf podrían estar haciendo conversiones diferentes que afecten la calidad
  • Una prueba que tarda 15 horas en hardware potente no parece fácil de reproducir ni de escalar. Aun así, toca una preocupación muy extendida en varios servicios cloud: el punto clave es que lo que yo hice ping puede no ser realmente lo que estoy recibiendo
    • Mi interpretación es que el primer destinatario de esta prueba es más bien el propio vendor, no el usuario. Entendí que la razón por la que la prueba es larga y exhaustiva es darle al vendor confianza sobre la calidad de su propio hosting
    • Yo correría el suite completo una vez por vendor, y luego iría rotando cada parte cada 2 o 4 semanas para imitar patrones de uso normales. Así podrías mantener la evaluación actualizada con el paso del tiempo
  • Me da gusto que esto exista. Los proveedores de inferencia suelen cambiar el nivel de cuantización por debajo de la mesa, y la mayoría de los usuarios ni siquiera lo verifica. Un validador estándar publicado por el creador del modelo parece lo más correcto, y ojalá otros laboratorios publiquen algo similar
  • También vale la pena ver el post relacionado de fireworks.ai que explica por qué se necesita este tipo de validador al operar modelos de pesos abiertos: quality-first with kimi k2p5
  • Llama la atención que, después de Anthropic, Moonshot también sea un proveedor de modelos que limita el ajuste de parámetros de sampling. Aun así, me gusta la idea del vendor verifier
    • Me pregunto qué significa aquí exactamente “limita el ajuste de parámetros de sampling”
    • Si el postentrenamiento se hizo con ciertos parámetros de sampling, me parece razonable que el uso real también se alinee con esos parámetros con los que fue entrenado
  • Esto me parece una idea realmente excelente. Yo opero el AI gateway Glama, y llegué a sacar por completo de la lista a algunos proveedores terceros porque vi que mentían descaradamente sobre la cuantización. Poder validar a los proveedores sería una gran mejora, porque permitiría ofrecer con más confianza una configuración más diversa de proveedores
  • Me preocupa que, si los vendors empiezan a optimizar para los 6 benchmarks de KVV, al final solo estemos midiendo cumplimiento con KVV y no fidelidad real del modelo. Me pregunto si existe alguna estrategia de rotación para evitar eso