hyperspaceai/agi：用 DiLoCo 把消费级设备拼成训练集群，值不值得接入

它想解决的不是推理，是训练算力的来源问题

单机跑一次语言模型训练，瓶颈通常不是代码，是显卡数量和电费。hyperspaceai/agi 的切入点在这里：把互不信任的消费级设备组织成一个训练集群。README 的说法是，32 个匿名节点在 24 小时内协作训练了一个语言模型，参与者包括消费级笔记本、小型虚拟机和一台放在家里的工作站。

目标读者写得很明确。一类是愿意贡献 GPU、CPU 或带宽换取积分的个人，仓库里列了九种节点能力，推理权重 +10%，研究权重 +12%，代理 +8%，存储 +6%，嵌入 +5%，记忆 +5%，编排 +5%，验证 +4%，中继 +3%。另一类是想搭私有集群的小团队，仓库用 pod 这个概念来承载，几台机器装完 CLI、建一个 pod、发邀请链接，就组成一个 mesh。

需要说清楚的是，README 直接写着「This is Day 1」。这句话不是谦虚，它意味着这套东西目前更像一个正在运行的实验场，而不是一个可以交付的生产系统。把它当成生产训练平台来评估，大概率会失望。

梯度怎么从你的笔记本走到别的节点：DiLoCo 加两层压缩

训练栈的核心是 DiLoCo。机制不复杂：每个节点在本地训练若干步，然后把压缩后的权重增量通过 P2P 网络广播出去。它不传完整权重，也不做逐 step 的同步，这是能跑在消费级设备上的前提。

压缩分两层叠加。第一层是 SparseLoCo，对 LoRA 增量做 top-k 稀疏化，README 给出的数字是相对原始增量 45 倍压缩。第二层是 Parcae 梯度池化，把相邻的 transformer 层按 6 层一组分组，组内梯度取平均，在 SparseLoCo 之上再压 6 倍。两层合起来，README 声称总共 195 倍压缩，单轮从 5.5 MB 降到 28 KB。这个 195 倍是 45 乘 6 的近似值，量级上说得通，但它是项目方自述，没有第三方复现。

另一个设计是自适应 inner steps。节点先跑一个硬件速度基准，再据此算出在 25 分钟训练预算内应该跑多少步。README 说快的 GPU 节点能跑 100 步以上，慢的 CPU 节点跑 5 到 10 步。这个设计解决的是异构集群里快节点等慢节点的问题，代价是慢节点每轮贡献的本地计算量极少，它对全局模型的边际价值需要实测才知道。

模型权重和训练 worker 本身走 WebTorrent 分发，README 明确说不依赖中心下载服务器。这个选择合理，但也意味着首次拉取权重时你的下载速度取决于当时在线的做种节点。

从安装到跑起来：真实命令与配置入口

安装是单行脚本，README 给的是 curl -fsSL https://agents.hyper.space/api/install | bash。注意这里有两个不同的安装地址，README 前半段用的是 download.hyper.space，加入网络那一节用的是 agents.hyper.space，两者指向的脚本是否一致，仓库没有说明。管道执行远程脚本这件事本身需要你自己决定是否接受。

训练相关只有两个入口。hyperspace train 加入下一轮训练，hyperspace train --solo 在本机自己的数据上训练。README 没有给出数据格式、数据放置路径或超参配置项，也没有说明 --solo 模式下的产物落在哪里。这是文档里比较薄的一块。

pod 相关的命令相对完整：hyperspace pod create "my-lab" 建 pod，hyperspace pod invite 拿邀请链接，hyperspace pod members 看成员，hyperspace pod models 看集群里所有模型。pod 内的查询会路由到当前加载了最好模型的成员，README 举的例子是 Qwen 3.5 32B、GLM-5 Turbo，以及任意 GGUF 模型。成员还可以把 OpenRouter、Groq、Together 的 key 汇总起来，按成员设预算。

