最新

大家好，我是雅库布，一位来自华沙的独立创始人。<p>从去年 12 月开始，我和几位贡献者一起构建了 GoModel。它是一个开源 AI 网关，位于您的应用程序和 OpenAI、Anthropic 等模型提供商之间。<p>我创建它的目的是为了解决我的初创公司面临的一些问题：<p><pre><code> - 跟踪每个客户或团队的 AI 使用情况和成本 - 在不更改应用程序代码的情况下切换模型 - 更轻松地调试请求流程 - 通过精确和语义缓存来降低 AI 支出 </code></pre> 它有什么不同？<p><pre><code> - ~17MB 的 Docker 镜像 - LiteLLM 的镜像要大 44 倍以上（"docker.litellm.ai/berriai/litellm:latest" 在 amd64 上约为 746 MB） - 请求工作流程是可见的，并且易于检查 - 默认情况下，配置优先使用环境变量 </code></pre> 我之所以现在发布，部分原因是因为最近发生的 LiteLLM 供应链攻击事件。他们的团队处理得非常好，但有些人仍在寻找替代方案，而 GoModel 就是其中之一。<p>网站：<a href="https://gomodel.enterpilot.io" rel="nofollow">https://gomodel.enterpilot.io</a><p>欢迎提供任何反馈。

在构建支付编排系统时，我遇到了一个问题： 大多数监控工具会在达到阈值时发出警报（例如，P95 &gt; 1000ms）。但实际上，系统在达到这些限制之前往往就会开始退化——尤其是在突发流量的情况下。 因此，我尝试在 FastAPI 应用内部直接检测阈值被突破之前的性能下降。 我构建了一个小的中间件，它可以： * 跟踪每个路由模板（例如 /users/{id}）的 P95 延迟 * 从最近的流量中动态学习基线 * 使用变化率检测峰值（不仅仅是静态阈值） * 计算一个 0–100 的健康评分，并显示趋势方向（改善 / 稳定 / 恶化） * 将事件存储在 Redis Streams 中，用于重放和调试 一个有趣的结果是： 在合成负载测试中（在 60 秒内，延迟从约 200ms 逐渐增加到约 1200ms，P95 警告阈值为 1000ms），变化率检测始终在静态阈值警报之前就发现了性能下降。虽然窗口很小，但通常足以在超过警报阈值之前注意到系统压力。 设计约束： * 对请求路径的开销接近于零（异步，即发即弃的写入） * 如果 Redis 不可用，必须静默失败 * 不需要外部监控堆栈（在应用内运行） 使用示例： ```python pythonapp.add_middleware(RequestMetricsMiddleware, alert_engine=engine) ``` 背景： 这是我正在构建的更大系统的一部分，该系统将云服务与移动货币 API（EcoCash 等）集成，其中部分失败和延迟峰值很常见。 还处于早期阶段——尚未在实际生产流量下进行测试。 很好奇其他人是如何在 FastAPI 或类似系统中处理早期性能下降检测的。 代码库：[https://github.com/Tandem-Media/fastapi-alertengine](https://github.com/Tandem-Media/fastapi-alertengine) PyPI：[https://pypi.org/project/fastapi-alertengine/](https://pypi.org/project/fastapi-alertengine/)