不是很理解transformers依赖的作用?

[NIyueeE]

本着学习的态度, 仔细研究了代码实现发现了如下无法理解的问题:

---

1. 未使用的 transformers tokenizer

• 初始化了 AutoTokenizer 但从未使用，却引入了沉重的依赖（torch、transformers 等），浪费内存和启动时间。
• 应删除相关 import 及初始化代码。

---

2. 全局队列线程不安全

• account_queue 是 Python 列表，在多个并发请求中通过 choose_new_account / release_account 操作，没有任何锁保护，存在竞态条件，可能导致重复取用同一账号或数据损坏。
• 应使用 queue.Queue 或 threading.Lock 保护。

---

3. 配置文件并发写入

• login_deepseek_via_account 每次登录成功都调用 save_config 写入文件，多请求并发写入会导致文件损坏或配置丢失。
• 应改为仅在启动时读取，运行期间不写入（或使用锁 + 异步写入）。

---

4. 会话重试逻辑中的账号切换缺陷

• create_session 和 get_pow_response 中，账号切换后 attempts 计数器直接递增，可能减少重试次数。
• 切换账号后未立即重试当前操作，而是继续循环，可能导致不必要的延迟或失败。

---

5. WASM PoW 计算效率低下

• 每次请求都重新加载 wasm 模块并实例化，开销巨大。应缓存模块和实例，或使用单例模式。

---

6. 流式响应中的线程泄漏风险

• sse_stream 中创建的 process_data 线程未在主生成器退出时被 join 或停止，若客户端断开连接，线程可能永远阻塞在 iter_lines 上，导致资源泄漏。

---

7. 非流式响应错误返回 StreamingResponse

• /v1/chat/completions 中 stream=False 时返回的是 StreamingResponse，但内容类型为 application/json，且生成器内仅 yield 一次完整 JSON，这不符合常规，客户端可能解析失败。应改为直接返回 JSONResponse。

---

8. 重复的工具调用检测逻辑

• detect_and_parse_tool_calls 函数已定义，但在非流式响应和 Claude 端点中又重复实现了类似逻辑，导致维护困难且不一致。

---

9. Claude 端点响应格式不兼容

• 在 Claude 非流式响应中插入了 "thinking" 类型的内容块，但 Anthropic API 官方不支持该类型，Claude Code 客户端可能无法解析。
• 流式响应一次性收集全部内容再发送事件，失去了流式意义，应改为逐块转发。

---

10. 大量死代码与未使用的导入

• claude_api_key_queue 相关函数从未使用。
• 部分 import（如 base64、ctypes 虽有用到，但很多其他导入冗余）。
• transformers 整体未用。

---

11. 异常处理不一致

• 有些地方抛出 HTTPException，有些返回 JSONResponse，有些只记录日志，导致客户端响应格式不统一。

---

12. 硬编码路径与魔法数字

• WASM 文件路径硬编码，若缺失则启动失败。
• 难度值（144000）、过期时间等魔法数字散落各处，不易维护。

---

13. 模型名称映射逻辑古怪

• convert_claude_to_deepseek 根据模型名中是否含 "opus" 或 "reasoner" 来选择 fast/slow 映射，但映射表本身又是配置的，逻辑混乱。

---

14. Token 计数使用简单估算

• 虽然可接受，但既然已有 transformers 却未用于精确计数，反而引入大依赖，本末倒置。

---

15. 未处理账号队列为空的情况

• 若 config.json 中未配置任何账号，choose_new_account 返回 None，后续请求直接抛出异常，没有友好提示。

---

16. 日志级别滥用

• 多处使用 logger.warning 输出正常流程信息（如登录响应文本），应改为 info 或 debug。

---

17. determine_claude_mode_and_token 多余

• 该函数仅调用 determine_mode_and_token，无任何额外逻辑，可删除并直接调用后者。

---

18. 状态变量 tried_accounts 在请求间不共享

• 每个请求独立维护已尝试账号列表，导致某个账号在单个请求中被排除后，其他并发请求仍可能选到该账号，无法实现全局熔断。

---

19. 会话删除时机问题

• 在流式响应中，delete_deepseek_session 在生成器 finally 中调用，但此时 process_data 线程可能还在读取数据，可能导致会话被提前删除但线程仍在尝试使用它，虽不致命但设计不良。

---

20. 大量重复代码

• 会话创建、PoW 获取、流式解析等逻辑在多个端点中重复，应抽取为公共函数。

---

这些问题严重影响代码的稳定性、可维护性和性能，建议优先修复线程安全、资源泄漏和响应格式错误等关键问题。

[NIyueeE]

只能说马太效应这一块, 希望大家可以看看我的项目实现 https://github.com/NIyueeE/deepseek-web-api

