Themis 用同一路徑的後續封包判斷 RDMA 是否真的掉包
重點
- 訓練叢集
- 訓練叢集可把同一條 RDMA 連線的封包分散到多條上行路徑，減少少數大流量連線撞在同一條鏈路的機會，但最慢工作仍取決於缺包能否及時補齊。
- Themis
- Themis 讓來源交換器按序號固定選路，目的交換器藉由同一路徑的較新封包判斷缺口，保留真正需要的重傳請求，並用小量狀態處理暫時無法判定的請求。
- ConnectX-7
- ConnectX-7 沿用硬體內建的失序寫入與選擇性重傳，因此交換器無須替網卡重排資料，但遇到流尾遺失或重傳再次失敗時，仍可能付出逾時等待的成本。
- Tofino2
- Tofino2 以每條連線的位元圖、路徑進度及鏡射封包換取較少的誤重傳；當連線數、路徑數或共享管線壓力成長時，交換器的可用狀態與處理容量就會決定部署範圍。
分散式訓練每進入一輪 AllReduce，各機器都要送出一批梯度、接收其他機器的資料，等最後一段傳完才能繼續。假設兩台伺服器之間有八條可走的路，交換器用 ECMP 對每條連線雜湊選路：八條路在拓樸上都能通，卻可能有幾條同時塞進多條大流，其他路還很空。一條繁忙上行就足以延後整輪同步。把同一條連線的封包逐包分散，可以把閒置頻寬用起來；快路徑的後送封包也因此會超車。
EuroSys 2026 的 Themis 論文 把這個問題拆成兩半。既有網卡可以把先到的資料寫到正確位置，但看見序號缺口時，仍可能把正常失序當成掉包。Themis 讓目的機架交換器修正「何時請求重傳」：它把目的端缺口跟原定路徑的進度比對，讓正常失序繼續前進，等到有足夠線索才送出 NACK。網卡仍負責資料寫入、重傳與完成通知。
依據 Themis §3–4 重繪。上半部走資料，下半部走 NACK；路徑選擇在來源端，缺口判斷在目的端。
資料可以先寫進記憶體，網卡還是會誤判掉包
以論文採用的 RDMA Write 與 Direct Data Placement 模式為例，資料封包帶有足以定位目的記憶體的資訊。接收網卡看到較晚序號先到，可以把它寫進應有的位置，同時在位元圖記下這一包已到。網卡保存下一個預期的序號 ePSN；如果預期 100，先收到 101，101 的寫入與 100 是否已到是兩件事。等 100 補齊，接收端才把連續接收的進度推到下一個缺口。既有的 Eunomia 分析 說明了位元圖如何支撐這種分工；這次要解的是另一個問題：在網卡已能容忍失序時，誰能判斷應不應該重傳？
論文 §2.3 描述的既有選擇性重傳機制，會在看見失序時對當前 ePSN 送出一次 NACK。單一路徑維持順序時，這個判斷通常合理；逐包分流之後，快路徑上的 101 先到，只能說慢路徑上的 100 還沒到。把 NACK 直接送回去，來源網卡除了多送一包，還可能進入較慢的傳送階段；即使無掉包，也可能同時浪費頻寬與傳送端資料路徑的處理時間。反過來，若交換器一概丟棄 NACK，100 真掉時，網卡通常也不會為同一缺口再發一次，只能等傳送端逾時。兩端都看得見序號，卻都缺少將序號與實際選路對起來的資訊。
交換器用路徑進度把遲到與掉包分開
假設有兩條等價路徑，正常時同一路徑維持順序。來源交換器按 PSN 除以二的餘數選路，偶數走 A、奇數走 B。目的交換器看到缺口 100，即使從未見過 100，也能算出它原定走 A。更大的 Clos 拓樸中，論文 §4.1 以可預測的標頭改寫控制選路；教學用的餘數式代表共同映射，實際部署還須確定雜湊、埠配置與兩端路徑編號能對上。
目的交換器維護兩份不同的紀錄：每條連線的代理位元圖，記下哪些封包已經向 RNIC 送出；每條路徑的最大序號，記下該路最新送出的封包。當 NACK 回到交換器，先查它指的包是否已經送往網卡；如果已送，這個請求多半已過時，便攔住。如果尚未送出，再比對原定路徑是否已送出較晚的包。同一路徑保持順序時，A 的 102 已通過而 100 還沒出現，就有理由讓 NACK 回源。若目前只有 B 的 101 到達，則先留下缺口，等後續封包判定。
依據 Themis 圖 6、7 重繪。代理位元圖回答「是否已送出」，路徑進度回答「原定路徑是否已走過缺口」。
把這套規則走一次。101 從 B 先到，RNIC 把它寫入目的緩衝區並送出 NACK(100)。目的交換器的位元圖尚未標 100，A 也還沒出現比 100 大的封包，於是留下 100 與重建請求所需資訊，丟棄原來的 NACK 封包。若接著是 A 的 100 抵達，暫存請求就清除；101 的資料早已到位，接收端可以繼續推進。若接著抵達的是 A 的 102，交換器用後續封包建立一份新的 NACK(100) 回送，來源網卡重送 100，網卡收到後才推進接收進度。兩種分支下，目的交換器都沒有扣住 101 的資料等 100。
暫存一個缺口就夠用，是因為論文的 RNIC 在同一條連線上只對目前最前面的缺口發 NACK；若新 NACK 指向更後面的缺口，舊缺口已由接收端跨過。這也限制了適用範圍：改用會為多個缺口同時發出請求的傳輸機制時，就不能直接照抄單一暫存欄位。若整輪傳送在缺口之後沒有同路封包，或剩餘封包也全失，交換器拿不到這項證明，傳送端的逾時仍是最後一條恢復路徑。Themis §4.2–4.3
每增加一條路徑，都要付出一筆交換器狀態
把路徑進度放在交換器上，代價跟跨機架連線數、傳送視窗與路徑數一起成長。假設每條連線保存一份 512 位元的邏輯位元圖，以及每條路徑 24 位元的最大 PSN。八條路徑時，每連線裸資料為 64 + 24 = 88 bytes；128 條路徑時為 64 + 384 = 448 bytes。每機架若有 16 張網卡、每張 512 條跨機架連線，則下界分別約 0.69 MiB 與 3.5 MiB。這個假設算例還沒有算暫存 NACK、視窗基準、避免壞路徑的計數器、配置對齊或跨管線副本。實作的位元圖也可能比邏輯視窗更長。若記憶體只以總量計帳，很容易漏掉特定管線的 SRAM 或處理階段先用完的情況。
另一筆代價是等多久才確認掉包。假設一條 QP 穩定送出 100 Gb/s 有效資料、每包 4 KiB、等距輪轉，八條路徑上，同一路徑相鄰兩包的送出間隔約 2.62 µs；128 條路徑時約 41.94 µs。這只是傳送端間隔，實際判定還要加排隊、傳播與控制封包回程。連線若只有 25 Gb/s，兩個值再乘四；短傳輸的最後幾包甚至沒有下一包可等。把更多路徑納入固定輪轉有機會改善容量分散，卻會稀釋各路徑提供後續線索的頻率。真正適合的路徑數應由突發流量、單一 QP 速率與尾端掉包的代價共同決定。
論文原型把來源邏輯放在 ingress、目的邏輯放在 egress，等資料離開佇列、準備送往網卡時才更新代理狀態。這個位置很重要：若在入列時就標記「已送」，封包仍可能在交換器內等待或掉落，交換器卻已經把真 NACK 擋掉。Tofino2 有多條彼此獨立的管線，資料與反向控制封包若走到不同管線，就未必讀得到同一份狀態。論文把控制封包送回與資料共用狀態的 egress，再鏡射到真正的出口。這增加內部處理工作，所以評估容量時要同時看資料 p99、鏡射量和管線資源，而非只看交換器標稱頻寬。Themis §5、表 1
壞路徑要更快繞開，單一路徑上的判斷也會變弱
若 A 路徑完全失效，就不會有 A 的後續封包來證明 100 掉了。Themis 觀察後續封包與暫存缺口的序號距離；差距超過門檻時，即使欠缺同路線索，也回送一個帶路徑避讓訊號的 NACK。來源端先讓本來要走 A 的一批封包改走其他路徑，避讓計數用完後才重新嘗試。正常重傳也可改走替代路徑，減少同一包連續掉在同一段鏈路上的機會。Themis §4.4
這裡的取捨是：讓系統在壞路徑上繼續等，會拖長訓練尾延遲；提早繞開則會破壞序號到路徑的一一對應，讓少量本來只是遲到的封包也被重傳。排隊造成的暫時慢路徑也可能越過同一門檻。上線時可先在單一訓練池做對照，把單路慢化、短時斷線、往返控制封包掉落以及最後一包掉落分開注入；一起觀察錯誤 NACK 比例、逾時比率、重新加入路徑後的尾延遲和訓練每步耗時。未來 1 個月的試部署中若只有平均頻寬上升，p99 collective 時間與逾時卻沒有改善，就應縮小噴灑路徑範圍，或讓該工作回到較保守的選路。
把等待拆成資料、排隊與控制三筆帳
可以拿同一個兩路案例比較緩衝空間。假設慢路比快路多等 20 µs，快路此刻正以 100 Gb/s 把同一條連線的資料送到目的交換器。若交換器必須照順序交付，單一缺口背後就可能先累積約 250 kB，也就是約 61 個 4 KiB 封包。這是有效資料量上限的簡化估算，還沒算每包的標頭與交換器內部單位。如果有 32 條連線同時進入這種狀態，而且每條都符合相同到達速率與差值，逐條相加是約 8 MB；實際能否同時達到還受限於入口和出口總頻寬，不能把這個相加值當成實測。Themis 的交換器只保存序號資訊，先到的資料交給網卡落地；即使控制狀態只占數百 bytes，也仍要確認主機緩衝區、RNIC 位元圖與回覆時點能吸收失序。減少的是交換器等待中的 payload，整條路徑的等待時間並沒有憑空消失。
同一條 100 Gb/s 連線若每一千包出現一次誤重傳，每包都是 4 KiB，單看多送的封包，有效頻寬損失約 0.1%。這個數字可能遠小於工作完成時間的損失，因為 NACK 還會干擾傳送端的流水線和速率。相反地，若抑制了所有 NACK，資料頻寬圖可能很好看，但掉一個尾包就可能讓整批等待 RTO。論文實體測試用 4 ms 的 RTO；只要有一次完整逾時，單看時間就約等於在 100 Gb/s 傳送 50 MB 的時間。測試時因此要分開統計「重傳了多少 bytes」和「一輪多等多久」，才看得出改善是否來自減少誤重傳、縮短真掉包的等待，或只來自路徑分散。
避免把交換器看見的進度當成網卡已完成
以一個網卡到 ToR 的短鏈路錯誤為例，目的交換器可能已把 100 標記為送出，網卡卻沒收到。隨後 101 觸發的 NACK 可能被當成過期請求，這時真正可靠的最後保護仍在端點。驗證時可把掉包位置從 spine 鏈路移到目的網卡前，再比較兩種情境的 NACK 過濾率與 RTO 次數。這能確認交換器正在解的是哪一段路徑，以及哪一段要靠鏈路錯誤監控、端點計數器或較保守的選路。若實際部署做不到把每路進度與 QP 生命週期正確對上，應先讓同一條連線回到既有路徑策略，再修正狀態初始化、清除及路徑變更時的對照方式；不宜在正常流量下等待偶發尾延遲替系統指出錯誤。
原型證明了哪一段，還要自己量哪一段
EuroSys 2026 論文 §6 的實體測試使用八張 ConnectX-7、兩台 Tofino2（虛擬成四個 ToR 與兩個 spine）與 100 Gb/s 鏈路。每張網卡向同群下一站執行 256 MB RDMA Write，量最慢流的完成時間。與同樣在交換器逐包分流的 RNIC 選擇性重傳對照，在啟用 DCQCN 的設定下，作者報告最慢流完成時間縮短 46.5%–77.8%。這證明在這套網卡、鏈路與流量條件下，過濾誤重傳的效果能穿過真實的網卡與交換器資料路徑；還沒有直接量到大型訓練叢集的 GPU 閒置時間。
同篇論文用 256 NIC、200 Gb/s 的 NS-3 模擬補上 collective 比較。相對於 RNIC 選擇性重傳配自適應路由，作者報告最慢一組 AllReduce 完成時間縮短 22.7%–35.4%，AllToAll 縮短 29.3%–47.3%。最慢組的完成時間會影響同步訓練，但加速比例還取決於原本有多少時間卡在通訊。假設每步原為 100 ms，其中 40 ms 是完全未與計算重疊的 collective，若該段縮短 30%，每步變成 88 ms，時間下降 12%，步數吞吐約增加 13.6%；若大部分通訊原已被計算掩蓋，整步收益會更小。這個換算是條件式估算，與原型量測分開。
| 做法 | 最適合的條件 | 主要成本 |
|---|---|---|
| ECMP 或 flowlet 選路 | 連線本來就夠多，或長流內有足夠空檔改道 | 在同步的大流量突發下，可能仍有幾條上行過載 |
| ConWeave 在目的 ToR 重排 | 既有網卡需要較有序的封包流，且目的交換器有緩衝空間 | 等待時要保留實際資料；流量大時需驗證佇列與緩衝壓力 |
| Themis 驗證 NACK | 網卡已能接收失序資料，且兩端交換器可控制選路 | 每條連線的位元圖與路徑進度、管線處理和故障下的誤判成本 |
| 端點原生多路徑傳輸 | 有條件換網卡或調整傳輸層，能讓端點掌握整體路徑資訊 | 硬體／韌體改造，與混用既有網卡的驗證成本 |
2023 年的 ConWeave 已把保持有序送達的工作移到目的 ToR。Themis 再往前問：當網卡能自己放置失序資料，交換器是否只需保存判斷缺口的資訊？這兩種作法的差別會反映在容量規劃：前者要先量等候中的資料量；後者要先量活躍跨機架 QP、每路回報速度，以及有多少 NACK 因為無法判斷而落入逾時。若叢集的主要瓶頸是大量持續掉包、低速短流或不穩定路由，應先確認 Themis 的選路假設在現場成立，再把論文的改善幅度放進訓練容量估算。
證據範圍
本文討論的是論文採用的 RNIC 模式與可程式化交換器。位元圖是交換器送往 RNIC 的代理紀錄，並非網卡已寫入記憶體的獨立證明；主機側鏈路與網卡丟包需要另行驗證。同路徑維持順序是主要判定前提；繞路、鏈路聚合或雜湊變更時須重新驗證。兩組假設算例使用十進位 Gb/s 與二進位 KiB、MiB，沒有模擬實際 ASIC 管線或訓練作業。