返回首页
最新
你好，我是雅库布，来自华沙的独立创始人。
自去年12月以来，我和几位贡献者一起在构建GoModel。这是一个开源的AI网关，位于你的应用程序和模型提供商（如OpenAI、Anthropic等）之间。
我为我的初创公司构建它，以解决几个问题：
- 跟踪每个客户或团队的AI使用情况和成本
- 在不更改应用代码的情况下切换模型
- 更轻松地调试请求流程
- 通过精确和语义缓存减少AI开支
它有什么不同之处？
- ~17MB的Docker镜像
- LiteLLM的镜像超过44倍大（“docker.litellm.ai/berriai/litellm:latest” ~ 746 MB在amd64上）
- 请求工作流可见且易于检查
- 默认情况下，配置优先使用环境变量
我现在发布这个消息，部分原因是最近发生的LiteLLM供应链攻击。他们的团队处理得非常出色，但仍然有一些人正在寻找替代方案，而GoModel就是其中之一。
网站： [https://gomodel.enterpilot.io](https://gomodel.enterpilot.io)
任何反馈都非常感谢。
在构建支付编排系统时，我遇到了一个问题：
大多数监控工具在阈值被突破时才会发出警报（例如，P95 > 1000毫秒）。但实际上，系统往往在达到这些极限之前就开始降级，尤其是在突发流量的情况下。
因此，我尝试在FastAPI应用程序内部检测降级，提前识别阈值被突破的情况。
我构建了一个小型中间件，它能够：
<p>跟踪每个路由模板的P95延迟（例如，/users/{id}）
从最近的流量动态学习基线
使用变化率检测峰值（不仅仅是静态阈值）
计算0-100的健康评分及趋势方向（改善/稳定/降级）
将事件存储在Redis Streams中，以便重放和调试
<p>一个有趣的结果是：
在合成负载测试中（延迟从约200毫秒逐渐上升到约1200毫秒，持续60秒，P95警告阈值为1000毫秒），变化率检测始终在静态阈值警报之前稍微提前地发现了降级。这个窗口虽然很小，但通常足以在突破警报阈值之前注意到系统压力。
<p>设计约束：
<p>请求路径上的几乎零开销（异步，火忘写入）
如果Redis不可用，必须静默失败
不需要外部监控栈（在应用内运行）
<p>示例用法：
pythonapp.add_middleware(RequestMetricsMiddleware, alert_engine=engine)
<p>背景：
这是我正在构建的一个更大系统的一部分，该系统将云服务与移动支付API（如EcoCash等）集成，其中部分故障和延迟峰值是常见现象。
目前仍处于早期阶段——尚未在真实生产流量下进行测试。
<p>想知道其他人在FastAPI或类似系统中如何处理早期降级检测。
代码库：<a href="https://github.com/Tandem-Media/fastapi-alertengine" rel="nofollow">https://github.com/Tandem-Media/fastapi-alertengine</a>
PyPI：<a href="https://pypi.org/project/fastapi-alertengine/" rel="nofollow">https://pypi.org/project/fastapi-alertengine/</a>