Checkpoint

3秒看懂

Checkpoint（檢查點）在深度學習中有兩種緊密相關但目標不同的含義：

1. 訓練快照（Training Snapshot）：週期性將模型引數、最佳化器狀態、學習率排程器和隨機數狀態等完整訓練狀態儲存至持久化儲存。訓練中斷或硬體故障後可從最近快照精確恢復，也可用於實驗分支回滾。
2. 啟用檢查點（Gradient / Activation Checkpointing）：一種以計算時間換取視訊記憶體空間的最佳化技術。前向傳播時僅保留部分關鍵啟用，丟棄中間啟用，反向傳播時根據保留的輸入動態重算被丟棄的啟用，大幅降低峰值視訊記憶體佔用，使得在有限的 GPU 視訊記憶體上訓練更大型模型或使用更大的 micro batch size 成為可能。

3分鐘產業解釋

在大型模型競爭白熱化的背景下，Checkpoint 被賦予雙重的工程與戰略價值：

• 可靠性基石：數千張 GPU 叢集連續訓練數週至數月，硬體故障、節點掉線、程序崩潰近乎是必然事件。訓練快照是唯一有效的“保險”——每 N 步儲存一次完整狀態，使價值數十萬甚至數百萬美元的算力投入不至於因一次機架掉電而清零。同時，雲端上訓練大量採用可搶佔例項，定期快照讓“中斷-恢復”成為標準化運營流水線。
• 視訊記憶體槓桿：GPU 視訊記憶體容量增速（近年來約 2 年翻倍）遠落後於模型引數膨脹速度（約每年 5–10 倍）。啟用檢查點通過將視訊記憶體壓力轉換為可控的額外計算（通常 20%–40% 的單步時間增加），使訓練 GPT-4、Llama 3、Gemma 等數百億至數千億引數模型成為可能。它已從一個選題性技巧演變為所有主流訓練棧的“預設開啟”基礎能力。

產業實踐中，兩類 Checkpoint 往往同時配置：訓練快照保障訓練的物理連續性，啟用檢查點保障視訊記憶體邊界內的數學可行性。PyTorch、TensorFlow 等架構與 DeepSpeed、Megatron-LM 等分散式訓練庫已將它們深度融合，使用者僅需配置若干引數即可啟用。雲端廠商（AWS、Azure、GCP）則圍繞檢查點提供高吞吐物件儲存、並行檔案系統和託管訓練服務，進一步降低門檻。

技術原理

訓練快照檢查點

儲存內容
一個能完整恢復訓練的快照通常包含：

• 模型引數（權重、偏置，即 state_dict）；
• 最佳化器狀態（如 Adam 的一階動量與二階動量，其體積可達模型引數的 2 倍）；
• 學習率排程器狀態；
• 隨機數生成器狀態（保證資料載入與 dropout 模式的可復現性）；
• 訓練元資訊（步數、epoch、資料迭代器位置或資料集的確定性隨機種子）。

儲存時機與策略

• 按步間隔儲存：每 100 或 1000 步儲存一次，適配上萬個訓練步數。
• 按時間間隔儲存：適合訓練時長高度不確定的場景。
• 滾動保留：維持最近 K 個檢查點，平衡儲存開銷與恢復精度；舊檢查點按策略刪除或移動到冷儲存。

恢復機制
從快照重新建置模型與最佳化器物件，載入上述全部狀態；若採用確定性資料載入（如固定的全域性隨機種子 + 按步數同步的資料讀取器），訓練可從斷點精確延續，如同從未中斷。

分散式場景的一致性保障

• 資料並行：每個 rank 擁有完整模型副本，通常僅 rank 0 執行儲存（簡單但存在單點寫入頻寬瓶頸），或各 rank 寫入分片狀態。
• 模型並行（張量並行、流水線並行）：模型狀態在多個裝置上切分存放。儲存時需並行收集所有分片，並按協商一致的分片方案寫入；恢復時反向分發。Megatron-LM 和 DeepSpeed 均實現分散式檢查點讀寫器，通過 NCCL 集合通訊或並行 I/O 完成高效聚合和分發。大叢集中常採用多節點併發寫入分散式檔案系統，以避免單節點 I/O 成為瓶頸。

啟用檢查點（Gradient Checkpointing）

