系列第 8 篇 · 反直觉优化✅本文性质说明token 数、prefill 延迟、问答正确率全部本机真跑Qwen2.5-0.5B-Instruct纯 NumPy CPU脚本eng_repr_tokens.py给全。成本金额是「本机实测 token 数 × 公开挂牌单价假设」的外推单价已标注为假设值。Skyvern 生产 A/B 的成功率数据作为外部佐证单独标注。一句话结论同一份订单数据只改写法不改内容喂给模型的开销差得离谱——而且省下的比例随数据量变大还在涨明细条数JSONHTMLHTML 省MarkdownMD 省1775824.7%4344.2%31389928.3%7347.1%1035124231.1%18048.7%3094063132.9%47449.6%但省 token 不等于能用。同一批问题问下来JSON 3/3、HTML 3/3、Markdown 2/3——最省的 Markdown 答错了一题。HTML 是甜点位省 33% token、prefill 快 19%、正确率和 JSON 打平。背景与痛点JSON 是默认选项也是最贵的选项给模型喂结构化数据几乎所有人第一反应是json.dumps()。问题是 JSON 为机器解析设计不为 token 效率设计每个字段名都要重复一遍加上引号、冒号、逗号、缩进——这些标点税你按 token 付费。以 30 条明细的订单为例JSON 里name、qty、price这三个键各重复 30 次光键名就烧掉几百个 token而它们没有携带任何信息——第一次出现就够了。核心方法三种表征怎么权衡同一份订单三种写法# JSON字段名逐条重复标点最多 { order_id: A1024, customer: 张三, items: [ {name: 机械键盘, qty: 1, price: 399.0}, {name: 鼠标垫, qty: 2, price: 29.9} ], total: 458.8, status: paid } # HTML/XML属性紧凑键名仍在但没有引号税缩进税模型预训练见得极多 order idA1024 statuspaid customer张三/customer item name机械键盘 qty1 price399.0/ item name鼠标垫 qty2 price29.9/ total458.8/total /order # Markdown最省但字段语义被压平成自然语言 # 订单 A1024 (paid) - 客户张三 - 机械键盘 x1 399.0 - 鼠标垫 x2 29.9 - 合计458.8判断维度三个信息密度同内容多少 token、模型熟悉度预训练分布里见过多少、字段保真度键值对应关系是否还在。JSON 保真度最高但最贵Markdown 最便宜但把status: paid压成了标题里的(paid)HTML 两头都不吃亏。实验与数字本机真跑2026-08-19复现命令python eng_repr_tokens.py # A: token 规模扫描 B: 理解力探针环境Qwen2.5-0.5B-Instruct纯 NumPy CPU 推理引擎本系列第 3 篇那套模型加载 1.3s全程 94s。① token 规模扫描省的比例会放大关键代码——用真 tokenizer 数不用字符数估def ntok(s): 内容 token 数去掉 encode() 自动加的 BOS避免虚增 return len(eng.encode(s)) - 1 for n in (1, 3, 10, 30): js, ht, md, _ build(n) # 同一份数据的三种序列化 tj, th, tm ntok(js), ntok(ht), ntok(md) print(n, tj, th, f{(1-th/tj)*100:.1f}%, tm, f{(1-tm/tj)*100:.1f}%)结果就是开头那张表。HTML 的节省从 24.7% 涨到 32.9%Markdown 从 44.2% 涨到 49.6%。为什么会涨因为固定开销order_id、customer、total、status这些只出现一次的字段被摊薄了而逐条重复的键名开销随条数线性增长——JSON 越长冗余占比越高。这个规律很实用你的 payload 越大这个优化越值得做。反过来说小 payload 上测出来才省 24%不要据此判断它不划算。② 成本外推token 实测单价为假设按 30 条明细、100 万次调用、输入单价$0.15 / 1M token假设值非本机产出表征token/次100 万次成本JSON940$141HTML631$95Markdown474$71仅 JSON→HTML 这一项省$46。这里的重点不是绝对金额单价随模型和厂商差几十倍而是比例结构不换模型、不裁数据、不动 prompt 逻辑只改序列化函数账单直接砍三分之一。③ 理解力探针Markdown 翻车了省 token 的前提是模型还读得懂。我用官方 chat 模板问了三个只能从数据里读出的问题表征prompt token客户名字订单状态鼠标垫数量答对JSON182张三✅paid✅2✅3/3HTML143张三✅paid✅2✅3/3Markdown118张三✅已支付❌2✅2/3Markdown 那一题很有意思它并没有不知道而是答了已支付。数据里paid被我压进了标题# 订单 A1024 (paid)失去了status: paid这种显式键值绑定模型于是把它当自然语言意译了。这就是保真度损失的真实形态不是幻觉不是漏读而是字段值被改写成语义等价但字符串不等的东西。如果下游代码要if status paid这条链就断了——而且断得很隐蔽因为答案看起来是对的。④ 附带发现prefill 延迟跟着 token 一起降每题的实际生成耗时纯 CPUprefill 占主导表征三题耗时平均相对 JSONJSON12.3s / 12.7s / 12.8s12.60s—HTML10.1s / 10.2s / 10.2s10.17s-19.3%Markdown8.3s / 8.3s / 8.2s8.27s-34.4%省 token 是双重收益账单降首 token 延迟也降。这条和第 2 篇首 token 延迟拆解直接呼应——prefill 成本正比于输入长度砍输入就是砍 TTFT比改推理参数省事得多。⑤ 外部佐证Skyvern 生产 A/B指标JSONHTML变化单任务成本$1.22$1.08-11.4%成功率59.9%63.8%3.9%来源Skyvern 生产 A/B 报告2026-06约 1,100 个真实任务。他们的成本降幅11.4%小于我本机的 token 降幅33%合理——真实请求里还有 system prompt、历史消息、输出 token 等不受表征影响的固定部分。而成功率反升 3.9%和我本机 HTML 打平 JSON 的结果同向HTML 更贴近模型预训练分布噪声更少。至少可以说省 token 不必然牺牲质量。为什么重要这是极少数纯赚的优化成本↓、延迟↓、质量不降。不像量化省显存但掉精度或换小模型省钱但掉能力那样要做权衡。改动量小到离谱动的是序列化函数几十行不碰模型、不碰 prompt 逻辑、不碰架构。payload 越大越划算而生产里的 payload 通常比 demo 大得多——demo 上测出 24%生产可能是 33%。呼应第 1 篇账单砍 79%降本的杠杆多数不在模型上在你怎么喂它。反过来给了个警告别无脑上 Markdown。它最省但会压平字段语义对需要精确字段值的下游是隐性风险。读者可复用交付物表征格式选型决策表先问一句下游要不要按字段精确取值 要写库 / 走 if 判断 / 触发流程 └─ 优先 HTML/XML 标签表征 · 键值绑定完整namex qty1 · 省 25-33% token量越大省越多 · 本机实测正确率与 JSON 持平 3/3 └─ 必须 JSON 的唯一场景你要把模型输出直接 json.loads() 输入用 HTML、输出要 JSON —— 这两件事可以分开定 不要摘要 / 分类 / 问答 / 语义检索 └─ 用 Markdown省 44-50% · 但字段值可能被意译paid → 已支付 · 只要下游不做字符串精确比较就无所谓 落地检查清单 □ 用真 tokenizer 数 token别用 len(str)/4 估 □ 在你的真实 payload 规模上测别用 1 条 demo 测 □ 换格式后必须跑正确率回归至少 20 题别只看 token 降了就上线 □ 重点回归精确字段值类问题状态码、枚举、ID、金额 □ 输入表征和输出格式解耦输入 HTML 省钱输出仍可要求 JSON □ 长列表数据优先 HTML/MD单条小对象差异不大不用折腾踩坑记录复现时会遇到encode()不认特殊 tokenchat 模板必须手拼 ID。本系列踩过的老坑|im_start|走 BPE 会被切成碎片。必须直接拼151644/151645python def chat_ids(system, user): enc lambda t: eng.encode(t)[1:] # 去掉自动 BOS ids [IM_START] enc(system\n system) [IM_END] enc(\n) ids [IM_START] enc(user\n user) [IM_END] enc(\n) ids [IM_START] enc(assistant\n) return ids只解码新生成的 token。如果 decode 整个prompt gen模型会把整段输入回显进答案于是关键词永远命中正确率假性 100%。第 10 篇的注入实验就是这么被坑过一次。数 token 要减掉 BOS。encode()会自动加一个 BOS三种表征各加 1 个比例算出来会被稀释。早期我那版没减同一份数据得到 95/78/59省 17.9%减掉后是 94/77/58省 18.1%——小 payload 上这个误差不能忽略。别用字符数或len(text)/4估 token。中文场景下这个经验公式误差极大Markdown 的字符数比 HTML 少得有限但 token 少得多因为中文词在 tokenizer 里的切分和标点完全不是一个量级。HTML 表征别真去塞完整网页 DOM。省 token 的是标签化的紧凑表征不是原始 HTML——真实 DOM 里的class、style、data-*属性比 JSON 还冗余。手工构造语义标签或先做 DOM 精简。今日可做的 3 件事找到你最高频的那个 LLM 调用把输入的json.dumps()换成标签表征用真 tokenizer 数一下前后 token10 分钟的事。按你真实 payload 的最大规模再测一遍。小样本会低估收益——我这儿 1 条时省 24.7%30 条时省 32.9%。跑一次正确率回归专门挑精确字段值的问题状态、枚举、ID。如果你打算用 Markdown这一步是必须的——我这儿正是在status上翻的车。下篇预告第 9 篇函数调用真跑——0.5B 调工具比 1.5B 还准我拿 12 个真实场景本机真跑了一遍。系列终篇10 篇汇总在 09、10 之后。本文数据来源本机真跑eng_repr_tokens.py2026-08-19Qwen2.5-0.5B-Instruct 纯 NumPy CPUtoken 规模扫描1/3/10/30 条明细HTML 省 24.7%→32.9%MD 省 44.2%→49.6%理解力探针JSON 3/3、HTML 3/3、Markdown 2/3status被意译为「已支付」prefill 延迟JSON 12.60s / HTML 10.17s-19.3%/ MD 8.27s-34.4%原始结果存eng_repr_tokens.json成本外推token 数为本机实测输入单价 $0.15/1M token 为公开挂牌价假设值非本机产出外部佐证引用Skyvern 生产 A/B 报告2026-06约 1,100 任务——单任务成本 $1.22→$1.08-11.4%、成功率 59.9%→63.8%3.9% 表征格式实测：JSON 换 HTML 省 33% token 且质量不掉，Markdown 最省却答错
系列第 8 篇 · 反直觉优化✅本文性质说明token 数、prefill 延迟、问答正确率全部本机真跑Qwen2.5-0.5B-Instruct纯 NumPy CPU脚本eng_repr_tokens.py给全。成本金额是「本机实测 token 数 × 公开挂牌单价假设」的外推单价已标注为假设值。Skyvern 生产 A/B 的成功率数据作为外部佐证单独标注。一句话结论同一份订单数据只改写法不改内容喂给模型的开销差得离谱——而且省下的比例随数据量变大还在涨明细条数JSONHTMLHTML 省MarkdownMD 省1775824.7%4344.2%31389928.3%7347.1%1035124231.1%18048.7%3094063132.9%47449.6%但省 token 不等于能用。同一批问题问下来JSON 3/3、HTML 3/3、Markdown 2/3——最省的 Markdown 答错了一题。HTML 是甜点位省 33% token、prefill 快 19%、正确率和 JSON 打平。背景与痛点JSON 是默认选项也是最贵的选项给模型喂结构化数据几乎所有人第一反应是json.dumps()。问题是 JSON 为机器解析设计不为 token 效率设计每个字段名都要重复一遍加上引号、冒号、逗号、缩进——这些标点税你按 token 付费。以 30 条明细的订单为例JSON 里name、qty、price这三个键各重复 30 次光键名就烧掉几百个 token而它们没有携带任何信息——第一次出现就够了。核心方法三种表征怎么权衡同一份订单三种写法# JSON字段名逐条重复标点最多 { order_id: A1024, customer: 张三, items: [ {name: 机械键盘, qty: 1, price: 399.0}, {name: 鼠标垫, qty: 2, price: 29.9} ], total: 458.8, status: paid } # HTML/XML属性紧凑键名仍在但没有引号税缩进税模型预训练见得极多 order idA1024 statuspaid customer张三/customer item name机械键盘 qty1 price399.0/ item name鼠标垫 qty2 price29.9/ total458.8/total /order # Markdown最省但字段语义被压平成自然语言 # 订单 A1024 (paid) - 客户张三 - 机械键盘 x1 399.0 - 鼠标垫 x2 29.9 - 合计458.8判断维度三个信息密度同内容多少 token、模型熟悉度预训练分布里见过多少、字段保真度键值对应关系是否还在。JSON 保真度最高但最贵Markdown 最便宜但把status: paid压成了标题里的(paid)HTML 两头都不吃亏。实验与数字本机真跑2026-08-19复现命令python eng_repr_tokens.py # A: token 规模扫描 B: 理解力探针环境Qwen2.5-0.5B-Instruct纯 NumPy CPU 推理引擎本系列第 3 篇那套模型加载 1.3s全程 94s。① token 规模扫描省的比例会放大关键代码——用真 tokenizer 数不用字符数估def ntok(s): 内容 token 数去掉 encode() 自动加的 BOS避免虚增 return len(eng.encode(s)) - 1 for n in (1, 3, 10, 30): js, ht, md, _ build(n) # 同一份数据的三种序列化 tj, th, tm ntok(js), ntok(ht), ntok(md) print(n, tj, th, f{(1-th/tj)*100:.1f}%, tm, f{(1-tm/tj)*100:.1f}%)结果就是开头那张表。HTML 的节省从 24.7% 涨到 32.9%Markdown 从 44.2% 涨到 49.6%。为什么会涨因为固定开销order_id、customer、total、status这些只出现一次的字段被摊薄了而逐条重复的键名开销随条数线性增长——JSON 越长冗余占比越高。这个规律很实用你的 payload 越大这个优化越值得做。反过来说小 payload 上测出来才省 24%不要据此判断它不划算。② 成本外推token 实测单价为假设按 30 条明细、100 万次调用、输入单价$0.15 / 1M token假设值非本机产出表征token/次100 万次成本JSON940$141HTML631$95Markdown474$71仅 JSON→HTML 这一项省$46。这里的重点不是绝对金额单价随模型和厂商差几十倍而是比例结构不换模型、不裁数据、不动 prompt 逻辑只改序列化函数账单直接砍三分之一。③ 理解力探针Markdown 翻车了省 token 的前提是模型还读得懂。我用官方 chat 模板问了三个只能从数据里读出的问题表征prompt token客户名字订单状态鼠标垫数量答对JSON182张三✅paid✅2✅3/3HTML143张三✅paid✅2✅3/3Markdown118张三✅已支付❌2✅2/3Markdown 那一题很有意思它并没有不知道而是答了已支付。数据里paid被我压进了标题# 订单 A1024 (paid)失去了status: paid这种显式键值绑定模型于是把它当自然语言意译了。这就是保真度损失的真实形态不是幻觉不是漏读而是字段值被改写成语义等价但字符串不等的东西。如果下游代码要if status paid这条链就断了——而且断得很隐蔽因为答案看起来是对的。④ 附带发现prefill 延迟跟着 token 一起降每题的实际生成耗时纯 CPUprefill 占主导表征三题耗时平均相对 JSONJSON12.3s / 12.7s / 12.8s12.60s—HTML10.1s / 10.2s / 10.2s10.17s-19.3%Markdown8.3s / 8.3s / 8.2s8.27s-34.4%省 token 是双重收益账单降首 token 延迟也降。这条和第 2 篇首 token 延迟拆解直接呼应——prefill 成本正比于输入长度砍输入就是砍 TTFT比改推理参数省事得多。⑤ 外部佐证Skyvern 生产 A/B指标JSONHTML变化单任务成本$1.22$1.08-11.4%成功率59.9%63.8%3.9%来源Skyvern 生产 A/B 报告2026-06约 1,100 个真实任务。他们的成本降幅11.4%小于我本机的 token 降幅33%合理——真实请求里还有 system prompt、历史消息、输出 token 等不受表征影响的固定部分。而成功率反升 3.9%和我本机 HTML 打平 JSON 的结果同向HTML 更贴近模型预训练分布噪声更少。至少可以说省 token 不必然牺牲质量。为什么重要这是极少数纯赚的优化成本↓、延迟↓、质量不降。不像量化省显存但掉精度或换小模型省钱但掉能力那样要做权衡。改动量小到离谱动的是序列化函数几十行不碰模型、不碰 prompt 逻辑、不碰架构。payload 越大越划算而生产里的 payload 通常比 demo 大得多——demo 上测出 24%生产可能是 33%。呼应第 1 篇账单砍 79%降本的杠杆多数不在模型上在你怎么喂它。反过来给了个警告别无脑上 Markdown。它最省但会压平字段语义对需要精确字段值的下游是隐性风险。读者可复用交付物表征格式选型决策表先问一句下游要不要按字段精确取值 要写库 / 走 if 判断 / 触发流程 └─ 优先 HTML/XML 标签表征 · 键值绑定完整namex qty1 · 省 25-33% token量越大省越多 · 本机实测正确率与 JSON 持平 3/3 └─ 必须 JSON 的唯一场景你要把模型输出直接 json.loads() 输入用 HTML、输出要 JSON —— 这两件事可以分开定 不要摘要 / 分类 / 问答 / 语义检索 └─ 用 Markdown省 44-50% · 但字段值可能被意译paid → 已支付 · 只要下游不做字符串精确比较就无所谓 落地检查清单 □ 用真 tokenizer 数 token别用 len(str)/4 估 □ 在你的真实 payload 规模上测别用 1 条 demo 测 □ 换格式后必须跑正确率回归至少 20 题别只看 token 降了就上线 □ 重点回归精确字段值类问题状态码、枚举、ID、金额 □ 输入表征和输出格式解耦输入 HTML 省钱输出仍可要求 JSON □ 长列表数据优先 HTML/MD单条小对象差异不大不用折腾踩坑记录复现时会遇到encode()不认特殊 tokenchat 模板必须手拼 ID。本系列踩过的老坑|im_start|走 BPE 会被切成碎片。必须直接拼151644/151645python def chat_ids(system, user): enc lambda t: eng.encode(t)[1:] # 去掉自动 BOS ids [IM_START] enc(system\n system) [IM_END] enc(\n) ids [IM_START] enc(user\n user) [IM_END] enc(\n) ids [IM_START] enc(assistant\n) return ids只解码新生成的 token。如果 decode 整个prompt gen模型会把整段输入回显进答案于是关键词永远命中正确率假性 100%。第 10 篇的注入实验就是这么被坑过一次。数 token 要减掉 BOS。encode()会自动加一个 BOS三种表征各加 1 个比例算出来会被稀释。早期我那版没减同一份数据得到 95/78/59省 17.9%减掉后是 94/77/58省 18.1%——小 payload 上这个误差不能忽略。别用字符数或len(text)/4估 token。中文场景下这个经验公式误差极大Markdown 的字符数比 HTML 少得有限但 token 少得多因为中文词在 tokenizer 里的切分和标点完全不是一个量级。HTML 表征别真去塞完整网页 DOM。省 token 的是标签化的紧凑表征不是原始 HTML——真实 DOM 里的class、style、data-*属性比 JSON 还冗余。手工构造语义标签或先做 DOM 精简。今日可做的 3 件事找到你最高频的那个 LLM 调用把输入的json.dumps()换成标签表征用真 tokenizer 数一下前后 token10 分钟的事。按你真实 payload 的最大规模再测一遍。小样本会低估收益——我这儿 1 条时省 24.7%30 条时省 32.9%。跑一次正确率回归专门挑精确字段值的问题状态、枚举、ID。如果你打算用 Markdown这一步是必须的——我这儿正是在status上翻的车。下篇预告第 9 篇函数调用真跑——0.5B 调工具比 1.5B 还准我拿 12 个真实场景本机真跑了一遍。系列终篇10 篇汇总在 09、10 之后。本文数据来源本机真跑eng_repr_tokens.py2026-08-19Qwen2.5-0.5B-Instruct 纯 NumPy CPUtoken 规模扫描1/3/10/30 条明细HTML 省 24.7%→32.9%MD 省 44.2%→49.6%理解力探针JSON 3/3、HTML 3/3、Markdown 2/3status被意译为「已支付」prefill 延迟JSON 12.60s / HTML 10.17s-19.3%/ MD 8.27s-34.4%原始结果存eng_repr_tokens.json成本外推token 数为本机实测输入单价 $0.15/1M token 为公开挂牌价假设值非本机产出外部佐证引用Skyvern 生产 A/B 报告2026-06约 1,100 任务——单任务成本 $1.22→$1.08-11.4%、成功率 59.9%→63.8%3.9%