在昇騰設備上做分布式訓練時HCCLHuawei Collective Communication Library就是那個藏在底層、負責多卡和跨節點梯度同步的集合通信庫。很多做模型訓練的同學用過它但真正參與過它開發的并不多。這篇東西我想從一個貢獻者的視角把從提 Issue 到 PR 合入的完整鏈路拆開講一遍包括什么樣的 Issue 會被維護者認真看、PR 怎么寫才不用來回折騰十輪、CI 掛了先查哪里、以及 code review 時那些不好意思問出口的潛規則。如果你已經有 C/C 或 Python 基礎想找一個有真實落地場景的開源項目練手HCCL 其實是個比想象中更友好的選擇。這篇文章會從項目背景、Issue 規范、環境準備、PR 流程、CI 調試到合入后的收尾工作逐步帶你把整套流程走通。哪怕你還沒碰過集合通信只要愿意讀代碼、愿意跑測試也能找到自己可以下手的位置。1. 項目畫像先搞清楚 HCCL 到底是什么1.1 它在分布式訓練棧里的位置在聊怎么給 HCCL 貢獻代碼之前先花點時間把項目本身講清楚。HCCL 是昇騰 AI 加速卡上的集合通信庫對標的是 GPU 生態里的 NCCL。訓練大模型時數據并行是最常見的并行策略每張卡算完自己那一份梯度之后需要把梯度同步到所有卡上這個同步動作就是靠集合通信庫來完成的。AllReduce、AllGather、ReduceScatter 這些通信原語就是 HCCL 對外提供的核心能力。你可以把它理解成快遞系統里的分揀中心每張卡都往里面投遞自己的梯度包裹分揀中心負責按照規則重新打包再派送給所有卡。如果分揀中心效率低整個訓練任務都會卡在等待上。這也是為什么集合通信庫的性能優化如此重要——哪怕只提升 10% 的通信效率在大規模訓練里節省的時間成本都是非常可觀的。對貢獻者來說這個位置意味著兩件事一是你寫的代碼會被真實的高性能計算場景使用改動的影響面很直觀二是它涉及的知識面比較寬包括操作系統、網絡協議、硬件拓撲、并發編程但每個方向都不是說你要成為專家才能參與很多任務其實是在已有代碼框架上做增量優化和修補。1.2 代碼倉庫和模塊劃分HCCL 的源碼可以通過公開代碼托管平臺獲取常見的路徑是在 Gitee 或 GitHub 上搜索相關組織下的 HCCL 倉庫。拿到源碼之后你會發現它并不是一個特別龐大的項目但目錄結構劃分得很清晰。核心內容一般集中在通信算子的實現、設備管理、拓撲發現、傳輸鏈路這幾個模塊里。從新人的角度我建議先不要把精力放在底層傳輸鏈路上那個模塊涉及到對硬件驅動的理解排查問題的門檻很高。相對友好的切入點是集合通信算子的上層邏輯、工具腳本、文檔注釋和測試用例。比如你看到某個算子在特定數據大小下性能異常順著調用鏈往下查可能定位到的是內存分配策略或者同步等待邏輯的問題這種問題的修復往往只涉及幾百行代碼但對于理解整個項目幫助極大。順便說一句HCCL 的代碼風格整體比較規整大量使用 C 特性但也保留了不少 C 風格的接口設計。原因很簡單這個庫需要被上層框架比如 PyTorch 的適配層通過 C 接口調用所以對外 API 用 C 接口更穩定內部的實現則用 C 來保證開發效率。1.3 貢獻前的能力準備先潑一盆冷水給 HCCL 貢獻代碼不是會寫 Python 調幾個框架就行的事情。它需要一定的 C/C 功底至少要能讀懂指針、引用、模板這些基礎概念理解多線程和鎖的用法以及具備通過日志和調試工具排查問題的經驗。但也不用被嚇住因為項目里不只是代碼一種貢獻形式。文檔修正、示例代碼、測試補充、Issue 復現驗證這些都是非常有價值的貢獻方式。尤其對于第一次參與開源的人來說從文檔和測試入手熟悉了整個流程之后再碰核心代碼是曲線比較平滑的一條路。環境方面如果你手頭有昇騰設備那當然是最好的可以本地復現并驗證性能改動。如果沒有也可以貢獻一些不依賴硬件的代碼邏輯優化或者在 CI 環境里去跑測試。只不過需要提前說明的是HCCL 的很多測試是依賴真實硬件環境的純軟件模擬環境只能覆蓋一部分功能這個限制對所有貢獻者都一樣不是你一個人的問題。2. 從一條合格 Issue 開始2.1 Issue 不是吐槽區我見過很多新手在 GitHub/Gitee 上提 Issue開頭就是“訓練報錯了求大佬看看”然后附一張模糊的截圖沒有版本號沒有日志沒有復現步驟。這種 Issue 基本不可能得到有效的回復——不是維護者不熱情而是信息不足以定位問題。高質量開源協作的第一步是學會提一條合格的 Issue。一個合格的 HCCL Issue必須包含幾個核心要素問題現象、復現步驟、環境信息、日志信息。現象描述要準確比如“在 8 卡環境執行 AllReduce 時當數據量為 512MB 時性能比預期低 30%”就比“訓練很慢”有用得多。復現步驟要可操作別人按你的步驟能走通。環境信息包括操作系統版本、CANN 版本、HCCL 版本、固件驅動版本、卡型號和拓撲。日志信息則是運行時的報錯輸出、HCCL 日志通常由環境變量控制開關以及必要的堆棧信息。有人可能會覺得我提個 Issue 而已還需要整理這么多東西嗎換個角度想如果你是那個需要花半小時甚至更久去復現問題的維護者你希望看到什么樣的報告將心比心把信息整理清楚本身就是對維護者勞動的尊重。2.2 一份能加速處理的 Issue 長什么樣我以一個真實的 bug 類 Issue 為例給你拆解一下模板要素標題[Bug] AllReduce 在數據量為 256MB 時觸發段錯誤 環境信息 - 操作系統Ubuntu 20.04.6 LTS - CANN 版本8.0.RC1 - HCCL 版本v1.8.1 - 固件驅動24.1.rc1 - 硬件4 張 Atlas 訓練卡單機單卡環形互聯 復現步驟 1. 編譯 examples/allreduce_benchmark參數配置如下省略具體參數 2. 設置 HCCL_LOGFILE/tmp/hccl.log 環境變量 3. 啟動測試程序數據量設置為 256MB 4. 觀察程序退出碼 期望行為正常完成集合通信并輸出正確結果。 實際行為程序在通信初始化階段崩潰退出碼 -11堆棧顯示在拓撲發現模塊具體報錯粘貼。 日志片段 粘貼關鍵日志避免貼整個文件這個模板的信息密度很高維護者拿到手可以直接開始復現。值得注意的一點是“數據量為 256MB 時崩潰128MB 或 512MB 時正常”這種信息非常關鍵因為它能幫助維護者快速縮小問題范圍——可能涉及內存池分配策略、通信緩沖區的邊界條件或者某個特定數據分片邏輯。另外如果問題涉及性能最好附上基線數據和實測數據的對比說明是在什么條件測的。性能問題比崩潰問題更難處理因為它可能和網絡拓撲、CPU 頻率、PCIe/NVLink/HCCS 鏈路狀態都有關沒有數據的性能 Issue 基本等于大海撈針。2.3 Issue 里的溝通禮儀Issue 提完之后你可能會遇到幾種情況。一種是維護者很快回復“能否提供更多信息”這時你需要及時補充一種是長時間沒人回復這并不一定代表你的問題不重要可能是維護者比較忙也可能是你的 Issue 確實缺少必要信息還有一種情況是有人回復了但是給了一個和你預期不一樣的解釋方向。在 Issue 評論區溝通要保持專業和耐心。不要用“這東西怎么這么難用”這種抱怨語氣直接陳述技術問題就好。如果某個對話已經偏離主題可以禮貌地提醒對方回到問題本身。如果維護者要求你驗證某個修復補丁盡量第一時間去跑然后把結果反饋到評論區——這是建立信任的過程。這里還有一個很容易踩的坑在 Issue 里貼完整的大文件日志。幾萬行的日志會把真正有用的錯誤信息淹沒掉正確做法是先用 grep 過濾掉無關內容只保留報錯前后的關鍵幾十行并在日志片段外簡要標注每部分可能表示的含義。維護者每天要處理大量 Issue信息越聚焦你的問題被解決的優先級就越高。3. 從 Issue 到開發計劃3.1 怎么篩選適合自己的任務不是所有 Issue 都需要你寫代碼。HCCL 的項目維護者通常會給 Issue 打標簽比如 good first issue、help wanted、bug、enhancement 等。如果你是第一次參與建議優先找 good first issue 或者文檔增強類的任務這類任務的技術依賴少評審要求相對寬松能幫你把整個工具鏈跑通。篩選任務的時候有幾點經驗可以分享。首先看 Issue 的創建時間——太老的問題可能已經沒人關注你做了也可能不被接受。其次是看評論區的活躍度如果維護者在此前已經給過一些方向性建議說明這個問題是被認可的你可以在此基礎上展開。第三是評估影響范圍盡量選那些改動文件不超過 10 個、核心邏輯相對獨立的問題。以 HCCL 為例一個對新人比較友好的任務是“補充某個通信原語在異常輸入下的錯誤碼檢查”這種改動通常只需要在 API 入口增加參數校驗邏輯清晰、影響面可控。相比之下“優化某拓撲下 AllReduce 的帶寬利用率”這種任務雖然很有吸引力但往往需要你深入理解硬件拓撲和網絡通信機制調試周期很長不建議拿來做第一個 PR。3.2 認領任務與溝通方式找到合適的 Issue 之后不要直接悶頭開始寫代碼。正確的做法是先在這個 Issue 下面評論說明你想認領這個任務并簡單描述你打算怎么解決。好處有三個一是避免和其他貢獻者撞車讓別人知道這個任務有人在做二是維護者會給你反饋如果方案有問題可以及時調整避免白干三是有溝通記錄作為依據后續你提交 PR 時維護者更容易建立上下文。在評論認領任務時可以簡單描述你的技術背景和計劃時間線比如“我熟悉 C 和內存管理計劃兩周內完成修復并提交 PR”。這種信息能打消維護者對新人執行力的顧慮。但要注意一旦你承諾了時間線最好能真的推進如果有意外延期也應該及時在 Issue 里同步而不是一直沉默。另外一個小技巧認領任務后可以先把相關代碼讀一遍在評論里提出你的初判。比如“經排查問題出現在 topology.c 中的設備發現邏輯可能和 PCIe 鏈路寬度檢測有關”。即使這個判斷不完全正確維護者也會覺得你是真的在做事而不是隨便占個坑。3.3 本地開發環境搭建開發環境搭建是很多新手真正卡住的地方。我的建議是分兩步走先搞定能在本地完成的工作讀代碼、編譯、跑靜態檢查再解決需要硬件資源的工作跑真實通信測試。HCCL 的代碼構建一般依賴 Linux 環境、GCC 編譯器、CMake 和 Python 工具鏈。拿到源碼后按 README 的說明安裝好依賴依次執行配置、編譯、安裝這幾個步驟即可。在配置階段有幾個選項比較重要比如是否啟用測試代碼、日志等級、調試符號等。如果你是做功能開發而非性能調優建議打開調試符號和更詳細的日志輸出方便定位問題。沒有昇騰硬件的情況下依然可以完成編譯驗證但鏈接階段可能會缺少某些底層庫。這種情況下一個可行的替代方案是只編譯與你改動相關的模塊做語法級別的驗證然后把完整的驗證寄托在 CI 上。這個過程雖然不那么順暢但很多開源項目的貢獻者都是這樣工作的——本地環境不完全匹配CI 反而成了最終裁判。綁定硬件環境的測試跑不了還有一個折中方案編寫針對純軟件邏輯的單元測試。比如某個函數負責解析環境變量、計算通信緩沖區大小或者維護內部狀態這種邏輯完全可以在宿主機上寫單元測試跑起來。HCCL 中這一類可以脫離硬件驗證的代碼比你想象的多得多這也是很多新人能夠遠程貢獻的主要原因。4. 寫 PR不只是把代碼推上去4.1 分支與提交規范代碼開發完成后提交 PR 的第一步是在遠端倉庫創建自己的分支。分支命名建議遵循一定的規范比如用 fix/ 開頭表示 bug 修復用 feature/ 表示新功能用 docs/ 表示文檔變更。這樣維護者從分支名就能快速判斷改動的性質。分支創建好之后開發過程中的 commit 信息也要講究。我見過很多 PR 里一個 commit 寫了 800 行改動信息只是“fix bug”這種提交歷史基本沒有可讀性。更好的做法是遵循 Conventional Commits 規范在提交信息里用簡短的類型前綴說明改動類別比如 feat: 新功能、fix: 修復問題、test: 測試相關、docs: 文檔修改。同時一個 commit 盡量只做一件事把邏輯上獨立的修改拆成多個 commit方便 reviewer 逐個審查。Git 操作層面有幾個建議。一是經常拉取主分支的最新代碼及時 rebase 以減少合并沖突二是在提交信息中用祈使句開頭比如 Fix double free in comm buffer而不是 Fixing 或 Fixed三是提交信息正文可以簡單寫清楚為什么做這個修改以及實現的思路但不要寫廢話。4.2 代碼風格與自檢清單在推上遠端之前先在自己的分支上做一輪自檢這種自檢能大幅提高 PR 通過率。以 C 代碼為例重點檢查以下幾項。第一命名是否規范。HCCL 這類底層庫對命名風格有嚴格要求變量名要能清晰表達含義避免 a、b、c 這種無意義命名函數和類的命名要符合項目既有風格不要一種模塊用駝峰、一種用下劃線至少在同一個文件里保持一致。第二邊界條件是否處理。比如你改了一個緩沖區分配邏輯是否考慮了 size 為 0 的情況是否考慮了內存對齊要求是否能處理分配失敗這些邊界條件往往是 bug 的溫床。第三是內存和資源管理。C/C 項目最常見的問題就是內存泄漏、雙重釋放、資源未釋放。如果你改動的代碼涉及動態內存分配仔細檢查每條路徑上資源是否都被正確釋放。對于不熟悉 C 內存管理的同學建議先讀幾遍項目里已有的分配釋放邏輯照葫蘆畫瓢比自由發揮更安全。第四日志是否恰當。HCCL 有自己的日志系統在關鍵路徑和錯誤分支上應該有合理的日志輸出方便線上問題排查。但日志也不能太多每個正常操作都打一條日志會把性能拖垮。第五測試是否充分。如果改動修復了某個 bug至少應該有一個能驗證該 bug 被修復的測試用例。對于性能優化則需要附上優化前后的基準測試結果。4.3 PR 描述怎么寫得讓 Reviewer 秒懂PR 描述是你和 reviewer 溝通的第一份材料它的質量直接決定了 review 的順暢程度。一份好的 PR 描述不需要長篇大論但必須覆蓋幾個核心信息這個 PR 解決什么問題、改動涉及哪些模塊、實現思路是什么、測試結果如何、是否有關聯的 Issue。一個比較實用的模板結構如下## 背景 2~3 句話說清楚為什么要做這個修改關聯的 Issue 編號 ## 改動內容 列出主要改動文件和每個文件的核心變更點 ## 實現思路 簡要說明采用的技術方案為什么選擇這個方案而不是其他方案 ## 測試驗證 本地測試、單測、CI 結果、性能對比數據 ## 影響范圍 這個改動會影響哪些模塊或場景是否涉及接口變更、是否需要升級適配寫 PR 描述的時候要站在 reviewer 的角度去寫。reviewer 可能對你的改動上下文不熟悉你要用最短的時間讓他理解你在做什么、為什么這么做。不要直接拷貝 commit message 到 PR 描述里commit message 是給代碼歷史看的PR 描述是給人看的兩者內容可以有重疊但 PR 描述應該更完整、更有邏輯。還有一點PR 描述里提到的測試結果一定要真實可查不要編造數字。如果某個性能數據是在特定條件下測出來的要如實寫明測試環境和方法。reviewer 大概率會追著你問數據的來源如果數據站不住腳你的信譽會大打折扣。5. 過 CI 和 Code Review 的硬仗5.1 CI 跑哪些東西提交 PR 之后代碼會自動進入 CI 流程。HCCL 的 CI 通常包括編譯檢查、單元測試、靜態代碼掃描、以及依賴于硬件環境的集成測試。你不一定能看到所有 CI 階段但編譯檢查和靜態掃描基本每次都會觸發。CI 失敗是每個貢獻者都會遇到的事情第一次不用慌。最常見的失敗原因有三類編譯錯誤、代碼格式不符合規范、測試用例掛了。編譯錯誤比較直觀順著日志里報錯的文件和行號定位即可。格式問題則需要用項目指定的工具跑一遍自動格式化比如 clang-format 或 astyle 之類格式化完成后再提交。測試用例失敗的情況需要具體分析。如果在本地能復現那就按正常的調試流程走如果本地無法復現則可能是環境差異導致的此時可以在 PR 評論中說明情況并請求維護者協助查看 CI 日志。有些 CI 失敗是因為基礎設施不穩定導致的偶發失敗比如網絡超時、資源調度延遲這種情況下重跑一次就過了但如果是你的代碼引起的重跑多少次都是失敗。想減少 CI 往返次數最好的辦法是在本地盡量復現 CI 的檢查項。比如提前在本地跑單元測試、靜態檢查、格式化校驗確保這些過了再推代碼。CI 每失敗一次你的 PR 合入時間就延后一次而每個維護者一天能處理的 PR 數量是有限的。5.2 面對 review 意見的心態與技術準備Code review 是整個貢獻流程中壓力最大但也最有價值的環節。你的 PR 提交后維護者或社區成員會逐行查看代碼提出修改意見。這些意見可以是針對正確性的嚴重問題也可以是對變量命名的吹毛求疵甚至是對代碼風格的偏執。先說一個最重要的心態建設review 意見不是針對你一個人的它是針對代碼本身的。看到“這里加個空指針檢查”這種意見不要興奮也不要失落把它當作一次技術方案打磨的過程就好。技術準備方面你要能區分不同性質的 review 意見。如果是正確性問題比如并發競爭、內存錯誤、邏輯漏洞這個沒有商量的余地務必認真修改。如果是風格和可讀性意見雖然不強制但建議盡量順從因為維護者比你更了解項目的歷史慣性和后續維護成本。如果是方案層面的討論比如“你為什么會選擇用自旋鎖而不是互斥鎖”這種意見開放度比較高你可以從實際場景和性能測試數據出發據理力爭前提是你的論證有數據支撐。有個經驗可以分享當你在 review 中修改代碼之后一定要在 PR 評論區回復每條意見的處理結果。常見的做法是直接用 GitHub/Gitee 的回復功能加一段“已修復見 commit xxxxxxx”或者“這個建議我不太認同原因是……”。每個意見都有交代reviewer 才能放心地在后續 commit 中只關注新增的改動。5.3 反復修改與歷史清理除非你寫代碼真的行云流水否則一個 PR 經過多輪 review 修改是非常普遍的事情。每輪修改之后你需要在 PR 里追加新的 commit。這里有一個困擾很多新手的問題我改了一輪產生了 3 個新 commit歷史能清理嗎我的建議是分階段處理。在你的 PR 還沒有被 reviewer 大量關注之前可以用 git rebase 把多個小 commit 合并成幾個邏輯完整的 commit讓歷史保持整潔。但當 reviewer 已經在舊 commit 上留過言之后就不要再隨意 rebase 了因為那會讓 review 評論和代碼版本對不上反而增加溝通成本。這個階段你可以通過追加 commit 的方式表達等 PR 合入時平臺一般會默認用 squash merge 的方式把整個 PR 壓成一個 commit這樣最終歷史依然干凈。Git 操作上還有一個注意項rebase 時不要強推git push --force已經公開的 commit如果你用了一定要在 PR 評論里明確告知否則別人本地的分支會變得非常混亂。更穩妥的做法是先 fetch 主分支最新代碼然后 rebase 到最新再強推你的 PR 分支。5.4 合入前最后一道關卡簽署與自評很多開源項目在 PR 正式合入前還有一個輕量級的合規檢查常見的是貢獻者許可協議CLA和開發者原創證書DCO。HCCL 這類商業驅動的開源項目通常都在意這種合規問題因為它涉及代碼的版權歸屬和法律風險。如果合入前提示你需要簽署 CLA不要覺得麻煩這是一條一次性流程填一遍以后所有項目都能通用。DCO 的簽署則更簡單一般只需要在你的 commit message 尾部追加一行 Signed-off-by: 你的名字 郵箱表示你確認這些代碼是你寫的或者你有權提交這些代碼。很多新手一看到英文縮寫就以為很復雜其實整個流程五分鐘內就能完成。還有一個容易被忽略的步驟合入前自己最后讀一遍完整的 diff。尤其是改動后的文件從 Git 的 diff 視角再審視一次。你會發現很多平時注意不到的小問題,比如誤提交的調試代碼、多余的空白改動、臨時的日志輸出。自己先把這些問題清理干凈再讓維護者看到能少挨很多批。6. 合入之后與常見問題速查6.1 合入不是終點PR 合入之后很多人會覺得這件事結束了可以接著去做下一個任務。但從貢獻者的角度合入只是開始真正驗證你改動的時刻是在之后的一個月。首先你要關注合入后的 CI 情況。合入主分支并不意味著代碼完全沒問題穩健的項目通常會在主分支上跑更長時間、更全面的回歸測試。如果這些測試發現你引入了回歸維護者會在你的 PR 討論里回復你或者新建一個 Issue 指向你的提交。其次你可以繼續保持對相關 Issue 的關注。如果你的改動修復了某個用戶報告的 bug可以留意用戶側有沒有反饋“這個修復有效”或“問題仍然存在”的信息。如果問題仍然存在你需要重新打開 Issue 繼續排查這也是開源社區協作的正常節奏。另外作為一個已經合入過代碼的貢獻者你已經有資格去 review 別人的 PR 了。這是一個很好的學習機會——你會發現坐在 reviewer 的位置上你會更加理解那些你曾經覺得煩瑣的規范其實都是項目質量和可維護性的保證。6.2 常見問題速查表下面整理了一些 HCCL 貢獻過程中常見的問題和排查方向是我以及身邊同事實際踩過的坑供你參考。問題現象可能原因排查思路本地編譯失敗報缺少頭文件依賴庫路徑未配置檢查 CANN 或驅動環境變量確認 LD_LIBRARY_PATH 是否正確CI 失敗全部失敗在編譯階段拉取代碼時未同步子模塊檢查倉庫是否用 --recurse-submodules 拉取或手動更新子模塊CI 失敗失敗在靜態掃描代碼格式不符合規范本地運行 clang-format 等格式化工具后重新提交本地單測通過CI 單測失敗環境差異或測試數據不同對比本地與 CI 的環境變量、依賴版本必要時在 PR 中請求維護者獲取 CI 日志性能優化數據不佳方案與硬件拓撲不匹配嘗試在不同卡數、不同數據量下進行基準測試分析是否引入了不必要的同步無法在本地復現 Issue 中的崩潰缺少日志開關或特定環境變量按 Issue 中提供的信息逐項核對尤其是數據量、拓撲和驅動版本PR 長期無人 review維護者繁忙或描述不清晰在 PR 評論區禮貌 維護者或補充測試數據和復現步驟讓問題更清晰6.3 幾條值得謹記的避坑心得做了一段時間 HCCL 貢獻之后有幾個踩過的坑讓我印象很深這里集中說一下。第一不要在 issue 里只問“怎么解決”而不提供任何上下文。一個好的問題應該讓人感覺你已經讀過代碼、有自己的猜測只需要別人幫你確認方向。我在社區里看到過的最高效的一次提問是一個貢獻者直接貼出了他定位到的代碼行號并附上了他對問題的分析維護者只回了一句“你的判斷是對的修吧”這比來回追問五六輪高效太多。第二不要在一個 PR 里同時修多個不相關的問題。多個問題混在一起reviewer 很難評估風險。一個 PR 解決一個問題是開源協作的基本契約。如果你發現代碼里另外有一個 bug請新建一個 Issue 或者再開一個 PR不要塞到當前這個里。第三不要忽視文檔的力量。代碼改動如果涉及對外行為的變化比如環境變量語義變更、接口參數調整、日志輸出變化一定同步更新相關文檔。你維護的不只是代碼還有這個項目的可理解性。很多 PR 因為文檔沒有同步更新而被要求返工這種事情完全可以提前避免。第四不要在 rebase 的過程中引入重復的改動。很多新手在 rebase 主分支時因為沖突解決不當把主分支的代碼又復制了一份到自己分支里導致 diff 里出現大量無關改動。遇到這種情況建議用 git diff 對比主分支和自己分支的差異檢查是否只保留了你想要改動的文件。最后再說一點參與開源項目不是一個零和博弈。你可能提交的第一個 PR 會被拒絕會被告知設計欠妥甚至會被人說“這個思路根本不對”。這些都很正常很多資深開發者當年的第一個 PR 也是被反復打回來的。關鍵是你能從反饋里學到東西而不是被打擊之后就放棄。如果你手頭有昇騰設備又有興趣深入了解分布式訓練底層的通信邏輯可以試著從跑通官方 benchmark 開始然后自己設置一些異常數據或者異常環境變量看看會發生什么。好奇心是最好的入口而 Issue 和 PR 只是把你對問題的理解轉化成最終代碼的載體。只要你能把一件事寫清楚、說清楚、改清楚開源社區的大門對你就是敞開的。