詳解大模型應用可觀測全鏈路

阿里妹導讀

阿里雲可觀測解決方案從幾個方面來嘗試幫助使用 QwQ、Deepseek 的 LLM 應用開發者來滿足領域化的可觀測述求。

一、背景

近日，隨著阿里通義千問推出的 QwQ 系列深度思考模型爆火全球，以其令人讚歎的推理能力強、價效比突出等特點，一經發布就引發廣泛關注，從資本市場與工業界走進大眾視野中。

越來越多普羅大眾開始瞭解與嘗試 LLM 應用。但伴隨著使用者需求的激增，無論是基於官方模型服務還是自建部署大模型，在應用層呼叫大語言模型服務時，都可能面臨響應超時或者不穩定等問題，從而影響使用者的實際使用體驗。相較於過往的雲原生應用，LLM 應用可觀測發生了翻天覆地的變化，不僅僅是資源型別、核心指標、資料特徵的變化，故障模型、除錯方式也發生了巨大改變。面對這一系列的穩定性挑戰，本文給出了更符合業務特徵的可觀測解決方案。

二、大模型可觀測的挑戰

隨著模型規模的擴大和推理請求量激增，推理服務會逐漸暴露出一系列效能瓶頸問題；基於大語言模型構建的 LLM 應用，從研發到生產落地，也面臨若干環節的挑戰，例如模型選擇，提示詞調優，流程編排、開發除錯以及部署上線等；

我們總結從模型層到應用層的挑戰包含如下：

效能與成本：許多企業在部署大模型時發現，GPU 利用率往往難以達到理想水平，導致資源浪費和成本上升；
使用與開發體驗：引入推理架構雖然提升了擴充套件性，但也增加了系統的複雜性，使得故障排查和效能調優變得更加困難。複雜的 LLM 應用往往鏈路較長，流程編排複雜、依賴元件多且雜，往往端側出現問題時定位鏈路問題根因效率低；
效果評估：大模型輸出不可預測以及幻覺，可能會導致效果不符合預期；
安全合規：內容輸入輸出可能會涉及內容安全合規等風險。

我們熟悉的分散式、微服務應用可觀測解決方案經過多年發展，已相對成熟。透過對效能、資源等核心指標的監控，及時發現系統性能瓶頸及容量問題，而 LLM 應用則是從效能、成本、效果三大方面來對可觀測性提出了差異化的觀測需求；AI 推理服務的監控需求則不僅涉及硬體資源和效能指標，還包括模型行為和分散式架構的複雜性；為了解決這些問題，我們需要一套統一可觀測方案，能夠覆蓋從硬體到軟體、從單機到叢集，從模型到應用的全鏈路能力。

三、典型 LLM 應用元件與可觀測資料型別

一個基於 LLM 的 ChatBot 應用架構參考如下：包含若干元件，包含前端 UI 元件、認證模組、會話管理、對話服務以及後臺管理等一系列微服務，透過靜態或者動態的流程編排來滿足業務靈活性。在整體架構中涉及大語言模型相關的技術以及元件還包括：

AI 閘道器：基於 AI 閘道器對接不同 LLM 服務來應對不同場景的請求，滿足大小模型混合使用的情況，另外在出現故障時能夠自動切換模型服務來保障服務的連續性；
內容安全：客戶的輸入存在不確定性，往往需要引入 Moderation 和 Guardrails 技術來進行內容審查以及提示詞防禦，避免合規問題；
工具呼叫：面對複雜的業務場景，呼叫外部工具或者服務來完成具體操作，如藉助呼叫網際網路搜尋來“準即時”獲取最新資訊，利用客戶授權的工具來幫助客戶完成實際行為動作；
RAG 技術：基於向量資料庫來最佳化對話上下文或者長期記憶，來解決模型應答的幻覺問題，提升回答的即時性以及準確性；
快取技術：透過對接快取服務能夠直接命中快取，一方面可以直接命中快取可以提升回答效率，另一方面可以降低對 LLM 的重複呼叫進而降低成本。

和典型應用一樣，我們能夠透過 Trace、Metric、Log 建立一套立體的可觀的體系，在下文中，我們依次會透過 Trace、Metric、Log 演示效能分析、內容評估、安全合規與敏感資訊保護等場景的解決方案。

四、LLM 應用必備的可觀測能力：採集治理、領域檢視、根因定位