問題來源
經典反向傳播要求前向過程中產生的所有啟用張量駐留於視訊記憶體，直至對應反向計算完成。對於 Transformer 模型，啟用視訊記憶體佔用與層數、序列長度、隱藏維度和 batch size 成正比，極易成為瓶頸。

核心原理
將網路分割為若干“檢查點段”（如一個 Transformer Block）。前向傳播時，僅在段邊界保留輸入張量，段內所有中間啟用計算後立即釋放。當反向傳播到達該段時，利用儲存的段輸入重新執行一次段的前向計算，重新獲得段內啟用後完成梯度計算。這相當於用額外一段完整的前向計算換取段內全部啟用的視訊記憶體釋放。

在典型配置下，啟用視訊記憶體可由與層數線性相關降低至與段數線性相關（通常為常數或平方根級別），視訊記憶體節省顯著。額外計算量約為一次完整前向，總訓練時間增加大致在 20%–40%，具體取決於前向計算與反向計算的耗時比例以及重算段落的選擇（參考：Chen 等 2016 年原論文及後續社群實踐經驗總結）。

選擇性重計算
為控制額外開銷，實現中通常只對視訊記憶體壓力最大的部分網路段做檢查點（如 Transformer 層本身），而對計算量大但視訊記憶體消耗小的操作（如注意力矩陣乘法）保留完整啟用。PyTorch 的 torch.utils.checkpoint 允許使用者單獨標記檢查點分段；DeepSpeed 的 Activation Checkpointing 支援自動或手選層配置，配合模型並行在流水線氣泡中隱藏部分重計算開銷。

關鍵引數

• 檢查點體積（Checkpoint Size）
  單次儲存的儲存量，受模型引數量、最佳化器狀態和精度影響。舉例：一個 175B 引數的 GPT-3 類模型，若採用 Adam 最佳化器與 FP16 混合精度訓練（引數 FP16，最佳化器狀態 FP32），單一全域性檢查點體積約為 2.8 TB（引數 350 GB + 最佳化器約 700 GB × 2 + 其他狀態，參考社群估算；具體數字因並行策略和分片方式變化）。萬億引數模型單檢查點體積可達數十 TB 級別。

• 儲存/恢復吞吐（Save/Restore Throughput）
  持續寫入/讀取檢查點的速度，以 GB/s 或 TB/min 計。例如，在 NVIDIA DGX SuperPOD 中，通過多節點並行寫入 Lustre 檔案系統，實測聚合寫入吞吐可超過 100 GB/s（NVIDIA 白皮書，2023 年）。該指標直接決定檢查點儲存間隔下限和恢復時間。

• 恢復時間目標（Recovery Time Objective, RTO）
  從故障發生到訓練完全恢復至故障前步數所需牆鍾時間，包含讀取檢查點、重建分散式狀態、重放資料等。萬卡叢集中，單個大型模型檢查點的載入可能需要數分鐘至數十分鐘。RTO 越短，有效訓練時間佔比越高。

• 視訊記憶體節省率（Memory Saving Ratio）
  啟用檢查點開啟後峰值視訊記憶體的下降比例，通常以“× 倍”表達。例如，開啟 Transformer 層粒度的啟用檢查點可使啟用視訊記憶體降低約 80%–90%（具體取決於隱藏維度與序列長度組合）。PyTorch 文件中記載，開啟檢查點後模型所需視訊記憶體可縮減至原來的 1/√L 或更低。

• 額外計算開銷（Recomputation Overhead）
  啟用重計算導致的總訓練時間增加比例。典型區間為 15%–40%。通過選擇性檢查點和與流水線排程協同，DeepSpeed 等架構可將開銷控制在 20% 左右（DeepSpeed 文件，2024 年版本）。

• 檢查點保真度（Checkpoint Fidelity）
  確保儲存過程中的狀態是確定的、可完全復現的，分散式環境下無競態導致的狀態不一致。通常通過全域性 barrier 同步和確定的集合通訊順序來保障。

• 儲存成本佔比
  大規模訓練中，檢查點佔據的儲存空間可能遠大於資料集本身。例如，訓練一個千億引數模型期間保留 10 個滾動檢查點，總儲存需求可達數十 TB 到百 TB 級。對雲端儲存費用影響顯著，也成為架構設計需考慮的變數。

上述體積與吞吐數值因並行策略（資料並行、張量並行、流水線並行、ZeRO 分片等級）、硬體（NVMe、InfiniBand 網絡卡、GPU 視訊記憶體）和資料型別而異，實際專案應以實測為準。

