最初发表于tamiz.pro. 2021年,一个运营以Go为基础的基础设施服务的团队在负载下同时打击了100万个被同时吞噬的地道.
他们从这种规模中吸取的教训——结构化货币、取消传播、资源预算编制、可观察到的失败——这次的情况有所不同。
如今,同样的模式在工程师们建立生产AI代理系统时被冲出水面, 除了在事件循环上进行goroutines赛跑之外,我们正在管理LLM的呼叫,工具执行,以及流出在分布式服务中的反应.
平行不是偶然的。
这两个域都具有核心的张力:无约束的扇出在代码上看起来优雅而生产上灾难性.
了解Go社区如何大规模地解决了这个问题,让AI工程师们对现在正在打击代理平台的问题有一个头绪.
- " Fan-Out " 问题:当平行主义在1M-Goroutine事件的规模上变得混乱时,事件就无辜地开始。
一名要求处理者在下游呼唤时产下一名工人:在正常负荷下, 但是,当系统看到各种请求——每个请求都有50-200个子任务——突然出现出故障。
在没有取消的情况下,每个飞行中的出行程序都活了下来,直到其上游请求超时或过程被终止。
Go运行时间并没有崩溃(它的设计就是为此而来),但调度器的起落架变得相当可观,等待操作的记忆也积累了.
修补的不是去除出行道, 等效AI代理框架今天呈现出完全相同的模式.
考虑一个典型的"计划与执行"代理:单一用户请求可以向20-50个并行的LLM呼叫,每个都带有自己的上下文窗口,API活性,以及出错表面.
没有货币限制,你正在打击利率限制, 吹掉你的象征性预算, 降低所有同时期用户的反应质量。
出行道泄漏变成了象征性的漏出 和暂时性的级联 平行的解决方案是相同的:基于semaphore的边框货币、上下文传播和结构化清理: 课程尺度:无论是goroutines,HTTP连接,还是LLM引用,不受约束的平行主义,都是一种设计味.
Go社区从规模上学到了这一点。
AI工程师正在学习它, 通常在困难的部分之前。
2.
取消:Goroutines How Handle Boundment Go的软件包是合作取消的一流软件。
当一个父上下文被取消时,所有后人必须注意这个信号并停止工作: 关键不变量:呼叫树中的每个goroutine都会继承一个可以被取消的上下文.
如果链条上的任何环节 掉入上下文 并产生无节制的出行道, 你有一个泄漏。
Go跑步时间不会强制你这么做的 AI代理管道面临同样的取消问题 但很难看出来 当用户取消一个长期运行的代理时,您需要通过: 飞行中 LLM API 调用——必须中止(或者在回复到达时至少忽略) 来传播该信号.
工具执行程序 – 必须尊重取消 Callback/ update 流 – 必须停止将结果推给死手 – 状态变异 – 应该回滚或彻底放弃 Go社群的见解:取消不是处理问题的错误, 一个在用户移动后继续产生结果的代理不仅浪费;如果这些结果反馈到另一个请求读取的状态,那就会产生积极有害的效果.
3.
有结构的通币:从通道到工具调用"去哲学"Go Go的通币指导原则是众所周知的:"不要通过共享内存来交流;通过交流来共享内存".
频道执行订单,防止种族,使控制流明确.
在一个频道上接收的goroutine会被屏蔽,直到数据到达或频道关闭——它不会旋转,民意调查或猜测.
每个阶段通过打入的频道进行交流.
没有股份