@LemonLeon https://i.imgur.com/5UjHGb4.png

@kuanat 感谢回复，我调整了测试方法。以下是最新的情况：

1.1 ）部署环境：Centos7 Mysql8 nodev16.16.0 go1.20.2
1.2 ）测试方法：
Windows Python3.8.10 locust 1000 用户并发，测试结果稳定在 300qps 附近（单个 locust 终端）

https://i.imgur.com/80mq5LU.png
https://i.imgur.com/1CRZujq.png

2 ） 2c4g 4c8g 6c16g ，测出来的并发量都是 300 附近。内存，磁盘读写，带宽压力并不大

3 ）我推测的原因有两个，要么在 cpu ，要么在数据库。通过提高数据库的最大连接数，并发线程有一点提高。

4 ）当用户端发起超多请求时候，数据库提前打开连接等待，然后系统就超出 mysql 最大连接数，并发降低下来。这是我的推测。

如果是这样，那一定有一种方案，是把这些任务都放在内存中处理完了，最后再批量插入数据库中。

5 ）我看到有一些中转系统就是基于内存处理的，欢迎大家指正和指路

这里统一感谢大家的回复！还没有找到优化方案，目前正在尝试增加机器性能。

如果你有时间远程协助我，可以添加我的联系方式 v：bitdark

@monsterxx03 你好，方便远程帮我排查一下吗

@RockChinQ 不在上游，但是分布式后面是要考虑的

@tonywangcn 空的，麻烦重新发一下

@Immortal 不会是 GPT 限制，后台官方接口的数量成倍增加，并发量没有变化。

目前可以确定是服务器资源的问题，更准确说是 oneapi 程序没有很好的利用系统资源

@ETiV 不行，gpt 做不了这个任务

@xabcstack 这个报错是存在的，没有具体统计过。OK 总体的报错率可以控制在 2%以下

@justin2018 OpenKey 价格并不算低，文档有详细的说明

@potatowish 监控程序连接着 Google Sheet 做监控面板，可以看到分钟级别的更新情况

@superares 是的。只是入门级的方案，主要解决了单点故障问题

@OceanBreeze 没有记录对话数据，只记录了计费信息

@yinmin 多谢提醒

@me1onsoda 让我来会会他们

前端部分已开源：
https://github.com/terobox/ChatGPT-API-Faucet

@xJogger 支持

@airyland @Free3 是的，先跑起来再说

老哥，lemonsqueezy 可以结算到国内银行卡吗？