Nota del autor: con la llegada de los precios por franja horaria (pico y valle) y el cobro por uso de herramientas en la API de DeepSeek, la vieja estimación de «precio unitario × Token» ha quedado obsoleta. En este artículo recalculamos, en 5 pasos, el coste real de invocación de una aplicación a partir de cuatro dimensiones: franja horaria, tipo de token, caché y llamadas a herramientas.
Muchos desarrolladores siguen con una hoja de costes anclada en «precio de entrada × tokens de entrada + precio de salida × tokens de salida». Desde que la API de DeepSeek introdujo precios por franja horaria y cobro por llamadas a herramientas, a esa fórmula le faltan dos variables: en qué franja horaria se hace la petición y cuántas veces se llama a las herramientas. Una misma aplicación, con el mismo consumo de tokens, ejecutada en otra franja puede generar una factura notablemente distinta.
Este no es un artículo de copiar y pegar precios. Aquí no vas a encontrar ninguna tarifa sin verificar: todos los precios, descuentos por franja y criterios de caché deben consultarse en los datos en tiempo real de la página de precios de APIYI, docs.apiyi.com/models, y en los anuncios oficiales de DeepSeek. Lo que este artículo resuelve es el método: una vez que tienes la tabla de precios delante, cómo aplicarla correctamente a los logs de tu propio negocio.
Valor principal: al terminar de leer, tendrás un marco reutilizable para estimar costes de la API de DeepSeek, serás capaz de decidir qué peticiones conviene mover a la franja valle y qué llamadas a herramientas merece la pena recortar, y sabrás de dónde obtener datos de precios fiables.
Puntos clave del costo tras la tarificación por horas pico y valle de la API de DeepSeek
Últimamente ha aumentado claramente el debate en los medios sobre el rumbo comercial de DeepSeek (por ejemplo, el reportaje de 36Kr «Liang Wenfeng baja de la montaña, ¿qué busca DeepSeek?»). El cambio en la estructura de precios también es un tema central para los desarrolladores. Sea cual sea la lógica comercial detrás, para quien consume la API el impacto más directo es que el modelo de costos pasó de ser “unidimensional” a “multidimensional”. La siguiente tabla desglosa primero la nueva estructura de costos.
| Dimensión de costo | Descripción | Impacto en el cálculo |
|---|---|---|
| Coeficiente por franja horaria | Se aplican tarifas distintas en horas pico y horas valle | Obliga a agrupar las solicitudes por franja según su hora; no sirve el promedio de todo el día |
| Tokens de entrada (acierto de caché) | Parte de la entrada que acierta la caché de contexto | El precio unitario difiere del de la parte no cacheada; hay que contabilizarla por separado |
| Tokens de entrada (fallo de caché) | Entrada que aparece por primera vez o cuya caché caducó | En aplicaciones con System Prompt largo, suele ser la mayor proporción |
| Tokens de salida | Incluyen los tokens del proceso de razonamiento de los modelos de razonamiento | A menudo se subestima el volumen de salida de los modelos de razonamiento |
| Costo de invocación de herramientas | Uso de herramientas facturado por número de llamadas u otros criterios | Nueva partida de costo independiente que, además, incrementa los tokens |
Los números concretos de los precios no aparecen en la tabla, y eso es intencional. El precio de DeepSeek se ha ajustado varias veces en el último tiempo; antes lanzó un descuento nocturno para horas de menor demanda y luego cambió de estrategia. Si codificas fijo en el modelo de costos una cifra que viste un día, en unos meses se convertirá en un dato erróneo. Lo correcto es tratar el precio unitario como un “parámetro de entrada” del modelo y leerlo en tiempo real desde la página de precios.
Detalles clave de la facturación por franjas horarias de la API de DeepSeek
La esencia de la tarificación pico/valle es trasladar el ahorro de las franjas en que la capacidad de cómputo está ociosa a las tareas que se pueden ejecutar con retraso. Para el cálculo, hay tres detalles en los que es fácil equivocarse. Primero, la zona horaria: las franjas oficiales suelen definirse en hora de Pekín (UTC+8), mientras que muchos logs de servidor registran por defecto UTC; si no haces la conversión, clasificarás mal todo el lote de solicitudes. Segundo, las solicitudes que cruzan franjas: una solicitud de salida en streaming larga puede empezar en hora pico y terminar en hora valle; hay que ver si se factura por la hora de inicio o por la de fin según las reglas oficiales. Tercero, los reintentos: una solicitud que falla y se reintenta puede caer en otra franja; conviene calcularla según la hora de la solicitud que finalmente se completó con éxito.
Detalles clave del cobro por herramientas de la API de DeepSeek
La trampa del cobro por herramientas es la “doble facturación”. Tomemos como ejemplo una herramienta de búsqueda web: una sola llamada puede generar, además del costo de la herramienta por uso, resultados que se inyectan en el contexto y se vuelven a cobrar como tokens de entrada en la ronda siguiente. Si el modelo llama tres o cuatro veces seguidas a herramientas dentro de un mismo turno de conversación, el costo en tokens crece a medida que se acumula el contexto. Por eso, al calcular el costo de herramientas hay que contabilizar a la vez el “número de llamadas” y los “tokens de entrada adicionales que aportan los resultados de la herramienta”; ninguna de las dos cosas puede faltar.
Guía rápida del coste de invocación de la API de DeepSeek: recálculo en 5 pasos
El siguiente proceso no requiere escribir ningún código: basta con exportar registros y usar una hoja de cálculo. Si ya tienes una plataforma de datos, traduce estos pasos a SQL o a informes.
Paso 1: preparar la tabla de parámetros de precios
Primero crea una «tabla de parámetros de precios»; cada fila es una variable de facturación y todos los precios unitarios se toman de la página de precios, registrando la fecha de consulta. Este paso determina la exactitud de todos los cálculos posteriores.
| Nombre de variable | Significado | Fuente de datos |
|---|---|---|
| Precio unitario de entrada con acierto de caché en horario pico | Precio de entrada con acierto de caché durante el horario pico | Página de precios de APIYI docs.apiyi.com/models |
| Precio unitario de entrada sin acierto de caché en horario pico | Precio de entrada sin acierto de caché durante el horario pico | Página de precios de APIYI docs.apiyi.com/models |
| Precio unitario de salida en horario pico | Precio de los tokens de salida durante el horario pico | Página de precios de APIYI docs.apiyi.com/models |
| Tres precios unitarios correspondientes al horario valle | Precios de entrada, caché y salida durante el horario valle | Página de precios de APIYI y anuncios oficiales |
| Precio unitario por invocación de herramienta | Criterio de facturación y precio unitario de cada tipo de herramienta | Página de precios de APIYI y anuncios oficiales |
| Límites de franja horaria | Horas de inicio y fin de pico/valle y zona horaria | Anuncio oficial de DeepSeek |
💡 Sugerencia sobre fuentes de datos: actualiza periódicamente la tabla de parámetros de precios comparándola con la página de precios de APIYI docs.apiyi.com/models y anota en la tabla la «fecha de consulta». Cuando el precio oficial cambie, solo tendrás que modificar esta tabla y todo el modelo de costes se actualizará automáticamente.
Paso 2: Exportar el registro de uso con marcas de tiempo
Cada registro de solicitud debe incluir al menos estos campos: hora de inicio de la solicitud, nombre del modelo, número de tokens de entrada, cuántos de ellos acertaron en caché, número de tokens de salida, número de llamadas a herramientas y tipo de herramienta. El campo usage de la respuesta de DeepSeek devuelve las estadísticas de tokens con y sin acierto de caché; en los modelos de razonamiento, los tokens de pensamiento también se contabilizan como salida. Si tu registro solo guarda el total de tokens, conviene completar antes la instrumentación; de lo contrario, los cálculos que hagas después no pasarán de ser una estimación gruesa.
Paso 3: Agrupar por franjas horarias
Convierte primero todas las marcas de tiempo a hora de Pekín y luego etiqueta cada solicitud como «pico» o «valle» según los límites entre horas punta y horas valle. Recomendamos además hacer una subdivisión por hora, así podrás ver la forma de onda del tráfico del negocio y tendrás una base para programar mejor las tareas. Muchos equipos, al llegar a este punto, descubren que una parte considerable de sus solicitudes proviene en realidad de tareas programadas y que podrían trasladarse perfectamente a las horas valle.
Paso 4: Cálculo desglosado del costo de tokens y el costo de herramientas
Para cada intervalo de tiempo, calcula por separado: costo de tokens = entrada con acierto de caché × precio unitario correspondiente + entrada con fallo de caché × precio unitario correspondiente + salida × precio unitario correspondiente; costo de herramientas = número de llamadas de cada tipo de herramienta × precio unitario de la herramienta correspondiente. Al final, suma los dos intervalos, pico y valle, y obtendrás el costo total bajo el nuevo criterio.
Un ejemplo ilustrativo usando solo volúmenes de uso, sin precios: supongamos que una aplicación de atención al cliente recibe 10.000 solicitudes al día, con una entrada media de 3.000 tokens por solicitud, de los cuales alrededor del 60 % aciertan en caché, y una salida de 500 tokens; además, de media, cada 5 solicitudes se activa una herramienta de búsqueda. Entonces, cada día se generarán aproximadamente 12 millones de tokens de entrada con acierto de caché, unos 18 millones de tokens de entrada sin acierto de caché, alrededor de 5 millones de tokens de salida y unas 2.000 llamadas a herramientas, además de los tokens de entrada adicionales que genera la inserción de resultados de herramientas. Si distribuyes estas cantidades según la proporción pico-valle y las multiplicas por los precios unitarios de la tabla de parámetros de precios, obtendrás el costo diario real.
Paso 5: Comparar con el criterio anterior y detectar oportunidades de optimización
Compara el resultado del nuevo criterio con la estimación anterior basada en un “precio promedio único”; la parte con la mayor diferencia será el foco de la optimización. Las conclusiones habituales son de tres tipos: la proporción de horas pico es demasiado alta, las llamadas a herramientas son demasiado frecuentes o la tasa de acierto de caché es baja. En la siguiente sección veremos acciones concretas para estos tres casos.
🚀 Inicio rápido: Si quieres probar la diferencia de costos entre DeepSeek y otros modelos con el mismo conjunto de interfaces, puedes realizar las llamadas a través de APIYI apiyi.com. APIYI ofrece las API de los modelos DeepSeek que aparecen en este artículo y es compatible tanto con los formatos de interfaz de OpenAI como con los de Anthropic; normalmente, solo tendrás que cambiar base_url y la clave API en el código existente para conectarte. Encontrarás las direcciones y los parámetros concretos en el centro de documentación docs.apiyi.com.
Escenarios de aplicación y estrategias de costos con la tarificación pico/valle de la API de DeepSeek
Distintos tipos de aplicaciones tienen una sensibilidad muy diferente a la tarificación pico/valle y al cobro por herramientas. Primero identifica en qué categoría encajas y luego decide la dirección de optimización; esto es más efectivo que aplicar una solución única como «moverlo todo a la noche».
| Tipo de aplicación | Flexibilidad horaria | Dependencia de herramientas | Estrategia recomendada | Plataforma disponible |
|---|---|---|---|---|
| Atención al cliente en línea / chatbots | Baja, deben responder en tiempo real | Media | Mejorar la tasa de aciertos de caché y simplificar las llamadas a herramientas | APIYI apiyi.com, DeepSeek oficial |
| Procesamiento por lotes de documentos / etiquetado de datos | Alta, se puede ejecutar con retraso | Baja | Programar todo en horas valle | APIYI apiyi.com, DeepSeek oficial |
| Búsqueda con IA / asistentes de investigación | Media | Alta | Controlar el número de rondas de llamadas a herramientas y comprimir el contenido que se reinyecta | APIYI apiyi.com, DeepSeek oficial |
| Agentes de código | Media | Alta | Combinar llamadas a herramientas y acortar el contexto | APIYI apiyi.com, DeepSeek oficial |
| Tareas programadas de generación de contenido | Alta | Media | Generar por lotes en horas valle y solo revisar en horas pico | APIYI apiyi.com, DeepSeek oficial |
Optimización de costos de la API de DeepSeek en aplicaciones en tiempo real
Las aplicaciones en tiempo real no pueden evitar las horas pico, así que el foco debe estar en la caché y las herramientas. Coloca el System Prompt fijo, el resumen de la base de conocimiento y los ejemplos Few-shot al principio de los mensajes y manténlos idénticos a nivel de bytes; esto puede aumentar de forma notable la tasa de aciertos de caché. En cuanto a las herramientas, primero puedes hacer una evaluación ligera para decidir «si realmente se necesita buscar» y evitar que el modelo llame repetidamente en escenarios innecesarios.
Programación en horas valle de la API de DeepSeek para aplicaciones offline
Las tareas offline son las que más se benefician de la tarificación pico/valle. La idea es añadir una capa de cola de tareas entre el sistema de negocio y la invocación del modelo: en horas pico solo se encolan, y en horas valle los consumidores las procesan de forma centralizada. Hay que tener en cuenta dos cosas: primero, la concurrencia se concentra en horas valle, así que hay que evaluar de antemano los límites de velocidad y, si hace falta, aplicar limitación de tasa por lotes; segundo, hay que definir un tiempo de espera máximo para las tareas, para evitar que las que no se completen en horas valle pasen a la siguiente hora pico y terminen liquidándose a precio alto.
Comparación de opciones de optimización del costo por herramientas en la API de DeepSeek
El cobro por herramientas es una partida nueva y también la más fácil de descontrolar, porque su consumo lo decide el propio modelo. La siguiente tabla compara varias formas habituales de controlarlo.
| Opción de optimización | Fuente del ahorro | Casos de uso | Consideraciones |
|---|---|---|---|
| Evaluación previa de intención | Reduce el número de llamadas innecesarias a herramientas | Asistentes de búsqueda, atención al cliente | La evaluación en sí también consume tokens; conviene usar una indicación ligera |
| Limitar el número máximo de rondas de llamada | Pone un tope al costo de herramientas por solicitud | Aplicaciones tipo agente | Si hay muy pocas rondas, puede afectar la calidad de la respuesta |
| Comprimir los resultados devueltos por las herramientas | Reduce los tokens de entrada generados al reinsertar resultados | Herramientas de búsqueda y recuperación | Conservar solo el resumen y los campos clave |
| Reutilización de caché de resultados | Evita repetir llamadas para la misma consulta | Escenarios con preguntas frecuentes concentradas | Configurar un tiempo de expiración razonable para evitar información desactualizada |
| Sustitución por recuperación propia | Usar una base de conocimiento propia en lugar de herramientas de pago | Negocios con conocimiento de dominio estable | Hay que evaluar el costo de desarrollo y mantenimiento propios |
Interpretación de la comparación
La evaluación previa de intención es la que tiene un efecto más directo sobre la frecuencia de llamadas y encaja en la mayoría de escenarios conversacionales; sin embargo, añade una pequeña sobrecarga de evaluación a cada solicitud, y en conversaciones cortas puede que no compense. En cambio, comprimir los resultados devueltos por las herramientas casi no tiene efectos secundarios: es una práctica que toda aplicación con herramientas debería activar por defecto. Limitar el número máximo de rondas de llamada se parece más a un fusible, y sirve para evitar que solicitudes aisladas generen facturas anómalas porque el modelo llame a herramientas repetidamente.
💡 Recomendación de elección: el efecto de la optimización de costos de herramientas varía mucho según el negocio, así que conviene hacer primero una comparación A/B con poco tráfico. Con APIYI apiyi.com puedes cambiar entre distintos modelos bajo el mismo formato de interfaz para hacer pruebas comparativas y, junto con el precio unitario en tiempo real de la página de precios docs.apiyi.com/models, calcular más rápido el beneficio real de cada opción.
Preguntas frecuentes
P1: ¿Qué es el precio pico-valle de la API de DeepSeek?
El precio pico-valle significa que un mismo modelo se factura con tarifas distintas según la franja horaria: normalmente el precio es más bajo en horario valle (fuera de punta), lo que sirve para orientar las tareas que pueden posponerse hacia momentos de menor carga de cómputo. Los límites exactos de las franjas y el porcentaje de descuento deben consultarse en los anuncios oficiales de DeepSeek y en la página de precios de APIYI.
P2: ¿Qué diferencia hay en el método de cálculo entre el precio pico-valle y el precio único anterior?
Con el precio único basta con «total de Tokens × precio unitario»; con el precio pico-valle primero hay que agrupar las solicitudes por franja horaria, aplicar el precio de cada franja por separado y luego sumar la tarifa de invocación de herramientas. Estimar con un precio medio diario oculta el sesgo que introduce la proporción de tráfico en horas pico, sobre todo en negocios cuya carga se concentra en el horario diurno.
P3: Si una solicitud cruza entre franjas pico y valle, ¿con qué hora se factura?
Depende de las reglas de facturación oficiales; el criterio habitual es tomar la hora de inicio de la solicitud, pero no conviene darlo por sentado. Se recomienda convertir el «punto temporal de facturación» en un parámetro configurable dentro del modelo de cálculo, rellenarlo una vez confirmado el criterio oficial y, además, marcar aparte las solicitudes de streaming de larga duración para hacer verificaciones por muestreo.
Q4: ¿Por qué el cobro de herramientas puede hacer que el costo se «multiplique»?
Porque la invocación de herramientas suele generar dos cargos: la tarifa de la invocación en sí y el costo del resultado de la herramienta al reinyectarse en el contexto y facturarse de nuevo como Tokens de entrada. En invocaciones de herramientas de varias rondas el contexto no deja de crecer, y cada ronda posterior paga por los resultados anteriores, así que hay que controlar a la vez el número de invocaciones y la longitud del contenido reinyectado.
P5: ¿Cómo invocar DeepSeek rápidamente vía API y verificar el costo?
Puedes seguir estos pasos:
1. Entra en APIYI apiyi.com, registra una cuenta y obtén una clave API
2. Consulta la dirección de acceso en el centro de documentación docs.apiyi.com y elige el formato compatible con OpenAI o Anthropic
3. Consulta en la página de precios docs.apiyi.com/models los precios unitarios de entrada, salida y caché de los modelos de DeepSeek correspondientes
4. Ejecuta el cálculo de 5 pasos de este artículo con solicitudes de bajo volumen y compáralo con la factura de control para calibrar
APIYI ofrece la invocación de los modelos DeepSeek tratados en este artículo, con un formato de interfaz compatible con los SDK más habituales, lo que facilita sustituirlos y validarlos directamente en proyectos existentes.
P6: Al invocar a través de una plataforma de terceros, ¿los criterios de pico-valle y de cobro de herramientas son los mismos?
Los criterios de facturación de distintas plataformas pueden diferir de los oficiales, por ejemplo en si se distingue por franja horaria o cómo se convierte la tarifa de herramientas. Cuando invoques a través de APIYI, toma como referencia los datos reales indicados en la página de precios de APIYI docs.apiyi.com/models y no apliques directamente la tabla de precios oficial; confirmar esto antes de hacer el cálculo evita la mayor parte de las discrepancias en la conciliación.
P7: ¿Qué limitaciones conocidas tiene el cálculo de costos de la API de DeepSeek?
Principalmente tres. Primero, los precios cambian, así que el modelo debe admitir actualizaciones parametrizadas. Segundo, la longitud de los Tokens de razonamiento de los modelos de inferencia fluctúa mucho y estimar con la media genera un error elevado, por lo que conviene usar percentiles. Tercero, el número de invocaciones de herramientas lo decide el propio modelo y varía notablemente con la misma indicación según la entrada, así que requiere monitoreo continuo en lugar de una estimación puntual.
Puntos clave del cálculo de costos con precios pico y valle de la API de DeepSeek
- El costo pasa a ser multidimensional: el horario, la caché, la salida y las herramientas determinan juntos la factura.
- El precio unitario debe parametrizarse: usa los datos en tiempo real de la página de precios de APIYI como referencia; no lo codifiques de forma fija.
- Alinea primero la zona horaria: convierte todos los registros a hora de Beijing antes de separarlos en franjas pico y valle; así evitas clasificar mal todo el lote.
- Las herramientas se facturan dos veces: la tarifa de llamada más los tokens de relleno; hay que contabilizar ambos.
- Mueve las tareas offline al horario valle: usar una cola de tareas para suavizar los picos es la optimización con el retorno más directo.
- Para tareas en tiempo real, apóyate en la caché: mantén fijo el prefijo para mejorar la tasa de aciertos de caché.
- El cálculo se puede validar rápido: haz una prueba con poco tráfico a través de la interfaz compatible de APIYI y calibra el modelo comparándolo con la factura.
Resumen
Después de que la API de DeepSeek introdujo los precios pico y valle y el cobro por herramientas, el cambio central en el cálculo de costos se puede resumir en tres puntos:
- De un total agregado a un desglose por franjas: divide las solicitudes por franja horaria y aplica precios distintos a pico y valle para ver la estructura real de costos.
- De solo tokens a tokens más herramientas: la tarifa de herramientas es un costo aparte y además puede elevar el consumo de tokens de entrada.
- De la estimación estática al monitoreo continuo: los precios y el uso cambian, así que el modelo de cálculo debe parametrizarse y recalibrarse con regularidad.
Te sugiero ejecutar primero el flujo de 5 pasos de este artículo sobre los registros de la última semana, identificar tres indicadores clave —proporción de uso en horario pico, frecuencia de llamadas a herramientas y tasa de aciertos de caché— y luego optimizar de forma específica. Si necesitas probar DeepSeek y otros modelos bajo una interfaz unificada, puedes conectarte a través de APIYI apiyi.com; para el modo de acceso, consulta el centro de documentación docs.apiyi.com. Todos los precios unitarios deben tomarse de los datos reales de la página de precios docs.apiyi.com/models.
📚 Referencias
- Reportaje de 36Kr: «Liang Wenfeng baja de la montaña, ¿qué está buscando DeepSeek?»
- Enlace:
36kr.com/p/4055279154779015 -
Descripción: Reportaje del sector sobre los recientes movimientos comerciales de DeepSeek, útil como referencia para entender el contexto del ajuste de precios.
-
Página de precios de APIYI: precio unitario de entrada, salida y caché de modelos como DeepSeek
- Enlace:
docs.apiyi.com/models -
Descripción: Fuente de todos los parámetros relacionados con precios en este artículo; conviene verificarlos antes de hacer los cálculos.
-
Centro de documentación de APIYI: métodos de integración y descripción del formato de la interfaz
- Enlace:
docs.apiyi.com -
Descripción: Incluye instrucciones de integración en formatos compatibles con OpenAI y Anthropic.
-
Documentación oficial de la API de DeepSeek: reglas de facturación y descripción del campo usage
- Enlace:
api-docs.deepseek.com - Descripción: Los límites de las franjas horarias pico y valle, el mecanismo de caché y los criterios de facturación de herramientas se rigen por lo indicado en la documentación oficial.
Autor: Equipo técnico de APIYI
Intercambio técnico: Si tienes problemas durante el cálculo de costos o el proceso de integración, no dudes en contactarnos a través del sitio web oficial de APIYI, apiyi.com. Para más materiales de integración, puedes consultar el centro de documentación en docs.apiyi.com
