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

调用大模型 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 可能让你双倍计费

先给一个锚点。我实测一台 2 核 2G 的云主机，上面跑着 nginx、Redis 和两个 Go 服务，MariaDB 的进程 RSS 是：

mysql  14.5%  291932 KB  /usr/libexec/mariadbd

285 MB，是这台机器上最大的单个进程。而整机 available 只有 1.1 G。换句话说，你还没开始跑业务，数据库已经拿走了四分之一的可用余量。

选型的真正依据：写入量 ≈ 请求量

在动手比较之前，先想清楚 API 中转站的负载长什么样，否则比较是没有意义的。

• 读：API key 校验、用户配置、配额查询。数据量小、可缓存、频率高——三种数据库都轻松应对，不构成差异。
• 写：每次请求落一条用量/计费记录。这是全部的关键：写入速率基本等于请求速率。

所以问题可以化简成一句：你每秒有几次请求？

大多数个人自建的中转站落在第一档，很多人却直接上了 MySQL——在小机器上这笔开销是白花的。

三种数据库的内存画像

并发写入模型的差异

SQLite：如果选它，这几个 pragma 不能少

默认配置的 SQLite 在并发场景下表现很差，而这常被误当成"SQLite 不能上生产"的证据。实际要配的就几行：

PRAGMA journal_mode = WAL;      -- 读写不再互相阻塞。默认的 delete 模式才是性能灾难
PRAGMA busy_timeout = 5000;     -- 遇锁等 5 秒而不是立刻报 SQLITE_BUSY
PRAGMA synchronous = NORMAL;    -- 配合 WAL 的合理折中
PRAGMA foreign_keys = ON;       -- 默认是关的，很多人不知道
PRAGMA cache_size = -32000;     -- 负数表示 KB，这里约 32 MB

其中 busy_timeout 是最容易漏、后果最直接的一条。不配它，两个并发写会有一个立刻收到 SQLITE_BUSY 失败——表现出来就是"偶发写入失败"，而你会以为是 SQLite 不稳定，其实只是它在如实告诉你"锁被占了"，而你没让它等。

synchronous = NORMAL 的取舍要说清：配合 WAL 时它能抵御应用崩溃，但操作系统崩溃或断电可能丢掉最近几个已提交事务。对用量日志这种损失几条可接受的数据没问题；如果这张表直接用于扣款对账，就该用 FULL。

备份不能直接 cp。 WAL 模式下 -wal 文件里有还没合并进主库的数据，直接复制主文件会拿到一个不一致的快照：

# ✓ 正确
sqlite3 /path/to/app.db "VACUUM INTO '/backup/app-$(date +%F).db'"

# ❌ 错误：WAL 模式下这样拷出来的库可能缺最近的写入
cp /path/to/app.db /backup/

MySQL / MariaDB：小机器上的调优

如果已经在用 MySQL 系，285 MB 是可以压下来的：

[mysqld]
# 关掉它就能省几十 MB，个人站几乎不需要
performance_schema = OFF

innodb_buffer_pool_size = 96M
innodb_buffer_pool_instances = 1    # 池子小的时候拆成多个实例反而浪费
innodb_log_file_size = 32M

# 每个连接都要分配缓冲区，这个数不是免费的
max_connections = 30

key_buffer_size = 8M
tmp_table_size = 16M
max_heap_table_size = 16M

performance_schema = OFF 是性价比最高的一条——它默认开启，为性能诊断收集大量数据，而个人站基本用不上。代价是出问题时少了一套诊断视图，需要时再临时打开即可。

max_connections = 30 看着很小，但要算清楚：中转程序的连接池通常配 10–20，加上你偶尔用客户端连进去看数据，30 足够。这个数配成 151（默认值）不会立刻占用内存，但它决定了内存占用的上限，在没有 swap 的机器上等于把 OOM 的可能性留在了那里。

PostgreSQL：注意它是进程模型

PostgreSQL 和 MySQL 最大的运维差异在这里：每个连接是一个独立的操作系统进程，不是线程。 所以连接数对内存的影响比 MySQL 显著得多。

shared_buffers = 128MB          # 通用建议是内存的 25%，但共享机器上别照抄
max_connections = 20            # 进程模型下这个数很值钱
work_mem = 2MB                  # 注意：单次查询可能同时用掉好几份
maintenance_work_mem = 32MB
effective_cache_size = 512MB    # 这只是给优化器的提示，不实际占用

