🎁 Nuevo Regístrate gratis, 10 llamadas de regalo. Hasta 1 $, sin tarjeta.
Reasoning effort en GLM 5.2: el ajuste que reduce el coste 20x

Reasoning effort en GLM 5.2: el ajuste que reduce el coste 20x

Contenido
  1. Qué es GLM 5.2
  2. Cómo queda frente a otros modelos por precio
  3. El ajuste de reasoning effort
  4. Una tarea sencilla: razonar solo aumenta el coste
  5. Una tarea compleja: el razonamiento compensa, pero el valor predeterminado no
  6. La regla de decisión
  7. La caché ayuda con la entrada, no con el razonamiento
  8. Cómo usarlo en Synthorai
  9. Conclusión
  10. Fuentes

GLM 5.2 ya está disponible en Synthorai por aproximadamente una sexta parte del precio por token de los modelos frontier. Su promesa de pesos abiertos y resultados comparables a los modelos frontier es real. Pero el precio por token no es la cifra en la que conviene fijarse. El coste real de una tarea de programación con GLM 5.2 puede variar en más de un orden de magnitud por un único ajuste: el reasoning effort. Y el valor predeterminado deja ese ajuste en la peor posición. Bien configurado, GLM 5.2 acierta y cuesta menos que los modelos frontier tanto en tareas sencillas como complejas. Con la configuración predeterminada, la misma respuesta cuesta veinte veces más y tarda varios minutos. Lo hemos medido.

TL;DR

  • GLM 5.2 cuesta en Synthorai $1.40/M de entrada y $4.40/M de salida, aproximadamente una sexta parte de la tarifa de salida de claude-opus-4-8.
  • En una tarea de programación sencilla, GLM 5.2 con el razonamiento desactivado costó $0.0008 y tardó 5 segundos. El valor predeterminado sin límite produjo la misma respuesta por $0.0285 y tardó 137 segundos.
  • En una tarea compleja, reasoning_effort: high dio la respuesta correcta por $0.0031 en 13 segundos: unas 20 veces más barato y 30 veces más rápido que el valor predeterminado sin límite ($0.062, 405 segundos).
  • En ambas tareas, el nivel low de GLM generó más tokens de razonamiento que high: los nombres de los niveles no se corresponden con la cantidad de tokens.

Qué es GLM 5.2

GLM 5.2 es el modelo frontier de pesos abiertos de Zhipu, publicado el 2026-06-13. Es una red mixture-of-experts (~744B de parámetros totales, ~40B activos), ofrece un contexto útil de 1M tokens y usa una licencia MIT que permite alojarlo en infraestructura propia. Está orientado a programación y tareas con agentes, con buenos resultados publicados en benchmarks (SWE-bench Pro 62.1, Terminal-Bench 2.1 81.0, AIME 2026 99.2, GPQA Diamond 91.2). En Synthorai se identifica como glm-5.2 y cuesta $1.40 por millón de tokens de entrada y $4.40 por millón de tokens de salida.

El punto clave para todo lo que sigue es que se trata de un modelo de razonamiento, y la cantidad de razonamiento es configurable.

Cómo queda frente a otros modelos por precio

Por precio de catálogo por token, GLM 5.2 está muy por debajo de los modelos frontier occidentales y entre los modelos chinos más baratos. Estas son las tarifas de Synthorai para una selección representativa:

ModeloEntrada ($/M)Salida ($/M)Lectura de caché ($/M)
deepseek-v4-pro0.440.870.0036
kimi-k2.50.573.010.12
glm-5.21.404.400.26
qwen3-max1.206.000.36
gemini-3.1-pro2.0012.000.20
claude-opus-4-85.0025.000.50
gpt-5.55.0030.000.50

Su tarifa de salida de $4.40 es aproximadamente una séptima parte de la de gpt-5.5 y una sexta parte de la de claude-opus-4-8, aunque deepseek-v4-pro y kimi-k2.5 son aún más baratos. GLM 5.2 ofrece prestaciones de nivel frontier a precios propios de los modelos chinos, pero no es la opción más barata. No hay una tarifa independiente por escribir en caché: la escritura se factura al precio de entrada y solo la lectura recibe el descuento indicado en la tabla. El descuento varía según el proveedor. En GLM 5.2, una lectura de caché cuesta aproximadamente una quinta parte de la tarifa de entrada; en los modelos frontier (gpt-5.5, claude-opus-4-8, gemini-3.1-pro), las lecturas cuestan alrededor de una décima parte.

También supone un avance respecto a sus predecesores. La generación anterior de GLM era extraordinariamente barata. La familia GLM 5 subió los precios, y GLM 5.2 cuesta aproximadamente tres veces más por token de entrada que GLM-4.6, según las tarifas oficiales de Zhipu:

Modelo GLMPublicaciónEntrada ($/M)Salida ($/M)
GLM-4.52025-070.602.20
GLM-4.62025-090.431.74
GLM-520261.003.20
GLM-5.22026-061.404.40

