Kimi K3 API: Por Qué 1M de Contexto Cambia el Enrutamiento de Modelos

Kimi K3 llega con dos cifras hechas para titulares: 2.8 billones (trillions) de parámetros y una ventana de contexto de 1 millón de tokens.

Para un equipo de producción, el número más útil es 10.

En la API oficial de Kimi K3 de Moonshot, los tokens de entrada con cache miss cuestan diez veces más que los tokens de entrada con cache hit. El requisito más trascendente ni siquiera es un número: las aplicaciones multi-turno y con tool-calling deben preservar el mensaje completo del assistant, incluidos el razonamiento y el estado de las herramientas.

Eso hace que Kimi K3 sea más que un nuevo model ID. Convierte la disposición del contexto, la estabilidad de la caché, la persistencia de sesión y el enrutamiento en los límites de tarea en arquitectura de producción.

TL;DR

• Moonshot describe Kimi K3 como un modelo abierto de clase 3T con 2.8T de parámetros, visión nativa y una ventana de contexto de 1,048,576 tokens.
• K3 ya estaba disponible a través de los productos Kimi y de la API de Moonshot en el momento de la verificación, pero la publicación de los pesos completos estaba programada para el 27 de julio de 2026.
• El modelo activa 16 de 896 expertos, así que su recuento total de parámetros no equivale al cómputo activo por token.
• El precio oficial de la API es de $0.30 por 1M de tokens de entrada con cache hit, $3.00 por 1M de tokens de entrada con cache miss y $15.00 por 1M de tokens de salida.
• Hoy K3 siempre razona en max y exige preservar los mensajes completos del assistant en bucles multi-turno y de tool-calls.
• Moonshot advierte que la falta del historial de pensamiento o cambiar una sesión existente a K3 puede volver inestable la calidad.
• K3 no figuraba en el catálogo en vivo de Velokey cuando se verificó este artículo. No adivines un model ID; verifica primero la disponibilidad en vivo.

Estado de Kimi K3: Confirmado, Pendiente y No Disponible

El material que rodea al lanzamiento de un modelo importante tiende a colapsar varios estados distintos en una sola palabra: lanzado.

Para Kimi K3, esos estados deben mantenerse separados.

La página de lanzamiento de Kimi K3 de Moonshot lo describe como el primer modelo abierto de la clase 3T. Esa es la caracterización del proveedor. La distinción práctica actual es que los desarrolladores ya pueden invocar K3 a través de la API de Moonshot, mientras que los equipos que planean un despliegue local todavía necesitan los pesos reales, la licencia, la model card y el informe técnico.

Si este artículo se actualiza después del 27 de julio, el estado de la publicación de los pesos debería verificarse de nuevo. Un lanzamiento planificado y un artefacto descargable y con licencia no son lo mismo.

Qué Significan 2.8T de Parámetros en la Práctica

Kimi K3 combina Kimi Delta Attention, Attention Residuals y una arquitectura Stable LatentMoE. Moonshot dice que el modelo activa 16 de 896 expertos por request.

Eso cambia cómo debe leerse el titular de los parámetros.

*Moonshot reporta 2.8T de parámetros totales, 16 de 896 expertos efectivamente activados, una ventana de contexto de 1,048,576 tokens y visión nativa.*

Un recuento total de 2.8T de parámetros describe la capacidad global del modelo. No significa que cada parámetro esté activo para cada token. La activación dispersa de expertos es el mecanismo que permite a un modelo muy grande exponer más capacidad sin pagar el coste de cómputo completo de un modelo denso en cada paso.

Moonshot también reporta aproximadamente 2.5 veces la eficiencia de escalado global de Kimi K2. Es un resultado de arquitectura reportado por el proveedor, no una medición independiente en producción, pero apunta al verdadero objetivo de ingeniería: hacer que un modelo muy grande sea utilizable para trabajo de horizonte largo, en lugar de simplemente hacerlo grande.

K3 también incluye comprensión visual nativa y se posiciona para coding, trabajo de conocimiento, razonamiento, imágenes y video. Esas capacidades amplían el conjunto de cargas de trabajo posibles por API, pero no le dicen a un equipo qué cargas de trabajo serán económicas.

Esa respuesta viene del contexto, la salida, la latencia y el comportamiento de las herramientas.

Por Qué una Ventana de 1M de Tokens No Elimina la Ingeniería de Contexto

La página oficial de precios de Kimi lista una ventana de contexto de 1,048,576 tokens.

Es una capacidad enorme. No es una instrucción para llenar cada request.

Un agente de coding o de investigación de larga duración puede acumular:

• instrucciones de sistema
• reglas de permisos y seguridad
• definiciones de herramientas
• archivos de repositorio y documentos
• evidencia recuperada
• mensajes del usuario
• razonamiento del assistant
• tool calls y resultados de herramientas
• reintentos, correcciones y ramas abandonadas

