Carriles de inferencia en producción de Gemini 3.6 Flash y Gemini 3.5 Flash comparados en velocidad y coste

Comparación

Gemini 3.6 Flash frente a Gemini 3.5 Flash: ¿deberías mover cargas de producción?

Jacey

Founder

21 de julio de 2026

20 min de lectura

Última verificación: 2026-07-21. Escrito por Jacey e incluye 216 llamadas a la API que ejecutamos el día del lanzamiento; el método se describe en detalle donde aparecen esos resultados. EvoLink opera un gateway de API que enruta a modelos de terceros, incluidos los dos modelos que se analizan aquí.

La versión corta

Muévete ahora si los tokens de salida dominan tu factura. Los bucles de agentes, la generación larga de código y el trabajo intensivo en razonamiento caen en el rango de un 26 % a un 29 % más barato.
Ganancia pequeña si tu tráfico es intensivo en entrada. Un pipeline de documentos que ronda los 20 tokens de entrada por cada token de salida ahorra un 7,1 %, porque el precio de entrada no cambió en absoluto.
La inteligencia está plana. La medición independiente sitúa a los dos modelos en 50,1 y 50,2 en el mismo índice. Lo que se movió es la velocidad: de 165 a 304 tokens de salida por segundo, y de 2,7 a 1,3 minutos por tarea.
Prueba primero si tu carga de trabajo es intensiva en conocimiento o genera UI de front-end. Esos son los dos sitios donde la evidencia publicada apunta en sentido contrario.
El nivel de thinking mueve tu factura más que el modelo. En nuestras propias pruebas, bajar del valor por defecto medium a minimal recortó el coste de una pasada en un 73,6 % sin pérdida de precisión en nuestro conjunto de tareas. Fíjalo deliberadamente sea cual sea el modelo que ejecutes.
Esto no es un cambio de cadena de modelo. temperature, top_p y top_k ahora se aceptan y luego se ignoran sin error, y thinking_budget ya no existe.

La respuesta corta, por carga de trabajo

El valor de esta actualización depende casi por completo de dos cosas: la proporción de tokens de entrada frente a tokens de salida en tu tráfico, y si la latencia es actualmente una queja.

Tu carga de trabajo	Veredicto	Por qué
Agentes multi-turno, bucles de tool-calling, generación larga de código	Muévete	Los tokens de salida y de thinking dominan, y esa es la única parte del precio que bajó
Cualquier caso donde la latencia por tarea sea la queja	Muévete	El tiempo por tarea se redujo aproximadamente a la mitad en medición independiente
Preguntas y respuestas intensivas en conocimiento	Shadow-run primero	La única puntuación de conocimiento comparable entre generaciones bajó
Generación de front-end y de UI	Shadow-run primero	Google documenta dos regresiones específicas aquí, ambas con una corrección a nivel de prompt
Procesamiento de documentos y RAG a aproximadamente 20:1	Sin prisa	El ahorro es del 7,1 %, que está dentro del ruido de un mes normal

Si la pregunta que en realidad te haces es si ejecutar Gemini 3.5 Flash-Lite en su lugar, esa es una decisión distinta con una respuesta distinta, y la cubrimos en Gemini 3.6 Flash frente a 3.5 Flash-Lite. Flash-Lite es un nivel de capacidad inferior, no una versión más nueva del modelo que estás ejecutando, así que ninguno de los números de abajo se traslada a él.

Qué cambió en realidad

Gemini 3.6 Flash no es una nueva generación de modelo. Su model card afirma que está construido sobre Gemini 3.5 Flash, lo que lo convierte en una actualización de post-entrenamiento sobre la misma base. Ese único hecho explica la mayor parte de lo que sigue: la capacidad se movió lateralmente, mientras que las cosas que el post-entrenamiento y el serving pueden mover, la velocidad y la eficiencia de tokens, se movieron mucho.

Aquí están los detalles prácticos, tomados de la documentación de modelos de Google.

ID del modelo: gemini-3.6-flash. Una versión estable, sin sufijo preview y sin sello de fecha, así que no hay ninguna decisión de aliasing que tomar.
Contexto: 1.048.576 tokens de entrada y 65.536 tokens de salida, sin cambios. Entra texto, imagen, vídeo, audio y PDF; sale solo texto.
Nivel de thinking por defecto: medium, seleccionable entre minimal, low, medium y high.
Precio: la entrada se mantuvo en 1,50 $ por millón de tokens. La salida bajó de 9,00 $ a 7,50 $, un recorte del 16,67 %. Las lecturas cacheadas son 0,15 $ por millón. Consulta la página de precios de Google para los niveles batch y priority.

