DSCP

3 秒看懂

DSCP 是 IP 包頭裡 6 bit 的”優先順序標籤”（0–63），路由器/交換器看到它就知道這個包該優先轉發還是可以丟棄。在 AI 叢集的 RoCEv2 RDMA 網路中，DSCP 是保障訓練流量不被阻塞的關鍵 QoS 機制之一。

3 分鐘產業解釋

為什麼 AI 產業鏈要關心一個 1998 年的網路協議欄位？

大型模型訓練的本質是一張由數千到數萬張 GPU 構成的分散式計算圖。GPU 之間通過 AllReduce、All-to-All 等集合通訊原語進行海量資料交換。一次訓練迭代中，任何一個數據包延遲或丟失都可能導致 GPU 流水線空轉（bubble），直接侵蝕寶貴的算力利用率。

問題在於：AI 叢集的物理網路不是訓練流量的獨佔通道。至少有三類流量共存：

流量型別	特徵	時延敏感度
訓練通訊（梯度/啟用）	大塊、突發、吞吐導向	極高（尾延遲直接影響迭代時間）
儲存 I/O（檢查點/資料載入）	大塊、持續、吞吐導向	高
管理/監控/SSH	小包、低頻寬	低

DSCP 的核心價值：在網路層為不同流量打上”顏色標籤”，讓交換器按優先順序排程，確保訓練通訊的優先轉發權。

產業位置

┌──────────────────────────────────────────────────┐
│                  應用層（PyTorch/Megatron）         │
│              集合通訊：AllReduce / All-to-All        │
├──────────────────────────────────────────────────┤
│              傳輸層（RoCEv2 / UCX / NCCL）          │
├──────────────────────────────────────────────────┤
│  ★ 網路層 QoS ★  ← DSCP 在這裡發揮作用              │
│  IP Header: DSCP 欄位標記優先順序                     │
├──────────────────────────────────────────────────┤
│              鏈路層（Ethernet + PFC/ECN）            │
│           802.1Qbb Priority Flow Control           │
├──────────────────────────────────────────────────┤
│           物理層（400G/800G 光模組/SerDes）           │
└──────────────────────────────────────────────────┘

DSCP 工作在 IP 層（L3），是端到端 QoS 策略的一部分，與鏈路層的 PFC（Priority Flow Control，802.1Qbb）協同配合：DSCP 決定”這個包屬於哪類業務”，PFC 在鏈路層實現”該類業務暫停傳送”的流控。

15 分鐘專家深入

1. DSCP 在 AI 叢集中的典型配置實踐

在 NVIDIA Spectrum-X 或 Broadcom Memory-Centric Infrastructure 參考架構中，RoCEv2 訓練網路通常採用如下 DSCP 對映策略（定性模式，具體值因廠商/OEM 方案而異）：

訓練 GPU↔GPU 流量    →  DSCP EF (46 / 101110)  →  對映至最高優先順序佇列
儲存流量（NVMe-oF）   →  DSCP AF41 (34 / 100010) →  對映至次高優先順序佇列
管理/監控流量         →  DSCP CS0 (0 / 000000)   →  盡力而為佇列

關鍵機制鏈：

NCCL/RoCEv2 應用層：由網絡卡驅動或 NCCL 環境變數設定 DSCP 值
交換器識別：交換器根據 DSCP 值將資料包分配到對應的硬體佇列
佇列排程：採用嚴格優先順序（Strict Priority）或加權排程（WRR/DRR）
擁塞管理：結合 ECN 標記和 PFC，實現無損或近無損傳輸

2. DSCP 與 PFC 的協同關係

這是理解 AI 網路 QoS 最容易混淆的地方：

        DSCP（L3 - 網路層）          PFC（L2 - 鏈路層）
        ┌─────────────────┐        ┌─────────────────┐
        │ 分類：哪個業務？    │  對映   │ 流控：該不該暫停？   │
        │ 64 種程式碼點       │──────→│ 8 個優先順序 CoS     │
        │ 端到端語義         │        │ 逐跳/逐鏈路語義     │
        └─────────────────┘        └─────────────────┘

DSCP → CoS 對映：交換器將入埠的 DSCP 值對映到 802.1Q 的 3-bit PCP/CoS 欄位（0–7），從而關聯到 PFC 的 8 個優先順序
典型做法：訓練流量的 DSCP 對映到某個 CoS 值，該 CoS 值啟用 PFC；管理流量的 CoS 不啟用 PFC（避免非關鍵流量參與反壓）