[iidamie]

最开始引用 transformers 是采用了 DeepSeek 官方计算 Token 用量的方法 https://api-docs.deepseek.com/zh-cn/quick_start/token_usage
后续不使用的原因是，在一些 PR 中，有些人计算 Token 用量的方法不再调用了 transformers 而是使用 len() 来大致计算

[NIyueeE]

最开始引用 transformers 是采用了 DeepSeek 官方计算 Token 用量的方法 https://api-docs.deepseek.com/zh-cn/quick_start/token_usage 后续不使用的原因是，在一些 PR 中，有些人计算 Token 用量的方法不再调用了 transformers 而是使用 len() 来大致计算

如下是deepseekwebapi后端的实际响应流, 可以看到是有chunk实际是返回了了token计数的, 同时我觉得对于这种免费api方案给token_usage没有实际的意义

data: {"v":"我可以"}

data: {"v":"帮"}

data: {"v":"你的"}

data: {"v":"吗"}

data: {"v":"？"}

data: {"v":"😊"}

data: {"p":"response","o":"BATCH","v":[{"p":"accumulated_token_usage","v":50},{"p":"quasi_status","v":"FINISHED"}]}

[NIyueeE]

同时deepseek后端提供了edit_message端口, 可以用来模拟'无状态'api避免频繁创建session

[iidamie]

最开始引用 transformers 是采用了 DeepSeek 官方计算 Token 用量的方法 https://api-docs.deepseek.com/zh-cn/quick_start/token_usage 后续不使用的原因是，在一些 PR 中，有些人计算 Token 用量的方法不再调用了 transformers 而是使用 len() 来大致计算

如下是deepseekwebapi后端的实际响应流, 可以看到是有chunk实际是返回了了token计数的, 同时我觉得对于这种免费api方案给token_usage没有实际的意义

data: {"v":"我可以"}

data: {"v":"帮"}

data: {"v":"你的"}

data: {"v":"吗"}

data: {"v":"？"}

data: {"v":"😊"}

data: {"p":"response","o":"BATCH","v":[{"p":"accumulated_token_usage","v":50},{"p":"quasi_status","v":"FINISHED"}]}

这个返回在一年前这个项目刚创建时并不存在，是后续才添加上的

[iidamie]

同时deepseek后端提供了edit_message端口, 可以用来模拟'无状态'api避免频繁创建session

但是这涉及到 message_id session_id 该如何存储，若对方客户端使用标准接口请求时，无法携带 message_id session_id
这种想法早在我尝试在一个session中持续对话而不是每次对话都重新创建新的session中就已经想到过
但对于标准格式请求时基本无法实现

[NIyueeE]

同时deepseek后端提供了edit_message端口, 可以用来模拟'无状态'api避免频繁创建session

但是这涉及到 message_id seesion_id 该如何存储，若对方客户端使用标准接口请求时，无法携带 message_id session_id 这种想法早在我尝试在一个session中持续对话而不是每次对话都重新创建新的session中就已经想到过 但对于标准格式请求时基本无法实现

其实可以实现, 我的项目就是用的这种方法, 并且已在冒烟测试和实际生产环境中严格验证

[CJackHwang]

只能说马太效应这一块, 希望大家可以看看我的项目实现 https://github.com/NIyueeE/deepseek-web-api

今年年初我也是看了原作者这个项目，发现了很多和你发现一样的问题，就自己修了一版

https://github.com/CJackHwang/ds2api

后面实在受不了Python性能就用go重写了一版
目前我这边进度在网页反代里面应该算是工程最完善的，可以看看

[NIyueeE]

只能说马太效应这一块, 希望大家可以看看我的项目实现 https://github.com/NIyueeE/deepseek-web-api

今年年初我也是看了原作者这个项目，发现了很多和你发现一样的问题，就自己修了一版

https://github.com/CJackHwang/ds2api

后面实在受不了Python性能就用go重写了一版 目前我这边进度应该网页反代里面应该算是工程最完善的，可以看看

我测, 大佬强啊, 我就知道我很有可能重复造轮子了; 调研不充分一切都白搭, 无语了。。。

[CJackHwang]

只能说马太效应这一块, 希望大家可以看看我的项目实现 https://github.com/NIyueeE/deepseek-web-api

今年年初我也是看了原作者这个项目，发现了很多和你发现一样的问题，就自己修了一版

https://github.com/CJackHwang/ds2api

后面实在受不了Python性能就用go重写了一版 目前我这边进度应该网页反代里面应该算是工程最完善的，可以看看

我测, 大佬强啊, 我就知道我很有可能重复造轮子了; 调研不充分一切都白搭, 无语了。。。

太多轮子了哈哈哈哈