Caché de prompts de LLM: calcula el ahorro sin contar tokens dos veces

El almacenamiento en caché de prompts puede reducir el costo de enviar repetidamente las mismas instrucciones o contexto a un LLM. El ahorro depende de los aciertos reales de caché, las categorías de cobro del proveedor y la frecuencia con la que se reutiliza el material en caché antes de que venza.

Un precio bajo de lectura de caché es solo una parte del cálculo. Las escrituras pueden tener un precio aparte, los tokens de salida siguen costando dinero y un total de entrada reportado puede incluir ya tokens en caché. Esta guía explica cómo construir una estimación útil y verificarla contra los registros de uso. Los ejemplos desarrollados usan precios explícitamente hipotéticos, no resultados medidos de aplicaciones ni ofertas de un proveedor.

Identifica qué almacena en caché realmente el proveedor

El almacenamiento en caché de prompts generalmente se refiere al contexto de entrada reutilizable. No debe confundirse con una aplicación que devuelve una respuesta guardada previamente sin llamar a un modelo.

La documentación de almacenamiento en caché de contexto de DeepSeek describe la coincidencia de unidades de prefijo de prompt persistidas. Está habilitado de forma predeterminada, pero opera con base en el mejor esfuerzo. Solicitudes de aspecto similar no garantizan un acierto, y una entrada en caché no significa que simplemente se devolverá la respuesta anterior.

Para tu aplicación, distingue tres mecanismos:

• Almacenamiento en caché de prompts del proveedor: el servicio de inferencia reutiliza el procesamiento de entrada elegible y reporta sus propias categorías de uso.
• Almacenamiento en caché de respuestas de la aplicación: tu aplicación entrega un resultado guardado, potencialmente evitando por completo una llamada al modelo.
• Almacenamiento en caché de recuperación o documentos: tu aplicación evita repetir el trabajo de extracción o recuperación, pero aún puede enviar el texto resultante al modelo.

Mide cada uno por separado. De lo contrario, un cambio en la recuperación de documentos puede confundirse con un descuento de inferencia, o un acierto de caché de respuestas puede contarse como un acierto de caché del proveedor.

Divide la entrada en categorías que no se superpongan

Comienza con el esquema de uso del endpoint seleccionado, no con una fórmula supuesta. DeepSeek reporta prompt_cache_hit_tokens y prompt_cache_miss_tokens. Otras API pueden exponer campos diferentes o desgloses anidados.

Si una respuesta reporta 10,000 tokens de entrada totales, incluidos 8,000 tokens en caché, la entrada sin caché restante es 2,000. Cobrar los 10,000 a la tarifa sin caché y luego sumar 8,000 a la tarifa con caché cuenta dos veces una parte de la solicitud.

Para un servicio con tarifas separadas de acierto y fallo, una estimación básica de tokens del modelo es:

cost = miss_tokens / 1M × miss_rate + hit_tokens / 1M × hit_rate + output_tokens / 1M × output_rate

Usa esa fórmula solo cuando coincida con las definiciones del proveedor. Si el servicio reporta la creación o el almacenamiento de caché por separado, concilia esas categorías antes de sumar sus cobros. Un precio de escritura de caché podría reemplazar otra categoría o ser un cobro adicional; la tarifa debe resolver esa distinción.

Mantén la moneda, las unidades, el ID del modelo, el proveedor y la fecha junto a tu cálculo. Un número cotizado por mil tokens no puede insertarse sin cambios en una fórmula por millón de tokens.

Incluye la primera escritura y la vida útil

La guía de cobro por inferencia de Kimi distingue las escrituras de caché de K3 por su duración, con categorías de cinco minutos y una hora. Su entrada con acierto de caché se cobra al precio de acierto sin otro cobro por escritura de caché. Esas son reglas de la plataforma directa, no una prueba de que una puerta de enlace use la misma contabilidad.

