一、背景

網(wǎng)絡(luò)互聯(lián)是大規(guī)模集群不可或缺的一部分，也是大規(guī)模模型訓(xùn)練中影響任務(wù)穩(wěn)定性和效率的關(guān)鍵因素，然而網(wǎng)絡(luò)相關(guān)問題的診斷和修復(fù)又是個老大難問題。本文我們介紹清華大學(xué)和阿里的 SkeletonHunter 系統(tǒng)，其提供了一個不錯的思路。

對應(yīng)的論文為：SkeletonHunter: Diagnosing and Localizing Network Failures in Containerized Large Model Training [1]

相關(guān)工作可以參考我們之前的文章：

• LLaMA 3 背后的大規(guī)模 GPU 集群 RoCE 網(wǎng)絡(luò)建設(shè)
• HPN 7.0：阿里云新一代萬卡集群網(wǎng)絡(luò)架構(gòu)
• 萬卡 GPU 集群互聯(lián)：硬件配置和網(wǎng)絡(luò)設(shè)計
• 大規(guī)模 GPU 集群運(yùn)維實(shí)踐：假裝萬卡 GPU 集群經(jīng)驗
• Meta 萬卡 GPU 集群穩(wěn)定性剖析與最佳實(shí)踐

二、摘要

靈活性和可移植性使得容器技術(shù)成為近年來大規(guī)模模型訓(xùn)練備受青睞的基礎(chǔ)設(shè)施。然而，這些優(yōu)勢也會面臨諸多挑戰(zhàn)，比如容器的高動態(tài)性、Underlay（物理網(wǎng)絡(luò)）和 Overlay（虛擬網(wǎng)絡(luò)） 網(wǎng)絡(luò)的復(fù)雜交互作用，以及故障檢測與定位的高要求。現(xiàn)在的數(shù)據(jù)中心調(diào)試工具依賴全面性或機(jī)會性的監(jiān)測，在此場景下效率較低，并且準(zhǔn)確度不足。

本文中，作者提出 SkeletonHunter —— 一種容器網(wǎng)絡(luò)監(jiān)控診斷系統(tǒng)，其利用大模型訓(xùn)練產(chǎn)生的網(wǎng)絡(luò)流量的固有且規(guī)律的稀疏特征，采用 Traffic Skeleton 機(jī)制（持續(xù)追蹤訓(xùn)練流量傳輸?shù)年P(guān)鍵網(wǎng)絡(luò)路徑集合），從而實(shí)現(xiàn)快速可靠的網(wǎng)絡(luò)故障檢測和定位。

該系統(tǒng)在生產(chǎn)環(huán)境部署 6 個月，成功檢測到 4816 次網(wǎng)絡(luò)故障，準(zhǔn)確率 98.2%，召回率 99.3%，并以 95.7% 的高精度完成故障定位。在修復(fù) 98% 的問題網(wǎng)絡(luò)組件后，月均故障率顯著下降 99.1%。

三、引言

3.1 大模型訓(xùn)練的網(wǎng)絡(luò)需求

大模型訓(xùn)練對網(wǎng)絡(luò)有極高的要求，比如：

• 低時延：RoCE 網(wǎng)絡(luò) RTT 需要低于 20μs。
• 高同步性：訓(xùn)練任務(wù)高度同步，10μs 的 RTT 增加就可能導(dǎo)致 20% 的性能下降（Alibaba HPN: A Data Center Network for Large Language Model Training [2]）。
• 零丟包：任何丟包或時延抖動都有可能導(dǎo)致訓(xùn)練任務(wù)同步失敗。

3.2 容器化的挑戰(zhàn)

根據(jù)作者經(jīng)驗，在大規(guī)模容器化模型訓(xùn)練 Infra 中準(zhǔn)確及時地定位網(wǎng)絡(luò)問題，會面臨 3 大挑戰(zhàn)：

高動態(tài)性：如下圖所示，容器生命周期短，超過 50% 容器的生命周期小于 60 分鐘，并且狀態(tài)變化頻繁。

端點(diǎn)（Endpoint）復(fù)雜：如下圖所示，每個容器可綁定多個 RNIC（RDMA NIC，如 8 個），形成復(fù)雜端點(diǎn)拓?fù)洹?/p>

