一种双层网关下大模型用量的可信计量与对账方法与流程

本发明涉及云计算与人工智能，特别指一种双层网关下大模型用量的可信计量与对账方法。

背景技术：

1、近年来，大语言模型服务平台普遍采用双层网关架构以实现高可用访问控制、安全策略实施与精细化计费。该架构中，业务侧部署业务接入网关，负责身份认证、应用接入、租户与团队管理、智能体路由、授权控制及计费归属等业务语义层管控；模型侧部署模型运行网关，承担模型路由、供应商适配、缓存管理、护栏策略、重试与fallback机制及token真实用量采集等执行层职能。

2、上述职能划分导致两层网关在信息维度上天然割裂：业务网关掌握请求发起方的身份归属与授权快照，模型网关掌握实际模型调用的执行链路与供应商用量明细。任一单层网关独立记录的数据均无法独立构成从“调用方”至“调用内容与消耗量”的完整证据闭环，为用量结算与对账带来根本性信息不对称挑战。

3、为应对该问题，现有系统普遍采用以下手段：（一）用量信息提取与记录。业务网关从模型服务返回的http响应头、非流式json响应体或流式sse数据帧中解析token用量（含prompt_tokens、completion_tokens、total_tokens），并与调用方身份关联后持久化至本地用量表；响应中缺失明确用量字段时，退而根据字符数估算。模型网关则在每次调用结束后，将模型标识、供应商、缓存命中状态、调用状态及token用量写入日志或用量表。（二）跨网关请求链路追踪。业务网关在入口生成trace id并通过请求头向下游传递；模型网关在日志中记录上游trace id，同时返回自身生成的模型侧trace id，为两层网关间的调用链关联提供技术基础。

4、然而，上述方案在面向大模型服务用量可信计量与自动对账的实际应用中，仍存在以下系统性技术缺陷：

5、一、用量归属与执行信息缺乏可信绑定。业务网关无法感知模型网关实际路由结果与供应商信息；模型网关未保留计量时点的业务侧授权快照。依靠trace id事后关联仅能提供线索，无法建立计量时点下业务身份与实际执行记录间不可分割的绑定关系，缺乏审计证明力。

6、二、重试与fallback场景下用量归并准确性不足。一次业务请求可能触发多次底层调用尝试（如同端点重试或切换备用模型），业务网关仅能观察最终响应，对中间过程无感知，易导致用量重复或遗漏合并，缺乏对单次请求内部多次调用尝试的显式建模与追踪机制。

7、三、流式响应提前中断场景缺乏部分消费结算依据。sse流式响应中，连接可能在最终usage事件到达前因客户端断开、网络异常或护栏策略而终止，导致模型网关记录的供应商消耗量与业务侧转发量可能存在偏差，现有方案无法区分“供应商已生成但未送达”与“供应商实际仅生成至此”两种情况，缺乏可靠的差分证据机制。

8、四、缓存命中、护栏拦截、供应商异常等场景的消费语义未统一建模。护栏拦截不产生token消费，缓存命中仅产生读取量，供应商错误可能已消耗输入token但无有效输出。现有方案仅以http成功/失败作为计费二元判断依据，将不同技术事实映射为同一结算结果，无法真实反映资源消耗类型与量级。

9、五、异常补账过程缺乏幂等语义保障。定时任务重试、消息重投、人工补偿或延迟回执可能触发同一请求重复补账。现有方案缺少由全局计量标识、回执版本号及账务事件类型构成的幂等键设计，重复补账持续放大账务差异且难以追溯根因。

10、六、审计完整性与数据隐私保护之间存在结构性矛盾。保存完整提示词与响应内容有助于复核审计，但扩大敏感数据暴露面，可能违反隐私合规要求；而不保存正文时，现有方案缺乏足够结构化辅助证据（如请求指纹、授权快照摘要、尝试链完整性校验值等）证明某笔用量记录对应请求的身份、授权状态及回执的完整对应关系，导致审计追溯与隐私合规难以兼顾。

11、综上所述，现有技术仍以各层网关独立统计用量加事后人工核对为主要实现路径，缺少面向双层网关信息分置架构的统一计量上下文模型、调用尝试链显式追踪机制、可信用量回执体系及异常场景下的幂等补偿机制。

