我們剛拿到一批國產(chǎn)算力設(shè)備型號(hào)就是 Atlas 800I A2要求在完全離線的內(nèi)網(wǎng)環(huán)境里把推理服務(wù)跑起來模型則鎖定了 DeepSeek-R1-Distill-Llama-70B 和 Qwen3-32B。聽起來就是一個(gè)典型的“單機(jī)多模型、離線裝環(huán)境、上線接API”的活兒真做起來卻發(fā)現(xiàn)每一環(huán)都有講究尤其是離線環(huán)境下驅(qū)動(dòng)、固件、推理引擎、模型量化這幾大件任何一環(huán)版本對(duì)不上后面全是靠日志猜。這篇文章就把我整套部署過程、踩過的坑、調(diào)參思路完整復(fù)盤一遍。材料全是自己實(shí)操記錄適合正在做國產(chǎn)化推理部署、剛剛接觸昇騰離線環(huán)境的同學(xué)參考。文章不吹參數(shù)、不堆抽象概念只講一套能落地的路徑從硬件查看到離線依賴傳遞從模型量化和目錄規(guī)劃到 MindIE 配置與雙模型服務(wù)化最后附上高頻問題排查清單。1. 項(xiàng)目概述與部署思路1.1 這個(gè)項(xiàng)目到底在解決什么問題標(biāo)題里三樣?xùn)|西分開看大家都不陌生Atlas 800I A2 是一臺(tái)面向推理場(chǎng)景的服務(wù)器MindIE 是適配昇騰芯片的推理引擎DeepSeek-R1-Distill-Llama-70B 和 Qwen3-32B 是兩個(gè)開源大模型。但把它們放進(jìn)“離線部署”這個(gè)約束條件里問題就變成了另一回事。我先說說真實(shí)的業(yè)務(wù)場(chǎng)景。某內(nèi)部業(yè)務(wù)平臺(tái)需要給不同團(tuán)隊(duì)分別提供“推理問答”和“通用對(duì)話”能力一個(gè)模型偏復(fù)雜推理、一個(gè)模型偏通用交互所以必須同時(shí)掛載兩個(gè)不同規(guī)模和不同風(fēng)格的模型。網(wǎng)絡(luò)環(huán)境是物理隔離的內(nèi)網(wǎng)無法在線拉取容器鏡像、pip 包、預(yù)編譯 wheel、模型權(quán)重所有東西都必須先在外網(wǎng)或中轉(zhuǎn)機(jī)上準(zhǔn)備齊全再通過移動(dòng)介質(zhì)或內(nèi)網(wǎng)傳輸通道拷進(jìn)去。這種情況下最怕的不是模型本身裝不好而是“傳進(jìn)去之后缺一個(gè)依賴、版本驗(yàn)不過、驅(qū)動(dòng)和固件不匹配”這類致命小問題。因?yàn)殡x線環(huán)境里每一個(gè)小補(bǔ)丁都要重新走一遍傳輸流程成本非常高。所以整個(gè)項(xiàng)目的真正難點(diǎn)在于如何把部署過程中所有可能的變數(shù)在前置準(zhǔn)備階段就徹底壓到最小。1.2 方案選型為什么是這套組合有朋友問我既然是要跑大模型為什么不用更常見的英偉達(dá) GPU 或者直接用 vLLM、TGI 這類推理框架這個(gè)問題在拿到硬件清單之前是可以討論的但設(shè)備已經(jīng)定了 Atlas 800I A2且供應(yīng)鏈上已經(jīng)不再新購其他架構(gòu)的卡討論就變成怎么在現(xiàn)有條件下做到最優(yōu)。Atlas 800I A2 屬于昇騰生態(tài)的推理服務(wù)器板卡本身對(duì)標(biāo)的場(chǎng)景就是高并發(fā)、大吞吐的在線服務(wù)。MindIE 是昇騰上原生的推理引擎它最大的優(yōu)勢(shì)是和底層芯片適配最緊密圖編譯、算子融合、KV Cache 管理這些優(yōu)化是原生內(nèi)置的。如果你在昇騰卡上硬套一個(gè)為 CUDA 設(shè)計(jì)的框架要么做一層轉(zhuǎn)換層要么大量算子走降級(jí)實(shí)現(xiàn)性能損耗非常可觀。模型的選型則和推理引擎關(guān)系不大主要是看場(chǎng)景。DeepSeek-R1-Distill-Llama-70B 屬于蒸餾過的推理增強(qiáng)模型在數(shù)學(xué)、邏輯、代碼這類任務(wù)上的表現(xiàn)比較穩(wěn)Qwen3-32B 則是通用對(duì)話能力更強(qiáng)的模型上下文理解、指令跟隨表現(xiàn)均衡。兩個(gè)模型一個(gè)偏重、一個(gè)偏輕放到同一個(gè)服務(wù)層里正好互補(bǔ)。這套方案的優(yōu)點(diǎn)在于MindIE 原生支持多模型服務(wù)化多個(gè)模型可以注冊(cè)到同一個(gè)框架內(nèi)對(duì)上層業(yè)務(wù)暴露統(tǒng)一的 OpenAI 風(fēng)格接口。整體架構(gòu)不復(fù)雜后續(xù)如果新增第三個(gè)模型不需要重新設(shè)計(jì)服務(wù)層。它的問題則是文檔相對(duì)少、社區(qū)實(shí)踐經(jīng)驗(yàn)分散離線部署更是沒有太多現(xiàn)成“抄作業(yè)”的范本。這正是我寫這篇文章的原因。1.3 完整部署流程與階段劃分整個(gè)部署可以拆成六個(gè)階段我按這個(gè)順序執(zhí)行基本沒有返工。第一階段是硬件摸底與環(huán)境檢查確認(rèn)服務(wù)器固件、板卡狀態(tài)、硬盤容量、系統(tǒng)版本這個(gè)階段花半天時(shí)間主要是避免后面裝到一半發(fā)現(xiàn)盤不夠或者固件版本過低。第二階段是離線依賴準(zhǔn)備這是整個(gè)項(xiàng)目流程里最繁瑣的一步。需要在外網(wǎng)環(huán)境把所有安裝包、鏡像、依賴庫全部搜集齊全然后按依賴關(guān)系整理成清單逐個(gè)校驗(yàn)后傳入內(nèi)網(wǎng)。第三階段是驅(qū)動(dòng)固件和基礎(chǔ)軟件棧安裝包括昇騰驅(qū)動(dòng)、固件、CANN 工具包以及后續(xù) MindIE 所依賴的 Python 環(huán)境或容器環(huán)境。第四階段是模型文件的準(zhǔn)備與量化處理。兩個(gè)模型都需要先完成格式確認(rèn)、權(quán)重校正、量化等操作并規(guī)劃好目錄結(jié)構(gòu)。第五階段是 MindIE 安裝、模型注冊(cè)、服務(wù)配置將兩個(gè)模型加載起來。第六階段是接口驗(yàn)證、并發(fā)測(cè)試和問題調(diào)優(yōu)。下面我從第一階段開始逐步展開。整個(gè)流程里最容易被低估的是第二和第四階段因?yàn)樗鼈儽砻嫔峡雌饋碇皇恰翱轿募焙汀芭芤粋€(gè)轉(zhuǎn)換腳本”實(shí)際上恰恰是后續(xù)所有報(bào)錯(cuò)的源頭。2. 硬件與軟件環(huán)境準(zhǔn)備2.1 硬件摸底從板卡到硬盤都要查清在線部署很多問題可以靠日志和重裝解決離線環(huán)境不行所以在動(dòng)手裝第一行環(huán)境之前我習(xí)慣把硬件信息全部摸一遍。首先是板卡狀態(tài)。通過昇騰設(shè)備的管理工具查看板卡數(shù)量和型號(hào)確認(rèn)能被系統(tǒng)正常識(shí)別。這里有一個(gè)關(guān)鍵點(diǎn)如果服務(wù)器里插了多張卡需要記錄每張卡的物理槽位和 ID 對(duì)應(yīng)關(guān)系。后面 MindIE 分配設(shè)備時(shí)如果指定了錯(cuò)誤的 ID模型會(huì)加載失敗。雖然可以通過工具重新枚舉但在離線場(chǎng)景下每多一次操作就多一份風(fēng)險(xiǎn)。其次是內(nèi)存容量。這里指的不是顯存而是系統(tǒng)內(nèi)存。加載一個(gè) 70B 模型光權(quán)重文件就要占用相當(dāng)大的內(nèi)存來映射如果系統(tǒng)內(nèi)存不足MindIE 會(huì)直接把模型加載階段卡死。我當(dāng)時(shí)專門看了機(jī)器的物理內(nèi)存和 swap 配置默認(rèn) swap 太小在模型加載時(shí)出現(xiàn)過奇怪的中斷后來把 swap 調(diào)大后問題消失。然后是硬盤容量與分區(qū)。兩個(gè)模型的權(quán)重文件加上量化中間文件、日志、容器鏡像輕松占用數(shù)百 GB 空間。如果機(jī)器上本來還跑了其他業(yè)務(wù)磁盤余量必須提前算清楚。我的經(jīng)驗(yàn)是模型目錄單獨(dú)分一個(gè)區(qū)避免系統(tǒng)盤被日志和臨時(shí)文件寫滿。同時(shí)要確認(rèn)文件系統(tǒng)類型推薦 ext4 或 xfs某些網(wǎng)絡(luò)文件系統(tǒng)在大文件隨機(jī)讀取時(shí)性能衰減非常明顯。最后是固件和系統(tǒng)版本。Atlas 800I A2 對(duì)固件版本有明確要求驅(qū)動(dòng)和固件版本必須匹配。我見過很多裝不上、加載失敗的問題最后查下來都是固件版本太老而折舊的固件又需要單獨(dú)的更新工具離線環(huán)境里一旦缺了這個(gè)就非常被動(dòng)。所以硬件摸底時(shí)一定要把固件版本作為必查項(xiàng)提前和驅(qū)動(dòng)版本需求校對(duì)好。2.2 離線依賴包的準(zhǔn)備與傳遞離線部署最大的工作量不在安裝而在“準(zhǔn)備”。我曾經(jīng)吃過一個(gè)虧外網(wǎng)拿到的驅(qū)動(dòng)安裝包拷進(jìn)內(nèi)網(wǎng)后才發(fā)現(xiàn)缺少一個(gè)編譯依賴庫。所以現(xiàn)在我做離線環(huán)境都會(huì)列一張“三層依賴清單”。第一層是核心安裝包包括系統(tǒng) ISO 或 yum 源、昇騰驅(qū)動(dòng)包、固件升級(jí)包、CANN 工具包、MindIE 安裝包。第二層是運(yùn)行依賴包括 python 解釋器、pip 依賴庫、編譯工具鏈、容器引擎如果走容器方式以及對(duì)應(yīng)的離線鏡像包。第三層是模型文件包括權(quán)重、分詞器、配置文件以及量化工具可能的額外依賴。這三層里最容易漏的是第三層的“工具依賴”。比如做模型量化時(shí)腳本可能需要某個(gè)版本的 transformers 或 tokenizers而你以為只是把模型拷過去就行。所以我的習(xí)慣是在源機(jī)器上先完整跑通一遍部署流程圖把每一步實(shí)際用到的依賴都記錄下來再按照這個(gè)記錄去內(nèi)網(wǎng)準(zhǔn)備。文件傳遞方面強(qiáng)烈建議在介質(zhì)導(dǎo)入后先做 MD5 校驗(yàn)。我是吃過虧的一個(gè)十幾 GB 的鏡像文件從移動(dòng)硬盤拷到服務(wù)器后導(dǎo)入時(shí)總是報(bào)損壞最后發(fā)現(xiàn)是拷貝過程中文件字節(jié)不一致。所以準(zhǔn)備了一個(gè)校驗(yàn)清單每個(gè)文件對(duì)應(yīng)一個(gè)校驗(yàn)值傳入內(nèi)網(wǎng)后逐個(gè)核對(duì)。2.3 驅(qū)動(dòng)、固件與CANN的安裝順序昇騰軟件棧的安裝順序非常嚴(yán)格通常是固件先于驅(qū)動(dòng)驅(qū)動(dòng)先于 CANNCANN 先于 MindIE。如果你先裝了 MindIE 再回頭升級(jí)驅(qū)動(dòng)很可能出現(xiàn)動(dòng)態(tài)庫鏈接版本對(duì)不上的問題當(dāng)時(shí)排查這類問題會(huì)比較痛苦。固件升級(jí)我單獨(dú)提醒一句如果服務(wù)器已經(jīng)承載了業(yè)務(wù)固件升級(jí)一般需要重啟且升級(jí)過程中不能斷電。這個(gè)操作通常建議在業(yè)務(wù)窗口期執(zhí)行不要和模型加載趕在一起。驅(qū)動(dòng)和 CANN 裝完后需要驗(yàn)證設(shè)備能否被正常枚舉。標(biāo)準(zhǔn)做法是運(yùn)行設(shè)備查詢工具看到板卡信息正常顯示、芯片狀態(tài)為健康再繼續(xù)往下走。同時(shí)確認(rèn) CANN 的環(huán)境變量是否寫入配置文件因?yàn)?MindIE 啟動(dòng)時(shí)會(huì)依賴這些環(huán)境變量來定位算子包和運(yùn)行時(shí)庫。這里有一個(gè)容易忽略的細(xì)節(jié)CANN 安裝完成后環(huán)境變量腳本可能不會(huì)被自動(dòng)加載。之后你在終端手動(dòng) source 一次沒問題但一旦以服務(wù)方式啟動(dòng) MindIE它不會(huì)讀取你的 shell 配置所以要確保環(huán)境變量寫入系統(tǒng)級(jí) profile 文件。否則模型加載時(shí)會(huì)報(bào)找不到算子或 runtime 庫的錯(cuò)誤。3. 模型文件準(zhǔn)備與量化選擇3.1 模型目錄規(guī)劃與文件檢查模型文件不是簡單仍在一個(gè)目錄里就能被 MindIE 認(rèn)出來的。每個(gè)模型應(yīng)該獨(dú)立一個(gè)目錄目錄內(nèi)部結(jié)構(gòu)與源模型保持一致權(quán)重文件、配置文件、分詞器文件缺一不可。我習(xí)慣的目錄結(jié)構(gòu)如下/models/ ├── module_info/ │ ├── deepseek-r1-distill-llama-70b/ │ │ ├── config.json │ │ ├── tokenizer.json │ │ ├── tokenizer_config.json │ │ ├── model.safetensors │ │ └── generation_config.json │ └── qwen3-32b/ │ ├── config.json │ ├── tokenizer.json │ ├── tokenizer_config.json │ ├── model.safetensors │ └── generation_config.json ├── mindie/ │ └── ... └── logs/模塊信息目錄和模型權(quán)重目錄分開的好處是模型文件可以躺在只讀存儲(chǔ)上權(quán)重不會(huì)因?yàn)槿罩竞团R時(shí)文件污染。另外強(qiáng)烈建議把 models 目錄掛載到容量足夠的單獨(dú)分區(qū)。文件檢查有三個(gè)重點(diǎn)。第一是確認(rèn)分詞器文件齊全。很多模型加載失敗并不是因?yàn)闄?quán)重壞了而是 tokenizer 文件缺失MindIE 加載時(shí)報(bào)錯(cuò)信息又偏偏不明顯。第二是檢查權(quán)重文件是否完整。如果有分片權(quán)重需要核對(duì)分片數(shù)量和總大小。第三是確認(rèn)配置文件的字段是否能被當(dāng)前 MindIE 版本解析。不同版本的 MindIE 對(duì) config.json 的兼容性有差異老版本解析新模型配置時(shí)會(huì)因?yàn)槲粗侄胃婢械母婢苯又袛嗉虞d需要手動(dòng)去掉配置里的多余字段。3.2 量化格式選型與顯存估算大模型能不能跑、能跑多大批次最核心的計(jì)算依據(jù)是顯存。先給一個(gè)通用公式所需顯存 ≈ 權(quán)重顯存 KV Cache 顯存 激活與臨時(shí)緩沖顯存其中權(quán)重顯存等于參數(shù)總量乘以每個(gè)參數(shù)占用的字節(jié)數(shù)。FP16 下每個(gè)參數(shù)占 2 字節(jié)INT8 占 1 字節(jié)INT4 占 0.5 字節(jié)。所以DeepSeek-R1-Distill-Llama-70BFP16 權(quán)重大約需要 140GB 顯存W4A16 量化后大約只需要 35GB 左右。Qwen3-32BFP16 權(quán)重約 64GBW8A8 量化后約 32GBW4A16 量化后約 16GB。你以為量化只是為了省空間其實(shí)它還直接影響推理吞吐。70B 模型如果不量化單卡顯存放不下就必須多卡張量并行卡間通信開銷會(huì)攤薄性能。量化后權(quán)重縮小單卡或雙卡就能承載通信開銷小實(shí)際端到端吞吐反而更高。MindIE 支持的量化模式并不只有一種常見的包括 W8A8、W4A16、以及帶校準(zhǔn)環(huán)節(jié)的智能量化。我的建議是追求極致精度選 W8A8追求高吞吐選 W4A16。但 W4A16 容易在低比特下造成精度損失尤其是推理鏈較長的任務(wù)中答案質(zhì)量下降會(huì)很明顯。所以我在實(shí)際項(xiàng)目中做了一個(gè)折中70B 模型用 W4A16 換取能跑起來32B 模型用 W8A8 保證通用對(duì)話質(zhì)量。這個(gè)組合最后在顯存占用和輸出質(zhì)量上表現(xiàn)都比較平衡。有一個(gè)值得強(qiáng)調(diào)的概念量化和校準(zhǔn)不是一錘子買賣。量化過程需要使用有代表性的校準(zhǔn)數(shù)據(jù)集用少量樣本統(tǒng)計(jì)出權(quán)重分布的截?cái)喾秶?。如果校?zhǔn)集選得不好量化后的模型在某些場(chǎng)景下可能輸出明顯劣化。我通常會(huì)用一小段和業(yè)務(wù)數(shù)據(jù)分布相近的文本做校準(zhǔn)而不是直接用默認(rèn)的隨機(jī)樣本。3.3 雙模型同時(shí)部署的資源分配兩個(gè)模型要同時(shí)常駐就必須提前把顯存分配方案定下來。假設(shè)部署機(jī)上單卡顯存是 64GB一共 8 張卡那么理論顯存總量是 512GB但實(shí)際可用的要打折因?yàn)楸Ａ羯倭匡@存給驅(qū)動(dòng)和運(yùn)行時(shí)。我的分配原則是先滿足精度要求更高、需要復(fù)雜推理的模型再滿足并發(fā)量更高的模型最后再用剩余顯存放輕量模型。70B 模型如果使用 W4A16量化后權(quán)重約 35GBKV Cache 和激活再加一點(diǎn)單卡 64GB 勉強(qiáng)可以跑但并發(fā)很低。實(shí)際部署中我更傾向于用 2 卡張量并行承載 70B這樣顯存余量大KV Cache 可以給足并發(fā)能力明顯上升。32B 模型 W8A8 量化后約 32GB單卡即可承載留一張卡給它就夠了。另外MindIE 在分配設(shè)備時(shí)建議使用固定的卡組不要任意跨卡。比如 0-1 號(hào)卡給 70B2 號(hào)卡給 32B剩余卡用于后續(xù)擴(kuò)容或跑其他服務(wù)。規(guī)劃好卡組后把編號(hào)寫進(jìn)配置后面所有模型實(shí)例都按這個(gè)拓?fù)鋪砼堋Ｈ绻銏D省事讓框架自動(dòng)調(diào)度一旦某個(gè)模型退出后殘留資源碎片反而更難排查。4. MindIE 推理引擎配置與模型加載4.1 部署模式容器還是裸機(jī)MindIE 本身的部署有兩種主流方式一是直接安裝在物理機(jī)操作系統(tǒng)上二是以容器方式運(yùn)行。離線環(huán)境下我優(yōu)先推薦容器。原因是容器把大量依賴關(guān)系的管理問題收斂到了鏡像內(nèi)部。你只需要導(dǎo)入一個(gè)離線鏡像啟動(dòng)容器時(shí)把模型目錄和配置文件掛載進(jìn)去容器里的環(huán)境是固定的不會(huì)因?yàn)槲锢頇C(jī)系統(tǒng)里多裝了一個(gè) Python 庫就把推理環(huán)境搞亂。而裸機(jī)方式一旦遇到系統(tǒng)庫版本沖突排查成本很高。容器鏡像的導(dǎo)入流程本身很簡單加載鏡像 tar 包確認(rèn)鏡像列表里有對(duì)應(yīng)的鏡像名然后創(chuàng)建一個(gè)啟動(dòng)腳本。這里有一個(gè)非常容易被忽略的地方——離線導(dǎo)入的鏡像是沒有原本的 tag 信息的導(dǎo)入后你可能看到一堆“None”標(biāo)簽需要手動(dòng)打 tag否則后面 run 的時(shí)候找不到鏡像名。啟動(dòng)容器時(shí)要注意幾個(gè)參數(shù)。一是掛載目錄模型目錄和日志目錄必須掛進(jìn)去。二是共享內(nèi)存大小大模型加載時(shí)共享內(nèi)存不夠會(huì)直接失敗建議啟動(dòng)時(shí)加大共享內(nèi)存參數(shù)。三是設(shè)備映射容器內(nèi)要能訪問到昇騰設(shè)備需要把對(duì)應(yīng)設(shè)備節(jié)點(diǎn)和驅(qū)動(dòng)目錄都映射進(jìn)去。4.2 模型注冊(cè)與服務(wù)配置MindIE 啟動(dòng)后模型并不自動(dòng)處于可服務(wù)狀態(tài)。需要先完成模型注冊(cè)也就是告訴推理框架“模型文件在哪個(gè)路徑、用什么格式、占用哪些卡、服務(wù)端口多少”。這個(gè)信息通常寫在一個(gè)配置文件里。以前我在內(nèi)網(wǎng)部署時(shí)配置模型路徑踩過一個(gè)坑填寫 absolute path 時(shí)手誤把路徑寫錯(cuò)了一個(gè)層級(jí)MindIE 啟動(dòng)后并沒有立刻報(bào)錯(cuò)而是等到第一個(gè)推理請(qǐng)求進(jìn)來時(shí)才提示找不到權(quán)重文件。所以我現(xiàn)在寫完配置文件后第一件事就是手動(dòng)確認(rèn)路徑存在、可讀并且用工具把目錄下的文件樹列出來核對(duì)。配置文件中比較關(guān)鍵的字段包括模型路徑、分詞器路徑、設(shè)備卡號(hào)、服務(wù)端口、最大輸入長度、最大輸出長度以及 KV Cache 分配策略。其中最大輸入輸出長度直接影響顯存占用。比如你把單次最大輸出設(shè)置成 4096 tokens而用戶請(qǐng)求都比較短那這部分預(yù)留給輸出的顯存就一直被占著峰值并發(fā)利用率很低。建議按業(yè)務(wù)實(shí)際需要設(shè)置不要貪大。4.3 兩個(gè)模型如何共用一個(gè)服務(wù)層業(yè)務(wù)方通常希望能用一個(gè)統(tǒng)一的 API 地址訪問兩個(gè)模型而不是分別給兩個(gè) IP 端口。MindIE 支持在服務(wù)層做多模型管理給業(yè)務(wù)方兩種選擇。第一種是每個(gè)模型一個(gè)獨(dú)立端口業(yè)務(wù)方按需切換。這種方式配置最簡單每個(gè)模型實(shí)例完全獨(dú)立互不影響。你可以把一個(gè)模型的服務(wù)端口設(shè)為 8001另一個(gè)設(shè)為 8002業(yè)務(wù)側(cè)根據(jù)模型種類選擇請(qǐng)求地址。第二種是統(tǒng)一入口模式通過路由參數(shù)指定目標(biāo)模型。這樣配置復(fù)雜一些但對(duì)業(yè)務(wù)方友好只在服務(wù)層暴露一個(gè)地址。兩種模式的選擇主要看上游系統(tǒng)的接入方式如果上游是一個(gè)網(wǎng)關(guān)它更希望每個(gè)模型有獨(dú)立端口便于負(fù)載均衡我會(huì)建議用第一種如果是直接客戶端調(diào)用那統(tǒng)一入口更舒服。我把兩個(gè)模型分開配置、獨(dú)立端口。這樣做的另一個(gè)好處是模型 A 升級(jí)或重啟時(shí)模型 B 的服務(wù)不受影響。如果你的業(yè)務(wù)不允許兩側(cè)同時(shí)中斷獨(dú)立端口是更穩(wěn)的選擇。下面是一份參考用的配置片段實(shí)際字段名請(qǐng)以你手里的 MindIE 版本手冊(cè)為準(zhǔn)但整體結(jié)構(gòu)是一致的model_a: model_path: /models/module_info/deepseek-r1-distill-llama-70b/ tokenizer_path: /models/module_info/deepseek-r1-distill-llama-70b/ device_ids: [0, 1] port: 8001 max_input_len: 2048 max_output_len: 1024 model_b: model_path: /models/module_info/qwen3-32b/ tokenizer_path: /models/module_info/qwen3-32b/ device_ids: [2] port: 8002 max_input_len: 4096 max_output_len: 20485. 推理驗(yàn)證與性能調(diào)優(yōu)5.1 用 curl 快速打通 API服務(wù)配置完成后先用最樸素的 curl 驗(yàn)證而不是一上來就寫復(fù)雜客戶端。這一步的目的是確認(rèn)鏈路通、模型已加載、接口格式正確。我通常先請(qǐng)求一個(gè)很短的問題例如“你好”觀察返回時(shí)間。如果這個(gè)請(qǐng)求能通再測(cè)試長上下文、多輪對(duì)話、流式輸出。驗(yàn)證命令的通用格式如下curl -X POST http://127.0.0.1:8001/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1, messages: [{role: user, content: 請(qǐng)用一句話介紹你自己}], max_tokens: 128, stream: false }如果返回結(jié)果正常再測(cè)一下流式輸出把 stream 設(shè)為 true觀察是否按 token 陸續(xù)返回。這一步在實(shí)際體驗(yàn)上非常關(guān)鍵因?yàn)榱魇捷敵瞿艽蟠蠼档陀脩舻母兄舆t。兩個(gè)模型都要各跑一輪基礎(chǔ)驗(yàn)證。很多人在部署多模型服務(wù)時(shí)只驗(yàn)證了第一個(gè)模型能通就宣布完成。但實(shí)際上第二個(gè)模型因?yàn)槎丝谡加?、卡?hào)寫錯(cuò)、路徑問題而加載失敗的情況很常見必須單獨(dú)驗(yàn)證。5.2 壓測(cè)指標(biāo)解讀與調(diào)優(yōu)方向接口通了不代表能上生產(chǎn)。我習(xí)慣用一段簡單的并發(fā)腳本模擬不同并發(fā)數(shù)下的請(qǐng)求表現(xiàn)重點(diǎn)看三個(gè)指標(biāo)首 Token 延遲、吞吐量Tokens per second、以及顯存占用。首 Token 延遲高通常不是模型算得慢而是請(qǐng)求排隊(duì)的等待時(shí)間長?？梢詸z查服務(wù)配置里的最大并發(fā)數(shù)是否太低或者 KV Cache 分配不足。吞吐量上不去先看是不是單卡算力瓶頸如果單卡利用率已經(jīng)接近上限再調(diào)參意義不大不如增加設(shè)備或減少權(quán)重位寬。顯存占用異常則要看是否有模型實(shí)例跑飛了或者最大輸入長度設(shè)置過大導(dǎo)致顯存預(yù)留給 KV Cache 的部分太多。調(diào)優(yōu)方向有四個(gè)值得優(yōu)先嘗試一是調(diào)整最大批處理 token 數(shù)。MindIE 支持動(dòng)態(tài)批處理一次性處理多個(gè)請(qǐng)求。這個(gè)值設(shè)置得太小并發(fā)一高就排隊(duì)設(shè)置得太大又會(huì)把顯存撐爆。我一般從顯存余量反推先設(shè)一個(gè)中位數(shù)壓測(cè)后根據(jù)顯存占用峰值上下調(diào)整。二是檢查 KV Cache 是否有足夠余量。對(duì)話長度越長KV Cache 占用越多。如果長對(duì)話場(chǎng)景占比高需要壓縮單實(shí)例并發(fā)數(shù)否則到一定長度后服務(wù)會(huì)強(qiáng)制截?cái)嗷蛘邎?bào)顯存不足。三是確認(rèn)是否啟用連續(xù)批處理。連續(xù)批處理能在一個(gè)請(qǐng)求生成完之前插入新的請(qǐng)求提高 GPU 利用率。這個(gè)功能在 MindIE 中通常默認(rèn)開啟但如果你在配置時(shí)關(guān)閉了并發(fā)能力會(huì)明顯下降。四是針對(duì)量化模型檢查是否開啟對(duì)應(yīng)的算子優(yōu)化。有的優(yōu)化開關(guān)在模型注冊(cè)階段才生效你改完配置后需要重啟模型實(shí)例。調(diào)優(yōu)是一個(gè)反復(fù)迭代的過程不要指望一把參數(shù)到位。我通常的做法是“先通再優(yōu)”先把功能跑通、測(cè)出基線數(shù)據(jù)再逐項(xiàng)調(diào)整配置并對(duì)比指標(biāo)每次只改一個(gè)變量這樣得到的數(shù)據(jù)才有參考價(jià)值。6. 常見問題與排查實(shí)錄6.1 離線安裝階段的高頻坑離線環(huán)境的問題大多集中在“裝不上”和“起不來”兩類。先說“裝不上”。最常見的錯(cuò)誤是依賴庫缺失。昇騰驅(qū)動(dòng)包安裝時(shí)會(huì)檢查系統(tǒng)里是否具備某些運(yùn)行庫缺了就會(huì)中斷。解決辦法是在源環(huán)境先裝好所有依賴再整體打包傳入。如果內(nèi)網(wǎng)有本地的軟件源直接配置源地址效率更高。如果沒有源只能用 RPM/DEB 包逐層安裝注意依賴順序。其次是版本不匹配。驅(qū)動(dòng)、固件、CANN、MindIE 四者之間存在版本對(duì)應(yīng)關(guān)系。你單獨(dú)看每個(gè)包都能裝上但組合起來就可能出現(xiàn)算子編譯失敗或運(yùn)行時(shí)報(bào)錯(cuò)。我的經(jīng)驗(yàn)是先確認(rèn)固件版本滿足驅(qū)動(dòng)要求再確認(rèn) MindIE 版本支持的 CANN 版本范圍。版本對(duì)應(yīng)表在離線文檔包里通常有先查再裝。還有一個(gè)很容易被忽略的點(diǎn)安裝包自帶的后綴或位寬信息。比如某個(gè)安裝包只支持 aarch64但你確認(rèn)安裝的是 x86 系統(tǒng)那裝到一半就會(huì)失敗。這類問題在核對(duì)安裝包時(shí)就要注意。6.2 模型加載與推理階段的坑模型加載階段的報(bào)錯(cuò)信息通常比較籠統(tǒng)不要指望它直接告訴你缺哪個(gè)文件。我的排查順序是先看路徑權(quán)限再看目錄結(jié)構(gòu)最后看配置字段。有一次模型加載失敗日志里只寫了“model not found”我檢查路徑后發(fā)現(xiàn)目錄存在文件也在。折騰了半天才想起是容器內(nèi)和宿主機(jī)路徑不一致掛載目錄后容器內(nèi)路徑和配置里寫的路徑差了一層導(dǎo)致文件找不到。所以先確認(rèn)容器內(nèi)實(shí)際看到的是哪個(gè)路徑再寫配置文件。推理階段的典型問題是輸出質(zhì)量差或者響應(yīng)亂碼。量化模型輸出質(zhì)量差優(yōu)先檢查量化校準(zhǔn)集是否有代表性以及量化位寬是否過于激進(jìn)。響應(yīng)亂碼則多半是 tokenizer 加載錯(cuò)誤或者請(qǐng)求里的 prompt 格式和模型訓(xùn)練時(shí)的格式不一致。還有一類隱蔽問題是端口沖突。兩個(gè)模型實(shí)例如果配了同一個(gè)端口第二個(gè)模型可能不會(huì)立刻報(bào)錯(cuò)而是在請(qǐng)求路由時(shí)隨機(jī)打到某一個(gè)實(shí)例上。驗(yàn)證時(shí)表現(xiàn)出來就是明明訪問的是模型 A返回的內(nèi)容卻像模型 B 的風(fēng)格。檢查端口占用和進(jìn)程狀態(tài)非常必要。下面是我整理的高頻問題速查表問題現(xiàn)象可能原因排查方向驅(qū)動(dòng)安裝失敗固件版本過低先升級(jí)固件再裝驅(qū)動(dòng)模型加載報(bào) model not found容器內(nèi)外路徑不一致確認(rèn)掛載后實(shí)際路徑并核對(duì)配置請(qǐng)求超時(shí)并發(fā)數(shù)或 KV Cache 分配不足調(diào)大 max_batch 或壓縮 max_output_len輸出亂碼tokenizer 路徑指向錯(cuò)誤檢查 tokenizer 文件和模型是否匹配返回內(nèi)容像是另一個(gè)模型端口沖突檢查服務(wù)端口占用和模型路由啟動(dòng)時(shí)找不到算子庫CANN 環(huán)境變量未加載確認(rèn)環(huán)境變量已寫入系統(tǒng) profile6.3 排查工具與日志路徑速查離線環(huán)境里沒有云上那種一鍵診斷平臺(tái)所有問題都要靠日志和命令行工具來定位。我建議從一開始就養(yǎng)成看日志的習(xí)慣不要等報(bào)錯(cuò)才翻。常用的日志路徑包括 MindIE 服務(wù)日志、模型加載日志、以及昇騰設(shè)備運(yùn)行時(shí)日志。這些日志的存放位置在安裝后就能通過命令查到。日志級(jí)別建議一開始就調(diào)到 debug等確認(rèn)服務(wù)穩(wěn)定后再降回 info否則排查問題時(shí)會(huì)因?yàn)槿罩拘畔⒉蛔愣鵁o從下手。設(shè)備側(cè)的排查工具有兩個(gè)關(guān)鍵命令一個(gè)是查看設(shè)備狀態(tài)和健康信息另一個(gè)是監(jiān)控實(shí)時(shí)利用率。當(dāng)服務(wù)起來后用監(jiān)控命令觀察卡上的算力占用、顯存占用如果模型已經(jīng)加載但是顯存占用一直上不去說明請(qǐng)求沒有被正確分發(fā)到設(shè)備上。最后再說一個(gè)容易被忽略的驗(yàn)證手段把日志和配置備份保留下來。每次你有動(dòng)作之前先備份當(dāng)前能用的配置和啟動(dòng)命令。離線環(huán)境下試錯(cuò)成本高備份一份可以隨時(shí)回滾的現(xiàn)場(chǎng)比什么排查技巧都管用。這次項(xiàng)目結(jié)束復(fù)盤我最大的體會(huì)是“離線部署沒有捷徑但可以有清單”。把每一步依賴、每一個(gè)版本、每一條路徑都核對(duì)清楚絕大多數(shù)坑都可以在動(dòng)手之前被提前排除。不要急著去調(diào)參、去壓測(cè)先把現(xiàn)場(chǎng)環(huán)境搞清楚比什么都強(qiáng)。最后再分享一個(gè)小技巧如果你這臺(tái) Atlas 800I A2 后續(xù)還要再擴(kuò)充模型建議把驅(qū)動(dòng)、固件、CANN、MindIE 的安裝包和鏡像單獨(dú)歸檔到一個(gè)離線倉庫目錄并維護(hù)一份版本清單。這樣后續(xù)新增模型或重建環(huán)境時(shí)就不用每次都在外網(wǎng)重新搜集材料了一臺(tái)服務(wù)器從接電到模型上線能省下大半天時(shí)間。