随着大语言模型在编码、Agent（智能体）等场景中的深入应用，开发者对多模型、低成本、开箱即用的模型 API 需求持续增长，大模型中转站逐渐成为连接开发者与模型服务的重要基础设施。中转站对外提供与主流模型 API 兼容的统一接口，将不同模型厂商的服务进行聚合，调用者通常只需修改模型名称即可完成切换。

与直接调用模型厂商官方 API 不同，开发者在使用中转站时，实际上将原本直接发生在「用户—模型厂商」之间的调用链路，变成了「用户—中转站—模型厂商」的多级链路。中转站不仅承担请求转发功能，还可能参与模型路由、请求处理、日志记录与响应处理等环节，而这些过程对调用者通常不可见。因此，中转站带来的风险并不局限于接口可用性与调用稳定性，还可能延伸至数据安全、模型真实性、请求完整性以及供应链安全等方面。

基于此，本次测评选取 100 个具有代表性的大模型中转站作为测试对象，围绕 26 类主流模型形成 849 个模型—中转站测试组合，通过 19 项黑盒检测器，从基础能力、站点安全性、模型一致性、响应完整性和服务稳定性五个维度对中转站的实际服务进行验证。

测评结果显示，中转站的质量呈现明显的两极分化：共发现 135 个测试组合实际不可用，涉及 45 个站点；296 个测试组合存在至少一项模型真实性异常证据，涉及 75 个站点；110 个测试组合存在隐藏指令注入现象；239 个测试组合存在明显延迟异常。部分站点还同时出现模型不可用、模型偷换、请求注入、上下文截断、限流及高延迟等多类问题。

本次测评并非仅关注中转站能否正常调用模型，而是从黑盒调用链路出发，通过多种相互独立的检测手段交叉验证中转站的实际行为，综合评估其在实际使用过程中的服务质量与安全风险，为开发者选择和使用中转服务提供参考。完整的方法论、测评结果以及全部 100 个受测中转站的综合评分、站点等级和五个检测维度得分，请参阅榜单和完整版报告：

在线榜单：https://ai.trusttools.cn/benchmark

GitHub 完整版报告：https://github.com/AITrustTools/llm-relay-assessment

中转站位于开发者与模型服务商之间，是对外提供主流模型 API 兼容接口的中间层。表面上，中转站主要承担模型接入、切换与请求转发；但从实际架构看，请求通常还需经过身份认证、参数解析、模型路由、内容检测、额度控制等环节，响应则可能经过二次处理、日志记录和计费统计后再返回用户。在 Claude Code、Codex 等 Agent 场景下，请求和响应还可能包含代码、文件内容、工具调用参数及业务上下文，使中转站处于敏感的数据与控制链路之中。

因此，中转站的核心问题并不仅在于能否正常调用模型，更在于整个调用链路是否可信、完整和可靠。围绕这一链路，本报告将风险划分为站点侧、请求侧、响应侧和服务侧四个维度：站点侧关注中转站自身的可信性，包括是否存在威胁情报标记、恶意或投毒记录，以及 TLS 加密是否有效；请求侧关注用户请求在转发过程中是否被完整、准确地传递；响应侧关注返回内容及相关元数据是否保持完整、有效；服务侧则关注调用过程中的稳定性与可用性。

以模型偷换为例：用户通过 OpenAI 协议指定 model 字段请求某一模型，但中转站可依据内部路由策略，将请求转发至价格更低或能力不同的替代模型，并在返回时将 model 字段改回用户请求的名称。这样，用户从 API 请求和响应表面均难以发现异常，实际调用的模型却已经发生变化。

类似风险还包括上下文截断（在转发前压缩、截断或摘要用户输入以降低上游 Token 消耗）、模型降级（以低能力版本冒充 Pro/Max 等高规格模型）、隐藏指令注入（在请求中暗加系统指令或控制内容）、真假模型路由（依据用户、请求特征或调用时间动态切换后端）、参数透传缺失（结构化输出、推理强度等参数未传递至上游）以及响应注入与投毒等。

1.1 中转投毒与数据窃取

2026 年 4 月，来自 UC Santa Barbara、UC San Diego 等机构的研究人员发表《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》，对 428 个第三方大模型中转站进行系统性测试，结果显示有 9 个中转站主动向 Agent 的响应中注入恶意代码，共计 26 个中转站存在访问测试环境敏感凭证的行为，该研究同时验证了针对 Agent 工具调用链路的攻击方式。由于中转站能够接触传输过程中的完整 JSON 数据，其具备修改模型响应和 Tool Call 的能力。

