Imagen 4 vs Nano Banana: qué elegir y cómo migrar la API

A 8 de octubre de 2026, Imagen 4 ya no es una opción para una integración nueva ni un respaldo operativo: sus tres modelos cerraron en la Gemini API el 17 de agosto de 2026. Para sustituirlo en la Gemini Developer API, el punto de partida actual es Nano Banana 2.1, disponible de forma general desde el 6 de octubre con el ID gemini-nano-banana-2.1. Google lo indica como sustituto de Imagen 4 y de Nano Banana 2, gemini-3.1-flash-image. Nano Banana 2 está obsoleto en la Developer API, sin fecha de cierre anunciada; en Vertex AI mantiene soporte hasta el 28 de mayo de 2027 o después. Que no tenga fecha no lo convierte en un destino duradero: no conviene empezar una migración hacia él sin una necesidad concreta. Tabla oficial de retiradas de la Gemini API, versiones de modelos en Vertex AI.

Dos datos que Google publicó la semana del lanzamiento de 2.1 ya no valen: la fecha de cierre del 29 de octubre de 2026 para Nano Banana 2, que apareció en su tabla el día del lanzamiento y después se eliminó, y el precio de salida 4K de 2.1, que pasó de 0,0756 a 0,113 USD por imagen. Registro de cambios de la Gemini API, precios de la Gemini API.

La elección práctica es esta: 2.1 para generación y edición general; Lite si solo necesitas 1K y sus funciones bastan; Pro si mejora los entregables que realmente apruebas. El nombre Pro no demuestra que vaya a resolver mejor todos tus prompts. En Firebase AI Logic, además, 2.1 no figuraba en el catálogo de modelos a 7 de octubre de 2026: allí hay que elegir y validar una integración expresamente documentada para ese SDK. Modelos de imagen de Gemini, catálogo de Firebase.

Migrar implica revisar tres cosas: la solicitud que envías, la respuesta que guardas y el criterio que convierte una imagen generada en un trabajo terminado. Cambiar únicamente el nombre del modelo deja intactos muchos errores del código antiguo.

Qué se ha retirado y qué fecha corresponde a tu integración

Localiza primero el servicio al que llama tu aplicación. Una clave de Gemini Developer API, un proyecto Cloud y el SDK de Firebase son accesos distintos; un alias de un proveedor tampoco identifica por sí solo el modelo de Google.

Los tres IDs afectados en la Developer API son imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 e imagen-4.0-fast-generate-001. En la tabla oficial, el 24 de junio de 2025 es la fecha de lanzamiento, no una retirada en junio de 2026. Las fechas de cierre de esa tabla son las fechas más tempranas de retirada; la documentación de Imagen ya indica que esos modelos están cerrados. Retiradas de modelos, estado de Imagen.

La discrepancia de Firebase no está resuelta por una prueba de disponibilidad. Su guía de migración y su catálogo de modelos publican fechas diferentes para algunas filas. En Nano Banana 2, ninguno de los tres accesos publica ya un cierre próximo: Firebase muestra un límite no anterior al 28 de mayo de 2027, Vertex AI indica «28 de mayo de 2027 o después» y la Developer API lo marca como obsoleto sin fecha de cierre. Ninguna de esas indicaciones es una prórroga garantizada. Si necesitas un puente con Nano Banana 2, trátalo como temporal, mantén preparado el cambio a 2.1 y confirma el soporte de tu acceso o proveedor.

Para Pro, Firebase y Vertex AI muestran también el 28 de mayo de 2027 (Vertex añade «o después»), y Vertex da el 28 de junio de 2027 o después para Lite; la tabla actual de la Developer API no anuncia fecha de cierre para 2.1, Nano Banana 2, Lite ni Pro. Son estados documentales distintos, no garantías de disponibilidad indefinida. Fechas de la Developer API, fechas publicadas por Firebase, versiones de modelos en Vertex AI.

