DeepSeek V4-Flash-Vision-Exp: precio, visión y enrutamiento

El lanzamiento registrado el 21 de agosto de 2026 colocó a DeepSeek-V4-Flash-Vision-Exp en la documentación oficial de DeepSeek como un modelo experimental que acepta entrada de imágenes además de texto. La tabla de precios publicada muestra US$ 0,22 por millón de tokens de input en cache miss fuera de hora punta. Para el comprador, la consecuencia es directa: la ruta multimodal debe medirse por solicitud, no elegirse por un precio aislado. La página oficial de precios fue consultada el 25 de agosto de 2026.

¿Qué se lanzó y qué confirma la documentación?

La documentación oficial confirma que DeepSeek-V4-Flash-Vision-Exp es experimental, utiliza deepseek-v4-flash-vision-exp en la llamada a la API y acepta entrada de imágenes además de texto. La misma página publica seis valores por millón de tokens, divididos entre input en cache hit, input en cache miss y output, en dos ventanas de cobro. Ese es el hecho central, sin extrapolación.

Hecho confirmado: la página Your First API Call lista deepseek-v4-flash-vision-exp como identificador de API e informa que la versión experimental acepta imágenes. La página de precios nombra la versión DeepSeek-V4-Flash-Vision-Exp. La documentación también informa que la conversión de imágenes a tokens depende de sus dimensiones. Este texto no reproduce benchmarks ni declara liderazgo, superioridad o equivalencia.

Los seis precios publicados son:

Cache hit y cache miss son las dos categorías publicadas para el cobro del input. El comprador debe usar el consumo registrado por el proveedor y el estado de cache de cada solicitud para clasificar la llamada. Si explica mecanismos de prefijo o cache de contexto, necesita consultar la documentación específica, porque la tabla de precios no define esa semántica.

La documentación define como hora punta los periodos de 01:00 a 04:00 UTC y de 06:00 a 10:00 UTC, de lunes a viernes. Todos los demás periodos se clasifican en la nota de la tabla como fuera de hora punta. Un equipo que opera en Brasil debe registrar la hora en UTC, en lugar de inferir la franja desde el reloj local del servicio. La hora cambia la cuenta.

La página oficial también advierte que los precios pueden variar y que el proveedor puede ajustarlos. Por eso, los seis valores anteriores son el registro fechado de la tabla oficial consultada el 25 de agosto de 2026. No son una promesa de costo efectivo para una aplicación específica ni sustituyen la lectura periódica de la documentación oficial.

Inferencia operativa: el comprador debe guardar la fecha de lectura de la tabla junto con el informe de consumo. Sin esa fecha, una comparación hecha semanas después mezcla el precio de referencia con el precio vigente.

¿Por qué el precio por token no basta en una solicitud multimodal?

El precio por token no basta porque una imagen enviada a DeepSeek-V4-Flash-Vision-Exp se convierte en tokens según sus dimensiones y se cobra junto con los tokens de input del texto. El costo de la solicitud depende, por tanto, de la imagen, el texto, el cache, la franja horaria y el output consumido. La medición cambia la decisión.

La fórmula publicada por la documentación es sencilla: el gasto resulta del número de tokens multiplicado por el precio correspondiente. La parte difícil es identificar correctamente el número y la categoría de cada token. En una solicitud multimodal, los tokens de la imagen entran en el input. La tabla consultada no muestra un cobro separado para imágenes.

La documentación oficial de Vision, consultada el 25 de agosto de 2026, informa que las imágenes se redimensionan antes de la inferencia. Las imágenes grandes se reducen a un presupuesto aproximado de 800 x 800 píxeles totales, las imágenes pequeñas se amplían y cada imagen tiene un límite superior documentado de 384 tokens bajo esa regla de procesamiento. En una solicitud con varias imágenes, cada imagen se cuenta de forma independiente. El límite de 384 tokens está condicionado a esa mecánica documentada, no es una propiedad general de los modelos multimodales.

