整理｜核子可樂、冬梅

Stephen：是的，我們現在有最多的軟體工程師和硬體工程師。我記得幾年之前 CEO 黃仁勳曾經說過，“英偉達不再是一家硬體公司，而是一家軟體公司”。這話一點沒錯。

Stephen： 沒錯，我是 CUDA 團隊的架構師，而且從 2008 年開始就參與這個專案了。最初團隊裡只有 12 個人，那段經歷非常有趣。

記得我當初就是隨機加入了英偉達內部的團隊，當時大家的工作就是用顯示卡 GPU 做計算。結果剛一入職，我就發現大家都氣呼呼的。“咋的了這是？”我完全搞不清狀況。後來才知道，當時所有人都會用 3D Mark 基準測試來給硬體跑分，而 CUDA 會佔用掉 10% 的 GPU 資源。所有圖形開發同事都說 “它讓 3D Mark 得分低了 10%”，而且為此惱怒不已。我真的沒想到自己也會被捲進來。

但諷刺的是，如今的 GPU 保持著 90% 可程式設計、10% 固定功能的設計比例，相當於跟當初的情況完全顛倒了。我們在 CUDA 身上傾注的心血，最終在遊戲等各類用例下都在發揮作用。

Stephen： 當時有 OpenGL 和 DirectX，它們誕生於 2000 年左右。雖然我不是圖形專家，但大致上開發者會構建容納 3D 物件的場景並進行沉浸。OpenGL 就是構造這些場景、實現矩陣旋轉的工具。之後 OpenGL 開始提供一些可程式設計的小指令碼，這樣開發者就能實現幾何體變形之類的效果。這種可程式設計性當時被稱為可程式設計著色器，是 GPU 上最早的無固定功能硬體——也可以說是後來可程式設計設計的起源。

CUDA 的發明者是斯坦福大學的 Ian Buck，他想出瞭如何將普通編譯器對映為可程式設計形式。他在英偉達實習時說服了 Jensen，強調這隻會佔用晶片 10% 的資源。但正因為如此，同事們才特別不爽。但現在回想起來，這不就是圖形開發人員強調的“動態可程式設計著色、幾何圖形能創造出更好的遊戲畫面，更好的視覺效果”嗎？總之我們開始像設計計算系統那樣設計圖形系統，包含函式、迴圈、變數和 C 編譯器。

一切的開始源於固定函式渲染。固定函式渲染代表我們可以將網格傳遞到硬體，由硬體中的機制處理這些三角形並顯示在螢幕上。但在傳遞給硬體之前，這些函式大半都存放在軟體當中。正因為如此，OpenGL 和 DirectX 的驅動程式才特別複雜。各種東西中都需要內建編譯器，確保硬體本身始終以最高速度顯示出最多的三角形。

如今，我們已經可以使用著色器和核心來管理並控制幾何圖形的變形和移動了。所以，固定函式渲染的作用就是說明“這是個三角形，這是一張紋理圖，把它們顯示在螢幕上”。這是一份巨大的清單，能夠實現很多效果。但隨著技術發展，開發者們希望增強控制能力或者新增一些光源之類的效果，而最終成果就是可程式設計設計。

幾乎所有這些都可以在 GPU 中以高度輕量化的執行緒形式存在，它們可以執行最基本的程式碼。過去我們沒辦法使用 for 迴圈，一切內容都需要註冊，而且不能執行函式。那時候一切真的非常基礎，但至少可以獲取一些變數，把它們相加以得到另一個變數，再開平方等等。總之，這一點點計算量成就了更強的控制能力。

於是我們下定決心，哪怕圖形顯示還不需要 CUDA，我們也要藉此實現可程式設計性。事實證明我們是對的。但現在的情況又不一樣了，我們在圖形方面看到的不少重大進步，其實是來自基於 AI 的著色器、神經網路著色器等，比如機器學習 RTX。光線追蹤的技術原理雖然特殊，但 RTX 使其能夠嵌入微小的機器學習演算法，再以程式化方式生成結果，且速度比普通軟體演算法要快得多。

