Aviso: GPT Image 2.6 Flare y Sunburst ya están disponibles con un 20 % de descuento por tiempo limitado, pruébalo ahora
HiAPI
Blog

Comparativa

Lista de verificación de selección de Gemini Omni 1.2 Flash: modos de entrada, especificaciones y presupuesto

Verificar modos de entrada, especificaciones, presupuesto y límites de efectos, y completar la validación de selección con tus propias muestras

Nov 11, 2026
深松绿底上几块被直线剖分为深浅绿平面的大棱镜,构成克制的几何封面图。
En esta página

Qué revisa esta lista

gemini-omni-1.2-flash se ofrece públicamente a través de HiAPI. Al seleccionarlo, conviene verificar primero cuatro aspectos: si los modos de entrada cubren tu flujo de materiales, si los parámetros de especificación cumplen las restricciones del producto, si el presupuesto puede calcularse con claridad según la resolución y la duración, y qué efectos quedan fuera del alcance de garantía. La siguiente lista solo describe las capacidades públicas actuales y no incluye pruebas reales ni clasificaciones de competidores.

Ilustración conceptual que solo ayuda a explicar la entrada, el flujo o el presupuesto; no representa datos de pruebas reales del modelo.

Modos de entrada: cuatro rutas disponibles y reglas de exclusión mutua

Los modos de entrada públicos actuales incluyen:

  • Texto a vídeo: generar vídeo solo con un prompt.
  • Imagen inicial a vídeo: especificar el fotograma inicial con first_frame_url para dar movimiento a la imagen.
  • Transición entre fotograma inicial y final: especificar a la vez first_frame_url y last_frame_url para generar una transición entre el fotograma inicial y el final; este modo admite como máximo 10 segundos y no puede incluir negative_prompt ni system_prompt.
  • Imagen de referencia a vídeo: pasar de 1 a 10 imágenes de referencia públicas por HTTP(S) con image_urls para restringir el estilo o el sujeto; aunque solo se pase una imagen, sigue siendo una imagen de referencia y no un fotograma inicial.

Conviene prestar especial atención a los límites de exclusión mutua: image_urls es incompatible con first_frame_url/last_frame_url; last_frame_url depende de first_frame_url y no puede usarse por separado. first_frame_url puede especificar por sí solo el fotograma inicial. Todos los parámetros de imagen solo aceptan URL públicas HTTP(S); no se admite Base64.

Las capacidades no disponibles incluyen: edición de vídeo, continuación de vídeo, entrada de vídeo o audio, y seed. Si necesitas estas capacidades, no deberías incluir este modelo entre los candidatos.

Parámetros de especificación: obligatorios, valores predeterminados y restricciones estrictas

prompt es el único campo obligatorio; debe ser no vacío y tener como máximo 20000 caracteres. El resto de parámetros se configuran según necesidad:

  • duration: entero, de 3 a 15 segundos, predeterminado 10 segundos.
  • resolution: 360p, 720p, 1080p, 4k, predeterminado 720p. 1080p y 4k son salidas ampliadas; 4k puede no incluir pista de audio.
  • aspect_ratio: 16:9 o 9:16, predeterminado 16:9.

El modo de fotograma inicial y final, además de tener un máximo de 10 segundos, no puede usar simultáneamente negative_prompt ni system_prompt. El modo de imagen de referencia está sujeto a la cantidad de 1 a 10 imágenes y al formato de URL. Incluir estas restricciones en la validación de parámetros del producto resulta más cómodo que remediarlo tras un fallo de llamada.

Presupuesto: precio unitario por resolución × duración solicitada × número de vídeos

La cotización predeterminada actual por multiplicador se distingue según la resolución:

  • 360p: $0.0229/segundo
  • 720p: $0.0343/segundo
  • 1080p: $0.0343/segundo
  • 4k: $0.0800/segundo

