海外模型调用延迟优化：从网络到代码的全栈指南

国内调用海外大模型 API 的延迟通常明显高于国内模型，但通过合理的架构设计和接入策略，可以将用户感知延迟控制在可接受范围内。本文从网络、架构和代码三个层次系统梳理合规可用的优化手段。

延迟的构成分析

调用海外大模型 API 的端到端延迟由以下部分叠加：

延迟来源	典型范围	可优化性
跨境网络 RTT	100-400ms（取决于节点位置）	中（选节点、用专线）
TLS 握手	50-100ms（首次连接）	高（连接复用）
模型推理时间	500ms-10s+（取决于模型和 prompt 长度）	低（取决于服务商）
首 token 延迟（TTFT）	上述之和	中（流式输出）
输出 token 生成速度	模型固有	低

理解各段延迟来源，才能对症下药，而不是盲目”优化”。

先学会实测，再谈优化

很多人上来就猜”是不是网络慢""是不是模型慢”，猜错了方向，优化半天没效果。正确的做法是先把延迟拆开测出来，再决定改哪一段。用 curl 自带的 timing 变量就能拆分出连接、TLS、首字节各段耗时，不需要额外抓包工具：

curl -w "\ndns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
  -o /dev/null -s \
  -X POST https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"你好"}]}'

你应该看到类似这样的输出（数值仅示例，实际以你的网络环境为准）：

dns: 0.012s
connect: 0.180s
tls: 0.420s
ttfb: 1.350s
total: 1.680s

拿到这组数字之后怎么判断该往哪个方向使劲：

• connect 和 tls 加起来如果超过 300ms，说明是网络层的问题（跨境路由绕远、握手慢），该去换节点或加连接复用，而不是去优化 prompt。
• ttfb - tls 这一段才是模型真正的”思考时间”，如果这段占了大头（比如超过 1 秒），说明瓶颈在推理侧，优化方向应该是精简 prompt、换轻量模型，或者开流式输出降低用户感知。
• 同一个请求连续测 5-10 次，看波动范围。如果 connect 时间时高时低、波动很大（比如从 80ms 跳到 500ms），大概率是跨境线路本身抖动，这种情况换云厂商加速产品比在代码里死磕更划算。

把这套方法记下来，后面每次做优化前后都测一遍，才知道改动有没有真效果，不然全靠”感觉快了”是没法向老板汇报的。

网络层优化

1. 选择亚太区 API 端点

不同服务商的亚太节点到国内延迟差异显著：

服务商 / 节点	到国内典型 RTT
Azure OpenAI 日本东区	60-100ms
Azure OpenAI 新加坡	70-120ms
Google Vertex AI 新加坡	80-130ms
OpenAI 直连（美国）	200-350ms
Anthropic 直连（美国）	200-350ms

以上为参考范围，实际延迟受运营商线路和时段影响。优先选择亚太节点是最简单有效的网络层优化。

2. 使用云厂商跨境加速产品

阿里云 Global Accelerator、腾讯云 Anycast 等产品可通过云厂商的骨干网络传输跨境流量，降低公网抖动。适合延迟敏感且有合规需求的企业，费用按流量计费，需评估 ROI。

3. 连接复用

避免每次请求重建 TCP+TLS 连接，使用 HTTP/1.1 Keep-Alive 或 HTTP/2，可节省每次 50-100ms 的握手开销。主流 HTTP 客户端默认支持连接复用，注意连接池大小配置。

这里有个坑很多人会踩：用 requests 库直接 requests.post(...) 调用，看似方便，但每次调用都是新建一个连接，之前提到的 TLS 握手开销一分都省不了。想复用连接必须显式用 Session，并且把连接池大小配置够，否则并发一高，连接池不够用照样要排队新建连接：

import requests
from requests.adapters import HTTPAdapter

session = requests.Session()
# pool_connections 是不同 host 的连接池数量，pool_maxsize 是单个 host 的最大连接数
adapter = HTTPAdapter(pool_connections=10, pool_maxsize=50, max_retries=0)
session.mount("https://", adapter)

# 后续所有请求都用这个 session，而不是 requests.post
resp = session.post(url, headers=headers, json=payload, timeout=(3, 30))

timeout=(3, 30) 这个写法要注意，第一个数字是连接超时（3 秒内建不上连接就放弃），第二个是读超时（拿到响应第一个字节之后，两次数据包之间最多等 30 秒）。很多人只写一个 timeout=30，遇到网络层直接连不上的情况（比如 DNS 解析失败、跨境线路完全中断）也要傻等 30 秒才报错，体验很差。把连接超时设短一点（3-5 秒），读超时按你业务能接受的最长等待设，两者分开配置。

如果你用的是异步框架，httpx.AsyncClient 同理要配置 limits：

import httpx

client = httpx.AsyncClient(
    limits=httpx.Limits(max_connections=50, max_keepalive_connections=20),
    timeout=httpx.Timeout(connect=3.0, read=30.0),
)

max_keepalive_connections 决定了有多少条连接会被保活复用，设得太小，高并发下大部分请求还是要走冷启动握手，等于白配置了连接池。

架构层优化

4. 流式输出（Streaming SSE）

所有主流海外模型 API 均支持流式响应（SSE，Server-Sent Events）。开启后，首个 token 到达即可开始向用户渲染，用户感知的”等待时间”从完整响应时间降至首 token 时间（TTFT）。

# OpenAI 兼容接口流式调用示例（逻辑示意）
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[...],
    stream=True  # 开启流式
)
for chunk in response:
    print(chunk.choices[0].delta.content, end="", flush=True)

