La llegada de Gemini 3.1 Flash Live ha cambiado por completo la conversación sobre voz e IA en tiempo real. Ya no estamos hablando solo de pasar texto a audio, sino de agentes capaces de escuchar, razonar, llamar herramientas, consultar la web y responder en voz natural dentro de una misma sesión en vivo. Y todo ello con una estructura de precios que, por primera vez, permite plantearse productos de voz serios sin que el coste se dispare.
En paralelo, Google ha movido ficha con Gemini 3.1 Flash‑Lite y el resto de la familia 3.1, cerrando una arquitectura de modelos por niveles que afecta tanto a cómo diseñamos nuestros sistemas como a cuánto pagamos por cada conversación. Si estás pensando en migrar desde Gemini 2.5 Flash Live, lanzar un asistente telefónico o montar pipelines de moderación y soporte a gran escala, conviene entender muy bien qué ofrece cada pieza… y dónde están los pequeños matices que luego se convierten en bugs caros.
¿Qué es exactamente Gemini 3.1 Flash Live?
Gemini 3.1 Flash Live es el modelo de audio en tiempo real más reciente de Google, accesible en vista previa a través de Gemini Live API dentro de Google AI Studio y Vertex AI. El identificador técnico del modelo es gemini-3.1-flash-live-preview, y está diseñado como un modelo nativo de audio optimizado para diálogos de baja latencia con matices acústicos, precisión numérica y comprensión multimodal (texto, imagen, audio y vídeo).
Es importante entender que no existe un producto separado llamado “Gemini 3.1 Flash Live API”. Lo que hay es Gemini Live API como superficie común, sobre la que puedes ejecutar diferentes modelos Live (entre ellos este 3.1 Flash Live). Técnicamente, se trata de una sesión WebSocket con estado, pensada para streaming continuo, interrupciones de usuario, entrada multimodal y respuestas habladas, no para un simple ciclo clásico de petición-respuesta como el de generateContent.
La documentación oficial indica que el modelo soporta function calling y Search grounding. Traducido a algo práctico: no es solo un sistema de TTS bonito, sino un agente de voz capaz de usar herramientas externas y consultar la web durante la propia conversación. La ficha del modelo marca un knowledge cutoff en enero de 2025, así que si tu caso de uso necesita información reciente tendrás que apoyarte en grounding, tu propio sistema de retrieval o integración con otras APIs.
Hay dos detalles técnicos fáciles de pasar por alto. Por un lado, la ficha del modelo habla de salida en texto y audio, pero la guía de capacidades de Live API recalca que los modelos de audio nativo funcionan con response modality AUDIO. Lo prudente para producción es tratar el texto como una capa de transcripción de salida, no como garantía de que recibirás siempre una respuesta textual pura. Por otro lado, Google confirma que todo el audio generado por Gemini 3.1 Flash Live se marca con SynthID, algo relevante si tu aplicación se orienta a usuarios finales y tienes que informar sobre contenido sintético.
Experiencia real en producción: voz más natural y pipeline simplificado
Uno de los cambios más llamativos al pasar a Gemini 3.1 Flash Live lo están notando equipos que ya operaban agentes de voz en producción. Un ejemplo claro es la plataforma de código abierto Dograh, pensada para construir agentes de llamadas telefónicas con un constructor visual de flujos. Antes utilizaban la típica combinación de STT + LLM + TTS (por ejemplo, Deepgram/Gladia para transcripción, un LLM independiente para el razonamiento y ElevenLabs o cartesia para la síntesis de voz).
Ese enfoque implicaba tres saltos de API encadenados, con la consiguiente complejidad y coste. Al migrar a Gemini 3.1 Flash Live, toda esa tubería se colapsa en una sola conexión Live. En la práctica, el equipo reporta una mejora clara en la calidad percibida de la voz y el ritmo de la conversación. No se trata solo de “un TTS ligeramente mejor”: el modelo maneja con más naturalidad las pausas, las interrupciones del usuario y el tempo general, lo que hace que la interacción suene más cercana a hablar con una persona real.
En cuanto a latencia, sus pruebas desde Asia (contra servidores en Estados Unidos) arrojan una media de alrededor de 922 ms por respuesta. Es una cifra algo más alta que los reclamos de menos de 300 ms que circulan en algunas demos, pero bastante razonable si tenemos en cuenta el componente de red transcontinental. La hipótesis obvia es que en Estados Unidos o regiones más cercanas al servidor se consigan tiempos claramente mejores, así que si desarrollas desde Europa o América conviene medir con tus propios números.
Hay un punto conflictivo que les ha sorprendido: no se puede acceder a las transcripciones en tiempo real durante la llamada. Están disponibles una vez finalizada la sesión, lo que sirve perfectamente para análisis post‑llamada, pero dificulta mucho la ingeniería de contexto en vivo. Si tu agente necesita, por ejemplo, hacer un resumen de lo ya hablado a mitad de la conversación, tienes que replantear cómo gestionas el contexto y qué información mantienes en tu propio backend en lugar de confiar en una transcripción continua proporcionada por el modelo.
En el lado económico, la estructura de precios de Gemini 3.1 Flash Live resulta competitiva frente a operar tres APIs separadas (STT, LLM, TTS). Además, la capacidad de llamar a herramientas durante sesiones de audio en vivo funciona de forma sólida. Para muchos desarrollos, llegamos a un punto donde la antigua arquitectura STT + LLM + TTS empieza a sentirse como el enfoque equivocado, tanto por coste como por robustez y latencia agregada.
La familia Gemini 3.1: Pro, Flash y Flash‑Lite
Gemini 3.1 no se limita a Live; Google ha articulado una familia de modelos por niveles con roles bien definidos. En la parte alta está Gemini 3.1 Pro, pensado para razonamiento complejo y tareas exigentes. En el punto intermedio encontramos Gemini 3.1 Flash, que trata de combinar buena capacidad de razonamiento con velocidad. Y en el escalón de volumen y precio contenido se sitúa Gemini 3.1 Flash‑Lite, el modelo más rentable para cargas repetitivas y latencia baja.
Lo interesante de Flash‑Lite es que no se limita a ser una versión recortada de Flash. Está construido sobre la misma arquitectura base que Gemini 3 Pro, pero ajustado específicamente para priorizar rendimiento y coste. Por eso, en muchos benchmarks se comporta mejor de lo que uno esperaría por su precio, llegando a igualar o superar en capacidad a Gemini 2.5 Flash a pesar de ser más rápido y barato.
Flash‑Lite y su lógica de “niveles de pensamiento”
La novedad conceptual más llamativa de Gemini 3.1 Flash‑Lite es la introducción de los llamados niveles de pensamiento: mínimo, bajo, medio y alto. No hablamos de un cambio de modelo, sino de cuánto cómputo interno se permite dedicar a cada tarea. Para una simple traducción de texto, por ejemplo, puedes fijar el nivel en mínimo y conseguir una respuesta prácticamente instantánea y muy barata. Si la tarea exige más precisión o requiere interpretar matices, subes el nivel a medio o alto y aceptas un pico de latencia y coste.
En pruebas con tickets de soporte al cliente, con el nivel mínimo las respuestas llegaban en menos de dos segundos, suficientes para preguntas rutinarias. Con el nivel medio, tardaba unos cinco segundos pero captaba mejor los detalles ocultos en el mensaje, lo que puede ser clave cuando nos jugamos la satisfacción del usuario. Esta capacidad de modular el “pensamiento” del modelo de acuerdo con la tarea y el presupuesto es una herramienta muy potente para ajustarse a los requisitos de cada producto.
Coste y rendimiento de Gemini 3.1 Flash‑Lite
En términos de precio, Flash‑Lite se posiciona como el modelo más económico de la línea Gemini. La tarifa anunciada es de unos $0,25 por millón de tokens de entrada y $1,50 por millón de tokens de salida. Frente a ello, Gemini 3.1 Pro arranca en torno a $2 por millón de tokens de entrada y $18 por millón de tokens de salida en cargas pesadas, así que estamos hablando de aproximadamente una octava parte del coste para tareas básicas.
Lo llamativo es que también resulta más barato que Gemini 2.5 Flash, que rondaba los $0,30/$2,50, pese a ofrecer mayor capacidad. Es un movimiento poco habitual, porque lo normal es que una mejora de prestaciones se traduzca en un precio igual o superior. En rendimiento, Google habla de una velocidad de generación de unos 363 tokens por segundo, con un tiempo hasta el primer token unas 2,5 veces más rápido que en 2.5 Flash. En pipelines de moderación o clasificación de contenido, esa diferencia entre tres segundos de espera y uno se nota mucho cuando procesas cientos o miles de elementos.
Flash‑Lite admite entrada multimodal (texto, imágenes, audio y vídeo), con una ventana de contexto de hasta 1 millón de tokens y capacidad para generar hasta 64.000 tokens de salida textual. En pruebas reales con catálogos de e‑commerce y etiquetado de imágenes, se ha observado un nivel de consistencia muy alto en clasificación, algo crítico cuando automatizas etiquetado de productos o moderación de comunidades a gran escala.
Cuándo usar Flash‑Lite y cuándo subir a Flash o Pro
La regla operativa sencilla sería: usa Gemini 3.1 Flash‑Lite cuando ejecutes miles o millones de tareas homogéneas donde importe más el coste por token que el razonamiento avanzado. Pensemos en traducción masiva, moderación de contenido, análisis de sentimiento simple o extracción de datos estructurados (por ejemplo, campos clave de facturas y recibos).
Un patrón muy efectivo es usar Flash‑Lite como modelo de enrutamiento. Se le encarga leer la solicitud entrante, clasificarla como “simple” o “compleja” y, en función de ello, redirigir el trabajo hacia Flash o Pro. Este enfoque permite reducir el coste global sin sacrificar calidad en las tareas que de verdad necesitan un modelo más potente. De hecho, el propio CLI de Gemini de código abierto ya utiliza Flash‑Lite para este papel de controlador de tráfico.
En cambio, si la tarea implica razonamiento en múltiples pasos, creatividad, resolución de problemas ambiguos o programación compleja, conviene irse directamente a Gemini 3.1 Flash o Pro. En una prueba para generar componentes de interfaz de usuario a partir de descripciones en lenguaje natural, Flash‑Lite se defendía bien con peticiones muy directas, pero se quedaba corto cuando el prompt era más vago o requería decisiones de diseño abiertas. Gemini 3.1 Flash manejaba tanto las solicitudes precisas como las más abiertas con resultados mucho más sólidos.
Qué lanzó Google realmente el 26 de marzo y cuál es el estado del modelo
El anuncio oficial del 26 de marzo de 2026 presenta Gemini 3.1 Flash Live como el último modelo de audio en tiempo real de Google, disponible para desarrolladores en modo vista previa. La página de modelo concreta ese mensaje de marketing en un contrato técnico: código gemini-3.1-flash-live-preview, entrada multimodal y orientación clara a diálogo de baja latencia.
En las notas de documentación, Google deja claro que este modelo soporta function calling y grounding con Search, y que continúa en evolución activa, con mejoras constantes en seguimiento de instrucciones, calidad de entrada de audio y capacidades de razonamiento. A fecha del lanzamiento y en los meses posteriores, el modelo sigue marcado como preview, con los consiguientes límites de tasa algo más conservadores. Para pruebas habituales no suelen saltar las cuotas, pero si planeas una despliegue industrial en producción, es clave revisar tus límites concretos en AI Studio en lugar de asumir lo que lees en una tabla genérica.
Elegir entre Gemini 2.5 Flash Live y 3.1 Flash Live
Para proyectos nuevos, la recomendación lógica es empezar directamente con Gemini 3.1 Flash Live. Google lo señala como su modelo Live de referencia y, además, la propia documentación de migración indica que espera movimiento progresivo desde gemini-2.5-flash-native-audio-preview-12-2025. Sin embargo, migrar no significa que “todo lo de 2.5 existe igual o mejor en 3.1”.
La clave está en revisar si tu diseño actual depende de capacidades que 2.5 sí ofrece y 3.1 todavía no replica. La guía de migración habla muy claro: Gemini 3.1 Flash Live usa tool calling secuencial. Si explotabas behavior: NON_BLOCKING en 2.5 para que la conversación continuara mientras las herramientas trabajaban en segundo plano, ese patrón hoy no está disponible en 3.1. Lo mismo ocurre con características como proactive audio o affective dialog: si tu UX apoyaba parte de su magia en esos comportamientos, puedes perder más de lo que ganas solo por mejorar la calidad de voz.
Un resumen honesto sería algo así: si arrancas proyecto, usa 3.1 Flash Live; si ya tienes un sistema maduro en 2.5 Flash Live, migra solo cuando las nuevas restricciones encajen bien con tu producto. A veces, una arquitectura más limpia y una latencia algo mejor no compensan la pérdida de ciertas capacidades asíncronas que tu experiencia actual da por sentadas.
Precios de Gemini 3.1 Flash Live leídos como operador, no como tokens
Uno de los aciertos de la nueva tabla de precios de Live es que incluye tarifas por minuto, mucho más cercanas a cómo piensa alguien que opera un producto de voz que las cifras en millones de tokens. Asumiendo audio de entrada y salida continuos, los números publicados implican en torno a $0.023 por minuto de conversación puramente de audio. Una llamada de 10 minutos se iría a unos $0.23 de coste bruto de modelo antes de sumar grounding, procesamiento de imagen o vídeo y el resto de tu infraestructura.
El grounding con Google Search es otra línea de coste que muchos subestiman. Con una tarifa aproximada de $14 por cada 1.000 consultas, cada llamada a Search sale por unos $0.014 una vez superado el tramo gratuito. Una sesión de voz que dispare cinco consultas estaría añadiendo en torno a $0.07 extra. No parece dramático en una llamada aislada, pero en productos de alto volumen termina afectando al margen.
En vídeo hay un riesgo añadido menos evidente. La guía de migración explica que, por defecto, el turn coverage incluye todos los frames de vídeo. Si vienes de 2.5 con la costumbre de enviar cámara abierta todo el rato mientras el trabajo real es casi todo de voz, en 3.1 puedes encontrarte con una factura inflada de forma silenciosa. Y, como siempre con modelos en vista previa, las cuotas de peticiones por minuto o por día no aparecen de forma limpia en la página pública; hay que ir a Google AI Studio para comprobar los rate limits reales de tu proyecto.
Arquitectura de integración: backend primero, navegador después
Si lo que buscas es tener algo funcional con Gemini 3.1 Flash Live lo antes posible, la vía más rápida y sensata sigue siendo la integración server‑to‑server. La documentación de Live API la trata prácticamente como opción por defecto. El patrón base es claro: abres una sesión Live, indicas que quieres respuesta de tipo AUDIO y empiezas a enviar datos mediante send_realtime_input según llegan audio, texto o vídeo desde tu aplicación.
Para audio real, Google exige PCM de 16 bits a 16 kHz en little‑endian como entrada, con un MIME type del estilo audio/pcm;rate=16000. El audio de salida llega en PCM a 24 kHz. Los límites de sesión documentados son de 15 minutos para sesiones solo de audio y 2 minutos si hay audio + vídeo, aunque se pueden ampliar de forma lógica aplicando las técnicas de session management y resumption descritas en la guía.
Si necesitas conexión directa desde el navegador, Google no recomienda exponer una API key larga en el frontend, sino trabajar con ephemeral tokens. La idea es clara: emites tokens de corta vida desde tu backend, el cliente los utiliza como si fueran una API key para abrir la sesión Live y mejoras la latencia de extremo a extremo sin comprometer seguridad. Los defaults habituales son alrededor de 1 minuto para abrir una nueva sesión con el token y luego unos 30 minutos para seguir enviando mensajes en esa conexión, mientras el token tenga sentido operativo.
Errores típicos al migrar de Gemini 2.5 Flash Live a 3.1 Flash Live
La parte más traicionera de una migración no son los fallos ruidosos, sino lo que sigue funcionando “a medias” mientras tu aplicación ya se comporta de forma diferente a la esperada. La documentación de 3.1 destaca una serie de cambios que conviene aplicar con cuidado para no perder horas en debugging.
En primer lugar, hay que dejar de enviar thinkingBudget. En 3.1 esa configuración ya no existe y el control pasa a llamarse thinkingLevel, con valor por defecto minimal para priorizar la latencia. Si sigues utilizando el antiguo parámetro de 2.5, estarás girando una perilla que ya no hace nada. En segundo lugar, al procesar los eventos del servidor es fundamental leer todas las parts de cada evento, porque un único mensaje puede incluir audio y transcripción a la vez; si tu parser asume una parte por evento, puedes perder datos sin enterarte.
También cambia el flujo de mensajes del cliente. En 2.5, send_client_content podía seguir alimentando la conversación durante toda la sesión; en 3.1 queda para el seed inicial. Todo lo que ocurra en vivo debe pasar por send_realtime_input. En cuanto a herramientas, hay que diseñarlas como bloqueantes y síncronas: el modelo espera la respuesta de la tool antes de avanzar. Si tu experiencia se apoyaba en tools en segundo plano mientras la charla continuaba, tendrás que rediseñar la orquestación.
Otros ajustes recomendados son eliminar de la configuración opciones no soportadas como proactive audio o affective dialog, revisar con lupa el envío de vídeo para no pagar por frames innecesarios y, si necesitas texto, tratarlo siempre como transcripción de salida. La documentación es algo ambigua en ese punto, así que asumir que tendrás siempre texto “limpio” como si fuera un modelo puramente textual puede llevar a sorpresas.
¿Cuándo Gemini 3.1 Flash Live no es la elección adecuada?
A pesar de sus ventajas, hay bastantes situaciones en las que tiene más sentido elegir otra pieza del ecosistema. Si tu producto no gira en torno a la voz en tiempo real, Live API añade complejidad innecesaria: gestión de sesiones WebSocket, audio PCM, interrupciones, tokens efímeros, etc. Para chat de texto clásico o generación de contenido, probablemente estés mejor con modelos no Live de la familia Gemini.
Si tu sistema actual depende fuertemente de uso asíncrono de herramientas, migrar a 3.1 puede incluso empeorar la experiencia. Es la razón principal para mantenerte un tiempo más en 2.5 Flash Live. De igual modo, si no puedes implementar una capa de backend capaz de emitir ephemeral tokens con seguridad, no fuerces una arquitectura de navegador directo: mantener toda la sesión Live del lado del servidor sigue siendo la alternativa más sensata.
Y si lo único que necesitas es convertir texto en voz sin razonamiento, herramientas ni multimodalidad, un servicio de TTS puro será casi seguro más sencillo y barato de operar. Gemini 3.1 Flash Live está diseñado para agentes conversacionales complejos; usarlo como un simple altavoz inteligente suele ser matar moscas a cañonazos.
En conjunto, el aterrizaje de Gemini 3.1 Flash Live y Flash‑Lite marca un punto de inflexión: por un lado, simplifican la pila clásica STT + LLM + TTS en una sola capa capaz de mantener conversaciones ricas con herramientas y grounding; por otro, consolidan un modelo de infraestructura de IA por niveles en el que combinas un router barato y rápido con razonadores potentes cuando hace falta.
Entender bien sus límites —latencia real, costes por minuto, restricciones en el uso de tools y manejo de vídeo— es lo que te permitirá pasar de pruebas vistosas a productos de voz que aguantan el tipo en producción y escalan sin tirar tus márgenes por la ventana. Comparte la información para que más usuarios conozcan del tema.