原文作者: Yihan Xu，Foresight Ventures
- 目前 AI Crypto 結合的點主要有 2 個比較大的方向：分散式算力和 ZKML；關於 ZKML 可以參考我之前的一篇文章。本文將圍繞去中心化的分散式算力網路做出分析和反思。
- 在 AI 大模型的發展趨勢下，算力資源會是下一個十年的大戰場，也是未來人類社會最重要的東西，並且不只是停留在商業競爭，也會成為大國博弈的戰略資源。未來對於高效能運算基礎設施、算力儲備的投資將會指數級上升。
- 去中心化的分散式算力網路在 AI 大模型訓練上的需求是最大的，但是也面臨最大的挑戰和技術瓶頸。包括需要複雜的資料同步和網路最佳化問題等。此外，資料隱私和安全也是重要的制約因素。雖然有一些現有的技術能提供初步解決方案，但在大規模分散式訓練任務中，由於計算和通訊開銷巨大，這些技術仍無法應用。
- 去中心化的分散式算力網路在模型推理上更有機會落地，可以預測未來的增量空間也足夠大。但也面臨通訊延遲、資料隱私、模型安全等挑戰。和模型訓練相比，推理時的計算複雜度和資料互動性較低，更適合在分散式環境中進行。
- 透過 Together 和 Gensyn.ai 兩個初創公司的案例，分別從技術最佳化和激勵層設計的角度說明了去中心化的分散式算力網路整體的研究方向和具體思路。
一、分散式算力—大模型訓練
我們在討論分散式算力在訓練時的應用，一般聚焦在大語言模型的訓練，主要原因是小模型的訓練對算力的需求並不大，為了做分散式去搞資料隱私和一堆工程問題不划算，不如直接中心化解決。而大語言模型對算力的需求巨大，並且現在在爆發的最初階段， 2012-2018 ，AI 的計算需求大約每 4 個月就翻一倍，現在更是對算力需求的集中點，可以預判未來 5-8 年仍然會是巨大的增量需求。
在巨大機遇的同時，也需要清晰的看到問題。大家都知道場景很大，但是具體的挑戰在哪裡？誰能 target 這些問題而不是盲目入局，才是判斷這個賽道優秀專案的核心。
- 資料準備：首先需要一個巨大的資料集，這個資料集包含例如網際網路資訊、新聞、書籍等各種資料。在訓練前需要對這些資料進行預處理，包括文字清洗、標記化（tokenization）、詞表構建等。
- 資料分割：處理完的資料會被分割成多個 batch，以在多個 GPU 上並行處理。假設選擇的 batch 大小是 512 ，也就是每個批次包含 512 個文字序列。然後，我們將整個資料集分割成多個批次，形成一個批次佇列。
- 裝置間資料傳輸：在每個訓練步驟開始時，CPU 從批次佇列中取出一個批次，然後將這個批次的資料透過 PCIe 匯流排傳送到 GPU。假設每個文字序列的平均長度是 1024 個標記，那麼每個批次的資料大小約為 512 * 1024 * 4 B = 2 MB（假設每個標記使用 4 位元組的單精度浮點數表示）。這個資料傳輸過程通常只需要幾毫秒。
- 並行訓練：每個 GPU 裝置接收到資料後，開始進行前向傳播（forward pass）和反向傳播（backward pass）計算，計算每個引數的梯度。由於模型的規模非常大，單個 GPU 的記憶體無法存放所有的引數，因此我們使用模型並行技術，將模型引數分佈在多個 GPU 上。
- 梯度聚合和引數更新：在反向傳播計算完成後，每個 GPU 都得到了一部分引數的梯度。然後，這些梯度需要在所有的 GPU 裝置之間進行聚合，以便計算全域性梯度。這需要透過網路進行資料傳輸，假設用的是 25 Gbps 的網路，那麼傳輸 700 GB 的資料（假設每個引數使用單精度浮點數，那麼 1750 億引數約為 700 GB）需要約 224 秒。然後，每個 GPU 根據全域性梯度更新其儲存的引數。
- 同步：在引數更新後，所有的 GPU 裝置需要進行同步，以確保它們都使用一致的模型引數進行下一步的訓練。這也需要透過網路進行資料傳輸。
- 重複訓練步驟：重複上述步驟，直到完成所有批次的訓練，或者達到預定的訓練輪數（epoch）。
這個過程涉及到大量的資料傳輸和同步，這可能會成為訓練效率的瓶頸。因此，最佳化網路頻寬和延遲，以及使用高效的並行和同步策略，對於大規模模型訓練非常重要。
- 資料傳輸：訓練時節點需要頻繁地交換模型引數和梯度資訊。這需要將大量的資料在網路中傳輸，消耗大量的網路頻寬。如果網路條件差或者計算節點之間的距離較大，資料傳輸的延遲就會很高，進一步加大了通訊開銷。
- 同步問題：訓練時節點需要協同工作以保證訓練的正確進行。這需要在各節點之間進行頻繁的同步操作，例如更新模型引數、計算全域性梯度等。這些同步操作需要在網路中傳輸大量的資料，並且需要等待所有節點完成操作，這會導致大量的通訊開銷和等待時間。
- 梯度累積和更新：訓練過程中各節點需要計算自己的梯度，並將其傳送到其他節點進行累積和更新。這需要在網路中傳輸大量的梯度資料，並且需要等待所有節點完成梯度的計算和傳輸，這也是導致大量通訊開銷的原因。
- 資料一致性：需要保證各節點的模型引數保持一致。這需要在各節點之間進行頻繁的資料校驗和同步操作，這會導致大量的通訊開銷。
雖然有一些方法可以減少通訊開銷，比如引數和梯度的壓縮、高效並行策略等，但是這些方法可能會引入額外的計算負擔，或者對模型的訓練效果產生負面影響。並且，這些方法也不能完全解決通訊開銷問題，特別是在網路條件差或計算節點之間的距離較大的情況下。
舉一個例子：
去中心化分散式算力網路
GPT-3 模型有 1750 億個引數，如果我們使用單精度浮點數（每個引數 4 位元組）來表示這些引數，那儲存這些引數就需要～ 700 GB 的記憶體。而在分散式訓練中，這些引數需要在各個計算節點之間頻繁地傳輸和更新。
假設有 100 個計算節點，每個節點每個步驟都需要更新所有的引數，那麼每個步驟都需要傳輸約 70 TB（700 GB* 100 ）的資料。如果我們假設一個步驟需要 1 s（非常樂觀的假設），那麼每秒鐘就需要傳輸 70 TB 的資料。這種對頻寬的需求已經遠超過了大多數網路，也是一個可行性的問題。
實際情況下，由於通訊延遲和網路擁堵，資料傳輸的時間可能會遠超 1 s。這意味著計算節點可能需要花費大量的時間等待資料的傳輸，而不是進行實際的計算。這會大大降低訓練的效率，而這種效率上的降低不是等一等就能解決的，而是可行和不可行的差別，會讓整個訓練過程不可行。
中心化機房
就算是在中心化的機房環境下，大模型的訓練仍然需要很重的通訊最佳化。
在中心化的機房環境中，高效能運算裝置作為叢集，透過高速網路進行連線來共享計算任務。然而，即使在這種高速網路環境中訓練引數數量極大的模型，通訊開銷仍然是一個瓶頸，因為模型的引數和梯度需要在各計算裝置之間進行頻繁的傳輸和更新。
就像開始提到的，假設有 100 個計算節點，每個伺服器具有 25 Gbps 的網路頻寬。如果每個伺服器每個訓練步驟都需要更新所有的引數，那每個訓練步驟需要傳輸約 700 GB 的資料需要～ 224 秒。透過中心化機房的優勢，開發者可以在資料中心內部最佳化網路拓撲，並使用模型並行等技術，顯著地減少這個時間。
相比之下，如果在一個分散式環境中進行相同的訓練，假設還是 100 個計算節點，分佈在全球各地，每個節點的網路頻寬平均只有 1 Gbps。在這種情況下，傳輸同樣的 700 GB 資料需要～ 5600 秒，比在中心化機房需要的時間長得多。並且，由於網路延遲和擁塞，實際所需的時間可能會更長。
不過相比於在分散式算力網路中的情況，最佳化中心化機房環境下的通訊開銷相對容易。因為在中心化的機房環境中，計算裝置通常會連線到同一個高速網路，網路的頻寬和延遲都相對較好。而在分散式算力網路中，計算節點可能分佈在全球各地，網路條件可能會相對較差，這使得通訊開銷問題更為嚴重。
OpenAI 訓練 GPT-3 的過程中採用了一種叫 Megatron 的模型並行框架來解決通訊開銷的問題。Megatron 透過將模型的引數分割並在多個 GPU 之間並行處理，每個裝置只負責儲存和更新一部分引數，從而減少每個裝置需要處理的引數量，降低通訊開銷。同時，訓練時也採用了高速的互連網路，並透過最佳化網路拓撲結構來減少通訊路徑長度。
3.為什麼分散式算力網路不能做這些最佳化
要做也是能做的，但相比中心化的機房，這些最佳化的效果很受限。
1. 網路拓撲最佳化：在中心化的機房可以直接控制網路硬體和佈局，因此可以根據需要設計和最佳化網路拓撲。然而在分散式環境中，計算節點分佈在不同的地理位置，甚至一個在中國，一個在美國，沒辦法直接控制它們之間的網路連線。儘管可以透過軟體來最佳化資料傳輸路徑，但不如直接最佳化硬體網路有效。同時，由於地理位置的差異，網路延遲和頻寬也有很大的變化，從而進一步限制網路拓撲最佳化的效果。
2. 模型並行：模型並行是一種將模型的引數分割到多個計算節點上的技術，透過並行處理來提高訓練速度。然而這種方法通常需要頻繁地在節點之間傳輸資料，因此對網路頻寬和延遲有很高的要求。在中心化的機房由於網路頻寬高、延遲低，模型並行可以非常有效。然而，在分散式環境中，由於網路條件差，模型並行會受到較大的限制。
4.資料安全和隱私的挑戰
幾乎所有涉及資料處理和傳輸的環節都可能影響到資料安全和隱私：
1. 資料分配：訓練資料需要被分配到各個參與計算的節點。這個環節資料可能會在分散式節點被惡意使用/洩漏。
2. 模型訓練：在訓練過程中，各個節點都會使用其分配到的資料進行計算，然後輸出模型引數的更新或梯度。這個過程中，如果節點的計算過程被竊取或者結果被惡意解析，也可能洩露資料。
3. 引數和梯度聚合：各個節點的輸出需要被聚合以更新全域性模型，聚合過程中的通訊也可能洩露關於訓練資料的資訊。
對於資料隱私問題有哪些解決方案？
- 安全多方計算：SMC 在某些特定的、規模較小的計算任務中已經被成功應用。但在大規模的分散式訓練任務中，由於其計算和通訊開銷較大，目前還沒有廣泛應用。
- 差分隱私：應用在某些資料收集和分析任務中，如 Chrome 的使用者統計等。但在大規模的深度學習任務中，DP 會對模型的準確性產生影響。同時，設計適當的噪聲生成和新增機制也是一個挑戰。
- 聯邦學習：應用在一些邊緣裝置的模型訓練任務中，比如 Android 鍵盤的詞彙預測等。但在更大規模的分散式訓練任務中，FL 面臨通訊開銷大、協調複雜等問題。
- 同態加密：在一些計算複雜度較小的任務中已經被成功應用。但在大規模的分散式訓練任務中，由於其計算開銷較大，目前還沒有廣泛應用。
小結一下
以上每種方法都有其適應的場景和侷限性，沒有一種方法可以在分散式算力網路的大模型訓練中完全解決資料隱私問題。
寄予厚望的 ZK 是否能解決大模型訓練時的資料隱私問題？
理論上 ZKP 可以用於確保分散式計算中的資料隱私，讓一個節點證明其已經按照規定進行了計算，但不需要透露實際的輸入和輸出資料。
但實際上將 ZKP 用於大規模分散式算力網路訓練大模型的場景中面臨以下瓶頸：
- 計算和通訊開銷 up：構造和驗證零知識證明需要大量的計算資源。此外，ZKP 的通訊開銷也很大，因為需要傳輸證明本身。在大模型訓練的情況下，這些開銷可能會變得特別顯著。例如，如果每個小批次的計算都需要生成一個證明，那麼這會顯著增加訓練的總體時間和成本。
- ZK 協議的複雜度：設計和實現一個適用於大模型訓練的 ZKP 協議會非常複雜。這個協議需要能夠處理大規模的資料和複雜的計算，並且需要能夠處理可能出現的異常報錯。
- 硬體和軟體的相容性：使用 ZKP 需要特定的硬體和軟體支援，這可能在所有的分散式計算裝置上都不可用。
小結一下
要將 ZKP 用於大規模分散式算力網路訓練大模型，還需要長達數年的研究和開發，同時也需要學術界有更多的精力和資源放在這個方向。
1.挑戰
通訊延遲：
在分散式環境中，節點間的通訊是必不可少的。在去中心化的分散式算力網路中，節點可能遍佈全球，因此網路延遲會是一個問題，特別是對於需要實時響應的推理任務。
模型部署和更新：
模型需要部署到各個節點上。如果模型進行了更新，那麼每個節點都需要更新其模型，需要消耗大量的網路頻寬和時間。
資料隱私：
雖然推理任務通常只需要輸入資料和模型，不需要回傳大量的中間資料和引數，但是輸入資料仍然可能包含敏感資訊，如使用者的個人資訊。
模型安全：
在去中心化的網路中，模型需要部署到不受信任的節點上，會導致模型的洩漏導致模型產權和濫用問題。這也可能引發安全和隱私問題，如果一個模型被用於處理敏感資料，節點可以透過分析模型行為來推斷出敏感資訊。
質量控制：
去中心化的分散式算力網路中的每個節點可能具有不同的計算能力和資源，這可能導致推理任務的效能和質量難以保證。
2.可行性
計算複雜度：
在訓練階段，模型需要反覆迭代，訓練過程中需要對每一層計算前向傳播和反向傳播，包括啟用函式的計算、損失函式的計算、梯度的計算和權重的更新。因此，模型訓練的計算複雜度較高。
在推理階段，只需要一次前向傳播計算預測結果。例如，在 GPT-3 中，需要將輸入的文字轉化為向量，然後透過模型的各層（通常為 Transformer 層）進行前向傳播，最後得到輸出的機率分佈，並根據這個分佈生成下一個詞。在 GANs 中，模型需要根據輸入的噪聲向量生成一張圖片。這些操作只涉及模型的前向傳播，不需要計算梯度或更新引數，計算複雜度較低。
資料互動性：
在推理階段，模型通常處理的是單個輸入，而不是訓練時的大批次的資料。每次推理的結果也只依賴於當前的輸入，而不依賴於其它的輸入或輸出，因此無需進行大量的資料互動，通訊壓力也就更小。
以生成式圖片模型為例，假設我們使用 GANs 生成圖片，我們只需要向模型輸入一個噪聲向量，然後模型會生成一張對應的圖片。這個過程中，每個輸入只會生成一個輸出，輸出之間沒有依賴關係，因此無需進行資料互動。
以 GPT-3 為例，每次生成下一個詞只需要當前的文字輸入和模型的狀態，不需要和其他輸入或輸出進行互動，因此資料互動性的要求也弱。
小結一下
不管是大語言模型還是生成式圖片模型，推理任務的計算複雜度和資料互動性都相對較低，更適合在去中心化的分散式算力網路中進行，這也是現在我們看到大多數專案在發力的一個方向。
（RedPajama from Together）
Together 是一家專注於大模型的開源，致力於去中心化的 AI 算力方案的公司，希望任何人在任何地方都能接觸和使用 AI。Together 剛完成了 Lux Capital 領投的 20 m USD 的種子輪融資。
Together 由 Chris、Percy、Ce 聯合創立，初衷是由於大模型訓練需要大量高階的 GPU 叢集和昂貴的支出，並且這些資源和模型訓練的能力也集中在少數大公司。
從我的角度看，一個比較合理的分散式算力的創業規劃是：
Step 1. 開源模型
要在去中心化的分散式算力網路中實現模型推理，先決條件是節點必須能低成本地獲取模型，也就是說使用去中心化算力網路的模型需要開源（如果模型需要在相應的許可下使用，就會增加實現的複雜性和成本）。比如 chatgpt 作為一個非開源的模型，就不適合在去中心化算力網路上執行。
因此，可以推測出一個提供去中心化算力網路的公司的隱形壁壘是需要具備強大的大模型開發和維護能力。自研並開源一個強大的 base model 能夠一定程度上擺脫對第三方模型開源的依賴，解決去中心化算力網路最基本的問題。同時也更有利於證明算力網路能夠有效地進行大模型的訓練和推理。
而 Together 也是這麼做的。最近釋出的基於 LLaMA 的 RedPajama 是由 Together, Ontocord.ai, ETH DS 3 Lab, Stanford CRFM 和 Hazy Research 等團隊聯合啟動的，目標是研發一系列完全開源的大語言模型。
Step 2. 分散式算力在模型推理上落地
就像上面兩節提到的，和模型訓練相比，模型推理的計算複雜度和資料互動性較低，更適合在去中心化的分散式環境中進行。
在開源模型的基礎上，Together 的研發團隊針對 RedPajama-INCITE-3 B 模型現做了一系列更新，比如利用 LoRA 實現低成本的微調，使模型在 CPU（特別是使用 M 2 Pro 處理器的 MacBook Pro）上執行模型更加絲滑。同時，儘管這個模型的規模較小，但它的能力卻超過了相同規模的其他模型，並且在法律、社交等場景得到了實際應用。
Step 3. 分散式算力在模型訓練上落地
（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 在激勵層過多的研究成果，我認為這和技術研發具有相同的重要性，是確保去中心化算力網路發展的關鍵因素。
(Gensyn.ai)
從 Together 的技術路徑我們可以大致理解去中心化算力網路在模型訓練和推理上的落地過程以及相應的研發重點。
另一個不能忽視的重點是算力網路激勵層/共識演算法的設計，比如一個優秀的網路需要具備：
1. 確保收益足夠有吸引力；
2. 確保每個礦工獲得了應有的收益，包括防作弊和多勞多得；
3. 確保任務在不同節點直接合理排程和分配，不會有大量閒置節點或者部分節點過度擁擠；
4. 激勵演算法簡潔高效，不會造成過多的系統負擔和延遲；
……
看看 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/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
