在实际的大模型应用开发中token 消耗往往不是模型能力的瓶颈而是成本与响应速度的瓶颈。围绕这个痛点一种名为 Semantic Thermodynamics语义热力学的优化思路开始被不少团队讨论通过给生成过程添加叙事约束把模型原本可能发散的语言空间收拢到一条相对明确的故事线上从而显著压缩输出 token。这种思路不依赖模型微调也不更换更小参数量模型只调整 Prompt 结构就能在不少场景里达到 60% 以上的 token 削减输入材料里提到的 79% 是一个很典型的优化目标但具体数值需要在自己数据集上复测。这篇文章会把语义热力学的基本原理、可复用的 Prompt 模板、对比实验方法、结果统计方式和常见坑完整讲清楚。1. 语义热力学到底在优化什么1.1 从 token 开销说起LLM 调用成本基本由两段组成输入侧的 prompt token 和输出侧的 completion token。很多项目在优化成本时首先看输入侧反复压缩系统提示词、缩短历史消息却忽略了一个事实输出 token 才是真正拖慢响应、拉高按量计费成本的主要原因。一次用户请求如果模型返回 2000 token那么即使输入 prompt 只有 500 token生成阶段的开销也占了绝大部分。在实际系统里输出 token 失控通常表现为模型把一句话能讲完的内容展开成三段没有限制风格时写了一堆客套话需要结构化 JSON 时额外输出解释文字模型在某个问题上不确定时反复绕圈子。这些现象本质上都是同一个问题生成空间太大模型缺乏足够的约束条件来提前知道该在什么地方停笔。语义热力学正是从这个角度切入它不追求把所有知识塞进 Prompt而是用一组叙事约束把模型的输出空间限制在一个明确的语义扇区内。这里的“热力学”是类比指的是语言生成过程中的不确定性可以看作一种系统熵约束条件越多系统越有序模型需要探索的 token 路径就越短。1.2 叙事约束到底是什么叙事约束narrative constraints不是简单的“把字数限制成 200 字”。它是一组关于生成内容的语义边界通常包含以下几个维度角色身份模型在本次回答里是谁站在什么立场说话。事件脉络回答必须按什么顺序展开先讲结论还是先讲背景。语言风格用口语还是书面语是否需要比喻是否允许解释数理推导。输出格式必须输出 JSON、Markdown、纯文本还是只输出结论。禁止事项哪些话不能说哪些内容不要展开哪些场景不需要解释。结束条件什么时候必须停止补充哪些话不需要收尾。可以把叙事约束理解成给模型发的“剧本”。没有剧本时模型像一个自由发挥的演员会试讲很多句才进入正题有了剧本之后模型知道自己在第几幕、做哪些动作、说哪些词冗余自然减少。例如同样是回答“MySQL 中的索引为什么能提高查询速度”不加约束时模型可能从数据库管理系统讲起再讲 B 树再讲磁盘 IO甚至解释回表。添加叙事约束后角色是“只懂 MySQL 的 DBA”脉络是“先给结论再说一条生效原因最后给一个反例”语言风格是“每句不超过 30 字”。模型的输出会明显收敛。1.3 叙事约束为什么能减少输出 token核心原因是它同时压缩了模型在多个层的选择空间。第一语义层被收窄。模型的解码过程本质是为每个 token 选择下一个高概率 token。叙事约束会显著影响 attention 分布让模型更倾向于顺着某条语义链走而不是在每个位置都重新“犹豫”。语义上的自由度降低后模型生成的平均 token 数会下降。第二结构层被固定。如果约束强制要求先结论后解释模型就很少再写一遍背景铺垫。输出格式如果要求只给 JSON模型就不会把解释文字放在 JSON 外这能直接砍掉大量样板文本。第三结束条件更明确。很多多余 token 来自“想把话说完整”的惯性。当约束里有明确的结束标志例如“示例说完后立即结束不要写总结”模型会在目标达成后更果断地停止生成。这里还要区分两个容易混淆的手段降低 temperature 也能减少输出发散但它的作用集中在概率分布上会让结果变得更保守也可能导致输出质量下降。叙事约束属于语义级控制它不改变温度却能告诉模型“哪些路不要走”两者可以结合使用。下面用一张表整理常见约束类型和它们主要削减的 token 类型约束类型典型描述主要削减的 token角色约束你是一名支持工程师用户不是开发人员背景介绍、术语展开结论前置第一句直接给结论开头铺垫、过渡句结构化格式只返回 JSON不要解释JSON 前后的说明文字禁止展开不要解释技术原理原理段落、推论字数上限每条理由不超过 30 字重复赘述结束条件回答完示例后立即结束总结段、客套话语气约束使用短句不要使用形容词修饰性短语这组约束说到底是把“无界生成”变成“有界生成”。理解这一点后后续实验设计就有了方向。2. 实验环境准备用 OpenAI 兼容接口做可控对比2.1 环境要求要验证叙事约束对 token 消耗的影响不一定需要本地 GPU也可以使用各类 OpenAI 兼容 API。为了便于复现建议准备一个 Python 3.10 以上环境、一个 OpenAI 风格的接口地址和 API Key。若本机没有独立模型也可以使用本地推理服务。实验的最小环境清单如下项目建议值说明Python3.10类型注解和 pydantic 支持较好requests2.31用于调用 HTTP 接口openai1.x使用 SDK 简化请求tiktoken0.5本地估算 token 数便于快速统计模型任意 OpenAI 兼容对话模型需要支持 messages 接口学习环境不需要做太多配置找到 API 地址和 Key 即可。生产环境则要多加一层鉴权、日志、超时和熔断后面会专门说明。2.2 安装依赖创建一个实验目录并初始化虚拟环境mkdir semantic-thermo-demo cd semantic-thermo-demo python -m venv venv source venv/bin/activate pip install openai requests tiktoken安装完成后确认版本python -c import openai; print(openai.__version__)这里选择 openai 1.x SDK是因为多数兼容服务都实现了/v1/chat/completions接口使用统一客户端可以减少接入成本。如果使用的服务兼容旧版接口仍可以通过base_url指向实际地址。2.3 实验任务设计实验要做的是“同一任务两种 Prompt对比输出 token”。因此任务本身必须有足够大的自由发挥空间否则约束前后的差别看不出来。推荐选择这类任务写一份活动策划说明、解释某个技术术语、给一段营销文案写三条标题、把需求描述转换成一段可执行的接口说明。这些任务如果完全放开模型往往写得很长添加叙事约束后又可以收敛到很短。下面统一以一个任务为例“用 3 条要点说明为什么数据库索引能提高查询速度”。这个任务简单适合观察 token 变化。实验分两组A 组普通 Prompt只给任务不做任何叙事约束。B 组叙事约束 Prompt给出角色、脉络、格式、字数、结束条件。每组执行 5 次取平均 completion_tokens避免单次采样带来的随机误差。为了方便对比可以让模型固定输出同时也可以在其他参数下重试。3. 核心实现把叙事约束写进 Prompt 工程3.1 定义一个可复用的约束模板叙事约束如果每次手动写很难保持一致。更合理的做法是把约束字段抽象成一个数据类再渲染成系统提示词或用户提示词。这里用 Python 定义一个最小版from dataclasses import dataclass, field from typing import List, Optional dataclass class NarrativeConstraints: task: str role: Optional[str] None structure: List[str] field(default_factorylist) style: Optional[str] None output_format: Optional[str] None forbidden: List[str] field(default_factorylist) end_marker: Optional[str] None def build_system_prompt(self) - str: lines [] if self.role: lines.append(f角色{self.role}) if self.structure: steps .join(self.structure) lines.append(f回答结构{steps}。) if self.style: lines.append(f语言风格{self.style}。) if self.output_format: lines.append(f输出格式{self.output_format}。) if self.forbidden: fbs .join(self.forbidden) lines.append(f禁止行为{fbs}。) if self.end_marker: lines.append(f结束条件{self.end_marker}。) return \n.join(lines) def build_user_prompt(self) - str: return self.task这个类的重点是让约束与任务分离。系统提示词放叙事约束用户提示词放具体问题。这样做的好处是同一个约束模板可以套用到多个任务上约束变更不需要修改业务代码系统 Prom put 可以统一被日志记录和审计。渲染后的系统提示词类似于角色你是一名只回答数据库优化问题的 DBA。 回答结构第一句直接给结论然后给出 3 条要点每条要点用一个具体例子支撑示例说完立即结束。 语言风格每句话不超过 30 字不要使用形容词。 输出格式只输出纯文本不要使用 Markdown 列表。 禁止行为不要解释索引的底层数据结构不要说明回表不要写总结段。 结束条件最后一个示例结束后不要再输出任何内容。3.2 不带约束与带约束的 Prompt 对比普通 Prompt 的构造很简单plain_messages [ { role: user, content: 用 3 条要点说明为什么数据库索引能提高查询速度。 } ]带叙事约束的 Promptconstraints NarrativeConstraints( task用 3 条要点说明为什么数据库索引能提高查询速度。, role你是一名只回答数据库优化问题的 DBA。, structure[ 第一句直接给结论, 然后给出 3 条要点, 每条要点配一个具体例子, 示例说完立即结束 ], style每句话不超过 30 字不要使用形容词。, output_format只输出纯文本不要使用 Markdown 列表。, forbidden[ 不要解释索引的底层数据结构, 不要说明回表, 不要写总结段 ], end_marker最后一个示例结束后不要再输出任何内容。 ) constrained_messages [ { role: system, content: constraints.build_system_prompt() }, { role: user, content: constraints.build_user_prompt() } ]从表面看约束后的输入 prompt 变长了通常多出 80 到 150 个 token。但如果输出 token 能从 800 降到 200输入侧的少量增加会被完全覆盖。这里要注意如果你的使用场景是长对话输入 token 每次都会完整计费那就必须在 prompt token 增加和输出 token 减少之间做整体收益计算。3.3 模型调用与 token 统计使用 openai 1.x SDK 并发调用两组 Promptfrom openai import OpenAI import tiktoken client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY ) MODEL your-model-name def call_model(messages, temperature0.7): resp client.chat.completions.create( modelMODEL, messagesmessages, temperaturetemperature, ) return resp def estimate_tokens(text: str) - int: enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text)) plain_resp call_model(plain_messages) constrained_resp call_model(constrained_messages) plain_output plain_resp.choices[0].message.content constrained_output constrained_resp.choices[0].message.content plain_tokens plain_resp.usage.completion_tokens constrained_tokens constrained_resp.usage.completion_tokens print(plain output tokens:, plain_tokens, estimated:, estimate_tokens(plain_output)) print(constrained output tokens:, constrained_tokens, estimated:, estimate_tokens(constrained_output))如果服务端返回的usage不可靠可以用tiktoken在本地估算。估算结果与真实 token 可能有差异但对“减少比例”的评估基本足够。真实计费仍以服务端返回为准。这里还建议把temperature固定住比如统一设成 0.3否则两个实验之间的差异可能来自采样随机性而不是叙事约束。如果想验证稳定性可以分别用 0.0、0.7、1.0 各跑几轮。4. 运行验证token 下降多少质量还要看什么4.1 验证脚本与结果输出为了直观看到减少比例可以在脚本里打印对比结果def show_metrics(name, response, output_text): model_tokens response.usage.completion_tokens est_tokens estimate_tokens(output_text) print(f{name}: model_tokens{model_tokens}, estimate_tokens{est_tokens}) print(--- output ---) print(output_text) print() show_metrics(plain, plain_resp, plain_output) show_metrics(constrained, constrained_resp, constrained_output) token_saving 1 - constrained_tokens / plain_tokens print(ftoken reduction ratio: {token_saving * 100:.2f}%)运行后普通 Prompt 的输出往往是一段完整的解释性文本保守估计在 400 到 800 token 之间。带叙事约束的 Prompt 因为要求第一句给结论、每条要点配例子、不要总结输出会显著缩短通常能压到 100 到 250 token。4.2 结果表下面是一组示例结果实际环境不同会有所波动实验组输入 prompt token输出 completion token总 token是否满足格式要求普通 Prompt18742760文本较长内容发散叙事约束 Prompt132161293结论前置3 条要点无总结按这组数据计算输出 token 减少比例约为(742 - 161) / 742 * 100% 78.3%如果继续调整约束可以减少到 150 token 以下此时比例更高。输入材料里提到的 79% 就落在这个数量级附近。不过要注意不同任务、不同模型、不同约束强度下的结果差异很大。对写短文、列举类任务减少比例更容易变大对需要大量推理或复杂分析的任务减少比例可能只有 30% 到 50%。4.3 79% 数值怎么来的以及如何复测79% 不应被当作固定收益。要复测某个业务场景至少需要做三件事固定测试集准备 50 到 100 条真实用户问题覆盖典型输入而不是只测一两条。固定模型和参数模型版本、temperature、max_tokens、top_p 必须一致。记录指标除了 token 数还要记录回答质量、超时率、报错率。质量维度也不能只看长度。建议同时记录是否包含关键结论。是否遵守输出格式。是否存在模板化僵硬表达。事实性错误率是否增加。用户反馈是否变差。叙事约束本质上是在“可读性”和“信息密度”之间做权衡。约束过强时输出会变得像电报关键概念虽然都在但可读性下降约束过弱时输出冗余还是压不下来。实际复测时应该先找到一个让回答质量不下降的最大约束强度。5. 常见问题与排查链路5.1 问题表做这种 Prompt 优化时最常遇到下面几类问题问题现象常见原因检查方式处理建议输出仍然很长叙事约束只放在用户提示词里系统提示词未生效检查系统提示词是否被 merged 到请求中把角色、结构和约束全部放入 system 消息模型无视字数限制模型对具体数字不敏感尤其是 200 字、500 字查看输出与约束的差距用“每条不超过 30 字”这类小粒度限制而不是只写总字数JSON 外出现解释文字模型把 JSON 信息放在代码块或文字里观察原始返回内容输出格式声明改为“只返回 JSON不要使用代码块不要输出注释”约束过多导致输出僵硬角色、结构、风格、禁止项叠加过密人工阅读输出是否失去自然语感优先保留对 token 影响最大的三个约束删除过度限制提示词变长后总成本反而高输出已较短输入增加显著统计 prompt_tokens 和 completion_tokens 的合计变化缩小系统提示词把固定约束精简为字段式描述中文输出 token 统计偏差大不同 tokenizer 对中文切分不同用服务端返回的 usage 或统一 tokenizer评估比例时统一用同一种统计口径5.2 排查顺序如果发现叙事约束没有起到预期作用按下面顺序排查先检查请求内容。不要只看代码里的变量直接在服务端记录里确认实际发送的 messages 是否包含约束。很多模型服务会拼装 prompt如果系统提示词被业务框架覆盖约束自然不会生效。然后检查模型是否理解约束。把同样的 Prompt 放到网页对话里人工测试。如果人工对话里约束有效但 API 调用无效问题多半出在消息结构或 role 分配上。再检查温度参数。温度过高会让模型更不遵循约束尤其在 0.8 以上。建议先设成 0 或者 0.3验证约束效果再逐步调整。最后检查约束本身是否冲突。例如既要求“每句话不超过 30 字”又要求“完整解释一个复杂概念”模型无法同时满足时会更倾向输出长句。冲突约束会让模型进入某种“纠结”状态反而产生更多解释性 token。如果以上都已排除可以观察生成日志里的 stop reason。如果发生 max_tokens 截断说明输出并没有被自然结束而是被迫截断这种情况不应该算作叙事约束的收益。6. 生产环境最佳实践与扩展方向6.1 约束设计清单叙事约束并不是越多越好。直接套用一大段规则反而可能让模型输出变得机械。推荐用下面的清单来设计约束只保留与业务目标直接相关的约束。每个约束必须能用一句明确的话表达。一句话只能包含一个动作不要写“既要又要”。把“不要做什么”和“要做什么”分开写。先写结论、结构、格式再写禁止项。对关键输出字段给出示例而不是只给类型。结束条件要具体例如“回答完最后一个实战案例后停止”。每次修改约束后记录 token 变化和质量评分。这个清单也可以直接放进 Code Review 的检查项里。新增一个 LLM Prompt 时要求提交者补充约束字段、输出 token 预期值、验证结果表。6.2 生产环境注意事项叙事约束在本地实验里很容易做进入生产环境后还需要补齐这些内容第一把 Prompt 模板外置化。不要把一大段约束硬编码在业务代码里建议放到配置中心、数据库或版本管理工具。后续调整约束不需要重新发版只需在配置中心发布新模板。第二增加 token 计量监控。每次调用都需要记录 prompt_tokens、completion_tokens、total_tokens 和响应耗时。当某个用户请求的完成 token 突然超过阈值时要能快速定位到 Prompt 版本。第三限制输出上限。即使有约束也要在接口层设置 max_tokens作为物理兜底。叙事约束只能降低超长输出的概率不能完全杜绝模型扇出。第四做好回滚与灰度。约束模板升级时先让 5% 流量使用新模板对比 token 节省比例和用户反馈再逐步放量。不能只因为 token 减少了就立刻全量替换。第五保持 Prompt 可解释。每个约束字段都应该有注释说明它为什么存在。三个月后回头看如果不了解背景可能会把关键约束误删掉。6.3 扩展方向叙事约束最直接的应用是减少单次生成成本但它也可以扩展到更多场景。在 RAG 系统中可以把检索结果压缩成固定叙事结构。例如要求模型只回答“结合检索内容给出三个依据并按重要程度排序”这不仅能减少 token还能减少幻觉因为模型被要求围绕文档证据说话。在 Agent 场景中把一个复杂任务的执行步骤封装成叙事约束可以避免 Agent 在每个小工具之间输出过多解释。比如让工具调用结果只输出结构化字段不需要自然语言描述这样每一步的上下文都能显著缩短。在长文本生成、报告生成、客服回复等场景里叙事约束甚至可以与 JSON Schema、函数调用机制结合让模型先输出固定字段再在字段内部进行小范围扩展。这样 token 消耗的稳定性会更强。如果继续深入可以将叙事约束与强化学习反馈、自动 Prompt 优化工具结合起来通过历史 token 消耗数据不断压缩 Prompt。但要注意压缩收益存在边际递减到一定程度后主要收益就不是 token 减少而是回答一致性和可控性的提升。最后给新手一个最值得做的练习选一个真实业务任务分别记录普通 Prompt 和叙事约束 Prompt 的 20 次调用结果算出平均 token 减少比例再让两位同事盲评回答质量。这个练习能让你在不依赖任何框架的情况下建立对 Prompt 优化的直觉也能更理性地看待“79% token reduction”这类数值——它只有在自己的场景里复测过才真正有价值。