work_mem 有个容易踩的坑：它是每个排序/哈希操作的上限，不是每个连接的上限。一个复杂查询里有多个排序节点时会各分配一份，并发多个这样的查询，内存就会超出直觉。小机器上宁可配小，让它落盘排序。

如果应用的连接池配得比较大，考虑在前面加 pgbouncer 做连接复用——但这又是一个常驻进程，在 2G 机器上要权衡它值不值。

比选型更要紧的问题：日志表会无限长大

这是本文最想强调的一点。无论你选哪个数据库，真正会在半年后咬你的是用量日志表。

机制很简单：每个请求写一行，从不删除。按前面的换算：

• 10 req/s → 每天 86 万行 → 一年约 3.1 亿行
• 每行假设 300 字节 → 一年约 90 GB

后果不是"磁盘满了"这么简单，而是一连串的连带效应：查询变慢 → 管理后台的用量统计页面开始超时 → 备份时间越来越长 → 最后磁盘真的满了，而磁盘满会让数据库直接拒绝写入，整个中转站停摆。

所以从第一天就该有保留策略：

-- 最朴素但有效：定期删除旧数据 + 保留聚合结果
DELETE FROM logs WHERE created_at < NOW() - INTERVAL 90 DAY;

-- 删之前先把要长期保留的口径聚合出来
INSERT INTO usage_daily (day, user_id, model, requests, tokens)
SELECT DATE(created_at), user_id, model, COUNT(*), SUM(total_tokens)
FROM logs
WHERE created_at < NOW() - INTERVAL 90 DAY
GROUP BY 1, 2, 3;

两点提醒：

• 大表上的 DELETE 本身就是个事故来源。 一次删几千万行会长时间持锁、把 binlog/WAL 撑爆。要分批删（每次几千行、中间 sleep），或者用按时间分区的表直接 DROP PARTITION——后者是从一开始就该做的设计。
• SQLite 删完记得 VACUUM，否则文件大小不会回落（空间被标记为可复用但不归还给文件系统）。注意 VACUUM 需要与库等大的临时空间，磁盘快满时反而做不了——所以别等到那时候。

决策建议

最后一条实践建议：先从 SQLite 开始不是妥协。 但要知道 SQLite → MySQL 的迁移不是无痛的——SQLite 是动态类型（type affinity），日期存储没有原生类型，AUTOINCREMENT 语义也不同。如果你已经能预见到半年内会上多实例，那一开始就选 MySQL 或 PostgreSQL，省掉一次迁移。

相关阅读

• new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少 —— 那台机器 285 MB 的 MariaDB 实测数据出自这里
• 大模型 API 中转的超时与重试：一次 504 可能让你双倍计费 —— 用量日志正是核对重复计费的依据
• Caddy 还是 nginx 给 API 中转做反代：证书自动化是决定性差异 —— 同一台小机器上的另一项运维取舍

这篇文章不谈"Docker 好还是不好"，只回答一个具体问题：在小内存机器上，这几百 MB 的差价花得值不值。

先看一台真实 2G 机器的内存都被谁吃了

大多数部署教程会告诉你"new-api 占用很小"，这话没错，但它回答的不是你真正要问的问题。下面是我手上一台腾讯云 2 核 2G / CentOS Stream 9 机器的实测数据，已连续运行 34 天，跑着 nginx、MariaDB、Redis 和两个自己写的 Go 服务：

              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       613Mi        74Mi       7.0Mi       1.2Gi       1.1Gi
Swap:            0B          0B          0B

按进程 RSS 排出来的大户：

这里有个细节要说清楚，否则数字看着不自洽：上面各进程 RSS 加起来（约 691 MB）大于 free 报的 used（613 MB），这不是我算错了。RSS 会把进程间共享的内存页（共享库、写时复制的父子页）在每个进程里各算一遍，所以 RSS 求和天然偏高。判断"还剩多少能用"要看 available，判断"谁是大户"才看 RSS。

从这张图能得出两个结论，它们直接决定选型：