Overlay/Underlay 交織：多租戶隔離引入虛擬網(wǎng)絡(luò)層，導(dǎo)致故障定位困難。如下圖 Figure 6 所示為生產(chǎn)環(huán)境中每臺機(jī)器上 Flow Table 數(shù)量的分布情況，每臺機(jī)器平均 Flow Table 數(shù)量超過 40 條，最大達(dá)到 9355 條。實(shí)際上這只是網(wǎng)絡(luò)協(xié)議棧中虛擬組件的一種。

除此之外，容器化網(wǎng)絡(luò)會對網(wǎng)絡(luò)故障的排查難度產(chǎn)生倍增效應(yīng)。假設(shè)某個訓(xùn)練任務(wù)涉及 X 個容器，每個容器平均綁定 Y 張 NIC，而每個 NIC 平均關(guān)聯(lián) Z 個虛擬網(wǎng)絡(luò)組件，那么每個訓(xùn)練 Step（通常幾十秒），需要探測 X*Y*Z（比如 1K * 8 * 16 = 128K）個網(wǎng)絡(luò)組件，成本非常高。

這些挑戰(zhàn)使得傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控手段（如 Pingmesh）在容器化大模型訓(xùn)練場景中效率低、準(zhǔn)確性差。

3.3 核心洞察

盡管容器網(wǎng)絡(luò)復(fù)雜，但大模型訓(xùn)練的網(wǎng)絡(luò)流量具有以下兩個關(guān)鍵特征：

空間稀疏性（Spatial Sparsity）：訓(xùn)練任務(wù)通常會采用 DP、TP、PP 等分布式策略，每個 GPU/NIC 只與特定組內(nèi)的其他 GPU/NIC 通信。因此，實(shí)際通信路徑遠(yuǎn)小于全互聯(lián)拓?fù)洌纬上∈璧?guī)則的 “Traffic Pattern”。

如下圖 Figure 8 所示為 512 GPU 的 Dense 模型訓(xùn)練，TP=8、PP=8、DP=8。機(jī)內(nèi) 8 個 GPU 通過 NVLink + NVSwitch 實(shí)現(xiàn)高速互聯(lián)，可以將 TP 放在機(jī)內(nèi)。每個 GPU 對應(yīng)一個 RDMA NIC，通過軌道優(yōu)化的網(wǎng)絡(luò)互聯(lián)（如下圖 Figure 10 所示）。

如下圖 Figure 9a 展示了上述訓(xùn)練任務(wù)中各 NIC 間對應(yīng)的流量矩陣，該矩陣呈現(xiàn)出高度稀疏性。這一特性提供了高效監(jiān)控網(wǎng)絡(luò)連接狀態(tài)的可能性——只需聚焦于實(shí)際存在連接的 <源，目的> 節(jié)點(diǎn)對（而非所有節(jié)點(diǎn)對）。除 Dense 模型外，MoE 模型會引入 EP 并行策略。如下圖 Figure 9b 所示，EP 可能產(chǎn)生不同的流量模式，但其空間分布稀疏性特征依然成立。

時間周期性（Temporal Burstiness）：訓(xùn)練是迭代式的，每 Step 迭代結(jié)束時會有參數(shù)同步（如 AllReduce），引發(fā)周期性流量突發(fā)。這些突發(fā)流量在 NIC 上表現(xiàn)為周期性的吞吐量峰值。如下圖 Figure 7 所示：

四、SkeletonHunter 系統(tǒng)設(shè)計與實(shí)現(xiàn)

4.1 系統(tǒng)架構(gòu)

SkeletonHunter 的核心思路是通過推斷訓(xùn)練任務(wù)的 “Traffic Skeleton”，只監(jiān)控真正可能通信的路徑，從而大幅降低監(jiān)控開銷并提升故障定位精度。如下圖 Figure 11 所示，其包含 3 個關(guān)鍵組件：

• Traffic Skeleton Inference
• Connectivity Anomaly Detection
• Optimistic Overlay-Underlay Disentanglement

4.2 流量模式推斷（Traffic Skeleton Inference）

Traffic Skeleton Inference 的目標(biāo)是：在不感知用戶模型結(jié)構(gòu)的前提下，僅憑 NIC 上的吞吐量規(guī)律，反推出訓(xùn)練任務(wù)實(shí)際通信的 “Traffic Skeleton”，從而把探測矩陣壓縮 95% 以上。整個過程分 為三步：Preload → Initialization → Runtime，依次在控制面和數(shù)據(jù)面進(jìn)行。

