lobechat 有考虑直接支持每个渠道多账号添加吗 调用模型时直接负载均衡调用
- 关于 Claude API 多个相同角色，在我的项目里面，我是在转发 API 之前检查 role，如果是一样的角色再合并，并且对 content 是文本也是列表类型做了精细的合并策略。既然我们都有这样的需求，我认为 uni-api 做这样的适配是合理的，这样可以避免用户侧代码臃肿。如果这一点实现了，我将在这里通知一下您。
其实不仅仅是 Claude ，之前 Google Gemini 1.0 的时候我记得也有这个问题。好像1.5 是把这个口子放开了一些，但比如多 system 这种就兼容起来比较难。
另外图片处理逻辑上也是，比如 OpenAI 是支持直接传图url的，但是 google 和 Anthropic 都不支持。这里理论上也需要做一次转换的，把用户的 url 转成 base64 后再发给 AI API，不然就没法用。
- 流式 tools calling 的兼容，在我的场景里 uni-api 在统一 OpenAI 和 Claude tool use 的转发上还没发现有什么问题，我现在的项目（指上面的机器人，我有个公共免费机器人供用户使用）是全面的流式响应，如果大佬有什么边缘 case 的话，并且 uni-api 上也有问题，我也会尽快修复的。
流式 Tools Calling 最大的问题应该是各种非 OpenAI 的 provider 怎么兼容到 OpenAI 上，比如 TogetherAI 的返回很奇怪、 Minimax 的返回很离奇。Mistral 的 Tools 返回一言难尽。
还有就是一些走了 OpenAI 接口的但又没完全支持流式的，比如 Groq。
以上这些提到的我大部分都兼容处理过了（详见上述 RFC ），但还存在一些特别棘手的比如 Ollama 既不是 OpenAI 格式，又只支持了 non-stream 的 Tools Calling 的 provider，只能暂时放弃。
直接做一个 oneapi 是没有计划的。我们在开源版的核心设计原则还是用户填个官方 key 就能正常使用这个渠道，做多渠道的有点偏离目标了。
但考虑到这类管理的诉求估计还是会有的，未来我们可能会有一个版本是基于 LiteLLM 包一层 UI，然后再和 LobeChat 做更加深度的集成，作为未来付费镜像的一个特性来提供吧。
1 Like
感谢大佬回复这么多具体的场景，稍后等我把基础的功能实现了，我就会一一分析您场景的这些边缘 case 想想方法。
看了一下 RFC，确实有些接口过于奇怪，我认为应该会有折衷方案，主要就是费时间会比较恶心，我深有体会，我遇到最奇葩的还是 Gemini API，它的流式居然是一行行输出 json。
我想可能有些 API 如果实在过于奇怪，可能没必要非要适配 OpenAI 的 API 了。我遇到这些奇怪的API，在我的项目里，我直接根据用户模型和URL路由到我写的定制响应处理 class 里面去
。
不错不错，期待大佬做出更优秀的产品。
1 Like
太强了, mark
感谢大佬，辛苦了
我就是对接他人的api不太方便，格式太多种了。索性自己撸了个轮子。目前自用中
1 Like
你这个真玩具…接口没按照openai 规范 后来我叫克劳拉给我改标准了
1 Like
本来就是只需要一个类 一个模块这样写 你混在一起改都改不了
openai.chat
gemin.chat
clude.chat
chat返回文本就行 每个解析模块单独写
输出使用openai格式统一输出
很多程序员对于代码的架构设计…似乎很薄弱…以至于难以复用代码
等我开源在我基础上魔改体验一流
今天把上游错误代码都返回了
这样子设计好 轻轻松松加入 负载均衡算法 加权算法
1 Like
返回纯文本不够的，tools calling要做好必须要结构化输出的
你好，现在已经支持单个渠道多个 API key，自动开启负载均衡了。详细的配置指南可以看 README。
你好。我的项目也支持渠道级加权负载均衡了。目前支持四种负载均衡方式。
挺好的，要是用go写的更好了，只要一个执行文件，一个配置文件，本地、远程都方便跑……
1 Like
是这样的，我也想用 go 写，但是对 go 不怎么熟悉，还是回到舒适圈了。
你好，现在已经支持限流了，详细配置方法写在 README 里面了。
太强了佬，这效率杠杠滴
1 Like
代码写的恶心的话…bug多…golang不好写