链相关需要单独的安装路径，README 给的是 curl -sSL https://download.hyper.space/api/install，然后 hyperspace start --chain-role fullnode。链 ID 是 808080。另外，节点本地还暴露一个 OpenAI 兼容接口，Base URL 是 http://localhost:8080/v1，端点包括 /chat/completions、/models、/embeddings。

快照是原始 CRDT 状态，不是研究结论

每小时有一个节点把网络研究状态推到仓库的 network-snapshots 分支，路径是 snapshots/latest.json 和 snapshots/日期/小时.json。README 建议直接把这个 URL 丢给任意 LLM 分析。

快照结构在 README 里给了样例：version、timestamp、generatedBy、summary，加五个排行榜（machineLearning、searchEngine、finance、skills、causes），再加 experimentCounts。字段里有一句 disclaimer 值得单独拎出来：Raw CRDT leaderboard state. No statistical significance testing. Interpret the numbers yourself. 项目方自己承认这些数字没有做显著性检验。

样例里还有一个细节：financeTotalRuns 是 0，searchTotalRuns 只有 13，而 mlTotalRuns 是 1369。README 列了五个研究领域，但实际跑起来的实验高度集中在机器学习一个方向上。这不一定是缺陷，可能只是领域刚开放，但它说明排行榜上的领域覆盖度不能按字面理解。用这些快照做任何横向对比之前，先看对应领域的总运行次数。

链的部分：支付通道是给 agent 之间的小额结算准备的

仓库里有一整套区块链实现，README 指向 blockchain/README.md。共识用的是 Mysticeti，即 Sui 那条未认证 DAG，通过 Rust FFI 接入。执行层是无状态执行，配 proof-carrying transactions，README 说自 v1.0.0 起符合 Hyperpaper 的 § V 条款。

对 agent 场景真正有用的是流式支付通道：开一次通道，然后按 sub-cent 级别持续流式付费，最后在链上关闭。这个设计针对的是 agent 之间高频、极小额的调用结算，如果走常规链上转账，手续费会吃掉全部金额。

从发布记录看，链这条线在 2026 年 4 月 29 日一天之内连发了 chain-v1.7.6、v1.7.7、v1.7.8 三个版本，三个版本的说明文字完全相同，都是 Mysticeti force-commit-at-frontier fix。同一天对同一个问题连发三个补丁，说明这个 frontier 提交逻辑当时并不稳定。README 里还写着「54 releases (v0.2.0-alpha → v1.5.7)」和「Chain ID 808080」，但发布记录已经到 v1.7.8，README 的版本号明显滞后。以发布页为准，不要以 README 的表格为准。

pod 的迁移承诺与实际约束

pod 里有一个叫 Capsule 的东西：把 pod 的完整状态（vault、providers、settings）打包成一个 .tar.gz，用 AES-256-GCM 加密，可以迁移，也可以用 docker compose up 自托管。这是整个仓库里最接近「可运维」的部分。

约束也很清楚。第一，pod 是私有集群，不是公开网络，它的价值上限取决于你拉进来的机器数量和型号，人少就是没有意义。第二，共享 provider key 意味着成员之间要互相信任，README 提到可以按成员设预算，但没说预算超限时是拒绝请求还是告警。第三，Capsule 的加密密钥怎么分发、丢了怎么办，README 没有交代。

还有 Pod VM，README 说可以在 9 家云厂商上跑常驻 agent 守护进程，包括 Oracle Free、Scaleway、Fly、Vultr、Lightsail、DO、Linode、Hetzner、Vercel。这只是部署目标的列举，README 没有给出各家的配置差异或任何一家的实测结果。

什么时候它就是个错误的工具

第一，需要可复现结论的场景。DiLoCo 这类异步、异构、节点随时掉线的训练方式，天然不保证两次运行得到相同结果。README 自己的快照都声明不做显著性检验。如果你要写论文或者做 A/B 对比，这套栈给不了你控制变量。

