自建网关能让我更便宜地调用模型吗？

不一定更便宜，要看你怎么用。自建中转（One-API/New-API 之类）省的是“聚合管理”和“统一接口”的运维成本：一个网关聚合多家 Key、做负载均衡和额度控制，避免重复开发。但模型本身按 token 计费，网关不降低官方单价。只有在你能拿到更便宜的渠道（如批量折扣、渠道差价）或通过缓存/复用降低调用量时，才真省钱。对个人少量调用，直接调官方 API 往往更简单；中转的价值在“多 Key 统一调度”而非“更便宜”。

1 核 1GB 的机器真够用吗？

对“网关本身”够用。One-API/New-API 这类程序极轻量，1 核 1GB 跑网关进程绰绰有余，内存主要给连接和缓存。但注意：网关只做转发，不吃模型算力；真正的开销在“被调用的模型端”（官方 API 在远端），本地不跑大模型。所以 1c1g 完全能扛一个中小流量的中转。瓶颈通常是出口带宽和并发连接数，不是 CPU/内存。若你本地还要塞一个 7B 量化模型做推理，那 1GB 远远不够，至少 4–8GB 起。

One-API 和 New-API 怎么选？

两者同源：New-API 是 One-API 的一个活跃分支（fork），界面和接口高度兼容，社区更新更快。选 New-API 通常更稳：bug 修得勤、对新模型/新渠道适配更快、文档和群支持更活跃；One-API 原项目维护节奏慢一些。功能上都支持多渠道聚合、额度/分组、负载均衡、令牌转发。新手直接上 New-API 即可；若你现有系统已基于 One-API 且跑得稳，不必强行迁移。两者都靠社区维护，生产环境记得备份数据库和密钥。

为什么流式输出变成攒一批才发？

多半是配置或代码问题，不是模型的事。常见原因：① 网关/反代（Nginx）开了缓冲（proxy_buffering on），把流式响应攒成整块才下发；② 你的客户端用了非流式请求或把 chunk 累加完才渲染；③ 中转程序本身把 SSE 事件合并转发以省连接。修复：Nginx 设 proxy_buffering off、加 X-Accel-Buffering: no，客户端用支持 SSE 流式读取的库（如 OpenAI SDK 的 stream=true），并确认中转程序开启“流式透传”。排错时直连官方看是否流畅，可定位是哪一层在缓冲。

把中转网关对公众卖 Key 合规吗？

风险很高，先看清边界。技术上能卖，但合规上要当心：① 多数模型服务商的 ToS 禁止转售/再分发 API 访问，擅自卖 Key 可能封号且不退费；② 若面向国内公众收款，涉及经营资质、税务与支付合规；③ 用户拿去生成违规内容，你作为提供方有连带责任风险。稳妥做法：只做自用或多账户统一调度，不对外公开售卖；若要做商业代理，走正规渠道授权并签协议、做好内容审核与实名，否则不建议轻易对外卖 Key。

【API 中转 01】VPS 搭建 AI API 中转/代理：OpenAI / Claude 合规中转、延迟优化与成本

2026-08-15 · DevCraft Studio

用 One-API / New-API 在 VPS 上自建 AI API 中转网关，统一多家模型 Key、限额与计费；讲清 1C1G 够用的原因、机房延迟优化、Nginx 调优，以及个人内部用量与对公众转售的合规边界。

AI API 中转系列 · 共 2 篇

延伸阅读

一、为什么要在 VPS 上搞一个 API 中转

如果你只用一两个 Key、偶尔调调官方接口，其实没必要自己搭网关。但当事情变多，原生方式就会很狼狈。典型场景有这么几个。

一个是多 Key 管不过来。你有 OpenAI 的 Key、Claude 的 Key、DeepSeek 的 Key，分布在不同的脚本、不同的项目里，哪个快到期、哪个被限流，全靠脑子记。中转网关把这些 Key 收口成一个内部 endpoint，外面只认一个地址、一个令牌。

一个是团队或多项目要分别限额。三个人共用一个 OpenAI Key，某人写个死循环把额度一夜跑爆，全组停工。建了中转之后，每个人拿独立的令牌，设各自的额度上限，谁超谁停，互不影响。

一个是想统一接口。你的 LobeChat、Dify、还有自己写的脚本，如果都用 OpenAI 格式，就能一套代码调所有模型，今天用 gpt、明天换 deepseek 不必改业务代码。中转网关把这个「转换头」的角色担起来。

还有一个是很实际的诉求：看清谁花了多少 token。原生方式下，各家账单是混在一起的；中转网关的日志里每条请求都带模型名、输入输出了多少 token、耗时、调的是哪个令牌，谁用超了一目了然。一句话，中转网关像公司前台或总机：外面只记一个分机号，实际转给不同部门，谁打了多少电话、花了多少钱，前台一本账。

