1. 先搞明白AI工程和“調(diào)模型”到底差在哪1.1 什么是真正的 ai-engineering而不是跑通一個(gè) demo先說(shuō)個(gè)我自己的經(jīng)歷。前兩年我第一次接觸一個(gè)所謂的“AI項(xiàng)目”實(shí)際上就是拿到一個(gè)公開(kāi)的模型權(quán)重寫(xiě)了個(gè)30行的Python腳本調(diào)用了一下輸出了幾個(gè)結(jié)果。那叫“用AI”不叫“AI工程”。真正讓我意識(shí)到兩者差距的是后來(lái)接了一個(gè)內(nèi)部需求公司想讓員工在一個(gè)集中式入口里用自然語(yǔ)言提問(wèn)然后系統(tǒng)從幾十萬(wàn)份技術(shù)文檔里找到答案還要帶著來(lái)源引用返回。一開(kāi)始我覺(jué)得這有什么難的——模型加載起來(lái)做個(gè)embedding接個(gè)向量庫(kù)完事了。結(jié)果真正做下去才發(fā)現(xiàn)模型加載跑通只是這個(gè)項(xiàng)目里最不起眼的5%。剩下95%的時(shí)間都在處理數(shù)據(jù)質(zhì)量、環(huán)境一致性、訓(xùn)練穩(wěn)定性、線(xiàn)上延遲、評(píng)測(cè)標(biāo)準(zhǔn)、回歸回歸回歸——這才是ai-engineering from scratch的核心。所以這篇文章想分享的不是某一個(gè)模型的調(diào)用代碼而是當(dāng)你決定“從零開(kāi)始把一條AI產(chǎn)品線(xiàn)真正落地”時(shí)你需要面對(duì)的那些繞不開(kāi)的問(wèn)題以及我踩過(guò)之后留下的方案。適合剛?cè)腴T(mén)的算法工程師、想把模型產(chǎn)品化的后端開(kāi)發(fā)以及正在復(fù)現(xiàn)論文或開(kāi)源項(xiàng)目、卻被環(huán)境、數(shù)據(jù)、部署折磨到懷疑人生的學(xué)生。標(biāo)題里的“from scratch”有兩層含義技術(shù)棧上的從零不是用別人封裝好的Paas平臺(tái)拖幾個(gè)組件而是自己掌握鏈路里的每一個(gè)關(guān)鍵環(huán)節(jié)。認(rèn)知上的從零打破“模型就是一切”的幻覺(jué)建立工程化思維。1.2 為什么選擇自建而不是直接套現(xiàn)成平臺(tái)做AI工程第一件事通常是選型用現(xiàn)成的大模型API還是自己微調(diào)部署用托管的向量數(shù)據(jù)庫(kù)還是自己起一個(gè)這里沒(méi)有標(biāo)準(zhǔn)答案但有決策框架。我當(dāng)時(shí)的判斷標(biāo)準(zhǔn)是四看看數(shù)據(jù)敏感性企業(yè)內(nèi)部文檔涉及業(yè)務(wù)細(xì)節(jié)不能隨便出網(wǎng)?？炊ㄖ粕疃葐?wèn)答效果依賴(lài)對(duì)私有術(shù)語(yǔ)的理解通用模型明顯不夠?？撮L(zhǎng)期成本調(diào)用量上來(lái)之后按token付費(fèi)的費(fèi)用遠(yuǎn)高于自建推理?？磮F(tuán)隊(duì)成長(zhǎng)希望團(tuán)隊(duì)借這個(gè)項(xiàng)目真正建立AI工程能力而不是變成一個(gè)API轉(zhuǎn)發(fā)器。四條下來(lái)“自建 開(kāi)源模型微調(diào) 私有部署”是唯一合理的路徑。但自建有一個(gè)被嚴(yán)重低估的代價(jià)鏈路變長(zhǎng)了。以前用一個(gè)API只需要關(guān)注輸入輸出自建之后你要關(guān)注數(shù)據(jù)管道、GPU資源、訓(xùn)練穩(wěn)定性、推理吞吐、監(jiān)控告警。每多一個(gè)環(huán)節(jié)就多了一批潛在的故障點(diǎn)。這是所有從零開(kāi)始的人要先做好的心理建設(shè)。1.3 一個(gè)貫穿全文的實(shí)例內(nèi)部文檔問(wèn)答機(jī)器人為了讓下面的內(nèi)容不至于飄在理論上我以“企業(yè)內(nèi)部文檔問(wèn)答機(jī)器人”作為貫穿案例。項(xiàng)目目標(biāo)很明確用戶(hù)輸入一個(gè)問(wèn)題系統(tǒng)返回一段答案并附帶來(lái)源文檔和頁(yè)碼。業(yè)務(wù)上要求準(zhǔn)確率不低于85%首字節(jié)延遲低于2秒支持30個(gè)并發(fā)。訓(xùn)練數(shù)據(jù)來(lái)自公司內(nèi)部的技術(shù)文檔、產(chǎn)品手冊(cè)、歷史工單大約50萬(wàn)條。這個(gè)例子覆蓋了AI工程的主要模塊數(shù)據(jù)管道、模型微調(diào)、推理部署、評(píng)測(cè)反饋。后面每個(gè)章節(jié)都會(huì)用它來(lái)說(shuō)明“為什么這么做”“參數(shù)怎么定”“踩了什么坑”。2. 環(huán)境與基礎(chǔ)設(shè)施搭地基的姿勢(shì)決定上層建筑的穩(wěn)定程度2.1 GPU選型與驅(qū)動(dòng)別一上來(lái)就被顯存卡死做AI工程第一道坎通常是硬件環(huán)境。我當(dāng)時(shí)拿到的是一臺(tái)雙卡機(jī)器配置是2塊24G顯存的GPU。很多人會(huì)問(wèn)“顯存選多大”其實(shí)這個(gè)問(wèn)題不應(yīng)該脫離模型規(guī)模去談。如果目標(biāo)是微調(diào)一個(gè)7B參數(shù)量的模型采用LoRA方式24G顯存跑fp16是夠的如果要全參數(shù)微調(diào)24G會(huì)很吃力。訓(xùn)練和推理的顯存需求差異也很大推理階段可以用量化大幅壓縮。選型的時(shí)候我列過(guò)一個(gè)粗略的評(píng)估表模型規(guī)模推理最低顯存FP16微調(diào)推薦顯存LoRA全參微調(diào)推薦顯存1B以下4G8G16G7B16G24G80G13B32G48G160G注意這只是經(jīng)驗(yàn)值實(shí)際要看序列長(zhǎng)度和batch size。序列越長(zhǎng)、batch越大顯存需求越高。驅(qū)動(dòng)和CUDA版本這塊我吃過(guò)一次虧?rùn)C(jī)器上預(yù)裝了CUDA 11.8但PyTorch版本要求CUDA 12.1結(jié)果程序沒(méi)有報(bào)CUDA錯(cuò)誤而是直接報(bào)“illegal memory access”排查了一天最后才發(fā)現(xiàn)是版本不匹配。現(xiàn)在我的原則是先查PyTorch官方對(duì)應(yīng)的CUDA版本再回過(guò)頭配置驅(qū)動(dòng)。跑一個(gè)簡(jiǎn)單的驗(yàn)證命令確認(rèn)環(huán)境正常python -c import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))如果輸出顯示的GPU名稱(chēng)正確CUDA可用再開(kāi)始裝模型能省掉一大半玄學(xué)問(wèn)題。2.2 用Docker把環(huán)境固化下來(lái)不要相信“在我電腦上是好的”AI工程的復(fù)現(xiàn)性有一個(gè)大敵環(huán)境漂移。“在我電腦上跑得好好的”這句話(huà)在AI項(xiàng)目里出現(xiàn)的頻率遠(yuǎn)超其他軟件項(xiàng)目。原因很簡(jiǎn)單訓(xùn)練腳本依賴(lài)的Python包有幾百個(gè)每個(gè)包又有不同版本某次升級(jí)一個(gè)小版本可能就帶來(lái)數(shù)值變化。為了把環(huán)境固化我強(qiáng)烈建議從第一步就引入Docker。我用的基礎(chǔ)鏡像形如FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime RUN apt-get update apt-get install -y git curl RUN pip install --no-cache-dir transformers datasets accelerate peft trl COPY ./requirements.txt /app/ RUN pip install --no-cache-dir -r /app/requirements.txt這樣做的好處有三個(gè)環(huán)境與宿主隔離不會(huì)再因?yàn)橄到y(tǒng)Python升級(jí)導(dǎo)致依賴(lài)崩掉。訓(xùn)練、推理、測(cè)試用同一個(gè)鏡像結(jié)果可以對(duì)比。部署的時(shí)候直接把鏡像推到內(nèi)部倉(cāng)庫(kù)生產(chǎn)機(jī)和開(kāi)發(fā)機(jī)環(huán)境完全一致。我用的是conda還是Docker答案是都要。conda負(fù)責(zé)創(chuàng)建Python虛擬環(huán)境Docker負(fù)責(zé)把整個(gè)系統(tǒng)層傳下去。在Docker里面再用conda管理Python環(huán)境可以兼顧靈活與可復(fù)現(xiàn)。2.3 實(shí)驗(yàn)跟蹤沒(méi)有記錄的訓(xùn)練都是白訓(xùn)從零開(kāi)始做AI工程最容易忽略的一個(gè)環(huán)節(jié)是實(shí)驗(yàn)記錄。我早期就是這樣改個(gè)參數(shù)跑一晚上第二天醒來(lái)發(fā)現(xiàn)效果好了但忘了昨天改了什么。那種“明明前一天還在變好現(xiàn)在怎么退步了”的困惑基本都源于沒(méi)有做好跟蹤。后來(lái)我引入了MLflow配合一套簡(jiǎn)單的命名規(guī)范。每個(gè)實(shí)驗(yàn)記錄三樣?xùn)|西超參數(shù)學(xué)習(xí)率、batch size、epoch數(shù)、LoRA rank指標(biāo)訓(xùn)練loss、驗(yàn)證loss、準(zhǔn)確率、F1產(chǎn)物模型檢查點(diǎn)路徑、評(píng)測(cè)報(bào)告、日志文件命名規(guī)范是“日期-模型-版本-說(shuō)明”比如“20240601-bert-base-zh-v01-lr2e5”。不要小看命名一個(gè)清晰的名字能讓你三個(gè)月后翻記錄時(shí)省下大量時(shí)間。如果你不想引入額外的服務(wù)也可以用最簡(jiǎn)單的CSV記錄表。核心不是工具而是“每次改動(dòng)都有跡可循”這個(gè)習(xí)慣。2.4 項(xiàng)目目錄結(jié)構(gòu)讓數(shù)據(jù)、代碼、模型、實(shí)驗(yàn)各歸其位從零搭建AI工程第一個(gè)該建立的不是模型而是目錄結(jié)構(gòu)?；靵y的目錄是后期維護(hù)的地獄。我最后固定的結(jié)構(gòu)是這樣的ai-engineering/ ├── configs/ # 所有訓(xùn)練、推理、評(píng)測(cè)的配置 ├── data/ # 數(shù)據(jù)原始、清洗后、切分后 ├── src/ # 代碼 │ ├── data/ # 數(shù)據(jù)處理邏輯 │ ├── models/ # 模型定義 │ ├── train/ # 訓(xùn)練腳本 │ ├── infer/ # 推理邏輯 │ └── eval/ # 評(píng)測(cè)邏輯 ├── experiments/ # 實(shí)驗(yàn)記錄與產(chǎn)物 ├── models/ # 最終模型權(quán)重 └── scripts/ # 運(yùn)行入口腳本這個(gè)結(jié)構(gòu)的原則是數(shù)據(jù)和模型不跟代碼混在一起配置和實(shí)驗(yàn)結(jié)果又跟代碼分開(kāi)。實(shí)際用下來(lái)的好處是很多時(shí)候只需要拷貝某個(gè)子目錄就能完成交接不用把“那一堆亂七八糟的文件”一起拷走。3. 數(shù)據(jù)是真正的上線(xiàn)難點(diǎn)清洗、版本化、切分3.1 從原始文檔到訓(xùn)練數(shù)據(jù)清洗規(guī)則怎么定很多從零開(kāi)始做AI工程的人會(huì)低估數(shù)據(jù)處理的比重。真實(shí)情況是一個(gè)生產(chǎn)中可用的模型其數(shù)據(jù)工程耗時(shí)往往占總工時(shí)的60%以上。尤其像文檔問(wèn)答這種場(chǎng)景原始數(shù)據(jù)是PDF、Word、HTML混在一起排版各異直接拿去訓(xùn)練根本不可能。我的清洗分四步走第一步做格式轉(zhuǎn)換。PDF用解析工具抽出文本W(wǎng)ord轉(zhuǎn)成純文本HTML剝掉標(biāo)簽。這里要注意PDF雙欄排版很容易抽取錯(cuò)亂需要按欄切分再拼接。第二步做段落切分。按標(biāo)題層級(jí)和段落邊界把文檔切成“語(yǔ)塊”而不是簡(jiǎn)單按字符數(shù)硬切。我當(dāng)時(shí)用了一套基于標(biāo)題編號(hào)的規(guī)則同時(shí)保留每塊的來(lái)源元數(shù)據(jù)文檔名、章節(jié)路徑、頁(yè)碼。第三步做規(guī)則過(guò)濾。批量去掉頁(yè)眉頁(yè)腳、導(dǎo)航重復(fù)段落、空行、亂碼字符。規(guī)則要寫(xiě)成腳本反復(fù)迭代不要手動(dòng)刪。第四步做人工抽檢。每清洗完一批數(shù)據(jù)隨機(jī)抽100條檢查質(zhì)量。如果錯(cuò)誤率超過(guò)2%說(shuō)明清洗規(guī)則還需要補(bǔ)。一點(diǎn)心得清洗規(guī)則寧多勿少因?yàn)榕K數(shù)據(jù)給模型帶來(lái)的傷害是隱性的——它不會(huì)報(bào)錯(cuò)只會(huì)讓效果差一點(diǎn)、再差一點(diǎn)最終你根本不知道是模型的問(wèn)題還是數(shù)據(jù)的問(wèn)題。3.2 數(shù)據(jù)版本管理改過(guò)什么永遠(yuǎn)要能查談到數(shù)據(jù)AI工程師圈子里流傳著一句話(huà)“模型是數(shù)據(jù)的影子。”你改了一版數(shù)據(jù)模型效果完全不同。這時(shí)如果你沒(méi)記錄數(shù)據(jù)版本那么復(fù)現(xiàn)就是一個(gè)笑話(huà)。我做數(shù)據(jù)版本管理的辦法不復(fù)雜用類(lèi)似DVC的方式但核心是把兩樣?xùn)|西固定下來(lái)——數(shù)據(jù)文件的哈希值和一份數(shù)據(jù)清單。每當(dāng)數(shù)據(jù)變更我會(huì)生成一個(gè)新的數(shù)據(jù)版本號(hào)格式是“v日期-序號(hào)”并記錄原始數(shù)據(jù)來(lái)源清洗腳本版本清洗參數(shù)清洗后樣本數(shù)量人工抽檢結(jié)果這份記錄放在數(shù)據(jù)目錄的“CHANGELOG.md”里。為什么這么在意因?yàn)楫?dāng)我發(fā)現(xiàn)模型效果下降時(shí)第一件事就是檢查數(shù)據(jù)版本是否被動(dòng)過(guò)。有一次團(tuán)隊(duì)同事順手“優(yōu)化”了清洗腳本去掉了一個(gè)去重步驟結(jié)果數(shù)據(jù)量從50萬(wàn)變成55萬(wàn)模型準(zhǔn)確率掉了3個(gè)點(diǎn)。查了兩天最后定位到就是數(shù)據(jù)版本變了。如果一開(kāi)始就查CHANGELOG十分鐘就能解決。3.3 切分與分布檢查訓(xùn)練集驗(yàn)證集的劃分要防止“作弊”數(shù)據(jù)切分看起來(lái)是個(gè)簡(jiǎn)單問(wèn)題——隨機(jī)分一下就行其實(shí)不是。文檔問(wèn)答場(chǎng)景有一個(gè)典型風(fēng)險(xiǎn)同一份文檔的不同段落可能既出現(xiàn)在訓(xùn)練集又出現(xiàn)在驗(yàn)證集。模型見(jiàn)過(guò)相關(guān)內(nèi)容驗(yàn)證集分?jǐn)?shù)虛高上線(xiàn)后面對(duì)新文檔效果驟降。這就是數(shù)據(jù)泄露。我的切分原則是按文檔級(jí)別切分而不是按段落切分。同一篇文檔的段落放進(jìn)同一個(gè)集合。驗(yàn)證集和測(cè)試集不使用同一批文檔。切分之后人工檢查類(lèi)別分布。比如工單類(lèi)的數(shù)據(jù)占了60%驗(yàn)證集也要保持類(lèi)似的占比否則指標(biāo)會(huì)有偏。切分完一定要跑一個(gè)簡(jiǎn)單的分布檢查腳本輸出訓(xùn)練/驗(yàn)證/測(cè)試三個(gè)集合的樣本量、來(lái)源分布、平均長(zhǎng)度?？吹饺M數(shù)字大致匹配再進(jìn)入訓(xùn)練環(huán)節(jié)。這里特別提醒一點(diǎn)不要反復(fù)在測(cè)試集上調(diào)參。測(cè)試集的唯一使命是最終評(píng)估一次。想調(diào)參用驗(yàn)證集。這個(gè)原則違反了你的指標(biāo)就只是“對(duì)測(cè)試集的記憶”不是真實(shí)能力。4. 模型訓(xùn)練與微調(diào)的實(shí)操?gòu)募虞d到收斂4.1 訓(xùn)練循環(huán)骨架每一行都有存在的理由從零開(kāi)始寫(xiě)訓(xùn)練循環(huán)不是把模型的forward和backward拼在一起就完事。一個(gè)生產(chǎn)可用的訓(xùn)練腳本要考慮的東西比教科書(shū)示例多得多梯度累積、混合精度、梯度裁剪、checkpoint保存、日志頻率。我用的訓(xùn)練循環(huán)骨架大致長(zhǎng)這樣for epoch in range(num_epochs): model.train() for step, batch in enumerate(train_loader): batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss / grad_accum_steps loss.backward() if (step 1) % grad_accum_steps 0: torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() optimizer.zero_grad() if step % log_steps 0: logger.info(fepoch {epoch}, step {step}, loss {loss.item():.4f}) # 每N步做一次驗(yàn)證 evaluate(model, val_loader)看起來(lái)平平無(wú)奇但有幾個(gè)點(diǎn)值得展開(kāi)。梯度累積是為了在單卡顯存受限時(shí)用多個(gè)小batch模擬大batch的效果。grad_accum_steps 理想batch size / 實(shí)際batch size。比如理想batch是32顯存只放得下8那accum_steps就是4?；旌暇華MP可以讓訓(xùn)練加速且省顯存。PyTorch里用torch.cuda.amp即可一般不改業(yè)務(wù)代碼。但要注意部分模型在FP16下數(shù)值不穩(wěn)定loss會(huì)突變成nan。如果你遇到這種問(wèn)題可以退回FP32或者用BF16在許多新卡上更穩(wěn)。4.2 超參數(shù)的起點(diǎn)以及調(diào)參的順序邏輯超參數(shù)是玄學(xué)嗎某種意義上是的但調(diào)參順序是有邏輯的。我的經(jīng)驗(yàn)是從學(xué)習(xí)率開(kāi)始調(diào)。找一個(gè)大致的范圍比如1e-5到5e-5先用小數(shù)據(jù)集快速跑幾個(gè)epoch觀察loss走勢(shì)。loss不降說(shuō)明學(xué)習(xí)率太小或者模型結(jié)構(gòu)有問(wèn)題loss震蕩說(shuō)明學(xué)習(xí)率太大。選定學(xué)習(xí)率之后再調(diào)batch size。batch size主要影響訓(xùn)練穩(wěn)定性和收斂速度太大會(huì)顯存爆炸太小會(huì)導(dǎo)致梯度噪聲大、收斂慢。再然后是epoch數(shù)。epoch數(shù)其實(shí)不是一個(gè)需要“調(diào)”的參數(shù)而是和早停early stopping配合的概念。我一般設(shè)置一個(gè)上限比如10個(gè)epoch如果驗(yàn)證指標(biāo)連續(xù)3個(gè)epoch沒(méi)有提升就提前結(jié)束訓(xùn)練并保存驗(yàn)證集上表現(xiàn)最好的那個(gè)檢查點(diǎn)。warmup比例也值得一說(shuō)。很多模型微調(diào)時(shí)會(huì)設(shè)置一段“預(yù)熱期”學(xué)習(xí)率從零線(xiàn)性上升到目標(biāo)值再按余弦曲線(xiàn)下降。warmup的比例我習(xí)慣設(shè)為總步數(shù)的3%到5%。它的作用是防止訓(xùn)練初期由于學(xué)習(xí)率過(guò)大導(dǎo)致模型參數(shù)劇烈震蕩。4.3 什么時(shí)候上分布式單卡能解決的事別浪費(fèi)時(shí)間在多卡上很多從零開(kāi)始的人有個(gè)誤區(qū)一上來(lái)就研究分布式訓(xùn)練框架。其實(shí)大多數(shù)項(xiàng)目單卡就能搞定。我的判斷標(biāo)準(zhǔn)是如果單卡訓(xùn)練一輪的時(shí)間在可接受范圍內(nèi)比如一個(gè)晚上能跑完就絕對(duì)不要上分布式。分布式訓(xùn)練帶來(lái)的增益不是沒(méi)有但它同時(shí)引入通信開(kāi)銷(xiāo)、調(diào)試難度和版本兼容問(wèn)題。性?xún)r(jià)比極低。只有當(dāng)訓(xùn)練時(shí)間超過(guò)資源容忍度比如單卡要跑一周以上才是考慮DDPDistributedDataParallel的時(shí)機(jī)。如果可以?xún)?yōu)先用LoRA這種參數(shù)高效微調(diào)技術(shù)而不是全參微調(diào)。它在保持效果接近的情況下顯存占用和訓(xùn)練時(shí)間都能大幅降低。微調(diào)一個(gè)7B模型的LoRA24G單卡完全夠用。這個(gè)決策讓我的團(tuán)隊(duì)省下了一整臺(tái)A100預(yù)算。4.4 模型產(chǎn)物管理檢查點(diǎn)怎么存選哪個(gè)版本上線(xiàn)一個(gè)訓(xùn)練任務(wù)跑完會(huì)留下很多檢查點(diǎn)每個(gè)epoch保存一次加上早停保存的最佳檢查點(diǎn)以及最后一輪檢查點(diǎn)。不可能全部上線(xiàn)需要一套選擇邏輯。我現(xiàn)在的規(guī)則是候選檢查點(diǎn)都跑一遍評(píng)測(cè)集記錄核心指標(biāo)準(zhǔn)確率、F1、延遲。上線(xiàn)選擇不只看單一指標(biāo)。比如準(zhǔn)確率最高的檢查點(diǎn)可能在某類(lèi)問(wèn)題上的穩(wěn)定性很差我會(huì)看分項(xiàng)指標(biāo)再?zèng)Q定。所有檢查點(diǎn)統(tǒng)一命名格式模型名-訓(xùn)練數(shù)據(jù)版本-epoch號(hào)-指標(biāo)值。這個(gè)格式保證三個(gè)月后還能定位到“為什么選它”。保存檢查點(diǎn)的時(shí)候不只是存權(quán)重還要把訓(xùn)練配置和tokenizer一起打包。有過(guò)一次教訓(xùn)三個(gè)月后想恢復(fù)一個(gè)模型繼續(xù)訓(xùn)練結(jié)果只找到權(quán)重文件tokenizer配置丟了那個(gè)模型直接報(bào)廢。權(quán)重可以不要tokenizer和config一定要留在模型目錄里。5. 推理部署與性能調(diào)優(yōu)模型跑起來(lái)只是開(kāi)始5.1 在線(xiàn)服務(wù)還是離線(xiàn)批量先想清楚業(yè)務(wù)形態(tài)部署的第一步不是寫(xiě)API而是判斷業(yè)務(wù)到底需要什么形態(tài)。文檔問(wèn)答這個(gè)場(chǎng)景用戶(hù)需要實(shí)時(shí)交互所以必須是在線(xiàn)服務(wù)接口響應(yīng)要快。而像“每周自動(dòng)給全量工單打標(biāo)簽”這種就不需要API跑一個(gè)批量腳本就行。在線(xiàn)服務(wù)又分同步和異步。同步返回適合單次問(wèn)答場(chǎng)景簡(jiǎn)單直接。異步適合處理慢操作比如生成很長(zhǎng)的答案先返回任務(wù)ID用戶(hù)再通過(guò)輪詢(xún)拿結(jié)果。我當(dāng)時(shí)的業(yè)務(wù)首字節(jié)延遲要求是2秒同步就夠用沒(méi)有引入額外的消息隊(duì)列。這里提醒一點(diǎn)不要為了“看起來(lái)高級(jí)”而加消息隊(duì)列。每多一個(gè)組件就多一層運(yùn)維負(fù)擔(dān)。先把同步接口做好發(fā)現(xiàn)瓶頸再演進(jìn)。5.2 推理加速量化、批處理、緩存三板斧模型部署之后第一件事就是壓測(cè)。我的經(jīng)驗(yàn)是不要憑感覺(jué)判斷性能直接用壓測(cè)工具跑指標(biāo)。壓測(cè)看三個(gè)數(shù)字QPS每秒能處理多少請(qǐng)求、P99延遲最慢的1%請(qǐng)求耗時(shí)、顯存占用。我的壓測(cè)結(jié)果是單卡初始QPS只有5P99延遲4秒遠(yuǎn)遠(yuǎn)不夠。之后我做了三板斧優(yōu)化第一板斧是量化。把模型從FP16量化到INT8或INT4顯存占用直接下降50%以上推理速度提升明顯。當(dāng)時(shí)用的是類(lèi)似GPTQ的思路通過(guò)校準(zhǔn)集選擇量化參數(shù)。INT4的量化會(huì)讓效果略有下降但在這個(gè)業(yè)務(wù)場(chǎng)景下可接受。第二板斧是批處理。在線(xiàn)推理服務(wù)默認(rèn)是一個(gè)請(qǐng)求一個(gè)請(qǐng)求地過(guò)模型GPU利用率很低。改成動(dòng)態(tài)批處理服務(wù)在極短的時(shí)間窗口比如50ms內(nèi)收集多個(gè)請(qǐng)求合并成一個(gè)batch同時(shí)推理。這個(gè)改動(dòng)把GPU利用率從20%拉到80%以上QPS直接翻了幾倍。第三板斧是結(jié)果緩存。高頻問(wèn)題往往占線(xiàn)上請(qǐng)求的大頭。對(duì)完全相同或高度相似的query直接用Redis緩存之前的結(jié)果。這個(gè)改動(dòng)把30%的請(qǐng)求變成“零推理”效果立竿見(jiàn)影。優(yōu)化后我的最終指標(biāo)是QPS 25P99延遲1.2秒滿(mǎn)足業(yè)務(wù)需求。別小看這些優(yōu)化它們是“從能跑到能扛流量”的關(guān)鍵。5.3 API服務(wù)怎么做才像話(huà)模型推理服務(wù)本質(zhì)上是一個(gè)高并發(fā)的接口服務(wù)工程上不能裸奔。我用FastAPI搭的服務(wù)骨架大概長(zhǎng)這樣from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class Query(BaseModel): question: str top_k: int 3 app.post(/v1/qa) async def qa(query: Query): try: result pipeline.run(query.question, top_kquery.top_k) return {answer: result[answer], sources: result[sources]} except Exception: raise HTTPException(status_code500, detailinternal error)但光有這個(gè)還不行生產(chǎn)環(huán)境至少還要有超時(shí)控制每個(gè)推理請(qǐng)求設(shè)置超時(shí)上限比如5秒避免慢請(qǐng)求拖垮線(xiàn)程池。重試策略對(duì)偶發(fā)的GPU顯存不足、臨時(shí)CUDA錯(cuò)誤做有限重試。限流對(duì)用戶(hù)或客戶(hù)端IP做每分鐘請(qǐng)求數(shù)限制防止惡意調(diào)用。隊(duì)列上限當(dāng)并發(fā)過(guò)大時(shí)服務(wù)的策略是“快速失敗”還是“排隊(duì)等待”要提前定好。我當(dāng)時(shí)選的是快速失敗返回503讓調(diào)用方自己退避。5.4 上線(xiàn)后的監(jiān)控沒(méi)有監(jiān)控的服務(wù)是一顆定時(shí)炸彈服務(wù)上線(xiàn)后我開(kāi)始搭建最基本的監(jiān)控指標(biāo)。不是要什么花哨的可觀測(cè)性平臺(tái)而是先把最關(guān)鍵的指標(biāo)看住。GPU監(jiān)控利用工具每10秒采集一次顯存使用率、GPU利用率和溫度寫(xiě)入時(shí)序數(shù)據(jù)庫(kù)畫(huà)到面板上。顯存持續(xù)上漲是泄漏的典型信號(hào)基本可以斷定服務(wù)代碼或推理框架有內(nèi)存管理問(wèn)題。請(qǐng)求監(jiān)控記錄QPS、P99/平均延遲、超時(shí)率和5xx錯(cuò)誤率。延遲突增和錯(cuò)誤率飆升是兩大核心告警。數(shù)據(jù)漂移監(jiān)控上線(xiàn)后的模型會(huì)面對(duì)未知的線(xiàn)上數(shù)據(jù)分布。我的做法是定期從線(xiàn)上日志里取最新的query樣本和訓(xùn)練時(shí)的query做embedding距離分布對(duì)比。如果分布偏移過(guò)大就需要考慮重新訓(xùn)練。這個(gè)問(wèn)題在文檔問(wèn)答場(chǎng)景很常見(jiàn)——業(yè)務(wù)人員提問(wèn)習(xí)慣會(huì)隨時(shí)間變化。不做監(jiān)控模型就像蒙著眼開(kāi)車(chē)。你永遠(yuǎn)不知道它在生產(chǎn)環(huán)境里已經(jīng)被用戶(hù)的真實(shí)請(qǐng)求折磨成什么樣了。6. 評(píng)測(cè)體系與回歸測(cè)試不評(píng)測(cè)等于白做6.1 評(píng)測(cè)集是AI工程的“法律文件”模型好用不好用不是訓(xùn)練指標(biāo)說(shuō)了算而是評(píng)測(cè)集說(shuō)了算。很多人只盯著訓(xùn)練集上的loss降沒(méi)降這是最大的誤區(qū)。Loss降了可能是過(guò)擬合可能是數(shù)據(jù)泄漏可能只是“背題”。真正衡量模型能力的是一份和訓(xùn)練集完全獨(dú)立、由人工標(biāo)注、覆蓋真實(shí)業(yè)務(wù)場(chǎng)景的評(píng)測(cè)集。我當(dāng)時(shí)花了兩周時(shí)間做評(píng)測(cè)集。從50萬(wàn)條數(shù)據(jù)里挑出2000條作為評(píng)測(cè)樣本覆蓋幾十種問(wèn)題類(lèi)型每條由三個(gè)人獨(dú)立標(biāo)注取多數(shù)作為最終答案。同時(shí)保證評(píng)測(cè)集里的文檔不會(huì)出現(xiàn)在訓(xùn)練集里。評(píng)測(cè)集要包含兩類(lèi)樣本常規(guī)樣本絕大多數(shù)線(xiàn)上請(qǐng)求長(zhǎng)什么樣評(píng)測(cè)集就長(zhǎng)什么樣。邊界樣本故意放一些模糊問(wèn)題、帶錯(cuò)別字的query、語(yǔ)義相近但答案不同的陷阱題。沒(méi)有邊界樣本你的評(píng)測(cè)分?jǐn)?shù)會(huì)很漂亮但上線(xiàn)后被真實(shí)用戶(hù)一問(wèn)就原形畢露。6.2 自動(dòng)化回歸測(cè)試改一個(gè)參數(shù)不要把全線(xiàn)上搞掛有了評(píng)測(cè)集下一步是把評(píng)測(cè)自動(dòng)化。我設(shè)計(jì)了一套回歸測(cè)試流程每次模型更新或者數(shù)據(jù)更新都會(huì)跑一遍。流程分三段第一段是冒煙測(cè)試。用10條左右的高置信度樣本驗(yàn)證模型能不能正常加載、推理會(huì)不會(huì)報(bào)錯(cuò)。耗時(shí)兩分鐘作用是把明顯的代碼問(wèn)題擋在門(mén)口。第二段是核心評(píng)測(cè)。用完整的2000條評(píng)測(cè)集跑一遍生成詳細(xì)報(bào)告。包括總體準(zhǔn)確率、分類(lèi)型準(zhǔn)確率、和上一版模型的對(duì)比。如果新版模型總體指標(biāo)下降超過(guò)1%除非有明確理由否則默認(rèn)不通過(guò)。第三段是錯(cuò)誤case留檔。每次評(píng)測(cè)失敗的樣本自動(dòng)記錄下來(lái)標(biāo)記“待人工分析”。這些case是數(shù)據(jù)迭代最寶貴的來(lái)源。我從這個(gè)流程里吃到最大的甜頭是再也不用擔(dān)心團(tuán)隊(duì)里任何人“偷偷把參數(shù)改了”之后影響線(xiàn)上效果看不到——自動(dòng)化測(cè)試會(huì)用指標(biāo)說(shuō)話(huà)。6.3 基于bad case的迭代閉環(huán)AI工程的“永動(dòng)機(jī)”效果提升不是靠突然的靈感而是靠對(duì)bad case的持續(xù)分析。我的操作流程是收集錯(cuò)誤樣本從評(píng)測(cè)失敗和線(xiàn)上日志里匯總bad case。聚類(lèi)分析把bad case歸類(lèi)。比如“模型分不清‘退款’和‘退貨’的區(qū)別”“模型對(duì)縮寫(xiě)理解錯(cuò)誤”“檢索結(jié)果缺失導(dǎo)致生成失敗”。每類(lèi)給一個(gè)標(biāo)簽。定位根因有些bad case是數(shù)據(jù)問(wèn)題有些是檢索問(wèn)題有些是模型能力邊界。根因不同解決方案完全不同。數(shù)據(jù)補(bǔ)強(qiáng)針對(duì)根因補(bǔ)充對(duì)應(yīng)的訓(xùn)練數(shù)據(jù)或調(diào)整清洗規(guī)則。重新訓(xùn)練和評(píng)測(cè)回到訓(xùn)練階段跑完自動(dòng)化測(cè)試看是否解決。這個(gè)循環(huán)跑上個(gè)10輪模型效果就會(huì)逐步逼近業(yè)務(wù)預(yù)期。數(shù)據(jù)版本管理、實(shí)驗(yàn)記錄、自動(dòng)化評(píng)測(cè)的意義在這個(gè)閉環(huán)里全部體現(xiàn)出來(lái)。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 環(huán)境與訓(xùn)練階段的高頻問(wèn)題現(xiàn)象常見(jiàn)原因排查思路啟動(dòng)就報(bào)“illegal memory access”CUDA版本與PyTorch不匹配先核對(duì)PyTorch官方要求的CUDA版本再檢查驅(qū)動(dòng)與CUDA訓(xùn)練中途顯存OOMbatch size過(guò)大或顯存碎片化先減小batch size或開(kāi)啟梯度累積再檢查是否有變量未釋放loss是NaN學(xué)習(xí)率過(guò)大、FP16數(shù)值不穩(wěn)定、數(shù)據(jù)里有臟標(biāo)簽降低學(xué)習(xí)率可嘗試BF16檢查數(shù)據(jù)清洗loss一直不降學(xué)習(xí)率太小或訓(xùn)練數(shù)據(jù)分布混亂快速跑5個(gè)epoch看loss斜率排除數(shù)據(jù)標(biāo)簽大量錯(cuò)誤訓(xùn)練完指標(biāo)高線(xiàn)上效果差數(shù)據(jù)泄漏或評(píng)測(cè)集覆蓋不足檢查切分是否按文檔級(jí)別補(bǔ)充邊界樣本OOM是我遇到最多的。一開(kāi)始我以為是GPU顯存不夠排查老半天發(fā)現(xiàn)是某個(gè)代碼片段把中間結(jié)果列表全部積在內(nèi)存里batch的loss都正常但內(nèi)存先爆了。用free -g看一眼系統(tǒng)內(nèi)存能快速區(qū)分是顯存還是內(nèi)存問(wèn)題。7.2 部署與服務(wù)階段的高頻問(wèn)題現(xiàn)象常見(jiàn)原因排查思路P99延遲持續(xù)走高并發(fā)排隊(duì)過(guò)多或批處理窗口設(shè)置不合理看隊(duì)列長(zhǎng)度調(diào)整動(dòng)態(tài)批處理最大等待時(shí)間GPU顯存使用率只增不減推理框架或服務(wù)代碼內(nèi)存泄漏用監(jiān)控工具觀察顯存曲線(xiàn)最小化復(fù)現(xiàn)定位是框架還是業(yè)務(wù)代碼請(qǐng)求大量返回503隊(duì)列上限觸發(fā)快速失敗放寬隊(duì)列上限或增加實(shí)例檢查限流配置是否誤傷正常用戶(hù)修改代碼后推理結(jié)果變了未固定隨機(jī)種子或模型未加載同一檢查點(diǎn)固定PYTHONHASHSEED和隨機(jī)種子核對(duì)模型路徑與config服務(wù)重啟后首次請(qǐng)求特別慢模型冷加載上線(xiàn)時(shí)寫(xiě)預(yù)熱腳本啟動(dòng)后發(fā)送幾條請(qǐng)求讓模型預(yù)熱再對(duì)外服務(wù)部署階段有個(gè)細(xì)節(jié)容易被忽視模型文件的加載路徑。我犯過(guò)一次錯(cuò)部署時(shí)從網(wǎng)盤(pán)下載模型下載完成度沒(méi)有校驗(yàn)結(jié)果服務(wù)用的是一半的權(quán)重文件準(zhǔn)確率低到不可思議還沒(méi)有報(bào)錯(cuò)。后來(lái)我在所有模型加載環(huán)節(jié)都加了一步校驗(yàn)加載后跑一遍冒煙測(cè)試檢查輸出是否符合預(yù)期。這個(gè)習(xí)慣救了我好幾次。7.3 數(shù)據(jù)層面的問(wèn)題排查數(shù)據(jù)的問(wèn)題最隱蔽因?yàn)椴粓?bào)錯(cuò)。我發(fā)現(xiàn)過(guò)一個(gè)現(xiàn)象模型對(duì)英文縮寫(xiě)理解特別差一開(kāi)始以為是模型能力問(wèn)題后來(lái)分析是清洗腳本把所有句點(diǎn)都去掉了導(dǎo)致“U.S.A”這種詞被粘連成“USA”含義還算對(duì)但“app.v1.2.3”這種版本號(hào)被破壞訓(xùn)練樣本全亂了。這類(lèi)問(wèn)題只能靠“清洗后人工抽檢”和“數(shù)據(jù)分布統(tǒng)計(jì)”這類(lèi)預(yù)防機(jī)制出了再查往往為時(shí)已晚。另一個(gè)高發(fā)問(wèn)題是重復(fù)數(shù)據(jù)。很多文檔的內(nèi)容是重復(fù)粘貼的如果不做去重某些句子在訓(xùn)練集中出現(xiàn)幾十次模型就會(huì)嚴(yán)重偏向這些說(shuō)法對(duì)其他同義表達(dá)不敏感。至少做一次MinHash或simhash去重比任何調(diào)參都管用。8. 最后分享兩個(gè)親測(cè)有效的習(xí)慣寫(xiě)到最后說(shuō)點(diǎn)不太能寫(xiě)進(jìn)項(xiàng)目匯報(bào)里的體會(huì)。第一個(gè)習(xí)慣是把每一步的關(guān)鍵決策和踩坑記錄下來(lái)。不是寫(xiě)API文檔那種而是記錄“為什么當(dāng)時(shí)那么選”“后來(lái)發(fā)現(xiàn)有什么問(wèn)題”“下次怎么做更好”。這種草根筆記看著不起眼但在項(xiàng)目中期回頭查問(wèn)題時(shí)它的價(jià)值超過(guò)任何一本教科書(shū)。第二個(gè)習(xí)慣是永遠(yuǎn)從最小閉環(huán)開(kāi)始。不要一開(kāi)始就規(guī)劃一個(gè)完美的大系統(tǒng)而是先做一個(gè)丑但通全鏈路的版本10條數(shù)據(jù)、1個(gè)模型、1個(gè)接口、10條評(píng)測(cè)樣本。跑通之后再一步步把工程化能力加進(jìn)去。所有大的AI工程問(wèn)題都是在閉環(huán)里逐個(gè)暴露、逐個(gè)解決的。從零到一搭建AI工程確實(shí)不容易但這個(gè)過(guò)程建立的工程判斷力和排錯(cuò)能力才是真正的資產(chǎn)。項(xiàng)目會(huì)結(jié)束模型會(huì)迭代但這些能力會(huì)留在這個(gè)團(tuán)隊(duì)的血液里后面的路自然會(huì)越走越穩(wěn)。