来源笔记
HiveMind: OS-Inspired Scheduling for Concurrent LLM Agent Workloads
摘要
HiveMind 是一个透明的 HTTP 代理，它按操作系统调度竞争进程的方式来调度并发 LLM 代理流量。它针对编码代理工作负载中的一个常见故障场景：多个代理共享一个有速率限制的 API，发生冲突，即使总容量足够也会失败。
问题
- 论文处理的是并行 LLM 编码代理共享同一个 API key 或端点时的失败。没有协调时，代理会碰到速率限制、连接上限、延迟尖峰和 HTTP 502、
ECONNRESET这类瞬时服务器错误。 - 这类失败很重要，因为编码代理是长时间运行的有状态会话。运行中途的 API 故障会浪费 50k-500k token，丢失上下文，并在文件编辑和工具调用已经发生后迫使重启。
- 促发案例里，11 个 Claude Code 代理并发使用一个 Anthropic key；其中 3 个失败，失败率为 27%，浪费了大约 135k token 和大约 15 分钟。论文认为问题出在协调上，而不是 API 总容量，因为如果把启动时间错开 5 秒，11 个都能完成。
方法
- HiveMind 在代理和上游模型 API 之间放一个本地代理层，因此现有代理不需要改代码。代理继续发普通 HTTP 请求，由代理层决定何时以及如何转发。
- 核心机制是一组五个类操作系统的调度控制加上透明重试：接纳控制限制在途请求，速率限制跟踪监控 RPM/TPM 和提供方头信息，AIMD 背压在延迟或错误上升时降低并发，token 预算限制失控代理，优先队列按优先级和估计成本安排工作。
- 熔断器会在最近错误率过高时快速失败新请求，然后在冷却期后探测恢复。像 429、502、503、529 和连接重置这类可重试错误会带指数退避和抖动重试，对代理隐藏。
- 系统会自动识别 Anthropic、OpenAI、Azure OpenAI、Google AI、Ollama 和通用 OpenAI 兼容端点的提供方配置。它也支持 SSE 流式输出，并从流事件或响应正文中提取 token 数。
- 论文强调的一项实现细节是用
asyncio.Condition做动态并发控制，而不是直接修改 semaphore，这样在高负载下调整容量是安全的。
结果
- 在 7 个场景、5 到 50 个并发代理下，未协调执行在冲突条件下的失败率是 72%-100%，而摘要称 HiveMind 把失败率降到 0%-18%。
- 在表 5 中，直接执行与 HiveMind 的失败率分别是：
micro-10100% -> 10%，micro-20100% -> 10%，micro-50100% -> 0%，replay-1173% -> 18%，stress100% -> 10%，lat.-spike100% -> 0%。micro-5在两种模式下都是 0%，因为没有冲突。 - 死亡代理造成的浪费计算在评估场景中下降了 48%-100%。表 5 报告的 token 浪费减少幅度是：
replay-11为 48%，micro-20为 94%，micro-10、micro-50、stress和lat.-spike为 100%。 - 对
replay-11的消融研究显示，完整 HiveMind 达到 11 个存活、0 个死亡、失败率 0.0%。关闭重试后，结果降到 4 个存活、7 个死亡、失败率 63.6%，说明重试是最重要的单项机制。只保留接纳控制时，结果是 2 个存活、9 个死亡、失败率 81.8%，说明单纯限制并发不够。 - 去掉背压后，11 个代理中有 1 个死亡，失败率 9.1%。去掉接纳控制或速率限制跟踪时，在那个场景里仍然是 0.0% 失败，作者把这解读为其余控制机制起到了补偿作用。
- 面向 Ollama 的真实验证在摘要中报告，每个请求的代理开销低于 3 ms。提供的摘录没有给出表 7 的完整数值，只提到这项开销结论。