exo 如何用 --no-worker 启动只负责网络与编排的 coordinator-only 节点【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo在组建 exo 多设备 AI 集群时你手里可能有一台机器网络条件好但 GPU/统一内存资源不足以参与推理。exo 的--no-worker启动参数就是为这种场景准备的——README 中将其描述为「Run exo without the worker component. Useful for coordinator-only nodes that handle networking and orchestration but dont execute inference tasks」适用于「machines without sufficient GPU resources but with good network connectivity」。按本文操作你可以在这台机器上启动一个只负责网络与编排、不执行推理任务的 coordinator-only 节点并通过 API 端点确认它已正常加入集群。--no-worker到底改变了什么从启动入口 src/exo/main.py 的逻辑看每个 exo 节点由若干组件构成Zenoh 网络路由器Router监听--zenoh-port默认 52414、事件路由EventRouter、下载协调器DownloadCoordinator、Worker、Master 和 API。--no-worker是 argparse 的store_true参数见main.py中Args类它只影响其中一项未加--no-worker时节点创建Worker并在任务组中运行worker.run加上--no-worker后worker NoneWorker 任务不再启动该节点就不承担推理执行。而网络、编排相关组件不受该参数影响仍然全部启动代码中注释「We start every node with a master」——每个节点都会创建Master并参与选举Election因此 coordinator-only 节点同样可以竞选并成为 masterAPI 默认开启除非显式传--no-api监听--api-port默认 52415下载协调器默认开启除非显式传--no-downloads该节点仍可以下载模型分片。也就是说--no-worker的语义精确地是「去掉推理执行组件」而不是「只跑一个网络进程」。准备条件--no-worker没有额外依赖前置条件与从源码运行 exo 相同见 README.md 的 Quick Start已安装 uv、node构建 dashboardLinux 要求 18 及以上、rustnightly用于构建 Rust 绑定macOS 另需 XcodeMetal ToolChain与 macmon已克隆仓库并构建 dashboardgit clone https://github.com/exo-explore/exo # Build dashboard cd exo/dashboard npm install npm run build cd ..启动 coordinator-only 节点在目标机器上进入 exo 仓库根目录执行uv run exo --no-worker这是 README「Configuration Options」一节给出的完整命令无需其他参数。启动后该节点会加入同 namespace 的集群发现discovery 端口默认 52413、提供本地 API 与 dashboard默认http://localhost:52415、参与 master 选举但不会执行推理任务。按需调整的可选参数以下参数在main.py的参数定义中均有对应项仅在多机混跑或端口冲突时才需要加# 同一网络存在多个互不干扰的集群时隔离 namespace不同 namespace 的节点不会互连 uv run exo --no-worker --namespace my-dev-cluster # 该节点也不需要承担模型下载时 uv run exo --no-worker --no-downloads # API 端口冲突时 uv run exo --no-worker --api-port 52416其中--namespace默认值为当前 exo 版本号见main.py中--namespace的default__version__help 文本为「Discovery namespace, nodes with different namespaces will not connect.」--no-downloads的 help 文本为「Disable the download coordinator (node wont download models)」。如果希望这台机器优先成为 masterREADME 与main.py均提供了--force-master-m参数会赋予该节点选举优先级seniority1_000_000是否使用取决于你的编排需求不是 coordinator-only 的必选项。验证节点已就绪README 与 docs/api.md 给出了可直接执行的检查方式API 与 dashboard 可访问浏览器打开http://localhost:52415/。README 说明每个设备都提供 API 与 dashboarddashboard 的 cluster 视图会展示集群拓扑与各节点查看集群状态/state端点「Returns the current state of the cluster, including nodes and active instances」api.md可以确认你的 coordinator-only 节点与其他节点同处一个拓扑中curl http://localhost:52415/state查看当前 masterGET /node_id返回当前 master 节点 IDapi.md 示例响应为{node_id: node-1234}实际值因部署而异curl http://localhost:52415/node_id/events与/state在 api.md 中被标注为「primarily intended for operational visibility and debugging」适合在此场景下持续观察节点间的连接与事件。边界与限制该节点不执行推理README 明确 coordinator-only 节点「dont execute inference tasks」。模型实例的推理会落在集群中其他带 worker 的节点上如果集群里只有这一台--no-worker节点则没有任何节点可以执行推理。该节点仍默认下载模型--no-worker不会关闭下载协调器需要时加--no-downloads。该节点仍提供 API默认 API 在 52415 端口开启可用--no-api关闭、--api-port改端口。同 namespace 才互通默认 namespace 为 exo 版本号跨版本节点不会互连混装不同版本时可用--namespace显式对齐或隔离。Linux 上 exo 目前跑 CPUGPU 支持在开发中因此「GPU 资源不足」在 Linux 上并不构成跳过 worker 的理由——该参数更适合资源受限但仍需参与网络/编排的节点。完成以上步骤后你的目标机器上就有一个只负责网络与编排的 exo 节点它出现在集群/state与 dashboard 拓扑中参与选举可在 API 上查询状态但不承担推理执行。下一步可选是在其余带 GPU/内存资源的机器上以普通方式uv run exo启动带 worker 的节点组成完整集群。【免费下载链接】exoRun frontier AI locally.项目地址: https://gitcode.com/GitHub_Trending/exo8/exo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考