Precios de DeepSeek V4: 20-50 veces más barato que OpenAI (Desglose de costos)

Precios de DeepSeek V4: 20-50 veces más barato que OpenAI (Desglose de costos)

Recientemente, estuve buscando un modelo más silencioso, algo que pudiera usar frecuentemente sin vigilar el contador cada hora. DeepSeek V4 apareció una y otra vez en conversaciones con otros desarrolladores, generalmente con una ceja levantada: “Es… realmente barato.”

Dora está aquí. Pasé la segunda mitad de enero de 2026 integrándolo en algunos flujos de trabajo pequeños: un resumidor de investigación, un reescritor de notas de producto y un organizador semanal de pendientes. Nada sofisticado. Me importaba cómo se traducían los tokens en dólares reales durante una semana normal. Aquí está lo que aprendí sobre el costo de DeepSeek V4 API, los descuentos que importan, y una forma muy simple de presupuestarlo antes de lanzar.

Precios actuales de DeepSeek

No pretenderé que los números sean estables. Los precios se mueven, y difieren según dónde compres acceso (directo vs. a través de un intermediario como OpenRouter). Entonces, dos puntos de referencia:

  • Verifica la fuente: la documentación oficial de DeepSeek API y la página de precios. Son las tasas canónicas cuando te conectas directamente.
  • Si diriges a través de un mercado, abre la tarjeta del modelo. Por ejemplo, los modelos de DeepSeek en OpenRouter listan las tasas por millón de tokens y cualquier descuento basado en tiempo. Lo que vi a finales de enero de 2026 en todos los proveedores fue consistente en espíritu: DeepSeek V4 se sitúa bien por debajo de los modelos frontera tanto para tokens de entrada como de salida. Los centavos exactos varían. Estoy compartiendo cómo trabajo con los precios en lugar de congelarlos en su lugar.

Tasas estándar

Si eres nuevo en la facturación de modelos basada en uso, dos líneas importan:

  • Tokens de entrada (lo que envías): cobrados por 1M de tokens.
  • Tokens de salida (lo que recibes): también cobrados por 1M de tokens, generalmente más alto que la entrada.

En mis ejecuciones, las tasas brutas de V4 fueron lo suficientemente bajas como para que los picos diarios pequeños no dolieran. Eso se muestra más en trabajos por lotes. Por ejemplo, mi organizador semanal de pendientes envía ~20 indicaciones de ~3–5K tokens de entrada cada una y recibe ~1–2K tokens de salida. Incluso con tasas de muestra conservadoras, el total para toda la ejecución se mantuvo en la zona del “dinero para café”.

Dos notas prácticas:

  • La inflación de salida se cuela sin notarse. Si tus indicaciones fomentan pensamientos largos, la línea de salida puede duplicar tu factura. Establecí un límite máximo en max_tokens e hice el estilo más apretado. Ahorré dinero, mejores resultados.
  • El tamaño del fragmento importa. Si estás resumiendo documentos largos, pagarás por cada token superpuesto. Pasé de una superposición de 1,600 tokens a 400 y no perdí calidad.

Descuentos por aciertos en caché (90% de descuento)

Este cambió mis cálculos mentales. Algunas plataformas y proveedores de modelos admiten almacenamiento en caché de indicaciones para prefijos repetidos. Si tus primeros N tokens de la indicación no cambian (mensaje del sistema, instrucciones compartidas, esquema), los aciertos en caché pueden facturarse con un descuento pronunciado. 90% de descuento es la cifra que he visto documentada en algunas implementaciones de almacenamiento en caché de proveedores (la disponibilidad varía: confirma en la página de precios de tu proveedor).

Lo que esto parecía en la práctica:

  • Mi resumidor de investigación comparte un indicador del sistema largo y fijo y un esquema de herramientas estable. Solo cambia el texto de origen.
  • Después de la primera llamada, las llamadas posteriores alcanzan el caché para ese prefijo compartido.
  • En plataformas que honran la facturación de caché, esos tokens reutilizados se redujeron a la tasa con descuento.

