Procesamiento de imágenes de productos de comercio electrónico con DeepSeek V4.1 Flash a través de la API de hiapi

DeepSeek V4.1 Flash no genera imágenes de producto: esto es lo que realmente domina en tu stack de comercio electrónico

Si has llegado aquí por la expresión «imágenes de producto», DeepSeek V4.1 Flash no puede generarlas: es un modelo puramente de texto, sin salida de imagen, audio ni vídeo. Pero un catálogo de comercio electrónico depende mucho más del texto que de las imágenes: cada ficha necesita una descripción, cada imagen necesita un texto alternativo, cada pregunta de cliente necesita una respuesta y cada canal publicitario necesita una versión distinta del mismo argumento de venta. Es justo la capa en la que este modelo destaca, y además resulta excepcionalmente económico y flexible para esta tarea: admite tanto /v1/chat/completions como /v1/responses, así que no tendrás que reconstruir tu integración en torno a un único formato de solicitud. Esta guía cubre la parte textual del flujo de trabajo de imágenes de producto: generación masiva de descripciones con salida estructurada, preguntas y respuestas de atención al cliente y variantes de copy multicanal, con ejemplos de solicitudes reales basadas en la API de hiapi. Si necesitas las imágenes en sí, puedes combinarlo con un modelo de imagen como GPT Image 2 y dejar que DeepSeek V4.1 Flash se encargue de todo el texto que rodea a la imagen.

Por qué importa la doble interfaz de API

La mayoría de los modelos de nivel de razonamiento de hiapi eligen una sola ruta —Chat Completions o Responses— y la mantienen. DeepSeek V4.1 Flash admite de forma nativa POST /v1/chat/completions y POST /v1/responses, lo que significa que puedes conectarlo a la integración que ya tengas sin tener que construir un cliente nuevo específicamente para este modelo. Los siguientes puntos se aplican a ambos endpoints:

• reasoning_effort tiene cinco niveles reales. El texto de la página de precios solo menciona none, high y max, pero el modelo también acepta low y medium en solicitudes reales: los cinco niveles son válidos. Para tareas breves y deterministas como el copy de una ficha, none o low bastan; reserva high/max para escenarios que requieren criterio, como las respuestas de atención al cliente sensibles a políticas.
• La salida estructurada se comporta de forma distinta según el endpoint. Para este modelo, usar response_format: {"type": "json_schema", ...} en /v1/chat/completions no devuelve resultados validados contra el esquema; en su lugar, usa response_format: {"type": "json_object"} y describe la estructura en el prompt. Si necesitas forzar la validación del esquema, envía la misma solicitud a /v1/responses con text.format.type=json_schema, que sí lo respeta.
• La llamada a funciones y el streaming funcionan como se espera en /v1/chat/completions: tools, tool_choice y stream: true se comportan igual que en cualquier otro modelo de chat compatible con OpenAI de hiapi, por lo que tu código actual de llamada a funciones no necesita ajustes.

La URL base es https://api.hiapi.ai/v1, con la misma clave que usas para tus otros modelos de hiapi. En la página del modelo encontrarás los formatos completos de solicitud y respuesta de ambos endpoints.

Caso de uso 1: generación masiva de descripciones de producto con salida estructurada

La aplicación más directa consiste en convertir hojas de especificaciones en copy de ficha alineado con la marca a gran escala, con un formato que tu CMS pueda importar directamente sin posprocesamiento. En Chat Completions, el modo json_object junto con un esquema explícito en el prompt lo consigue de forma fiable:

import json
import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/chat/completions",
    headers={
        "Authorization": f"Bearer {HIAPI_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "model": "deepseek-v4.1-flash",
        "reasoning_effort": "none",
        "response_format": {"type": "json_object"},
        "messages": [
            {
                "role": "system",
                "content": (
                    "You write concise, factual e-commerce listing copy. "
                    "Never invent specs that aren't in the input. "
                    "Respond with JSON matching this shape: "
                    '{"title": str, "short_description": str, '
                    '"long_description": str, "bullet_points": [str]}'
                ),
            },
            {
                "role": "user",
                "content": (
                    "Product: ceramic pour-over coffee dripper, 400ml, "
                    "matte white, dishwasher safe, fits standard filters. "
                    "Write listing copy for this product."
                ),
            },
        ],
    },
)
listing = json.loads(resp.json()["choices"][0]["message"]["content"])

Ejecuta esto para cada SKU de tu base de datos de productos y obtendrás un copy coherente sin tener que editar texto a mano desde una ventana de chat. Si prefieres que la respuesta devuelva un error explícito cuando el formato sea incorrecto, en lugar de confiar en que el modelo respete el prompt, envía la solicitud equivalente a /v1/responses con text.format.type=json_schema: esa ruta valida la salida contra tu esquema antes de devolverla.

Caso de uso 2: preguntas y respuestas de atención al cliente basadas en tu propia documentación

Para un asistente de soporte, ambos endpoints exigen que reenvíes la conversación en curso: ninguno conserva estado entre llamadas de forma predeterminada, así que el historial de la conversación lo gestiona tu aplicación, no el proveedor. Esto resulta útil si necesitas anonimizar, ramificar o restaurar conversaciones desde tu propia base de datos en lugar de confiar en el almacenamiento de sesiones del proveedor.

history = [
    {"role": "system", "content": "Answer only from the provided product FAQ context. "
                                    "If the answer isn't in context, say so and offer to escalate."},
]

