为什么这些大模型 API 都不提供临时 API KEY

像阿里云和火山是支持的，但是他们的大模型没有像硅基流动这种全，更新也不太及时

对象存储这么做是因为大文件需要直传，但 LLM 的数据量没有那么大吧，相比于 LLM 本身的计算量和耗时，在服务端转发一遍可以忽略不计。

然后对象存储的临时签名只有上传或者读取文件一种权限，LLM 的话那岂不是客户端可以运行任意的 prompt 了？如果要对 prompt 做限制/做模板，这个复杂度还不如从后端转发一下。

你可以用 api 生成和销毁 key

@jybox #2 数据没那么大，但是一次长请求要占用很长时间，限制/模板都可以在客户端做

@vacuitym api 生成和销毁 key 也有很多厂商不支持，只能手动操作，甚至还有限定重置次数的，离谱

@jybox #2 另外对服务端流量带宽影响也不小吧

对象存储也不是一开始就有这东西的吧

因为你说的这些问题在快速增长的 AI 风口面前不值一提，这些 AI 公司不会优先考虑这个的

不过主流大模型基本都可以通过云来调用，所以也可以变相解决

@jybox #2 还有一种情况，如果是用的按实例时长收费的 Serverless 服务，影响就更大了

因为没有需求吧，LLM 的接口通常来说 body 不会很大，不像对象存储那样费流量，有急切的节省服务器流量的需求。你这种需求的话，自己做个服务转发一下，也是很容易的。

@ZeroClover 你说的没错，但是我觉得还有一个重要原因就是 OpenAI 没做，问题是 OpenAI 的 API 又不愁卖，OpenAI 如果做了他们肯定抄的很快

因为实际开发场景并不是这样，并不是 ChatGPT 套壳。
内部很多逻辑的，直连大模型没有什么好处

@iyaozhen 我猜你说的那些逻辑也可以放在客户端

因为客户端默认都是不可信的，你不能期望客户端可以限制住用户的请求，想想如果客户破解客户端拿到了 API KEY ，是不是就可以不受限制的调用大模型了？

你这不就找到商机了么

@tt83 #14 客户端怎么更新呢，下载 app ？增加拉取 prompt 接口，web 端的话。prompt 核心资产如何保密，换模型怎么办

当然都可以客户端实现，我说的是，为了一个直连这点微乎其微的好处，增加了一堆麻烦，没必要

为什么说微乎其微：减轻服务端压力，本身并没有什么压力，没有 cpu 密集型操作，换成客户端边缘计算没收益
响应速度，这个就更难说了，一方面 llm 本身就很慢，快 10ms 也没啥用。另一方面，客户端环境复杂，且不说跨境合规，就国内各个地方网络就很复杂，而且也不可控，比如我要用 http/3 不一定支持

因为大模型服务商只提供模型服务，在工程方面就比较简单粗暴，一般大模型网关就提供有有效期的 apikey 了，通过 one-api 等服务转发一下即可

@tt83 #12 OpenAI API 有巨量功能其他 AI 公司都没有的

大部分公司也就只是抄了下 Chat Completion 而已

而且让客户端直连模型 API 目前也看不出来有什么特别具体的好处

做过类似的功能，使用 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. 客户端不可信，有时不想行为被客户更改。

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

后端的逻辑比如负载、限流之类的规则不要了吗

完全没必要啊，对象存储的功能相对单一，但是这种 key 一旦在客户端被拿到，随便干啥都可以了，根本限制不了。

OpenAI 其实已经有了，新的 ChatKit 就支持这种用法

@SingeeKing 当然，它有归它有，但这个感觉还是初级阶段

S3 支持 pre-signed url 有很大的一点原因是大文件上传走服务器中转成本太高了，因此有这个东西，而且可以限制上传的文件类型、大小甚至 MD5 可以有效防止滥用

但是至少 ChatKit 的现有实现，一旦生成了 client_secret ，用多少量可就是用户说了算了…… 广泛使用还是得等一个优化的速率&费用限制接口

通过 new-api 中转下?

@iyaozhen #17 我们的 prompt 不加密，甚至鼓励用户自己修改。想请教 LLM 这种时长比较长的 stream 请求影响大不大，比如一个 2 核 4g 的服务器大概能能支持多少并发，对带宽要求高不高