💡 本系列第 2 篇《ChatGPT/Claude API 中转 VPS 推荐 2026：稳定不掉线的便宜方案》专门讲「该选哪台 VPS 来跑中转」——机房延迟、IP 纯净度与三档预算套餐，搭好网关后接着读那篇选机器。

二、先泼盆冷水：你可能并不需要

把上面好处说完，必须泼点冷水。自建网关不是免费的午餐，它用你的运维时间换中转的便利。规模太小反而划不来。

适合自建的情况：你有多家模型 Key 要统一管理；团队或多人要分别限额和审计；你的应用（聊天前端、工作流、脚本）想用一套 OpenAI 格式调所有模型；你关心每笔请求的用量和成本归属。

不适合自建的情况：你只是个人偶尔调一下官方 API；你只有一两个 Key、且用量很小；你不想花任何时间维护一个额外服务；你对 Docker、反代、密钥管理完全没概念。这类人直接用官方 SDK 就好，别为了「看起来专业」而自找麻烦。

另外要清楚：网关本身几乎零边际成本，真正的开销永远在上游官方 API 的 token 费用，而不是这台 VPS。所以自建省的是「管理成本」，不是「模型费用」。抱着「自建能便宜调用模型」的念头来的人，多半会失望，因为贵的是模型不是网关。

三、典型架构长什么样

一个典型的中转架构是这样走的：客户端（你的应用、聊天前端、脚本）先把请求发到网关，网关做三件事——鉴权（这个令牌合不合法）、路由（该转发给 OpenAI 还是 Claude 还是 DeepSeek）、计费与限流（扣多少额度、超没超上限）。然后网关把请求转发给上游官方或第三方，拿到回复再原样回给客户端。

网关是「中间层」，它自己不跑模型、只做转发和记账。这决定了它对算力的需求极低。前面那层通常还会再挡一个 Nginx 做反代和 HTTPS，把网关保护在内网后面。理解这一点很重要：整个系统里最贵、最慢的环节永远是上游模型推理，网关只是个轻量管道。

把请求路径画清楚有助于排错：客户端到 Nginx（TLS 终止、可能做连接复用），Nginx 到网关（3000 端口），网关到上游官方 API（出网到美区或你选的机房）。任何一段出问题，表现都是「接口慢」或「报错」，所以后面我们会讲延迟优化和常见报错对照。

四、One-API 还是 New-API

这两个是同一范式的代表，都出自 Go 加 React，都能用 OpenAI 格式统一多家模型。One-API 是开创者，2023 年开源，许可证 MIT，镜像名 justsong/one-api。New-API 是 One-API 的增强 fork，仓库在 QuantumNous/new-api，镜像名 calciumion/new-api:latest。

两者最大的区别在许可证和丰富度。One-API 是 MIT，宽松，闭源商用分发都没包袱；New-API 是 AGPL-3.0，有开源传染性，如果你要做闭源或商业分发，要谨慎对待它的开源义务。功能上 New-API 多了 Claude 和 Gemini 的原生格式输出、在线充值、Prompt Cache 缓存计费、RBAC 权限、更完整的用量看板；One-API 则更轻量稳定，基础计费也够用。

两者数据库兼容，可以从 One-API 平滑迁移到 New-API，数据不丢。怎么选？个人自用、只要简单统一接口，One-API 就够了；如果你要接入 Claude/Gemini 原生、要团队运营能力、要更细的看板，上 New-API。下面部署以 New-API 为例，因为功能更全，但步骤对 One-API 同样适用。

五、十分钟部署（以 New-API 为例）

最简部署是一行 Docker。容器端口 3000，数据卷挂到 /data，用 SQLite 就能跑（生产环境建议换 MySQL）。启动后默认账号是 root、密码 123456，部署后第一件事就是改密码，这步绝对不能省，否则公网一扫就进后台了。

登录后台后做三件事。第一，改掉默认密码，并到设置里关闭公开注册，避免陌生人自己建号。第二，配置渠道（Channel）：把 OpenAI、Claude、DeepSeek 各自的 Base URL 和 Key 填进去，可以一个模型配多个 Key 换行分隔，网关会自动轮询和故障转移。第三，创建一个令牌（Token）给下游用，设好额度上限和可用模型范围。

下游接入几乎零改动。你的业务代码只改两个环境变量：把 OPENAI_BASE_URL 指向 http://你的服务器:3000/v1，把 OPENAI_API_KEY 换成在中转后台生成的那个令牌。之后所有 OpenAI 格式调用都走你的网关，代码一行不用改。比如原来直连官方，现在只是换了个 endpoint 和 key，背后实际路由到哪家模型由网关决定。