3. 常用 PHB（Per-Hop Behavior）型別

IETF 定義了以下標準 PHB 組，這是 DSCP 的”語義層”：

PHB 型別	DSCP 值（二進位制）	DSCP 值（十進位制）	語義	AI 叢集用途
CS0（Class Selector 0）	000000	0	盡力而為（BE）	管理流量預設
CS6/CS7	110000 / 111000	48 / 56	網路控制	路由協議（BGP/OSPF）
AF41	100010	34	確保轉發，低丟棄優先順序	儲存/資料載入
EF	101110	46	加速轉發，低延遲低抖動	GPU 訓練通訊（典型選擇）

注意：EF (DSCP 46) 是業界用於”低延遲保障”的經典選擇，但在大規模 AI 叢集中，部分方案採用 CS7 或自定義對映，具體取決於交換器廠商和叢集網路設計。上表為典型模式而非唯一標準。

4. 為什麼不能只靠 PFC？

PFC 是逐跳（hop-by-hop）的鏈路層流控，存在以下侷限性：

擁塞傳播（Congestion Spreading）：一個埠的 PFC pause 幀可能導致反壓波及上游埠，產生”佇列樹形阻塞”
PFC Storm：配置不當可能產生 PFC 風暴，導致大面積網路癱瘓
無業務感知：PFC 只知道”這個佇列滿了，暫停”，不知道包裡是什麼業務

DSCP 的價值在於提供 L3 層的業務分類和端到端語義，與 PFC 形成互補：DSCP 負責”分好類”，PFC 負責”保不失”，ECN 負責”通知擁塞”。

技術原理

1. DSCP 在 IP 報文中的位置

IPv4 報文頭的 ToS 欄位（8 bit）被 DiffServ 重新定義：

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |    DSCP (6b)  |ECN |         Total Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  TTL  |    Protocol           |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    DSCP 欄位：IP 頭第 2 位元組的高 6 位（bit 0–5）
    ECN 欄位：IP 頭第 2 位元組的低 2 位（bit 6–7）
    → 合起來就是原 ToS 欄位的 8 bit

IPv6 類似：Traffic Class 欄位（8 bit）同樣高 6 位用於 DSCP，低 2 位用於 ECN。

2. DSCP 的作用域模型

         邊緣網路                     核心網路                    邊緣網路
    ┌──────────────┐            ┌──────────────┐           ┌──────────────┐
    │  Classifier   │           │              │           │  Classifier   │
    │  + Marker     │           │  Per-Hop     │           │  + Marker     │
    │              │           │  Behavior    │           │              │
    │  流量分類 &    │  ── DSCP ─→  基於 DSCP 的 │  ─ DSCP → │  流量分類 &    │
    │  DSCP 標記    │           │  佇列排程/    │           │  DSCP 標記    │
    │              │           │  擁塞管理     │           │              │
    └──────────────┘            └──────────────┘           └──────────────┘
         ↑ 信任邊界                    ↑ 不修改 DSCP              ↑ 信任邊界

核心原則（RFC 2475）：

DSCP 在網路邊緣標記（Classifier + Marker）
核心網路只讀取 DSCP 並執行對應的 PHB，原則上不修改
這使得核心路由器無需維護每流狀態，實現可擴充套件的 QoS

3. ECN 與 DSCP 的配合（AI 叢集關鍵）

傳送端                              交換器                               接收端
  │                                  │                                    │
  │─── IP 包 (DSCP=46, ECN=10) ───→│                                    │
  │                                  │  佇列深度 > 閾值?                   │
  │                                  │  是 → 將 ECN 改為 11 (CE)           │
  │                                  │─── IP 包 (DSCP=46, ECN=11) ────→  │
  │                                  │                                    │
  │←──────── CNP (擁塞通知包) ─────────│←─── 接收端檢測到 CE ──────────────│
  │                                    傳送 CNP                            │
  │  降低傳送速率                                                       │

ECN = 10（ECT）：傳送端宣告支援 ECN
ECN = 11（CE - Congestion Experienced）：交換器在擁塞時標記
CNP（Congestion Notification Packet）：RoCEv2 接收端發回的擁塞通知

在 AI 叢集中，DSCP + ECN + PFC 構成三層擁塞管理體系：

