重點內容：
我們在討論分布式算力在訓練時的應用，一般聚焦在大語言模型的訓練，主要原因是小模型的訓練對算力的需求并不大，為了做分布式去搞數據隱私和一堆工程問題不劃算，不如直接中心化解決。而大語言模型對算力的需求巨大，并且現在在爆發的最初階段，2012-2018，AI的計算需求大約每4個月就翻一倍，現在更是對算力需求的集中點，可以預判未來5-8年仍然會是巨大的增量需求。
在巨大機遇的同時，也需要清晰的看到問題。大家都知道場景很大，但是具體的挑戰在哪里？誰能target這些問題而不是盲目入局，才是判斷這個賽道優秀項目的核心。
（NVIDIA NeMo Megatron Framework）
以訓練一個具有1750億參數的大模型為例。由于模型規模巨大，需要在很多個GPU設備上進行并行訓練。假設有一個中心化的機房，有100個GPU，每個設備具有32GB的內存。
這個過程涉及到大量的數據傳輸和同步，這可能會成為訓練效率的瓶頸。因此，優化網絡帶寬和延遲，以及使用高效的并行和同步策略，對于大規模模型訓練非常重要。
需要注意的是，通信的瓶頸也是導致現在分布式算力網絡做不了大語言模型訓練的原因。
各個節點需要頻繁地交換信息以協同工作，這就產生了通信開銷。對于大語言模型，由于模型的參數數量巨大這個問題尤為嚴重。通信開銷分這幾個方面：
雖然有一些方法可以減少通信開銷，比如參數和梯度的壓縮、高效并行策略等，但是這些方法可能會引入額外的計算負擔，或者對模型的訓練效果產生負面影響。并且，這些方法也不能完全解決通信開銷問題，特別是在網絡條件差或計算節點之間的距離較大的情況下。
舉一個例子：
GPT-3模型有1750億個參數，如果我們使用單精度浮點數（每個參數4字節）來表示這些參數，那存儲這些參數就需要~700GB的內存。而在分布式訓練中，這些參數需要在各個計算節點之間頻繁地傳輸和更新。
假設有100個計算節點，每個節點每個步驟都需要更新所有的參數，那么每個步驟都需要傳輸約70TB（700GB*100）的數據。如果我們假設一個步驟需要1s（非常樂觀的假設），那么每秒鐘就需要傳輸70TB的數據。這種對帶寬的需求已經遠超過了大多數網絡，也是一個可行性的問題。
實際情況下，由于通信延遲和網絡擁堵，數據傳輸的時間可能會遠超1s。這意味著計算節點可能需要花費大量的時間等待數據的傳輸，而不是進行實際的計算。這會大大降低訓練的效率，而這種效率上的降低不是等一等就能解決的，而是可行和不可行的差別，會讓整個訓練過程不可行。
就算是在中心化的機房環境下，大模型的訓練仍然需要很重的通信優化。
在中心化的機房環境中，高性能計算設備作為集群，通過高速網絡進行連接來共享計算任務。然而，即使在這種高速網絡環境中訓練參數數量極大的模型，通信開銷仍然是一個瓶頸，因為模型的參數和梯度需要在各計算設備之間進行頻繁的傳輸和更新。
就像開始提到的，假設有100個計算節點，每個服務器具有25Gbps的網絡帶寬。如果每個服務器每個訓練步驟都需要更新所有的參數，那每個訓練步驟需要傳輸約700GB的數據需要~224秒。通過中心化機房的優勢，開發者可以在數據中心內部優化網絡拓撲，并使用模型并行等技術，顯著地減少這個時間。
相比之下，如果在一個分布式環境中進行相同的訓練，假設還是100個計算節點，分布在全球各地，每個節點的網絡帶寬平均只有1Gbps。在這種情況下，傳輸同樣的700GB數據需要~5600秒，比在中心化機房需要的時間長得多。并且，由于網絡延遲和擁塞，實際所需的時間可能會更長。
不過相比于在分布式算力網絡中的情況，優化中心化機房環境下的通信開銷相對容易。因為在中心化的機房環境中，計算設備通常會連接到同一個高速網絡，網絡的帶寬和延遲都相對較好。而在分布式算力網絡中，計算節點可能分布在全球各地，網絡條件可能會相對較差，這使得通信開銷問題更為嚴重。
OpenAI 訓練 GPT-3 的過程中采用了一種叫Megatron的模型并行框架來解決通信開銷的問題。Megatron 通過將模型的參數分割并在多個 GPU 之間并行處理，每個設備只負責存儲和更新一部分參數，從而減少每個設備需要處理的參數量，降低通信開銷。同時，訓練時也采用了高速的互連網絡，并通過優化網絡拓撲結構來減少通信路徑長度。
要做也是能做的，但相比中心化的機房，這些優化的效果很受限。
網絡拓撲優化：在中心化的機房可以直接控制網絡硬件和布局，因此可以根據需要設計和優化網絡拓撲。然而在分布式環境中，計算節點分布在不同的地理位置，甚至一個在中國，一個在美國，沒辦法直接控制它們之間的網絡連接。盡管可以通過軟件來優化數據傳輸路徑，但不如直接優化硬件網絡有效。同時，由于地理位置的差異，網絡延遲和帶寬也有很大的變化，從而進一步限制網絡拓撲優化的效果。
模型并行：模型并行是一種將模型的參數分割到多個計算節點上的技術，通過并行處理來提高訓練速度。然而這種方法通常需要頻繁地在節點之間傳輸數據，因此對網絡帶寬和延遲有很高的要求。在中心化的機房由于網絡帶寬高、延遲低，模型并行可以非常有效。然而，在分布式環境中，由于網絡條件差，模型并行會受到較大的限制。
幾乎所有涉及數據處理和傳輸的環節都可能影響到數據安全和隱私：
小結一下
以上每種方法都有其適應的場景和局限性，沒有一種方法可以在分布式算力網絡的大模型訓練中完全解決數據隱私問題。
寄予厚望的ZK是否能解決大模型訓練時的數據隱私問題？
理論上ZKP可以用于確保分布式計算中的數據隱私，讓一個節點證明其已經按照規定進行了計算，但不需要透露實際的輸入和輸出數據。
但實際上將ZKP用于大規模分布式算力網絡訓練大模型的場景中面臨以下瓶頸：
計算和通信開銷up：構造和驗證零知識證明需要大量的計算資源。此外，ZKP的通信開銷也很大，因為需要傳輸證明本身。在大模型訓練的情況下，這些開銷可能會變得特別顯著。例如，如果每個小批量的計算都需要生成一個證明，那么這會顯著增加訓練的總體時間和成本。
ZK協議的復雜度：設計和實現一個適用于大模型訓練的ZKP協議會非常復雜。這個協議需要能夠處理大規模的數據和復雜的計算，并且需要能夠處理可能出現的異常報錯。
硬件和軟件的兼容性：使用ZKP需要特定的硬件和軟件支持，這可能在所有的分布式計算設備上都不可用。
要將ZKP用于大規模分布式算力網絡訓練大模型，還需要長達數年的研究和開發，同時也需要學術界有更多的精力和資源放在這個方向。
分布式算力另外一個比較大的場景在模型推理上，按照我們對于大模型發展路徑的判斷，模型訓練的需求會在經過一個高點后隨著大模型的成熟而逐步放緩，但模型的推理需求會相應地隨著大模型和AIGC的成熟而指數級上升。
推理任務相較于訓練任務，通常計算復雜度較低，數據交互性較弱，更適合在分布式環境中進行。
（Power LLM inference with NVIDIA Triton）
通信延遲：
在分布式環境中，節點間的通信是必不可少的。在去中心化的分布式算力網絡中，節點可能遍布全球，因此網絡延遲會是一個問題，特別是對于需要實時響應的推理任務。
模型部署和更新：
模型需要部署到各個節點上。如果模型進行了更新，那么每個節點都需要更新其模型，需要消耗大量的網絡帶寬和時間。
數據隱私：
雖然推理任務通常只需要輸入數據和模型，不需要回傳大量的中間數據和參數，但是輸入數據仍然可能包含敏感信息，如用戶的個人信息。
模型安全：
在去中心化的網絡中，模型需要部署到不受信任的節點上，會導致模型的泄漏導致模型產權和濫用問題。這也可能引發安全和隱私問題，如果一個模型被用于處理敏感數據，節點可以通過分析模型行為來推斷出敏感信息。
質量控制：
去中心化的分布式算力網絡中的每個節點可能具有不同的計算能力和資源，這可能導致推理任務的性能和質量難以保證。
計算復雜度：
在訓練階段，模型需要反復迭代，訓練過程中需要對每一層計算前向傳播和反向傳播，包括激活函數的計算、損失函數的計算、梯度的計算和權重的更新。因此，模型訓練的計算復雜度較高。
在推理階段，只需要一次前向傳播計算預測結果。例如，在GPT-3中，需要將輸入的文本轉化為向量，然后通過模型的各層（通常為Transformer層）進行前向傳播，最后得到輸出的概率分布，并根據這個分布生成下一個詞。在GANs中，模型需要根據輸入的噪聲向量生成一張圖片。這些操作只涉及模型的前向傳播，不需要計算梯度或更新參數，計算復雜度較低。
數據交互性：
在推理階段，模型通常處理的是單個輸入，而不是訓練時的大批量的數據。每次推理的結果也只依賴于當前的輸入，而不依賴于其它的輸入或輸出，因此無需進行大量的數據交互，通信壓力也就更小。
以生成式圖片模型為例，假設我們使用GANs生成圖片，我們只需要向模型輸入一個噪聲向量，然后模型會生成一張對應的圖片。這個過程中，每個輸入只會生成一個輸出，輸出之間沒有依賴關系，因此無需進行數據交互。
以GPT-3為例，每次生成下一個詞只需要當前的文本輸入和模型的狀態，不需要和其他輸入或輸出進行交互，因此數據交互性的要求也弱。
不管是大語言模型還是生成式圖片模型，推理任務的計算復雜度和數據交互性都相對較低，更適合在去中心化的分布式算力網絡中進行，這也是現在我們看到大多數項目在發力的一個方向。
去中心化的分布式算力網絡的技術門檻和技術廣度都非常高，并且也需要硬件資源的支撐，因此現在我們并沒有看到太多嘗試。以Together和Gensyn.ai舉例：
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． 分布式算力在模型訓練上落地
從中長期來看，雖然面臨很大的挑戰和技術瓶頸，承接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在激勵層過多的研究成果，我認為這和技術研發具有相同的重要性，是確保去中心化算力網絡發展的關鍵因素。
從Together的技術路徑我們可以大致理解去中心化算力網絡在模型訓練和推理上的落地過程以及相應的研發重點。
另一個不能忽視的重點是算力網絡激勵層/共識算法的設計，比如一個優秀的網絡需要具備：
……
看看Gensyn.ai是怎么做的：
首先，算力網絡中的solver通過bid的方式競爭處理user提交的任務的權利，并且根據任務的規模和被發現作弊的風險，solver需要抵押一定的金額。
Solver在更新parameters的同時生成多個checkpoints（保證工作的透明性和可追溯性），并且會定期生成關于任務的密碼學加密推理proofs（工作進度的證明）；
Solver完成工作并產生了一部分計算結果時，協議會選擇一個verifier，verifier也會質押一定金額（確保verifier誠實地執行驗證），并且根據上述提供的proofs來決定需要驗證哪一部分的計算結果。
通過基于Merkle tree的數據結構，定位到計算結果存在分歧的確切位置。整個驗證的操作都會上鏈，作弊者會被扣除質押的金額。
項目總結
激勵和驗證算法的設計使得Gensyn.ai不需要在驗證過程中去重放整個計算任務的所有結果，而只需要根據提供的證明對一部分結果進行復制和驗證，這極大地提高了驗證的效率。同時，節點只需要存儲部分計算結果，這也降低了存儲空間和計算資源的消耗。另外，潛在的作弊節點無法預測哪些部分會被選中進行驗證，所以這也降低了作弊風險；
這種驗證分歧并發現作弊者的方式也可以在不需要比較整個計算結果的情況下（從Merkle tree的根節點開始，逐步向下遍歷），可以快速找到計算過程中出錯的地方，這在處理大規模計算任務時非常有效。
總之Gensyn.ai的激勵/驗證層設計目標就是：簡潔高效。但目前僅限于理論層面，具體實現可能還會面臨以下挑戰：
在經濟模型上，如何設定合適的參數，使其既能有效地防止欺詐，又不會對參與者構成過高的門檻。
在技術實現上，如何制定一種有效的周期性的加密推理證明，也是一個需要高級密碼學知識的復雜問題。
在任務分配上，僅僅算力網絡如何挑選和分配任務給不同的solver也需要合理的調度算法的支撐，僅僅按照bid機制來分配任務從效率和可行性上看顯然是有待商榷的，比如算力強的節點可以處理更大規模的任務，但可能沒有參與bid（這里就涉及到對節點availability的激勵問題），算力低的節點可能出價最高但并不適合處理一些復雜的大規模計算任務。
誰需要去中心化算力網絡這個問題其實一直沒有得到驗證。閑置算力應用在對算力資源需求巨大的大模型訓練上顯然是最make sense，也是想象空間最大的。但事實上通信、隱私等瓶頸不得不讓我們重新思考：
去中心化地訓練大模型是不是真的能看到希望？
如果跳出這種大家共識的，“最合理的落地場景”，是不是把去中心化算力應用在小型AI模型的訓練也是一個很大的場景。從技術角度看，目前的限制因素都由于模型的規模和架構得到了解決，同時，從市場上看，我們一直覺得大模型的訓練從當下到未來都會是巨大的，但小型AI模型的市場就沒有吸引力了嗎？
我覺得未必。相比大模型小型AI模型更便于部署和管理，而且在處理速度和內存使用方面更有效率，在大量的應用場景中，用戶或者公司并不需要大語言模型更通用的推理能力，而是只關注在一個非常細化的預測目標。因此，在大多數場景中，小型AI模型仍然是更可行的選擇，不應該在fomo大模型的潮水中被過早地忽視。