def ask(user_message: str, faq_context: str) -> str:
    history.append({"role": "user", "content": f"Context:\n{faq_context}\n\nQuestion: {user_message}"})
    resp = requests.post(
        "https://api.hiapi.ai/v1/chat/completions",
        headers={"Authorization": f"Bearer {HIAPI_KEY}", "Content-Type": "application/json"},
        json={
            "model": "deepseek-v4.1-flash",
            "reasoning_effort": "low",
            "messages": history,
        },
    )
    answer = resp.json()["choices"][0]["message"]["content"]
    history.append({"role": "assistant", "content": answer})
    return answer

Para cualquier acción que requiera consultar el estado de un pedido o iniciar una devolución, declárala como función en tools: el modelo devolverá una entrada tool_calls, tu backend la ejecutará, después añadirás un mensaje con role: "tool" que contenga el resultado y volverás a llamar. Así el modelo nunca toca directamente tu base de datos de pedidos, y funciona igual que cualquier otro modelo de chat compatible con OpenAI de hiapi.

Caso de uso 3: variantes de copy de marketing para distintos canales

Los mismos datos de producto necesitan una redacción distinta en la página de producto, en el asunto de un correo electrónico y en un titular publicitario de 30 caracteres. Con stream: true en /v1/chat/completions, puedes generar varias variantes de canal en una sola solicitud y renderizarlas a medida que llegan, en lugar de esperar la respuesta completa; esto resulta útil si vas a alimentar una vista previa en tiempo real dentro de una herramienta interna. Aquí también conviene mantener reasoning_effort en none o low: igualar el tono de un copy breve no requiere un razonamiento más pesado, y así se mantiene baja la latencia cuando los responsables de marketing iteran en tiempo real.

Cuánto cuesta

DeepSeek V4.1 Flash se factura de forma uniforme por token, sin escalones ni umbrales que planificar de antemano:

Entrada	Salida	Entrada en caché
$0.44 / 1M tokens	$1.32 / 1M tokens	$0.014 / 1M tokens

Para los casos de uso anteriores —una descripción de producto, un turno de conversación de soporte, un lote de variantes de canal—, cada llamada cuesta solo una fracción de céntimo. Merece la pena usar la tarifa de entrada en caché de forma consciente: si tu prompt de sistema es largo y se repite en miles de llamadas de SKU, mantenlo idéntico byte a byte entre solicitudes para que cumpla los requisitos de la tarifa de caché. Las tarifas se basan en el uso y pueden cambiar; antes de comprometerte con una tarea de gran volumen, consulta hiapi.ai/pricing.

Cómo encaja esto con el resto de tu stack

Nada de esto sustituye al modelo de imagen real: DeepSeek V4.1 Flash no tiene acceso a /v1/tasks ni puede producir salida visual. Si tu flujo de trabajo necesita fotografía de producto o imágenes de estilo de vida que acompañen a estos textos, se trata de una llamada independiente a un modelo de imagen como GPT Image 2, y ambos no comparten formato de solicitud ni endpoint. Si ya has leído la guía de comercio electrónico de GPT-6 Astra, la forma del problema es exactamente la misma; la diferencia es que DeepSeek V4.1 Flash te ofrece elección de endpoint y una curva de costes plana en lugar de una escalonada.

Preguntas frecuentes

¿Puede DeepSeek V4.1 Flash generar imágenes de producto? No. Es un modelo puramente de texto, sin salida de imagen, audio ni vídeo, accesible mediante /v1/chat/completions o /v1/responses. Combínalo con un modelo de imagen para cubrir la parte visual de la ficha de producto.

Para este modelo, ¿debo usar Chat Completions o Responses? Ambos sirven: elige el que coincida con tu integración actual. El único caso en que importa es si fuerzas la salida estructurada: la validación con json_schema funciona en /v1/responses pero no en /v1/chat/completions, donde en su lugar debes usar el modo json_object.

¿Qué hace reasoning_effort y qué nivel debería usar? Controla cuánto razonamiento interno realiza el modelo antes de responder, intercambiando latencia y coste por calidad de criterio. Los cinco niveles (none, low, medium, high, max) son válidos en solicitudes reales, aunque la página de precios solo muestre tres. Para tareas breves y deterministas como la generación de descripciones, usa none o low; reserva high o max para respuestas de soporte que impliquen criterio.

¿Se puede usar el streaming junto con la llamada a funciones? Sí: stream: true y tools funcionan de forma independiente en /v1/chat/completions y pueden combinarse en la misma solicitud, igual que en cualquier otro modelo de chat compatible con OpenAI de hiapi.

¿Necesito reenviar la conversación completa en cada turno de soporte? Sí, en ambos endpoints. Ninguno conserva el estado de la conversación entre llamadas de forma predeterminada, así que tu aplicación debe reenviar cada vez el historial necesario. Esto incrementa el coste de los tokens de entrada reenviados, pero significa que tú controlas qué contexto se incluye y puedes anonimizar o ramificar conversaciones desde tu propia base de datos.

¿La tarifa de entrada en caché es automática? Solo se aplica automáticamente cuando la parte inicial de la solicitud (normalmente el prompt de sistema) es idéntica byte a byte entre llamadas. Comprueba cached_tokens en el objeto usage de la respuesta en lugar de dar por hecho que se ha aplicado el descuento.