Hay otra fecha que suele confundirse con el cierre de Imagen: el 24 de junio de 2026 corresponde a la retirada de módulos generativos del antiguo SDK de Vertex AI en las nuevas versiones. No significa que desaparezca todo el SDK de Cloud ni que una versión antigua fijada deje de existir. Google dirige la migración de esos módulos hacia google-genai; en JavaScript, de @google-cloud/vertexai hacia @google/genai. Retirada de los módulos generativos del SDK.

Nano Banana 2.1, Nano Banana 2 y Pro: cuál sustituye tu trabajo

La comparación con Imagen 4 sirve para conservar el resultado que necesitabas, no para seguir comprando un modelo retirado. Compara los candidatos actuales con imágenes antiguas que tengas derecho a conservar y con tus requisitos de entrega.

Capacidades y plazos según la guía de imágenes, la ficha de 2.1 y la tabla de retiradas. La entrada de vídeo en 2.1 no significa que genere vídeos. Tampoco soporta 512 px: una configuración heredada con ese tamaño necesita cambiar de tamaño o de candidato.

Para un catálogo de productos, empieza por las condiciones de aprobación: forma y color del producto, fidelidad a la referencia y espacio para la composición. Para una pieza publicitaria, añade la exactitud del texto. Para una entrega final, añade tamaño, formato y revisión. Prueba Pro en los casos donde 2.1 incumpla esas condiciones o requiera demasiada reparación; no lo reserves automáticamente para 4K, porque 2.1 también lo ofrece.

El texto dentro de la imagen es donde más conviene comprobarlo. En la comparativa Nano Banana 2.1 vs Pro vs GPT Image 2.5: mismo prompt, 9 pruebas, con una sola generación de 1K por prompt, Pro mantuvo la redacción pedida y 2.1 la alteró en tres tareas de texto. Es una muestra pequeña, no una tasa de error, pero justifica incluir piezas con texto en tus pruebas. Las novedades y límites de 2.1 están detallados en Nano Banana 2.1: novedades, precio y prueba real por API.

Las referencias tienen límites propios. En 2.1, el máximo documentado es de 14 imágenes, con límites de 10 objetos y 4 personajes; Pro tiene condiciones diferentes, entre ellas 6 objetos y 5 personajes. Esas cifras no prometen una conservación perfecta de todos los detalles. Usa las mismas referencias admitidas en cada candidato y comprueba el resultado que importa a tu aplicación. Limitaciones de las referencias.

Si tu aplicación usa Firebase, el catálogo de modelos de Firebase enumera Pro, 3.1 Flash Image y Lite, pero no 2.1. Lite y Pro son candidatos documentados; elige según el tamaño y las funciones que necesitas y comprueba tu versión del SDK y proveedor antes de cambiar tráfico. La ausencia de 2.1 en esa página no demuestra que cualquier SDK instalado lo rechace, pero impide dar su compatibilidad por confirmada. Firebase requiere el plan Blaze con facturación habilitada para generar imágenes, independientemente del proveedor subyacente, y no ofrece búsqueda de imágenes para fundamentar la generación. Soporte de Firebase AI Logic.

En Cloud, el catálogo actual de generación de imágenes sí incluye 2.1. Sigue siendo necesario comprobar proyecto, ubicación y acceso. Que un ID esté documentado en Cloud no convierte una clave de Developer API en una credencial Cloud. En Vertex AI, 2.1 se publica en la región global, no admite Flex y devuelve un error de API si la solicitud lleva seed, topK, logprobs, temperature o topP: si tu configuración de Imagen fijaba una semilla para repetir resultados, elimina ese campo y no esperes la misma reproducibilidad. Nano Banana 2.1 en Vertex AI.

Adapta la solicitud: un ID nuevo no convierte generate_images en Gemini