層級	機制	作用	時間尺度
L3 網路層	DSCP	流量分類	靜態配置
L3 網路層	ECN	擁塞訊號傳遞	微秒–毫秒
L2 鏈路層	PFC	無損流控	亞微秒
應用層	NCCL 速率調整	全域性排程	毫秒–秒

技術演進史

時間	里程碑	說明
1981	RFC 791	IPv4 定義 ToS 欄位（8 bit），最初用於 IP Precedence（僅高 3 bit）
1992	RFC 1349	擴充套件 ToS 欄位語義，4 bit TOS 子欄位用於延遲/吞吐/可靠性/開銷
1998	RFC 2474	正式定義 DSCP：將 ToS 欄位高 6 bit 重新定義為 DSCP，低 2 bit 留給 ECN
1998	RFC 2475	DiffServ 架構架構：邊緣分類標記 + 核心 PHB 執行
1999	RFC 2597	AF（Assured Forwarding）PHB 定義：4 類 × 3 丟棄優先順序 = 12 個 DSCP
1999	RFC 2598	EF（Expedited Forwarding）PHB 定義：低延遲低抖動保障
2001	RFC 3168	ECN 標準化，佔用 ToS 欄位低 2 bit，與 DSCP 共存
2010 年代	RoCE v1/v2	資料中心 RDMA 技術興起，DSCP 成為 RoCEv2 QoS 標配
2018–	AI 叢集規模化	萬卡訓練叢集出現，DSCP + PFC + ECN 三位一體成為 AI 網路 QoS 基石
2023–	超大規模叢集	10 萬卡叢集（如 xAI Colossus）對網路 QoS 提出更精細需求

技術路線對比

AI 叢集網路 QoS 技術方案對比

維度	DSCP + PFC + ECN（乙太網路方案）	InfiniBand 自有 QoS	專用排程（如 HPN/自研）
標準化程度	IETF/IEEE 標準成熟，多廠商互操作	InfiniBand TA 規範	私有協議
部署規模	支援數萬埠級 AI 叢集	傳統上限約數千節點（單子網），超大規模需多子網	因方案而異
精細度	6 bit DSCP（64 類）+ 8 CoS + ECN	Virtual Lane（VL，最多 16 個）	可定製
生態相容	通用乙太網路裝置，供應鏈豐富	需專用 HCA/交換器	需定製硬體/軟體
成本	中（商用交換器 + RoCE 網絡卡）	高（專用硬體）	高（定製研發）
典型代表	NVIDIA Spectrum-X, Broadcom Jericho/AI 網路	NVIDIA Quantum-2 InfiniBand	Google TPU v4/v5 互聯

產業趨勢：超大規模 AI 訓練正從 InfiniBand 向乙太網路方案遷移（如 xAI、Meta 的大叢集），DSCP 在乙太網路方案中的地位持續上升。

上下游

上游：誰設定 DSCP？

環節	機制
NCCL / PyTorch	通過環境變數（如 `NCCL_IB_TC` 或類似 UCX 引數）控制 RoCEv2 資料包的 DSCP/ToS
作業系統核心	`tc`（traffic control）工具、iptables 的 `--set-dscp-mark`
網絡卡驅動	NVIDIA/Mellanox OFED 驅動中的 QoS 配置
SDN 控制器	集中下發 DSCP 標記策略

下游：誰消費 DSCP？

環節	機制
接入交換器	基於 DSCP 做分類，對映到硬體佇列，決定排程優先順序
核心交換器	執行 PHB，佇列排程（SP/WRR/DRR），ECN 標記
出口閘道器	可能根據 DSCP 做流量整形/限速

供應鏈對映

[GPU/CPU]  ──  [RDMA 網絡卡（NVIDIA CX-7/CX-8, Broadcom P 系列）]
                     │
                     ↓  設定 DSCP
              [ToR 交換器（Spectrum-4, Memory 交換晶片）]
                     │
                     ↓  基於 DSCP 排程
              [Leaf/Spine 交換器]
                     │
                     ↓  ECN 標記（如果擁塞）
              [接收端網絡卡] ──  CNP ──  [傳送端降速]

關鍵指標

