最新

最近我一直在处理多个涉及 AI 端点（包括一些我本地运行的）的项目，我发现我需要一种方法来轻松地在多个端点之间进行负载均衡。有时我本地的服务器无法承受负载，我不得不根据当时我的额度情况，增加 z.ai 或 Anthropic 的使用量。 一件事导致了另一件事，我最终编写了 Busbar：一个用 Rust（我最近很喜欢 Rust）编写的 LLM 网关。你可以将现有的 OpenAI/Anthropic/Gemini SDK 指向它，将模型更改为一个池名称，然后该名称就会在各个供应商之间进行负载均衡。你的客户端代码无需更改，甚至不会意识到发生了什么。 我的核心思想是“协议，而非提供商”。我无损地实现了六种协议——Anthropic、OpenAI、Gemini、Bedrock、Responses、Cohere。你只需用三行 YAML 定义一个提供商，主要指定该提供商所使用的协议。 你的客户端通过一种协议与 Busbar 通信，Busbar 再通过另一种协议与提供商通信。 * 每种协议都会在双向进行请求和响应的流式传输和缓冲。相同协议的调用会原样通过；跨协议调用会协调差异（例如，一个方言需要但另一个方言可选的字段）。 * 一个故障转移机制，能够识别故障的来源。它会停止将流量路由到真正出现故障的后端，但不会因为请求过大而惩罚模型（它会重试使用更大上下文的模型），也不会在调用方发送了错误请求时责怪后端。一个健康的模型永远不会因为非自身原因而被移出轮换。这些都是我个人在项目中遇到并希望一次性解决的问题，而不是在 10 个应用程序中反复解决。 * 手工实现的 AWS 组件，这样我就不必依赖 AWS SDK：SigV4 和一个从头开始编写的 AWS EventStream 帧解码器，用于 Bedrock。 目前版本是 1.0.0-rc.2——功能完整，API 稳定，在发布 1.0.0 之前正在进行发布候选验证。我一直在我的项目中使用它，它很好地解决了我的问题。 这是一个独立项目，采用 AGPL-3.0 许可。AGPL 的选择可以讨论；我知道它对于请求路径组件很重要。 非常欢迎反馈，特别是关于翻译在边缘情况下是否仍然可能出现信息丢失的地方。我希望收到贡献和参与讨论！

下周6月12日，SpaceX将开启一段由华尔街控股的旅程。 这将最终导致“enshittification”（一种指代平台在生命周期中逐渐变质的现象），因为SpaceX正在亏损数十亿美元，而新投资者期望定期发布收益报告，这将给SpaceX带来无尽增长的压力，使其偏离最初的使命。 不幸的是，这次IPO只是对散户投资者、养老金等群体的一次巨大抛售，目的是迫使全球所有资本都投资于SpaceX。 我认为最好开始着手开发一个非华尔街控股的开源版SpaceX。 您希望看到一个由社区拥有的开源SpaceX具备哪些特性？