AI API 中转站架构方案：单层 vs 双层#

场景：用户在国内，统一中转多家上游 AI API，要求稳定、快速、免 ICP 备案。
上游覆盖：

• 海外：OpenAI、Anthropic（Claude）、Google Gemini
• 中国模型：DeepSeek、通义千问、智谱、月之暗面、百川等（可扩展）
  本文对比单层与双层两种中转架构，说明海外 / 中国模型分流，以及主站 NewAPI + 副站 Sub2API 号池的软件分层。

1 · 架构总览#

中转站本质是 AI API 网关：客户端 → 你的服务器 → 上游厂商 API → 返回。
网络架构与具体模型名无关；差异主要在上游地域、可达性、IP 风控、协议与计费，由 new-api 等网关统一处理。

关键原则：海外上游与中国模型上游的最优出口位置不同——不要假设「一台美西机器」对所有上游都最优。

1.1 单层架构#

一台美国 VPS 同时承担「对国内用户服务」与「访问上游」两个角色。
对海外上游较合适；对中国模型 API 往往要从美西再回程访问国内/亚太端点，延迟与稳定性都不是最优。

1.2 双层架构（可选：入口统一 + 出口分流）#

• 入口：香港（国内用户就近、免备案）
• 海外出口：美西（OpenAI / Anthropic / Gemini）
• 中国模型出口：香港直出（或同入口机转发），不必再绕美西

2 · 核心区别：为什么双层更稳#

跨太平洋这段链路，两种方案走的网络完全不同（主要影响海外上游路径）：

• 单层：用户流量要先自己跨过中国公网国际出口才能到美国 VPS。
• 本文最终双层方案：用户先就近进入香港，再通过 WireGuard 到东京；WireGuard 提供加密和源站收口，底层仍是跨厂商公网。
• 需要真正骨干专线时：香港与东京必须购买支持跨地域私网的同云产品，并配置 CEN / CCN / 云企业网等付费服务。
• CN2 GIA：公网「VIP 道」，仍不是云厂商私有骨干。
• 中国模型：最优路径往往是香港（或亚太）直出，不必强制走美西；双层里把中国模型渠道绑在香港出口即可。

核心洞察：用户感知延迟看第一跳；上游延迟看出口是否靠近该上游。海外与中国模型应分流出口。

3 · 完整对比表#

4 · 单层架构#

优点#

• 部署简单，一台机器搞定
• 成本低、运维省心
• 选 CN2 GIA-E 时，海外上游体验已经不错

缺点#

• 跨洋段走公网，晚高峰拥堵
• 用户首跳延迟高
• 单点，出口 IP 被封则受影响
• 中国模型从美西回程访问，非最优

推荐机型（摘要；完整采购见 §8）#

• 入门：搬瓦工 CN2 GIA-E（洛杉矶）
• 进阶：DMIT 洛杉矶 GIA 高配
• 长期更推荐双层（§5 + §8），单层仅作过渡

适用场景#

• 起步、用户量小，且以海外模型为主

• 暂不强调中国模型延迟

1. 输入 api.你的站.com
2. 电脑问 DNS：这域名的 IP 是多少？
3. DNS 回答：盾机IP
4. 电脑连上盾机IP，开始通信（此步有缓存，几十毫秒且不常发生）

5 · 双层架构（可选方案，含中国模型分流）#

本节保留用于说明“香港入口隐藏源站 / 多地域出口”的可选升级路线，不是当前采购结论。当前最终方案为两台 DMIT 东京直连，见 §13。

术语：入口 / 出口怎么定义？
以「你的中转系统」为参照，按请求流动方向命名：用户 → 入口 → 出口 → 上游。

• 入口（ingress）：用户流量进入系统的第一道门（结果上离用户近）。
• 出口（egress）：流量离开系统、去连上游的最后一道门（离上游近）。
  「近的叫入口」不是因为它近，而是因为请求从这里进来。类比：大楼正门（入口）进人、后门（出口）通外面。

优点#

• 用户就近连香港，体验快、稳
• 可按预算选择公网 WireGuard 或同云跨地域专线；本文最终采购默认前者
• 中国模型香港直出，避免美西绕路
• 出口 IP 可隐藏、可多备，抗封强
• 按上游拆渠道，扩展 OpenAI / Claude / Gemini / 国产模型都清晰

缺点#

• 机器与隧道成本更高
• 需配置路由：哪些模型走美西、哪些走香港

推荐机型（摘要；完整采购见 §8）#

