AI全栈知识15AI应用的可观测性 - Token监控与成本控制写在前面你维护一个普通微服务监控很简单QPS、延迟、错误率、CPU、内存。这些指标稳定可预测每次请求消耗的资源基本一致。AI服务不一样。同一个接口用户问你好可能消耗100个Token问帮我写一份完整的K8s部署方案可能消耗5000个Token。每次请求的成本完全不可预测。如果不做好监控你可能遇到月底收到一张天价账单不知道钱花在哪某个用户在刷量Token一直在烧但没人发现Agent陷入死循环一个请求消耗了几万Token用户投诉AI好慢但你看CPU利用率才30%这篇帮你建立AI服务的完整可观测性体系。AI服务跟普通服务的监控区别普通微服务的监控指标固定、成本可预测 - QPS每秒处理多少请求 - 延迟每个请求多少毫秒 - 错误率多少请求报错 - 资源CPU/内存使用率 特点每次请求消耗的资源差不多AI服务多出来的监控指标波动大、成本不可预测 - Token消耗每次请求不一样100~10000 - 首Token延迟用户等多久看到第一个字 - 生成速度每秒输出多少Token - 成本元直接跟钱挂钩 - 调用轮次Agent跑了几轮 - 模型选择用了哪个模型大小模型成本不同维度普通微服务AI服务成本模型固定服务器费/月变动按Token计费延迟构成单一处理时间复合首Token生成请求成本差异几乎一样差100倍简单问题vs复杂问题失败模式崩溃/超时额外有死循环/Token爆炸/模型拒绝成本归因按服务分摊需按团队/功能/用户归因核心指标一Token消耗为什么Token是最重要的指标Token 钱。调用大模型API按Token计费通义千问qwen-turbo 输入0.003元/千Token 输出0.006元/千Token GPT-4o 输入0.01元/千Token 输出0.03元/千Token一个请求如果消耗5000 Token输入3000输出2000用GPT-4o就花了0.09元。看着不多100个用户每人每天10次 90元/天 2700元/月。如果有个Agent死循环消耗了50000 Token一次请求就花掉将近1元。不监控根本发现不了。需要记录的Token指标# 每次请求记录token_metrics{request_id:req-xxx,user_id:user-001,function:customer_service,# 哪个功能model:qwen-turbo,# 用了哪个模型prompt_tokens:1500,# 输入Tokencompletion_tokens:800,# 输出Tokentotal_tokens:2300,# 总Tokencost_yuan:0.0093,# 换算成钱rounds:3,# Agent跑了几轮}Prometheus打点fromprometheus_clientimportCounter,Histogram# Token总量TOKENS_TOTALCounter(ai_tokens_total,Total tokens consumed,[model,function,token_type]# 按模型、功能、输入/输出分类)# 每次请求的Token数分布TOKENS_PER_REQUESTHistogram(ai_tokens_per_request,Tokens per request,[model,function],buckets[100,500,1000,2000,5000,10000,20000,50000])# 使用时TOKENS_TOTAL.labels(modelqwen-turbo,functioncustomer_service,token_typeprompt).inc(1500)TOKENS_TOTAL.labels(modelqwen-turbo,functioncustomer_service,token_typecompletion).inc(800)TOKENS_PER_REQUEST.labels(modelqwen-turbo,functioncustomer_service).observe(2300)核心指标二延迟TTFT 生成速度两段延迟AI服务的延迟跟普通服务不一样分两段用户发送问题 ↓ [等待...] ← TTFTTime To First Token首Token延迟 ↓ 用户在这段时间里看到的是空白/loading 开始输出第一个字 ↓ [持续输出中...] ← 生成速度每秒输出多少Token ↓ 用户看到文字在一个一个往外蹦 输出完毕 ← 总延迟End-to-End Latency为什么要分开看指标影响什么用户感受TTFT用户等多久开始看到回答TTFT3秒用户就觉得卡了生成速度文字蹦出来的快慢10 tokens/s像打字机30基本感知不到总延迟完整回答出来要多久Agent多轮可能几十秒用户体验主要看TTFT。哪怕总回答需要10秒只要0.5秒就开始出字用户感觉就很快流式输出的优势。Prometheus打点TTFTHistogram(ai_time_to_first_token_seconds,Time to first token,[model,function],buckets[0.1,0.3,0.5,1.0,2.0,3.0,5.0,10.0])GENERATION_SPEEDHistogram(ai_generation_tokens_per_second,Token generation speed,[model],buckets[5,10,20,30,50,100])E2E_LATENCYHistogram(ai_request_duration_seconds,End-to-end request latency,[model,function],buckets[1,2,5,10,20,30,60])核心指标三成本归因问题月底Token账单来了总共花了5000元。老板问钱花在哪了哪个团队花的哪个功能最烧钱如果没有成本归因你只能说总共花了5000。有了归因你能说本月Token成本归因 客服机器人3200元64%← 最大头 内部知识搜索1100元22% 运维Agent500元10% 测试/开发调试200元4%怎么做在每次API调用时打上标签团队、功能、环境classCostTracker:def__init__(self):self.records[]defrecord(self,team,function,model,tokens,cost):self.records.append({timestamp:datetime.now(),team:team,# 哪个团队function:function,# 哪个功能model:model,# 什么模型tokens:tokens,# 消耗多少Tokencost:cost,# 花了多少钱})defdaily_report(self):生成每日成本报告# 按团队/功能汇总...Prometheus Label设计# 关键通过label区分来源COST_YUANCounter(ai_cost_yuan_total,Total cost in yuan,[team,function,model,environment])# 使用时COST_YUAN.labels(teamcustomer_service,functionchat_bot,modelqwen-turbo,environmentproduction).inc(0.009)Grafana里就能按team筛选看每个团队的花费趋势。核心指标四调用链追踪为什么需要Agent可能调了5轮LLM、3个工具最后给了一个错误答案。不记录调用链你不知道是第几轮出的问题。一次Agent请求的完整调用链{trace_id:trace-abc123,request_id:req-001,user_input:帮我查查order-service为什么报错,total_duration_ms:8500,total_tokens:4500,total_cost_yuan:0.018,rounds:[{round:1,action:llm_call,model:qwen-turbo,prompt_tokens:800,completion_tokens:50,duration_ms:1200,decision:call tool: get_unhealthy_pods},{round:2,action:tool_call,tool:get_unhealthy_pods,duration_ms:300,result:order-service-xxx: CrashLoopBackOff},{round:3,action:llm_call,model:qwen-turbo,prompt_tokens:1200,completion_tokens:60,duration_ms:1500,decision:call tool: get_pod_logs},{round:4,action:tool_call,tool:get_pod_logs,duration_ms:500,result:OutOfMemoryError...},{round:5,action:llm_call,model:qwen-turbo,prompt_tokens:1800,completion_tokens:200,duration_ms:2000,decision:final_answer}]}有了这个出问题时能精确定位第几轮、调了什么、结果是什么、Token花在哪了。接入方式可以用OpenTelemetry或自己写日志。核心是每次LLM调用和工具调用都带上同一个trace_idimportuuidclassRequestTracer:def__init__(self):self.trace_idstr(uuid.uuid4())self.rounds[]deflog_llm_call(self,round_num,model,prompt_tokens,completion_tokens,duration_ms,decision):self.rounds.append({round:round_num,action:llm_call,model:model,prompt_tokens:prompt_tokens,completion_tokens:completion_tokens,duration_ms:duration_ms,decision:decision,})deflog_tool_call(self,round_num,tool_name,duration_ms,result_preview):self.rounds.append({round:round_num,action:tool_call,tool:tool_name,duration_ms:duration_ms,result:result_preview[:200],# 只存前200字})核心指标五异常检测AI服务独有的异常场景异常现象原因告警条件Token暴涨单次请求20000 TokenAgent死循环/用户输入超长文本单次阈值成本突增今日花费已超预算80%流量突增/被刷量/模型选错了日成本阈值延迟飙升TTFT从0.5s变成5s模型过载/并发太高P99阈值拒绝率升高模型频繁返回无法回答安全策略误杀/Prompt有问题拒绝率10%空回答模型返回空字符串模型异常/Token用完空回答率5%重复调用同一用户短时间大量请求恶意刷量/前端bug每分钟20次告警规则Prometheus AlertManagergroups:-name:ai_service_alertsrules:# Token单次暴涨-alert:HighTokensPerRequestexpr:ai_tokens_per_request20000for:0mlabels:severity:warningannotations:summary:单次请求Token异常高# 日成本超预算-alert:DailyCostExceededexpr:sum(increase(ai_cost_yuan_total[24h]))200for:5mlabels:severity:criticalannotations:summary:今日AI成本已超200元# TTFT延迟飙升-alert:HighTTFTexpr:histogram_quantile(0.99,ai_time_to_first_token_seconds)5for:5mlabels:severity:warningannotations:summary:首Token延迟P99超过5秒# 用户刷量-alert:UserRateLimitexpr:sum(rate(ai_tokens_total[1m])) by (user_id)50000for:2mlabels:severity:warningannotations:summary:某用户Token消耗速率异常Grafana面板设计推荐面板布局第一行概览 - 今日总Token消耗 今日总成本大数字显示 - 当前QPS - 当前活跃用户数 第二行延迟 - TTFT P50 / P95 / P99 趋势图 - 生成速度 (tokens/s) 趋势图 - 请求总延迟分布 第三行Token详情 - Token消耗趋势按功能/团队分色 - 每次请求Token分布直方图 - 输入Token vs 输出Token比例 第四行成本 - 每日成本趋势柱状图 - 成本按团队归因饼图 - 成本按模型归因饼图 - 预算消耗进度条 第五行异常 - 单次高Token请求列表 - 错误/拒绝率趋势 - Agent平均轮次趋势PromQL示例# 今日总Token sum(increase(ai_tokens_total[24h])) # 今日总成本元 sum(increase(ai_cost_yuan_total[24h])) # TTFT P99 histogram_quantile(0.99, rate(ai_time_to_first_token_seconds_bucket[5m])) # 按团队的Token消耗速率 sum(rate(ai_tokens_total[5m])) by (team) # Agent平均轮次 avg(ai_agent_rounds_per_request)成本控制实战预算管理classBudgetManager:def__init__(self,daily_budget_yuan200,monthly_budget_yuan5000):self.daily_budgetdaily_budget_yuan self.monthly_budgetmonthly_budget_yuan self.daily_spent0self.monthly_spent0defcheck_budget(self,estimated_cost):请求前检查预算ifself.daily_spentestimated_costself.daily_budget:returnFalse,今日预算已用完ifself.monthly_spentestimated_costself.monthly_budget:returnFalse,本月预算已用完returnTrue,OKdefon_request_complete(self,actual_cost):请求完成后记录花费self.daily_spentactual_cost self.monthly_spentactual_cost# 达到80%告警ifself.daily_spentself.daily_budget*0.8:send_alert(今日预算已使用80%)省钱策略策略做法节省比例大小模型路由简单问题用小模型复杂问题用大模型30-50%Prompt精简去掉冗余的System Prompt10-20%缓存相同问题直接返回缓存结果视场景20-80%限流每用户每分钟限制请求次数防止异常消耗设Token上限max_tokens限制输出长度防止超长回答选择合适模型不是所有场景都需要最贵的模型50-90%缓存示例importhashlibclassResponseCache:def__init__(self,ttl_seconds3600):self.cache{}self.ttlttl_secondsdefget_cache_key(self,model,messages):相同的输入生成相同的keycontentf{model}:{str(messages)}returnhashlib.md5(content.encode()).hexdigest()defget(self,model,messages):keyself.get_cache_key(model,messages)ifkeyinself.cache:entryself.cache[key]iftime.time()-entry[time]self.ttl:returnentry[response]# 命中缓存省TokenreturnNonedefset(self,model,messages,response):keyself.get_cache_key(model,messages)self.cache[key]{response:response,time:time.time()}完整监控架构AI应用打点 │ ├── Prometheus指标Token/延迟/成本/错误率 │ ↓ │ Prometheus Server │ ↓ │ Grafana面板展示 │ ↓ │ AlertManager告警通知 │ ├── 调用链日志每轮详情 │ ↓ │ ELK / Loki存储查询 │ ↓ │ Kibana / Grafana搜索回溯 │ └── 成本报表 ↓ 定时任务每日/每周汇总 ↓ 发送到钉钉/邮件面试怎么说如果被问AI服务怎么做监控AI服务跟普通微服务最大的区别是每次请求成本不固定所以监控要重点关注Token消耗和成本。我的监控体系分五个维度Token消耗按模型、功能、团队打标签能做成本归因延迟分首Token延迟TTFT和总延迟用户体验主要看TTFT成本每日预算管控达到80%告警达到100%限流调用链Agent的每轮LLM调用和工具调用都记录出问题能回溯异常检测单次Token暴涨、用户刷量、死循环都有告警规则技术栈用Prometheus打点 Grafana面板 AlertManager告警调用链用ELK或Loki。还有一些省钱手段大小模型路由简单问题用小模型、响应缓存、Prompt精简。我们落地后Token成本降了约40%。延伸思考问题答案自部署vLLM也需要监控Token吗需要。虽然不按Token付费但Token数影响延迟和吞吐是容量规划的依据怎么估算一次请求的成本输入Token × 输入单价 输出Token × 输出单价。大部分API返回usage字段监控数据存多久明细日志保留7-30天聚合指标保留3-6个月做趋势分析小公司需要做这么完整吗不用。先做Token总量日成本TTFT这三个最核心的其他慢慢补OpenTelemetry支持AI监控吗社区在推LLM Observability标准LangSmith和LangFuse是专门做AI调用链的工具小结本篇核心收获AI服务监控核心差异每次请求成本不固定Token钱五大监控维度Token消耗、延迟TTFT总延迟、成本归因、调用链、异常检测TTFT比总延迟更重要用户体验看首字输出速度成本归因必须做按团队/功能打标签知道钱花在哪了异常检测防止烧钱Token暴涨、死循环、刷量都要有告警省钱手段大小模型路由缓存Prompt精简限流下一篇预告AI全栈知识16AI应用架构设计 - 从单体到平台下一篇进入架构设计OneAPI网关层设计应用层RAG/Agent的分层模型层vLLM的部署策略从单应用到AI平台的演进路径参考链接Prometheus Client PythonOpenTelemetry LLM ObservabilityLangFuseAI调用链追踪LangSmithLangChain官方追踪vLLM Metrics文档