技術路線

演化脈絡

• 2016 年以前：訓練快照作為基礎容錯手段，主要依靠架構提供簡單的 save/load API，解決 GPU 叢集故障率增高下的訓練可恢復性。
• 2016 年：Chen 等人發表《Training Deep Nets with Sublinear Memory Cost》，首次系統化提出啟用重計算，論證可將視訊記憶體消耗由線性降至亞線性，為極深網路的訓練開啟新可能。
• 2017–2019 年：PyTorch 和 TensorFlow 內建啟用檢查點介面；Horovod 等推出更高效的分散式儲存；分散式訓練社群開始形成“按步儲存 + 滾動保留”的最佳實踐。
• 2020–2022 年：大型模型元年。DeepSpeed 推出 ZeRO 狀態分割槽，並與啟用檢查點深度耦合，大幅降低巨模型訓練視訊記憶體門檻；Megatron-LM 實現張量並行/流水線並行下的分散式檢查點讀寫器；各大雲端廠商儲存閘道器支援並行寫入。
• 2023 年至今：針對 MoE（混合專家）模型、動態網路的選擇性檢查點策略成為熱點；非同步檢查點寫入技術出現（在訓練主迴圈不阻塞的情況下將狀態複製到 CPU 記憶體後非同步刷盤），減少儲存暫停時間；萬億引數模型推動分層次、分片壓縮的檢查點方案研究。

主流方案對比

維度	訓練快照檢查點	啟用檢查點
主要目標	容錯恢復、實驗回溯、模型交付	降低訓練峰值視訊記憶體
儲存內容	模型/最佳化器/排程器/隨機狀態等全套	僅段邊界輸入張量
儲存/IO 開銷	大（每檢查點數 GB~數十 TB）	極小（少量張量，通常 KB~MB）
計算開銷	可忽略（僅序列化和 I/O 耗時）	顯著（額外前向重算，總時間增加 15%–40%）
啟用方式	按步/按時觸發	始終啟用，作用於指定模組
能否獨立恢復訓練	可精確恢復	不能，僅影響啟用管理
代表性實現	PyTorch torch.save、Lightning Checkpoint	PyTorch checkpoint_sequential、DeepSpeed Activation Checkpointing
分散式相容性	需要並行儲存與恢復邏輯	與模型並行協同設計，需考慮重算與通訊重疊

上游

Checkpoint 的效能高度依賴底層硬體與系統棧：

• GPU 視訊記憶體與算力：啟用檢查點的重計算增加了計算總量，對 GPU 浮點算力提出更高要求；同時，檢查點段的選擇需要精確匹配視訊記憶體頻寬和容量，不同 GPU 微架構（A100/H100/B200）上的最優策略可能不同。
• 儲存系統：訓練快照要求高突發順序寫入頻寬和低延遲後設資料操作。常用方案包括高階並行檔案系統（如 Lustre、GPFS）、NVMe over Fabrics（NVMe-oF）和雲端原生的高吞吐物件儲存（AWS S3 Express One Zone、Azure Blob Hot）。儲存系統的寫入緩衝能力、讀映象分發會直接決定 RTO。實踐中，多節點併發寫入時小檔案隨機後設資料操作可能成為瓶頸，推動面向檢查點最佳化的非同步寫入聚合中介軟體的發展（如 Facebook 內部使用的 Tectonic 檔案系統定製修改，據 Meta 工程部落格）。
• 網路互連：分散式檢查點需要多節點並行寫入，集合通訊（NCCL）和並行 I/O 生成的網路負載非常可觀。高頻寬低延遲網路（如 InfiniBand HDR/NDR、RoCE v2）是維持檢查點吞吐的必備條件。萬卡叢集中，檢查點儲存會產生瞬時的全交換資料流，網路擁塞控制方案影響儲存完成時間。
• CPU 記憶體與系統匯流排：非同步檢查點方案需先將狀態複製到 CPU 記憶體，而後非同步寫入磁碟，因此 CPU-DRAM 容量和 PCIe/NVLink 頻寬成為緩衝瓶頸。極大規模下可能需使用 CPU 記憶體池或 NVDIMM 作為寫緩衝。

下游

