1. 為什么大模型后端比傳統(tǒng)后端更“怕黑”先聊一個(gè)我在多個(gè)項(xiàng)目里反復(fù)遇到的場景線上的大模型服務(wù)突然響應(yīng)變慢了從原來的1.2秒漲到4秒。傳統(tǒng)后端排查查接口日志、看數(shù)據(jù)庫慢查詢、盯CPU和內(nèi)存基本能定位。但到了大模型這條鏈路事情變得棘手——你打開日志看到的是一大段提示詞、一大段流式輸出token沒有SQL沒有Redis有的是一個(gè)HTTP調(diào)用外部推理服務(wù)的耗時(shí)記錄和一堆看似“正?！钡笜?biāo)異常的曲線。你不知道是模型服務(wù)端出了問題、prompt被業(yè)務(wù)側(cè)改壞了、還是并發(fā)把某個(gè)中間環(huán)節(jié)壓垮了。這時(shí)候靠傳統(tǒng)的那套“日志里撈關(guān)鍵字”的玩法基本是寸步難行。這也是我在做大模型后端工程化時(shí)最強(qiáng)烈的體會(huì)大模型后端不是“多了一個(gè)外部API調(diào)用”那么簡單它更像是把一個(gè)高度不確定、高成本、高延遲的第三方組件硬塞進(jìn)了你原本確定性的系統(tǒng)里。日志體系與可觀測性在這個(gè)背景下不再是一個(gè)運(yùn)維輔助工具而是整個(gè)系統(tǒng)能不能穩(wěn)定迭代的基礎(chǔ)設(shè)施。這篇文章我想完整復(fù)盤一下我在大模型后端工程中落地日志體系與可觀測性的全過程——從架構(gòu)設(shè)計(jì)、埋點(diǎn)規(guī)范、全鏈路Trace到成本監(jiān)控、質(zhì)量畫像、告警規(guī)則再到踩過的坑和排查實(shí)錄。內(nèi)容偏向工程落地適合正在做大模型應(yīng)用后端、或者想把現(xiàn)有服務(wù)可觀測性補(bǔ)齊的開發(fā)者參考。2. 可觀測性的整體設(shè)計(jì)與拆解思路2.1 大模型后端到底需要觀測什么傳統(tǒng)后端可觀測性講“三支柱”——日志、指標(biāo)、鏈路追蹤。大模型后端不是推翻這套體系而是在此之上增加了四個(gè)大模型特有的觀測維度。第一個(gè)是成本維度。大模型按Token計(jì)費(fèi)一次普通對(duì)話可能只有幾分錢但一個(gè)批量任務(wù)、一個(gè)Agent多輪調(diào)用鏈可能一次就消耗幾百萬Token。成本從“賬單上的一個(gè)數(shù)字”變成了“每一次請(qǐng)求都會(huì)產(chǎn)生的實(shí)時(shí)消耗”必須在單個(gè)請(qǐng)求粒度就能回答“這單花了多少錢”。第二個(gè)是質(zhì)量維度。傳統(tǒng)接口返回的是結(jié)構(gòu)化數(shù)據(jù)對(duì)錯(cuò)明確。大模型返回的是文本沒有絕對(duì)的“對(duì)錯(cuò)”。同一套prompt在不同模型版本、不同參數(shù)配置下輸出可能忽好忽壞。必須有一套針對(duì)生成內(nèi)容的觀測手段比如響應(yīng)長度分布、拒絕回答比例、關(guān)鍵詞命中率、語義相似度漂移等。第三個(gè)是行為漂移維度。大模型服務(wù)的“系統(tǒng)狀態(tài)”不只有CPU、內(nèi)存這類硬件指標(biāo)還包括“模型行為狀態(tài)”——同一段prompt這周和上周的輸出分布是否一致。模型版本升級(jí)、prompt模板調(diào)整、上下文策略改動(dòng)都可能導(dǎo)致線上行為悄悄變化。這類變化不靠日志是發(fā)現(xiàn)不了的。第四個(gè)是鏈路串聯(lián)維度。一個(gè)典型的大模型后端請(qǐng)求往往要經(jīng)過網(wǎng)關(guān)鑒權(quán)、檢索增強(qiáng)、上下文組裝、模型調(diào)用、結(jié)果后處理、流式回推等多個(gè)階段。任何一個(gè)環(huán)節(jié)出問題都會(huì)表現(xiàn)為“用戶覺得變慢了”但具體是哪個(gè)環(huán)節(jié)必須靠全鏈路Trace才能回答。這四個(gè)維度決定了我們需要的不僅是“日志收集系統(tǒng)”而是一套以請(qǐng)求為圓心、把成本、質(zhì)量、時(shí)延、鏈路全部串起來的觀測體系。2.2 日志、指標(biāo)、Trace在大模型場景的分工三支柱在大模型場景下各有側(cè)重我實(shí)際落地時(shí)是這樣劃分的日志負(fù)責(zé)“發(fā)生了什么”。每一筆請(qǐng)求的完整生命周期包括入?yún)⒄z索結(jié)果數(shù)量、組裝后的prompt長度、模型返回的token數(shù)、流式傳輸?shù)暮臅r(shí)、錯(cuò)誤碼、重試次數(shù)。日志是事后回溯的基礎(chǔ)要求全量記錄、結(jié)構(gòu)化輸出、可檢索。指標(biāo)負(fù)責(zé)“現(xiàn)在怎么樣”。以固定時(shí)間窗口聚合出來的數(shù)字包括QPS、平均首Token延遲、P95/P99整體延遲、Token吞吐量、成本消耗速率、緩存命中率、錯(cuò)誤率。指標(biāo)用于實(shí)時(shí)監(jiān)控和告警不需要全量但要實(shí)時(shí)、要穩(wěn)定。Trace負(fù)責(zé)“慢在哪里”。一次請(qǐng)求從進(jìn)入到返回經(jīng)過的每個(gè)子階段耗時(shí)拆解。傳統(tǒng)Trace可以精確到毫秒級(jí)大模型場景還需要額外記錄ttft首Token生成時(shí)間、推理耗時(shí)、傳輸耗時(shí)這幾個(gè)關(guān)鍵階段因?yàn)樗鼈儗?duì)用戶體驗(yàn)的影響完全不一樣。這里有一個(gè)容易犯的錯(cuò)誤很多人上來就想上一套全量日志全量Trace結(jié)果就是存儲(chǔ)成本爆炸、查詢變慢、鏈路采樣率過低導(dǎo)致失去參考價(jià)值。我的建議是分層處理——日志全量但精簡字段Trace按請(qǐng)求采樣比如默認(rèn)10%慢請(qǐng)求100%采樣指標(biāo)全量實(shí)時(shí)聚合。三者的數(shù)據(jù)量級(jí)差別很大不要用一套方案硬套。2.3 技術(shù)選型背后的考量大模型后端可觀測性在選型上我見過不少團(tuán)隊(duì)被“新概念”帶偏去自研一套大模型監(jiān)控平臺(tái)。其實(shí)大可不必。存量的開源生態(tài)完全夠用而且穩(wěn)定性有保障。日志存儲(chǔ)方面核心需求是全文檢索和快速過濾尤其是能對(duì)prompt內(nèi)容做關(guān)鍵詞查詢。我采用的是業(yè)界主流的“日志采集器分布式搜索引擎”組合業(yè)務(wù)側(cè)通過日志SDK異步上報(bào)結(jié)構(gòu)化JSON采集端做簡單的字段解析和清洗寫入分布式搜索引擎配合監(jiān)控可視化平臺(tái)做查詢分析。指標(biāo)鏈路用的是主流的時(shí)序數(shù)據(jù)庫采集器組合重點(diǎn)放在自定義業(yè)務(wù)指標(biāo)的埋點(diǎn)上也就是上一節(jié)說的成本、延遲、Token消耗這類指標(biāo)。鏈路追蹤選型上我建議直接采用開源的標(biāo)準(zhǔn)鏈路協(xié)議配合兼容該協(xié)議的采集端和存儲(chǔ)端這樣未來無論是切換模型供應(yīng)商、還是接入云廠商托管的可觀測服務(wù)遷移成本都可控。選型的一個(gè)核心原則是不要為了大模型單獨(dú)造輪子。大模型的可觀測性難點(diǎn)不在采集和存儲(chǔ)而在“埋什么點(diǎn)”和“怎么關(guān)聯(lián)”這些屬于業(yè)務(wù)層的設(shè)計(jì)工具解決不了。3. 核心細(xì)節(jié)解析與埋點(diǎn)規(guī)范3.1 統(tǒng)一TraceId與請(qǐng)求生命周期我踩過的第一個(gè)坑就是日志之間串不起來。大模型后端通常不是單服務(wù)而是API網(wǎng)關(guān)、業(yè)務(wù)服務(wù)、檢索服務(wù)、模型網(wǎng)關(guān)多層結(jié)構(gòu)甚至同一個(gè)請(qǐng)求會(huì)經(jīng)過多個(gè)微服務(wù)。如果沒有統(tǒng)一的請(qǐng)求ID排查問題基本靠猜。解決方案是在網(wǎng)關(guān)層生成統(tǒng)一TraceId通過HTTP頭向下游傳遞所有日志框架自動(dòng)攜帶這個(gè)ID。大模型相關(guān)的日志事件統(tǒng)一繼承同一個(gè)TraceId確保從用戶請(qǐng)求進(jìn)入到最終流式響應(yīng)結(jié)束所有日志都能按一個(gè)ID拉出來。流式響應(yīng)尤其需要注意——大模型是邊生成邊返回的一個(gè)請(qǐng)求會(huì)產(chǎn)生多次chunk寫操作每個(gè)chunk的日志都必須帶同一個(gè)TraceId否則排查“流到一半斷了”的問題時(shí)日志根本對(duì)不上。我的埋點(diǎn)規(guī)范里有幾條硬性要求所有外部調(diào)用必須記錄調(diào)用目標(biāo)、請(qǐng)求大小、響應(yīng)大小、耗時(shí)、重試次數(shù)、錯(cuò)誤信息。所有日志必須是結(jié)構(gòu)化JSON禁止在業(yè)務(wù)代碼里拼字符串日志。關(guān)鍵路徑上的日志必須帶BatchId、UserId、TraceId三個(gè)關(guān)聯(lián)字段缺一不可。日志級(jí)別按場景嚴(yán)格區(qū)分DEBUG用于聯(lián)調(diào)INFO記錄請(qǐng)求摘要WARN記錄可降級(jí)場景ERROR記錄真正的異常。3.2 提示詞結(jié)構(gòu)與響應(yīng)元數(shù)據(jù)的記錄規(guī)范大模型日志里最容易失控的就是內(nèi)容字段——如果你把完整prompt和完整響應(yīng)都塞進(jìn)日志存儲(chǔ)成本會(huì)迅速壓垮整個(gè)日志系統(tǒng)。但如果不記錄內(nèi)容出了問題又無從分析。這里需要有取舍地記錄。我的做法是把日志內(nèi)容拆成“元數(shù)據(jù)”和“內(nèi)容摘要”兩層。元數(shù)據(jù)全量記錄模型名稱、模型版本、temperature、max_tokens、top_p等參數(shù)以及Token輸入數(shù)、Token輸出數(shù)、耗時(shí)、緩存命中與否。內(nèi)容摘要層則分場景常規(guī)業(yè)務(wù)請(qǐng)求記錄prompt的模板ID、模板版本號(hào)以及渲染后的prompt截?cái)嗲?00個(gè)字符。響應(yīng)記錄截?cái)嗲?00個(gè)字符。異常與失敗請(qǐng)求完整記錄prompt和響應(yīng)。因?yàn)檫@是排查問題的核心證據(jù)不能省?；叶扰c實(shí)驗(yàn)請(qǐng)求按實(shí)驗(yàn)組ID全量記錄用于后續(xù)質(zhì)量分析。涉及隱私或敏感業(yè)務(wù)的請(qǐng)求內(nèi)容字段直接脫敏只記錄處理后的特征值。這套規(guī)范落地后日志量大約能壓掉70%同時(shí)保留了絕大多數(shù)排查場景需要的證據(jù)。另外要強(qiáng)推一個(gè)細(xì)節(jié)記錄prompt模板ID和版本號(hào)。大模型應(yīng)用里prompt是會(huì)頻繁迭代的同一份prompt今天改了個(gè)詞明天可能就多了一批重新生成的需求。如果日志里只有prompt內(nèi)容沒有版本號(hào)線上出問題想回滾對(duì)比會(huì)非常痛苦。我們后來把prompt管理做成了獨(dú)立的配置中心每次變更自動(dòng)生成版本號(hào)日志埋點(diǎn)里帶上這個(gè)版本號(hào)這波操作在后面排查質(zhì)量問題時(shí)幫了大忙。3.3 Token計(jì)算的三種口徑Token是成本和質(zhì)量觀測的核心單位但它的統(tǒng)計(jì)口徑很容易出問題。我遇到過不止一次日志里記錄的Token消耗總和和模型服務(wù)商賬單上的數(shù)字對(duì)不上差了20%以上。這不是模型服務(wù)商亂扣費(fèi)而是我們統(tǒng)計(jì)口徑有問題。實(shí)際落地中Token統(tǒng)計(jì)至少有三種口徑第一種是計(jì)費(fèi)口徑。模型服務(wù)商賬單上的Token數(shù)包含輸入Token、輸出Token、緩存Token、特殊字符拆分規(guī)則等這是你實(shí)際要付的錢。這個(gè)口徑必須從模型服務(wù)商的響應(yīng)報(bào)文里拿不能自己數(shù)。第二種是應(yīng)用口徑。業(yè)務(wù)代碼里通過官方SDK拿到的usage信息用于實(shí)時(shí)成本展示和配額控制。這個(gè)口徑同樣來自模型響應(yīng)但要注意不同SDK對(duì)usage的解析方式不同有些SDK默認(rèn)不返回usage需要顯式開啟參數(shù)。第三種是自算口徑。本地用分詞器對(duì)輸入的prompt和輸出的文本重新計(jì)算Token數(shù)。用于在沒有模型服務(wù)商響應(yīng)的情況下做估算比如日志采樣數(shù)據(jù)的成本推算、prompt超長預(yù)判。三種口徑的使用場景一定要分清楚。我在日志埋點(diǎn)里分別用三個(gè)字段記錄并在面板上明確標(biāo)注口徑來源。如果混用輕則成本預(yù)估失真重則觸發(fā)錯(cuò)誤的告警規(guī)則——比如我們?cè)?jīng)因?yàn)橛米运憧趶饺ズ藢?duì)模型賬單導(dǎo)致誤以為模型服務(wù)商扣費(fèi)異常白白折騰了一個(gè)星期。3.4 上下文與檢索環(huán)節(jié)的觀測細(xì)節(jié)大模型后端很少是“裸模型”直接對(duì)外基本都會(huì)接知識(shí)庫檢索、歷史會(huì)話摘要、上下文管理等模塊。這些模塊看似是傳統(tǒng)后端組件但它們直接影響大模型的效果和成本必須納入觀測范圍。檢索環(huán)節(jié)的觀測重點(diǎn)是召回文檔數(shù)、每篇文檔的相關(guān)性得分、最終拼接進(jìn)上下文的文檔數(shù)與Token數(shù)。一個(gè)非常典型的線上問題是“prompt被上下文撐爆”——知識(shí)庫召回20篇文檔每篇幾千字加上歷史記錄prompt總長超過模型上下文窗口請(qǐng)求直接報(bào)錯(cuò)。如果檢索日志里記錄了拼接后的總Token數(shù)、各部分Token占比這類問題一眼就能看穿。上下文管理模塊的觀測重點(diǎn)是會(huì)話歷史的截?cái)嗖呗詫?shí)際觸發(fā)了多少次、每次截?cái)嗔硕嗌贄l、截?cái)嗪髞G失了哪部分信息。大模型應(yīng)用最隱蔽的質(zhì)量殺手之一就是“歷史太長被悄悄截?cái)嗲懊娴男畔G了用戶還在繼續(xù)追問”。這類問題不會(huì)報(bào)錯(cuò)只會(huì)表現(xiàn)為回答越來越偏沒有日志記錄截?cái)嘈袨榈脑捇緹o解。4. 實(shí)操工程化從埋點(diǎn)到告警的完整鏈路4.1 業(yè)務(wù)側(cè)埋點(diǎn)的具體實(shí)現(xiàn)埋點(diǎn)這塊我推薦“SDK封裝注解/中間件自動(dòng)化”的方式盡量避免在每個(gè)業(yè)務(wù)方法里手寫日志代碼。手寫的壞處不是“累”而是容易漏——大模型后端的日志字段非常多手寫很容易在不同方法里字段命名不一致后面做聚合查詢會(huì)非常痛苦。我們最終沉淀的埋點(diǎn)封裝包含這幾個(gè)核心組件請(qǐng)求上下文組件負(fù)責(zé)從HTTP頭或消息隊(duì)列消息體里提取TraceId、UserId、業(yè)務(wù)場景名并寫入線程上下文。異步線程池場景下必須做上下文透傳否則日志會(huì)失去關(guān)聯(lián)。模型調(diào)用攔截器統(tǒng)一攔截所有進(jìn)出模型網(wǎng)關(guān)的調(diào)用自動(dòng)記錄模型名、參數(shù)、輸入Token、輸出Token、耗時(shí)、錯(cuò)誤信息。業(yè)務(wù)代碼里只需要寫一次調(diào)用日志自動(dòng)補(bǔ)齊。流式響應(yīng)增強(qiáng)組件大模型流式返回比較特殊傳統(tǒng)的“method入口出口記錄耗時(shí)”方式統(tǒng)計(jì)不準(zhǔn)因?yàn)槭譚oken可能很快但整體流完可能很久。增強(qiáng)組件會(huì)分別記錄連接建立時(shí)間、首Token到達(dá)時(shí)間、流結(jié)束時(shí)間三段分別埋點(diǎn)。業(yè)務(wù)事件日志API給業(yè)務(wù)代碼輸出自定義事件用比如“檢索完成”“上下文截?cái)唷薄皟?nèi)容安全判定命中”統(tǒng)一JSON格式自動(dòng)附帶TraceId。這套封裝落地后業(yè)務(wù)開發(fā)新增一個(gè)模型調(diào)用場景基本不需要額外關(guān)注日志代碼觀測能力自動(dòng)補(bǔ)齊。還有一個(gè)細(xì)節(jié)日志輸出必須走異步通道。大模型響應(yīng)動(dòng)輒幾千Token日志內(nèi)容本來就大如果再同步寫磁盤會(huì)對(duì)接口時(shí)延產(chǎn)生影響。我們統(tǒng)一采用高性能異步日志框架并且配置了獨(dú)立的日志隊(duì)列和刷盤策略確保日志寫入在高并發(fā)下不會(huì)阻塞業(yè)務(wù)線程。4.2 全鏈路Trace的采樣與串聯(lián)策略鏈路追蹤的采樣策略我強(qiáng)烈建議針對(duì)大模型場景做專門設(shè)計(jì)不要直接用默認(rèn)的全量或固定比例采樣。原因是大模型的調(diào)用鏈路有幾個(gè)特點(diǎn)一是單次調(diào)用體量大二是外部推理耗時(shí)占比高三是并發(fā)模型調(diào)用比如并行跑多個(gè)子任務(wù)會(huì)產(chǎn)生大量同層級(jí)Span。如果按默認(rèn)的“全鏈路10%采樣”等于是隨機(jī)丟棄請(qǐng)求——可能剛好把最貴的、最慢的那筆請(qǐng)求丟掉了。我的采樣策略是三層組合默認(rèn)按請(qǐng)求路徑采樣10%保證常規(guī)流量有數(shù)據(jù)參考。所有慢請(qǐng)求總耗時(shí)超過P90閾值的強(qiáng)制100%采樣通過攔截器判斷耗時(shí)后主動(dòng)標(biāo)記。所有錯(cuò)誤請(qǐng)求、重試請(qǐng)求、降級(jí)請(qǐng)求100%采樣。所有成本超過設(shè)定閾值的“大單請(qǐng)求”比如單次消耗超過設(shè)定金額100%采樣。這套策略的實(shí)質(zhì)是“把采樣資源留給異常和關(guān)鍵請(qǐng)求”。效果也是立竿見影——之前排查慢請(qǐng)求經(jīng)常找不到Trace改完之后只要告警通知你“有慢請(qǐng)求”點(diǎn)進(jìn)去必定有完整鏈路。4.3 指標(biāo)設(shè)計(jì)從業(yè)務(wù)視角定義監(jiān)控項(xiàng)大模型監(jiān)控面板不能只堆QPS和CPU必須圍繞“業(yè)務(wù)可用性”來設(shè)計(jì)。我實(shí)際使用的核心指標(biāo)分為五組第一組時(shí)延指標(biāo)整體響應(yīng)時(shí)延、首Token時(shí)延、推理完成時(shí)延、流式傳輸時(shí)延。這四者必須分開看。用戶體感主要受首Token時(shí)延影響而后端資源消耗主要受推理完成時(shí)延影響。我們有一次線上排查發(fā)現(xiàn)整體響應(yīng)時(shí)延P95漲了50%但首Token時(shí)延平穩(wěn)最終定位出來是流式傳輸環(huán)節(jié)的網(wǎng)絡(luò)問題如果只盯著總時(shí)延方向就偏了。第二組成本指標(biāo)每小時(shí)Token消耗總量、輸入/輸出Token比例、單請(qǐng)求平均成本、按業(yè)務(wù)場景聚合的成本分布。成本指標(biāo)的意義不只是算錢更是發(fā)現(xiàn)異常行為——如果某個(gè)場景的輸入Token突然暴漲大概率是上下文管理邏輯出了bug比如歷史消息重復(fù)拼接。第三組錯(cuò)誤指標(biāo)模型調(diào)用錯(cuò)誤率、超時(shí)率、重試率、內(nèi)容安全攔截率。這里要特別注意大模型請(qǐng)求的超時(shí)重試和普通接口不一樣重試可能帶來重復(fù)扣費(fèi)所以重試率必須單獨(dú)監(jiān)控。第四組緩存指標(biāo)緩存命中率、緩存節(jié)省成本、緩存回源率。大模型的語義緩存和結(jié)果緩存能大幅降本但這個(gè)收益是動(dòng)態(tài)的需要持續(xù)監(jiān)控命中率來判斷緩存策略是否仍然有效。第五組上下文指標(biāo)請(qǐng)求平均上下文Token數(shù)、最大上下文Token數(shù)、上下文截?cái)嘤|發(fā)率。這組指標(biāo)直接反映prompt工程側(cè)的穩(wěn)定性上下文Token暴漲通常意味著檢索或歷史管理出了問題。4.4 告警規(guī)則的幾個(gè)實(shí)戰(zhàn)設(shè)計(jì)告警規(guī)則是“寧可少而準(zhǔn)不可多而廢”。我見過太多團(tuán)隊(duì)第一天上線就配了二十條告警結(jié)果全是噪音最后告警被靜默等于沒配。大模型后端的告警我沉淀了幾個(gè)實(shí)戰(zhàn)經(jīng)驗(yàn)。首Token時(shí)延必須單獨(dú)設(shè)置告警閾值?？倳r(shí)延波動(dòng)很常見但首Token時(shí)延如果連續(xù)多個(gè)周期超過模型供應(yīng)商的SLO說明模型服務(wù)端可能出問題這類告警要直接拉高優(yōu)先級(jí)。我們的經(jīng)驗(yàn)閾值是P95首Token時(shí)延超過模型供應(yīng)商公布值的1.5倍并持續(xù)5分鐘觸發(fā)告警。成本異常要配環(huán)比告警。絕對(duì)值告警沒意義不同業(yè)務(wù)規(guī)模成本差異太大。我們做的是“每小時(shí)成本同比上一小時(shí)同場景成本增長超過50%且絕對(duì)增量超過設(shè)定金額”觸發(fā)告警。這個(gè)規(guī)則成功抓到過一次線上事故某個(gè)定時(shí)任務(wù)的循環(huán)條件寫錯(cuò)模型調(diào)用變成死循環(huán)成本在一個(gè)小時(shí)內(nèi)翻了四倍。模型錯(cuò)誤率告警必須分級(jí)。5xx類錯(cuò)誤率超過1%觸發(fā)警告超過5%觸發(fā)緊急但4xx類錯(cuò)誤要單獨(dú)看錯(cuò)誤碼——上下文超限、內(nèi)容安全攔截這類“業(yè)務(wù)錯(cuò)誤”不是故障卻往往比故障更值得關(guān)注。上下文截?cái)嗦矢婢芏嗳撕雎?。我建議把它當(dāng)成一等告警來配。上下文截?cái)嗦释蝗簧仙馕吨R(shí)庫召回策略出問題或者用戶行為發(fā)生變化這種問題不告警的話表面看起來一切正常實(shí)際用戶體驗(yàn)已經(jīng)在悄悄下滑了。5. 常見問題與排查思路實(shí)錄5.1 一次典型的“響應(yīng)變慢”排查過程拿一個(gè)真實(shí)案例來串一下排查思路。某天線上反饋對(duì)話響應(yīng)變慢用戶體感明顯但錯(cuò)誤率沒有變化。我按這個(gè)順序排查第一步看指標(biāo)面板?？倳r(shí)延P95從2秒漲到3.5秒首Token時(shí)延P95也從800毫秒漲到2秒說明問題出在“模型首Token返回前”的階段而不是流式傳輸階段。第二步拉全鏈路Trace。篩選慢請(qǐng)求的Trace發(fā)現(xiàn)耗時(shí)主要集中在“檢索增強(qiáng)”環(huán)節(jié)該環(huán)節(jié)的Span耗時(shí)從平均300毫秒漲到1.5秒。第三步看檢索環(huán)節(jié)日志。發(fā)現(xiàn)召回文檔數(shù)沒有變化但“向量檢索”的耗時(shí)異常高。繼續(xù)下鉆看到向量索引服務(wù)的CPU已經(jīng)打滿慢查詢語句集中在某個(gè)特定知識(shí)庫集合上。第四步看該知識(shí)庫集合的日志發(fā)現(xiàn)當(dāng)天有人批量導(dǎo)入了大量新文檔觸發(fā)了向量索引的增量重建任務(wù)這個(gè)任務(wù)和線上檢索搶資源。整個(gè)排查過程耗時(shí)約40分鐘比傳統(tǒng)后端排障要快得多。關(guān)鍵在于指標(biāo)快速收斂范圍、Trace精確定位環(huán)節(jié)、日志給出根因證據(jù)。三者缺一都得靠猜。5.2 Token統(tǒng)計(jì)口徑不一致的排查記錄另一個(gè)高頻坑是統(tǒng)計(jì)口徑。我們?cè)龅侥硺I(yè)務(wù)場景報(bào)告“今日成本比模型服務(wù)商賬單多了30%”差點(diǎn)就要找服務(wù)商理論。排查后發(fā)現(xiàn)業(yè)務(wù)側(cè)日志統(tǒng)計(jì)用的是SDK返回的usage字段但該SDK版本默認(rèn)不統(tǒng)計(jì)緩存命中的Token消耗而模型服務(wù)商賬單里緩存命中的Token也是按折扣價(jià)計(jì)費(fèi)的兩邊基礎(chǔ)數(shù)據(jù)就差了。加上我們?nèi)罩纠镉袀€(gè)字段把“預(yù)估Token”和“計(jì)費(fèi)Token”混在一起算乘上單價(jià)后誤差被放大。最后統(tǒng)一了統(tǒng)計(jì)鏈路所有成本計(jì)算必須從模型服務(wù)商官方賬單接口拉每日明細(xì)日志側(cè)只做實(shí)時(shí)展示不用于對(duì)賬。同時(shí)把SDK升級(jí)到支持完整usage返回的版本在埋點(diǎn)里區(qū)分prompt_tokens、completion_tokens、cached_tokens三個(gè)字段。現(xiàn)在兩邊誤差控制在1%以內(nèi)對(duì)賬基本無感。5.3 日志體量失控與采樣策略調(diào)整全量日志上線不到兩周搜索引擎存儲(chǔ)集群的磁盤消耗就比預(yù)估快了一倍。定位后發(fā)現(xiàn)大模型流式輸出的每個(gè)chunk都被打了一條日志一個(gè)千Token響應(yīng)產(chǎn)生了上百條日志記錄單請(qǐng)求日志量膨脹到幾十KB。這是大模型日志最常見的失控場景。后來的整改方案是流式傳輸過程只記錄聚合摘要不再逐chunk輸出日志。具體做法是在流結(jié)束或異常中斷時(shí)一次性輸出該請(qǐng)求的總傳輸Token數(shù)、傳輸耗時(shí)、中斷位置。如果確實(shí)需要逐chunk調(diào)試單獨(dú)開DEBUG級(jí)別按TraceId過濾生產(chǎn)環(huán)境默認(rèn)關(guān)閉。另外做了分級(jí)存儲(chǔ)策略最近7天的全量日志保留在熱存儲(chǔ)支持秒級(jí)查詢7天到30天的轉(zhuǎn)冷存儲(chǔ)30天以上的自動(dòng)清理只保留聚合指標(biāo)。成本直接降了一個(gè)量級(jí)查詢速度反而更快了。5.4 超時(shí)重試導(dǎo)致重復(fù)扣費(fèi)的隱藏事故還有一次事故讓我印象深刻。業(yè)務(wù)方反饋某個(gè)批處理任務(wù)成本異常高查日志發(fā)現(xiàn)大量請(qǐng)求都走了“超時(shí)-重試”路徑。進(jìn)一步分析模型網(wǎng)關(guān)配置的超時(shí)時(shí)間是30秒但那個(gè)批處理任務(wù)使用的模型推理本身就比較慢P95耗時(shí)已經(jīng)達(dá)到35秒。結(jié)果就是大量請(qǐng)求第一次調(diào)用30秒超時(shí)重試又花了35秒成功單次邏輯操作產(chǎn)生了兩次模型調(diào)用、雙倍成本。這個(gè)問題的根本原因是超時(shí)配置和模型能力不匹配但可觀測性在這里的價(jià)值是它讓“重試率”這個(gè)指標(biāo)浮出水面。如果沒有重試率監(jiān)控這筆成本會(huì)成為一筆糊涂賬。我們隨后為不同模型型號(hào)配置了差異化的超時(shí)時(shí)間并給重試行為增加了告警——單場景重試率超過5%直接通知。6. 在日志體系落地過程中的幾點(diǎn)經(jīng)驗(yàn)心得做完整套體系后我最大的體會(huì)是大模型后端可觀測性70%是設(shè)計(jì)問題20%是埋點(diǎn)問題只有10%是工具問題。很多團(tuán)隊(duì)一上來就搭監(jiān)控平臺(tái)、接告警通道結(jié)果因?yàn)槁顸c(diǎn)字段不規(guī)范、Trace鏈路不完整、指標(biāo)口徑不統(tǒng)一平臺(tái)搭得再漂亮也是花架子。幾個(gè)值得反復(fù)強(qiáng)調(diào)的經(jīng)驗(yàn)第一指標(biāo)和日志必須建立“可下鉆”關(guān)系。面板上看到一個(gè)異常指標(biāo)能一鍵跳到對(duì)應(yīng)的Trace列表再從Trace跳到完整日志。如果三級(jí)跳轉(zhuǎn)做不到可觀測性就是半成品。我們?yōu)榇藢ｉT做了一次數(shù)據(jù)模型對(duì)齊確保三套系統(tǒng)里請(qǐng)求ID的格式、字段名完全一致。第二可觀測性要覆蓋模型的“非功能屬性”。Token成本、上下文截?cái)?、提示詞版本、重試率、緩存命中率這些在大模型場景比CPU和內(nèi)存更關(guān)鍵。傳統(tǒng)運(yùn)維指標(biāo)只是底線大模型特有的業(yè)務(wù)指標(biāo)才是核心競爭力。第三從第一天就把內(nèi)容脫敏規(guī)則設(shè)計(jì)好。大模型應(yīng)用會(huì)記錄大量用戶輸入而這些輸入可能包含敏感信息。我們很早就定了規(guī)則日志中默認(rèn)不記錄原始對(duì)話內(nèi)容只記錄長度、關(guān)鍵詞、分類標(biāo)簽只有顯式標(biāo)記為“可審計(jì)”的請(qǐng)求才保留全文。這個(gè)決策幫我們避免了很多后續(xù)的合規(guī)麻煩。第四定期做日志數(shù)據(jù)的“減脂”。大模型日志天然膨脹每個(gè)月我都會(huì)檢查一次哪些字段實(shí)際查詢率不到5%哪些日志事件重復(fù)度最高有沒有新的截?cái)嘁?guī)則可以加這是一種持續(xù)治理不是一次性工程。做可觀測性這件事短期看是增加了一堆埋點(diǎn)代碼和配置文件好像拖慢了業(yè)務(wù)節(jié)奏。但等到模型上線、流量起來、用戶開始反饋“有時(shí)候回答很慢”“有些回答明顯變差了”的時(shí)候你就知道這套看不見的體系才是讓你能睡個(gè)安穩(wěn)覺的東西。大模型后端還在快速演進(jìn)今天記錄的每一個(gè)Token、每一條Trace都是未來優(yōu)化模型、迭代prompt、控制成本最重要的原始依據(jù)。