RE:CZ

将每日网络等待从3小时压缩到3分钟

系统架构

👤 关注AI应用架构、跨境网络优化和云部署的开发者与技术负责人
文章基于2026年7月16日至9月8日生产环境的513,336次真实调用，分析旧架构中推理流量跨国传输导致的性能瓶颈。数据显示，推理流量约占总流量98.3%，每天造成近3小时网络等待。通过将推理设备部署到AWS US、让其与OpenAI走低延迟内网，同时仅将工具参数和结果在AWS与中国主力机之间传输，跨国流量从7.94GB降至0.14GB，网络等待缩短至约3分钟。
  • ✨ 旧架构中推理请求与响应平均约794KB/次，占总流量98.3%。
  • ✨ 每天约7.94GB推理流量跨国传输，造成近3小时网络等待。
  • ✨ 将推理设备部署到AWS US，并通过内网连接OpenAI。
  • ✨ 中国主力机仅执行工具并传输轻量控制数据，跨国流量降至0.14GB。
  • ✨ 每日网络等待从约3小时降至约3分钟，降低约98.3%。
📅 2026-09-08 · 1,447 字 · 约 6 分钟阅读
  • 架构优化
  • 网络性能
  • AWS
  • OpenAI
  • 工具调用
  • 推理部署

Table of Contents

用 50 万次真实调用，我把每日网络等待从 3 小时压到了 3 分钟一、先说结论二、背景：旧架构为什么慢三、数据会说话四、解决方案：从“全家桶”到“分离部署”新架构：推理留在 AWS，工具留在 CN五、最终结果六、数据可靠性说明七、总结

用 50 万次真实调用，我把每日网络等待从 3 小时压到了 3 分钟

2026-09-08

数据来源：2026-07-16 至 2026-09-08，513,336 次生产环境调用

一、先说结论

如果你没时间看完，这是最核心的一句话：

基于 50 万次真实 API 调用数据，我把每天的网络传输等待时间从大约 3 小时压缩到了 3 分钟。

怎么做到的？——把推理和工具执行拆开，让大流量走内网，小流量过跨国。

下面是完整过程和真实数据。

二、背景：旧架构为什么慢

最开始，我的主力机部署在中国大陆，上面跑着 CodeX。CodeX 是一个完整的 AI 应用开发框架，它负责调用 OpenAI API、管理对话上下文、执行工具调用……所有事情都在一台机器上完成。

它的网络拓扑是这样的：

flowchart LR
    A[CN 主力机<br>CodeX] -->|公网请求<br>VPN + Cloudflare| B[OpenAI API]
    B -->|推理响应<br>~794 KB / 次| A

每一次推理请求，都要从中国经过 VPN、Cloudflare，跨越太平洋到达 OpenAI，然后再把结果传回来。这条链路的特征非常不友好：

  • 带宽：10 Mbps（实际有效吞吐约 0.75 MB/s）
  • 延迟：RTT 约 300ms，且时常波动
  • 稳定性：偶发丢包、重传

在这个架构下，每天 10,000 次调用，光是等网络传输数据，就要花大约 3 个小时。

这 3 个小时里，CodeX 什么也没做——只是在等网络。

三、数据会说话

为了搞清楚“3 小时”到底花在哪里，我拉取了旧架构下 2026 年 7 月 16 日到 9 月 8 日的全部访问日志，一共 513,336 次有效调用——这个样本量足够说明问题了。

我统计了单次调用的流量构成：

流量类型 平均大小 日总量（×10,000）
推理请求 + 响应 794,338 Bytes（~794 KB） 7.94 GB
工具调用参数 591.59 Bytes —
工具调用响应 13,387.34 Bytes —
工具调用合计 13,978.93 Bytes（~13.65 KB） 0.14 GB

两组数据相差 58 倍。推理流量占了总流量的 98.3%，工具控制信号只占 1.7%。

然后算了一笔时间账：

