hyperspaceai/agi：把 DiLoCo 訓練與 libp2p 網路塞進一個 CLI 的研究倉庫

這個倉庫在賣什麼：訓練堆疊、共識鏈、快照，三件事綁在一起

hyperspaceai/agi 不是一個單一工具。打開倉庫會看到三條互相比鄰的產品線：CLI 與 Pod 私有叢集、DiLoCo 分散式訓練堆疊、以及 Chain ID 為 808080 的 Hyperspace A1 區塊鏈。三者共用同一個 libp2p 網路與同一份安裝指令，README 也把它們寫成同一個系統的不同側面。

目標讀者因此分成兩類。一類是想把手上幾台機器串成一個推論叢集的小團隊，他們要的是 hyperspace pod 系列指令。另一類是對去中心化訓練有興趣、願意接受實驗性質的研究者，他們要的是 hyperspace train。至於倉庫標題裡的 AGI，README 自己給了時間座標：「This is Day 1, but this is how it starts.」這句話是宣告，不是成果。判斷這個專案時，把它當成一套仍在早期、但已經有具體指令與資料格式的實驗平台，比當成通用人工智慧的進展來得準確。

倉庫以 JavaScript 撰寫，授權為 MIT，預設分支 main，首頁是 agents.hyper.space。README 明確標示它是一個 living research repository，由網路上的自主代理撰寫。這一點會影響你怎麼讀它的文件：內容會隨代理產出而變動，版本節奏也偏快。

DiLoCo 加上兩層壓縮：195 倍是怎麼算出來的

訓練部分的做法是 DiLoCo。README 的說明是每個節點在本機訓練，再把壓縮後的權重差值透過 P2P 網路分享出去。這個選擇解決的是頻寬問題：如果每輪都要同步完整權重，家用網路根本撐不住，節點數一多就會卡在傳輸而不是計算。

壓縮分兩層疊加。第一層是 SparseLoCo，對 LoRA 差值做 top-k 稀疏化，README 給的數字是相對原始資料 45 倍壓縮。第二層是 Parcae 梯度池化，把相鄰的 transformer 層分組，每組 6 層，組內梯度取平均，在此之上再拿 6 倍。兩者相乘後，README 寫的合併結果是 195 倍，每輪從 5.5 MB 降到 28 KB。

這裡要說清楚一件事：45 乘 6 等於 270，不是 195，所以兩層壓縮並非完全獨立相乘，實際比例會依模型與稀疏度而變。倉庫沒有給出量測條件，也沒有說明這個數字是在哪個模型規模下得到。把它當成量級參考，不要當成保證值。

另一項設計是自適應內層步數。節點會先量測自身硬體速度，再算出要跑幾步才能填滿 25 分鐘的訓練預算。README 舉的例子是快的 GPU 節點跑 100 步以上，慢的 CPU 節點跑 5 到 10 步。這是針對異質裝置的務實做法：與其讓慢節點拖住整輪，不如讓每個人都在同一段時間內貢獻自己能給的計算量。代價是各節點貢獻的梯度品質不對等，而倉庫沒有說明這是否在聚合時做加權。

節點能力與權重：九種角色，權重加總之後代表什麼並不清楚

每個節點可以執行九種能力中的任意組合，README 給了各自的權重：推論 +10%、研究 +12%、代理 +8%、儲存 +6%、嵌入 +5%、記憶 +5%、編排 +5%、驗證 +4%、中繼 +3%。嵌入能力指定使用 all-MiniLM-L6-v2 這個 CPU 向量模型。

這些權重的作用是決定節點在網路中獲得多少點數。問題在於倉庫沒有說明權重如何與實際貢獻量掛鉤。一台跑滿 GPU 推論的機器與一台只在背景做中繼的機器，如果都只勾選一項能力，權重差距只有幾個百分點。對於打算投入硬體成本換取點數的人，這是一個必須先向專案方釐清的問題。

網路本身建在 libp2p 上，與 IPFS 使用同一套協定，透過 6 個 bootstrap 節點連接美國、歐洲、亞洲、南美與大洋洲。節點之間沒有中心伺服器，瀏覽器節點透過中繼能力處理 NAT 穿透。這個架構的實際限制是 bootstrap 節點仍然是事實上的入口：它們不控制內容，但控制新節點能不能找到網路。六個節點的分布看起來是為了降低單點風險，README 沒有說明它們由誰維運。

Pod：把幾台機器變成一個共用推論叢集

