AI 工程從零開始｜Phase 10 Part 2：LLM 預訓練 — 萬億 Token 的工程挑戰

June 21, 2026 • 23 min read • Yen

AI LLM Pretraining Scaling Laws Distributed Training Data Pipeline RKK Interview

大多數人以為預訓練只是「把資料丟進去跑就好」。 現實是：70% 的工時花在資料清洗，20% 花在除錯 Loss Spike， 只有 10% 是真正的訓練時間。 預訓練是 LLM 工程中最貴、最脆弱、也最決定性的一步。

面試情境： 假設你是某 AI 新創的基礎架構工程師，團隊計畫訓練一個 7B 參數的 LLM，預算 $500K，目標是在 3 個月內完成預訓練。請說明你會如何規劃資料管線、選擇分散式訓練策略，以及如何監控並從 Loss Spike 中恢復？

一、核心問題：預訓練為什麼是 LLM 最貴的一步

預訓練（Pretraining）是 LLM 生命週期中的「原始碼編譯」——一旦做錯，後續的 Fine-tuning、RLHF、RAG 全都是在一個有缺陷的基礎上打補丁。

成本規模感：

模型	參數量	訓練 Token	GPU 小時	估計成本
GPT-3	175B	300B	~3.5M A100 小時	~$4.6M
LLaMA-2 7B	7B	2T	~180K A100 小時	~$240K
LLaMA-2 70B	70B	2T	~1.7M A100 小時	~$2.3M
Mistral 7B	7B	1T	~120K A100 小時	~$160K

一次「失敗的」預訓練跑到 80% 才發現資料有問題，等於直接燒掉 $100K–$3.6M。

預訓練的三大工程挑戰：

資料品質：網路爬取資料中 40–60% 是低品質或有害內容，清洗管線的設計直接決定模型能力上限。
計算效率：單張 A100 理論算力 312 TFLOPS，實際 MFU（Model FLOP Utilization）能達到 40–50% 已是優秀，差的設定可能低於 20%。
訓練穩定性：在數萬步的訓練中，Loss Spike 平均每 5K–20K 步出現一次，每次恢復需要回退並調整，成本極高。

二、三個演進階段（POC / MVP / Scale）

Phase 1：POC（< 1B 參數，< 100B Token）

目標： 驗證資料管線與訓練腳本可運行，不追求 SOTA。

┌─────────────────────────────────────────────────────┐
│  Phase 1：POC 預訓練架構                             │
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│  │ 原始資料  │───▶│ 簡單清洗  │───▶│  Tokenizer   │  │
│  │ 10–50GB  │    │ 規則過濾  │    │  (BPE/SP)    │  │
│  └──────────┘    └──────────┘    └──────┬───────┘  │
│                                          │           │
│                                          ▼           │
│  ┌───────────────────────────────────────────────┐  │
│  │  單機多卡訓練（4–8 × A100）                    │  │
│  │  DDP（Data Parallel）                         │  │
│  │  Batch Size: 512–1024                         │  │
│  └───────────────────────┬───────────────────────┘  │
│                           │                          │
│                           ▼                          │
│  ┌─────────────────────────────────────────────┐    │
│  │  WandB / TensorBoard 監控 Loss              │    │
│  │  每 1K 步儲存一個 Checkpoint                 │    │
│  └─────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘

Phase 1 關鍵參數：

模型規模：125M–1B 參數
資料量：10–100B Token
硬體：1–2 節點，4–8 × A100 80GB
訓練時間：3–14 天
成本：$5K–$30K
MFU 目標：> 30%（低標，主要驗證流程正確性）

可接受的妥協：

資料去重不完整（模糊去重即可）
無自動 Loss Spike 恢復
Checkpoint 頻率低（每 1K 步）

Phase 2：MVP（1B–13B 參數，1T Token）

目標： 生產級訓練，團隊可持續運行而不需要 24/7 人工監控。