Las dimensiones de la imagen permiten estimar la tokenización, y la página de uso de tokens ofrece una calculadora para tamaños específicos. Esa estimación no sustituye los tokens de imagen registrados efectivamente en la respuesta de uso de la API, que deben separarse de la estimación al comparar el cobro. Sin nombrar y citar el campo de uso correspondiente en la documentación de la API, este artículo no trata ese registro como definitivo. No existe un costo universal para una foto, una captura de pantalla, una página escaneada o un cuadro técnico. Una estimación no es una factura.

Este punto cambia la unidad de análisis. “US$ 0,22 por millón” describe el precio del input en cache miss fuera de hora punta. No describe el costo de una solicitud que combina imagen, instrucción textual y respuesta. Del mismo modo, “US$ 0,007 por millón” vale para input en cache hit fuera de hora punta, no para cualquier entrada enviada al modelo.

El output merece una línea propia. La tabla publica US$ 0,66 por millón de tokens fuera de hora punta y US$ 1,32 por millón de tokens en hora punta. Una tarea con poco input y una respuesta extensa no debe compararse solo por la línea del input. El output debe permanecer separado en el informe.

El error más común es sumar los tokens de input y output como si fueran una misma categoría. Eso borra la diferencia entre input en cache hit, input en cache miss y output. El segundo error es tratar la imagen como un archivo adjunto sin peso económico. La documentación oficial dice lo contrario: la imagen convertida entra en el cobro del input.

Punto aún no verificado: la documentación consultada no permite afirmar un costo universal por clase de imagen. Las dimensiones permiten una estimación, pero los tokens y el uso registrados efectivamente en cada llamada definen la referencia de la API. Tampoco corresponde convertir los precios publicados en un porcentaje de ahorro sin datos de uso comparables. La medición cierra la duda.

¿Qué cambia para el comprador de IA en producción?

Para el comprador de IA en producción, la entrada de imágenes amplía el conjunto de tareas que puede entrar en evaluación, pero aumenta las variables que deben observarse. La decisión correcta no es adoptar el modelo porque parece barato. Es probar el costo por tarea completada, la calidad de la respuesta, la latencia, el comportamiento del cache y la disponibilidad en el flujo que se enrutará. El precio no decide por sí solo.

Hecho confirmado: DeepSeek describe el modelo como experimental. La documentación consultada no respalda una recomendación universal, disponibilidad general, SLA ni liderazgo de rendimiento. El texto de la tabla tampoco es un benchmark de calidad visual o textual.

Inferencia operativa: el CTO debe tratar el modelo como una ruta candidata, no como destino predeterminado. El líder de plataforma debe separar las tareas que usan imágenes de las tareas de texto y registrar si la respuesta cumple el criterio de negocio. FinOps debe mirar el costo por tarea completada, porque los tokens baratos no garantizan una respuesta útil en el primer intento.

La documentación oficial de precios, consultada el 25 de agosto de 2026, lista 1 millón de tokens de contexto, un máximo de 384 mil tokens de output y un límite de concurrencia de 2.500 para deepseek-v4-flash-vision-exp. La guía oficial de Vision, consultada en la misma fecha, documenta formatos de imagen compatibles, un límite de 48 MiB para el cuerpo de la solicitud, 32 MiB para imágenes en base64 o URL externa, 64 MiB para IDs de la Files API y hasta 600 imágenes por solicitud. El máximo es de 8.192 píxeles por lado, reducido a 4.096 píxeles cuando la solicitud contiene 15 o más imágenes. Son valores de documentación consultados el 25 de agosto de 2026, no un SLA ni una garantía de disponibilidad.

La clasificación de calidad debe definirse antes de la prueba. Para leer documentos, el equipo puede comprobar campos extraídos correctamente, omisiones y necesidad de revisión humana. En el análisis de imágenes, puede verificar si la respuesta identifica los elementos exigidos por la tarea. El artículo no atribuye al modelo una capacidad que la fuente oficial no describió. La prueba debe responder la pregunta de adecuación.