Esos son los campos que importan para la decisión de esta página. Para la matriz completa de capacidades y una primera solicitud funcional contra el nuevo ID de modelo, consulta nuestra guía de Gemini 3.6 Flash.

Una corrección que vale la pena hacer, porque está circulando: el precio de entrada no subió. Tanto gemini-3.5-flash como gemini-3.6-flash cobran 1,50 $ por millón de tokens de entrada. La afirmación de un aumento oculto viene de comparar contra un precio de una generación Flash anterior.

Qué le pasa a tu factura

Se supone que dos cosas distintas reducen tu coste: el precio de salida es un 16,67 % más bajo, y se reporta que el modelo usa menos tokens de salida para la misma tarea. Compuesto, el gasto del lado de salida cae un 30,8 %.

Ese número es real, y también es la razón por la que tanta cobertura de este lanzamiento exagera el ahorro. El precio de entrada no se movió. Así que cuanto más se acerque tu tráfico a ser intensivo en entrada, menos de ese 30,8 % ves en realidad.

Comparación de coste por carga de trabajo de Gemini 3.6 Flash que muestra por qué las cargas de trabajo de IA intensivas en salida capturan más ahorro que los pipelines intensivos en entrada

El ahorro de Gemini 3.6 Flash se concentra en el lado de salida, así que las proporciones de tokens de la carga de trabajo determinan el impacto en el coste de producción.

Proporción entrada:salida	Carga de trabajo típica	En 3.5 Flash	En 3.6 Flash	Cambio
20:1	Procesamiento de documentos, RAG	$39.00	$36.23	7,1 % más barato
5:1	Preguntas y respuestas generales	$16.50	$13.72	16,8 % más barato
1:1	Agentes multi-turno con thinking activado	$10.50	$7.72	26,4 % más barato
1:3	Trabajo intensivo en razonamiento, generación larga de código	$28.50	$20.17	29,2 % más barato

Lee la tabla así. Cada fila cotiza una carga de trabajo normalizada a 1 millón de tokens de salida en 3.5 Flash, con los tokens de entrada fijados por la proporción indicada, con precios de nivel estándar. Asume un 17 % menos de tokens de salida en el modelo más nuevo y tokens de entrada idénticos.

Ese supuesto del 17 % merece que se indiquen sus condiciones, porque todo en la tabla descansa sobre él. Google cita la cifra en lugar de medirla, y la fuente es Artificial Analysis. Los recuentos absolutos de tokens publicados en esa misma página, 59 millones frente a 75 millones, dan un 21,3 %. Las dos cifras no se han reconciliado públicamente. Usamos el 17 % más conservador en todo momento, así que trata la tabla como el extremo bajo del rango en lugar de una promesa.

Los tokens de thinking se facturan a la tarifa de salida. Por eso las filas de agentes se mueven más: en un agente multi-turno, el presupuesto de thinking no es un redondeo en la factura, es una parte grande de ella.

Luego lo medimos, y la tabla resultó ser optimista. Nuestro conjunto de tareas corre a aproximadamente 1 token de entrada por cada 1,5 tokens de salida facturados, lo que se sitúa entre las filas 1:1 y 1:3, donde la tabla predice un ahorro del 26 % al 29 %. Medimos un 13,6 % en el nivel de thinking medium y un 20,1 % en high.

Toda la brecha es el supuesto de eficiencia de tokens. En medium, el modelo más nuevo facturó un 1,7 % más de tokens de salida que su predecesor, no un 17 % menos, así que casi todo el ahorro que obtuvimos vino del recorte de precio en lugar de la eficiencia de tokens. En high la reducción sí apareció en parte, con un 6,4 % menos de tokens de salida. El método y las cifras completas están en la siguiente sección.

Así que lee la tabla como la aritmética implícita en la afirmación del proveedor, y nuestras cifras como lo que produjo una carga de trabajo real. Si tu trabajo se parece más al nuestro que a un conjunto de benchmarks, planifica con el número más bajo.

Misma inteligencia, aproximadamente el doble de velocidad

Artificial Analysis obtuvo acceso previo al lanzamiento y es actualmente la única fuente independiente con un desglose completo. Sus números, medidos en el nivel de thinking high:

Métrica	3.6 Flash	3.5 Flash
Intelligence Index v4.1	50.1	50.2
Humanity's Last Exam	38.3%	40.2%
GPQA Diamond	92.8%	92.2%
SciCode	52.7%	53.1%
Razonamiento de contexto largo (AA-LCR)	69.7%	69.3%
Velocidad de salida	303.6 tok/s	165.4 tok/s
Tiempo hasta el primer token	11.54 s	20.22 s
Tiempo medio por pregunta	1.3 min	2.7 min
Coste medio por pregunta	$0.50	$0.59

