Cómo usar el contexto de 1M de Kimi K3: repos y documentos

Kimi K3 lleva la ventana de contexto a 1 048 576 tokens, aproximadamente cuatro veces la de K2. Mucho trabajo que antes exigía trocear, hacer RAG y unir fragmentos una y otra vez ahora se puede «meter de una sola vez». Pero 1M no es una invitación a llenar la ventana a lo bruto. Bien usado, ahorra esfuerzo y dinero; mal usado, resulta lento y caro. Aquí explicamos cómo aprovechar de verdad el contexto de 1M.

Qué cabe en 1M tokens

Como conversión aproximada (texto mixto, según la experiencia práctica), 1M tokens equivale más o menos a:

• un repositorio de código de tamaño medio: la parte central de varios cientos de archivos fuente;
• un libro entero: un manual técnico o documento largo de varios cientos de páginas;
• decenas de PDF / contratos: todo el conjunto documental de un proyecto leído de una vez;
• un historial de conversación muy largo: el contexto completo de un agente de larga duración tras muchas rondas de llamadas a herramientas.

Dicho de otro modo, las tareas que antes había que dividir porque «no cabían» ahora K3 puede resolverlas en su mayoría dentro del contexto completo de una sola petición. El modelo ve el panorama completo, y la mayor ganancia es la coherencia de las respuestas y la menor pérdida de información.

Cómo organizar el análisis de código de todo el repositorio

Al pasar código a K3, la estructura importa más que la cantidad. La forma recomendada de organizar los messages:

system_prompt = "Eres un ingeniero senior. A continuación está el repositorio completo. Cita archivos y números de línea concretos en tus respuestas."

repo_dump = "\n\n".join(
    f"### FILE: {path}\n```\n{code}\n```"
    for path, code in files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": repo_dump + "\n\nPregunta: ¿en qué archivos está la lógica de autenticación de inicio de sesión? ¿Hay código duplicado que se pueda fusionar?"},
    ],
)

Algunos puntos clave:

• pon a cada archivo una marca de ruta clara (### FILE: path) para que el modelo pueda citarlo con precisión;
• coloca la parte que no cambia (el contenido del repositorio) al principio y la pregunta, distinta en cada petición, al final, así el prefijo fijo aprovecha el caché;
• pide al modelo que cite archivos / números de línea para que la salida sea verificable y no algo vago.

Q&A de documentos largos y caché

Los escenarios de documentos largos (contratos legales, artículos, manuales) son el uso más cómodo del contexto de 1M: mete el documento completo en el mensaje system o en el primer mensaje user y luego simplemente sigue preguntando, sin trocear ni recuperar por tu cuenta.

La clave para ahorrar: K3 tiene el caché de contexto activado por defecto. Cuando haces distintas preguntas sobre el mismo documento largo de forma repetida, ese prefijo del documento acierta en el caché y el precio de entrada baja de ¥20/M a ¥2/M. Así que el orden a seguir es:

[system: rol + instrucciones]        ← fijo
[user: el documento completo]        ← fijo, acierta en el caché
[user: la pregunta de esta ronda]    ← cambia en cada ronda

Poner el contenido fijo delante y el variable detrás es la primera regla para ahorrar en contexto largo. Para el cálculo detallado de precios y caché, consulta el desglose de precios de Kimi K3.

Cuándo conviene seguir usando RAG

1M es mucho, pero no es una solución mágica:

• base de conocimiento muy superior a 1M (toda la wiki de una empresa, un millón de líneas de código): sigues necesitando recuperar antes de alimentar el modelo, y RAG no va a quedar obsoleto;
• solo necesitas unos pocos fragmentos relevantes: meterlo todo es un desperdicio, gastas tokens de entrada para nada y la latencia sube;
• fuerte tiempo real / alta concurrencia: cuanto más largo el contexto, más lenta y cara cada llamada, así que recorta en escenarios de alta frecuencia.

Regla práctica: si cabe de una vez y la mayor parte del contenido es relevante, mételo directamente; si no, recupera primero y luego pasa a K3 los fragmentos coincidentes. Los dos enfoques también se combinan: usa RAG para reducir el alcance a unos cientos de miles de tokens y deja que K3 responda en profundidad dentro de ese contexto «grande pero relevante».

Aspectos a tener en cuenta

• cuanto más largo, más caro y lento: 1M es un techo, no un objetivo; usa solo lo que necesites;
• aprovecha el caché: pon el prefijo fijo al principio y acierta siempre en el caché con documentos largos / múltiples turnos;
• lo visual también cuenta como contexto: los tokens de imagen / vídeo también consumen presupuesto, vigila el total en tareas multimodales largas;
• no conserves solo el content: en flujos de múltiples turnos / llamadas a herramientas, devuelve el mensaje assistant completo tal cual, no pierdas el estado.

El código de integración completo y la resolución de errores están en el tutorial de la API de Kimi K3. Si quieres llamar a K3 y a los modelos de otros proveedores con una sola clave, repartiendo tareas largas y cortas según la carga, lo más cómodo es empezar por el panel de GetModel.