——不是死在進(jìn)程里就叫活著凌晨?jī)牲c(diǎn)業(yè)務(wù)方的電話(huà)把你從床上拽起來(lái)你們的AI客服瘋了用戶(hù)問(wèn)天氣它回了一段菜譜。你揉著眼睛登上服務(wù)器看了眼儀表盤(pán)——綠的一片CPU 12%內(nèi)存 40%GPU利用率 8%。服務(wù)在跑進(jìn)程沒(méi)崩端口也通。模型死了三個(gè)小時(shí)你的告警一條沒(méi)響。這不是故事這是我們組去年Q3復(fù)盤(pán)報(bào)告里白紙黑字寫(xiě)著的真實(shí)故障。模型服務(wù)到底難在哪你管過(guò)MySQL、Redis、Kafka那套監(jiān)控思路印在腦子里服務(wù)不響應(yīng)看進(jìn)程進(jìn)程在但慢看CPU和IOCPU不高看連接數(shù)和鎖。但模型服務(wù)把這些經(jīng)驗(yàn)全砸碎了——服務(wù)活著不等于模型在工作。vLLM、TGI、Ollama這些推理框架只要你啟動(dòng)了HTTP接口就會(huì)返回200哪怕模型推理已經(jīng)徹底卡死或者輸出全是亂碼。你盯著服務(wù)可用率99.9%的曲線(xiàn)覺(jué)得一切正常但用戶(hù)看到的是一個(gè)接一句的廢話(huà)?；卮鹳|(zhì)量變差不等于有錯(cuò)誤。模型不會(huì)拋異常它只是在努力給出一個(gè)答案——這個(gè)答案可能離題萬(wàn)里可能邏輯混亂但HTTP狀態(tài)碼是200進(jìn)程也沒(méi)報(bào)錯(cuò)。傳統(tǒng)監(jiān)控基于狀態(tài)碼和異常日志的方式在這里完全失效。慢得像沒(méi)事。有些模型退化是漸進(jìn)式的P99延遲從800毫秒爬到15秒每秒吞吐量從200 token掉到30用戶(hù)以為在加載你以為是網(wǎng)絡(luò)抖動(dòng)。三個(gè)真實(shí)踩過(guò)的坑第一個(gè)坑只看服務(wù)活著不看回答質(zhì)量。我們上線(xiàn)第一版監(jiān)控時(shí)用最樸素的方式探測(cè)HTTP端口響應(yīng)200就標(biāo)記正常。三個(gè)月后才發(fā)現(xiàn)模型在某些異常輸入下會(huì)進(jìn)入復(fù)讀模式——對(duì)任何問(wèn)題都循環(huán)輸出同一句話(huà)HTTP狀態(tài)碼還是200。業(yè)務(wù)方反映AI客服瘋了我們這邊儀表盤(pán)一片綠整整兩小時(shí)后才被二次投訴暴露。第二個(gè)坑沒(méi)盯延遲分位數(shù)只看平均值。平均響應(yīng)時(shí)間300毫秒看起來(lái)很健康。但P99是8秒P999是47秒——真實(shí)用戶(hù)感受到的不是平均值是那個(gè)最慢的請(qǐng)求。某次流量突增導(dǎo)致排隊(duì)積壓平均延遲幾乎沒(méi)變化但P999從20秒跳到了90秒大量用戶(hù)以為服務(wù)掛了。我們事后加了延遲分位數(shù)告警才看見(jiàn)這個(gè)坑。第三個(gè)坑告警淹沒(méi)在噪音里。這個(gè)最要命。上線(xiàn)初期我們?cè)O(shè)了CPU80%告警、GPU90%告警、顯存85%告警聽(tīng)起來(lái)很全。結(jié)果是白天開(kāi)發(fā)測(cè)試流量一沖CPU瞬間破80一晚上告警幾百條值班人員兩小時(shí)后直接設(shè)置了消息免打擾——然后真正的故障告警也進(jìn)免打擾了直到業(yè)務(wù)方打電話(huà)才知道。閾值太松漏報(bào)閾值太緊噪音兩者之間沒(méi)有標(biāo)準(zhǔn)答案只有反復(fù)調(diào)參。務(wù)實(shí)要盯的四個(gè)指標(biāo)結(jié)合業(yè)界實(shí)踐和我們的生產(chǎn)經(jīng)驗(yàn)以下四個(gè)指標(biāo)是模型服務(wù)監(jiān)控的最小集合值得每個(gè)運(yùn)維認(rèn)真盯第一可用性不是端口可用是請(qǐng)求成功且回答有效。建議在探測(cè)接口里放一個(gè)標(biāo)準(zhǔn)Prompt預(yù)期答案包含特定關(guān)鍵詞或滿(mǎn)足格式校驗(yàn)連續(xù)3次失敗才觸發(fā)告警。這比HTTP探測(cè)貴一點(diǎn)但能抓住服務(wù)活著但腦子壞了的情況。第二P99延遲不是平均值。你需要分別盯住P50、P99、P999三個(gè)分位點(diǎn)建議告警閾值按分位點(diǎn)梯度設(shè)置P505秒預(yù)警P9915秒正式告警P99960秒升級(jí)。為什么要梯度因?yàn)镻999觸及的用戶(hù)少但痛感強(qiáng)不能和普通慢請(qǐng)求混為一談。第三異?；卮鹇?。定義你自己的異常連續(xù)重復(fù)超過(guò)N個(gè)字符、回答長(zhǎng)度低于某個(gè)閾值、包含特定亂碼pattern、格式校驗(yàn)失敗。這個(gè)指標(biāo)沒(méi)有通用標(biāo)準(zhǔn)你得自己定義模型正常工作時(shí)應(yīng)該長(zhǎng)什么樣。我們目前用的是有效回答率抽檢5%的請(qǐng)求LLM判斷回答是否相關(guān)低于85%觸發(fā)告警。第四顯存占用和碎片率。顯存泄漏在模型服務(wù)里是慢性殺手進(jìn)程不崩潰但每次請(qǐng)求分配一點(diǎn)顯存不釋放直到OOM被容器kill掉。建議監(jiān)控顯存使用趨勢(shì)而非單點(diǎn)值如果連續(xù)兩小時(shí)顯存只漲不跌哪怕還沒(méi)OOM也要預(yù)警。另外注意顯存的顯存碎片率vLLM里碎片率超過(guò)30%會(huì)導(dǎo)致有效顯存利用率大幅下降。給運(yùn)維的真心話(huà)模型服務(wù)的監(jiān)控沒(méi)有銀彈沒(méi)有一套模板拿來(lái)就用。你們的模型不同、框架不同、業(yè)務(wù)對(duì)正常的定義也不同。這篇文章里的指標(biāo)和建議是踩坑踩出來(lái)的參考不是標(biāo)準(zhǔn)答案。真正有用的是兩件事一是盡快建立你們自己的正?；€(xiàn)這需要在上線(xiàn)后持續(xù)觀察數(shù)據(jù)而不是第一天就定好閾值二是讓業(yè)務(wù)方參與告警策略的制定——他們對(duì)回答質(zhì)量的感知往往比你儀表盤(pán)上的數(shù)字更靈敏。最后一句話(huà)別相信服務(wù)在跑就等于服務(wù)正常。這個(gè)行業(yè)里沉默的故障比崩潰的故障更常見(jiàn)也更危險(xiǎn)。本文基于公開(kāi)技術(shù)資料與行業(yè)實(shí)踐整理不構(gòu)成具體產(chǎn)品選型或部署方案建議。