Si el código llama a Imagen con generate_images, prompt, numberOfImages y una respuesta predictions, tienes que cambiar la operación y sus datos. Gemini genera imágenes como contenido: el texto y las imágenes de entrada forman parte de la solicitud, y las imágenes de salida deben extraerse de la respuesta correspondiente.

Puedes conservar generateContent si tu aplicación ya usa ese protocolo compatible. Google lo sigue soportando. Para un proyecto nuevo recomienda Interactions, disponible de forma general desde junio de 2026. Cambiar de modelo y cambiar de protocolo son decisiones diferentes; no mezcles los campos de ambos. Guía de Interactions.

La siguiente solicitud JSON ilustra una imagen 16:9 de 1K con 2.1 en la Developer API directa. Su destino es POST https://generativelanguage.googleapis.com/v1beta/interactions, con Content-Type: application/json y una clave de ese servicio en la cabecera x-goog-api-key. No es un cuerpo para Firebase, Cloud o un proveedor con autenticación Bearer.

{
  "model": "gemini-nano-banana-2.1",
  "input": "Crea una fotografía de producto de una taza azul sobre una mesa clara, con espacio vacío a la derecha para una composición publicitaria. No añadas texto.",
  "response_format": {
    "type": "image",
    "mime_type": "image/png",
    "aspect_ratio": "16:9",
    "image_size": "1K"
  },
  "store": false
}

Los nombres y las mayúsculas importan: aquí se usa image_size: "1K". Para editar, input puede ser una lista de partes; la parte de imagen usa type: "image", data con Base64 sin prefijo de URL de datos y mime_type. No traslades a esta petición el prompt o las predictions de Imagen. Contrato de generación de imágenes.

store: false evita guardar la interacción como historial del servidor, pero no equivale a retención cero y no permite ejecución en segundo plano ni reutilizar su ID como historial almacenado. Si usas previous_interaction_id, se hereda el historial, no las herramientas, instrucciones del sistema ni la configuración de generación: reenvía las opciones actuales. Almacenamiento y continuidad de Interactions.

Los campos que debes retirar o reinterpretar en Firebase

En Firebase, la migración pasa de ImagenModel a GenerativeModel; de ImagenGenerationConfig a GenerationConfig con ImageConfig; y de ImagenSafetySettings a SafetySetting. ImageConfig está disponible a partir de las versiones del SDK de mayo de 2026. Configura modalidad de respuesta IMAGE o imagen y texto según lo que consuma tu aplicación. Migración oficial de Firebase.

No sustituyas numberOfImages por un número de candidatos esperando el mismo resultado. Si antes ofrecías cuatro variantes al usuario, decide cómo pedirlas, mostrar fallos parciales y limitar costes. Tampoco reduzcas los filtros de seguridad al cambiar el tipo de configuración. Estas restricciones corresponden a Firebase: no justifican fijar PNG o una única imagen en cualquier otro protocolo.

Guarda las imágenes de la respuesta, no el primer campo que encuentres

Una respuesta HTTP correcta puede contener texto sin ninguna imagen utilizable. En Interactions, recorre los pasos de salida del modelo y sus bloques de contenido; guarda los bloques type: "image" con data y mime_type. No presupongas que la imagen está en la primera posición ni guardes como resultado final un bloque de pensamiento. El atajo output_image del SDK devuelve solo la última imagen; usarlo además del recorrido puede guardar dos veces el mismo resultado. Salidas intercaladas.

Este script local, sin SDK ni llamadas de red, lee una respuesta previamente guardada en respuesta.json y escribe sus imágenes en imagenes/. Guárdalo como guardar-imagenes.py en la misma carpeta que esa respuesta y ejecútalo con python3 guardar-imagenes.py. Es un extractor para la forma REST anterior; no sirve para candidates o predictions.

import base64
import json
from pathlib import Path

respuesta = json.loads(Path("respuesta.json").read_text(encoding="utf-8"))
extensiones = {"image/png": ".png", "image/jpeg": ".jpg", "image/webp": ".webp"}
imagenes = []

