实时聊天的逐词输出成本：今年应按会话核算，而非按调用记账

§1 单次调用价格无法代表实时聊天成本

一次请求很便宜，不代表解决一个用户问题很便宜。实时聊天往往包含多轮追问、历史上下文、工具调用和失败重试。用户看到的是连续对话，账单记录的却可能是十几次模型请求。

今年的实用做法，是把每次会话成本作为产品经营指标，把每次调用成本保留为排障指标。尤其在逐词输出场景中，回复已经开始、用户是否看完、任务是否完成，是三个不同事件，不能用一次成功响应替代衡量。

会话应围绕同一用户目标划分，而不是简单等同于一个聊天窗口。可以从连续完成一次客服处理、一次代码修改或一次资料查询开始，并设置明确的空闲超时规则。跨天恢复、切换任务和后台自动执行，也要有统一归属。

成功标准应来自业务结果，例如问题已解决、修改通过验证或用户确认完成。不要把连接正常关闭、模型停止生成或用户没有继续追问，直接认定为成功。

会话总成本＝模型费用＋工具费用＋可归属的运行费用。模型费用应分别记录输入、输出、缓存写入和缓存读取，并按照实际账单规则计价。不要把命中缓存的输入当作免费，也不要重复累计供应商已经汇总的用量字段。

为每个会话关联全部请求与工具执行记录，保留模型版本、价格版本、重试原因和结束状态。正式报告以结算用量为准；流式过程中的估算只用于预算预警，并在拿到账单后校正。

例如，一次会话包含三轮回复和一次自动重试，即使每次请求价格都很低，重复发送历史内容也可能推高总成本。只比较最后一次调用，会漏掉前面所有投入。

逐词输出改善的是等待体验，不会自动降低费用。用户点击停止或关闭页面后，如果服务端仍在生成，未展示的内容也可能产生费用。客户端断开后，应尽快向上游传播取消信号，并验证上游是否实际停止。

每条回复至少记录首词延迟、生成结束时间、取消时间、实际用量和已展示内容。已展示令牌不等于计费令牌；网络缓冲、取消传播延迟和供应商统计方式都可能造成差异。

流式重试尤其需要谨慎：已经展示部分内容后，直接重新请求既可能重复扣费，也可能让用户收到两份答案。应区分尚未输出时的重试与输出后的恢复，并设置会话级重试上限。

优化目标不是让每次请求都最便宜，而是在质量和延迟达标时降低每个成功会话的成本。例如，可测试用 Claude Haiku 4.5 处理明确的简单任务，复杂任务再升级至 Claude Sonnet 5.5；这只是路由实验方案，不能预设它必然更省。

评估时同时观察成功率、追问轮数、升级比例和首词延迟。便宜模型如果导致更多澄清与重试，最终可能更贵。为长会话设置预算提醒、输出上限和上下文压缩策略，但要验证摘要是否遗漏关键约束。

需要接入多模型并保留实时逐词回复时，可以考虑 Fluxio。它是流式优先、按令牌付费的人工智能接口中继，可通过一个密钥访问多种模型，并兼容采用开放式接口规范的客户端，适合集中接入和路由实验。

不过，统一接口不等于自动获得完整的会话经济性。应用仍需维护会话标识、任务结果与工具成本，并核验各模型的用量返回、缓存规则和取消行为。上线后持续按任务类型对比成本与完成率，才能判断一次优化是否真正减少了解决问题的支出。