Pod 是這個倉庫裡最容易落地驗證的功能。流程是每個成員安裝 CLI，其中一人建立 pod，產生邀請連結，其餘成員加入後形成 mesh。README 給的指令是：

hyperspace pod create "my-lab" hyperspace pod invite hyperspace pod members hyperspace pod models

推論查詢會路由到當下載入最佳模型的成員，文件列出的例子包含 Qwen 3.5 32B、GLM-5 Turbo，以及任何 GGUF 模型。成員也可以把 OpenRouter、Groq、Together 的 API key 集中起來共用，並設定每位成員的預算上限。這對小型實驗室有實際意義：不必每個人各自買一份額度，也不必每個人都準備一張能跑大模型的顯卡。

另外兩個元件是 Pod VM 與 Pod Capsule。Pod VM 是在九家供應商上常駐的代理守護程序，README 列出 Oracle Free、Scaleway、Fly、Vultr、Lightsail、DigitalOcean、Linode、Hetzner、Vercel。Pod Capsule 是把整個 pod 狀態（vault、providers、settings）打包成 .tar.gz，使用 AES-256-GCM 加密，可透過 docker compose up 自架或搬遷。

這裡有一個需要留意的細節：Capsule 包含 vault 與 providers，也就是金鑰材料。加密強度取決於密碼與金鑰管理方式，而 README 沒有說明密碼如何派生、是否使用 KDF。要把 Capsule 放到共用儲存或雲端硬碟之前，先確認這一點。

鏈與快照：Mysticeti 共識、串流支付通道，以及沒有統計檢定的排行榜

區塊鏈部分使用 Mysticeti 共識，README 描述為 Sui 的 uncertified DAG，透過 Rust FFI 接入，Chain ID 為 808080。執行方式是無狀態執行搭配 proof-carrying transactions，並提供串流支付通道，用於代理之間的次美分微支付：開一次通道，持續串流小額款項，最後在鏈上結算。這個設計針對的是高頻、小額的機器對機器付費場景，用一般鏈上交易手續費會直接吃掉金額。README 列出已發佈 54 個版本，從 v0.2.0-alpha 到 v1.5.7。

與此並行的是每小時發佈的網路快照。節點會把完整研究狀態寫進 repo 的 network-snapshots 分支，路徑格式是 snapshots/latest.json 與 snapshots/2026-03-11/04.json 這類時間戳檔案。README 建議把這個 URL 直接餵給任何 LLM 分析。

快照的結構值得細看。頂層有 version、timestamp、generatedBy、summary，接著是 leaderboards，底下分 machineLearning、searchEngine、finance、skills、causes 五個領域，各自有 top10 與 globalBest。另有 experimentCounts，README 範例中 mlTotalRuns 是 1369、searchTotalRuns 是 13、financeTotalRuns 是 0。

最重要的欄位是 disclaimer，原文寫著這是 raw CRDT leaderboard state，沒有做統計顯著性檢定，要讀者自行解讀。這個揭露是誠實的，也直接劃出了使用邊界：排行榜上的名次差異可能只是雜訊。任何拿這些數字做決策的人，都應該先看 experimentCounts，因為某個領域如果只有十幾次或零次執行，排行榜本身沒有太多資訊量。

安裝與啟動：三條路徑，各自對應不同的使用深度

瀏覽器路徑最快，打開 agents.hyper.space 就會建立一個代理，不需要安裝任何東西。適合先看看網路長什麼樣子，但沒有本機 GPU 推論能力。

CLI 路徑是完整版本，指令是：

curl -fsSL https://agents.hyper.space/api/install | bash

裝好後會取得背景守護程序與開機自動啟動。要加入訓練，執行 hyperspace train；只想在自己的資料上本機訓練，用 hyperspace train --solo。要跑鏈節點，則是：

curl -sSL https://download.hyper.space/api/install | bash hyperspace start --chain-role fullnode

注意這裡有兩個不同的安裝網域：agents.hyper.space 與 download.hyper.space。兩者都採 curl 管線到 bash 的形式。這種安裝方式把執行權直接交給遠端腳本，在評估階段建議先下載腳本檢視內容再執行，尤其是要跑 fullnode 的機器。

第三條路徑是給 AI 代理用的 OpenAI 相容 API，跑在本機 8080 埠：Base URL 是 http://localhost:8080/v1，端點包含 /chat/completions、/models、/embeddings，另外在 agents.hyper.space/skill.md 提供 skill 檔。既有工具鏈如果支援改 base URL，接上這個端點就能把本地代理當成模型供應商。

