說到算力提升，大家可能想到的就是通過工藝進步、Chiplet封裝以及架構優化來提升性能，以及通過“東數西算”擴建數據中心的方式來擴大計算節點的規模。

但僅僅考慮這些，還遠遠不夠。要想實現算力1000倍甚至更多倍的提升，勢必需要宏觀整體全方位的協同優化和創新。

具體辦法，本文詳細分析。

1 算力綜述

1.1 對算力的追求，永無止境

幾個典型案例：

2012-2018年共6年時間里，人們對于AI算力的需求增長了超過30萬倍；

要想實現L4/L5級別的自動駕駛算力，需要將目前兩位數TOPS的算力提升到四位數TOPS，需要算力提升100倍；

Intel SVP拉加·庫德里表示，要想實現元宇宙級別的用戶體驗，需要當前的算力要再提升1000倍。

軟件和硬件，是一對永恒的矛盾：硬件永遠無法滿足軟件對性能的需要。

目前，算力要想進一步提升，遇到非常大的挑戰：一方面，基于CPU的性能已經到達瓶頸，摩爾定律失效；另一方面，通過AI-DSA等加速方式提供的算力靈活性、易用性都很差，導致算力的利用率很低，芯片的落地規模很小。

換個視角看，因為硬件的約束，限制了軟件的迅猛發展。假設硬件可以立竿見影、快速的提供相比目前千倍萬倍的算力，上層應用場景一定會繁花似錦，我們可以大踏步的走進元宇宙等數字新時代。

對算力的追求，永無止境！

1.2 跟算力相關的因素

在今年二月份的時候，公眾號發布了《預見·第四代算力革命》四篇系列文章，詳細地拆解了算力的組成因素，以及介紹了新一代的計算架構。在文章中，我們列出了如下的公式：

實際總算力 = （單個處理器的）性能 x 處理器的數量 x 利用率

這樣，跟算力相關的需要優化的因素就可以簡單總結為三個層次：

第一個層次，單芯片性能。單芯片性能的提升，簡單地來說，主要有三個辦法：工藝進步、Chiplet封裝以及架構/微架構創新。

第二個層次，芯片的落地規模，即數量。要想芯片大規模落地，首先要考慮的不是簡單的建設數據中心，買更多的服務器，而是要考慮芯片是否能夠支持大規模落地。例如，受AI算法快速多變和算法眾多的原因，目前AI芯片的落地存在困境。

第三個層次，整體算力的利用率。如果算力資源不能連成一片，一盤散沙，那就沒有意義。要想提升算力利用率，考慮的重心不是單芯片的資源利用率，而是宏觀資源利用率。宏觀資源利用率，就是把所有的計算資源連成一個大的計算資源池，然后可以非常靈活的資源切分、組合、分配和回收。挑戰在于，如何把種類繁多的異質的計算資源匯集到一個資源池。

三個層次，從微觀、中觀再到宏觀，逐次為大家解開算力提升的方方面面。接下來，我們詳細拆解。

2 第一層：提升單芯片的性能

2.1 方法一：工藝進步

要想單芯片持續不斷的性能提升，工藝封裝是主要的推動力量。工藝持續進步、3D堆疊等技術，在芯片上可以容納更多的晶體管，也意味著芯片的規模可以越來越大。目前的挑戰在于，隨著工藝進入5納米以內，工藝進步對芯片的性能提升變得越來越緩慢。

未來，量子工藝，可能會替代現在的CMOS工藝。有了量子門級電路的強力支撐，顯著地提升了芯片的性能，而上層的芯片架構和軟件生態，跟現有工藝是兼容的，仍然可以持續繁榮發展。

2.2 方法二：通過Chiplet，立竿見影地大規模提升單芯片設計規模

Chiplet，中文通常稱為小芯片，意思就是說通過把不同功能的裸芯片DIE，通過某種介質封裝在一起，從而形成多DIE的單芯片。

UCIe是一個開放的行業互連標準，可以實現小芯片之間的封裝級互連，具有高帶寬、低延遲、經濟節能的優點。UCIe能夠滿足幾乎所有計算領域，包括云端、邊緣端、企業、5G、汽車、高性能計算和移動設備等，對算力、內存、存儲和互聯不斷增長的需求。UCIe 具有封裝集成不同Die的能力，這些Die可以來自不同的晶圓廠、采用不同的設計和封裝方式。