• 大規模預訓練：千卡/萬卡叢集上持續數月的訓練，完全依賴定期檢查點實現“無限長時間執行”。Llama 3 的訓練就使用了密集的檢查點策略以確保在多重故障下依然可持續（Meta 公開 blog，2024 年）。
• 故障恢復與彈性訓練：雲端上可搶佔例項、電網波動、裝置維護等場景中，檢查點實現分鐘級恢復，使訓練任務具備雲端原生的彈性；配合 Kubernetes Job 或 SLURM 的自動重啟，實現訓練自動化。
• 實驗管理：從不同檢查點啟動多分支實驗（如微調、RLHF、資料配比消融），大幅加速研發迭代。Hugging Face Hub 等模型倉庫中，多數模型以檢查點形態分發，供社群自由續訓或微調。
• 模型交付：最終檢查點常作為模型發行的標準格式。提供者可能同時釋出原始訓練快照（含最佳化器狀態）和僅推論權重的輕量檢查點，用於下游部署。
• 知識蒸餾與剪枝：蒸餾、量化感知訓練、結構化剪枝等工作通常從特定檢查點起始，以保證可比性與復現性。

受益公司

• Meta（PyTorch）：PyTorch 核心維護了 torch.utils.checkpoint 及相關分散式儲存 API，其技術路線極大影響了業界檢查點實踐。Meta 自身在大規模訓練中積累的檢查點方案通過開源反哺社群，鞏固了架構地位。
• 微軟（DeepSpeed / Azure）：DeepSpeed 將 ZeRO 狀態分片與啟用檢查點深度融合，降低了超大型模型訓練門檻，並天然引導使用者使用 Azure 雲端服務實現協同最佳化。DeepSpeed 的檢查點方案已成為多數 GPT 類模型訓練棧的標配元件。
• NVIDIA（Megatron-LM / NeMo / DGX 系統）：NVIDIA 提供從晶片（H100/B200）到系統（DGX SuperPOD）到軟體（Megatron-LM、NeMo）的全棧檢查點最佳化，尤其是並行檔案系統與網路配置的緊密整合，使其在高階訓練叢集市場佔據主導。
• Hugging Face：通過 transformers 庫統一了預訓練模型的檢查點儲存/載入介面，並運營業界最大的模型檢查點託管平台，掌握重要的分發節點地位。
• 雲端基礎設施廠商（AWS、GCP、CoreWeave 等）：提供高效能儲存與網路，決定檢查點 I/O 上限；其託管訓練服務（如 Amazon SageMaker、GCP Vertex AI）均內建檢查點策略，對使用者透明。
• 新興訓練架構企業（ColossalAI、MosaicML/Databricks 等）：通過創新的非同步檢查點、梯度累積感知檢查點等差異化特性爭奪市場關注，部分已被大廠整合（如 MosaicML 被 Databricks 收購）。

以上僅列舉公開資訊中與 Checkpoint 技術棧直接相關的公司，不構成任何投資評價。

市場規模

直接統計缺失
截至 2024 年 7 月，尚無第三方機構釋出以“Checkpoint 軟體/服務”為獨立品類的市場規模報告。Checkpoint 屬於深度學習訓練基礎設施中的一項橫向能力，其商業價值隱含在架構、雲端服務和儲存硬體中，公開資料未見拆分資料。

參考關聯市場

• 整體 AI 基礎設施市場：根據 IDC 2024 年初發布的《Worldwide AI Infrastructure Tracker》，2023 年全球 AI 伺服器與儲存支出約 326 億美元，預計 2027 年將超過 520 億美元。與檢查點直接相關的高吞吐並行檔案系統和物件儲存在該市場中佔據重要份額，但具體比例未單獨揭露。
• HPC 儲存市場：Hyperion Research 2023 年報告指出，全球 HPC 儲存（含 AI 訓練）市場約 75 億美元，特別是支援高速突發寫入的並行檔案系統與 NVMe-oF 方案增速超過 20%。
• 雲端儲存消費：大規模訓練專案中，檢查點儲存費用可佔訓練總雲端成本的 5%–15%（根據各雲端廠商公開案例估算，如 Azure 部落格 2023 年某客戶案例）。隨著模型引數增長，檢查點相關儲存消費的絕對額與相對比例預計將繼續上升。

以上關聯市場資料取自第三方公開報告，口徑與具體數字請查閱原報告。

玩家對比

