Gemini API amplía límites de archivos y acepta GCS y URLs | Keryc
Google anuncia cambios prácticos en la forma de llevar datos a la Gemini API: ahora puedes usar URLs externas (públicas o firmadas) y registrar objetos en Google Cloud Storage (GCS), además de aumentar el límite de archivos inline. ¿El objetivo? Evitar re-subidas innecesarias y acelerar el paso a producción de aplicaciones multimodales.
Qué cambia (resumen técnico)
Soporte para URLs externas: puedes pasar una URL pública o una URL firmada (pre-signed) de proveedores como AWS S3, Azure Blob u otros. La Gemini API recupera el contenido de forma segura durante el procesamiento.
Registro de archivos en Google Cloud Storage (GCS): si tus datos ya están en GCS, los registras con la Files API y no necesitas mover bytes. El URI registrado se puede reutilizar en múltiples requests.
Límites inline aumentados: el tamaño máximo para datos inline sube de a (base64 codificado; límites específicos varían según el tipo de dato). Ideal para prototipos, imágenes grandes o clips de audio cortos sin almacenamiento intermedio.
20 MB
100 MB
En pocas palabras: menos fricción para traer tus datos —desde donde estén— directamente a la API.
Cómo usarlo — ejemplos prácticos
Usar una URL externa
Imagina que tienes PDFs en un bucket S3 privado. En vez de descargar y volver a subir, generas una URL firmada con expiración y la pasas en la petición de generación. Gemini descarga el archivo durante el procesamiento. Así reduces latencia y costes de transferencia.
Casos típicos: grandes documentos, imágenes pesadas, archivos de audio/vídeo cortos.
Ventaja práctica: no necesitas infraestructura intermedia para rehostear archivos.
Registrar archivos en GCS
Si tu pipeline ya escribe en Google Cloud Storage, registra el URI con la Files API. Registro único, uso repetido. No mueves bytes, sólo otorgas acceso.
Requisito: autenticación OAuth con credenciales de IAM que tengan permiso de lectura al bucket.
Ideal para: datos que se consultan frecuentemente (modelos RAG, análisis multimodal recurrente).
Usar inline cuando convenga
Para prototipos o apps en tiempo real donde prefieres simplicidad, ahora puedes embutir hasta 100 MB base64. Es rápido, pero no recomendado a escala por costos y latencia de payloads grandes.
Consideraciones técnicas y de seguridad
Autenticación: el registro de GCS requiere OAuth de una cuenta con permisos read sobre el bucket. Asegúrate de aplicar el principio de menor privilegio.
URLs firmadas: controla la caducidad y los permisos. No uses expiraciones largas sin justificación.
Validación: valida tipos MIME y tamaños antes de enviar la URL o el payload inline. Evita sorpresas en producción.
Costes y latencia: si bien evitas re-subidas, la API fetching desde URLs externas implica transferencia saliente del proveedor de origen. Mide latencia y costos en tu configuración.
Persistencia: registrar en GCS evita la limitación previa de 48 horas de almacenamiento efímero en Files API.
Recomendaciones para producción
Usa GCS registrado para datos persistentes y de acceso frecuente.
Emplea URLs firmadas para integraciones con otros clouds (S3, Azure) y controla expiración corta.
Conserva inline (100 MB) para prototipos o respuestas en tiempo real; no es la opción más económica a gran escala.
Implementa auditoría y rotación de credenciales IAM.
Prueba el flujo end-to-end con archivos representativos (video largo, audio, PDF con imágenes) antes de escalar.
Beneficios directos para tu app
Menos trabajo operativo: cero re-subidas y menos storage temporal.
Escalado más limpio: puedes apuntar a producción sin reestructurar dónde guardas los datos.
Flexibilidad multimodal: video, audio, imágenes y documentos pueden llegar por la vía que mejor encaje con tu infraestructura.
¿Y ahora qué? Actualiza tus SDKs a la última versión, revisa permisos y empieza probando con URLs firmadas y un registro GCS simple. Si ya trabajas con pipelines en la nube, esto puede ahorrar días de ingeniería.