4.2.1 Preload：Basic Ping List 生成

如上圖 Figure 10，集群采用軌道優(yōu)化拓?fù)洌好總€機(jī)器 8 個 GPU，對應(yīng) 8 個 NIC，同號 GPU 對應(yīng)的 NIC 連接在同一個 ToR Switch 下。

NCCL 會自動將跨 Rail 流量轉(zhuǎn)換為 “節(jié)點(diǎn)內(nèi) GPU 通過 NVLink 通信 + 節(jié)點(diǎn)間 Rail 通信（PXN）”，因此跨 Rail 網(wǎng)絡(luò)路徑永遠(yuǎn)不會被使用。因此 SkeletonHunter 可以在任務(wù)啟動前將跨 Rail 連接刪除，生成 Basic Ping List，對于常見 8-Rail 集群，探測項可以降低到 1/8。

4.2.2 Initialization：增加 Ping List 激活

容器啟動時間差異較大，如果立即探測，會把還沒有 Ready 的容器判斷為網(wǎng)絡(luò)不可達(dá)。為了避免這個問題，SkeletonHunter 的 Controller 將 Ping List 激活下放到數(shù)據(jù)面容器。

具體來說，當(dāng)容器創(chuàng)建時，其 Agent 首先從 Controller 獲取 Basic Ping List，但暫不啟動實(shí)際的連通性探測，知道其他容器完成注冊并激活已經(jīng)創(chuàng)建容器中記錄的對應(yīng) Ping 目標(biāo)。通過這種方式，可以有效避免容器初始化階段的誤報。

4.2.3 Runtime：基于推斷的 Traffic Skeleton 優(yōu)化

此優(yōu)化基于以下關(guān)鍵洞察：

• 并行組內(nèi) GPU 執(zhí)行完全相同的計算圖，只是輸入數(shù)據(jù)不同 → NIC 流量突發(fā)周期在時域上幾乎重合。
• 不同并行組的突發(fā)在相位上存在固定滑移（Pipeline Parallelism 引入）。
• 實(shí)際通信只發(fā)生在同一并行組內(nèi)部，因此 95% 以上的 <源, 目標(biāo)> 對永遠(yuǎn)無流量。

Traffic Skeleton 推斷的具體流程如下所示：

提取容器 NIC 吞吐量突發(fā)周期的頻域特征：具體來說，使用 STFT（短時傅里葉變換）將時域吞吐量突發(fā)周期轉(zhuǎn)換到頻域。（PS：也試過小波變換和離散傅里葉變換，不過 STFT 計算復(fù)雜度最低），如下圖 Figure 13 所示，經(jīng)轉(zhuǎn)換，A 與 B 具有相似特征，C 與 D 具有另外的相似特征，表明 A/B，C/D 分別在不同數(shù)據(jù)平面的相同拓?fù)湮恢谩?/p>

聚類：對提取的 STFT 特征進(jìn)行層次聚類，通過度量 NIC 流量突發(fā) STFT 特征的相似性進(jìn)行分組。

約束推導(dǎo)：進(jìn)一步對分組過程施加以下約束條件，根據(jù)訓(xùn)練任務(wù)分配的 GPU 數(shù)量，使分組結(jié)果更具可解釋性。其中 k 表示訓(xùn)練任務(wù)中 NIC 組的總數(shù)；ci 表示第 i 個組，[c-] 表示各組 NIC 數(shù)量平均值取最接近整數(shù)；N 是 NIC 的總數(shù)，ri 表示機(jī)器 Hr 中的第 i 個 NIC。

• 公式（1）：最小化各組間 NIC 數(shù)量方差 → 保障各 DP 組規(guī)模一致。
• 公式（2）：總 NIC 數(shù) N 必須能被 k 整除 → 符合 N 是 DP 組的整數(shù)倍。
• 公式（3）：同一物理機(jī)上的 NIC 不能分在同一組 → DP 通常不會分在機(jī)內(nèi)。

