作為從業(yè)者我經(jīng)常被問(wèn)到同一個(gè)問(wèn)題AI到底怎么從零落地不只是跑通一個(gè)開(kāi)源模型而是從環(huán)境、數(shù)據(jù)、訓(xùn)練、部署到維護(hù)走完一個(gè)完整的工程閉環(huán)。這個(gè)叫ai-engineering-from-scratch的項(xiàng)目乍看像一份學(xué)習(xí)清單實(shí)際上它本質(zhì)上是把AI工程實(shí)踐的可復(fù)制路徑完整梳理了一遍。我當(dāng)初看到這個(gè)標(biāo)題就來(lái)了興趣因?yàn)闃I(yè)內(nèi)最缺的恰恰是這種從零到一的系統(tǒng)性拆解而不是東拼西湊的代碼片段。這篇博文我就圍繞這個(gè)主題把我實(shí)際落地AI工程時(shí)積累的思路、步驟和那些坑原原本本寫(xiě)出來(lái)。1. 到底什么是AI工程先搞懂從零開(kāi)始的邊界很多人一說(shuō)AI工程第一反應(yīng)就是訓(xùn)練模型。這個(gè)理解說(shuō)對(duì)了一半但恰恰是最容易誤導(dǎo)人的那一半。真正把AI系統(tǒng)落地到生產(chǎn)環(huán)境的人都知道模型訓(xùn)練在整個(gè)工程鏈路里只占一小塊真正的復(fù)雜度分布在數(shù)據(jù)治理、實(shí)驗(yàn)管理、部署上線、監(jiān)控迭代這些臟活累活上。我在接觸ai-engineering-from-scratch這類(lèi)實(shí)踐項(xiàng)目時(shí)最深的一點(diǎn)體會(huì)就是從零開(kāi)始指的絕不是從零寫(xiě)網(wǎng)絡(luò)結(jié)構(gòu)而是從零搭建一條能持續(xù)產(chǎn)出、評(píng)估、交付模型的能力流水線。1.1 別把AI工程等同于訓(xùn)練模型AI工程是一個(gè)系統(tǒng)邊界極其模糊的領(lǐng)域它的核心難點(diǎn)在于橫跨了軟件工程、數(shù)據(jù)工程、MLOps和業(yè)務(wù)邏輯四塊知識(shí)體系。我見(jiàn)過(guò)不少團(tuán)隊(duì)模型在Notebook里跑得很漂亮一上生產(chǎn)就崩原因不是模型本身問(wèn)題而是周?chē)墓こ棠_手架沒(méi)搭起來(lái)。舉個(gè)例子你在Jupyter里做完數(shù)據(jù)清洗下一步要進(jìn)入模型訓(xùn)練是不是經(jīng)常發(fā)現(xiàn)環(huán)境依賴(lài)沖突今天裝了這個(gè)庫(kù)明天更新了那個(gè)庫(kù)結(jié)果半年后復(fù)現(xiàn)不了實(shí)驗(yàn)。這不是你技術(shù)不行而是缺少工程化的約束。AI工程里環(huán)境一致性、數(shù)據(jù)版本化、實(shí)驗(yàn)可復(fù)現(xiàn)這三件事優(yōu)先級(jí)永遠(yuǎn)排在模型結(jié)構(gòu)之上。解決不了這三個(gè)問(wèn)題即使你把Loss調(diào)得再低交付的時(shí)候一樣寸步難行。1.2 這套工程棧的整體架構(gòu)長(zhǎng)什么樣我自己落地AI項(xiàng)目時(shí)習(xí)慣把整條鏈路拆成六個(gè)環(huán)節(jié)基礎(chǔ)設(shè)施、數(shù)據(jù)、訓(xùn)練、評(píng)估、部署、監(jiān)控。它們的關(guān)系不是線性的而是循環(huán)迭代?；A(chǔ)設(shè)施環(huán)境管理、依賴(lài)鎖定、容器化封裝數(shù)據(jù)層采集、清洗、標(biāo)注、特征工程、版本管理訓(xùn)練層基線模型、超參調(diào)優(yōu)、實(shí)驗(yàn)追蹤評(píng)估層離線指標(biāo)、線上反饋、人工評(píng)測(cè)部署層推理服務(wù)、網(wǎng)關(guān)路由、資源調(diào)度監(jiān)控層數(shù)據(jù)漂移、效果衰退、自動(dòng)告警我說(shuō)過(guò)很多次的一句話(huà)是模型只占20%剩下的80%全是工程。這80%恰恰就是ai-engineering-from-scratch這個(gè)主題想要表達(dá)的核心價(jià)值——把隱性知識(shí)顯性化把零散的實(shí)踐變成系統(tǒng)路徑。不管你是做NLP、CV還是推薦系統(tǒng)外層任務(wù)會(huì)變底層骨架幾乎是一樣的。2. 環(huán)境準(zhǔn)備與基礎(chǔ)設(shè)施先把地基打牢環(huán)境問(wèn)題是我見(jiàn)過(guò)勸退新手最多的一個(gè)環(huán)節(jié)。同樣是Python版本不同行為就不一樣同樣是PyTorchCUDA版本不對(duì)直接報(bào)錯(cuò)。這些跟模型能力無(wú)關(guān)的問(wèn)題耗費(fèi)的精力往往比調(diào)參還多。所以從零開(kāi)始搞AI工程第一課不是Transformer而是怎么把環(huán)境管明白。2.1 Python環(huán)境與依賴(lài)管理我先說(shuō)Python版本。不要用系統(tǒng)自帶的Python更不要直接在全局環(huán)境里pip install這是新手最容易踩的坑。我建議直接用uv或者poetry這類(lèi)工具來(lái)管理虛擬環(huán)境原因有三個(gè)環(huán)境隔離不同項(xiàng)目互不干擾依賴(lài)鎖定避免在我機(jī)器上是好的這類(lèi)問(wèn)題安裝速度快尤其是uv比pip快一個(gè)量級(jí)拿我自己常用的配置舉例。假設(shè)今天要新建一個(gè)項(xiàng)目我一般會(huì)做這么幾件事uv venv .venv --python 3.10 source .venv/bin/activate uv add torch --index-url https://download.pytorch.org/whl/cu118 uv add transformers datasets evaluate fastapi uvicorn這段配置里有幾個(gè)細(xì)節(jié)值得說(shuō)。第一Python我固定用3.10不是越新越好很多深度學(xué)習(xí)庫(kù)對(duì)3.11、3.12的兼容性在當(dāng)時(shí)還不穩(wěn)定第二PyTorch要單獨(dú)指定CUDA版本的index否則默認(rèn)裝的是CPU版本你根本用不了GPU第三把FastAPI和uvicorn提前加進(jìn)來(lái)是提醒你自己模型最終是要部署的別等訓(xùn)練完了再手忙腳亂補(bǔ)服務(wù)。環(huán)境的復(fù)現(xiàn)性還體現(xiàn)在依賴(lài)鎖定上。poetry和uv都會(huì)生成一個(gè)lock文件團(tuán)隊(duì)協(xié)作時(shí)大家用同一個(gè)lock文件構(gòu)建出來(lái)的環(huán)境是一致的。我見(jiàn)過(guò)太多因?yàn)閞equirements.txt里寫(xiě)的是范圍版本比如numpy1.21而導(dǎo)致的依賴(lài)沖突最后排查到崩潰。用鎖文件一次解決。2.2 用Docker封裝可復(fù)現(xiàn)的實(shí)驗(yàn)環(huán)境虛擬環(huán)境解決了單機(jī)上的隔離問(wèn)題但換一臺(tái)機(jī)器、換一個(gè)云服務(wù)器環(huán)境還是可能不一致。這時(shí)候就得上Docker。我在中后期項(xiàng)目的每一個(gè)實(shí)驗(yàn)都會(huì)打一個(gè)鏡像好處是顯而易見(jiàn)的換機(jī)器、換GPU、換機(jī)房鏡像拉下來(lái)就能跑不會(huì)出現(xiàn)A機(jī)器能跑B機(jī)器跑不了的事。一個(gè)典型的AI訓(xùn)練鏡像我的Dockerfile大致長(zhǎng)這樣FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /workspace COPY requirements-lock.txt . RUN pip install --no-cache-dir -r requirements-lock.txt COPY src/ ./src/ COPY configs/ ./configs/ ENV PYTHONPATH/workspace ENV NVIDIA_VISIBLE_DEVICESall CMD [python, src/train.py, --config, configs/baseline.yaml]這里有一個(gè)我踩過(guò)很多次的坑默認(rèn)的pytorch/pytorch鏡像不是完整的跑訓(xùn)練環(huán)境很多常用庫(kù)比如scikit-learn、pandas、tensorboard都不在里面必須在裝完基礎(chǔ)鏡像后重新補(bǔ)裝。所以我會(huì)單獨(dú)維護(hù)一個(gè)requirements-lock.tx我們文件平時(shí)開(kāi)發(fā)環(huán)境和訓(xùn)練鏡像都用它確保兩個(gè)環(huán)境高度一致。GPU的容器化還有一步要特別注意宿主機(jī)上必須安裝好NVIDIA Container Toolkit并且在docker run的時(shí)候帶上--gpus參數(shù)否則容器內(nèi)根本訪問(wèn)不到GPU。我曾經(jīng)因?yàn)橥搜btoolkit在容器里用了CPU訓(xùn)練一個(gè)三個(gè)小時(shí)才能跑完的實(shí)驗(yàn)浪費(fèi)了整整一個(gè)下午。這種低級(jí)失誤經(jīng)歷一次就長(zhǎng)記性了。3. 數(shù)據(jù)工程模型的糧食決定天花板模型再?gòu)?qiáng)也是吃數(shù)據(jù)長(zhǎng)大的。我一直覺(jué)得數(shù)據(jù)質(zhì)量差的場(chǎng)景里你用再大的模型也白搭數(shù)據(jù)質(zhì)量到位一個(gè)相對(duì)小的模型就能出很好的效果。ai-engineering-from-scratch這種項(xiàng)目如果沒(méi)有單獨(dú)強(qiáng)調(diào)數(shù)據(jù)工程那一定是不完整的。3.1 數(shù)據(jù)收集與清洗流程數(shù)據(jù)清洗不是簡(jiǎn)單drop掉空值。不同任務(wù)、不同模態(tài)的數(shù)據(jù)臟數(shù)據(jù)的表現(xiàn)完全不一樣。比方說(shuō)做文本分類(lèi)你要處理的可能是爬蟲(chóng)抓下來(lái)的網(wǎng)頁(yè)正文里面混著導(dǎo)航欄、版權(quán)聲明、各種廣告文本做圖像任務(wù)要處理的是標(biāo)注錯(cuò)位的框、模糊過(guò)曝的圖、重復(fù)樣本。我總結(jié)了一套比較通用的清洗流程基本能覆蓋90%的場(chǎng)景def clean_text(text: str) - str: # 1. 去掉HTML標(biāo)簽和亂碼 text re.sub(r[^], , text) # 2. 壓縮連續(xù)空白 text re.sub(r\s, , text).strip() # 3. 去掉過(guò)長(zhǎng)無(wú)意義的重復(fù)內(nèi)容 if len(text) 10 or text.count(text[:20]) 5: return # 4. 去除非目標(biāo)語(yǔ)言字符按需調(diào) text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9?！丁贰尽?、\s], , text) return text這個(gè)簡(jiǎn)單的清洗函數(shù)解決了我好幾個(gè)項(xiàng)目里的共性問(wèn)題。值得注意的是不同任務(wù)的清洗強(qiáng)度完全不同。做對(duì)話(huà)系統(tǒng)的數(shù)據(jù)你要保留口語(yǔ)化特征不能把嗯嗯這種詞全刪掉做輿情分析表情符號(hào)可能本身是重要信號(hào)。所以清洗不是一勞永逸的事每個(gè)項(xiàng)目都需要單獨(dú)審視。3.2 特征工程與數(shù)據(jù)增強(qiáng)傳統(tǒng)機(jī)器學(xué)習(xí)時(shí)代特征工程是決定模型上限的關(guān)鍵深度學(xué)習(xí)以后很多人覺(jué)得特征工程沒(méi)用了這是另一個(gè)誤區(qū)。經(jīng)驗(yàn)告訴我特征層面的先驗(yàn)知識(shí)依然是效率最高的信息注入方式。比如做時(shí)間序列預(yù)測(cè)你把星期幾、是否節(jié)假日、過(guò)去一周均值這些特征拼進(jìn)去模型立刻就從魔怔擬合變得有業(yè)務(wù)sense了。數(shù)據(jù)增強(qiáng)這塊文本和圖像的路數(shù)完全不一樣。圖像可以用flip、rotation、cutout文本這邊常用的是回譯、同義詞替換、對(duì)抗噪聲注入。拿回譯舉例中文翻譯成英文再翻譯回中文表達(dá)方式就會(huì)發(fā)生變化數(shù)據(jù)量一下子就多了。但要小心一點(diǎn)回譯對(duì)口語(yǔ)化數(shù)據(jù)比較友好對(duì)專(zhuān)業(yè)術(shù)語(yǔ)多的數(shù)據(jù)效果很差術(shù)語(yǔ)可能被改得面目全非。3.3 數(shù)據(jù)版本管理全文我特別想強(qiáng)調(diào)的一點(diǎn)就是數(shù)據(jù)版本管理。代碼有Git管實(shí)驗(yàn)有MLflow管數(shù)據(jù)要是沒(méi)有版本管理整個(gè)流水線的可復(fù)現(xiàn)性就是空談。很多團(tuán)隊(duì)數(shù)據(jù)集都是放在服務(wù)器某個(gè)文件夾里誰(shuí)都不許動(dòng)這其實(shí)是很原始的方案。我自己用DVCData Version Control來(lái)管數(shù)據(jù)集思路和Git一致但它是針對(duì)大文件設(shè)計(jì)的底層存儲(chǔ)可以對(duì)接S3、OSS、NAS這些地方。一個(gè)典型的流程是dvc init dvc remote add -d myremote s3://mybucket/dvc-store dvc add data/raw dvc push這樣每個(gè)實(shí)驗(yàn)、每次訓(xùn)練用的數(shù)據(jù)是哪個(gè)版本都能在DVC的記錄里追溯到。之前出過(guò)一件事某團(tuán)隊(duì)訓(xùn)練數(shù)據(jù)被人手動(dòng)替換了幾個(gè)文件模型效果莫名下降但沒(méi)人敢確定是哪天被改的。用DVC之后再也不會(huì)出現(xiàn)這種憑感覺(jué)猜版本的問(wèn)題。4. 模型訓(xùn)練與迭代從基線到可用數(shù)據(jù)和環(huán)境都準(zhǔn)備好了才輪到真正的模型訓(xùn)練環(huán)節(jié)。這個(gè)環(huán)節(jié)我聊的不是某個(gè)網(wǎng)絡(luò)結(jié)構(gòu)有多精妙而是圍繞訓(xùn)練這件事本身的工程化操作怎么把實(shí)驗(yàn)管起來(lái)怎么從一團(tuán)亂麻里找到有效的方向。4.1 選型策略選模型這件事我的建議是梯度式起步不要一開(kāi)始就上最復(fù)雜的結(jié)構(gòu)。想做文本分類(lèi)先跑個(gè)簡(jiǎn)單的FastText或者TextCNN想做目標(biāo)檢測(cè)先用現(xiàn)成的YOLO預(yù)訓(xùn)練模型做遷移。用我自己的話(huà)說(shuō)就是先用笨辦法把數(shù)據(jù)管線和評(píng)估流程跑通再逐步升級(jí)模型結(jié)構(gòu)檢驗(yàn)天花板到底在哪。這種策略的好處太多了。一方面簡(jiǎn)單模型的調(diào)試成本低出問(wèn)題容易排查適合磨合數(shù)據(jù)管線另一方面它給你提供了一個(gè)扎實(shí)的基線后面換復(fù)雜模型時(shí)提升幅度是不是真的有用一眼就能對(duì)比出來(lái)。反過(guò)來(lái)一上來(lái)就跑大模型數(shù)據(jù)有小毛病你根本發(fā)現(xiàn)不了最后還會(huì)誤以為是模型不行。4.2 訓(xùn)練參數(shù)與實(shí)驗(yàn)追蹤訓(xùn)練參數(shù)這塊我最常被問(wèn)到一個(gè)問(wèn)題學(xué)習(xí)率到底設(shè)多少合適我的回答是先看訓(xùn)練曲線再說(shuō)。業(yè)界通用的做法是用學(xué)習(xí)率預(yù)熱加余弦退火初始值盡量偏小比如1e-5到1e-4這個(gè)區(qū)間起步讓模型穩(wěn)定訓(xùn)練幾個(gè)epoch之后再根據(jù)loss曲線調(diào)整。一個(gè)標(biāo)準(zhǔn)的訓(xùn)練步長(zhǎng)配置我長(zhǎng)期用下面這套o(hù)ptimizer: adamw learning_rate: 3e-5 warmup_ratio: 0.1 weight_decay: 0.01 batch_size: 32 gradient_accumulation_steps: 4 max_epochs: 5batch_size和gradient_accumulation_steps這兩個(gè)參數(shù)要連起來(lái)看。如果你的GPU顯存不夠一個(gè)batch只能塞8條數(shù)據(jù)那就通過(guò)梯度累積模擬更大的batch效果上接近32條真實(shí)數(shù)據(jù)但代價(jià)是訓(xùn)練時(shí)間會(huì)增加。這套東西的工程本質(zhì)就是用時(shí)間換顯存在資源受限的情況下把實(shí)驗(yàn)跑起來(lái)。實(shí)驗(yàn)追蹤方面我不用手寫(xiě)日志文件而是直接上MLflow或者WandB。每一步迭代的loss、評(píng)測(cè)指標(biāo)、超參數(shù)、模型產(chǎn)物都能自動(dòng)記錄后面要做橫向?qū)Ρ纫粋€(gè)頁(yè)面就全看完了。有人覺(jué)得記錄這些是浪費(fèi)時(shí)間真到月底寫(xiě)報(bào)告或者復(fù)現(xiàn)舊模型的時(shí)候你就知道一個(gè)規(guī)范化的實(shí)驗(yàn)記錄能救多少命。4.3 評(píng)估與調(diào)優(yōu)閉環(huán)離線指標(biāo)不能光看單一值。分類(lèi)任務(wù)不能只看Accuracy樣本不均衡的時(shí)候Accuracy會(huì)騙人要同時(shí)看Precision、Recall和F1。我建議你在訓(xùn)練腳本里就把這些指標(biāo)全部計(jì)算出來(lái)用一個(gè)統(tǒng)一的評(píng)估函數(shù)輸出而不是等訓(xùn)練結(jié)束再臨時(shí)寫(xiě)腳本算。評(píng)估之后是調(diào)優(yōu)循環(huán)這里的關(guān)鍵在于每次只改一個(gè)變量。我先固定數(shù)據(jù)、模型結(jié)構(gòu)只動(dòng)學(xué)習(xí)率和訓(xùn)練輪次有了相對(duì)好的結(jié)果再微調(diào)Batch size和權(quán)重衰減。一次動(dòng)兩個(gè)以上的變量出了問(wèn)題你根本不知道是哪個(gè)參數(shù)導(dǎo)致的。調(diào)優(yōu)過(guò)程中還要建立一套什么時(shí)候停的機(jī)制。我最常用的策略是Early Stopping監(jiān)控驗(yàn)證集loss連續(xù)三個(gè)epoch不降就提前終止訓(xùn)練省時(shí)間也省算力。但有一點(diǎn)要注意早停的判定指標(biāo)要和最終目標(biāo)一致比如你做推薦系統(tǒng)最終看線上點(diǎn)擊率那就不要只看loss要結(jié)合驗(yàn)證集的業(yè)務(wù)指標(biāo)來(lái)定。5. 部署上線與服務(wù)化讓模型真正跑起來(lái)模型訓(xùn)練得再好不部署上線就是紙上談兵。這一節(jié)應(yīng)該是ai-engineering-from-scratch里最有工程味的一部分也是我踩坑最多、收獲最大的環(huán)節(jié)。5.1 用FastAPI封裝推理服務(wù)模型部署最常見(jiàn)的形態(tài)是HTTP推理服務(wù)。我用FastAPI做過(guò)好幾個(gè)生產(chǎn)級(jí)的服務(wù)穩(wěn)定性和性能都很對(duì)得起它的口碑。一個(gè)標(biāo)準(zhǔn)的推理服務(wù)我通常分成這樣幾層from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class InferenceRequest(BaseModel): texts: list[str] class InferenceResponse(BaseModel): predictions: list[str] model None app.on_event(startup) def load_model(): global model model load_model_from_disk(models/best_model.pt) app.post(/predict, response_modelInferenceResponse) def predict(req: InferenceRequest): try: preds model.predict(req.texts) return InferenceResponse(predictionspreds) except Exception as e: raise HTTPException(status_code500, detailstr(e))這個(gè)代碼看起來(lái)簡(jiǎn)單但里面有一個(gè)很多新手忽略的細(xì)節(jié)模型加載必須在startup階段完成不能在請(qǐng)求函數(shù)里加載。不然第一個(gè)請(qǐng)求進(jìn)來(lái)卡個(gè)幾十秒后面每個(gè)請(qǐng)求還得搶模型加載的鎖整個(gè)服務(wù)直接癱瘓。服務(wù)上線之后還要考慮并行和批量推理。GPU推理和CPU推理的資源模型完全不一樣CPU適合低并發(fā)、低延遲的請(qǐng)求GPU適合高吞吐、大批量的場(chǎng)景。我一般會(huì)設(shè)置一個(gè)max_batch_size參數(shù)把請(qǐng)求攢夠一定數(shù)量再一次性進(jìn)模型推理吞吐量能提升好幾倍。5.2 性能優(yōu)化與監(jiān)控部署層面的優(yōu)化手段有很多。首先是最簡(jiǎn)單也最剛需的把推理過(guò)程轉(zhuǎn)成TensorRT或者ONNX格式。不要小看這一步我遇到過(guò)FP16量化后速度和精度雙豐收的情況。轉(zhuǎn)換的時(shí)候要仔細(xì)檢查算子的兼容性不是所有PyTorch算子都能轉(zhuǎn)成功。然后要加緩存。對(duì)于文本分類(lèi)這類(lèi)高頻重復(fù)的請(qǐng)求用Redis做一層精確匹配的緩存命中率如果達(dá)到30%整體QPS壓力能下降不少。我習(xí)慣在業(yè)務(wù)層面的分類(lèi)模型前加一個(gè)文本哈希緩存成本極低收益肉眼可見(jiàn)。監(jiān)控是最后一個(gè)維度。除了常規(guī)的CPU、內(nèi)存、GPU顯存監(jiān)控還要特別關(guān)注數(shù)據(jù)漂移的問(wèn)題。線上請(qǐng)求的文本長(zhǎng)度分布、關(guān)鍵詞分布如果和訓(xùn)練集差異過(guò)大模型表現(xiàn)一定會(huì)衰退。我給線上服務(wù)專(zhuān)門(mén)配了一個(gè)特征分布日志每天自動(dòng)算一遍KL散度一旦超過(guò)閾值就觸發(fā)告警。這個(gè)機(jī)制為我至少提前暴露過(guò)三次模型效果下滑的風(fēng)險(xiǎn)。6. 常見(jiàn)問(wèn)題排查實(shí)錄最后這部分我把實(shí)操中反復(fù)踩過(guò)的坑匯總一下做成一份問(wèn)題速查表方便遇到問(wèn)題時(shí)直接對(duì)照參考。很多問(wèn)題看起來(lái)稀奇古怪但背后的原因其實(shí)就那么幾類(lèi)。6.1 高頻問(wèn)題速查表問(wèn)題現(xiàn)象大概率原因解決辦法跑模型時(shí)CUDA out of memoryGPU顯存不足減小batch_size或增加gradient_accumulation_steps本地正常、容器里報(bào)缺庫(kù)環(huán)境不一致統(tǒng)一用鎖定依賴(lài)的鏡像不用裸pip安裝不同GPU上結(jié)果不一致CUDA版本或cuDNN不一致固定鏡像和CUDA版本使用確定性算法數(shù)據(jù)加載慢GPU利用率低DataLoader并行度不足調(diào)大num_workers開(kāi)啟pin_memory模型線上效果比離線差太多數(shù)據(jù)漂移或特征不一致對(duì)比線上特征分布與訓(xùn)練集分布加漂移告警Early Stopping過(guò)早停止驗(yàn)證集loss波動(dòng)大增大patience或改用EMA平滑后的指標(biāo)FastAPI并發(fā)請(qǐng)求速度下降明顯模型加載邏輯錯(cuò)誤或沒(méi)有批量推理把模型加載移到startup加批量推理邏輯模型推理延遲高算子沒(méi)有優(yōu)化轉(zhuǎn)ONNX或TensorRT開(kāi)啟FP166.2 排查思路與快捷命令遇到問(wèn)題不要慌先確定在哪個(gè)環(huán)節(jié)出了問(wèn)題。我有一套固定的排查順序數(shù)據(jù)環(huán)節(jié)、環(huán)境環(huán)節(jié)、代碼環(huán)節(jié)、資源環(huán)節(jié)。先用最簡(jiǎn)單的方式排除資源瓶頸再看環(huán)境一致性最后才懷疑模型結(jié)構(gòu)。幾個(gè)我常用的排查命令# 檢查GPU是否正常工作 nvidia-smi # 檢查容器內(nèi)能否訪問(wèn)GPU docker run --gpus all nvidia/cuda:11.8-base nvidia-smi # 檢查Python依賴(lài)的版本沖突 pip check # 查看訓(xùn)練日志里有沒(méi)有隱式錯(cuò)誤 tail -f nohup.out | grep ERROR一個(gè)特別想分享的技巧訓(xùn)練中遇到loss變成NaN別急著調(diào)學(xué)習(xí)率先看數(shù)據(jù)里有沒(méi)有NaN值或者無(wú)窮大值。我在金融數(shù)據(jù)處理時(shí)遇到過(guò)一位同事數(shù)據(jù)里有幾個(gè)無(wú)窮大的樣本整個(gè)embedding層直接崩了查了兩天才定位到原因就是數(shù)據(jù)處理階段少了一個(gè)clip操作。先查數(shù)據(jù)再查代碼最后查超參這個(gè)順序能幫你節(jié)省大量時(shí)間。關(guān)于早期的實(shí)踐我最后多說(shuō)一句從零開(kāi)始做AI工程不要迷信大模型和復(fù)雜結(jié)構(gòu)先扎扎實(shí)實(shí)把數(shù)據(jù)、環(huán)境、評(píng)估、部署這條鏈路走通一遍哪怕做的是一個(gè)很簡(jiǎn)單的任務(wù)。鏈條通了的價(jià)值遠(yuǎn)大于某個(gè)模型刷到一個(gè)漂亮分?jǐn)?shù)。我自己回頭看最痛苦、成長(zhǎng)最快的階段正是當(dāng)時(shí)把這條鏈路從無(wú)到有搭起來(lái)的那段日子。希望這篇基于ai-engineering-from-scratch的梳理能幫你少走一些我走過(guò)的彎路。