如果你以為 DeepSeek 最新開源的項(xiàng)目又是一份讓人驚艷的模型權(quán)重那可能把這次動作看小了。這次開源的是一整套底層軟件棧包括面向特定模型結(jié)構(gòu)的高性能計(jì)算內(nèi)核、多卡通信庫、分布式文件系統(tǒng)和數(shù)據(jù)處理框架。模型是蓋在上面的樓這一層才是承重結(jié)構(gòu)和地基。今天這篇就把“算力地基”這幾個(gè)字拆開聊透講清楚它到底解決了什么問題、為什么難、以及你可以在自己的機(jī)器上怎么把這一套跑起來。先說一個(gè)我自己的判斷過去兩年開源 AI 領(lǐng)域最不缺的就是“新模型”——今天一個(gè) 7B明天一個(gè) 13B大家都想讓你下載權(quán)重跑個(gè) Demo。但真正稀缺的是讓這些權(quán)重能在不同硬件上高效跑起來的那層看不見的軟件。DeepSeek 這次開源的恰恰是后者?？炊@件事的人已經(jīng)在動手搭建自己的算力底座還沒意識到這一點(diǎn)的朋友可能錯(cuò)過了近期對整個(gè) AI 硬件生態(tài)最有價(jià)值的一次開放。1. 這次開源的到底是什么1.1 模型之外的另一件大事我們通常說的“開源一個(gè)模型”拿到的是一堆權(quán)重文件加一個(gè)推理腳本下載權(quán)重、加載、輸入文字、輸出文字完了。這當(dāng)然很有用但它只解決了“能用”的問題沒有解決“用好”和“規(guī)?；谩钡膯栴}。這次 DeepSeek 開源的東西跟模型權(quán)重相比是另一個(gè)維度的產(chǎn)物。按照公開資料和代碼倉庫的整理大致包含幾個(gè)層次一個(gè)或者多個(gè)針對特定模型結(jié)構(gòu)優(yōu)化的高性能計(jì)算內(nèi)核比如解碼階段用的注意力算子。一套面向多卡、多機(jī)場景的通信庫用于大規(guī)模并行訓(xùn)練和推理。一套分布式文件系統(tǒng)解決多節(jié)點(diǎn)讀寫訓(xùn)練數(shù)據(jù)時(shí)的吞吐瓶頸。一個(gè)數(shù)據(jù)處理框架讓海量樣本在進(jìn)入模型之前就能完成切分、打散、緩存等操作。這些東西不直接產(chǎn)生“一句話回答”但它們是讓模型訓(xùn)練不中斷、讓推理不卡頓、讓多卡利用率不暴跌的關(guān)鍵。打個(gè)比方模型權(quán)重像是一份精致的菜譜而這次開源的是廚房的水管、電路、排煙管道。菜譜好抄水電改造成本高得多。DeepSeek 把后者也一起開放了這才是“地基”二字的真實(shí)含義。很多開發(fā)者的第一反應(yīng)是“我又不搞超大規(guī)模集群這些跟我有什么關(guān)系”關(guān)系比你想象的大。即便你只在單卡上跑推理高性能內(nèi)核能不能被調(diào)用直接決定你的輸出速度是 50 token/s 還是 20 token/s。通信庫與文件系統(tǒng)看似屬于大集群的事但現(xiàn)代消費(fèi)級顯卡也能湊出兩臺機(jī)器做并行多機(jī)效率從 30% 提到 80%依賴的正是這一類底層軟件。1.2 三層地基分別解決什么問題為了把“算力地基”講清楚我習(xí)慣把這個(gè)層次拆成三個(gè)問題單卡快不快、多卡強(qiáng)不強(qiáng)、數(shù)據(jù)供不供得上。第一層是單卡計(jì)算效率。顯卡的理論算力很高但那是硬件的極限能力。能不能把極限能力釋放出來取決于算子實(shí)現(xiàn)的好壞。很多人用過通用推理框架可能遇到過“同一個(gè)模型在 A 卡上很快在 B 卡上慢 3 倍”的情況。很多時(shí)候不是 B 卡硬件差而是 B 卡上的算子沒有針對性優(yōu)化或者直接走了一個(gè)非常保守的通用 fallback 實(shí)現(xiàn)。第二層是多卡通信效率。大模型動輒幾十億上百億參數(shù)單卡顯存放不下必須切成多份放到多張卡上。機(jī)器之間要頻繁地同步梯度、交換激活值。如果通信庫寫得不好你會看到一個(gè)尷尬的現(xiàn)象加機(jī)器速度沒有線性提升甚至因?yàn)橥ㄐ砰_銷大于計(jì)算收益越加越慢。第三層是數(shù)據(jù)供給效率。訓(xùn)練過程里 GPU 吃數(shù)據(jù)的速度驚人幾 TB 的數(shù)據(jù)集如果按傳統(tǒng)方式從普通文件系統(tǒng)讀取GPU 會長期處于“等數(shù)據(jù)”的狀態(tài)。文件系統(tǒng)與數(shù)據(jù)處理框架解決的就是“喂得飽而且喂得快”的問題。以前這三層軟件棧通常由每個(gè)硬件廠商各自維護(hù)和自家硬件綁定得很死。DeepSeek 這套開源方案的價(jià)值在于它把三層地基做成了相對通用的公共底座。硬件廠商不必從零開始造輪子應(yīng)用開發(fā)者也不必為一套特定的卡寫死代碼。2. 不是所有算力都能直接拿來用2.1 紙面算力不等于真實(shí)算力很多朋友第一次接觸加速卡選型時(shí)都會盯著“每秒多少萬億次浮點(diǎn)運(yùn)算”這個(gè)指標(biāo)。我不否認(rèn)它重要但真正決定模型跑多快的是“有效算力”——也就是在真實(shí)模型負(fù)載下能被軟件端到端發(fā)揮出來的那部分算力。有效算力和紙面算力之間的差距可能大得離譜。一個(gè)設(shè)計(jì)良好的算子可能把硬件的有效算力用到 70% 以上一個(gè)倉促寫成的通用算子可能連 15% 都到不了。差距來自哪里分塊策略、寄存器復(fù)用、訪存模式、指令級并行度每一個(gè)細(xì)節(jié)都能讓性能產(chǎn)生數(shù)量級差異。打個(gè)生活化的比方同樣一段高速路紙面數(shù)據(jù)是限速 120 km/h但實(shí)際通行效率取決于入口匝道設(shè)計(jì)、收費(fèi)站數(shù)量、車道標(biāo)線清晰程度。軟件棧就是這些“道路交通設(shè)施”路修得再好設(shè)施跟不上也跑不快。我在測試不同硬件時(shí)經(jīng)常遇到一種情況評測軟件顯示某張卡的矩陣乘算力很強(qiáng)跑真實(shí)模型卻總是慢半拍。把性能剖析工具拉出來一看問題出在注意力實(shí)現(xiàn)上——普通的 attention 實(shí)現(xiàn)沒有做分頁顯存KV Cache 頻繁拷貝光內(nèi)存搬移就吃掉了一半帶寬。這就是典型的有算力但用不出來的場景。2.2 不同架構(gòu)之間的隱形壁壘除了硬件本身的差異更大的障礙來自軟件生態(tài)。不同加速卡有完全不同的指令集、內(nèi)存模型、編譯工具鏈和驅(qū)動接口。今天你在主流顯卡上寫的 CUDA 代碼換到另一個(gè)平臺大概率一行都跑不通。不是代碼邏輯不對而是硬件根本不認(rèn)識這套指令。更深層的壁壘有三個(gè)算子庫成熟度主流加速卡背后有沉淀多年的數(shù)學(xué)庫矩陣乘、卷積、歸一化這些都有高度優(yōu)化的現(xiàn)成實(shí)現(xiàn)。其他平臺可能只有一個(gè)功能不全的初版庫缺算子時(shí)就得自己寫。編譯器成熟度自動向量化、循環(huán)重排這些優(yōu)化能力成熟的編譯器已經(jīng)做得很好新興平臺的編譯器常常還比較“老實(shí)”代碼怎么寫它就怎么執(zhí)行?；ヂ?lián)方案差異多卡通信有的走標(biāo)準(zhǔn)網(wǎng)絡(luò)有的走專用高速互聯(lián)還有的用 RDMA。通信庫必須適配每一種拓?fù)浞駝t就會產(chǎn)生嚴(yán)重延遲。這就是為什么“硬件發(fā)布”到“能真正跑大模型”之間通常要隔十八個(gè)月甚至更久的軟件適配期。DeepSeek 開源的這套東西正在用公共代碼庫的方式壓縮這個(gè)等待周期只要這層地基是開放的所有硬件生態(tài)都能站在同一條起跑線上。2.3 顯存與通信是隱形的天花板很多人以為大模型跑不動是因?yàn)樗懔Σ粔蚱鋵?shí)顯存容量、顯存帶寬和通信帶寬往往更早成為瓶頸。模型參數(shù)越來越大顯存卻卡在幾 GB 到幾十 GB 的物理邊界。為了裝下模型不得不做量化、張量并行、分批調(diào)度這些全都是底層的工程問題。通信層面更麻煩。大模型訓(xùn)練時(shí)梯度同步的通信量動輒以 GB 為單位。數(shù)據(jù)并行每次反向傳播結(jié)束都要做一次全局梯度同步通信耗時(shí)如果和計(jì)算耗時(shí)重疊得不好整體訓(xùn)練效率就直線下降。理想的通信庫要做三件事知道網(wǎng)絡(luò)拓?fù)?、選擇最短路徑、把通信藏在計(jì)算背后。聽起來簡單實(shí)現(xiàn)起來每一個(gè)都是一場硬仗。3. 這套開源方案的核心設(shè)計(jì)拆解3.1 統(tǒng)一接口讓上層應(yīng)用不感知硬件差異從公開的架構(gòu)和信息來看這套開源基建在設(shè)計(jì)上有一個(gè)明顯特點(diǎn)對外暴露的是一層相對穩(wěn)定的抽象接口真正的硬件相關(guān)實(shí)現(xiàn)放在后端。上層模型框架只需要跟穩(wěn)定的接口打交道不需要關(guān)心當(dāng)前機(jī)器上到底是哪種加速卡。這種分層思路和操作系統(tǒng)很像。你寫一個(gè) read() 函數(shù)不需要管底層是機(jī)械硬盤還是固態(tài)硬盤操作系統(tǒng)幫你屏蔽了差異。這套開源地基做的就是 AI 領(lǐng)域類似的事情提供一套標(biāo)準(zhǔn)的算子、通信、數(shù)據(jù)讀寫接口把千差萬別的硬件差異擋在下面。選擇在什么抽象層級上做標(biāo)準(zhǔn)化是個(gè)非常關(guān)鍵的設(shè)計(jì)決策。層定得太底層每個(gè)硬件后端還是得各自維護(hù)一大套代碼失去了公共底座的意義層定得太上層很多性能細(xì)節(jié)被藏住又跑不出性能。從實(shí)際效果看它選擇了一個(gè)比較務(wù)實(shí)的中間點(diǎn)核心熱點(diǎn)算子做多版本實(shí)現(xiàn)通用算子走自動生成接口層保持穩(wěn)定。3.2 算子特化與自動生成兩條腿走路底層計(jì)算內(nèi)核的開發(fā)業(yè)內(nèi)通常有兩條路線手工調(diào)優(yōu)和自動生成。手工調(diào)優(yōu)可以達(dá)到極致性能但開發(fā)周期極長一個(gè)團(tuán)隊(duì)一年能做好十幾個(gè)算子就非常了不起了。自動生成可以覆蓋更多場景但生成的代碼質(zhì)量參差不齊容易在邊緣形狀上翻車。從公開信息看這套開源的路線是兩者結(jié)合針對模型里調(diào)用最頻繁、性能影響最大的算子比如解碼階段的核心注意力內(nèi)核投入大量人力做手工特化對于其他數(shù)量眾多但調(diào)用頻率較低的算子通過自動生成加上編譯優(yōu)化來兜底。這種“二八原則”的投入策略非常值得學(xué)習(xí)。我見過很多團(tuán)隊(duì)試圖把所有算子都手工優(yōu)化一遍結(jié)果人力不夠、維護(hù)困難最后草草收場。也有人完全依賴自動生成熱點(diǎn)算子性能上不去模型整體速度平平。先識別熱點(diǎn)把人力花在刀刃上其余交給自動化這是工業(yè)級工程和拍腦袋優(yōu)化的本質(zhì)區(qū)別。3.3 通信調(diào)度把“等”變成“算”多卡訓(xùn)練和推理性能差核心原因往往是“大量時(shí)間在等待”。等待通信完成、等待數(shù)據(jù)從磁盤讀進(jìn)來、等待另一張卡算完。這套開源軟件棧里通信層面做了大量“計(jì)算與通信重疊”的調(diào)度設(shè)計(jì)。舉個(gè)直觀的例子在模型某一層做前向計(jì)算的時(shí)候下一層需要用到的權(quán)重本來還在傳輸路上。聰明的調(diào)度器會提前發(fā)起權(quán)重預(yù)取請求讓通信和計(jì)算同時(shí)進(jìn)行。等當(dāng)前這一層算完權(quán)重恰好也到了計(jì)算流水線一刻不停。這個(gè)技術(shù)叫 pipeline 預(yù)取實(shí)現(xiàn)得好的通信庫能把多機(jī)擴(kuò)展效率從 40% 拉到 90% 以上。文件系統(tǒng)層面的思路也類似。分布式文件系統(tǒng)支持 RDMA 直讀數(shù)據(jù)多個(gè)節(jié)點(diǎn)可以同時(shí)從數(shù)據(jù)集群拉取樣本而不是所有請求都擠在一個(gè)存儲節(jié)點(diǎn)上。數(shù)據(jù)處理框架還會把樣本切成小塊、提前打散并緩存到本地最大限度避免 GPU 空轉(zhuǎn)。這些手段單獨(dú)看都不算玄學(xué)難的是把它們組合成一套完整的系統(tǒng)并且經(jīng)得起上千卡規(guī)模集群的考驗(yàn)。開源的意義在于別人花幾年時(shí)間踩坑積累出來的調(diào)度經(jīng)驗(yàn)現(xiàn)在你可以直接拿過來用。4. 在自己的機(jī)器上跑一遍完整流程4.1 環(huán)境準(zhǔn)備與依賴清單我自己實(shí)際跑這套流程用的是一臺 8 卡 Linux 服務(wù)器系統(tǒng)是通用的 Ubuntu 版本驅(qū)動已經(jīng)裝好。如果你手頭只有單加速卡也能體驗(yàn)大部分功能只是通信層面的效果看不完整。準(zhǔn)備工作大致分四塊操作系統(tǒng)與驅(qū)動確認(rèn)驅(qū)動版本符合要求用加速卡自帶的監(jiān)控命令能看到設(shè)備列表和顯存信息。容器環(huán)境強(qiáng)烈建議用容器隔離環(huán)境避免污染系統(tǒng)自帶的 Python 和庫容器在團(tuán)隊(duì)協(xié)作時(shí)也能保證版本一致。編譯工具鏈很多底層組件需要從源碼編譯準(zhǔn)備好全套編譯工具包括編譯器、構(gòu)建工具和依賴的數(shù)學(xué)庫。Python 環(huán)境使用虛擬環(huán)境或容器內(nèi)的 Python 3.10安裝常用依賴庫。有一個(gè)很容易被忽略的點(diǎn)不同組件對軟件版本有強(qiáng)依賴建議記錄下驅(qū)動版本、系統(tǒng)內(nèi)核版本、編譯器等關(guān)鍵信息。很多失敗案例的根源都是版本不匹配提前鎖定可以省掉大量排查時(shí)間。4.2 最小推理示例的完整操作下面以一個(gè)最小推理任務(wù)為例演示從拉取代碼到跑通模型的整個(gè)過程。這里用的是演示性質(zhì)的代碼實(shí)際 API 請以你拉下來的倉庫文檔為準(zhǔn)。第一步拉取代碼git clone https://example.com/your-repo.git cd your-repo第二步創(chuàng)建并激活虛擬環(huán)境python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt第三步編譯 C 擴(kuò)展如果倉庫包含需要編譯的原生代碼python setup.py build_ext --inplace編譯時(shí)間取決于機(jī)器性能一般在幾分鐘到十幾分鐘。如果遇到編譯失敗先檢查編譯器和依賴庫版本后面的踩坑章節(jié)會展開說。第四步寫一個(gè)極簡推理腳本加載模型并測量輸出速度import time from transformers import AutoTokenizer, AutoModelForCausalLM model_name your-model-path tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) prompt 寫一段關(guān)于深度學(xué)習(xí)訓(xùn)練優(yōu)化的文字 inputs tokenizer(prompt, return_tensorspt) start time.time() outputs model.generate(**inputs, max_new_tokens128) elapsed time.time() - start generated tokenizer.decode(outputs[0], skip_special_tokensTrue) new_tokens outputs.shape[1] - inputs.input_ids.shape[1] print(f生成 {new_tokens} 個(gè) token耗時(shí) {elapsed:.2f}s速度 {new_tokens/elapsed:.2f} tokens/s)第五步把輸入長度、生成長度固定多測幾輪取平均值記作基線。第六步檢查是否有調(diào)用到高性能內(nèi)核。有的推理框架會輸出算子選擇日志有的需要用性能監(jiān)控工具觀察內(nèi)核運(yùn)行時(shí)長。如果沒有用上你預(yù)期的高性能內(nèi)核請檢查調(diào)用的后端參數(shù)是否正確。這套流程跑通之后你手上就有了一個(gè)基準(zhǔn)線后續(xù)做任何優(yōu)化都有數(shù)據(jù)可以對比。4.3 性能驗(yàn)證先量化再調(diào)優(yōu)性能優(yōu)化最怕“感覺快了”或者“感覺慢了”一切要以數(shù)據(jù)為準(zhǔn)。我建議至少記錄以下四類指標(biāo)端到端延遲從輸入到完整輸出的總耗時(shí)。首 Token 延遲發(fā)送請求到收到第一個(gè) Token 的時(shí)間流式輸出的體驗(yàn)主要看這個(gè)指標(biāo)。吞吐量單位時(shí)間能生成的 Token 總數(shù)吞吐在高并發(fā)場景下比單請求延遲更重要。資源利用率顯存占用、負(fù)載、內(nèi)存交換量。我自己的習(xí)慣是先跑單請求測延遲然后逐步增加并發(fā)請求數(shù)觀察吞吐量變化。如果并發(fā)升高后吞吐量上不去可能是顯存帶寬成了瓶頸也可能是調(diào)度開銷過大如果顯存占用率居高不下則需要檢查 KV Cache 的配置。5. 實(shí)戰(zhàn)踩坑記錄與排查速查表5.1 三個(gè)最具代表性的失敗現(xiàn)場踩坑一驅(qū)動與組件版本不匹配直接報(bào)錯(cuò)。有一次我在新機(jī)器上拉好代碼直接編譯結(jié)果跑推理時(shí)報(bào)錯(cuò)提示找不到某個(gè)計(jì)算庫。查了半天發(fā)現(xiàn)是驅(qū)動版本太老而組件要求在較新的驅(qū)動之上才能使用特定的算子。解決方案很簡單升級驅(qū)動到要求版本問題消失但排查過程花了兩個(gè)小時(shí)。踩坑二顯存明明夠用卻報(bào)了 OOM。這類問題最迷惑人。模型加載完還剩不少顯存一旦生成長文本就崩。后來發(fā)現(xiàn)是 KV Cache 在長序列下急劇膨脹加上顯存碎片導(dǎo)致大塊連續(xù)內(nèi)存分配失敗。解決方法是調(diào)小生成長度限制、優(yōu)化 KV Cache 的內(nèi)存分配方式或者開啟更激進(jìn)的內(nèi)存復(fù)用策略。踩坑三多卡通信超時(shí)。第一次跑多卡并行時(shí)日志里頻繁出現(xiàn)通信超時(shí)錯(cuò)誤。檢查網(wǎng)絡(luò)發(fā)現(xiàn)機(jī)間走的是普通交換機(jī)沒有開啟相關(guān)硬件卸載包處理延遲過高。把網(wǎng)絡(luò)調(diào)成更適配高性能計(jì)算的配置后通信超時(shí)基本消失。這個(gè)問題的教訓(xùn)是多卡性能不只是卡的問題網(wǎng)絡(luò)拓?fù)浜驮O(shè)備固件一樣關(guān)鍵。5.2 一個(gè)問題排查的通用思路遇到底層組件問題我的排查順序幾乎固定看日志錯(cuò)誤信息本身能篩掉一半問題先找第一個(gè)報(bào)錯(cuò)而不是最后一屏。查版本列出所有關(guān)鍵組件的版本號對照官方文檔確認(rèn)兼容性。拆分問題用最小復(fù)現(xiàn)腳本單獨(dú)測某個(gè)功能確認(rèn)是算子、通信還是數(shù)據(jù)層的問題。搜關(guān)鍵詞把完整報(bào)錯(cuò)信息復(fù)制到搜索引擎對比別人遇到的類似情況。二分定位如果問題出在數(shù)據(jù)加載就逐步縮小數(shù)據(jù)集看是數(shù)量還是特定樣本觸發(fā)。工具鏈方面Linux 自帶的性能工具已經(jīng)夠用。用一些命令看內(nèi)存和負(fù)載GPU 監(jiān)控用硬件自帶的命令或者性能剖析工具網(wǎng)絡(luò)層面可以用 iperf 測一下節(jié)點(diǎn)間帶寬。5.3 獨(dú)家避坑經(jīng)驗(yàn)四條經(jīng)驗(yàn)一先用最小的模型把整條流水線跑通再上大規(guī)模任務(wù)。我看到太多人一上來就加載幾百億參數(shù)的模型結(jié)果環(huán)境和配置問題還沒解決錯(cuò)誤信息都分不清是模型本身的問題還是環(huán)境問題。小模型跑通一次你至少確認(rèn)了“安裝、編譯、加載、推理”這條鏈路是通的。經(jīng)驗(yàn)二每次改動前后都記錄環(huán)境信息。養(yǎng)成習(xí)慣把驅(qū)動版本、依賴包版本、環(huán)境變量寫進(jìn)一個(gè)文件。等到需要回滾或者排查時(shí)這份記錄能救命。經(jīng)驗(yàn)三不要迷信默認(rèn)參數(shù)。很多指標(biāo)默認(rèn)參數(shù)保證的是“通用”不是“最優(yōu)”。有必要試一下實(shí)際工作負(fù)載下的表現(xiàn)別只跑基準(zhǔn)測試。經(jīng)驗(yàn)四底層代碼問題優(yōu)先查編譯器與依賴版本別急著懷疑代碼邏輯。大多數(shù)“莫名其妙”的報(bào)錯(cuò)都是版本不匹配導(dǎo)致的代碼本身跑在正確環(huán)境里是沒問題的。6. 寫在最后的個(gè)人觀察6.1 開源正在從“給模型”走向“給生態(tài)”過去一年開源社區(qū)的主角是模型權(quán)重。每隔幾周就有一個(gè)刷榜的新模型出現(xiàn)大家下載、微調(diào)、部署、分享效果。這種繁榮當(dāng)然有價(jià)值但它的天花板也很明顯模型再好底層軟件不給力最終體驗(yàn)還是會打折扣。DeepSeek 這波開源底層基礎(chǔ)設(shè)施更像是一種生態(tài)層面的布局。給開源社區(qū)的不是一條魚而是一張網(wǎng)、一根漁竿、一套處理魚的流水線。硬件廠商的姿態(tài)也在變化。過去每家都希望開發(fā)者用自己的專用軟件?，F(xiàn)在越來越多人意識到與其各自維護(hù)一套孤島不如合力維護(hù)一套開放底座在上層競爭模型體驗(yàn)和工具鏈。這對整個(gè)行業(yè)的意義可能比某一個(gè)模型的開源更深遠(yuǎn)。6.2 普通開發(fā)者和研究者可以怎么參與不需要頂級算力也不需要是大廠工程師普通開發(fā)者完全可以參與這類開源基建直接使用在自己的機(jī)器上部署這套軟件棧跑通一個(gè)完整任務(wù)提交使用反饋。閱讀源碼從算子實(shí)現(xiàn)開始讀對比通用實(shí)現(xiàn)和高性能實(shí)現(xiàn)之間的差異這是學(xué)習(xí)并行計(jì)算最實(shí)際的路徑。提 Issue 和補(bǔ)丁遇到文檔沒寫清楚的或者 bug幫助社區(qū)改進(jìn)這也是貢獻(xiàn)。集成到自己的項(xiàng)目如果你是做推理服務(wù)或者訓(xùn)練平臺開發(fā)的把這套地基變成你產(chǎn)品的一部分能節(jié)省大量時(shí)間。我在實(shí)際把這些組件跑起來的過程中最大的感受不是“又多了一個(gè)能用的庫”而是開源圈終于有人在認(rèn)真鋪路。以前從硬件、模型到應(yīng)用之間那些“最后一公里”問題每個(gè)團(tuán)隊(duì)都要各自啃一遍既浪費(fèi)時(shí)間又容易踩坑現(xiàn)在終于有一條值得眾人共同維護(hù)的公共道路。如果你也對性能優(yōu)化和異構(gòu)計(jì)算感興趣不妨從第一個(gè)樣例開始把代碼拉下來跑通它然后看看底座內(nèi)部到底是什么樣的。親自動手之后就好理解“地基”兩個(gè)字的分量了。