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

[tt83]

永久 API KEY 只敢放在服务端或者个人使用。

通过服务端下发临时 API KEY 到客户端，用户本地直接请求大模型 API ，不仅能减轻服务端压力，也能提高用户端响应速度。

云厂商的对象存储一直都这么做，为什么现在这些大模型厂商都简单粗暴就搞一个永久 API KEY 也不能通过 API 来更新？

[tt83]

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

[jybox]

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

[jybox]

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

[vacuitym]

你可以用 api 生成和销毁 key

[tt83]

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

[tt83]

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

[tt83]

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

[spritecn]

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

[ZeroClover]

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

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

[tt83]

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

[javalaw2010]

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

[tt83]

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

[iyaozhen]

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

[tt83]

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

[C0reFast]

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

[reatang]

你这不就找到商机了么

[iyaozhen]

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

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

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

[FlashEcho]

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

[ZeroClover]

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

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

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

[0703wzq]

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