在被大規模採用後，Sora 的推理成本將很快超過訓練成本。
OpenAI 推出的 Sora 模型能夠在各種場景下生成極其逼真的影片，吸引了全世界的目光。
最後，文中還討論了對用於訓練 Sora 等模型的算力的看法，並對訓練計算與推理計算的算力比較進行了預測，這對估計未來 GPU 需求具有重要意義。機器之心對此文進行了整理。
本報告的主要調查結果總結如下：
Sora 是一個建立在擴散 Transformers（DiT）、潛在擴散模型之上的擴散模型，模型和訓練資料集似乎都更大更多。
Sora 證明，擴大影片模型是有效的，與大語言模型（LLM）類似，將模型做得更大將是快速改進模型的主要驅動力。
Runway、Genmo 和 Pika 等公司正在圍繞類 Sora 影片生成模型構建直觀的介面和工作流程。這將決定它們的用途和可用性。
Sora 需要大量的計算能力來訓練，至少需要在 4200~10500 塊英偉達 H100 GPU 上訓練 1 個月。
推理階段，估計每個 H100 GPU 每小時最多可以生成約 5 分鐘的影片。與 LLM 相比，像 Sora 這樣基於擴散的模型推理成本要高几個數量級。
隨著類 Sora 模型的廣泛部署，推理計算消耗將多於訓練計算消耗。「平衡點」估計為 1530 萬至 3810 萬分鐘的影片生成，之後在推理上花費的計算會比原始訓練更多。作為參考，TikTok 每天上傳 1700 萬分鐘的影片，YouTube 每天上傳 4300 萬分鐘的影片。
假設 TikTok（所有影片時長的 50%）和 YouTube（全部影片時長的 15%）等流行平臺上大量採用人工智慧做影片生成，考慮到硬體利用率和使用模式，本文估計推理階段的計算峰值需求約為 72 萬塊 Nvidia H100 GPU。
總之，Sora 在影片生成的質量和能力方面取得了重大進展，但也有可能大大增加對 GPU 推理計算的需求。
Sora 的誕生背景
Sora 是一種擴散模型。擴散模型是影像生成領域的熱門模型，著名的模型有 OpenAI 的 DALL・E 和 Stability AI 的 Stable Diffusion。最近，Runway、Genmo 和 Pika 等公司也在探索影片生成，很可能也利用了擴散模型。
從廣義上講，擴散模型是一種生成式機器學習模型，它透過向資料中新增隨機噪聲來逐步反向學習，最終學會建立與其所訓練的資料（如影像或影片）相似的資料。這些模型從純粹的噪聲模式開始，逐步去除噪聲，再完善模型，直至將其轉化為連貫而詳細的輸出。
擴散過程示意圖：噪聲被逐步去除，直至輸出清晰可見詳細的影片。圖片摘自 Sora 技術報告。
這與大語言模型（LLM）在概念上的工作方式明顯不同：LLM 會一個接一個地反覆生成 token（這被稱為自迴歸取樣）。Token 一旦產生，就不會再改變。人們在使用 Perplexity 或 ChatGPT 等工具時，可能已經見識過這種效果：答案會一個字一個字地逐漸出現，就像有人在打字一樣。
Sora 的技術細節
OpenAI 在釋出 Sora 的同時，還發布了一份技術報告。遺憾的是，這份報告的細節不多。不過，其設計似乎深受《Scalable Diffusion Models with Transformers》這篇研究論文的影響，該論文提出了一種基於 Transformer 的架構，稱為 DiT（Diffusion Transformers 的縮寫），用於影像生成。Sora 似乎將這項工作擴充套件到了影片生成。因此，結合 Sora 技術報告和 DiT 論文，就可以相當準確地瞭解 Sora 模型的工作原理。
Sora 有三個重要部分：1）它不是在畫素空間，而是在隱空間中執行擴散（又稱潛在擴散）；2）它使用 Transformers 架構；3）它似乎使用了一個非常大的資料集。
潛在擴散
要理解第一點，即潛在擴散，可以考慮生成一幅影像，並使用擴散生成每個畫素。然而，這樣做的效率非常低（例如，一幅 512x512 的影像有 262,144 個畫素）。取而代之的方法是，首先將畫素對映成具有一定壓縮係數的隱空間表徵，在這個更緊湊的隱空間中執行擴散，最後再將隱空間表徵解碼回畫素空間。這種對映大大降低了計算複雜度：以 64 位的隱空間為例，只需生成 64x64=4,096 個表徵，而不必在 512x512=262,144 個畫素上執行擴散過程。這一想法是《High-Resolution Image Synthesis with Latent Diffusion Models》論文中的關鍵突破，也是穩定擴散技術的基礎。
從畫素（左側）到潛在表示（右側的方框網格）的對映。圖片摘自 Sora 技術報告。
DiT 和 Sora 都採用了這種方法。對於 Sora 來說，另一個考慮因素是影片具有時間維度：影片是影像的時間序列，也稱為幀。從 Sora 的技術報告中可以看出，從畫素對映到隱空間的編碼步驟既發生在空間上（指壓縮每個幀的寬度和高度），也發生在時間上（指跨時間壓縮）。
Transformers
關於第二點，DiT 和 Sora 都用普通的 Transformer 架構取代了常用的 U-Net 架構。這很重要，因為 DiT 論文的作者觀察到，使用 Transformer 能穩定地擴大模型規模：隨著訓練計算量的增加（訓練模型的時間延長或模型增大，或兩者兼而有之），效能也會隨之提高。Sora 的技術報告也指出了同樣的情況也適用於影片，並提供了一個說明。
關於模型質量如何隨訓練計算量的增加而提高的說明：基本計算量、4 倍計算量和 32 倍計算量（從左到右）。影片摘自 Sora 技術報告。
這種縮放自由度可以用所謂的縮放定律（scaling law）來量化，是一種重要的特性，以前在大語言模型（LLM）和其他模態的自迴歸模型中都對其進行過研究。應用縮放以獲得更好模型的能力是 LLM 快速發展的主要推動力之一。既然影像和影片生成也有同樣的特性，我們應該期待同樣的縮放方法在這裡也能發揮作用。
資料
訓練像 Sora 這樣的模型所需的最後一個關鍵要素是標註資料，本文認為這就是 Sora 的秘訣所在。要訓練像 Sora 這樣的文字生成影片模型，需要成對的影片和文字描述。OpenAI 並沒有詳細介紹他們的資料集，但他們暗示資料集非常龐大：「我們從大語言模型中汲取靈感，這些模型透過在網際網路級規模的資料上進行訓練，獲得了通用能力」。OpenAI 還發布了一種用詳細文字標籤註釋影像的方法，該方法曾被用於收集 DALLE・3 資料集。其總體思路是在資料集的一個標註子集上訓練一個標註模型，然後使用該標註模型自動標註其餘的資料集。Sora 的資料集似乎也採用了同樣的技術。
Sora 的影響分析
本文認為 Sora 有幾個重要的影響，如下所示。
影片模型開始真正有用
Sora 生成的影片質量有一個明顯的提升，在細節和時間一致性方面都是如此（例如，該模型能夠正確處理物體在暫時被遮擋時的持續性，並能準確生成水中的倒影）。本文認為，現在的影片質量已經足以應對某些型別的場景，可以在現實世界中應用。Sora 可能很快就會取代部分影片素材的使用。
影片生成領域公司的市場分佈圖。
但 Sora 還會面臨一些挑戰：目前還不清楚 Sora 模型的可操控性。編輯生成的影片既困難又耗時，因為模型輸出的是畫素。此外，圍繞這些模型建立直觀的使用者介面和工作流程也是使其發揮作用的必要條件。Runway、Genmo 和 Pika 等公司以及更多公司（見上面的市場圖）已經在著手解決這些問題。
模型縮放對影片模型有效，可以期待進一步的進展
DiT 論文的一個重要觀點是，如上所述，模型質量會隨著計算量的增加而直接提高。這與已觀察到的 LLM 的規律相似。因此，隨著影片生成模型使用越來越多的計算能力進行訓練，我們應該期待這類模型的質量能快速提高。Sora 清楚地證明了這一方法確實有效，我們期待 OpenAI 和其他公司在這方面加倍努力。
資料生成與資料增強
在機器人和自動駕駛汽車等領域，資料本來就稀缺：網上沒有機器人執行任務或汽車行駛的實時資料。因此，解決這些問題的方法通常是進行模擬訓練或在現實世界中大規模收集資料（或兩者結合）。然而，由於模擬資料往往不夠真實，這兩種方法都難以奏效。大規模收集真實世界的資料成本高昂，而且要為罕見事件收集足夠多的資料也具有挑戰性。
透過修改影片的某些屬性對其進行增強的示例，在本例中，將原始影片（左）渲染為鬱鬱蔥蔥的叢林環境（右）。圖片摘自 Sora 技術報告。
本文認為，類似 Sora 的模型在這方面會非常有用。類似 Sora 的模型有可能直接用於生成合成資料。Sora 還可用於資料增強，將現有影片轉換成不同的外觀。上圖展示了資料增強的效果，Sora 可以將行駛在森林道路上的紅色汽車影片轉換成鬱鬱蔥蔥的叢林景色。使用同樣的技術可以重新渲染白天與夜晚的場景，或者改變天氣條件。
模擬和世界模型
一個前瞻的研究方向是學習所謂的世界模型。如果這些世界模型足夠精確，就可以直接在其中訓練機器人，或者用於規劃和搜尋。
像 Sora 這樣的模型似乎是直接從影片資料中隱式地學習真實世界運作的基本模擬。這種「湧現模擬機制」目前還存在缺陷，但卻令人興奮：它表明，我們或許可以透過影片大規模地訓練這些世界模型。此外，Sora 似乎還能模擬非常複雜的場景，如液體、光的反射、織物和頭髮的運動。OpenAI 甚至將他們的技術報告命名為「作為世界模擬器的影片生成模型」，這表明他們認為這是他們模型最重要的價值。
最近，DeepMind 公司的 Genie 模型也展示了類似的效果： 透過只在遊戲影片上進行訓練，該模型學會了模擬這些遊戲（並製作了新的遊戲）。在這種情況下，模型甚至可以在不直接觀察動作的情況下學會對動作進行判斷。同樣，在這些模擬中直接進行學習也是可以期待的。
谷歌 DeepMind 的「Genie：生成式互動環境」介紹影片。
綜合來看，本文認為 Sora 和 Genie 這樣的模型可能會非常有用，有助於最終在真實世界的任務中大規模地訓練具身智慧體（例如機器人）。不過，這些模型也有侷限性：由於模型是在畫素空間中訓練的，因此它們會對每一個細節進行建模，比如風如何吹動草葉，即使這與手頭的任務完全無關。雖然隱空間被壓縮了，但由於需要能夠對映回畫素，因此隱空間仍需保留大量此類資訊，因此目前還不清楚能否在隱空間中有效地進行規劃。
Sora 的計算量估算
Factorial Funds 公司內部喜歡評估模型在訓練和推理階段分別使用了多少計算量。這很有用，因為這樣可以為預測未來需要多少計算量提供依據。不過，要估算出這些資料也很困難，因為有關用於訓練 Sora 的模型大小和資料集的詳細資訊非常少。因此，需要注意的是，本節中的估算結果具有很大的不確定性，因此應謹慎對待。
根據 DiT 估算 Sora 的訓練計算量
關於 Sora 的詳細資料非常少，透過再次檢視 DiT 論文（這篇論文顯然是 Sora 的基礎），也可以根據其中提供的計算數字進行推斷。最大的 DiT 模型 DiT-XL 有 675M 個引數，訓練時的總計算預算約為 10^21 FLOPS。這相當於約 0.4 臺 Nvidia H100 使用 1 個月（或一臺 H100 使用 12 天）。
現在，DiT 只是影像模型，而 Sora 是影片模型。Sora 可以生成長達 1 分鐘的影片。如果我們假設影片是以 24fps 的速度編碼的，那麼一段影片最多由 1,440 幀組成。Sora 的畫素到潛在空間對映似乎在空間和時間上都進行了壓縮。如果假定採用 DiT 論文中相同的壓縮率（8 倍），那麼在潛空間中將有 180 幀。因此，當簡單地將 DiT 推廣到影片時，得到的計算倍率是 DiT 的 180 倍。
本文還認為，Sora 的引數要比 675M 大得多。本文作者估計至少得有 20B 的引數，所需計算量是 DiT 的 30 倍。
最後，本文認為 Sora 的訓練資料集比 DiT 大得多。DiT 在 batch 大小為 256 的情況下進行了三百萬次訓練，即在總計 7.68 億張圖片上進行了訓練（請注意，由於 ImageNet 僅包含 1,400 萬張圖片，因此相同的資料被重複了很多次）。Sora 似乎是在混合影像和影片的基礎上進行訓練的，除此之外，我們對該資料集幾乎一無所知。因此，本文做了一個簡單的假設，即 Sora 的資料集 50% 是靜態影像，50% 是影片，而且資料集是 DiT 使用的資料集的 10 倍到 100 倍。然而，DiT 在相同的資料點上反覆訓練，如果有更大的資料集，可能效能還會更好。因此，本文認為 4-10 倍的計算倍率的假設是更合理的。
綜上所述，考慮到額外資料集計算的低倍估算值和高倍估算值，本文得出以下計算結果：
低倍資料集估計值：10^21 FLOPS × 30 × 4 × (180 / 2) ≈ 1.1x10^25 FLOPS
高倍資料集估計值：10^21 FLOPS × 30 × 10 × (180 / 2) ≈ 2.7x10^25 FLOPS
這相當於使用 1 個月的 4,211 - 10,528 臺 Nvidia H100 進行訓練。
推理與訓練計算的比較
我們往往會考慮的另一個重要因素是訓練計算與推理計算的比較。從概念上講，訓練計算量非常大，但也是一次性成本，只產生一次。相比之下，推理計算量要小得多，但每次使用都會產生。因此，推理計算會隨著使用者數量的增加而增加，並且隨著模型的廣泛使用而變得越來越重要。
因此，研究「平衡點」是非常有用的，即推理所耗費的計算量大於訓練所耗費的計算量。
DiT （左）和 Sora （右）的訓練與推理計算結果對比。對於 Sora，本文的資料基於上一節的估計，因此並不完全可靠。這裡還顯示了訓練計算的兩種估計值：一種是低估計值（假設資料集大小為 4 倍乘數），另一種是高估計值（假設資料集大小為 10 倍乘數）。
本文再次使用了 DiT 來推斷 Sora。對於 DiT，最大的模型（DiT-XL）每步使用 524×10^9 FLOPS，DiT 使用 250 個擴散步驟生成單幅影像，總計 131×10^12 FLOPS。我們可以看到，在生成 760 萬張影像後達到了平衡點，之後推理計算佔據了主導地位。作為參考，使用者每天在 Instagram 上傳大約 9500 萬張圖片（資料來源）。
對於 Sora，本文推斷 FLOPS 約為：524×10^9 FLOPS × 30 × 180 ≈ 2.8×10^15 FLOPS.。如果仍然假設每段影片經歷 250 次擴散步驟，那麼每段影片的 FLOPS 總量就是 708×10^15。在生成 1530 萬至 3810 萬分鐘的影片後，就會達到平衡點，此時所花費的推理計算量將超過訓練計算量。作為參考，每天約有 4,300 萬分鐘的影片上傳到 YouTube。
需要注意的是，對於推理而言，FLOPS 並不是唯一重要的因素。例如，記憶體頻寬是另一個重要因素。此外，關於如何減少擴散步驟的數量的研究，可能會大大降低計算密集度，從而加快推理速度。FLOPS 利用率在訓練和推理之間也會有所不同，在這種情況下，也需要考慮。
不同模型的推理計算比較
本文還對不同模型在不同模式下每單位輸出的推理計算量是如何表現的進行了研究。這樣做的目的是為了瞭解不同類別模型的推理計算密集程度，這對計算規劃和需求有直接影響。需要強調的是，每個模型的輸出單位都會發生變化，因為它們是在不同的模式下執行的：對於 Sora，單次輸出是一段 1 分鐘長的影片；對於 DiT，單次輸出是一張 512x512px 的圖片；而對於 Llama 2 和 GPT-4，單個輸出被定義為包含 1,000 個 token 的文字的單個文件。
各模型每單位輸出的推理計算量比較（Sora 為 1 分鐘影片，GPT-4 和 LLama 為 21000 個文字 token，DiT 為一張 512x512px 的圖片）。可以看到，本文估計 Sora 的推理計算成本要高出幾個數量級。
本文比較了 Sora、DiT-XL、LLama 2 70B 和 GPT-4，並繪製了它們之間的對比圖（使用 FLOPS 的對數標度）。對於 Sora 和 DiT，本文使用了上文的推理估計值。對於 Llama 2 和 GPT-4，本文使用「FLOPS = 2 × 引數數量 × 生成的 token 數」這一經驗公式估算 FLOPS 數。對於 GPT-4，本文假設該模型是一個專家混合（MoE）模型，每個專家有 220B 個引數，每個前向傳遞中有 2 個專家處於活動狀態。不過對於 GPT-4，這些數字並未得到 OpenAI 的確認，因此仍需謹慎對待。
可以看到，像 DiT 和 Sora 這樣基於擴散的模型的推理成本要高得多：DiT-XL（一個擁有 675M 引數的模型）與 LLama 2（一個擁有 70B 引數的模型）消耗的推理計算量大致相同。我們還可以看到，在推理工作負載方面，Sora 甚至比 GPT-4 更昂貴。
需要再次指出的是，上述許多資料都是估算值，依賴於簡化的假設，沒有考慮到 GPU 的實際 FLOPS 利用率、記憶體容量和記憶體頻寬的限制以及推測解碼等高階技術。
類 sora 模型獲得顯著的市場份額之後所需的推理計算量
本節根據 Sora 的計算需求推斷出了需要多少臺 Nvidia H100 才能大規模執行類似 Sora 的模型，這意味著人工智慧生成的影片已經在 TikTok 和 YouTube 等流行影片平臺上實現顯著的市場滲透。
假設每臺 Nvidia H100 每小時製作 5 分鐘影片（詳見上文），換言之每臺 H100 每天製作 120 分鐘影片。
TikTok ：假設人工智慧的滲透率為 50%，則每天的影片時長為 1700 萬分鍾（影片總數為 3400 萬 × 平均時長為 30s）
YouTube ：每天 4300 萬分鍾影片，假設人工智慧的滲透率為 15%（大部分為 2 分鐘以下的影片）
人工智慧每天製作的影片總量：850 萬 + 650 萬 = 1 070 萬分鍾
支援 TikTok 和 YouTube 上的創作者社群所需的 Nvidia H100 總量：1,070 萬 / 120 ≈ 89000
再基於以下各種因素考慮，這一數字可能有些保守：
假設 FLOPS 的利用率為 100%，並且沒有考慮記憶體和通訊瓶頸。實際上，50% 的利用率更符合實際情況，即增加 1 倍。
需求在時間上不是平均分佈的，而是突發的。高峰需求尤其成問題，因為你需要更多的 GPU 才能滿足所有流量的需求。本文認為，高峰需求會使所需 GPU 的最大數量再增加 1 倍。
創作者可能會生成多個候選影片，然後從這些候選影片中選出最佳影片。我們做了一個保守的假設，即平均每個上傳的影片會生成 2 個候選影片，這又增加了 1 倍。
在峰值時，總共需要大約 720000 塊 Nvidia H100 GPU
這表明，隨著生成式人工智慧模型變得越來越流行且實用，推理計算將佔主導地位。對於像 Sora 這樣的基於擴散的模型，更是如此。
還需要注意的是，擴充套件模型將進一步大大增加推理計算的需求。另一方面，其中一些問題可以透過更最佳化的推理技術和跨堆疊的其他最佳化方法來解決。
影片內容的創意驅動了對 OpenAI 的 Sora 等模型最直接的需求。
原文連結：https://www.factorialfunds.com/blog/under-the-hood-how-openai-s-sora-model-works?continueFlag=8d0858264bc384419d2c0c1cfdc7d065