TOON vs JSON:现实检验 — 何时节省 token,何时不节省
Source: Dev.to
介绍
最近出现了一波关于 TOON(Token‑Oriented Object Notation)的文章,很多文章宣称它能节省 “50 % 令牌”,甚至称 JSON 对 LLM 应用已经“过时”。在实际数字分析后,结论很明确:
- TOON 确实有用,但营销宣传过于简化了现实。
- “50 % 节省” 的数据通常是相对于 格式化(美化)JSON,而不是实际发送给 LLM 的 压缩(minified)JSON。
如果以压缩 JSON——真实的基准——进行比较,情况会有很大不同。
令牌节省概览
| 数据类型(相对于压缩 JSON) | 典型令牌影响 |
|---|---|
| 均匀数组(用户列表、日志) | 20 %–35 % 节省 – 这是 TOON 的强项 |
| 带数组的 API 响应 | 0 %–15 % 节省 – 改进有限 |
| 混合嵌套结构 | ‑5 % 到 +10 % – 结果各异;请自行测试数据 |
| 配置对象 | +10 % 到 +20 % 更多令牌 – TOON 在这里会增加开销 |
| 深度嵌套对象 | +15 % 到 +20 % 更多令牌 – TOON 在这里会增加开销 |
| 单一平面对象 | ‑5 % 到 +5 % – 差别不大 |
关键要点: 根据数据结构的不同,TOON 甚至可能使令牌使用量增加 15‑20 %。
TOON 如何节省令牌
TOON 在头部声明字段名一次,然后对 均匀数组 以 CSV‑类似的行流式写入值。
users[3]{id,name,role}:
1,Alice,admin
2,Bob,user
3,Carol,user
等价的压缩 JSON
{"users":[{"id":1,"name":"Alice","role":"admin"},{"id":2,"name":"Bob","role":"user"},{"id":3,"name":"Carol","role":"user"}]}
节省的来源在于不必为每条记录重复 "id":、"name":、"role":。当记录数达到 100 条时,令牌减少会非常显著。
当 TOON 效率下降时
对于非表格化数据,TOON 会退回到类似 YAML 的缩进方式,这往往比压缩 JSON 更冗长,因为:
- 空白(缩进)会消耗令牌。
- 键仍然会在每个嵌套对象中重复。
- 小对象的开销比 JSON 那种紧凑的大括号更大。
示例:配置对象
压缩 JSON
{"debug":true,"maxRetries":3,"timeout":5000,"features":{"darkMode":true,"beta":false}}
TOON 表示
debug: true
maxRetries: 3
timeout: 5000
features:
darkMode: true
beta: false
压缩 JSON 更省令牌,因为它没有换行或缩进,且标点符号已经最小化。
实用指南:何时使用哪种格式
何时使用 TOON
- 你拥有 大量均匀对象数组(≈ 100 条以上且字段一致)。
- 数据主要是 表格化 的(用户列表、商品目录、日志条目、分析数据)。
- 数组中的每个对象共享相同字段。
何时使用 JSON(压缩)
- 处理 带有元数据的分页 API 结果。
- 数据具有 深度嵌套(组织结构图、递归树)。
- 发送 配置对象 或功能标志。
- 对象的 字段不一致(稀疏数据)。
- 结构 混合(既有数组又有嵌套对象)。
- 处理 单一平面对象。
考虑使用纯 CSV 当
- 数据 纯粹表格化且无层级。
- 需要 最大令牌效率(CSV 对平面表格的节省约为 TOON 的 ~30 %)。
YAML 与 JSON 与 TOON 对比
- YAML 通常是最差的令牌效率选择,使用的令牌比压缩 JSON 多约 21 %,因为空白有意义且键会在每个数组项中重复。
- JSON 对大多数嵌套或混合结构仍是最紧凑的。
- TOON 为 JSON 所缺乏的 表格化优化 提供了可能,但仅在数据符合该模式时才有效。
LLM 兼容性考虑
- 大多数 LLM 主要在 JSON 上进行训练。
- 使用 TOON 往往需要在提示中加入 格式说明,这会部分抵消令牌节省。
- 小模型(如
gpt‑3.5‑turbo)有时即使理解 TOON 输入,也会在输出有效 TOON 时出现困难。 - TOON 缺乏 RFC 级别的标准;实现可能各不相同,使得 调试比 JSON 更困难。
- 现有工具、日志记录器和验证器默认期待 JSON,因而引入 TOON 会增加摩擦。
实际 API 响应示例
{"total":150,"page":1,"users":[...]}
只有 users 数组可以从 TOON 优化中受益;外围的元数据(total、page)则没有。对这些小型元数据对象使用 TOON 的格式声明实际上可能 增加总令牌数。
建议
- 使用真实数据进行测试 – 将生产负载粘贴到转换器(例如 json2toon.de)中,比较令牌数量。
- 始终以压缩 JSON 为基准,而不是美化 JSON。
- 对你的具体结构进行画像 – 均匀数组能省令牌,配置对象则不能。
- 在令牌计算中加入任何格式说明提示。
- 验证 LLM 的理解能力 – 确保目标模型能够可靠地解析和生成 TOON。
结论
- 均匀数组 → TOON(20‑35 % 令牌节省)。
- 平面表格数据 → CSV(最高约 ~30 % 节省)。
- 其他所有情况 → 压缩 JSON(最省令牌且兼容性最高)。
不要让 hype 主导你的架构决策。测量你的具体使用场景,了解权衡,并选择真正能为你的工作负载最小化令牌使用的格式。
构建了 json2toon.de 来帮助开发者做基于数据的格式决策。用你的真实负载试一试,看看实际数字。