生产环境流量偏高：纯文本请求下出站流量仍大，需流量观测与重试/stream优化

[webwww123]

问题描述

线上观察到 grok2api 网络流量持续偏高。乍看请求几乎都是文本请求（/v1/chat/completions），但出站流量依然很大，希望确认是否存在可优化点。

现象与量化数据（只读排查）

统计窗口：最近 24 小时（约 2026-02-25 19:15 +08 到 2026-02-26 19:15 +08）

1. 来源贡献（请求量口径）

• new-api -> grok2api：99.46%
• 其他来源：0.54%

2. 接口贡献（请求量口径）

• /v1/chat/completions：99.58%
• 其他接口：0.42%

3. stream 贡献

• stream 请求占比：33.62%
• 但 stream 对应 completion tokens 占比：54.48%（说明流式输出对下行流量贡献偏高）

4. 重试/失败放大

• 上游失败尝试占全部上游尝试：6.29%
• 相比纯成功请求的额外开销：6.71%
• 失败中：429 占 86.18%，403 占 13.24%

5. 调用结构补充

• 在该窗口内，/v1/chat/completions 请求约 5 万级，文本请求量本身很大。

期望

希望项目侧能提供/改进以下能力，便于控制流量：

1. 内置流量观测指标

• 按 endpoint / model / stream / status 的请求数与字节数统计（in/out）

2. stream 流量优化开关

• 可配置 chunk 频率/合并策略
• 明确 gzip/brotli 在流式场景下的建议配置

3. 429 场景下的重试策略优化

• 更清晰的可配置项（总预算、退避、并发限制、失败快速返回）
• 降低无效重试对流量与上游压力的放大

4. token 刷新与 usage 查询的节流建议

• 给出高并发生产场景推荐值
• 降低辅助调用在高峰期的额外负载

5. 文档补充

• 给出“纯文本高并发 + stream”场景下的大致流量估算区间，帮助容量规划

环境信息

• 部署方式：Docker
• 镜像：ghcr.io/chenyme/grok2api:latest
• SERVER_WORKERS=1
• 生产环境，排查全程只读

如果需要，我可以补充更细的日志切片（按小时峰值、状态码分布、stream/非stream对比）。

[webwww123]

补充一个更直观的核心结论（生产实测）：

我们现在的痛点

grok2api 实际日流量大约在 500GB/天量级（出站为主），已经明显超出我们对“纯文字请求”场景的预期。

我们理解高并发+stream会放大流量，但当前量级在生产成本和稳定性上都压力很大，因此希望项目侧优先支持“可观测 + 可控”的降流量能力。

目前我们看到的结构（简述）

• 请求几乎都在 /v1/chat/completions
• 主要是文本请求，但 stream 占比较高，导致下行放大
• 429/403 导致额外重试，进一步放大流量

诉求（按优先级）

1. 增加官方流量观测指标（endpoint/model/stream/status 的 in/out bytes）
2. 提供 stream 粒度/合并策略开关（降低 chunk 级开销）
3. 优化 429 场景的重试策略（减少无效重试流量）

如果需要，我们可以继续提供更细的生产样本数据协助定位。