版本方面，README 標示 CLI 為 v5.20.0，對應 Parcae 梯度池化與自適應內層步數。近期 release 集中在 chain-v1.7.6 到 chain-v1.7.8，三個版本都在同一天發佈，標題都是 Mysticeti force-commit-at-frontier 修正。同一個修正連發三次，通常代表前兩次沒有真正解決問題，或者需要配合不同節點版本分批上線。要跑 fullnode 的人應該直接跳到最新版，而不是從中間版本開始。

與 Petals 的差異：壓縮梯度而非切分模型

同樣想用一群消費級裝置跑大模型，Petals 走的是另一條路。Petals 把模型切成區塊，不同節點負責不同層，推論時請求在節點之間接力傳遞，重點是讓單一節點不必載入完整模型。hyperspaceai/agi 的訓練堆疊不切模型，每個節點都持有可訓練的副本，只交換壓縮後的權重差值。

這個差異決定了兩種系統的失敗模式。Petals 的瓶頸在推論延遲與節點鏈路的穩定性，任何一環掉線都會影響請求。hyperspaceai/agi 的瓶頸在同步頻寬與聚合策略，節點可以離線一段時間再回來，但每輪的梯度壓縮率與聚合權重會直接影響模型品質。

選擇上，如果你的目標是讓使用者查詢一個大模型，切分式架構的延遲特性比較可預期。如果你的目標是讓多台機器共同訓練並累積成果，DiLoCo 這類做法對網路中斷的容忍度較高。兩者解決的不是同一個問題，不該直接比效能數字。

倉庫還有一項 Petals 沒有的東西：每小時寫回 repo 的快照。它把網路狀態變成一組可下載、可版本控管的 JSON，而不是只能透過 API 查詢的即時狀態。對於想做事後分析的人，這比即時儀表板實用。

該驗證什麼：從快照與 Pod 開始，不要從 AGI 宣稱開始

這個倉庫的維護成本有兩層。技術上，CLI 版本推進到 v5.20.0，鏈端在一天內連發三個修正版，意味著如果你是 fullnode 營運者，需要跟上更新節奏，否則可能卡在已知的共識問題上。授權是 MIT，條款寬鬆，修改與再散布的限制少，但這只涵蓋程式碼；透過網路產生的點數、鏈上支付通道中的資金，以及 Pod 共用 API 額度所衍生的費用歸屬，都不在 MIT 的範圍內，這些需要另外向專案方確認。

要驗證的第一件事是快照的實際內容。抓 snapshots/latest.json，看你要投入的領域在 experimentCounts 裡有多少次執行。如果數字是個位數，那個領域的排行榜還不足以支撐任何結論。disclaimer 欄位已經明講沒有統計檢定，這不是免責樣板，而是對資料性質的準確描述。

第二件事是 Pod 的實際連通性。建立 pod、發出邀請、確認成員機器進入同一個 mesh，再檢查 hyperspace pod models 是否真的看到跨機器的模型清單。這一步不需要 GPU 也能測，卻能驗證整個路由機制是否如文件所述。

第三件事是訓練路徑的除錯資訊。README 提到自主 worker 會自動安裝依賴、啟動 Python sidecar、失敗時指數退避，並能撐過 CLI 重啟。但它沒有交代節點中途離線時，未完成的梯度如何處理，也沒有交代匿名節點之間的資料分片如何避免重疊。這兩點在 32 節點規模還能靠人工核對，規模一大就會變成難以定位的品質問題。在把訓練結果當成研究產出之前，先確認這兩件事在程式碼裡怎麼實作。

編輯結論

需要跨機器共用模型與 API 額度的小型實驗室，值得先試 Pod：安裝 CLI、執行 hyperspace pod create 與 hyperspace pod invite，確認成員機器真的進入同一個 mesh，再決定是否把推論流量導過去。想找可直接用於生產的分散式訓練框架的人應該先停下來：倉庫沒有交代節點掉線後的權重合併策略，也沒有交代資料分片如何在匿名節點間避免重疊，這兩點在 32 節點規模還能靠人工檢查，節點一多就會變成無法除錯的黑箱。動手前先讀 snapshots/latest.json 的 disclaimer 欄位與 experimentCounts，確認你要投入的領域真的有跑過實驗，而不是只有 leaderboard 結構。

官方來源

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