Chiplet的價值非常巨大，有了Chiplet標準UCIe之后，整個產業鏈的企業可以一起行動起來，快速地把應用Chiplet技術的相關芯片產品落地，這會使得平均單芯片設計規模會顯著激增。也意味著在宏觀背景下，單芯片可以支持顯著增加的設計規模，也即顯著增加的性能。

2.3 方法三：通過超異構計算，指數級的提升芯片性能

Chiplet技術可以顯著的、數量級的提升芯片的設計規模。但如果我們不在架構上進行大范圍的創新，而是小修小補，那么就會暴殄天物。

Chiplet的利用方式，如上圖所示，大體上可以分為三種：

方案1：設計規模不變，優化單DIE面積和良率等，可以百分比的提升性能。

方案2：單DIE設計規模不變，多DIE集成。這樣，隨著面積的增加，性能可以線性增長。

方案3：多DIE集成設計規模倍增，并且重構系統。如下圖所示，通過超異構的方式，構建更加優化的系統，這樣可以做到隨著面積的增加，指數級的增加性能。

圖 通過超異構重構并優化（宏）系統

3 第二層：提升芯片的落地規模（數量）

要想提升芯片的落地規模，并不是直接復制這么簡單。這里涉及很多復雜的先決問題，需要解決。一個典型反面案例就是目前的AI芯片困境：由于AI-DSA的靈活性跟AI算法所需要的靈活性不匹配，導致現在AI芯片的落地就存在很多困境，從而限制了其落地的規模。

3.1 芯片要足夠通用，以此來覆蓋更多的用戶、更多的場景和更長期的場景迭代

芯片需要足夠的通用，才可能覆蓋更多的客戶、更多的場景，以及每一個場景的長期迭代。

但在CPU性能達到瓶頸之后，很多人逐漸“忘記”了這個這些原則。很多人覺得，需要針對場景的特點深度“定制”，在芯片設計的時候，把更多的業務邏輯變成硬件，把傳統軟件完成的工作通過硬件加速實現，從而提升性能。

然而，實踐證明，這種方式是走不通的。還是以AI芯片為例：

AI場景算法極其眾多，一般的互聯網公司，內部經常使用的AI算法可能會多達上千種；并且，AI算法還變化很快，算法迭代通常上是2個月一個小迭代，6個月一個大迭代。

然而，芯片的迭代周期沒有這么快，芯片通常2年一個迭代，并且還要考慮大約5年的生命周期。硬件7年的迭代+生命周期和軟件2個月的迭代周期，差距懸殊。

強行把軟件的業務邏輯直接下沉到硬件，可能會碰到這樣的尷尬：只能適配某個用戶的某個更細分場景的某個短時期內的應用，從而導致芯片的價值和落地規模受到極大的約束。

當CPU到達性能瓶頸之后，新的挑戰是：如何在硬件加速時代，實現足夠高的通用性。

這里，我們給出“完全可編程”處理器的概念：

所有功能由用戶通過軟件定義。授人以魚不如授人以漁，既然提供的是平臺化解決方案。不同的用戶，根據自己的需求組合功能，實現功能和場景差異。

所有業務邏輯由用戶通過編程實現。用戶自己的軟件已經存在，業務邏輯也是經過長期打磨，對業務邏輯修改一定是慎之又慎。用戶期望的是不修改業務邏輯情況下，通過硬件實現業務處理的加速。

用戶沒有平臺依賴。軟件熱遷移需要一致性接口硬件，上層業務邏輯也需要一致性的硬件功能支持。這些都需要，站在用戶視角，不同芯片廠家提供的是接口和架構完全一致標準化的產品。

如果在CPU處理器上實現上述“完全可編程”的支持，非常簡單，但意義不大，因為沒有提升性能?！巴耆删幊獭笔窃诔悩嫷亩喾N異質處理引擎混合計算下，實現算力的數量級提升，同時仍能保持足夠的“完全可編程”能力。

3.2 芯片要很好的靈活性，適配復雜宏系統的各種變化

越是簡單的系統，變化越少，對靈活性的要求越低；越是復雜的系統，變化越大，對靈活性的要求越高。

