我认为“使用更少的token”作为LLM成本建议过于肤浅
摘要
本文认为，常见的专注于减少token的LLM成本建议过于肤浅，而在生产环境中更具影响力的策略是，将不同的工作流步骤路由到不同的模型，而不是使用单一的默认模型。
许多关于LLM成本的建议似乎止步于提示压缩、缓存或token限制。但在生产工作流中，我怀疑更大的问题是模型选择。例如：
- 分类工单意图
- 总结上下文
- 检索文档
- 草拟回复
- 最终高风险响应
这些步骤可能不应该全部使用同一个模型。对于在生产环境中运行AI代理或RAG的团队：你们是将不同步骤路由到不同模型，还是仍然在所有地方使用一个默认模型？
相似文章
我对LLM代码风格与Token成本的发现
本文讨论了LLM代码风格选择如何影响Token消耗和成本，并提供了优化建议，如使用Web API标准和更简单的缩进以减少输出Token。
降低LLM API成本的10种方法
一份实用指南，列出了使用LLM API时降低成本的10种策略，包括模型选择、提示缓存、批处理以及监控费用。
并非所有Token都同等重要：通过强化学习中的Token重要性实现高效LLM推理
本文提出了一个强化学习框架，通过建模Token重要性来选择性地对不重要的Token进行惩罚，同时保留关键推理步骤，采用重要性感知奖励和动态长度奖励来减少冗余，在不牺牲准确性的前提下提高效率。
吐槽：别再说什么LLM只是“下一个词预测器”了。
对LLM“只是下一个词预测器”这一过于简单化的说法提出批判，认为大规模预测会诱导出有用的表示和能力，并且这种轻率的否定混淆了目标与学习系统。
知道何时放弃：通过多阶段飞行中拒绝实现令牌高效的LLM合成数据生成
本文提出了多阶段飞行中拒绝（MSIFR），一种无需训练的框架，通过在中间检查点检测并终止低质量生成轨迹来减少基于LLM的合成数据生成中的令牌浪费。在五个模型和七个基准测试中，MSIFR作为独立方法可减少11%-77%的令牌消耗，与早期退出方法结合时最多减少78.2%，同时保持或提升准确率。