登入 Y Combinator 公司網站查詢 LLM Observability 關鍵詞發現，存在 10 家以上的產品解決方案來滿足 LLM 可觀測需求場景，例如 Langfuse、TraceLoop、Arize AI、Datadog 以及 Helicone 等，分別從 LLMOps、Debug、Evaluation 等角度來構建產品形態滿足不同的角色需求，產品能力各有側重。Arize 公司提出 LLM 可觀測五大支柱(Evaluation、Trace&Spans、Prompt Engineering、Search&Retrieval、Fine-tuning)，從這五大支柱出發，一方面需要覆蓋模型層基礎設施的模型訓練以及推理等水位指標，另外一方面需要滿足 LLM 應用層的若干可觀測述求，基於豐富的指標、呼叫鏈、日誌、事件等資料集合可觀測大盤以及告警能力，提供強大的可觀測分析解決能力。

整體思路上，成熟的可觀測性平臺需要支援從端側不同接入形態的資料採集上報，構建領域化分析檢視以及場景化分析能力，覆蓋端到端全鏈路分析，及時發現線上問題，輔助 LLMOps 進行根因定位。阿里雲可觀測解決方案從以下幾個方面來嘗試幫助使用 DeepSeek 或QWQ 的 LLM 應用開發者來滿足領域化的可觀測述求。

面向 LLM 應用領域化指標洞察

透過分析 LLM 應用的互動特點以及處理鏈路，分析應用正規化以及工作流程，往往一個使用者會發起多輪對話。一次會話過程涉及到多次 Query，一次 Query 請求會涉及到若干操作，梳理並定義出關鍵的操作型別(LLM Span Kind)，用以標識 LLM 應用鏈路的核心操作語義，參考最新的OTel GenAI語義規範[1]，實現自動化的埋點採集上述核心行為，藉助呼叫鏈分析可以更加聚焦 LLM 領域關鍵執行動作，分析內部執行細節，包括輸入輸出以及 Token 消耗明細等內容。

LLM 應用除了微服務已有的核心指標外，需要額外關注模型層的推理效能、Token 消耗、效果評估指標等特殊指標，能夠從 LLM 領域視角去更好的洞察應用的業務表現。在業務表現下降或者出現內容風險時，能夠及時感知第一時間進行人工介入。

模型推理過程中會關注推理速率以及效能體驗，可能會關注如下指標：

Time to First Token (TTFT): 生成第一個令牌所需的時間，用於評估系統響應速度；
Time Between Tokens (TBT) ：生成相鄰令牌之間的時間間隔，評估生成流暢度；
Time Per Output Token (TPOT): 生成每個輸出令牌的平均時間，用於評估生成效率，計算公式為：

;

評估場景，往往需要藉助自動化或者人工評估手段從準確性、有毒性，幻覺等角度來評估整體效能、安全性以及可靠性等。

高質量的可觀測資料採集能力

要實現上述面向 LLM 領域的呼叫鏈和指標的採集和上報，需要具備端側埋點自動採集以及對接服務端上報資料的能力。由於 LLM 應用的主流開發語言為 Python，阿里雲提供基於 OpenTelemetry Python Agent 底座的自研 Python Agent。除了覆蓋常見的 Web 框架、資料庫以及訊息佇列等埋點外，針對LLM應用進行量身打造，支援 LLamaIndex/LangChain/通義千問/OpenAI/Dify/PromptFlow 等國內外框架和模型。在原理上利用框架的 Callback 機制以及 wrapper 原理，能夠實現無侵入埋點，極大地簡化了整合接入流程。

我們看到 DeepSeek 官網提供的請求示例如下：

# Please install OpenAI SDK first: `pip3 install openai`from openai import OpenAIclient = OpenAI(api_key="<DeepSeek API Key>", base_url="https://api.deepseek.com")response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "You are a helpful assistant"}, {"role": "user", "content": "Hello"}, ], stream=False)print(response.choices[0].message.content)

從官方示例上看，DeepSeek 相容 OpenAI 的 SDK 呼叫請求，阿里雲 Python Agent 支援 Open AI SDK 自動化埋點，所以預設相容 DeepSeek 場景自動化埋點採集能力，實現低成本採集各種請求類指標。另外，針對基於 vLLM 加速框架的模型服務進行自動化埋點採集，可以從模型服務端視角獲取更多的效能評估指標，從而可以彌補部分場景客戶端視角採集不全的短板。

面向使用者的 LLM 應用體驗監控

目前，國內外的 LLM 應用已經滲透到多個領域，並且在不同行業中展現出強大的潛力，而 LLM 應用相比傳統 Web、移動端應用，在使用者體驗監控方面存在以下差異：

那麼，LLM 應用如何衡量使用者體驗呢？目前 LLM 應用大多采用流式響應方式（即：逐字輸出結果），相比傳統應用，除了上文提到的 Time to First Token (TTFT)、Time Between Tokens (TBT) 、Time Per Output Token (TPOT) 等指標外，在使用者體驗方面還需要關注以下效能指標：