在云網邊端萬物互聯的大背景下，系統具有如下一些變化：

隨著應用系統規模的擴大，系統在逐漸解構，傳統的巨服務在逐漸的變成一組微服務的系統，甚至客戶端，也分解成瘦客戶端和一組“微服務”的組合；

以服務器為例，物理的計算資源按照一定的粒度切分，然后組合出各種虛擬的計算資源組合，如虛擬機、容器等，形成多用戶的多個不同系統共存；這些虛擬的計算資源組合，再跟更多的虛擬計算資源組合形成軟件層次的集群協同。

更多用戶的更多集群系統共存于一個數據中心；還有跨數據中心的系統共存和協同；甚至，還有跨云網邊端的系統共存和協同。

系統越來越復雜，并且不同用戶不同系統混合部署于同一個物理的數據中心服務器上。系統對虛擬化、彈性擴展、可編程能力等靈活性能力的要求，遠高于單機系統。因此，要考慮單芯片如何大規模落地，就需要在靈活性方面重點關注：

一方面需要提升單芯片的擴展性、可編程性、靈活性、易用性等能力；

另一方面，需要提供基于芯片平臺的整體解決方案給到用戶，并且能夠提供很好的宏觀系統靈活性能力的支撐。

3.3 之后，才是大規模復制

當我們的單芯片，可以支持更大規模落地，可以支撐宏系統的各種復雜的能力要求，給駕馭宏觀系統的軟件工程師提供強大的基礎支撐。之后，才是通過大規模的算力建設來提升宏觀算力。

目前，超大規模數據中心越來越多，從傳統數百臺服務器的機房，升級到數千臺服務器的數據中心，再到數萬臺甚至數十萬臺的超大規模數據中心。都是通過數量的增加，來不斷提升宏觀總算力。

集中式的云數據中心還無法滿足所有場景的需求，數量眾多的邊緣數據中心也越來越多，進一步加大了在網的服務器數量，進一步增加了宏觀總算力。

2022年初，國家發改委、中央網信辦、工業和信息化部、國家能源局聯合印發通知，同意在京津冀、長三角、粵港澳大灣區、成渝、內蒙古、貴州、甘肅、寧夏等8地啟動建設國家算力樞紐節點，并規劃了10個國家數據中心集群。至此，全國一體化大數據中心體系完成總體布局設計，“東數西算”工程正式全面啟動。

“東數西算”，進一步通過規?；ㄔO，提升我們國家的宏觀總算力。

4 第三層：提升算力資源的利用率

算力資源的利用率，對算力的規模和成本影響非常巨大。麥肯錫的一份研究報告顯示，全球服務器的平均每日利用率通常最高僅為6%；據Gartner統計，全球數據中?利用率不足12%。以上數據都表明，數據中心的服務器成本及資源消耗存在巨大的“浪費”。如果可以把算力資源的綜合利用率從6%提升到90%，也就意味著可以立竿見影的增加15倍的宏觀算力，同時意味著單位算力成本下降到1/15。

4.1 最基本的，提升單芯片的計算資源利用率

在CPU為主流計算處理器的時候。通過操作系統，可以實現把一個個應用封裝成進程/線程，然后再經過調度，可以實現對計算資源的分時復用（單核情況下）。在多核情況下，就會通過多核調度器，實現對多個計算資源的綜合調度。

更進一步的，（站在單機系統視角）通過計算機虛擬化和容器虛擬化技術，進一步提升資源的利用率。

4.2 資源池化，把孤島連成一片，進一步提升資源利用率

如何提高宏觀算力的利用率？本質的就一句話：把眾多單個芯片的性能，匯集成一個大的算力資源池。反過來，如果獨立的各個芯片的性能，無法匯集成巨大的算力資源池，形成一個個孤島，單個芯片性能再高也沒有意義，一盤散沙，利用率也很難提升。

從這個意義上說，我們不僅需要關注如何提升單個芯片的資源利用率，還更應關注的是如何把無數多個計算資源匯集成龐大的資源池，可以非常靈活的資源切分、組合、分配和回收，從而提升宏觀算力利用率。

要把一個個個體的資源連接成巨大的資源池，需要：