┌──────────────────────────────────────────────────────────┐
│  Phase 2：MVP 預訓練架構                                  │
│                                                          │
│  資料管線（多來源）                                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │Common    │  │ GitHub   │  │ Books /  │              │
│  │Crawl     │  │ Code     │  │ Papers   │              │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘              │
│       └─────────────┴─────────────┘                      │
│                      │                                    │
│                      ▼                                    │
│  ┌────────────────────────────────────────────────────┐  │
│  │  清洗管線（Apache Spark / Ray Data）               │  │
│  │  語言識別 → 品質過濾 → 去重（MinHash LSH）         │  │
│  │  毒性過濾 → 個資移除 → 格式標準化                  │  │
│  └────────────────────────┬───────────────────────────┘  │
│                            │                              │
│                            ▼                              │
│  ┌────────────────────────────────────────────────────┐  │
│  │  分散式訓練叢集（8–32 節點）                        │  │
│  │  DP（Data Parallel）+ TP（Tensor Parallel）        │  │
│  │  ZeRO Stage 2                                      │  │
│  │  Global Batch Size: 4M–8M Token                    │  │
│  └────────────────────────┬───────────────────────────┘  │
│                            │                              │
│                            ▼                              │
│  ┌───────────────────┐  ┌──────────────────────────────┐ │
│  │  自動 Checkpoint   │  │  Loss Spike 自動偵測 + 告警  │ │
│  │  每 500 步一次     │  │  Prometheus + PagerDuty      │ │
│  └───────────────────┘  └──────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘

Phase 2 關鍵參數：

模型規模：1B–13B 參數
資料量：500B–2T Token
硬體：8–32 節點，64–256 × A100 80GB
訓練時間：2–6 週
成本：$100K–$600K
MFU 目標：> 40%

Phase 3：Scale（> 30B 參數，> 2T Token）

目標： 企業級，成本最佳化，自動化故障恢復。

┌───────────────────────────────────────────────────────────────┐
│  Phase 3：Scale 預訓練架構                                     │
│                                                               │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  全域資料湖（PB 級）                                     │  │
│  │  S3 / GCS → Delta Lake → 流式資料載入                   │  │
│  └───────────────────────────┬─────────────────────────────┘  │
│                               │                                │
│                               ▼                                │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  3D 平行化訓練叢集（100+ 節點）                          │  │
│  │                                                         │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │  Pipeline Parallelism（PP）                      │  │  │
│  │  │  Stage 0 → Stage 1 → Stage 2 → Stage 3          │  │  │
│  │  └───────────────────────────────────────────────── ┘  │  │
│  │                         ↕                               │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │  Tensor Parallelism（TP）per Stage               │  │  │
│  │  │  GPU0│GPU1│GPU2│GPU3│ ← 切 Attention/FFN         │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  │                         ↕                               │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │  Data Parallelism（DP）across PP groups          │  │  │
│  │  │  ZeRO Stage 3 / FSDP                             │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  └─────────────────────────────────────────────────────────┘  │
│                                                               │
│  ┌──────────────┐  ┌─────────────────┐  ┌────────────────┐   │
│  │ 自動故障恢復  │  │ 彈性 Checkpoint  │  │  成本分析儀表板 │   │
│  │ < 5 分鐘 RTO │  │ 分散式儲存       │  │  $/Token 追蹤  │   │
│  └──────────────┘  └─────────────────┘  └────────────────┘   │
└───────────────────────────────────────────────────────────────┘

Phase 3 關鍵參數：

模型規模：30B–700B+ 參數
資料量：2T–15T Token
硬體：100–1000+ 節點，800–8000+ × A100/H100
訓練時間：1–6 個月
成本：$1M–$100M+
MFU 目標：> 45–50%（H100 叢集）

三、訓練資料管線：從 Common Crawl 到乾淨語料

原始網路資料到可用訓練語料的轉化率通常只有 20–35%，清洗管線的每個步驟都有直接的品質/成本取捨。