12、因此，如何提供一种双层网关下大模型用量的可信计量与对账方法，实现提升双层网关架构下大模型服务用量计量的可信性、对账准确性、审计证明力及异常场景下的鲁棒性与幂等一致性，成为一个亟待解决的技术问题。

技术实现思路

1、本发明要解决的技术问题，在于提供一种双层网关下大模型用量的可信计量与对账方法，实现提升双层网关架构下大模型服务用量计量的可信性、对账准确性、审计证明力及异常场景下的鲁棒性与幂等一致性。

2、本发明提供了一种双层网关下大模型用量的可信计量与对账方法，所述双层网关包括业务网关和模型网关，包括以下步骤：

3、步骤s1：所述业务网关在接收到业务请求后，生成全局计量标识，并基于所述业务请求的认证结果和路由上下文生成计量上下文，所述计量上下文至少包含所述全局计量标识以及用于标识请求方身份归属和授权状态的信息；所述业务网关对所述计量上下文进行完整性保护后传递至所述模型网关；

4、步骤s2：所述模型网关接收并验证所述计量上下文的完整性，验证通过后，基于所述全局计量标识管理本次请求的用量会话；每当发生一次实际模型调用或逻辑事件时，所述模型网关创建一条调用尝试记录，记录该次尝试的相关信息，并将同一用量会话下的各调用尝试记录按顺序关联，形成可验证的尝试链；

5、步骤s3：所述模型网关在所述用量会话达到结束条件后，根据所述尝试链聚合得到实际用量，生成用量回执，所述用量回执至少包含所述全局计量标识、聚合用量以及供应商生成进度标记；所述模型网关对所述用量回执进行数字签名或消息认证码计算；

6、步骤s4：所述模型网关将所述用量回执返回至所述业务网关；所述业务网关在转发所述业务请求的响应过程中采集业务侧观测数据，所述业务侧观测数据至少包含从模型服务响应中解析的token用量以及客户端转发进度标记；

7、步骤s5：所述业务网关接收并验证所述用量回执的数字签名或消息认证码，校验所述用量回执与所述计量上下文的绑定关系，将所述用量回执中的聚合用量与所述业务侧观测数据及已结算量进行比较，根据比较结果更新本次请求的计量状态；验证失败时记录对应的回执拒绝原因；

8、步骤s6：所述业务网关根据所述计量状态，以至少包含所述全局计量标识和回执版本的组合作为幂等键，生成并持久化追加式的结算事件，完成用量的计量与对账；对于重复或过期的用量回执，仅记录处置事件而不改变已确定的结算状态。

9、进一步的，所述步骤s1中，所述计量上下文还包括上下文版本、枚举版本、枚举模式摘要、随机数、追踪标识、创建时间、有效期、请求模型、流式标志及价格策略版本；所述请求方身份归属和授权状态的信息包括身份引用、授权快照摘要和请求指纹；所述身份引用至少包含应用标识、租户标识、团队标识、用户标识、智能体标识及凭证摘要中的一项或多项；所述授权快照摘要通过对授权规则、可用模型集合、价格策略及配额策略进行规范化排序后计算摘要得到；所述请求指纹通过对请求方法、规范化路径、声明模型、内容长度及正文散列计算摘要得到；所述枚举版本用于标识当前计量所使用的枚举规则集合的版本号。

10、进一步的，所述步骤s2还包括：

11、所述模型网关先按所述全局计量标识查询既有绑定；若同一所述全局计量标识对应的计量上下文摘要、随机数及签名内容与本次请求完全一致，且处于幂等重试窗内，则幂等返回既有用量会话或处理状态；若同一所述全局计量标识对应的计量上下文摘要、随机数或签名内容中的任一项不同，则拒绝请求并记录绑定冲突；若不同所述全局计量标识在同一签名密钥及有效期内复用同一随机数，则判定为重放并拒绝；

12、所述步骤s2中，所述调用尝试记录至少包含尝试标识、尝试序号、尝试原因、尝试结果、实际模型、供应商及用量信息；所述尝试原因包括初始调用、重试、回退、缓存命中或护栏拦截；所述尝试结果包括成功、接受前超时、接受后超时、用量产生前供应商错误、用量产生后供应商错误、派发前取消、派发后取消、缓存服务或护栏拒绝；所述尝试记录之间的顺序关联通过密码学摘要链接实现，具体方式为：h0=h(全局计量标识||上下文版本)，hi=h(规范化(第i条尝试记录)||h(i-1))，其中h为密码学散列函数，尝试链根摘要=hn；所述尝试序号在同一全局计量标识内严格递增，后一尝试记录必须引用前一尝试记录的摘要。