A cada fila se aplican dos condiciones. Se midieron en el nivel de thinking high mientras que el valor por defecto de la API es medium, así que ejecutar la configuración por defecto no es el mismo experimento. Y las cifras de velocidad y latencia son medianas de 72 horas tomadas sobre un modelo que se lanzó el mismo día, lo que significa que la ventana de muestra es de menos de un día y cabe esperar que se mueva.

Dicho eso, la forma es clara y es un compromiso más que una regresión. La paridad del Intelligence Index en 50,1 frente a 50,2 es una diferencia de redondeo. Las puntuaciones de razonamiento y de contexto largo subieron ligeramente. La única puntuación intensiva en conocimiento que es directamente comparable entre las dos generaciones, Humanity's Last Exam, bajó 1,9 puntos. Mientras tanto, la velocidad de salida subió un 84 % y el tiempo por pregunta se redujo aproximadamente a la mitad.

Así que si lo que querías de este lanzamiento era un modelo más inteligente, esta actualización no se construyó para ti, y quedarte en gemini-3.5-flash no te cuesta nada en ese eje. Si lo que querías era la misma calidad de trabajo terminando en la mitad de tiempo a un coste unitario menor, eso es exactamente lo que se lanzó.

La salvedad de lo intensivo en conocimiento merece un paso extra en lugar de una preocupación extra. Un movimiento de 1,9 puntos en un benchmark es una señal para revisar tu propio conjunto de evaluación, no una razón para saltarte el lanzamiento.

El nivel de thinking mueve la factura más que el modelo

Todas las cifras publicadas de arriba describen el nivel de thinking high, mientras que el valor por defecto de la API es medium. Esa brecha es lo bastante grande como para cambiar una decisión de compra, así que ejecutamos nuestra propia prueba el día del lanzamiento.

Los niveles de thinking de Gemini 3.6 Flash acumulan progresivamente más tokens de razonamiento mientras la salida final de producción se mantiene compacta

El nivel de thinking puede cambiar la salida facturada más que el propio cambio de modelo, así que los equipos de producción deberían fijarlo y evaluarlo explícitamente.

El montaje: nueve tareas en tres grupos, extracción estructurada de facturas, logs y HTML de productos; tool-calling multi-turno de tres a cinco pasos contra herramientas simuladas; y localización y reparación de código, donde una descripción de bug tiene que convertirse en un parche ejecutable. Las entradas van entre 1.000 y 4.000 tokens, así que esto no cubre trabajo de contexto largo. Cada tarea se ejecutó tres veces contra cada una de ocho configuraciones de modelo y nivel de thinking, 216 llamadas en total, enviadas en serie a través de OpenRouter con el proveedor fijado a Google AI Studio. Los tokens de respuesta y los tokens de thinking se registraron por separado, y todo se cotiza a la lista de nivel estándar de Google en lugar de la facturación propia del gateway. No se fijó ningún parámetro de muestreo, ya que no hacen nada.

Configuración	Tokens de respuesta	Tokens de thinking	Proporción de thinking	Coste por pasada	Correctas
3.6 Flash `minimal`	1,162	0	0%	$0.0158	9/9
3.6 Flash `low`	1,056	1,095	51%	$0.0232	9/9
3.6 Flash `medium` (por defecto)	1,080	5,944	85%	$0.0598	9/9
3.6 Flash `high`	1,092	6,679	86%	$0.0653	9/9
3.5 Flash `medium`	1,078	5,827	84%	$0.0692	9/9
3.5 Flash `high`	1,113	7,185	87%	$0.0818	9/9

Destacan tres cosas.

Los tokens de thinking son la factura. En medium y high son del 84 % al 87 % de todo lo que pagas por el lado de salida. La longitud de la respuesta apenas se mueve en toda la tabla. Qué modelo elijas cambia tu coste mucho menos que qué nivel elijas.

minimal no es "pensar menos", es "no pensar". Los tokens de thinking volvieron en exactamente cero, una pasada costó un 73,6 % menos que el valor por defecto medium, y la puntuación fue la misma, nueve de nueve. Si estás en medium porque nunca elegiste un nivel, esa es la mayor palanca de coste disponible para ti, y funciona en el modelo que ya estás ejecutando.

