Forsight Vnturs: 理性看待去中心化算力网络

发布时间：2025-07-03 23:39:29 来源：杜仲山楂猪肚汤网 作者：创业研究

作者 ：Ian Xu，Foresight Research

我们在讨论分布式算力在训练时的应用，一般聚焦在大语言模型的训练，主要原因是小模型的训练对算力的需求并不大，为了做分布式去搞数据隐私和一堆工程问题不划算，不如直接中心化解决。而大语言模型对算力的需求巨大，并且现在在爆发的最初阶段，2012-2018，AI的计算需求大约每4个月就翻一倍，现在更是对算力需求的集中点，可以预判未来5-8年仍然会是巨大的增量需求。


(NVIDIA NeMo Megatron Framework）


以训练一个具有1750亿参数的大模型为例。由于模型规模巨大，需要在很多个GPU设备上进行并行训练。假设有一个中心化的机房，有100个GPU，每个设备具有32GB的内存。

这个过程涉及到大量的数据传输和同步，这可能会成为训练效率的瓶颈。因此，优化网络带宽和延迟，以及使用高效的并行和同步策略，对于大规模模型训练非常重要。

需要注意的是，通信的瓶颈也是导致现在分布式算力网络做不了大语言模型训练的原因。

虽然有一些方法可以减少通信开销，比如参数和梯度的压缩、高效并行策略等，但是这些方法可能会引入额外的计算负担，或者对模型的训练效果产生负面影响。并且，这些方法也不能完全解决通信开销问题，特别是在网络条件差或计算节点之间的距离较大的情况下。

去中心化分布式算力网络

假设有100个计算节点，每个节点每个步骤都需要更新所有的参数，那么每个步骤都需要传输约70TB（700GB*100）的数据。如果我们假设一个步骤需要1s（非常乐观的假设），那么每秒钟就需要传输70TB的数据。这种对带宽的需求已经远超过了大多数网络，也是一个可行性的问题。

中心化机房

在中心化的机房环境中，高性能计算设备作为集群，通过高速网络进行连接来共享计算任务。然而，即使在这种高速网络环境中训练参数数量极大的模型，通信开销仍然是一个瓶颈，因为模型的参数和梯度需要在各计算设备之间进行频繁的传输和更新。

相比之下，如果在一个分布式环境中进行相同的训练，假设还是100个计算节点，分布在全球各地，每个节点的网络带宽平均只有1Gbps。在这种情况下，传输同样的700GB数据需要～5600秒，比在中心化机房需要的时间长得多。并且，由于网络延迟和拥塞，实际所需的时间可能会更长。

OpenAI 训练 GPT-3 的过程中采用了一种叫Megatron的模型并行框架来解决通信开销的问题。Megatron 通过将模型的参数分割并在多个 GPU 之间并行处理，每个设备只负责存储和更新一部分参数，从而减少每个设备需要处理的参数量，降低通信开销。同时，训练时也采用了高速的互连网络，并通过优化网络拓扑结构来减少通信路径长度。

（Data used to train LLM models）


要做也是能做的，但相比中心化的机房，这些优化的效果很受限。

几乎所有涉及数据处理和传输的环节都可能影响到数据安全和隐私：

对于数据隐私问题有哪些解决方案？

小结一下

寄予厚望的ZK是否能解决大模型训练时的数据隐私问题？

但实际上将ZKP用于大规模分布式算力网络训练大模型的场景中面临以下瓶颈：

小结一下

分布式算力另外一个比较大的场景在模型推理上，按照我们对于大模型发展路径的判断，模型训练的需求会在经过一个高点后随着大模型的成熟而逐步放缓，但模型的推理需求会相应地随着大模型和AIGC的成熟而指数级上升。

(Power LLM inference with NVIDIA Triton)


通信延迟：

模型部署和更新：

数据隐私：

模型安全：

质量控制：

计算复杂度：

在推理阶段，只需要一次前向传播计算预测结果。例如，在GPT-3中，需要将输入的文本转化为向量，然后通过模型的各层（通常为Transformer层）进行前向传播，最后得到输出的概率分布，并根据这个分布生成下一个词。在GANs中，模型需要根据输入的噪声向量生成一张图片。这些操作只涉及模型的前向传播，不需要计算梯度或更新参数，计算复杂度较低。

在推理阶段，模型通常处理的是单个输入，而不是训练时的大批量的数据。每次推理的结果也只依赖于当前的输入，而不依赖于其它的输入或输出，因此无需进行大量的数据交互，通信压力也就更小。

以GPT-3为例，每次生成下一个词只需要当前的文本输入和模型的状态，不需要和其他输入或输出进行交互，因此数据交互性的要求也弱。

不管是大语言模型还是生成式图片模型，推理任务的计算复杂度和数据交互性都相对较低，更适合在去中心化的分布式算力网络中进行，这也是现在我们看到大多数项目在发力的一个方向。

去中心化的分布式算力网络的技术门槛和技术广度都非常高，并且也需要硬件资源的支撑，因此现在我们并没有看到太多尝试。以Together和Gensyn.ai举例：

（RedPajama from Together）


Together由Chris、Percy、Ce联合创立，初衷是由于大模型训练需要大量高端的GPU集群和昂贵的支出，并且这些资源和模型训练的能力也集中在少数大公司。

Step1. 开源模型

因此，可以推测出一个提供去中心化算力网络的公司的隐形壁垒是需要具备强大的大模型开发和维护能力。自研并开源一个强大的base model能够一定程度上摆脱对第三方模型开源的依赖，解决去中心化算力网络最基本的问题。同时也更有利于证明算力网络能够有效地进行大模型的训练和推理。

Step2. 分布式算力在模型推理上落地

在开源模型的基础上，Together的研发团队针对RedPajama-INCITE-3B模型现做了一系列更新，比如利用LoRA实现低成本的微调，使模型在CPU（特别是使用M2 Pro处理器的MacBohuobi Pro）上运行模型更加丝滑。同时，尽管这个模型的规模较小，但它的能力却超过了相同规模的其他模型，并且在法律、社交等场景得到了实际应用。

（Overcoming Communication Bottlenecks for Decentralized Training
的算力网络示意图）

调度优化

通信压缩优化

项目总结

但是目前并没有看到Together在激励层过多的研究成果，我认为这和技术研发具有相同的重要性，是确保去中心化算力网络发展的关键因素。

(Gensyn.ai)


从Together的技术路径我们可以大致理解去中心化算力网络在模型训练和推理上的落地过程以及相应的研发重点。

……

首先，算力网络中的solver通过bid的方式竞争处理user提交的任务的权利，并且根据任务的规模和被发现作弊的风险，solver需要抵押一定的金额。

Solver在更新parameters的同时生成多个checkpoints（保证工作的透明性和可追溯性），并且会定期生成关于任务的密码学加密推理proofs（工作进度的证明）；

通过基于Merkle tree的数据结构，定位到计算结果存在分歧的确切位置。整个验证的操作都会上链，作弊者会被扣除质押的金额。

激励和验证算法的设计使得Gensyn.ai不需要在验证过程中去重放整个计算任务的所有结果，而只需要根据提供的证明对一部分结果进行复制和验证，这极大地提高了验证的效率。同时，节点只需要存储部分计算结果，这也降低了存储空间和计算资源的消耗。另外，潜在的作弊节点无法预测哪些部分会被选中进行验证，所以这也降低了作弊风险；

总之Gensyn.ai的激励/验证层设计目标就是：简洁高效。但目前仅限于理论层面，具体实现可能还会面临以下挑战：

谁需要去中心化算力网络这个问题其实一直没有得到验证。闲置算力应用在对算力资源需求巨大的大模型训练上显然是最make sense，也是想象空间最大的。但事实上通信、隐私等瓶颈不得不让我们重新思考：

如果跳出这种大家共识的，“最合理的落地场景”，是不是把去中心化算力应用在小型AI模型的训练也是一个很大的场景。从技术角度看，目前的限制因素都由于模型的规模和架构得到了解决，同时，从市场上看，我们一直觉得大模型的训练从当下到未来都会是巨大的，但小型AI模型的市场就没有吸引力了吗？

我觉得未必。相比大模型小型AI模型更便于部署和管理，而且在处理速度和内存使用方面更有效率，在大量的应用场景中，用户或者公司并不需要大语言模型更通用的推理能力，而是只关注在一个非常细化的预测目标。因此，在大多数场景中，小型AI模型仍然是更可行的选择，不应该在fomo大模型的潮水中被过早地忽视。

相关文章