使用openai翻译时，请求包太小，导致请求次数多、费用高

[seeflood]

您希望的更新和改进是什么 | Update or Improve

背景

这两天尝试把逆向poe.com 的api 封装成 openai风格的api，让插件调用。但是调几次就会被封号。
我感觉很奇怪，因为我已经小心调整插件的参数、把速度调到最慢了。
于是抓包研究了下，发现了这个问题

问题描述

在使用openai翻译时，每次请求的payload比较小，经常只翻译一句话，例如:

这会导致:

1. 翻译一篇文章时，prompt 占比高，整体费用高。 OpenAI翻译网页的的请求量太大了，费用很高 #353
2. 小请求会导致调用次数多，而调用次数多会导致以下问题
   2.1. 在使用第三方api代理时(例如 api2d.com ）非常贵。这些第三方代理的收费策略对小请求不友好，比如一个请求明明只花费20token，但是代理会认为“不足100token的，按花了100 token算钱” https://api2d.com/wiki/doc#usage

2.2. 在使用逆向的api 时，因为短时间内请求次数多，导致容易被风控发现、封号

尝试过的解决方案

我尝试了把插件配置里的“每次请求最大段落数”调大

但这样做有问题:

• 渲染慢。插件当前不支持流式渲染，比如我一次发7个段落的包:

插件会等这7个段落的翻译结果全返回了，才一次性渲染7个段落，导致渲染慢
（理想情况下，应该是一个段落的结果出现后，立刻渲染）

• 依然有一些小请求

解决方案

有3个方案

A. 在插件之外实现一个API 网关，把小请求聚合，做批处理优化

我本来想这么搞，但仔细想了下，这个方案展开讨论的话太复杂，比如: 不知道包的顺序，可能乱序; 比如: 如果并发太低，又会出现“小包导致队头阻塞”的问题

B. 流式渲染

#328
缺点如 @theowenyoung 所说:

每一个段落都用流去展示的话，其实看起来会有点乱。

C. 一次翻译多个段落，但是渲染时按段落渲染

比如一个请求要求翻译5个段落，但是在接收流式结果时，一旦发现第一个段落翻译完成后，立刻渲染第一个段落 (而不是等到5个段落的翻译全返回了再渲染）
这样就不需要支持流式渲染，不会导致排版混乱；也能保证渲染速度，用户体验好；完美解决问题

补充说明 | Additional context

我个人倾向C方案，也愿意帮忙贡献代码~

[seeflood]

cc @versun @theowenyoung 可以帮忙看下这个问题不~

[seeflood]

补充一个新发现的问题，请求包太小，导致翻译时没有文章上下文、翻出来的东西不对
和这个issue说的一样:
#164

[theowenyoung]

抱歉这么晚才回复，理论上目前 OpenAI 的设置里面已经提供了 每次最多发送多少个段落选项：

所以这个方案3是否可以认为已实现？

[keyboard3]

暂无反馈 关闭此问题