high costó aquí solo un 9,3 % más que medium, porque el presupuesto extra quedó sin gastar: el thinking subió de 5.944 tokens a 6.679. Eso es un hecho sobre estas tareas más que sobre el modelo. En trabajo más difícil esa brecha se ensancha.

Dónde nuestros números no concuerdan con la otra ejecución independiente

aibenchy ejecutó 22 preguntas de benchmark cortas tras el lanzamiento y encontró el modelo más nuevo un 29,4 % más caro en medium y un 9,7 % más barato en high. Nosotros lo encontramos más barato en ambos niveles, en un 13,6 % y un 20,1 %. Los resultados de high concuerdan en dirección. Los resultados de medium apuntan en sentidos opuestos, y la razón es visible en un número: ellos midieron un 66,2 % más de thinking en el modelo más nuevo en medium, nosotros medimos un 2,0 % más.

No vamos a decir que su resultado está mal. Dos conjuntos de tareas produjeron respuestas opuestas a la misma pregunta, y esa es la conclusión que vale la pena llevarse: si este modelo te ahorra tokens depende de con qué lo ejecutes, no del modelo por sí solo. El propio "17 % menos de tokens de salida" de Google no nombra ni un nivel de thinking ni un conjunto de tareas, por eso se reproduce en algunas cargas de trabajo y no en otras.

Lo que nuestra prueba no puede decirte. Nueve tareas no eran lo bastante difíciles como para separar los niveles en calidad. Todas las configuraciones puntuaron nueve de nueve. Así que estos números respaldan una recomendación basada en coste sobre qué nivel ejecutar, y no localizan el punto donde la calidad empieza a caer. Las ejecuciones repetidas también variaron: los tokens de thinking se movieron entre un 6 % y un 51 % entre ejecuciones idénticas de la misma tarea, por eso las cifras de arriba son promedios de tres ejecuciones. Una ronda más difícil dirigida a encontrar el codo de calidad está corriendo por separado, y actualizaremos esta página con ella.

La parte accionable es simple: sea cual sea el modelo que ejecutes, fija el nivel de thinking explícitamente y cotiza el nivel que realmente ejecutas, no el nivel al que se publicaron los benchmarks.

Dos cosas que Google dice que el nuevo modelo hace peor

Google publica dos debilidades específicas en su post de lanzamiento, y ambas se concentran en el mismo sitio.

Explora antes de editar. El modelo es más propenso que 3.5 Flash a ejecutar una pasada de diagnóstico antes de cambiar código. En tareas complejas eso eleva la precisión. En tareas de front-end simples produce pasos de exploración extra que no necesitabas y que no querías pagar.

Los evaluadores humanos prefirieron la salida visual del modelo más antiguo. En disposición y estilo visuales específicamente, los evaluadores favorecieron el modelo anterior. La mitigación que indica Google es escribir tus reglas de diseño en el prompt en lugar de dejar el estilo a los valores por defecto del modelo.

La model card también lista alucinaciones y respuestas ocasionalmente lentas o timeouts entre las limitaciones conocidas.

Nada de eso argumenta en contra de la actualización. Argumenta a favor de dividir la decisión por superficie. Si tienes un nivel de agentes y un nivel de generación de UI, son cargas de trabajo distintas con evidencia distinta, y no hay ninguna regla que diga que tengan que ejecutar el mismo ID de modelo.

Cambiar no es un cambio de cadena de modelo

Esta es la parte que atrapa a los equipos, y es la razón por la que una recomendación de "solo cambia el nombre del modelo" del mismo día ahora está mal. A partir de este lanzamiento, y explícitamente para todos los modelos posteriores, varios parámetros cambiaron de comportamiento. La lista completa está en el changelog de la API de Google; los que rompen producción en silencio son estos.

temperature, top_p y top_k se ignoran, y no se lanza ningún error. La documentación de Google afirma que una futura generación de modelos devolverá HTTP 400, pero hoy los valores simplemente se descartan. Si dependes de temperature=0 para mantener determinista un pipeline de extracción o clasificación, esa garantía desaparece sin línea de log, sin excepción y sin alerta. El enfoque de reemplazo es poner la regla en la system instruction.

Hay una versión de segundo orden de esto que vale la pena revisar. Los metadatos de modelo de OpenRouter todavía listan temperature, top_p y seed entre los parámetros soportados, así que un gateway aceptará tu valor y lo reenviará, y el modelo lo ignorará. Cualquiera que hoy esté ajustando temperature para mejorar la calidad de salida está ajustando un no-op.

thinking_budget se reemplaza por thinking_level. El antiguo presupuesto numérico pasa a ser un enum de cadena. Enviar ambos en una solicitud devuelve un 400.