• 入口 / 中国模型出口：阿里云 / 腾讯云香港轻量（1～2C/1～2G）— 盾机；不可用香港 IP 直连 OpenAI。
• 源站 / 海外低 TTFT 出口：日本东京 2～4C/4～8G（DMIT 等优质线路）；当前最终方案将 NewAPI 与 Sub2API 分到两台 DMIT。
• 美西备用 / AZ / 纯净 IP：DMIT 洛杉矶 GIA / Vultr 等 — 按需加第 3 台。
• 完整台数、规格、下单顺序、厂商表：见 §8 服务器选型。

适用场景#

• 稳定快速 + 海外与中国模型并存
• 正式运营、多上游并行

5.1 出口地域与首字延迟（TTFT）：香港 / 日本 / 美西三方对比#

实践中不少站长的双层架构用日本节点，GPT 首字延迟（TTFT）常压到 1s 以内。要讲清「为什么是日本」，需要分两个维度看——日本既可能是替代美西的「出口」，也可能是替代香港的「亚洲中转」。

关键概念：TTFT（首字延迟）= 首个 token 返回前的网络往返累加 + 模型预填充（prefill），与整段生成速度是两回事。要低 TTFT，核心是把「请求 → 第一个 token」之间的 RTT 压到最小。

两个比较维度（别混淆）

那位站长的「日本低 TTFT」现象，更适合用「日本 vs 香港」解释：赢的不是第一跳（中国→港/日相近），而是日本去美国的跨太平洋 onward 路由更优。

三方端到端对比（面向国内用户访问 OpenAI）

注意：上表「香港 → OpenAI」标为不可直连——香港只能当入口，不能作 OpenAI 出口（详见 §5 警告）。所以「日本 vs 香港」比的是亚洲侧入口/中转位置，OpenAI 出口本就轮不到香港。

为什么日本这一段这么关键

• 第一跳超短：中日海缆密、距离近，用户就近落地。
• onward 跨洋优：东京是海缆枢纽，日本→美西 90～120ms，容量大、稳定；香港偏南，港→美路由常更长更挤。
• 连接复用免握手：出口对上游维持长连接 / 连接池（keep-alive + HTTP/2），省掉每次跨洋 TLS 冷启动（300～400ms）。
• 短 prompt 预填充快：中短上下文 prefill 仅几十~百余 ms，网络成主导项，一优化就进 1s。

落地要点（否则优势会被吃掉）

• 必须开上游连接复用 / 保活：否则每请求跨洋 TLS 握手 300～400ms，日本优势归零。
• 选大带宽 + 优质线路的日本机；廉价日本 VPS 走公网绕路无此效果。
• 注意日本 IP 纯净度（部分日本 IP 段也被 OpenAI 风控），必要时备用 IP。
• 长上下文（几万 token）prefill 高，任何出口都难 <1s，这是模型侧而非网络侧。
• 可组合：香港做入口/中国模型出口 + 日本做海外低延迟出口 + 美西做纯净 IP 备用，按渠道分流。

5.2 入口选型：香港 vs 日本#

入口不能只看延迟，还要同时看第一跳、聚合带宽、固定成本和运维复杂度。据此：

香港入口的价值与代价

• 回国路由最成熟：阿里云/腾讯云香港有 BGP/内网回国优化，优质线路（CN2 等）多终结香港，第一跳 30～50ms 且稳定。
• 中国模型能直出：香港到国内 API 近，DeepSeek/通义/智谱不必绕美西/日本。
• 免备案、云厂商现成。
• 但所有请求和响应都经过入口；20～200 Mbps 香港机放在共享高速日本节点前面，会直接限制整站聚合吞吐。
• 还会新增证书、Nginx、WireGuard、防火墙、监控和故障切换的运维成本。

那个例外为什么成立（多一跳的代价）

分离：用户 →40ms→ 香港 →~50ms→ 日本 →~100ms→ OpenAI  ≈ 190ms
单节点：用户 →60ms→ 日本 →~100ms→ OpenAI              ≈ 160ms

• 当前由 DMIT 东京 core-01 直接承担入口和默认出口，worker-01 独立承载号池与媒体任务；两台都不经过香港盾机。
• 只有中国模型从日本访问持续不达标时，才加香港出口；该节点不进入用户主链路。
• 只有确实需要隐藏源站且能购买同等级高带宽入口时，才恢复香港入口双层架构。

一句话：当前入口默认日本；香港从“必买盾机”改为“数据触发后的可选出口 / 高带宽入口”。

5.3 安全与隐藏源站 IP：盾机架构#

如果业务以后明确要求隐藏日本源站 IP，可以恢复本节的双机架构；但入口必须具备与业务峰值相匹配的带宽。低带宽盾机虽然能隐藏源站，却会成为所有 API 流量的串行瓶颈，因此当前最终方案不启用盾机。

核心认知：暴露的永远是「可弃的盾」，不是核心

总得有一个公网 IP 被用户连，躲不掉。关键不是「暴不暴露」，而是暴露的是哪台机器、值不值钱、能不能随时换。