六、VPS 配置怎么选，成本多少

因为网关不跑模型、只转发请求加记录用量，它吃资源极少。根据实测配置建议：个人自用 1 核 1GB 就能跑，2GB 更稳；小团队内部 2 核 2GB 起步更舒服；多人分发再加 MySQL，2 核 4GB 更稳妥；磁盘 20GB 起，注意日志别无限保留，否则数据库会比程序还大。系统推荐 Ubuntu 22.04 或 24.04，或者 Debian 12。

所以「1C1G 足矣」是有依据的：瓶颈不在 VPS，而在上游官方 API 的推理速度和你的 token 额度。你给再大的机器，模型响应也不会更快。成本结构也很清楚：VPS 本身几美元一个月，加上官方 token 费；中转网关的边际成本约等于仅 VPS 的带宽，极小。一句话，贵的是模型，不是网关。别在 VPS 规格上过度花钱，把预算留给 token 更实在。

七、延迟优化：选对机房加 Nginx 调优

延迟是中转体验里最直观的一项。OpenAI 和 Anthropic 的推理主要在美国（us-east-1、us-west-2）。从美国本地到首 token 大约 40 到 80 毫秒；从亚洲普遍 300 到 600 毫秒，高峰能破 1 秒。有实测显示东京到 api.anthropic.com 仅连接加 TLS 就吃掉 600 到 900 毫秒。区域基准上，美东弗吉尼亚约 42 毫秒、日本东京约 89 毫秒、新加坡约 112 毫秒（P50）。另一组 VPS 到 OpenAI 实测：韩国 RTT 35 毫秒、TTFT 298 毫秒；东京 38/302；新加坡 62/348；美西 155/432。

给国内用户的机房建议是香港、新加坡、日本东京——它们同时兼顾「到国内用户低延迟」和「到官方 API 稳定低延迟」。香港到国内 Ping 常 30 到 50 毫秒、到 OpenAI 不到 150 毫秒，是常见首选；日本和新加坡次之，取决于线路（比如走 CN2 的新加坡会更好）。延迟像快递路程：模型在美国，你在亚洲，包裹再快也得跨洋；把网关放在离你和官方都近的香港或日本，等于把收发点设在枢纽。

Nginx 层有几招实在的优化。启用 HTTP/2 多路复用（listen 443 ssl http2），降低并发请求延迟。用 upstream 配 keepalive 32，再加 proxy_http_version 1.1 和把 Connection 头清空，做连接复用，省掉每次 TCP 加 TLS 握手。开 proxy_ssl_server_name on 让 SNI 正确解析上游 TLS。用 ssl_session_cache shared:SSL:50m 复用 TLS 会话，省握手往返。最关键的一条：流式接口必须 proxy_buffering off，否则 SSE 会被攒成一批再发，体验从「逐字流出」变成「转圈半天蹦一大段」。客户端侧也要把 SDK 超时调大（比如 120 秒），避免长上下文或慢模型被客户端自己判超时。

八、合规与风控：别踩线

这部分必须如实说，面向国内用户尤其要清醒。根据《生成式人工智能服务管理暂行办法》，通过提供可编程接口等方式向境内公众提供生成式 AI 服务者，即属「服务提供者」——中转站不能简单辩称「我只是转发」。而 OpenAI、Anthropic、Google 等境外模型目前都未在中国境内完成备案。

上游服务条款也要看：OpenAI 商业条款禁止买卖或转让 API Key、禁止规避速率或地区限制；Anthropic 禁止以第三方身份代为路由请求。违规的主要后果是封号。许可证方面，New-API 是 AGPL-3.0，做闭源或商业分发要注意开源传染性义务，One-API 的 MIT 则宽松得多。

数据合规上，用户的 Prompt 与回复都经过中转服务器，构成数据出境，受《个人信息保护法》《数据安全法》约束，应最小化留存、做脱敏、不存明文。密钥安全上，HTTPS 必须开，后台关闭公开注册、用强密码、加 IP 白名单，上游 Key 与用户令牌加密存储、定期轮换、泄露即吊销。

本文的定位很明确：把它当作「个人/团队内部统一网关、方便管理与限额」来用，合规边界更宽；而「对公众转售、绕开地区限制卖 Key」是灰色生意，对外经营需要备案与上游授权，本文不鼓励也不展开。模型映射省钱这类技巧（比如把 gpt-4o 请求映射到 deepseek-chat）自用可以，对公众隐瞒映射涉及合规与诚信风险，对外必须披露。

#API中转 #OneAPI #NewAPI #OpenAI #Claude #合规

💡 延伸阅读：关于架构与基础设施的更多深潜指南，请前往 VPS 主题导读中心 (Hub) 获取全盘策略。