La latencia y la franja horaria forman parte de la misma decisión. Una ventana fuera de hora punta puede presentar un precio publicado menor, pero el comprador no debe desplazar tráfico sensible sin medir el efecto sobre el tiempo de respuesta y la operación. La hora punta tiene dos franjas UTC. La política debe convertir esa información en un campo observable, no en una regla escondida en el código.

El modo de fallo también debe nombrarse. Un flujo puede enviar una imagen grande, recibir una respuesta incompleta, repetir la solicitud y pagar de nuevo tokens de input y output. También puede enviar la misma tarea a otra ruta sin registrar la causa. Cuando ocurre, el costo por tarea queda invisible y el equipo concluye que el modelo es caro, cuando el problema real fue una política de retry sin trazabilidad.

Ese es el tipo de medición tratado en cómo medir el rendimiento de proveedores de LLM antes de definir una política de enrutamiento. La diferencia aquí es que la entrada de imágenes añade una variable de tokens que debe aparecer en el baseline desde la primera prueba.

¿Cómo comparar el costo antes de cambiar la ruta?

La comparación debe salir del precio unitario y llegar a una política de solicitudes. Antes, un equipo podía mirar la línea del input y elegir la ruta por intuición. Después, debe registrar imagen, texto, output, cache, hora UTC, calidad y costo por tarea, además de mantener un fallback cuando la respuesta o la disponibilidad no cumplan el criterio definido. La hoja de cálculo necesita contexto.

La columna de la derecha no afirma que el modelo tendrá un costo efectivo determinado. Describe lo que el comprador necesita medir para llegar a ese costo. La tabla oficial es el punto de partida. El resultado de producción aparece después de que el equipo observa su propio tráfico.

No hay base para calcular un porcentaje de ahorro a partir de los seis números. El precio fuera de hora punta se publica en una franja, el precio en hora punta en otra, y la solicitud puede combinar cache miss, imagen y output. Sin volumen, dimensiones, distribución de cache, horarios y calidad, cualquier porcentaje sería inventado.

El cambio de ruta también debe considerar la estabilidad del resultado. Si la respuesta falla el criterio de la tarea, un segundo procesamiento puede consumir más tokens que la primera llamada. Si el equipo no registra el retrabajo, la hoja muestra un precio bajo y una operación cara.

El comprador que ya sigue la economía de modelos en el enrutamiento puede reutilizar la disciplina de break-even, pero no debe importar una conclusión de una versión a otra. El evento actual tiene entrada de imágenes y una composición de cobro específica. La unidad correcta sigue siendo la tarea observada.

¿Qué medir en la prueba de DeepSeek V4-Flash-Vision-Exp?

La prueba debe responder cinco decisiones antes de cualquier cambio en la ruta predeterminada: qué tareas entran, qué imágenes se medirán, cómo se compararán cache y hora, qué calidad aprueba la respuesta y cuándo se activa el fallback. Cada decisión necesita un registro por solicitud y un baseline anterior a la adopción. La prueba empieza pequeña.

1. Definir el baseline textual y multimodal. El equipo debe separar las tareas que ya usan texto de las tareas que enviarán imágenes, y registrar volumen, tokens de texto, tokens de output y resultado operativo. Sin ese corte, una variación del costo puede venir de la mezcla de tareas, no del modelo.

2. Crear un corpus representativo y anonimizado. La muestra fija debe contener las clases de imagen que la operación recibe de verdad, como capturas de pantalla, documentos escaneados, imágenes de producto y cuadros técnicos, con dimensiones registradas y datos personales eliminados. El mismo corpus debe ejecutarse con DeepSeek y con la ruta actual, en una comparación pareada.

3. Fijar la rúbrica y medir la calidad. Antes de mirar el precio, el equipo debe definir criterios de aprobación por tarea, como campos correctos, ausencia de omisiones, identificación de los elementos exigidos y necesidad de revisión humana. La rúbrica no cambia durante el ciclo. El informe debe incluir éxito en el primer paso, tasa de revisión humana, retries, latencia y costo por tarea aceptada, junto con tokens y cache.

