國產(chǎn)算力與國產(chǎn)大模型我最近在多個項目里把這兩樣東西放在了一起本文就是這次從選型到落地的經(jīng)驗復盤。這輪AI的競爭底層拼的是算力和模型的協(xié)同能力。過去一年我陸續(xù)接觸了幾套國產(chǎn)算力集群方案也幫幾個客戶把他們自研或開源的國產(chǎn)大模型往國產(chǎn)硬件上遷。踩過坑走過彎路但總體趨勢已經(jīng)非常明確國產(chǎn)大算力配上國產(chǎn)大模型不再是“能不能跑”的驗證階段而是進入了“怎么跑得更快、更穩(wěn)、更劃算”的實效階段。這篇內(nèi)容我盡量寫透覆蓋硬件選型、并行策略、算子適配、推理優(yōu)化和集群調(diào)度幾個關(guān)鍵環(huán)節(jié)。不管你是做模型訓練、平臺工程還是應(yīng)用開發(fā)這幾塊內(nèi)容都繞不開。先給結(jié)論這套組合的瓶頸不在芯片峰值算力而在軟件棧的成熟度和工程化的精細程度。誰先把這個短板補上誰就能跑在前面。1. 選型思路為什么“國產(chǎn)算力國產(chǎn)模型”是必然趨勢1.1 需求側(cè)的邏輯訓練和部署大模型算力成本始終是核心約束。用通用GPU跑DeepSeek這類開源模型成本曲線非常陡峭。我做過測算一個7B參數(shù)的稠密模型在通用加速卡上做全參數(shù)微調(diào)單次實驗的算力成本動輒數(shù)千元如果是多輪實驗累計起來非?？捎^。國產(chǎn)算力卡的單價雖然也在漲但綜合算上集群搭建、運維和長周期使用的成本相比進口方案有明顯優(yōu)勢。尤其是推理場景國產(chǎn)卡的性價比優(yōu)勢更突出——單卡能承載的并發(fā)請求量和單位token成本在適配優(yōu)化后完全可以和進口卡正面競爭。1.2 供給側(cè)的變化這兩年國產(chǎn)芯片的進步是實打?qū)嵉?。單卡FP16算力已經(jīng)追到了國際主流產(chǎn)品的同一代際水平顯存容量和帶寬也不再是短板。更重要的是生態(tài)在逐步補齊開發(fā)框架適配了主流深度學習框架分布式通信庫開始支持多機多卡的高性能通信推理引擎也能直接加載通用格式的模型權(quán)重了。我這次選型的核心標準有三條算力密度和顯存容量是否能滿足模型參數(shù)量需求軟件棧是否支持高效的并行訓練和推理優(yōu)化工具鏈是否完善包括調(diào)試、性能分析和模型轉(zhuǎn)換。這三條缺一不可只看紙面算力參數(shù)一定會踩坑。1.3 深層的產(chǎn)業(yè)協(xié)同效應(yīng)這輪組合之所以能“換道提速”核心在于協(xié)同優(yōu)化。國產(chǎn)加速卡廠商和模型團隊的合作深度遠超以往。過去模型跑在通用生態(tài)上芯片廠商只能被動適配現(xiàn)在雙方在算子層面、通信層面做聯(lián)合優(yōu)化。比如針對模型的注意力機制定制融合算子針對MoE結(jié)構(gòu)優(yōu)化專家并行策略。這種深度協(xié)同是“國產(chǎn)組合”獨有的優(yōu)勢也是換道提速的根本原因。2. 硬件平臺認知與軟件棧適配2.1 別按慣用套路調(diào)參拿到國產(chǎn)算力卡的第一件事不是馬上開始訓練而是重新理解它的架構(gòu)特性。很多國產(chǎn)芯片的設(shè)計思路和常用芯片有本質(zhì)區(qū)別計算單元的指令調(diào)度方式不同緩存層級和顯存帶寬的比例不同對數(shù)據(jù)精度格式的支持范圍不同。我最初做遷移時按習慣設(shè)置了很大的批量大小結(jié)果發(fā)現(xiàn)顯存經(jīng)常吃緊、計算單元卻大量空閑。后來調(diào)整策略把小批量、梯度累積、流水線并行結(jié)合起來才把硬件利用率拉上來。這類經(jīng)驗不在任何官方文檔里只能靠壓測和調(diào)試驗證。2.2 軟件棧全鏈路盤點一個成熟的軟件棧至少包含這幾層底層驅(qū)動和運行時庫負責硬件抽象和資源管理算子庫提供高效的融合算子和基礎(chǔ)算子通信庫負責多卡間的數(shù)據(jù)傳輸和集合通信上層框架適配層讓主流的訓練和推理框架能在上面跑工具鏈包括編譯優(yōu)化器和性能分析器。我建議你在選型前就把這些組件全部列出來逐一確認版本兼容性。我遇到過一種情況推理框架的某個版本依賴新的算子庫接口但訓練集群上的算子庫版本較低導致模型轉(zhuǎn)換和部署時頻繁報錯卡了好幾天。2.3 異構(gòu)計算的定位國產(chǎn)算力卡在單個機柜內(nèi)組成訓練集群時我傾向于采用異構(gòu)計算思路一個典型部署是8卡訓練機4臺搭配2臺高帶寬存儲節(jié)點組成一個訓練單元單機通過高速網(wǎng)絡(luò)互聯(lián)。存儲節(jié)點提供高速數(shù)據(jù)集緩存避免訓練流程反復讀文件拖慢整體速度。推理環(huán)境則獨立部署用低延遲網(wǎng)絡(luò)互聯(lián)避免數(shù)據(jù)流量相互干擾?；旌暇扔柧毥ㄗh使用半精度為主、單精度為輔的策略主訓練參數(shù)與優(yōu)化器狀態(tài)用單精度保存中間計算用半精度。國產(chǎn)芯片對混合精度的支持已經(jīng)比較完善收益非常明顯。3. 國產(chǎn)大模型的部署與微調(diào)實踐3.1 模型選型與評估維度國產(chǎn)大模型的生態(tài)已經(jīng)非常豐富從密集小模型比如7B、13B參數(shù)到大規(guī)模的MoE模型都有。選模型之前先確認三個問題第一任務(wù)類型是什么是文本生成、代碼補全還是多模態(tài)理解不同任務(wù)的精度特征差異很大。第二算力預(yù)算能支撐多大參數(shù)量的模型做全參數(shù)微調(diào)還是只能用參數(shù)高效微調(diào)技術(shù)如LoRA第三是否需要商用許可。開源模型雖然可以免費商用但一些有著寬松授權(quán)的模型在改造自由度上更具優(yōu)勢能省掉后續(xù)不少麻煩。我經(jīng)常給客戶用一張評估表來輔助決策舉例但結(jié)構(gòu)和邏輯可復用評估維度說明權(quán)重建議模型能力基線在目標任務(wù)上的表現(xiàn)與同類模型的對比30%資源占用顯存消耗、推理時延、吞吐量、部署成本30%生態(tài)適配對國產(chǎn)訓練框架、推理引擎、微調(diào)工具的兼容性25%授權(quán)與成本許可協(xié)議、商業(yè)使用限制、可改造性15%這幾個維度權(quán)重可以根據(jù)實際項目調(diào)整但每一項都要實際測試不能光看官方宣傳。3.2 微調(diào)流程細節(jié)與實操選定模型后微調(diào)是整個流程中細節(jié)最多、最容易出問題的環(huán)節(jié)。我用一個標準流程說明第一步數(shù)據(jù)準備。將原始數(shù)據(jù)統(tǒng)一成對話格式做清洗和去重。這一步特別重要數(shù)據(jù)質(zhì)量直接決定微調(diào)效果。我把清洗規(guī)則列得比較長過濾敏感詞、剔除重復樣本、處理表情符號、統(tǒng)一標點。做中文任務(wù)的時候還要額外處理繁體簡體混合和口語化表達。第二步定義微調(diào)策略。資源有限我一般用LoRA凍結(jié)原模型參數(shù)只訓練低秩矩陣。需要更新的參數(shù)量可以控制在全參數(shù)的1%左右顯存開銷大幅下降。對于能力較強的基座模型只用幾百條高質(zhì)量樣本做指令微調(diào)效果就可以非常明顯。第三步訓練參數(shù)配置。在國產(chǎn)芯片上學習率設(shè)置我建議比慣用值略低配合小幅度的預(yù)熱步數(shù)。批量大小設(shè)小一些用梯度累積補足。序列長度則根據(jù)任務(wù)調(diào)整做摘要生成就設(shè)短一些做長文檔理解就逐步增加到更長。訓練過程中除了觀察損失曲線我還會關(guān)注梯度范數(shù)和激活值分布。我遇到過損失曲線在下降但生成質(zhì)量變差的反常現(xiàn)象后來排查發(fā)現(xiàn)是數(shù)據(jù)里的某個標簽字段污染了模型輸出格式。這就不是訓練參數(shù)能解決的必須重新清洗數(shù)據(jù)。第四步評估與迭代。微調(diào)完成后不能只盯著測試集指標。我習慣讓模型在真實業(yè)務(wù)樣本上跑一遍輸出人工評估可讀性和格式一致性。這一步能發(fā)現(xiàn)自動化指標發(fā)現(xiàn)不了的問題。3.3 推理優(yōu)化與部署要點部署是大模型落地的“最后一公里”也是國產(chǎn)算力組合最容易暴露短板的環(huán)節(jié)。主要性能指標是吞吐量和響應(yīng)時延。核心優(yōu)化手段如下動態(tài)批處理把多個并發(fā)請求動態(tài)合并成一批可以顯著提升吞吐量。在線推理服務(wù)建議開啟但要注意單批請求長度差異太大時會拖慢整體響應(yīng)需要設(shè)置合理的超時時間。顯存管理優(yōu)化使用KV Cache復用和連續(xù)顯存分配技術(shù)減少顯存碎片。我實測過僅優(yōu)化顯存分配這一項單卡并發(fā)能力就能提升約40%。低比特量化把權(quán)重壓縮到INT8甚至更低來換取推理加速。國產(chǎn)芯片對低比特計算支持不錯但在量化時要小心精度損失。我用過幾種量化工具對同一個7B模型做對比在保證答案準確率下降控制在1%以內(nèi)時INT8推理速度相比原來的FP16部署提升約1.5倍且顯存占用降低了約一半。部署架構(gòu)方面我推薦把推理服務(wù)拆成兩個獨立層入口層負責請求鑒權(quán)、流量控制、負載均衡和基礎(chǔ)安全校驗推理層真正跑模型推理的Worker節(jié)點支持彈性擴縮容。兩層分離的好處是推理層可以根據(jù)請求量獨立擴容沒有服務(wù)入口的壓力入口層也不會因為推理擁堵而垮掉。4. 并行策略與通信瓶頸排查4.1 并行策略怎么選訓練大模型繞不開分布式并行。我常用的并行方案有四種數(shù)據(jù)并行、流水線并行、張量并行和專家并行。它們解決的問題各不相同組合使用時需根據(jù)模型和集群規(guī)模動態(tài)調(diào)整。數(shù)據(jù)并行的實現(xiàn)最簡單核心代碼改動少適合小規(guī)模試水。問題在于顯存占用大戶即優(yōu)化器狀態(tài)和梯度會隨著并行進程數(shù)線性增長。所以純數(shù)據(jù)并行只適合一行GPU放得下的模型。流水線并行把模型按層切成多段分配到不同設(shè)備上執(zhí)行能解決超長模型顯存不夠的問題。但我體驗下來它的短板是設(shè)備之間存在等待氣泡利用率上不去。建議把切分點選在計算量相對均衡的地方每段包含層數(shù)不必相同只要總耗時接近就行。張量并行把每一層的矩陣計算切到多張卡上通信量極高只適合在一個節(jié)點內(nèi)使用節(jié)點間網(wǎng)絡(luò)帶寬滿足不了。MoE模型中的專家并行是把不同的專家模塊分到不同設(shè)備上能大幅提升大規(guī)模MoE的訓練效率但路由通信同樣是瓶頸。我在訓練一個13B密集模型時用的是“數(shù)據(jù)并行流水線并行張量并行”的三級組合先按張量并行把單層切到4卡再按流水線切成4段最后在節(jié)點間做數(shù)據(jù)并行。這樣既壓低了單卡顯存又把節(jié)點內(nèi)的高帶寬通信充分利用起來。4.2 網(wǎng)絡(luò)通信是隱藏瓶頸并行訓練里網(wǎng)絡(luò)通信最容易被忽視但恰恰是決定擴展效率上限的關(guān)鍵。我用一個通用公式來估算通信占比如果一張卡在單個batch里的計算耗時是T通信耗時是C理想擴展效率是 1/(1C/T)。通信占比每高一點效率損失都被放大。排查通信瓶頸我會重點關(guān)注三個位置第一集合通信模式的實現(xiàn)效率。大規(guī)模并行訓練中全規(guī)約操作是最常見的集合通信。有的實現(xiàn)是層次化的先歸約到節(jié)點內(nèi)再跨節(jié)點歸約性能就高有的實現(xiàn)是平面廣播集群規(guī)模一大立刻崩潰。我建議在選型時直接壓測一下多節(jié)點場景下的通信帶寬和擴展效率不要等訓練跑起來才發(fā)現(xiàn)。第二網(wǎng)絡(luò)拓撲感知。訓練任務(wù)調(diào)度時要盡量讓頻繁通信的進程組落在同一個交換域內(nèi)。有一次我們的訓練集群效率極低排查到最后發(fā)現(xiàn)是容器調(diào)度策略把8個進程均勻散在了兩個交換域里跨交換域通信占了總通信量的60%以上。我把調(diào)度策略改為拓撲感知優(yōu)先后訓練耗時直接降了35%。第三網(wǎng)卡和驅(qū)動的流控設(shè)置。國產(chǎn)網(wǎng)絡(luò)設(shè)備有些特性需要手動開啟。比如某些網(wǎng)卡的流控默認關(guān)閉高負載下丟包嚴重就會導致通信超時。這類問題特征是訓練間歇性變慢日志里有大量重傳記錄。打開流控并調(diào)大緩沖區(qū)之后問題基本消失。4.3 框架層面還有哪些優(yōu)化空間現(xiàn)在的深度學習框架自身也做了不少針對國產(chǎn)芯片的優(yōu)化但默認參數(shù)不一定適合你的模型。值得動手的優(yōu)化點包括關(guān)閉冗余的梯度同步有些框架默認每步都同步所有梯度改為按層分組異步同步能減少通信量啟用融合優(yōu)化器把優(yōu)化器更新操作融合進計算流減少多次內(nèi)核啟動的開銷使用編譯緩存反復跑相同結(jié)構(gòu)訓練任務(wù)時把圖編譯產(chǎn)物緩存起來二次任務(wù)啟動能快非常多。這些優(yōu)化每項都在細節(jié)里但疊加起來很可觀。我一度把一個7B模型的訓練吞吐提升了近20%改的全是框架層配置硬件沒動過。5. 推理服務(wù)的完整落地實錄5.1 一個可復用的部署架構(gòu)推理服務(wù)的架構(gòu)我直接給出一個能落地的方案。一個完整的推理服務(wù)至少包含模型倉庫存放模型權(quán)重、版本信息和配置預(yù)加載服務(wù)服務(wù)啟動時把模型加載進顯存并完成預(yù)熱避免首次請求過慢推理Worker按副本數(shù)水平擴展每個副本獨立加載模型實例網(wǎng)關(guān)入口負責將請求分發(fā)到各副本支持輪詢和最小連接數(shù)策略。我實際的部署步驟是把訓練好的模型權(quán)重導出為標準格式在推理引擎里做精度校驗和量化校準寫一份部署配置指定模型路徑、量化類型、最大并發(fā)數(shù)和顯存分配策略啟動預(yù)加載服務(wù)并做一次白名單請求確認推理結(jié)果正確拉起網(wǎng)關(guān)入口把線上流量導過來持續(xù)觀測延遲、吞吐、顯存水位和請求失敗率。關(guān)鍵效果同一批請求在優(yōu)化前是逐個排隊處理優(yōu)化后并發(fā)成批進入延遲最大的那些請求減少了近一半整體吞吐翻了一倍。這些數(shù)字與硬件和模型規(guī)模有關(guān)不作為絕對值參考但優(yōu)化空間是真實的。5.2 推理階段的性能調(diào)優(yōu)記錄這個環(huán)節(jié)最花時間也最容易有成就感。第一天我拿到一個國產(chǎn)算力集群單節(jié)點8卡準備部署一個13B模型。最初用默認參數(shù)啟動單實例只能并發(fā)處理少量請求響應(yīng)延遲還偏高顯卡利用率不到20%。問題出在依賴的算子實現(xiàn)版本過舊部分計算流程沒有融合。更換版本并開啟自動融合后顯存分配碎片化問題也隨之改善。隨后調(diào)整了動態(tài)批處理的等待窗口從固定值改為自適應(yīng)值請求少時減少等待請求多時拉開一點窗口湊大批次。吞吐量又提升了一截。最后用量化把模型從原精度壓到INT8同時做了一層輸出概率的補償保證生成質(zhì)量不塌。至此才算完成。整個調(diào)優(yōu)周期約兩周大部分時間花在定位算子級瓶頸上。5.3 可觀測性建設(shè)運維側(cè)容易忽略的是可觀測性。推理服務(wù)一旦出問題如果沒有完善的指標監(jiān)控排查會非常痛苦。我建議至少要覆蓋這些指標基礎(chǔ)設(shè)施層卡利用率、顯存使用率、溫度、互聯(lián)帶寬服務(wù)層推理請求數(shù)、平均延遲、P99延遲、批大小分布業(yè)務(wù)層生成成功率、平均生成token數(shù)、內(nèi)容拒答率資源層進程CPU內(nèi)存占用、網(wǎng)絡(luò)連接數(shù)、磁盤IO。把這些指標接入現(xiàn)有監(jiān)控體系配上告警規(guī)則。比如P99延遲連續(xù)5分鐘超過閾值就報警顯存水位超過90%就提醒擴容。有了這套優(yōu)化和排查效率會高很多。6. 常見問題與排查技巧實錄6.1 算子不支持導致的靜默失敗這是國產(chǎn)芯片遷移中最常見的一類問題訓練能啟動Loss也在降但某一輪突然出現(xiàn)NaN或報錯原因往往是某個自定義算子沒有對應(yīng)實現(xiàn)框架悄悄走了兜底路徑而兜底路徑數(shù)值精度不達標。排查思路很簡單固定隨機種子復現(xiàn)問題逐步縮小范圍到特定的算子再對照算子支持矩陣查是否命中已知兼容性問題。如果確認算子有問題改寫成等價操作組合即可繞過。6.2 模型并行通信卡死現(xiàn)象多機訓練時某個節(jié)點心跳超時任務(wù)整體卡住其他節(jié)點在等它。排查步驟先看節(jié)點的網(wǎng)卡狀態(tài)和錯誤計數(shù)器有無大量丟棄包或錯誤包再看網(wǎng)絡(luò)交換機端口有無異常告警最后看集合通信庫日志確認卡住的是哪個集合通信操作。解決方向一般是調(diào)整網(wǎng)絡(luò)驅(qū)動參數(shù)、換用層次化集合通信實現(xiàn)、或者把并行策略中的通信熱點分散到不同網(wǎng)絡(luò)路徑上。6.3 推理時顯存越用越滿推理服務(wù)跑一段時間后顯存持續(xù)上漲最終OOM。這是典型的顯存泄漏。定位方法論記錄顯存隨時間的變化曲線確認是持續(xù)上漲還是臺階式上漲關(guān)閉動態(tài)批處理功能看是否仍然泄漏以區(qū)分是緩存策略引發(fā)還是內(nèi)核資源未釋放升級推理引擎版本或顯存分配器往往能解決一部分內(nèi)核級泄漏問題。我在一個項目里排查了三天最后發(fā)現(xiàn)是某個老版本推理引擎的key-value緩存回收邏輯有缺陷。升級到新版本后顯存曲線立刻變成了平穩(wěn)直線。6.4 常見問題速查表現(xiàn)象可能原因排查方向訓練Loss震蕩不收斂學習率過大、數(shù)據(jù)順序不當、梯度累積步數(shù)不匹配調(diào)低學習率、打亂數(shù)據(jù)順序、檢查累積步數(shù)設(shè)置訓練速度遠低于預(yù)期網(wǎng)絡(luò)拓撲不感知、通信模式低效、批大小太小啟用拓撲感知調(diào)度、壓測通信帶寬、增大批大小推理首token延遲高模型未預(yù)熱、顯存分配碎片化、算子未融合啟動時做預(yù)熱請求、開啟顯存復用、檢查計算圖融合日志并發(fā)一高就崩動態(tài)批處理等待窗口設(shè)置不當調(diào)整超時參數(shù)設(shè)置每批最大token上限生成內(nèi)容重復率高解碼參數(shù)不合適、長度懲罰太弱調(diào)整溫度參數(shù)、增加重復懲罰系數(shù)7. 換道提速的經(jīng)驗總結(jié)把這一路的體會濃縮成幾條供參考第一明確目標再選型。不同團隊的情況天差地別有人需要極致訓練性能有人只看推理性價比有人更看重二次開發(fā)的自由度。目標不同最優(yōu)解必然不同。不要盲目追最新的旗艦卡也不要低估舊款多卡集群的整體產(chǎn)出。第二軟件棧生態(tài)遠比芯片算力參數(shù)重要。能跑起來、能優(yōu)化起來、能排查出問題遠比紙面性能數(shù)字重要。選型評估時建議留出兩周時間專門做生態(tài)驗證跑通工具鏈全流程。第三工程化水平?jīng)Q定上限。同樣一套硬件和模型A團隊可能跑出雙倍于B團隊的吞吐差別全在工程細節(jié)顯存管理、并行策略、通信優(yōu)化、請求調(diào)度。這些都要在項目初期就規(guī)劃好不能等出了問題再補。第四團隊要建立“硬件模型”的復合能力。過去做應(yīng)用的和做芯片的是兩個圈子現(xiàn)在必須融合。至少要有一個人能看懂計算圖融合邏輯有一個人能讀懂網(wǎng)絡(luò)通信指標有一個人能做推理服務(wù)的容量評估。國產(chǎn)算力和國產(chǎn)模型的組合正在從“可用”走向“好用”。這個過程中沒有銀彈只有把每一個環(huán)節(jié)摳細、把每一分算力用在刀刃上才能真正跑出加速度。希望這篇文章能幫你少踩幾個坑把時間花在更值得做的事情上。