最新

各位 HN 的朋友们： 我构建了一个适用于 AWS Lambda 的 Bash 运行时，旨在让编写胶水代码更简单、更快速。有时，你只需要一点 `sed`、`awk`、可能还有一个循环和几次 HTTP API 调用，而这个运行时就为你提供了所有完成这些任务的工具。它内置了 `jq` 和 `curl`，因此你可以直接处理 JSON 载荷并串联 HTTP API 调用，包括使用 `curl --aws-sigv4` 调用 AWS 服务。 为了保持简洁的风格，Lambda 处理器的契约也尽可能地简化：从标准输入读取，写入标准输出，成功时返回 0，错误时返回非 0。你可以运行 shell 脚本，调用二进制文件（无论是 `al2023.provided` 中可用的，还是你可以将自己的静态二进制文件与处理器一起打包），或者两者的结合。如果你还记得 Adam Drake 关于 bash 和 coreutils 如何比 Hadoop 集群更快的帖子，并对此表示赞同，我希望你能尝试一下这个运行时，并觉得它很有用。该运行时被打包为一个 Lambda 层，因此可以直接集成到你正常的 AWS 基础设施中。

<a href="https://xcancel.com/eastdakota/status/2062860530360959273" rel="nofollow">https://xcancel.com/eastdakota/status/2062860530360959273</a>

最近我一直在处理多个涉及 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 的选择可以讨论；我知道它对于请求路径组件很重要。 非常欢迎反馈，特别是关于翻译在边缘情况下是否仍然可能出现信息丢失的地方。我希望收到贡献和参与讨论！