for paso in respuesta.get("steps", []):
    if paso.get("type") != "model_output":
        continue
    for bloque in paso.get("content", []):
        if bloque.get("type") != "image":
            continue
        mime = bloque.get("mime_type")
        datos = bloque.get("data")
        if mime not in extensiones or not isinstance(datos, str) or not datos:
            raise ValueError("Bloque de imagen sin formato o datos admitidos")
        contenido = base64.b64decode(datos, validate=True)
        if not contenido:
            raise ValueError("Imagen vacía")
        imagenes.append((contenido, extensiones[mime]))

if not imagenes:
    raise ValueError("La respuesta no contiene imágenes finales guardables")

destino = Path("imagenes")
destino.mkdir(exist_ok=True)
for numero, (contenido, extension) in enumerate(imagenes, start=1):
    archivo = destino / f"imagen-{numero:02d}{extension}"
    archivo.write_bytes(contenido)
    print(archivo)

El extractor valida la presencia de datos, Base64 y un MIME admitido; no demuestra que el archivo se decodifique como imagen ni que cumpla el encargo. Añade esa comprobación antes de entregarlo: apertura correcta, dimensiones reales, formato esperado y revisión del contenido. La solicitud y el extractor se han comprobado con JSON y respuestas ficticias locales; no se ha realizado una llamada al modelo ni una prueba de facturación.

Si no hay imagen, conserva el identificador del trabajo y clasifica la causa. Un error de modelo retirado o 404 exige revisar ID, servicio y endpoint. Un 429 requiere revisar cuota y límites del proyecto; crear más claves no aumenta esa cuota. Los errores de configuración, pago y permisos necesitan corregir su causa. Para fallos temporales 503 o 504, define reintentos limitados; tras un timeout puede haber un resultado desconocido y repetir la petición puede duplicar generación y coste. Un bloqueo de seguridad no es una señal para desactivar filtros. Errores de API, límites.

Compara costes con el mismo tamaño y por imagen aprobada

Estas tarifas corresponden a la Gemini Developer API, Standard, en USD, a 8 de octubre de 2026; Vertex AI publica las mismas tarifas para 2.1. La tabla muestra solo la salida de imagen: no incluye entrada, texto o pensamiento de salida, búsqueda ni solicitudes adicionales. Precios de la Gemini API.

Para 2.1, el precio de salida de imagen es 30 USD por millón de tokens: 1K corresponde a 1.120 tokens, 2K a 1.680 y 4K a 3.780. En Batch, la salida de imagen cuesta 15 USD por millón, es decir, 0,0168, 0,0252 y 0,0567 USD respectivamente. El soporte de Batch del modelo no prueba que exista un endpoint /interactions/batch: usa el procedimiento Batch documentado para tu integración. Precios, ficha del modelo.

Con esas cifras, 2.1 sigue siendo más barato que Nano Banana 2 en los tres tamaños, aunque el ahorro relativo baja de la mitad en 1K a una cuarta parte en 4K. Nano Banana 2 conserva además una salida de 512 px a 0,045 USD. Si vienes de Nano Banana 2, el ahorro por tamaño está calculado en Nano Banana 2 API: precio por imagen y cuánto ahorras con 2.1.

La igualdad de precio de salida entre Lite y 2.1 en 1K no implica igual factura. Sus entradas cuestan 0,25 y 1,50 USD por millón de tokens, respectivamente; el texto de salida cuesta 1,50 y 7,50 USD por millón. En 2.1, el pensamiento se factura como texto de salida. Search tiene 5.000 consultas mensuales incluidas compartidas con modelos 3.x y después cuesta 14 USD por 1.000 consultas; una petición puede provocar varias consultas. No conviertas ese número en 5.000 imágenes gratuitas. Detalle de facturación.

Para comparar decisiones, usa:

Coste por imagen aprobada =
  (coste de generación + reintentos + reparación y revisión)
  / número de imágenes aprobadas