解決方案	訓練快照能力	啟用檢查點策略	分散式最佳化亮點	社群/生態
PyTorch 原生	torch.save、支援 FSDP 分片儲存	torch.utils.checkpoint 選擇性包裝	與 DDP/FSDP 深度整合，但高階並行需手配	最廣泛的模型實現依託，生態最大
DeepSpeed	提供 ZeRO 1/2/3 的分片檢查點，支援非同步寫入	自動或手動按層配置，可與流水線氣泡重疊	ZeRO 狀態下僅儲存/載入分片，節省記憶體與 I/O；CPU/NVMe 解除安裝	大量開源大型模型訓練採用，由微軟維護
Megatron-LM（NVIDIA NeMo）	張量/流水線並行下分散式檢查點讀寫器	提供與模型並行模式繫結的啟用重算	分散式檢查點寫入器高度最佳化，針對 NVIDIA 硬體/網路調優	NVIDIA 內部預訓練首選，社群有部分複用
Hugging Face Transformers	統一的 save_pretrained/from_pretrained	依賴 PyTorch 或 DeepSpeed 外掛轉發	主要關注模型交付與微調場景，對分散式寫入支援有限	最大型模型分發平台，下游應用豐富
ColossalAI	支援多維並行分片檢查點，非同步寫入	提供靈活的啟用檢查點定製	將檢查點與自動並行化結合，降低使用者感知	新興，社群增速較快
JAX/Flax 生態	基於 Orbax 提供非同步檢查點	jax.checkpoint（原 jax.remat）	支援多主機多裝置檢查點，與 TPU 訓練緊密配合	主要由 Google 及 TPU 使用者使用

功能狀態均基於對應專案截至 2024 年 7 月公開文件與程式碼倉庫資訊。

風險

• 技術瓶頸風險：萬億引數級模型的單檢查點體積可達數十 TB，當前最先進的並行檔案系統在未作專門最佳化的情況下也可能觸達寫吞吐天花板；恢復時間可能長至小時級別，影響有效訓練時間。雖然研究層面不斷探索檢查點壓縮、增量儲存等方法，但尚未成為工業界主流，存在過渡期瓶頸。
• 異構算力適配風險：GPU + AI 晶片（如 TPU、NPU）混合訓練或跨叢集訓練時，不同晶片架構之間的檢查點格式、運算元確定性重算行為不一致，可能產生狀態恢復錯誤或額外轉換開銷，增加工程複雜性。
• 安全與合規風險：檢查點含完整可復現的訓練狀態，包括模型權重、最佳化器狀態、資料取樣狀態等。一旦洩露，攻擊者可重建模型甚至推斷訓練資料分佈。同時，某些行業（如金融、醫療）的合規要求可能對檢查點的保留和傳輸施加限制，涉及資料駐留和加密傳輸等成本。
• 成熟度與創新空間：檢查點技術整體已趨於成熟，架構層面的顛覆式創新空間有限，這可能導致部分創業公司難以實現差異化壁壘。然而與 MoE、動態架構、線上學習等新範式的結合仍存在未充分解決的技術點，成為潛在的不確定性來源。
• 儲存成本失控風險：滾動保留多個檢查點產生的儲存費用隨模型規模與專案數量指數增長，如果缺乏精細化的生命週期管理策略（如自動冷熱分層、增量差異儲存），儲存成本可能侵蝕訓練總預算，尤其對於長期執行的自監督訓練專案。

誤讀糾偏

• 誤讀：“檢查點就是模型最終權重檔案”
  糾正：僅儲存模型權重（如 model.pt）不包含最佳化器狀態等，無法實現精確恢復訓練。如果從純權重檔案繼續訓練，最佳化器將從零初始化，改變訓練動力學，導致收斂路徑漂移。用於恢復訓練的檢查點必須儲存完整訓練狀態。

• 誤讀：“啟用檢查點一定會加速訓練”
  糾正：啟用檢查點本質是視訊記憶體最佳化技術，通過釋放視訊記憶體允許增大 batch size，可能間接提高吞吐（更高 GPU 利用率）。但若視訊記憶體本非瓶頸，重計算只會單純延長單步時間，降低訓練速度。是否“加速”取決於視訊記憶體約束是否為系統主要瓶頸。

• 誤讀：“啟用檢查點適用於所有模型”
  糾正：該技術要求模型可分段且重算具有確定性。涉及不可逆隨機操作（如某些動態 dropout 或依賴全域性狀態的層）時，重算可能產生不同結果，導致梯度誤差。通常需配合固定隨機種子和可控的隨機遮擋。

