簡介一份面向醫(yī)療信息化、智慧急救與區(qū)域協(xié)同平臺(tái)建設(shè)者的完整方案PPT聚焦5GAI在急救場景中的落地可用于產(chǎn)品規(guī)劃、項(xiàng)目申報(bào)或技術(shù)方案參考。資源包共1個(gè)文件為pptx演示文稿約871KB內(nèi)容涵蓋項(xiàng)目背景與業(yè)務(wù)痛點(diǎn)、總體架構(gòu)、核心功能模塊、關(guān)鍵技術(shù)、應(yīng)用場景、實(shí)施計(jì)劃與預(yù)期效益等完整章節(jié)。已有44人學(xué)習(xí)。方案詳細(xì)展示了5G低時(shí)延、網(wǎng)絡(luò)切片、邊緣計(jì)算、AI預(yù)測算法與智能優(yōu)先級算法如何用于急救通信、調(diào)度指揮、遠(yuǎn)程會(huì)診和病患分級預(yù)警并給出數(shù)據(jù)層、平臺(tái)層、應(yīng)用層、安全層的分層架構(gòu)設(shè)計(jì)。讀者可快速獲得一套從痛點(diǎn)到落地的智慧急救平臺(tái)建設(shè)思路適合用于方案撰寫、內(nèi)部培訓(xùn)或投標(biāo)材料的框架參考。1. 從響應(yīng)快到?jīng)Q策快5G智慧急救AI區(qū)域協(xié)同平臺(tái)到底在解決什么急救業(yè)務(wù)里有個(gè)老生常談的黃金4分鐘但真正做過院前急救信息化的人清楚瓶頸往往不在救護(hù)車抵達(dá)之前而在車到現(xiàn)場之后。心電圖、血壓、血氧、車內(nèi)視頻要傳回區(qū)域中心值班醫(yī)生要判斷該不該啟動(dòng)卒中中心或胸痛中心院內(nèi)要提前備床、備手術(shù)室。這一串動(dòng)作里5G解決的不只是把視頻傳回去而是把過去電話調(diào)度加人工判讀的模式替換成AI先做一版預(yù)判、區(qū)域平臺(tái)再統(tǒng)一調(diào)度資源。所謂區(qū)域協(xié)同就是讓急救站點(diǎn)、救護(hù)車、醫(yī)院、指揮中心在同一張數(shù)據(jù)平面上聯(lián)動(dòng)5G承載這張網(wǎng)AI把數(shù)據(jù)變成決策。這份5G智慧急救AI區(qū)域協(xié)同平臺(tái)建設(shè)方案真正硬核的部分不在服務(wù)器采購清單而在三件事網(wǎng)絡(luò)時(shí)延能否壓到指標(biāo)內(nèi)、AI推理跑在哪個(gè)位置不拖后腿、5G鏈路抖動(dòng)時(shí)業(yè)務(wù)如何不中斷。下面按一名網(wǎng)絡(luò)工程師與AI應(yīng)用工程師協(xié)同交付的視角把架構(gòu)選型、數(shù)據(jù)鏈路、驗(yàn)證方法、排錯(cuò)手段依次講透。適合正在做醫(yī)療信息化、5G專網(wǎng)集成或AI輔助診斷落地的團(tuán)隊(duì)參考。2. 5G基站與MEC邊緣節(jié)點(diǎn)急救場景的網(wǎng)絡(luò)架構(gòu)選型2.1 5G網(wǎng)絡(luò)切片與5QI優(yōu)先級先把業(yè)務(wù)等級定清楚5G智慧急救平臺(tái)要傳的數(shù)據(jù)不只是視頻。心電波形要求低時(shí)延但數(shù)據(jù)量小車內(nèi)全景視頻要求大上行帶寬但能容忍幾百毫秒時(shí)延AI預(yù)判結(jié)果必須低時(shí)延高可靠。如果全部走默認(rèn)承載高峰時(shí)跟普通視頻流量搶資源關(guān)鍵數(shù)據(jù)就可能被擠掉。此時(shí)需要引入5G網(wǎng)絡(luò)切片。以SA架構(gòu)為例切片選擇發(fā)生在核心網(wǎng)控制面終端通過NSSAI攜帶切片標(biāo)識(shí)核心網(wǎng)依據(jù)簽約數(shù)據(jù)把PDU會(huì)話分流到對應(yīng)切片實(shí)例。車載業(yè)務(wù)和公眾業(yè)務(wù)在核心網(wǎng)側(cè)隔離資源互相不擠占。另一個(gè)更細(xì)的粒度是5QI它決定數(shù)據(jù)包在基站調(diào)度器和UPF上的轉(zhuǎn)發(fā)優(yōu)先級、時(shí)延預(yù)算與丟包率要求。急救平臺(tái)不建議把業(yè)務(wù)全部塞進(jìn)同一個(gè)5QI而是按下表劃分業(yè)務(wù)類型5QI參考值資源類型預(yù)期時(shí)延預(yù)算典型用途心電、生命體征上行3GBR50ms級實(shí)時(shí)波形傳輸與AI判讀車內(nèi)視頻上行82non-GBR10ms級全景視頻、搶救過程留痕AI決策結(jié)果下行3GBR50ms級平臺(tái)下發(fā)的診斷提示與調(diào)度指令病歷、日志文件6non-GBR300ms級補(bǔ)充病歷、工作日志上傳提示上表為常見參考值實(shí)際生效值以運(yùn)營商核心網(wǎng)現(xiàn)網(wǎng)策略為準(zhǔn)。尤其要確認(rèn)GBR業(yè)務(wù)的帶寬門限否則AI決策下發(fā)在網(wǎng)絡(luò)擁塞時(shí)可能被延遲處理。5QI和切片的配置通常由運(yùn)營商在核心網(wǎng)完成園區(qū)側(cè)能做的是確保終端側(cè)參數(shù)匹配。常見做法是讓車載CPE的APN/DNN指向急救專網(wǎng)在PDU會(huì)話建立請求里攜帶切片標(biāo)識(shí)同時(shí)把UPF分流規(guī)則限定為指定目的地址段。上線前有一項(xiàng)必做檢查從車載側(cè)看AI服務(wù)地址是不是走專網(wǎng)路由。如果包被轉(zhuǎn)發(fā)到公網(wǎng)出口說明UPF分流規(guī)則沒匹配到MEC網(wǎng)段時(shí)延和安全性都會(huì)出問題。舉例來說心電波形若被劃進(jìn)低優(yōu)先級5QI急救車在大文件上傳場景下心跳包會(huì)排在視頻業(yè)務(wù)后面大屏上的波形就會(huì)出現(xiàn)鋸齒狀卡頓這類問題只有從QoS配置層面才能根治。2.2 邊緣節(jié)點(diǎn)部署在哪從基站到MEC的本地分流拓?fù)銩I推理放哪里直接決定端到端時(shí)延。以一個(gè)地市級區(qū)域協(xié)同平臺(tái)為例常見架構(gòu)分三層救護(hù)車車載終端、MEC邊緣節(jié)點(diǎn)、區(qū)域中心機(jī)房。車載終端采集生命體征與視頻5G基站無線接入后數(shù)據(jù)經(jīng)UPF分流到就近的MEC節(jié)點(diǎn)MEC上跑AI推理服務(wù)結(jié)果再同步到區(qū)域中心做跨院區(qū)調(diào)度。關(guān)鍵點(diǎn)在UPF的分流規(guī)則常用的是上行分類器UL CL或本地分流方案讓去往MEC AI服務(wù)IP的流量在本地卸載不再繞行核心網(wǎng)。這個(gè)拓?fù)湎聫?G基站空口到MEC的單程時(shí)延通常能做到5到15ms比繞行核心網(wǎng)少一跳抖動(dòng)也小得多。部署位置上我一般建議把MEC節(jié)點(diǎn)放在地市級中心機(jī)房或急救網(wǎng)絡(luò)匯聚點(diǎn)而不是每個(gè)5G基站都放一套。急救調(diào)度是區(qū)域級行為邊緣節(jié)點(diǎn)太少時(shí)延覆蓋差太多AI模型生命周期管理和算力成本都會(huì)失控。一個(gè)地級市按地理片區(qū)劃分兩到三個(gè)邊緣節(jié)點(diǎn)即可滿足每個(gè)節(jié)點(diǎn)部署GPU推理卡和容器服務(wù)即可。若三甲醫(yī)院自有5G專網(wǎng)基站節(jié)點(diǎn)可以再下探到醫(yī)院機(jī)房院內(nèi)急會(huì)診的AI輔助判讀走院內(nèi)閉環(huán)數(shù)據(jù)不出院區(qū)對病歷隱私和跨院調(diào)度都更友好。2.3 車載終端與基站切換接入側(cè)的可靠性設(shè)計(jì)救護(hù)車沿途要穿過大量5G基站的覆蓋范圍必然涉及小區(qū)切換。切換過程會(huì)出現(xiàn)數(shù)十毫秒到數(shù)百毫秒的中斷窗口對視頻影響可控對AI決策下發(fā)這種小包影響有限但若恰好落在切換窗口仍可能觸發(fā)TCP重傳。工程上常用手段有兩類一是車載CPE支持雙卡主備或雙鏈路選發(fā)主卡走專網(wǎng)備卡走運(yùn)營商公眾網(wǎng)絡(luò)二是將上行數(shù)據(jù)拆成更小的分片降低單包在空口的駐留時(shí)間。后者對視頻不太友好一般只用在心電等小包關(guān)鍵業(yè)務(wù)上?；緜?cè)的切換定時(shí)器同樣需要關(guān)注。比如T304定時(shí)器它約束終端在切換過程中的等待時(shí)長車在高速路上移動(dòng)時(shí)若T304設(shè)置過短切換容易失敗反之會(huì)讓終端在信號(hào)已經(jīng)崩潰的小區(qū)上遲遲不重選。建議在現(xiàn)場拉網(wǎng)測試時(shí)把車速60km/h、80km/h、120km/h三檔場景各跑一遍依據(jù)切換成功率回調(diào)運(yùn)營商側(cè)的定時(shí)器參數(shù)。配置完成后可在支持自行刷機(jī)的5G CPE上檢查PDU會(huì)話狀態(tài)# 查看PDU會(huì)話地址是否落在專網(wǎng)網(wǎng)段 ip addr show wwan0 # 查看默認(rèn)路由是否指向UPF的N6接口網(wǎng)關(guān) ip route show提示多數(shù)商用CPE不開放shell這條命令只適用于可自行刷機(jī)調(diào)試的工程測試設(shè)備。拿不到shell時(shí)就在管理面看上報(bào)的IP是否屬于專網(wǎng)地址段。3. 區(qū)域協(xié)同平臺(tái)的數(shù)據(jù)鏈路與AI推理最小實(shí)現(xiàn)3.1 從救護(hù)車到AI服務(wù)的協(xié)議與數(shù)據(jù)結(jié)構(gòu)網(wǎng)絡(luò)通了接下來是數(shù)據(jù)怎么組織。區(qū)域協(xié)同平臺(tái)的核心鏈路是車載采集端 → 5G接入 → MEC推理服務(wù) → 區(qū)域中心調(diào)度引擎。這四段之間需要一套能容忍弱網(wǎng)、便于壓縮、帶時(shí)間戳的報(bào)文格式。常見做法是JSON行協(xié)議每條報(bào)文一行包含消息類型、終端ID、時(shí)間戳、業(yè)務(wù)數(shù)據(jù)與質(zhì)量標(biāo)志。急救場景對時(shí)間敏感終端上送數(shù)據(jù)時(shí)必須帶設(shè)備本地時(shí)間并在MEC側(cè)換算成網(wǎng)絡(luò)時(shí)間否則后續(xù)時(shí)延統(tǒng)計(jì)和AI時(shí)序分析都會(huì)錯(cuò)位。下面給出一版最小數(shù)據(jù)結(jié)構(gòu)實(shí)際交付時(shí)可擴(kuò)展為Protobuf以減小空口開銷{ msg_type: vitals.upload, ambulance_id: AMB-0031, ts_msec: 1700000000123, vitals: {heart_rate: 118, spo2: 88, ecg_rhythm: afib}, payload_len: 96, seq: 128 }字段中ts_msec表示設(shè)備采集時(shí)刻的毫秒時(shí)間戳seq用于MEC側(cè)做亂序和重傳檢測payload_len供接收端校驗(yàn)完整性避免半包解析。注意這里刻意不把AI判讀結(jié)果放進(jìn)上行報(bào)文上行只負(fù)責(zé)原始數(shù)據(jù)推理結(jié)果走獨(dú)立的下行通道便于兩類消息設(shè)置不同的5QI也方便故障時(shí)區(qū)分到底是采集問題還是推理問題。3.2 用Python模擬一條急救業(yè)務(wù)上行鏈路在邊緣節(jié)點(diǎn)和平臺(tái)側(cè)開發(fā)還沒就緒時(shí)可用一段Python腳本模擬車載端上報(bào)壓力測試MEC的接收能力。這個(gè)腳本會(huì)周期性地組裝JSON報(bào)文通過socket發(fā)給MEC的推理服務(wù)端口并統(tǒng)計(jì)每次發(fā)送耗時(shí)。# ambulance_sender.py # 模擬救護(hù)車車載端向MEC推理服務(wù)上報(bào)生命體征 import json, socket, time EDGE_AI_HOST 10.10.1.100 # MEC上AI服務(wù)的專網(wǎng)地址 EDGE_AI_PORT 8080 INTERVAL 1.0 # 上報(bào)周期(秒) TIMEOUT 0.5 # 發(fā)送超時(shí)超過即認(rèn)為鏈路不可達(dá) def collect_vitals(): # 真實(shí)環(huán)境改為讀取監(jiān)護(hù)儀驅(qū)動(dòng)數(shù)據(jù) return {heart_rate: 118, spo2: 88, ecg_rhythm: afib} def send_report(seq): vt collect_vitals() msg {msg_type: vitals.upload, ambulance_id: AMB-0031, ts_msec: int(time.time() * 1000), vitals: vt, seq: seq} data json.dumps(msg).encode(utf-8) b\n t0 time.monotonic() with socket.create_connection((EDGE_AI_HOST, EDGE_AI_PORT), timeoutTIMEOUT) as s: s.sendall(data) return (time.monotonic() - t0) * 1000 seq 0 while True: cost send_report(seq) print(fseq{seq} send_cost_ms{cost:.1f}) seq 1 time.sleep(INTERVAL)這一段重點(diǎn)在于TIMEOUT的設(shè)置。急救場景中鏈路短暫抖動(dòng)是常態(tài)超時(shí)設(shè)得太小會(huì)讓腳本頻繁報(bào)錯(cuò)太大又會(huì)拖住主循環(huán)。經(jīng)驗(yàn)值取500ms與5G切換中斷窗口相當(dāng)既能暴露問題又不至于把偶發(fā)抖動(dòng)放大成故障。send_report返回的應(yīng)用層發(fā)送耗時(shí)不等于空口時(shí)延它只是給開發(fā)階段一個(gè)相對成本參考真正驗(yàn)收要用第4章的撥測方法。如果循環(huán)里連續(xù)三次發(fā)送超時(shí)說明PDU會(huì)話可能已經(jīng)中斷需要觸發(fā)CPE重?fù)芑蚯袚Q到備卡。3.3 AI推理的模型位置與調(diào)度參數(shù)大模型和輕量模型分層干活A(yù)I大模型在醫(yī)療領(lǐng)域的輔助能力已經(jīng)很可觀但直接塞進(jìn)救護(hù)車終端不現(xiàn)實(shí)放在區(qū)域中心又太遠(yuǎn)。常見的做法是在MEC節(jié)點(diǎn)上部署雙層推理第一層是輕量模型用心電、血氧這類數(shù)值型特征做快速異常分類毫秒級返回第二層是可選的大型模型對判斷困難或數(shù)據(jù)完整的病例做結(jié)構(gòu)化解讀用時(shí)更長但結(jié)論更完整。兩層共享同一套上報(bào)接口根據(jù)特征閾值決定是否升級到大模型避免每個(gè)心跳都占用大模型推理資源。邊緣側(cè)推理服務(wù)的調(diào)度參數(shù)可以從三處調(diào)推理服務(wù)的超時(shí)閾值、最大并發(fā)數(shù)、以及是否啟用緩沖隊(duì)列。心電異常檢測這類任務(wù)單請求推理應(yīng)在20ms內(nèi)完成超時(shí)上限建議200ms若平均推理時(shí)延超過100ms優(yōu)先檢查GPU顯存占用和輸入預(yù)處理是否成了瓶頸而不是盲目加節(jié)點(diǎn)。對于大模型調(diào)用要設(shè)置結(jié)果超時(shí)和應(yīng)用層降級策略比如2秒內(nèi)沒返回就回退到輕量模型的結(jié)論并提示人工復(fù)核。此時(shí)AI輔助決策更像一個(gè)有工具調(diào)用能力的agent先做數(shù)值判讀必要時(shí)再請求多模態(tài)分析最后把結(jié)構(gòu)化建議推給區(qū)域中心調(diào)度引擎。4. 5G網(wǎng)絡(luò)時(shí)延驗(yàn)證與信令排錯(cuò)上線前必做的科目4.1 從終端到MEC的RTT與上行帶寬撥測AI服務(wù)已經(jīng)跑在MEC上接下來要回答一個(gè)問題方案里的時(shí)延指標(biāo)到底達(dá)沒達(dá)標(biāo)。驗(yàn)證不能只依賴ping平均時(shí)延要看分布和抖動(dòng)。標(biāo)準(zhǔn)做法是從車載CPE的LAN側(cè)接入測試終端向MEC的AI服務(wù)地址發(fā)起分組時(shí)延測試。注意ICMP包最好包一層真實(shí)業(yè)務(wù)負(fù)載大小心電子包通常為256字節(jié)視頻包為1024字節(jié)左右。# 每200ms發(fā)一個(gè)1024字節(jié)的包持續(xù)200次 ping -i 0.2 -s 1024 -c 200 10.10.1.100 # 連續(xù)UDP上行打流觀察丟包與時(shí)延分布 iperf3 -c 10.10.1.100 -u -b 8M -t 60 --get-server-output實(shí)測結(jié)果怎么看RTT均值只代表鏈路基線重點(diǎn)看90分位和最大抖動(dòng)?？湛谡r(shí)專網(wǎng)內(nèi)RTT通常保持在10ms上下如果看到某個(gè)周期的RTT突然跳到150ms以上多半是發(fā)生了基站切換或重傳需要結(jié)合網(wǎng)管確認(rèn)時(shí)間點(diǎn)。iperf3的UDP模式可以測上行丟包率和接收端抖動(dòng)若丟包率高于0.1%且集中在某段測試區(qū)間基本能鎖定是無線弱覆蓋或小區(qū)負(fù)載過高而不是平臺(tái)側(cè)問題。測試路線建議覆蓋急救車真實(shí)行駛路徑避免只在基站近點(diǎn)測出好看數(shù)據(jù)。4.2 切換與信令流程對AI推理連續(xù)性的影響急救車跨基站移動(dòng)時(shí)5G信令流程中的測量報(bào)告、切換命令和執(zhí)行過程都會(huì)短暫占用空口資源。對AI推理服務(wù)來說更關(guān)鍵的是PDU會(huì)話在切換后是否保持。5G的N2切換基于N2信令終端不換PDU會(huì)話錨點(diǎn)時(shí)延影響通常只有幾十毫秒但若跨UPF切換隧道重新建立中斷窗口會(huì)長很多?？紤]到急救車急救路線相對固定部署時(shí)盡量把MEC節(jié)點(diǎn)放在高頻活動(dòng)路線的匯聚位置避免頻繁跨UPF。另一個(gè)容易被忽略的點(diǎn)是隨機(jī)接入的preamble格式。在弱覆蓋或遠(yuǎn)距離場景下長格式的preamble能提升上行同步成功率但會(huì)占更多時(shí)隙如果配置過長小區(qū)整體接入容量會(huì)下降。急救車從邊緣小區(qū)切入時(shí)若preamble配置與覆蓋環(huán)境不匹配會(huì)出現(xiàn)切換后首次上行數(shù)據(jù)丟失。排查時(shí)先看基站側(cè)切換成功率和RRC重建次數(shù)再?zèng)Q定是否調(diào)整格式不要在沒數(shù)據(jù)的情況下盲改。4.3 急救協(xié)同平臺(tái)的常見故障定位表把網(wǎng)絡(luò)問題和應(yīng)用問題分清楚能省掉大量扯皮。下面是交付過程中最常遇到的幾類現(xiàn)象和定位手段現(xiàn)象可能原因定位手段心跳數(shù)據(jù)周期性中斷基站切換或終端休睡調(diào)度在CPE側(cè)抓包對比中斷時(shí)刻與切換日志AI服務(wù)偶發(fā)超時(shí)MEC側(cè)并發(fā)隊(duì)列堆積或GC停頓查看推理服務(wù)平均時(shí)延與活躍請求數(shù)上行視頻卡頓切片帶寬不足或5QI優(yōu)先級失效在UPF側(cè)查詢GBR用量與丟包計(jì)數(shù)下發(fā)指令延遲高下行路由繞行或DNN不對檢查PDU會(huì)話地址段與核心網(wǎng)轉(zhuǎn)發(fā)路徑跨院區(qū)調(diào)度不同步區(qū)域中心與MEC數(shù)據(jù)一致性問題比對兩級數(shù)據(jù)庫同步延遲和重試次數(shù)排查有一個(gè)原則先從網(wǎng)絡(luò)側(cè)排除RRC重建、切換失敗和丟包這三項(xiàng)再進(jìn)應(yīng)用層。5G網(wǎng)絡(luò)的隱蔽故障往往表現(xiàn)為時(shí)延偶爾變大這種軟性癥狀不會(huì)直接報(bào)錯(cuò)先拉網(wǎng)管數(shù)據(jù)能快速圈定范圍。5. 把協(xié)同延遲再壓一檔應(yīng)用層優(yōu)先級隊(duì)列與邊緣節(jié)點(diǎn)容災(zāi)5.1 在平臺(tái)側(cè)實(shí)現(xiàn)急救業(yè)務(wù)的多級優(yōu)先級隊(duì)列前面把5QI規(guī)劃到了網(wǎng)絡(luò)層但AI調(diào)度引擎入口還需要一道應(yīng)用層優(yōu)先級隊(duì)列。網(wǎng)絡(luò)層保障包傳輸應(yīng)用層保障計(jì)算資源的分配順序。區(qū)域協(xié)同平臺(tái)的調(diào)度引擎會(huì)收到心臟驟停預(yù)警、卒中疑似預(yù)警、普通轉(zhuǎn)運(yùn)信息三類消息對延遲的容忍差異很大適合用帶截止時(shí)間的優(yōu)先級隊(duì)列管理# priority_queue_edf.py # 結(jié)合截止時(shí)間與業(yè)務(wù)優(yōu)先級的急救任務(wù)調(diào)度隊(duì)列 import heapq, time class EmergencyTask: def __init__(self, task_id, deadline_ms, priority, payload): self.task_id task_id self.deadline time.monotonic() deadline_ms / 1000 self.priority priority # 0最高2最低 self.payload payload def __lt__(self, other): # 先看任務(wù)是否臨近截止時(shí)間再看業(yè)務(wù)優(yōu)先級 if abs(self.deadline - other.deadline) 0.1: return self.priority other.priority return self.deadline other.deadline queue [] heapq.heappush(queue, EmergencyTask(cardiac, 500, 0, {spo2: 82})) heapq.heappush(queue, EmergencyTask(transfer, 3000, 2, {note: routine}))這個(gè)隊(duì)列先按截止時(shí)間排序截止時(shí)間接近時(shí)再按業(yè)務(wù)優(yōu)先級排序能兼顧急性任務(wù)和普通任務(wù)避免心臟驟停預(yù)警被轉(zhuǎn)運(yùn)類任務(wù)的長耗時(shí)拖住。實(shí)際部署時(shí)把兩類消息的deadline_ms分別設(shè)為500和3000再對心跳缺失和重復(fù)上報(bào)做冪等過濾即可。5.2 邊緣節(jié)點(diǎn)的健康檢查與自動(dòng)降級上一節(jié)處理的是任務(wù)排隊(duì)邊緣節(jié)點(diǎn)本身也會(huì)失效。MEC宕機(jī)、GPU進(jìn)程被殺、容器重啟都會(huì)中斷AI服務(wù)。推薦在每臺(tái)邊緣節(jié)點(diǎn)部署一個(gè)健康檢查探針探針只負(fù)責(zé)心跳上報(bào)不參與業(yè)務(wù)邏輯避免誤判。檢查命令可以極簡單# 本地探活超時(shí)300ms即判定節(jié)點(diǎn)異常 curl --max-time 0.3 http://127.0.0.1:8080/healthz # 若失敗則執(zhí)行主備切換腳本把流量導(dǎo)向備用節(jié)點(diǎn)健康檢查周期建議設(shè)為1秒連續(xù)3次失敗才切換避免單次抖動(dòng)造成頻繁倒換。切換動(dòng)作要配合DNS或L4負(fù)載均衡的權(quán)重下調(diào)讓車輛側(cè)新發(fā)起的連接自動(dòng)走到備用節(jié)點(diǎn)已經(jīng)在途的推理要等返回后再切換否則任務(wù)會(huì)丟失。這里有個(gè)容易踩的坑健康檢查只查端口通不通不查模型是否真的可用。端口通但GPU顯存耗盡時(shí)探針仍然顯示正常因此生產(chǎn)環(huán)境的探針應(yīng)對/healthz返回推理延遲和顯存使用率兩個(gè)字段由調(diào)度端一并判斷。本文還有配套的精品資源點(diǎn)擊獲取