Kimi API se factura por uso y no ofrece un plan de suscripción. Al comparar proveedores, mirar solo «cuánto cuesta un millón de tokens» lleva fácilmente a elegir mal: lo que de verdad determina la factura es el modelo, la longitud del contexto, la tasa de acierto de caché y la longitud de la salida. La serie K2 ofrece 262,144 tokens de contexto y K3 llega a 1,048,576. Un contexto largo es una capacidad valiosa, pero también implica que el lado de la entrada acumule costo con más facilidad.

Este artículo desglosa la estructura de facturación de la serie K2, de dónde viene el costo del contexto largo, un método de medición reproducible y el orden para bajar costos, sin fijar precios unitarios. Los precios concretos se rigen por la documentación oficial y los precios de modelos del sitio.

Nota: Moonshot y Kimi son marcas de sus respectivos titulares. Los nombres de modelo, la longitud de contexto y las reglas de facturación pueden cambiar; este artículo toma como ejemplo la situación habitual de octubre de 2026. Verifica de nuevo las páginas oficiales antes de comprar.

1. Cómo se reparte la serie K2

Modelo Posición Contexto Tareas adecuadas Punto de costo
kimi-k2.6 Uso general 262,144 Conversación, extracción, atención al cliente, procesamiento de documentos Tasa de acierto de caché
kimi-k2.7-code Código 262,144 Generación de código, preguntas sobre repositorios, agentes Entrada larga y muchos resultados de herramientas
kimi-k2.7-code-highspeed Código de alta velocidad 262,144 Autocompletado de baja latencia, programación interactiva Equilibrio entre precio unitario y throughput
kimi-k3 Nueva generación 1,048,576 Documentos ultralargos, tareas complejas de varios pasos Contexto largo y escritura de caché

Los modelos se renuevan, y la serie K2 puede recibir nuevas versiones más adelante. Al comprar, rígete por la lista oficial de modelos y los precios de modelos del sitio; no trates los nombres de este artículo como un compromiso permanente.

Las tareas generales no deberían usar por defecto el contexto máximo. Si metes un documento completo en un contexto de 1M, el costo de entrada se acumula rápido con cada turno; suele ser más rentable usar primero recuperación para acotar el alcance y luego pedir al modelo que lea solo los fragmentos clave. En tareas de código ocurre lo contrario: la estructura del repositorio y los resultados de las herramientas a menudo deben conservarse, así que la prioridad es estabilizar el prefijo y elevar la tasa de acierto de caché.

2. La factura se compone de tres bloques

La serie K2 factura tres conceptos: entrada con acierto de caché, entrada sin acierto de caché y salida. K3 además cobra la escritura de caché por separado, con dos niveles de TTL, 5 minutos y 1 hora, de modo que no se puede multiplicar un precio unitario promedio por el total de tokens.

Concepto Cuándo se genera Efecto en el costo Control
Entrada sin caché Prompt, documentos y resultados de herramientas que aparecen por primera vez Crece linealmente con el contexto Recuperación, resumen, recorte del historial
Entrada con caché System prompt y prefijos fijos que se repiten Suele ser bastante menor que la entrada sin caché Prefijo estable, orden fijo de herramientas
Tokens de salida Contenido y razonamiento que genera el modelo Las salidas largas amplifican la factura Limitar max_completion_tokens
Escritura de caché (K3) Escritura del prefijo en caché Se cobra según el nivel de TTL Cachear solo contenido estable y reutilizable

Si descomponemos una solicitud, la fórmula de costo es:

Costo por solicitud =
  tokens de entrada sin caché × precio unitario sin caché
+ tokens de entrada con caché × precio unitario con caché
+ tokens de salida × precio unitario de salida

En K3 hay que sumar además la escritura de caché. El campo usage de la respuesta entrega prompt_tokens, completion_tokens y prompt_tokens_details; tanto los aciertos como las escrituras de caché se cuentan dentro de prompt_tokens, así que la parte sin caché se obtiene restando esos dos valores del total.

3. Por qué el contexto largo tiende a encarecerse

Escenario Estructura típica de tokens Costo principal Vía de optimización
Preguntas sobre documentos largos Entrada alta, salida media El documento se reenvía una y otra vez Recuperación más caché
Agente sobre repositorio de código Entrada y salida altas Resultados de herramientas e historial Resumen, recorte y caché
Atención al cliente multiturno La entrada se acumula por turno Mensajes del historial repetidos Resumen incremental
Extracción por lotes Entrada media, salida corta Lectura repetida de documentos Procesamiento por lotes con un modelo pequeño

Las diferencias suelen venir de cinco puntos:

  1. La entrada se acumula por turno: si reenvías el texto completo en cada ronda, la factura casi se duplica con cada intercambio.
  2. Tasa de acierto de caché: un prefijo fijo se puede reutilizar; las marcas de tiempo que cambian, los ID aleatorios y el orden dinámico invalidan la caché.
  3. Salida de herramientas: una búsqueda o una ejecución de código devuelve un bloque entero de registros y el siguiente turno lo arrastra tal cual, sumando costo.
  4. Longitud de salida: el «análisis detallado» abierto es el que más salidas largas produce, y la salida suele costar más que la entrada con caché.
  5. Modelo mal asignado: usar un modelo grande para clasificar, o reintentar una y otra vez una tarea compleja con un modelo inadecuado, también infla el costo.

