AI 中转站评测框架GatewayBench上线，官网 Check4U.ai 同步开放

AI 中转站解决了模型访问问题，但也制造了新的信任问题。 AI 中转站评测框架GatewayBench 现已通过官网 Check4U.ai 开放评测入口，试图将模型真实性、计费透明度、缓存隔离和真实成本转化为可验证指标。GatewayBench 同时面向 API 中转站、聚合网关和模型服务商开放公开评测榜单，希望用可复查的审计数据，让诚实交付获得更多市场信任。

大模型 API 正在进入全球生产环境，被接入客服、代码生成、Agent 工作流、风控系统和科研实验。但在这场智能化浪潮背后，一个长期存在的问题正在变得更加突出：全球开发者并不拥有同等的模型访问条件。

在一些地区，团队可以相对顺畅地绑定信用卡、调用官方接口、使用最新模型；而在另一些地区，开发者仍然会受到地缘限制、支付门槛、账号风控和企业合规流程影响。业务和科研需求不会因此消失，于是第三方 AI 中转市场，也就是 Shadow API，逐渐成为一种现实中的工程替代方案。

对许多团队来说， AI 中转站具有十足的吸引力，它让开发者能够以更低的接入门槛使用 GPT、Claude 等主流模型，体验上接近官方 API，也在一定程度上填补了官方渠道无法覆盖的空白。

但问题在于，这个市场的后端极不透明。

服务商通常会强调原版模型、低价、高速、支持缓存等卖点，但用户很难验证后端究竟发生了什么：模型是否被替换或降级，token 是不是被准确计费，缓存折扣又是否被真实返还，跨账号数据是否严格隔离，失败请求是否仍然被扣费。

这种黑箱风险已经超出普通采购范畴。2026 年 3 月，德国 CISPA 亥姆霍兹信息安全中心的一篇审计论文显示，全球至少有 187 篇学术论文使用过AI 中转API（ Shadow API），其中 62% 已被 ACL、CVPR、ICLR 等顶级会议接收。如果实验中的底层模型被替换、量化或降级，研究结果的可复现性和可信度都会受到影响。

AI 中转站API 解决了访问问题，却制造了新的信任问题。

GatewayBench：把网关黑箱转化为可验证指标

在这一背景下，GatewayBench 作为一套面向 AI 中转站的审计评测框架正式上线，并通过 Check4U.ai 开放评测入口。它的目标是为这一市场提供更客观、可复查的评测标准。

和普通跑分工具不同，GatewayBench 更像是一个面向大模型网关的审计框架。传统横向评测通常比较速度、价格、模型覆盖率和可用性，并默认网关返回的数据真实可信。但在AI 中转站API场景下，这个前提并不稳固：一个平台可以看起来又快又便宜，但请求进入网关之后，模型是否被降级、token 是否被准确计费、缓存是否被正确处理，用户未必看得见。

因此，GatewayBench 新增了一个传统评测中很少被量化的维度：技术诚信，这个指标关注的并非接口表面上的速度和便宜，而是网关交付过程本身是否可信，即当开发者把请求交给中转网关后，最终获得的服务，是否仍然符合平台最初承诺的模型能力、成本结构和隔离边界。

三层评估框架：可信度、性能与经济性

对应到框架设计中，GatewayBench 将综合评估拆成三个维度：L1 可信度、L2 性能、L3 经济性。

L1 可信度 关注模型真实性、计费透明度和缓存可信度；

L2 性能 关注延迟、Goodput 和长上下文场景下的稳定交付能力；

L3 经济性 关注名义单价之外的真实出账成本。

综合分采用如下权重：

综合分 = 0.40 × L1 可信度 + 0.40 × L3 经济性 + 0.20 × L2 性能

这个权重设计意味着，在 AI中转站API场景下，可信度和真实成本优先于速度。一个网关必须先证明模型真实、账单透明、成本可解释，才有资格进入性能竞争。

L1 可信度：把黑箱变成可验证信号

大模型中转网关最大的风险，在于用户很难知道后端到底发生了什么，模型是否被替换，thinking tokens 是否被虚报，缓存折扣是否真实返还，过去往往只能通过感觉模型变笨了或账单看起来异常来判断。

GatewayBench 的 L1 维度，试图把这些模糊怀疑变成可验证的审计问题，将可信度拆成三部分：模型真实性、计费透明度和缓存可信度。对应的审计方法也不再依赖厂商自报日志，而是引入统计检验、密码学结构和延迟指纹，从外部反推网关是否真的交付了承诺的模型、成本和隔离边界。

