对较差，这使得通信开销问题更为严重。 OpenAI 训练 GPT-3 的过程中采用了一种叫Megatron的模型并行框架来解决通信开销的问题。Megatron 通过将模型的参数分割并在多个 GPU 之间并行处理，每个设备只负责存储和更新一部分参数，从而减少每个设备需要处理的参数量，降低通信开销。同时，训练时也采用了高速的互连网络，并通过优化网络拓扑结构来减少通信路径长度。 （Data used to train LLM models） 3.为什么分布式算力网络不能做这些优化 要做也是能做的，但相比中心化的机房，这些优化的效果很受限。 网络拓扑优化：在中心化的机房可以直接控制网络硬件和布局，因此可以根据需要设计和优化网络拓扑。然而在分布式环境中，计算节点分布在不同的地理位置，甚至一个在中国，一个在美国，没办法直接控制它们之间的网络连接。尽管可以通过软件来优化数据传输路径，但不如直接优化硬件网络有效。同时，由于地理位置的差异，网络延迟和带宽也有很大的变化，从而进一步限制网络拓扑优化的效果。 模型并行：模型并行是一种将模型的参数分割到多个计算节点上的技术，通过并行处理来提高训练速度。然而这种方法通常需要频繁地在节点之间传输数据，因此对网络带宽和延迟有很高的要求。在中心化的机房由于网络带宽高、延迟低，模型并行可以非常有效。然而，在分布式环境中，由于网络条件差，模型并行会受到较大的限制。 4.数据安全和隐私的挑战 几乎所有涉及数据处理和传输的环节都可能影响到数据安全和隐私： 数据分配：训练数据需要被分配到各个参与计算的节点。这个环节数据可能会在分布式节点被恶意使用/泄漏。 模型训练：在训练过程中，各个节点都会使用其分配到的数据进行计算，然后输出模型参数的更新或梯度。这个过程中，如果节点的计算过程被窃取或者结果被恶意解析，也可能泄露数据。 参数和梯度聚合：各个节点的输出需要被聚合以更新全局模型，聚合过程中的通信也可能泄露关于训练数据的信息。 对于数据隐私问题有哪些解决方案？ 安全多方计算：SMC在某些特定的、规模较小的计算任务中已经被成功应用。但在大规模的分布式训练任务中，由于其计算和通信开销较大，目前还没有广泛应用。 差分隐私：应用在某些数据收集和分析任务中，如Chrome的用户统计等。但在大规模的深度学习任务中，DP会对模型的准确性产生影响。同时，设计适当的噪声生成和添加机制也是一个挑战。 联邦学习：应用在一些边缘设备的模型训练任务中，比如Android键盘的词汇预测等。但在更大规模的分布式训练任务中，FL面临通信开销大、协调复杂等问题。 同态加密：在一些计算复杂度较小的任务中已经被成功应用。但在大规模的分布式训练任务中，由于其计算开销较大，目前还没有广泛应用。 小结一下 以上每种方法都有其适应的场景和局限性，没有一种方法可以在分布式算力网络的大模型训练中完全解决数据隐私问题。 寄予厚望的ZK是否能解决大模型训练时的数据隐私问题？ 理论上ZKP可以用于确保分布式计算中的数据隐私，让一个节点证明其已经按照规定进行了计算，但不需要透露实际的输入和输出数据。 但实际上将ZKP用于大规模分布式算力网络训练大模型的场景中面临以下瓶颈： 计算和通信开销up：构造和验证零知识证明需要大量的计算资源。此外，ZKP的通信开销也很大，因为需要传输证明本身。在大模型训练的情况下，这些开销可能会变得特别显著。例如，如果每个小批量的计算都需要生成一个证明，那么这会显著增加训练的总体时间和成本。 ZK协议的复杂度：设计和实现一个适用于大模型训练的ZKP协议会非常复杂。这个协议需要能够处理大规模的数据和复杂的计算，并且需要能够处理可能出现的异常报错。 硬件和软件的兼容性：使用ZKP需要特定的硬件和软件支持，这可能在所有的分布式计算设备上都不可用。 小结一下 要将ZKP用于大规模分布式算力网络训练大模型，还需要长达数年的研究和开发，同时也需要学术界有更多的精力和资源放在这个方向。 二、分布式算力—模型推理 分布式算力另外一个比较大的场景在模型推理上，按照我们对于大模型发展路径的判断，模型训练的需求会在经过一个高点后随着大模型的成熟而逐步放缓，但模型的推理需求会相应地随着大模型和AIGC的成熟而指数级上升。 推理任务相较于训练任务，通常计算复杂度较低，数据交互性较弱，更适合在分布式环境中进行。 (Power LLM inference with NVIDIA Triton) 1.挑战 通信延迟： 在分布式环境中，节点间的通信是必不可少的。在去中心化的分布式算力网络中，节点可能遍布全球，因此网络延迟会是一个问题，特别是对于需要实时响应的推理任务。 模型部署和更新： 模型需要部署到各个节点上。如果模型进行了更新，那么每个节点都需要更新其模型，需要消耗大量的网络带宽和时间。 数据隐私： 虽然推理任务通常只需要输入数据和模型，不需要回传大量的中间数据和参数，但是输入数据仍然可能包含敏感信息，如用户的个人信息。 模型安全： 在去中心化的网络中，模型需要部署到不受信任的节点上，会导致模型的泄漏导致模型产权和滥用问题。这也可能引发安全和隐私问题，如果一个模型被用于处理敏感数据，节点可以通过分析模型行为来推断出敏感信息。 质量控制： 去中心化的分布式算力网络中的每个节点可能具有不同的计算能力和资源，这可能导致推理任务的性能和质量难以保证。 2.可行性 计算复杂度： 在训练阶段，模型需要反复迭代，训练过程中需要对每一层计算前向传播和反向传播，包括激活函数的计算、损失函数的计算、梯度的计算和权重的更新。因此，模型训练的计算复杂度较高。 在推理阶段，只需要一次前向传播计算预测结果。例如，在GPT-3中，需要将输入的文本转化为向量，然后通过模型的各层（通常为Transformer层）进行前向传播，最后得到输出的概率分布，并根据这个分布生成下一个词。在GANs中，模型需要根据输入的噪声向量生成一张图片。这些操作只涉及模型的前向传播，不需要计算梯度或更新参数，计算复杂度较低。 数据交互性： 在推理阶段，模型通常处理的是单个输入，而不是训练时的大批量的数据。每次推理的结果也只依赖于当前的输入，而不依赖于其它的输入或输出，因此无需进行大量的数据交互，通信压力也就更小。 以生成式图片模型为例，假设我们使用GANs生成图片，我们只需要向模型输入一个噪声向量，然后模型会生成一张对应的图片。这个过程中，每个输入只会生成一个输出，输出之间没有依赖关系，因此无需进行数据交互。 以GPT-3为例，每次生成下一个词只需要当前的文本输入和模型的状态，不需要和其他输入或输出进行交互，因此数据交互性的要求也弱。 小结一下 不管是大语言模型还是生成式图片模型，推理任务的计算复杂度和数据交互性都相对较低，更适合在去中心化的分布式算力网络中进行，这也是现在我们看到大多数项目在发力的一个方向。 三、项目 去中心化的分布式算力网络的技术门槛和技术广度都非常高，并且也需要硬件资源的支撑，因此现在我们并没有看到太多尝试。以Together和Gensyn.ai举例： 1.Together （RedPajama from Together） Together是一家专注于大模型的开源，致力于去中心化的AI算力方案的公司，希望任何人在任何地方都能接触和使用AI。Together刚完成了Lux Capital领投的20m USD的种子轮融资。 Together由Chris、Percy、Ce联合创立，初衷是由于大模型训练需要大量高端的GPU集群和昂贵的支出，并且这些资源和模型训练的能力也集中在少数大公司。 从我的角度看，一个比较合理的分布式算力的创业规划是： Step1. 开源模型 要在去中心化的分布式算力网络中实现模型推理，先决条件是节点必须能低成本地获取模型，也就是说使用去中心化算力网络的模型需要开源（如果模型需要在相应的许可下使用，就会增加实现的复杂性和成本）。比如chatgpt作为一个非开源的模型，就不适合在去中心化算力网络上执行。 因此，可以推测出一个提供去中心化算力网络的公司的隐形壁垒是需要具备强大的大模型开发和维护能力。自研并开源一个强大的base model能够一定程度上摆脱对第三方模型开源的依赖，解决去中心化算力网络最基本的问题。同时也更有利于证明算力网络能够有效地进行大模型的训练和推理。 而Together也是这么做的。最近发布的基于LLaMA的RedPajama是由Together, Ontocord.ai, ETH DS3Lab, Stanford CRFM和Hazy Research等团队联合启动的，目标是研发一系列完全开源的大语言模型。 Step2. 分布式算力在模型推理上落地 就像上面两节提到的，和模型训练相比，模型推理的计算复杂度和数据交互性较低，更适合在去中心化的分布式环境中进行。 在开源模型的基础上，Together的研发团队针对RedPajama-INCITE-3B模型现做了一系列更新，比如利用LoRA实现低成本的微调，使模型在CPU（特别是使用M2 Pro处理器的MacBook Pro）上运行模型更加丝滑。同时，尽管这个模型的规模较小，但它的能力却超过了相同规模的其他模型，并且在法律、社交等场景得到了实际应用。 Step3. 分布式算力在模型训练上落地 （Overcoming Communication Bottlenecks for Decentralized Training的算力网络示意图） 从中长期来看，虽然面临很大的挑战和技术瓶颈，承接AI大模型训练上的算力需求一定是最诱人的。Together在建立之初就开始布局如何克服去中心化训练中的通信瓶颈方面的工作。他们也在NeurIPS 2022上发布了相关的论文：Overcoming Communication Bottlenecks for Decentralized Training。我们可以主要归纳出以下方向： 调度优化 在去中心化环境中进行训练时，由于各节点之间的连接具有不同的延迟和带宽，因此，将需要重度通信的任务分配给拥有较快连接的设备是很重要的。Together通过建立模型来描述特定调度策略的成本，更好地优化调度策略，以最小化通信成本，最大化训练吞吐量。Together团队还发现，即使网络慢100倍，端到端的训练吞吐量也只慢了1.7至2.3倍。因此，通过调度优化来追赶分布式网络和中心化集群之间的差距很有戏。 通信压缩优化 Together提出了对于前向激活和反向梯度进行通信压缩，引入了AQ-SGD算法，该算法提供了对随机梯度下降收敛的严格保证。AQ-SGD能够在慢速网络（比如500 Mbps）上微调大型基础模型，与在中心化算力网络（比如10 Gbps）无压缩情况下的端到端训练性能相比，只慢了31%。此外，AQ-SGD还可以与最先进的梯度压缩技术（比如QuantizedAdam）结合使用，实现10%的端到端速度提升。 项目总结 Together团队配置非常全面，成员都有非常强的学术背景，从大模型开发、云计算到硬件优化都有行业专家支撑。并且Together在路径规划上确实展现出了一种长期有耐心的架势，从研发开源大模型到测试闲置算力（比如mac）在分布式算力网络用语模型推理，再到分布式算力在大模型训练上的布局。— 有那种厚积薄发的感觉了:) 但是目前并没有看到Together在激励层过多的研究成果，我认为这和技术研发具有相同的重要性，是确保去中心化算力网络发展的关键因素。 2.Gensyn.ai (Gensyn.ai) 从Together的技术路径我们可以大致理解去中心化算力网络在模型训练和推理上的落地过程以及相应的研发重点。 另一个不能忽视的重点是算力网络激励层/共识算法的设计，比如一个优秀的网络需要具备： 确保收益足够有吸引力； 确保每个矿工获得了应有的收益，包括防作弊和多劳多得； 确保任务在不同节点直接合理调度和分配，不会有大量闲置节点或者部分节点过度拥挤； 激励算法简洁高效，不会造成过多的系统负担和延迟； …… 看看Gensyn.ai是怎么做的： 成为节点 首先，算力网络中的solver通过bid的方式竞争处理user提交的任务的权利，并且根据任务的规模和被发现作弊的风险，solver需要抵押一定的金额。 验证 Solver在更新parameters的同时生成多个checkpoints（保证工作的透明性和可追溯性），并且会定期生成关于任务的密码学加密推理proofs（工作进度的证明）； Solver完成工作并产生了一部分计算结果时，协议会选择一个verifier，verifier也会质押一定金额（确保verifier诚实地执行验证），并且根据上述提供的proofs来决定需要验证哪一部分的计算结果。 如果solver和verifier出现分歧 通过基于Merkle tree的数据结构，定位到计算结果存在分歧的确切位置。整个验证的操作都会上链，作弊者会被扣除质押的金额。 项目总结 激励和验证算法的设计使得Gensyn.ai不需要在验证过程中去重放整个计算任务的所有结果，而只需要根据提供的证明对一部分结果进行复制和验证，这极大地提高了验证的效率。同时，节点只需要存储部分计算结果，这也降低了存储空间和计算资源的消耗。另外，潜在的作弊节点无法预测哪些部分会被选中进行验证，所以这也降低了作弊风险； 这种验证分歧并发现作弊者的方式也可以在不需要比较整个计算结果的情况下（从Merkle tree的根节点开始，逐步向下遍历），可以快速找到计算过程中出错的地方，这在处理大规模计算任务时非常有效。 总之Gensyn.ai的激励/验证层设计目标就是：简洁高效。但目前仅限于理论层面，具体实现可能还会面临以下挑战： 在经济模型上，如何设定合适的参数，使其既能有效地防止欺诈，又不会对参与者构成过高的门槛。 在技术实现上，如何制定一种有效的周期性的加密推理证明，也是一个需要高级密码学知识的复杂问题。 在任务分配上仅仅算力网络如何挑选和分配任务给不同的solver也需要合理的调度算法的支撑，仅仅按照bid机制来分配任务从效率和可行性上看显然是有待商榷的，比如算力强的节点可以处理更大规模的任务，但可能没有参与bid（这里就涉及到对节点availability的激励问题），算力低的节点可能出价最高但并不适合处理一些复杂的大规模计算任务。 四、对未来的一点思考 谁需要去中心化算力网络这个问题其实一直没有得到验证。闲置算力应用在对算力资源需求巨大的大模型训练上显然是最make sense，也是想象空间最大的。但事实上通信、隐私等瓶颈不得不让我们重新思考： 去中心化地训练大模型是不是真的能看到希望？ 如果跳出这种大家共识的，“最合理的落地场景”，是不是把去中心化算力应用在小型AI模型的训练也是一个很大的场景。从技术角度看，目前的限制因素都由于模型的规模和架构得到了解决，同时，从市场上看，我们一直觉得大模型的训练从当下到未来都会是巨大的，但小型AI模型的市场就没有吸引力了吗？ 我觉得未必。相比大模型小型AI模型更便于部署和管理，而且在处理速度和内存使用方面更有效率，在大量的应用场景中，用户或者公司并不需要大语言模型更通用的推理能力，而是只关注在一个非常细化的预测目标。因此，在大多数场景中，小型AI模型仍然是更可行的选择，不应该在fomo大模型的潮水中被过早地忽视。 Reference https://www.together.xyz/blog/neurips-2022-overcoming-communication-bottlenecks-for-decentralized-training-12 https://www.together.xyz/blog/redpajama https://docs.gensyn.ai/litepaper/ https://www.nvidia.com/en-in/deep-learning-ai/solutions/large-language-models/ https://indiaai.gov.in/article/training-data-used-to-train-llm-models 来源：金色财经lg...
北美站
