去中心化推理：把一個大模型拆給很多臺機器跑

Petals 的 README 第一行寫著：

Run large language models at home, BitTorrent-style

下面接著一句：Llama 2 70B 單批生成，最高每秒 6 個 token¹。一個 70B 的模型，就算壓到 4 位也要 35 GB 左右，家裡沒有哪張顯示卡裝得下。它的意思是：你只要跑模型的一小塊，剩下的交給網上其他人的顯示卡，像 BT 下載那樣大家互相幫忙。

我們自己也有過一個類似的念頭：手上有 20 臺小機器，每臺大約 10 GB 記憶體，能不能連成一個網路，把 Qwen3-30B 跑起來，而且算下來比買 API 還便宜？再往外看，io.net 這類專案說它聚合了全世界幾十萬張閒置 GPU，聽上去也是同一個思路。

那麼，一個模型到底是怎麼拆給很多臺機器的？拆開以後每個 token 要在網路上走幾趟，為什麼 Petals 跨著公網還能有每秒幾個 token？把閒置的機器連起來，真的能更便宜嗎？我們從“為什麼要拆”開始，一層一層往下看。

一、模型為什麼要拆

現象：模型比任何一臺機器的記憶體都大

先交代後文反覆用到的幾個詞。大模型由幾十層結構相同的層（transformer block）疊起來，每層裡是一堆矩陣，這些矩陣的數字叫權重。生成文字時，模型每次只產出一個 token（一個詞或半個詞）：把當前的一個 token 變成一串數字，依次穿過所有層，最後算出下一個 token 是什麼。在層與層之間流動的那串數字叫啟用。為了不重複計算前文，每層還會把前面每個 token 的中間結果存下來，叫 KV 快取。

權重有多大？Llama 2 70B 有 80 層、700 億個權重，16 位儲存要 140 GB，壓到 4 位還有 35 GB 左右。distributed-llama 給出的 Llama 3.3 70B 4 位模型檔案是 40 GB，Qwen3-30B-A3B 是 17 GB²。而一張 T4 有 16 GB 視訊記憶體，一張 RTX 3090 有 24 GB，一臺入門的 Mac mini M4 Pro 也是 24 GB。

圖 1 · 一個 70B 模型壓到 4 位，仍比一張消費級顯示卡或一臺小機器的記憶體大

原因：每生成一個 token，都要把整個模型讀一遍

裝不下為什麼不能放在硬碟或記憶體裡、用到哪層再搬上來？因為生成每一個 token 都要把所有層的權重讀一遍。如果權重放在顯示卡外面，每個 token 都要把幾十 GB 從記憶體搬進視訊記憶體一次。Petals 的論文算過：哪怕用 PCIe 4.0 x16、假設顯示卡算得無限快，這種“解除安裝”（offloading）方式跑 BLOOM-176B 也只有每秒 0.18 步；實測只有 0.0427 步，也就是二十多秒才出一個 token³。

解決：把模型切開，每臺機器只放一部分

既然一臺放不下、搬來搬去又太慢，就讓每臺機器常駐模型的一部分，權重從此不動，只讓啟用在機器之間流動。切法有兩種：按層切，每臺拿連續的若干層；層內切，每一層都拆開，每臺拿每層的一部分。兩種切法對網路的要求完全不同，我們先看更直觀的按層切。

按層切開以後，機器之間到底要傳什麼？

二、按層切開：流水線並行

一個 token 怎麼穿過三臺機器

Petals 論文裡的一組配置是三臺各帶一張 T4 的伺服器，合起來 48 GB，放下 4 位的 Llama 2 70B³。80 層按順序分給三臺，第一臺拿 0–26 層，第二臺拿 27–53 層，第三臺拿 54–79 層。你自己的電腦是客戶端，只放首尾兩小塊：把文字變成數字的嵌入層和把數字變回詞表機率的輸出層，BLOOM-176B 裡這兩塊還不到全部權重的 3%。

