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.