上述過程有助于推斷出 DP 組，其值等同于 [c-]。接下來基于 TP x PP = N / [c-] 推斷出 TP 和 PP 配置。利用吞吐量突增周期的時間偏移特性，可以進(jìn)一步區(qū)分不同的 PP Stage。比如，第一個 PP Stage 1 相比 PP Stage 2 更早經(jīng)歷相同的流量突增。最后可以推斷出任務(wù)的并行策略，并確定每個任務(wù)的 Traffic Skeleton。MoE 模型的 EP 也可以采用類似方式探測。

經(jīng)過一系列手段，SkeletonHunter 將 Ping List 進(jìn)一步縮減 95% 以上。如下圖 Figure 15 和 Figure 16 所示，探測目標(biāo)和成本相比 Full Mesh 都大幅下降，比如 512 GPU，F(xiàn)ull Mesh 需要探測 560s，SkeletonHunter-Basic 需要 64.85s，而最終 SkeletonHunter 只需要 8.23s：

4.3 異常檢測（Anomaly Detection）

高丟包率可明確歸因于網(wǎng)絡(luò)問題，但突發(fā)的高時延可能因為瞬時擁塞或網(wǎng)絡(luò)資源競爭，需要通過數(shù)據(jù)分析來過濾這些瞬時時延突增。為此，作者核心思路是采用最先進(jìn)的序列分析技術(shù)，以評估通信模式是否隨時間發(fā)生變化。

具體而言，SkeletonHunter 的 Analyzer 會聚合采集數(shù)據(jù)，并通過統(tǒng)計檢驗進(jìn)行短期與長期時延異常檢測，其理論基礎(chǔ)是大數(shù)定律。

短周期異常檢測：以每 30s 為粒度進(jìn)行短期分析，通過 25 分位、中位數(shù)、75 分位、最小值、均值、標(biāo)準(zhǔn)差和最大值來描述時延分布。隨后，基于局部離群因子（LOF）對每個時間窗口的時延分布進(jìn)行異常檢測。并設(shè)置回溯 5 分鐘作為參考值，若新的 5 分鐘窗口具有較高的 LOF 值且無法與先前窗口聚類，則判斷出現(xiàn)異常。

長周期異常檢測：以每 30 分鐘聚合并分析時延數(shù)據(jù)。旨在檢測網(wǎng)絡(luò)性能的漸進(jìn)式退化（通常在短周期檢測中很難發(fā)現(xiàn)）。由于長期分析可收集海量時延數(shù)據(jù)，因此采用統(tǒng)計檢驗方法檢測時延異常，長期運(yùn)行正常的兩種 NIC 的時延數(shù)據(jù)始終遵循對數(shù)正態(tài)分布。如下圖 Figure 14 所示，在時間 T 內(nèi)對每個 <源、目標(biāo)> NIC 對的時延數(shù)據(jù)進(jìn)行參數(shù)估計，并推導(dǎo)出估計的對數(shù)正態(tài)分布，以驗證數(shù)據(jù)是否遵循估計的對數(shù)正態(tài)分布。圖中所示，T+0.5 小時的時延數(shù)據(jù)仍符合估計分布，而 T+1 小時和 T+1.5 小時的數(shù)據(jù)則偏離了估計分布。因此，T+1 小時和 T+1.5 小時判定為時延異常。

4.4 故障定位（Optimistic Overlay-Underlay Disentanglement）

在檢測到高丟包率或時延異常后，SkeletonHunter 僅能確定兩個容器間存在網(wǎng)絡(luò)問題，但無法精確定位導(dǎo)致該問題的具體網(wǎng)絡(luò)組件。為此，作者基于“Overlay 和 Underlay 的根因分布屬于軟件和硬件問題，且不會相互傳導(dǎo)”的假設(shè)進(jìn)行問題定位。

如下圖 Algorithm 1 所示，該機(jī)制首先將容器間的傳輸路徑分為獨(dú)立的 Underlay 和 Overlay 鏈路（1-6 行），隨后分別通過 Overlay 邏輯可達(dá)性分析（7-15）和 Underlay 交集分析（16-21 行）實(shí)現(xiàn)雙層級故障定位。

Overlay 網(wǎng)絡(luò)故障：SkeletonHunter Analyzer 通過中繼數(shù)據(jù)轉(zhuǎn)發(fā)過程，系統(tǒng)驗證數(shù)據(jù)包是否正確轉(zhuǎn)發(fā)到目的地或是否存在循環(huán)路由。當(dāng)檢測到不可達(dá)時，可在斷點(diǎn)處精確定位故障 Overlay 鏈路。若數(shù)據(jù)包被轉(zhuǎn)發(fā)至已經(jīng)訪問過的組件，則判斷轉(zhuǎn)發(fā)規(guī)則存在錯誤，形成路由循環(huán)。