13、进一步的，所述步骤s3中，所述用量回执还包括回执版本、枚举版本、枚举模式摘要、与所述计量上下文中的追踪标识相对应的业务侧追踪标识和模型侧追踪标识、最终模型、供应商、尝试数量、可计费token、费用、价格版本、缓存结果、护栏结果、生成时间及密钥标识；所述聚合用量至少包含输入token、输出token、缓存读取token及缓存写入token中的一项或多项；所述结束条件包括请求完成、流式响应未携带最终用量信息、全部尝试失败或达到回执生成超时；所述供应商生成进度标记用于表征所述模型网关确认的供应商侧已生成的token进度；所述回执终止类型包括完整完成、部分流式、无供应商调用、全部尝试失败或派发前取消；

14、所述用量回执采用单调递增的回执版本；当流式响应未携带最终用量信息时，所述模型网关先生成临时回执，后续从供应商日志获得准确用量后生成更高版本的修订回执，并通过前一回执哈希与前一版本关联；低版本回执不得覆盖高版本结算结果。

15、进一步的，所述步骤s4中，所述用量回执通过响应头部、响应体扩展字段、sse最终事件、http尾部字段、消息队列、webhook或按全局计量标识主动查询方式中的一种或多种返回；当客户端提前断开连接时，所述业务网关通过按全局计量标识定位的事件提交接口向所述模型网关提交经数字签名或消息认证码保护的断开事件，所述断开事件至少包含事件标识、事件类型、最后转发序号、客户端转发进度标记及发生时间；所述模型网关以所述全局计量标识和所述事件标识的组合作为唯一性判据，进行幂等接收，并根据所述断开事件更新所述用量会话的结束条件判定依据；所述客户端转发进度标记用于表征所述业务网关确认的已向客户端转发的token进度。

16、进一步的，所述步骤s5中，所述计量状态包括请求阶段、消费结果和结算状态；所述请求阶段按已绑定、已派发、观测中、回执已定稿的顺序单向迁移；所述消费结果包括未确定、无消费、部分消费或完全消费；所述结算状态包括未结算、已结算、需补偿或人工复核；所述用量回执的处置事件类型包括接受新版本、重复忽略、过时忽略或版本跳跃；所述回执拒绝原因包括签名无效、绑定不匹配、枚举模式不匹配、密钥不可用或回执格式错误。

17、进一步的，所述步骤s5中，所述比较包括：将所述用量回执中的聚合用量、所述业务侧观测数据中的token用量及已结算量按输入、输出、缓存读取、缓存写入分别进行比较；当差异在预设绝对阈值和/或相对阈值内时视为可接受；对于流式响应，还比较所述供应商生成进度标记与所述客户端转发进度标记，以区分供应商已生成但未送达客户端的部分。

18、进一步的，所述步骤s5还包括：

19、当所述用量回执的回执版本等于当前最新回执版本时，记录重复忽略处置事件；当所述回执版本小于当前最新回执版本时，记录过时忽略处置事件；当所述回执版本大于当前最新回执版本加1时，将所述结算状态更新为需补偿并记录版本跳跃处置事件；所述用量回执的数字签名或消息认证码验证失败时，或者所述用量回执与所述计量上下文的绑定关系校验失败时，不进行结算，记录所述拒绝原因并将所述结算状态更新为需补偿。

20、进一步的，所述步骤s6中，所述结算事件的事件类型包括首次计费、补账、冲正、零消费或人工调整；所述结算事件至少包含所述全局计量标识、回执版本、事件类型、token差额、金额差额、幂等键及前后状态；数据库对所述幂等键建立唯一约束，重复提交仅能成功写入一次；对于首个被接受的有效回执，差额为零时写入零消费事件；对于已有结算基线后的回执版本号连续递增的高版本回执，正差额生成补账事件，负差额生成冲正事件，差额为零时仅写处置事件而不生成token金额账务事件；累计结算值由同一全局计量标识下全部有效结算事件求和得到。

21、进一步的，所述方法还包括：

