Exo 分布式 AI 集群容错完全指南:一台设备掉线时,集群如何继续运转

发布时间:2026/8/31 9:04:58
Exo 分布式 AI 集群容错完全指南:一台设备掉线时,集群如何继续运转 Exo 分布式 AI 集群容错完全指南一台设备掉线时集群如何继续运转【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo半夜集群里某台机器突然断电其余设备照常运转。Exo 是一个用多台家用设备搭建本地分布式 AI 集群的项目容错与高可用从第一天就写进了它的架构里。跟着一次故障的生命周期看看它如何扛过单点故障。故障发生前如何预防单点风险跑大模型时没人想把整个集群押在某个「指挥点」上。Exo 不预设永久主节点每个节点启动时都默认自己就是主节点随后各自广播状态互相比较。选举消息里带着时钟值、资历、已处理命令数与候选会话四项信息比较顺序固定同一组候选人在每台机器上都会算出同一个赢家集群不需要额外协商就能收敛到唯一主节点。完整逻辑见选举算法实现。主节点故障后如何自动切换有节点掉线、或有新设备加入时每个存活节点侦测到连接变化后时钟加一并触发新一轮选举通常在 3 秒内收敛。主节点切换因此不是「应急预案」而是日常流程的一部分。旧主节点即使再没回来集群也会自己组织出新的指挥点无需人介入。模型分片与放置如何避免把所有东西压在一台机器上调度模型时主节点先查看当前拓扑挑出内存充足、彼此互联的节点「环」再把模型权重切成分片放到这些节点上。评分逻辑优先选择已经下载过该模型、空闲内存更多的机器新任务不必重新下载权重。这套放置策略既是并行加速的来源也是容错的根子单机承载的分片越少它倒下时的影响面就越小。故障发生瞬间心跳检测与自动止血 心跳看门狗5 秒确认一次进程是否还活着真正加载模型、执行推理的 runner 进程由runner 监督者看护它每 5 秒轮询一次进程是否存活。一旦发现死亡先记录死因——退出码、被哪个信号杀死、stderr 的最后几行——再向集群上报「runner 失败」事件。与此同时该 runner 上正在进行的推理请求不会被挂起客户端会收到一个明确的错误块调用方立刻知道哪里出了问题。节点超时后如何从拓扑中移除集群层面还记录着每个节点的最后通信时间。一台机器失联超时后主节点会把它从拓扑里移除连同它的内存、磁盘、网络记录一起清理并重算还有哪些节点组合可用。故障被确认的那一刻起这个节点的「影子」就不再占据调度名额。故障处理中数据与任务如何不掉线模型权重存在磁盘上恢复不依赖单份副本模型权重的每一个分片都持久化在持有它的节点本地磁盘上。节点掉线后主节点在剩余节点上重新跑一遍放置流程。评分规则天然优先选择已持有权重的机器新实例只需从磁盘加载文件不必从头重新下载。对于进行中的请求客户端会收到明确的失败事件业务方可以选择重试或换到其他可用实例。张量与流水线并行剩下的节点如何接住工作分片放置意味着并行张量并行下每台机器负责不同的权重切片流水线并行下每台机器承接不同的层段。一台机器离线只影响它自己的那份分片其余集群满负荷继续工作。官方多机基准测试也印证了这一点节点数增加后Exo 相对传统 TCP 方案的吞吐优势进一步扩大。故障之后如何持续盯住集群 ️控制面板如何一眼看清整个集群状态网页控制面板持续上报每个节点的资源占用、温度与拓扑状态并实时渲染。哪台机器温度在爬升、哪个节点刚重新上线、哪个实例正在加载模型不用翻日志一眼就能看清。异常如何留痕事件、日志与保活集群的每次状态变化——节点加入、节点超时、runner 失败——都以事件形式进入中央状态机形成可追溯的时间线监督者还会把 runner 的 stderr 归档到日志方便事后复盘。流式 API 带有 10 秒一次的保活心跳长连接不会在无人知晓时悄悄断开。Exo 的容错不是功能堆叠而是一条链事前把风险摊开事中快速止血事后把任务接回然后持续盯着。git clone https://gitcode.com/GitHub_Trending/exo8/exo无论你是第一次跑大模型、做分布式推理研究还是开发新模型你搭在家里的集群从此不怕「一台机器倒下」。【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考