1、內容質量方面：

首次回答準確率 (First Response Accuracy)：使用者問題在首次回答中被正確解決的比例，通常結合人工標註或輔助模型判斷；
幻覺率 (Hallucination Rate)：模型生成內容中虛構事實或邏輯矛盾的比例，需要透過知識圖譜校驗、RAG（檢索增強生成）答案一致性對比；

2、互動效率方面：

使用者中斷率 (Abandonment Rate)：指使用者在生成完成前主動終止互動的比例，可能由於生成內容質量較差，或響應速度較慢導致；
多輪對話平均輪次 (Average Turns per Session)：使用者需要多次互動才能完成目標任務的對話輪數，可能反映意圖理解偏差，或內容生成質量不符合預期；
意圖修正頻率 (Intent Correction Frequency)：使用者透過“重述問題”或“否定回答”修正模型理解的次數；

除此之外，在不同應用場景下，還需要關注對應的業務指標，比如：智慧客服場景，需要關注人工透傳率；內容生成場景，還需要關注內容原創度、以及排版等，以上這些指標，通常很難在服務端進行埋點，因此，需要結合使用者體驗監控來進行覆蓋；

3、LLM 應用會話與傳統應用會話的關聯：

LLM 應用和傳統 Web、移動端應用一樣，都有會話的概念，從使用者體驗監控的視角，可以做如下對比：

相同點：

均需記錄使用者行為序列
依賴唯一識別符號（Session ID）追蹤鏈路
關注異常終止（如崩潰、網路中斷）

從上面的對比來看，LLM 應用的會話其實和傳統應用的會話沒有本質的區別，兩者之間可以進行關聯，這樣可以方便和使用者其他互動操作進行關聯分析，相信隨著 LLM 應用不斷發展，越來越多傳統應用接入 LLM 能力，這一點將會得到驗證。

LLM 專屬領域視覺化分析檢視

開箱即用的指標分析大盤可以覆蓋基礎的業務黃金三指標外以及場景化分析，針對複雜應用架構的 LLM 應用也可以滿足效能瓶頸分析需求。相比於微服務應用觀測檢視，新的 LLM 應用檢視，更加強調領域化大盤設計，突出 LLM 相關指標，支援 LLM 呼叫趨勢、Token 使用趨勢、模型維度分析、RAG 以及 Tool 呼叫分析等，從效能以及成本多種角度提供對應用執行狀態的全面瞭解；阿里雲可觀測提供的應用分析大盤效果如下：

推理效能分析：關注大模型呼叫請求數、耗時、錯誤等效能指標，從而可以對比不同的模型差異，例如首包耗時等領域指標；

Token 消耗分析：可以跟蹤分析輸入/輸出 Token 趨勢，瞭解哪些會話以及使用者 Token 消耗偏高，能夠幫助使用者分析 Token 成本以及增長趨勢。

呼叫鏈大模型分析檢視：基於 LLM 領域語義格式化展示 TraceView 更直觀，能夠輔助開發者快速瞭解執行過程以及輸入輸出細節，縮短定位問題的時間。

會話分析檢視：可以有效瞭解使用者對話時序以及對話問答效果，幫忙開發者最佳化流程設計以及提示詞調優，從可觀測到業務運營實現更好的業務洞察。

雲產品一站式端到端全鏈路打通

越來越多的企業使用到雲產品，而云產品對於開發者而言存在黑盒，例如從客戶端時間看到的耗時長，比較難分析是客戶端慢還是服務端慢了；雲產品自身提供端到端的鏈路埋點以及打通，就可以有效幫助開發定位耗時錯慢根因；目前可觀測鏈路 OpenTelemetry 版與阿里雲近 10 款雲產品（RUM、ALB、MSE 閘道器、ASM 等）深度合作，完成了雲產品內部鏈路插樁與資料上報。對於企業使用者來說，只需在相應的雲產品控制檯一鍵啟用鏈路追蹤開關，就可以直接看到相應的呼叫鏈，大幅簡化了鏈路採集成本。針對 LLM 應用的雲產品整合，阿里雲可觀測和百鍊、PAI、MSE 閘道器等密切合作，在 Prometheus 接入中心可以完成 PAI、百鍊、靈駿、容器Ray框架的接入，在雲產品側可以一鍵開啟實現開箱即用的鏈路打通。

另外，我們知道一個複雜的應用系統涉及到元件非常複雜，呼叫鏈鏈路也會非常長。當我們需要對 LLM 應用問題進行排查時，通常需要覆蓋使用者端到服務端完整鏈路進行分析，同時需要結合使用者體驗監控的資料，追蹤使用者側的輸入和操作，復現整個問題過程。前後端打通的完整呼叫鏈效果如下：

