> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sub2api.ruilinlu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API 响应延迟较高排查

> 导致 API 响应延迟升高的常见原因，以及如何通过流式响应和模型选择改善体验。

API 响应延迟（Latency）是用户在使用 AI 服务时最关心的指标之一。当你感觉 Sub2API 返回结果较慢时，可能是模型本身处理时间较长、网络传输距离远或请求上下文过大等多种因素叠加导致的。本文将帮助你定位延迟来源并提供优化方案。

## 常见原因

<Accordion title="大模型首 Token 时间（TTFT）较长">
  参数规模更大的模型（如 GPT-4、Claude Opus）在处理复杂任务时需要更长的计算时间，首 Token 返回时间（Time To First Token，TTFT）自然更长。
</Accordion>

<Accordion title="上下文窗口过大">
  如果你的请求包含大量历史消息或长文本，模型需要先加载和处理全部上下文，这会显著增加响应延迟。
</Accordion>

<Accordion title="系统高负载时段">
  在高峰期，上游供应商的算力资源可能处于高负载状态，处理速度会相应下降。
</Accordion>

<Accordion title="网络传输距离">
  客户端与 Sub2API 服务器之间的网络延迟，以及 Sub2API 与上游之间的网络延迟，都会影响整体响应时间。
</Accordion>

## 解决方法

### 启用流式响应

流式响应（Streaming）不会等到完整结果生成后才返回，而是逐步输出每个 Token，让用户更快看到内容开始。这是改善主观体验最有效的手段。

```python theme={null}
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "写一篇关于人工智能的文章"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")
```

更多关于流式响应的用法，请参考 [流式传输](/api/streaming)。

### 选择更快的模型

不同模型的响应速度差异明显。在性能优先的场景下，可以选择轻量级模型：

* Claude Haiku：速度快、成本低
* Gemini Flash：响应快，适合高频调用
* GPT-4o mini：轻量且延迟低

### 减少上下文大小

<Steps>
  <Step title="精简请求内容">
    删除不必要的历史消息和冗余文本，只保留对当前任务最关键的信息。
  </Step>

  <Step title="使用摘要代替完整历史">
    对于多轮对话，考虑定期将历史消息压缩为摘要，减少每次请求携带的 Token 数量。
  </Step>

  <Step title="拆分长任务">
    将一个超长的任务拆分为多个小请求串行处理，避免单次请求处理时间过长。
  </Step>
</Steps>

### 检查网络连通性

<Steps>
  <Step title="测试到 Sub2API 的网络延迟">
    使用 `ping` 或 `curl` 测试到 `https://sub2api.ruilinlu.com` 的 RTT，确认基础网络质量。
  </Step>

  <Step title="选择更近的接入点">
    如果你的部署位置与 Sub2API 服务器地理距离较远，考虑将服务部署到更近的区域以降低网络延迟。
  </Step>
</Steps>

## 有效预防

* 对用户体验敏感的交互场景，始终启用流式响应
* 建立模型选择策略：复杂推理用大模型、简单任务用小模型
* 定期监控 API 延迟指标，设置异常告警阈值
* 优化 Prompt 设计，减少不必要的上下文开销

API 响应延迟（Latency）是用户在使用 AI 服务时最关心的指标之一。当你感觉 Sub2API 返回结果较慢时，可能是模型本身处理时间较长、网络传输距离远或请求上下文过大等多种因素叠加导致的。本文将帮助你定位延迟来源并提供优化方案。

## 常见原因

<Accordion title="大模型首 Token 时间（TTFT）较长">
  参数规模更大的模型（如 GPT-4、Claude Opus）在处理复杂任务时需要更长的计算时间，首 Token 返回时间（Time To First Token，TTFT）自然更长。
</Accordion>

<Accordion title="上下文窗口过大">
  如果你的请求包含大量历史消息或长文本，模型需要先加载和处理全部上下文，这会显著增加响应延迟。
</Accordion>

<Accordion title="系统高负载时段">
  在高峰期，上游供应商的算力资源可能处于高负载状态，处理速度会相应下降。
</Accordion>

<Accordion title="网络传输距离">
  客户端与 Sub2API 服务器之间的网络延迟，以及 Sub2API 与上游之间的网络延迟，都会影响整体响应时间。
</Accordion>

## 解决方法

### 启用流式响应

流式响应（Streaming）不会等到完整结果生成后才返回，而是逐步输出每个 Token，让用户更快看到内容开始。这是改善主观体验最有效的手段。

```python theme={null}
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "写一篇关于人工智能的文章"}],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")
```

更多关于流式响应的用法，请参考 [流式传输](/api/streaming)。

### 选择更快的模型

不同模型的响应速度差异明显。在性能优先的场景下，可以选择轻量级模型：

* Claude Haiku：速度快、成本低
* Gemini Flash：响应快，适合高频调用
* GPT-4o mini：轻量且延迟低

### 减少上下文大小

<Steps>
  <Step title="精简请求内容">
    删除不必要的历史消息和冗余文本，只保留对当前任务最关键的信息。
  </Step>

  <Step title="使用摘要代替完整历史">
    对于多轮对话，考虑定期将历史消息压缩为摘要，减少每次请求携带的 Token 数量。
  </Step>

  <Step title="拆分长任务">
    将一个超长的任务拆分为多个小请求串行处理，避免单次请求处理时间过长。
  </Step>
</Steps>

### 检查网络连通性

<Steps>
  <Step title="测试到 Sub2API 的网络延迟">
    使用 `ping` 或 `curl` 测试到 `https://sub2api.ruilinlu.com` 的 RTT，确认基础网络质量。
  </Step>

  <Step title="选择更近的接入点">
    如果你的部署位置与 Sub2API 服务器地理距离较远，考虑将服务部署到更近的区域以降低网络延迟。
  </Step>
</Steps>

## 有效预防

* 对用户体验敏感的交互场景，始终启用流式响应
* 建立模型选择策略：复杂推理用大模型、简单任务用小模型
* 定期监控 API 延迟指标，设置异常告警阈值
* 优化 Prompt 设计，减少不必要的上下文开销