如果未来目标明确变成“隐藏源站”，应把主站后移，再增加一台带宽足够且可替换的入口节点；不能用明显低于主站吞吐的廉价盾机，否则安全层会变成性能瓶颈。

要几台机器？最少 2 台

NewAPI 核心不是单独一台，可与出口机合并：

盾机配置要求：很低

盾机是搬运工（TLS + 反代转发），不跑模型、不存数据。钱花在线路和带宽，别花在 CPU。

盾机 → 源站：这一跳也要隐藏 + 收口

• 别用公网明连，否则源站 IP 仍可能被探。
• 推荐 WireGuard / 内网隧道 加密互联；或云厂商同账号内网 / 专线。
• 源站防火墙只放行盾机 IP，其余入站全拒。

预算不够 / 要抗大流量攻击时的付费增强

• 性价比：自建盾机（带基础 DDoS 防护的 VPS）——本节方案。
• 抗大流量：盾机前再叠 亚洲高防 IP（阿里云香港高防 / 腾讯云大陆境外高防），节点在亚洲、延迟低。
• 安全+分发一体：腾讯云 EdgeOne 等（有亚洲节点，优于 CF 免费版）。
• 不推荐为国内加速堆 CF 付费（Argo/Business）——入口段仍受 Anycast 限制，同样花钱不如投亚洲方案。

流量怎么走（概念）#

6 · 多上游说明#

6.1 海外上游#

6.2 中国模型上游#

具体 Base URL、是否必须备案账号、实名与内容合规，以各厂商最新政策为准；中转站不替代你对上游的合法授权与合规义务。

6.3 网关侧（new-api）建议#

• 按厂商建独立渠道，模型前缀清晰：gpt-* / claude-* / gemini-* / deepseek-* / qwen-* / glm-* 等
• 按渠道指定出口（或上游 Base URL 指向对应出口反代），实现海外 / 中国模型分流
• 多 Key 轮询 + 健康检查
• 客户端统一 BASE_URL，只靠模型名路由

7 · IP 被封风险与抗封#

海外上游更常遇到出口 IP 被风控；中国模型更多是账号/配额/合规与限流，但脏 IP、异常并发同样会触发 429。

被封 / 拦截主要原因

降低风险手段

• 海外出口：独立纯净 IP（DMIT / Vultr），买前测 api.openai.com / api.anthropic.com / Gemini 端点
• 中国模型：在香港出口测各官方 API；确认 Key 权限与地域
• new-api 限流 + 多 Key + 健康检查
• 美西准备 2 个备用出口 IP；重要海外上游可独立备用渠道
• 出口不对国内用户暴露（双层入口天然隔离）

8 · 服务器选型（落地采购）#

结合本方案业务默认：

模型在上游，VPS 不需要 GPU。钱花在 线路、带宽、IP 纯净度、台数角色，不花在高主频大内存堆料。

8.1 当前取向：两台 DMIT 东京 Premium#

8.2 台数：现在正式购买 2 台#

国内用户 → DMIT 东京① NewAPI 核心
              ├─ 官方海外模型 / 中国模型 → 东京直出
              ├─ 编码渠道 → DMIT 东京② Sub2API → 每号独立住宅代理
              └─ 生图与视频 → DMIT 东京② media worker → 上游异步任务

TooBox 客户端 ←→ R2 预签名直传直读 ←→ DMIT 东京②转存结果

两台 DMIT 分工可以隔离单机资源故障，但如果都位于同一个东京区域，仍然共享供应商和地域故障域：能防单台宿主机、单个系统和单个 IP 故障，不能完全防 DMIT 东京区域或上游骨干整体故障。需要更高 SLA 时，第三节点必须放到不同地域或不同供应商。

8.3 两台服务器精确选型#

DMIT 官方当前将东京 Premium 描述为面向中国大陆的 CN2 GIA 优化网络，并给出约 28～30ms 的参考延迟和低于 0.1% 的参考丢包；这些是官方参考值，不是所有地区、运营商和时间段的 SLA。正式下单后仍必须做国内三网、晚高峰、SSE 和上游连通性实测。

8.4 两台服务器职责与资源预算#

两台都必须给系统、Docker 和突发峰值预留约 1.5～2 GB。图片和视频模型在上游运行，服务器不需要 GPU；如果以后在本地执行高码率 FFmpeg 转码或本地推理，应新增专用计算节点，不能继续挤占号池和备用 NewAPI。

8.5 后续扩容触发条件#

8.6 当前采购清单#

现在只买：

