建AI工程體系：數(shù)據(jù)管道、模型部署與監(jiān)控實(shí)戰(zhàn)指南)
1. 從零搭建AI工程體系為什么我勸你別一上來(lái)就啃框架ai-engineering-from-scratch這個(gè)標(biāo)題第一次看到的時(shí)候我愣了一下。不是因?yàn)槟吧∏∠喾词且驗(yàn)樘煜ち恕^(guò)去幾年我?guī)н^(guò)不少?gòu)乃惴◢忁D(zhuǎn)工程崗、或者干脆是從其他行業(yè)跳進(jìn)來(lái)做AI應(yīng)用的朋友幾乎每個(gè)人都會(huì)問(wèn)同一個(gè)問(wèn)題我到底該從哪兒開(kāi)始大多數(shù)人的第一反應(yīng)是打開(kāi)某個(gè)深度學(xué)習(xí)框架的官方教程跑一遍MNIST手寫數(shù)字識(shí)別然后覺(jué)得自己入門了。但真到了要做一個(gè)能上線的AI功能時(shí)立刻抓瞎模型怎么打包推理延遲怎么壓數(shù)據(jù)管道怎么搭線上效果和離線評(píng)估對(duì)不上怎么辦這些問(wèn)題框架教程一個(gè)都不會(huì)教你。所以從零構(gòu)建AI工程能力這件事核心根本不是從零學(xué)某個(gè)框架而是從零建立一套工程化的思維方式和工具鏈?？蚣苤皇瞧渲幸画h(huán)而且往往不是最難的那一環(huán)。這篇文章我想聊的就是這套體系到底包含什么、每一塊該怎么練、以及我在實(shí)際項(xiàng)目里踩過(guò)的那些坑。適合誰(shuí)看如果你已經(jīng)會(huì)寫Python、大致知道什么是神經(jīng)網(wǎng)絡(luò)但一提到把模型部署到生產(chǎn)環(huán)境就心里沒(méi)底那這篇就是寫給你的。如果你是完全的零基礎(chǔ)也能看但建議先把Python和基礎(chǔ)數(shù)學(xué)補(bǔ)一補(bǔ)再回來(lái)。全文我會(huì)盡量用大白話加實(shí)際案例來(lái)講不堆術(shù)語(yǔ)。2. AI工程能力到底包含哪些模塊2.1 先搞清楚AI工程和算法研究的分界線很多人把這兩件事混為一談結(jié)果學(xué)得又累又沒(méi)方向。我用一句話區(qū)分算法研究關(guān)心模型能不能達(dá)到某個(gè)指標(biāo)AI工程關(guān)心這個(gè)模型能不能穩(wěn)定、高效、低成本地跑在真實(shí)業(yè)務(wù)里。舉個(gè)具體例子。研究側(cè)可能花兩周把某個(gè)任務(wù)的準(zhǔn)確率從92%調(diào)到94%這是他們的KPI。但工程側(cè)要操心的是這個(gè)94%的模型推理一次要200毫秒業(yè)務(wù)要求50毫秒以內(nèi)怎么辦模型文件2個(gè)G邊緣設(shè)備裝不下怎么辦輸入數(shù)據(jù)里混了臟數(shù)據(jù)導(dǎo)致模型輸出崩潰怎么兜底這些問(wèn)題研究側(cè)通常不管但工程側(cè)必須解決。所以AI工程的能力模塊我一般拆成這么幾塊數(shù)據(jù)處理與管道從原始數(shù)據(jù)到模型可用輸入的完整鏈路包括清洗、特征工程、批處理、增量更新模型訓(xùn)練與實(shí)驗(yàn)管理不只是跑訓(xùn)練腳本還包括實(shí)驗(yàn)追蹤、超參管理、版本控制模型優(yōu)化與壓縮量化、剪枝、蒸餾、算子融合目的是讓模型跑得動(dòng)、跑得快推理服務(wù)與部署把模型包裝成可調(diào)用的服務(wù)處理并發(fā)、超時(shí)、降級(jí)監(jiān)控與運(yùn)維線上指標(biāo)監(jiān)控、數(shù)據(jù)漂移檢測(cè)、模型回滾機(jī)制成本與資源管理GPU調(diào)度、緩存策略、彈性伸縮這六塊里純寫代碼的難度其實(shí)都不算高難的是把它們串起來(lái)并且讓整條鏈路在出問(wèn)題時(shí)能快速定位。這也是為什么我說(shuō)別一上來(lái)就啃框架——框架只覆蓋了第二塊和第三塊的一部分剩下的你得自己搭。2.2 為什么從零反而比從框架更快這里我要說(shuō)一個(gè)反直覺(jué)的觀點(diǎn)如果你目標(biāo)是做AI工程從零手寫一些基礎(chǔ)組件比直接調(diào)框架API學(xué)得更快。原因很簡(jiǎn)單。調(diào)API的時(shí)候你是在一個(gè)被高度抽象過(guò)的層面上工作很多細(xì)節(jié)被隱藏了。隱藏是好事效率高但代價(jià)是你不知道底下發(fā)生了什么。一旦出問(wèn)題你連從哪兒查都不知道。我自己帶人的經(jīng)驗(yàn)是讓新人先用NumPy手寫一遍簡(jiǎn)單的線性回歸和前向傳播哪怕寫得慢、寫得丑寫完他對(duì)張量運(yùn)算梯度損失函數(shù)這些概念的理解會(huì)完全不一樣。之后再去看框架的API他會(huì)明白每一行代碼背后大概在干什么調(diào)參和排錯(cuò)的時(shí)候心里有譜。當(dāng)然我不是說(shuō)所有東西都要手寫。像卷積、注意力機(jī)制這種手寫一遍理解原理就夠了真做項(xiàng)目還是用框架。關(guān)鍵是你得知道哪些東西值得手寫一遍哪些直接用現(xiàn)成的。我的建議是數(shù)據(jù)管道、訓(xùn)練循環(huán)、評(píng)估邏輯這三塊值得自己搭一遍模型結(jié)構(gòu)本身用框架就行。3. 核心模塊的實(shí)操要點(diǎn)與避坑指南3.1 數(shù)據(jù)管道最不起眼但最容易翻車的地方我見(jiàn)過(guò)太多項(xiàng)目模型本身沒(méi)問(wèn)題最后栽在數(shù)據(jù)管道上。數(shù)據(jù)管道這塊有幾個(gè)關(guān)鍵點(diǎn)我一個(gè)個(gè)說(shuō)。第一數(shù)據(jù)版本控制。模型有版本數(shù)據(jù)也得有版本。你今天用A版本數(shù)據(jù)訓(xùn)了個(gè)模型明天數(shù)據(jù)更新了想復(fù)現(xiàn)昨天的結(jié)果發(fā)現(xiàn)數(shù)據(jù)變了復(fù)現(xiàn)不出來(lái)。解決辦法是用類似DVC這樣的工具或者簡(jiǎn)單點(diǎn)每次數(shù)據(jù)處理完打個(gè)快照存起來(lái)記錄好哈希值。別嫌麻煩這個(gè)習(xí)慣能救你無(wú)數(shù)次。第二增量處理而不是全量重跑。很多新手的數(shù)據(jù)管道是每次全量重跑數(shù)據(jù)量小的時(shí)候沒(méi)事數(shù)據(jù)一上來(lái)就是幾百萬(wàn)條每次重跑幾小時(shí)迭代效率直接崩。正確做法是把管道設(shè)計(jì)成增量的新數(shù)據(jù)來(lái)了只處理新的部分歷史處理結(jié)果緩存起來(lái)。第三數(shù)據(jù)校驗(yàn)必須前置。模型訓(xùn)練前一定要有數(shù)據(jù)校驗(yàn)環(huán)節(jié)檢查字段類型、取值范圍、缺失率、分布是否異常。我踩過(guò)的一個(gè)坑是上游某個(gè)字段突然從整數(shù)變成了字符串訓(xùn)練腳本沒(méi)報(bào)錯(cuò)默默把這一列當(dāng)成了全NaN處理模型訓(xùn)出來(lái)效果奇差查了兩天才發(fā)現(xiàn)是數(shù)據(jù)的問(wèn)題。如果當(dāng)時(shí)有校驗(yàn)五分鐘就能定位。提示數(shù)據(jù)校驗(yàn)不用搞得很復(fù)雜用pandera或者great_expectations這類庫(kù)定義好每個(gè)字段的期望類型和范圍跑一遍就能攔住大部分低級(jí)錯(cuò)誤。3.2 訓(xùn)練循環(huán)別小看重復(fù)造輪子的價(jià)值訓(xùn)練循環(huán)這塊我強(qiáng)烈建議每個(gè)做AI工程的人都自己從零寫一遍。不是讓你不用框架的Trainer而是至少寫一次純PyTorch或者純NumPy的訓(xùn)練循環(huán)把前向、損失、反向、更新這幾步手動(dòng)串起來(lái)。為什么因?yàn)橹挥心阕约簩戇^(guò)你才知道loss.backward()背后發(fā)生了什么才知道梯度累積、梯度裁剪、學(xué)習(xí)率調(diào)度這些操作是在哪個(gè)環(huán)節(jié)介入的。線上出問(wèn)題的時(shí)候比如loss突然變成NaN你才能快速判斷是數(shù)據(jù)問(wèn)題、學(xué)習(xí)率問(wèn)題還是數(shù)值精度問(wèn)題。自己寫訓(xùn)練循環(huán)的時(shí)候有幾個(gè)細(xì)節(jié)特別容易忽略隨機(jī)種子的設(shè)置不只是torch.manual_seedNumPy、Python內(nèi)置random、甚至CUDA的種子都要設(shè)否則結(jié)果不可復(fù)現(xiàn)梯度累積的正確實(shí)現(xiàn)不是簡(jiǎn)單地把loss加起來(lái)要注意除以累積步數(shù)否則等效學(xué)習(xí)率會(huì)變混合精度訓(xùn)練的坑用AMP的時(shí)候loss scaling沒(méi)處理好會(huì)導(dǎo)致梯度下溢表現(xiàn)為loss不降反升這些細(xì)節(jié)框架的Trainer都幫你處理了但你不理解的話出問(wèn)題就只能干瞪眼。3.3 模型優(yōu)化量化、剪枝、蒸餾到底該選哪個(gè)模型優(yōu)化是AI工程里技術(shù)含量比較高的一塊也是最能體現(xiàn)工程價(jià)值的地方。三個(gè)主流手段量化、剪枝、蒸餾我做個(gè)對(duì)比。優(yōu)化手段核心思路典型收益適用場(chǎng)景主要風(fēng)險(xiǎn)量化降低數(shù)值精度如FP32轉(zhuǎn)INT8體積減4倍速度提升2-4倍推理部署尤其是邊緣設(shè)備精度損失需校準(zhǔn)剪枝去掉不重要的權(quán)重或結(jié)構(gòu)體積和計(jì)算量下降模型明顯過(guò)參數(shù)化時(shí)剪多了精度崩需重訓(xùn)蒸餾用大模型教小模型小模型精度接近大模型需要小模型但精度要求高訓(xùn)練成本高需教師模型實(shí)際項(xiàng)目里這三者經(jīng)常組合使用。比如先蒸餾出一個(gè)中等大小的模型再量化部署。但順序很重要一般先蒸餾再量化因?yàn)榱炕蟮哪Ｐ秃茈y再蒸餾。量化這塊我要多啰嗦幾句因?yàn)榭幼疃?。?xùn)練后量化PTQ簡(jiǎn)單但精度損失可能比較大量化感知訓(xùn)練QAT精度好但要在訓(xùn)練階段就介入成本高。我的經(jīng)驗(yàn)是先試PTQ如果精度掉得能接受就用PTQ掉太多再考慮QAT。校準(zhǔn)數(shù)據(jù)集的選擇也很關(guān)鍵要用有代表性的真實(shí)數(shù)據(jù)別隨便拿幾條樣本糊弄。3.4 推理服務(wù)并發(fā)、超時(shí)、降級(jí)一個(gè)都不能少模型訓(xùn)好了優(yōu)化完了最后一步是部署成服務(wù)。這一步的坑說(shuō)實(shí)話比訓(xùn)練還多。并發(fā)處理是第一個(gè)坎。模型推理是計(jì)算密集型任務(wù)單進(jìn)程處理并發(fā)請(qǐng)求會(huì)排隊(duì)。常見(jiàn)做法是用多進(jìn)程或者異步IO。但要注意GPU推理的時(shí)候多進(jìn)程共享GPU會(huì)有顯存競(jìng)爭(zhēng)問(wèn)題得用專門的推理服務(wù)器比如Triton或者TorchServe來(lái)管理。超時(shí)控制是第二個(gè)坎。線上請(qǐng)求必須有超時(shí)否則一個(gè)慢請(qǐng)求能把整個(gè)服務(wù)拖垮。超時(shí)時(shí)間怎么定我的經(jīng)驗(yàn)是看P99延遲超時(shí)設(shè)成P99的1.5到2倍比較合理。超時(shí)后的處理也要想好是返回默認(rèn)值、走降級(jí)邏輯還是直接報(bào)錯(cuò)。降級(jí)機(jī)制是第三個(gè)坎也是最容易被忽略的。模型服務(wù)掛了怎么辦常見(jiàn)做法是準(zhǔn)備一個(gè)規(guī)則兜底方案模型不可用時(shí)切到規(guī)則。比如推薦系統(tǒng)模型掛了就返回?zé)衢T內(nèi)容。這個(gè)兜底方案平時(shí)可能用不上但關(guān)鍵時(shí)刻能保住業(yè)務(wù)不中斷。注意降級(jí)邏輯一定要定期演練別等到真出事的時(shí)候才發(fā)現(xiàn)兜底方案本身有bug。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)降級(jí)代碼寫了半年沒(méi)跑過(guò)真觸發(fā)的時(shí)候直接報(bào)錯(cuò)等于沒(méi)有。4. 完整實(shí)操流程從零搭一個(gè)可用的AI服務(wù)4.1 環(huán)境準(zhǔn)備與項(xiàng)目結(jié)構(gòu)說(shuō)了這么多理論來(lái)點(diǎn)實(shí)際的。我以一個(gè)文本分類服務(wù)為例走一遍完整流程。假設(shè)我們要做一個(gè)情感分析服務(wù)輸入一段文本輸出正面/負(fù)面。項(xiàng)目結(jié)構(gòu)我一般這么組織project/ ├── data/ │ ├── raw/ # 原始數(shù)據(jù) │ ├── processed/ # 處理后的數(shù)據(jù) │ └── validation/ # 校驗(yàn)規(guī)則 ├── src/ │ ├── data_pipeline/ # 數(shù)據(jù)管道 │ ├── training/ # 訓(xùn)練代碼 │ ├── optimization/ # 模型優(yōu)化 │ └── serving/ # 推理服務(wù) ├── configs/ # 配置文件 ├── experiments/ # 實(shí)驗(yàn)記錄 ├── tests/ # 測(cè)試 └── requirements.txt這個(gè)結(jié)構(gòu)的好處是職責(zé)清晰數(shù)據(jù)、代碼、配置、實(shí)驗(yàn)記錄分開(kāi)團(tuán)隊(duì)協(xié)作的時(shí)候不容易亂。配置用YAML文件管理不同環(huán)境開(kāi)發(fā)、測(cè)試、生產(chǎn)用不同的配置文件避免硬編碼。環(huán)境依賴這塊我建議用conda或者venv隔離別用系統(tǒng)Python。依賴版本一定要鎖死requirements.txt里寫清楚具體版本號(hào)別用。我踩過(guò)的坑是本地開(kāi)發(fā)用的某個(gè)庫(kù)是1.2版本生產(chǎn)環(huán)境裝的時(shí)候自動(dòng)裝了1.5API變了服務(wù)起不來(lái)。4.2 數(shù)據(jù)管道搭建與校驗(yàn)數(shù)據(jù)管道我用一個(gè)簡(jiǎn)單的例子說(shuō)明。假設(shè)原始數(shù)據(jù)是一個(gè)CSV文件兩列text和label。第一步是數(shù)據(jù)加載和清洗。清洗包括去重、去空、去除異常字符。這一步用pandas就能搞定但要注意內(nèi)存數(shù)據(jù)大的時(shí)候用分塊讀取。第二步是數(shù)據(jù)校驗(yàn)。我定義一個(gè)校驗(yàn)規(guī)則import pandera as pa from pandera import Column, DataFrameSchema schema DataFrameSchema({ text: Column(str, checks[ pa.Check(lambda s: s.str.len() 0), pa.Check(lambda s: s.str.len() 5000) ]), label: Column(int, checkspa.Check.isin([0, 1])) })這個(gè)規(guī)則會(huì)檢查text非空且長(zhǎng)度合理label只能是0或1。跑一遍校驗(yàn)不符合的數(shù)據(jù)直接攔下來(lái)記錄日志。第三步是特征處理。文本分類一般先分詞再轉(zhuǎn)成ID序列。分詞器要固定下來(lái)訓(xùn)練和推理用同一個(gè)否則輸入分布不一致效果會(huì)崩。分詞器的詞表也要版本化跟模型綁定。第四步是數(shù)據(jù)緩存。處理好的數(shù)據(jù)存成二進(jìn)制格式比如pickle或者parquet下次直接用不用重新處理。緩存要帶版本號(hào)數(shù)據(jù)或處理邏輯變了就換新版本。4.3 訓(xùn)練與實(shí)驗(yàn)管理訓(xùn)練這塊我建議用配置驅(qū)動(dòng)的方式。所有超參寫在配置文件里代碼只讀配置不硬編碼。這樣換超參不用改代碼實(shí)驗(yàn)也好管理。實(shí)驗(yàn)管理我用MLflow或者WandB這類工具每次訓(xùn)練自動(dòng)記錄超參、指標(biāo)、模型文件。這樣回頭對(duì)比實(shí)驗(yàn)的時(shí)候一目了然。別用Excel記實(shí)驗(yàn)記著記著就亂了。訓(xùn)練循環(huán)的關(guān)鍵代碼大概長(zhǎng)這樣for epoch in range(num_epochs): model.train() for batch in train_loader: optimizer.zero_grad() outputs model(batch[input_ids]) loss criterion(outputs, batch[label]) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() # 驗(yàn)證 model.eval() with torch.no_grad(): val_metrics evaluate(model, val_loader) scheduler.step(val_metrics[f1]) # 記錄 mlflow.log_metrics(val_metrics, stepepoch)這里有幾個(gè)細(xì)節(jié)梯度裁剪防止梯度爆炸學(xué)習(xí)率調(diào)度器根據(jù)驗(yàn)證指標(biāo)調(diào)整學(xué)習(xí)率每個(gè)epoch記錄指標(biāo)。這些都是實(shí)戰(zhàn)里總結(jié)出來(lái)的不是可有可無(wú)的。4.4 模型優(yōu)化與導(dǎo)出訓(xùn)練完的模型先做優(yōu)化再導(dǎo)出。以量化為例如import torch.quantization as tq model.eval() model.qconfig tq.get_default_qconfig(fbgemm) model_prepared tq.prepare(model, inplaceFalse) # 用校準(zhǔn)數(shù)據(jù)跑一遍 with torch.no_grad(): for batch in calib_loader: model_prepared(batch[input_ids]) model_quantized tq.convert(model_prepared, inplaceFalse) torch.save(model_quantized.state_dict(), model_quantized.pt)校準(zhǔn)數(shù)據(jù)要用真實(shí)分布的數(shù)據(jù)一般幾百到幾千條就夠。量化完一定要在驗(yàn)證集上重新評(píng)估確認(rèn)精度損失在可接受范圍內(nèi)。如果掉太多考慮換QAT或者放棄量化。導(dǎo)出的時(shí)候除了模型權(quán)重還要把分詞器、配置、版本信息一起打包。我一般打成一個(gè)目錄里面包含model.pt、tokenizer、config.yaml、version.txt。部署的時(shí)候整個(gè)目錄一起加載避免版本不匹配。4.5 推理服務(wù)實(shí)現(xiàn)推理服務(wù)我用FastAPI寫簡(jiǎn)單直接。核心代碼from fastapi import FastAPI from pydantic import BaseModel import torch app FastAPI() model load_model(model_dir) tokenizer load_tokenizer(model_dir) class Request(BaseModel): text: str class Response(BaseModel): label: int confidence: float app.post(/predict, response_modelResponse) async def predict(req: Request): inputs tokenizer(req.text, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): outputs model(**inputs) probs torch.softmax(outputs.logits, dim-1) label int(torch.argmax(probs, dim-1)) confidence float(torch.max(probs)) return Response(labellabel, confidenceconfidence)這個(gè)服務(wù)能跑但離生產(chǎn)可用還差幾步。第一要加超時(shí)控制用asyncio.wait_for包一層。第二要加限流防止請(qǐng)求打爆。第三要加健康檢查接口方便監(jiān)控。第四要加日志記錄每個(gè)請(qǐng)求的輸入輸出和耗時(shí)。部署的時(shí)候用gunicorn加uvicorn worker多進(jìn)程跑起來(lái)。GPU的話注意每個(gè)進(jìn)程的顯存占用別開(kāi)太多worker把顯存撐爆。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 訓(xùn)練相關(guān)的高頻問(wèn)題問(wèn)題一loss不下降或者變成NaN。排查思路先看數(shù)據(jù)有沒(méi)有異常值、標(biāo)簽有沒(méi)有錯(cuò)。再看學(xué)習(xí)率是不是太大了。然后看梯度有沒(méi)有爆炸。最后看數(shù)值精度FP16訓(xùn)練容易出這個(gè)問(wèn)題試試用FP32或者加loss scaling。問(wèn)題二訓(xùn)練集效果好驗(yàn)證集效果差。典型的過(guò)擬合。解決辦法加正則化、加dropout、減小模型、增加數(shù)據(jù)。還有一個(gè)容易被忽略的原因訓(xùn)練集和驗(yàn)證集的數(shù)據(jù)分布不一致比如驗(yàn)證集里有訓(xùn)練集沒(méi)見(jiàn)過(guò)的類別。這種情況要檢查數(shù)據(jù)劃分邏輯。問(wèn)題三結(jié)果不可復(fù)現(xiàn)。九成是隨機(jī)種子沒(méi)設(shè)全。除了PyTorch的種子還要設(shè)NumPy、Python random、CUDA的種子。另外DataLoader的worker多的時(shí)候每個(gè)worker的種子也要設(shè)。還有如果用了非確定性算子比如某些CUDA操作結(jié)果也會(huì)有微小差異這個(gè)要接受。5.2 部署相關(guān)的高頻問(wèn)題問(wèn)題一線上延遲比離線測(cè)試高很多。常見(jiàn)原因批處理大小不一樣、硬件不一樣、有網(wǎng)絡(luò)開(kāi)銷、有預(yù)處理開(kāi)銷。排查的時(shí)候要分段計(jì)時(shí)看時(shí)間花在哪。我遇到過(guò)一次離線測(cè)試用的是批處理線上是單條推理延遲差了十倍。后來(lái)改成動(dòng)態(tài)批處理延遲降下來(lái)了。問(wèn)題二顯存溢出。推理的時(shí)候顯存溢出一般是批處理太大或者模型太大。解決辦法減小批處理、用量化模型、用梯度檢查點(diǎn)訓(xùn)練時(shí)。還有一個(gè)坑是顯存碎片長(zhǎng)時(shí)間運(yùn)行后顯存碎片化明明有空間卻分配不出來(lái)。解決辦法是定期重啟服務(wù)或者用顯存池管理。問(wèn)題三服務(wù)偶發(fā)崩潰。這種最難查。我的經(jīng)驗(yàn)是加詳細(xì)的日志和監(jiān)控記錄每次崩潰前的輸入、狀態(tài)、資源使用情況。常見(jiàn)原因有內(nèi)存泄漏、并發(fā)競(jìng)爭(zhēng)、依賴庫(kù)的偶發(fā)bug。內(nèi)存泄漏可以用tracemalloc或者memory_profiler查。5.3 問(wèn)題速查表現(xiàn)象可能原因排查方向解決思路loss變NaN學(xué)習(xí)率過(guò)大、數(shù)據(jù)異常、精度問(wèn)題檢查數(shù)據(jù)、降低學(xué)習(xí)率、用FP32加梯度裁剪、數(shù)據(jù)校驗(yàn)驗(yàn)證集效果差過(guò)擬合、數(shù)據(jù)分布不一致對(duì)比訓(xùn)練驗(yàn)證分布加正則、檢查數(shù)據(jù)劃分結(jié)果不可復(fù)現(xiàn)種子沒(méi)設(shè)全、非確定性算子檢查所有隨機(jī)源設(shè)全種子、固定算子線上延遲高批處理差異、預(yù)處理開(kāi)銷分段計(jì)時(shí)動(dòng)態(tài)批處理、優(yōu)化預(yù)處理顯存溢出批處理大、碎片化監(jiān)控顯存使用減小批處理、定期重啟服務(wù)偶發(fā)崩潰內(nèi)存泄漏、并發(fā)問(wèn)題加日志監(jiān)控定位后修復(fù)、加兜底6. 我個(gè)人的一些經(jīng)驗(yàn)和建議做AI工程這幾年最大的體會(huì)是技術(shù)深度重要但工程思維更重要。很多問(wèn)題不是靠某個(gè)高級(jí)算法解決的而是靠合理的架構(gòu)設(shè)計(jì)、完善的監(jiān)控、嚴(yán)謹(jǐn)?shù)牧鞒探鉀Q的。比如數(shù)據(jù)版本控制這件事技術(shù)上沒(méi)什么難度但堅(jiān)持做的人不多?？删褪沁@個(gè)小習(xí)慣能在關(guān)鍵時(shí)刻幫你快速定位問(wèn)題。再比如降級(jí)機(jī)制平時(shí)看起來(lái)是多余的但真出事的時(shí)候它就是業(yè)務(wù)的救命稻草。還有一個(gè)建議是別追求一步到位。我見(jiàn)過(guò)太多團(tuán)隊(duì)一上來(lái)就想搭一個(gè)完美的MLOps平臺(tái)結(jié)果搭了半年還沒(méi)上線。正確的做法是先跑通最小閉環(huán)模型能訓(xùn)、能部署、能監(jiān)控然后再逐步優(yōu)化。先解決有無(wú)再解決好壞。最后說(shuō)個(gè)具體的技巧。做AI工程一定要養(yǎng)成寫文檔和記錄的習(xí)慣。每次踩坑、每次決策都記下來(lái)。不是為了給別人看是為了給三個(gè)月后的自己看。我現(xiàn)在回頭看自己兩年前的項(xiàng)目筆記很多當(dāng)時(shí)覺(jué)得理所當(dāng)然的決策現(xiàn)在都想不起來(lái)為什么那么做了。文檔就是你的第二大腦。這個(gè)領(lǐng)域變化快工具和框架年年更新但底層的工程原則變化很慢。把數(shù)據(jù)管道、訓(xùn)練循環(huán)、部署監(jiān)控這幾塊的基本功練扎實(shí)不管工具怎么變你都能快速上手。反過(guò)來(lái)如果只追新工具不理解原理工具一換你就得重新學(xué)。所以ai-engineering-from-scratch這件事我的建議是從原理入手從最小閉環(huán)做起邊做邊補(bǔ)細(xì)節(jié)。別貪多別求快把每一塊都真正搞懂比什么都重要。 從零構(gòu)建AI工程體系：數(shù)據(jù)管道、模型部署與監(jiān)控實(shí)戰(zhàn)指南
1. 從零搭建AI工程體系為什么我勸你別一上來(lái)就啃框架ai-engineering-from-scratch這個(gè)標(biāo)題第一次看到的時(shí)候我愣了一下。不是因?yàn)槟吧∏∠喾词且驗(yàn)樘煜ち恕^(guò)去幾年我?guī)н^(guò)不少?gòu)乃惴◢忁D(zhuǎn)工程崗、或者干脆是從其他行業(yè)跳進(jìn)來(lái)做AI應(yīng)用的朋友幾乎每個(gè)人都會(huì)問(wèn)同一個(gè)問(wèn)題我到底該從哪兒開(kāi)始大多數(shù)人的第一反應(yīng)是打開(kāi)某個(gè)深度學(xué)習(xí)框架的官方教程跑一遍MNIST手寫數(shù)字識(shí)別然后覺(jué)得自己入門了。但真到了要做一個(gè)能上線的AI功能時(shí)立刻抓瞎模型怎么打包推理延遲怎么壓數(shù)據(jù)管道怎么搭線上效果和離線評(píng)估對(duì)不上怎么辦這些問(wèn)題框架教程一個(gè)都不會(huì)教你。所以從零構(gòu)建AI工程能力這件事核心根本不是從零學(xué)某個(gè)框架而是從零建立一套工程化的思維方式和工具鏈?？蚣苤皇瞧渲幸画h(huán)而且往往不是最難的那一環(huán)。這篇文章我想聊的就是這套體系到底包含什么、每一塊該怎么練、以及我在實(shí)際項(xiàng)目里踩過(guò)的那些坑。適合誰(shuí)看如果你已經(jīng)會(huì)寫Python、大致知道什么是神經(jīng)網(wǎng)絡(luò)但一提到把模型部署到生產(chǎn)環(huán)境就心里沒(méi)底那這篇就是寫給你的。如果你是完全的零基礎(chǔ)也能看但建議先把Python和基礎(chǔ)數(shù)學(xué)補(bǔ)一補(bǔ)再回來(lái)。全文我會(huì)盡量用大白話加實(shí)際案例來(lái)講不堆術(shù)語(yǔ)。2. AI工程能力到底包含哪些模塊2.1 先搞清楚AI工程和算法研究的分界線很多人把這兩件事混為一談結(jié)果學(xué)得又累又沒(méi)方向。我用一句話區(qū)分算法研究關(guān)心模型能不能達(dá)到某個(gè)指標(biāo)AI工程關(guān)心這個(gè)模型能不能穩(wěn)定、高效、低成本地跑在真實(shí)業(yè)務(wù)里。舉個(gè)具體例子。研究側(cè)可能花兩周把某個(gè)任務(wù)的準(zhǔn)確率從92%調(diào)到94%這是他們的KPI。但工程側(cè)要操心的是這個(gè)94%的模型推理一次要200毫秒業(yè)務(wù)要求50毫秒以內(nèi)怎么辦模型文件2個(gè)G邊緣設(shè)備裝不下怎么辦輸入數(shù)據(jù)里混了臟數(shù)據(jù)導(dǎo)致模型輸出崩潰怎么兜底這些問(wèn)題研究側(cè)通常不管但工程側(cè)必須解決。所以AI工程的能力模塊我一般拆成這么幾塊數(shù)據(jù)處理與管道從原始數(shù)據(jù)到模型可用輸入的完整鏈路包括清洗、特征工程、批處理、增量更新模型訓(xùn)練與實(shí)驗(yàn)管理不只是跑訓(xùn)練腳本還包括實(shí)驗(yàn)追蹤、超參管理、版本控制模型優(yōu)化與壓縮量化、剪枝、蒸餾、算子融合目的是讓模型跑得動(dòng)、跑得快推理服務(wù)與部署把模型包裝成可調(diào)用的服務(wù)處理并發(fā)、超時(shí)、降級(jí)監(jiān)控與運(yùn)維線上指標(biāo)監(jiān)控、數(shù)據(jù)漂移檢測(cè)、模型回滾機(jī)制成本與資源管理GPU調(diào)度、緩存策略、彈性伸縮這六塊里純寫代碼的難度其實(shí)都不算高難的是把它們串起來(lái)并且讓整條鏈路在出問(wèn)題時(shí)能快速定位。這也是為什么我說(shuō)別一上來(lái)就啃框架——框架只覆蓋了第二塊和第三塊的一部分剩下的你得自己搭。2.2 為什么從零反而比從框架更快這里我要說(shuō)一個(gè)反直覺(jué)的觀點(diǎn)如果你目標(biāo)是做AI工程從零手寫一些基礎(chǔ)組件比直接調(diào)框架API學(xué)得更快。原因很簡(jiǎn)單。調(diào)API的時(shí)候你是在一個(gè)被高度抽象過(guò)的層面上工作很多細(xì)節(jié)被隱藏了。隱藏是好事效率高但代價(jià)是你不知道底下發(fā)生了什么。一旦出問(wèn)題你連從哪兒查都不知道。我自己帶人的經(jīng)驗(yàn)是讓新人先用NumPy手寫一遍簡(jiǎn)單的線性回歸和前向傳播哪怕寫得慢、寫得丑寫完他對(duì)張量運(yùn)算梯度損失函數(shù)這些概念的理解會(huì)完全不一樣。之后再去看框架的API他會(huì)明白每一行代碼背后大概在干什么調(diào)參和排錯(cuò)的時(shí)候心里有譜。當(dāng)然我不是說(shuō)所有東西都要手寫。像卷積、注意力機(jī)制這種手寫一遍理解原理就夠了真做項(xiàng)目還是用框架。關(guān)鍵是你得知道哪些東西值得手寫一遍哪些直接用現(xiàn)成的。我的建議是數(shù)據(jù)管道、訓(xùn)練循環(huán)、評(píng)估邏輯這三塊值得自己搭一遍模型結(jié)構(gòu)本身用框架就行。3. 核心模塊的實(shí)操要點(diǎn)與避坑指南3.1 數(shù)據(jù)管道最不起眼但最容易翻車的地方我見(jiàn)過(guò)太多項(xiàng)目模型本身沒(méi)問(wèn)題最后栽在數(shù)據(jù)管道上。數(shù)據(jù)管道這塊有幾個(gè)關(guān)鍵點(diǎn)我一個(gè)個(gè)說(shuō)。第一數(shù)據(jù)版本控制。模型有版本數(shù)據(jù)也得有版本。你今天用A版本數(shù)據(jù)訓(xùn)了個(gè)模型明天數(shù)據(jù)更新了想復(fù)現(xiàn)昨天的結(jié)果發(fā)現(xiàn)數(shù)據(jù)變了復(fù)現(xiàn)不出來(lái)。解決辦法是用類似DVC這樣的工具或者簡(jiǎn)單點(diǎn)每次數(shù)據(jù)處理完打個(gè)快照存起來(lái)記錄好哈希值。別嫌麻煩這個(gè)習(xí)慣能救你無(wú)數(shù)次。第二增量處理而不是全量重跑。很多新手的數(shù)據(jù)管道是每次全量重跑數(shù)據(jù)量小的時(shí)候沒(méi)事數(shù)據(jù)一上來(lái)就是幾百萬(wàn)條每次重跑幾小時(shí)迭代效率直接崩。正確做法是把管道設(shè)計(jì)成增量的新數(shù)據(jù)來(lái)了只處理新的部分歷史處理結(jié)果緩存起來(lái)。第三數(shù)據(jù)校驗(yàn)必須前置。模型訓(xùn)練前一定要有數(shù)據(jù)校驗(yàn)環(huán)節(jié)檢查字段類型、取值范圍、缺失率、分布是否異常。我踩過(guò)的一個(gè)坑是上游某個(gè)字段突然從整數(shù)變成了字符串訓(xùn)練腳本沒(méi)報(bào)錯(cuò)默默把這一列當(dāng)成了全NaN處理模型訓(xùn)出來(lái)效果奇差查了兩天才發(fā)現(xiàn)是數(shù)據(jù)的問(wèn)題。如果當(dāng)時(shí)有校驗(yàn)五分鐘就能定位。提示數(shù)據(jù)校驗(yàn)不用搞得很復(fù)雜用pandera或者great_expectations這類庫(kù)定義好每個(gè)字段的期望類型和范圍跑一遍就能攔住大部分低級(jí)錯(cuò)誤。3.2 訓(xùn)練循環(huán)別小看重復(fù)造輪子的價(jià)值訓(xùn)練循環(huán)這塊我強(qiáng)烈建議每個(gè)做AI工程的人都自己從零寫一遍。不是讓你不用框架的Trainer而是至少寫一次純PyTorch或者純NumPy的訓(xùn)練循環(huán)把前向、損失、反向、更新這幾步手動(dòng)串起來(lái)。為什么因?yàn)橹挥心阕约簩戇^(guò)你才知道loss.backward()背后發(fā)生了什么才知道梯度累積、梯度裁剪、學(xué)習(xí)率調(diào)度這些操作是在哪個(gè)環(huán)節(jié)介入的。線上出問(wèn)題的時(shí)候比如loss突然變成NaN你才能快速判斷是數(shù)據(jù)問(wèn)題、學(xué)習(xí)率問(wèn)題還是數(shù)值精度問(wèn)題。自己寫訓(xùn)練循環(huán)的時(shí)候有幾個(gè)細(xì)節(jié)特別容易忽略隨機(jī)種子的設(shè)置不只是torch.manual_seedNumPy、Python內(nèi)置random、甚至CUDA的種子都要設(shè)否則結(jié)果不可復(fù)現(xiàn)梯度累積的正確實(shí)現(xiàn)不是簡(jiǎn)單地把loss加起來(lái)要注意除以累積步數(shù)否則等效學(xué)習(xí)率會(huì)變混合精度訓(xùn)練的坑用AMP的時(shí)候loss scaling沒(méi)處理好會(huì)導(dǎo)致梯度下溢表現(xiàn)為loss不降反升這些細(xì)節(jié)框架的Trainer都幫你處理了但你不理解的話出問(wèn)題就只能干瞪眼。3.3 模型優(yōu)化量化、剪枝、蒸餾到底該選哪個(gè)模型優(yōu)化是AI工程里技術(shù)含量比較高的一塊也是最能體現(xiàn)工程價(jià)值的地方。三個(gè)主流手段量化、剪枝、蒸餾我做個(gè)對(duì)比。優(yōu)化手段核心思路典型收益適用場(chǎng)景主要風(fēng)險(xiǎn)量化降低數(shù)值精度如FP32轉(zhuǎn)INT8體積減4倍速度提升2-4倍推理部署尤其是邊緣設(shè)備精度損失需校準(zhǔn)剪枝去掉不重要的權(quán)重或結(jié)構(gòu)體積和計(jì)算量下降模型明顯過(guò)參數(shù)化時(shí)剪多了精度崩需重訓(xùn)蒸餾用大模型教小模型小模型精度接近大模型需要小模型但精度要求高訓(xùn)練成本高需教師模型實(shí)際項(xiàng)目里這三者經(jīng)常組合使用。比如先蒸餾出一個(gè)中等大小的模型再量化部署。但順序很重要一般先蒸餾再量化因?yàn)榱炕蟮哪Ｐ秃茈y再蒸餾。量化這塊我要多啰嗦幾句因?yàn)榭幼疃?。?xùn)練后量化PTQ簡(jiǎn)單但精度損失可能比較大量化感知訓(xùn)練QAT精度好但要在訓(xùn)練階段就介入成本高。我的經(jīng)驗(yàn)是先試PTQ如果精度掉得能接受就用PTQ掉太多再考慮QAT。校準(zhǔn)數(shù)據(jù)集的選擇也很關(guān)鍵要用有代表性的真實(shí)數(shù)據(jù)別隨便拿幾條樣本糊弄。3.4 推理服務(wù)并發(fā)、超時(shí)、降級(jí)一個(gè)都不能少模型訓(xùn)好了優(yōu)化完了最后一步是部署成服務(wù)。這一步的坑說(shuō)實(shí)話比訓(xùn)練還多。并發(fā)處理是第一個(gè)坎。模型推理是計(jì)算密集型任務(wù)單進(jìn)程處理并發(fā)請(qǐng)求會(huì)排隊(duì)。常見(jiàn)做法是用多進(jìn)程或者異步IO。但要注意GPU推理的時(shí)候多進(jìn)程共享GPU會(huì)有顯存競(jìng)爭(zhēng)問(wèn)題得用專門的推理服務(wù)器比如Triton或者TorchServe來(lái)管理。超時(shí)控制是第二個(gè)坎。線上請(qǐng)求必須有超時(shí)否則一個(gè)慢請(qǐng)求能把整個(gè)服務(wù)拖垮。超時(shí)時(shí)間怎么定我的經(jīng)驗(yàn)是看P99延遲超時(shí)設(shè)成P99的1.5到2倍比較合理。超時(shí)后的處理也要想好是返回默認(rèn)值、走降級(jí)邏輯還是直接報(bào)錯(cuò)。降級(jí)機(jī)制是第三個(gè)坎也是最容易被忽略的。模型服務(wù)掛了怎么辦常見(jiàn)做法是準(zhǔn)備一個(gè)規(guī)則兜底方案模型不可用時(shí)切到規(guī)則。比如推薦系統(tǒng)模型掛了就返回?zé)衢T內(nèi)容。這個(gè)兜底方案平時(shí)可能用不上但關(guān)鍵時(shí)刻能保住業(yè)務(wù)不中斷。注意降級(jí)邏輯一定要定期演練別等到真出事的時(shí)候才發(fā)現(xiàn)兜底方案本身有bug。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)降級(jí)代碼寫了半年沒(méi)跑過(guò)真觸發(fā)的時(shí)候直接報(bào)錯(cuò)等于沒(méi)有。4. 完整實(shí)操流程從零搭一個(gè)可用的AI服務(wù)4.1 環(huán)境準(zhǔn)備與項(xiàng)目結(jié)構(gòu)說(shuō)了這么多理論來(lái)點(diǎn)實(shí)際的。我以一個(gè)文本分類服務(wù)為例走一遍完整流程。假設(shè)我們要做一個(gè)情感分析服務(wù)輸入一段文本輸出正面/負(fù)面。項(xiàng)目結(jié)構(gòu)我一般這么組織project/ ├── data/ │ ├── raw/ # 原始數(shù)據(jù) │ ├── processed/ # 處理后的數(shù)據(jù) │ └── validation/ # 校驗(yàn)規(guī)則 ├── src/ │ ├── data_pipeline/ # 數(shù)據(jù)管道 │ ├── training/ # 訓(xùn)練代碼 │ ├── optimization/ # 模型優(yōu)化 │ └── serving/ # 推理服務(wù) ├── configs/ # 配置文件 ├── experiments/ # 實(shí)驗(yàn)記錄 ├── tests/ # 測(cè)試 └── requirements.txt這個(gè)結(jié)構(gòu)的好處是職責(zé)清晰數(shù)據(jù)、代碼、配置、實(shí)驗(yàn)記錄分開(kāi)團(tuán)隊(duì)協(xié)作的時(shí)候不容易亂。配置用YAML文件管理不同環(huán)境開(kāi)發(fā)、測(cè)試、生產(chǎn)用不同的配置文件避免硬編碼。環(huán)境依賴這塊我建議用conda或者venv隔離別用系統(tǒng)Python。依賴版本一定要鎖死requirements.txt里寫清楚具體版本號(hào)別用。我踩過(guò)的坑是本地開(kāi)發(fā)用的某個(gè)庫(kù)是1.2版本生產(chǎn)環(huán)境裝的時(shí)候自動(dòng)裝了1.5API變了服務(wù)起不來(lái)。4.2 數(shù)據(jù)管道搭建與校驗(yàn)數(shù)據(jù)管道我用一個(gè)簡(jiǎn)單的例子說(shuō)明。假設(shè)原始數(shù)據(jù)是一個(gè)CSV文件兩列text和label。第一步是數(shù)據(jù)加載和清洗。清洗包括去重、去空、去除異常字符。這一步用pandas就能搞定但要注意內(nèi)存數(shù)據(jù)大的時(shí)候用分塊讀取。第二步是數(shù)據(jù)校驗(yàn)。我定義一個(gè)校驗(yàn)規(guī)則import pandera as pa from pandera import Column, DataFrameSchema schema DataFrameSchema({ text: Column(str, checks[ pa.Check(lambda s: s.str.len() 0), pa.Check(lambda s: s.str.len() 5000) ]), label: Column(int, checkspa.Check.isin([0, 1])) })這個(gè)規(guī)則會(huì)檢查text非空且長(zhǎng)度合理label只能是0或1。跑一遍校驗(yàn)不符合的數(shù)據(jù)直接攔下來(lái)記錄日志。第三步是特征處理。文本分類一般先分詞再轉(zhuǎn)成ID序列。分詞器要固定下來(lái)訓(xùn)練和推理用同一個(gè)否則輸入分布不一致效果會(huì)崩。分詞器的詞表也要版本化跟模型綁定。第四步是數(shù)據(jù)緩存。處理好的數(shù)據(jù)存成二進(jìn)制格式比如pickle或者parquet下次直接用不用重新處理。緩存要帶版本號(hào)數(shù)據(jù)或處理邏輯變了就換新版本。4.3 訓(xùn)練與實(shí)驗(yàn)管理訓(xùn)練這塊我建議用配置驅(qū)動(dòng)的方式。所有超參寫在配置文件里代碼只讀配置不硬編碼。這樣換超參不用改代碼實(shí)驗(yàn)也好管理。實(shí)驗(yàn)管理我用MLflow或者WandB這類工具每次訓(xùn)練自動(dòng)記錄超參、指標(biāo)、模型文件。這樣回頭對(duì)比實(shí)驗(yàn)的時(shí)候一目了然。別用Excel記實(shí)驗(yàn)記著記著就亂了。訓(xùn)練循環(huán)的關(guān)鍵代碼大概長(zhǎng)這樣for epoch in range(num_epochs): model.train() for batch in train_loader: optimizer.zero_grad() outputs model(batch[input_ids]) loss criterion(outputs, batch[label]) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() # 驗(yàn)證 model.eval() with torch.no_grad(): val_metrics evaluate(model, val_loader) scheduler.step(val_metrics[f1]) # 記錄 mlflow.log_metrics(val_metrics, stepepoch)這里有幾個(gè)細(xì)節(jié)梯度裁剪防止梯度爆炸學(xué)習(xí)率調(diào)度器根據(jù)驗(yàn)證指標(biāo)調(diào)整學(xué)習(xí)率每個(gè)epoch記錄指標(biāo)。這些都是實(shí)戰(zhàn)里總結(jié)出來(lái)的不是可有可無(wú)的。4.4 模型優(yōu)化與導(dǎo)出訓(xùn)練完的模型先做優(yōu)化再導(dǎo)出。以量化為例如import torch.quantization as tq model.eval() model.qconfig tq.get_default_qconfig(fbgemm) model_prepared tq.prepare(model, inplaceFalse) # 用校準(zhǔn)數(shù)據(jù)跑一遍 with torch.no_grad(): for batch in calib_loader: model_prepared(batch[input_ids]) model_quantized tq.convert(model_prepared, inplaceFalse) torch.save(model_quantized.state_dict(), model_quantized.pt)校準(zhǔn)數(shù)據(jù)要用真實(shí)分布的數(shù)據(jù)一般幾百到幾千條就夠。量化完一定要在驗(yàn)證集上重新評(píng)估確認(rèn)精度損失在可接受范圍內(nèi)。如果掉太多考慮換QAT或者放棄量化。導(dǎo)出的時(shí)候除了模型權(quán)重還要把分詞器、配置、版本信息一起打包。我一般打成一個(gè)目錄里面包含model.pt、tokenizer、config.yaml、version.txt。部署的時(shí)候整個(gè)目錄一起加載避免版本不匹配。4.5 推理服務(wù)實(shí)現(xiàn)推理服務(wù)我用FastAPI寫簡(jiǎn)單直接。核心代碼from fastapi import FastAPI from pydantic import BaseModel import torch app FastAPI() model load_model(model_dir) tokenizer load_tokenizer(model_dir) class Request(BaseModel): text: str class Response(BaseModel): label: int confidence: float app.post(/predict, response_modelResponse) async def predict(req: Request): inputs tokenizer(req.text, return_tensorspt, truncationTrue, max_length512) with torch.no_grad(): outputs model(**inputs) probs torch.softmax(outputs.logits, dim-1) label int(torch.argmax(probs, dim-1)) confidence float(torch.max(probs)) return Response(labellabel, confidenceconfidence)這個(gè)服務(wù)能跑但離生產(chǎn)可用還差幾步。第一要加超時(shí)控制用asyncio.wait_for包一層。第二要加限流防止請(qǐng)求打爆。第三要加健康檢查接口方便監(jiān)控。第四要加日志記錄每個(gè)請(qǐng)求的輸入輸出和耗時(shí)。部署的時(shí)候用gunicorn加uvicorn worker多進(jìn)程跑起來(lái)。GPU的話注意每個(gè)進(jìn)程的顯存占用別開(kāi)太多worker把顯存撐爆。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 訓(xùn)練相關(guān)的高頻問(wèn)題問(wèn)題一loss不下降或者變成NaN。排查思路先看數(shù)據(jù)有沒(méi)有異常值、標(biāo)簽有沒(méi)有錯(cuò)。再看學(xué)習(xí)率是不是太大了。然后看梯度有沒(méi)有爆炸。最后看數(shù)值精度FP16訓(xùn)練容易出這個(gè)問(wèn)題試試用FP32或者加loss scaling。問(wèn)題二訓(xùn)練集效果好驗(yàn)證集效果差。典型的過(guò)擬合。解決辦法加正則化、加dropout、減小模型、增加數(shù)據(jù)。還有一個(gè)容易被忽略的原因訓(xùn)練集和驗(yàn)證集的數(shù)據(jù)分布不一致比如驗(yàn)證集里有訓(xùn)練集沒(méi)見(jiàn)過(guò)的類別。這種情況要檢查數(shù)據(jù)劃分邏輯。問(wèn)題三結(jié)果不可復(fù)現(xiàn)。九成是隨機(jī)種子沒(méi)設(shè)全。除了PyTorch的種子還要設(shè)NumPy、Python random、CUDA的種子。另外DataLoader的worker多的時(shí)候每個(gè)worker的種子也要設(shè)。還有如果用了非確定性算子比如某些CUDA操作結(jié)果也會(huì)有微小差異這個(gè)要接受。5.2 部署相關(guān)的高頻問(wèn)題問(wèn)題一線上延遲比離線測(cè)試高很多。常見(jiàn)原因批處理大小不一樣、硬件不一樣、有網(wǎng)絡(luò)開(kāi)銷、有預(yù)處理開(kāi)銷。排查的時(shí)候要分段計(jì)時(shí)看時(shí)間花在哪。我遇到過(guò)一次離線測(cè)試用的是批處理線上是單條推理延遲差了十倍。后來(lái)改成動(dòng)態(tài)批處理延遲降下來(lái)了。問(wèn)題二顯存溢出。推理的時(shí)候顯存溢出一般是批處理太大或者模型太大。解決辦法減小批處理、用量化模型、用梯度檢查點(diǎn)訓(xùn)練時(shí)。還有一個(gè)坑是顯存碎片長(zhǎng)時(shí)間運(yùn)行后顯存碎片化明明有空間卻分配不出來(lái)。解決辦法是定期重啟服務(wù)或者用顯存池管理。問(wèn)題三服務(wù)偶發(fā)崩潰。這種最難查。我的經(jīng)驗(yàn)是加詳細(xì)的日志和監(jiān)控記錄每次崩潰前的輸入、狀態(tài)、資源使用情況。常見(jiàn)原因有內(nèi)存泄漏、并發(fā)競(jìng)爭(zhēng)、依賴庫(kù)的偶發(fā)bug。內(nèi)存泄漏可以用tracemalloc或者memory_profiler查。5.3 問(wèn)題速查表現(xiàn)象可能原因排查方向解決思路loss變NaN學(xué)習(xí)率過(guò)大、數(shù)據(jù)異常、精度問(wèn)題檢查數(shù)據(jù)、降低學(xué)習(xí)率、用FP32加梯度裁剪、數(shù)據(jù)校驗(yàn)驗(yàn)證集效果差過(guò)擬合、數(shù)據(jù)分布不一致對(duì)比訓(xùn)練驗(yàn)證分布加正則、檢查數(shù)據(jù)劃分結(jié)果不可復(fù)現(xiàn)種子沒(méi)設(shè)全、非確定性算子檢查所有隨機(jī)源設(shè)全種子、固定算子線上延遲高批處理差異、預(yù)處理開(kāi)銷分段計(jì)時(shí)動(dòng)態(tài)批處理、優(yōu)化預(yù)處理顯存溢出批處理大、碎片化監(jiān)控顯存使用減小批處理、定期重啟服務(wù)偶發(fā)崩潰內(nèi)存泄漏、并發(fā)問(wèn)題加日志監(jiān)控定位后修復(fù)、加兜底6. 我個(gè)人的一些經(jīng)驗(yàn)和建議做AI工程這幾年最大的體會(huì)是技術(shù)深度重要但工程思維更重要。很多問(wèn)題不是靠某個(gè)高級(jí)算法解決的而是靠合理的架構(gòu)設(shè)計(jì)、完善的監(jiān)控、嚴(yán)謹(jǐn)?shù)牧鞒探鉀Q的。比如數(shù)據(jù)版本控制這件事技術(shù)上沒(méi)什么難度但堅(jiān)持做的人不多?？删褪沁@個(gè)小習(xí)慣能在關(guān)鍵時(shí)刻幫你快速定位問(wèn)題。再比如降級(jí)機(jī)制平時(shí)看起來(lái)是多余的但真出事的時(shí)候它就是業(yè)務(wù)的救命稻草。還有一個(gè)建議是別追求一步到位。我見(jiàn)過(guò)太多團(tuán)隊(duì)一上來(lái)就想搭一個(gè)完美的MLOps平臺(tái)結(jié)果搭了半年還沒(méi)上線。正確的做法是先跑通最小閉環(huán)模型能訓(xùn)、能部署、能監(jiān)控然后再逐步優(yōu)化。先解決有無(wú)再解決好壞。最后說(shuō)個(gè)具體的技巧。做AI工程一定要養(yǎng)成寫文檔和記錄的習(xí)慣。每次踩坑、每次決策都記下來(lái)。不是為了給別人看是為了給三個(gè)月后的自己看。我現(xiàn)在回頭看自己兩年前的項(xiàng)目筆記很多當(dāng)時(shí)覺(jué)得理所當(dāng)然的決策現(xiàn)在都想不起來(lái)為什么那么做了。文檔就是你的第二大腦。這個(gè)領(lǐng)域變化快工具和框架年年更新但底層的工程原則變化很慢。把數(shù)據(jù)管道、訓(xùn)練循環(huán)、部署監(jiān)控這幾塊的基本功練扎實(shí)不管工具怎么變你都能快速上手。反過(guò)來(lái)如果只追新工具不理解原理工具一換你就得重新學(xué)。所以ai-engineering-from-scratch這件事我的建議是從原理入手從最小閉環(huán)做起邊做邊補(bǔ)細(xì)節(jié)。別貪多別求快把每一塊都真正搞懂比什么都重要。