指標	說明	AI 叢集典型要求
DSCP 值域	6 bit，0–63	訓練流量一般使用單個 DSCP 值（如 EF=46）
DSCP-to-Queue 對映延遲	交換器從識別 DSCP 到完成入隊的時間	通常納秒級（硬體轉發）
PFC 響應時間	從檢測到擁塞到上游暫停傳送	亞微秒（要求極低，是無損網路關鍵）
ECN 標記閾值	觸發 ECN CE 標記的佇列深度	通常配置為佇列容量的 10%–30% [廠商建議範圍]
端到端尾延遲（P99）	從傳送到接收的最差情況延遲	AI 叢集期望 < 10μs（同機架），< 100μs（跨機架）
RoCEv2 丟包率	RDMA 流量的丟包比例	趨近於零（任何丟包都可能觸發超時重傳，嚴重拖慢訓練）

供需與市場資料

背景市場

DSCP 本身不產生直接營收，但它是 AI 叢集網路解決方案的必要元件，其價值嵌入在以下市場中：

市場	估算規模	來源/口徑	與 DSCP 的關係
資料中心交換晶片	~$150–200 億（2025E）	[行業報告估算]	DSCP 分類排程是交換晶片的基本功能
AI 網路裝置（交換+網絡卡）	~$300–400 億（2025E）	[行業報告估算]	DSCP 是 AI 網路 QoS 的基礎機制
RoCEv2 RDMA 網絡卡	~$50–80 億（2025E）	[供應鏈估算]	網絡卡負責設定初始 DSCP 值

關鍵趨勢

400G→800G 遷移加速：更高的頻寬使單個擁塞事件的影響更大，QoS 機制（DSCP + ECN + PFC）的重要性進一步提升
超乙太網路聯盟（Ultra Ethernet Consortium, UEC）：正在制定下一代 AI 乙太網路標準，預計將在 DSCP 基礎上擴充套件更精細的 QoS 語義
端網協同：DSCP 標記從傳統的”靜態配置”向”應用層感知動態調整”演進

代表公司與資本對映

環節	代表公司	DSCP 相關產品/能力	關注要點
交換晶片	NVIDIA（Spectrum-X）	Spectrum-4 晶片，完整的 DSCP/PFC/ECN 端到端方案	AI 網路營收高速增長
交換晶片	Broadcom（Jericho3-AI）	Memory-Centric 交換架構，DSCP-aware 排程	最大乙太網路交換晶片供應商
交換晶片	Marvell（Teralynx）	面向 AI 的低延遲交換晶片	AI 網路份額追趕
交換裝置	Arista Networks	EOS 作業系統，AI Center 叢集網路方案	Meta/微軟等大客戶
交換裝置	華為	CloudEngine 系列，AI Fabric 方案	國內 AI 叢集主要供應商
RDMA 網絡卡	NVIDIA（ConnectX）	ConnectX-7/8，NCCL 原生整合 DSCP 設定	生態鎖定優勢
RDMA 網絡卡	Broadcom（P 系列）	面向 AI 的 RDMA 網絡卡	開放生態替代選項
作業系統/軟體	SONiC	開源網路作業系統，DSCP/QoS 配置標準化	超大規模使用者首選

投資邏輯

核心判斷

DSCP 是 AI 叢集網路 QoS 的基礎協議機制，其投資價值不在於協議本身（免費標準），而在於承載它的硬體和軟體平台。

投資主線

AI 乙太網路替代 InfiniBand 的趨勢 → DSCP 在乙太網路方案中的重要性上升
- 受益標的：Arista（ANET）、Broadcom（AVGO）、Marvell（MRVL）
- 邏輯：超大規模 AI 訓練從 IB 遷移到乙太網路，帶來乙太網路交換/網絡卡增量
交換晶片高階化 → 支援精細 DSCP 排程的高階晶片 ASP 更高
- 受益標的：Broadcom、Marvell、NVIDIA
- 邏輯：AI 叢集對 QoS 的嚴格要求推動交換晶片向更復雜排程引擎升級
網路軟體/自動化 → QoS 策略從手動配置走向意圖驅動自動化
- 受益標的：Arista、Cisco、以及 SDN 軟體廠商
- 邏輯：萬卡叢集手工配置 DSCP 不現實，需要自動化編排

風險提示

DSCP 作為開放標準，不構成直接競爭壁壘，關鍵在系統級方案整合能力
如果 InfiniBand 在超大規模場景持續保持優勢，乙太網路 QoS 方案的價值可能被壓縮

常見誤讀糾偏

誤讀 1：“DSCP 就是 QoS 的全部”

糾偏：DSCP 僅是 QoS 體系中的分類標記環節。一個完整的 AI 叢集網路 QoS 方案至少包含：