• 誤讀：“儲存越頻繁越好”
  糾正：過於頻繁的檢查點儲存會消耗大量 I/O 頻寬和儲存空間，拖累訓練主迴圈。在大規模叢集中，一次全量檢查點儲存的耗時可達到數分鐘甚至更高，若儲存頻率超過合理閾值，有效訓練時間佔比會顯著下降。需根據模型規模、叢集故障率（MTBF）和 RTO 綜合確定最優間隔。

最新事件

• 2024 年 4 月：Meta 釋出 Llama 3 模型，其訓練流程中大量運用 PyTorch FSDP + 檢查點技術，並在公開工程部落格中提及長期訓練中的故障恢復策略與檢查點頻率配置經驗（Meta AI Blog，2024 年 4 月）。
• 2024 年 6 月：DeepSpeed 釋出 0.14.x 版本，增強非同步檢查點（Asynchronous Checkpointing）支援，允許在訓練步不阻塞的情況下完成狀態持久化，據專案釋出說明，可將檢查點 IO 開銷隱藏超過 90%。
• 2024 年上半年：PyTorch 2.3 版本改進了 torch.utils.checkpoint 與 compile 的相容性，並增加了對選擇性啟用重計算的更好支援；同時社群提出用於 FSDP 的更高效的分片檢查點合併方案。
• 2024 年：NVIDIA 在其 NeMo 架構中整合面向 MoE 架構的最佳化檢查點方案，可減少 expert 引數分片的儲存冗餘；多家雲端廠商釋出增強型並行檔案系統例項，以應對萬卡叢集突發寫入需求（如 AWS 推出 FSx for Lustre 高吞吐例項）。
• 公開報告：部分研究機構開始釋出千億-萬億引數模型訓練的檢查點 IO 基準測試（如 MLPerf 基準的儲存相關指標），推動行業內標準化的比較。

以上事件均來源於相應專案官方公告、技術部落格或公開報告，截至 2024 年 7 月。

追蹤指標

若需持續把握 Checkpoint 領域的技術與產業動態，建議關注以下量化指標與訊號：

1. 最大公開單檢查點體積：觀測公開報告或論文中使用的檢查點大小，反映引數規模增速對儲存系統的衝擊。
2. 主流架構檢查點寫入吞吐基準：例如在 MLPerf、社群基準中出現的 GB/s 寫入速度，反映儲存棧與架構協同的進步。
3. 典型 RTO 改善曲線：關注雲端廠商與系統廠商公佈的恢復時間目標，衡量彈性訓練能力的提升。
4. 啟用檢查點節省率與額外開銷的最新資料：不同模型架構下的實測值，可判斷技術效益是否飽和。
5. 新並行策略（如 MoE、專家並行）下的檢查點方案成熟度：是否出現針對新架構的專用檢查點庫或論文。
6. 非同步與增量檢查點的生產採用度：主流訓練架構 Release Note 中是否新增相關特性，以及開源大型模型訓練程式碼中是否啟用。
7. 儲存硬體路線圖：PCIe 6.0、CXL 記憶體共享、NVIDIA Spectrum-X 等新型互連與儲存介質對檢查點 I/O 頻寬的潛在推動作用。
8. 訓練故障率與叢集規模關係：Meta、Google 等釋出的故障統計資料，可評估檢查點頻率設定的經濟區間。

信源

• PyTorch 官方文件：torch.save 與 torch.utils.checkpoint 章節
• Chen, Tianqi, et al. “Training Deep Nets with Sublinear Memory Cost.” arXiv 1604.06174, 2016.
• DeepSpeed 文件：Activation Checkpointing 與 ZeRO Checkpoint 部分
• Megatron-LM GitHub 倉庫：分散式檢查點設計與實現文件
• Hugging Face Transformers 文件：模型儲存與載入
• NVIDIA NeMo 架構文件：檢查點與恢復
• Meta AI Blog, “How Meta Trains Large Language Models at Scale,” 2024.
• IDC, “Worldwide AI Infrastructure Tracker, 2023–2027,” 2024.
• Hyperion Research, “HPC Storage Market Update,” 2023.
• 各雲端廠商官方部落格與技術白皮書（AWS、Azure、GCP 訓練儲存最佳實踐）
• MLPerf Storage Benchmark 相關白皮書與公開結果

注：所有技術引數、效能數字請以對應架構和硬體的官方文件及最新論文為準；市場數字引自第三方研究機構，僅用於說明行業規模量級，不構成任何投資評價。