对于 B 端工具类产品，流式输出是降低用户感知延迟最高 ROI 的单项优化。

5. 语义缓存

对同语义的高频查询做结果缓存（如使用向量相似度判断是否为相同意图），可将重复查询的延迟从秒级降至毫秒级，同时大幅降低 API 成本。适合 FAQ 问答、固定 prompt 的内容生成等场景。

6. 请求预热与并发控制

• 预热连接：在业务低峰期保持少量长连接，避免冷启动握手延迟。
• 并发限制：海外模型 API 有 RPM（每分钟请求数）和 TPD 限制，超限触发 429 错误，需在客户端做令牌桶或漏桶限流。
• 队列异步化：非实时任务（批量生成、定时报告）放入队列异步处理，避免占用实时接口配额。

具体到代码怎么写，用 asyncio.Semaphore 控制并发上限是最省心的办法，比手写令牌桶简单得多，适合大多数中小规模场景：

import asyncio
import httpx

MAX_CONCURRENT = 8  # 按你账号的 RPM 限额倒推，别设太满
semaphore = asyncio.Semaphore(MAX_CONCURRENT)

async def call_model(client: httpx.AsyncClient, prompt: str) -> str:
    async with semaphore:  # 拿不到信号量就在这里排队等待
        resp = await client.post(url, json={"model": "gpt-4o-mini", "messages": [
            {"role": "user", "content": prompt}
        ]})
        resp.raise_for_status()
        return resp.json()["choices"][0]["message"]["content"]

async def main(prompts: list[str]):
    async with httpx.AsyncClient(timeout=30) as client:
        tasks = [call_model(client, p) for p in prompts]
        return await asyncio.gather(*tasks, return_exceptions=True)

MAX_CONCURRENT 怎么定不是拍脑袋。假设你的账号限额是 RPM=60（每分钟 60 次请求），单次请求平均耗时 2 秒，那么理论上稳态并发数是 60/60*2 ≈ 2，留出余量设成 3-4 比较稳；如果直接设成 8、10 这种数字，大概率没跑几轮就开始收到 429。批量任务建议先按限额的 60%-70% 起步，跑稳了再往上加，别一上来就打满。

429 报错在不同厂商长得不完全一样，但套路类似。OpenAI 返回的错误体通常是：

{"error": {"message": "Rate limit reached for gpt-4o-mini in organization org-xxx on requests per min (RPM): Limit 60, Used 60, Requested 1.", "type": "requests", "code": "rate_limit_exceeded"}}

看到这种信息不要马上重试，先看响应头里的 Retry-After（有些厂商会给，单位是秒），没有的话用指数退避 + 抖动（比如第一次等 1 秒，第二次 2 秒，第三次 4 秒，每次再加一点随机值避免多个请求同时重试撞车），连续退避 3-4 次还失败再报错给上层，不要无限重试。更完整的重试策略和降级方案可以参考 海外模型稳定性与重试策略，这里不重复展开。

还有一种常见报错是超时后的 httpx.ReadTimeout 或 requests.exceptions.ReadTimeout，这类报错不代表请求失败了，只代表你等的时间不够长——服务器可能还在算，只是没在你设的超时时间内返回。遇到这种情况先别急着重试（重试等于又占用一次配额、又要重新排队），可以先把 read timeout 调大一点观察是不是稳定复现，如果是长文本生成任务，超时时间给到 60-120 秒都是正常的。

7. 国产模型兜底切换

对延迟 SLA 要求严格的场景（如 P95 < 3 秒），可设置超时阈值，海外模型超时后自动切换至国产模型。多数国产模型（DeepSeek、Qwen 等）的响应延迟在国内环境下更稳定。

代码层优化

8. 减少 Prompt 长度

推理时间与 input token 数正相关。在不影响效果的前提下：

• 精简 system prompt，去除冗余说明
• 对长文档做预处理摘要或 RAG 切片，而非整文喂入模型
• 使用 prompt caching（Claude、GPT 等均支持）复用重复前缀

9. 选择适配任务的轻量模型

旗舰模型（GPT-4o、Claude 3.5 Sonnet）推理速度慢于轻量模型（GPT-4o mini、Claude 3 Haiku）。对于分类、抽取、简单摘要等任务，轻量模型通常足够，延迟可降低 50-80%。

常见问题

优化后国内调用海外模型能达到什么延迟水平？
经过亚太节点选择 + 流式输出 + 连接复用的综合优化，TTFT（首 token 延迟）通常可控制在 800ms-2s 以内（亚太节点），完整响应时间取决于输出长度。实时对话场景体验可接受，但无法与国内模型的百毫秒级相比。

流式输出在所有场景下都适用吗？
不完全适用。需要完整响应再做后处理（如 JSON 解析、结构化输出）的场景，流式输出会增加代码复杂度，需要做流式 JSON 的增量解析。建议根据场景权衡。

语义缓存如何实现？
主流方案是将请求 prompt 向量化，在向量数据库（如 Redis + RedisVL、Qdrant）中做近似搜索，相似度超过阈值则返回缓存结果。需注意缓存的失效策略和知识库更新时的缓存刷新机制。

---

本文仅作技术与合规科普，企业请通过合规渠道接入海外模型，遵守数据出境等相关规定。

相关阅读：国内合规调用 Claude/GPT/Gemini 指南 · 海外模型稳定性与重试策略 · 海外模型合规接入专题

如需了解企业合规聚合接入方案，欢迎访问 力达云等候名单。