El contexto puede caber mientras la tarea, aun así, se vuelve más lenta, más cara y más difícil de controlar.

El contexto largo cambia la pregunta principal de "¿Cabrá esto?" a "¿Qué merece permanecer activo?"

Una sesión de producción debería separar cuatro capas:

1. Prefijo estable: instrucciones duraderas, conocimiento fijo y definiciones de herramientas reutilizadas con frecuencia.
2. Conjunto de trabajo de la tarea: los archivos, la evidencia, las imágenes y las herramientas necesarias para el objetivo actual.
3. Estado de sesión completo: los mensajes necesarios para preservar la continuidad del razonamiento y de las herramientas.
4. Puntos de control reiniciables: resúmenes verificados que permiten a una tarea recuperarse sin arrastrar para siempre cada rama fallida.

*El contexto largo es operativamente útil cuando las instrucciones estables, el conjunto de trabajo activo, el estado completo de la sesión y los puntos de control de reinicio se gestionan por separado.*

La ventana de un millón de tokens da más margen a los equipos. No sustituye la recuperación, la compactación, los puntos de control ni los presupuestos de tokens.

Cómo el Precio de Kimi K3 Cambia la Arquitectura de Prompts

El precio oficial de K3 según Moonshot es:

• Entrada con cache hit: $0.30 por 1M de tokens
• Entrada con cache miss: $3.00 por 1M de tokens
• Salida: $15.00 por 1M de tokens

Los precios excluyen los impuestos aplicables y pueden cambiar. Verifica la página oficial en vivo antes de cualquier compra.

El modelo de costes básico es:

input cost = cache-hit MTok x $0.30 + cache-miss MTok x $3.00
output cost = output MTok x $15.00

*Los precios verificados el 17 de julio de 2026 muestran una brecha de 10× entre las tarifas de entrada con cache hit y cache miss, lo que convierte la estabilidad del prefijo en un mecanismo de control de costes. Son tarifas oficiales de la API de Kimi, no precios de Velokey; los precios pueden cambiar.*

La brecha de diez veces en el precio de entrada hace que la estructura del prompt forme parte de la arquitectura de costes.

El caching de contexto de Kimi es automático. No hay cache ID manual ni TTL que gestionar. La API intenta reutilizar el contexto inicial repetido, como system prompts, documentos de conocimiento y definiciones de herramientas.

Automático no significa garantizado.

Si una aplicación cambia el comienzo del prompt en cada llamada, reordena las herramientas, inyecta timestamps en el prefijo o serializa el mismo conocimiento en un orden distinto, puede convertir contexto reutilizable en cache misses.

Moonshot dice que la API oficial ha alcanzado tasas de cache hit superiores al 90% en cargas de trabajo de coding. Trátalo como un resultado reportado por el proveedor, no como una promesa para una aplicación distinta. El número en el que un equipo de producción debe confiar es el medido en su propio tráfico.

Rastrea al menos:

• tokens de entrada con cache hit
• tokens de entrada con cache miss
• tokens de salida de razonamiento y de respuesta final
• tiempo hasta el primer token
• latencia total de la respuesta
• número de tool calls
• tasa de reintentos
• coste por tarea completada

El precio por request no basta para un agente. Un solo objetivo del usuario puede desencadenar decenas de llamadas al modelo, tool calls, reintentos y pasos de verificación.

Por Qué el Pensamiento Preservado Cambia el Enrutamiento de Modelos

Kimi K3 siempre razona. La API actualmente solo admite reasoning_effort="max", y una respuesta puede contener reasoning_content además de su content final.

Para conversaciones multi-turno y tool calls, la documentación de Kimi dice que el mensaje completo del assistant debe añadirse al siguiente request. Los desarrolladores no deben conservar solo la respuesta visible. El mensaje devuelto también puede contener campos de razonamiento y de tool-calls necesarios para la continuidad.

Esto afecta tanto al coste como al enrutamiento.

El razonamiento histórico sigue ocupando la ventana de contexto y contribuye al consumo de tokens. Una sesión de agente larga, por tanto, crece por algo más que los mensajes del usuario y los documentos.

También significa que la selección de modelo no es segura si se hace sin estado.

Moonshot advierte que la calidad de K3 puede volverse muy inestable cuando un harness no devuelve el historial completo de pensamiento o cuando una sesión en curso con otro modelo se cambia a K3.

La regla de producción más segura es simple:

> Enruta en el límite de la tarea o de la sesión y luego fija el modelo seleccionado hasta un punto de control deliberado.