Un ejemplo hipotético permite separar precio y aceptación. Si generas 100 imágenes de 1K con 2.1 y apruebas 80, la salida de imagen suma 3,36 USD y representa 0,042 USD por aprobada. Si con Pro generas 100 y apruebas 90, esa salida suma 13,40 USD y representa unos 0,149 USD por aprobada. Son supuestos de cálculo, no tasas de aceptación observadas. Pro solo compensaría la diferencia si los costes evitados de reparación, revisión o rechazo fueran suficientes; añade los demás conceptos antes de decidir.

No compares esas cifras con una antigua tarifa de Imagen como si aún pudieras contratarla, ni con el precio de un proveedor sin igualar servicio, tamaño, modalidad y reglas de cobro. Las filas API de 2.1 y Pro no ofrecen nivel gratuito. Una prueba en AI Studio o una interfaz de usuario no concede una API gratuita para producción. Tarifas y niveles de servicio.

Una tarifa por llamada cambia la cuenta, sobre todo en 4K. En LaoZhang API, gemini-nano-banana-2.1 cuesta 0,045 USD por llamada con cualquier tamaño, nivel de pensamiento o número de referencias (tarifa pública a 8 de octubre de 2026); cada búsqueda añade 0,014 USD. Frente a la salida de imagen de Google, sale más barato en 4K (0,113 USD) y más caro en 1K (0,0336 USD), aunque en esa tarifa por llamada la entrada y el pensamiento no se cobran aparte, como sí ocurre en Google. Esa ruta usa generateContent con autenticación Bearer, no el cuerpo de Interactions del ejemplo anterior: necesita su propio adaptador y sus propias pruebas de aceptación antes de recibir tráfico o servir de recuperación.

Aviso: laozhang.ai es un servicio propio. Sus precios son nuestra tarifa, no una comparación independiente.

Valida el entregable y cambia tráfico con una recuperación disponible

Imagen 4 retirado no puede participar en una prueba A/B en vivo. Usa las imágenes históricas conservadas legalmente como referencia del encargo anterior y ejecuta las nuevas pruebas solo en candidatos disponibles. Si el texto del prompt cambia porque el nuevo protocolo lo exige, guarda ambas versiones y explica qué cambió; no atribuyas al modelo una diferencia causada por otra entrada.

Define la aceptación antes de mirar los resultados. Una imagen publicitaria podría exigir texto exacto, producto fiel y dimensiones correctas; una miniatura podría priorizar composición y legibilidad a tamaño pequeño. Incluye casos habituales y casos difíciles que hayan causado incidencias. No hay un número universal de prompts que garantice una migración: la muestra debe cubrir tus trabajos y el coste de equivocarte.

Registra cada resultado con su modelo, tamaño, prompt, referencias, fecha, error y decisión de aprobación. Conserva los intentos descartados para calcular el coste real. Mide también el tiempo de reparación y la latencia que observa tu aplicación; la documentación de capacidades no sustituye esas mediciones. Así puedes decidir, por ejemplo, mantener variantes sencillas en Lite, elegir 2.1 para edición general y enviar ciertos encargos a Pro.

Para pasar a producción, sigue un orden que puedas deshacer:

1. Prepara una configuración independiente por trabajo. Guarda modelo, acceso, formato, tamaño y versión del lector de respuestas. No repartas IDs por el código sin un punto claro para cambiarlos.
2. Valida una vía alternativa antes del cambio. Puede ser otro modelo soportado con su propio adaptador y resultados aprobados. Si no lo tienes, prepara una cola de espera o revisión manual con un plazo de entrega explícito.
3. Empieza por trabajos de menor impacto. Decide qué fracción puedes asumir según tu volumen y supervisión. Aumenta el tráfico cuando la aceptación, errores, tiempo de entrega y presupuesto cumplan tus criterios.
4. Detén el aumento ante un fallo definido. Una subida de rechazos, formatos que no se abren o costes inesperados debe activar la vía alternativa o la cola; no nuevos reintentos sin límite.
5. Retira la configuración de Imagen cuando el reemplazo esté estable. Conserva las imágenes y registros históricos que necesites, pero elimina la selección del endpoint retirado como recuperación.

