在Python相關(guān)數(shù)據(jù)科學(xué)領(lǐng)域的社區(qū)中，近年來(lái)有一個(gè)計(jì)算資源選擇的趨勢(shì)：在數(shù)據(jù)挖掘階段，比如數(shù)據(jù)清洗、抽取和特征工程，開發(fā)者基本傾向使用 CPU ，調(diào) CPU 下的一些包；進(jìn)入建模階段之后，尤其在深度學(xué)習(xí)任務(wù)中，開發(fā)者會(huì)用 GPU 來(lái)處理模型訓(xùn)練和推斷。這兩個(gè)階段任務(wù)對(duì)應(yīng)的包的底層物理計(jì)算架構(gòu)，是切割得非常清楚的，當(dāng)然一些開發(fā)者可能由于 GPU 資源不夠用，會(huì)把建模和推理部分也放在 CPU 里處理，但是很少看到有人會(huì)把比如ETL、因子抽取等這些工作放在 GPU 中處理。

之所以出現(xiàn)這種情況，主要是由于異構(gòu)計(jì)算對(duì)資源要求比較高。原先這些計(jì)算資源沒有補(bǔ)齊，但是就目前來(lái)說(shuō)，開發(fā)者已經(jīng)比較容易獲得 GPU 資源或者其他一些計(jì)算資源。我今天想和大家分享的是因子抽取、ETL 等這些工作在 GPU 的支撐下會(huì)體現(xiàn)出更好的性能，接下來(lái)我會(huì)圍繞一個(gè)具體的作業(yè)案例跟大家進(jìn)行分享。

以上的作業(yè)案例比較簡(jiǎn)單，大體內(nèi)容是有兩個(gè)五5萬(wàn)乘以5萬(wàn)的矩陣，我們希望通過移窗求相關(guān)性系數(shù)。稍微有一些大數(shù)據(jù)經(jīng)驗(yàn)的朋友都知道，5萬(wàn)乘以5萬(wàn)的數(shù)據(jù)量是一個(gè)很小的數(shù)量級(jí)。這段代碼本身很簡(jiǎn)單，用的包也很簡(jiǎn)單——Pandas 的 Numpy，應(yīng)該說(shuō)是 Python 生態(tài)下面做數(shù)據(jù)科學(xué)計(jì)算最常用的一個(gè)包。我同時(shí)簡(jiǎn)單介紹一下這次計(jì)算的物理環(huán)境：有一個(gè) 20 個(gè)核心的 CPU，64G 的內(nèi)存，還有一塊3090的顯卡，24G 顯存。我們現(xiàn)在就準(zhǔn)備拿剛才那一份腳本來(lái)跑。大家可以想一下，剛才那個(gè)小腳本在這樣的環(huán)境下面跑，會(huì)出現(xiàn)什么樣的問題？

Demo 1

腳本跑起來(lái)之后，大家會(huì)發(fā)現(xiàn)內(nèi)存的占用增加地非?？?。我們?cè)O(shè)置為在數(shù)據(jù)加載完成和計(jì)算開始的時(shí)候都會(huì)做打印，在數(shù)據(jù)加載的階段，內(nèi)存占用情況比較危險(xiǎn)，數(shù)據(jù)加載完成后，內(nèi)存已經(jīng)用掉大約 20G 了。從常規(guī)經(jīng)驗(yàn)來(lái)說(shuō)，這個(gè)占用情況是比較出乎意料的，因?yàn)檫@只是兩個(gè) 5 萬(wàn)乘 5 萬(wàn)的矩陣，而且我們進(jìn)行的是單精度計(jì)算。這個(gè)任務(wù)失敗原因是內(nèi)存不足。我們用一個(gè)常規(guī) Pandas 的 Numpy 的處理包，在這樣的物理資源之下居然跑不了一個(gè)相對(duì)簡(jiǎn)單的任務(wù)?，F(xiàn)在我們把矩陣排成 5 萬(wàn)乘 1 萬(wàn)再看一下具體的耗時(shí)情況。這個(gè)任務(wù)在改寫后，可以執(zhí)行完成，其用時(shí)是 45 秒。我們稍后會(huì)嘗試把剛才的任務(wù)在 GPU 環(huán)境下運(yùn)行，會(huì)用到一些 GPU 的上的包，我們將對(duì)其進(jìn)行改寫和遷移，再看性能上會(huì)不會(huì)有較大的提升。