DSCP：L3 流量分類（“是什麼業務？”）
佇列排程：交換器內部如何分配頻寬（SP/WRR/DRR）
PFC：L2 無損流控（“佇列滿了暫停上游”）
ECN：端到端擁塞通知（“通知傳送端降速”）
應用層速率調整：NCCL 級別的全域性排程

DSCP 沒有流量控制能力，它只是給資料包”貼標籤”。

誤讀 2：“PFC 替代了 DSCP 的作用”

糾偏：PFC 工作在 L2 鏈路層（802.1Qbb），它的 8 個優先順序（CoS）是逐鏈路的。DSCP 工作在 L3 網路層，是端到端的。二者是協作關係而非替代關係：

DSCP 在源端標記，跨越多個交換器跳數保持不變
PFC 的 pause 幀只在一跳有效，不跨路由器
跨 L3 邊界的場景（如跨 POD/跨 AZ），DSCP 是唯一能保持業務分類語義的機制

誤讀 3：“DSCP 是 InfiniBand 的競爭技術”

糾偏：DSCP 是 IP/Ethernet 協議棧的組成部分。InfiniBand 使用 Virtual Lane (VL) 實現類似功能，走的是完全不同的協議棧。二者不是競品，而是分別服務於乙太網路和 InfiniBand 兩種網路架構。當前的競爭格局是乙太網路（用 DSCP/QoS）vs. InfiniBand（用 VL/QoS） 在 AI 叢集網路層面的路線之爭。

誤讀 4：“DSCP 配置是一次性的，設好就不用管”

糾偏：在 AI 訓練場景中，不同訓練任務的通訊模式差異很大（如 Dense Model 的 AllReduce vs. MoE 模型的 All-to-All），最優的 DSCP/佇列策略可能隨任務變化。更先進的方案正在探索動態 DSCP 策略調整，由網路控制器根據即時擁塞狀態和任務特徵自動最佳化。

學習路徑

Level 0  理解 OSI 模型和 IP 報文結構
   │       → 推薦：《計算機網路：自頂向下方法》
   ▼
Level 1  理解 DiffServ 基礎
   │       → IETF RFC 2474（DSCP 定義）
   │       → IETF RFC 2475（DiffServ 架構）
   ▼
Level 2  理解 AI 網路中的 QoS 三件套
   │       → DSCP + PFC + ECN 協同機制
   │       → 推薦：NVIDIA Networking Community 文件
   │       → 推薦：《Data Center Networks: Topologies, Architectures and Fault-Tolerance Characteristics》
   ▼
Level 3  動手配置
   │       → 在 Linux 中用 `tc` 設定 DSCP
   │       → 在 SONiC/SONiC 配置 DSCP-to-Queue 對映
   │       → 模擬 RoCEv2 環境下的 QoS 驗證
   ▼
Level 4  AI 叢集級設計
   │       → 端到端 QoS 策略設計（NCCL→網絡卡→ToR→Leaf→Spine）
   │       → 推薦：NVIDIA AI Networking Best Practices 白皮書
   │       → 推薦：超乙太網路聯盟（UEC）技術文件
   ▼
Level 5  前沿研究
           → UEC 下一代 QoS 語義
           → 意圖驅動網路（IBN）中的動態 QoS
           → 大型模型訓練中的網路感知排程

一句話總結

DSCP 是 IP 報文裡 6 bit 的優先順序標籤，本身極其簡單，但在 AI 叢集萬卡訓練場景中，它是保障 GPU 間 RDMA 流量獲得優先排程的關鍵分類機制——理解 DSCP，是理解 AI 網路 QoS 的第一步。

延伸閱讀與來源

資源	說明
IETF RFC 2474	DSCP 定義的權威標準
IETF RFC 2475	DiffServ 架構架構
IETF RFC 2597	AF PHB 定義
IETF RFC 2598	EF PHB 定義
IETF RFC 3168	ECN 標準化
InfiniBand Trade Association	IB QoS (Virtual Lane) 規範
NVIDIA Networking Documentation	Spectrum-X / ConnectX QoS 配置指南
Ultra Ethernet Consortium (UEC)	下一代 AI 乙太網路標準進展
Arista AI Networking Whitepapers	AI 叢集網路設計實踐

本文件基於 IETF 標準文獻和公開行業資料撰寫。涉及 AI 叢集具體配置的內容為行業典型模式的定性描述，實際部署因廠商方案和叢集規模而異。市場規模為行業估算，非精確認定。