Primero el montaje, porque es ahí donde esto se torció. Cogí el prompt exacto que hay detrás de la demo de voz de marca de nuestra landing, esa que lee unos cuantos de tus posts y escribe uno nuevo con tu voz, y lo pasé por tres modelos: Sonnet 4.6 de Claude (el que tenemos en producción), DeepSeek y GLM. Seis muestras de voz distintas, cada una dos veces, y cada salida anonimizada puntuada por un juez a ciegas. La pregunta tenía dinero de verdad detrás: ¿podría un modelo más barato hacer este trabajo igual de bien que Sonnet, o mejor?
Lo corrí de tres maneras, y las tres tandas se contradijeron de forma tan completa que "qué modelo" resultó ser la pregunta equivocada. Ronda a ronda.
Ronda 1: cambiar el nombre del modelo
Esta es la prueba que casi todo el mundo hace de verdad. La misma configuración que en producción, solo que con otro nombre de modelo.
| Modelo | JSON válido | Latencia | Coste/gen |
|---|---|---|---|
| Sonnet 4.6 | 12/12 | 7,9 s | 0,0079 $ |
| DeepSeek | 4/12 | 22,7 s | 0,0013 $ |
| GLM | 0/12 | 26,7 s | 0,0041 $ |
GLM no produjo ni una sola salida usable. DeepSeek produjo cuatro. No porque sean malos modelos, sino porque ambos son reasoning-first: con el presupuesto de tokens de producción se ponen a pensar en voz alta ("1. Analicemos los posts...") y se quedan sin sitio antes de soltar el JSON que la página necesita. El cambio ingenuo no te da una demo peor. Te da una rota. Si me hubiera quedado en un sondeo de dos salidas, me habría enterado de esto por los usuarios.
Ronda 2: dales espacio
Los mismos modelos, pero con modo JSON activado y un presupuesto de tokens más grande, para que los modelos de razonamiento puedan terminar la idea.
| Modelo | JSON válido | Latencia | Nota del juez |
|---|---|---|---|
| Sonnet 4.6 | 12/12 | 7,7 s | 3,37 |
| DeepSeek | 11/12 | 43 s | 4,33 |
| GLM | 12/12 | 44 s | 4,73 |
La foto se da la vuelta. Con espacio para terminar, los dos retadores emiten JSON válido, y el juez puntúa su parecido con la voz por encima o al nivel de Sonnet. Así que los modelos en sí nunca fueron el problema; lo era la primera prueba. Pero mira la latencia. Más de cuarenta segundos. Nadie espera 44 segundos por una demo en una landing. Salida estupenda, función inservible.
Ronda 3: la versión que de verdad lanzarías
Modo JSON activado, razonamiento desactivado y DeepSeek en su endpoint rápido.
| Modelo | JSON válido | Latencia | Coste/gen | Nota del juez |
|---|---|---|---|---|
| Sonnet 4.6 | 12/12 | 8,7 s | 0,0079 $ | 3,17 |
| DeepSeek (rápido) | 12/12 | 2,8 s | 0,00019 $ | 4,10 |
| GLM (sin razonar) | 12/12 | 9,0 s | 0,0017 $ | 4,77 |
Con la fontanería adecuada, los dos se vuelven viables de verdad. El endpoint rápido de DeepSeek respondió en 2,8 segundos, más rápido que Sonnet, a más o menos una cincuentava parte del coste, con JSON válido en todas y cada una de las veces. GLM igualó la velocidad de Sonnet a una quinta parte del coste y se llevó la nota más alta del juez. Las muestras respaldaron los números. GLM clavó el cierre de una creadora ("ahora mismo romantizando mi matcha sobrevalorado, y no voy a aceptar preguntas"), y las muestras bilingües volvieron correctamente en italiano en los tres modelos.
Lo que de verdad aprendí
El modelo era la variable menos interesante. Los mismos tres modelos pasaron de rotos a mejores que el titular sin cambiar el modelo en absoluto, solo la fontanería a su alrededor. El presupuesto de tokens, el modo JSON y si el razonamiento estaba activado o no pesaron más que qué laboratorio entrenó el aparato. Todo el ejercicio fue un recordatorio de que "pásate al modelo más barato y ya" es una frase que esconde toda la ingeniería de verdad.
Una advertencia, porque el juez tampoco fue perfecto. Acertó al pillar que Sonnet envuelve su JSON en bloques de markdown, lo cual es real y la razón de que producción tenga un quitabloques. Pero también se inventó infracciones de raya larga en salidas que no contenían ni una sola raya larga. Así que me fío más de las muestras vistas con mis ojos que de las notas con sus decimales exactos. La dirección es sólida; el tercer decimal, no.
¿La decisión práctica? Para esta demo en concreto el gasto es minúsculo, así que Sonnet se queda como opción segura por defecto y el endpoint rápido de DeepSeek es la mejora a la que tiraría primero. De todas formas, el ahorro de verdad no está aquí. Está en las funciones de mucho volumen que se ejecutan miles de veces al día, donde 50 veces más barato deja de ser un error de redondeo. Esa es la prueba que merece la pena correr a continuación.
Si te quedas con una sola cosa: antes de cambiar un modelo para ahorrar dinero, pásalo por la fontanería exacta en la que va a vivir. El modelo que crees que estás probando no es el que reciben tus usuarios.