如何用Petals去中心化推理运行Llama 2 70B？众包算力网络配置详解

Petals是一个去中心化的大模型推理框架，它把类似Llama 2 70B这样的巨型Transformer模型按层切分，让互联网上的志愿者各自托管其中的若干层。推理请求从客户端发出后，会沿着一条由不同节点组成的链式路径依次计算，每个节点只负责自己持有的层，然后把中间激活传给下一个节点。这种模式与BitTorrent分发文件的思想高度相似，但传输的对象变成了神经网络的前向计算。由于不需要集中式服务器保存完整模型，单个节点的显存需求可以降低到几GB，同时整个网络的聚合算力足以支撑70B甚至更大的模型。

一、去中心化推理的底层原理

Petals的核心设计是把Transformer模型按连续的层块进行切分。一个完整的Llama 2 70B拥有80个Transformer层，可以划分为10个块，每块8层。志愿者节点可以声明自己托管一个或多个块，客户端在发起推理前会通过分布式哈希表（DHT）查找哪些节点持有输入层附近的块，然后按顺序建立一条链式连接。

推理过程中的数据流是这样的：客户端首先做token嵌入，把嵌入向量发送给持有第一个块的节点；该节点执行对应层的自注意力与前馈计算，输出隐藏状态再发给下一个持有相邻块的节点；依此类推，直到最后一个节点输出logits，返回给客户端进行采样。整个过程中，任何一个节点都不需要看到完整模型参数，也不需要保存所有层的权重。

如果某个节点在推理中途掉线，客户端会检测到超时，然后从DHT中寻找替代节点，从上一个健康节点保存的中间激活继续计算。这种容错机制与去中心化文件共享中的分片冗余思路类似，只是这里的“分片”是计算单元而非静态数据。要理解网络状态，可以用下面的代码查看当前公共网络中注册的块数量。

import petals

# 查看当前Petals公共网络中可用的总块数
config = petals.DistributedBloomConfig.from_pretrained(
    "bigscience/bloom-petals",
    use_auth_token=False
)
total_blocks = config.num_blocks
print(f"网络已注册的块总数: {total_blocks}")

二、公共网络配置与节点接入

想成为算力贡献者，首先需要安装Petals客户端与服务端依赖。在Linux服务器上使用pip即可完成安装，若使用Windows，注意安装路径中的反斜杠必须保留，例如 C:\Petals 这样的写法不要替换成斜杠。安装完成后，启动服务端进程时至少要指定模型名称、公网IP和端口。

公网可达性是节点能否被其他客户端发现的关键。如果你的服务器位于NAT之后，需要在路由器上配置端口转发，同时在云安全组或系统防火墙中放行对应端口。默认端口是31337，也可以自定义。此外还需要设置引导节点（bootstrap peers），可以指定官方维护的长期在线节点，也可以自己搭建一个稳定节点作为网络入口。下面的命令演示了如何启动一个贡献8个块的GPU节点。

# 安装Petals
pip install petals

# 启动服务端，贡献一块GPU显存
python -m petals.cli.run_server \
    --model_name bigscience/bloom-petals \
    --public_name 203.0.113.15 \
    --port 31337 \
    --num_blocks 8 \
    --torch_dtype auto \
    --device cuda

启动后节点会自动加入DHT网络，并定期向其他对等节点发送心跳。你可以通过日志观察到其他客户端发来的前向计算请求。块数量设置越大，单个节点承担的层数越多，对显存和计算能力的要求也越高。一般8GB显存可以运行1到2个块，24GB显存可以运行4到6个块。如果希望节点自动选择最优块数，可以将 --num_blocks 设置为 auto。

对于只想使用算力的用户，不需要运行服务端，只需在客户端代码中指定同一个模型名称，Petals会自动发现网络中的节点并建立连接。客户端本身只保存tokenizer和嵌入层、输出层，显存占用通常在2GB以下。

三、客户端运行Llama 2 70B推理

客户端使用Petals提供的分布式模型类替代Hugging Face原始模型类。以Llama 2 70B为例，社区已经提供了转换后的分布式版本，例如 bigscience/bloom-petals 是一个兼容的示例模型。如果要使用真正的Llama 2 70B权重，需要先获得Meta的授权并转换为Petals支持的格式，但调用方式完全一致。

下面这段代码展示了一个完整的文本生成流程：加载tokenizer，用 DistributedBloomForCausalLM 从公共网络加载模型，然后把输入移动到GPU，执行生成。注意客户端并不需要本地拥有模型权重，权重是分片存储在远程节点上的。

import torch
from transformers import AutoTokenizer
from petals import DistributedBloomForCausalLM

# 使用Petals客户端连接公共网络
model_name = "bigscience/bloom-petals"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = DistributedBloomForCausalLM.from_pretrained(model_name)
model = model.cuda()

inputs = tokenizer("用Petals运行Llama 2 70B的优势是什么？",
                   return_tensors="pt")["input_ids"].cuda()
outputs = model.generate(inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0]))

实际运行Llama 2 70B时，如果使用 meta-llama/Llama-2-70b-chat-hf 原版权重，需要先将其转换为Petals的分布式格式，或者在Hugging Face Hub上查找已转换的社区版本。转换工具会按层切分权重并生成块索引文件，客户端加载时会自动从不同节点拉取对应分片。

四、性能瓶颈与优化策略

去中心化推理的延迟主要由最慢的节点决定。因为链式传递过程中每一跳都会引入网络往返时间，如果某个志愿者节点的带宽较低或GPU繁忙，整条推理路径都会变慢。因此客户端通常会对节点进行测速，优先选择延迟低、吞吐高的路径。

块数量越多，单块层数越少，并行度越高，但中间激活的传输次数也会增加。每个激活向量的尺寸与隐藏维度相关，对于Llama 2 70B，每个token的隐藏状态约为8KB，序列长度1024时一次传输约8MB。高带宽节点适合承担更多块，以减少总跳数。

安全方面，中间激活会暴露输入数据的部分信息，如果推理内容涉及隐私，不建议使用公共网络。同时，目前Petals主要依赖志愿者免费贡献算力，缺乏激励机制，长期稳定性不如商业API。你可以用下面的代码简单测量一次推理的端到端延迟，评估网络状况。

import time
from petals import DistributedBloomForCausalLM
from transformers import AutoTokenizer

model_name = "bigscience/bloom-petals"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = DistributedBloomForCausalLM.from_pretrained(model_name)

inputs = tokenizer("性能测试", return_tensors="pt")["input_ids"]
start = time.time()
outputs = model.generate(inputs, max_new_tokens=20)
end = time.time()
print(f"推理耗时: {end - start:.2f} 秒")

如果测得延迟过高，可以尝试指定更少的生成步数，或者手动设置 allowed_servers 参数只使用延迟低于阈值的节点。对于需要稳定低延迟的场景，自建私有Petals网络并只允许可信节点加入是更合理的选择。

Petals去中心化推理Llama 2 70B修改时间：2026-10-04 03:41:32