1. 模型真实性：识别模型替换与降级

在灰色中转市场里，最难发现的套利方式之一，是模型的动态替换。网关可以根据成本、负载、用户类型或请求特征，在不同后端模型之间动态切换。更复杂的情况是，网关可能在明显的测试请求或重点客户请求中调用官方模型，在普通流量、长尾请求或高成本任务中切换到量化模型、蒸馏模型，或成本更低的替代模型。这样一来，单次抽样很难发现问题，用户看到的也只是一个看起来正常的响应。

如果只看最终输出，很难识别这类问题。但大模型底层是一个概率分布系统。给定同一个 prompt，原版模型会生成一套相对稳定的候选 token 排序。低配模型即使能给出相似答案，其长尾 token 的概率顺位也会出现持续偏移。

为此，GatewayBench 引入了 RUT（Rank-based Uniformity Test，基于排序的均匀性检验） 方法，用于验证黑箱 LLM API 的行为是否与参考模型一致。它并不直接比较中转站最终生成的文本语义，而是通过连续抽样，把网关生成的 token 放回参考模型的概率排序中做一致性检验。如果网关发生模型替换、量化降级或有害微调，输出文本可能仍然看起来接近，但 token 在参考模型概率分布中的位置会出现系统性偏移。这种偏移，就是模型被调包或降级的统计痕迹。

在持续监控层面，GatewayBench 还可以结合 Logprob Tracking。这类方法不需要每次生成完整回答，而是在固定 prompt 下只请求一个输出 token，并追踪该 token 的 log probability 是否出现稳定偏移。若同一 endpoint 在不同时段出现明显 logprob 漂移，就可能意味着后端模型发生了更新、微调、量化调整或路由切换。

这类偏差很难通过话术掩盖。RUT 主要是判断目标 endpoint 的行为是否接近参考模型，而Logprob Tracking 则用更低成本持续观察同一 endpoint 是否发生漂移。二者结合，可将「模型是否被调包」从主观体感问题，转化为可以统计检验和持续监控的问题。对企业用户来说，验证的指标是厂商交付的模型，是否和合同、接口文档、价格表里承诺的是同一个模型。

2. 计费透明度：审计隐藏的 thinking tokens

推理模型（Reasoning）让大模型计费变得更难核验。由于 thinking tokens 默认不可见，平台既可以基于这部分 token 计费，也可以在用户无法核对的地方虚报数量。这意味着，推理模型把一部分真实成本转移到了黑箱内部，而账单透明度也因此变成可信度审计的一部分。

GatewayBench 将计费透明度单独列出，正是为了处理这个问题。它的基本假设是：最终答案的复杂度，与其背后的推理成本存在一定相关性。一个严密、复杂、步骤完整的答案，通常不可能以极低的思考成本生成；反过来，一个简单答案也不应被计入异常高的 hidden token 消耗。

基于这一点，GatewayBench 引入 PALACE 与 CoIn 审计机制。PALACE 的思路，是在评测端训练一个反向推理器：它不需要看到网关隐藏的完整思考日志，只需要观察用户 prompt 和最终 answer，就能估算出一个合理的 thinking token 区间。当账单中申报的思考 token 明显偏离这个区间，就会触发计费异常判断。

CoIn 则提供另一层约束。通过把 token 级别的向量指纹组织成可验证的密码学结构，例如 Merkle Tree，使计费记录更难被事后篡改。

这样，GatewayBench 可以试图验证一个问题，即这笔账是否与模型实际生成过程相匹配，是否存在隐藏 token 的异常申报。

这类审计的意义在于，推理模型时代的计费不再只发生在用户可见的文本里。真正的成本可能藏在看不见的 thinking tokens 中。GatewayBench 要解决的，是如何让不可见的推理成本重新变得可质疑、可验证、可追责。

3. 缓存欺诈：验证折扣返还与账号隔离

Prompt cache 是 AI Gateway 降低成本、提升速度的重要机制，命中缓存的请求通常能获得 2 折左右的骨折价。但它也制造了新的灰色地带：中转商可能拿到上游缓存折扣，却继续向用户按全价收费；也可能为了提高命中率，把不同用户的 prompt 放进共享缓存池，用隐私隔离换成本优势。

因此，缓存问题不再只是单纯的性能或价格问题，而是同时指向账单可信度和数据隔离边界。一个 Gateway 可以用缓存省钱当然是好事，但必须证明这笔节省真实返还给用户，并且没有通过跨账号共享上下文来套利。