這種切法叫流水線並行：像流水線上的工位，每個工位只做自己那幾道工序，做完交給下一個。

圖 2 · 按層切開以後，機器之間只傳一個 token 的啟用，Llama 2 70B 每一跳是 16 KB

圖 2 裡沿著強調色走一遍：客戶端把當前 token 變成 8192 個數，16 位儲存是 16 KB；伺服器 A 跑完 27 層，把同樣大小的 16 KB 交給 B，B 交給 C，C 再把結果交回客戶端，客戶端取樣出下一個詞。之後的每一個 token 都重複這一圈。

每臺伺服器還要把自己那幾層的 KV 快取留在本機，這樣下一個 token 只需要傳這一個 token 的啟用，不用把前文重傳一遍。

網路頻寬不是問題

每一跳只有十幾 KB，在 100 Mbit/s 的家用寬頻上傳一次只要 1.3 毫秒。Petals 的實測也是這樣：3 臺 T4 跑 Llama 2 70B，頻寬從 1 Gbit/s 降到 100 Mbit/s，每秒生成步數還是 2.29，一點沒變；10 臺 RTX 3090 跑 BLOOM-176B，從 1.17 降到 1.05³。

機器會掉線：兩份快取

公網上的機器是別人的，隨時可能關機。KV 快取在伺服器上，伺服器一走，這一段的前文就丟了。Petals 的辦法是再存一份：客戶端把發給每一段的輸入都記下來。某臺伺服器掉線時，客戶端找另一臺持有同樣幾層的伺服器，把記下的輸入重放一遍，重建它的 KV 快取，然後接著生成³。客戶端還會測量每臺伺服器的延遲，挑一條總耗時最短的路線。

頻寬不是問題，掉線也有辦法。那 Petals 為什麼只有每秒幾個 token？

三、每個 token 都要跑一圈網路

現象：延遲一高，速度就掉

還是 Petals 的資料：頻寬固定在 100 Mbit/s，把往返時延（RTT，一個資料包到對方再回來的時間）從不到 5 毫秒加到 100 毫秒，3 臺 T4 每秒的步數從 2.29 掉到 1.57；10 臺 RTX 3090 從 1.05 掉到 0.34，每個 token 從不到 1 秒變成將近 3 秒³。

實驗：每多一個節點，每個 token 多一次往返

為了把網路的影響單獨拿出來看，我們用 llama.cpp 的 RPC 後端做了個小實驗⁴。它的做法和 Petals 一樣是按層切：每臺機器執行一個 ggml-rpc-server，主程序用 --rpc 連上它們，把各層分配過去。

# 每个节点
ggml-rpc-server -p 51001 -t 4
# 主进程：全部层放到 RPC 节点上
llama-bench -m qwen2.5-1.5b-instruct-q4_k_m.gguf -p 0 -n 32 -ngl 99 \
  --rpc 127.0.0.1:52001,127.0.0.1:52002,127.0.0.1:52003,127.0.0.1:52004

模型是 Qwen2.5-1.5B 的 4 位量化版，1.04 GiB。1、2、4 個節點都跑在同一臺 4 核的雲伺服器上，中間各串一個自己寫的 TCP 轉發程式，每個方向延遲固定的毫秒數，用來模擬不同的往返時延。這樣算力始終是同一份，變的只有節點數和網路。不經過 RPC、直接在本機跑，是每 token 38.4 毫秒。

圖 3 · 按層切開後，每個 token 對每個節點付一次往返：4 個節點、RTT 40 毫秒時，每 token 從 38 毫秒漲到 215 毫秒（llama.cpp 實測）

三條線幾乎都是直線，斜率分別是 1.05、1.90、3.79：每多一個節點，每個 token 就多付大約一次往返時延。即使時延為零，每多一個節點也要多幾毫秒的固定開銷：4 個節點每個 token 要 66.8 毫秒，比本機多了七成多。