1. DMIT 东京 Premium MEDIUM × 2：每台 4 vCore / 8 GB / 160 GB SSD / 6 TB / 1 Gbps，单台 $320.90/月，两台 $641.80/月。
2. Cloudflare DNS Free：$0/月；API 域名 DNS only（灰云），主节点故障时切到备用节点。
3. Cloudflare R2：图片、参考图、音频、视频、任务结果和备份使用预签名直传直读。
4. 订阅号池代理：每个合法授权账号绑定独立静态住宅代理，费用随账号数量单独计算。

**暂时不买：**香港盾机、香港国模出口、第三地域灾备节点和本地 GPU 服务器。

**持续成本另计：**模型 API、合法授权的订阅渠道、代理、Adobe 积分或第三方生图 / 视频采购，不属于服务器固定成本。

8.7 推荐上线顺序#

1. 同时购买两台 DMIT 东京 Premium MEDIUM，分别标记为 core-01 与 worker-01。
2. core-01 部署 Nginx、NewAPI、PostgreSQL、Redis、监控和自动备份。
3. worker-01 部署 Sub2API、独立任务队列、media worker、生图网关和备用 NewAPI。
4. 建立两台之间的 WireGuard / 私网通道和严格防火墙，只允许必要的内部端口。
5. 配置每账号独立住宅代理，以及 R2 预签名上传 / 下载；禁止大图片和视频 Base64 穿过 NewAPI。
6. 做国内三网晚高峰、各上游、30～50 并发、72 小时稳定性和主节点故障切换测试。

8.8 避免买错#

部署与渠道配置见《New API 中转站运维手册》《Sub2API 号池运维手册》。

8.9 对象存储：默认 Cloudflare R2#

本方案对象存储默认用 Cloudflare R2（S3 兼容）。实践里便宜、好用，适合中转站存图与静态资产，不必为省几块钱再自建 MinIO 当主力（除非强合规内网）。

通俗导读（不懂术语先看这段）#

把这些名词用大白话对齐一下：

一句话理解成本：存储费各家半斤八两，真正烧钱的是"用户看图"的流量费。R2 的杀手锏就是流量不要钱。

为什么 R2 免流量费，国内 OSS/COS 却要收？#

结论："不用出流量费"是 Cloudflare 的商业策略，不是行业标配。 国内只要"公网大量看图"，流量费就绕不开——所以能白嫖 R2 流量就别整站搬去国内桶。

R2 免费也有隐含条件（走它自己的网络、超大量会被"约谈"），并非无限白嫖。

国外还有哪些"像 R2"的低/免流量费产品#

不止 R2，这些也主打流量便宜甚至不收（都 S3 兼容）：

怎么挑：

关键认知：换哪个"仓库"都解决不了国内访问快慢——决定国内体验的是前面那层 CDN。 先把 CDN 做好，再谈换桶。

中转站为什么需要对象存储#

文本 chat 本身不大；一生图，磁盘与回源流量会陡增——图放对象存储，VPS 只做网关。

方案总览（中转站常见选项）#

横向对比（中转站视角）#

价格为数量级心智，以各官网实时价为准；中转站成本大头通常在模型与号池，对象存储比的是「会不会被流量费打穿」。

按场景怎么选

组合拳（推荐）

主存：R2（零出站，API/Worker 写入）
     └─ 自定义域 img.example.com 给客户端

可选备线：
  - 国内用户体感差 → 热门前缀同步/回源到 OSS+CDN
  - 强合规客户    → 其流量走国内桶，其它仍 R2

和「API 入口不要用 CF 免费橙云加速国内」不矛盾：

• API 入口 → 日本主服务器灰云直连
• 图床 / 静态对象 → R2（省流量、S3 兼容）
  两套用途，不要混成「全家桶都走 CF CDN」。

各方案要点（避免踩坑）#

成本心智（生图站）#

假设每月 10 万张图 × 均 2MB ≈ 200GB 出站（数量级）：

存储费在中小站通常 ≪ 模型费；优先消灭「出站黑洞」，再抠存储单价。

推荐用法（与 NewAPI / 生图）#

用户 → 日本 NewAPI
         ├─ 文本 → Sub2API / 上游（响应体小，可直接流式返回）
         └─ 生图 / 视频 → 创建异步任务
                          → 客户端用 R2 预签名地址直传参考文件
                          → worker 将结果写入 R2（或 OSS 备线）
                          → 返回 https://img.你的域/... 持久链

注意点（通用）#

稳定优先怎么选（觉得 R2 不稳时）#

先分清「不稳」到底出在哪层——R2 后端本身可用性并不差（有 SLA），大多数"不稳"是链路层，不是存储层：

所以"要稳定"有三条正交手段，按需叠加：

分场景稳定选型：

一句话：你现在的"不稳"八成是「R2 直连 + CF 国内边缘」造成的，不是 R2 存不住。 先做 ①自定义域+CDN；国内用户多就上 ②国内桶为主；对 SLA 敏感再上 ③双写。想要"最稳且国内快"，主选 COS/OSS、R2 降为备份是最省心的组合。