Python的GPU計(jì)算生態(tài)

在數(shù)據(jù)科學(xué)的領(lǐng)域里面，GPU 相較于 CPU，其性能優(yōu)勢(shì)體現(xiàn)在哪里？首先最顯著的是特點(diǎn)是 GPU 為多核，一般有上千核心，但是 GPU 的單核心和 CPU 處理器的單核心在性能上相比是差了很多的。待執(zhí)行的任務(wù)如果是一個(gè)能非常好地進(jìn)行并行化的結(jié)構(gòu)表，并且每一個(gè)計(jì)算單位的計(jì)算復(fù)雜度不是特別高，我們可以通過并行化對(duì)其進(jìn)行計(jì)算。這種情況下，如果我們把任務(wù)分配給 GPU 去計(jì)算的話，一般都會(huì)獲得很大的效率提升。

Python 生態(tài)下面有很多 GPU 計(jì)算相關(guān)的包，尤其是剛剛過去的這三四年里，社區(qū)里很多項(xiàng)目都開始做數(shù)據(jù)科學(xué)相關(guān)的類，比如說(shuō) Pandas 或者 Numpy。當(dāng)然大家最熟悉還是 Tensorflow、Pytorch 這些面向 AI 的 Python上層的包。

· CUDA API：Numba，CuPy，PyCUDA

· 類Pandas：cuDF，Dask-cuDF

· 類SciKit-learn：cuML

· 類NumPy：cuNumeric

· 類NetWorkX：cuGraph

· 上層框架：TensorFlow，Pytorch等

我梳理了一些包，這里也有我用過一些，比如 cuDF。從使用上面來(lái)說(shuō)，現(xiàn)在還有很多比較基礎(chǔ)的計(jì)算子沒有被覆蓋，在實(shí)際使用當(dāng)中也會(huì)有一些未知的 bug。當(dāng)然，一個(gè)軟件包在它的發(fā)展初期，很容易出現(xiàn)類似的問題。總體使用下來(lái)，我感到 Numba 在發(fā)展了十幾年之后，在 GPU 的作業(yè)任務(wù)里使用起來(lái)是比較穩(wěn)定的。另外 Numba 是直接用 Python 去封裝 CUDA 的，大家使用起來(lái)也會(huì)比較順手。因?yàn)?Numba 是直接調(diào) CUDA 層，所以計(jì)算的適應(yīng)性、覆蓋性都比較高。在稍后的案例中，我也會(huì)用 Numba 來(lái)運(yùn)行。在具體進(jìn)行 GPU 編程之前，我會(huì)簡(jiǎn)單介紹 GPU 編程、異構(gòu)計(jì)算的基本概念。

GPU編程硬件基礎(chǔ)

CPU 和儲(chǔ)存設(shè)備（也就是我們常說(shuō)的內(nèi)存），一般統(tǒng)稱為主機(jī) Host；GPU 和顯存的部分稱為設(shè)備，主機(jī)和設(shè)備之間在主板上通過 bus 進(jìn)行通信。也就是說(shuō)，我們的數(shù)據(jù)先通過 CPU 的一些包把先拉取到內(nèi)存里，但如果要放到 GPU 上去計(jì)算，是要先把這個(gè)數(shù)據(jù)遷移到 GPU 的顯存里面才能夠進(jìn)行計(jì)算。計(jì)算完成后，如果計(jì)算最終需要在 CPU 的里面和 CPU 下面的內(nèi)存里面做計(jì)算驗(yàn)證，那么還是要把數(shù)據(jù)通過總線（bus）從顯存里面遷移出去。我們談到性能調(diào)優(yōu)，是主要是圍繞 bus 層進(jìn)行通信資源和計(jì)算資源的調(diào)用和優(yōu)化。

· 核函數(shù)：表示該函數(shù)是一個(gè)在GPU設(shè)備上運(yùn)行的函數(shù)，需要在核函數(shù)上添加@cuda.jit裝飾符。

· 執(zhí)行配置：主函數(shù)調(diào)用GPU核函數(shù)時(shí)，需要添加如[2, 4]這樣的執(zhí)行配置，例如gpu_print2, 4表示同時(shí)開啟8個(gè)線程并行地執(zhí)行g(shù)pu_print函數(shù)，函數(shù)將被并行地執(zhí)行8次。