4. Separar cache y hora. Cada llamada necesita cache_status y hora_utc. El equipo debe comparar input en cache hit con input en cache miss y distinguir las franjas de 01:00 a 04:00 UTC y de 06:00 a 10:00 UTC, de lunes a viernes, de los demás periodos. La tabla publicada orienta la prueba, pero no promete el resultado.

5. Decidir el fallback y el límite de exposición. El equipo debe fijar cuándo la respuesta se enviará a otra ruta, qué límite de gasto aceptará por clave o proyecto y cómo se auditará cada cambio. La política necesita backoff exponencial limitado por un techo, circuit breaker y un presupuesto máximo conjunto de retries y fallbacks por tarea. Los errores transitorios de transporte o del proveedor pueden entrar en la política; las solicitudes inválidas, como formato, tamaño, dimensión o cantidad de imágenes no compatibles, y la selección de un modelo sin Vision deben filtrarse y no repetirse. El trace debe registrar si ocurrió una segunda llamada al proveedor, para hacer visible el cobro duplicado cuando el primer intento ya fue aceptado o procesado parcialmente.

La prueba debe resistir una auditoría. Un informe que solo contiene el gasto total no muestra qué ocurrió con la imagen. Un informe con tokens, pero sin cache, no explica la elección del precio. Un panel que muestra costo, pero omite calidad, no informa si el ahorro se obtuvo con más retrabajo.

El model router como middleware de la stack de IA ayuda a colocar la decisión en el lugar correcto: la aplicación no debería cargar una regla de precio aislada mientras los datos de ruta quedan dispersos en integraciones distintas.

¿Dónde entra Nexforce Router en esta decisión?

Nexforce Router entra como gateway y capa de decisión para comparar rutas de modelos, sin prometer una integración específica con el identificador deepseek-v4-flash-vision-exp. La conexión honesta es operativa: una API, selección por costo, performance, latencia y contexto, fallback configurable, límites, trazabilidad, observabilidad y analytics para la política que el comprador realmente pruebe. La gobernanza va primero.

La referencia del producto describe Router como un gateway LLM con una API para modelos e inteligencia de enrutamiento. Entre las capacidades documentadas están la selección por costo, performance, latencia y contexto, fallback de modelo, ranking de precio y performance, límites por clave, agente o proyecto, logs, métricas, tracing, dashboards, cache y analytics de ahorro y performance. La página institucional de Nexforce Router respalda este mapeo.

Eso no significa que Nexforce haya confirmado para este artículo una integración lista con el identificador de DeepSeek. La documentación oficial consultada confirma el identificador en el endpoint del proveedor. Router se presenta aquí como una capa de gobernanza capaz de recibir una política de decisión, no como prueba de compatibilidad validada con este modelo experimental.

En la práctica, la aplicación puede enviar la solicitud a una capa única mientras la política decide si el tráfico seguirá por una ruta multimodal, por otra ruta disponible o por un fallback. Esa es una inferencia arquitectónica, no una propiedad verificada de esta integración. Una prueba real de Router debe validar la conservación del payload multimodal, la normalización de errores específicos del proveedor, el tratamiento de imágenes y la telemetría de cobro antes de concluir que el cambio de ruta funciona como se espera.

Los límites por clave o proyecto ayudan a impedir que una prueba experimental consuma todo el presupuesto. La trazabilidad conserva la relación entre solicitud, tokens, hora y respuesta. La observabilidad muestra latencia y errores. El analytics organiza costo y performance. Ninguna de estas funciones convierte el precio publicado en ahorro garantizado.