双写/切换最小模型：

写：网关出图 → 同一 key 规范
     ├─ PutObject → R2      （省流量）
     └─ PutObject → COS/OSS （国内快、SLA 稳）   ← 失败只告警，不阻塞主流程

读：客户端拿到的是 https://img.你的域/{key}
     img.你的域 由智能解析/CDN 决定回源：
       国内 → COS/OSS 源
       海外 → R2 源
     某源异常 → 健康探测切到另一源

要点：两边用同一套 {date}/{hash}/{uuid}.png key，才能无缝切换；写副本失败只记日志，别拖垮出图主链路。

采购结论（与 §8.8 并列）#

省钱优先 → R2 主 + 自定义域/CDN；稳定优先（尤其国内用户）→ COS/OSS 主 + R2 双写备。两者都比"R2 直连 r2.dev"稳得多。

9 · 通用注意事项#

• 出口靠近上游：海外低 TTFT → 日本（§5.1）；纯净/AZ → 美西；中国模型 → 香港/亚太（实测为准）
• IP 纯净度：海外出口重点防封；号池用家宽；中国模型重点账号与限流
• 大流量：图像 / 多模态选够带宽与流量的套餐；生图与文本分渠道；图文件默认进 R2（§8.9），别长期堆源站盘
• 对象存储：默认 Cloudflare R2；与 S3/B2/Wasabi/OSS/COS/Bunny/MinIO/本地盘对比见 §8.9；API 入口仍走盾机，勿与橙云加速入口混谈
• 免备案：入口与节点选香港 / 日本 / 美国等境外地域，不要绑大陆需备案节点
• 网关：new-api / one-api 多渠道（详见《New API 中转站运维手册》）
• 合规：仅使用合法授权的上游 Key；对外服务自行履行内容安全等义务
• 主副站：对外只暴露 NewAPI；Sub2API 作号池渠道，见 §10；编码默认 Pro20x + 每号家宽，见 §11；生图 Adobe/网页线，见 §12
• 服务器规格与下单顺序：见 §8；对象存储见 §8.9

10 · 主站 NewAPI + 副站 Sub2API（号池）#

你计划拆成两个中转站，职责分离，这是长期可维护的做法：

客户端只连主站；副站不直接对公网用户暴露（或仅内网 / 白名单）。

10.1 为什么拆成两个站#

组合后：

用户 → 主站 NewAPI → 若干渠道
                      ├─ 官方 / 企业 API Key（OpenAI、Anthropic、Gemini、DeepSeek…）
                      ├─ 副站 Sub2API（订阅号池）→ 真实订阅会话
                      └─ 其他第三方中转（可选）

10.2 推荐对接方式#

1. 副站 Sub2API 部署在合适出口机（订阅类多依赖海外可达，常与美西出口同机房或同网段）。
2. 在 Sub2API 中：IP 管理加家宽代理 → 建号池/分组/账号（每号绑独立代理）→ 对外 API Key（仅给主站用）。
3. 主站 NewAPI 新增一条（或多条）渠道：
   • 类型选兼容 OpenAI / Anthropic 等（以 Sub2API 实际暴露协议为准）
   • Base URL = 副站地址（建议内网或 https://sub.internal/...，勿裸奔公网）
   • Key = Sub2API 发给主站的密钥
   • 模型列表与号池支持的模型对齐（如部分 Claude / GPT 订阅模型）
4. 主站再配官方 Key 渠道、国模渠道等，用优先级 / 权重 / 分组决定：
   • 稳定付费流量 → 官方 Key
   • 编码默认 → Sub2API Pro20x 号池（Priority 高，见 §11）
   • 订阅池容量 / 弹性 → Sub2API 其它池或三方
   • 故障时自动切换（NewAPI 渠道禁用 / 重试）

10.3 与当前两台 DMIT 如何叠在一起#

当前主站和副站物理分离，避免号池浏览器、验证码、代理异常或媒体任务抢占核心数据库资源：

可选拓扑：

国内用户 → [DMIT 东京①] NewAPI 主站
                    ├─ channel: 国模 / 官方 Key → 东京直出 → 上游
                    ├─ channel: 编码 → [DMIT 东京②] Sub2API → 每号独立代理 → 授权账号池
                    └─ image/video → [DMIT 东京②] media worker → 上游异步任务 → R2

10.4 运维与安全要点#