· 計(jì)算同步：由于CPU與GPU在任務(wù)執(zhí)行上是異步的，如果CPU任務(wù)需要GPU的計(jì)算結(jié)果，則需要調(diào)用cuda.synchronize()來(lái)進(jìn)行同步。

在 CUDA 進(jìn)行編程開發(fā)還涉及到一些基本概念。首先是核函數(shù)，核函數(shù)是在 GPU 上面跑的函數(shù)，在寫法上，我們一般會(huì)在函數(shù)上面加 @cuda.jit 裝飾符，任務(wù)分配的時(shí)候我們要做一個(gè)執(zhí)行配置，在這個(gè)case里面，我們的執(zhí)行配置是中括號(hào)里面[2,4]，2x4 乘起來(lái)是 8，它代表的是這個(gè)任務(wù)會(huì)被并發(fā)地執(zhí)行八次。任務(wù)計(jì)算完之后，一般整體作業(yè)任務(wù)會(huì)是比較復(fù)雜的，后續(xù)還可能要執(zhí)行多個(gè)步驟。在執(zhí)行下一步驟的時(shí)候，我們需要用到上一步的計(jì)算結(jié)果，如果上一步計(jì)算是在 GPU 場(chǎng)景下進(jìn)行的，那我們需要用 cuda.synchronize() 進(jìn)行計(jì)算同步。這段代碼和一般作業(yè)任務(wù)組織不同之處在于核函數(shù)處理部分，相當(dāng)于在常規(guī)寫法上增加一部分，而這部分其實(shí)是基于線程次序的。

GPU線程和物理資源分配

談及線程次序之前，我們先將線程相關(guān)的基礎(chǔ)概念進(jìn)行一些講解。首先， CUDA 核函數(shù)定義的運(yùn)算都是放在單獨(dú)線程的，多個(gè)線程它可以組成一個(gè)塊（Block），多個(gè)塊可以組成一個(gè)網(wǎng)絡(luò)（Grid）， 單線程是對(duì)應(yīng)一個(gè) CUDA 的。線程在 Core 上面跑，Block 在 SM 上面跑，Grid 則對(duì)應(yīng)著一個(gè)任務(wù)。

我們接下來(lái)將介紹怎么找線程中的序號(hào)，為什么要找這個(gè)序號(hào)呢？是因?yàn)?GPU 要發(fā)揮它的性能，而它最大的性能優(yōu)勢(shì)在于多核心，所以在 GPU 更適用于并行計(jì)算的場(chǎng)景。常規(guī)來(lái)說(shuō)我們要對(duì)大數(shù)據(jù)進(jìn)行切割，然后把它們放在一個(gè)一個(gè)線程里。當(dāng)數(shù)據(jù)處理完成，返回結(jié)果的時(shí)候，系統(tǒng)默認(rèn)為亂序返回，所以如果我們不知道線程對(duì)應(yīng)的是哪個(gè)序號(hào)的話，數(shù)據(jù)就回不去了。

我們?cè)谟?GPU 計(jì)算的時(shí)候，核心的工作是做數(shù)據(jù)和線程綁定，那么線程怎么去做綁定呢？首先我們要先會(huì)找線程的序號(hào)，在 CUDA 中找線程序號(hào)是比較容易的，因?yàn)?CUDA 已經(jīng)內(nèi)置了我們所需要用的參數(shù)了。

· 通過CUDA提供的內(nèi)置變量，記錄thread和block的大小及索引下標(biāo)，以[2, 4]配置為例：

· blockDim.x：表示block的大小是4，即每個(gè)block有4個(gè)thread；

· threadIdx.x：是一個(gè)從0到blockDim.x - 1（4-1=3）的索引下標(biāo)，記錄這是第幾個(gè)thread；

· gridDim.x：表示grid的大小是2，即每個(gè)grid有2個(gè)block；

· blockIdx.x：是一個(gè)從0到gridDim.x - 1（2-1=1）的索引下標(biāo)，記錄這是第幾個(gè)block