┌─────────────────────────────────────────────────────────────────────┐
│  資料清洗管線（以 Common Crawl 為例）                                │
│                                                                     │
│  原始 CC（~3.2PB）                                                  │
│       │                                                             │
│       ▼  [Step 1：語言識別]  fastText lid.176.bin                   │
│  保留英文/中文等目標語言（去掉 ~40% 非目標語言）                     │
│       │                                                             │
│       ▼  [Step 2：URL 黑名單]  SafeBrowsing + 自訂清單               │
│  移除色情、賭博、惡意軟體域名（去掉 ~10%）                           │
│       │                                                             │
│       ▼  [Step 3：品質過濾]  規則 + 分類器                          │
│  • 過短文本（< 50 token）                                           │
│  • 重複行比例 > 30%                                                 │
│  • 符號/數字比例異常                                                 │
│  • 困惑度過濾（KenLM 訓練的參考語言模型）                           │
│  去掉 ~35%                                                          │
│       │                                                             │
│       ▼  [Step 4：去重]  MinHash LSH                               │
│  文件級去重（Jaccard similarity > 0.8 視為重複）                     │
│  N-gram 級去重（移除高頻範本文本）                                   │
│  去掉 ~15%                                                          │
│       │                                                             │
│       ▼  [Step 5：個資移除]  正規表達式 + NER                       │
│  Email、電話、身份證、信用卡號碼遮罩                                 │
│       │                                                             │
│       ▼                                                             │
│  乾淨語料（保留 ~25–35% of 原始）                                   │
│  CC-100B tokens from 3.2PB raw → ~1.1TB 乾淨文本                   │
└─────────────────────────────────────────────────────────────────────┘

關鍵工程決策：

MinHash 去重的規模挑戰：

100B 文件的去重需要 O(N log N) 時間
實作上使用 LSH（Locality-Sensitive Hashing）將相似文件分到同一個 bucket
每個文件用 128–256 個 MinHash 值表示，band 數 = 20，每 band 6–7 個值
Jaccard ≥ 0.8 的碰撞機率 > 99%，誤刪率 < 1%
實際工程：用 Apache Spark 或 Ray Data 分散式計算，100B 文件約需 2–4 小時（200 cores）

資料混合比例（以 LLaMA-2 為例）：

資料來源	比例	Token 數	說明
Common Crawl	67%	1.34T	主要語料
GitHub	4.5%	89B	程式碼品質高
Wikipedia	4.5%	89B	結構化知識
Books	4.5%	89B	長文本理解
ArXiv	2.5%	50B	技術推理
StackExchange	2%	40B	QA 格式
其他	15%	300B	補充來源

四、Scaling Laws：Chinchilla 最優 N vs D 分配

4.1 Kaplan vs Chinchilla

2020 年 OpenAI 的 Kaplan Scaling Law 建議「給定算力，優先放大模型參數量」——這導致了 GPT-3（175B 參數，僅用 300B Token）的策略。

2022 年 DeepMind 的 Chinchilla 論文（Hoffmann et al.）修正了這個結論：

Chinchilla 最優公式：

N_optimal ≈ C^0.5 / 8.7    （最優參數量）
D_optimal ≈ C^0.5 × 1.75   （最優 Token 數）

其中 C = 訓練計算量（FLOPs）
簡化規則：D_optimal ≈ 20 × N_optimal

模型	參數量 (N)	訓練 Token (D)	D/N 比	Chinchilla 最優？
GPT-3	175B	300B	1.7x	嚴重欠訓練（差 10x）
Gopher	280B	300B	1.1x	嚴重欠訓練
Chinchilla	70B	1.4T	20x	✓ 最優
LLaMA-2 7B	7B	2T	286x	過度訓練（推理最優化）
LLaMA-2 70B	70B	2T	29x	接近最優

4.2 為什麼要「過度訓練」（Overtrain）小模型？

Chinchilla 最優是針對訓練成本最優，但工程上常見另一個目標：推理成本最優。

訓練成本最優：在固定計算預算 C 下，最大化訓練後模型能力
推理成本最優：在固定能力目標下，最小化每次推理的計算量
                                  ↓
「用更多 Token 訓練更小的模型」可以在相同能力下顯著降低推理成本

實際案例（7B 模型）：

Chinchilla 最優：140B Token（≈ 20 × 7B）
LLaMA-2：2T Token（≈ 286 × 7B）
結果：LLaMA-2 7B 的推理能力接近 Chinchilla-70B，但推理成本只有 1/10

決策矩陣：

目標	建議策略	Token 比例
最大化訓練效率	Chinchilla 最優	20×
邊緣推理部署	過度訓練小模型	100–300×
研究/實驗	欠訓練大模型（快速驗證）	5–10×

五、分散式訓練：DP / TP / PP / ZeRO

5.1 四種平行化的本質差異

Data Parallelism（DP）

每個 GPU 持有完整的模型副本，但處理不同的 mini-batch
梯度在所有 GPU 間做 AllReduce 同步
通訊瓶頸：梯度大小 = 模型參數量 × 4 bytes
限制：單 GPU 必須能放下整個模型