物理網(wǎng)絡(luò)故障：SkeletonHunter 采用網(wǎng)絡(luò)掃描技術(shù)對可能發(fā)生故障的物理鏈路進(jìn)行投票篩選。此外，每個物理機(jī)部署 Agent 程序，通過 Traceroute 探測實(shí)現(xiàn)底層路徑分析，與 R-Pingmesh 和007 類似。

驗證 NIC：進(jìn)一步驗證 NIC，此過程涉及人工操作。物理機(jī) Agent 將卸載至 NIC 的 OVS Flow Table 進(jìn)行轉(zhuǎn)存，初步檢測網(wǎng)絡(luò)間的配置一致性，但可能導(dǎo)致臨時性的網(wǎng)絡(luò)性能下降，但對確保網(wǎng)絡(luò)配置正確性至關(guān)重要。若未檢測到不一致情況，則需人工核查 NIC 與 OVS 的配置以定位故障。

通過上述方式，SkeletonHunter 能有效定位 Overlay 與 Underlay 網(wǎng)絡(luò)故障，并將其分類歸因于物理交換機(jī)、NIC 網(wǎng)卡、虛擬交換機(jī)或主機(jī)配置等問題。

實(shí)際上，作者也曾遇到 Overlay 和 Underlay 同時出現(xiàn)問題的案例。例如，底層 NIC 的異常行為可能導(dǎo)致 Overlay 虛擬交換機(jī)配置錯誤，進(jìn)而加劇網(wǎng)絡(luò)故障。此類情況下只能依靠領(lǐng)域知識與經(jīng)驗進(jìn)行人工干預(yù)。

五、關(guān)鍵結(jié)果 & 局限性

在 4K 個物理節(jié)點(diǎn)的生產(chǎn)集群部署，每個節(jié)點(diǎn) 8 個 RDMA NIC（200 Gbps 或 400 Gbps），128 Core，2TB 內(nèi)存。每個 NIC 都運(yùn)行在 SR-IOV 模式，包含 128 個 VF（Virtual Function）。從 2024 年 3 月到 8 月，共 6+ 月，涉及 2M+ 任務(wù)。

5.1 關(guān)鍵結(jié)果

如下圖 Table 1 所示總結(jié)了 SkeletonHunter 檢測到的代表性網(wǎng)絡(luò)問題，所有問題可以歸納為 19 種不同類型，主要涉及模型訓(xùn)練的 6 個核心組件：

• 物理交換機(jī)
• NIC 網(wǎng)卡
• 主機(jī)板卡
• 虛擬交換機(jī)
• 容器運(yùn)行時
• 配置項

鏈路/交換機(jī)異常：針對主機(jī)間網(wǎng)絡(luò)出現(xiàn)的問題（問題 1-4），SkeletonHunter 能篩選所有異常探測結(jié)果，并采用網(wǎng)絡(luò)掃描技術(shù)精準(zhǔn)定位故障設(shè)備。大多數(shù)鏈路/交換機(jī)異常可通過對應(yīng)交換機(jī)的告警日志即時驗證，從而快速確定根本原因。

主機(jī)相關(guān)異常：實(shí)踐經(jīng)驗表明（問題 5-13），多種因素可能導(dǎo)致主機(jī)側(cè)異常。出現(xiàn)時立即隔離故障主機(jī)/模塊以消除其對模型訓(xùn)練的影響。如下圖 Figure 18 所示，展示了一個生成環(huán)境遇到的典型案例。90s 前，兩個容器 NIC 之間的時延穩(wěn)定在 16us 左右；90s 后，時延上升到 120us 左右，Ping 數(shù)據(jù)包出現(xiàn)輕微丟包（< 0.1%）。