最重要參數(shù)是上面的這4個(gè)。 blockDim.x 是表示已設(shè)置的 block大?。?threadIdx.x 是我們的線程的序號(hào)，它表示的是單個(gè) block 線程序號(hào)，從 0 到 blockDim.x-1；下面這個(gè) gridDim.x 表示，作業(yè)任務(wù)分配多少個(gè) block；blockIdx.x 是表示的是在 grid 里 block 的次序。比如說(shuō)，這個(gè)綠框表示的線程是在第一個(gè) block 里面的第二個(gè)次序。

· 某個(gè)thread在整個(gè)grid中的位置編號(hào)為：threadIdx.x + blockIdx.x * blockDim.x

有了4個(gè)參數(shù)之后，接下來(lái)計(jì)算就很簡(jiǎn)單了。比如，我們要計(jì)算 2 號(hào)序線程，實(shí)際上首先我們把確定 blockDim 是在第幾個(gè) block，再加上它在這個(gè) block 里的次序，就可以獲得。

執(zhí)行配置?[gridDim, blockDim]一般遵循的配置規(guī)則：

· block運(yùn)行在SM上，不同硬件架構(gòu)（Turing、Volta、Pascal…）的CUDA核心數(shù)不同，一般需要根據(jù)當(dāng)前硬件來(lái)設(shè)置block的大小blockDim。一個(gè)block中的thread數(shù)最好是32、128、256的倍數(shù)。注意，限于當(dāng)前硬件的設(shè)計(jì)，block大小不能超過1024。

· grid的大小gridDim，即一個(gè)grid中block的個(gè)數(shù)可以由總線程數(shù)N除以blockDim得到，并向上取整。

· block和grid的大小可以設(shè)置為二維甚至三維。

如何設(shè)計(jì)執(zhí)行配置

了解到核函數(shù)如何通過線程次序進(jìn)行綁定后，接下來(lái)我們涉及到的是執(zhí)行配置的操作問題。執(zhí)行配置分兩部分，（1）gridDim（2）blockDim。blockDim 表示任務(wù)要怎么分，一個(gè) block 里面要包含多少線程；gridDim表示作業(yè)任務(wù)要分配多少 block，在整個(gè)執(zhí)行過程中，我們很多調(diào)配工作是依賴于經(jīng)驗(yàn)的，具有一定的實(shí)驗(yàn)性質(zhì)。這主要是因?yàn)槲覀兪褂玫?GPU 的硬件架構(gòu)設(shè)計(jì)不一樣，很多時(shí)候要參考技術(shù)表。技術(shù)表介紹了計(jì)算任務(wù)和其限制，以及最終這些內(nèi)容在物理架構(gòu)上是怎樣實(shí)現(xiàn)的。如果我們需要極致優(yōu)化計(jì)算性能，一般來(lái)說(shuō)要根據(jù)計(jì)算卡本身的屬性去做相應(yīng)場(chǎng)景的適配，而且很多時(shí)候我們是需要通過調(diào)試來(lái)完成優(yōu)化的。

我們說(shuō)到的 blockDim、gridDim ，它最多可以寫成三維。相較于 gridDim，這個(gè) blockDim 尤其需要我們注意，它雖然可以寫成三維 x、y、z，但是它是一個(gè) block 最多只能包含 1024 個(gè)線程。所以不管 x、y 這里寫了多少，相乘得到的最終數(shù)值不能超過1024。

我們?cè)賮?lái)看一下 CUDA 對(duì)于數(shù)據(jù)在 bus 層的調(diào)取機(jī)制是怎樣的。CUDA 在調(diào)取機(jī)制上進(jìn)行了自動(dòng)化處理，做計(jì)算的時(shí)候，如果我們所調(diào)用的數(shù)據(jù)沒有在內(nèi)存上面，調(diào)取機(jī)制啟動(dòng)后，系統(tǒng)會(huì)自動(dòng)在內(nèi)存上拉取進(jìn)行計(jì)算。在數(shù)據(jù)計(jì)算量較大的情況下，我們需要對(duì)數(shù)據(jù)進(jìn)行切分再進(jìn)行并行計(jì)算，如果計(jì)算步驟較多，自動(dòng)機(jī)制容易造成通信資源的浪費(fèi)。因?yàn)橄乱徊降挠?jì)算也是在 GPU 上進(jìn)行的，但是如果系統(tǒng)進(jìn)行自動(dòng)拉取，它會(huì)把數(shù)據(jù)就直接又拷貝回內(nèi)存，進(jìn)行下一步計(jì)算的時(shí)候，它又要從內(nèi)存里面去拉取過來(lái)，這時(shí)候整體的性能會(huì)受到很大影響。