2026 年 8 月，国内论坛有用户发帖反映，在使用 Agent 编写代码时发现模型思维链中存在投毒内容：在正常命令后拼接了大量窃取数据的命令，并发送至攻击者控制的服务器。

1.2 中转数据售卖与凭证泄露

该研究的作者还披露了另一类风险：中转站管理者可能将用户历史对话数据直接作为商品售卖。据其描述，其曾从一家头部中转站服务商处购买约 6TB 的数据集，其中包含大量用户历史数据以及 SSH 密钥、VPN 配置、云服务访问密钥等敏感凭证。

中转站内部的路由策略、请求处理逻辑与模型供应关系对用户不可见，无法通过直接检查其内部配置判断其是否按用户预期提供服务。因此，本次测评将中转站视为黑盒系统，以用户实际可观测的请求、响应及服务行为作为检测依据，针对特定测评目标构造测试输入，并将实际观测结果与目标模型或标准协议的预期行为进行对比。当中转站的实际行为与预期存在稳定、可重复的差异，且多个相互独立的检测手段给出一致结论时，即可据此判断相应环节存在异常。

测评从基础能力、站点安全性、模型一致性、响应完整性和服务稳定性五个维度建立检测体系，共设计 19 项检测器，其中模型一致性检测为重点。由于不同模型在调用形式与参数支持上存在差异，测评框架以模型为基本单位，为每个模型独立编排检测策略，相同模型在统一配置、统一方法下完成测试。各检测器归属的一级维度、检测内容及适用范围如下表所示。

注：本表所列检测器构成与适用范围为本次测评执行时的实际状态，后续检测规则可能持续优化迭代，适用范围、检测方式亦可能随之调整，以最新版本为准。

上述检测均在测试端以黑盒方式完成，测评无法直接获取中转站内部路由策略与调用日志，部分结果属于基于外部行为特征的间接判断。对于模型偷换等高风险结论，本报告均以多个相互独立的检测结果交叉验证为前提；「未发现异常」仅表示在本次测试范围与条件下未观察到足以支持该风险判断的证据，不代表确认不存在该风险。

本次测评共纳入 100 个大模型中转站，样本覆盖国内运营与海外运营两类服务市场，各占 50%，并同时覆盖企业运营与非企业运营两类服务主体。国内运营样本主要包括面向国内用户提供 GPT、Claude、Gemini 等模型服务的中转平台，海外运营样本主要涵盖面向境外用户提供模型 API 聚合与中转服务的平台。

测评围绕 26 类主流模型，共形成 849 个模型—中转站测试组合，受测模型覆盖 OpenAI、Anthropic、DeepSeek、智谱（Z.AI）、Qwen、Gemini、MiMo、xAI 等主要厂商。针对不同中转站提供的相同模型，在统一的探针、测试流程及判定阈值下开展重复测试，以保证不同站点之间的结果可横向比较。

4.1 实际可用模型与宣称不一致

实际不可用是本次测评中覆盖范围最广的一类问题。当同一模型的 OpenAI Chat、OpenAI Responses、Anthropic Messages 三类协议探针均调用失败时，该测试组合被判定为实际不可用。本次测评共发现 135 个测试组合实际不可用，涉及 45 个中转站，模型服务的实际可用性与站点对外宣称情况之间存在明显偏差。

不可用问题高度集中于少数站点：受测模型不可用数量最多的数个站点，其不可用比例均超过受测模型总数的一半，个别站点达到约 80%。上述站点均对外展示了较为完整的模型列表，并以「官方渠道」「全系列模型可用」「企业级稳定性」等宣传吸引用户，而用户通常在充值后的调用过程中才会发现其中的虚假宣传。

进一步分析发现，模型不可用与其他异常问题具有较强的共现关系：存在不可用模型的 45 个站点中，绝大多数同时存在其他异常证据，部分站点同时出现模型偷换类证据。这表明部分站点的模型不可用并非孤立的单一服务异常，而是与模型供给、模型路由及服务实现等问题同时存在。

4.2 普遍存在的模型偷换现象

