Cómo leer esto (y por qué tres corridas)
Una sola pasada de benchmark miente: un modelo tiene un momento de suerte o de mala suerte y la tabla cuenta la historia equivocada. Todo lo que sigue son tres corridas por celda, calificadas contra una respuesta correcta conocida, igual que nuestra suite de pruebas estándar califica a cada modelo. “Aprueba” significa coincidencia exacta o validador aprobado, no una impresión. Donde un resultado es indicativo y no definitivo, lo decimos.
C1: calidad bruta del modelo (suite de 7 pruebas, ×3)
| Modelo | Aprobó | Latencia prom. | Dónde perdió |
|---|---|---|---|
| Kimi-K2.7-Code | 21/21 | 2.2s | — (perfecto + el más rápido) |
| GPT-5 | 21/21 | 6.6s | — |
| Opus 4.8 | 16/21 | 3.2s | tool_use, code |
| Kimi-K2.6 (deepinfra) | 7/21 | 42.7s | falla del proveedor: vea abajo |
Kimi K2.7-Code empató con GPT-5 con un 21/21 perfecto, y fue el modelo más rápido del grupo (2.2s en promedio frente a 6.6s de GPT-5). Ese es el titular, y se sostuvo al repetir: en esta suite, por medición y no por publicidad, Kimi compite con los modelos de frontera.
El 7/21 de Kimi-K2.6 no es una falla del modelo: es una falla del proveedor. El mismo modelo obtuvo 21/21 con otro proveedor de servicio (vea C2). Un endpoint estaba agotando el tiempo de espera y devolviendo respuestas vacías; lo atribuimos a la capa de servicio, no a Kimi. (El 16/21 de Opus fue una mala corrida en un solo endpoint y un solo día: nuestra Deep Suite, más larga, le da una puntuación más alta; no le dé demasiado peso a una sola comparación).
C2: mismo modelo, distinta fuente: ¿gana el proveedor original?
| Fuente | Aprobó | Latencia prom. |
|---|---|---|
| Kimi-K2.6 vía fireworks | 21/21 | 9.9s |
| kimi-for-coding (Kimi directo) | 18/21 | 4.8s |
| Kimi-K2.6 vía deepinfra | 7/21 | 42.7s |
Lo natural es suponer que ir directo con el fabricante del modelo da el mejor resultado. No fue así. Usar Kimi directo para la inferencia no dio ninguna ventaja de calidad: un proveedor de servicio externo incluso le ganó en tasa de aprobación en esta corrida, y la única ventaja de la vía directa fue una menor latencia. La lección se generaliza: la capa de servicio importa más que la fuente. Elija un proveedor por su confiabilidad y su latencia, no por el logotipo que tiene el endpoint. (Es la misma tesis sobre la capa de servicio que nuestra revisión de la inferencia administrada). El valor real de Kimi directo no es su API: es la Code CLI con una suscripción de tarifa fija, que es justo lo que pone a trabajar la siguiente prueba.
C3: el duelo de harness: Kimi Code CLI frente a claude -p
Esta es la que importa estratégicamente. Pusimos la Kimi Code CLI de Moonshot, su harness de agentes, frente a claude -p (el Claude Agent SDK con Sonnet 4.6), con calificación y tres corridas cada uno.
| Tarea | Kimi Code CLI | claude -p (Sonnet) |
|---|---|---|
| razonamiento (17×23) | 3/3 · 4.0s | 3/3 · 2.0s · $0.087 |
| probabilidad condicional | 3/3 · 5.1s | 1/3 · 1.9s · $0.152 |
| código (palíndromo) | 3/3 · 5.4s | 3/3 · 2.9s · $0.149 |
La repetición cambió la historia. Kimi Code CLI sacó 9/9; claude -p sacó 7/9: falló la trampa de probabilidad condicional dos de tres veces (el clásico error de P(ambas | al menos una roja)). Con una sola pasada lo habríamos llamado empate; tres corridas mostraron que el agente de Kimi fue más confiable aquí en esa trampa de razonamiento.
Las concesiones son reales y van en los dos sentidos: claude -p fue más o menos el doble de rápido en tiempo de reloj (Kimi razona de forma más visible antes de responder). Pero en costo la brecha es estructural, no gradual, y ese es todo el punto.
La base de costo es la verdadera historia
En ese duelo, claude -p costó $0.087–$0.152 por tarea, facturado por consumo, por token. La Kimi Code CLI corrió con un plan de tarifa fija: su costo marginal por tarea es prácticamente cero, porque el plan funciona por ventanas de cuota, no por token. Con volumen, eso es el impuesto de tokens en una sola tabla.
No ponemos un falso equivalente facturado por consumo para el lado de tarifa fija, porque no hay uno honesto que poner: un plan fijo tiene un precio mensual fijo y una ventana de uso, y el punto de equilibrio depende por completo de su volumen. El planteamiento honesto es un intercambio, no un ganador: velocidad y una API conocida de un lado, confiabilidad en la trampa de razonamiento y una factura fija del otro. Este es justo el tipo de intercambio que nuestra consola de revisión ahora mide directamente: el harness de Kimi es un candidato seleccionable junto a claude -p en la misma corrida calificada.
Conclusión, después de tres corridas
- Kimi K2.7-Code compite con los modelos de frontera y es rápido. 21/21 empata con GPT-5, con la latencia más baja del grupo. La versión medida más sólida de “Kimi está avanzando”.
- La capa de servicio le gana a la fuente. El mismo modelo fue de 21/21 a 7/21 dependiendo solo de quién lo servía. Ir directo no dio ninguna ventaja en la inferencia: elija el proveedor, no el logotipo.
- En la capa de agentes fue el intercambio que esperábamos. Kimi se sostuvo mejor en la trampa de razonamiento (9/9 frente a 7/9);
claude -pfue más rápido, pero facturado por consumo. La decisión real es velocidad frente a modelo de facturación y confiabilidad.
El estándar de honestidad (salvedades)
- Tres corridas por celda suavizan la mayor parte de la variación, pero no son infinitas; un resultado de 1/3 o 2/3 es indicativo, no la última palabra.
- La latencia es tiempo de reloj e incluye la cola del proveedor, no la velocidad pura del modelo: la cifra de 42s está inflada por largos flujos de razonamiento y por tiempos de espera agotados en un endpoint que fallaba.
- El costo marginal del lado de tarifa fija es de ~$0, pero el plan es una cuota mensual fija: el punto de equilibrio depende del volumen, así que “más barato” depende de cuánto use.
- La falla del proveedor es un problema de servicio que hay que volver a probar en la próxima instantánea, no una señal de la calidad de Kimi, y le bajaremos la calificación al endpoint que falla si persiste.
El método es el producto. Publicamos lo que de verdad devolvió el benchmark, incluidas las partes que complican un titular limpio, porque una comparación a la que no se le pueden encontrar huecos es la única que vale la pena correr.