Presupuesto = precio unitario de la resolución elegida × duración solicitada × número de vídeos. Prevalece la factura real y el multiplicador aplicable; no deduzcas la facturación a partir de los segundos del contenedor del archivo (por ejemplo, segundos decimales). La duración solicitada debe calcularse según el parámetro duration, no según los metadatos del archivo de vídeo.

Hay que distinguir dos tipos de eventos de coste: éxito pero insatisfacción requiere crear de nuevo la tarea, lo que aumenta el presupuesto; fallo real se gestiona según las reglas de reembolso de la plataforma. No asumas por defecto que todos los fallos se reembolsan ni que ninguno lo hace; prevalece la factura real. Ante un tiempo de espera de red, no vuelvas a crear la tarea directamente; consulta primero las tareas existentes para evitar que la misma solicitud se facture dos veces.

Aspectos no garantizados: estos efectos requieren validación propia

Una capacidad pública no equivale a una promesa de resultados. Actualmente no se garantiza que todos los modos incluyan sonido, sincronización labial, texto preciso ni consistencia total del sujeto o de la marca. 1080p y 4k son salidas ampliadas; 4k puede no incluir pista de audio. Al seleccionar, no infieras calidad, tiempo de proceso ni ventajas de coste a partir de la página de parámetros; si no hay datos de pruebas reales, tampoco deberías inventar comparativas ni clasificaciones de competidores.

Validación con tus propias muestras: calidad, tiempo de respuesta y coste aplicable

Se recomienda usar el mismo lote de prompts y el mismo lote de imágenes de referencia o fotogramas iniciales para ejecutar por separado texto a vídeo, imagen inicial a vídeo, transición entre fotograma inicial y final e imagen de referencia a vídeo (cuando aplique), y registrar tres grupos de resultados:

  • Calidad: en tus escenarios típicos, cuántas generaciones producen un resultado directamente utilizable; no solo mires el mejor.
  • Tiempo de respuesta: el tiempo desde el envío de la tarea hasta obtener un resultado utilizable, incluidos los reintentos y las consultas necesarios.
  • Coste aplicable: calcular el presupuesto según tu resolución, duración y número de vídeos, e incluir las repeticiones por éxito pero insatisfacción, en lugar de mirar solo el precio unitario.

Durante la validación, fija las entradas y los parámetros, registra cada punto y no mezcles en una misma comparación resultados de distintas resoluciones, duraciones o modos de entrada. Solo tus propias muestras pueden indicar si este modelo es adecuado para tu producto.

Puntos de verificación antes de la integración

  • ¿El producto necesita edición de vídeo, continuación, entrada de vídeo o audio, o seed? Si es así, este modelo no es aplicable.
  • ¿El flujo de materiales puede proporcionar URL de imagen públicas HTTP(S)? Si solo dispone de Base64, primero hay que adaptar la carga y el alojamiento.
  • ¿Se usan a la vez image_urls y los parámetros de fotograma inicial/final? Ambos son mutuamente excluyentes y deben bloquearse en la capa de validación de parámetros.
  • ¿La duración del modo de fotograma inicial y final supera los 10 segundos o incluye por error negative_prompt o system_prompt?
  • ¿El presupuesto se calcula como precio unitario por resolución × duración solicitada × número de vídeos y reserva margen para repeticiones por éxito pero insatisfacción?
  • ¿Ante un tiempo de espera de red se consultan primero las tareas existentes en lugar de crear directamente de nuevo?

A través de la interfaz unificada de HiAPI, puedes realizar primero una validación con muestras pequeñas según la lista anterior y luego decidir si integrarlo en producción. La base para la selección debe ser la calidad, el tiempo de respuesta y el coste aplicable que hayas medido tú mismo, no conclusiones comparativas sin pruebas reales.

Artículos relacionados

Ver todos los artículos →

Empieza a crear con artefactos de IA persistentes

Consigue tu API key y llama a modelos de imagen, vídeo y audio a través de una única API basada en tasks.

Leer la documentación de la API