最新

嗨，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>

我最近在多个项目中工作，涉及到人工智能端点（包括一些我本地运行的），发现需要一种方法来轻松地在多个端点之间进行负载均衡。有时我的本地服务器无法处理负载，我不得不根据当时的信用情况增加对 z.ai 或 Anthropic 的使用。 事情发展到最后，我写了 Busbar：一个用 Rust 编写的 LLM 网关（最近我对 Rust 情有独钟）。你只需将现有的 OpenAI/Anthropic/Gemini SDK 指向它，将模型更改为一个池名称，这个名称现在就可以在不同供应商之间进行负载均衡。你的客户端代码不会改变，也不会知道这一切的发生。 我的核心理念是“协议，而不是供应商”。我无损实现了六种协议——Anthropic、OpenAI、Gemini、Bedrock、Responses 和 Cohere。你只需用三行 YAML 定义一个供应商，主要指定该供应商所使用的协议。 你的客户端通过 Busbar 使用一种协议，而 Busbar 则向供应商使用另一种协议。 - 每种协议在两个方向上都能翻译请求和响应，无论是流式还是缓冲。同一协议的调用不会被修改；跨协议的调用则会协调一些不便之处（一个方言要求的字段而另一个方言则将其视为可选）。 - 一个能够识别故障责任的断路器。它会停止路由到真正失败的后端，但不会因为请求过大而惩罚模型（而是会在更大上下文的模型上重试），也不会因为调用者发送了错误请求而责怪后端。健康的模型不会因为不是它的错而被从轮换中剔除。这些都是我个人曾面临并希望在 Busbar 中解决的问题，而不是在十个应用中解决十次。 - 手动实现的 AWS 功能，因此我不依赖于 AWS SDK：SigV4 和从零开始的 AWS 事件流帧解码器用于 Bedrock。 目前是 1.0.0-rc.2 版本——功能完整且 API 稳定，正在进行发布候选验证，预计在 1.0.0 之前完成。我已经在我的项目中使用它，并且它很好地解决了我的问题。 这是一个个人项目，采用 AGPL-3.0 许可证。AGPL 的选择可以讨论；我知道这对请求路径组件很重要。 非常欢迎反馈，特别是在边缘情况下翻译可能仍然存在损失的地方。希望能有贡献和讨论！