做过类似的功能，使用 golang 做了一层中转，业务先请求鉴权 api 生成临时 apikey (甚至该 key 事先绑定好 prompt ，用于某些业务场景防止被篡改 prompt)，下发到客户端后，客户端再请求一个模型中转 api

你只考虑功能本身当然没有问题，所以你只有技术思维。但 API 产品还有计费需求和合规考量，API Key 一是区分谁使用谁付费的依据，还有滥用时可以停用，放在客户端 Key 会泄漏，别人的使用记在你的费用，别人滥用你的 KEY 导致被停用，你愿意吗？

产品+架构思维一点都没有 1. 为什么要把用户的数据留到本地？ 2. 我宣传用 GPT-5 实际是 GPT-3.5 你怎么知道？ 3. 阿里云服务调用阿里大模型接口响应是不是更快？ 4. API KEY 有速率限制，你是在后端直接轮换 KEY ，还是在前端用临时 KEY 出错了换新 KEY 再进行 Retry ？

对象存储有这玩意是因为这玩意完全可控... 我们干的最黑的事儿, 也不过是偷了王者荣耀的 sts 把我们自己的文件放上面免费存了几年 且后续人家直接可以通过比对数据库和实际文件把不是应该有的文件都删了... 你敢做临时 api key 我就敢 1 小时给你生成几十万美元 token 账单

大模型那输出速度，你的后端转发离瓶颈远着

安全问题不用考虑了? 如果模型直接输出了意料外的内容. 产品下架都是小事, 还有更严重的.

临时 key （让前端直接用）是一个非常糟糕的设计。

你都直连大模型厂家了，我还怎么收集训练素材优化自家的模型？付费上班的牛马数据标注员为什么不用起来？

@tt83 「我猜你说的那些逻辑也可以放在客户端」 1. 这部分逻辑不想被「开源」 2. 客户端不可信，有时不想行为被客户更改。

问题是很多都要代理才能访问，客户端不能要用户买个代理吧