Tensor Parallelism（TP / Megatron-LM）

將單層的矩陣乘法水平切割到多個 GPU
Attention 的 Q/K/V 矩陣按 head 分片，FFN 按中間維度分片
需要 AllReduce（Attention）和 AllGather（FFN）
通訊量：每個 transformer layer 需要 2 次 AllReduce
最佳 TP 大小：4–8（超過 8 通訊開銷增大）

Pipeline Parallelism（PP / GPipe / 1F1B）

將 transformer 的層分配到不同 GPU，形成流水線
1F1B（One Forward One Backward）排程減少 Bubble 時間
Bubble ratio = (PP - 1) / (m + PP - 1)，其中 m 是 micro-batch 數
當 m ≥ 4×PP 時，bubble 開銷 < 20%

ZeRO（Zero Redundancy Optimizer）

ZeRO Stage 1：分片 Optimizer State（記憶體省 4×）
ZeRO Stage 2：分片 Optimizer State + Gradient（記憶體省 8×）
ZeRO Stage 3：分片全部（OS + Grad + Param）（記憶體省 64×）
代價：ZeRO Stage 3 需要 AllGather 參數，通訊量增加 50%

5.2 3D 平行化組合建議

┌──────────────────────────────────────────────────────────────┐
│  3D 並行配置（以 70B 模型 × 256 GPU 為例）                    │
│                                                              │
│  256 GPU = TP=4 × PP=8 × DP=8                               │
│                                                              │
│  DP Group（每組有相同的模型分片）                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │  DP Rank 0    DP Rank 1  ...  DP Rank 7             │    │
│  │  [PP_TP_mesh] [PP_TP_mesh]    [PP_TP_mesh]          │    │
│  └─────────────────────────────────────────────────────┘    │
│                           ↕ AllReduce（梯度同步）             │
│                                                              │
│  PP_TP Mesh（32 GPU = TP=4 × PP=8）                          │
│                                                              │
│  Pipeline Stage 0  Stage 1  ...  Stage 7                     │
│  ┌──────────┐ ┌──────────┐  ┌──────────┐                    │
│  │GPU0 GPU1 │ │GPU4 GPU5 │  │GPU28 GPU29│                   │
│  │GPU2 GPU3 │ │GPU6 GPU7 │  │GPU30 GPU31│                   │
│  └──────────┘ └──────────┘  └──────────┘                    │
│    TP=4 切         TP=4 切        TP=4 切                     │
│    Layers 0–9    Layers 10–19   Layers 70–79                 │
└──────────────────────────────────────────────────────────────┘

5.3 通訊拓撲的重要性

TP（Tensor Parallel）需要最高頻寬，必須在同一節點內（NVLink 600 GB/s）
PP（Pipeline Parallel）需要點對點通訊，可跨節點（InfiniBand 400 Gb/s）
DP（Data Parallel）需要 AllReduce，可跨機架（InfiniBand）

黃金規則：TP 大小 ≤ 同節點 GPU 數（通常 4 或 8）

六、訓練監控：Loss Spike 診斷與恢復

6.1 Loss Spike 的常見原因

症狀	可能原因	診斷方法
Loss 突然上升 10–50% 後緩慢恢復	壞批次資料（異常長文本或亂碼）	記錄 batch index，重現後跳過
Loss 上升後不恢復	學習率過大，梯度爆炸	監控 gradient norm（應 < 1.0）
Loss 在某個步驟後持續震盪	Optimizer state 損壞	回退到前一個 checkpoint
Loss 在某個 epoch 後突然下降	資料集循環，模型見到已學資料	檢查資料混洗策略
多個 GPU 的 Loss 不一致	DP 梯度同步錯誤	比較各 DP rank 的 Loss

6.2 監控指標清單

必須監控的指標（每 10–50 步記錄一次）：
├── Training Loss（主要信號）
├── Gradient Norm（grad_norm > 10 = 警告，> 100 = 停止）
├── Learning Rate（確認 LR Schedule 正確）
├── GPU 利用率（< 80% 表示有瓶頸）
├── GPU 記憶體使用率（接近 OOM 時預警）
├── 訓練吞吐量（tokens/sec，突然下降表示有問題）
└── 每個 PP Stage 的 bubble time（> 25% 需調整）

