tokio-prompt-orchestrator

已完成答案在默认 300 秒窗口内可复用，存储在带大小限制的 moka 缓存中，以防止内存无限增长。

在 200 个相同请求的基准测试中，直连供应商产生 200 次上游调用，而通过代理仅产生 1 次上游调用，199 个请求加入共享结果，最慢响应仍为 1.58 秒。

代理的去重键是整个扁平化对话的哈希，而非仅最后一条消息，以避免不同聊天中输入相同文字的用户共享答案。

代理的上游调用在独立的 spawn 任务中运行，因此即使第一个调用者断开，加入的其余请求仍能获得结果。

在 WildChat-1M 数据集（59,857 个对话、172,418 个用户轮次、25.3 天流量）的默认 5 分钟窗口下，仅有 2,568 次调用（1.49%）是精确重复；窗口拉到 24 小时为 4.39%，完整 25 天为 4.77%。

在供应商宕机测试中，直连方式在 60 秒内向已死供应商发送了 89 次调用（30 个请求各重试 3 次），而通过代理仅发送 5 次调用，减少 94%，因熔断器在连续 5 次失败后打开。

在挂起供应商测试中，直连和代理的 p95 等待时间分别为 53.7 秒和 53.6 秒，代理仅有 2 次调用到达挂起供应商（直连为 30 次），但熔断器从未打开，因为 30 秒超时下需要 5 次失败即 150 秒挂起才触发。

熔断器的默认配置为连续 5 次失败触发打开，80% 近期成功率关闭，60 秒后半开探测。

去重应该默认开启，因为未命中时零成本；但真正的节省只在机器发送请求的场景（代理循环、脚本化请求）出现，处理改写问题的语义去重是更困难的问题。

开源项目 tokio-prompt-orchestrator 是一个位于应用与模型 API 之间的 LLM 代理服务器，采用 MIT 协议，由 Mattbusel 开发。

2.0.3 版本已将熔断拒绝响应改为携带 `x-should-retry: false` 和 `Retry-After` 头，使拒绝请求约 1 毫秒返回而非 1.35 秒，p95 从 1459 毫秒降至 314 毫秒。

2.0.3 版本新增 `--timeout` 参数并将超时计为熔断失败；使用 `--timeout 5` 后，熔断器在挂起约 13 秒时打开，最慢等待从 66.3 秒降至 11.4 秒，挂起期间请求中位等待从 34.9 秒降至 1 毫秒。

2.0.3 版本修复了服务器串行处理上游调用的 Bug，新增 `--concurrency` 参数，默认同时运行最多 16 个上游调用；同样 20 个不同提示词在默认设置下 3.0 秒完成，`--concurrency 32` 时 1.5 秒完成。