Si un modelo o proveedor falla a mitad de una tarea, crea un paquete de reinicio con los hechos verificados, las acciones completadas, los archivos actuales, las decisiones abiertas y los objetivos restantes. Arranca el modelo de reemplazo desde ese estado explícito en lugar de cambiar silenciosamente el model ID dentro del mismo bucle de herramientas.

*Selecciona el modelo en un límite de tarea, fíjalo durante el bucle de herramientas y cambia de modelo solo tras un punto de control deliberado o en una sesión nueva. Es una recomendación de producción, no una arquitectura oficial de enrutamiento de Kimi.*

Esta es la diferencia entre enrutamiento por request y enrutamiento por sesión.

Dónde Encaja Kimi K3 en un Stack Multi-Modelo

El modo de razonamiento máximo de K3 hace que la separación de cargas de trabajo sea importante desde el primer día.

Moonshot lista la proactividad excesiva como una limitación actual. K3 puede tomar decisiones inesperadas cuando una tarea larga se topa con ambigüedad o un obstáculo menor.

Eso hace que el diseño de permisos sea tan importante como el diseño de prompts:

• separa el acceso de lectura del de escritura
• mantén las API keys y las credenciales de producción en el servidor
• exige aprobación para acciones destructivas o externas
• define condiciones de parada explícitas
• registra cada acción de herramienta solicitada y su resultado
• evalúa el comportamiento de recuperación, no solo las ejecuciones exitosas

El modelo más capaz no debería recibir automáticamente los permisos más amplios.

API de Kimi K3 vs Autoalojamiento

La publicación prevista de los pesos abiertos pone el despliegue local sobre la mesa. No convierte el despliegue local en el ganador automático.

Moonshot dice que K3 usa entrenamiento consciente de la cuantización con pesos MXFP4 y activaciones MXFP8. La compañía recomienda configuraciones de supernodo con 64 o más aceleradores para el despliegue.

Es una recomendación, no un mínimo estricto publicado, pero basta para mostrar que servir K3 a escala completa es un proyecto de infraestructura a nivel de clúster.

El acceso mediante API gestionada es la primera vía práctica cuando:

• el tráfico es incipiente o variable
• el equipo quiere validar la calidad antes de comprar infraestructura
• la velocidad de despliegue importa
• el equipo no puede operar un gran stack de inferencia distribuido
• el producto necesita comparar K3 con varios otros modelos

El autoalojamiento se vuelve más plausible cuando:

• la licencia final permite el uso previsto
• los requisitos de soberanía de datos exigen control local
• la carga es lo bastante sostenida como para justificar capacidad dedicada
• la organización ya opera infraestructura de modelos grandes
• el equipo puede gestionar la utilización, el batching, el caching, las actualizaciones y la recuperación ante fallos

Los pesos abiertos no hacen gratuitos el hardware, la red, la capacidad ociosa, la observabilidad ni el tiempo de ingeniería.

El orden más seguro es evaluar primero por API y comprometer infraestructura después.

Una Checklist de Producción para Agentes con Kimi K3

Antes de enviar tráfico de producción a K3, responde estas preguntas.

Encaje de la carga de trabajo

• ¿La tarea necesita razonamiento de horizonte largo, contexto grande, visión o herramientas complejas?
• ¿El resultado es lo bastante valioso como para justificar el razonamiento máximo y el coste de los tokens de salida?
• ¿Podría un modelo más barato encargarse de la primera pasada de clasificación, extracción o reescritura?

Diseño de sesión

• ¿El modelo está fijado durante toda la vida de la tarea?
• ¿Se almacena y se reproduce el mensaje completo del assistant?
• ¿Puede el flujo de trabajo reiniciarse desde un punto de control tras un fallo?
• ¿Las definiciones de herramientas se cargan solo cuando se necesitan?

Coste y latencia

• ¿Qué porcentaje de los tokens de entrada son cache hits?
• ¿Con qué rapidez crece el historial de razonamiento?
• ¿Cuáles son el tiempo hasta el primer token y la duración total de la tarea?
• ¿Cuánto gasto proviene de reintentos y tool calls fallidas?
• ¿Cuál es el coste por resultado aceptado, no solo por request?

Seguridad y operaciones

• ¿Qué acciones requieren aprobación humana?
• ¿Las credenciales se almacenan solo en el servidor?
• ¿Las acciones destructivas están bloqueadas por defecto?
• ¿Son observables las tool calls, los errores, el uso de tokens, la latencia y el gasto?

Evaluación

• ¿K3 supera a una línea base sólida en la carga de trabajo real?
• ¿Supera a una línea base más barata lo suficiente como para justificar el coste?
• ¿Qué ocurre cuando la tarea se reinicia en otro modelo?
• ¿Con qué frecuencia necesita el modelo corrección humana?

El resultado de la evaluación debería ser una frontera calidad-coste-latencia, no una única puntuación de benchmark.