推理流量过海：

7.94 GB = 7,940 MB ÷ 0.75 MB/s ≈ 10,587 秒 ≈ 2.94 小时

工具控制流量过海（如果单独传的话）：

0.14 GB = 140 MB ÷ 0.75 MB/s ≈ 187 秒 ≈ 3 分钟

问题找到了：每天将近 3 小时花在传推理流量上，但这些数据根本就不应该走跨国链路。

四、解决方案：从“全家桶”到“分离部署”

既然问题出在“所有事情都在 CN 主力机上做，所有流量都要过海”，那解决方案就是把事情拆开。

新架构：推理留在 AWS，工具留在 CN

我把推理能力从 CodeX 里剥离出来，部署到了 AWS US：

flowchart LR
    subgraph CN["🇨🇳 CN 主力机"]
        T[工具执行环境]
        C[HTTP/2 客户端]
    end

    subgraph AWS["☁️ AWS US"]
        R[推理设备<br>Rust + SQLite]
        O[OpenAI API]
    end

    C -->|工具参数下行<br>591.59 Bytes| R
    C -->|工具结果上行<br>13,387.34 Bytes| R
    R <-->|推理流量<br>7.94 GB/天 内网闭环| O

这个新架构的核心变化是：

  1. 推理设备（一个轻量的 Rust 服务器 + SQLite）部署在 AWS US，和 OpenAI 在同一个区域
  2. 推理设备和 OpenAI 之间走 AWS 内部骨干网：延迟 <10ms，带宽 Gbps 级别
  3. CN 主力机不再直接调用 OpenAI，只负责两件事：
    • 接收推理设备推送过来的工具调用参数（591.59 Bytes）
    • 执行完工具后，把结果（13,387.34 Bytes）传回推理设备
  4. SQLite 在推理设备侧维护对话上下文，CN 主力机是无状态的

对比一下旧架构和新架构的跨国链路：

对比项 旧架构（CodeX 在 CN） 新架构（推理在 AWS US）
跨国链路传输内容 推理请求 + 响应（794 KB / 次） 工具参数 + 结果（13.65 KB / 次）
日跨国流量 7.94 GB 0.14 GB
到 OpenAI 的延迟 ~300ms（公网） <10ms（AWS 内网）

五、最终结果

指标 旧架构 新架构 变化
跨国日流量 7.94 GB 0.14 GB 缩小 56.7 倍
跨国传输耗时 2.94 小时 3 分钟 ↓ 98.3%
到 OpenAI 的网络延迟 ~300ms（公网） <10ms（AWS 内网） ↓ 30 倍
每日网络等待总计 约 3 小时 约 3 分钟 ↓ 98.3%

六、数据可靠性说明

  • 统计周期：2026-07-16 16:50 至 2026-09-08 09:51（中国标准时间）
  • 样本总量：513,336 次调用，生产环境全量日志，非抽样
  • 流量统计：基于实际 HTTP 请求/响应体大小
  • 工具调用参数：591.59 Bytes / 次
  • 工具调用响应：13,387.34 Bytes / 次
  • 带宽估算：按实测有效吞吐 0.75 MB/s 计算（非理论值 1.25 MB/s）
  • RTT 估算：按实测 300ms 计算（含 VPN + Cloudflare 叠加）

所有原始日志均可导出验证。

七、总结

我没有升级带宽，没有换更强的机器，也没有让 OpenAI 跑得更快。

我只是做了一件事：把推理和工具执行拆开。

  • 推理（重流量）留在 AWS US，和 OpenAI 做邻居
  • 工具执行（轻控制信号）留在 CN 主力机

结果是：每天 3 小时的网络等待，变成了 3 分钟。

数据驱动的架构优化，没有玄学，只有实打实的数字。

数据来源：生产环境推理设备访问日志，样本量 513,336 次调用。 统计周期：2026-07-16 16:50 至 2026-09-08 09:51（CST）。

See Also