Una pregunta útil es cuántas veces se reutilizará un prefijo mientras su entrada de caché siga siendo elegible. Considera este esquema de cobro hipotético para un prefijo de un millón de tokens:

Cobro	Precio supuesto
Procesar el prefijo sin caché	US$1.00 por uso
Primera escritura de caché, que reemplaza el cobro de entrada ordinario	US$1.25
Cada lectura de caché posterior	US$0.10

Cinco usos sin caché cuestan US$5.00. Una escritura seguida de cuatro lecturas cuesta US$1.65, un 67% de ahorro en ese prefijo. Con un solo uso, la ruta con caché cuesta más: US$1.25 en lugar de US$1.00.

La suposición de que la escritura reemplaza el cobro de entrada ordinario es esencial. Si un proveedor real cobra las escrituras de forma adicional, la fórmula cambia. Estos precios ilustran el método; no son una cotización actual de Kimi ni de cheapaimodel.

Para este esquema de tipo reemplazo, compara write_cost + (uses − 1) × read_cost con uses × ordinary_cost. Luego repite el cálculo para el número esperado de usos dentro de la duración real. Una lectura barata no puede ayudar si cada solicitud llega después de que la entrada haya vencido.

Calcula el ahorro en toda la solicitud

Un descuento en la entrada no es el mismo porcentaje de descuento en la cuenta final. Supón que una carga de trabajo sin caché tiene US$10 de cobros de entrada y US$20 de cobros de salida. Asume que el 80% de esa entrada se convierte en aciertos de caché, que las lecturas cuestan el 10% de la tarifa de entrada ordinaria y que no hay cobros adicionales por escritura.

El nuevo cobro de entrada es de US$2 por los fallos más US$0.80 por los aciertos, es decir, US$2.80. El total pasa a ser US$22.80 en lugar de US$30: un ahorro general del 24%, a pesar de un descuento del 90% en la tarifa de la porción con caché.

Las respuestas largas, la salida de razonamiento, las llamadas a herramientas, los reintentos y el almacenamiento pueden cambiar aún más el total. Usa el uso facturable que reporta el endpoint en lugar de contar solo la respuesta final visible. Para conocer los precios actuales de los modelos, empieza con la comparación de precios y luego aplica tu propia mezcla de uso.

Diseña una medición útil

Reúne suficiente información para comparar cosas equivalentes:

• Modelo y ruta del proveedor, hora de la solicitud y configuración relevante.
• Entrada total, aciertos de caché, fallos de caché, creación de caché y salida donde se reporten.
• Servicios cobrados por separado y el cobro registrado en la cuenta.
• Si el resultado cumplió los criterios de aceptación de la aplicación.

Calcula una proporción de aciertos ponderada por tokens: total de tokens con acierto dividido entre el total de tokens de entrada elegibles. Promediar porcentajes por solicitud puede engañar cuando una solicitud diminuta y una solicitud grande reciben el mismo peso.

Mantén las instrucciones estables y el contexto reutilizable antes de cambiar el material específico de la tarea cuando esa disposición se ajuste a las reglas de prefijo documentadas del proveedor. No reordenes las instrucciones de seguridad ni elimines el contexto necesario solo para buscar una mayor tasa de aciertos. Valida la calidad del resultado después de cambiar la estructura del prompt.

Reconcilia antes de escalar

Compara una muestra pequeña de registros de uso con la vista de cobros del proveedor. Investiga categorías faltantes, redondeos, ventanas de precios distintas y cargos por escritura o por herramientas antes de asumir que el recibo está mal.

cheapaimodel publica las tarifas de entrada, salida y lectura de caché en su página de precios. Confirma las reglas de escritura y otros cargos aplicables del modelo correspondiente antes de tratar un subtotal de tres columnas como un recibo completo. Para distinciones específicas de K3, consulta la guía de la API de Kimi.

El resultado útil es un menor costo por resultado aceptado. Un mayor conteo de tokens en caché por sí solo no establece que la aplicación se volviera más barata o más efectiva.