境搭建到模型部署的完整指南)
1. 別急著寫代碼想清楚從零開始到底意味著什么我見(jiàn)過(guò)太多人栽在這一步。打開GitHub看到一個(gè)叫ai-engineering-from-scratch的倉(cāng)庫(kù)熱血上頭克隆下來(lái)就開始跑訓(xùn)練腳本結(jié)果卡在環(huán)境依賴上折騰了一整天最后連數(shù)據(jù)集長(zhǎng)什么樣都沒(méi)看清楚。這幾乎是每個(gè)剛接觸AI工程的初學(xué)者都會(huì)踩的坑——拿到了倉(cāng)庫(kù)地址卻不知道自己究竟要在這個(gè)工程里做什么。先把這個(gè)概念拆開AI工程不是寫模型而是用工程化的方法把模型變成可持續(xù)運(yùn)行、可維護(hù)、可迭代的系統(tǒng)。一個(gè)合格的AI工程至少包含四件套數(shù)據(jù)管線、訓(xùn)練實(shí)驗(yàn)、部署服務(wù)、監(jiān)控運(yùn)維。絕大多數(shù)初學(xué)者只盯著訓(xùn)練這一環(huán)然后被環(huán)境配置、數(shù)據(jù)清洗、模型存儲(chǔ)、接口封裝這些問(wèn)題反復(fù)摩擦。所以如果你想認(rèn)真做ai-engineering-from-scratch這個(gè)項(xiàng)目我建議你第一步不是看代碼而是畫一張圖把下面這幾件事理清楚這個(gè)工程要解決什么問(wèn)題分類、生成、還是檢索數(shù)據(jù)的來(lái)源是什么原始格式長(zhǎng)什么樣需要哪些預(yù)處理步驟模型選多大、選什么架構(gòu)訓(xùn)練需要什么樣的GPU資源和顯存訓(xùn)練完成后怎么提供服務(wù)需要多高的并發(fā)和延遲要求模型漂移了怎么辦人工反饋的通道在哪里只有把這些想明白了你才知道倉(cāng)庫(kù)里哪些代碼是核心、哪些是輔助、哪些可以直接跳過(guò)不用管。從零開始做AI工程本質(zhì)上是從業(yè)務(wù)問(wèn)題開始倒推技術(shù)方案而不是從代碼開始正推能跑起來(lái)什么。2. 環(huán)境搭建的坑遠(yuǎn)比你想的多得多2.1 Python環(huán)境從Virtualenv到Conda的取舍在正式開始跑任何AI項(xiàng)目之前環(huán)境是第一道關(guān)卡。你可能會(huì)覺(jué)得用pip install裝幾個(gè)包有什么難的但真到了深度學(xué)習(xí)項(xiàng)目里坑馬上就會(huì)冒出來(lái)CUDA版本對(duì)不上、PyTorch和TensorFlow沖突、Python 3.10某庫(kù)不兼容、protobuf版本互相打架……我甚至見(jiàn)過(guò)有人在Mac上用pip install tensorflow裝上之后發(fā)現(xiàn)只能跑CPU還以為是代碼寫錯(cuò)了。我的建議是如果你不是只做純Python的原型驗(yàn)證直接用Conda。不光是虛擬環(huán)境隔離更重要的是它能同時(shí)管理Python版本和CUDA依賴尤其是你用NVIDIA GPU做深度學(xué)習(xí)訓(xùn)練的時(shí)候。Conda環(huán)境可以做到每個(gè)項(xiàng)目一套獨(dú)立體系互不污染。用conda create -n ai-eng python3.10創(chuàng)建環(huán)境然后按需安裝PyTorch或TensorFlow對(duì)應(yīng)的CUDA版本踩坑概率驟降。2.2 GPU驅(qū)動(dòng)與CUDA版本的匹配邏輯這是整個(gè)環(huán)境搭建過(guò)程中最容易讓人崩潰的一段。很多人照著網(wǎng)上的教程裝了CUDA結(jié)果torch.cuda.is_available()返回False怎么排查都找不到問(wèn)題。核心原因通常是裝了新的CUDA Toolkit但顯卡驅(qū)動(dòng)太老或者驅(qū)動(dòng)版本支持的最高CUDA版本低于你安裝的版本。這里有一個(gè)基本匹配邏輯顯卡驅(qū)動(dòng)是底層CUDA Toolkit是上層上層不能超過(guò)下層的上限。用nvidia-smi查看驅(qū)動(dòng)支持的CUDA版本然后裝一個(gè)不高于這個(gè)上限的CUDA版本再用pip裝對(duì)應(yīng)編譯好的PyTorch版本基本就不會(huì)出錯(cuò)。另外我強(qiáng)烈建議在項(xiàng)目根目錄寫一個(gè)environment.yml或者至少寫清楚依賴列表版本。不做版本鎖定的AI工程等于給自己埋雷——三個(gè)月后你打開之前的項(xiàng)目發(fā)現(xiàn)依賴全變了代碼跑不起來(lái)了那種痛苦相信很多人都有體會(huì)。2.3 Docker從能跑到可復(fù)現(xiàn)的關(guān)鍵一步到了真的要把項(xiàng)目給別人復(fù)現(xiàn)、或者部署到服務(wù)器上的時(shí)候Docker絕對(duì)繞不開。如果你只是在自己電腦上調(diào)代碼Conda就夠用但只要涉及團(tuán)隊(duì)協(xié)作、服務(wù)器部署、或者你想讓這個(gè)從零開始的項(xiàng)目具備工程化的底子一定要一開始就把Dockerfile寫好。FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, train.py]這份Dockerfile雖然簡(jiǎn)單但它體現(xiàn)了工程化最基本的要求環(huán)境可重復(fù)構(gòu)建。在寫Dockerfile時(shí)有幾個(gè)細(xì)節(jié)需要注意盡量選擇官方發(fā)布的帶CUDA的鏡像作為基礎(chǔ)避免重復(fù)裝驅(qū)動(dòng)和CUDA的煩惱把requirements.txt放在源碼之前單獨(dú)COPY這樣能充分利用Docker緩存后續(xù)改代碼不會(huì)重新安裝依賴構(gòu)建速度快好幾倍。注意國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下拉取Docker鏡像和pip依賴都可能遇到連接問(wèn)題建議提前配置好鏡像源。這不是小問(wèn)題很多人的AI工程就是從下載依賴失敗這一步開始放棄的。3. 數(shù)據(jù)管線的優(yōu)先級(jí)沒(méi)數(shù)據(jù)模型就是花架子3.1 先解決數(shù)據(jù)從哪來(lái)再到數(shù)據(jù)怎么喂很多從零開始的AI工程卡住的核心往往不是模型太復(fù)雜而是根本沒(méi)有高質(zhì)量數(shù)據(jù)。很多人習(xí)慣先寫好訓(xùn)練代碼然后才去找數(shù)據(jù)集最后發(fā)現(xiàn)格式對(duì)不上、標(biāo)簽質(zhì)量差、數(shù)量不夠又回頭改代碼浪費(fèi)大量時(shí)間。我的建議是數(shù)據(jù)先行。不管你是爬公開數(shù)據(jù)集、從業(yè)務(wù)系統(tǒng)導(dǎo)出還是自己設(shè)計(jì)標(biāo)注方案一定要在寫模型代碼前先把數(shù)據(jù)流程跑通原始數(shù)據(jù) → 清洗 → 預(yù)處理 → 切分訓(xùn)練/驗(yàn)證/測(cè)試集 → 構(gòu)建DataLoader。這一步走完了后續(xù)訓(xùn)練模型時(shí)就會(huì)非常順暢。3.2 數(shù)據(jù)清洗的常規(guī)操作清單數(shù)據(jù)清洗聽(tīng)起來(lái)不酷但它是決定模型效果上限的隱形要素。我總結(jié)了一套常規(guī)操作你在項(xiàng)目里直接照著做就可以去重。文本數(shù)據(jù)要處理完全重復(fù)的樣本圖像數(shù)據(jù)檢查完全相同的圖片這一步看似簡(jiǎn)單但能有效防止驗(yàn)證集數(shù)據(jù)泄漏讓模型效果虛高。處理缺失值。圖像中缺樣本可以直接丟棄文本中缺標(biāo)簽可以考慮規(guī)則補(bǔ)全表格數(shù)據(jù)則可以填充均值或眾數(shù)具體策略取決于業(yè)務(wù)場(chǎng)景。標(biāo)準(zhǔn)化/歸一化。文本轉(zhuǎn)小寫、去除停用詞圖像做灰度歸一化數(shù)值特征縮放到0到1區(qū)間。不同模型對(duì)此敏感度差異很大但標(biāo)準(zhǔn)做法一定不會(huì)錯(cuò)。標(biāo)簽分布檢查。做一個(gè)簡(jiǎn)單的統(tǒng)計(jì)直方圖看類別是否極度不均衡。如果發(fā)生嚴(yán)重不均衡在訓(xùn)練前就想好要不要做重采樣否則后面模型會(huì)被多數(shù)類帶跑偏。這些步驟不需要都用上重武器很多情況下其實(shí)就是幾行Python的事。比如用pandas做標(biāo)簽分布檢查import pandas as pd df pd.read_csv(data/labels.csv) value_counts df[label].value_counts() print(value_counts) # 輸出類別分布比例判斷是否需要重采樣 class_ratios value_counts / len(df) print(class_ratios)3.3 數(shù)據(jù)集切分容易被忽視的三個(gè)細(xì)節(jié)切訓(xùn)練集、驗(yàn)證集、測(cè)試集人人都知道8:1:1但實(shí)際操作里有三個(gè)細(xì)節(jié)特別容易被忽略。第一類別比例要保持。如果原始數(shù)據(jù)集里A類占80%、B類占20%那你切出來(lái)的訓(xùn)練集也保持這個(gè)比例不能切完發(fā)現(xiàn)訓(xùn)練集里全是A類。用sklearn的train_test_split時(shí)別忘設(shè)置stratifydf[label]這個(gè)參數(shù)。第二驗(yàn)證集和測(cè)試集必須保持未來(lái)感。如果數(shù)據(jù)帶時(shí)間順序比如新聞文本、交易記錄一定要按時(shí)間切分不能隨機(jī)打亂否則就是讓模型用未來(lái)的信息預(yù)測(cè)過(guò)去你得到的是一個(gè)看起來(lái)95%準(zhǔn)確率但在真實(shí)場(chǎng)景下崩得一塌糊涂的模型。第三切分完固定下來(lái)。把切分后的索引存成文件或者設(shè)置固定隨機(jī)種子保證每次復(fù)現(xiàn)時(shí)訓(xùn)練集、驗(yàn)證集完全一致。沒(méi)有這一步你的實(shí)驗(yàn)對(duì)比就沒(méi)有公平性可言——每次訓(xùn)練的數(shù)據(jù)都不一樣你根本無(wú)法判斷模型效果提升是因?yàn)楦倪M(jìn)了模型還是因?yàn)閾Q了一批訓(xùn)練數(shù)據(jù)。4. 訓(xùn)練實(shí)驗(yàn)管理你以為的跑通只是萬(wàn)里長(zhǎng)征第一步4.1 實(shí)驗(yàn)記錄為什么比代碼本身更值錢到了訓(xùn)練階段一個(gè)典型的錯(cuò)誤是改一改參數(shù)跑一遍訓(xùn)練看一眼loss下降沒(méi)有然后繼續(xù)改——沒(méi)有任何記錄。跑了幾十次實(shí)驗(yàn)后看到結(jié)果最好的是第三天的某一次但你完全記不清當(dāng)時(shí)用了什么參數(shù)、什么數(shù)據(jù)版本、什么隨機(jī)種子。AI工程和寫普通軟件最大的區(qū)別就在于它的行為是概率性的實(shí)驗(yàn)的復(fù)現(xiàn)和追蹤極其重要。如果你從零開始做工程化我建議在第一天就把下面這些東西記錄下來(lái)模型結(jié)構(gòu)的具體配置隱藏層維度、層數(shù)、激活函數(shù)、dropout率訓(xùn)練超參數(shù)學(xué)習(xí)率、batch size、epoch數(shù)、優(yōu)化器及參數(shù)數(shù)據(jù)版本用哪份清洗后的數(shù)據(jù)、預(yù)處理腳本的版本訓(xùn)練環(huán)境PyTorch版本、CUDA版本、GPU型號(hào)隨機(jī)種子固定種子保證可復(fù)現(xiàn)關(guān)鍵指標(biāo)train loss、val loss、accuracy、F1等這些信息可以先用一個(gè)簡(jiǎn)單的CSV表格記錄也可以直接引入MLflow或者Weights and Biases這類實(shí)驗(yàn)管理平臺(tái)。我對(duì)從零開始的項(xiàng)目的建議是先用CSV手動(dòng)記錄把習(xí)慣養(yǎng)成等實(shí)驗(yàn)數(shù)量多了再上平臺(tái)。4.2 一個(gè)最小可用的訓(xùn)練循環(huán)下面這段代碼是一個(gè)結(jié)構(gòu)清晰的訓(xùn)練循環(huán)框架你拿到任何入門深度學(xué)習(xí)項(xiàng)目里都可以直接改改就用import torch from torch.utils.data import DataLoader def train_one_epoch(model, dataloader, optimizer, criterion, device): model.train() total_loss 0.0 correct 0 total 0 for inputs, labels in dataloader: inputs, labels inputs.to(device), labels.to(device) optimizer.zero_grad() outputs model(inputs) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * inputs.size(0) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() avg_loss total_loss / total accuracy correct / total return avg_loss, accuracy def validate(model, dataloader, criterion, device): model.eval() total_loss 0.0 correct 0 total 0 with torch.no_grad(): for inputs, labels in dataloader: inputs, labels inputs.to(device), labels.to(device) outputs model(inputs) loss criterion(outputs, labels) total_loss loss.item() * inputs.size(0) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() avg_loss total_loss / total accuracy correct / total return avg_loss, accuracy如果你觀察足夠仔細(xì)會(huì)發(fā)現(xiàn)一個(gè)關(guān)鍵點(diǎn)訓(xùn)練時(shí)用optimizer.zero_grad()清空梯度這是初學(xué)者最容易忘的。如果忘了梯度會(huì)跨batch累加模型行為完全不可控。另外model.train()和model.eval()的切換也不能省它控制著Dropout和BatchNorm在不同階段的行為差別省了它你看到的驗(yàn)證集指標(biāo)基本沒(méi)有參考價(jià)值。4.3 從過(guò)擬合一個(gè)batch到真正收斂我這里有一個(gè)實(shí)戰(zhàn)中非常有效的經(jīng)驗(yàn)希望盡早傳授給你正式開始大規(guī)模訓(xùn)練之前先取一兩個(gè)batch的數(shù)據(jù)跑一次完整的前向和反向傳播看模型能否把loss降到接近0。這個(gè)過(guò)程俗稱過(guò)擬合一個(gè)小batch它的意義在于用最短的時(shí)間確認(rèn)整條鏈路是通的——從數(shù)據(jù)加載到模型前向、從loss計(jì)算到梯度回傳、從參數(shù)更新到指標(biāo)統(tǒng)計(jì)每一個(gè)環(huán)節(jié)都沒(méi)有bug。很多初學(xué)者跳過(guò)了這一步直接讓模型在全部數(shù)據(jù)上訓(xùn)練結(jié)果發(fā)現(xiàn)36個(gè)小時(shí)跑完loss就是不降再回頭排查發(fā)現(xiàn)是數(shù)據(jù)標(biāo)簽錯(cuò)位了。這時(shí)已經(jīng)浪費(fèi)了整整一天半的GPU時(shí)間。等小batch過(guò)擬合測(cè)試通過(guò)再回到完整訓(xùn)練流程上這就到了策略取舍的地方學(xué)習(xí)率設(shè)多少合適。一個(gè)經(jīng)驗(yàn)是3e-4到5e-5區(qū)間對(duì)大多數(shù)Transformer類模型來(lái)說(shuō)是一個(gè)安全起點(diǎn)CNN模型可以放寬到1e-3。如果你開啟了學(xué)習(xí)率預(yù)熱和衰減策略通常訓(xùn)練表現(xiàn)會(huì)更穩(wěn)定。4.4 早停法與模型保存別把GPU燒到最后訓(xùn)練過(guò)程中我比較推薦使用早停法。設(shè)置一個(gè)耐心值比如連續(xù)5個(gè)epoch驗(yàn)證集指標(biāo)沒(méi)有提升就停止訓(xùn)練把模型恢復(fù)到驗(yàn)證集表現(xiàn)最好的那一步。這樣做的原因很簡(jiǎn)單深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練曲線往往是鋸齒狀上升的后期可能出現(xiàn)局部波動(dòng)、過(guò)擬合和指標(biāo)回退繼續(xù)燒GPU除了傷害錢包和耐心沒(méi)有多少收益。模型保存同樣有講究。我建議每一輪都保存包含訓(xùn)練信息的完整checkpointtorch.save({ epoch: epoch, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), valid_loss: best_valid_loss, config: model_config, }, fcheckpoints/checkpoint_{epoch:03d}.pt)這樣你在后續(xù)任何時(shí)候都可以精確恢復(fù)訓(xùn)練或者進(jìn)行模型評(píng)估不用從頭再來(lái)。只保存model.state_dict()的做法雖然方便加載但想繼續(xù)訓(xùn)練或者復(fù)盤實(shí)驗(yàn)時(shí)就會(huì)很被動(dòng)。從工程角度講一個(gè)checkpoint如果能告訴你這個(gè)模型在哪個(gè)epoch、什么數(shù)據(jù)、什么超參數(shù)下訓(xùn)練的它的價(jià)值會(huì)超出模型權(quán)重本身。5. 模型部署這最后一公里決定項(xiàng)目能否真正落地5.1 TorchScript、ONNX還是一種簡(jiǎn)單服務(wù)化封裝模型訓(xùn)練完怎么給別人用是很多從零開始項(xiàng)目最容易掉鏈子的一步。你有可能把訓(xùn)練好的模型寫成model.pt文件放在Git倉(cāng)庫(kù)里就完事了但其他人想跑起來(lái)就得把整個(gè)訓(xùn)練代碼拉下來(lái)環(huán)境全部裝一遍再調(diào)用一些模糊不清的函數(shù)。這不是工程化的做法。生產(chǎn)環(huán)境里常見(jiàn)的方式有三種TorchScript、ONNX和純服務(wù)化封裝。TorchScript是PyTorch官方提供的模型序列化格式好處是它把模型結(jié)構(gòu)和權(quán)重打包成單一文件不依賴原始Python類定義。導(dǎo)出方式很簡(jiǎn)單model.eval() scripted_model torch.jit.script(model.cpu()) scripted_model.save(models/model_scripted.pt)ONNX則更進(jìn)一步把模型轉(zhuǎn)換成與框架無(wú)關(guān)的中間格式可以直接用ONNX Runtime在CPU上達(dá)到遠(yuǎn)超PyTorch原生的推理速度。但ONNX對(duì)某些動(dòng)態(tài)結(jié)構(gòu)兼容性不夠理想如果你的模型里包含循環(huán)和條件控制可能需要額外處理。對(duì)初學(xué)者來(lái)說(shuō)我建議的路線是先不用管TorchScript和ONNX這些繁瑣格式先寫一個(gè)標(biāo)準(zhǔn)的推理腳本封裝把模型的加載和預(yù)測(cè)封裝成干凈的predict(input)接口。這段代碼才是工程化的第一步import torch from PIL import Image import torchvision.transforms as transforms class ModelInference: def __init__(self, model_path, devicecpu): self.device torch.device(device) self.model torch.jit.load(model_path, map_locationself.device) self.model.eval() self.transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) def predict(self, image_path): image Image.open(image_path).convert(RGB) tensor self.transform(image).unsqueeze(0).to(self.device) with torch.no_grad(): output self.model(tensor) prob torch.softmax(output, dim1) return prob5.2 FastAPI是當(dāng)前比較穩(wěn)妥的服務(wù)化選擇如果你想把這個(gè)推理腳本變成真正的線上服務(wù)我推薦用FastAPI它相比Flask有幾個(gè)更貼合AI項(xiàng)目的特點(diǎn)原生支持異步、自動(dòng)生成API文檔、基于Pydantic做請(qǐng)求參數(shù)校驗(yàn)尤其適合深度學(xué)習(xí)模型的在線推理場(chǎng)景。一個(gè)最小可用的服務(wù)只需要幾十行代碼from fastapi import FastAPI, UploadFile, File import uvicorn import torch app FastAPI() inferer ModelInference(models/model_scripted.pt, devicecpu) app.post(/predict) async def predict(file: UploadFile File(...)): contents await file.read() with open(/tmp/upload.jpg, wb) as f: f.write(contents) probabilities inferer.predict(/tmp/upload.jpg) top3_indices torch.topk(probabilities, 3).indices[0].tolist() return {predictions: [{class_id: idx, probability: float(probabilities[0, idx])} for idx in top3_indices]} if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)這個(gè)服務(wù)看起來(lái)簡(jiǎn)陋但它完整地做到了模型推理對(duì)外提供HTTP接口這件事。你可以先用uvicorn main:app --reload在本地起服務(wù)然后用curl測(cè)一下curl -X POST http://localhost:8000/predict -F filetest.jpg如果一切正常返回的JSON里就是模型的預(yù)測(cè)結(jié)果。到了這一步模型能跑和模型能用之間的距離就被拉近了。5.3 部署到云服務(wù)器時(shí)的幾個(gè)實(shí)操建議本地跑通只是第一步真正部署到云服務(wù)器的過(guò)程中還有幾個(gè)注意點(diǎn)值得提前準(zhǔn)備。第一個(gè)是模型文件的分發(fā)和加載路徑。不要把大模型文件直接放進(jìn)Git倉(cāng)庫(kù)Github有100MB的文件大小限制而且push幾十MB的權(quán)重文件會(huì)造成倉(cāng)庫(kù)膨脹日后拉取代碼非常痛苦。正規(guī)做法是使用模型專用的對(duì)象存儲(chǔ)服務(wù)如S3、OSS或者用Git LFS來(lái)管理。第二個(gè)是GPU和CPU之間的選擇。很多推理場(chǎng)景其實(shí)CPU就夠用。特別是用的預(yù)訓(xùn)練模型參數(shù)量在億級(jí)以下且沒(méi)有大量請(qǐng)求并發(fā)時(shí)開一個(gè)好消息是即使不上GPU優(yōu)化過(guò)的CPU推理也能滿足一般業(yè)務(wù)需求。更重要的是CPU服務(wù)器通常便宜得多從成本角度考慮非常劃算。第三個(gè)是服務(wù)自動(dòng)重啟和健康檢查。用systemd或Docker Compose管理服務(wù)進(jìn)程讓它崩潰后自動(dòng)拉起。加上一個(gè)/health端點(diǎn)方便負(fù)載均衡和監(jiān)控系統(tǒng)定期檢查服務(wù)是否存活。6. 上線的終點(diǎn)是監(jiān)控模型漂移和效果衰減防不勝防如果你以為模型部署上線后就萬(wàn)事大吉那我只能說(shuō)你還沒(méi)經(jīng)歷過(guò)真正的AI工程。模型跑在生產(chǎn)環(huán)境里數(shù)據(jù)分布每天都在變用戶的輸入模式和訓(xùn)練集有差異模型的效果可能在你不知不覺(jué)中持續(xù)下降——這就是所謂的模型漂移問(wèn)題。它通常發(fā)生在兩種情況下一是數(shù)據(jù)漂移即輸入數(shù)據(jù)分布發(fā)生變化二是概念漂移即輸入到輸出的映射規(guī)則發(fā)生了變化。針對(duì)這些問(wèn)題我建議你從第一天就建立以下三個(gè)監(jiān)控習(xí)慣輸入數(shù)據(jù)分布監(jiān)控對(duì)每一批真實(shí)請(qǐng)求的特征做統(tǒng)計(jì)和訓(xùn)練集分布對(duì)比發(fā)現(xiàn)異常偏離能及時(shí)預(yù)警。預(yù)測(cè)結(jié)果質(zhì)量抽檢人工抽樣檢查模型輸出記錄錯(cuò)誤率和置信度分布變化。延遲和負(fù)載監(jiān)控記錄服務(wù)的推理延遲、并發(fā)請(qǐng)求量、內(nèi)存和GPU利用率確保系統(tǒng)穩(wěn)定性。舉個(gè)很直觀的例子一個(gè)在晴天拍攝街景下訓(xùn)練出來(lái)的分類模型部署后遇到連續(xù)陰雨天氣輸入圖片的像素分布發(fā)生明顯偏移模型準(zhǔn)確率可能從95%直接跌到70%。如果沒(méi)有數(shù)據(jù)分布監(jiān)控你可能要等用戶大量投訴后才發(fā)現(xiàn)問(wèn)題。而有了監(jiān)控告警你可以第一時(shí)間發(fā)現(xiàn)分布偏離及時(shí)收集新數(shù)據(jù)、重新訓(xùn)練模型把影響控制在最小范圍。7. 從跑通一個(gè)倉(cāng)庫(kù)到做出自己的AI工程最后階段的路徑建議說(shuō)實(shí)話ai-engineering-from-scratch這類項(xiàng)目之所以有吸引力恰恰在于它給了你一個(gè)從混沌到清晰的成長(zhǎng)路徑。但我要提醒你完全照著倉(cāng)庫(kù)跑一遍你的收獲非常有限。真正的成長(zhǎng)發(fā)生在你改這個(gè)倉(cāng)庫(kù)的那一刻——換一個(gè)數(shù)據(jù)集、加一個(gè)新功能、換一種模型架構(gòu)、修復(fù)一個(gè)bug、把單機(jī)訓(xùn)練改成分布式、把同步推理改成異步隊(duì)列。每一次改變都會(huì)逼你深入理解一個(gè)原本一知半解的環(huán)節(jié)。在這里我給你三條可以具體執(zhí)行的方向選一個(gè)小而完整的問(wèn)題場(chǎng)景比如文本分類或圖像分類從數(shù)據(jù)采集到服務(wù)上線全流程親手走一遍不依賴任何端到端的AutoML工具。把這個(gè)項(xiàng)目的某一環(huán)徹底做深例如把數(shù)據(jù)管線切換到流式處理或者把模型推理用ONNX Runtime重寫體會(huì)不同技術(shù)選擇之間的差異。給自己設(shè)定一個(gè)交付標(biāo)準(zhǔn)Git倉(cāng)庫(kù)里有清晰的README、能一鍵復(fù)現(xiàn)的環(huán)境配置、完整的實(shí)驗(yàn)記錄、標(biāo)準(zhǔn)化的模型推理接口。做到這些你的工程化意識(shí)就已經(jīng)比絕大多數(shù)教程搬運(yùn)工強(qiáng)了。我在做類似的從零項(xiàng)目時(shí)最大的感受是AI工程的知識(shí)密度其實(shí)被遠(yuǎn)遠(yuǎn)低估了。很多人覺(jué)得我懂機(jī)器學(xué)習(xí)算法就夠了但實(shí)際上數(shù)據(jù)清洗、依賴管理、訓(xùn)練調(diào)度、模型服務(wù)化、監(jiān)控告警、實(shí)驗(yàn)追蹤這些工程能力才是真正區(qū)分能做Demo和能落地的分界線。而且這些能力沒(méi)有任何捷徑只能在項(xiàng)目中一個(gè)一個(gè)坑踩過(guò)來(lái)踩得越多下一次就越穩(wěn)。 AI工程從零開始：從環(huán)境搭建到模型部署的完整指南
1. 別急著寫代碼想清楚從零開始到底意味著什么我見(jiàn)過(guò)太多人栽在這一步。打開GitHub看到一個(gè)叫ai-engineering-from-scratch的倉(cāng)庫(kù)熱血上頭克隆下來(lái)就開始跑訓(xùn)練腳本結(jié)果卡在環(huán)境依賴上折騰了一整天最后連數(shù)據(jù)集長(zhǎng)什么樣都沒(méi)看清楚。這幾乎是每個(gè)剛接觸AI工程的初學(xué)者都會(huì)踩的坑——拿到了倉(cāng)庫(kù)地址卻不知道自己究竟要在這個(gè)工程里做什么。先把這個(gè)概念拆開AI工程不是寫模型而是用工程化的方法把模型變成可持續(xù)運(yùn)行、可維護(hù)、可迭代的系統(tǒng)。一個(gè)合格的AI工程至少包含四件套數(shù)據(jù)管線、訓(xùn)練實(shí)驗(yàn)、部署服務(wù)、監(jiān)控運(yùn)維。絕大多數(shù)初學(xué)者只盯著訓(xùn)練這一環(huán)然后被環(huán)境配置、數(shù)據(jù)清洗、模型存儲(chǔ)、接口封裝這些問(wèn)題反復(fù)摩擦。所以如果你想認(rèn)真做ai-engineering-from-scratch這個(gè)項(xiàng)目我建議你第一步不是看代碼而是畫一張圖把下面這幾件事理清楚這個(gè)工程要解決什么問(wèn)題分類、生成、還是檢索數(shù)據(jù)的來(lái)源是什么原始格式長(zhǎng)什么樣需要哪些預(yù)處理步驟模型選多大、選什么架構(gòu)訓(xùn)練需要什么樣的GPU資源和顯存訓(xùn)練完成后怎么提供服務(wù)需要多高的并發(fā)和延遲要求模型漂移了怎么辦人工反饋的通道在哪里只有把這些想明白了你才知道倉(cāng)庫(kù)里哪些代碼是核心、哪些是輔助、哪些可以直接跳過(guò)不用管。從零開始做AI工程本質(zhì)上是從業(yè)務(wù)問(wèn)題開始倒推技術(shù)方案而不是從代碼開始正推能跑起來(lái)什么。2. 環(huán)境搭建的坑遠(yuǎn)比你想的多得多2.1 Python環(huán)境從Virtualenv到Conda的取舍在正式開始跑任何AI項(xiàng)目之前環(huán)境是第一道關(guān)卡。你可能會(huì)覺(jué)得用pip install裝幾個(gè)包有什么難的但真到了深度學(xué)習(xí)項(xiàng)目里坑馬上就會(huì)冒出來(lái)CUDA版本對(duì)不上、PyTorch和TensorFlow沖突、Python 3.10某庫(kù)不兼容、protobuf版本互相打架……我甚至見(jiàn)過(guò)有人在Mac上用pip install tensorflow裝上之后發(fā)現(xiàn)只能跑CPU還以為是代碼寫錯(cuò)了。我的建議是如果你不是只做純Python的原型驗(yàn)證直接用Conda。不光是虛擬環(huán)境隔離更重要的是它能同時(shí)管理Python版本和CUDA依賴尤其是你用NVIDIA GPU做深度學(xué)習(xí)訓(xùn)練的時(shí)候。Conda環(huán)境可以做到每個(gè)項(xiàng)目一套獨(dú)立體系互不污染。用conda create -n ai-eng python3.10創(chuàng)建環(huán)境然后按需安裝PyTorch或TensorFlow對(duì)應(yīng)的CUDA版本踩坑概率驟降。2.2 GPU驅(qū)動(dòng)與CUDA版本的匹配邏輯這是整個(gè)環(huán)境搭建過(guò)程中最容易讓人崩潰的一段。很多人照著網(wǎng)上的教程裝了CUDA結(jié)果torch.cuda.is_available()返回False怎么排查都找不到問(wèn)題。核心原因通常是裝了新的CUDA Toolkit但顯卡驅(qū)動(dòng)太老或者驅(qū)動(dòng)版本支持的最高CUDA版本低于你安裝的版本。這里有一個(gè)基本匹配邏輯顯卡驅(qū)動(dòng)是底層CUDA Toolkit是上層上層不能超過(guò)下層的上限。用nvidia-smi查看驅(qū)動(dòng)支持的CUDA版本然后裝一個(gè)不高于這個(gè)上限的CUDA版本再用pip裝對(duì)應(yīng)編譯好的PyTorch版本基本就不會(huì)出錯(cuò)。另外我強(qiáng)烈建議在項(xiàng)目根目錄寫一個(gè)environment.yml或者至少寫清楚依賴列表版本。不做版本鎖定的AI工程等于給自己埋雷——三個(gè)月后你打開之前的項(xiàng)目發(fā)現(xiàn)依賴全變了代碼跑不起來(lái)了那種痛苦相信很多人都有體會(huì)。2.3 Docker從能跑到可復(fù)現(xiàn)的關(guān)鍵一步到了真的要把項(xiàng)目給別人復(fù)現(xiàn)、或者部署到服務(wù)器上的時(shí)候Docker絕對(duì)繞不開。如果你只是在自己電腦上調(diào)代碼Conda就夠用但只要涉及團(tuán)隊(duì)協(xié)作、服務(wù)器部署、或者你想讓這個(gè)從零開始的項(xiàng)目具備工程化的底子一定要一開始就把Dockerfile寫好。FROM pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, train.py]這份Dockerfile雖然簡(jiǎn)單但它體現(xiàn)了工程化最基本的要求環(huán)境可重復(fù)構(gòu)建。在寫Dockerfile時(shí)有幾個(gè)細(xì)節(jié)需要注意盡量選擇官方發(fā)布的帶CUDA的鏡像作為基礎(chǔ)避免重復(fù)裝驅(qū)動(dòng)和CUDA的煩惱把requirements.txt放在源碼之前單獨(dú)COPY這樣能充分利用Docker緩存后續(xù)改代碼不會(huì)重新安裝依賴構(gòu)建速度快好幾倍。注意國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境下拉取Docker鏡像和pip依賴都可能遇到連接問(wèn)題建議提前配置好鏡像源。這不是小問(wèn)題很多人的AI工程就是從下載依賴失敗這一步開始放棄的。3. 數(shù)據(jù)管線的優(yōu)先級(jí)沒(méi)數(shù)據(jù)模型就是花架子3.1 先解決數(shù)據(jù)從哪來(lái)再到數(shù)據(jù)怎么喂很多從零開始的AI工程卡住的核心往往不是模型太復(fù)雜而是根本沒(méi)有高質(zhì)量數(shù)據(jù)。很多人習(xí)慣先寫好訓(xùn)練代碼然后才去找數(shù)據(jù)集最后發(fā)現(xiàn)格式對(duì)不上、標(biāo)簽質(zhì)量差、數(shù)量不夠又回頭改代碼浪費(fèi)大量時(shí)間。我的建議是數(shù)據(jù)先行。不管你是爬公開數(shù)據(jù)集、從業(yè)務(wù)系統(tǒng)導(dǎo)出還是自己設(shè)計(jì)標(biāo)注方案一定要在寫模型代碼前先把數(shù)據(jù)流程跑通原始數(shù)據(jù) → 清洗 → 預(yù)處理 → 切分訓(xùn)練/驗(yàn)證/測(cè)試集 → 構(gòu)建DataLoader。這一步走完了后續(xù)訓(xùn)練模型時(shí)就會(huì)非常順暢。3.2 數(shù)據(jù)清洗的常規(guī)操作清單數(shù)據(jù)清洗聽(tīng)起來(lái)不酷但它是決定模型效果上限的隱形要素。我總結(jié)了一套常規(guī)操作你在項(xiàng)目里直接照著做就可以去重。文本數(shù)據(jù)要處理完全重復(fù)的樣本圖像數(shù)據(jù)檢查完全相同的圖片這一步看似簡(jiǎn)單但能有效防止驗(yàn)證集數(shù)據(jù)泄漏讓模型效果虛高。處理缺失值。圖像中缺樣本可以直接丟棄文本中缺標(biāo)簽可以考慮規(guī)則補(bǔ)全表格數(shù)據(jù)則可以填充均值或眾數(shù)具體策略取決于業(yè)務(wù)場(chǎng)景。標(biāo)準(zhǔn)化/歸一化。文本轉(zhuǎn)小寫、去除停用詞圖像做灰度歸一化數(shù)值特征縮放到0到1區(qū)間。不同模型對(duì)此敏感度差異很大但標(biāo)準(zhǔn)做法一定不會(huì)錯(cuò)。標(biāo)簽分布檢查。做一個(gè)簡(jiǎn)單的統(tǒng)計(jì)直方圖看類別是否極度不均衡。如果發(fā)生嚴(yán)重不均衡在訓(xùn)練前就想好要不要做重采樣否則后面模型會(huì)被多數(shù)類帶跑偏。這些步驟不需要都用上重武器很多情況下其實(shí)就是幾行Python的事。比如用pandas做標(biāo)簽分布檢查import pandas as pd df pd.read_csv(data/labels.csv) value_counts df[label].value_counts() print(value_counts) # 輸出類別分布比例判斷是否需要重采樣 class_ratios value_counts / len(df) print(class_ratios)3.3 數(shù)據(jù)集切分容易被忽視的三個(gè)細(xì)節(jié)切訓(xùn)練集、驗(yàn)證集、測(cè)試集人人都知道8:1:1但實(shí)際操作里有三個(gè)細(xì)節(jié)特別容易被忽略。第一類別比例要保持。如果原始數(shù)據(jù)集里A類占80%、B類占20%那你切出來(lái)的訓(xùn)練集也保持這個(gè)比例不能切完發(fā)現(xiàn)訓(xùn)練集里全是A類。用sklearn的train_test_split時(shí)別忘設(shè)置stratifydf[label]這個(gè)參數(shù)。第二驗(yàn)證集和測(cè)試集必須保持未來(lái)感。如果數(shù)據(jù)帶時(shí)間順序比如新聞文本、交易記錄一定要按時(shí)間切分不能隨機(jī)打亂否則就是讓模型用未來(lái)的信息預(yù)測(cè)過(guò)去你得到的是一個(gè)看起來(lái)95%準(zhǔn)確率但在真實(shí)場(chǎng)景下崩得一塌糊涂的模型。第三切分完固定下來(lái)。把切分后的索引存成文件或者設(shè)置固定隨機(jī)種子保證每次復(fù)現(xiàn)時(shí)訓(xùn)練集、驗(yàn)證集完全一致。沒(méi)有這一步你的實(shí)驗(yàn)對(duì)比就沒(méi)有公平性可言——每次訓(xùn)練的數(shù)據(jù)都不一樣你根本無(wú)法判斷模型效果提升是因?yàn)楦倪M(jìn)了模型還是因?yàn)閾Q了一批訓(xùn)練數(shù)據(jù)。4. 訓(xùn)練實(shí)驗(yàn)管理你以為的跑通只是萬(wàn)里長(zhǎng)征第一步4.1 實(shí)驗(yàn)記錄為什么比代碼本身更值錢到了訓(xùn)練階段一個(gè)典型的錯(cuò)誤是改一改參數(shù)跑一遍訓(xùn)練看一眼loss下降沒(méi)有然后繼續(xù)改——沒(méi)有任何記錄。跑了幾十次實(shí)驗(yàn)后看到結(jié)果最好的是第三天的某一次但你完全記不清當(dāng)時(shí)用了什么參數(shù)、什么數(shù)據(jù)版本、什么隨機(jī)種子。AI工程和寫普通軟件最大的區(qū)別就在于它的行為是概率性的實(shí)驗(yàn)的復(fù)現(xiàn)和追蹤極其重要。如果你從零開始做工程化我建議在第一天就把下面這些東西記錄下來(lái)模型結(jié)構(gòu)的具體配置隱藏層維度、層數(shù)、激活函數(shù)、dropout率訓(xùn)練超參數(shù)學(xué)習(xí)率、batch size、epoch數(shù)、優(yōu)化器及參數(shù)數(shù)據(jù)版本用哪份清洗后的數(shù)據(jù)、預(yù)處理腳本的版本訓(xùn)練環(huán)境PyTorch版本、CUDA版本、GPU型號(hào)隨機(jī)種子固定種子保證可復(fù)現(xiàn)關(guān)鍵指標(biāo)train loss、val loss、accuracy、F1等這些信息可以先用一個(gè)簡(jiǎn)單的CSV表格記錄也可以直接引入MLflow或者Weights and Biases這類實(shí)驗(yàn)管理平臺(tái)。我對(duì)從零開始的項(xiàng)目的建議是先用CSV手動(dòng)記錄把習(xí)慣養(yǎng)成等實(shí)驗(yàn)數(shù)量多了再上平臺(tái)。4.2 一個(gè)最小可用的訓(xùn)練循環(huán)下面這段代碼是一個(gè)結(jié)構(gòu)清晰的訓(xùn)練循環(huán)框架你拿到任何入門深度學(xué)習(xí)項(xiàng)目里都可以直接改改就用import torch from torch.utils.data import DataLoader def train_one_epoch(model, dataloader, optimizer, criterion, device): model.train() total_loss 0.0 correct 0 total 0 for inputs, labels in dataloader: inputs, labels inputs.to(device), labels.to(device) optimizer.zero_grad() outputs model(inputs) loss criterion(outputs, labels) loss.backward() optimizer.step() total_loss loss.item() * inputs.size(0) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() avg_loss total_loss / total accuracy correct / total return avg_loss, accuracy def validate(model, dataloader, criterion, device): model.eval() total_loss 0.0 correct 0 total 0 with torch.no_grad(): for inputs, labels in dataloader: inputs, labels inputs.to(device), labels.to(device) outputs model(inputs) loss criterion(outputs, labels) total_loss loss.item() * inputs.size(0) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() avg_loss total_loss / total accuracy correct / total return avg_loss, accuracy如果你觀察足夠仔細(xì)會(huì)發(fā)現(xiàn)一個(gè)關(guān)鍵點(diǎn)訓(xùn)練時(shí)用optimizer.zero_grad()清空梯度這是初學(xué)者最容易忘的。如果忘了梯度會(huì)跨batch累加模型行為完全不可控。另外model.train()和model.eval()的切換也不能省它控制著Dropout和BatchNorm在不同階段的行為差別省了它你看到的驗(yàn)證集指標(biāo)基本沒(méi)有參考價(jià)值。4.3 從過(guò)擬合一個(gè)batch到真正收斂我這里有一個(gè)實(shí)戰(zhàn)中非常有效的經(jīng)驗(yàn)希望盡早傳授給你正式開始大規(guī)模訓(xùn)練之前先取一兩個(gè)batch的數(shù)據(jù)跑一次完整的前向和反向傳播看模型能否把loss降到接近0。這個(gè)過(guò)程俗稱過(guò)擬合一個(gè)小batch它的意義在于用最短的時(shí)間確認(rèn)整條鏈路是通的——從數(shù)據(jù)加載到模型前向、從loss計(jì)算到梯度回傳、從參數(shù)更新到指標(biāo)統(tǒng)計(jì)每一個(gè)環(huán)節(jié)都沒(méi)有bug。很多初學(xué)者跳過(guò)了這一步直接讓模型在全部數(shù)據(jù)上訓(xùn)練結(jié)果發(fā)現(xiàn)36個(gè)小時(shí)跑完loss就是不降再回頭排查發(fā)現(xiàn)是數(shù)據(jù)標(biāo)簽錯(cuò)位了。這時(shí)已經(jīng)浪費(fèi)了整整一天半的GPU時(shí)間。等小batch過(guò)擬合測(cè)試通過(guò)再回到完整訓(xùn)練流程上這就到了策略取舍的地方學(xué)習(xí)率設(shè)多少合適。一個(gè)經(jīng)驗(yàn)是3e-4到5e-5區(qū)間對(duì)大多數(shù)Transformer類模型來(lái)說(shuō)是一個(gè)安全起點(diǎn)CNN模型可以放寬到1e-3。如果你開啟了學(xué)習(xí)率預(yù)熱和衰減策略通常訓(xùn)練表現(xiàn)會(huì)更穩(wěn)定。4.4 早停法與模型保存別把GPU燒到最后訓(xùn)練過(guò)程中我比較推薦使用早停法。設(shè)置一個(gè)耐心值比如連續(xù)5個(gè)epoch驗(yàn)證集指標(biāo)沒(méi)有提升就停止訓(xùn)練把模型恢復(fù)到驗(yàn)證集表現(xiàn)最好的那一步。這樣做的原因很簡(jiǎn)單深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練曲線往往是鋸齒狀上升的后期可能出現(xiàn)局部波動(dòng)、過(guò)擬合和指標(biāo)回退繼續(xù)燒GPU除了傷害錢包和耐心沒(méi)有多少收益。模型保存同樣有講究。我建議每一輪都保存包含訓(xùn)練信息的完整checkpointtorch.save({ epoch: epoch, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), valid_loss: best_valid_loss, config: model_config, }, fcheckpoints/checkpoint_{epoch:03d}.pt)這樣你在后續(xù)任何時(shí)候都可以精確恢復(fù)訓(xùn)練或者進(jìn)行模型評(píng)估不用從頭再來(lái)。只保存model.state_dict()的做法雖然方便加載但想繼續(xù)訓(xùn)練或者復(fù)盤實(shí)驗(yàn)時(shí)就會(huì)很被動(dòng)。從工程角度講一個(gè)checkpoint如果能告訴你這個(gè)模型在哪個(gè)epoch、什么數(shù)據(jù)、什么超參數(shù)下訓(xùn)練的它的價(jià)值會(huì)超出模型權(quán)重本身。5. 模型部署這最后一公里決定項(xiàng)目能否真正落地5.1 TorchScript、ONNX還是一種簡(jiǎn)單服務(wù)化封裝模型訓(xùn)練完怎么給別人用是很多從零開始項(xiàng)目最容易掉鏈子的一步。你有可能把訓(xùn)練好的模型寫成model.pt文件放在Git倉(cāng)庫(kù)里就完事了但其他人想跑起來(lái)就得把整個(gè)訓(xùn)練代碼拉下來(lái)環(huán)境全部裝一遍再調(diào)用一些模糊不清的函數(shù)。這不是工程化的做法。生產(chǎn)環(huán)境里常見(jiàn)的方式有三種TorchScript、ONNX和純服務(wù)化封裝。TorchScript是PyTorch官方提供的模型序列化格式好處是它把模型結(jié)構(gòu)和權(quán)重打包成單一文件不依賴原始Python類定義。導(dǎo)出方式很簡(jiǎn)單model.eval() scripted_model torch.jit.script(model.cpu()) scripted_model.save(models/model_scripted.pt)ONNX則更進(jìn)一步把模型轉(zhuǎn)換成與框架無(wú)關(guān)的中間格式可以直接用ONNX Runtime在CPU上達(dá)到遠(yuǎn)超PyTorch原生的推理速度。但ONNX對(duì)某些動(dòng)態(tài)結(jié)構(gòu)兼容性不夠理想如果你的模型里包含循環(huán)和條件控制可能需要額外處理。對(duì)初學(xué)者來(lái)說(shuō)我建議的路線是先不用管TorchScript和ONNX這些繁瑣格式先寫一個(gè)標(biāo)準(zhǔn)的推理腳本封裝把模型的加載和預(yù)測(cè)封裝成干凈的predict(input)接口。這段代碼才是工程化的第一步import torch from PIL import Image import torchvision.transforms as transforms class ModelInference: def __init__(self, model_path, devicecpu): self.device torch.device(device) self.model torch.jit.load(model_path, map_locationself.device) self.model.eval() self.transform transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]) ]) def predict(self, image_path): image Image.open(image_path).convert(RGB) tensor self.transform(image).unsqueeze(0).to(self.device) with torch.no_grad(): output self.model(tensor) prob torch.softmax(output, dim1) return prob5.2 FastAPI是當(dāng)前比較穩(wěn)妥的服務(wù)化選擇如果你想把這個(gè)推理腳本變成真正的線上服務(wù)我推薦用FastAPI它相比Flask有幾個(gè)更貼合AI項(xiàng)目的特點(diǎn)原生支持異步、自動(dòng)生成API文檔、基于Pydantic做請(qǐng)求參數(shù)校驗(yàn)尤其適合深度學(xué)習(xí)模型的在線推理場(chǎng)景。一個(gè)最小可用的服務(wù)只需要幾十行代碼from fastapi import FastAPI, UploadFile, File import uvicorn import torch app FastAPI() inferer ModelInference(models/model_scripted.pt, devicecpu) app.post(/predict) async def predict(file: UploadFile File(...)): contents await file.read() with open(/tmp/upload.jpg, wb) as f: f.write(contents) probabilities inferer.predict(/tmp/upload.jpg) top3_indices torch.topk(probabilities, 3).indices[0].tolist() return {predictions: [{class_id: idx, probability: float(probabilities[0, idx])} for idx in top3_indices]} if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)這個(gè)服務(wù)看起來(lái)簡(jiǎn)陋但它完整地做到了模型推理對(duì)外提供HTTP接口這件事。你可以先用uvicorn main:app --reload在本地起服務(wù)然后用curl測(cè)一下curl -X POST http://localhost:8000/predict -F filetest.jpg如果一切正常返回的JSON里就是模型的預(yù)測(cè)結(jié)果。到了這一步模型能跑和模型能用之間的距離就被拉近了。5.3 部署到云服務(wù)器時(shí)的幾個(gè)實(shí)操建議本地跑通只是第一步真正部署到云服務(wù)器的過(guò)程中還有幾個(gè)注意點(diǎn)值得提前準(zhǔn)備。第一個(gè)是模型文件的分發(fā)和加載路徑。不要把大模型文件直接放進(jìn)Git倉(cāng)庫(kù)Github有100MB的文件大小限制而且push幾十MB的權(quán)重文件會(huì)造成倉(cāng)庫(kù)膨脹日后拉取代碼非常痛苦。正規(guī)做法是使用模型專用的對(duì)象存儲(chǔ)服務(wù)如S3、OSS或者用Git LFS來(lái)管理。第二個(gè)是GPU和CPU之間的選擇。很多推理場(chǎng)景其實(shí)CPU就夠用。特別是用的預(yù)訓(xùn)練模型參數(shù)量在億級(jí)以下且沒(méi)有大量請(qǐng)求并發(fā)時(shí)開一個(gè)好消息是即使不上GPU優(yōu)化過(guò)的CPU推理也能滿足一般業(yè)務(wù)需求。更重要的是CPU服務(wù)器通常便宜得多從成本角度考慮非常劃算。第三個(gè)是服務(wù)自動(dòng)重啟和健康檢查。用systemd或Docker Compose管理服務(wù)進(jìn)程讓它崩潰后自動(dòng)拉起。加上一個(gè)/health端點(diǎn)方便負(fù)載均衡和監(jiān)控系統(tǒng)定期檢查服務(wù)是否存活。6. 上線的終點(diǎn)是監(jiān)控模型漂移和效果衰減防不勝防如果你以為模型部署上線后就萬(wàn)事大吉那我只能說(shuō)你還沒(méi)經(jīng)歷過(guò)真正的AI工程。模型跑在生產(chǎn)環(huán)境里數(shù)據(jù)分布每天都在變用戶的輸入模式和訓(xùn)練集有差異模型的效果可能在你不知不覺(jué)中持續(xù)下降——這就是所謂的模型漂移問(wèn)題。它通常發(fā)生在兩種情況下一是數(shù)據(jù)漂移即輸入數(shù)據(jù)分布發(fā)生變化二是概念漂移即輸入到輸出的映射規(guī)則發(fā)生了變化。針對(duì)這些問(wèn)題我建議你從第一天就建立以下三個(gè)監(jiān)控習(xí)慣輸入數(shù)據(jù)分布監(jiān)控對(duì)每一批真實(shí)請(qǐng)求的特征做統(tǒng)計(jì)和訓(xùn)練集分布對(duì)比發(fā)現(xiàn)異常偏離能及時(shí)預(yù)警。預(yù)測(cè)結(jié)果質(zhì)量抽檢人工抽樣檢查模型輸出記錄錯(cuò)誤率和置信度分布變化。延遲和負(fù)載監(jiān)控記錄服務(wù)的推理延遲、并發(fā)請(qǐng)求量、內(nèi)存和GPU利用率確保系統(tǒng)穩(wěn)定性。舉個(gè)很直觀的例子一個(gè)在晴天拍攝街景下訓(xùn)練出來(lái)的分類模型部署后遇到連續(xù)陰雨天氣輸入圖片的像素分布發(fā)生明顯偏移模型準(zhǔn)確率可能從95%直接跌到70%。如果沒(méi)有數(shù)據(jù)分布監(jiān)控你可能要等用戶大量投訴后才發(fā)現(xiàn)問(wèn)題。而有了監(jiān)控告警你可以第一時(shí)間發(fā)現(xiàn)分布偏離及時(shí)收集新數(shù)據(jù)、重新訓(xùn)練模型把影響控制在最小范圍。7. 從跑通一個(gè)倉(cāng)庫(kù)到做出自己的AI工程最后階段的路徑建議說(shuō)實(shí)話ai-engineering-from-scratch這類項(xiàng)目之所以有吸引力恰恰在于它給了你一個(gè)從混沌到清晰的成長(zhǎng)路徑。但我要提醒你完全照著倉(cāng)庫(kù)跑一遍你的收獲非常有限。真正的成長(zhǎng)發(fā)生在你改這個(gè)倉(cāng)庫(kù)的那一刻——換一個(gè)數(shù)據(jù)集、加一個(gè)新功能、換一種模型架構(gòu)、修復(fù)一個(gè)bug、把單機(jī)訓(xùn)練改成分布式、把同步推理改成異步隊(duì)列。每一次改變都會(huì)逼你深入理解一個(gè)原本一知半解的環(huán)節(jié)。在這里我給你三條可以具體執(zhí)行的方向選一個(gè)小而完整的問(wèn)題場(chǎng)景比如文本分類或圖像分類從數(shù)據(jù)采集到服務(wù)上線全流程親手走一遍不依賴任何端到端的AutoML工具。把這個(gè)項(xiàng)目的某一環(huán)徹底做深例如把數(shù)據(jù)管線切換到流式處理或者把模型推理用ONNX Runtime重寫體會(huì)不同技術(shù)選擇之間的差異。給自己設(shè)定一個(gè)交付標(biāo)準(zhǔn)Git倉(cāng)庫(kù)里有清晰的README、能一鍵復(fù)現(xiàn)的環(huán)境配置、完整的實(shí)驗(yàn)記錄、標(biāo)準(zhǔn)化的模型推理接口。做到這些你的工程化意識(shí)就已經(jīng)比絕大多數(shù)教程搬運(yùn)工強(qiáng)了。我在做類似的從零項(xiàng)目時(shí)最大的感受是AI工程的知識(shí)密度其實(shí)被遠(yuǎn)遠(yuǎn)低估了。很多人覺(jué)得我懂機(jī)器學(xué)習(xí)算法就夠了但實(shí)際上數(shù)據(jù)清洗、依賴管理、訓(xùn)練調(diào)度、模型服務(wù)化、監(jiān)控告警、實(shí)驗(yàn)追蹤這些工程能力才是真正區(qū)分能做Demo和能落地的分界線。而且這些能力沒(méi)有任何捷徑只能在項(xiàng)目中一個(gè)一個(gè)坑踩過(guò)來(lái)踩得越多下一次就越穩(wěn)。