Stephen：CUDA 其實是一套集合。很多朋友在說起 CUDA 時，首先想到的是 CUDA C++ 語言。但不止於此，它包含一系列類似於 C++ 的庫，可以透過特定方式編寫並更好地發揮對應硬體的效能。它可以呼叫 cuDNN 的 PyTorch 框架，比如呼叫 cuBLAS、呼叫 cuTENSOR 乃至編譯器。PyTorch 下面的這一切都是 CUDA。甚至 CUDA 程式碼本身也代表著英偉達為 PyTorch 程式碼庫做出的貢獻。

所以說，CUDA 就是一套完整的技術棧。畢竟沒人願意直接編寫彙編程式碼，也幾乎不想編寫 C++ 這類低階程式碼，這就需要一套庫或者封裝的 SDK 幫大家解決需求。CUDA 有 10 個層，最底層是編譯器，負責獲取最終程式碼並將其對映至 GPU 執行緒。

DirectX 就是一個 SDK，是微軟打造的 API。其中是一組定義如何設定圖形的函式。大家在 Windows 上玩的任何遊戲幾乎都要依賴 DirectX。OpenGL 也差不多，只是有點跟不上時代了。Vulkan 取代了它的地位。如果大家在 Linux 上玩遊戲，那就要用到 Vulkan。這些都是標準圖形 SDK。雖然不一定能完全互換，但從功能上講，它們有很多共性。

Stephen：DirectX 是微軟的 API 規範，定義了圖形的設定方式。也就是說，英偉達 GPU 或者其他顯示卡只要實現了 DirectX API 和 Vulkan API，就能讓遊戲跟它們通訊。有些程式在英偉達 GPU 上執行效果更好，但 DirectX 永遠存在。Vulkan 則可以新增擴充套件及其他廠商特定的驅動程式，藉此支援某些核心硬體。

在 CUDA 專案期間，我們一直在努力達成的一個目標，就是讓同樣使用匯編語言的圖形管道和 CUDA 通用軟體開發管道保持互操作性。這也是 AI 在圖形領域的意義所在。機器學習模型及其執行、推理都是由 CUDA C++ 編寫而成。換言之，AI 核心、圖形核心和著色器可以共存並相互呼叫。

另外一個重點在於功率。我的筆記型電腦只有 150 瓦，桌上型電腦則有 1.5 千瓦。而哪怕是功率達到 20 兆瓦的資料中心，它的容納上限也是明確的。因此除非摩爾定律持續起效、電晶體數量不斷增加，否則缺少能效提升空間的電晶體總會耗盡我們的功率配額。因此，降低執行功率以維持相同或者更多晶片的執行，就成了一大核心目標。

能效的意義也得到了歷史的證明。隨著電晶體的縮小，啟動它們所需要的電量也在降低。直到 2006 年英特爾酷睿 2 釋出之前，這種思路都非常有效。但奔騰 4 第一次出現了功率問題，漏電子流效應意味著電子會逃離電晶體。這跟電阻無關，單純是量子力學所決定。這些電子會傳送到其他東西上，進而導致能量損失。

晶片開關的速度越快，能量損失的速度也會越快，進而拉低主頻。正因為如此，2006 年到 2007 年左右出現了一系列主頻很低的 CPU。它們的出現，打破了“主頻就是效能”的固有認知。

後來我們又遇到了單核功率瓶頸。 我們發現如果繼續縮小電晶體，那麼其功耗將會翻倍，導致電壓不足以正常實現狀態切換。結果就是當時的晶片主頻從 3、4 GHz 下降至 1.5 GHz，但雙核、四核和八核晶片逐漸誕生。如今某些 AMD 晶片甚至有 128 個核心。

核心數量的增加其實是種妥協性質的障眼法，是在掩飾半導體廠商已經無法繼續提高主頻的問題。這樣設計出來的晶片雖然理論上擁有雙倍效能，但也只有兩個核心全部滿負荷運轉時才成立，而當時絕大多數軟體根本不支援多執行緒。

所以如果觀察摩爾定律曲線，就會發現 CPU 的電晶體密度已經提高了 20 倍，但單執行緒、單核心效能卻僅僅提高了幾倍。所以除非採用並行處理，否則自 2006 年以來，後續釋出的 CPU 根本就沒什麼顛覆性的效能提升。

總之，我們已經在單核設計上窮盡了一切手段。繼續縮小電晶體的唯一好處，就是實現並行化。並行化是軟體領域的必要能力，GPU 就完全是在執行平行計算。當前的 GPU 大約可提供 25 萬個執行緒，這在過去簡直無法想象。