Tres más pequeños. candidate_count no está soportado en Gemini 3.x. Una solicitud cuyo mensaje final lleve el rol model ahora devuelve 400, lo que elimina el prefill de respuesta. Y cada FunctionResponse debe llevar ahora tanto call_id como name.

Para la versión línea por línea, incluido el propio tooling de migración automatizada de Google y el calendario de retirada de los modelos que este reemplaza, consulta nuestra guía de migración a Gemini 3.6 Flash. Una advertencia si buscas esto por tu cuenta: las guías escritas para actualizaciones anteriores de Gemini, incluida la nuestra sobre pasar de Gemini 3 Flash Preview a Gemini 3.5 Flash, todavía describen los parámetros de muestreo como funcionales, porque en ese par de modelos lo eran. Las deprecaciones de arriba empiezan con esta generación.

Una nota práctica sobre probar los dos en paralelo: como ambos IDs de modelo se exponen a través de un único endpoint compatible con OpenAI en EvoLink, puedes apuntar base_url a un solo gateway y cambiar la cadena de modelo para hacerles A/B contra tus propios prompts, sin levantar primero una segunda integración. Esa es la forma más barata de responder las preguntas de arriba sobre conocimiento y UI para tu propio tráfico.

Antes de accionar el interruptor

Los números publicados estrechan la pregunta. Cuatro mediciones la cierran.

Registra los tokens de respuesta y los tokens de thinking por separado. Una métrica de tokens totales no te dirá por qué se movió tu factura, porque solo uno de los dos componentes se comporta de forma distinta entre estos modelos.
Fija el nivel de thinking explícitamente. No heredes medium por accidente, y cotiza el nivel que realmente ejecutas en lugar del nivel high que usaron los benchmarks publicados. En nuestro conjunto de tareas esto valió más que el cambio de modelo: minimal costó un 73,6 % menos que el valor por defecto medium con la misma precisión. Comprueba si tu propio trabajo lo tolera antes de asumir lo mismo.
Haz shadow-run de tu mezcla real de prompts, no de un conjunto de benchmarks. Esto importa más si tu tráfico es intensivo en conocimiento, que es el único eje donde la puntuación comparable bajó.
Haz grep antes de cambiar. Busca en tu código temperature, top_p, top_k, thinking_budget y candidate_count. Los tres primeros fallan en silencio, lo que significa que tus pruebas pasarán y tus salidas derivarán.

FAQ

¿Es Gemini 3.6 Flash un Gemini 3.5 Pro renombrado? Esa especulación circuló tras el lanzamiento. La respuesta de la comunidad más votada la rechazó, argumentando que no hay indicios de un modelo Pro renombrado y que esto es una actualización de Flash. La model card respalda esa lectura: afirma que el modelo está construido sobre Gemini 3.5 Flash. Registramos la especulación, no la respaldamos.

¿Se va a apagar gemini-3.5-flash? Las fechas de retirada que Google ha anunciado son 2026-10-16 para gemini-2.5-flash y gemini-2.5-flash-lite, y 2027-05-07 para gemini-3.1-flash-lite. No se ha anunciado ninguna fecha de retirada para los modelos lanzados el 2026-07-21. No hay ningún plazo anunciado que fuerce esta decisión, así que puedes tomarte el tiempo de medir.

¿Subió el precio de entrada? No. Ambos modelos cobran 1,50 $ por millón de tokens de entrada en nivel estándar. Solo cambió el precio de salida, de 9,00 $ a 7,50 $.

¿Puedo seguir usando temperature=0 para salida determinista? No, y este es el modo de fallo que hay que vigilar. El parámetro se acepta y se ignora sin error. Mueve la restricción a la system instruction y verifica la salida en lugar de la solicitud.

¿Es 3.6 Flash significativamente más barato para RAG? A aproximadamente 20 tokens de entrada por token de salida, las cifras publicadas implican un ahorro del 7,1 %. Es real pero pequeño, porque el lado de entrada de tu factura no cambió. Trátalo como el techo en lugar de la estimación: en nuestras propias tareas el ahorro efectivo salió por debajo de lo que predecía la misma aritmética, y nuestra prueba no cubrió en absoluto la recuperación de contexto largo. Los equipos de RAG deberían tratar este lanzamiento primero como una mejora de latencia y en segundo lugar como una mejora de coste.

¿Qué ID de modelo debería usar? gemini-3.6-flash. Hay una única versión estable, sin sufijo preview y sin variante con sello de fecha entre las que elegir.