Dos advertencias de las pruebas:

  • “Cercano” no se almacena en caché. Cambia una línea en el prefijo compartido y perderás el acierto.
  • Los esquemas grandes y fijos se pagan por sí solos. Si puedes consolidar instrucciones y herramientas en un prefijo estable, hazlo una vez y aprovecha el caché.

Si tu proveedor no expone el almacenamiento en caché, aún puedes simular parte de los ahorros moviendo la orientación repetida a un indicador del sistema más corto y consistente y eliminando la redundancia de los mensajes del usuario.

Descuentos fuera de horas pico (75% de descuento)

Algunos mercados han comenzado a ofrecer descuentos basados en tiempo para suavizar la demanda. He visto ventanas fuera de horas pico con cortes pronunciados (números como 50–75% de descuento aparecen, pero depende del revendedor y del modelo). Los modelos de DeepSeek tienden a participar porque su economía ya se inclina hacia la eficiencia.

Dos formas en que esto me ayudó:

  • Programé mi trabajo semanal de pendientes para la ventana fuera de horas pico. Misma carga de trabajo, artículo de línea más bajo.
  • Agrupé los resúmenes de investigación durante la noche. La latencia no importaba, y el descuento sí.

Esto no es universal. Si te conectas a DeepSeek directamente, verifica si publican algún precio según la hora del día. Si vas a través de un intermediario, lee la letra pequeña de la tarjeta del modelo. La diferencia puede ser lo suficientemente grande como para cambiar cuándo ejecutas las cosas.

Por qué DeepSeek es tan barato

Quería entender si el precio bajo era algo promocional, o si la arquitectura realmente lo soporta. De lo que es público, dos piezas se destacaron.

Arquitectura MoE

Los modelos grandes más nuevos de DeepSeek se apoyan en Mezcla de Expertos (MoE). En términos simples: en lugar de despertar el cerebro completo para cada token, el router elige algunos subnetworks de expertos para manejarlo. Aún obtienes un modelo capaz, pero solo una fracción de los parámetros funcionan por paso, lo que reduce la computación y el costo.

Por qué esto importa en la práctica:

  • El rendimiento se escala mejor. De mi lado, la latencia p95 se mantuvo razonable incluso cuando empujé trabajos paralelos.
  • Los costos no se disparan linealmente con la complejidad. Las indicaciones largas no castigaban tan duramente como lo hacen en modelos densos, siempre activos.

He usado otros modelos MoE que se sentían frágiles en tareas especializadas: V4 manejó indicaciones pesadas en estructura (salidas JSON, uso de herramientas) sin tambalear. Esa estabilidad es parte de la historia de costos también: menos reintentos, menos repeticiones.

Eficiencia de Engram

La documentación de DeepSeek menciona trabajo en manejo de contexto y eficiencia de memoria (destacan cosas como enrutamiento de atención mejorado y manejo de caché KV en algunas versiones). No puedo verificar los internales, pero puedo compartir lo que observé:

  • Las indicaciones de contexto largo no colapsaron el rendimiento en mis pruebas en enero de 2026. Ejecuté contextos de 32K tokens sin la sensación de “todo se convierte en melaza”.
  • El formato determinista se mantuvo a una temperatura más alta de lo que esperaba, lo que significaba que podía mantener las salidas más cortas sin colapsar la calidad.

Mi lectura: el precio no es un truco de marketing. Es el resultado de una arquitectura que está construida para mantener la computación por token baja, más una disposición a pasar eso al precio de etiqueta. Si tienes curiosidad sobre las notas técnicas, comienza con la documentación oficial de DeepSeek y cualquier artículo vinculado desde sus tarjetas de modelo.

Plantilla de calculadora de costos

Ya no bloqueo presupuestos a centavos exactos. Planeo rangos, luego ajusto una vez que el uso real se estabiliza. Aquí está la plantilla que usé para DeepSeek V4. Es lo suficientemente simple como para recrearla en una hoja de cálculo.

