從零搭建AI工程能力這件事我前前后后折騰過好幾輪。最早的時候我也走過彎路——買了一堆講Transformer推導(dǎo)的書把注意力機制的公式背得滾瓜爛熟結(jié)果真到要上線一個文本分類服務(wù)的時候連推理延遲怎么壓、顯存怎么省、模型版本怎么管都一頭霧水。后來我才想明白一件事AI工程不是機器學(xué)習(xí)理論的延伸它是一門獨立的工程學(xué)科核心矛盾在于“模型的不確定性與工程系統(tǒng)的確定性要求之間的沖突”。這篇內(nèi)容就是把我這些年從零構(gòu)建AI工程能力體系的過程拆開講從底層原理到落地實操適合那些已經(jīng)會調(diào)API、但想真正搞懂“一個AI系統(tǒng)是怎么被工程化地搭起來”的開發(fā)者。1. 先搞清楚AI工程到底在工程什么1.1 它和傳統(tǒng)軟件工程的根本分歧在哪傳統(tǒng)軟件工程里輸入是確定的邏輯是確定的輸出也是確定的。你寫一個訂單金額計算函數(shù)給定輸入輸出永遠(yuǎn)一致。但AI系統(tǒng)不是這樣——同一個輸入模型可能給出不同的輸出尤其是生成式模型而且你很難用單元測試去斷言“這個輸出是對的”。這就引出了AI工程最核心的幾個工程問題概率性輸出的可測試性你沒法寫assert output expected只能寫“輸出在某個可接受范圍內(nèi)”或者“輸出不包含某些違規(guī)內(nèi)容”。數(shù)據(jù)依賴的隱蔽性傳統(tǒng)軟件的bug在代碼里AI系統(tǒng)的bug可能在訓(xùn)練數(shù)據(jù)里、在特征管道里、在推理時的預(yù)處理邏輯里。性能瓶頸的轉(zhuǎn)移傳統(tǒng)后端瓶頸通常在IO或數(shù)據(jù)庫AI系統(tǒng)的瓶頸可能在GPU顯存、在批處理策略、在tokenizer的效率上。我踩過最典型的一個坑早期做一個情感分析服務(wù)離線評估準(zhǔn)確率92%上線后用戶投訴不斷。排查了兩天才發(fā)現(xiàn)訓(xùn)練時的文本預(yù)處理用了jieba分詞而線上服務(wù)為了圖快直接按空格切詞中文根本沒空格等于把整句話當(dāng)成一個token喂進(jìn)去了。這個bug不在模型里不在代碼邏輯里在“訓(xùn)練和推理的預(yù)處理不一致”這個工程縫隙里。所以AI工程的第一課不是學(xué)模型是學(xué)“怎么讓一個概率系統(tǒng)在確定性的工程約束下穩(wěn)定運行”。1.2 從零構(gòu)建需要覆蓋的五個能力層我把AI工程能力拆成五層從下往上依次是層級能力域典型工作內(nèi)容常見工具L1環(huán)境與依賴管理GPU驅(qū)動、CUDA版本、Python環(huán)境隔離conda、docker、poetryL2數(shù)據(jù)處理管道數(shù)據(jù)清洗、特征工程、數(shù)據(jù)集版本管理pandas、DVC、Great ExpectationsL3模型訓(xùn)練與微調(diào)訓(xùn)練循環(huán)、超參管理、分布式訓(xùn)練PyTorch、Lightning、wandbL4推理服務(wù)化模型導(dǎo)出、服務(wù)框架、批處理、量化ONNX、Triton、vLLML5運維與監(jiān)控日志、指標(biāo)、漂移檢測、A/B測試Prometheus、Grafana、Evidently很多人一上來就扎進(jìn)L3覺得訓(xùn)模型才是“AI”結(jié)果L1的環(huán)境問題就能卡一周L4的服務(wù)化更是完全沒概念。我的建議是從L1和L4兩頭往中間做——先把環(huán)境搞穩(wěn)、把推理服務(wù)跑通再回頭補訓(xùn)練和數(shù)據(jù)的細(xì)節(jié)。因為推理服務(wù)是最終交付物先看到交付物的樣子你才知道中間每一步是為了什么。1.3 一個最小可用的AI工程骨架長什么樣在展開每一層之前先給你一個我常用的最小骨架讓你有個全局感project/ ├── configs/ # 所有配置不硬編碼 │ ├── train.yaml │ └── serve.yaml ├── data/ # 數(shù)據(jù)版本管理 │ ├── raw/ │ └── processed/ ├── src/ │ ├── data/ # 數(shù)據(jù)處理 │ ├── model/ # 模型定義 │ ├── train/ # 訓(xùn)練邏輯 │ └── serve/ # 推理服務(wù) ├── tests/ # 測試包括數(shù)據(jù)測試 ├── docker/ # 環(huán)境固化 └── Makefile # 一鍵復(fù)現(xiàn)這個骨架的關(guān)鍵設(shè)計原則是配置與代碼分離、數(shù)據(jù)與代碼分離、訓(xùn)練與推理共享同一套預(yù)處理代碼。最后一條尤其重要前面那個分詞不一致的坑根源就是訓(xùn)練和推理各寫了一套預(yù)處理。2. 環(huán)境與依賴為什么你的CUDA總是裝不對2.1 CUDA版本地獄的本質(zhì)原因新手最容易被CUDA折磨。你裝了個PyTorch提示CUDA版本不匹配換了個版本又和驅(qū)動不兼容。這個問題的本質(zhì)是三層版本必須嚴(yán)格對齊GPU驅(qū)動版本決定了你最高能支持的CUDA版本向下兼容CUDA Toolkit版本PyTorch等框架編譯時依賴的版本框架版本PyTorch/TensorFlow各自綁定了特定的CUDA版本它們的關(guān)系是驅(qū)動版本 ≥ 框架要求的CUDA版本。比如你的驅(qū)動支持到CUDA 12.4那你可以跑CUDA 11.8編譯的PyTorch但不能跑CUDA 12.6編譯的。我常用的排查命令# 查看驅(qū)動支持的CUDA版本 nvidia-smi # 查看當(dāng)前CUDA Toolkit版本 nvcc --version # 查看PyTorch實際使用的CUDA版本 python -c import torch; print(torch.version.cuda)注意nvidia-smi顯示的CUDA版本是驅(qū)動支持的最高版本不是你實際安裝的版本。很多人看到這個數(shù)字就以為裝對了其實不是。2.2 用容器把環(huán)境問題一次性解決我現(xiàn)在的做法是本地只裝驅(qū)動所有Python環(huán)境和CUDA都跑在容器里。這樣換機器、換項目都不會互相污染。一個典型的Dockerfile片段FROM nvidia/cuda:12.1.0-cudnn8-runtime-ubuntu22.04 RUN apt-get update apt-get install -y python3.10 python3-pip RUN pip install torch2.2.0 --index-url https://download.pytorch.org/whl/cu121 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt這里有個經(jīng)驗基礎(chǔ)鏡像選runtime而不是devel除非你需要編譯CUDA算子。runtime鏡像小很多部署時拉取快。另外cudnn版本也要和CUDA對齊12.1.0-cudnn8這種tag就是官方幫你配好的組合。2.3 依賴鎖定別讓“昨天還能跑”變成玄學(xué)Python依賴的坑在于pip install默認(rèn)裝最新版今天能跑的代碼明天可能就崩了。我的做法是用poetry或pip-tools生成鎖定文件poetry.lock/requirements.txt帶精確版本號區(qū)分requirements.in寬松約束和requirements.txt精確鎖定CI里用鎖定文件安裝保證本地和線上一致# 用pip-tools的流程 pip-compile requirements.in -o requirements.txt # 生成鎖定 pip-sync requirements.txt # 按鎖定安裝這套流程看起來麻煩但能省掉無數(shù)次“在我機器上是好的”的扯皮。3. 數(shù)據(jù)處理管道AI系統(tǒng)里最臟最累的活3.1 為什么數(shù)據(jù)管道值得單獨工程化我見過太多項目把數(shù)據(jù)處理寫成一個個散落的腳本clean.py、split.py、augment.py跑的時候靠記憶按順序執(zhí)行。這種做法的致命問題是不可復(fù)現(xiàn)——三個月后你想重新訓(xùn)練根本記不清當(dāng)時的數(shù)據(jù)是怎么處理的。數(shù)據(jù)管道工程化的核心目標(biāo)是給定原始數(shù)據(jù)和一份配置能一鍵復(fù)現(xiàn)出完全相同的訓(xùn)練集。這需要三個東西數(shù)據(jù)版本管理原始數(shù)據(jù)、處理后數(shù)據(jù)都要有版本標(biāo)識處理邏輯代碼化每一步轉(zhuǎn)換都是可測試的函數(shù)數(shù)據(jù)校驗處理前后自動檢查數(shù)據(jù)質(zhì)量3.2 用DVC做數(shù)據(jù)版本管理Git管代碼DVC管數(shù)據(jù)?；居梅╠vc init dvc add data/raw/dataset.csv # 生成dataset.csv.dvc指針文件 git add data/raw/dataset.csv.dvc data/raw/.gitignore git commit -m add raw dataset v1DVC會把大文件存到遠(yuǎn)程存儲S3、本地NAS都行Git里只留一個指針文件。這樣你切換Git分支時dvc checkout就能拿到對應(yīng)版本的數(shù)據(jù)。我踩過的坑DVC的緩存目錄默認(rèn)在項目內(nèi)容易把磁盤撐爆。建議一開始就配置外部緩存dvc cache dir /mnt/large-disk/dvc-cache3.3 數(shù)據(jù)校驗在訓(xùn)練前攔住臟數(shù)據(jù)數(shù)據(jù)問題如果等到訓(xùn)練完才發(fā)現(xiàn)浪費的是幾小時甚至幾天的GPU時間。我習(xí)慣在管道里加一層校驗用pydantic或Great Expectations都行。一個輕量做法是用pydantic定義數(shù)據(jù)schemafrom pydantic import BaseModel, validator class TrainingSample(BaseModel): text: str label: int validator(text) def text_not_empty(cls, v): if not v.strip(): raise ValueError(text不能為空) return v validator(label) def label_in_range(cls, v): if v not in (0, 1): raise ValueError(label必須是0或1) return v然后在數(shù)據(jù)加載時逐條校驗把不合規(guī)的樣本記錄下來而不是直接丟棄——丟棄會讓你丟失數(shù)據(jù)分布的信息記錄下來才能分析是采集問題還是標(biāo)注問題。3.4 訓(xùn)練/推理預(yù)處理必須共享代碼回到開頭那個分詞坑。解決方案是把預(yù)處理邏輯抽成一個獨立模塊訓(xùn)練和推理都import它# src/data/preprocess.py def preprocess_text(text: str) - str: 訓(xùn)練和推理共用的預(yù)處理 text text.strip().lower() tokens jieba.lcut(text) return .join(tokens)訓(xùn)練腳本和推理服務(wù)都調(diào)用這個函數(shù)。任何預(yù)處理邏輯的修改都必須同時影響訓(xùn)練和推理否則就會出現(xiàn)訓(xùn)練-推理偏差training-serving skew。這是AI工程里最隱蔽也最致命的一類bug。4. 訓(xùn)練工程化讓實驗可復(fù)現(xiàn)、可比較4.1 配置管理告別硬編碼超參新手寫訓(xùn)練腳本超參直接寫在代碼里lr 1e-4 batch_size 32 epochs 10改一次跑一次改多了自己都記不清哪個配置對應(yīng)哪個結(jié)果。正確做法是用配置文件# configs/train.yaml model: name: bert-base-chinese num_labels: 2 training: lr: 1e-4 batch_size: 32 epochs: 10 warmup_ratio: 0.1 data: train_path: data/processed/train.csv max_length: 128用hydra或omegaconf加載命令行還能覆蓋python train.py training.lr5e-5 training.batch_size64這樣每次實驗的完整配置都能被記錄下來配合wandb或mlflow實驗對比一目了然。4.2 實驗追蹤別靠腦子記結(jié)果我早期用Excel記實驗結(jié)果記到第20次就亂了。后來換成wandb每次訓(xùn)練自動記錄loss曲線、指標(biāo)、配置、甚至GPU利用率。關(guān)鍵代碼就幾行import wandb wandb.init(projectsentiment, configcfg) for epoch in range(epochs): train_loss train_one_epoch() val_f1 evaluate() wandb.log({train_loss: train_loss, val_f1: val_f1})實驗追蹤的價值不在于記錄而在于對比。當(dāng)你想知道“為什么這次比上次差”時能直接diff兩次實驗的配置差異而不是靠回憶。4.3 檢查點策略什么時候存、存什么模型檢查點不是越多越好占磁盤還容易搞混。我的策略是按驗證指標(biāo)存最優(yōu)只保留驗證集上表現(xiàn)最好的N個定期存每N個epoch存一次防止訓(xùn)練崩潰丟失進(jìn)度存完整狀態(tài)不只是模型權(quán)重還要存優(yōu)化器狀態(tài)、學(xué)習(xí)率調(diào)度器狀態(tài)、當(dāng)前epoch這樣才能斷點續(xù)訓(xùn)torch.save({ epoch: epoch, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict(), best_metric: best_metric, }, fcheckpoints/epoch_{epoch}.pt)提示斷點續(xù)訓(xùn)時優(yōu)化器狀態(tài)和調(diào)度器狀態(tài)必須一起恢復(fù)否則學(xué)習(xí)率曲線會錯亂訓(xùn)練效果可能明顯變差。4.4 分布式訓(xùn)練什么時候需要、怎么上手單卡能跑就別上分布式分布式調(diào)試成本高。判斷標(biāo)準(zhǔn)很簡單單卡跑一個epoch的時間 × 總epoch數(shù) 你能接受的等待時間就該考慮分布式了。PyTorch的DDPDistributedDataParallel是目前最成熟的選擇。核心改動import torch.distributed as dist from torch.nn.parallel import DistributedDataParallel as DDP dist.init_process_group(nccl) model model.to(local_rank) model DDP(model, device_ids[local_rank])配合torchrun啟動torchrun --nproc_per_node4 train.py踩過的坑DDP下每個進(jìn)程的隨機種子要不同否則數(shù)據(jù)增強會重復(fù)。還有驗證和保存檢查點只在rank 0上做否則會寫沖突。5. 推理服務(wù)化從模型文件到可用API5.1 模型導(dǎo)出為什么不能直接pickle訓(xùn)練完的PyTorch模型直接torch.save然后線上torch.load看起來能用但有幾個問題依賴訓(xùn)練代碼加載時需要模型類定義線上服務(wù)得把訓(xùn)練代碼也帶上性能差PyTorch的eager模式推理有額外開銷跨框架難想換推理引擎如TensorRT就卡住了更好的做法是導(dǎo)出成中間格式。ONNX是通用選擇torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{input_ids: {0: batch, 1: seq}}, opset_version14 )dynamic_axes很關(guān)鍵不設(shè)置的話batch size和序列長度會被固定死線上只能處理特定形狀的輸入。5.2 推理引擎選型ONNX Runtime vs Triton vs vLLM不同場景選不同引擎我整理了一個對比引擎適用場景優(yōu)勢局限ONNX Runtime中小模型、CPU/GPU通用輕量、易集成大模型支持一般Triton Inference Server多模型、多框架混合動態(tài)批處理、模型編排部署復(fù)雜vLLM大語言模型PagedAttention、高吞吐只支持LLM類我的經(jīng)驗判別式模型分類、NER用ONNX Runtime就夠了生成式大模型直接上vLLM。Triton適合模型多、需要統(tǒng)一管理的場景但學(xué)習(xí)曲線陡。5.3 動態(tài)批處理吞吐量的關(guān)鍵線上請求是零散到達(dá)的如果每個請求單獨推理GPU利用率極低。動態(tài)批處理把短時間內(nèi)到達(dá)的請求攢成一批一起推理# 簡化的動態(tài)批處理邏輯 class BatchScheduler: def __init__(self, max_batch_size32, max_wait_ms10): self.queue [] self.max_batch_size max_batch_size self.max_wait_ms max_wait_ms async def add_request(self, request): self.queue.append(request) if len(self.queue) self.max_batch_size: return await self.flush() await asyncio.sleep(self.max_wait_ms / 1000) return await self.flush()max_wait_ms是延遲和吞吐的權(quán)衡點設(shè)大了吞吐高但延遲高設(shè)小了反之。我一般從10ms起步根據(jù)實際P99延遲調(diào)整。5.4 量化用精度換顯存和速度模型量化把FP32權(quán)重壓成INT8甚至INT4顯存占用能降一半以上推理速度也能提升。常見做法from onnxruntime.quantization import quantize_dynamic quantize_dynamic( model.onnx, model_int8.onnx, weight_typeQuantType.QInt8 )注意量化會帶來精度損失必須在上線前用驗證集評估。我遇到過量化后F1掉3個點的情況這種就不能接受。一般分類任務(wù)掉1個點以內(nèi)可以接受生成任務(wù)要更謹(jǐn)慎。6. 監(jiān)控與運維上線只是開始6.1 模型監(jiān)控和傳統(tǒng)監(jiān)控的區(qū)別傳統(tǒng)服務(wù)監(jiān)控看QPS、延遲、錯誤率就夠了。AI服務(wù)還要額外看輸入分布漂移線上輸入的特征分布和訓(xùn)練時是否一致輸出分布漂移模型輸出的分布是否發(fā)生偏移預(yù)測置信度置信度整體下降往往預(yù)示模型失效我見過一個案例一個推薦模型上線三個月效果逐漸變差排查發(fā)現(xiàn)是用戶行為模式變了但模型沒重新訓(xùn)練。如果當(dāng)時監(jiān)控了輸入特征分布就能提前發(fā)現(xiàn)。6.2 用Evidently做漂移檢測Evidently是個輕量的漂移檢測庫幾行代碼就能生成報告from evidently.report import Report from evidently.metric_preset import DataDriftPreset report Report(metrics[DataDriftPreset()]) report.run(reference_datatrain_df, current_dataprod_df) report.save_html(drift_report.html)它會告訴你哪些特征發(fā)生了漂移、漂移程度如何。我一般設(shè)個閾值漂移超過閾值就觸發(fā)告警人工判斷是否需要重新訓(xùn)練。6.3 日志設(shè)計出問題時能查到什么AI服務(wù)的日志要比普通服務(wù)更詳細(xì)。我必記的字段請求ID用于追蹤單次請求全鏈路原始輸入脫敏后預(yù)處理后的輸入模型輸出和置信度推理耗時區(qū)分預(yù)處理、推理、后處理模型版本號logger.info({ request_id: req_id, model_version: v1.2.3, input_len: len(text), prediction: pred, confidence: conf, preprocess_ms: pre_ms, inference_ms: inf_ms, })模型版本號尤其重要出問題時第一件事就是確認(rèn)線上跑的是哪個版本以及這個版本是什么時候上線的。6.4 灰度發(fā)布與回滾模型更新不能全量直接上。我的做法是新模型先接5%流量觀察指標(biāo)指標(biāo)正常逐步放量到50%、100%任何指標(biāo)異常立即回滾到舊版本這要求服務(wù)支持多模型版本共存通過請求頭或配置決定走哪個版本。用Triton的話它原生支持多版本模型自己寫服務(wù)的話可以維護(hù)一個版本路由表。7. 一些讓我少走彎路的實操心得7.1 先跑通端到端再優(yōu)化每一環(huán)新手最容易犯的錯是“完美主義”——非要把數(shù)據(jù)處理做到極致才開始訓(xùn)練非要把模型調(diào)到SOTA才上線。我的建議是先用最粗糙的方式跑通端到端隨便清洗下數(shù)據(jù)、用現(xiàn)成模型、寫個最簡單的Flask服務(wù)。跑通之后你才知道瓶頸在哪再針對性優(yōu)化。我見過太多項目卡在“數(shù)據(jù)還沒準(zhǔn)備好”階段幾個月最后不了了之。7.2 測試要覆蓋數(shù)據(jù)而不只是代碼傳統(tǒng)測試測代碼邏輯AI工程還要測數(shù)據(jù)。我習(xí)慣加這幾類測試數(shù)據(jù)schema測試字段類型、取值范圍數(shù)據(jù)分布測試關(guān)鍵特征的均值、方差在合理范圍預(yù)處理一致性測試訓(xùn)練和推理的預(yù)處理函數(shù)輸出一致模型輸出測試給定固定輸入輸出在預(yù)期范圍不是精確相等def test_preprocess_consistency(): text 這個產(chǎn)品很好用 train_out preprocess_text(text) serve_out preprocess_text(text) assert train_out serve_out7.3 把“重新訓(xùn)練”做成一條命令模型需要定期重新訓(xùn)練如果每次都要手動跑一堆腳本遲早會出錯。我的目標(biāo)是一條命令完成從數(shù)據(jù)到部署的全流程retrain: dvc pull python src/data/process.py python src/train/train.py python src/serve/export.py docker build -t model-service:latest .用Makefile或Airflow都行關(guān)鍵是流程固化、可重復(fù)執(zhí)行。7.4 顯存不夠時的排查順序顯存OOM是高頻問題我的排查順序是batch size是不是太大先減半試試有沒有梯度累積的誤用梯度累積不省顯存只省batch維度中間激活有沒有及時釋放用del加torch.cuda.empty_cache()是不是用了混合精度AMP能省不少顯存模型本身是不是太大考慮量化或換小模型from torch.cuda.amp import autocast, GradScaler scaler GradScaler() with autocast(): output model(input) loss criterion(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()混合精度通常能省30%-50%顯存而且速度更快幾乎是無腦該開的選項。7.5 別忽視CPU側(cè)的瓶頸大家盯著GPU但很多時候瓶頸在CPUtokenizer太慢、數(shù)據(jù)加載是單線程、后處理邏輯復(fù)雜。我遇到過一個服務(wù)GPU利用率只有20%排查發(fā)現(xiàn)是tokenizer成了瓶頸。解決方案是用fast tokenizerRust實現(xiàn)或者把tokenization放到GPU上做。from transformers import AutoTokenizer # 用fast版本快很多 tokenizer AutoTokenizer.from_pretrained(bert-base-chinese, use_fastTrue)7.6 版本管理要覆蓋模型、數(shù)據(jù)、代碼三者一個AI系統(tǒng)的“版本”是三維的代碼版本Git commit、數(shù)據(jù)版本DVC hash、模型版本訓(xùn)練產(chǎn)出的checkpoint。三者必須能對應(yīng)起來。我的做法是在模型元數(shù)據(jù)里記錄{ model_version: v1.2.3, git_commit: a1b2c3d, data_version: dataset-v2-hash456, training_config: configs/train_v3.yaml, trained_at: 2024-01-15T10:30:00Z }這樣任何一次線上問題都能追溯到確切的代碼、數(shù)據(jù)、配置組合。8. 從零到一的路線圖建議如果你現(xiàn)在要從零構(gòu)建AI工程能力我建議按這個順序推進(jìn)每一步都有明確的交付物第一階段1-2周把環(huán)境跑通能用Docker起一個PyTorch環(huán)境跑通一個預(yù)訓(xùn)練模型的推理。交付物是一個能接收文本、返回分類結(jié)果的HTTP服務(wù)。第二階段2-3周加上數(shù)據(jù)處理管道用DVC管理數(shù)據(jù)版本訓(xùn)練和推理共享預(yù)處理代碼。交付物是一條能從原始數(shù)據(jù)到訓(xùn)練出模型的完整命令。第三階段2-3周引入實驗追蹤和配置管理能對比不同超參的實驗結(jié)果。交付物是一份能復(fù)現(xiàn)最佳實驗的配置文件。第四階段2-3周做推理優(yōu)化導(dǎo)出ONNX、加動態(tài)批處理、嘗試量化。交付物是一份推理性能對比報告延遲、吞吐、顯存。第五階段持續(xù)加上監(jiān)控和漂移檢測建立灰度發(fā)布流程。交付物是一套能自動告警的監(jiān)控面板。這個路線圖的關(guān)鍵是每個階段都有可運行的交付物而不是學(xué)完所有理論再動手。AI工程是實踐性極強的領(lǐng)域很多坑只有真正跑起來才會遇到。我個人在實際操作中的體會是AI工程最難的不是某個具體技術(shù)點而是把散落的技術(shù)點串成一條穩(wěn)定可靠的流水線。模型會換、數(shù)據(jù)會變、需求會調(diào)整但那條流水線的骨架——配置管理、版本控制、測試、監(jiān)控——是相對穩(wěn)定的。把這條骨架搭好后面換什么模型都是往里填的事。