原因：流水線上的每一跳都要排隊等

道理很簡單。下一個 token 要等這一個 token 算完才知道是什麼，所以一個請求裡的 token 只能一個接一個地生成，每個 token 又要按順序穿過每一段。一個 token 的耗時大約是：

t_{\text{token}} \approx \sum_{i=1}^{N} t_i + N \cdot \text{RTT}

$t_i$ 是第 $i$ 臺機器算自己那幾層的時間， $N$ 是段數。前一項和整個模型放在一臺機器上時差不多：總共要讀的權重一樣多，只是分給了好幾臺輪流讀。後一項是拆開以後多出來的。llama.cpp 的 RPC 是星形連線，啟用每次都要回到主程序再發給下一臺；Petals 讓伺服器直接傳給下一段，但段數一多，往返的次數照樣跟著漲。

這就解釋了開頭的數字。在同一個城市裡，RTT 幾毫秒，三五臺機器多出來的不過十幾毫秒，Llama 2 70B 還能有每秒兩步左右；跨大洲 RTT 上百毫秒，再加幾段，每個 token 就要一兩秒。也解釋了 Jeff Geerling 在 4 臺 Mac Studio 上看到的現象：llama.cpp RPC 加機器反而變慢⁵。按層切能裝下更大的模型，但不會讓單個請求更快。

有沒有辦法讓幾臺機器同時算，把單個請求也變快？

四、層內切開：張量並行

讓每一層都由所有機器一起算

另一種切法是把每一層都拆開。一層裡最大的是幾個矩陣乘法，把矩陣按列切成 4 份，4 臺機器各算一份，再把結果拼起來，這一層就快了將近 4 倍。這叫張量並行。distributed-llama 和 exo 走的都是這條路²⁶。

代價是同步。每臺只算出了部分結果，必須和其他機器交換、合併，才能進入下一步。常見的切法是每層同步兩次，注意力之後一次，MLP 之後一次⁷。Llama 2 70B 有 80 層，生成一個 token 就要全員同步 160 次。流水線並行一個 token 只要 $N$ 跳，張量並行要 160 次。

圖 4 · 生成一個 token，流水線並行要傳 4 次，張量並行要全員同步 160 次（Llama 2 70B，4 臺機器，圖中只畫出前 10 層）

實測：區域網裡能變快

distributed-llama 有一組 4 臺 Mac mini M4 Pro（每臺 24 GB）的實測⁸：

distributed-llama · Mac mini M4 Pro 24 GB · 純 CPU

配置	tok/s	推理 ms/token	傳輸 ms/token
Llama 3.1 8B · 4 位（單臺放得下）
1 臺	16.91	58.70	0.06
2 臺 · 雷靂 5	30.27	25.81	6.94
4 臺 · 雷靂 5	38.83	20.73	4.61
4 臺 · 10G 乙太網	34.61	14.34	14.25
Llama 3.3 70B · 4 位（單臺 24 GB 放不下）
2 臺 · 雷靂 5	3.31	285.05	16.28
4 臺 · 雷靂 5	6.51	116.64	36.62
4 臺 · 10G 乙太網	6.04	130.47	34.41

資料來自 distributed-llama 討論區 #147（v0.11.1，生成 64 個 token）。

表 1 · 張量並行在區域網裡能讓單個請求變快：8B 模型 4 臺快 2.3 倍；70B 要 4 臺才裝得下，每個 token 有約 37 毫秒花在傳輸上

Llama 3.1 8B 一臺就放得下，2 臺快了 1.79 倍，4 臺到 2.3 倍。Llama 3.3 70B 單臺裝不下，4 臺時每個 token 裡 116 毫秒在算，37 毫秒在傳。exo 在 4 臺 Mac Studio 上用 Thunderbolt 5 的 RDMA，把裝置之間的時延從 300 微秒壓到 50 微秒以內，Qwen3 235B 跑到每秒 32 個 token⁵。

