各位佬友好，向大家同步一个近期的计费异常排查进展、技术复盘与处理方案。 问题原因与技术详情 此前我们陆续收到部分佬友通过工单反馈，在特定场景下调用扣费偏高。经过团队排查日志与代码比对，确认是在处理 涉及缓存读取的请求 时，协议转换环节的两个历史逻辑缺陷叠加，导致缓存 Token 被重复计费。 一、协议转换时未能正确剥离透明缓存 当用户使用 Claude 协议接口调用非 Claude 模型时，系统需要将上游返回的用量换算为 Claude 格式。旧逻辑只在“存在显式缓存写入”时，才将缓存 Token 从总输入中扣除；而 DeepSeek、GLM、Kimi 等国产模型的机制属于自动透明缓存，通常只有缓存读取、没有缓存写入，导致原本包含缓存的“总输入”被系统错误地原样当作了全量的“全新输入”。 二、响应转换过程中丢失了原始计费快照 在响应转换环节，旧代码未能完整保留上游返回的原始计费信息，导致最终结算模块只能依照 Claude 原生语义来理解用量（即假定“输入 Token 与缓存读取 Token 互为独立实体”）。因此，上一步骤中已经混入输入里的缓存部分，又被系统按照缓存折扣费率单独计费了一次。 两项缺陷叠加的最终表现为 ：命中了缓存的请求，其缓存读取部分除了正常收取的缓存折扣价外，还被按普通输入的全价额外重复收取了一次。 影响范围 受影响场景 ：通过 Claude 协议接口（ /v1/messages ）调用非 Claude 模型且命中缓存的请求。主要集中在 DeepSeek、GLM、Kimi 系列，另有极少量 GPT 与 Gemini 请求。 不受影响场景 ：Claude 原生系列模型（输入与缓存本身即独立计价）；所有通过标准 OpenAI 协议接口（ /v1/chat/completions 、 /v1/responses ）调用的请求，计费全程完全正确。 核查周期 ：覆盖系统日志保留期内的全部记录，直至修复补丁上线生效为止。 我们的失误与处理行动 上游New API原版此前已合入相关修复，但由于 我们基于原项目进行了二次开发 ，为了保障线上环境稳定，在拉取合并代码时过于保守滞后，未能第一时间将关键修复合入生产环境，扩大了受影响时间，这是我们在维护与测试把控上的严重疏失，再次向各位受影响的佬友致歉。 目前我们已执行以下处理措施： 补丁验证与上线 ：修复逻辑已在本地编译测试，并使用真实计费引擎完成了前后差异复现验证，确认当前所有涉及缓存读取的计费已彻底恢复正常。 拉网式逐条重算 ：我们对日志保留期内数十万条涉及缓存的消费记录进行了逐条重算。按照每条请求发生时的基准价格、倍率、分组以及时段系数，重新计算出正确金额，差额部分即为多扣金额。 差额全额补退 ：所有重算数据均完成交叉复核；对于极少数无法完全确认的边缘记录，一律按对用户有利的口径兜底计算。因该缺陷多扣除的全部额度， 已原路全额补退至对应账户 ，大家可前往控制台账单明细查验。 专项补偿与福利 除了退还多扣额度外，为弥补给大家造成的不便，我们提供以下专项福利： 受影响用户补偿 ：系统已将所有在此次异常中受影响的账号 自动加入专属活动分组 。大家进入控制台在活动分组下创建 Key，即可直接享受 连续 3 天、每天 200 次的国产大模型免费调用 。 未受影响用户福利 ：未受影响的佬友同样可以参与，前往我们的 主帖 评论盖楼留下你的 ZeroCat 用户 ID，我们也会分批拉入该活动分组一同免费体验。 新分组上线通知 全新的 【GPT】特惠分组 现已正式上线： 该分组倍率低至 0.08x ，旨在进一步降低大吞吐与高频调用的门槛。详细模型列表与实时倍率欢迎查阅模型广场： ZeroCat 写在最后 后续我们会严格优化对核心计费与协议转换模块的补丁跟进机制，杜绝类似滞后情况。 大家在核对账单时若发现数据有任何出入，或在调用中遇到其他疑问，请随时提交 站内工单 联系我们，我们会逐一核实处理。 感谢各位佬友一直以来的支持。 11 个帖子 - 10 位参与者 阅读完整话题

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/20 13:59:07