模型偷换是本次测评中最为突出的一类风险，849 个受测组合中共有 296 个组合命中至少一项模型真实性异常证据，涉及 75 个中转站，共获取 467 条可疑证据和 138 条强证据，表明模型真实性问题并非个别站点的偶发异常。从价格维度看，部分中转站提供的海外高端模型价格甚至低于原生 API 价格数十倍，这种显著价差与模型厂商的服务区域限制共同构成了模型偷换的经济动机。

在显式身份信息方面，26 个站点的 43 个测试组合中，模型自报身份与用户请求模型不一致。其中 8 个站点的 11 个组合在 response model 字段中持续返回与请求模型不一致的模型名称。

行为指纹的统计性偏离提供了更大范围的证据：基于随机偏好分布的序贯检验结果显示，159 个测试组合明确拒绝了其输出分布与官方模型一致的假设，涉及 67 个站点，异常主要集中于 Claude 系列与 GPT 主力型号。Tokenizer 特征检测也在 63 个站点的 124 个测试组合上判定异常，即受测服务无法复现所声明模型原生 Tokenizer 的特定 Token 行为。

部分中转站还在后端按用户、请求特征、调用时间等条件在真假模型之间动态路由，导致相同输入在不同时间表现出明显不同的能力特征，仅凭单次调用难以确认获得的是稳定一致的模型服务。

4.3 请求注入与篡改

本次测评共发现 110 个测试组合存在隐藏指令注入现象，其中 62 个组合明确判定异常，额外输入 Token 数量的中位数为 496；186 个组合的输入 Token 规模与官方模型基线存在明显偏离；31 个组合在上下文完整性检测中无法完整找回预先埋入的隐藏标记，其中 28 个组合进一步确认存在上下文压缩或截断问题。

典型情形包括：个别组合的额外注入规模达数千 Token，输入 Token 总量中有九成以上为额外注入内容；部分站点的长文本请求在多个测试档位中实际输入较少，远低于官方基线，存在明显的输入内容丢失；个别站点的全部受测 Claude 模型均未找回任何预先埋入的隐藏标记，表明其长文本请求处理存在一致性截断。

这意味着用户发送给中转站的原始请求，并不一定以完整、原样的形式传递至上游模型。对于依赖复杂 Prompt、长上下文或 Agent 工作流的应用，这类请求链路中的隐式修改可能直接影响模型的最终行为，且用户往往将由此导致的能力下降归因于模型本身。

4.4 高延迟、低成功率与资源限制

服务稳定性问题同样突出。请求延迟检测覆盖全部 849 个测试组合，其中 239 个组合判定为异常，涉及 72 个站点；请求成功率检测覆盖 714 个具备有效统计的组合，其中 23 个组合的成功率低于 50%。站点层面的 P95 延迟中位数从约 1 秒至超过 100 秒，差距达两个数量级：响应较快的站点与官方直连 API 水平接近，而延迟最高的站点 P95 延迟中位数超过 100 秒；部分异常组合的生成吞吐中位数仅 0.1～0.7 token/s，难以满足交互式应用的基本要求。

高延迟问题集中于通过反向代理提供海外模型的场景：239 个延迟异常组合中，Claude 系列占 119 个、GPT 系列占 56 个。成功率方面，个别站点的整体请求成功率不足 25%，另有多个站点低于 90%。此外，16 个站点反复出现 429 限流或上游额度异常，部分站点的错误信息明确指向共享上游账号的额度限制，甚至有站点在触发限流后对后续请求实施超过 20 小时的持续限制。

值得注意的是，部分站点的上游账号及密钥获取途径并非正规渠道（如泄露凭证、共享账号、虚拟卡套利、模型逆向等），上游可用性与合法性存在大量不稳定因素，相关限制在站点的对外服务信息中也往往未作说明，用户仅在实际调用中才会发现服务能力与页面展示之间的差距。

4.5 多供应商模型表现存在差异

用户通常更容易信任规模较大、模型覆盖广且服务稳定的中转站，但从技术架构看，规模并不能直接证明其上游模型来源与请求处理过程透明。大型平台采用多供应商架构，同一模型名称下可接入多家模型供应商，平台按价格、延迟、吞吐及故障情况进行动态选择与切换。测评中即观察到部分大型平台的单一模型下接入十余家供应商。

这种机制提高了服务可用性，但也意味着用户请求的是同一个模型名称，实际承担推理任务的可能是不同后端供应商，其模型版本、推理环境、量化方式与数据处理策略均可能存在差异。测评结果显示，大型中转站并未因规模与品牌自然获得与规模相匹配的绝对优势；相反，将多供应商平台的供应商限定为单一后端后，其模型稳定性和一致性均明显提升，测评分数显著高于默认负载均衡策略。