4. Haz una medición reproducible

  1. Elige entre 20 y 50 tareas reales que cubran los niveles simple, medio y complejo, y define por escrito el criterio de aceptación.
  2. Cuantifica primero la entrada con la interfaz de estimación de tokens; no la calcules a ojo por número de palabras.
  3. Ejecuta el mismo lote con kimi-k2.6 y con el modelo de código, y registra calidad, latencia y número de retrabajos.
  4. Lee de usage la entrada, la salida, los aciertos de caché y las escrituras de caché.
  5. Compara por el costo de «completar una tarea aceptable», no por el precio de lista de un millón de tokens.
  6. Incluye en el costo por tarea los reintentos, las solicitudes fallidas y las escrituras de caché.
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Extrae este contrato en JSON: ..."}],
    max_completion_tokens=1024,
)

u = resp.usage
print("entrada", u.prompt_tokens, "salida", u.completion_tokens)
print("detalle de caché", getattr(u, "prompt_tokens_details", None))

Las llamadas en streaming deben añadir stream_options={"include_usage": True}; el uso completo solo llega en el último fragmento. Para calcular importes, multiplica por los precios unitarios reales del contrato o de la página de precios, no por capturas de pantalla de hace meses.

5. Orden para reducir el costo

  1. Primero la caché: fija el system prompt, las definiciones de herramientas y el prefijo de la base de conocimiento, y verifica con cached_tokens si realmente hay aciertos.
  2. Después reduce la entrada: recupera solo fragmentos relevantes, resume el historial y evita meter la base completa en el contexto.
  3. Limita la salida: define un max_completion_tokens razonable, pide JSON o campos fijos y elimina las fórmulas de cortesía.
  4. Enruta por modelo: usa kimi-k2.6 para tareas generales, la versión de código K2.7 para programación y considera K3 solo para material ultralargo.
  5. Convierte las solicitudes largas a streaming: el streaming no cambia el precio unitario, pero reduce los reintentos causados por timeouts y desconexiones.
  6. Monitorea y alerta: revisa el uso por proyecto, modelo y escenario, fija topes de presupuesto y repasa cada semana el ranking de consumo.

El orden no se invierte. Primero trabaja la caché y el gobierno de la entrada, y solo después considera cambiar a un modelo más barato; de lo contrario, solo estarás haciendo más barata una respuesta equivocada.

6. Cómo gestionar presupuesto y factura

  • Una clave por proyecto y un presupuesto diario por proyecto, para que un solo negocio no agote toda la cuota.
  • Conciliación mensual por tres dimensiones: proyecto, modelo y escenario, para identificar las llamadas que más crecen.
  • Registra por separado la tasa de acierto de caché, el número de reintentos y la longitud media de salida; sin esos datos no puedes demostrar el efecto de la optimización.
  • Los equipos que necesitan pagar en RMB y recibir factura pueden usar un gateway de IA local para unificar la factura de varios modelos; las condiciones concretas de precio y factura se rigen por los precios de modelos.

Preguntas frecuentes

¿Qué conviene más, K2 o K3?

Depende de la tarea. La serie K2 tiene un contexto de 262,144 tokens y cubre la mayoría de los escenarios de documentos y código; K3 ofrece un contexto mayor y sirve para material ultralargo. Compara por el costo total de completar una tarea aceptable, no solo por el precio unitario.

¿Cuánto ahorra la caché?

Depende de la tasa de reutilización del prefijo y de la tasa de acierto. La entrada con caché suele ser bastante menor que la entrada sin caché, y un acierto además prolonga la vigencia de la caché; pero si el prefijo cambia en cada solicitud o es demasiado corto, no habrá aciertos.

¿El streaming sale más barato?

No cambia el precio unitario de forma directa. Su valor está en reducir el costo oculto de timeouts, conexiones interrumpidas y reintentos en solicitudes largas.

¿Por qué la factura es mayor que mi estimación?

Entre las omisiones habituales están el historial de mensajes, los resultados de herramientas, el texto completo de documentos, los reintentos, las salidas largas y los fallos de caché. Concilia los logs de solicitudes contra usage para localizar la diferencia.

¿Cómo pagan en RMB los equipos que operan en China?

Pueden llamar a Kimi a través de un gateway de IA que ofrezca recarga y factura en RMB, con una factura unificada para varios modelos. Los modelos disponibles, los precios y las reglas de facturación se rigen por los precios de modelos.

Próximos pasos

Crea primero una clave de prueba en ZSQH AI Gateway, ejecuta un lote de tareas reales con kimi-k2.6 y con el modelo de código, y registra tokens, aciertos de caché y calidad antes de decidir el modelo principal. La disponibilidad y los precios se rigen por los precios de modelos.

Lecturas relacionadas: