模型在本地調(diào)得再漂亮上了線(xiàn)才發(fā)現(xiàn)GPU利用率不到30%接口P99延遲飄到幾百毫秒算法同學(xué)說(shuō)“我代碼沒(méi)問(wèn)題”infra同學(xué)說(shuō)“我資源也沒(méi)問(wèn)題”兩邊對(duì)著一個(gè)黑盒互相甩鍋——這種場(chǎng)面我在不止一個(gè)團(tuán)隊(duì)里見(jiàn)過(guò)。算法和infra的協(xié)同聽(tīng)起來(lái)是個(gè)工程管理話(huà)題實(shí)際操作起來(lái)全是技術(shù)細(xì)節(jié)推理框架怎么選、batch size怎么定、數(shù)據(jù)管道怎么設(shè)計(jì)、profile的結(jié)果怎么解讀。這篇東西不聊虛的把我自己在一線(xiàn)做“算法-infra協(xié)同”的踩坑經(jīng)驗(yàn)、設(shè)計(jì)思路和排查方法整成一份可復(fù)用的參考給正在被模型部署和性能調(diào)優(yōu)折磨的算法工程師、以及被各種“優(yōu)化需求”打擾的infra工程師都做個(gè)參照。我前幾年主導(dǎo)過(guò)一個(gè)推薦模型的推理服務(wù)優(yōu)化項(xiàng)目從最開(kāi)始的兩邊互相看不懂到后面沉淀出一套配合模式中間的過(guò)程很能說(shuō)明問(wèn)題。下面按我自己的實(shí)踐路徑把整個(gè)協(xié)同過(guò)程拆開(kāi)講。1. 為什么“算法-infra協(xié)同”成了必須面對(duì)的問(wèn)題1.1 算法模型跑通只是第一步上線(xiàn)才是真正的門(mén)檻很多算法團(tuán)隊(duì)習(xí)慣的交付狀態(tài)是模型在離線(xiàn)評(píng)測(cè)集上指標(biāo)達(dá)標(biāo)然后在Jupyter Notebook里跑通一個(gè)推理demo就認(rèn)為“算法已經(jīng)完成”。但實(shí)際情況是從Notebook到生產(chǎn)服務(wù)之間有一道巨大的鴻溝這道鴻溝幾乎全是infra的領(lǐng)域。拿我自己踩過(guò)的坑來(lái)說(shuō)。有一次我們訓(xùn)練好的CTR模型離線(xiàn)AUC比舊模型高了三個(gè)千分點(diǎn)算法同學(xué)很開(kāi)心覺(jué)得這個(gè)版本穩(wěn)了。但一到線(xiàn)上壓測(cè)就傻眼了單機(jī)QPS只有預(yù)期的四分之一P99延遲超過(guò)500毫秒線(xiàn)上流量稍微一抖服務(wù)直接超時(shí)雪崩。那時(shí)候算法和infra互相都覺(jué)得是對(duì)方的問(wèn)題。算法覺(jué)得“模型邏輯就這么簡(jiǎn)單無(wú)非就是個(gè)矩陣乘法加激活函數(shù)怎么可能這么慢”infra覺(jué)得“機(jī)器配置給夠了是你模型代碼寫(xiě)得爛”。后來(lái)profile一查問(wèn)題根本不在模型計(jì)算本身特征拼接時(shí)反復(fù)做內(nèi)存拷貝、Python側(cè)循環(huán)處理請(qǐng)求、每個(gè)請(qǐng)求都重新加載一次詞表這些代碼層面的問(wèn)題全被忽略了。模型本身可能只占整個(gè)推理鏈路的20%時(shí)間剩下80%都被數(shù)據(jù)處理、框架調(diào)度、IO等待吃掉了。這件事給我的教訓(xùn)是算法模型的“正確性”和系統(tǒng)的“可用性”是兩回事。算法同學(xué)的交付物不應(yīng)該只是模型權(quán)重還應(yīng)該包含對(duì)推理鏈路的整體理解以及和infra一起把系統(tǒng)調(diào)優(yōu)到可用的狀態(tài)的意愿。1.2 協(xié)同斷點(diǎn)到底卡在哪里要說(shuō)算法和infra的協(xié)同難難就難在兩邊的心智模型不一樣。我觀察下來(lái)斷點(diǎn)主要集中在這幾個(gè)地方。第一個(gè)斷點(diǎn)是語(yǔ)言不通。算法同學(xué)張口閉口是“AUC”、“l(fā)oss收斂”、“Embedding維度”infra同學(xué)關(guān)心的是“QPS”、“P99時(shí)延”、“CPU水位”、“內(nèi)存占用”。兩邊都在說(shuō)性能但說(shuō)的根本不是一回事。算法眼里的“性能”是模型效果指標(biāo)infra眼里的“性能”是系統(tǒng)資源指標(biāo)中間缺一個(gè)翻譯層。第二個(gè)斷點(diǎn)是交付物邊界不清。算法覺(jué)得“我把模型文件發(fā)給你就行了”infra覺(jué)得“你給我的模型我跑不起來(lái)”。模型用什么框架導(dǎo)出、有沒(méi)有帶預(yù)處理邏輯、依賴(lài)的Python包版本、詞表文件在哪、特征維度是多少這些信息如果不掉清楚infra同學(xué)就得靠猜。猜的代價(jià)就是反復(fù)試錯(cuò)時(shí)間全耗在溝通上。第三個(gè)斷點(diǎn)是資源評(píng)估全靠拍腦袋。算法說(shuō)“給我4張A100”問(wèn)他要4張卡的理由他說(shuō)“可能不夠多要點(diǎn)保險(xiǎn)”。infra那邊資源池本來(lái)就不寬裕一看這種申請(qǐng)直接打回。其實(shí)完全可以做精細(xì)化評(píng)估跑一下profile看顯存峰值和計(jì)算密度再用公式估算一下吞吐需求有理有據(jù)地填申請(qǐng)單。第四個(gè)斷點(diǎn)是性能問(wèn)題定位的方式不對(duì)。我見(jiàn)過(guò)有團(tuán)隊(duì)遇到線(xiàn)上延遲高第一反應(yīng)是“加機(jī)器”結(jié)果加了兩倍的機(jī)器延遲一點(diǎn)沒(méi)降因?yàn)槠款i在CPU上的數(shù)據(jù)預(yù)處理不在GPU推理。按加機(jī)器來(lái)擴(kuò)容完全擴(kuò)錯(cuò)了方向。這些斷點(diǎn)單獨(dú)看都是小事但疊在一起就會(huì)形成巨大的協(xié)作成本。我后來(lái)總結(jié)了一個(gè)觀點(diǎn)算法和infra的協(xié)同本質(zhì)上是要找到一種方式把彼此的領(lǐng)域知識(shí)翻譯成對(duì)方能理解的語(yǔ)言比如用可量化的指標(biāo)、標(biāo)準(zhǔn)的交付格式、清晰的流程節(jié)點(diǎn)把這些知識(shí)編碼下來(lái)。2. 我在協(xié)同項(xiàng)目里的整體設(shè)計(jì)思路2.1 從“交付模型”轉(zhuǎn)向“交付服務(wù)”這個(gè)轉(zhuǎn)變是我做協(xié)同優(yōu)化時(shí)第一個(gè)確立的原則。如果算法團(tuán)隊(duì)的交付物只是模型文件那infra團(tuán)隊(duì)的職責(zé)就成了“把模型跑起來(lái)”至于跑得好不好、快不快全是infra的事算法自然就不關(guān)心推理性能。這樣分工從根上就有問(wèn)題因?yàn)橥评硇阅艿暮艽笠徊糠秩Q于模型結(jié)構(gòu)、算子實(shí)現(xiàn)和特征處理方式這些都在算法團(tuán)隊(duì)的控制范圍內(nèi)。正確的做法是把交付邊界往后推算法團(tuán)隊(duì)交付的不只是模型文件還包括一套推理服務(wù)的可運(yùn)行版本。這套版本要有明確的性能指標(biāo)要求比如目標(biāo)QPS、目標(biāo)延遲、吞吐上限并且要附帶模型對(duì)資源需求的估算說(shuō)明比如建議的batch size范圍、顯存占用預(yù)估、CPU內(nèi)存需求。infra團(tuán)隊(duì)基于這套交付物做容量規(guī)劃和部署調(diào)優(yōu)雙方的責(zé)任邊界從“模型文件”移動(dòng)到了“性能指標(biāo)”。你說(shuō)這不是算法團(tuán)隊(duì)得多干不少活嗎確實(shí)多了但這種“多”是必要的。因?yàn)橹挥袑?xiě)模型的團(tuán)隊(duì)才最清楚模型的計(jì)算圖、內(nèi)存占用和算子特性這些信息轉(zhuǎn)述給infra要么失真要么說(shuō)不全。把性能要求寫(xiě)進(jìn)交付規(guī)范雙方對(duì)話(huà)就有了共同基準(zhǔn)。2.2 接口規(guī)范化讓算法和infra解耦的關(guān)鍵第二個(gè)原則是接口規(guī)范化。我之前出現(xiàn)過(guò)不少讓人崩潰的協(xié)作問(wèn)題算法同學(xué)說(shuō)“這個(gè)實(shí)現(xiàn)依賴(lài)Python 3.8的一個(gè)特性”infra同學(xué)部署的生產(chǎn)環(huán)境是Python 3.7直接跑不起來(lái)或者模型輸入的特征順序算法和工程端理解的不一樣上線(xiàn)之后預(yù)測(cè)結(jié)果全亂了。后來(lái)我們做了一個(gè)標(biāo)準(zhǔn)化的模型服務(wù)接口規(guī)范把模型推理的輸入輸出格式固定下來(lái)特征按有序字典傳入模型版本用語(yǔ)義化版本號(hào)管理配置信息如batch size、并發(fā)數(shù)、超時(shí)時(shí)間全部外置到配置文件里。這樣算法迭代模型時(shí)不需要改動(dòng)服務(wù)框架infra升級(jí)基礎(chǔ)設(shè)施時(shí)也不需要跟算法確認(rèn)每個(gè)細(xì)節(jié)。模型文件、特征配置、服務(wù)框架、資源規(guī)格四層各管各的通過(guò)標(biāo)準(zhǔn)化接口銜接。這個(gè)設(shè)計(jì)很像軟件工程里的依賴(lài)倒置原則高層的算法邏輯不要依賴(lài)底層的具體基礎(chǔ)設(shè)施底層基礎(chǔ)設(shè)施也不要反哺高層的模型代碼兩邊只依賴(lài)抽象接口。實(shí)踐下來(lái)這個(gè)解耦帶來(lái)的好處是兩邊可以并行推進(jìn)不再互相阻塞。2.3 用性能基線(xiàn)和透明數(shù)據(jù)建立信任第三個(gè)原則是用數(shù)據(jù)說(shuō)話(huà)建立性能基線(xiàn)。在協(xié)同項(xiàng)目里最怕的不是性能差而是性能數(shù)據(jù)不透明。算法說(shuō)“我這個(gè)模型很快”沒(méi)有任何數(shù)據(jù)支撐infra說(shuō)“服務(wù)器有瓶頸”也說(shuō)不清瓶頸在哪。最后只能靠嗓門(mén)大。我們的做法是建立一套標(biāo)準(zhǔn)的性能評(píng)測(cè)流程每次模型迭代上線(xiàn)前都要在固定的評(píng)測(cè)環(huán)境下跑一次壓測(cè)記錄吞吐量、P99時(shí)延、GPU利用率、顯存占用、CPU開(kāi)銷(xiāo)等核心指標(biāo)把這些指標(biāo)記錄到一份自動(dòng)生成的評(píng)測(cè)報(bào)告里和上一版本做對(duì)比。誰(shuí)快誰(shuí)慢、快在哪慢在哪一目了然不再有“我覺(jué)得”“我感覺(jué)”的空間。這套評(píng)測(cè)流程跑起來(lái)之后我明顯感覺(jué)到兩邊溝通順暢多了。infra說(shuō)“你的服務(wù)GPU利用率低”直接拿出監(jiān)控截圖和nvidia-smi數(shù)據(jù)算法說(shuō)“這個(gè)算子慢”直接拿出profiling報(bào)告指出熱點(diǎn)。數(shù)據(jù)代替了猜測(cè)協(xié)作自然就高效了。3. 推理服務(wù)協(xié)同優(yōu)化的實(shí)操全過(guò)程3.1 環(huán)境準(zhǔn)備階段選對(duì)工具鏈后面能省一半的麻煩這個(gè)項(xiàng)目的目標(biāo)是讓一個(gè)推薦模型的在線(xiàn)推理服務(wù)達(dá)到線(xiàn)上要求支撐2000 QPS的流量P99延遲不超過(guò)100毫秒。模型用的是DeepFM架構(gòu)特征規(guī)模大約5000萬(wàn)維稀疏特征加200維稠密特征服務(wù)于用戶(hù)點(diǎn)擊率預(yù)估場(chǎng)景。環(huán)境選型上我們做了一輪比較。模型原本是用PyTorch訓(xùn)練的原計(jì)劃直接用PyTorch做推理服務(wù)但壓測(cè)發(fā)現(xiàn)Python側(cè)的開(kāi)銷(xiāo)太高GIL讓多線(xiàn)程并發(fā)受限后來(lái)?yè)Q成了ONNX Runtime加TensorRT的后端方案。ONNX Runtime負(fù)責(zé)從PyTorch導(dǎo)出的模型做轉(zhuǎn)換和執(zhí)行TensorRT在NVIDIA GPU上做算子融合和精度校準(zhǔn)。實(shí)測(cè)下來(lái)單卡的推理吞吐比純PyTorch提升了接近3倍P99時(shí)延也降了一個(gè)數(shù)量級(jí)。工具鏈方面profile用的是PyTorch自帶的torch.profiler配合NVIDIA的Nsight Systems資源監(jiān)控用的Prometheus加Grafana部署走的是Docker加Kubernetes。這套組合的好處是覆蓋了從模型算子級(jí)別到系統(tǒng)資源級(jí)別的全鏈路觀測(cè)兩邊拿到的數(shù)據(jù)是同一套不會(huì)再出現(xiàn)“我這邊看到CPU滿(mǎn)了你那邊說(shuō)進(jìn)程很閑”這種數(shù)據(jù)對(duì)不上的情況。3.2 從單卡推理到服務(wù)化部署這一步隱藏了最多的坑模型導(dǎo)出之后第一版直接拿ONNX Runtime的Python接口做了個(gè)Wrap然后用Flask啟動(dòng)了一個(gè)HTTP服務(wù)。簡(jiǎn)單測(cè)了一下能跑通但很快就暴露了問(wèn)題Python接口的調(diào)用開(kāi)銷(xiāo)很大每次請(qǐng)求進(jìn)來(lái)都要做Python和C之間的數(shù)據(jù)交換而且不支持真正的多進(jìn)程并行推理CPU并發(fā)利用不起來(lái)。后來(lái)改成了ONNX Runtime的C部署方案配合TensorRT的engine來(lái)做推理。這一步改動(dòng)帶來(lái)的性能提升非常直接因?yàn)槭〉袅薖ython解釋器這層開(kāi)銷(xiāo)每次推理調(diào)用的延遲直接砍掉了三分之一。同時(shí)我們用內(nèi)存映射的方式預(yù)加載了模型的Embedding參數(shù)避免了每個(gè)請(qǐng)求都從磁盤(pán)讀取參數(shù)導(dǎo)致的IO抖動(dòng)。服務(wù)端的并發(fā)模型也做了一輪重構(gòu)。最初是每個(gè)請(qǐng)求一個(gè)小線(xiàn)程線(xiàn)程切換開(kāi)銷(xiāo)大后來(lái)改成了線(xiàn)程池加有界隊(duì)列的模式根據(jù)目標(biāo)QPS動(dòng)態(tài)調(diào)整worker數(shù)量配合OMP_NUM_THREADS環(huán)境變量控制底層并行度。這么改完單實(shí)例的QPS從原來(lái)的不到400提升到了接近1500CPU和GPU的使用率也均衡了很多。這里有個(gè)數(shù)據(jù)值得記錄一下同樣的模型和機(jī)器純Python部署的P99時(shí)延是180ms換成C后端之后降到了58ms再配合TensorRT的FP16精度優(yōu)化進(jìn)一步降到了35ms。這三步優(yōu)化每一步單獨(dú)拿出來(lái)看都不算大工程但疊加起來(lái)就是數(shù)量級(jí)的差別。3.3 壓測(cè)過(guò)程和瓶頸分析把一切問(wèn)題擺到明面上壓測(cè)工具用的是wrk加自研的流量回放腳本。wrk負(fù)責(zé)模擬高并發(fā)HTTP請(qǐng)求流量回放腳本則從線(xiàn)上Nginx日志抽取真實(shí)請(qǐng)求樣本按時(shí)間戳順序重放到測(cè)試服務(wù)上盡量還原線(xiàn)上請(qǐng)求的特征包括請(qǐng)求大小分布、特征稀疏度、以及峰值時(shí)刻的流量形態(tài)。壓測(cè)分為三輪。第一輪是小流量驗(yàn)證用100 QPS跑10分鐘確認(rèn)功能正確、內(nèi)存沒(méi)有泄漏、日志沒(méi)有報(bào)錯(cuò)。第二輪是加壓測(cè)試從500 QPS起步每2分鐘增加250 QPS觀察各項(xiàng)指標(biāo)的變化趨勢(shì)找到服務(wù)崩潰的臨界點(diǎn)。第三輪是持續(xù)穩(wěn)定性測(cè)試用目標(biāo)負(fù)載的80%1600 QPS連續(xù)跑8小時(shí)確認(rèn)長(zhǎng)時(shí)間運(yùn)行下沒(méi)有內(nèi)存膨脹、句柄泄漏等問(wèn)題。瓶頸分析階段我們抓到了好幾個(gè)經(jīng)典問(wèn)題。第一個(gè)是第一個(gè)版本在1000 QPS左右時(shí)P99延遲突然從60ms跳升到400ms查下來(lái)發(fā)現(xiàn)是Python側(cè)的特征預(yù)處理線(xiàn)程變成了瓶頸CPU打滿(mǎn)GPU反而在空轉(zhuǎn)。解決辦法是預(yù)處理部分全部向C側(cè)下沉用ONNX Runtime的custom operator實(shí)現(xiàn)特征拼接把CPU和GPU的工作重新配平。第二個(gè)是壓測(cè)跑到中段出現(xiàn)周期性延遲尖峰后來(lái)發(fā)現(xiàn)是日志寫(xiě)的太頻繁磁盤(pán)IO被打滿(mǎn)改成異步日志之后尖峰消失。第三個(gè)是Embedding查表在GPU上表現(xiàn)為顯存訪(fǎng)問(wèn)不連續(xù)用class-wise的存儲(chǔ)布局優(yōu)化之后這塊耗時(shí)又降了一些。這些瓶頸沒(méi)有一個(gè)能被直覺(jué)直接發(fā)現(xiàn)全靠profile數(shù)據(jù)才能定位。所以我強(qiáng)烈建議優(yōu)化性能的時(shí)候一定要先把“當(dāng)前時(shí)間花在哪兒”搞清楚再談怎么優(yōu)化千萬(wàn)不要憑感覺(jué)。4. 協(xié)同過(guò)程中必踩的坑與解決方案實(shí)錄4.1 “GPU利用率上不去”到底是誰(shuí)的鍋這是我在協(xié)同項(xiàng)目里被問(wèn)過(guò)最多的問(wèn)題也是算法和infra最容易吵架的導(dǎo)火索。很多團(tuán)隊(duì)拿“GPU利用率”作為模型服務(wù)效率的核心指標(biāo)但GPU利用率低的原因遠(yuǎn)比想象的復(fù)雜不一定是模型的錯(cuò)。我見(jiàn)過(guò)的GPU利用率低的典型原因有這么幾類(lèi)數(shù)據(jù)加載和預(yù)處理太慢GPU在等數(shù)據(jù)利用率自然上不去batch size設(shè)得太小GPU的并行能力沒(méi)有充分釋放CPU側(cè)的Python邏輯占了太多時(shí)間GPU一直在空轉(zhuǎn)模型本身有串行依賴(lài)計(jì)算圖并行度不夠。每一類(lèi)對(duì)應(yīng)的解法完全不同。定位方法說(shuō)起來(lái)很簡(jiǎn)單打開(kāi)Nsight Systems或者nvidia-smi的監(jiān)控看GPU到底是“計(jì)算密集”還是“空閑等待”。如果是等待就去看CPU側(cè)在忙什么如果是計(jì)算密集但利用率依舊低那就去看模型的計(jì)算圖是不是存在大量的串行節(jié)點(diǎn)。有一次我們排查一個(gè)BERT的服務(wù)發(fā)現(xiàn)GPU利用率一直只有20%多profile一看問(wèn)題在CPU側(cè)的分詞器上——每次請(qǐng)求都要重新做一次分詞一個(gè)毫秒級(jí)的操作在并發(fā)量大的時(shí)候被放大成了巨大的等待。改成預(yù)分詞加緩存之后GPU利用率直接翻倍。這類(lèi)問(wèn)題暴露出來(lái)以后我最大的感觸是千萬(wàn)不要把“GPU利用率低”當(dāng)作某個(gè)人的責(zé)任問(wèn)題它更接近一個(gè)系統(tǒng)問(wèn)題。GPU利用率是結(jié)果指標(biāo)不是原因指標(biāo)單純盯著它沒(méi)什么用還是要一級(jí)一級(jí)往下拆。4.2 模型精度復(fù)現(xiàn)不了的隱形元兇模型從PyTorch導(dǎo)出到ONNX再到TensorRT之后經(jīng)常有算法同學(xué)跑回來(lái)反饋“線(xiàn)上預(yù)測(cè)結(jié)果和離線(xiàn)對(duì)不上?！币婚_(kāi)始我們以為是模型導(dǎo)出過(guò)程出了錯(cuò)后來(lái)才發(fā)現(xiàn)最隱蔽的問(wèn)題來(lái)自“數(shù)值精度”和“算子實(shí)現(xiàn)差異”。PyTorch在GPU訓(xùn)練時(shí)默認(rèn)用FP32推理轉(zhuǎn)成TensorRT的FP16后部分算子比如LayerNorm、Softmax的數(shù)值精度會(huì)有微小差異在大多數(shù)場(chǎng)景下不影響排序但有些邊界樣本的預(yù)測(cè)值會(huì)變化幾個(gè)百分點(diǎn)。算法同學(xué)如果拿著離線(xiàn)全精度的輸出和線(xiàn)上半精度的輸出逐條比對(duì)就會(huì)看到差異。解決的辦法是分類(lèi)處理對(duì)精度有嚴(yán)格要求的任務(wù)比如風(fēng)控、金融場(chǎng)景保持FP32推理用算子融合和優(yōu)化內(nèi)存訪(fǎng)問(wèn)來(lái)提速對(duì)排序、推薦這類(lèi)對(duì)絕對(duì)概率值不敏感、只看相對(duì)順序的任務(wù)可以用FP16甚至INT8配合校準(zhǔn)集把精度損失控制在一個(gè)很小的范圍內(nèi)。還有個(gè)容易被忽略的點(diǎn)是框架版本差異PyTorch 1.x和2.x導(dǎo)出的ONNX算子集不一樣TensorRT版本不同也可能導(dǎo)致同樣的模型在部署時(shí)行為不同。所以必須把“訓(xùn)練框架版本、導(dǎo)出工具版本、推理框架版本”這三項(xiàng)固定下來(lái)做成一個(gè)部署配置的“鐵三角”任何一項(xiàng)升級(jí)都要重新回歸。4.3 資源申請(qǐng)被駁回其實(shí)是可以避免的“申請(qǐng)4張A100被infra駁回了說(shuō)我浪費(fèi)資源怎么辦”這種問(wèn)題我隔三差五就能遇到。實(shí)際情況是不少算法同學(xué)根本不估算自己到底需要多少資源申請(qǐng)的時(shí)候全靠感覺(jué)往大了填。infra那邊資源池是共享的肯定優(yōu)先批給那些能說(shuō)清楚需求的團(tuán)隊(duì)。資源估算其實(shí)沒(méi)那么難。第一步在目標(biāo)機(jī)器上跑一次真實(shí)的訓(xùn)練或推理任務(wù)記錄峰值顯存和平均顯存這就是“單實(shí)例基線(xiàn)”。第二步根據(jù)訓(xùn)練數(shù)據(jù)量和目標(biāo)訓(xùn)練周期估算需要的總算力公式大概是總算力需求FLOPs 單樣本前向計(jì)算量 × 訓(xùn)練樣本數(shù) × epoch數(shù)。第三步結(jié)合單卡算力算出需要的顯卡數(shù)量和訓(xùn)練天數(shù)再留出20%到30%的冗余應(yīng)對(duì)波動(dòng)。拿這個(gè)思路去和infra溝通交流起來(lái)完全不同。你說(shuō)“我需要4張卡跑完需要3天實(shí)測(cè)單卡峰值顯存是38GB考慮數(shù)據(jù)加載波動(dòng)留了10%的buffer需要40GB以上的卡”這種申請(qǐng)沒(méi)有理由被駁回。說(shuō)到底資源申請(qǐng)不只是填個(gè)數(shù)字它本身就是一種工程能力是算法和infra之間建立信任的重要一環(huán)。5. 把協(xié)同能力沉淀成團(tuán)隊(duì)資產(chǎn)5.1 給算法同學(xué)的建議不要把“跑通了”當(dāng)作交付完成我自己也是算法出身太知道“跑通”和“交付”之間的差距了。模型在Notebook里跑通了只是證明你的思路在二三十個(gè)樣本上可行真正讓模型產(chǎn)生價(jià)值的是它能穩(wěn)定地服務(wù)線(xiàn)上流量還能在流量翻倍時(shí)不崩在資源減半時(shí)依然可控。這些要求都不是算法同學(xué)的“分內(nèi)事”但如果完全不關(guān)心你的模型就永遠(yuǎn)活不過(guò)上線(xiàn)那一天。所以至少要做到交付模型時(shí)附帶一份“模型說(shuō)明卡”內(nèi)容包括模型結(jié)構(gòu)、輸入輸出的字段和類(lèi)型、依賴(lài)的框架及版本、詞表在線(xiàn)獲取方式、推薦的batch size范圍、估計(jì)的顯存占用、冷啟動(dòng)時(shí)間、對(duì)CPU和內(nèi)存的依賴(lài)。這份卡片不要求多規(guī)范但至少能讓infra同學(xué)不用靠猜來(lái)部署你的模型。另外學(xué)會(huì)讀profile是算法同學(xué)性?xún)r(jià)比最高的技能投資。一個(gè)模型服務(wù)慢90%的情況下用profile都能找到原因。我見(jiàn)過(guò)太多人拿著性能問(wèn)題去找infra連自己程序的火焰圖都沒(méi)看過(guò)一眼。不要只會(huì)跑訓(xùn)練要學(xué)會(huì)看推理的計(jì)算熱點(diǎn)。掌握這一項(xiàng)技能你在協(xié)同中的話(huà)語(yǔ)權(quán)會(huì)高很多。5.2 給基礎(chǔ)設(shè)施同學(xué)的建議把“不行”變成“怎么才行”infra同學(xué)在這類(lèi)協(xié)同里也有一個(gè)常見(jiàn)的立場(chǎng)問(wèn)題因?yàn)殚L(zhǎng)期被各種不靠譜的資源申請(qǐng)和不規(guī)范的服務(wù)代碼折磨容易變成一個(gè)“什么都說(shuō)不行”的狀態(tài)。這樣短期看是保護(hù)了資源池長(zhǎng)期看會(huì)壓制業(yè)務(wù)的迭代速度最后被業(yè)務(wù)方集體吐槽“基礎(chǔ)設(shè)施跟不上業(yè)務(wù)”。我的建議是infra團(tuán)隊(duì)的重點(diǎn)不應(yīng)該放在審批和拒絕上而是應(yīng)該放在提供“自助能力”上。比如做一個(gè)標(biāo)準(zhǔn)的模型部署平臺(tái)算法同學(xué)上傳模型文件、選定推理框架和后端配置平臺(tái)自動(dòng)生成Docker鏡像、分配測(cè)試環(huán)境、跑一輪標(biāo)準(zhǔn)壓測(cè)、輸出性能報(bào)告?；A(chǔ)設(shè)施把通用的能力沉淀成工具和流程就能把“每個(gè)項(xiàng)目都要人肉介入支持一次”的重復(fù)勞動(dòng)省掉。這需要在思想上做一個(gè)轉(zhuǎn)變infra的kpi不是“管住了多少資源”而是“業(yè)務(wù)能多快地把模型部署上線(xiàn)并且用盡量少的資源跑起來(lái)”。如果基礎(chǔ)設(shè)置的同學(xué)能往這個(gè)方向做算法和infra的摩擦?xí)『芏唷?.3 把復(fù)盤(pán)和知識(shí)沉淀變成日常動(dòng)作項(xiàng)目結(jié)束之后我們做了一次總結(jié)把整個(gè)協(xié)同過(guò)程中的經(jīng)驗(yàn)和工具沉淀成了幾樣?xùn)|西一份模型交付標(biāo)準(zhǔn)文檔、一個(gè)自動(dòng)化壓測(cè)腳本、一套性能基準(zhǔn)數(shù)據(jù)表、一段線(xiàn)上問(wèn)題排查的SOP。這些資產(chǎn)的價(jià)值在后面的幾次迭代里被充分證明了——新模型上線(xiàn)的時(shí)間從一開(kāi)始的三天壓縮到了半天性能問(wèn)題的定位時(shí)間也從按小時(shí)計(jì)縮短到了按分鐘計(jì)。復(fù)盤(pán)形式上我們沒(méi)有搞那種全員參加的PPT大會(huì)就是內(nèi)部拉了一個(gè)文檔把從模型開(kāi)發(fā)到部署調(diào)優(yōu)到線(xiàn)上穩(wěn)定的過(guò)程中所有關(guān)鍵決策、踩坑記錄、數(shù)據(jù)截圖、最終結(jié)論全部寫(xiě)進(jìn)去想到什么記什么。每周項(xiàng)目例會(huì)上花15分鐘過(guò)一遍。三個(gè)月后回頭翻這份文檔里面很多記錄在當(dāng)下看來(lái)已經(jīng)成了團(tuán)隊(duì)共識(shí)但如果沒(méi)有當(dāng)時(shí)的記錄這些共識(shí)根本建立不起來(lái)。還有一點(diǎn)很關(guān)鍵知識(shí)沉淀要落到代碼和腳本里不能只活在文檔里。比如“壓測(cè)時(shí)必須監(jiān)控GPU利用率”這個(gè)原則寫(xiě)在文檔里可能過(guò)幾周就沒(méi)人看了但如果寫(xiě)進(jìn)壓測(cè)腳本里每次壓測(cè)結(jié)束自動(dòng)出一份指標(biāo)報(bào)告這個(gè)原則就變成了流程的一部分天然被強(qiáng)制執(zhí)行。制度化永遠(yuǎn)是比自覺(jué)更可靠的保障。6. 一個(gè)更長(zhǎng)期的視角算法與基礎(chǔ)設(shè)施雙輪驅(qū)動(dòng)的演進(jìn)路徑6.1 模型迭代和基礎(chǔ)設(shè)施演進(jìn)要配套走我們剛開(kāi)始做這個(gè)協(xié)同項(xiàng)目的時(shí)候總覺(jué)得模型迭代是最重要的infra只是“陪跑”。但做到后面才發(fā)現(xiàn)兩者其實(shí)是在互相牽引的。模型側(cè)有個(gè)新想法比如從單模態(tài)走向多模態(tài)或者模型結(jié)構(gòu)要從2D卷積換成3D卷積這對(duì)基礎(chǔ)設(shè)施提出的要求是完全不同的反過(guò)來(lái)基礎(chǔ)設(shè)施這邊推理框架升級(jí)支持了新的算子和精度模式也會(huì)反過(guò)來(lái)影響模型側(cè)怎么做結(jié)構(gòu)設(shè)計(jì)和調(diào)優(yōu)。所以現(xiàn)在我們?cè)谧黾夹g(shù)規(guī)劃時(shí)會(huì)把算法和infra放在同一個(gè)盤(pán)子里看。每次新模型立項(xiàng)的時(shí)候算法團(tuán)隊(duì)要寫(xiě)清楚預(yù)期的推理需求和資源消耗infra團(tuán)隊(duì)根據(jù)這個(gè)需求反饋基礎(chǔ)設(shè)施的改造計(jì)劃兩邊一起排期而不是等算法做完了再丟給infra“看看能不能跑”。這種平行推進(jìn)的節(jié)奏看起來(lái)很慢實(shí)際算總時(shí)間反而更快因?yàn)樗鼫p少了大量返工和等待。6.2 “算法-infra協(xié)同”的三種模式根據(jù)團(tuán)隊(duì)的大小和業(yè)務(wù)復(fù)雜度我觀察到的協(xié)同模式大概有三類(lèi)你可以看看自己團(tuán)隊(duì)現(xiàn)在卡在哪一類(lèi)。第一種是“工程師一肩挑”小團(tuán)隊(duì)里算法同學(xué)順便把自己寫(xiě)的服務(wù)部署上線(xiàn)了這種模式最靈活但對(duì)個(gè)人能力要求極高而且隨著業(yè)務(wù)變大很難維持。第二種是“接口人協(xié)作”算法和infra各派一個(gè)人負(fù)責(zé)對(duì)接互相轉(zhuǎn)述需求這種模式對(duì)接口人的能力依賴(lài)極大接口人一換人就可能崩。第三種是“流程化協(xié)同”通過(guò)標(biāo)準(zhǔn)的交付物、性能指標(biāo)、部署流程來(lái)協(xié)作人和人之間對(duì)具體細(xì)節(jié)的依賴(lài)降到最低這也是我在這篇文章里主要推薦的做法。三種模式之間不是互斥的團(tuán)隊(duì)小的時(shí)候可以用第一種起家逐漸過(guò)渡到第二種最后在業(yè)務(wù)量上來(lái)之后用第三種方式做長(zhǎng)治久安的保障。關(guān)鍵是心里要有個(gè)譜現(xiàn)在的協(xié)同方式在小規(guī)模下夠用但它不會(huì)自動(dòng)適配更大體量的團(tuán)隊(duì)和更復(fù)雜的業(yè)務(wù)。6.3 數(shù)據(jù)驅(qū)動(dòng)的協(xié)同能力評(píng)估最后一個(gè)想聊的心得是協(xié)同本身也要量化不能被“最近好像合作好多了”這種模糊感覺(jué)帶過(guò)去。我們每個(gè)月會(huì)看幾個(gè)關(guān)鍵數(shù)字平均模型上線(xiàn)周期、壓測(cè)通過(guò)率、資源超用率、線(xiàn)上重大性能事件次數(shù)。這組數(shù)字能直觀反映算法和infra之間的配合是否在變好而不是憑某幾次印象做判斷。我第一次提出這個(gè)想法時(shí)有同事開(kāi)玩笑說(shuō)“連協(xié)同都要上指標(biāo)了是不是卷過(guò)頭了”。但實(shí)際跑下來(lái)效果還挺好。因?yàn)橐坏?shù)字看得到就總有人會(huì)想辦法改進(jìn)數(shù)字。比如那陣子壓測(cè)通過(guò)率只有60%大家分析一圈發(fā)現(xiàn)是模型交付的“模型說(shuō)明卡”寫(xiě)得不完整infra拿到模型以后各種猜浪費(fèi)了不少時(shí)間。后來(lái)把說(shuō)明卡模板和交付工具打通壓測(cè)通過(guò)率很快升了上來(lái)。如果沒(méi)有數(shù)據(jù)這種問(wèn)題可能永遠(yuǎn)藏在“溝通不太順”的模糊說(shuō)法里誰(shuí)也看不到具體的短板在哪里。所以我的建議是如果你的團(tuán)隊(duì)也經(jīng)常因?yàn)樗惴ê蚷nfra的邊界吵架、推諉先別急著開(kāi)“加強(qiáng)溝通”的會(huì)不如一起定一套可量化的協(xié)同指標(biāo)把問(wèn)題擺到明面上。數(shù)據(jù)到位了協(xié)作自然會(huì)改善。我個(gè)人在帶著團(tuán)隊(duì)跑完這個(gè)項(xiàng)目之后最大的感受就是算法和infra的協(xié)同說(shuō)到底是兩個(gè)知識(shí)體系之間的翻譯工作。算法同學(xué)需要理解一點(diǎn)系統(tǒng)原理和工程約束infra同學(xué)也要懂一點(diǎn)模型推理的基本邏輯中間用標(biāo)準(zhǔn)化的接口、可量化的指標(biāo)和數(shù)據(jù)化的復(fù)盤(pán)來(lái)搭橋。不要指望靠幾次團(tuán)建或幾輪溝通就能根治協(xié)作問(wèn)題真正管用的還是把這些協(xié)同點(diǎn)固化到流程和技術(shù)里讓流程替人去記憶、去執(zhí)行。這一步做到了團(tuán)隊(duì)的能力才算真正沉淀下來(lái)。