Stephen：CUDA 所關注的就不是單執行緒程式設計場景。我們在 CUDA 立項早期就確定了並行性的規劃方針。比如是把這種機制藏起來、公開出去，還是允許使用者思考並參與進來。

我們實際是把它分成了兩個部分，即粗粒度與細粒度。首先要明確一點，沒人能同時執行這 25 萬個執行緒。這世界上有兩種並行型別，其一是資料並行，即使用者擁有大量資料，比如需要渲染螢幕上的每一個畫素。這時候可以把任務拆分並展開，也就是分而治之的處理思路。

另外一種是任務並行，即場景中有多個物件，遊戲就是典型案例。你可能需要為多個物件改變幾何形狀、執行程式紋理、設定光源等等。這時候要做的就不是拿 25 萬個執行緒渲染同一個物件，而是要同時渲染 100 個物件，把這些物件分配給多個執行緒。

在 CUDA 之前，很多程式設計模型都只支援一種並行型別，即資料並行或者任務並行。但有了幾十萬個執行緒，我們覺得劃分應該更明確一些。比如根據實際需求把資料或者任務拆分成多個獨立部分，再各自分配 1000 個執行緒來處理。

我們讓這種拆分過程透明可見，這也更貼合 GPU 的實際執行狀態。CUDA 的一大原則，就是儘可能貼近硬體以實現最佳效能。GPU 內部的硬體擁有我們稱為流式多處理器（SM）的核心。當前的 GPU 擁有約 150 個這樣的核心，它使用這些核心進行程式分配，且每核心可執行 2000 個執行緒。

這就讓硬體擁有了自然拆分任務和資料的能力。比如先將 GPU 資源拆分成 150 個獨立的部分，接下來既可以把它們組合起來解決同一個問題，也可以指揮特定部分所對應的執行緒分別處理問題中的圖形或者演算法等具體環節。

這就是 CUDA 得以迅速發展的原因。隨著晶片越做越大並迎來流式多處理器，這種任務拆分自然會讓計算效能得到提升。這跟 CPU 完全不同——CPU 始終強調單執行緒，因此增加核心數量對於實際效能的貢獻往往比較有限。

Carter： 我是學物理學出身，程式設計設計方面的事我不太有發言權，但這種正規化變化確實給了我很大幫助。比如在 AI 爆發之前，CUDA 的第一個目標就是計算科學，希望最佳化天氣預報和計算生物學等的處理效能。

物理學家跟程式設計師不同，他們可以窮盡一生去探究物理世界的秘密。正是因為我發現自己缺少那樣極致的天賦，最終才決定投身計算機。我曾在大學物理實驗室工作過，那裡會把角色分得很開——有科學家、也有程式設計師，大家各司其職共同協作。物理學家不知道如何最大限度運用計算機，而程式設計師就出面解決這類需求。這種強強聯手的方式非常成功。

我們專門去找過這些物理學家，向他們介紹 CUDA 和多執行緒設計。他們剛開始確實會拒絕，因為這不是他們慣常的計算實現思路，沒想過怎樣把任務對映到大量執行緒上。但這種習慣思維意味著更大的問題必須由更大的計算機來解決，總有一天計算機會不夠大，這時工作就卡住了。

2000 年初那段時間，人們總覺得算力的提升是無上限的。但物理學家的態度更靈活，畢竟只要算力能再強哪怕一點點，結果都可能完全不同。所以他們對任何能幫助自己跨越新邊界的技術，都比較願意接受。

就比如說 2D 圖形到 3D 影像的轉換，後者對於供電和記憶體的需求百倍、千倍於前者。但大家都希望能儘早實現，而不是坐等摩爾定律帶來足夠強大的單臺計算機。

所以哪怕在 CUDA 之前，就有很多博士生在編寫新演算法，努力在更小的機器上解決更大的難題。我對這方面探索很感興趣，因此經常會出席超級計算會議，跟其他與會者交流心得。

讓我印象深刻的是，2019 年時大家都對 AI 嗤之以鼻，覺得這東西根本就不存在。但短短幾年的疫情之後，如今每個人都在聊 AI，比如“我把 AI 加入了自己的生物演算法”。