A cambio, se obtiene el contexto de 1M y los resultados de nivel frontier en benchmarks. Pero la tarifa por token es solo el titular. El coste real por tarea depende del reasoning effort.

El ajuste de reasoning effort

El razonamiento de GLM 5.2 se regula por niveles, no con un simple interruptor. Puede desactivarse (enable_thinking: false), configurar reasoning_effort como low, medium o high, o dejar el valor predeterminado, que ejecuta el razonamiento sin límite. Este ajuste afecta al coste y a la latencia mucho más que el precio por token. Probamos una tarea de programación sencilla y otra compleja con todas las configuraciones. Después comprobamos cada respuesta contra una implementación de referencia usando cientos de casos aleatorios.

Una tarea sencilla: razonar solo aumenta el coste

Planificación de intervalos ponderados, un problema de programación dinámica de dificultad intermedia:

ModoTokens de razonamientoTokens de respuestaCosteLatenciaCorrecto
glm-5.2, razonamiento desactivado0169$0.0008≈5s
glm-5.2, reasoning_effort: low1,563150$0.007639s
glm-5.2, valor predeterminado sin límite≈6,290≈150$0.0285137s
gpt-5.5 (referencia)59141$0.00644.8s
claude-opus-4-8 (referencia)0201$0.00573.3s

Hay dos resultados claros. Con el razonamiento desactivado, la respuesta es correcta y tiene el menor coste de toda la tabla, unas 8 veces menos que los modelos frontier. Aumentar el nivel solo encarece la misma respuesta. Además, la factura depende del razonamiento, no de la respuesta: el código que devuelve GLM tiene unos 150 tokens en todos los casos, mientras que el razonamiento previo pasa de cero a unos 6,300 tokens, facturados a la misma tarifa de salida de $4.40/M. El valor predeterminado sin límite consume todos esos tokens para llegar a la misma solución que obtuvo sin razonamiento, y eso explica toda la diferencia de coste. Los modelos frontier responden aquí con poco o ningún razonamiento declarado: gpt-5.5 usa 59 tokens de razonamiento y el consumo de claude-opus-4-8 no registra ninguno.

Una tarea compleja: el razonamiento compensa, pero el valor predeterminado no

Coincidencia de cadenas con comodines (? y *), el problema clásico en el que es fácil introducir errores difíciles de detectar. Con el razonamiento desactivado, la solución falló. Devolvió una recursión con memoización:

def is_match(s, p):
    memo = {}
    def match(i, j):
        if (i, j) in memo:
            return memo[(i, j)]
        if j == len(p):
            result = i == len(s)
        elif i < len(s) and p[j] in (s[i], '?'):
            result = match(i + 1, j + 1)
        elif p[j] == '*':
            result = match(i + 1, j) or match(i, j + 1)
        else:
            result = False
        memo[(i, j)] = result
        return result
    return match(0, 0)

A primera vista parece correcta, y el uso de memoización da la impresión de que se han cuidado los detalles. Pero la rama de * llama de forma recursiva a match(i + 1, j) sin limitar i. Cuando se agota la cadena y aún queda un * en el patrón, i sigue creciendo indefinidamente hasta desbordar la pila. Rápida, barata e incorrecta.

Al subir el nivel, devuelve el algoritmo iterativo correcto con dos punteros, que retrocede hasta el último * en vez de usar recursión:

def is_match(s, p):
    s_idx, p_idx, star_idx, match_idx = 0, 0, -1, 0
    while s_idx < len(s):
        if p_idx < len(p) and (p[p_idx] == '?' or p[p_idx] == s[s_idx]):
            s_idx += 1
            p_idx += 1
        elif p_idx < len(p) and p[p_idx] == '*':
            star_idx = p_idx
            match_idx = s_idx
            p_idx += 1
        elif star_idx != -1:
            p_idx = star_idx + 1
            match_idx += 1
            s_idx = match_idx
        else:
            return False
    while p_idx < len(p) and p[p_idx] == '*':
        p_idx += 1
    return p_idx == len(p)

Estos son los resultados de todos los niveles en esta tarea:

Configuración de GLM 5.2CosteLatenciaCorrecto
razonamiento desactivado$0.00076sno (desbordamiento de pila)
reasoning_effort: high$0.003113s
reasoning_effort: medium$0.003216s
reasoning_effort: low$0.006840s
valor predeterminado sin límite$0.062405s
gpt-5.5 (referencia)$0.00645.4s
claude-opus-4-8 (referencia)$0.00694.6s

Todos los niveles explícitos resolvieron el problema. reasoning_effort: high lo hizo por $0.0031 en 13 segundos: unas veinte veces más barato y treinta veces más rápido que el valor predeterminado sin límite para la misma respuesta. También cuesta menos que los modelos frontier y solo tarda unos segundos más. GLM tiene una peculiaridad: low produjo más razonamiento que high de forma consistente en ambas tareas, así que los nombres no reflejan la cantidad de tokens. Medium y high fueron los niveles más baratos y rápidos.