Cómo Preparar un Cliente Compatible con OpenAI Sin Inventar un Model ID

Kimi K3 no estaba en el catálogo en vivo de Velokey cuando se verificó este artículo. La disponibilidad puede cambiar, así que consulta el catálogo de modelos en vivo y consulta el endpoint de modelos antes de escribir código de integración.

No adivines un model ID a partir de un artículo de blog.

El siguiente ejemplo lista los model IDs actualmente disponibles para una cuenta de Velokey. No asume que K3 esté presente.

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VELOKEY_API_KEY"],
    base_url="https://api.velokey.ai/v1",
)

for model in client.models.list().data:
    print(model.id)

Mantén la API key en una variable de entorno del lado del servidor. Si un model ID de Kimi K3 no aparece en GET /v1/models, todavía no está disponible para esa cuenta a través de Velokey. Sigue usando un modelo verificado como disponible o la API oficial de Kimi en lugar de hardcodear un ID no listado.

Una vez que un nuevo modelo esté disponible, un cliente compatible con OpenAI reduce el trabajo de migración. La aplicación sigue necesitando evaluación específica del modelo, reglas de sesión y telemetría. La compatibilidad de interfaz no borra las diferencias de comportamiento.

Cuándo Kimi K3 Justifica el Gasto

Kimi K3 resulta más convincente cuando una tarea es cara para un humano, difícil de dividir y lo bastante valiosa como para justificar una traza de razonamiento larga: un refactor grande, un trabajo de investigación multi-herramienta, un flujo de ingeniería multimodal o un conjunto de documentos complejo que necesita síntesis sostenida.

Es menos convincente como predeterminado universal. Clasificación, extracción, etiquetado, reescritura simple y soporte rutinario son los ámbitos donde un stack multi-modelo debería proteger el presupuesto.

La decisión de producción no debería venir de 2.8T por sí solo. Debería venir de la tasa de cache hit, el coste por tarea completada, la estabilidad de sesión, el éxito de las herramientas, la latencia, el comportamiento de recuperación y la corrección humana.

Esa es la verdadera historia de la API de Kimi K3. El modelo es grande, pero la arquitectura de sesión que lo rodea decide si es útil.

Preguntas Frecuentes sobre la API de Kimi K3

¿Es Kimi K3 completamente open source ahora?

Al 17 de julio de 2026, Moonshot dijo que los pesos completos del modelo se publicarían antes del 27 de julio. K3 ya estaba disponible a través de los productos Kimi y de la API oficial. Verifica el repositorio, la licencia, la model card y el informe técnico antes de describirlo como descargable en un artículo posterior.

¿Cuál es la ventana de contexto de Kimi K3?

Moonshot lista 1,048,576 tokens. La ventana grande aumenta la capacidad, pero no elimina la necesidad de recuperación, caching, control del historial y puntos de control.

¿Cuál es el precio oficial de la API de Kimi K3?

Moonshot lista $0.30 por 1M de tokens de entrada con cache hit, $3.00 por 1M de tokens de entrada con cache miss y $15.00 por 1M de tokens de salida, sin incluir los impuestos aplicables.

¿Kimi K3 usa los 2.8T de parámetros en cada token?

No. Moonshot dice que la arquitectura Stable LatentMoE activa 16 de 896 expertos. El recuento total de parámetros describe la capacidad, mientras que la activación dispersa limita el cómputo activo.

¿Puedo cambiar de modelo a mitad de una sesión de Kimi K3?

Hazlo con cautela. Moonshot advierte que un historial de pensamiento incompleto o cambiar una sesión en curso de otro modelo a K3 puede volver inestable la generación. Enruta en un límite de sesión o reinicia desde un punto de control verificado.

¿Está Kimi K3 disponible a través de Velokey?

No estaba listado cuando se verificó este artículo el 17 de julio de 2026. Usa el catálogo de modelos en vivo y GET /v1/models para conocer la disponibilidad actual a nivel de cuenta. No te fíes de una afirmación estática de un blog.

Fuentes

• Lanzamiento y limitaciones de Kimi K3
• Quickstart de la API de Kimi K3
• Precios oficiales de Kimi K3
• Context caching de la API de Kimi
• Thinking effort de Kimi K3

Divulgación: Velokey publica este artículo y proporciona una capa de acceso por API compatible con OpenAI para modelos de múltiples proveedores. Kimi K3 no figuraba en el catálogo en vivo de Velokey en el momento de la revisión.

¿Quieres preparar un solo cliente para las opciones de modelos actuales y futuras sin inventar IDs? Sigue el [quickstart de Velokey](https://docs.velokey.ai/quickstart) y selecciona únicamente un modelo devuelto por GET /v1/models.