GatewayBench 的方法，是用延迟指纹来验证缓存账单。账单里的 cached_tokens 可以伪造，但缓存命中带来的低延迟很难伪装。如果账单显示命中缓存，TTFT 却仍然明显偏高，就说明所谓缓存折扣可能只是账面数字，实际计算并没有省下来。

此外，GatewayBench 还会做跨账号隔离探测：先用账号 A 发送一段极罕见长文本建立缓存，再用账号 B 发送同样内容。如果 B 出现异常低延迟（首字延迟 TTFT 掉进 50 毫秒以内），就说明两个账号可能共享了缓存上下文。这个测试直接击中了缓存优化背后的隐私风险。

缓存是一把双刃剑。它可以让系统更快、更便宜，也可能让账单更不透明、隔离边界更模糊。GatewayBench 把缓存纳入可信度审计，本质上是在要求网关证明一件事：你省下来的成本，不能来自用户看不见的账单造假和数据混用。

大模型可信度的核心在于生成的过程，即GatewayBench 关注的是这个答案是不是由承诺的模型、以承诺的成本、在承诺的隔离条件下生成的，这才是真正的供应链可信。

L2：性能不等于峰值，而是按时交付

只有通过 L1 可信度审计的网关，才有资格进入性能与性价比的比较。

在大模型基础设施生态中，性能一直是中转站和聚合 API 厂商最愿意强调的指标。「全网最快」、「单并发 150 tokens/s」这类表述并不少见。但 GatewayBench 在设计指标体系时，对性能保持了相当克制的权重分配：L2 性能只占综合评分的 20%。

原因很简单。速度当然重要，它决定了系统是否具备基本可用性，也能淘汰掉频繁卡顿、长尾失控的服务。但速度不应该超过可信度和经济性。一个网关即使跑得很快，只要存在模型替换、账单注水或缓存不透明，就无法成为可信的企业级基础设施。

因此，GatewayBench 不追逐单点峰值，而是把性能拆成更贴近生产环境的问题：延迟决定用户等多久，Goodput 衡量在延迟红线内还能交付多少有效产能，长上下文测试则观察系统在重负载下如何退化。

这套设计背后的前提是：性能是门槛，但绝非终点。企业真正购买的是在可信前提下稳定、按时、可预期的交付能力。

1. 延迟与 Goodput：满足 SLO 的吞吐才是有效产能

在商业级 AI 系统里，不谈延迟的吞吐没有太大意义。聊天场景中，迟到意味着用户流失；Agent 场景中，迟到意味着任务链中断；自动化交易或风控场景中，迟到甚至可能错过关键的决策窗口。大模型服务的核心能力，考验的并非单位时间内能吐出多少 token，而是在业务可接受的时间内，稳定交付多少结果。

GatewayBench 的方法是，先用延迟指标定义可用，再用Goodput计算可用状态下还能交付多少，这比单纯看 tokens/s 更接近企业采购时真正关心的问题。

在大模型系统里，延迟早已无法用一个单一数字概括，而是被解构为四维坐标：

• TTFT（首字延迟）： 衡量第一个 Token 出现的耗时，决定用户交互的第一体感。

• TPOT / ITL（字间延迟）： 衡量 token 之间的间隔，判断流式输出是否顺滑。

• TTFA（首个有效答案延迟）： 衡量推理模型中用户看到第一条有效答案的时间，避免 hidden thinking tokens 扭曲体感。

• E2E Latency（端到端总时间）： 衡量整个请求从开始到结束的总耗时，适合非流式和批处理场景。

这种拆解的必要性在于，承认慢在生产环境里有不同的形态。一个系统可能首字很快，但后续输出卡顿；也可能空载时表现不错，一到并发压力下 P95、P99 长尾全面失控。平均值很难暴露这些问题，分层延迟指标才能定位真正的体验缺陷。

在此基础上，GatewayBench 引入 SLO （服务等级目标）作为业务红线。企业可以规定，例如 P95 TTFA 必须小于 1.5 秒，P95 E2E 必须小于 8 秒，流式输出不能出现明显抖动。Goodput 就建立在这条红线之上：只有在满足 SLO 的前提下交付的吞吐，才算有效产能。

这也是 Goodput 的关键含义。并发上升时，网关即使仍在输出 token，只要排队导致首字变慢、流式卡顿或端到端延迟越线，这部分产出在商业上就不再有效。因此，这个指标测的并非系统空载时的峰值速度，而是在真实压力下还能按时交付多少。对企业来说，买的也正是这种能力。

