從零搭建AI工程能力這件事我前前后后折騰過好幾輪。最早的時(shí)候我也走過彎路——買了一堆講Transformer推導(dǎo)的書把注意力機(jī)制的公式背得滾瓜爛熟結(jié)果真到要上線一個(gè)文本分類服務(wù)的時(shí)候連推理延遲怎么壓、顯存怎么省、模型版本怎么管都一頭霧水。后來我才想明白一件事AI工程不是機(jī)器學(xué)習(xí)理論的延伸它是一門獨(dú)立的工程學(xué)科核心矛盾在于“模型的不確定性與工程系統(tǒng)的確定性要求之間的沖突”。這篇內(nèi)容就是把我這些年從零構(gòu)建AI工程能力體系的過程拆開講從底層原理到落地實(shí)操適合那些已經(jīng)會(huì)調(diào)API、但想真正搞懂“一個(gè)AI系統(tǒng)是怎么被工程化地搭起來”的開發(fā)者。1. 先搞清楚AI工程到底在工程什么1.1 它和傳統(tǒng)軟件工程的根本分歧在哪傳統(tǒng)軟件工程里輸入是確定的邏輯是確定的輸出也是確定的。你寫一個(gè)訂單金額計(jì)算函數(shù)給定輸入輸出永遠(yuǎn)一致。但AI系統(tǒng)不是這樣——同一個(gè)輸入模型可能給出不同的輸出尤其是生成式模型而且你很難用單元測(cè)試去斷言“這個(gè)輸出是對(duì)的”。這就引出了AI工程最核心的幾個(gè)工程問題概率性輸出的可測(cè)試性你沒法寫assert output expected只能寫“輸出在某個(gè)可接受范圍內(nèi)”或者“輸出不包含某些違規(guī)內(nèi)容”。數(shù)據(jù)依賴的隱蔽性傳統(tǒng)軟件的bug在代碼里AI系統(tǒng)的bug可能在訓(xùn)練數(shù)據(jù)里、在特征管道里、在推理時(shí)的預(yù)處理邏輯里。性能瓶頸的轉(zhuǎn)移傳統(tǒng)后端瓶頸通常在IO或數(shù)據(jù)庫(kù)AI系統(tǒng)的瓶頸可能在GPU顯存、在批處理策略、在tokenizer的效率上。我踩過最典型的一個(gè)坑早期做一個(gè)情感分析服務(wù)離線評(píng)估準(zhǔn)確率92%上線后用戶投訴不斷。排查了兩天才發(fā)現(xiàn)訓(xùn)練時(shí)的文本預(yù)處理用了jieba分詞而線上服務(wù)為了圖快直接按空格切詞中文根本沒空格等于把整句話當(dāng)成一個(gè)token喂進(jìn)去了。這個(gè)bug不在模型里不在代碼邏輯里在“訓(xùn)練和推理的預(yù)處理不一致”這個(gè)工程縫隙里。所以AI工程的第一課不是學(xué)模型是學(xué)“怎么讓一個(gè)概率系統(tǒng)在確定性的工程約束下穩(wěn)定運(yùn)行”。1.2 從零構(gòu)建需要覆蓋的五個(gè)能力層我把AI工程能力拆成五層從下往上依次是層級(jí)能力域典型工作內(nèi)容常見工具L1環(huán)境與依賴管理GPU驅(qū)動(dòng)、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運(yùn)維與監(jiān)控日志、指標(biāo)、漂移檢測(cè)、A/B測(cè)試Prometheus、Grafana、Evidently很多人一上來就扎進(jìn)L3覺得訓(xùn)模型才是“AI”結(jié)果L1的環(huán)境問題就能卡一周L4的服務(wù)化更是完全沒概念。我的建議是從L1和L4兩頭往中間做——先把環(huán)境搞穩(wěn)、把推理服務(wù)跑通再回頭補(bǔ)訓(xùn)練和數(shù)據(jù)的細(xì)節(jié)。因?yàn)橥评矸?wù)是最終交付物先看到交付物的樣子你才知道中間每一步是為了什么。1.3 一個(gè)最小可用的AI工程骨架長(zhǎng)什么樣在展開每一層之前先給你一個(gè)我常用的最小骨架讓你有個(gè)全局感project/ ├── configs/ # 所有配置不硬編碼 │ ├── train.yaml │ └── serve.yaml ├── data/ # 數(shù)據(jù)版本管理 │ ├── raw/ │ └── processed/ ├── src/ │ ├── data/ # 數(shù)據(jù)處理 │ ├── model/ # 模型定義 │ ├── train/ # 訓(xùn)練邏輯 │ └── serve/ # 推理服務(wù) ├── tests/ # 測(cè)試包括數(shù)據(jù)測(cè)試 ├── docker/ # 環(huán)境固化 └── Makefile # 一鍵復(fù)現(xiàn)這個(gè)骨架的關(guān)鍵設(shè)計(jì)原則是配置與代碼分離、數(shù)據(jù)與代碼分離、訓(xùn)練與推理共享同一套預(yù)處理代碼。最后一條尤其重要前面那個(gè)分詞不一致的坑根源就是訓(xùn)練和推理各寫了一套預(yù)處理。2. 環(huán)境與依賴為什么你的CUDA總是裝不對(duì)2.1 CUDA版本地獄的本質(zhì)原因新手最容易被CUDA折磨。你裝了個(gè)PyTorch提示CUDA版本不匹配換了個(gè)版本又和驅(qū)動(dòng)不兼容。這個(gè)問題的本質(zhì)是三層版本必須嚴(yán)格對(duì)齊GPU驅(qū)動(dòng)版本決定了你最高能支持的CUDA版本向下兼容CUDA Toolkit版本PyTorch等框架編譯時(shí)依賴的版本框架版本PyTorch/TensorFlow各自綁定了特定的CUDA版本它們的關(guān)系是驅(qū)動(dòng)版本 ≥ 框架要求的CUDA版本。比如你的驅(qū)動(dòng)支持到CUDA 12.4那你可以跑CUDA 11.8編譯的PyTorch但不能跑CUDA 12.6編譯的。我常用的排查命令# 查看驅(qū)動(dòng)支持的CUDA版本 nvidia-smi # 查看當(dāng)前CUDA Toolkit版本 nvcc --version # 查看PyTorch實(shí)際使用的CUDA版本 python -c import torch; print(torch.version.cuda)注意nvidia-smi顯示的CUDA版本是驅(qū)動(dòng)支持的最高版本不是你實(shí)際安裝的版本。很多人看到這個(gè)數(shù)字就以為裝對(duì)了其實(shí)不是。2.2 用容器把環(huán)境問題一次性解決我現(xiàn)在的做法是本地只裝驅(qū)動(dòng)所有Python環(huán)境和CUDA都跑在容器里。這樣換機(jī)器、換項(xiàng)目都不會(huì)互相污染。一個(gè)典型的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這里有個(gè)經(jīng)驗(yàn)基礎(chǔ)鏡像選runtime而不是devel除非你需要編譯CUDA算子。runtime鏡像小很多部署時(shí)拉取快。另外cudnn版本也要和CUDA對(duì)齊12.1.0-cudnn8這種tag就是官方幫你配好的組合。2.3 依賴鎖定別讓“昨天還能跑”變成玄學(xué)Python依賴的坑在于pip install默認(rèn)裝最新版今天能跑的代碼明天可能就崩了。我的做法是用poetry或pip-tools生成鎖定文件poetry.lock/requirements.txt帶精確版本號(hào)區(qū)分requirements.in寬松約束和requirements.txt精確鎖定CI里用鎖定文件安裝保證本地和線上一致# 用pip-tools的流程 pip-compile requirements.in -o requirements.txt # 生成鎖定 pip-sync requirements.txt # 按鎖定安裝這套流程看起來麻煩但能省掉無數(shù)次“在我機(jī)器上是好的”的扯皮。3. 數(shù)據(jù)處理管道AI系統(tǒng)里最臟最累的活3.1 為什么數(shù)據(jù)管道值得單獨(dú)工程化我見過太多項(xiàng)目把數(shù)據(jù)處理寫成一個(gè)個(gè)散落的腳本clean.py、split.py、augment.py跑的時(shí)候靠記憶按順序執(zhí)行。這種做法的致命問題是不可復(fù)現(xiàn)——三個(gè)月后你想重新訓(xùn)練根本記不清當(dāng)時(shí)的數(shù)據(jù)是怎么處理的。數(shù)據(jù)管道工程化的核心目標(biāo)是給定原始數(shù)據(jù)和一份配置能一鍵復(fù)現(xiàn)出完全相同的訓(xùn)練集。這需要三個(gè)東西數(shù)據(jù)版本管理原始數(shù)據(jù)、處理后數(shù)據(jù)都要有版本標(biāo)識(shí)處理邏輯代碼化每一步轉(zhuǎn)換都是可測(cè)試的函數(shù)數(shù)據(jù)校驗(yàn)處理前后自動(dòng)檢查數(shù)據(jù)質(zhì)量3.2 用DVC做數(shù)據(jù)版本管理Git管代碼DVC管數(shù)據(jù)。基本用法dvc 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會(huì)把大文件存到遠(yuǎn)程存儲(chǔ)S3、本地NAS都行Git里只留一個(gè)指針文件。這樣你切換Git分支時(shí)dvc checkout就能拿到對(duì)應(yīng)版本的數(shù)據(jù)。我踩過的坑DVC的緩存目錄默認(rèn)在項(xiàng)目?jī)?nèi)容易把磁盤撐爆。建議一開始就配置外部緩存dvc cache dir /mnt/large-disk/dvc-cache3.3 數(shù)據(jù)校驗(yàn)在訓(xùn)練前攔住臟數(shù)據(jù)數(shù)據(jù)問題如果等到訓(xùn)練完才發(fā)現(xiàn)浪費(fèi)的是幾小時(shí)甚至幾天的GPU時(shí)間。我習(xí)慣在管道里加一層校驗(yàn)用pydantic或Great Expectations都行。一個(gè)輕量做法是用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ù)加載時(shí)逐條校驗(yàn)把不合規(guī)的樣本記錄下來而不是直接丟棄——丟棄會(huì)讓你丟失數(shù)據(jù)分布的信息記錄下來才能分析是采集問題還是標(biāo)注問題。3.4 訓(xùn)練/推理預(yù)處理必須共享代碼回到開頭那個(gè)分詞坑。解決方案是把預(yù)處理邏輯抽成一個(gè)獨(dú)立模塊訓(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)用這個(gè)函數(shù)。任何預(yù)處理邏輯的修改都必須同時(shí)影響訓(xùn)練和推理否則就會(huì)出現(xiàn)訓(xùn)練-推理偏差training-serving skew。這是AI工程里最隱蔽也最致命的一類bug。4. 訓(xùn)練工程化讓實(shí)驗(yàn)可復(fù)現(xiàn)、可比較4.1 配置管理告別硬編碼超參新手寫訓(xùn)練腳本超參直接寫在代碼里lr 1e-4 batch_size 32 epochs 10改一次跑一次改多了自己都記不清哪個(gè)配置對(duì)應(yīng)哪個(gè)結(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這樣每次實(shí)驗(yàn)的完整配置都能被記錄下來配合wandb或mlflow實(shí)驗(yàn)對(duì)比一目了然。4.2 實(shí)驗(yàn)追蹤別靠腦子記結(jié)果我早期用Excel記實(shí)驗(yàn)結(jié)果記到第20次就亂了。后來?yè)Q成wandb每次訓(xùn)練自動(dòng)記錄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})實(shí)驗(yàn)追蹤的價(jià)值不在于記錄而在于對(duì)比。當(dāng)你想知道“為什么這次比上次差”時(shí)能直接diff兩次實(shí)驗(yàn)的配置差異而不是靠回憶。4.3 檢查點(diǎn)策略什么時(shí)候存、存什么模型檢查點(diǎn)不是越多越好占磁盤還容易搞混。我的策略是按驗(yàn)證指標(biāo)存最優(yōu)只保留驗(yàn)證集上表現(xiàn)最好的N個(gè)定期存每N個(gè)epoch存一次防止訓(xùn)練崩潰丟失進(jìn)度存完整狀態(tài)不只是模型權(quán)重還要存優(yōu)化器狀態(tài)、學(xué)習(xí)率調(diào)度器狀態(tài)、當(dāng)前epoch這樣才能斷點(diǎn)續(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)提示斷點(diǎn)續(xù)訓(xùn)時(shí)優(yōu)化器狀態(tài)和調(diào)度器狀態(tài)必須一起恢復(fù)否則學(xué)習(xí)率曲線會(huì)錯(cuò)亂訓(xùn)練效果可能明顯變差。4.4 分布式訓(xùn)練什么時(shí)候需要、怎么上手單卡能跑就別上分布式分布式調(diào)試成本高。判斷標(biāo)準(zhǔn)很簡(jiǎn)單單卡跑一個(gè)epoch的時(shí)間 × 總epoch數(shù) 你能接受的等待時(shí)間就該考慮分布式了。PyTorch的DDPDistributedDataParallel是目前最成熟的選擇。核心改動(dòng)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啟動(dòng)torchrun --nproc_per_node4 train.py踩過的坑DDP下每個(gè)進(jìn)程的隨機(jī)種子要不同否則數(shù)據(jù)增強(qiáng)會(huì)重復(fù)。還有驗(yàn)證和保存檢查點(diǎn)只在rank 0上做否則會(huì)寫沖突。5. 推理服務(wù)化從模型文件到可用API5.1 模型導(dǎo)出為什么不能直接pickle訓(xùn)練完的PyTorch模型直接torch.save然后線上torch.load看起來能用但有幾個(gè)問題依賴訓(xùn)練代碼加載時(shí)需要模型類定義線上服務(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和序列長(zhǎng)度會(huì)被固定死線上只能處理特定形狀的輸入。5.2 推理引擎選型ONNX Runtime vs Triton vs vLLM不同場(chǎng)景選不同引擎我整理了一個(gè)對(duì)比引擎適用場(chǎng)景優(yōu)勢(shì)局限ONNX Runtime中小模型、CPU/GPU通用輕量、易集成大模型支持一般Triton Inference Server多模型、多框架混合動(dòng)態(tài)批處理、模型編排部署復(fù)雜vLLM大語(yǔ)言模型PagedAttention、高吞吐只支持LLM類我的經(jīng)驗(yàn)判別式模型分類、NER用ONNX Runtime就夠了生成式大模型直接上vLLM。Triton適合模型多、需要統(tǒng)一管理的場(chǎng)景但學(xué)習(xí)曲線陡。5.3 動(dòng)態(tài)批處理吞吐量的關(guān)鍵線上請(qǐng)求是零散到達(dá)的如果每個(gè)請(qǐng)求單獨(dú)推理GPU利用率極低。動(dòng)態(tài)批處理把短時(shí)間內(nèi)到達(dá)的請(qǐng)求攢成一批一起推理# 簡(jiǎn)化的動(dòng)態(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)衡點(diǎn)設(shè)大了吞吐高但延遲高設(shè)小了反之。我一般從10ms起步根據(jù)實(shí)際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 )注意量化會(huì)帶來精度損失必須在上線前用驗(yàn)證集評(píng)估。我遇到過量化后F1掉3個(gè)點(diǎn)的情況這種就不能接受。一般分類任務(wù)掉1個(gè)點(diǎn)以內(nèi)可以接受生成任務(wù)要更謹(jǐn)慎。6. 監(jiān)控與運(yùn)維上線只是開始6.1 模型監(jiān)控和傳統(tǒng)監(jiān)控的區(qū)別傳統(tǒng)服務(wù)監(jiān)控看QPS、延遲、錯(cuò)誤率就夠了。AI服務(wù)還要額外看輸入分布漂移線上輸入的特征分布和訓(xùn)練時(shí)是否一致輸出分布漂移模型輸出的分布是否發(fā)生偏移預(yù)測(cè)置信度置信度整體下降往往預(yù)示模型失效我見過一個(gè)案例一個(gè)推薦模型上線三個(gè)月效果逐漸變差排查發(fā)現(xiàn)是用戶行為模式變了但模型沒重新訓(xùn)練。如果當(dāng)時(shí)監(jiān)控了輸入特征分布就能提前發(fā)現(xiàn)。6.2 用Evidently做漂移檢測(cè)Evidently是個(gè)輕量的漂移檢測(cè)庫(kù)幾行代碼就能生成報(bào)告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)它會(huì)告訴你哪些特征發(fā)生了漂移、漂移程度如何。我一般設(shè)個(gè)閾值漂移超過閾值就觸發(fā)告警人工判斷是否需要重新訓(xùn)練。6.3 日志設(shè)計(jì)出問題時(shí)能查到什么AI服務(wù)的日志要比普通服務(wù)更詳細(xì)。我必記的字段請(qǐng)求ID用于追蹤單次請(qǐng)求全鏈路原始輸入脫敏后預(yù)處理后的輸入模型輸出和置信度推理耗時(shí)區(qū)分預(yù)處理、推理、后處理模型版本號(hào)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, })模型版本號(hào)尤其重要出問題時(shí)第一件事就是確認(rèn)線上跑的是哪個(gè)版本以及這個(gè)版本是什么時(shí)候上線的。6.4 灰度發(fā)布與回滾模型更新不能全量直接上。我的做法是新模型先接5%流量觀察指標(biāo)指標(biāo)正常逐步放量到50%、100%任何指標(biāo)異常立即回滾到舊版本這要求服務(wù)支持多模型版本共存通過請(qǐng)求頭或配置決定走哪個(gè)版本。用Triton的話它原生支持多版本模型自己寫服務(wù)的話可以維護(hù)一個(gè)版本路由表。7. 一些讓我少走彎路的實(shí)操心得7.1 先跑通端到端再優(yōu)化每一環(huán)新手最容易犯的錯(cuò)是“完美主義”——非要把數(shù)據(jù)處理做到極致才開始訓(xùn)練非要把模型調(diào)到SOTA才上線。我的建議是先用最粗糙的方式跑通端到端隨便清洗下數(shù)據(jù)、用現(xiàn)成模型、寫個(gè)最簡(jiǎn)單的Flask服務(wù)。跑通之后你才知道瓶頸在哪再針對(duì)性優(yōu)化。我見過太多項(xiàng)目卡在“數(shù)據(jù)還沒準(zhǔn)備好”階段幾個(gè)月最后不了了之。7.2 測(cè)試要覆蓋數(shù)據(jù)而不只是代碼傳統(tǒng)測(cè)試測(cè)代碼邏輯AI工程還要測(cè)數(shù)據(jù)。我習(xí)慣加這幾類測(cè)試數(shù)據(jù)schema測(cè)試字段類型、取值范圍數(shù)據(jù)分布測(cè)試關(guān)鍵特征的均值、方差在合理范圍預(yù)處理一致性測(cè)試訓(xùn)練和推理的預(yù)處理函數(shù)輸出一致模型輸出測(cè)試給定固定輸入輸出在預(yù)期范圍不是精確相等def test_preprocess_consistency(): text 這個(gè)產(chǎn)品很好用 train_out preprocess_text(text) serve_out preprocess_text(text) assert train_out serve_out7.3 把“重新訓(xùn)練”做成一條命令模型需要定期重新訓(xùn)練如果每次都要手動(dòng)跑一堆腳本遲早會(huì)出錯(cuò)。我的目標(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 顯存不夠時(shí)的排查順序顯存OOM是高頻問題我的排查順序是batch size是不是太大先減半試試有沒有梯度累積的誤用梯度累積不省顯存只省batch維度中間激活有沒有及時(shí)釋放用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%顯存而且速度更快幾乎是無腦該開的選項(xiàng)。7.5 別忽視CPU側(cè)的瓶頸大家盯著GPU但很多時(shí)候瓶頸在CPUtokenizer太慢、數(shù)據(jù)加載是單線程、后處理邏輯復(fù)雜。我遇到過一個(gè)服務(wù)GPU利用率只有20%排查發(fā)現(xiàn)是tokenizer成了瓶頸。解決方案是用fast tokenizerRust實(shí)現(xiàn)或者把tokenization放到GPU上做。from transformers import AutoTokenizer # 用fast版本快很多 tokenizer AutoTokenizer.from_pretrained(bert-base-chinese, use_fastTrue)7.6 版本管理要覆蓋模型、數(shù)據(jù)、代碼三者一個(gè)AI系統(tǒng)的“版本”是三維的代碼版本Git commit、數(shù)據(jù)版本DVC hash、模型版本訓(xùn)練產(chǎn)出的checkpoint。三者必須能對(duì)應(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工程能力我建議按這個(gè)順序推進(jìn)每一步都有明確的交付物第一階段1-2周把環(huán)境跑通能用Docker起一個(gè)PyTorch環(huán)境跑通一個(gè)預(yù)訓(xùn)練模型的推理。交付物是一個(gè)能接收文本、返回分類結(jié)果的HTTP服務(wù)。第二階段2-3周加上數(shù)據(jù)處理管道用DVC管理數(shù)據(jù)版本訓(xùn)練和推理共享預(yù)處理代碼。交付物是一條能從原始數(shù)據(jù)到訓(xùn)練出模型的完整命令。第三階段2-3周引入實(shí)驗(yàn)追蹤和配置管理能對(duì)比不同超參的實(shí)驗(yàn)結(jié)果。交付物是一份能復(fù)現(xiàn)最佳實(shí)驗(yàn)的配置文件。第四階段2-3周做推理優(yōu)化導(dǎo)出ONNX、加動(dòng)態(tài)批處理、嘗試量化。交付物是一份推理性能對(duì)比報(bào)告延遲、吞吐、顯存。第五階段持續(xù)加上監(jiān)控和漂移檢測(cè)建立灰度發(fā)布流程。交付物是一套能自動(dòng)告警的監(jiān)控面板。這個(gè)路線圖的關(guān)鍵是每個(gè)階段都有可運(yùn)行的交付物而不是學(xué)完所有理論再動(dòng)手。AI工程是實(shí)踐性極強(qiáng)的領(lǐng)域很多坑只有真正跑起來才會(huì)遇到。我個(gè)人在實(shí)際操作中的體會(huì)是AI工程最難的不是某個(gè)具體技術(shù)點(diǎn)而是把散落的技術(shù)點(diǎn)串成一條穩(wěn)定可靠的流水線。模型會(huì)換、數(shù)據(jù)會(huì)變、需求會(huì)調(diào)整但那條流水線的骨架——配置管理、版本控制、測(cè)試、監(jiān)控——是相對(duì)穩(wěn)定的。把這條骨架搭好后面換什么模型都是往里填的事。