53 papers · 11 topics
53 篇 · 11 個主題
Research digests研究導讀
One recent paper per page, from SIGCOMM, NSDI, ISCA and EuroSys 2024–2026. Each topic says which chapter to finish first, and its overview page compares the papers in it.每頁一篇近期論文，來自 2024–2026 年的 SIGCOMM、NSDI、ISCA 與 EuroSys。每個主題都標明要先讀完哪一章，主題總覽頁則比較同組的論文。
Inside the server伺服器內部 · Workloads and traces工作負載與追蹤 · Parallelism and MoE平行化與 MoE · Collective communication集體通訊 · Topology and optics拓樸與光學 · Load balancing and path monitoring負載平衡與路徑監測 · Transport and congestion control傳輸層與壅塞控制 · Checkpoints and the front end檢查點與前端網路 · Failures and diagnosis故障與診斷 · Sharing and simulation共用與模擬 · Whole-network designs整體網路設計
No digest matches.沒有符合的導讀。
Inside the server伺服器內部
- FabricPerfSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘FabricPerf: Measuring NIC-less Scale-Up Network through GPU Communication Kernel ProfilingFabricPerf：以 GPU 通訊 kernel 剖析量測沒有 NIC 的 scale-up 網路 · University of Hong KongExplain why NVLink has no NIC counters to read, how FabricPerf times transfers inside NCCL's kernels, and what its channel and L2 findings mean for tuning.說明為什麼 NVLink 沒有 NIC 計數器可讀、FabricPerf 如何在 NCCL 的 kernel 內為傳輸計時，以及它對 channel 與 L2 的發現對調校有什麼意義。
- InfiniteHBDSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘InfiniteHBD: Building Datacenter-Scale High-Bandwidth Domain for LLM with Optical Circuit Switching TransceiversInfiniteHBD：以光路交換光模組為 LLM 打造資料中心規模的高頻寬域 · Peking University, StepFun, LightelligenceExplain why switch-based scale-up domains stay small and fragment under faults, and how a switch inside each transceiver builds rings of any size around failed nodes.說明為什麼以交換器為核心的 scale-up 域規模有限、遇到故障會碎片化，以及光模組內的開關如何繞過故障節點，組出任意大小的環。
- PingPointSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Understanding and Profiling the Accelerator Chiplet Network Using PingPoint以 PingPoint 理解並剖析加速器的 chiplet 網路 · University of Wisconsin–MadisonExplain why an MI300X package is itself a network, how PingPoint's in-kernel pings find its congested links, and why fixed routes make placement the fix.說明為什麼一顆 MI300X 封裝本身就是一個網路、PingPoint 如何用 kernel 內的 ping 找出壅塞的鏈路，以及為什麼固定的路由讓「配置」成為解法。
Workloads and traces工作負載與追蹤
- AcmeNSDI 2024 · 10 minNSDI 2024 · 10 分鐘Characterization of Large Language Model Development in the Datacenter資料中心內大型語言模型開發的特性分析 · Shanghai AI Laboratory, Nanyang Technological University, Peking University, Shanghai Jiao Tong University, SenseTime, CUHKExplain what six months of traces from a 4,704-GPU LLM datacenter say about its network: which jobs it serves, why its NICs look idle, and what failures cost.說明一座 4,704 顆 GPU 的 LLM 資料中心六個月的紀錄對其網路透露了什麼：它服務哪些任務、為什麼 NIC 看起來閒著，以及故障的代價。
- HermodSIGCOMM 2025 (short paper) · 10 minSIGCOMM 2025 (short paper) · 10 分鐘Coflow Scheduling for LLM TrainingLLM 訓練的 coflow 排程 · HKUST, USTCExplain what a coflow is, where the coflows of an MoE training job collide, and how Hermod's key (micro-batch, type, layer) decides which goes first.說明什麼是 coflow、MoE 訓練任務的 coflow 在哪裡相撞，以及 Hermod 的鍵值（micro-batch、類型、層）如何決定誰先走。
Parallelism and MoE平行化與 MoE
- BubblesNSDI 2026 · 11 minNSDI 2026 · 11 分鐘Attack of the Bubbles: Straggler-Resilient Pipeline Parallelism for Large Model Training氣泡來襲：能抵抗 straggler 的大型模型訓練管線平行 · HKUST, Alibaba GroupExplain why one slow pipeline link costs more than its delay, compute how much delay a schedule absorbs, and follow how PipeMorph re-plans warm-up and moves sends to the CPU.說明為何一條變慢的管線鏈路造成的損失超過延遲本身，算出排程能吸收多少延遲，並理解 PipeMorph 如何重新規劃暖機、把傳送交給 CPU。
- ByteScaleSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘ByteScale: Communication-Efficient Scaling of LLM Training with a 2048K Context Length on 16384 GPUsByteScale：在 16384 顆 GPU 上以高通訊效率擴展 2048K 上下文長度的 LLM 訓練 · Peking University, ByteDance Seed, Shanghai Jiao Tong UniversityExplain why a fixed context-parallel ring wastes traffic on short sequences, when a ring hides its transfers behind attention, and how ByteScale sizes rings per sequence and balances ranks.說明為何固定的上下文平行環會在短序列上浪費流量、環在什麼條件下能把傳輸藏在 attention 後面，以及 ByteScale 如何逐序列決定環的大小並平衡各 rank。
- DeepSeek-V3ISCA 2025 · 11 minISCA 2025 · 11 分鐘Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI ArchitecturesDeepSeek-V3 的洞見：擴展的挑戰，以及對 AI 架構硬體的反思 · DeepSeek-AIExplain how DeepSeek-V3 fits MoE all-to-all onto H800 nodes with weak NVLink: node-limited routing, NVLink forwarding, FP8 dispatch and an eight-plane two-tier fat-tree, and what was measured.說明 DeepSeek-V3 如何把 MoE 的 all-to-all 放進 NVLink 被削弱的 H800 節點：節點受限路由、NVLink 轉送、FP8 dispatch 與八平面兩層 fat-tree，以及實際量到了什麼。
- MegaScale-MoEEuroSys 2026 · 11 minEuroSys 2026 · 11 分鐘MegaScale-MoE: Large-Scale Communication-Efficient Training of Mixture-of-Experts Models in ProductionMegaScale-MoE：在生產環境中以高通訊效率大規模訓練混合專家模型 · Peking University, ByteDance SeedExplain how MegaScale-MoE keeps every MoE layer on NVLink, which bytes still cross the NICs, and how sequence and expert parallelism, overlap and BF16 gradients cut communication.說明 MegaScale-MoE 如何讓每個 MoE 層都留在 NVLink 上、哪些位元組仍要經過 NIC，以及序列與專家平行、重疊與 BF16 梯度如何削減通訊。
- ACCLEPSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Balancing and Beyond: Communication-Centric Optimizations in Expert Parallelism平衡與超越：專家平行中以通訊為核心的最佳化 · Alibaba CloudExplain why skewed experts and duplicate copies slow the expert-parallel all-to-all of MoE serving, and how balancing, one copy per host and per-expert overlap cut it.說明為什麼偏斜的專家負載與重複的複本會拖慢 MoE 服務中的專家平行 all-to-all，以及平衡、每台主機一份複本與逐專家重疊如何把它縮短。
- UBEPSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘UBEP: Re-architecting Expert Parallelism Communication Library for Production SuperpodsUBEP：為生產環境 superpod 重新架構專家平行通訊函式庫 · Nanjing University, HuaweiExplain why MoE dispatch inside a superpod is limited by barriers and hop distance rather than bandwidth, and how UBEP splits cores, balances hops and fuses flags into data.說明為何 superpod 內的 MoE dispatch 受限於 barrier 與跳數距離而非頻寬，以及 UBEP 如何拆分核心、平衡跳數，並把旗標融入資料。
Collective communication集體通訊
- OptCCLSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘OptCCL: Scalable Synthesis of Optimal Collective Communication AlgorithmsOptCCL：可擴展地合成最佳集體通訊演算法 · Cornell UniversityExplain why step-based schedule solvers trade optimality for scale, and how OptCCL routes first, schedules second and solves one subproblem per class of identical GPUs.說明以時間步建模的排程求解器為何只能在最佳性與規模之間二選一，以及 OptCCL 如何先決定路由、再排程，並對每一類相同的 GPU 只解一個子問題。
- TheseusSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Theseus: Runtime-Adaptive GPU Collective Communication with Hot-Swappable SchedulesTheseus：以可熱抽換排程實現執行期自適應的 GPU 集體通訊 · Peking University, UCAS, NUS, Alibaba CloudExplain how Theseus swaps a collective's schedule mid-job: who signals the change, how all GPUs agree, and what a switch costs.說明 Theseus 如何在任務執行中更換集體操作的排程：由誰發出訊號、所有 GPU 如何取得一致，以及一次切換的代價。
- TrivanceSIGCOMM 2026 · 10 minSIGCOMM 2026 · 10 分鐘Trivance: Latency-Optimal AllReduce by Shortcutting Multiport NetworksTrivance：在多埠網路上抄捷徑，達到延遲最佳的 AllReduce · Weizenbaum Institute & TU Berlin, Purdue UniversityExplain how Trivance uses both ports of a ring node to finish an all-reduce in ⌈log₃ n⌉ steps, and what it pays in link load and synchronization.說明 Trivance 如何同時使用環上節點的兩個埠，以 ⌈log₃ n⌉ 步完成 all-reduce，以及它在鏈路負載與同步上付出的代價。
- ZipCCLSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘ZipCCL: Efficient Lossless Data Compression of Communication Collectives for Accelerating LLM TrainingZipCCL：以高效無損資料壓縮加速 LLM 訓練的集體通訊Explain when lossless compression speeds up a collective: how ZipCCL codes BF16 exponents in 3 bits, keeps every sum local, and why the link's speed decides the answer.說明無損壓縮何時能加速集體通訊：ZipCCL 如何用 3 位元編碼 BF16 指數、把每次加總留在本地，以及為何鏈路速度決定答案。
- DynamiQSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘DynamiQ: Accelerating Gradient Synchronization using Compressed Multi-hop All-reduceDynamiQ：以壓縮的多跳 all-reduce 加速梯度同步 · UCL, VMware Research by Broadcom, HarvardExplain why compression error grows hop by hop in a ring all-reduce, and how DynamiQ's agreed bit widths, re-fitted scales and correlated rounding keep accuracy near BF16.說明壓縮誤差為何在環形 all-reduce 中逐跳累積，以及 DynamiQ 如何以一致的位元寬度、每跳重新擬合的尺度與相關捨入，讓精度接近 BF16。
- EPICSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘EPIC: Abstraction and Polymorphism of In-Network Collectives on EthernetEPIC：乙太網路上網內集體通訊的抽象化與多型實現 · Peking University, USTC, NUDT, ICT CAS, BUPT, Infrawaves, Lenovo Research, Centec, Alibaba CloudExplain how EPIC lets switches from different vendors add gradients for unmodified RoCE hosts: one tree abstraction, three switch modes, and what an 8-rank testbed measured.說明 EPIC 如何讓不同廠商的交換器為未修改的 RoCE 主機相加梯度：一個樹狀抽象、三種交換器模式，以及 8 個 rank 的測試平台量到了什麼。
- HyNASIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘HyNA: Taming Tail Latency in MoE Training with Hybrid Switch SiliconHyNA：以混合式交換器晶片馴服 MoE 訓練的尾端延遲 · Beijing University of Posts and TelecommunicationsExplain how HyNA keeps in-switch gradient sums on time: an INT32 fast path, on-chip RISC-V cores for collisions and overflows, FP32 slot promotion, and what an FPGA prototype measured.說明 HyNA 如何讓交換器內的梯度加總準時完成：INT32 快速路徑、處理碰撞與溢位的晶片上 RISC-V 核心、FP32 槽升級，以及 FPGA 原型量到了什麼。
- PReCCLSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘PReCCL: Performant and Resilient Collective Communication via Integrated Inband Telemetry and Workload ReallocationPReCCL：結合頻內遙測與工作量重新分配的高效能、具韌性集體通訊 · Tsinghua University, Zhongguancun Laboratory, Alibaba CloudExplain how PReCCL measures each NCCL channel's progress from inside the library and moves bytes away from a slow or failed path at every collective boundary.說明 PReCCL 如何在函式庫內部量測每個 NCCL channel 的進度，並在每次集體操作的邊界，把位元組從變慢或故障的路徑移走。
- NCCLXSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Connecting 100K+ GPUs: Building the Communication Stack for Large-Scale LLM Training連接 10 萬顆以上 GPU：為大規模 LLM 訓練打造通訊堆疊 · Meta; Harvard UniversityExplain why stock NCCL strains at 100K GPUs, and how Meta's NCCLX moves data without staging copies, caps bytes in flight per distance class, and starts up faster.說明原版 NCCL 為何在 10 萬顆 GPU 時吃不消，以及 Meta 的 NCCLX 如何不經暫存複製就搬運資料、依距離類別限制在途位元組，並加快啟動。
- SyCCLSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘SyCCL: Exploiting Symmetry for Efficient Collective Communication SchedulingSyCCL：利用對稱性實現高效的集體通訊排程 · Alibaba Cloud, Tsinghua UniversityExplain how SyCCL uses symmetry in collectives and fabrics to cut schedule synthesis from hours to seconds, and why its testbed gains shrink to a few percent per step.說明 SyCCL 如何利用集體操作與網路的對稱性，把排程合成從數小時縮短到數秒，以及為什麼它在測試平台上的增益到了每個訓練步驟只剩幾個百分點。
- ResCCLSIGCOMM 2025 · 10 minSIGCOMM 2025 · 10 分鐘ResCCL: Resource-Efficient Scheduling for Collective CommunicationResCCL：集體通訊的資源高效排程 · Northeastern University, SIAT CAS, Alibaba CloudExplain why one thread block per connection wastes SMs and link time, and how ResCCL schedules primitives and shares thread blocks to fix it.說明為何每條連線配一個 thread block 會浪費 SM 與鏈路時間，以及 ResCCL 如何排程原語並共用 thread block 來解決。
- TE-CCLSIGCOMM 2024 · 11 minSIGCOMM 2024 · 11 分鐘Rethinking Machine Learning Collective Communication as a Multi-Commodity Flow Problem把機器學習的集體通訊重新看成多商品流問題 · University of Pennsylvania, Microsoft Research, University of Washington, OpenAIExplain how TE-CCL writes a GPU collective as a multi-commodity flow on a time-expanded graph, why copy forces integer variables, and what hours of solver time buy on real GPUs.說明 TE-CCL 如何把 GPU 集體操作寫成時間展開圖上的多商品流、為什麼「複製」逼出整數變數，以及數小時的求解時間在真實 GPU 上換到什麼。
- MCCSSIGCOMM 2024 · 11 minSIGCOMM 2024 · 11 分鐘MCCS: A Service-based Approach to Collective Communication for Multi-Tenant CloudMCCS：以服務化方式為多租戶雲提供集體通訊 · Duke University, MetaExplain why a cloud tenant's NCCL cannot choose a good ring, and how a provider-run collective service reorders rings, pins paths and prioritizes tenants while jobs run.說明雲端租戶的 NCCL 為何選不出好的環，以及由供應商執行的集體通訊服務如何在任務執行中重排環、固定路徑並為租戶設定優先順序。
- FASTNSDI 2026 · 11 minNSDI 2026 · 11 分鐘FAST: An Efficient Scheduler for All-to-All GPU CommunicationFAST：高效率的 GPU All-to-All 通訊排程器 · Carnegie Mellon University, MangoBoost, University of Washington, University of PennsylvaniaExplain how FAST schedules each skewed MoE all-to-all in microseconds: balance over NVLink, then one-to-one Birkhoff stages that keep the busiest server busy.說明 FAST 如何在微秒內為每一次偏斜的 MoE all-to-all 排程：先用 NVLink 平衡，再用一對一的 Birkhoff 階段讓最忙的伺服器一直保持忙碌。
- AutoCCLNSDI 2025 · 10 minNSDI 2025 · 10 分鐘AutoCCL: Automated Collective Communication Tuning for Accelerating Distributed and Parallel DNN TrainingAutoCCL：自動調校集體通訊，加速分散式與平行 DNN 訓練 · University of Science and Technology of China, Microsoft ResearchExplain which NCCL knobs set a collective's speed, why the best setting moves when a GEMM runs beside it, and how AutoCCL finds it during training.說明哪些 NCCL 參數決定集體操作的速度、為何旁邊跑著 GEMM 時最佳設定會移動，以及 AutoCCL 如何在訓練中把它找出來。
- SwingNSDI 2024 · 10 minNSDI 2024 · 10 分鐘Swing: Short-cutting Rings for Higher Bandwidth AllreduceSwing：抄捷徑繞過環，提升 allreduce 頻寬 · Sapienza University of Rome, ETH Zurich, RWTH Aachen UniversityExplain why two all-reduce schedules with equal steps and bytes run at different speeds on a torus, and how Swing's alternating peers cut link sharing.說明為什麼步數與位元組都相同的兩種 all-reduce 排程，在環面上速度不同，以及 Swing 左右交替的夥伴如何減少鏈路共用。
Topology and optics拓樸與光學
- ZCubeSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘From ATOP to ZCube: Automated Topology Optimization Pipeline and A Highly Cost-Effective Network Topology for Large Model Training從 ATOP 到 ZCube：自動化拓樸最佳化流程，與一個極具成本效益的大模型訓練網路拓樸 · Tsinghua University, Zhongguancun Laboratory, ByteDance, Harnets.AIExplain how a topology search found ZCube, why two half-speed NIC ports put every GPU pair within two switches, and what a 16-GPU testbed measured.說明拓樸搜尋如何找到 ZCube、為何兩個半速 NIC 埠讓每對 GPU 最多相隔兩台交換器，以及 16 顆 GPU 的測試平台量到了什麼。
- BSTSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Balanced Sparse Tree: A Scalable Network Topology for Large Language Models平衡稀疏樹：一種適用於大型語言模型的可擴展網路拓樸 · Huawei, Shanghai Jiao Tong University, UNSW SydneyExplain how a block design lets each spine serve only δ ToRs while every ToR pair still shares one spine, and what that sparsity costs on 24 NPUs.說明區組設計如何讓每台 spine 只服務 δ 台 ToR、而每對 ToR 仍共用一台 spine，以及這種稀疏在 24 顆 NPU 上的代價。
- MixNetSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘MixNet: A Runtime Reconfigurable Optical-Electrical Fabric for Distributed Mixture-of-Experts TrainingMixNet：用於分散式混合專家（MoE）訓練、可在執行期重新配置的光電混合網路 · HKUST, MIT, Peking University, Meta, et al.Explain how MixNet re-wires a regional optical switch inside every MoE layer, why expert compute can hide the switch, and why NIC re-link time is the catch.說明 MixNet 如何在每個 MoE 層內重新接線區域光交換器、為何專家計算能藏住切換，以及為何 NIC 重新連線時間才是真正的問題。
- OpusSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Opus: Photonic Rail-Optimized Fabric in ML DatacentersOpus：機器學習資料中心裡的光子 rail-optimized 網路 · Cornell University, University of MichiganExplain how Opus makes each rail one optical circuit switch, why parallelism phases leave idle windows, and when a reconfiguration fits inside them.說明 Opus 如何把每條 rail 變成一台光電路交換器、為何平行化階段之間留有閒置窗口，以及重新配置何時放得進這些窗口。
- HarvestSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Harvest: Adaptive Photonic Switching Schedules for Collective Communication in Scale-up DomainsHarvest：在 scale-up 域中為集體通訊自適應安排光子交換的時程 · Purdue University, Microsoft ResearchExplain when a photonic scale-up fabric should re-wire during one collective, how Harvest's dynamic program finds the steps, and why rings never gain.說明光子 scale-up 網路在一次集體操作中何時該重新接線、Harvest 的動態規劃如何找出那幾步，以及為何環演算法永遠得不到好處。
Load balancing and path monitoring負載平衡與路徑監測
- SGLBSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘SGLB: Scalable and Robust Global Load Balancing in Commodity AI ClustersSGLB：商用 AI 叢集中可擴展且穩健的全域負載平衡 · ByteDance, Peking University, Shanghai Jiao Tong University, BroadcomExplain why a switch that sees only its own queues still picks congested paths, what remote state SGLB's switches exchange, and how it reroutes around a failed link in microseconds.說明為何只看自己佇列的交換器仍會選到壅塞的路徑、SGLB 的交換器彼此交換哪些遠端狀態，以及它如何在微秒內繞過故障鏈路。
- StellarSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘Alibaba Stellar: A New Generation RDMA Network for Cloud AIAlibaba Stellar：面向雲端 AI 的新一代 RDMA 網路 · Alibaba CloudExplain how Alibaba's own RNIC sprays each RDMA connection over 128 paths under one congestion window and a 250 µs timer, and how it virtualizes RDMA for secure containers.說明阿里自研的 RNIC 如何在一個壅塞窗口與 250 µs 計時器之下，把每條 RDMA 連線噴灑到 128 條路徑，以及它如何為安全容器虛擬化 RDMA。
- PSN-PATHSIGCOMM 2026 · 10 minSIGCOMM 2026 · 10 分鐘PSN-PATH: When Multipath RDMA Meets Lossy NetworksPSN-PATH：當多路徑 RDMA 遇上有損網路Explain why a NIC that sprays one queue pair over several paths mistakes late packets for lost ones, and how PSN-PATH's lanes tell the two apart.說明把一個 queue pair 噴灑到多條路徑的 NIC 為何把晚到的封包誤當遺失，以及 PSN-PATH 的「通道」如何分辨兩者。
- R-PingmeshSIGCOMM 2024 · 10 minSIGCOMM 2024 · 10 分鐘R-Pingmesh: A Service-Aware RoCE Network Monitoring and Diagnostic SystemR-Pingmesh：服務感知的 RoCE 網路監控與診斷系統 · BUPT, Purple Mountain Laboratories, Douyin Vision / ByteDanceExplain how R-Pingmesh decides within 20 seconds whether a slow training job is the network's fault, and which RNIC or switch link is to blame.說明 R-Pingmesh 如何在 20 秒內判斷訓練任務變慢是不是網路的錯，以及該怪哪一張 RNIC 或哪一條交換器鏈路。
- OmniPath PingSIGCOMM 2026 · 10 minSIGCOMM 2026 · 10 分鐘OmniPath Ping: Active Network Measurement in the Era of Packet SprayingOmniPath Ping：封包噴灑時代的主動網路量測 · Peking University, Huawei TechnologiesExplain why packet spraying breaks Ping and Traceroute, and how switches that copy one probe onto every path and merge the answers restore diagnosis.說明封包噴灑為何讓 Ping 與 Traceroute 失效，以及交換器如何把一個探測封包複製到每條路徑、再合併回覆，讓診斷恢復可行。
Transport and congestion control傳輸層與壅塞控制
- OdinSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘Odin: Rethinking Congestion Control under All-to-All TrafficOdin：重新思考 All-to-All 流量下的壅塞控制 · Central South University, ByteDanceExplain why MoE all-to-all traffic defeats per-port congestion control on lossless RoCE, and how Odin's buffer flag, NIC ratio and compensation step change an HPCC-style controller.說明 MoE 的 all-to-all 流量為何讓無損 RoCE 上逐埠的壅塞控制失效，以及 Odin 的緩衝旗標、NIC 比值與補償步驟如何改變 HPCC 式的控制器。
- DCPSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘Revisiting RDMA Reliability for Lossy Fabrics重新檢視有損網路上的 RDMA 可靠性 · HKUST, HuaweiExplain why RoCE needed a lossless fabric, what breaks when packets drop or reorder, and how DCP's trimmed headers and precise retransmission fix it, with IRN as the reference.說明 RoCE 為何需要無損網路、封包遺失或亂序時哪裡會壞掉，以及 DCP 如何以修剪後的標頭與精確重傳修好它，並以 IRN 作為對照。
- FalconSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘Falcon: A Reliable, Low Latency Hardware TransportFalcon：可靠、低延遲的硬體傳輸層 · GoogleExplain how the Falcon NIC transport recovers from loss and reordering without PFC or switch help, separates fabric from host congestion, and avoids the connection-count cliff of RoCE NICs.說明 Falcon 網卡傳輸層如何不靠 PFC 或交換器協助就從丟包與亂序恢復、區分網路與主機端的壅塞，並避開 RoCE 網卡在連線數上的效能懸崖。
Checkpoints and the front end檢查點與前端網路
- ByteCheckpointNSDI 2025 · 11 minNSDI 2025 · 11 分鐘ByteCheckpoint: A Unified Checkpointing System for Large Foundation Model DevelopmentByteCheckpoint：為大型基礎模型開發打造的統一檢查點系統 · The University of Hong Kong, ByteDanceExplain how ByteCheckpoint saves training state once and loads it into any parallel layout, and why its stall is under a second while a save still takes 51 s.說明 ByteCheckpoint 如何把訓練狀態存一次就能載入任何平行配置，以及為何它的停頓不到一秒，一次儲存卻仍要 51 秒。
- CheckmateNSDI 2026 · 11 minNSDI 2026 · 11 分鐘Checkmate: Zero Performance Overhead Model Checkpointing via Network Gradient ReplicationCheckmate：以網路梯度複製實現零效能開銷的模型檢查點 · Tufts University, MITExplain how Checkmate copies each iteration's reduced gradients in the switch to CPU shadow nodes, so that every iteration is a checkpoint and the GPUs never stall.說明 Checkmate 如何在交換器裡把每次迭代歸約後的梯度複製給 CPU 影子節點，讓每次迭代都是一個檢查點，GPU 從不停頓。
- DistDPUSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘DistDPU: A Disaggregated DPU Architecture for High-Performance and Cost-Efficient AI CloudsDistDPU：為高效能、具成本效益的 AI 雲端設計的解耦式 DPU 架構 · Fudan University, Tencent, University of MichiganExplain why one DPU per 400G NIC wastes control silicon in an AI cloud, how DistDPU runs nine NICs from one shared control module, and what that costs.說明在 AI 雲端裡每張 400G NIC 配一顆 DPU 為何浪費控制晶片、DistDPU 如何用一個共用的控制模組管理九張 NIC，以及這樣做的代價。
Failures and diagnosis故障與診斷
- SkeletonHunterSIGCOMM 2025 · 10 minSIGCOMM 2025 · 10 分鐘SkeletonHunter: Diagnosing and Localizing Network Failures in Containerized Large Model TrainingSkeletonHunter：診斷與定位容器化大模型訓練中的網路故障 · Tsinghua University, Alibaba Cloud, UIUCExplain how SkeletonHunter infers, from outside the container, which paths a training job uses, probes only those, and places each failure in the overlay, the underlay or the RNIC.說明 SkeletonHunter 如何從容器外推斷訓練任務用了哪些路徑、只探測這些路徑，並把每個故障歸到 overlay、underlay 或 RNIC。
- MinderNSDI 2025 · 11 minNSDI 2025 · 11 分鐘Minder: Faulty Machine Detection for Large-scale Distributed Model TrainingMinder：大規模分散式模型訓練的故障機器偵測 · Tsinghua University, ByteDance, Northeastern University, Harvard UniversityExplain how Minder names the one faulty machine of a training task by comparing machines with each other, and why its alert takes minutes when each call takes seconds.說明 Minder 如何藉由機器之間互相比較，指出訓練任務中那一台故障機器，以及為何每次呼叫只要數秒，警報卻要數分鐘。
- TPU v4 resiliencyNSDI 2024 · 11 minNSDI 2024 · 11 分鐘Resiliency at Scale: Managing Google's TPUv4 Machine Learning Supercomputer大規模的韌性：管理 Google 的 TPUv4 機器學習超級電腦 · GoogleExplain how Google keeps faults away from TPUv4 jobs: placement on any healthy cubes, health checks before and during each job, and routing around a failed optical switch.說明 Google 如何讓故障遠離 TPUv4 任務：把任務放在任何健康的 cube 上、在任務前與任務中做健康檢查，以及繞過失效的光交換器。
Sharing and simulation共用與模擬
- CruxSIGCOMM 2024 · 11 minSIGCOMM 2024 · 11 分鐘Crux: GPU-Efficient Communication Scheduling for Deep Learning TrainingCrux：以 GPU 效率為目標的深度學習訓練通訊排程 · Alibaba CloudExplain how Crux decides whose traffic goes first on a shared link: GPU intensity, path choice, corrected priorities, and compression into a few switch queues.說明 Crux 如何決定共享鏈路上誰的流量先走：GPU 強度、路徑選擇、修正後的優先權，以及壓縮到少數交換器佇列。
- LEVELLERSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘LEVELLER: Fair Communication Scheduling via Progress-Rate Awareness in Multi-Tenant Training ClustersLEVELLER：以進度率感知實現多租戶訓練叢集的公平通訊排程 · China Telecom Cloud Computing Research Institute, BUPT, Temple UniversityExplain how LEVELLER scores each training job by its progress rate and turns the switch priorities that Crux uses toward fairness, and what that costs.說明 LEVELLER 如何以進度率為每個訓練任務評分，把 Crux 所用的交換器優先權轉向公平，以及代價為何。
- MonkeyTreeSIGCOMM 2026 · 11 minSIGCOMM 2026 · 11 分鐘MonkeyTree: Near-Minimal Congestion for Multi-tenant Training via MigrationMonkeyTree：以遷移讓多租戶訓練的壅塞降到接近最小 · MITExplain why ring traffic makes a rack's uplink demand a count of fragmented jobs, why two uplinks suffice for data parallelism, and what one worker migration costs.說明為何環狀流量讓機櫃的上行需求等於被碎片化的任務數、為何資料平行只需兩條上行，以及遷移一個 worker 要付出多少代價。
- SimAINSDI 2025 · 11 minNSDI 2025 · 11 分鐘SimAI: Unifying Architecture Design and Performance Tuning for Large-Scale Large Language Model Training with Scalability and PrecisionSimAI：兼顧可擴展性與精確度，統一大規模大型語言模型訓練的架構設計與效能調校 · Alibaba Cloud, Tsinghua University, Zhongguancun Laboratory, South China University of TechnologyExplain how SimAI predicts a training iteration within 4% of a real 1,024-GPU cluster: real framework and NCCL code, measured kernels, packet-level network, and what each part fixes.說明 SimAI 如何把一次訓練迭代的預測做到與真實 1,024 顆 GPU 叢集相差 4% 以內：真實的框架與 NCCL 程式碼、實測的 kernel、封包級網路，以及每一部分修正了什麼。
- WormholeNSDI 2026 · 11 minNSDI 2026 · 11 分鐘Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding以記憶化與快轉大幅加速大型模型訓練的封包級網路模擬 · Tsinghua University, Zhongguancun Laboratory, HuaweiExplain how Wormhole skips over 99.5% of ns-3's packet events yet stays packet-level: memoize repeated contention, fast-forward steady rates, and count speedup in events.說明 Wormhole 如何略過 ns-3 超過 99.5% 的封包事件，卻仍維持封包級：記住重複的競爭、快轉穩定的速率，並以事件數計算加速。
Whole-network designs整體網路設計
- PegasusSIGCOMM 2026 (Experience track) · 16 minSIGCOMM 2026 (Experience track) · 16 分鐘Pegasus: A Data Center Network for Bare-Metal AI CloudPegasus：裸機 AI 雲的資料中心網路 · Tsinghua University, Tencent, Nanjing University, Shanghai Jiao Tong UniversityExplain how Tencent's bare-metal AI cloud moves load balancing and congestion control into its own NIC, why one DPU manages eight NICs, and what its evidence shows.說明騰訊的裸機 AI 雲如何把負載平衡與壅塞控制搬進自研 NIC、為何一台 DPU 管理八張 NIC，以及它的證據能說明什麼。
- AstralSIGCOMM 2025 · 11 minSIGCOMM 2025 · 11 分鐘Astral: A Datacenter Infrastructure for Large Language Model Training at ScaleAstral：大規模大型語言模型訓練的資料中心基礎設施 · Nanjing University, Tencent, Harvard University, Politecnico di Milano and Queen Mary University of LondonExplain how Tencent's Astral builds a non-oversubscribed 128-port fat tree by grouping tier 2 by rail, why MoE justified the cost, and how it finds failures in minutes.說明騰訊的 Astral 如何依 rail 分組第二層、建出不超額認購的 128 埠 fat tree，為何 MoE 讓這個代價值得付，以及它如何在數分鐘內找到故障。