2. 长上下文：从退化曲线看真实调度能力

短文本响应快，并不能证明一个网关具备企业级能力。很多服务在处理日常聊天时表现很好，但一旦进入 RAG、长文档分析或复杂 Agent 场景，输入长度从 1k 上升到 10k、100k，系统压力表现会完全不同。

原因在于，长上下文消耗的并非普通的请求资源。它会显著增加 Attention 计算和 KV Cache 显存占用，也会影响排队策略、并发隔离和资源调度。也就是说，输入长度一旦进入 100k 级别，网关面对的就不再是更长的文本，而是完全不同的资源压力。

GatewayBench 设置 1k、10k、100k 三档输入长度，目的并不是要求长文本和短文本一样快，而是观察系统系统变慢的方式是否稳定、可解释、可预期。一个健康的系统，会随上下文增长稳定退化，企业可以据此规划容量和成本；反之，不健康的系统则可能在某个长度后突然断崖，P95/P99 长尾失控，甚至日志没有报错，实际业务已经不可用。

这条退化曲线还会暴露两类灰色策略。一类是软限流：面对高资源请求，网关并不直接拒绝服务，而是把它们放进更慢的队列，虽然表面可用，但实际体验被削弱。另一类则是隐性溢价：长上下文用户通常迁移成本更高，也更依赖上下文完整性，因此网关可能对大请求采用更贵的计费、更差的资源池，或不透明的动态调度。通过对比 1k、10k、100k 下的延迟、吞吐和成本变化，GatewayBench 可以观察性能退化与价格变化是否匹配。

因此，长上下文测试测的并非最大 token 容量，而是重负载下的调度诚实度。短文本峰值可以被优化出来，但100k 场景下的退化曲线，才更接近企业真正会遇到的生产压力。

L3 经济性：从标价到真实出账成本

在大模型商业落地的诸多变量中，价格往往是企业最敏感的一项。但 GatewayBench 的判断是：价格虽然最容易被公开标示，也最容易在细节中被重新包装。

因此，GatewayBench 将经济性（L3）赋予 40% 的高权重，与可信度（L1）并列为核心维度。其目标并不是比较价格表上的名义单价，而是帮助企业还原 True Cost per 1M Tokens：把输入、输出、缓存、失败请求、汇率、支付通道和退款条款都纳入之后，企业最终真正支付的成本。

这也意味着，价格透明度本身就是可信度的一部分。 一个网关如果无法清晰拆分定价结构，往往说明它仍有依赖信息不对称获利的空间。价格越模糊，技术降级、服务缩水和账单包装的灰度空间就越大。透明定价并非单纯的财务问题，而是大模型供应链能否被信任的问题。

3.1 明码定价：拆箱「大包价」

中转站行业一个常见做法，是宣传统一混合价，或用固定输入输出比例计算综合价格。这样方便横向比较，但也容易掩盖真实成本。企业调用大模型时，并不存在稳定的标准比例：RAG 和长上下文 Agent 往往是巨量输入、少量输出；代码生成和内容创作则可能是少量输入、海量输出。

混合报价的问题正在这里。 它把输入价、输出价、缓存命中价和缓存写入价压缩成一个数字，看起来简洁，却让企业难以判断成本到底发生在哪里。厂商也可以通过调整不同价格项，让综合价格看起来更有竞争力，同时把成本转移到特定业务场景中。例如压低输出价来优化榜单表现，却抬高输入价，最终让 RAG 用户承担更高账单。

GatewayBench 因此要求四类价格独立上报：输入价、输出价、缓存命中价和缓存写入价。对于 Anthropic 这类按照缓存生命周期区分价格的厂商，还需要进一步拆分不同 TTL 下的写入成本。

这么设计的意义，是让企业回到自己的业务负载里算账。一个做长文档检索的团队，真正关心的并非综合价格是否好看，而是输入和缓存成本会不会吞掉预算；一个做代码生成的团队，则更需要关注输出价格。四轨分报把价格从营销数字，重新拉回到可核算的采购变量。

2. 相对官方价：低价不等于诚实 

传统评测往往默认价格越低越好。但在大模型网关市场里，绝对低价并不总是好信号。GatewayBench 因此引入相对价格比：平台价格 / 官方厂商价格。低于官方价可以视为折扣；高于官方基准 5% 以上且没有公开解释，则会被扣分。

这背后的设计逻辑是，价格应当与技术角色匹配。一个平台如果只是简单转发请求，就很难为额外加价提供理由；但如果它承担了路由、容灾、统一计费、智能降级和多模型调度等能力，适度溢价就可以被视为合理的工程成本。

