利益披露：本文最后介绍的中转站是我自己在运营的。前面三分之二的取舍分析对任何人都成立， 你完全可以看完分析之后选择另外两条路——那也是这篇文章想说清楚的事。

调用大模型 API 有三条路，大多数人只比较了价格，然后在别的地方付出了没预料到的成本。

三条路的取舍

路一：直连官方

最干净的一条，也是最应该优先考虑的。你和供应商之间没有中间人，出问题时责任边界清晰， 额度、限速、模型上线时间都以官方为准。

它的实际成本不在价格上，而在这几处：

• 支付方式。 需要能付美元的卡，且部分供应商对特定地区的支付有限制。
• 网络可达性。 从国内直连的延迟和稳定性，取决于你的出口线路，而不是供应商。
• 多供应商的碎片化。 一旦你同时用 OpenAI、Google、Anthropic，就要维护三套 SDK、 三套密钥、三套计费口径。这个成本随供应商数量线性增长，而且很容易被低估。

路二：自己搭网关

用 new-api、one-api 这类开源网关，把多家供应商收敛成一个 OpenAI 兼容接口。 我自己就是这么做的，前面几篇文章都在写这件事。

它解决了碎片化，但把运维责任整个搬到了你身上：

这张表里的每一行，我都单独写过一篇文章，因为每一行我都实际踩过。 如果你打算走这条路，那几篇可以直接拿去用： 部署形态、 流式缓冲、 超时与重复计费、 限流与真实 IP、 证书自动化、 数据库选型。

什么时候值得自建：你有稳定的上游渠道、有运维精力、且用量大到中转的差价能覆盖你的时间成本。 什么时候不值得：你只是想赶紧把功能做出来，网关不是你的核心业务。

路三：用现成的中转站

省掉了运维，代价是你把可用性、计费准确性和数据流向都托付给了运营方。

这条路最大的问题不是价格，是你没有办法验证对方说的话。 几乎每个中转站都说自己"稳定、快速、官方直连"，但这些词没有一个是可证伪的。 所以选中转站真正该看的是：

1. 它敢不敢说自己不做什么。 只讲优点的介绍页，等于没有信息量。
2. 出问题时有没有人。 售后渠道是否真实存在、响应大概多久。
3. 计费是否可对账。 你能不能自己拉到用量明细，而不是只看一个余额数字。
4. 技术细节经不经得起问。 流式是不是真流式、超时怎么配的、限流按什么算—— 这些问题问出去，答不上来的多半没认真做过。

我自己那个站

前面说的第四条——“技术细节经不经得起问”——我把答案提前写好了。

aizhuan.fun 是我自己搭的 new-api 实例。它跑在首尔的一台机器上， 用的是裸二进制 + Caddy + 本机 MariaDB 的组合，不是 Docker。 这个选择的理由、以及上面那张表里六行的具体做法，都在前面那六篇文章里写着—— 你可以拿那些文章当作对这个站的技术审查材料，这也是我写它们的原因之一。

名字的意思：aizhuan = AI + 赚

这个站从一开始就不是给「研究大模型」的人准备的，而是给用大模型干活、并且要靠产出换钱的人准备的。

这解释了它的模型清单为什么长成那样——五个分组里三个是生图和视频，而不是清一色的文本对话模型：

分辨率分组（2k / 4k）单独拆出来也是同一个逻辑：做商用素材的人在乎能不能直接交付， 而不是能不能出个缩略图看看效果。

需要说清楚的一句：这个站提供的是工具和算力，不是收入。 能不能赚到钱取决于你做什么、做得怎么样、有没有出货渠道——这三件事都和 API 没关系。 任何把「接入某个 API 就能赚钱」当卖点的说法都不要信，包括从我这里听到的。 这个品类里充斥着承诺收入的宣传，我不打算加入它们。

如果你的需求是纯文本对话或者代码补全，市面上专做文本的中转可能更划算； 这里的模型覆盖是往内容生产那一侧偏的。

功能一：一个接口，替掉一堆 SDK

这是中转站最实在的价值，也是最容易被"模型多"这种话术盖过去的一点。

功能二：53 个模型，覆盖三类产出

功能三：不只是裸 API

如果只有 API，那和自己搭一个没区别。实际能省事的是这些配套：

第六行值得单独说：前面我列过选中转站要看的四条，其中一条是**「计费是否可对账」—— 你能不能自己拉到用量明细，而不是只看一个余额数字**。按小时粒度的数据导出就是对这条的回答。 这不是我事后找补的说法，那四条标准和这个功能都在，你可以自己对。

功能四：客户端一键接入

不想写代码的话，主流 AI 客户端可以直接一键导入配置，不用手动填 base_url 和 key：

怎么开始