機器學習的強大之處，在於我們可以訓練它來生成一條複雜的函式，從而簡單快速地解決問題——哪怕我們並不完全理解它的基本原理。仍然以天氣預報為例，由於蝴蝶效應，地球上某個區域的微小變化會極大影響其他區域的天氣。

照傳統方法，我們需要對整個星球進行預測，採集國家氣象局的行星模擬資料。然而，世界上最大的計算機也只能以約 10 公里的解析度模擬行星。雖然從星球的角度來看，10 公里這個單位並不算大，但常規雲團的直徑也就是 1 公里，且足以決定特定區域的天氣。換句話說，老辦法根本不可能準確生成整個星球的天氣預報。

幾年之前，人們發現可以使用機器學習模型來填補空白，而且效果比傳統雲團模型好得多。海洋模型和雲團模型都是極其複雜的系統，但透過填充這些邊長 10 公里的正方形塊，它們能夠有效實現 1 公里的解析度。所以過去幾年間，天氣預報的預測範圍已經從 5 天延長到了 7 天甚至是 10 天。

在 AI 的幫助下，天氣預報突然就“支楞”起來了，這是因為機器學習演算法讓我們得到了更好的結果。

之所以能把天氣預報的範圍延長到 10 天，是因為機器學習演算法能夠實現原本難以做到的事情，比如處理近似非線性議程。簡單來講，AI 可以將上百萬個維度上的無數個點擬合成一條曲線。在訓練過程中，它會逐漸把握住這條與資料最貼近的曲線，並在之後的推理期間用曲線核查真實採集到的點。也正因為如此，推理的速度才會遠遠快於訓練。

這樣的 AI 填充技術不僅適用於天氣預報，也適用於其他場景。AI 演算法對極其複雜的蛋白質模型進行推理，徹底改變了計算生物學。但這裡又要說回功率的問題。電晶體越小，電子損失越嚴重。因此隨著我們不斷增加電晶體數量，能效並不能隨之倍增。畢竟我們常用的筆記型電腦就只有 150 瓦，桌上型電腦是 1.5 千瓦，它們能容納的電晶體總量是有限的。

但 AI 演算法能把評估成本降低至百分之一甚至千分之一。比如在圖形渲染中，AI 可以生成幾乎看不出區別的近似幀，同時保證不超過筆記型電腦的功率上限。這雖然不是真正的精確渲染，但卻可以讓每畫素的生成成本都滿足預算範圍，這在以往根本不可能實現。

因此我們才特別需要新的 AI 演算法，作為替代方案，它們能夠適應功率預算且繼續提供良好的計算結果。

雖然在圖形渲染中，AI 有時候可能生成偽影，比如當遊戲中的物件快速移動時，AI 仍在根據上一幀生成下一幀，因此顯示效果和正確效果間會有輕微差異。但總體來講，AI 還是能比傳統方法更好地呈現運動曲線。

計算的歷史一直由馮·諾依曼計算架構所主導，其強調的是可重複、精確且合乎邏輯。但如今我們正進入神經計算的新時代，其中的計算並不精確。我們輸入同樣的資料，有可能會得到略有不同的輸出，這是因為問題中的變數太多。神經計算具有容錯性，不會像馮·諾依曼計算那樣因錯誤而崩潰。

神經演算法為高度複雜的問題找到了非常簡單的解決辦法，唯一的代價就是得到的是近似結果、而非精確結果。但這對人類來說已經夠好了。當然，我們在某些場景下不想用 AI，比如說報稅——報稅過程絕對不能有幻覺。但 AI 在數學問題上的表現令人震驚，所以我相信很快我就能把所有日常事務都交給它了。

未來，馮·諾依曼計算和 AI 計算將攜手共存，可能還要再加上量子計算等其他計算型別。CUDA 的挑戰，在於找到一種方法讓程式設計師同時控制這兩種計算型別。作為異構系統，GPU 中包含多種不同用途的不同硬體，而 CUDA 需要將它們統一起來，提供一套能夠與之互動的通用平臺。

隨著市面上的硬體越來越多，我們也越來越難以為開發者提供一套簡潔、無縫的程式設計模型。時至今日，我們仍不清楚該如何把神經演算法、馮·諾依曼演算法和量子計算融合起來。我們在英偉達的一大工作重點，就是讓 Python 成為 CUDA 平臺中的重要部分，確保平臺中的各個部分，包括庫、SDK 和編譯器都能跟 Python 順暢互動。

