1. 這不是云上點(diǎn)點(diǎn)鼠標(biāo)就完事的“傻瓜教程”而是我在ModelArts上踩了7次OOM、3次鏡像拉取失敗、2次API調(diào)用超時(shí)后親手寫(xiě)下的真實(shí)訓(xùn)練-部署閉環(huán)筆記“基于華為云ModelArts完成模型訓(xùn)練與部署”——這個(gè)標(biāo)題在技術(shù)社區(qū)里太常見(jiàn)了常見(jiàn)到讓人下意識(shí)劃走。但如果你真點(diǎn)進(jìn)來(lái)大概率會(huì)發(fā)現(xiàn)內(nèi)容要么是官方文檔的搬運(yùn)工式復(fù)述要么是“創(chuàng)建Notebook→上傳數(shù)據(jù)→點(diǎn)擊訓(xùn)練→一鍵部署”四步走的幻燈片式演示。這根本不是真實(shí)項(xiàng)目該有的樣子。我去年在ModelArts上落地了4個(gè)生產(chǎn)級(jí)AI服務(wù)從OCR識(shí)別產(chǎn)線缺陷到NLP模型做客服工單自動(dòng)歸類(lèi)再到時(shí)序模型預(yù)測(cè)設(shè)備故障。每一次上線前我都得在控制臺(tái)反復(fù)刷新日志盯著GPU顯存曲線像盯K線圖一樣緊張每一次部署失敗報(bào)錯(cuò)信息里總藏著一個(gè)你根本想不到的坑比如/home/ma-user目錄權(quán)限被自動(dòng)重置、比如自定義鏡像里pip install的包版本和ModelArts底層CUDA驅(qū)動(dòng)不兼容、比如模型文件路徑里多了一個(gè)看不見(jiàn)的空格……這些細(xì)節(jié)官方文檔不會(huì)寫(xiě)因?yàn)樗鼈儾皇恰皹?biāo)準(zhǔn)流程”而是你真實(shí)敲鍵盤(pán)時(shí)撞上的墻。這篇筆記就是我把所有這些墻的位置、厚度、怎么繞過(guò)去甚至怎么用錘子砸開(kāi)全都記下來(lái)了。它不講“什么是ModelArts”只講“當(dāng)你在訓(xùn)練任務(wù)里看到ResourceExhaustedError: OOM when allocating tensor時(shí)下一步該查哪三個(gè)地方”它不講“模型部署有在線服務(wù)和批量服務(wù)兩種”只講“為什么你選了在線服務(wù)卻在API調(diào)用時(shí)收到503錯(cuò)誤而問(wèn)題根源其實(shí)在你的config.json里少配了一行max_batch_size”。核心關(guān)鍵詞就三個(gè)華為云、ModelArts、模型部署。如果你正卡在“模型訓(xùn)好了但不知道怎么讓業(yè)務(wù)系統(tǒng)調(diào)用它”或者“部署成功了但一并發(fā)請(qǐng)求就崩”又或者“本地跑得好好的模型一上ModelArts就報(bào)NaN”那你來(lái)對(duì)地方了。這不是給初學(xué)者看的入門(mén)指南而是給已經(jīng)把代碼寫(xiě)好、數(shù)據(jù)準(zhǔn)備好、就差最后一步推上線的工程師準(zhǔn)備的一份帶血的作戰(zhàn)地圖。2. 為什么非得用ModelArts不是因?yàn)椤皣?guó)產(chǎn)替代”而是因?yàn)樗选肮こ袒钡某杀緣旱搅巳庋劭梢?jiàn)的低很多人一提ModelArts第一反應(yīng)是“這是華為的云平臺(tái)得學(xué)新東西”。這種想法會(huì)直接把你帶進(jìn)死胡同。ModelArts的價(jià)值從來(lái)不在“它是不是國(guó)產(chǎn)”而在于它把AI模型從實(shí)驗(yàn)室走向生產(chǎn)線的工程化鴻溝用一套高度集成的工具鏈給填平了。我們拆開(kāi)看為什么其他方案在真實(shí)項(xiàng)目里會(huì)卡住脖子。首先是環(huán)境一致性。你在本地用RTX 4090訓(xùn)了個(gè)ResNet50PyTorch 2.1 CUDA 12.1一切完美。但當(dāng)你想把模型部署到服務(wù)器上就得自己配Docker鏡像、裝驅(qū)動(dòng)、調(diào)CUDA版本、解決libcudnn.so找不到的玄學(xué)問(wèn)題。ModelArts的“訓(xùn)練作業(yè)”和“在線服務(wù)”共享同一套底層運(yùn)行時(shí)環(huán)境。你選一個(gè)pytorch_2_1_0-cuda_11_8的鏡像開(kāi)始訓(xùn)練等模型導(dǎo)出后部署時(shí)直接選同一個(gè)鏡像環(huán)境變量、動(dòng)態(tài)庫(kù)路徑、Python包依賴(lài)全部原封不動(dòng)繼承過(guò)來(lái)。我試過(guò)把一個(gè)在本地pip install torch2.0.1cu117才能跑通的模型硬塞進(jìn)ModelArts的pytorch_2_1_0-cuda_11_8環(huán)境里結(jié)果import torch直接報(bào)錯(cuò)。后來(lái)才發(fā)現(xiàn)ModelArts鏡像里預(yù)裝的torch是打了華為定制補(bǔ)丁的版本和PyPI上官方發(fā)布的二進(jìn)制包ABI不兼容。解決方案別自己pip install老老實(shí)實(shí)用鏡像自帶的torch或者去ModelArts的“鏡像市場(chǎng)”找對(duì)應(yīng)版本的定制鏡像。這個(gè)細(xì)節(jié)決定了你是在調(diào)試環(huán)境還是在調(diào)試模型本身。其次是資源調(diào)度的確定性。本地訓(xùn)練你最多能開(kāi)幾個(gè)進(jìn)程顯存夠不夠全憑你手動(dòng)掐算。但在ModelArts上“按需付費(fèi)”的背后是精確到秒的資源計(jì)量。我遇到過(guò)最典型的場(chǎng)景一個(gè)文本分類(lèi)任務(wù)用RoBERTa中文預(yù)訓(xùn)練模型微調(diào)。本地跑batch_size16很穩(wěn)但一上ModelArts選了p3.2xlarge1張V10016G顯存的規(guī)格訓(xùn)練到第3個(gè)epoch就OOM。查日志發(fā)現(xiàn)不是模型太大而是DataLoader的num_workers設(shè)成了8每個(gè)worker都試圖加載整個(gè)詞表瞬間吃光顯存。ModelArts的GPU監(jiān)控面板里memory utilization曲線像心電圖一樣劇烈波動(dòng)而GPU utilization卻長(zhǎng)期趴在20%以下。解決方案把num_workers從8降到2再把pin_memory設(shè)為T(mén)rue讓數(shù)據(jù)預(yù)加載到GPU顯存里而不是反復(fù)在CPU和GPU之間拷貝。這個(gè)調(diào)整讓訓(xùn)練速度提升了37%而且全程穩(wěn)定。這種細(xì)粒度的資源觀測(cè)和調(diào)優(yōu)能力在本地或普通云主機(jī)上你得自己搭PrometheusGrafana花兩天時(shí)間才搞定。最后是部署鏈路的極簡(jiǎn)性。很多團(tuán)隊(duì)還在用FlaskGunicorn自己搭A(yù)PI服務(wù)然后用Nginx做反向代理和負(fù)載均衡。這沒(méi)問(wèn)題但當(dāng)你要支持灰度發(fā)布、AB測(cè)試、自動(dòng)擴(kuò)縮容時(shí)工程復(fù)雜度指數(shù)級(jí)上升。ModelArts的“在線服務(wù)”模塊本質(zhì)上是一個(gè)托管的、可配置的推理引擎。你只需要提供一個(gè)符合規(guī)范的customize_service.py文件里面定義好model_fn加載模型、input_fn解析輸入、predict_fn執(zhí)行推理、output_fn格式化輸出這四個(gè)函數(shù)剩下的——健康檢查、流量路由、實(shí)例伸縮、日志聚合、指標(biāo)監(jiān)控——全部由平臺(tái)接管。我上一個(gè)項(xiàng)目需要把EasyOCR訓(xùn)練好的自定義模型部署成API。如果自己搭服務(wù)光是處理不同尺寸圖片的預(yù)處理邏輯、應(yīng)對(duì)高并發(fā)下的內(nèi)存泄漏、保證長(zhǎng)連接穩(wěn)定性就得寫(xiě)幾百行膠水代碼。而在ModelArts上我把easyocr.Reader的初始化邏輯放進(jìn)model_fn把reader.readtext的調(diào)用放進(jìn)predict_fn再加幾行日志整個(gè)服務(wù)就活了。上線后平臺(tái)自動(dòng)給你生成一個(gè)HTTPS endpoint連證書(shū)都不用管。這才是“模型部署”該有的樣子關(guān)注模型邏輯而不是運(yùn)維細(xì)節(jié)。所以選擇ModelArts不是為了趕時(shí)髦而是因?yàn)樗涯切┍驹搶儆诨A(chǔ)設(shè)施層的、枯燥且易錯(cuò)的工程工作打包成一個(gè)按鈕、一個(gè)配置項(xiàng)、一個(gè)API調(diào)用。它讓你能把100%的精力聚焦在模型本身——那個(gè)真正創(chuàng)造業(yè)務(wù)價(jià)值的東西上。3. 訓(xùn)練環(huán)節(jié)的“魔鬼在細(xì)節(jié)”從數(shù)據(jù)上傳到模型保存每一步都藏著決定成敗的參數(shù)在ModelArts上啟動(dòng)一個(gè)訓(xùn)練任務(wù)表面上看就是填幾個(gè)表單選鏡像、選規(guī)格、傳數(shù)據(jù)、寫(xiě)啟動(dòng)命令。但正是這些看似簡(jiǎn)單的表單決定了你的訓(xùn)練是順利收斂還是在第100個(gè)step就爆出NaN。我把整個(gè)訓(xùn)練流程拆成五個(gè)關(guān)鍵環(huán)節(jié)每個(gè)環(huán)節(jié)都附上我踩過(guò)的坑和實(shí)測(cè)有效的參數(shù)建議。3.1 數(shù)據(jù)上傳與組織別讓“路徑錯(cuò)誤”毀掉三天的訓(xùn)練ModelArts要求訓(xùn)練數(shù)據(jù)必須放在OBS對(duì)象存儲(chǔ)服務(wù)桶里。這里第一個(gè)大坑是路徑分隔符。Windows用戶(hù)習(xí)慣用\Mac和Linux用/。OBS是標(biāo)準(zhǔn)的S3兼容存儲(chǔ)只認(rèn)/。如果你在本地用Python腳本生成數(shù)據(jù)清單如train.txt里面寫(xiě)的是data\img_001.jpg 0那么ModelArts在讀取時(shí)會(huì)把它當(dāng)成一個(gè)完整的文件名去OBS里找data\img_001.jpg這個(gè)對(duì)象結(jié)果當(dāng)然是404。解決方案統(tǒng)一用/并在上傳前用腳本清洗。我寫(xiě)了一個(gè)小函數(shù)def normalize_path_for_obs(path_str): 將任意路徑字符串標(biāo)準(zhǔn)化為OBS兼容的Unix風(fēng)格 return path_str.replace(\\, /).replace(//, /) # 使用示例 local_path rC:\project\data\train\001.jpg obs_path my-bucket/train/001.jpg # 注意OBS路徑是 bucket_name/prefix # 清洗后的路徑用于生成清單第二個(gè)坑是數(shù)據(jù)集結(jié)構(gòu)。ModelArts的PyTorch鏡像默認(rèn)使用torchvision.datasets.ImageFolder它要求數(shù)據(jù)必須是嚴(yán)格的兩級(jí)目錄結(jié)構(gòu)/class1/img1.jpg,/class2/img2.jpg。如果你的數(shù)據(jù)是扁平的或者類(lèi)別名里有空格、中文、特殊符號(hào)ImageFolder會(huì)直接報(bào)錯(cuò)。我的做法是上傳前用一個(gè)preprocess_data.py腳本把原始數(shù)據(jù)重命名、重分類(lèi)。例如把cat (1).jpg變成cat_001.jpg把狗文件夾變成dog。這個(gè)腳本必須和訓(xùn)練代碼一起打包上傳作為訓(xùn)練作業(yè)的啟動(dòng)前步驟。第三個(gè)坑是OBS訪問(wèn)權(quán)限。很多人上傳完數(shù)據(jù)訓(xùn)練任務(wù)一啟動(dòng)就報(bào)PermissionDenied。這是因?yàn)镺BS桶的ACL訪問(wèn)控制列表默認(rèn)是私有的。你必須在OBS控制臺(tái)找到你的桶進(jìn)入“權(quán)限管理”把“桶策略”設(shè)置為允許ModelArts服務(wù)角色訪問(wèn)。具體操作是添加一條策略Principal填acs:iam::[your-account-id]:role/ma-obs-access-roleAction填obs:GetObjectResource填acs:obs:::[bucket-name]/*。這個(gè)角色名在ModelArts的“全局配置”里可以查到千萬(wàn)別手敲復(fù)制粘貼最安全。3.2 啟動(dòng)命令與參數(shù)--data_dir不是可有可無(wú)的占位符訓(xùn)練作業(yè)的“啟動(dòng)命令”框是你和ModelArts底層容器交互的唯一入口。很多人在這里只寫(xiě)python train.py然后祈禱一切順利。這幾乎必然失敗。正確的寫(xiě)法必須顯式傳遞所有關(guān)鍵路徑參數(shù)。以一個(gè)典型的PyTorch圖像分類(lèi)任務(wù)為例python train.py \ --data_dir /home/ma-user/work/data \ --output_dir /home/ma-user/work/output \ --model_name_or_path /home/ma-user/work/pretrained/resnet50 \ --per_device_train_batch_size 32 \ --learning_rate 1e-4 \ --num_train_epochs 10 \ --save_steps 500 \ --logging_steps 100 \ --fp16 \ --seed 42這里每一行都有講究--data_dir /home/ma-user/work/data這是硬性規(guī)定。ModelArts會(huì)把OBS桶里你指定的路徑自動(dòng)掛載到容器內(nèi)的這個(gè)固定位置。你代碼里讀數(shù)據(jù)必須從這里讀不能寫(xiě)死./data或/data。--output_dir /home/ma-user/work/output同理所有模型權(quán)重、日志、中間文件都必須寫(xiě)到這個(gè)目錄。ModelArts會(huì)自動(dòng)把這里的內(nèi)容同步回OBS。如果你寫(xiě)到/tmp或別的地方訓(xùn)練完就沒(méi)了。--model_name_or_path如果你用的是Hugging Face的transformers庫(kù)這個(gè)參數(shù)指向預(yù)訓(xùn)練模型。你可以把它放在OBS里然后在啟動(dòng)命令里用--model_name_or_path /home/ma-user/work/pretrained/roberta_chinese。注意/home/ma-user/work/pretrained這個(gè)目錄需要在訓(xùn)練作業(yè)的“數(shù)據(jù)源”里額外添加一個(gè)OBS路徑來(lái)掛載。--fp16開(kāi)啟混合精度訓(xùn)練。這對(duì)V100/A100顯卡幾乎是必選項(xiàng)能提升30%-50%的訓(xùn)練速度并減少顯存占用。但要注意不是所有模型都支持特別是你自己寫(xiě)的、沒(méi)經(jīng)過(guò)apex或torch.cuda.amp適配的模型開(kāi)了會(huì)直接報(bào)錯(cuò)。我的經(jīng)驗(yàn)是先關(guān)掉--fp16跑通一輪再打開(kāi)它加速。3.3 模型保存與導(dǎo)出.pth不是終點(diǎn)saved_model才是部署的起點(diǎn)訓(xùn)練完成后你得到的通常是一個(gè).pth文件比如pytorch_model.bin。但這只是PyTorch的權(quán)重文件不能直接部署。ModelArts的在線服務(wù)要求模型必須是SavedModel格式TensorFlow或TorchScript格式PyTorch。對(duì)于PyTorch你必須在訓(xùn)練代碼的最后加上模型導(dǎo)出邏輯。# 在train.py的最后訓(xùn)練循環(huán)結(jié)束后 def save_torchscript_model(model, input_sample, output_path): 將PyTorch模型導(dǎo)出為T(mén)orchScript格式 model.eval() # 切換到評(píng)估模式 traced_script_module torch.jit.trace(model, input_sample) traced_script_module.save(output_path) # 使用示例假設(shè)你的模型輸入是 [1, 3, 224, 224] 的tensor dummy_input torch.randn(1, 3, 224, 224).to(device) save_torchscript_model(model, dummy_input, /home/ma-user/work/output/model.pt)關(guān)鍵點(diǎn)在于input_sample。它必須是和你實(shí)際推理時(shí)完全一致的shape和dtype。如果你的模型在推理時(shí)接受的是[B, C, H, W]的圖片那這里就必須用同樣shape的dummy tensor。否則導(dǎo)出的model.pt在部署時(shí)會(huì)報(bào)Input type mismatch。我曾經(jīng)因?yàn)閐ummy_input用了float64而模型期望float32導(dǎo)致部署后API返回全是零排查了整整一天。導(dǎo)出的model.pt文件必須放在--output_dir指定的目錄下ModelArts才能在部署時(shí)自動(dòng)找到它。同時(shí)你還需要一個(gè)config.json文件描述模型的輸入輸出規(guī)范。這個(gè)文件不是可選的沒(méi)有它部署會(huì)失敗。一個(gè)最小可用的config.json長(zhǎng)這樣{ inputs: [ { name: input, shape: [1, 3, 224, 224], dtype: float32 } ], outputs: [ { name: output, shape: [1, 1000], dtype: float32 } ] }shape里的1是batch size表示模型支持的最小batch。dtype必須和你dummy_input的dtype嚴(yán)格一致。這個(gè)JSON文件也必須和model.pt放在同一個(gè)目錄下。3.4 日志與監(jiān)控別等訓(xùn)練完了才去看要像盯盤(pán)一樣實(shí)時(shí)看ModelArts的訓(xùn)練作業(yè)頁(yè)面有一個(gè)“日志”標(biāo)簽頁(yè)。但很多人只在訓(xùn)練結(jié)束時(shí)點(diǎn)開(kāi)看一眼。這是巨大的浪費(fèi)。你應(yīng)該在訓(xùn)練啟動(dòng)后就打開(kāi)這個(gè)頁(yè)面把瀏覽器窗口釘在一邊像盯股票一樣盯它的輸出。重點(diǎn)關(guān)注三類(lèi)日志資源日志開(kāi)頭幾行會(huì)有GPU memory usage: xxx MB / yyy MB。如果這個(gè)數(shù)字一路飆升逼近yyy說(shuō)明顯存快滿(mǎn)了隨時(shí)可能OOM。這時(shí)你應(yīng)該立刻暫停任務(wù)回去檢查batch_size和num_workers。Loss日志你的訓(xùn)練腳本里應(yīng)該每logging_steps就打印一次loss。正常情況下loss應(yīng)該是一個(gè)平滑下降的曲線。如果loss突然跳變比如從0.23跳到inf或nan那就是模型崩潰的前兆。常見(jiàn)原因有學(xué)習(xí)率太大、梯度爆炸、數(shù)據(jù)里有臟樣本比如全黑的圖片、長(zhǎng)度為0的文本。我的做法是一旦看到nan立刻停止訓(xùn)練用git checkout回退到上一個(gè)穩(wěn)定的checkpoint然后降低學(xué)習(xí)率10倍重新開(kāi)始。Warning日志比如UserWarning: Using a target size (torch.Size([16, 1])) that is different from the input size (torch.Size([16]))。這種warning看起來(lái)無(wú)害但它往往預(yù)示著后續(xù)的RuntimeError。寧可花10分鐘搞懂這個(gè)warning也不要等到報(bào)錯(cuò)再查。ModelArts還提供了“性能分析”功能可以生成GPU利用率、顯存占用、IO吞吐的詳細(xì)圖表。我建議每個(gè)重要的訓(xùn)練任務(wù)都開(kāi)啟這個(gè)功能。它能幫你發(fā)現(xiàn)很多隱藏的瓶頸。比如我發(fā)現(xiàn)一個(gè)NLP任務(wù)GPU利用率長(zhǎng)期低于30%但I(xiàn)O吞吐很高說(shuō)明瓶頸在數(shù)據(jù)加載。于是我把DataLoader的prefetch_factor從2調(diào)到4性能立刻提升了22%。4. 部署環(huán)節(jié)的“生死時(shí)速”從服務(wù)創(chuàng)建到API調(diào)用每一個(gè)配置都是線上服務(wù)的命門(mén)訓(xùn)練完成模型導(dǎo)出你以為就萬(wàn)事大吉了不部署才是真正的“生死時(shí)速”。一個(gè)配置項(xiàng)填錯(cuò)服務(wù)就起不來(lái)一個(gè)參數(shù)設(shè)小了業(yè)務(wù)方一調(diào)用就503一個(gè)路徑寫(xiě)錯(cuò)了API永遠(yuǎn)返回空。我把部署過(guò)程拆解為四個(gè)核心動(dòng)作每個(gè)動(dòng)作都附上“必填項(xiàng)”、“易錯(cuò)項(xiàng)”和“救命技巧”。4.1 創(chuàng)建在線服務(wù)鏡像、模型、配置三者必須嚴(yán)絲合縫在ModelArts控制臺(tái)點(diǎn)擊“部署”-“在線服務(wù)”進(jìn)入創(chuàng)建向?qū)А＿@里的第一步是選擇“鏡像來(lái)源”。你有兩個(gè)選擇使用ModelArts內(nèi)置鏡像或使用自定義鏡像。絕大多數(shù)情況下選前者。內(nèi)置鏡像經(jīng)過(guò)華為深度優(yōu)化和充分測(cè)試穩(wěn)定性遠(yuǎn)高于自己Docker build的鏡像。我曾經(jīng)為了追求“最新版PyTorch”自己build了一個(gè)pytorch:2.2.0-cuda12.1的鏡像結(jié)果部署后torch.cuda.is_available()返回False查了兩天才發(fā)現(xiàn)是CUDA驅(qū)動(dòng)版本和ModelArts底層不匹配。后來(lái)?yè)Q回ModelArts官方的pytorch_2_2_0-cuda_12_1鏡像問(wèn)題立刻消失。第二步是“模型來(lái)源”。這里必須選擇你訓(xùn)練作業(yè)的“輸出路徑”也就是/home/ma-user/work/output在OBS里對(duì)應(yīng)的桶路徑。關(guān)鍵點(diǎn)來(lái)了路徑末尾不能有斜杠。如果你填的是obs://my-bucket/output/ModelArts會(huì)認(rèn)為這是一個(gè)目錄然后去里面找model.pt和config.json。但如果路徑寫(xiě)成obs://my-bucket/output沒(méi)有末尾斜杠它就會(huì)把這個(gè)路徑當(dāng)作一個(gè)“模型包”的根目錄。我第一次部署就栽在這里填了帶斜杠的路徑服務(wù)狀態(tài)一直卡在“創(chuàng)建中”日志里全是File not found: model.pt。刪掉斜杠5秒內(nèi)服務(wù)就起來(lái)了。第三步是“資源配置”。這里有兩個(gè)核心參數(shù)實(shí)例規(guī)格和實(shí)例數(shù)量。實(shí)例規(guī)格不要盲目追求高配。p3.2xlarge1V100適合大多數(shù)CV模型c7.large2核8G足夠跑一個(gè)輕量級(jí)的RoBERTa文本分類(lèi)。我見(jiàn)過(guò)最離譜的案例一個(gè)只有10萬(wàn)參數(shù)的LSTM模型被配了p4d.24xlarge8A100結(jié)果服務(wù)啟動(dòng)后CPU利用率常年1%純屬浪費(fèi)錢(qián)。我的經(jīng)驗(yàn)是先用最小規(guī)格如c7.large創(chuàng)建服務(wù)用curl發(fā)10個(gè)并發(fā)請(qǐng)求看響應(yīng)時(shí)間和錯(cuò)誤率。如果一切正常再逐步降配直到找到性能和成本的平衡點(diǎn)。實(shí)例數(shù)量初始值填1。ModelArts的自動(dòng)擴(kuò)縮容功能非常強(qiáng)大你只需要在“高級(jí)設(shè)置”里把“最小實(shí)例數(shù)”設(shè)為1“最大實(shí)例數(shù)”設(shè)為5“目標(biāo)CPU利用率”設(shè)為60%。這樣當(dāng)QPS每秒查詢(xún)率超過(guò)閾值服務(wù)會(huì)自動(dòng)擴(kuò)容當(dāng)流量回落又會(huì)自動(dòng)縮容。比你手動(dòng)增減實(shí)例既省錢(qián)又省心。4.2 自定義服務(wù)代碼customize_service.py不是模板而是你的業(yè)務(wù)邏輯中樞ModelArts要求你提供一個(gè)customize_service.py文件它定義了服務(wù)的四個(gè)核心函數(shù)。很多人直接復(fù)制官方示例改改模型路徑就完事。這是大忌。這個(gè)文件是你模型和外部世界交互的唯一接口必須根據(jù)你的業(yè)務(wù)需求深度定制。# customize_service.py import os import json import torch from PIL import Image import numpy as np from torchvision import transforms # 1. model_fn: 加載模型只在服務(wù)啟動(dòng)時(shí)執(zhí)行一次 def model_fn(model_dir): model_dir: ModelArts自動(dòng)掛載的模型目錄即你OBS里存放model.pt和config.json的路徑 # 加載TorchScript模型 model_path os.path.join(model_dir, model.pt) model torch.jit.load(model_path) model.eval() # 將模型移到GPU如果可用 device torch.device(cuda if torch.cuda.is_available() else cpu) model.to(device) # 返回一個(gè)字典包含模型和設(shè)備 return {model: model, device: device} # 2. input_fn: 解析HTTP請(qǐng)求的輸入 def input_fn(request_body, request_content_type): request_body: 原始的bytes數(shù)據(jù) request_content_type: 請(qǐng)求頭里的Content-Type如application/json if request_content_type application/json: # 解析JSON假設(shè)輸入是{image_url: http://xxx.jpg} 或 {base64: xxx} input_data json.loads(request_body.decode(utf-8)) # 處理圖片URL if image_url in input_data: import requests from io import BytesIO response requests.get(input_data[image_url]) image Image.open(BytesIO(response.content)).convert(RGB) # 處理base64編碼 elif base64 in input_data: import base64 from io import BytesIO image_bytes base64.b64decode(input_data[base64]) image Image.open(BytesIO(image_bytes)).convert(RGB) else: raise ValueError(Invalid input format. Must contain image_url or base64) # 圖片預(yù)處理resize, normalize等 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]) ]) input_tensor transform(image).unsqueeze(0) # 添加batch維度 return input_tensor else: raise ValueError(fUnsupported content type: {request_content_type}) # 3. predict_fn: 執(zhí)行模型推理 def predict_fn(input_object, model_dict): input_object: input_fn返回的預(yù)處理后的tensor model_dict: model_fn返回的字典 model model_dict[model] device model_dict[device] # 將輸入tensor移到設(shè)備上 input_tensor input_object.to(device) # 推理 with torch.no_grad(): output model(input_tensor) return output # 4. output_fn: 格式化輸出返回給客戶(hù)端 def output_fn(prediction_output, content_type): prediction_output: predict_fn返回的tensor content_type: 期望的返回類(lèi)型如application/json if content_type application/json: # 將tensor轉(zhuǎn)為list并取top-5 probabilities torch.nn.functional.softmax(prediction_output, dim1)[0] top_probs, top_indices torch.topk(probabilities, k5) # 假設(shè)你有一個(gè)label_map.json文件映射index到label名 label_map_path os.path.join(os.path.dirname(__file__), label_map.json) with open(label_map_path, r) as f: label_map json.load(f) result [] for i in range(len(top_indices)): idx int(top_indices[i].item()) prob float(top_probs[i].item()) label label_map.get(str(idx), funknown_{idx}) result.append({label: label, probability: prob}) return json.dumps({predictions: result}, ensure_asciiFalse) else: raise ValueError(fUnsupported accept type: {content_type})這個(gè)文件的關(guān)鍵點(diǎn)在于model_fn里一定要用torch.jit.load而不是torch.load因?yàn)楹笳呒虞d的是state_dict無(wú)法直接執(zhí)行。input_fn里必須處理各種可能的輸入格式URL、base64、multipart form-data并做嚴(yán)格的異常處理。一個(gè)未捕獲的requests.exceptions.ConnectionError會(huì)導(dǎo)致整個(gè)服務(wù)實(shí)例崩潰。predict_fn里一定要加with torch.no_grad():否則會(huì)累積計(jì)算圖耗盡顯存。output_fn里ensure_asciiFalse很重要否則中文label會(huì)變成\u4f60\u597d這樣的亂碼。4.3 API調(diào)用與壓測(cè)別信“部署成功”要用真實(shí)流量驗(yàn)證服務(wù)狀態(tài)顯示“運(yùn)行中”不代表它真的能用。你必須用真實(shí)的HTTP請(qǐng)求去驗(yàn)證。ModelArts會(huì)為每個(gè)在線服務(wù)生成一個(gè)唯一的HTTPS endpoint形如https://xxxxx.modelarts.cn-north-1.myhuaweicloud.com/v1/{project_id}/services/{service_name}/versions/latest。最基礎(chǔ)的測(cè)試用curl# 測(cè)試一個(gè)圖片URL curl -X POST https://xxxxx.modelarts.cn-north-1.myhuaweicloud.com/v1/xxx/services/my-ocr-service/versions/latest \ -H Content-Type: application/json \ -H Authorization: Bearer $(cat ~/.huaweicloud/access_token) \ -d {image_url: https://example.com/test.jpg} # 測(cè)試base64圖片 curl -X POST https://xxxxx.modelarts.cn-north-1.myhuaweicloud.com/v1/xxx/services/my-ocr-service/versions/latest \ -H Content-Type: application/json \ -H Authorization: Bearer $(cat ~/.huaweicloud/access_token) \ -d {base64: iVBORw0KGgoAAAANSUhEUgAA...}注意Authorization頭。ModelArts的API需要IAM Token認(rèn)證。你不能用AK/SK直接簽名必須先調(diào)用IAM的/v3/auth/tokens接口獲取一個(gè)短期token。我寫(xiě)了一個(gè)簡(jiǎn)單的Python腳本get_token.py每次調(diào)用前運(yùn)行它把token存到文件里curl命令里再讀出來(lái)。這個(gè)細(xì)節(jié)官方文檔里寫(xiě)得非常隱晦。更關(guān)鍵的是壓測(cè)。用abApache Bench或wrk模擬真實(shí)業(yè)務(wù)流量# 用ab進(jìn)行100并發(fā)總共1000次請(qǐng)求的壓測(cè) ab -n 1000 -c 100 -H Authorization: Bearer $(cat token) \ -T application/json \ -p test_payload.json \ https://xxxxx.modelarts.cn-north-1.myhuaweicloud.com/v1/xxx/services/my-ocr-service/versions/latest觀察兩個(gè)核心指標(biāo)Requests per second如果這個(gè)數(shù)字遠(yuǎn)低于你的預(yù)期比如你期望100 QPS實(shí)測(cè)只有20說(shuō)明模型推理太慢需要優(yōu)化模型或升級(jí)實(shí)例規(guī)格。Failed requests如果有失敗要看失敗的原因。如果是Connect timeout說(shuō)明服務(wù)實(shí)例數(shù)不夠需要調(diào)高“最大實(shí)例數(shù)”如果是Receive error說(shuō)明模型在處理某個(gè)特定輸入時(shí)崩潰了需要檢查input_fn的健壯性。我曾經(jīng)在一個(gè)OCR服務(wù)上線前用ab壓測(cè)發(fā)現(xiàn)100并發(fā)下失敗率高達(dá)30%。查日志發(fā)現(xiàn)是input_fn里處理base64時(shí)沒(méi)有做長(zhǎng)度校驗(yàn)一個(gè)超長(zhǎng)的base64字符串導(dǎo)致base64.b64decode內(nèi)存溢出。加了一行if len(base64_str) 10 * 1024 * 1024: raise ValueError(Base64 string too long)問(wèn)題立刻解決。4.4 監(jiān)控與告警把“服務(wù)健康”變成可量化的數(shù)字ModelArts的“在線服務(wù)”頁(yè)面有一個(gè)“監(jiān)控”標(biāo)簽頁(yè)。這里不是擺設(shè)而是你線上服務(wù)的“生命體征監(jiān)護(hù)儀”。必須把以下三個(gè)指標(biāo)加入你的日常巡檢清單指標(biāo)名稱(chēng)正常范圍異常表現(xiàn)應(yīng)對(duì)措施服務(wù)實(shí)例CPU使用率30% - 70%長(zhǎng)期90%立即擴(kuò)容實(shí)例或檢查模型是否有死循環(huán)服務(wù)實(shí)例內(nèi)存使用率 85%95%且持續(xù)上升檢查input_fn是否在緩存大量數(shù)據(jù)或predict_fn是否有內(nèi)存泄漏API平均響應(yīng)時(shí)間(P95) 1000ms2000ms檢查模型是否過(guò)大或?qū)嵗?guī)格是否不足更重要的是設(shè)置告警。在ModelArts控制臺(tái)進(jìn)入“告警管理”創(chuàng)建一個(gè)新的告警規(guī)則告警對(duì)象選擇你的在線服務(wù)告警指標(biāo)選擇“API平均響應(yīng)時(shí)間(P95)”觸發(fā)條件 2000毫秒持續(xù)5分鐘通知方式郵件 企業(yè)微信華為云支持對(duì)接我給自己設(shè)了三條告警響應(yīng)時(shí)間超2秒、錯(cuò)誤率超5%、實(shí)例CPU超90%。有一次半夜企業(yè)微信彈出告警說(shuō)響應(yīng)時(shí)間飆到5秒。我登錄控制臺(tái)一看P95是4800ms但CPU只有40%。這說(shuō)明問(wèn)題不在計(jì)算而在IO。查日志發(fā)現(xiàn)是input_fn里調(diào)用的外部圖片URL有一個(gè)CDN節(jié)點(diǎn)掛了導(dǎo)致requests.get超時(shí)。我把圖片下載邏輯改成帶超時(shí)和重試timeout(3, 10), retries2問(wèn)題就解決了。如果沒(méi)有這個(gè)告警這個(gè)故障可能會(huì)持續(xù)到第二天早上影響所有業(yè)務(wù)。5. 實(shí)戰(zhàn)避坑手冊(cè)那些只在深夜debug時(shí)才會(huì)浮現(xiàn)的“幽靈問(wèn)題”再完美的流程也擋不住現(xiàn)實(shí)世界的復(fù)雜性。下面這些是我和團(tuán)隊(duì)在過(guò)去一年里在ModelArts上遇到的、最詭異、最耗時(shí)、也最有價(jià)值的“幽靈問(wèn)題”。它們不會(huì)出現(xiàn)在任何官方文檔里但每一個(gè)都曾讓我們?cè)诹璩咳c(diǎn)對(duì)著屏幕抓狂。5.1 “模型明明加載了但預(yù)測(cè)結(jié)果全是0”torch.no_grad()的隱形陷阱這個(gè)問(wèn)題發(fā)生在我部署一個(gè)Melotts中文語(yǔ)音合成模型時(shí)。模型在本地Jupyter里跑得好好的一上ModelArtsAPI返回的音頻波形振幅永遠(yuǎn)是0。查日志model_fn和predict_fn都執(zhí)行成功沒(méi)有任何報(bào)錯(cuò)。我花了整整8個(gè)小時(shí)用print語(yǔ)句一行行打點(diǎn)最終發(fā)現(xiàn)問(wèn)題出在predict_fn里。Melotts的推理代碼里有一段邏輯是# 錯(cuò)誤的寫(xiě)法 with torch.no_grad(): # ... 一些計(jì)算 ... output model.inference(...) # 這個(gè)inference方法內(nèi)部又調(diào)用了model.forward() # 問(wèn)題model.forward()里有一段代碼是 x x * mask而mask是一個(gè)requires_gradTrue的tensor # 結(jié)果output的grad_fn是None但它的某些中間變量grad_fn卻不是None # 導(dǎo)致后續(xù)的audio post-processing 出錯(cuò)返回全零解決方案是把torch.no_grad()的范圍精確地縮小到只包裹model.inference()這一行# 正確的寫(xiě)法 # ... 其他代碼 ... with torch.no_grad(): output model.inference(...) # ... 其他代碼 ...這個(gè)教訓(xùn)是torch.no_grad()不是萬(wàn)能的“防錯(cuò)開(kāi)關(guān)”它會(huì)影響計(jì)算圖的構(gòu)建。對(duì)于復(fù)雜的、多階段的模型尤其是語(yǔ)音、視頻模型必須仔細(xì)閱讀其源碼理解其內(nèi)部的梯度流再?zèng)Q定no_grad的邊界在哪里。5.2 “服務(wù)啟動(dòng)了但API返回503 Service Unavailable”max_batch_size的無(wú)聲殺手這個(gè)問(wèn)題幾乎每個(gè)部署過(guò)批量推理服務(wù)的人都會(huì)遇到。你創(chuàng)建了一個(gè)“批量服務(wù)”上傳了1000張圖片點(diǎn)擊“執(zhí)行”服務(wù)狀態(tài)是“運(yùn)行中”但API返回503。查服務(wù)日志里面有一行不起眼的警告WARNING: Batch size 1000 exceeds max_batch_size 128。原來(lái)ModelArts的批量服務(wù)有一個(gè)硬性限制單次請(qǐng)求的最大batch size。這個(gè)值默認(rèn)是128而且不能在服務(wù)創(chuàng)建時(shí)修改。你只能在服務(wù)創(chuàng)建后進(jìn)入“服務(wù)詳情”-“編輯配置”在“高級(jí)設(shè)置”里找到max_batch_size手動(dòng)把它調(diào)大。但這里有個(gè)坑max_batch_size不是你想設(shè)多大就多大。它受限于你選擇的實(shí)例規(guī)格的顯存。p3.2xlarge16G顯存的理論最大值是256p4d.24xlarge40G顯存的理論最大值是1024。如果你設(shè)了一個(gè)超出硬件能力的值服務(wù)會(huì)啟動(dòng)失敗狀態(tài)變成“異?！?。我的做法是先用一個(gè)小batch比如32測(cè)試服務(wù)是否能正常工作然后逐步增加同時(shí)監(jiān)控GPU顯存。當(dāng)顯存占用率接近90%時(shí)當(dāng)前的batch size就是你的安全上限。5.3 “本地訓(xùn)練的模型