Hay que evitar el valor predeterminado sin límite. Reúne lo peor de ambos extremos: consume razonamiento que quizá no sea necesario y tarda minutos, para terminar dando la misma respuesta que reasoning_effort: high por veinte veces más dinero.

La regla de decisión

El factor decisivo es el reasoning effort, y la configuración adecuada depende de la tarea, no del modelo:

  • Tareas sencillas o de gran volumen en las que sea fácil comprobar la corrección: razonamiento desactivado (enable_thinking: false). La respuesta es correcta y cuesta unas 8 veces menos que con los modelos frontier.
  • Problemas más complejos en los que falle sin razonamiento: reasoning_effort: medium o high. Respuesta correcta por unos $0.003 por tarea, más barata que los modelos frontier y solo unos segundos más lenta.
  • Nunca el valor predeterminado sin límite. Dejar el razonamiento activo sin limitar el esfuerzo convierte una respuesta de $0.003 en otra de $0.06 que tarda siete minutos.

Si no se puede determinar de antemano si una tarea necesita razonamiento, reasoning_effort: high es una opción predeterminada segura: fue barato, resolvió ambas tareas y nunca se disparó.

La caché ayuda con la entrada, no con el razonamiento

GLM 5.2 admite caché en el gateway y funciona justo donde cabría esperar. Enviamos un prefijo compartido de 1,494 tokens, un módulo de código que había que revisar, junto con varias preguntas diferentes:

LlamadaTokens del promptEn cachéSalidaCosteLatencia
pregunta nueva, prefijo aún sin almacenar en caché1,4930120$0.00266.5s
pregunta nueva, prefijo almacenado en caché1,4941,472120$0.00095.1s
repetición exacta (acierto semántico)1,4941,494120$0.00091.0s

Cuando el sistema ha visto un prefijo grande, lo almacena en caché. Los tokens de entrada en caché se facturan aproximadamente a una quinta parte de la tarifa normal de entrada. Esto redujo una petición idéntica en todo lo demás de $0.0026 a $0.0009, alrededor de un 64%. Las repeticiones exactas se sirven directamente desde la caché semántica: la misma respuesta al mismo coste que la llamada con caché, pero en cerca de un segundo en lugar de cinco.

La limitación es la misma que mostró el ajuste de razonamiento: la caché reduce el precio de la entrada. En cuanto se activa el razonamiento, el coste y la latencia pasan a depender de la salida de razonamiento, que no se almacena en caché. Por tanto, la caché aporta un ahorro real en tareas con mucho contexto y sin razonamiento, como enviar el mismo system prompt o codebase en cada llamada. Con el razonamiento activado, el ahorro es pequeño.

Cómo usarlo en Synthorai

glm-5.2 ya está disponible en el gateway. Nuestras pruebas dejan tres recomendaciones prácticas:

  • Configura explícitamente el reasoning effort. Usa enable_thinking: false para tareas sencillas y reasoning_effort: medium o high para problemas más complejos. Evita dejar el razonamiento activo sin límite de esfuerzo, es decir, el valor predeterminado: esa es la trampa de $0.06 y siete minutos.
  • Usa streaming cuando el razonamiento esté activo. Las respuestas con razonamiento pueden tardar varios minutos. En una petición sin streaming, la conexión permanece en silencio durante tanto tiempo que el cliente probablemente agotará el timeout antes de recibir la respuesta. Con stream: true se obtiene salida incremental y el resultado completo.
  • Reutiliza el contexto. Si envías el mismo system prompt grande o codebase en cada llamada, la caché de prefijos reduce el coste de entrada. Combinada con el razonamiento desactivado, abarata toda la petición.

El precio es de $1.40 / $4.40 por millón de tokens, y el gateway devuelve un campo cost en cada llamada para mostrar el coste exacto de la petición.

Conclusión

GLM 5.2 es un modelo de programación realmente barato y capaz. Con una configuración adecuada, supera en precio a los modelos frontier tanto en tareas sencillas como complejas. El problema está en la configuración. Su razonamiento se regula por niveles, pero el valor predeterminado no impone ningún límite. Así es como una tarea que debería costar $0.003 termina convertida en una llamada de $0.06 y siete minutos. Usa enable_thinking: false para tareas sencillas y reasoning_effort: medium o high para el resto. Con esos ajustes, GLM 5.2 ofrece respuestas correctas a bajo coste en todos los casos. Con el razonamiento predeterminado, se convierte en la opción más lenta y cara de todas.


Fuentes

Otras guías de esta serie con costes medidos: coste de la transcripción de audio con siete modelos ASR y coste de la generación de imágenes.

(Los precios de Synthorai indicados arriba son las tarifas de esta plataforma a fecha de 2026-06-24; las tarifas por generación de GLM proceden de la lista oficial de Zhipu).

Costes medidos en Synthorai el 2026-06-24 (glm-5.2 a $1.40 / $4.40 por M tokens); comprueba los precios actuales antes de basarte en ellos.

← Volver al blog