我剛加入英偉達時，當時的晶片大約有 3 萬個執行緒。硬體在執行時會將這些執行緒組合成塊，再由 GPU 使用 SIMT（單指令、多執行緒）實現平行計算。其中大多數執行緒會保持獨立執行，允許每個執行緒在必要時執行不同的操作。

另外，將資料對映至執行緒對於機器學習演算法的效率和效能同樣至關重要。機器學習面臨著諸多挑戰，例如軟體棧太深以及如何將資料有效對映至硬體等。

現在 AI 領域中即時編譯正逐漸成為主流。只要獲得了問題的引數，就能針對其做程式碼最佳化。CUDA 則始終提供編譯器層，確保開發者能夠插入自己的語言和內容。現在透過線上執行即時編譯，我們希望人們能夠在各類場景下使用編譯器，藉此縮短編譯時間並最佳化程式碼，讓使用者更快獲取大模型輸出的 token。

這種依靠極端複雜軟體實現最快推理速度的目標不易達成，必須從中尋求平衡。比如說某些演算法雖然生成速度更快、首次推理時間更短，但演算法本身卻是錯的。總之這類場景下沒有完美答案，真正的關鍵在於對映結果，同時輔以延遲和效率。

Stephen： 當時，不同的圖形架構之間存在著廣泛競爭，各家廠商都在嘗試自己的思路。英偉達也有自己的方案，而且被證明效果相當出色。

而且這些並不能算 GPU，只是其他型別的圖形晶片。英偉達於 1993 年開始製造圖形晶片，剛開始只是用來加速某些渲染工作。當時 GL 已經出現，大家都想給這個問題找到答案。其中一種方式，就是放棄提升單一執行緒效能、加快其逐畫素處理能力，而是讓多個執行緒並行執行。但注意，當時的執行緒跟我們現在說的計算執行緒並不是一碼事。

比如說，光柵化器會獲取螢幕上某個位置的斜三角形，並確定哪些畫素有光照、它們在邊界上的亮度引數。光柵化器隨後將三角形轉換成畫素，而這是個非常簡單的操作。只要能夠複製多個邏輯閘，我們就能一次性渲染多個畫素，保證光柵化器飛快執行。從本質上講，這並不屬於可程式設計設計，畢竟只是在按電晶體和邏輯閘的序列來決定畫素顯示還是不顯示。但效果仍然不錯，我們確實能在每個時鐘週期內渲染出更多畫素。

而這也現在現代並行性設計的起點，人們開始嘗試透過專用晶片儘量提高效能。克隆所有邏輯閘以便一次處理更多畫素的想法，逐漸演變成了可程式設計性理論，最終形成了如今規模極大的多執行緒機器。

另外需要關注的是，儘管從 CUDA 的角度來看，GPU 本身就是一臺大規模並行機器，但它卻並不擅長執行 Linux 這類序列問題。這類任務還是要交給 CPU 才行。

而我認為理想的異構機器應該是 CPU 與 GPU 的結合——也正因為如此，我才特別讚賞英偉達的 Grace Hopper 硬體。其中採用了 Hopper GPU 並配合基於 ARM 架構的 Grace CPU（伺服器級 CPU），以調整記憶體將二者連線起來以實現資料共享。它的獨特之處，不止於透過匯流排連線起兩臺計算裝置，而更多體現為一種共享快取系統的協同關係。在這樣的混合裝置上，我們能夠以不同於以往純 CPU 或純 GPU 的方式對其進行程式設計。在這樣的裝置上，我們可以讓 CPU 專門執行 Linux，讓 GPU 專門執行並行程式設計。

2025 年，AI 平價化浪潮來襲，微服務架構如何藉助大模型技術實現突破？3 月 22 日，以《雲原生 × AI 時代的微服務架構與技術實踐》為主題的 CloudWeGo 技術沙龍將在深圳正式啟幕。活動邀請到來自字節跳動、火山引擎、智譜 AI 的多位技術大咖，分享 LLM 驅動的程式碼遷移、Go 語言開發 AI 智慧體、智譜清言從單體到微服務架構的轉型之路、CloudWeGo AI+ 微服務體系下的可觀測性實踐多個精彩議題，更有大咖圓桌對話環節。掃碼報名，共探 AI 與微服務的未來！歡迎掃碼或點選閱讀原文報名