• 副站不对公网开放管理后台；仅主站 IP 白名单访问副站 API。
• 主站、副站数据库与密钥隔离；副站被打穿不直接泄露主站用户体系。
• 号池渠道与官方 Key 渠道分开监控：订阅失效、验证码、封号只影响 Sub2API 渠道。
• 每账号独立静态家宽代理（Sub2API IP 管理绑定）；禁止多号共机房 IP 裸奔。详见《Sub2API 号池运维手册》§4.4。
• 合规：仅使用自有合法授权的订阅与 API Key；号池共享需符合上游服务条款，对外商用自行评估风险。
• 主站运维细节见《New API 中转站运维手册》；副站部署与账号/分组/代理配置见《Sub2API 号池运维手册》。

10.5 职责一句话#

11 · GPT 上游三渠道编排（编码默认 Pro20x）#

上游常见三类（可并存，用 NewAPI 分组 + 优先级编排）：

11.1 编码线推荐编排（当前决策）#

IDE / Agent
  → 主站 NewAPI（coding 分组令牌）
      → P100：sub2api-pro20x-coding
            → Sub2API → 每号独立家宽 → ChatGPT Pro 池
      → P10 ：三方中转（可选 fallback）
      → （可选后续）Azure / 官方 Key 作 vip 稳仓

号池侧硬条件：Sub2API IP 管理 中 1 账号 1 静态家宽；粘性会话开；代理挂则停号，禁止回退 VPS 本机 IP。

11.2 为何编码不默认自建 AZ#

• 自有 Azure 按量接近官网（如 GPT-5.6 Sol 档约 $5 入 / $30 出 /1M tokens），编码长输出成本高。
• 市场廉价「AZ」货源成分复杂，不宜当成本地板。
• Pro20x + 家宽在单价与跟版上更适合写代码；要企业合规/发票/硬 SLA 时再上真 AZ。

11.3 与网络层的关系#

11.4 运维注意#

• 并发 ≈ 有效号数 × 单号会话能力（再受家宽限制）。
• 号池与三方/AZ 分渠道监控；号池异常只降级，不拖垮主站。
• 详细步骤：《Sub2API 号池运维手册》§4.4、§5.3、§6.1。

11.5 Pro20x 号池与生图（尤其 4K）——不要混用#

Pro20x 默认只做文本 / 编码，不做高分辨率生图主力。 社区与实测里常见：「号池能出图，但 4K 支持差 / 不稳 / 被降采样」。

分流建议（写进路由策略）：

文本 / 编码 / Agent     → Pro20x 号池（§11）
生图 ≤2K、要稳要量       → Adobe Firefly 网关（§12，可 firefly-gpt-image-2k-…）
生图 4K / 要 API 参数    → Adobe 4K 模型 id（如 firefly-gpt-image-4k-…）或 AZ/官方 Images API
禁止                     → 默认把 gpt-image-2@4K 打到 Pro20x 渠道

NewAPI 侧：coding 分组 不要挂图像模型；image 分组只挂 Adobe / AZ。若客户端仍用同一 BASE_URL，用 模型名 分流（gpt-5* → Pro20x，gpt-image* / firefly-* → 生图渠道）。

12 · 生图渠道：Adobe Firefly vs AZ gpt-image-2#

当 Azure / 官方 gpt-image-2 生图受限（配额、区域、风控、价高）时，中转站常见备线是 Adobe Firefly 生态生图，再经网关暴露为 OpenAI 兼容接口，接到主站 NewAPI。

12.1 「Adobe 渠道」到底是什么#

本方案说的「Adobe 生图渠道」默认指 B：独立副站跑网关，主站 NewAPI 只填 Base URL + Key。

它不是 Azure 官方 gpt-image-2，而是经 Adobe 入口调用的图像能力（额度、风控、条款跟 Adobe 积分与账号走）。

12.2 与 AZ gpt-image-2 对比#

12.3 常见网关与模型名#

社区常用开源（以仓库 README 为准，迭代快）：

adobe2api 侧 GPT Image 命名习惯（示例）：

firefly-gpt-image-{resolution}-{ratio}
resolution: 1k | 2k | 4k
ratio: 1x1 | 16x9 | 9x16 | 4x3 | …（以网关为准）
质量：部分网关用配置 gpt_image_quality = low | medium | high

客户端若仍请求 gpt-image-2，在 NewAPI 做 Model Mapping，例如：

gpt-image-2     → firefly-gpt-image-2k-1x1
gpt-image-2-4k  → firefly-gpt-image-4k-1x1   # 4K 单独映射，勿进 Pro20x

（目标 id 必须以你部署的网关模型列表为准。不要把 gpt-image* 映射到 Sub2API/Pro20x。）

12.4 推荐拓扑（与主副站正交）#

用户 → 主站 NewAPI
         ├─ 文本/编码 → Sub2API Pro20x（§11，每号家宽）
         └─ 生图 → Adobe 网关副站（内网）
                    └─ Adobe 账号池（+ 代理，按网关要求）
                         └─ Firefly：GPT Image / nano-banana / Firefly Image…
         └─ 生图备用 → AZ gpt-image-2（若仍可用）