第二，需要训练数据保密的任务。训练是在别人机器上跑的，哪怕只传压缩后的梯度，梯度本身也可能泄露信息。仓库没有讨论任何差分隐私或安全聚合机制，MIT 许可证也不附带任何数据保护承诺。

第三，需要稳定吞吐的生产推理。pod 的路由逻辑是「谁的模型最好就发给谁」，成员离线、模型卸载、网络抖动都会直接影响请求。README 没有提到重试策略、超时配置或健康检查。

第四，小模型微调。195 倍压缩的前提是只传 LoRA 增量。如果你要全参数微调，或者模型小到本地一张卡就能跑完，接入这套 P2P 栈带来的复杂度远大于收益。

第五，如果你只是想用大模型。直接调 API 或者本地跑 ollama 更快。这个项目的价值在训练侧的算力聚合，不在推理本身。

替代方案：与其接入公共网络，不如先看 Petals 或直接自建

同类方向里，Petals 走的是另一条路。它做的是把模型按层切分到多台机器上做分布式推理，每台机器负责模型的一部分，请求在节点之间流水线式传递。hyperspaceai/agi 的重心在训练，靠 DiLoCo 让每个节点完整地训练本地副本再同步增量。两者的取舍正好相反：Petals 对单次请求的延迟更敏感，因为一次前向要跨多个节点；hyperspaceai/agi 对节点异构更宽容，但收敛行为更难预测。如果你的需求是「本地显存装不下这个模型」，Petals 的思路更直接；如果是「我想用多台机器训练一个模型」，hyperspaceai/agi 的路径更贴题。

另一个现实选项是什么都不引入。几台机器在同一局域网里，用 torchrun 起一个同步数据并行的训练，配置成本低于接入一套 P2P 网络，而且结果可复现。hyperspaceai/agi 真正不可替代的场景只有一个：参与者之间没有互信、没有共享机房、无法约定统一的训练窗口。如果这些条件你不满足，这套栈的复杂度就是纯负担。

维护成本、许可证与上线前该确认的事

许可证是 MIT，商用、修改、再分发都不受限。需要注意的是 MIT 只覆盖代码本身，不覆盖网络行为、链上资产或你贡献的算力产生的任何结果。仓库里没有提到代币条款、积分兑换规则或任何形式的收益承诺，README 里的「earn points」具体如何结算，材料中没有说明。

维护成本主要来自两处。一是版本迭代快，链这条线一天之内连发三个补丁，CLI 已经到 v5.20.0，而 README 里链的版本号还停在 v1.5.7，文档和代码之间存在明显的时间差，你读到的说明可能已经不是当前行为。二是依赖面广，训练侧要 Python sidecar，网络侧是 libp2p，链侧是 Rust FFI，pod 侧还有 docker compose，任何一环出问题都要跨语言排查。README 提到训练 worker 有指数退避和 CLI 重启存活机制，说明掉线是常态而非异常。

上线前建议按顺序确认这四件事：跑一次 hyperspace train 并记录节点实际完成的 inner steps 数，与 README 声称的 5 到 10 步或 100 步以上做对照；拉取 snapshots/latest.json，看你关心的领域 experimentCounts 是否长期为零；用 hyperspace pod models 确认集群里实际加载了哪些模型，而不是假设 README 举的 Qwen 3.5 32B 一定可用；最后确认 pod capsule 的 AES-256-GCM 密钥由谁生成和保管。这四步都过了，再谈接入。

编辑结论

适合两类人：手里有闲置 GPU 或常开机器、想跑一次真实分布式训练实验的个人研究者；以及小团队想用 pod 把几台机器拼成一个共享推理集群。不适合需要可复现实验结论、需要 SLA 或需要合规审计的生产团队。接入前先验证三件事：一是运行 hyperspace train 后确认 25 分钟训练预算内节点实际完成的 inner steps 数，二是检查 snapshots/latest.json 里你关心的领域 experimentCounts 是否长期为零，三是确认 pod capsule 的 AES-256-GCM 密钥由谁保管。

官方来源

1. hyperspaceai/agi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases