Foresight Ventures: 理性看待去中心化算力網絡

大家都知道去中心化算力的場景很大，但是挑戰在哪裡？誰能 target 這些問題，而不是盲目入局，才是判斷這個賽道優秀項目的核心。

作者: Ian Xu@Foresight Ventures

TL;DR

• 目前 AI + Crypto 結合的點主要有 2 個比較大的方向：分佈式算力和 ZKML；關於 ZKML 可以參考我之前的一篇文章。本文將圍繞去中心化的分佈式算力網絡做出分析和反思。
• 在 AI 大模型的發展趨勢下，算力資源會是下一個十年的大戰場，也是未來人類社會最重要的東西，並且不只是停留在商業競爭，也會成為大國博弈的戰略資源。未來對於高性能計算基礎設施、算力儲備的投資將會指數級上升。
• 去中心化的分佈式算力網絡在 AI 大模型訓練上的需求是最大的，但是也面臨最大的挑戰和技術瓶頸。包括需要復雜的數據同步和網絡優化問題等。此外，數據隱私和安全也是重要的製約因素。雖然有一些現有的技術能提供初步解決方案，但在大規模分佈式訓練任務中，由於計算和通信開銷巨大，這些技術仍無法應用。
• 去中心化的分佈式算力網絡在模型推理上更有機會落地，可以預測未來的增量空間也足夠大。但也面臨通信延遲、數據隱私、模型安全等挑戰。和模型訓練相比，推理時的計算複雜度和數據交互性較低，更適合在分佈式環境中進行。
• 通過 Together 和 Gensyn.ai 兩個初創公司的案例，分別從技術優化和激勵層設計的角度說明了去中心化的分佈式算力網絡整體的研究方向和具體思路。

一、分佈式算力—大模型訓練

我們在討論分佈式算力在訓練時的應用，一般聚焦在大語言模型的訓練，主要原因是小模型的訓練對算力的需求並不大，為了做分佈式去搞數據隱私和一堆工程問題不划算，不如直接中心化解決。而大語言模型對算力的需求巨大，並且現在在爆發的最初階段，2012-2018，AI 的計算需求大約每 4 個月就翻一倍，現在更是對算力需求的集中點，可以預判未來 5-8 年仍然會是巨大的增量需求。

在巨大機遇的同時，也需要清晰的看到問題。大家都知道場景很大，但是具體的挑戰在哪裡？誰能 target 這些問題而不是盲目入局，才是判斷這個賽道優秀項目的核心。

1. 整體訓練流程

以訓練一個具有 1750 億參數的大模型為例。由於模型規模巨大，需要在很多個 GPU 設備上進行並行訓練。假設有一個中心化的機房，有 100 個 GPU，每個設備具有 32GB 的內存。

• 數據準備：首先需要一個巨大的數據集，這個數據集包含例如互聯網信息、新聞、書籍等各種數據。在訓練前需要對這些數據進行預處理，包括文本清洗、標記化（tokenization）、詞表構建等。
• 數據分割：處理完的數據會被分割成多個 batch，以在多個 GPU 上並行處理。假設選擇的 batch 大小是 512，也就是每個批次包含 512 個文本序列。然後，我們將整個數據集分割成多個批次，形成一個批次隊列。
• 設備間數據傳輸：在每個訓練步驟開始時，CPU 從批次隊列中取出一個批次，然後將這個批次的數據通過 PCIe 總線發送到 GPU。假設每個文本序列的平均長度是 1024 個標記，那麼每個批次的數據大小約為 512 * 1024 * 4B = 2MB（假設每個標記使用 4 字節的單精度浮點數表示）。這個數據傳輸過程通常只需要幾毫秒。
• 並行訓練：每個 GPU 設備接收到數據後，開始進行前向傳播（forward pass）和反向傳播（backward pass）計算，計算每個參數的梯度。由於模型的規模非常大，單個 GPU 的內存無法存放所有的參數，因此我們使用模型並行技術，將模型參數分佈在多個 GPU 上。
• 梯度聚合和參數更新：在反向傳播計算完成後，每個 GPU 都得到了一部分參數的梯度。然後，這些梯度需要在所有的 GPU 設備之間進行聚合，以便計算全局梯度。這需要通過網絡進行數據傳輸，假設用的是 25Gbps 的網絡，那麼傳輸 700GB 的數據（假設每個參數使用單精度浮點數，那麼 1750 億參數約為 700GB）需要約 224 秒。然後，每個 GPU 根據全局梯度更新其存儲的參數。
• 同步：在參數更新後，所有的 GPU 設備需要進行同步，以確保它們都使用一致的模型參數進行下一步的訓練。這也需要通過網絡進行數據傳輸。
• 重複訓練步驟：重複上述步驟，直到完成所有批次的訓練，或者達到預定的訓練輪數（epoch）。

這個過程涉及到大量的數據傳輸和同步，這可能會成為訓練效率的瓶頸。因此，優化網絡帶寬和延遲，以及使用高效的並行和同步策略，對於大規模模型訓練非常重要。

2. 通信開銷的瓶頸：

需要注意的是，通信的瓶頸也是導致現在分佈式算力網絡做不了大語言模型訓練的原因。

各個節點需要頻繁地交換信息以協同工作，這就產生了通信開銷。對於大語言模型，由於模型的參數數量巨大這個問題尤為嚴重。通信開銷分這幾個方面：

• 數據傳輸：訓練時節點需要頻繁地交換模型參數和梯度信息。這需要將大量的數據在網絡中傳輸，消耗大量的網絡帶寬。如果網絡條件差或者計算節點之間的距離較大，數據傳輸的延遲就會很高，進一步加大了通信開銷。
• 同步問題：訓練時節點需要協同工作以保證訓練的正確進行。這需要在各節點之間進行頻繁的同步操作，例如更新模型參數、計算全局梯度等。這些同步操作需要在網絡中傳輸大量的數據，並且需要等待所有節點完成操作，這會導致大量的通信開銷和等待時間。
• 梯度累積和更新：訓練過程中各節點需要計算自己的梯度，並將其發送到其他節點進行累積和更新。這需要在網絡中傳輸大量的梯度數據，並且需要等待所有節點完成梯度的計算和傳輸，這也是導致大量通信開銷的原因。
• 數據一致性：需要保證各節點的模型參數保持一致。這需要在各節點之間進行頻繁的數據校驗和同步操作，這會導致大量的通信開銷。

雖然有一些方法可以減少通信開銷，比如參數和梯度的壓縮、高效並行策略等，但是這些方法可能會引入額外的計算負擔，或者對模型的訓練效果產生負面影響。並且，這些方法也不能完全解決通信開銷問題，特別是在網絡條件差或計算節點之間的距離較大的情況下。

舉一個例子：

去中心化分佈式算力網絡

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 之間並行處理，每個設備只負責存儲和更新一部分參數，從而減少每個設備需要處理的參數量，降低通信開銷。同時，訓練時也採用了高速的互連網絡，並通過優化網絡拓撲結構來減少通信路徑長度。

3. 為什麼分佈式算力網絡不能做這些優化

要做也是能做的，但相比中心化的機房，這些優化的效果很受限。

1. 網絡拓撲優化：在中心化的機房可以直接控製網絡硬件和佈局，因此可以根據需要設計和優化網絡拓撲。然而在分佈式環境中，計算節點分佈在不同的地理位置，甚至一個在中國，一個在美國，沒辦法直接控制它們之間的網絡連接。儘管可以通過軟件來優化數據傳輸路徑，但不如直接優化硬件網絡有效。同時，由於地理位置的差異，網絡延遲和帶寬也有很大的變化，從而進一步限製網絡拓撲優化的效果。
2. 模型並行：模型並行是一種將模型的參數分割到多個計算節點上的技術，通過並行處理來提高訓練速度。然而這種方法通常需要頻繁地在節點之間傳輸數據，因此對網絡帶寬和延遲有很高的要求。在中心化的機房由於網絡帶寬高、延遲低，模型並行可以非常有效。然而，在分佈式環境中，由於網絡條件差，模型並行會受到較大的限制。

4. 數據安全和隱私的挑戰

幾乎所有涉及數據處理和傳輸的環節都可能影響到數據安全和隱私：

1. 數據分配：訓練數據需要被分配到各個參與計算的節點。這個環節數據可能會在分佈式節點被惡意使用/洩漏。
2. 模型訓練：在訓練過程中，各個節點都會使用其分配到的數據進行計算，然後輸出模型參數的更新或梯度。這個過程中，如果節點的計算過程被竊取或者結果被惡意解析，也可能洩露數據。
3. 參數和梯度聚合：各個節點的輸出需要被聚合以更新全局模型，聚合過程中的通信也可能洩露關於訓練數據的信息。

對於數據隱私問題有哪些解決方案？

• 安全多方計算：SMC 在某些特定的、規模較小的計算任務中已經被成功應用。但在大規模的分佈式訓練任務中，由於其計算和通信開銷較大，目前還沒有廣泛應用。
• 差分隱私：應用在某些數據收集和分析任務中，如 Chrome 的用戶統計等。但在大規模的深度學習任務中，DP 會對模型的準確性產生影響。同時，設計適當的噪聲生成和添加機制也是一個挑戰。
• 聯邦學習：應用在一些邊緣設備的模型訓練任務中，比如 Android 鍵盤的詞彙預測等。但在更大規模的分佈式訓練任務中，FL 面臨通信開銷大、協調複雜等問題。
• 同態加密：在一些計算複雜度較小的任務中已經被成功應用。但在大規模的分佈式訓練任務中，由於其計算開銷較大，目前還沒有廣泛應用。

小結一下

以上每種方法都有其適應的場景和局限性，沒有一種方法可以在分佈式算力網絡的大模型訓練中完全解決數據隱私問題。