生图与编码 分渠道、分分组、分监控，避免图像高峰拖死文本号池。

12.5 NewAPI 渠道配置（生图）#

主力：Adobe 网关

备用：AZ gpt-image-2（可选）

调用形态（以网关为准）：

# 图像专用
POST {base}/v1/images/generations
Authorization: Bearer <key>
{ "model": "firefly-gpt-image-2k-16x9", "prompt": "..." }

# 或 chat 出图（部分网关）
POST {base}/v1/chat/completions
{ "model": "firefly-gpt-image-2k-16x9", "messages": [{"role":"user","content":"..."}] }

12.6 分辨率与路由（2K / 4K）#

对象存储默认 Cloudflare R2（§8.9）； 说明：

• 行业公开信息里，GPT Image 2 的 4K 多在 API 侧且常为 beta；ChatGPT 订阅会话侧更稳的是较低分辨率档。
• adobe2api 等用 模型名后缀 表达分辨率（2k / 4k），比往 Pro 号池塞 size=4096x4096 可靠。
• 4K 更慢、更大、更贵（Adobe 积分 / API token）；超时与网关 quality 配置要单独压测。
• NewAPI：image 分组挂 Adobe（P100）+ 可选 AZ（P10）；禁止 把 gpt-image* 配进 coding/Pro20x 渠道的 Models 列表。

12.7 审核与通道：网页逆向 vs API（451）#

业界常见现象（与你观察一致）：

同一类图，走官方 API / Azure / 部分「正规模式」容易被审掉（如 HTTP 451 或内容策略拒绝）；走网页端 / 订阅会话逆向通道反而能出。

这不是偶发 bug，而是 多套审核与产品策略叠在一起：

451 常见含义（遇到时先分类）：

架构结论：

要「过审率 / 能出图」      → 网页逆向类通道（Firefly 网关 / 会话逆向）作生图主力之一
要「合规、合同、可审计」  → AZ / 官方 API，接受更严审核与更高拒图率
要「成本几分钱 + 质量还行」→ 往往就是大站把网页线规模化后的商品价（≠ 你自建积分成本）

12.8 成本、限制与合规#

12.9 运维要点#

• 积分耗尽、登录失效、代理挂：自动禁用渠道，不要打爆主站重试。
• 451 / content_policy：快速失败或降级到网页线，禁止对同一 API 渠道死磕重试。
• 生图倍率在 NewAPI 单独设，与文本 Pro20x 计费隔离；网页线与 AZ 线可不同倍率。
• 监控：成功率、耗时、451 率、上游错误码、账号/积分水位（网页线与 API 线分开）。
• 编排优先级示例：网页/Firefly 网关 P100 → 其它图模 P50 → AZ gpt-image-2 P10（451 多则 AZ 保持低优先或停用）。
• 4K 走 Adobe 4k 模型 id 或仍可用的 API，不要打 Pro20x；2K 亦可网页线，文本才用号池（§11.5）。
• 主站渠道操作见《New API 中转站运维手册》§16.6；编码号池见 §11 与《Sub2API 号池运维手册》。

13 · 最终选定方案（品牌、配置、价格与实施标准）#

前面章节解释了所有可选路线；本节不再继续列选项，而是给出一套可以直接采购和部署的最终方案。

13.1 最终决策#

采用「两台 DMIT 东京 Premium，核心与业务物理隔离」：

1. DMIT 东京① core-01：用户公网入口、Nginx、NewAPI、PostgreSQL、Redis、监控和备份。
2. DMIT 东京② worker-01：Sub2API 订阅号池、图片 / 视频异步 Worker、生图兼容网关和备用 NewAPI。
3. 每个订阅账号独立静态住宅代理：DMIT②只负责调度，禁止多个账号共用 DMIT 机房 IP 直连上游。
4. 媒体文件使用 Cloudflare R2：参考图、音频、生成图和视频由客户端预签名直传直读，大文件不经过 core-01。
5. 不购买低带宽香港盾机：API 域名使用 Cloudflare DNS only（灰云）直达 core-01；中国模型与海外模型先从东京实测直出。

13.2 采购清单（2026-07-23 价格基准）#

人民币仅按 $1 ≈ ¥7.20 做预算换算，不含税和汇率波动。DMIT 价格页注明产品和价格可能未及时同步，本文记录的是 2026-07-23 页面显示值；实际库存、税费、续费价和最终规格以下单页结算为准。

月度固定成本：

不计入上表：域名、模型 API 费用、合法授权的订阅账号、住宅代理、Adobe 积分或第三方生图 / 视频采购。这些是业务用量成本，不能与服务器固定成本混为一笔。