如果我們處理的是大數(shù)據(jù)類型，進(jìn)行大型層計(jì)算的話，我們?cè)趯懩_本的時(shí)候應(yīng)該先把數(shù)據(jù)進(jìn)行分配，用腳本的形式直接寫好。明寫出來(lái)的需要用到一些函數(shù)。這邊最常用的話是 cuda.to_device() ，它代表的是把主機(jī)上面的數(shù)據(jù)拷貝到設(shè)備；另外一個(gè)常用的函數(shù)是 cuda.copy_to_host()，它代表的是計(jì)算最終完成了，把結(jié)果拷貝回內(nèi)存里。由于最終的計(jì)算結(jié)果整體的數(shù)據(jù)維度可能也比較大，那么我們事先應(yīng)該先開辟這個(gè)空間，可以用 cuda.device_array() 和 numpy.empty() 等功能去訪問?；旧?CUDA 編程就會(huì)用到以上這些內(nèi)容。

這是一個(gè)簡(jiǎn)單的 demo 程序，用 GPU 做加法，加法的函數(shù)很簡(jiǎn)單。首先我們先找到線程序號(hào)，這一點(diǎn)是按照次序把數(shù)據(jù)計(jì)算填到每個(gè)結(jié)果的向量中，在進(jìn)行資源配置的時(shí)候，block 分配有 1024 的限制。常規(guī)來(lái)說(shuō) gridDim 任務(wù)中每一個(gè) grid 要分配多少 block，是通過整體計(jì)算量去除以每一個(gè) block 里面的線程數(shù)量得到的，即除以1024，再向上取整去算，很多情況下會(huì)產(chǎn)生冗余的線程。在設(shè)計(jì)核函數(shù)的時(shí)候我們會(huì)加一個(gè)判定，當(dāng)線程次序已經(jīng)運(yùn)行到我們不需要冗余線程的時(shí)候，就強(qiáng)制解除。

Demo 2

我們現(xiàn)在基本上已經(jīng)掌握基本 CUDA 編程的寫法，現(xiàn)在我們對(duì)剛才求相關(guān)性的作業(yè)做了重啟，我們把它遷移到 GPU 環(huán)境再嘗試運(yùn)行，現(xiàn)在可以看到顯存利用的情況，雖然計(jì)算中有波動(dòng)，但是峰值還沒有超過 6 個(gè)G，任務(wù)花費(fèi)的時(shí)間已經(jīng)從剛才的 45 秒優(yōu)化到了 5.5 秒。很多數(shù)據(jù)科學(xué)相關(guān)作業(yè)場(chǎng)景，都是適合放在 GPU 上去做計(jì)算的。雖然遷移的工作量并不小，但是我們獲得的性能提升非常大。

CUDA編程特性-多流

已經(jīng)遷移到 GPU 上計(jì)算的這個(gè)任務(wù)，有沒有可能再做進(jìn)一步優(yōu)化呢？其實(shí)它的優(yōu)化空間還非常大。我們剛才只是交代了 CUDA 編程里面的一些基礎(chǔ)寫法，其實(shí) CUDA 里面還有很多優(yōu)化點(diǎn)，這都是來(lái)自于 CUDA 自身一系列編程特性。今天我先介紹多流的特性。

首先說(shuō)一下流的概念，它指的是 CUDA 將放入隊(duì)列順序執(zhí)行的一系列操作。多流在 CPU 中也經(jīng)常會(huì)用的，在 GPU 上的執(zhí)行的情況也差不多?！岸嗔鳌敝傅氖前岩粋€(gè)大任務(wù)拆分開，放到多個(gè)流中，每次只對(duì)一部分?jǐn)?shù)據(jù)進(jìn)行拷貝、計(jì)算和回寫，并把這個(gè)流程做成流水線，大任務(wù)的計(jì)算和數(shù)據(jù)拷貝進(jìn)行并發(fā)執(zhí)行，從而獲得性能提升。