每 500 步記錄一次：
├── Validation Loss（偵測過擬合）
├── 每個資料來源的 Loss 分布
└── 梯度直方圖（偵測梯度消失/爆炸趨勢）

6.3 Loss Spike 自動恢復流程

偵測到 Loss Spike（Loss 在 100 步內上升 > 20%）
        │
        ▼
暫停訓練，記錄當前步驟 S 和 batch index B
        │
        ▼
回退到最近的健康 Checkpoint（S - 500 步）
        │
        ├─── 如果已回退 2 次以上 → 人工介入
        │
        ▼
分析 batch B 的資料：
  - 文本長度異常？ → 加入長度過濾
  - 亂碼/特殊字元？ → 加入字元過濾
  - 正常資料 → 可能是學習率問題
        │
        ▼
若資料正常：降低 LR 10–20%，從 checkpoint 重新開始
若資料異常：跳過該 batch，從 checkpoint 重新開始

實際成本估算： 在 256 GPU 叢集（$8/GPU/hour），每次 Loss Spike 恢復（回退 500 步）約需 1–2 小時，成本約 $2K–$4K。大型訓練中可能發生 10–30 次，總恢復成本 $20K–$120K。

七、Checkpointing 與斷點續訓

7.1 Checkpoint 策略

儲存頻率的取捨：

頻率	儲存成本	最大資料損失	適用場景
每 100 步	極高（磁碟可能耗盡）	100 步 × batch_size	不建議
每 500 步	高	500 步	Phase 2（生產）
每 1000 步	中等	1000 步	Phase 2 穩定期
每 5000 步	低	5000 步	風險過高，不建議

Checkpoint 大小計算：

70B 模型（FP16）的單個 Checkpoint 大小：
  參數：70B × 2 bytes = 140 GB
  Optimizer State（Adam）：70B × 12 bytes = 840 GB（FP32 × 3）
  總計：≈ 1 TB per checkpoint

每 500 步一個 checkpoint，保留最近 5 個：
  磁碟需求：5 × 1 TB = 5 TB（滾動覆寫）
  儲存成本（S3）：5 TB × $0.023/GB/月 ≈ $115/月（可忽略）

7.2 分散式 Checkpoint（Sharded Checkpoint）

對於 3D 平行化訓練，每個 GPU 只持有部分模型，checkpoint 也必須是分散式的：

1# 使用 PyTorch FSDP 的分散式 checkpoint 範例（概念）
2# 每個 rank 只儲存自己負責的參數分片
3dist_checkpoint.save(
4    state_dict=model.state_dict(),
5    storage_writer=dist_checkpoint.FileSystemWriter(checkpoint_dir),
6    # 每個 rank 寫入自己的分片檔案
7)

恢復時的關鍵注意事項：

拓撲必須相同（同樣的 TP/PP/DP 配置）才能直接恢復
若需要改變拓撲，必須先做 checkpoint resharding（耗時 1–4 小時）
建議在訓練開始時用「無拓撲」格式儲存一個完整 checkpoint 作為備份

八、為什麼選 X 不選 Y（六個關鍵決策）

選擇	選 X 的理由	不選 Y 的理由	翻轉條件
BPE Tokenizer（SentencePiece） vs 字元級 Tokenizer	詞彙表 32K–100K，序列長度最小化（1 Token ≈ 4 字元），訓練效率高	字元級：序列長 4–5×，注意力計算量增加 16–25×	若目標語言形態複雜（如阿拉伯語），可考慮 Unigram LM
AdamW vs SGD	自適應學習率，對超參數不敏感，大 batch 訓練穩定	SGD：需精確調 LR，在 Transformer 訓練中收斂慢 2–3×	超大 batch（> 64M token）時 SGD 可能更穩定
BF16 混合精度 vs FP16	BF16 動態範圍更大（指數位 8 vs 5），幾乎不發生 overflow，無需 Loss Scaling	FP16：精度高但 overflow 頻繁，需要複雜的 Loss Scale	H100 以前的硬體（V100）僅支援 FP16，必須用 FP16
Cosine LR Schedule + Warmup vs 固定 LR	訓練後期 LR 自然衰減，避免震盪；warmup 防止初期梯度爆炸	固定 LR：後期容易震盪，最終 Loss 高 5–15%	訓練步數 < 5000 的小實驗可以用 Linear Decay
Flash Attention 2 vs 標準 Attention	記憶體 O(N) 而非 O(N²)，速度快 2–4×，支援更長上下文	標準 Attention：128K token 的 sequence 需要 > 100 GB 記憶體	序列長度 < 2048 時差距不明顯，但 Flash Attention 2 幾乎無負面影響
ZeRO-2 vs ZeRO-3	通訊量少 30–50%，MFU 高；多數 7B–70B 訓練已足夠	ZeRO-3：AllGather 參數開銷大，通訊瓶頸明顯，MFU 低 10–20%	模型 > 200B 或 GPU 記憶體嚴重不足時，ZeRO-3 是唯一選擇