因此，GatewayBench摒弃了用同一条价格线衡量所有网关，而是根据供应链角色设定不同的容忍区间。聚合路由商提供跨模型调度、多通道容灾和统一账单，收取约 5.5% 的路由费，可以被解释为服务增值。纯透传网关或自部署代理如果没有提供额外能力，合理预期则接近零加价。

这避免了两个极端。过高的价格，如果缺少技术解释，可能只是供应链摩擦；过低的价格，如果明显低于官方成本，也可能是风险信号。网关可能通过模型降级、隐藏扣费、限流或账单不透明来弥补亏损。

因此，相对官方价的意义并不只是比便宜，而是判断价格是否诚实。通过这个指标，GatewayBench 要衡量的，是平台收取的每一部分溢价，能否对应真实的工程价值。

3. 隐性成本：失败扣费、余额约束与支付摩擦

经济性评估中，最容易被忽略的部分，往往不在价格表上。许多网关会用极低的名义单价吸引开发者，但企业一旦接入生产环境，真实成本可能来自一系列更隐蔽的财务摩擦。

第一类是失败请求计费。高并发场景下，部分网关可能出现超时、断流或 5xx 错误。用户没有获得有效输出，但请求仍被计入账单。对企业来说，这会把服务不稳定性转化为额外成本：系统越不稳定，实际单位成本越高。

第二类是账户余额约束。低单价往往伴随较高的充值门槛、不支持提现或退款，甚至存在最低消费、余额过期等条款。名义价格看起来便宜，但资金一旦进入账户，就可能失去灵活性。对采购方来说，这会降低预算可控性，也增加更换供应商的成本。

第三类是外汇与支付成本。对于跨境或多币种结算的企业，网页上的美元标价不一定等于最终支付成本。汇率差、通道手续费和不透明的支付加成，都会把实际单价抬高。如果这些成本没有被纳入评测，价格比较就会失真。

对企业采购而言，大模型基础设施选型关心的往往不是绝对低价，而是成本的可预测性。GatewayBench 的 L3 经济性评测，本质上更接近一套 Forensic Accounting 式的财务审计：通过四轨定价拆开价格结构，通过角色基准定义合理利润，通过隐性成本识别条款陷阱。最终衡量的是每百万 tokens 真正落到企业账单上的实际出账成本。这套框架试图把账单里的模糊空间提前暴露出来，让 AI 的商业成本重新变得可拆解、可解释、可预估。

结语：让诚实交付成为市场优势

 AI 中转站API 不会因为灰色属性而自动消失。只要模型访问仍然存在地区、支付和风控差异，大模型中转站API 市场就会继续存在。关键问题不是否定它的存在，而是让它从黑箱竞争走向透明竞争。

这也是 GatewayBench 的前提假设：承认这种现实需求，同时引入一套标准化的审计框架，让不可见的网关行为变得可验证，让开发者知道自己到底调用了什么、付了多少钱、承担了哪些风险。

但一次接入前评测还不够。要让市场真正变好，关键是把每一次调用留下的记录沉淀为信用。GatewayBench 希望在评测之外，进一步推动大模型网关市场形成一套可持续的履约机制：模型调用、计费记录、缓存命中、延迟表现和异常处理，都可以成为可复查的市场信号。

长期稳定、透明、诚实交付的 Gateway，理应获得更多开发者信任，也应该获得更好的市场分发；频繁出现模型漂移、性能异常或计费争议的服务商，则需要面对更高的信任成本。这不是为了惩罚某一类服务商，而是为了让市场回到更健康的竞争逻辑：真正交付好服务的网关，不应该被只会低价营销的平台掩盖；开发者也不应该在看不见后端的情况下，用业务稳定性和数据安全为黑箱买单。

GatewayBench 审计评测框架已正式上线，并通过官网 Check4U.ai 开放评测入口。 API 中转站、聚合网关和模型服务商均可参与 GatewayBench 公开评测，成为榜单中的公开评测对象。对服务商来说，这是一次用可复查数据证明交付质量的机会；对开发者来说，也意味着在选择第三方网关时，可以获得比宣传语和价格表更可靠的参考。

一个更好的大模型网关市场，不应该只靠宣传语建立信任，而应该靠持续交付沉淀信用。GatewayBench 希望成为这套信用基础设施的一部分，让诚实服务获得更多流量，让透明竞争利好最终用户，也让整个行业向更可验证、更可问责的方向演进。