不足：同步次數太多，離不開一個房間

160 次同步，每次哪怕只要 1 毫秒，一個 token 就是 160 毫秒；放到 RTT 50 毫秒的公網上，就是 8 秒。所以張量並行的機器都要靠網線、雷靂線直連，最好在同一張桌子上。exo 和 distributed-llama 都是“把家裡幾臺機器連起來”，而不是“把全世界的機器連起來”。

兩種切法各有邊界：按層切能跨公網，但單個請求不會更快；層內切能更快，但走不出區域網。 不管哪一種，單個請求的速度都不比一臺裝得下整個模型的機器快多少。那麼換個角度：單個請求慢，能不能靠同時服務很多請求，把總吞吐做上去？

五、靠併發把機器填滿

現象：流水線上大部分機器在等

回到按層切。一個請求在跑的時候，同一時刻只有一臺機器在算，其他機器都在等啟用傳過來。4 段流水線，每臺機器有四分之三的時間是空的。

解決：讓多個請求錯開排隊

如果同時有好幾個請求，機器 A 算完請求 1 的第一段交出去以後，馬上可以接請求 2 的第一段。只要請求夠多，每臺機器都能一直有活幹。

圖 5 · 單個請求填不滿流水線；多個請求錯開排隊，每臺機器都有活幹（“甲·2”表示請求甲的第 2 個 token）

另一種做法是把多個請求拼成一批，一起穿過流水線。一批 16 個請求，一次往返的時間就由 16 個 token 分攤。我們用 llama.cpp 的批次基準在同一套環境裡試了一下，4 個節點、RTT 20 毫秒：

生成吞吐（tok/s）· Qwen2.5-1.5B 4 位 · llama-batched-bench

同時請求數	本機	4 節點 · RTT 20 ms	4 節點 / 本機
1	23.07	7.06	31%
4	58.95	20.96	36%
16	168.80	68.38	41%

每個請求 32 個輸入 token、生成 32 個 token；4 個節點與本機是同一臺 4 核機器。

表 2 · 請求拼成一批以後，一次往返由整批 token 分攤：16 個請求時，4 節點的總吞吐是單請求的 9.7 倍

單個請求時，4 節點只有本機的 31%；16 個請求一起跑，總吞吐升到本機的 41%，是單請求的 9.7 倍。併發確實能把網路的代價攤薄，但攤不掉：批越大，每一步算得越久，網路佔的比例越小，可每一步該付的往返一次也沒少。

Petals 也是這樣設計的：多個客戶端同時使用時，各自的請求在伺服器之間交錯進行。論文裡 3 臺 T4 同時服務 3 個客戶端，每個客戶端每秒 2.02 步，合起來大約每秒 6 個 token；10 臺 RTX 3090 同時服務 10 個客戶端，合起來大約每秒 11.7 個 token³。

到這裡，拆模型這條路的技術輪廓已經清楚了。io.net 這類號稱幾十萬張 GPU 的專案，也是這樣拆的嗎？

六、io.net 拆的是什麼

現象：推理容器只能跑在一臺機器上

翻 io.net 的文件，會發現它的推理部署有一條硬性要求：容器“必須執行在單個節點內”⁹。使用者部署一個模型時，選的是 GPU 型號、數量和地點，比如一臺 8 卡 H100 的機器，整個模型放在這一臺機器裡跑。

也就是說，io.net 沒有把一個模型拆到天南海北的機器上。它拆的是市場：GPU 來自獨立資料中心、加密礦工和其他算力網路，io.net 把它們登記、驗證、撮合給需要的人¹⁰。

圖 6 · Petals 把一個模型拆給公網上的幾臺機器；io.net 把整臺機器撮合給使用者，推理容器只跑在單個節點上

原因：去中心化放在供給和結算上

io.net 的“去中心化”體現在幾處：