Volver atrás significa restaurar una configuración compatible con un servicio disponible, incluido su tratamiento de respuesta. Revertir un commit que apuntaba a Imagen puede recuperar el código y dejar el servicio roto. Un prompt más sencillo puede reducir fallos de contenido, pero no resuelve una caída del proveedor; una cola conserva trabajos pendientes, pero necesita límites y comunicación al usuario.

El cierre de la migración llega cuando tus solicitudes generan archivos utilizables, tus usuarios aprueban los trabajos, el coste cumple el presupuesto y la recuperación funciona con el acceso elegido. Un JSON válido o un archivo escrito en disco cubren solo una parte de ese recorrido.

Preguntas frecuentes

¿Basta con cambiar el ID de Imagen 4 por Nano Banana 2.1?

No si usabas la operación de Imagen. Debes pasar a generación de contenido, adaptar la configuración y leer las imágenes de la nueva respuesta. Si ya usabas generateContent con Gemini, puedes conservar ese protocolo compatible y revisar el modelo, sus opciones y el lector de salida. Migración a imágenes Gemini, protocolos soportados.

¿Debería elegir Nano Banana 2 o Nano Banana Pro para reemplazar Imagen 4?

En una migración nueva de la Developer API, empieza por Nano Banana 2.1, gemini-nano-banana-2.1. Nano Banana 2, gemini-3.1-flash-image, está obsoleto en la Developer API y Google recomienda 2.1 para todos los proyectos nuevos; no tiene fecha de cierre anunciada, pero tampoco es un destino que convenga estrenar. Pro es un candidato si reduce los fallos y la reparación de tus entregables lo suficiente para compensar su precio; esa ventaja debe comprobarse con tus trabajos. Modelos y retiradas, capacidades de imagen.

¿Puedo usar 2.1 con Firebase AI Logic?

No des su soporte por confirmado: a 7 de octubre de 2026, el catálogo de Firebase enumera Pro, 3.1 y Lite, pero no 2.1. Elige un candidato documentado para Firebase y confirma la compatibilidad de tu SDK y proveedor. El soporte de 2.1 en Developer API o Cloud no basta para demostrarlo en Firebase. Catálogo del SDK.

¿Puede seguir Imagen 4 como respaldo si falla la migración?

No como respaldo operativo actual. Las fechas publicadas de retirada ya han pasado y la documentación indica su cierre. Usa otro modelo soportado y previamente validado, o conserva el trabajo en una cola para revisión manual. Las imágenes antiguas sí pueden servir como referencia de calidad. Estado oficial de Imagen.

¿Nano Banana 2.1 admite 512 px o tiene API gratuita?

No admite 512 px: ofrece 1K, 2K y 4K. Su fila de precios no ofrece nivel gratuito de API. Para 1K Standard, 0,0336 USD es únicamente el coste de salida de imagen; suma entrada y cualquier otro concepto aplicable. Tamaños admitidos, precios.

¿Gemini 2.5 Flash Image también está retirado?

Está obsoleto, pero su fecha de cierre no coincide entre páginas de Google. La tabla de retiradas de la Developer API y Vertex AI publican el 15 de marzo de 2027 para gemini-2.5-flash-image, con Nano Banana Lite como sustituto; la página de precios de la Developer API y el catálogo de Firebase aún muestran el 2 de octubre de 2026, fecha ya pasada. Con ese conflicto, no lo elijas como destino ni como respaldo sin comprobar tu integración. Para una migración nueva, la recomendación actual de la Developer API es 2.1. Tabla de retiradas de la Developer API, precios de la Developer API, catálogo de Firebase.