• 直接在 aizhuan.fun 注册，不需要邀请码。
• 注册即送 $1 额度，够把下面的接入示例跑通、把想用的模型挨个试一遍。
• 充值支持微信和支付宝，没有起充门槛。

后两条正好对上前面提出的两个问题。

第三条对应「直连官方」那节说的支付摩擦——不需要能付美元的卡，这是选中转站相对直连的主要实际收益之一。

第二条对应更重要的那个：你没有办法验证一个中转站说的话。 所以别信我上面写的任何一句，用那 $1 自己验：流式是不是真流式、首字节多久、 你要的模型在不在、并发起来会不会掉。验完再决定要不要充钱。

一个中转站敢不敢让你先验证再付费，本身就是个信号。

接入示例

它是 OpenAI 兼容接口，绝大多数客户端和 SDK 改两行就能用：

from openai import OpenAI

client = OpenAI(
    base_url="https://aizhuan.fun/v1",
    api_key="你的 key",
    max_retries=0,   # 按 token 计费的接口，务必显式关掉自动重试
    timeout=600.0,   # 生成慢是正常的，别让客户端先放弃
)

那两行注释不是客套。max_retries 默认是 2，一次超时会让上游生成两次、计费两次—— 这条链路我单独写过一篇， 无论你用哪家中转都建议先看一眼。

我不承诺什么

这一节比上面所有内容都重要，因为它是可证伪的。

• 不承诺 100% 可用。 上游会抖、机房会抽风、模型会临时下线。 我能承诺的是出问题时有人在，以及事后会说清楚发生了什么。
• 不承诺永远最便宜。 中转站的价格随上游成本浮动，任何"永久最低价"的说法都不可信。
• 不承诺模型和官方完全同步。 新模型上线需要时间接入和测试。
• 不承诺替代直连。 如果你有稳定的官方渠道和付款方式，直连仍然是更干净的选择—— 这话写在推广文里看着奇怪，但它是真的。

最后

选哪条路取决于你在乎什么：

• 在乎责任边界清晰 → 直连官方
• 在乎掌控力，且愿意承担运维 → 自建，那六篇文章拿去用
• 在乎尽快开始做正事 → 用现成的，包括但不限于我这个

三条路我都走过，所以这篇文章里没有一句"中转站是唯一选择"。 如果看完你决定自建，我反而挺高兴——那六篇文章就没白写。

相关阅读

• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少
• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法
• 大模型 API 中转的超时与重试：一次 504 可能让你双倍计费

客户端最终只拿到一个响应，你的账单上是两笔。更麻烦的是这件事在监控里几乎看不出来：错误率只涨了一点，成本却在悄悄翻倍。

先纠正一个常见的误解.

网上很多文章会告诉你 nginx 的 proxy_next_upstream 会把超时请求转给下一个上游、导致重复计费。这个说法对 LLM API 来说是不准确的，值得先说清楚，否则你会去改一个本来没问题的配置。

proxy_next_upstream 的默认值确实是 error timeout，但 nginx 从 1.9.13 起有一条额外规则：

非幂等方法（POST、LOCK、PATCH）的请求，一旦已经发送给上游，就不会再转给下一台服务器——除非你显式加上 non_idempotent 选项。

LLM 的 chat completions 走的是 POST，所以 nginx 默认行为是安全的。真正的重复计费来源有两个，都不是 nginx 的默认配置：

1. 有人手工加了 non_idempotent——一些"提升可用性"的高可用教程会教这个，在普通 Web 服务上无害，在按 token 计费的接口上是直接烧钱。
2. 客户端 SDK 自己在重试——这是绝大多数情况的元凶。OpenAI 官方 Python SDK 的 max_retries 默认是 2，重试触发条件包含连接错误、408、409、429 和所有 5xx。nginx 吐的 504 正好落在 5xx 里。

双倍计费是怎么发生的

流式请求几乎不会撞上这个问题

这是很多人不知道的一点，也是"默认就该用流式"的一个纯运维理由。proxy_read_timeout 的官方定义是：

该超时只作用于两次连续读操作之间，而不是整个响应的传输时长。

所以：

• 非流式请求：从发出到收到完整 JSON，中间是一个长长的空隙。生成花 75 秒，就是一个 75 秒的读间隔 → 撞上 60 秒超时。
• 流式请求：token 一个接一个到达，每两次读之间只隔几百毫秒 → 无论总时长多久都不会触发超时。

正确的超时分层

关键是区分"连不上"和"生成慢"：前者应该快速失败，后者必须耐心等。用一个统一的大数字把三个超时都拉长，是把两种完全不同的故障混在一起处理。

