API 中转站是什么：工作原理、常见风险与选择清单

一次请求在中转站里走过的路

先把名词说清楚。所谓“中转 API”，是指在你的程序和真正跑模型的后端之间，多放一个对外暴露标准接口的网关。你的代码仍然按 OpenAI 的格式发请求，只是把 base_url 指向网关地址，把密钥换成网关发给你的那一把。

网关在这一跳里通常做三件事。

• 请求转发：校验请求体格式，必要时补全默认参数，再把请求交给后端；后端返回的内容（包括流式的 SSE 分片）原样或轻度加工后回传给你。
• 密钥映射：你持有的是网关签发的密钥，它只在网关里有意义。网关据此识别你是谁、余额多少、能调用哪些模型；真正与后端打交道的凭据始终留在网关内部，不会出现在你的代码里。
• 计费与限流：每个请求返回后，网关按 usage 里的输入、输出 token 数乘以单价扣减余额，同时按密钥统计每分钟请求数，超出就返回 429。

把这三件事串起来看，就能理解为什么中转站的体验差异很大：转发层的实现决定了延迟抖动和流式是否稳定，密钥层决定了泄露后的损失范围，计费层决定了账单是否透明可对账。

和单一模型直连服务有什么区别

直连服务指的是你直接向模型提供方的官方域名发请求，通常一个账号对应一套模型、一套计费规则、一份文档。中转服务则有两种常见形态，区别在于“后面接了多少东西”。

维度	直连单一服务	聚合型中转	单模型中转
模型数量	提供方自家的几个	几十个甚至上百个	一个
接口格式	各家自有格式	统一成 OpenAI 兼容	OpenAI 兼容
排障难度	最低，链路最短	最高，模型名映射多	较低，只有一个模型
适合场景	只用一家的稳定业务	需要频繁换模型对比	固定模型、追求可预期

如果你的业务只依赖一个模型，聚合的好处就用不上，反而要承担“模型名对应到谁”的不确定性。反过来，如果你每周都要换模型做对比测试，聚合型会省掉很多适配工作。没有绝对的优劣，关键是搞清楚自己属于哪一类。

本站属于最后一种：只提供一个模型，模型 id 为 uncensored，接口是 OpenAI 兼容的对话补全。这类取舍和成本的讨论，可以接着看 无限制 AI API 的成本与权衡。

三类最常见的风险

密钥安全

中转密钥等同于一张预付费的储值卡，谁拿到就能花你的余额。常见的泄露路径有：把密钥写进前端代码、提交到公开仓库、粘贴进工单或群聊截图。建议只放在服务端环境变量里，前端永远通过你自己的后端转一次；怀疑泄露时立刻重置，旧密钥应当马上失效。同时留意服务是否允许你自助重置，以及重置后旧密钥是否即时作废，而不是“过几个小时才生效”。

模型被替换

这是聚合型服务里被讨论最多的问题：你请求的是 A，实际返回的却是更便宜的 B。它很难靠文档判断，只能靠行为验证。可以固定一组带标准答案的小题、固定 temperature 反复测试，观察输出风格是否稳定；也可以请求 /v1/models 看清单是否与计费页一致。模型名称含糊、同一个名字不同时间表现差异很大，都值得警惕。

限速不透明

有些服务在文档里只写“合理使用”，实际在高峰期悄悄降速或直接丢请求，你的程序表现为偶发超时。成熟的做法是把每个密钥的每分钟请求数写明，超限时返回规范的 429，而不是让连接挂起。选型时务必问清：限流按密钥还是按账号，超限返回什么，余额用完是否返回独立的错误码。

选择中转服务的检查清单

下面这份清单可以直接复制到你的评估文档里，逐项打勾。

1. 是否提供公开的 GET /v1/models，返回的模型清单与定价页一致？
2. 错误响应是否是结构化 JSON，包含 code 与 message，并且 401、402、429、503 各有区分？
3. 每个密钥的每分钟请求上限是否写在文档里，而不是只在客服口中？
4. 上下文长度、单次最大输出 token、请求体大小是否有明确数字？
5. 计费是否按 usage 里的 token 数精确扣减，余额是否可随时查看？
6. 预付费余额是否会过期？试用额度的有效期是否写清？
7. 密钥是否可自助重置，旧密钥是否即时失效？
8. 是否支持流式输出，最后是否带有 usage 统计，方便你自己对账？
9. 关于提示词是否用于训练，是否有明确的一句话说明？
10. 不支持的能力（例如向量、图像、语音）是否如实标注，而不是含糊其辞？

满分并不现实，但前五项里只要有两项答不上来，就建议先小额试用，不要一次充大额余额。

拿到密钥后的十分钟验证

不管选哪家，上线前都值得花十分钟做最基础的验证。第一步，列出模型清单，确认返回的 id 和你预期一致：

复制curl -s https://api.llmzhongzhuan.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

第二步，发一个小请求，同时观察响应里的 usage 字段是否存在、数量是否合理。下面的例子故意让模型复述日期，用来观察它是否会编造它无从得知的信息，这是一个粗略的行为检查，不是严格评测：

复制curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "用一句话介绍你自己，然后复述今天的日期是几号。"}],
    "max_tokens": 200
  }' 

把这两步写进你的部署脚本里，每次换密钥或换服务时跑一遍。如果响应里没有 usage，或者 usage 的数字与输入长度明显对不上，就说明计费透明度有问题，需要在大额使用前先弄清楚。想了解如何在各类框架里接入，可以看 框架配置指南。

本站的参数，便于你对照清单

这里把本站的实际参数列出来，方便你拿上面的清单逐项核对，不用来回翻文档。

• 接口地址：https://api.llmzhongzhuan.com/v1，支持 POST /v1/chat/completions 与 GET /v1/models，鉴权使用 Bearer 密钥。
• 只有一个模型，id 为 uncensored；仅限文本，没有向量、图像、语音、视频和微调。
• 上下文共 100,000 token（输入加输出），max_tokens 默认 2048、单次最高 16,000；请求体不超过 8 MB。
• 每个密钥每分钟 300 次请求，超限返回 429；503 的 upstream_busy 表示稍后重试即可；余额用完或试用过期返回 402 的 no_credit。
• 价格为输入每百万 token 0.25 美元、输出每百万 token 1.00 美元，预付费充值，无订阅，余额不会过期。
• 提示词不会被用于训练。

具体数字以 定价页 和 文档 为准。新账号有 0.50 美元试用额度，有效期 7 天，注册不需要填写支付信息，可以先用它走完上面的验证流程。