自建大模型 API 中转站会遇到的问题，按它们实际出现的顺序排列：
先是部署形态——机器就这么大，裸二进制还是 Docker。 接着是反向代理——流式输出被缓冲、超时导致重复计费、限流被伪造 IP 绕过， 这三个坑都在同一份 nginx 配置里。 然后是运维——证书过期会让所有 SDK 客户端一起硬失败，比 500 难查得多。 最后是存储——用量日志表的无限增长，比数据库选型本身更容易在半年后咬你。
利益披露：本文最后介绍的中转站是我自己在运营的。前面三分之二的取舍分析对任何人都成立， 你完全可以看完分析之后选择另外两条路——那也是这篇文章想说清楚的事。 ...
给大模型 API 中转选反向代理，网上的对比文章大多在比性能、比配置语法、比模块生态。这些差异对一个 API 网关来说其实都不重要——真正的分水岭是证书生命周期由谁管理。 ...
nginx 的 proxy_read_timeout 默认是 60 秒，而长上下文或推理模型的单次生成经常超过这个数。超时之后 nginx 返回 504，看起来只是"一次失败"——但真实后果比这严重：上游很可能已经把生成做完并计了费，而客户端 SDK 收到 504 会自动重试，于是上游又生成一次、又计一次费。 ...
new-api 这类中转程序通常同时支持 SQLite、MySQL 和 PostgreSQL，安装文档也就一句"按需选择"。但在一台 2G 内存的小机器上，这个选择是有真实代价的——光是数据库进程本身就可能吃掉可用内存的四分之一。 ...
自建大模型 API 中转站几乎一定要做按 IP 限流：防注册刷号、防单账号打满上游配额。而这里有一个安静失效的陷阱——如果你的限流按 X-Forwarded-For 计数，那它等于没做。攻击者每个请求塞一个不同的伪造 IP，计数器永远打不满。 ...
在 2 核 2G 的云主机上部署 new-api，如果这台机器还跑着别的服务，裸二进制方案通常是唯一可行的选择。原因不是 new-api 本身重——它是个 Go 单体，编译出来就一个二进制——而是 Docker 守护进程加上容器化的数据库和缓存，会在系统底噪之上再叠几百 MB 常驻开销，而 2G 机器的可用余量往往只剩 1G 出头。 ...
自建大模型 API 中转后最常见的故障是：后端明明是流式的，经过反向代理就变成一次性返回——客户端等十几秒没有任何输出，然后整段文字一次吐完。首字节延迟几乎等于整个生成时长，流式的意义全部丧失。 ...