-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2个新特性 #653
base: main
Are you sure you want to change the base?
2个新特性 #653
Conversation
highkay
commented
Feb 20, 2025
- 增加多api_key轮换,用,分割
- 支持推理模型移除think标签
- 支持多个 API key,提高请求效率 - 添加错误处理机制,增强稳定性 - 实现客户端自动切换,提升容错能力 - 优化代码结构,提高可维护性
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
需要改进一下线程安全,另外优化一下代码结构。其他的还没想好,我有空时再想想
client = self.clients[self.current_client_index] | ||
|
||
# 更新index为下一个client | ||
self.current_client_index = (self.current_client_index + 1) % len(self.clients) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.current_client_index = (self.current_client_index + 1) % len(self.clients)
不是线程安全的。这句话会被多个线程并行调用。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
了解
return content.strip() | ||
|
||
except Exception as e: | ||
# 如果当前client失败,尝试使用其他client |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
是不是把调用某个client发请求并获取响应的代码抽成函数,然后再递归调用自己来实现这个自动重试的逻辑比较好?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这个其实我也没想好。我觉得比较好的设计是提供一种default的重试策略,然后不同的translator去覆盖,比如有的是429,那么重试应该降低请求频率,有的是安全围栏,那么应该换translator(比如google),而不是一味的连续重试,毕竟网络质量问题不是我遇到的最多的问题。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
先去掉吧,再开个issue追踪。整一套translator重试策略,并且允许配置多个translator感觉比较好。可以放到pdf2zh 2.0里做
content = response.choices[0].message.content.strip() | ||
|
||
# 过滤掉<think>标签内的内容 | ||
if "<think>" in content and "</think>" in content: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
这里没必要再多一个if。如果原文不包含这两个tag,re.sub应该是啥都不会干吧。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我把这个if去掉,然后改成预编译的吧
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re内部有缓存。另外你可以在初始化translator的时候compile一下re。
另外,判断字符串是否为子串开销也不小
@Byaidu @hellofinch 我不清楚多key轮换要不要加入到pdf2zh,你们俩看法? |
主要是免费的服务会有这种需求(白嫖),绕过一些tpm或者qps的限制,有点偏灰色,不鼓励,但是的确有需求吧,所以你写一个就用一个咯,对不需要人的也没啥影响。 |
但是对维护代码有影响啊... |
抽象一个client池,然后每次borrow一个出来?这样代码也更干净一些。 |
抽象一个translator池吧。后面只需要在borrow的时候按策略borrow就能实现自动换翻译器重试等。 |
这里正好有一个设计问题我有点不太明白,看converter应该是可以支持不同种类的translator的(当然也存在不好编排的问题),这种架构当初是怎么想的? 大概是这样一种抽象层级, |
这块在pdf2.0中完全重写了,现有版本忽略就好。我不建议给pdf2zh 1.x添加这个功能。等到pdf2zh 2.0出来了再整吧,到时候架构会好很多 |
除了translator,其他部分代码都得大改 |
这个想法很棒,但是维护起来的成本要考虑,2.0的话需要对这些部分都需要设计和重构,borrow的话地设置好相关的策略。 |
再补一句,推荐开一个issue或者PR用来讨论2.0的一些功能和设计。 |
#586 这里讨论2.0 |
只能 每次触发translate的时候就borrow |
那不是乱七八糟的?上一句deepseek,下一句qwen,再来一句gork? |
?????????? 只需要在borrow的时候按策略borrow就能实现自动换翻译器重试等 您好,可以按策略路由。比如说某个translator是备用的,只有其他翻译器报敏感内容等错才切过去。 再比如说你可以用5个key配置5个deepseek。 |
哦哦哦,我以为是触发一次就borrow一个呢,寻思也太怪了。哈哈哈 |
是翻译一句话就borrow一个。但是borrow按策略borrow,所以不会那么抽象的。 |