去中心化推理：把一个大模型拆给很多台机器跑

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 的耗时；想模拟远程，就在中间加一个延迟转发。