4.6 运营属性与质量风险

将 100 个站点按运营区域与运营主体交叉分组后，可以观察到明显的风险差异：海外企业群体的站点综合得分中位数为 80.3，S 级站点 4 个，D 级仅 2 个；国内非企业群体得分中位数仅 68.0，无 S 级站点，D 级多达 10 个；海外非企业群体虽然站点最少，但问题密度最高，13 个站点中有 6 个落入 D 级。

非企业与延迟问题的关联尤其显著：非企业站点的组合级延迟判负率高达 39.2%，企业站点仅为 19.5%；延迟判负的 239 个组合中有 144 个集中于非企业站点，其中国内非企业群体贡献 115 个，接近全部延迟判负组合的一半。模型偷换与 Tokenizer 替换在不同群体中的分布也呈互补特征：行为指纹偏离主要集中于国内站点，而 Tokenizer 替换主要发生于海外企业站点，说明国内以非企业为主的小型站点更倾向于直接替换模型后端，海外企业供应商则更多出现模型版本或供应商层面的近似替代。

基于前述各项测评结果，按照统一评分规则对 100 个中转站进行综合评价，并根据最终得分划分站点等级。综合评分在汇总各模型测评结果的基础上，同时考虑站点的测评覆盖规模与实际测评表现，引入基于样本规模的收缩机制，避免受测模型数量较少的站点仅凭少量高分模型获得过高排名，经测试确认不可用的模型同样按测评失败结果计入评分。

排名前十的站点及其各维度得分见下表：

注：各维度得分为该维度下已执行检测项在站点全部受测模型上的平均分；综合评分计算请参考完整版报告。

综合本次对 100 个大模型中转站的测评结果可以看到，中转站的主要风险来自其作为用户与上游模型之间的黑盒中间层，用户无法直接确认实际调用的模型、请求是否被完整转发以及请求最终由哪个上游后端处理。风险并非单一模型或单一接口问题，而是贯穿模型供应、请求处理和服务交付等多个环节。

从结果分布看，模型服务与模型真实性方面，模型列表和模型名称本身并不足以证明中转站实际提供了对应模型，296 个测试组合的真实性异常证据表明，模型真实性仍需通过持续的行为测试进行验证；请求完整性与服务稳定性方面，隐藏指令注入、上下文截断以及延迟与限流问题在部分站点集中出现，直接影响依赖复杂 Prompt、长上下文或 Agent 工作流的应用；多供应商与动态路由方面，站点规模和供应商数量并不能直接等同于模型服务的可信度；运营属性方面，运营区域、企业属性和站点规模只能作为辅助判断因素，不能替代技术测评。

对于开发者而言，仅依据模型列表、价格和站点宣传难以判断实际服务质量。建议在选择中转服务时，将模型真实性与请求完整性等技术指标纳入评估范围，优先参考模型价格合理、经过多维度、可重复测试验证的站点，并结合具体模型的测评结果进行选型决策；必要时可通过短探针、usage 对比、Tokenizer 探针等方式对所使用的中转服务进行自行验证。

本文仅呈现排名前十的站点及各维度得分。完整方法论与全部 100 个受测中转站的综合评分、站点等级及五个检测维度得分，请查阅完整版报告。

[1] https://www.alphaxiv.org/abs/2604.08407

[2] https://www.tomshardware.com/tech-industry/artificial-intelligence/chinese-grey-market-sells-claude-api-access-at-90-percent-off-through-proxy-networks-that-harvest-user-data

[3] https://arxiv.org/pdf/2607.10252

[4] https://zenodo.org/records/21278557

[5] https://platform.claude.com/docs/en/api/messages

[6] https://developers.openai.com/api/reference/resources/responses/methods/create

[7] https://developers.openai.com/api/reference/resources/chat

[8] https://github.com/canarybyte/veridrop

[9] https://github.com/Mohamed7415/fpverify

[10] https://x.com/shoucccc/status/2098169782541631871

[11] https://apito.ai/zh/blog/getting-started/how-to-verify-claude-api-authenticity-fingerprint-detection

[12] https://transformers.run/c2/2021-12-11-transformers-note-2/

[13] https://github.com/october-coder/api-check