Eficiencia de tokens de Kimi K3: velocidad, latencia y coste por tarea completada
Las cuatro preguntas ocultas tras «eficiencia»
| Pregunta | Métrica | Importancia |
|---|---|---|
| ¿Cuándo empieza? | Tiempo al primer token | Respuesta percibida y sensación de bloqueo. |
| ¿A qué velocidad genera? | Tokens de salida por segundo | Duración de respuestas y razonamientos largos. |
| ¿Cuántos tokens usa? | Entrada, caché, razonamiento y salida | Coste de llamadas del modelo. |
| ¿Cuánto trabajo completa? | Aceptación, reintentos y revisión | Valor útil creado. |
Un modelo puede generar rápido después de una larga espera, ser barato por token pero prolijo o parecer caro por petición y ahorrar al evitar reintentos. No lo reduzcas a «rápido» o «barato».
Variables de coste confirmadas de Kimi K3
Al 17 de julio de 2026, Moonshot publica:
| Categoría | Precio directo por 1 M de tokens | Uso |
|---|---|---|
| Entrada en caché | 0,30 $ | Repositorio, instrucciones o corpus estable con acierto real |
| Entrada sin caché | 3,00 $ | Prompt y contexto nuevo |
| Salida | 15,00 $ | Respuesta final y generación facturable según el canal |
Moonshot documenta 1.048.576 tokens de contexto y razonamiento siempre activo. Son útiles para tareas grandes y difíciles, pero hacen más importante seleccionar contexto y controlar salida. No son precios de EvoLink.
Por qué el debate inicial se centra en tokens de salida
Artificial Analysis midió inicialmente unos 62 tokens de salida por segundo, clasificó K3 como muy verboso e informó de unos 2.690,80 $ para su ejecución del Intelligence Index.
La instantánea demuestra por qué el precio unitario engaña, pero no garantiza velocidad o coste universal:
- es un entorno de terceros;
- prompts y ajustes cambian razonamiento y volumen;
- cola, rendimiento y caché varían por proveedor;
- producción puede usar más entrada y menos salida;
- un resultado aceptado vale más que varias respuestas cortas fallidas.
Úsala para justificar mediciones, no como veredicto de ruta.
Calcula correctamente el coste de lista
model_call_cost =
cached_input_mtokens * cached_input_rate
+ uncached_input_mtokens * uncached_input_rate
+ output_mtokens * output_rateEjemplo: prefijo de repositorio estable de 250K tokens, 25K tokens nuevos y 40K de salida.
| Escenario | Entrada en caché | Entrada nueva | Salida | Total directo |
|---|---|---|---|---|
| Primer uso sin acierto | 0,00 $ | 0,825 $ | 0,600 $ | 1,425 $ |
| Uso posterior con prefijo 250K en caché | 0,075 $ | 0,075 $ | 0,600 $ | 0,750 $ |
Con caché, la salida sigue siendo el 80 % del coste del modelo. Un fallo y un reintento parecido pueden duplicarlo antes de la revisión.
Fórmula de producción: coste por tarea completada
successful_task_cost =
initial_model_calls
+ retry_calls
+ fallback_calls
+ tool_costs
+ human_review_cost
+ defect_repair_costcost_per_success = total_workload_cost / accepted_tasks| Comportamiento | Apariencia por petición | Realidad por éxito |
|---|---|---|
| Respuesta corta barata que falla | Eficiente | Cara tras retry o fallback |
| Respuesta larga aceptada de una vez | Cara | Puede ser eficiente en trabajo difícil |
| Contexto largo en caché y salida controlada | Moderada | Puede funcionar bien para repositorios repetidos |
| Tarea lenta que bloquea un producto interactivo | Tokens asequibles | Operativamente inaceptable |
| Modelo premium en tarea fácil | Buena calidad | Desperdicio si un modelo pequeño basta |
Por eso K3 no debe ser el estándar automático para resúmenes, etiquetas o transformaciones simples. Su valor debe venir de dificultad, contexto, imagen o mejor aceptación.
Velocidad: mide la cronología completa
| Métrica | Inicio | Fin | Revela |
|---|---|---|---|
| Cola y conexión | Solicitud enviada | Respuesta aceptada | Sobrecarga de red/proveedor |
| Tiempo al primer token | Solicitud enviada | Primer token | Espera percibida y razonamiento inicial |
| Generación | Primer token | Último token | Rendimiento sostenido |
| Bucle de herramientas | Primera llamada | Último resultado | Coste de orquestación |
| Tiempo a candidato | Inicio de tarea | Modelo declara final | Productividad bruta |
| Tiempo a aceptado | Inicio de tarea | Tests y revisión pasan | Valor real en producción |
La última es la principal. Tres reparaciones rápidas pueden ser más lentas que una espera inicial más larga con resultado correcto.
Para productos interactivos fija por separado: tiempo al progreso visible, pausa máxima de herramientas, duración total, timeout/fallback y bucles máximos.
Eficiencia de tokens en agentes de código
También consumen al reenviar el repositorio, arrastrar herramientas antiguas, generar razonamiento largo, leer logs grandes, reintentar argumentos, reescribir archivos completos o llamar a un fallback premium.
| Etapa | Conteo | Señal |
|---|---|---|
| Tareas iniciadas | Todas | Demanda base |
| Candidatos | Llegan a respuesta o parche | Finalización bruta |
| Checks automáticos | Tests y validación pasan | Utilidad técnica |
| Revisión humana | Aceptado sin gran reescritura | Calidad de producción |
| Entregado o usado | Crea valor real | Eficiencia final |
Optimizar tokens por petición perdiendo resultados en el embudo es falsa eficiencia.
Prueba equivalente de eficiencia de K3
Usa 20–50 tareas reales en al menos cuatro categorías:
| Carga | Incluye | Aceptación |
|---|---|---|
| Frontend | Captura o briefing y restricciones | Rúbricas visual y técnica |
| Bugs | Defecto reproducible y tests | Causa corregida sin regresión |
| Análisis | Repositorio grande y preguntas precisas | Archivos correctos y respuesta útil |
| Agente con herramientas | Buscar, editar, terminal y tests | Uso válido y finalización sin ayuda |
| Síntesis documental | Corpus grande reutilizado | Conclusiones respaldadas y citas correctas |
task_id
model_route
prompt_version
cached_input_tokens
uncached_input_tokens
output_tokens
time_to_first_token
total_elapsed_time
retry_count
fallback_route
automated_pass
human_acceptance
review_minutesAl comparar K3 con otro modelo, mantén prompt, estado, herramientas, timeout y rúbrica.
Cómo la caché cambia el rol de enrutamiento
Buenos candidatos: convenciones y arquitectura, requisitos estables, corpus largo, instrucciones y documentación de herramientas o un workspace persistente.
La caché ayuda menos si cada solicitud cambia el contexto o el prefijo. Comprueba tokens realmente facturados como caché.
| Patrón | Implicación para K3 |
|---|---|
| Prefijo grande estable, muchas tareas | Buen candidato si aciertos y aceptación se mantienen |
| Prefijo cambia cada vez | Menor ahorro de entrada |
| Tareas cortas independientes | Un modelo pequeño puede ser más barato y rápido |
| Conversación larga obsoleta | Compactar antes de añadir contexto |
| Catálogo grande de herramientas | Cargar herramientas dinámicamente |
Política de coste recomendada en EvoLink
| Tráfico | Política inicial | Condición de promoción |
|---|---|---|
| Transformaciones fáciles y masivas | Modelo pequeño y barato | K3 solo si mejora mucho la aceptación |
| Código difícil y visual | Probar K3 | Mantener si coste por aceptado y latencia cumplen |
| Contexto grande repetido | K3 con medición de caché | Promover si aciertos reales reducen el total |
| Alto riesgo | K3 vs GPT-5.6 Sol o Claude Opus 4.8 | Ruta con mejor economía por resultado aceptado |
| Timeout o rechazo | Un fallback controlado | Parar tras un presupuesto de reintentos |
La pasarela unificada de EvoLink mantiene una sola capa mientras modelo, fallback y carga son configurables.
Errores frecuentes de medición
| Error | Por qué falla | Mejor opción |
|---|---|---|
| Solo precio de salida | Ignora verbosidad, reintentos y revisión | Coste por resultado aceptado |
| Un único prompt llamativo | Oculta variación y fallos | Conjunto representativo y repeticiones |
| Tokens sin tiempo | Una tarea barata puede incumplir latencia | Primer token y tiempo a aceptado |
| Suponer toda repetición en caché | Importan reglas y cambios de prefijo | Verificar tokens facturados |
| Herramientas o presupuestos distintos | Ventaja injusta | Fijar el entorno principal |
| Ignorar al revisor | La limpieza puede dominar | Registrar minutos y reescrituras |
Preguntas frecuentes
¿Kimi K3 es eficiente en tokens?
Depende de la carga. Sus tarifas y descuento de caché son buenos, pero primeras mediciones muestran mucha salida. Mide coste por tarea aceptada.
¿Por qué Kimi K3 puede parecer lento?
El razonamiento siempre activo se suma a cola, primer token, generación, herramientas, reintentos y validación. Mide cada fase.
¿Cuál es la velocidad de salida de Kimi K3?
Artificial Analysis informó inicialmente de unos 62 tokens por segundo. Es una instantánea, no una garantía por proveedor, región o carga.
¿Kimi K3 usa demasiados tokens?
Las primeras conversaciones plantean esa preocupación. La respuesta depende de si esos tokens producen un resultado aceptado o evitan reintentos.
¿Cuánto cuesta Kimi K3 por tarea?
No hay un importe universal. Suma caché, nueva entrada, salida, reintentos, fallback, herramientas y revisión y divide por tareas aceptadas.
¿La caché hace que Kimi K3 sea mucho más barato?
Puede hacerlo con prefijos grandes estables y aciertos reales. Salida, reintentos y contexto variable siguen contando.
¿Debe Kimi K3 ser el modelo estándar?
No para todo. Empieza por código difícil, visual, agentes y contexto grande; conserva modelos pequeños para tareas fáciles y masivas.
¿Cómo comparar K3 en EvoLink?
Usa misma tarea, prompt, herramientas, timeout y criterios. Mide tokens, primer token, tiempo total, reintentos, revisión y coste por aceptado.
Mide K3 en EvoLink
Empieza desde la página de Kimi K3, ejecuta un conjunto representativo y mantén configurable el fallback.
Ver Kimi K3 en EvoLinkLecturas relacionadas:
- Cómo usar Kimi K3 en EvoLink
- Prompts y casos de uso documentados de Kimi K3
- Análisis frontend de Kimi K3 (en inglés)
- Kimi K3 vs GPT-5.6 Sol
- Kimi K3 vs Claude Opus 4.8
Fuentes
- Kimi: artículo técnico de Kimi K3
- Kimi Platform: precio directo
- Kimi Platform: inicio rápido
- Artificial Analysis: rendimiento, velocidad y precio
- Simon Willison: Kimi K3 y coste por tarea
Las mediciones de terceros se presentan como instantáneas y no prueban el rendimiento o la facturación actual de EvoLink.