Hecho confirmado: el producto Nexforce Router documenta estas capacidades de gateway, enrutamiento, fallback, límites y observabilidad. Inferencia operativa: son adecuadas para estructurar una prueba del costo multimodal. Punto aún no verificado: la compatibilidad específica con deepseek-v4-flash-vision-exp y el comportamiento del modelo dentro de una ruta de Router no fueron confirmados por las fuentes oficiales usadas en este artículo; la conservación del payload multimodal, la normalización de errores, el tratamiento de imágenes y la telemetría de cobro requieren una prueba de integración.

Preguntas frecuentes sobre DeepSeek V4-Flash-Vision-Exp

DeepSeek-V4-Flash-Vision-Exp es un modelo experimental con entrada de imágenes, y la documentación oficial publica precios distintos para input en cache hit, input en cache miss y output, en hora punta y fuera de hora punta. Las respuestas siguientes mantienen la frontera entre lo que confirma la tabla, lo que el comprador debe medir y lo que sigue sin verificación. La tabla no es un benchmark.

¿Cuánto cuesta DeepSeek V4-Flash-Vision-Exp por millón de tokens?

Fuera de hora punta, la tabla publica US$ 0,007 por millón de tokens para input en cache hit, US$ 0,22 para input en cache miss y US$ 0,66 para output. En hora punta, publica US$ 0,014, US$ 0,44 y US$ 1,32, respectivamente. Son precios de tabla consultados el 25 de agosto de 2026.

¿Cómo se cobra una imagen?

La documentación oficial informa que las imágenes enviadas a DeepSeek-V4-Flash-Vision-Exp se convierten en tokens según sus dimensiones y se cobran como tokens de input junto con el texto. Las dimensiones permiten estimar la tokenización según la documentación, pero el uso registrado en la respuesta de la API es la referencia operativa, sin que este artículo nombre un campo específico como definitivo. No existe un costo universal para cualquier imagen. El registro vence a la estimación.

¿Cuáles son las horas punta?

Las horas punta publicadas son de 01:00 a 04:00 UTC y de 06:00 a 10:00 UTC, de lunes a viernes. Los demás periodos se clasifican como fuera de hora punta en la nota de la tabla. El sistema de medición debe registrar UTC, porque el huso horario local puede desplazar la llamada a una franja distinta de la política esperada.

¿El precio menor justifica colocar el modelo en la ruta predeterminada?

No. El modelo es experimental, y la documentación consultada no confirma una recomendación universal, SLA, disponibilidad general ni un benchmark de superioridad. El comprador debe medir calidad, latencia, tokens de imagen, cache, hora, output, fallos y fallback. La ruta predeterminada solo tiene sentido después de conocer el costo de la tarea completada, no solo el del token.

¿Nexforce Router ya integra este identificador?

Las fuentes usadas en este análisis no confirman una integración específica de Nexforce Router con deepseek-v4-flash-vision-exp. Router puede conectarse a la decisión como gateway y capa de enrutamiento, con selección, fallback, límites, trazabilidad y observabilidad documentados en el producto. La compatibilidad concreta con el identificador debe verificarse antes de cualquier promesa técnica.

Referencias y Lectura Complementaria

• DeepSeek API Docs, Models & Pricing, documentación oficial de precios consultada el 25 de agosto de 2026.
• DeepSeek API Docs, Your First API Call, documentación oficial que lista el identificador deepseek-v4-flash-vision-exp y apunta a la guía de Vision, consultada el 25 de agosto de 2026.
• DeepSeek API Docs, Vision, guía oficial sobre redimensionamiento, tokens de imagen, formatos, límites de solicitud y múltiples imágenes, consultada el 25 de agosto de 2026.
• Nexforce Router, página oficial del producto y de sus capacidades de gateway y enrutamiento.

La decisión de ruta empieza después de la tabla

El precio publicado abre una oportunidad de prueba, pero no cierra una decisión de producción. Para el comprador B2B, la pregunta correcta es cuánto cuesta completar una tarea multimodal con la calidad necesaria, en el horario real, con el cache observado y un fallback capaz de absorber el fallo. Nexforce Router es la capa de gobernanza para medir esa elección. La ruta solo debe cambiar después de los datos. El siguiente paso es medir.