location /v1/ {
    proxy_pass http://upstream_pool;

    # 连不上 → 快速失败。请求还没发出去，此时重试是安全的
    proxy_connect_timeout  5s;

    # 发送请求体 → 大 prompt 也就几百 KB，给足但不必夸张
    proxy_send_timeout     60s;

    # 读响应 → 生成慢是正常的，不是故障。这里必须放宽
    proxy_read_timeout     600s;

    # LLM 是非幂等的：绝不要开 non_idempotent
    # 保守起见连 timeout 重试也去掉，只保留连接阶段的重试
    proxy_next_upstream    error;
    proxy_next_upstream_tries 2;
    proxy_next_upstream_timeout 10s;

    # 流式必须配套，否则响应被攒起来又变回一个长读间隔
    proxy_buffering        off;
    gzip                   off;
    proxy_http_version     1.1;
    proxy_set_header       Connection "";
}

客户端侧要做的事

服务端配对了，客户端如果还在盲目重试，问题只是变少而不是消失。

from openai import OpenAI

client = OpenAI(
    base_url="https://your-gateway/v1",
    api_key="...",
    max_retries=0,   # 默认是 2，对按 token 计费的接口必须显式关掉
    timeout=600.0,   # 客户端超时也要放宽，否则轮到它先放弃
)

关掉自动重试之后，重试逻辑要自己写，并且只在明确安全的错误上重试：

更彻底的办法：在中转层做请求去重

如果你控制中转层（自建 new-api 之类就是这种情况），可以在网关上加一层短窗口去重，把重复计费在源头掐掉：

思路是给每个请求算一个指纹——模型名 + 消息体 + 关键参数的哈希——配上客户端标识，在 Redis 里存一个几十秒的短 key。窗口内出现相同指纹时，不再打上游，直接返回上一次的结果或一个明确的"重复请求"错误。

这个做法的取舍要讲清楚：

• 好处：无论客户端怎么重试，上游只被打一次，账单可控。
• 代价：LLM 本身是有随机性的（temperature > 0 时同样输入本该有不同输出），去重会让窗口内的重复请求拿到相同结果。对聊天场景通常无害，对"故意重新生成一次"的功能就是 bug。
• 所以：窗口要短（几十秒量级），并且给客户端一个显式绕过的办法（比如一个请求头或一个随机 nonce 参数）。

怎么发现自己已经在被双倍计费

从日志里找证据，不用等账单。特征是：同一客户端在很短时间内发出内容完全相同的请求，且其中至少一个返回了 504。

# 找 504：如果这个数不是 0，就值得往下查
awk '$9==504 {print $1, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# 找 504 之后紧跟着重试的模式：同 IP、同路径、几秒内连续多次
awk '$9==504 || $9==200 {print $1, $4, $9, $7}' /var/log/nginx/access.log \
  | grep '/v1/chat/completions' | tail -50

更可靠的信号是把上游用量与自己记录的成功响应数对账：如果上游统计的请求数明显高于你返回给客户端的成功数，差额基本就是被白烧掉的重试。

相关阅读

• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 本文说流式不容易超时，前提是流式真的没被缓冲掉
• Caddy 还是 nginx 给 API 中转做反代：证书自动化是决定性差异 —— 另一类会让全部请求一起失败的运维故障
• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 超时配置所在的那层反代怎么部署
• 给 API 中转站选数据库：SQLite / MySQL / PostgreSQL 在小机器上的取舍 —— 本文说的"拿用量日志对账"，那张表本身也会变成问题

这个问题九成不在应用代码里，而在 nginx 的 proxy_buffering 默认是开启的。但真正麻烦的地方是：请求路径上会缓冲的地方不止 nginx 一个，实际有五个，而且其中一个是你用来排查的 curl 自己。如果不知道这一点，你会在错误的层上改半天配置。

先分清 SSE 和 WebSocket

这是配置写错的根源。大模型 API 的流式输出用的是 SSE（Server-Sent Events）：一个普通的 HTTP 响应，Content-Type: text/event-stream，靠 chunked 编码持续往下写。它不涉及协议升级。

而网上大量"流式接口反代配置"教程给的是 WebSocket 的写法：

# ❌ 这是 WebSocket 的配置，SSE 不需要，而且硬编码有害
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

问题出在第二行硬编码了 "upgrade"：它会给经过这个 location 的所有请求都带上 Connection: upgrade，包括根本没有 Upgrade 头的普通请求和 SSE 请求。Connection 是逐跳（hop-by-hop）首部，被这么滥用会破坏到上游的 keepalive，某些上游实现还会因此行为异常。

正确的写法是用 map 按客户端是否真的请求升级来取值：

# http 块内
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# location 内
proxy_http_version 1.1;
proxy_set_header Upgrade    $http_upgrade;
proxy_set_header Connection $connection_upgrade;