1. 系统底噪比应用大得多。 journald 200 MB、两个云厂商 agent 合计 120 MB、rsyslogd 60 MB —— 这些你一行代码没写就已经存在了。
2. 可用余量只有 1.1 G，且没有 swap。 这意味着任何一次内存尖峰都直接触发 OOM killer，没有降级缓冲。

裸二进制方案的实际构成

new-api 是 Go 编译的单体，部署形态非常简单：

systemd
├── new-api            单二进制，Go 运行时
├── mariadbd           本机数据库
└── caddy / nginx      反向代理 + TLS

一个够用的 systemd unit：

[Unit]
Description=new-api
After=network-online.target mariadb.service
Wants=network-online.target

[Service]
Type=simple
User=newapi
WorkingDirectory=/opt/new-api
ExecStart=/opt/new-api/new-api --port 3000 --log-dir /var/log/new-api
Restart=always
RestartSec=5

# 小内存机器上值得加的两道保险
MemoryMax=512M
OOMPolicy=continue

[Install]
WantedBy=multi-user.target

MemoryMax 这行是小内存机器的关键：给应用设一个上限，让它在自己超标时被 cgroup 限制住，而不是把整机推向 OOM、让内核随机挑一个进程杀——被杀的往往是内存占用最大的 MariaDB，那就是数据库直接下线。

代价要讲清楚，裸二进制不是没有成本的：

• 升级是手动的：下载新二进制、systemctl stop、替换文件、systemctl start，回滚要自己留旧版本
• 没有进程隔离，应用和宿主机共享一切
• 依赖宿主机的 glibc 版本，跨发行版迁移可能编译不兼容（Go 静态编译能规避大部分，但 CGO 开启时不行）
• 数据库、缓存的版本管理全靠宿主机包管理器

Docker 方案多出来的常驻开销

把这 120–220 MB 放回前面那张图里看：可用内存 1126 MB，Docker 一上来先拿走两成，剩下的才是留给 new-api、Postgres 和 Redis 的。在 4G 机器上这笔账无所谓；在 2G 机器上它就是压垮骆驼的那根稻草。

Docker 换来的东西也是真的，别因为省内存就否定它：

• 升级是 docker compose pull && docker compose up -d，回滚是改个 tag
• 环境完全一致，本地能跑线上就能跑
• 数据库、Redis 的版本与宿主机解耦，不用跟发行版的包管理器较劲
• 多实例、多环境并存很容易

决策建议

两个几乎所有人都忽略的内存大户

journald 默认没有上限

前面实测里 systemd-journald 占了 200 MB，这不是异常，是默认行为——它会一直增长到磁盘配额上限。小内存机器上值得直接压掉：

# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=200M
RuntimeMaxUse=50M

改完 systemctl restart systemd-journald。如果你的服务日志已经写到文件并由 logrotate 管，journald 里那份基本是重复的。

云厂商 agent

实测里 YDService（主机安全）加 barad_agent（监控）合计约 120 MB。这些是装系统镜像时预置的，你未必需要全部。要不要关取决于你的取舍：关掉监控 agent 会失去云控制台的监控图表，关掉安全 agent 会失去入侵检测告警。在 2G 机器上这 120 MB 确实值钱，但别为了省内存把安全能力一起关掉——如果你的机器上有数据库对外暴露，那点内存远不如告警重要。

无 swap 是这类机器的隐藏地雷

前面实测数据里 Swap: 0B。云主机默认不带 swap，而 2G 机器最需要它——不是为了性能，是为了在内存尖峰时有个降级路径,而不是直接被 OOM killer 杀掉。

# 加 1G swapfile
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# 小内存机器上把 swappiness 调低，只在真的紧张时才用
sysctl -w vm.swappiness=10

代价是数据库一旦被换出磁盘，性能会明显下降。但"慢"永远好过"被杀"。

相关阅读

部署完成后，反向代理的配置有两个坑几乎人人会踩，我单独写了：

• 反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法 —— 流式输出变成一次性返回，问题通常不在应用
• API 中转站的限流为什么不能信 X-Forwarded-For —— 这个头客户端能自己塞，按它限流等于没限

而本文里那个占 285 MB 的 MariaDB，本身也是个可以重新选的决定：

• 给 API 中转站选数据库：SQLite / MySQL / PostgreSQL 在小机器上的取舍 —— 换成 SQLite 能把这 285 MB 整个省掉，代价是写并发上限