透過上述的鏈路打通能力，使用者在類似百鍊這樣的應用構建平臺專注構建智慧體應用，在百鍊側開啟應用可觀測基於請求呼叫鏈等進行除錯最佳化。透過登入阿里雲可觀測控制檯，檢視該智慧體的 LLM 應用更多的分析檢視，覆蓋 UI 端側->閘道器->後端->元件依賴->模型的完整業務鏈路，實現端到端全鏈路透視能力。

五、突破 LLM 應用觀測侷限：Dify 應用自動化埋點與端到端鏈路追蹤實戰

阿里雲 Python Agent 提供對常見大模型框架（Llamaindex、Dify、LangChain、OpenAI、通義千問、Prompt Flow等）的可觀測性提供自動化埋點接入能力。詳細資訊請檢視開始監控Python應用[2]。接下來以 Dify 應用接入可觀測舉例：

Dify.AI 是一款簡單易用且開源的 LLMOps 平臺，幫助開發者更簡單、更快速地建立 AI 應用。它的核心理念是透過可宣告式的 YAML 檔案定義 AI 應用的各個方面，包括 Prompt、上下文和外掛等。Dify 提供了視覺化的 Prompt 編排、運營、資料集管理等功能。這些功能使得開發者能夠在數天內完成 AI 應用的開發，或將 LLM 快速整合到現有應用中，並進行持續運營和改進。

在和客戶的交流中發現有很多開發者基於 Dify 開發 LLM 應用或者二次開發構建內部AI平臺，但缺乏有效的監控分析工具，同時也存在和其它內部系統鏈路打通的觀測需求。當前的 Dify 預設整合的 Langfuse 以及 Langsmith 都偏向於 LLM 領域，缺乏端到端的完整分析能力；阿里雲 Python Agent 針對上述場景，針對 Dify 內部執行鏈路進行精細埋點並採集豐富的資料，基於 OTel 標準預設和上下游進行串聯打通，幫助開發者更好的進行定位流程執行、工具呼叫、異常分析等。我們嘗試基於如下 Demo 來構建 LLM 應用並接入阿里雲可觀測。

步驟一：基於 Dify 構建工作流，並在業務流程中呼叫 DeepSeek 大語言模型來獲取結果。

步驟二：安裝阿里雲 Python Agent：

安裝 ack-onepilot，請確保 ack-onepilot 版本在 3.2.4 或以上。
修改 Dockerfile

從 PyPI 倉庫下載探針安裝器。

pip3 install aliyun-bootstrap

使用 aliyun-bootstrap 安裝探針。

aliyun-bootstrap -a install

透過 ARMS Python 探針啟動應用。

aliyun-instrument python app.py

構建映象。

授予 ARMS 資源的訪問許可權
修改工作負載 YAML

labels: aliyun.com/app-language: python # Python應用必填，標明此應用是Python應用。 armsPilotAutoEnable: 'on' armsPilotCreateAppName: "<your-deployment-name>" #應用在ARMS中的展示名稱

步驟三：在 Dify 應用入口發起流量，登入應用即時監控服務 ARMS 工作臺，檢視呼叫鏈詳情效果如下，包含模型呼叫引數、Token 消耗、呼叫耗時以及輸入輸出等內容：

六、未來展望以及挑戰

越來越多的微服務應用整合 LLM 能力來最佳化業務流程或者提效，往往出問題的環節不侷限於 LLM 呼叫，需要從使用者端到閘道器以及依賴服務等鏈路進行全鏈路問題排查以及根因定位。業界主流的 LLM Observability 平臺聚焦於模型側運維，提供了提示詞以及模板管理、Dataset、Evaluation、Playground 實驗對比等專業功能，比較適合研發除錯以及 LLMOps 運維人員，相對缺乏微服務領域端到端的全鏈路視角，而阿里雲可觀測平臺則側重於提供全鏈路的打通以及全棧可觀測能力。

阿里雲可觀測未來還會考慮支援實現呼叫鏈和 Evaluation 評分關聯，基於 Trace 進行進行自動化語義特徵分析等功能，幫助開發者解讀理解資料內涵，為客戶提供更多的語義化分析評估能力，實現可觀測和大模型的聯動打通。大模型服務作為LLM應用的核心依賴，模型側的診斷分析場景，例如支援 GPU Continous Profiling，vLLM 的推理框架的埋點觀測能力也在持續跟進中。阿里雲可觀測會持續跟蹤業界進展，提供全面且開箱即用的可觀測解決方案。