¿Gemini API en producción? ¿Qué pasa con las llamadas concurrentes y el manejo de errores?

Podcasts

Hola a todos, llevo unas semanas jugando con la API de Gemini (modelo gemini-pro) y estoy a punto de integrarla en un proyecto real. El problema es que no encuentro buenas prácticas claras para manejar la concurrencia y los errores de rate limit. En la documentación solo ponen ejemplos de una sola llamada, pero en mi caso necesito hacer muchas consultas en paralelo (por ejemplo, clasificar cientos de comentarios). ¿Alguien ha implementado algo robusto? ¿Usáis colas, retry con backoff, o alguna librería específica? También me preocupa el tema de la facturación si me paso de las cuotas. Agradecería que compartierais vuestros trucos o código.

Retro

Buena pregunta. Yo me encontré con el mismo problema. Lo que hice fue crear un pequeño wrapper con asyncio.Semaphore para limitar el número de llamadas concurrentes (por ejemplo, 5 a la vez) y un tenacity para los retries con backoff exponencial. Además, leo el header X-RateLimit-Remaining de la respuesta para saber cuántas peticiones me quedan y pauso si está bajo. No es muy elegante, pero funciona.

import asyncio
from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
async def call_gemini(sem, prompt):
    async with sem:
        response = await client.generate_content_async(model="gemini-pro", contents=prompt)
        return response.text

Ski

Ojo, no te fíes solo del rate limit de la API, también tienes que manejar errores de tipo ResourceExhausted y InternalServerError. Yo uso un decorador que captura las excepciones y hace retry solo si el error es recuperable. Además, para no perder datos, guardo los prompts que fallan en una cola tipo Redis y los proceso luego. Es un poco más de infraestructura, pero si tienes volumen, merece la pena.

Folk

Gracias por las respuestas. Me gusta la idea del semáforo, pero tengo una duda: ¿el backoff exponencial con tenacity no choca con el rate limit? Es decir, si la API te devuelve un 429, ¿cómo sabes cuánto tiempo esperar? He leído que a veces el header Retry-After viene bien, pero no he visto que Gemini lo use. ¿Alguna experiencia?

MusicFan

En mi caso, Gemini no envía Retry-After, así que hago lo siguiente: cuando recibo un 429, espero un tiempo fijo (por ejemplo, 1 segundo) y luego reintento. Pero si la respuesta trae el campo error.details con una sugerencia de espera, lo uso. Para no petar el sistema, también establezco un límite global de peticiones por minuto con ratelimit. Es un poco manual, pero no hay otra.

Wine

Perdón, pero discrepo un poco. Si tu volumen es alto, no deberías hacer las llamadas una a una desde tu servidor, sino usar un sistema de colas (como RabbitMQ) y procesar en lotes. Además, la API de Gemini permite enviar varios prompts en una sola llamada usando el parámetro contents como lista. Así reduces el número de peticiones y el coste. Yo lo uso para clasificar textos: mando 20 a la vez y luego parseo la respuesta. Eso es más eficiente que andar con semáforos.

Metalwork

No había pensado en lo de mandar varios prompts en una sola llamada. ¿Funciona bien con gemini-pro? ¿No hay límite de tokens en la respuesta? Y si me permites, ¿cómo parseas la salida para saber cuál corresponde a cada prompt? Supongo que tienes que indicar un separador o algo.

OpenSource

Sí, funciona, pero tienes que tener cuidado con el límite de tokens de salida (por defecto 2048). Si mandas 20 prompts, la respuesta concatenada puede superar eso. Lo que hago es usar un modelo con mayor límite (como gemini-pro con generationConfig ajustado) o procesar en bloques de 5. Para parsear, puedes pedirle al modelo que responda en formato JSON con un campo por prompt, y luego hacer un json.loads. No es perfecto, pero para casos simples va bien.

HipHop

Ojo, que el enfoque de lote puede ser más barato en número de peticiones, pero el coste se calcula por tokens, así que al final pagas lo mismo. La ventaja es que reduces la latencia y el riesgo de rate limit. Yo combino ambos: semáforo para controlar la concurrencia y lote para aprovechar mejor la API. Al final, es cuestión de medir y ajustar.