Por qué el coste por token no basta
El coste de generar una página con AesCode 8B no se reduce necesariamente a los tokens de entrada y salida. El modelo produce artefactos visuales estructurados en HTML y CSS, y el flujo descrito por el proyecto incluye renderizar el resultado en un navegador y comprobar propiedades del código y de la página. Si un resultado no cumple los criterios establecidos, un equipo también puede decidir corregirlo o generar una nueva versión.
Por eso conviene distinguir el coste de inferencia, el de verificación y el de las iteraciones. En un despliegue local, esos componentes pueden corresponder a recursos distintos: la inferencia puede consumir GPU, mientras que el renderizado y algunos controles pueden utilizar CPU, memoria y navegador. El coste económico dependerá de cómo se asignen esos recursos y de la política de reintentos.
La documentación de AesCode describe el método y sus verificadores, pero no publica tarifas, latencias por verificación ni una tasa universal de éxito al primer intento. Las cifras de esta guía son variables para un cálculo propio, no mediciones de AesCode 8B. La evaluación agregada del proyecto tampoco equivale a la probabilidad de que una tarea particular supere todos los criterios de un producto.
Componentes del coste
Una estimación útil separa las fases del flujo en lugar de asignar un coste único a cada generación. La inferencia comprende el procesamiento del prompt y la producción de HTML y CSS. Su duración depende, entre otros factores, del hardware, la configuración del modelo, la longitud de la entrada y la cantidad de tokens generados.
La verificación descrita por el proyecto renderiza el HTML en un navegador Playwright y ejecuta comprobaciones deterministas. Entre las propiedades examinadas figuran la ejecución, el texto, los límites de los elementos, los datos de tablas y gráficos, el layout semántico y el espacio en blanco. El repositorio documenta el funcionamiento de estos controles, no su consumo de recursos ni su latencia por tarea.
La iteración aparece cuando el flujo requiere otra generación o una corrección después de detectar un fallo. No todos los equipos repiten el proceso de la misma manera: algunos fijan un máximo de intentos, otros corrigen solo el código y otros incorporan revisión humana. El coste medio depende de esa política, de los recursos utilizados en cada fase y de los resultados observados en tareas representativas.
Fases que conviene medir por separado
Esta clasificación ayuda a registrar el consumo por tarea. No es una medición publicada del coste de AesCode 8B.
| Fase | Recursos posibles | Qué registrar |
|---|---|---|
| Inferencia | GPU y memoria | Tiempo de generación, tokens de entrada y salida, y uso de recursos. |
| Verificación | CPU, memoria y navegador; según la configuración, otros recursos | Tiempo de renderizado y controles ejecutados en cada intento. |
| Iteración | Recursos de inferencia y verificación | Número de intentos, correcciones y recursos adicionales hasta la aceptación. |
Modelo de cálculo y supuestos
Para estimar el coste de inferencia por intento, se puede dividir el número de tokens generados por la velocidad efectiva de generación. El resultado es un tiempo aproximado. Si el coste de la GPU se expresa por hora, el tiempo puede convertirse a esa unidad y multiplicarse por la tarifa o el coste interno correspondiente. Esta aproximación no representa por sí sola toda la utilización del sistema, especialmente cuando hay solicitudes concurrentes o recursos compartidos.
La verificación debe valorarse según los recursos que realmente utiliza. Si Playwright y los verificadores consumen CPU, aplicarles sin más una tarifa horaria de GPU no refleja necesariamente su coste. Para una estimación más fiel, conviene medir y valorar cada tipo de recurso por separado. El ejemplo de código mantiene una tarifa común solo para ilustrar la estructura del cálculo.
El factor 1/p puede estimar el número medio de intentos únicamente bajo supuestos concretos: intentos independientes, probabilidad de éxito constante y repetición hasta alcanzar el éxito, sin un límite de reintentos. En esas condiciones, se calcula primero el coste conjunto de inferencia y verificación por intento y se aplica el factor esperado una sola vez. La tasa de éxito del primer intento, por sí sola, no demuestra que esos supuestos se cumplan. Si los intentos posteriores cambian de estrategia, coste o probabilidad, o si existe un máximo de intentos, el modelo debe adaptarse.
El código supone una probabilidad de éxito constante y una tarifa común para inferencia y verificación. Sustituye esa tarifa por los costes de los recursos realmente usados cuando difieran.
def calcular_tco(tokens_salida, tok_por_seg, coste_gpu_hora, t_verif_seg, tasa_exito):
if tok_por_seg <= 0 or coste_gpu_hora < 0 or t_verif_seg < 0:
raise ValueError("Los tiempos y costes deben ser válidos")
if not 0 < tasa_exito <= 1:
raise ValueError("tasa_exito debe estar entre 0 y 1")
t_inferencia = tokens_salida / tok_por_seg
coste_inferencia = (t_inferencia / 3600) * coste_gpu_hora
coste_verificacion = (t_verif_seg / 3600) * coste_gpu_hora
factor_iteracion = 1 / tasa_exito
return (coste_inferencia + coste_verificacion) * factor_iteracionEjemplo hipotético: 100 presentaciones
Supongamos, solo para ilustrar el cálculo, una salida media de 5.000 tokens generada a 50 tokens por segundo, una verificación de 10 segundos por intento y un coste de 2 USD por hora. El ejemplo aplica la misma tarifa a la inferencia y a la verificación para simplificar; no afirma que la verificación consuma GPU ni que esos valores correspondan a una instalación real de AesCode 8B.
Con esos supuestos, la inferencia dura 100 segundos y la verificación otros 10 segundos por intento. El coste conjunto es 110/3600 × 2 = 0,061111 USD por intento. Si, además, se supone una tasa de éxito del 80 %, intentos independientes, probabilidad constante y repetición sin límite hasta lograr la aceptación, el factor medio es 1/0,8 = 1,25. El coste estimado por tarea aceptada es, por tanto, 0,061111 × 1,25 = aproximadamente 0,076389 USD. Para 100 tareas, la estimación es 7,64 USD.
El ejemplo no es una tarifa ni un resultado medido. Cambiar la velocidad, la duración de la verificación, el coste de los recursos, la tasa de éxito o la política de reintentos cambia el resultado. La relación entre el coste esperado y la probabilidad de éxito es inversa bajo estos supuestos; no es un crecimiento exponencial.
Cómo obtener una estimación propia
Una estimación operativa debe basarse en el mismo hardware, configuración y flujo que se prevén para el despliegue. Antes de medir, define qué significa que una tarea está aceptada: por ejemplo, qué requisitos de contenido deben cumplirse y qué defectos visuales son motivo de rechazo. Sin criterios estables, la tasa de éxito no permite comparar configuraciones de manera consistente.
Registra por separado la inferencia, el renderizado y cada verificación. Para cada tarea, anota los tokens de entrada y salida, la duración y los recursos utilizados en cada intento, los fallos detectados y el número de reintentos. Si el flujo limita los intentos, permite correcciones parciales o requiere revisión humana, incorpora esas reglas en el cálculo en lugar de suponer que se repite el mismo proceso hasta el éxito.
Un conjunto de pruebas debe representar los prompts, imágenes de referencia y tipos de página que se esperan en la aplicación. Una prueba pequeña puede servir como primera aproximación, pero no convierte su tasa de éxito en una garantía para otras tareas. Las diferencias de complejidad, carga concurrente, configuración del navegador y hardware pueden cambiar tanto el tiempo como el coste.
Medición del coste en el entorno objetivo
Mantén constantes los criterios de aceptación durante la comparación y separa los datos observados de las hipótesis.
- 01Define los criterios de aceptación y la política de reintentos, incluido cualquier límite de intentos.
- 02Selecciona prompts representativos y las imágenes de referencia que se usarán en el flujo real.
- 03Ejecuta el modelo con el hardware y la configuración previstos para el despliegue.
- 04Registra por intento los tokens, el tiempo y los recursos de inferencia, además del tiempo y los recursos de verificación.
- 05Calcula la tasa de éxito al primer intento solo para el conjunto probado y con los criterios definidos.
- 06Actualiza el modelo de costes con las tarifas y mediciones del entorno, y comunica los supuestos junto a la estimación.
Alcance de los resultados y límites de la estimación
La evaluación publicada del proyecto informa resultados agregados para 300 muestras de infografías, con tres generaciones por prompt y sin selección entre generaciones. Esas métricas describen el rendimiento del benchmark y sus dimensiones de evaluación; no constituyen una tasa general de éxito al primer intento para cualquier aplicación, prompt o criterio de aceptación. Tampoco demuestran que una página que supera comprobaciones deterministas esté lista para entregar sin revisión visual.
El repositorio describe el renderizado con Playwright y seis verificadores deterministas, además de canales de evaluación visual. No publica el coste ni la duración de cada verificación, el consumo de CPU o GPU por tarea, ni una tasa universal de éxito inicial. La configuración usada en una evaluación tampoco permite deducir por sí sola la memoria necesaria o el rendimiento en un hardware distinto.
Por tanto, el resultado del cálculo debe leerse como una estimación condicionada por las mediciones y supuestos elegidos. Separar los costes de GPU y CPU, explicitar la política de reintentos y usar criterios de aceptación reproducibles ayuda a comparar despliegues; no garantiza que el coste o la calidad se mantengan al cambiar el hardware, la carga o los prompts.
Continúa explorando
Correcciones y transparencia
Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.
Proponer una corrección