寄予厚望的 ZK 是否能解決大模型訓練時的數據隱私問題？

理論上 ZKP 可以用於確保分佈式計算中的數據隱私，讓一個節點證明其已經按照規定進行了計算，但不需要透露實際的輸入和輸出數據。

但實際上將 ZKP 用於大規模分佈式算力網絡訓練大模型的場景中面臨以下瓶頸：

• 計算和通信開銷 up：構造和驗證零知識證明需要大量的計算資源。此外，ZKP 的通信開銷也很大，因為需要傳輸證明本身。在大模型訓練的情況下，這些開銷可能會變得特別顯著。例如，如果每個小批量的計算都需要生成一個證明，那麼這會顯著增加訓練的總體時間和成本。
• ZK 協議的複雜度：設計和實現一個適用於大模型訓練的 ZKP 協議會非常複雜。這個協議需要能夠處理大規模的數據和復雜的計算，並且需要能夠處理可能出現的異常報錯。
• 硬件和軟件的兼容性：使用 ZKP 需要特定的硬件和軟件支持，這可能在所有的分佈式計算設備上都不可用。

小結一下

要將 ZKP 用於大規模分佈式算力網絡訓練大模型，還需要長達數年的研究和開發，同時也需要學術界有更多的精力和資源放在這個方向。

二、分佈式算力—模型推理

分佈式算力另外一個比較大的場景在模型推理上，按照我們對於大模型發展路徑的判斷，模型訓練的需求會在經過一個高點後隨著大模型的成熟而逐步放緩，但模型的推理需求會相應地隨著大模型和 AIGC 的成熟而指數級上升。

推理任務相較於訓練任務，通常計算複雜度較低，數據交互性較弱，更適合在分佈式環境中進行。

1. 挑戰

通信延遲：

在分佈式環境中，節點間的通信是必不可少的。在去中心化的分佈式算力網絡中，節點可能遍布全球，因此網絡延遲會是一個問題，特別是對於需要實時響應的推理任務。

模型部署和更新：

模型需要部署到各個節點上。如果模型進行了更新，那麼每個節點都需要更新其模型，需要消耗大量的網絡帶寬和時間。

數據隱私：

雖然推理任務通常只需要輸入數據和模型，不需要回傳大量的中間數據和參數，但是輸入數據仍然可能包含敏感信息，如用戶的個人信息。

模型安全：

在去中心化的網絡中，模型需要部署到不受信任的節點上，會導致模型的洩漏導致模型產權和濫用問題。這也可能引發安全和隱私問題，如果一個模型被用於處理敏感數據，節點可以通過分析模型行為來推斷出敏感信息。

質量控制：

去中心化的分佈式算力網絡中的每個節點可能具有不同的計算能力和資源，這可能導致推理任務的性能和質量難以保證。

2. 可行性

計算複雜度：

在訓練階段，模型需要反复迭代，訓練過程中需要對每一層計算前向傳播和反向傳播，包括激活函數的計算、損失函數的計算、梯度的計算和權重的更新。因此，模型訓練的計算複雜度較高。

在推理階段，只需要一次前向傳播計算預測結果。例如，在 GPT-3 中，需要將輸入的文本轉化為向量，然後通過模型的各層（通常為 Transformer 層）進行前向傳播，最後得到輸出的概率分佈，並根據這個分佈生成下一個詞。在 GANs 中，模型需要根據輸入的噪聲向量生成一張圖片。這些操作只涉及模型的前向傳播，不需要計算梯度或更新參數，計算複雜度較低。

數據交互性：

在推理階段，模型通常處理的是單個輸入，而不是訓練時的大批量的數據。每次推理的結果也只依賴於當前的輸入，而不依賴於其它的輸入或輸出，因此無需進行大量的數據交互，通信壓力也就更小。

以生成式圖片模型為例，假設我們使用 GANs 生成圖片，我們只需要向模型輸入一個噪聲向量，然後模型會生成一張對應的圖片。這個過程中，每個輸入只會生成一個輸出，輸出之間沒有依賴關係，因此無需進行數據交互。

以 GPT-3 為例，每次生成下一個詞只需要當前的文本輸入和模型的狀態，不需要和其他輸入或輸出進行交互，因此數據交互性的要求也弱。

小結一下

不管是大語言模型還是生成式圖片模型，推理任務的計算複雜度和數據交互性都相對較低，更適合在去中心化的分佈式算力網絡中進行，這也是現在我們看到大多數項目在發力的一個方向。

三、項目

去中心化的分佈式算力網絡的技術門檻和技術廣度都非常高，並且也需要硬件資源的支撐，因此現在我們並沒有看到太多嘗試。以 Together 和 Gensyn.ai 舉例：

1.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. 分佈式算力在模型訓練上落地

從中長期來看，雖然面臨很大的挑戰和技術瓶頸，承接 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

從 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/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

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。