如果这个 location 只服务 SSE、完全没有 WebSocket，那更简单——两行都不要写，改成让 nginx 复用到上游的连接：

proxy_http_version 1.1;
proxy_set_header Connection "";

请求路径上真实存在的五个缓冲点

第五个缓冲点最坑人，所以单独强调：curl 默认会缓冲输出。用不带 -N 的 curl 去验证流式，看到的永远是"一次性返回"，无论服务端配得对不对。排查流式问题的第一条纪律是所有 curl 都加 -N（等价于 --no-buffer）。

症状长什么样

用 curl 的计时字段可以把这件事量化，不用凭感觉：

curl -N -o /dev/null -s \
  -w "首字节 %{time_starttransfer}s / 总计 %{time_total}s\n" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","stream":true,"messages":[{"role":"user","content":"数到二十"}]}' \
  https://your-domain/v1/chat/completions

• 首字节 ≈ 总计 → 被完整缓冲了
• 首字节 ≪ 总计 → 流式正常

另一个免费信号在响应头里：

curl -N -D - -o /dev/null -s ... | grep -iE 'content-length|transfer-encoding|content-type'

出现 Content-Length 就说明响应被完整缓冲过——只有知道全部长度才能写出这个头。正常流式应该是 Transfer-Encoding: chunked（HTTP/1.1）或 HTTP/2 的分帧，加上 Content-Type: text/event-stream。

三层二分排查法

不要直接去猜哪一层，按下面这棵树走，两三条命令就能定位。核心思路是从最里层往外逐层加一跳，第一次出问题的那跳就是元凶。

nginx 侧的完整配置

location /v1/ {
    proxy_pass http://127.0.0.1:3000/v1/;

    # 关掉响应缓冲 —— 解决问题的主开关
    proxy_buffering    off;
    proxy_request_buffering off;
    proxy_cache        off;

    # gzip 压缩也会攒数据，流式 location 里必须关
    gzip               off;

    # chunked 需要 HTTP/1.1；清空 Connection 让 nginx 复用上游连接
    proxy_http_version 1.1;
    proxy_set_header   Connection "";

    # 长生成会超过默认的 60s，放宽读超时
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;

    proxy_set_header   Host      $host;
    proxy_set_header   X-Real-IP $remote_addr;
}

几个容易漏的点：

• gzip off 不是可选项。 nginx 的 gzip 模块要攒够数据才能压缩，开着它等于重新引入缓冲。很多人只关了 proxy_buffering 就以为完事，结果症状减轻但没消失，就是 gzip 在作祟。
• proxy_read_timeout 默认 60 秒。 长上下文生成很容易超，超了会收到截断的响应或 504，且现象酷似"流式坏了"。
• proxy_request_buffering off 管的是请求方向，上传大 prompt 时有用，和响应流式无关但顺手一起配。

不想改 nginx 配置？用响应头

如果你没有 nginx 的配置权限，或者不想为一个接口改全局配置，应用可以自己让 nginx 关掉缓冲——返回这个响应头：

X-Accel-Buffering: no

nginx 识别这个头并对该响应禁用缓冲。这是 nginx 特有的机制，非常实用：开关从运维侧移到了应用侧，随代码走，不会因为换机器忘配而复发。

Caddy 侧

Caddy 的 reverse_proxy 对 text/event-stream 会自动刷新，多数情况下开箱即用。如果确实需要强制：

your-domain.com {
    reverse_proxy 127.0.0.1:3000 {
        flush_interval -1
    }
}

flush_interval -1 表示每次写入立即刷新。另外 Caddy 默认会对文本类型启用压缩，如果显式配了 encode gzip，记得把流式路径排除掉，理由和 nginx 的 gzip off 一样。

应用侧：反代配对了也可能不流式

如果排查树的第一步就不通过，那是应用自己没有 flush。反代关掉缓冲只是"不主动攒"，它没法把应用攒着不发的数据变出来。Go 里的标准写法：

func stream(w http.ResponseWriter, r *http.Request) {
    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "streaming unsupported", http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("X-Accel-Buffering", "no") // 顺手把 nginx 也关掉

    for chunk := range chunks {
        fmt.Fprintf(w, "data: %s\n\n", chunk)
        flusher.Flush() // 少了这行，前面全白配
    }
    fmt.Fprint(w, "data: [DONE]\n\n")
    flusher.Flush()
}

注意 w.Header().Set 必须在第一次 Write 之前调用，否则不生效——这是另一个安静失败的经典来源。

相关阅读

• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 反代前面那一层，部署形态怎么选
• API 中转站的限流为什么不能信 X-Forwarded-For —— 本文配置里那行 X-Real-IP 为什么不能省