供給：誰都可以把機器掛上來，但掛著待租的裝置必須空閒，CPU 利用率不超過 30%，GPU 不超過 5%（部分消費級卡 20%）¹¹。
驗證：每小時跑一次工作量證明，確認這張卡真的存在、視訊記憶體真的有那麼大¹¹。
激勵：總量 8 億枚 IO 代幣，其中 3 億枚在 20 年裡按小時發給供應方，作為區塊獎勵¹²。

AkashML（Akash 網路上的推理服務）也類似：供給來自 65 個以上的資料中心，對外是一個和 OpenAI 相容的介面¹³。

為什麼不像 Petals 那樣拆模型？前面三節已經給出了答案：拆開以後單個請求更慢，吞吐也更低。要賣 API，就得和資料中心裡的整機比速度和價格，只有讓整個模型留在一臺機器裡，才比得過。

把模型留在一臺機器裡，去中心化省下的又是什麼錢？我們來算一筆賬。

七、閒置硬體能不能更便宜

每個 token 的成本從哪來

每百萬 token 的成本，就是每小時的成本除以每小時產出的 token 數。去中心化推理賭的是分子：機器本來就閒著，不算折舊，只算電費，分子就小得多。拆模型的方案卻在分母上吃虧：單個請求慢，併發又有限，每小時產出的 token 比資料中心的整機少幾個數量級。

我們按每度電 0.15 美元，只算電費，看看前面幾組實測每百萬 token 要花多少：

只算電費 · 每度 0.15 美元

配置	功耗	總吞吐 tok/s	美元 / 百萬 token
H100 · Llama 3.3 70B · 最大負載	700 W	2,209	0.013
H100 · 同上 · 線上可賣（推算）	700 W	約 450	0.065
拆開跑
3×T4 · Llama 2 70B · Petals，3 個客戶端	210 W	6.06	1.44
4×Mac mini · Llama 3.3 70B · 張量並行	260 W	6.51	1.66
10×RTX 3090 · BLOOM-176B · Petals，10 個客戶端	3,500 W	11.7	12.5

功耗按 H100 SXM 700 W、T4 70 W、RTX 3090 350 W、Mac mini 每臺 65 W 計，沒有算主機板、網路和客戶端。吞吐來自 TensorRT-LLM 效能表、Petals 論文表 2 / 表 3 和 distributed-llama #147；“線上可賣”是推算。參照：Llama 3.3 70B 市場最低價是每百萬輸出 token 0.32 美元。

表 3 · 拆開跑的方案光電費就超過每百萬 token 1 美元，比 70B 模型的市場最低價還貴；差距來自吞吐，不來自電價

一張 H100 滿載跑 70B¹⁴，每百萬 token 的電費約 1 美分。4 臺 Mac mini、3 臺 T4 這樣拆開跑，光電費就超過 1 美元，比 Llama 3.3 70B 的市場最低價（每百萬輸出 token 0.32 美元，DeepInfra）還貴四五倍¹⁵。差距不在電價，在吞吐：H100 一張卡同時服務幾百個請求，每秒兩千多個 token；拆開的消費級機器每秒只有幾個。

也就是說，對拆模型的方案，“硬體不要錢”這個前提還不夠，連電費都打不平。

賣 API 的去中心化供應商賣多少錢

那些把整個模型留在一臺機器裡的去中心化供應商呢？OpenRouter 上能看到 io.net、AkashML、Chutes（Bittensor 子網 64）的報價，和同一個模型的最低價放在一起：

OpenRouter 報價 · 美元 / 百萬輸出 token · 2026-10-20

供應商	模型	報價	該模型最低價
AkashML	gpt-oss-120b	0.187	0.15
AkashML	gpt-oss-20b	0.10	0.09
AkashML	Llama 3.3 70B	0.52	0.32
Io Net	Gemma 4 26B A4B	0.31	0.22
Io Net	Mistral Nemo	0.022	0.022
Chutes	Gemma 4 31B	0.37	0.32