stream 0 就是默認(rèn)的流，剛才已經(jīng)執(zhí)行那一份 CUDA 腳本是用默認(rèn)的流去計(jì)算的。我們把所有需要計(jì)算的整份數(shù)據(jù)先統(tǒng)一拷貝到顯存上面，進(jìn)行計(jì)算后再統(tǒng)一地拷貝回來(lái)。如果我們換成多流的方式去處理，針對(duì)特別大的數(shù)據(jù)先拆分再放在不同流并發(fā)去執(zhí)行。相較于默認(rèn)的流，拆分所需要拷貝時(shí)間花費(fèi)的時(shí)間，遠(yuǎn)小于多流寫法中節(jié)省的計(jì)算時(shí)間，所以整體這個(gè)計(jì)算性能是有提升的。

· 使用多流時(shí)先定義流：stream = numba.cuda.stream()

· CUDA的數(shù)據(jù)拷貝以及核函數(shù)都有專門的stream參數(shù)來(lái)接收流，以告知該操作放入哪個(gè)流中執(zhí)行

numba.cuda.to_device(obj, stream=0, copy=True, to=None)

numba.cuda.copy_to_host(self, ary=None, stream=0)

· 核函數(shù)調(diào)用的地方除了要寫清執(zhí)行配置，還要加一項(xiàng)stream參數(shù)

kernel[blocks_per_grid, threads_per_block, stream=0]

以上是使用多流會(huì)用到的基礎(chǔ)的函數(shù)，包括怎么樣去定義流。我們用的是 cuda.stream 去申請(qǐng)一個(gè)流。在下面不管是數(shù)據(jù)的遷移 to_device，to_host，還是具體資源配置放到核函數(shù)里面，我們只需要能把序號(hào)填進(jìn)去，就能夠?qū)崿F(xiàn)計(jì)算。

我們回到剛才的 demo 代碼。我們即使將其改成多流，核函數(shù)也是無(wú)需更改的，我們只需要把數(shù)據(jù)遷移的部分和資源分配的部分改成多流，以上的代碼中就包含了多流的寫發(fā)。首先我們會(huì)生成 5 個(gè)流，這部分?jǐn)?shù)據(jù)做了切分，在遷移的時(shí)候我們?cè)诤瘮?shù)里把序號(hào)填進(jìn)去，核函數(shù)保持一致，這個(gè)任務(wù)就調(diào)配成了多流的模式。

Demo 3

這個(gè)任務(wù)改成多流后的運(yùn)行性能是怎么樣的？我們可以看到顯存的調(diào)用波動(dòng)的范圍還是比較大的，但是同樣的代碼，用默認(rèn)的流執(zhí)行最終花費(fèi) 5.5 秒，用多流去跑只需要 3 點(diǎn)多秒的時(shí)間就可以跑完，從百分比上來(lái)看，還是有較大的性能提升的，我們的案例計(jì)算規(guī)模比較小，如果是大規(guī)模計(jì)算，這樣比例的效率提升則會(huì)更為可觀。

對(duì)于個(gè)人用戶來(lái)說(shuō)的話，平時(shí)如果處于學(xué)習(xí)或愛好去跑一些作業(yè)任務(wù)，為此單獨(dú)去買一個(gè)顯卡是不太經(jīng)濟(jì)的。如果我們希望測(cè)試不同種類的 GPU 架構(gòu)的話，就更不劃算了。GPU 下面有很多 Python 生態(tài)下面的包，都是最近進(jìn)行開發(fā)和維護(hù)的，除非我們非常熟悉它們的特性，否則作環(huán)境配置的時(shí)候，會(huì)碰到一些不知名的問題。環(huán)境配置其實(shí)是比較麻煩，尤其有一些包在互相之間調(diào)用的時(shí)候，所需要調(diào)的 CUDA 層版本可能不大匹配。在這種情況下，矩池云MATPool應(yīng)運(yùn)而生，大家的數(shù)據(jù)、計(jì)算腳本等等都可以放在網(wǎng)盤，調(diào)用數(shù)據(jù)、調(diào)用 GPU 資源等也都是開箱即用的模式。我們可以在一個(gè)已經(jīng)布置好環(huán)境的場(chǎng)景中調(diào)用 GPU，我們的網(wǎng)盤里面已經(jīng)存有腳本和數(shù)據(jù)，也就是說(shuō)一旦計(jì)算任務(wù)完成了，我們可以直接把物理資源釋放，這樣我們也就相當(dāng)于擁有了隨身攜帶的 GPU 計(jì)算資源。

完整演講視頻