22、步骤s7：执行周期性差异对账，按时间窗口读取待补偿记录，依据所述全局计量标识查询所述模型网关的用量回执，按所述全局计量标识精确匹配后校验所述授权快照摘要、所述请求指纹、时间窗口及追踪标识；对回执缺失、仅模型侧记录、仅业务侧记录、版本不一致、token不一致、实际模型不一致及价格版本不一致分别生成差异类型和处置建议；超过自动处理阈值或涉及密钥不可用的记录转人工复核；

23、步骤s8：仅保存请求指纹、请求长度、授权快照摘要、供应商生成进度标记、客户端转发进度标记、尝试链根摘要和用量回执的数字签名或消息认证码作为审计证据；复核时通过对受控环境中的原始记录重新计算摘要以证明审计证据与用量回执之间的对应关系，无需保存完整提示词和响应内容即可验证用量回执的归属与完整性。

24、本发明的优点在于：

25、1、在可信性上，业务网关将含授权快照摘要和请求指纹的计量上下文经完整性保护传递至模型网关，并由模型网关对聚合用量回执进行签名，实现业务身份与实际执行记录的双向强制绑定，确保任何单方无法抵赖或篡改；在对账准确性上，通过将单次请求映射为用量会话并对每次调用尝试（含重试、回退、缓存命中、护栏拦截及供应商异常）进行密码学摘要链接形成可验证尝试链，结合流式场景下供应商生成进度标记与客户端转发进度标记的差分比较，确保多尝试归并及流式中断场景下的用量计算精确无遗漏；在审计证明力上，仅保存正文散列、授权快照摘要、尝试链根摘要等摘要型证据，审计时通过重算验证即可还原对应关系，无需保存原始提示词与响应，从而在满足隐私合规的前提下提供完整的密码学可追溯性；在鲁棒性与幂等一致性上，以全局计量标识与回执版本的组合作为幂等键并结合数据库唯一约束，配合版本跳跃检测、过时忽略及追加式事件持久化，确保重复提交、延迟回执或乱序到达时结算状态的最终一致性且不放大账务差异，从而从请求发起到结算落账形成全链路可信、可审计且抗干扰的闭环体系。

26、2、通过业务网关生成包含全局计量标识、身份引用和授权快照摘要的计量上下文，并在传递前进行完整性保护，模型网关验证后对用量回执进行数字签名，从而建立业务身份、授权状态与实际执行记录间的密码学绑定关系，为用量结算提供不可篡改的审计证据闭环，确保了计量时点下调用方归属与消耗量的强关联性。

27、3、引入调用尝试记录与可验证尝试链机制，将一次业务请求触发的多次底层模型调用（如同端点重试、切换备用模型或回退）显式建模并按顺序关联，通过密码学摘要链接保证尝试链的完整性和顺序性不可篡改，从而准确汇总单次请求内所有尝试的消耗量，有效避免用量重复计算或遗漏，提升复杂调用场景下归并的精确性。

28、4、通过用量回执中的供应商生成进度标记与业务网关采集的客户端转发进度标记形成差分证据，并结合客户端断开事件提交机制，能够精确区分流式响应中断时“供应商已生成但未送达”与“供应商实际仅生成至此”两种情形，为部分消费提供可验证的量化结算依据，弥补了传统方案在流式提前终止场景下的证据缺失。

29、5、对缓存命中、护栏拦截、供应商异常等多样化技术场景进行细粒度语义建模，通过尝试记录明确区分不同尝试原因和结果，并在用量回执中分类统计输入、输出、缓存读取及缓存写入token，使得结算结果能够真实反映各类资源消耗的技术事实，避免以简单成功/失败二元判断导致的不公平计量。

30、6、基于全局计量标识与回执版本的组合构建幂等键，并配套版本递增与处置策略（接受、忽略、过时、跳跃），确保重复提交、定时任务重试或延迟回执均不改变已确定的结算状态，仅记录处置事件，从根本上保障了异常补账场景下的账务一致性和可追溯性。

31、7、仅存储请求指纹、授权快照摘要、尝试链根摘要及用量回执签名等结构化元数据作为审计证据，无需保存完整的提示词和响应内容，复核时通过对受控环境中的原始记录重新计算摘要即可验证用量回执的归属与完整性，既保证了审计追溯的可靠性，又避免了敏感数据暴露风险。