透過 OpenRouter 公開介面讀取各供應商價格；“最低價”是同一模型所有供應商裡最便宜的一家。

表 4 · 去中心化供應商的報價貼著市場走，沒有一家低於同模型的最低價

沒有一家比最低價便宜，大多數比最低價貴一些。它們用的是資料中心級的 GPU，成本結構和普通雲廠商差不多，價格也就跟著市場走。區別在於供給從哪來、怎麼結算：一部分供給是別人閒置的卡，供應方的一部分收入來自代幣獎勵。

八、回到 20 臺小機器

現在回頭看開頭那個念頭：20 臺各有 10 GB 記憶體的小機器，跑 Qwen3-30B-A3B。下面的數字是按前面的實測和模型結構推算的，沒有實際搭過 20 臺。

裝得下。 4 位量化後約 17 GB²，20 臺合計 200 GB，按層切成 20 段，每臺不到 1 GB。

單個請求會變慢。 Qwen3-30B-A3B 是混合專家模型，每個 token 只啟用約 3B 引數，4 位下每個 token 要讀約 2 GB 權重。一臺 32 GB 記憶體、頻寬每秒 50 GB 左右的普通電腦獨自跑，大約每秒 20–30 個 token。切成 20 段，讀權重的總時間不變，還要多 20 次往返和 20 份固定開銷。按我們實驗裡每個節點幾毫秒的開銷估算，大約每秒 5–10 個 token。

要靠併發才能打平電費。 按每臺滿載 25 瓦、每度電 0.15 美元，20 臺每小時電費約 0.075 美元。這個模型在 OpenRouter 上的輸出價是每百萬 token 0.50 美元，打平電費需要每秒約 42 個 token；如果再把每臺 200 美元的機器按 3 年攤進來，需要每秒約 125 個 token。單個請求只有 5–10 個，得同時跑十幾到幾十個請求，把 20 段流水線一直填滿。

所以這個方案能跑通，能不能省錢取決於兩件事：機器是不是本來就閒著，以及有沒有足夠多的併發請求。同樣這筆錢，買一臺 64 GB 記憶體的機器單獨跑，速度更快，也省掉了網路和 20 臺機器的運維。

小結

模型為什麼要拆？ 每個 token 都要把所有權重讀一遍，放在顯示卡外面來回搬太慢，只能讓每臺機器常駐一部分。
按層切傳什麼？ 每一跳只傳一個 token 的啟用，Llama 2 70B 是 16 KB；KV 快取留在各臺伺服器上。頻寬不是問題，掉線靠客戶端快取的輸入重放恢復。
為什麼慢？ 每個 token 都要按順序穿過每一段，每一段多一次往返。我們的實驗裡，斜率幾乎正好是每個節點一個 RTT。按層切能裝下更大的模型，不會讓單個請求更快。
層內切呢？ 每層同步兩次，70B 一個 token 要 160 次，只能在區域網甚至雷靂線上做；做到了，單個請求能快 2–3 倍。
併發有用嗎？ 有用。錯開排隊或拼批能把空轉的機器填滿，4 節點 16 個請求時總吞吐是單請求的 9.7 倍，但網路的代價攤不掉。
io.net 拆的是什麼？ 拆的是市場，不是模型。推理容器只能跑在單個節點上；去中心化在供給、驗證和代幣激勵上。
能更便宜嗎？ 拆模型的方案吞吐太低，只算電費每百萬 token 就要 1 美元以上，高於市場最低價；整機的去中心化供應商價格貼著市場走。“閒置硬體不要錢”只有在機器裝得下整個模型、又有足夠併發的時候才成立。

如果想自己驗證第三節的結論，只要一臺機器：編譯 llama.cpp 時開啟 -DGGML_RPC=ON，在本機起幾個 ggml-rpc-server，用 --rpc 把它們都連上，比較節點數不同時每個 token 的耗時；想模擬遠端，就在中間加一個延遲轉發。