在大型语言模型的实际部署中，token 消耗量直接影响响应延迟、运营成本与用户体验。传统评估往往关注模型在标准基准上的准确率，却忽视了「每消耗一个 token 能产生多少有效信息」这一效率维度。Caveman 项目通过强制模型使用简洁语言实现约 75% 的 token 节省，为我们提供了一个审视 token 效率的独特视角。本文以此为切入点，系统阐述如何构建基于真实推理延迟与准确率的 token 效率基准测试方法论。
基准测试的核心目标与边界
token 效率基准测试的根本目的是量化「输入输出过程中的资源利用有效性」。与单纯测量模型吞吐量和首字延迟不同，token 效率评估需要将生成质量纳入考量 —— 如果一个响应仅消耗 100 个 token 但答案错误，其效率未必高于消耗 400token 给出正确答案的实现。Caveman 的实践表明，压缩冗余表达（问候语、缓冲句式、过度解释）可以在保持技术准确性的前提下显著降低 token 消耗，这一发现直接推动了效率基准测试从单维度（吞吐量）向双维度（质量 × 成本）演进。
测试边界应明确覆盖三个层面：首先是响应生成的直接成本，即输出 token 数量与生成时间的乘积；其次是端到端的感知延迟，包括从请求发起到最后一个 token 返回的完整链路；最后是任务完成质量，需要为每个测试用例定义明确的正确性评判标准。Caveman 项目中每个测试用例都有对应的原始响应作为对照，这使得效率对比可以在相同任务语义下进行，这是构建可靠基准的基本前提。
关键量化指标体系
1. Token 效率比（Token Efficiency Ratio, TER）
TER 是衡量单位 token 产出有效信息的核心指标，计算公式为：TER = 任务完成质量分数 / 消耗的 token 数。质量分数的取法根据任务类型决定 —— 代码修复类任务可采用编译通过且通过预设测试用例的二值结果，解释类任务可采用人工评估或自动化评估（如基于答案关键点的覆盖率）。Caveman 在 React 组件渲染问题上的测试显示，原始响应消耗 1180token 给出完整解释，而 Caveman 模式仅消耗 159token，两者的技术信息量等效（均指向 useMemo 解决方案），因此 TER 提升了约 7.4 倍。
2. 时间到首 token（Time to First Token, TTFT）
TTFT 测量从请求发出到模型输出第一个 token 的时间间隔，主要受模型加载、输入处理与首次解码影响。在实际应用中，TTFT 决定了用户感知的「响应启动速度」。Caveman 模式的间接效益在于，由于输出 token 总数大幅减少，TTFT 在整个响应时间中的占比相对提升，使得整体端到端延迟更早进入可交互状态。对于需要快速反馈的交互式场景，TTFT 应作为独立的关键指标进行监控，典型阈值建议控制在 500 毫秒以内。
3. 每 token 生成时间（Time Per Output Token, TPOT）
TPOT 反映模型生成每个后续 token 的平均耗时，是计算总延迟的核心参数。总延迟的简化估算公式为：Total Latency ≈ TTFT + (Output Token Count × TPOT)。Caveman 模式由于输出 token 数减少至原来的约三分之一（平均从 1214 降至 294），即使 TPOT 保持不变，总延迟也相应缩短约 75%。这意味着在相同的硬件条件下，简洁回复模式天然具有延迟优势。
4. 准确率 - Token 权衡曲线
基准测试应覆盖多个压缩程度下的准确率表现，绘制准确率随 token 消耗变化的曲线。这一曲线能够识别「收益递减点」—— 在某个临界点之后，增加 token 消耗带来的准确率提升趋于平缓。Caveman 引用的 2026 年论文「Brevity Constraints Reverse Performance Hierarchies in Language Models」发现，在特定基准上限制模型输出长度反而提升了 26 个百分点的准确率，完全逆转了性能排序。这提示我们：更短的响应不必然意味着质量损失，优化 token 效率应作为与准确率并行的独立目标。
基准测试的实践方法
测试用例选取与分组
基准测试的测试用例应覆盖典型任务类型，并按 token 密度进行分组。Caveman 项目的测试集包括代码调试（React 重渲染、认证中间件、数据库竞态）、架构设计（微服务 vs 单体）、代码审查、安全问题检查等多种场景，每个场景的 token 节省比例差异显著（22% 至 87% 不等）。建议将任务分为四类：低信息密度任务（闲聊、格式转换）、中等信息密度任务（代码解释、PR 审查）、高信息密度任务（多步骤调试、架构设计）以及超高信息密度任务（完整实现、长篇文档生成）。不同类别的效率优化天花板差异明显，不宜使用单一均值进行跨类别比较。
测量协议与统计方法
每个测试用例应至少运行 5 次以捕获方差，计算中位数与 P95/P99 尾延迟。Token 计数应从 API 响应中直接获取实际消耗值，而非估算。准确率评估优先采用可自动化的指标（精确匹配、F1、ROUGE），对于主观性较强的任务可引入多人标注。基准测试报告应包含以下核心数据：任务名称、原始响应 token 数、优化模式 token 数、节省比例、TTFT、TPOT、端到端延迟、准确率得分、TER 值。
对照组设计
有效的基准测试需要明确的对照组。Caveman 采用的对照策略是：同一问题、同一模型、仅改变系统提示词（引导模型采用简洁风格）。这种设计控制了模型能力、硬件环境、输入复杂度等变量，纯粹反映提示工程对 token 效率的影响。在更广泛的基准中，还可以引入不同模型之间的横向对比、不同压缩技术（提示压缩、输出截断、风格引导）的纵向对比。
落地参数与监控建议
基于 Caveman 的实践数据，可以提炼以下可落地参数：对于代码调试类任务，建议将输出 token 上限设置为原始响应的 30% 至 40% 作为初始阈值；响应延迟的 SLA 可设定为 TTFT 小于 800 毫秒且总延迟小于 3 秒；准确率底线应保持与原始响应相当（允许 ±5% 波动）。生产环境中建议持续监控两项效率指标：一是 Token 使用效率（每千次请求的 token 总消耗），二是 TER 的移动平均值，当 TER 下降超过 15% 时触发告警。
需要注意的是，Caveman 模式仅作用于输出 token，思考 token（Claude 的 thinking tokens）不受影响。这意味着在需要复杂推理的任务中，总 token 节省比例会低于纯输出场景的比例。部署时应根据任务类型动态选择是否启用简洁模式 —— 代码补全等简单任务适合极简响应，而复杂架构规划仍需保留充分论述空间。
参考来源
本文核心案例与数据来源于 Caveman 项目 GitHub 仓库（https://github.com/juliusbrussee/caveman），该仓库提供了完整的基准测试数据与可复现的测试脚本。方法论部分参考了 2026 年论文「Brevity Constraints Reverse Performance Hierarchies in Language Models」（arXiv:2604.00025）关于长度约束与模型性能关系的发现，以及业界通用的 LLM 延迟与吞吐量指标定义（Anyscale 文档）。