1. 從零搭建AI工程體系為什么我勸你別一上來(lái)就調(diào)包“ai-engineering-from-scratch”這個(gè)標(biāo)題第一次看到的時(shí)候我愣了一下。市面上講AI的教程鋪天蓋地但絕大多數(shù)都是教你import torch然后跑一個(gè)預(yù)訓(xùn)練模型或者調(diào)個(gè)API就完事。真正講“從零開(kāi)始搭建AI工程體系”的內(nèi)容少得可憐。我自己在這個(gè)行業(yè)摸爬滾打了十來(lái)年帶過(guò)不少新人也面試過(guò)幾百個(gè)號(hào)稱“會(huì)AI”的候選人。一個(gè)很普遍的現(xiàn)象是很多人能背出Transformer的結(jié)構(gòu)圖能說(shuō)清楚Attention的計(jì)算公式但你讓他從零搭一個(gè)能用的訓(xùn)練流水線他立刻卡殼。數(shù)據(jù)怎么組織顯存怎么優(yōu)化訓(xùn)練中斷了怎么恢復(fù)模型上線后怎么監(jiān)控這些問(wèn)題調(diào)包教程里不會(huì)講但實(shí)際工作中天天遇到。所以這個(gè)項(xiàng)目標(biāo)題吸引我的地方在于它瞄準(zhǔn)的是一個(gè)真實(shí)存在的巨大缺口從“會(huì)調(diào)包”到“能工程化落地”之間的鴻溝。這篇文章我想基于自己這些年的實(shí)際經(jīng)驗(yàn)把這個(gè)標(biāo)題背后的核心內(nèi)容拆開(kāi)揉碎講清楚一個(gè)完整的AI工程體系到底包含哪些環(huán)節(jié)每個(gè)環(huán)節(jié)的關(guān)鍵決策怎么做以及那些只有踩過(guò)坑才知道的細(xì)節(jié)。適合誰(shuí)看如果你是剛?cè)胄械乃惴üこ處熣趶摹芭芡╠emo”向“能交付項(xiàng)目”過(guò)渡這篇文章能幫你少走至少半年的彎路。如果你是有經(jīng)驗(yàn)的開(kāi)發(fā)者想轉(zhuǎn)AI方向這里面的工程思路對(duì)你來(lái)說(shuō)反而是優(yōu)勢(shì)。如果你只是好奇AI工程到底在干什么也能從中看到一個(gè)真實(shí)的行業(yè)切面。2. 整體架構(gòu)設(shè)計(jì)AI工程體系到底包含什么2.1 為什么“從零”不等于“從輪子造起”先澄清一個(gè)概念。“ai-engineering-from-scratch”里的“from scratch”不是讓你用NumPy手寫(xiě)一個(gè)Transformer——那是深度學(xué)習(xí)框架開(kāi)發(fā)者干的事。這里的“從零”指的是從零搭建一套完整的、可運(yùn)行的、能支撐實(shí)際業(yè)務(wù)的AI工程體系。打個(gè)比方。你要開(kāi)一家餐廳“從零”不是讓你去種小麥、養(yǎng)牛、煉鐵鍋而是讓你從選址、菜單設(shè)計(jì)、供應(yīng)鏈搭建、廚房動(dòng)線規(guī)劃、人員分工、品控流程這一整套東西開(kāi)始搭。AI工程也是一樣PyTorch、TensorFlow這些框架就是你的“廚具”你不需要自己造但你需要知道怎么選、怎么用、怎么把它們組織成一個(gè)高效運(yùn)轉(zhuǎn)的系統(tǒng)。一個(gè)完整的AI工程體系我習(xí)慣把它拆成六個(gè)層次數(shù)據(jù)層數(shù)據(jù)的采集、清洗、標(biāo)注、版本管理、特征存儲(chǔ)訓(xùn)練層實(shí)驗(yàn)管理、分布式訓(xùn)練、超參調(diào)優(yōu)、模型檢查點(diǎn)評(píng)估層離線評(píng)估、在線A/B測(cè)試、回歸測(cè)試、偏差檢測(cè)部署層模型壓縮、推理優(yōu)化、服務(wù)化、灰度發(fā)布監(jiān)控層性能監(jiān)控、數(shù)據(jù)漂移檢測(cè)、告警機(jī)制迭代層反饋閉環(huán)、持續(xù)訓(xùn)練、版本回滾這六層缺一不可。很多團(tuán)隊(duì)的問(wèn)題就在于只關(guān)注訓(xùn)練層覺(jué)得模型訓(xùn)出來(lái)就萬(wàn)事大吉了結(jié)果上線后各種問(wèn)題層出不窮。2.2 技術(shù)選型的核心邏輯場(chǎng)景驅(qū)動(dòng)而非技術(shù)驅(qū)動(dòng)在搭建這套體系之前最重要的一步是明確你的場(chǎng)景需求。我見(jiàn)過(guò)太多團(tuán)隊(duì)一上來(lái)就選最時(shí)髦的技術(shù)棧結(jié)果發(fā)現(xiàn)根本不匹配自己的業(yè)務(wù)。選型的時(shí)候我一般會(huì)問(wèn)自己四個(gè)問(wèn)題第一個(gè)問(wèn)題數(shù)據(jù)量級(jí)和更新頻率是多少如果你的數(shù)據(jù)是TB級(jí)別的每天新增幾十萬(wàn)條那你的數(shù)據(jù)管道必須支持流式處理特征存儲(chǔ)要能支撐高并發(fā)讀寫(xiě)。如果數(shù)據(jù)量不大一周更新一次那用簡(jiǎn)單的批處理腳本就夠了沒(méi)必要上KafkaSpark那一套。第二個(gè)問(wèn)題訓(xùn)練頻率和延遲要求是什么一天訓(xùn)一次模型和一個(gè)月訓(xùn)一次對(duì)基礎(chǔ)設(shè)施的要求完全不同。前者需要自動(dòng)化的訓(xùn)練流水線后者手動(dòng)觸發(fā)就行。推理延遲要求是10ms還是1s直接決定了你要不要做模型量化、蒸餾、TensorRT優(yōu)化。第三個(gè)問(wèn)題團(tuán)隊(duì)的技術(shù)儲(chǔ)備如何如果團(tuán)隊(duì)里沒(méi)人懂Kubernetes你硬上K8s做模型部署運(yùn)維成本會(huì)高到離譜。選型要匹配團(tuán)隊(duì)能力而不是匹配招聘JD。第四個(gè)問(wèn)題預(yù)算約束是什么訓(xùn)練用A100還是3090推理用T4還是CPU這些都要算賬。我后面會(huì)給出具體的成本估算方法?；谶@四個(gè)問(wèn)題的答案你的技術(shù)棧選型基本就確定了。下面這張表是我總結(jié)的常見(jiàn)場(chǎng)景對(duì)應(yīng)的推薦方案場(chǎng)景特征數(shù)據(jù)層訓(xùn)練層部署層監(jiān)控層小數(shù)據(jù)量、低頻更新文件系統(tǒng)SQLite單機(jī)GPUFlask API日志文件中等數(shù)據(jù)量、日更新PostgreSQLMinIO單機(jī)多卡FastAPITritonPrometheusGrafana大數(shù)據(jù)量、實(shí)時(shí)更新KafkaFeature Store分布式訓(xùn)練K8sTriton全鏈路監(jiān)控邊緣部署本地緩存云端訓(xùn)練ONNX Runtime端側(cè)日志回傳注意這張表是起點(diǎn)不是終點(diǎn)。實(shí)際選型一定要結(jié)合具體業(yè)務(wù)做調(diào)整不要照搬。2.3 目錄結(jié)構(gòu)設(shè)計(jì)讓項(xiàng)目可維護(hù)的第一步一個(gè)AI工程項(xiàng)目最容易爛掉的地方就是目錄結(jié)構(gòu)。我接手過(guò)很多“祖?zhèn)鞔a”打開(kāi)一看根目錄下幾十個(gè)文件混在一起train.py、train_v2.py、train_final.py、train_final_真的最終版.py找代碼全靠搜索。從項(xiàng)目第一天起就定好目錄結(jié)構(gòu)后面能省無(wú)數(shù)時(shí)間。我推薦的結(jié)構(gòu)是這樣的project/ ├── configs/ # 配置文件 │ ├── base.yaml │ ├── train.yaml │ └── deploy.yaml ├── data/ # 數(shù)據(jù)相關(guān) │ ├── raw/ # 原始數(shù)據(jù) │ ├── processed/ # 處理后數(shù)據(jù) │ └── schemas/ # 數(shù)據(jù)schema定義 ├── src/ # 源代碼 │ ├── data/ # 數(shù)據(jù)處理模塊 │ ├── models/ # 模型定義 │ ├── training/ # 訓(xùn)練邏輯 │ ├── evaluation/ # 評(píng)估邏輯 │ └── serving/ # 服務(wù)化代碼 ├── experiments/ # 實(shí)驗(yàn)記錄 ├── notebooks/ # 探索性分析 ├── tests/ # 測(cè)試代碼 ├── scripts/ # 運(yùn)維腳本 └── docs/ # 文檔這個(gè)結(jié)構(gòu)的關(guān)鍵在于關(guān)注點(diǎn)分離。配置和代碼分離數(shù)據(jù)和代碼分離訓(xùn)練和服務(wù)分離。這樣做的好處是當(dāng)你要改一個(gè)超參數(shù)時(shí)不需要?jiǎng)哟a當(dāng)你要換一個(gè)模型時(shí)不需要?jiǎng)訑?shù)據(jù)管道當(dāng)你要部署時(shí)不需要把訓(xùn)練代碼也打包進(jìn)去。3. 數(shù)據(jù)管道搭建AI工程的地基3.1 數(shù)據(jù)版本管理別再用文件名區(qū)分了數(shù)據(jù)版本管理是AI工程里最容易被忽視的環(huán)節(jié)。我見(jiàn)過(guò)太多團(tuán)隊(duì)用data_v1.csv、data_v2_fixed.csv這種方式管理數(shù)據(jù)結(jié)果三個(gè)月后沒(méi)人說(shuō)得清哪個(gè)版本對(duì)應(yīng)哪次實(shí)驗(yàn)。正確的做法是引入數(shù)據(jù)版本控制工具。DVCData Version Control是我用得最順手的它和Git無(wú)縫集成大文件存在遠(yuǎn)端存儲(chǔ)Git里只存元數(shù)據(jù)。基本用法# 初始化DVC dvc init # 添加數(shù)據(jù)文件到DVC管理 dvc add data/raw/train.csv # 提交DVC元數(shù)據(jù)到Git git add data/raw/train.csv.dvc data/raw/.gitignore git commit -m add training data v1 # 推送數(shù)據(jù)到遠(yuǎn)端存儲(chǔ) dvc remote add -d storage s3://my-bucket/dvc-store dvc push這樣每次實(shí)驗(yàn)都能精確對(duì)應(yīng)到數(shù)據(jù)版本。當(dāng)你發(fā)現(xiàn)三個(gè)月前那個(gè)效果特別好的模型時(shí)能一鍵還原當(dāng)時(shí)的數(shù)據(jù)。實(shí)操心得DVC的緩存機(jī)制會(huì)占用大量本地磁盤(pán)建議定期執(zhí)行dvc gc清理不再需要的緩存。另外遠(yuǎn)端存儲(chǔ)建議用對(duì)象存儲(chǔ)而不是NFS性能和可靠性都好很多。3.2 數(shù)據(jù)清洗的工程化方法數(shù)據(jù)清洗不是寫(xiě)個(gè)Jupyter Notebook跑一遍就完事它需要工程化。核心原則是清洗邏輯要可復(fù)用、可測(cè)試、可追溯。我一般把清洗分成三個(gè)階段階段一數(shù)據(jù)探查。用Pandas Profiling或Great Expectations這類工具自動(dòng)生成數(shù)據(jù)質(zhì)量報(bào)告。重點(diǎn)看缺失值比例、異常值分布、類別不平衡程度。這一步在Notebook里做就行目的是了解數(shù)據(jù)長(zhǎng)什么樣。階段二清洗規(guī)則定義。把探查階段發(fā)現(xiàn)的每個(gè)問(wèn)題轉(zhuǎn)化成一條明確的規(guī)則。比如“age字段不能為負(fù)數(shù)”、“category字段只能是A/B/C三種值”。這些規(guī)則用代碼寫(xiě)出來(lái)放在src/data/validators.py里。階段三清洗流水線。把規(guī)則串成流水線用Airflow或Prefect這類工具調(diào)度。每次新數(shù)據(jù)進(jìn)來(lái)自動(dòng)跑一遍清洗輸出清洗報(bào)告。# src/data/cleaners.py import pandas as pd from typing import Dict, Any class DataCleaner: def __init__(self, config: Dict[str, Any]): self.config config def remove_duplicates(self, df: pd.DataFrame) - pd.DataFrame: 去重保留第一條 before len(df) df df.drop_duplicates(subsetself.config[dedup_keys]) after len(df) print(f去重: {before} - {after}, 移除 {before - after} 條) return df def handle_missing(self, df: pd.DataFrame) - pd.DataFrame: 處理缺失值 for col, strategy in self.config[missing_strategy].items(): if strategy drop: df df.dropna(subset[col]) elif strategy mean: df[col] df[col].fillna(df[col].mean()) elif strategy median: df[col] df[col].fillna(df[col].median()) elif strategy.startswith(constant:): value strategy.split(:)[1] df[col] df[col].fillna(value) return df def clip_outliers(self, df: pd.DataFrame) - pd.DataFrame: 截?cái)喈惓Ｖ?for col, (lower, upper) in self.config[clip_ranges].items(): df[col] df[col].clip(lower, upper) return df注意清洗規(guī)則一定要寫(xiě)單元測(cè)試。我踩過(guò)的坑是某次改了清洗邏輯導(dǎo)致某個(gè)字段的分布完全變了但因?yàn)闆](méi)有測(cè)試直到模型效果暴跌才發(fā)現(xiàn)?，F(xiàn)在我的習(xí)慣是每條清洗規(guī)則至少配一個(gè)測(cè)試用例。3.3 特征存儲(chǔ)從混亂到有序當(dāng)項(xiàng)目從單模型發(fā)展到多模型時(shí)特征管理就會(huì)變成噩夢(mèng)。同一個(gè)特征推薦模型算一遍風(fēng)控模型又算一遍兩邊邏輯還不一致。這時(shí)候就需要特征存儲(chǔ)Feature Store。特征存儲(chǔ)的核心價(jià)值是特征復(fù)用和一致性保證。訓(xùn)練時(shí)用的特征和推理時(shí)用的特征必須來(lái)自同一套計(jì)算邏輯否則會(huì)出現(xiàn)訓(xùn)練-服務(wù)偏差Training-Serving Skew。我推薦用Feast作為特征存儲(chǔ)方案它輕量、開(kāi)源、和主流框架集成好。基本架構(gòu)是離線存儲(chǔ)存歷史特征用于訓(xùn)練。一般用Parquet文件或數(shù)據(jù)倉(cāng)庫(kù)。在線存儲(chǔ)存最新特征用于推理。一般用Redis或DynamoDB。特征定義用Python代碼定義特征的計(jì)算邏輯保證線上線下一致。# feature_repo/features.py from feast import Entity, Feature, FeatureView, FileSource from feast.types import Float32, Int64 from datetime import timedelta # 定義實(shí)體 user Entity(nameuser_id, join_keys[user_id]) # 定義數(shù)據(jù)源 user_stats_source FileSource( pathdata/user_stats.parquet, timestamp_fieldevent_timestamp, ) # 定義特征視圖 user_stats_fv FeatureView( nameuser_stats, entities[user], ttltimedelta(days7), schema[ Feature(nametotal_orders, dtypeInt64), Feature(nameavg_order_value, dtypeFloat32), Feature(namedays_since_last_order, dtypeInt64), ], sourceuser_stats_source, )這樣定義之后訓(xùn)練時(shí)用get_historical_features拿歷史特征推理時(shí)用get_online_features拿實(shí)時(shí)特征兩邊邏輯完全一致。4. 訓(xùn)練流水線從手動(dòng)腳本到自動(dòng)化系統(tǒng)4.1 實(shí)驗(yàn)管理讓每次實(shí)驗(yàn)都可追溯沒(méi)有實(shí)驗(yàn)管理的團(tuán)隊(duì)工作狀態(tài)是這樣的小王跑了個(gè)模型準(zhǔn)確率92%很高興地跟組長(zhǎng)匯報(bào)。組長(zhǎng)問(wèn)“用的什么超參數(shù)”小王說(shuō)“等我翻一下Notebook。”翻了半小時(shí)找到了但發(fā)現(xiàn)那個(gè)Notebook后來(lái)又被改過(guò)已經(jīng)復(fù)現(xiàn)不出來(lái)了。實(shí)驗(yàn)管理要解決的就是這個(gè)問(wèn)題。核心要求是任何一次實(shí)驗(yàn)結(jié)果都能精確復(fù)現(xiàn)。這意味著要記錄代碼版本、數(shù)據(jù)版本、超參數(shù)、環(huán)境依賴、隨機(jī)種子、硬件信息。我常用的方案是MLflow它輕量、易用、功能全?；居梅╥mport mlflow import mlflow.pytorch # 設(shè)置實(shí)驗(yàn) mlflow.set_experiment(my-ai-project) with mlflow.start_run(run_namebaseline-v1): # 記錄超參數(shù) mlflow.log_params({ learning_rate: 1e-4, batch_size: 32, epochs: 50, optimizer: adamw, }) # 記錄指標(biāo) for epoch in range(50): train_loss train_one_epoch() val_loss, val_acc validate() mlflow.log_metrics({ train_loss: train_loss, val_loss: val_loss, val_acc: val_acc, }, stepepoch) # 記錄模型 mlflow.pytorch.log_model(model, model) # 記錄數(shù)據(jù)版本 mlflow.log_param(data_version, v1.2.0) mlflow.log_param(git_commit, get_git_commit())實(shí)操心得MLflow的Tracking Server建議單獨(dú)部署不要用本地文件存儲(chǔ)。團(tuán)隊(duì)協(xié)作時(shí)所有人都往同一個(gè)Server打點(diǎn)才能對(duì)比實(shí)驗(yàn)。另外模型文件不要直接存MLflow存到對(duì)象存儲(chǔ)MLflow里只存路徑。4.2 分布式訓(xùn)練什么時(shí)候需要怎么選分布式訓(xùn)練不是銀彈。很多場(chǎng)景下單卡就夠用硬上分布式反而增加復(fù)雜度和故障率。我的判斷標(biāo)準(zhǔn)是單卡能訓(xùn)完且時(shí)間可接受比如8小時(shí)內(nèi)單卡單卡訓(xùn)不完或時(shí)間太長(zhǎng)上分布式模型大到單卡放不下必須分布式分布式訓(xùn)練有三種主流方案數(shù)據(jù)并行Data Parallelism每個(gè)GPU持有完整模型副本數(shù)據(jù)切分到各GPU梯度匯總后更新。適合模型能放進(jìn)單卡顯存、但數(shù)據(jù)量大的場(chǎng)景。PyTorch的DDP是標(biāo)準(zhǔn)方案。模型并行Model Parallelism模型切分到多個(gè)GPU每個(gè)GPU持有部分層。適合模型大到單卡放不下的場(chǎng)景。實(shí)現(xiàn)復(fù)雜一般用Megatron-LM或DeepSpeed。流水線并行Pipeline Parallelism模型按層切分成多個(gè)階段不同階段在不同GPU上數(shù)據(jù)像流水線一樣流過(guò)。適合超大規(guī)模模型。PyTorch的Pipe是入門(mén)方案。實(shí)際項(xiàng)目中最常見(jiàn)的是數(shù)據(jù)并行混合精度。下面是一個(gè)DDP的啟動(dòng)腳本# 單機(jī)8卡訓(xùn)練 torchrun --nproc_per_node8 \ --master_port29500 \ src/training/train.py \ --config configs/train.yaml \ --batch_size 64 \ --learning_rate 1e-4# src/training/train.py 關(guān)鍵部分 import torch.distributed as dist from torch.nn.parallel import DistributedDataParallel as DDP def setup_ddp(): dist.init_process_group(backendnccl) local_rank int(os.environ[LOCAL_RANK]) torch.cuda.set_device(local_rank) return local_rank def main(): local_rank setup_ddp() model MyModel().to(local_rank) model DDP(model, device_ids[local_rank]) # 數(shù)據(jù)加載器要用DistributedSampler sampler DistributedSampler(dataset) dataloader DataLoader(dataset, samplersampler, batch_size...) for epoch in range(epochs): sampler.set_epoch(epoch) # 重要每個(gè)epoch要重新shuffle for batch in dataloader: ...注意DDP下只有rank 0的進(jìn)程應(yīng)該做日志記錄和模型保存否則會(huì)重復(fù)寫(xiě)文件導(dǎo)致沖突。另外sampler.set_epoch(epoch)這行很容易漏漏了的話每個(gè)epoch的數(shù)據(jù)順序都一樣影響訓(xùn)練效果。4.3 超參數(shù)調(diào)優(yōu)別再用網(wǎng)格搜索了超參數(shù)調(diào)優(yōu)是很多團(tuán)隊(duì)的痛點(diǎn)。網(wǎng)格搜索太慢隨機(jī)搜索碰運(yùn)氣手動(dòng)調(diào)參靠經(jīng)驗(yàn)。我推薦用貝葉斯優(yōu)化工具選Optuna。Optuna的核心優(yōu)勢(shì)是用更少的試驗(yàn)次數(shù)找到更好的參數(shù)。它通過(guò)建立代理模型預(yù)測(cè)哪些參數(shù)組合可能更好從而指導(dǎo)下一步搜索方向。import optuna def objective(trial): # 定義搜索空間 lr trial.suggest_float(lr, 1e-5, 1e-2, logTrue) batch_size trial.suggest_categorical(batch_size, [16, 32, 64, 128]) dropout trial.suggest_float(dropout, 0.1, 0.5) num_layers trial.suggest_int(num_layers, 2, 8) # 訓(xùn)練模型 model build_model(num_layers, dropout) val_acc train_and_evaluate(model, lr, batch_size) return val_acc # 創(chuàng)建study study optuna.create_study( directionmaximize, sampleroptuna.samplers.TPESampler(seed42), pruneroptuna.pruners.MedianPruner(n_startup_trials5), ) # 開(kāi)始優(yōu)化 study.optimize(objective, n_trials100, timeout3600*8) # 輸出最佳參數(shù) print(fBest trial: {study.best_trial.params})實(shí)操心得Optuna的Pruner功能非常有用。它會(huì)在訓(xùn)練過(guò)程中自動(dòng)終止那些明顯不好的試驗(yàn)節(jié)省大量算力。我一般設(shè)置n_startup_trials5讓前5個(gè)試驗(yàn)完整跑完之后才開(kāi)始剪枝。另外搜索空間的定義很關(guān)鍵范圍不要設(shè)太寬否則大部分試驗(yàn)都在無(wú)效區(qū)域浪費(fèi)算力。5. 模型部署與服務(wù)化讓模型真正產(chǎn)生價(jià)值5.1 推理優(yōu)化從100ms到10ms的實(shí)戰(zhàn)路徑模型訓(xùn)出來(lái)只是第一步能不能高效推理才是關(guān)鍵。我做過(guò)一個(gè)項(xiàng)目原始模型推理延遲120ms經(jīng)過(guò)一系列優(yōu)化后降到8ms提升了15倍。下面是我用的優(yōu)化路徑第一步模型量化。把FP32轉(zhuǎn)成FP16或INT8顯存占用減半推理速度提升1.5-2倍。PyTorch的torch.quantization或ONNX Runtime的量化工具都能做。# PyTorch動(dòng)態(tài)量化 import torch.quantization model MyModel() model.eval() quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, dtypetorch.qint8 ) torch.save(quantized_model.state_dict(), model_quantized.pt)第二步算子融合。把多個(gè)連續(xù)的小算子合并成一個(gè)減少kernel launch開(kāi)銷。TensorRT和ONNX Runtime都有自動(dòng)融合功能。第三步推理引擎優(yōu)化。用TensorRT或ONNX Runtime替換原生PyTorch推理。這一步通常能帶來(lái)2-3倍的提升。# ONNX Runtime推理 import onnxruntime as ort import numpy as np # 導(dǎo)出ONNX torch.onnx.export(model, dummy_input, model.onnx, opset_version13) # 創(chuàng)建推理會(huì)話 session ort.InferenceSession( model.onnx, providers[CUDAExecutionProvider], ) # 推理 input_name session.get_inputs()[0].name output session.run(None, {input_name: input_data})第四步批處理。把多個(gè)請(qǐng)求攢成一批一起推理GPU利用率能提升好幾倍。但要注意延遲和吞吐的權(quán)衡。第五步緩存。對(duì)于重復(fù)的輸入直接返回緩存結(jié)果。這個(gè)在推薦系統(tǒng)里特別有效熱門(mén)物品的embedding可以緩存。優(yōu)化手段延遲降低實(shí)現(xiàn)難度適用場(chǎng)景FP16量化1.5-2x低所有GPU場(chǎng)景INT8量化2-4x中對(duì)精度不敏感場(chǎng)景算子融合1.2-1.5x低所有場(chǎng)景TensorRT2-3x中NVIDIA GPU批處理3-5x中高吞吐場(chǎng)景緩存10x低重復(fù)輸入多5.2 服務(wù)化框架選型FastAPI vs Triton vs TorchServe模型服務(wù)化框架的選擇直接決定了你的運(yùn)維復(fù)雜度。我三個(gè)都用過(guò)說(shuō)說(shuō)各自的適用場(chǎng)景。FastAPI最靈活適合自定義邏輯多的場(chǎng)景。你可以完全控制請(qǐng)求處理流程做各種預(yù)處理和后處理。缺點(diǎn)是性能一般高并發(fā)下需要自己優(yōu)化。from fastapi import FastAPI import torch app FastAPI() model load_model() app.post(/predict) async def predict(request: PredictRequest): # 預(yù)處理 input_tensor preprocess(request.data) # 推理 with torch.no_grad(): output model(input_tensor) # 后處理 result postprocess(output) return {prediction: result}Triton Inference ServerNVIDIA出品性能最強(qiáng)支持多框架、多模型、動(dòng)態(tài)批處理。適合大規(guī)模部署場(chǎng)景。缺點(diǎn)是需要寫(xiě)配置文件靈活性不如FastAPI。TorchServePyTorch官方方案和PyTorch生態(tài)集成好。適合純PyTorch模型的部署。缺點(diǎn)是社區(qū)活躍度一般遇到問(wèn)題不好找資料。我的建議是小規(guī)模用FastAPI大規(guī)模用Triton純PyTorch生態(tài)用TorchServe。不要一上來(lái)就上Triton它的學(xué)習(xí)曲線不陡但也不平小項(xiàng)目用它是殺雞用牛刀。5.3 灰度發(fā)布與回滾上線不是終點(diǎn)模型上線最怕的是什么是新模型效果不如舊模型但你已經(jīng)全量發(fā)布了。所以灰度發(fā)布是必須的。我的做法是分三個(gè)階段階段一影子模式Shadow Mode。新模型和舊模型同時(shí)運(yùn)行但只有舊模型的結(jié)果返回給用戶。新模型的結(jié)果只記錄不生效。這個(gè)階段跑一周對(duì)比兩個(gè)模型的輸出差異。階段二小流量灰度。把1%的流量切給新模型觀察核心指標(biāo)。如果指標(biāo)沒(méi)有明顯下降逐步擴(kuò)大到5%、10%、50%。階段三全量發(fā)布。灰度到100%后舊模型保留一周作為回滾備份確認(rèn)沒(méi)問(wèn)題后再下線。# 灰度發(fā)布邏輯 import random def route_request(user_id: str) - str: 根據(jù)用戶ID決定用哪個(gè)模型 # 用user_id的hash做分流保證同一用戶始終用同一模型 bucket hash(user_id) % 100 if bucket current_gray_ratio: return new_model else: return old_model注意分流要用user_id的hash不要用隨機(jī)數(shù)。否則同一用戶一會(huì)兒用新模型一會(huì)兒用舊模型體驗(yàn)會(huì)非常割裂。另外灰度比例要?jiǎng)討B(tài)可調(diào)不要寫(xiě)死在代碼里。6. 監(jiān)控與迭代讓系統(tǒng)持續(xù)進(jìn)化6.1 數(shù)據(jù)漂移檢測(cè)模型效果下降的預(yù)警器模型上線后效果下降最常見(jiàn)的原因是數(shù)據(jù)漂移。輸入數(shù)據(jù)的分布變了模型還按老規(guī)律預(yù)測(cè)自然就不準(zhǔn)了。數(shù)據(jù)漂移檢測(cè)的核心是對(duì)比訓(xùn)練數(shù)據(jù)和線上數(shù)據(jù)的分布。常用的方法有PSIPopulation Stability Index衡量?jī)蓚€(gè)分布的差異PSI0.1表示穩(wěn)定0.1-0.25表示輕微漂移0.25表示顯著漂移。KS檢驗(yàn)統(tǒng)計(jì)兩個(gè)分布是否有顯著差異。KL散度衡量?jī)蓚€(gè)概率分布的差異。import numpy as np from scipy import stats def calculate_psi(expected, actual, buckets10): 計(jì)算PSI # 分桶 breakpoints np.percentile(expected, np.linspace(0, 100, buckets 1)) breakpoints[0] -np.inf breakpoints[-1] np.inf expected_percents np.histogram(expected, breakpoints)[0] / len(expected) actual_percents np.histogram(actual, breakpoints)[0] / len(actual) # 避免除零 expected_percents np.clip(expected_percents, 1e-6, None) actual_percents np.clip(actual_percents, 1e-6, None) psi np.sum((actual_percents - expected_percents) * np.log(actual_percents / expected_percents)) return psi # 使用 psi calculate_psi(train_data[feature_1], online_data[feature_1]) if psi 0.25: alert(特征feature_1發(fā)生顯著漂移PSI{:.3f}.format(psi))實(shí)操心得PSI對(duì)分桶數(shù)量敏感一般用10-20個(gè)桶。另外不要對(duì)所有特征都設(shè)同樣的閾值有些特征天然波動(dòng)大閾值要放寬。我一般先跑一周基線看每個(gè)特征PSI的正常波動(dòng)范圍再定閾值。6.2 模型性能監(jiān)控不只是準(zhǔn)確率模型上線后準(zhǔn)確率不是唯一要看的指標(biāo)。我一般會(huì)監(jiān)控四類指標(biāo)業(yè)務(wù)指標(biāo)點(diǎn)擊率、轉(zhuǎn)化率、GMV等。這是最終目標(biāo)但反饋慢不能作為唯一依據(jù)。模型指標(biāo)準(zhǔn)確率、召回率、AUC等。需要標(biāo)注數(shù)據(jù)才能算有延遲。系統(tǒng)指標(biāo)QPS、延遲、錯(cuò)誤率、GPU利用率。實(shí)時(shí)性強(qiáng)能快速發(fā)現(xiàn)問(wèn)題。數(shù)據(jù)指標(biāo)特征分布、缺失率、異常值比例。能提前預(yù)警數(shù)據(jù)問(wèn)題。這四類指標(biāo)要放在同一個(gè)Dashboard上看才能快速定位問(wèn)題。比如業(yè)務(wù)指標(biāo)下降同時(shí)數(shù)據(jù)指標(biāo)顯示某個(gè)特征漂移了那大概率是數(shù)據(jù)問(wèn)題。6.3 持續(xù)訓(xùn)練讓模型跟上變化模型不是訓(xùn)一次就完事需要持續(xù)迭代。持續(xù)訓(xùn)練的核心是自動(dòng)化和安全。自動(dòng)化指的是數(shù)據(jù)更新后自動(dòng)觸發(fā)訓(xùn)練訓(xùn)練完成后自動(dòng)評(píng)估評(píng)估通過(guò)后自動(dòng)部署。這個(gè)流水線用Airflow或Kubeflow Pipelines搭建。安全指的是新模型必須經(jīng)過(guò)嚴(yán)格評(píng)估才能上線。我一般設(shè)三道關(guān)卡離線評(píng)估在留出集上新模型的核心指標(biāo)必須不低于舊模型的95%?；貧w測(cè)試在一組固定的測(cè)試用例上新模型的輸出不能有異常變化。影子測(cè)試新模型和舊模型并行跑24小時(shí)輸出差異在可接受范圍內(nèi)。三道關(guān)卡都通過(guò)才允許灰度發(fā)布。# 持續(xù)訓(xùn)練流水線偽代碼 def continuous_training_pipeline(): # 1. 檢查數(shù)據(jù)更新 if not new_data_available(): return # 2. 數(shù)據(jù)清洗和驗(yàn)證 cleaned_data clean_and_validate(new_data) # 3. 訓(xùn)練新模型 new_model train(cleaned_data) # 4. 離線評(píng)估 metrics evaluate(new_model, test_set) if metrics[auc] baseline[auc] * 0.95: alert(新模型效果不達(dá)標(biāo)終止發(fā)布) return # 5. 回歸測(cè)試 if not regression_test(new_model): alert(回歸測(cè)試失敗終止發(fā)布) return # 6. 影子測(cè)試 shadow_test(new_model, duration_hours24) # 7. 灰度發(fā)布 gradual_rollout(new_model)7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 訓(xùn)練相關(guān)的高頻問(wèn)題問(wèn)題一Loss不下降或震蕩嚴(yán)重排查思路先看學(xué)習(xí)率是不是太大用學(xué)習(xí)率掃描找合適值。再看數(shù)據(jù)有沒(méi)有問(wèn)題比如標(biāo)簽錯(cuò)了、特征沒(méi)歸一化。最后看模型結(jié)構(gòu)是不是太深或太淺。我踩過(guò)的坑有一次loss一直震蕩調(diào)了一周參數(shù)都沒(méi)用最后發(fā)現(xiàn)是數(shù)據(jù)里混了一批錯(cuò)誤標(biāo)注的樣本。所以遇到問(wèn)題先查數(shù)據(jù)再查模型。問(wèn)題二過(guò)擬合排查思路看訓(xùn)練loss和驗(yàn)證loss的差距。差距大就是過(guò)擬合。解決方法加正則化、加dropout、加數(shù)據(jù)增強(qiáng)、減小模型。問(wèn)題三顯存不夠排查思路先看batch size能不能減。再看能不能用梯度累積。再看能不能用混合精度。最后看能不能用梯度檢查點(diǎn)。# 梯度累積示例 accumulation_steps 4 optimizer.zero_grad() for i, batch in enumerate(dataloader): output model(batch) loss criterion(output, batch[label]) loss loss / accumulation_steps # 歸一化 loss.backward() if (i 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()7.2 部署相關(guān)的高頻問(wèn)題問(wèn)題一推理延遲高排查思路先看是不是模型太大考慮量化或蒸餾。再看是不是批處理沒(méi)開(kāi)開(kāi)批處理。再看是不是CPU推理?yè)QGPU。最后看是不是預(yù)處理太慢優(yōu)化預(yù)處理。問(wèn)題二內(nèi)存泄漏排查思路用memory_profiler定位泄漏點(diǎn)。常見(jiàn)原因是全局變量累積、緩存沒(méi)清理、循環(huán)引用。問(wèn)題三服務(wù)不穩(wěn)定排查思路看日志、看監(jiān)控、看資源使用。常見(jiàn)原因是并發(fā)太高、超時(shí)設(shè)置不合理、依賴服務(wù)掛了。7.3 問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案Loss不下降學(xué)習(xí)率過(guò)大/數(shù)據(jù)問(wèn)題學(xué)習(xí)率掃描/數(shù)據(jù)檢查調(diào)小學(xué)習(xí)率/清洗數(shù)據(jù)過(guò)擬合模型太復(fù)雜/數(shù)據(jù)太少對(duì)比訓(xùn)練驗(yàn)證loss加正則/加數(shù)據(jù)顯存不夠batch太大/模型太大nvidia-smi監(jiān)控減batch/梯度累積/混合精度推理延遲高模型大/沒(méi)批處理分階段計(jì)時(shí)量化/批處理/換引擎內(nèi)存泄漏全局變量/緩存memory_profiler清理全局變量/加緩存淘汰數(shù)據(jù)漂移線上數(shù)據(jù)分布變了PSI/KS檢驗(yàn)重新訓(xùn)練/加漂移檢測(cè)最后分享一個(gè)小技巧遇到任何問(wèn)題先復(fù)現(xiàn)再定位最后解決。不要一上來(lái)就改代碼那樣只會(huì)引入新問(wèn)題。復(fù)現(xiàn)的意思是用最小的例子穩(wěn)定重現(xiàn)問(wèn)題。定位的意思是用二分法或日志逐步縮小問(wèn)題范圍。解決的意思是改完之后要驗(yàn)證問(wèn)題真的解決了而不是碰巧不出現(xiàn)了。這套AI工程體系我從零搭過(guò)三次每次都有新的體會(huì)。第一次搭的時(shí)候追求技術(shù)先進(jìn)什么新用什么結(jié)果運(yùn)維成本高到離譜。第二次搭的時(shí)候追求簡(jiǎn)單結(jié)果擴(kuò)展性不夠業(yè)務(wù)一增長(zhǎng)就要重構(gòu)。第三次才找到平衡點(diǎn)夠用就好留好擴(kuò)展接口。技術(shù)選型沒(méi)有絕對(duì)的對(duì)錯(cuò)只有適不適合當(dāng)下的場(chǎng)景。希望這些經(jīng)驗(yàn)?zāi)軒湍闵僮咭恍澛贰?