价格与网络依据：DMIT Pricing、DMIT Tokyo Location、Cloudflare R2 Pricing。

13.3 为什么两台都选 MEDIUM，而不是一高一低#

DMIT 东京 Premium 当前公开档位中，MINI 为 2 vCore / 4 GB / 60 GB / 2 TB / 1 Gbps，$89.90/月；MEDIUM 为 4 vCore / 8 GB / 160 GB / 6 TB / 1 Gbps，$320.90/月。

core-01 需要同时运行 NewAPI、PostgreSQL、Redis、日志和备份；worker-01 需要运行 Sub2API、图片 / 视频任务、浏览器型网关与备用 NewAPI。两边都只有 4 GB 会让操作系统和 Docker 几乎没有突发余量，也无法在故障时互相接管。因此稳定性优先时，两台统一 MEDIUM，便于镜像、Compose、监控阈值和故障切换保持一致。

如果必须压缩预算，可以把 worker-01 临时降为 MINI，但这属于成本优先降级方案：不能承担本地转码，浏览器型网关并发要严格限制，也不应把它宣传为完整热备。

13.4 两台服务器具体跑什么#

两台都保留约 1.5～2 GB 给 Ubuntu、Docker、文件缓存和突发峰值。视频由上游生成，本机只做任务编排和结果转存，不需要 GPU；如果以后执行本地 FFmpeg 转码或本地模型推理，新增专用计算节点，不与 Sub2API 抢资源。

core-01 对公网只开放 Nginx 的 80/443。worker-01 的 Sub2API、队列、网关和备用 NewAPI 默认只允许 core-01 的 WireGuard 地址访问；两台 SSH 都只允许固定管理 IP 或 VPN。

13.5 最终路由规则#

13.6 网络与端口基线#

关键配置：

• API 域名使用 Cloudflare 灰云，正常解析到 core-01；故障时按演练流程切到 worker-01 备用 NewAPI。
• core-01 与 worker-01 通过 WireGuard / 私网白名单通信，不把内部服务暴露到公网。
• 图片与视频使用 R2 自定义域和预签名 URL，大文件不经过 core-01 的 Nginx / NewAPI 数据面。
• Nginx 对 SSE / 流式响应关闭 proxy_buffering，连接超时按长请求设置。
• 主副节点的 Compose、镜像版本和非敏感配置同步；密钥进入 Secret，不进入 Git。
• 管理后台增加 IP 白名单 + MFA；Sub2API / 生图网关管理面禁止公网访问。

13.7 数据、备份与监控#

13.8 什么时候扩容#

13.9 下单与上线顺序#

1. 在 DMIT 官方下单页确认东京 Premium MEDIUM 库存、续费价和规格后，同时购买两台。
2. core-01 部署 Docker Compose、Nginx、NewAPI、PostgreSQL、Redis、监控和备份。
3. worker-01 部署 Sub2API、队列、media worker、生图网关与备用 NewAPI；两台建立 WireGuard。
4. 配置每账号独立住宅代理、海外 / 中国模型渠道，以及 R2 预签名上传和下载。
5. API DNS 灰云指向 core-01；公网只开放必要端口，内部服务仅 WireGuard 可达。
6. 压测 SSE、30～50 并发、长文本、订阅号池、生图、视频任务、R2 直传和断线重连。
7. 主动停止 core-01，验证数据库恢复、worker-01 备用 NewAPI 和 DNS 切换流程。

上线验收必须同时通过：

• 国内电信、联通、移动能稳定连接日本入口，流式输出不中断。
• core-01 公网只有 80/443 可访问；数据库、Redis、Sub2API、队列和生图网关端口均被拒绝。
• OpenAI / Anthropic / Gemini 与 DeepSeek / 通义 / 智谱 / Kimi 均能从日本稳定调用。
• Sub2API 每个账号均绑定独立静态住宅代理，代理故障时不会回退 DMIT 本机 IP。
• 参考图、图片和视频通过 R2 预签名 URL 直传直读，不穿过 NewAPI 大文件代理。
• 从 R2 备份恢复出的 worker-01 临时数据库能够正常登录并识别现有令牌。
• core-01 故障演练中，备用 NewAPI 能按流程接管，RTO 达到 15～30 分钟目标。

最终一句话：现在采购 DMIT 东京 Premium MEDIUM × 2，每台 4 vCore / 8 GB / 160 GB SSD / 6 TB / 1 Gbps、$320.90/月，两台约 $641.80/月（约 ¥4,621/月）。core-01 负责 NewAPI 与数据库，worker-01 负责 Sub2API 订阅号池、图片 / 视频异步任务和备用 NewAPI；每账号独立住宅代理，媒体文件使用 R2 直传直读，不购买低带宽香港盾机。