近年来，大型语言模型技术迅速发展，推动了人工智能应用的蓬勃兴起。众多企业和开发者纷纷尝试将语言模型集成到自身产品中，以满足智能客服、内容生成、对话系统等多样化需求。与此同时，围绕语言模型推理服务成本的讨论也变得愈发激烈。行业内普遍沿用的“每令牌计费”（dollars per token）模式虽然在API服务商收费体系中行之有效，但当用户将推理自托管时，这种计费思路反倒带来了诸多认知误区和实践困扰。本文将深入探讨为何“每令牌计费”模式对自托管应用不友好，并阐述按请求计费的优势所在。开源模型和自托管推理近年来成为热门趋势。
相比依赖OpenAI、Anthropic、Alphabet等巨头提供的闭源API，越来越多团队选择自行搭建推理平台，以降低成本、获得更高的数据自主权以及实现个性化功能定制。然而，自托管也面临明确的成本结构挑战。API服务商通常依据输入输出的令牌数计费，令牌作为模型理解文本的最小单位，理应反映计算资源消耗。然而现实中，令牌的数量因文本编码机制复杂且非线性，且用户体验感知集中在请求本身，而非令牌数量。端用户关心的是请求是否快速、准确地响应，而非其背后包含多少令牌。实际上，用户发起的每次交互才是价值体现的关键单元。
从应用视角出发，将成本与令牌数量挂钩显得繁复，且不符合业务需求。采用每请求计费的观念，更能贴合服务交付的实际情况。在自托管环境，成本主要由硬件计算能力的使用时间决定，如GPU算力租用费用或设备折旧。系统的总体费用可用“每秒的美元投入”乘以满足并发请求所需的资源数量加以估算。在这个计算结果中，令牌数量只作为推理引擎内部的中间指标，而不是直接用于成本核算的主变量。举例来说，一款宠物狗管理平台内置的智能客服，用户咨询“斗牛犬是否收费额外？”，这种请求虽可能涉及多个令牌，但对用户而言只是一次单一的交互。
如果系统运营方以令牌计费向用户收费，用户体验将混乱且难以接受，因为他们不会关心或理解具体有多少个令牌产生。换言之，围绕令牌数量设计价格模型，只对语言模型API服务商有意义，对于应用构建者及最终用户来说，无法直观映射为价值或费用。进一步讲述延迟体验和扩展需求的问题，单纯使用令牌数衡量无法有效指导系统设计。例如，评估单请求所能承受的最大响应时延时，开发者必须从用户需求出发，先明确每次请求希望的响应速度，然后结合典型请求及响应的字符或令牌数量对推理引擎性能进行测试评估。若只关注令牌每秒处理量，则无法精准反映真实的用户服务体验需求。同时，负载预测和服务器复制数量规划亦需基于请求数而非令牌数。
毕竟请求是可以调度拆分的服务单元，令牌不可随意拆分分布于多个节点，令牌的计量不能准确指导资源分配和负载均衡。再者，令牌计费引入的复杂性会干扰产品经理、设计师与工程团队的决策沟通。产品、设计和商业团队关心的是“每次请求成本多少”、“每个交互是否值得”，而非单纯令牌数量。他们希望用简洁明了的“每请求成本”指标来做ROI分析、客户定价与市场方案调整。相比之下，令牌作为底层抽象技术的二阶指标不利于跨部门协作，增加沟通成本和决策难度。对于自行托管的团队而言，理解和采用正确的成本指标还有助于优化基础设施规划、控制运营费用。
确认每秒并发请求数能够满足用户需求后，团队可据此选择合适的硬件配置和复制数量，避免过度投入资源，也避免性能不足导致用户体验下降。衡量绩效的核心其实是以“请求”作为计量单位，令牌则作为调优内部模型推理效率的参考。显而易见，“每令牌计费”模式的影响力源于大型API提供商在市场的统治地位，他们制造了业界统一期望，导致许多自托管用户沿用这样的思维，甚至以此为成本估算参考。然而这一模式忽视了自托管场景的根本差异，即不再是卖推理服务，而是为特定应用提供语言模型能力。只有跳出基于令牌的视角，转向以请求为中心，企业才能更理性地评估自建推理的合理性及其业务价值。一旦采用合理的成本核算方法，团队便可精准回答“我能支持多少并发请求”、“响应时延是否满足用户期待”、“基于当前硬件配置成本该如何预测”，这些核心问题更容易导向切实可行的架构方案和商业模式。
总之，拒绝陷入“每令牌计费”的迷思，拥抱基于请求的成本思维，是面向未来大型语言模型自托管的重要一步。它帮助团队更有效地协调技术与业务、优化资源配置、提升用户满意度并促进数字化转型。未来，随着开源模型和推理引擎的发展，产业内对自托管高性能、低成本LMM应用的需求将持续增长，树立合理的成本核算体系将成为关键。相关技术提供商如Modal等已经在推动这一新范式，为团队提供面向请求的高效推理平台，使团队快速构建高吞吐、低延迟、成本可控的智能应用。企业应积极拥抱这一转变，从关注令牌数量走向关注请求价值，真正实现人工智能与业务场景的深度融合与共赢。