硬件本身，需要支持（硬件）虛擬化，如Intel的VT-x/VT-d技術，包括IO設備，需要支持基于SR-IOV等技術的完全硬件虛擬化，加速器本身也需要支持虛擬化的邏輯處理通道。

在此之上，通過虛擬化技術，提升單個處理芯片的計算等資源的利用率，以及通過虛擬化技術中的軟件遷移功能，使得上層的業務軟件可以方便地選擇（整個資源池中）不同的物理資源運行。這樣才能實現資源的單硬件資源的切分和多硬件眾多資源的池化。

移動、電信等運營商積極倡導“算力網絡”技術，旨在通過網絡把宏觀所有的算力資源匯集成池，可以非常方便的為用戶提供最合適的算力組合，也可以最大限度的提升宏觀資源利用率。

4.3 挑戰在于，如何把異質的計算引擎池化

最理想情況是：CPU性能夠用，處理器依然是清一色的CPU處理器；所有CSP的所有的云和邊緣數據中心服務器，以及各類智能終端設備，都是一種架構，比如X86。這樣，我們就可以非常簡單地通過虛擬化技術和云和邊緣的分布式“操作系統”把處理器資源連接成一個巨大的唯一的算力資源池。

可惜的是，CPU的性能瓶頸，我們不得不通過各種硬件加速的方式，千方百計地來提升性能。這樣，超異構就會逐漸地成為計算架構的主流。超異構計算難以駕馭，數量眾多的處理器類型，會使得計算資源進一步碎片化，與計算資源池化背道而馳。

我們來進一步分析，如上圖所示，我們可以知道，各類處理引擎均存在各自不同的優勢和劣勢：

越左邊的處理引擎，覆蓋的場景越多，子類型越少，性能越低。例如CPU可以做到絕對的通用，可以適用于幾乎任意場景，因此只有一種子類型，但其性能最差。

越右邊的處理引擎，覆蓋的場景越少，子類型就需要的越多（例如有100個廠家，一個子類只能覆蓋一個場景，那么就需要有100個子類型，才能覆蓋所有場景），但性能卻會越來越好。

領域/場景越來越碎片化，構建生態越來越困難，需要從硬件定義軟件，逐步轉向軟件定義硬件。超異構計算處理引擎的類型和數量越來越多，（不同廠家）處理引擎架構越來越多，芯片平臺的數量越來越多，所處的位置（云網邊端）也越來越多，需要構建高效的、標準的、開放的生態體系。

最終，超異構計算，需要開源開放架構和生態（盡可能減少各種類型架構的數量，讓架構的數量逐漸收斂）；更需要能夠實現跨同類型不同架構以及不同類型架構處理器（引擎）的應用開發框架，如Intel oneAPI。

不同類型的計算資源最終需要匯集成單個資源池，因此，從不同的程度上來說，計算需要：

跨同領域不同架構的處理引擎子類，例如AI程序可以在不同的AI處理器上運行，軟件程序在x86、ARM或RSIC-v上均可運行；

跨不同類型的處理引擎，例如應用可以在CPU、GPU、FPGA或DSA運行；

跨不同廠家芯片平臺，例如整個軟件解決方案，可以在Intel平臺運行，也可以在NVIDIA平臺運行，也可以在其他各家芯片平臺運行；

跨云網邊端，微服務可以自適應的在云、網、邊、端任何位置運行，并且可以自適應的最優化的利用運行平臺的各種加速計算資源。

只有通過這樣一些辦法，把各類不同架構、不同類型、不同廠家、不同位置、不同的設備的資源連成唯一的一個巨大的計算資源池，才能真正避免算力資源孤島，才能真正實現算力資源利用率的最大化。

并且，超異構計算時代，不僅僅需要CPU（以及內存）支持硬件虛擬化，還需要其他的I/O設備、其他各類加速處理器（引擎）都需要支持硬件虛擬化?？梢园奄Y源通過時間或空間的切分和復用，實現資源的虛擬化，然后進一步通過虛擬化、算力網絡等技術，來提高資源的利用率。

最后，簡單聊一下開源開放。在單CPU處理器類型的時代，開源開放的RISC-v是我們的一個選項（還有x86和ARM可以選）。但到了超異構計算時代，開源開放就不是選項，而是唯一的出路。

審核編輯：劉清