<mark id="oztn4"></mark>
0
AI行業的節奏正在變得越來越快。
從去年的大模型，到今年Agent的集中爆發，技術熱點在持續切換。但在表層變化之下，有一個趨勢幾乎沒有發生改變：模型規模與使用強度的提升，正在持續推高對算力的需求。
當模型規模、調用頻率與應用復雜度同時增長，單純依賴算力堆疊已經難以為繼。
在這種局面下，開發者天然希望找到一套已經經過驗證、能覆蓋全鏈路的成熟體系。這正是CUDA生態在過去十幾年建立起來的護城河：它不僅提供了算力，更定義了從編程到部署的一整套標準。
也正是在這樣的背景下，一個更現實的問題開始浮出水面：當CUDA生態已經形成穩定閉環，后來者的路徑到底是什么？是盡可能兼容，以降低遷移成本；還是從底層出發，建立一套不依附既有體系的新結構？
華為張良給出了他的答案，他在分享會上反復強調：如果底層結構不改變，上層生態就很難真正建立。
這意味著，當前這場競爭，已經不只是算力性能的比較，而是一次圍繞“體系”的重構。
在AI基礎設施發展的早期階段，“能不能跑起來”曾經是最核心的判斷標準。
但隨著大模型進入工程化與規模化階段，這一標準迅速變得不再充分。系統的瓶頸，開始從“單點能力不足”，轉向“整體鏈路是否匹配真實負載”。
張良在回顧昇騰早期發展時，并沒有回避這一點。他提到，“2018年CANN剛發布時，我們知道CANN和硬件都是不完美的”。
那一階段屬于典型的“可運行但未成熟”狀態，行業的關注點更多集中在框架對比、性能指標等表層問題，而真正決定長期能力的底層結構，并沒有被充分展開。
面對大模型時代的新負載——長序列帶來的訪存壓力、低精度訓練成為主流，以及MoE等復雜模型架構的涌現，昇騰急需解決編程模型不夠靈活、訪存粒度無法適配、低精度支持缺失等問題。
這些問題無法通過軟件優化或算子補丁徹底解決，只能在芯片和系統底層重新設計。
轉折發生在近兩年。
按照張良的說法，從2025年開始，昇騰團隊“痛下決心”，不再圍繞局部問題進行修補，而是回到一個更根本的判斷：如果底層結構不改變，上層生態就不可能真正建立。
在最新一代昇騰950芯片中，這種調整體現在多個方面：編程模型更接近主流并行計算范式，降低開發遷移成本；數據訪問引入更細粒度訪存機制，以減少大模型場景下的無效帶寬消耗；同時提前支持FP8等低精度計算，以提升吞吐并支撐更大模型規模。
張良提到：“有客戶在測試不到一周后，就直接做出了下單決策。”
與此同時，昇騰在架構路徑上也做出了一個關鍵選擇。在專用加速芯片逐漸興起的背景下，針對特定場景進行深度優化，往往可以獲得更高的短期效率。
但張良明確表示，團隊并沒有沿著這一路徑繼續推進，而是堅持通用架構方向。原因在于，如果系統能力被限定在特定場景中，就很難形成外溢，也無法支撐多樣化應用的持續增長。
這一選擇意味著，昇騰并不只是試圖把模型“跑得更快”，而是在解決一個更長期的問題：當模型不斷變化、負載持續增長、開發范式不斷演進時，這套系統是否仍然能夠承載這些變化。
如果說底層結構決定了一套系統“能做到什么”，那么生態則決定了“有沒有人愿意在上面繼續做”。
在當前AI基礎設施格局中，CUDA已經不僅是一套技術方案，而是一整套高度穩定的開發體系。從編程模型、工具鏈到社區與人才結構，它所形成的，不只是功能層面的能力，更是一種“默認可用”的環境。
對于后來者而言，最直接的路徑，是盡可能向這一體系靠攏——通過接口兼容與生態復用，降低開發者的遷移門檻。
這是一條現實且常見的路徑，但昇騰并沒有選擇沿著它走下去。
張良給出的判斷非常直接：“如果基于CUDA來做，那我們做的一切生態發展，都無法徹底自主。”
這句話所指向的，并不只是技術路線之爭，而是一個更底層的問題：如果核心體系建立在他人的標準之上，那么無論投入多少工程資源，最終強化的仍然是原有系統，而不是自身能力。
進一步看，這種依附關系還意味著技術演進主動權的缺失。張良提到，“一旦出現危機的時刻，這一套體系做不到，你的特性在里面就沒了。”
這里的“特性”，不僅是具體功能，也包括體系能夠持續演進的空間。如果關鍵能力受限于既有框架，那么新的特性就很難真正落地，更難形成長期積累。
在這一判斷之下，昇騰選擇了一條更復雜但更具獨立性的路徑：在底層體系上堅持自研，在上層生態上盡可能對齊主流。
這意味著，在虛擬指令集、編譯器以及運行時等關鍵環節，昇騰不依賴既有標準，而是構建自己的實現；而在開發接口與使用方式上，則主動適配主流框架，使開發者可以在熟悉的環境中使用這套系統。
這種“分層處理”的方式，本質上是在控制權與使用門檻之間尋找平衡：既不完全依附，也不讓開發者從零開始。
但這條路徑的難度，很快體現在實際推進過程中。
在主流開源框架中，新硬件往往只能以插件形式接入，難以進入主干體系。
張良提到，昇騰最初面對的正是這樣的情況——對方并不直接接納，而是建議“你們可以自己做插件”。這意味著，生態上的“可用”與“被認可”之間，仍然存在明顯距離。
昇騰的做法，是持續參與開源社區：提交代碼、對齊規范，并通過工程實踐驗證自身實現的穩定性。在這個過程中，關系逐漸發生變化，從最初的外部適配，轉向更深層的協同。
例如在Triton中實現后端支持，在PyTorch Foundation體系中建立起持續集成流程，使平臺能夠跟隨主版本演進保持同步。這些變化的意義，在于昇騰不再只是“接入生態”，而是開始參與生態本身的構建。
與此同時，生態建設也被進一步轉化為可量化的工程問題。
張良提到，昇騰對開源軟件的支持能力、以及開源軟件對昇騰特性的支持程度，被細化為特性支持率、模型適配率、CI覆蓋率等一系列指標，“要求必須維持在95%以上”。
在模型側，昇騰也在推進類似的覆蓋能力。
昇騰已在DeepSeek V4發布當天實現全系列適配，950超節點推理時延低至10~20ms，并通過PyPTO編程范式將算子開發周期縮短至天級。
不過，這一路徑并非沒有不確定性。
在一個已經高度收斂的生態體系中，新的平臺不僅要補齊能力，還需要在時間上追趕。這不僅是技術問題，更是節奏問題：當主流框架持續快速迭代時，新體系是否能夠長期保持同步，并逐步建立自身影響力，仍然取決于持續的工程投入與社區協同。
也正是在這一意義上，“做一個CUDA兼容層”之所以沒有被選擇，是因為它無法回答一個更關鍵的問題——當生態演進發生變化時，這套體系是否仍然擁有自己的位置與空間。
在傳統AI工程體系中，開發過程高度依賴人工經驗。
從算子實現到性能調優，每個環節都需要工程師深入理解硬件、反復調試。這種模式在早期復雜度較低時尚可應對，但隨著模型規模擴大、系統鏈路拉長，人的處理能力開始成為效率瓶頸。
昇騰的應對方式，不是繼續在工具層面做優化，而是引入新的執行主體——Agent。
最直接的變化出現在算子開發環節：過去手寫算子需要深入硬件、反復調試，現在開發者只需描述設計意圖，Agent就可以自動完成環境配置并生成代碼。開發起點從“如何實現”轉向“要實現什么”。
圍繞這一思路，昇騰將Agent擴展到更完整的流程——從模型檢索、適配、量化，到遷移、優化與部署，原本分散的步驟被整合為一條連續路徑。
張良給出的目標是：“一分鐘找到模型，一小時驗證，一天完成部署。”壓縮的不只是時間，更是試錯成本與迭代周期。
支撐這一體系的，是“Skill”——一種標準化的能力單元，它將專家經驗、調優方法以及工程流程以模塊化方式沉淀下來，供Agent直接調用組合。
這意味著，原本依附于個體經驗的能力，開始被轉化為系統的一部分。開發者不再需要從零構建流程，而是通過定義目標與約束，讓系統完成大部分執行工作。
在標準化程度較高、路徑清晰的任務中，Agent可以顯著提升效率。但張良坦言，在“最深層次的復雜問題”上，當前Agent的能力“還不是那么強”，仍然離不開工程師的深度參與。
這使得Agent呈現出一種過渡性特征：一方面，它確實在改變開發節奏，使原本以天甚至周為單位的流程被壓縮到小時級；另一方面，它也在承擔一層“緩沖”的角色——在生態尚未完全成熟、底層差異仍然存在的情況下，通過自動化能力降低使用門檻。
這也引出一個更深遠的問題：Agent所帶來的，是一種長期穩定的新范式，還是在體系尚未完善時的過渡機制？答案或許取決于Skill的沉淀速度和底層差異的收斂程度。但無論如何，它在當下已經實實在在地改變了開發節奏。
回到最初的問題：當CUDA已經成為事實標準，后來者是否還有空間？
從昇騰這一路徑來看，它給出的答案，并不是正面替代，也不是簡單兼容，而是試圖在既有體系之外，構建一套可以獨立運轉的結構，讓這套系統在不依賴既有生態的情況下，仍然具備自洽能力。
當然，這一選擇仍然處在進行時之中。生態能否持續積累、與主流框架的協同能否長期穩定、開發方式的變化能否真正沉淀為工程能力，這些都需要時間來驗證。
雷峰網雷峰網(公眾號：雷峰網)
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