九、系統效應：訓練前後的量化對比

9.1 不同配置的訓練效率比較

指標	差的設定	優化後	改善幅度
MFU（7B 模型，A100）	22%	45%	+105%
Token 吞吐量（256 GPU）	180K tok/s	380K tok/s	+111%
1T Token 訓練時間	62 天	30 天	-52%
訓練成本（1T Token，7B）	$480K	$230K	-52%
Loss Spike 恢復時間	4–8 小時（人工）	0.5–1 小時（自動）	-85%
資料清洗吞吐量	5 TB/hr（單機）	80 TB/hr（Spark 集群）	+1500%

9.2 硬體選擇的成本效益

GPU	FP16 TFLOPS	記憶體	NVLink 頻寬	每小時成本	TFLOPS/$
A100 80GB	312	80 GB	600 GB/s	$2–4	78–156
H100 80GB SXM	989	80 GB	900 GB/s	$4–8	124–247
H100 NVL 94GB	989	94 GB	900 GB/s	$5–9	110–198
A10G 24GB	125	24 GB	PCIe only	$1–1.5	83–125

結論： H100 的 TFLOPS/$ 是 A100 的 1.6–2×，但實際 MFU 也更高，總體訓練成本可降低 40–50%。對於 70B+ 模型，切換到 H100 叢集通常能回收成本。

9.3 資料品質對最終 Loss 的影響

資料品質策略	最終 Validation Loss（7B/1T Token）	相對提升
無清洗（原始 CC）	2.85	baseline
基礎規則過濾	2.72	+4.6%
+ 去重	2.64	+7.4%
+ 品質分類器	2.58	+9.5%
+ 最優資料混合	2.51	+11.9%

十、面試答題要點

面試官問： 你負責訓練一個 7B LLM，預算 $500K，3 個月完成，請說明你的方案。

「我會分三層來規劃。首先是資料：用 Apache Spark 對 Common Crawl 做語言識別、品質過濾、MinHash 去重，目標產出 1.5T 乾淨 Token，比例參考 LLaMA-2 混合策略。訓練策略上，7B 模型用 Chinchilla 最優是 140B Token，但考慮到部署成本，我會選擇過度訓練到 1.5T——這樣 7B 的推理能力接近 Chinchilla-30B，但推理成本只有 1/5。基礎設施用 64 × A100 80GB（8 節點），DP + ZeRO-2，不需要 TP/PP，MFU 目標 40%，吞吐量約 200K tok/s，1.5T Token 需要約 87 天，成本約 $270K，在預算內。監控上，部署 WandB + 自動 Loss Spike 偵測（grad_norm > 10 觸發告警），每 500 步一個 Checkpoint，保留最近 10 個。關鍵風險是資料管線——我會在正式訓練前先用 10B Token 做 dry run 驗證整個流程，這個代價是 2–3 天和 $5K，但能避免損失 $100K+ 的大規模訓練。」

十一、系列導航

本文是 AI 工程從零開始 系列 Phase 10 的第 2 篇。

← 上一篇：Phase 10 Part 1：LLM 架構深探 — Transformer 的每一層在做什麼

→ 下一篇：Phase 10 Part 3：LLM 微調全景 — SFT、LoRA 與 RLHF 工程實踐

Phase 10 完整系列：

Part	主題	狀態
Part 1	Transformer 架構深探	✓
Part 2	LLM 預訓練工程（本文）	✓
Part 3	微調全景：SFT / LoRA / RLHF	即將發布
Part 4	推理優化：量化 / KV Cache / 投機解碼	即將發布
Part 5	LLM 部署：vLLM / TGI / 生產架構	即將發布