Entradas que completarás por carga de trabajo:

  • Llamadas por día (o por lote)
  • Tokens de entrada promedio por llamada
  • Tokens de salida promedio por llamada
  • Tasa de entrada por 1M de tokens (de tu proveedor)
  • Tasa de salida por 1M de tokens (de tu proveedor)
  • Tokens de prefijo almacenable en caché por llamada (0 si ninguno)
  • Descuento por acierto en caché (ej. 0.90 para 90% de descuento)
  • Multiplicador fuera de horas pico (ej. 0.25 si 75% de descuento, sino 1)

Pasos:

  1. Divide los tokens de entrada almacenable en caché y no almacenable en caché.

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)
  2. Precio la porción almacenable en caché a la tasa con descuento.

    • cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)
  3. Precio la entrada variable a la tasa de entrada completa.

    • variable_input_cost = (variable_input / 1,000,000) × input_rate
  4. Precio la salida a la tasa de salida.

    • output_cost = (avg_output_tokens / 1,000,000) × output_rate
  5. Súmalos por llamada, luego aplica cualquier multiplicador fuera de horas pico.

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier
  6. Escala por volumen.

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

Un pequeño ejemplo real de mi semana de pruebas (23–30 de enero de 2026):

  • 120 llamadas/día
  • 3,200 tokens de entrada/llamada, de los cuales 1,800 son un prefijo fijo y almacenable en caché
  • 1,100 tokens de salida/llamada
  • Tasas de ejemplo: $0.40 por 1M de entrada, $1.60 por 1M de salida (reemplaza con los tuyos)
  • Descuento por acierto en caché: 90%
  • Multiplicador fuera de horas pico: 0.5 (ventana del 50% de descuento usado a través de un revendedor)

Matemáticas (redondeadas):

  • Costo almacenable en caché por llamada = (1,800/1,000,000) × $0.40 × (1 − 0.90) ≈ $0.0000072
  • Costo de entrada variable por llamada = (1,400/1,000,000) × $0.40 ≈ $0.00056
  • Costo de salida por llamada = (1,100/1,000,000) × $1.60 ≈ $0.00176
  • Costo bruto por llamada ≈ $0.0023272
  • Ajustado fuera de horas pico ≈ $0.0011636
  • Diario ≈ $0.14
  • Mensual ≈ $4.20

Eso no es un error tipográfico. Las tasas bajas por millón más el almacenamiento en caché y fuera de horas pico convirtieron un servicio de “vigilar el contador” en algo que puedo olvidar. No ahorró tiempo al principio, pasé una hora haciendo que el prefijo almacenable en caché fuera realmente fijo, pero cada llamada después se hizo más barata.

Algunos límites que mantengo en la hoja:

  • Establece límites máximos duros en max_tokens. La hinchazón de salida es el asesino silencioso del presupuesto.
  • Rastrea los reintentos por separado. Los reintentos son gasto real.
  • Registra los tokens promedio semanalmente. La deriva de tokens ocurre a medida que evolucionan las indicaciones.

A quién le conviene esto:

  • Equipos que ejecutan muchas llamadas pequeñas y similares (ETL, resumen, QA).
  • Creadores con trabajos por lotes que pueden pasar a fuera de horas pico.

A quién puede no gustarle:

  • Aplicaciones que necesitan salidas largas y transmitidas todo el día, en horas pico. Los ahorros se reducen.
  • Configuraciones sin soporte de almacenamiento en caché. Aún pagarás tasas bajas, pero no las ridículamente bajas.

Si quieres un punto de partida, reconstruye la plantilla anterior en la herramienta de tu elección. Son 10 minutos de configuración y ahorran horas de conjeturas después.

Una última nota: si estás mezclando proveedores, normaliza todo a “costo por 1K tokens” en tu hoja también. Facilita comparaciones rápidas uno a uno cuando estés decidiendo si mantener V4 en la mezcla o cambiar una tarea a un modelo frontera por razones de calidad.

Sigo observando cómo se desplazan las ventanas fuera de horas pico. Últimamente se han movido más temprano en la tarde. No es un problema para trabajos por lotes, solo algo que sigo de cerca.