• 通過統(tǒng)計校驗，SkeletonHunter 判定該時延存在異常。
• SkeletonHunter 最初并未發(fā)現(xiàn) Overlay/Underlay 網(wǎng)絡(luò)問題，因此轉(zhuǎn)存了 NIC Flow Table。
• 隨后檢測到 Overlay 虛擬化 Flow Table 存在不一致性，立即隔離了該 NIC。
• 60s 后 NIC 恢復(fù)正常，所有指標(biāo)回歸常態(tài)。
• 深入分析發(fā)現(xiàn)，該問題源于 NIC 未能及時更新流計數(shù)器，致使控制平面將數(shù)據(jù)流判定為非活躍狀態(tài)并從 NIC 中移除，導(dǎo)致相關(guān)數(shù)據(jù)包轉(zhuǎn)由軟件棧處理從而產(chǎn)生顯著更高延遲。

虛擬交換機(jī)/容器異常。軟件組件（如虛擬交換機(jī)、容器及其相關(guān)配置）也可能成為可靠性問題的根源（問題 14-19），不過通過重啟或重新初始化相應(yīng)軟件組件即可快速解決此類問題。SkeletonHunter 通過這種方式將通常需要數(shù)小時的完整測試壓縮至分鐘級，直接執(zhí)行恢復(fù)流程，顯著降低了運(yùn)維成本。

5.2 局限性

5.2.1 用戶負(fù)載不確定性

SkeletonHunter 設(shè)計的核心假設(shè)是：大模型訓(xùn)練流量具有稀疏且規(guī)則的空間分布和周期性突增的時間模式。但這一假設(shè)并非對所有用戶負(fù)載都成立，比如：

• 調(diào)試或測試任務(wù)：用戶只是調(diào)試模型或者調(diào)試集合通信庫，可能導(dǎo)致 SkeletonHunter 的推斷錯誤。
• 非標(biāo)準(zhǔn)并行策略：EP、多模態(tài)訓(xùn)練、異步訓(xùn)練等，可能打破原有稀疏性模式，導(dǎo)致探測矩陣過大或失敗。
• 未來模型演進(jìn)：可能引入未知的并行模式，導(dǎo)致 SkeletonHunter 無法識別，適用性不足。

5.2.2 誤報 & 漏報

SkeletonHunter 還無法覆蓋 GPU 之間及 GPU 和 PCIe 間的連接問題 —— 這類問題與網(wǎng)絡(luò)無關(guān)，屬于硬件層面，只能通過其他硬件監(jiān)控工具進(jìn)行檢測（比如 DCGM 或 dmesg 日志）。

此外，SkeletonHunter 自身的問題也可能導(dǎo)致誤報，為了精確測量端到端時延，SkeletonHunter 采用精密時間協(xié)議消除時鐘漂移，這要求 Agent 及時響應(yīng)探測請求，但實(shí)踐中多次遇到 Agent 程序崩潰導(dǎo)致無法響應(yīng)探測的情況，致使 SkeletonHunter 錯誤地將對應(yīng)鏈路判斷為故障并出發(fā)報警。

5.2.3 樂觀假設(shè)的局限性

SkeletonHunter 使用 “樂觀解耦” 策略：假設(shè) Overlay（軟件）和 Underlay（硬件）故障不會同時發(fā)生，也不會互相影響。但作者也提到，現(xiàn)實(shí)中它們是可能同時出現(xiàn)的，這類問題只能人工排查。

5.2.4 探測機(jī)制的局限性

利用 Ping 進(jìn)行連通性測試，可能無法暴露某些真實(shí)通信路徑的問題。不過 Ping 探測也確實(shí)在監(jiān)控開銷與監(jiān)控精度之間得到平衡。

5.2.5 部署與演化成本

SkeletonHunter 依賴 Sidecar 容器部署 Agent，會帶來一定的開銷，好處是實(shí)現(xiàn)了 Agent 部署更新與訓(xùn)練任務(wù)更新的解耦。

除此之外，由于大規(guī)模模型訓(xùn)練場景的快速發(fā)展，基礎(chǔ)設(shè)施（如 GPU、NIC 及數(shù)據(jù)中心拓?fù)浣Y(jié)構(gòu)）與訓(xùn)練模型也會持續(xù)迭代，這也要求 SkeletonHunter 系統(tǒng)必須不斷升級，作者聲稱完成了 20+ 次的更新，相應(yīng)的維護(hù)成本也會比較大。

六、參考鏈接

1. ??https://ennanzhai.github.io/pub/sigcomm25-skeletonhunter.pdf??
2. ??https://ennanzhai.github.io/pub/sigcomm24-hpn.pdf??

本文轉(zhuǎn)載自??AI閑談??，作者：AI閑談