Skip to content Skip to sidebar Skip to footer

¿Menos tokens con TOON?

Lo medimos. Los datos dicen otra cosa.

Autor

Ing. César Augusto Cerón — Data Intelligence

Publicado por

IPCOM Labs

Lectura estimada

6 minutos

La premisa que queríamos que fuera verdad.

En arquitecturas donde los LLMs consumen datos estructurados — contextos de agente, payloads de herramientas, respuestas de API — el número de tokens no es un detalle técnico menor. Es coste directo y latencia medible. Por eso cuando apareció TOON, un formato de serialización diseñado explícitamente para reducir tokens, el equipo lo tomó en serio.

Lo pusimos a prueba. Benchmark riguroso, datasets controlados, seis tokenizadores. La conclusión no es la que esperábamos — y eso es exactamente por qué vale la pena publicarla.

Diseño del experimento.

Formatos evaluados.

Comparamos cuatro formatos de serialización con soporte real para estructuras jerárquicas:

Formato

Estructura

Jerarquía

Orientado a tabla

JSON

Objetos { } y arrays [ ]

No

Pretty JSON

Objetos {} con indentación

No

CSV

Filas y columnas

No

TOON

Bloques key:value propios

No

Tokenizadores.

Usamos seis: cl100k_base y o200k_base de OpenAI (tiktoken), más TinyLlama, Phi-2, GPT-2 y DistilBERT de HuggingFace. La intención era detectar si la eficiencia de TOON dependía del vocabulario del modelo — una hipótesis razonable que resultó irrelevante por otras razones.

Datasets.

Dataset

Profundidad

Campos

Registros

Total llaves

SMALL

0

5

10

50

MEDIUM

1

10

10.000

~100.000

LARGE

2

15

100.000

~200.000

DEEP

10

30

10.000

~400.000

Lo que encontramos.

Tamaño de archivo.

TOON produce archivos más grandes que JSON en todos los datasets excepto SMALL, donde la diferencia (304 bytes vs. 643) es demasiado pequeña para ser operacionalmente relevante. En datasets profundos, la penalidad de tamaño de TOON se amplifica con la profundidad de anidación. CSV sigue siendo el más compacto, pero al precio de perder toda capacidad de representar estructuras jerárquicas.

Con compresión gzip, todos los formatos se reducen entre 65% y 85%. Las diferencias se achican, pero TOON no invierte la tendencia: sigue siendo el más voluminoso después de la compresión.

Tiempos de serialización.

Aquí la diferencia es estructural:

×17

más lento que JSON en MEDIUM

×20

más lento que JSON en DEEP

×30

más lento al deserializar en SMALL

×22

más lento al deserializar en MEDIUM

JSON es consistentemente el más rápido. CSV es competitivo en lectura. TOON es sistemáticamente el peor en serialización y deserialización, y la penalidad crece con el tamaño y la profundidad del dataset. No es una diferencia de implementación que se pueda optimizar fácilmente; es el coste del esquema de representación elegido.

Nuestra conclusión.

TOON puede reducir tokens en datasets pequeños y planos. En cualquier otro escenario, los costes de tamaño y tiempo superan ese beneficio. JSON sigue siendo el estándar correcto para producción.

Para los que trabajan con LLMs en contextos de agente o herramientas de MCP, la implicación es directa: la optimización de tokens no está en el formato de serialización sino en el diseño del esquema, la selección de campos y la compresión de contexto a nivel semántico. Cambiar JSON por TOON no es el atajo que parecía.

¿Cuándo TOON sí tiene sentido?

  • Datasets pequeños (decenas de registros) con prioridad explícita de minimizar tokens.
  • Sistemas donde serialización y deserialización no están en el camino crítico de rendimiento.
  • Prototipos o escenarios de investigación donde se quiere explorar el espacio de representación.

En todos los demás casos: JSON con compresión gzip si el volumen lo justifica.

¿Por qué publicamos esto?

Porque el valor de un benchmark no está solo en confirmar lo que uno espera. Está en ahorrarle a otros el tiempo de hacer la misma prueba. El equipo de Data Intelligence de IPCOM hace este tipo de investigación aplicada de forma sistemática — sobre formatos, sobre métricas, sobre arquitecturas. IPCOM Labs es el canal donde eso sale del SharePoint interno y llega a quienes lo pueden usar.

Si trabajas con LLMs en producción y tienes preguntas sobre el diseño del experimento o los datos completos, estamos disponibles en los comentarios.

Go to Top