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