1. 开始之前为什么需要专门给大模型加装“监控仪表盘”现在做大模型应用已经不像一年前那样“调通接口就完事”。不管是做RAG知识库、Agent工作流还是给企业做私有化部署团队都会遇到一个很现实的问题跑起来容易想长期稳定地跑下去很难。尤其是在规模化场景下模型推理的耗时波动、Token消耗成本失控、任务半夜静默失败——这三大问题几乎是每个工程师都必须正面硬刚的坎。我自己在做DeepSeek Harness相关项目时最初的痛点和大多数人一样任务一多根本不知道每一个任务到底花了多少钱、哪一步最慢、失败是模型返回格式问题还是网络超时只能靠猜和翻日志硬扛。后来踩了不少坑才慢慢沉淀出一套查询口径。这篇文章就把这些经验整理出来重点讨论三件事怎么查耗时、怎么查成本、怎么查失败。如果你也在跑批量推理任务、长期Agent任务或者正在搭一个大模型应用的监控体系这篇文章应该能帮你少走很多弯路。本文会从指标定义、数据采集、日常查询、问题定位这四个层面展开尽量把“怎么查”这件事讲透。里面提到的查询思路和排查方法可以迁移到各类大模型推理框架上不一定只适用于某一个框架。2. 规模化观测的核心矛盾为什么默认日志总是“不够用”先聊一个很多团队都会忽略的问题。大模型推理和传统后端服务有一个本质区别传统接口的耗时和成本基本是稳定的但大模型任务受到模型负载、输入长度、输出长度、缓存命中率等多重因素影响同一个任务的耗时和Token消耗可能会有数倍波动。这意味着用“看日志、数报错”的方式去管理规模化推理任务一定会出问题。2.1 默认日志缺了哪些关键信息刚开始做DeepSeek Harness接入时我用的是最朴素的日志方案每个任务开始打一条结束打一条报错就打一条。看起来逻辑很完整但实际上距离“可观测”差得很远。默认日志通常缺少三类关键信息第一缺少阶段耗时拆分。一个完整的推理调用可能包含排队、网络传输、输入预处理、模型推理、输出流式处理这几个阶段。如果不做阶段拆分看到一个任务总耗时10秒你根本不知道瓶颈是在模型推理本身还是在网络传输上。不同的瓶颈对应完全不同的优化手段。第二缺少Token级成本归因。模型计费是基于Token的输入Token和输出Token的价格通常不一样输出Token一般更贵。且非流式调用和流式调用之间Token统计口径也有差异。如果不单独记录这些字段出了问题之后只能拿账单去对总量完全没法定位是哪个业务方、哪个任务类型消耗了大头。第三缺少失败类型标签。一个任务失败可能是模型端返回了异常状态码也可能是超时、限流、上下文超长、JSON解析失败、内容安全策略触发等。把这些失败原因全部混在Error日志里后续做问题归因时基本只能靠人肉逐条看效率极低。提示从一开始就按结构化字段输出任务日志包括任务ID、模型名称、输入Token数、输出Token数、各阶段耗时、状态码、失败类型、重试次数。这个习惯能让你在任务量从几百涨到几万的时候依然保持“可查询”的能力。2.2 规模化场景下有四个指标维度必须盯结合我自己的运维经验规模化观测至少要盯四个指标维度。如果你们团队刚起步可以先从这四个维度搭骨架后续再慢慢细化。第一个是吞吐维度比如每秒请求数RPS、每分钟任务数。这个指标反映的是系统的处理能力。大模型推理服务的RPS一般不会像普通Web服务那么高但要注意的是不能只盯请求数还要看输出Token的吞吐量Token/s因为一个输出很长的任务占用的资源量可能是短任务的好几倍。第二个是性能维度包括端到端延迟、首Token延迟、推理阶段耗时等。其中首Token延迟对交互式应用的影响很大它决定了用户从发出问题到看到第一个字需要等待多久。如果是流式接口首Token延迟一般会比端到端延迟更值得关注。第三个是成本维度包括每任务的Token消耗、单位Token成本、按业务线/模型维度的总成本。大模型应用的成本不像服务器资源那样“买了就能看到账单”它是按Token精细计量的更需要主动做埋点和统计。第四个是质量与稳定性维度包括成功率、失败分布、重试率、上下文截断次数等。这部分和业务质量直接挂钩也是排查“任务为什么挂了”的核心依据。这四个维度不是互相独立的。比如一个任务超时了可能是因为系统吞吐被打满也可能是因为输出Token数量超过了预期也可能是因为触发重试导致整体耗时翻倍。只有把四个维度的数据打通才能做交叉定位。3. 耗时查询的实操拆解从总耗时到每阶段耗时耗时是最直观也最好理解的指标但在规模化场景下只查总耗时远远不够。我遇到过很多次这样的情况一个任务显示耗时20秒看起来不算离谱但用户体感特别差原因是这20秒里有15秒花在了排队上真正开始推理之后3秒就出结果了。这种场景下如果只优化推理速度对体感没有任何改善。正确的做法是先拆阶段。3.1 划分阶段端到端任务至少要切五段在DeepSeek Harness的调用链路里我把一次完整的任务切成了五个阶段排队等待阶段从任务提交到开始被处理的时间这个阶段的长短反映了服务的繁忙程度。预处理阶段包括请求参数校验、对话历史组装、Prompt模板渲染、上下文截断处理等。网络传输阶段请求从客户端到服务端的网络往返耗时。如果自建网关或跨地域调用这个阶段可能会很夸张。模型推理阶段从请求发到模型服务到第一个Token生成或者完整结果生成的时间。这是核心阶段也最需要精细监控。后处理阶段包括结果解析、格式化输出、工具调用结果注入、向量检索后处理等。每个阶段都需要记录独立的时间戳。有人可能会问直接在总耗时上做减法不行吗不行。只有记录阶段级耗时才能回答“到底慢在哪里”这个问题。而且阶段耗时的采集逻辑建议放在代码的公共封装层不要在业务代码里散落打点。这样后续有新的调用场景接入时会默认带上这些指标不需要额外开发。3.2 耗时查询的三个常用口径阶段拆分做好之后查询耗时就有多维度的口径可以选择了。我这里分享三个最常用的查询场景。第一个场景是“跑批任务整体耗时分布”。比如每天凌晨批量跑1000个文档处理任务预计2小时内跑完但今天跑了3小时还没结束。这时候不应该只看单个任务的日志而要看这批任务的耗时分布曲线和P50/P95/P99延迟。如果发现绝大多数任务都快只有少数任务异常慢那大概率是长文本任务拖慢了整体节奏如果发现整体分布都右移了那可能是模型服务本身变慢了需要去查模型端的负载情况。第二个场景是“单任务阶段耗时分析”。当用户反馈“他这个问题感觉回答得特别慢”时我会去查这个任务ID的阶段耗时记录。先看端到端总耗时然后依次看五个阶段快速定位是等待时间太长还是模型推理时间太长还是后处理阶段发生了什么异常。第三个场景是“多模型对比”。如果系统里接入了多个模型渠道我会用同一批测试请求分别打向不同渠道对比它们的阶段耗时分位值。这种对比能直观看出“更贵的模型是否真的更快”或者“同一个模型在不同渠道商的响应能力差距有多大”。-- 示例按小时聚合统计“模型推理耗时”的P50/P95并关联请求量 SELECT date_format(start_time, %Y-%m-%d %H:00:00) AS hour, approx_percentile(inference_ms, 0.50) AS p50_infer_ms, approx_percentile(inference_ms, 0.95) AS p95_infer_ms, COUNT(*) AS total_requests FROM task_timing_log WHERE start_time now() - interval 24 hour GROUP BY 1 ORDER BY 1 DESC3.3 开源组件打点用装饰器把指标采集逻辑收敛到一行为了不让打点代码污染业务逻辑我实现了一个简单的装饰器专门用来统一记录耗时指标。这个装饰器会把上面提到的几个阶段都拆分清楚并且自动关联任务ID和模型名称。import time import functools from dataclasses import dataclass, field dataclass class StageTiming: stage: str duration_ms: float extra: dict field(default_factorydict) def trace_stages(task_id, model_name): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): stages [] # 排队阶段往往由外层队列系统注入这里从函数开始计时 t0 time.perf_counter() # 预处理阶段示例 t time.perf_counter() # ... 原本的预处理逻辑 ... stages.append(StageTiming(stagepreprocess, duration_ms(time.perf_counter() - t) * 1000)) # 模型推理阶段示例 t time.perf_counter() result func(*args, **kwargs) stages.append(StageTiming(stageinference, duration_ms(time.perf_counter() - t) * 1000)) # 后处理阶段示例 t time.perf_counter() # ... 原本的后处理逻辑 ... stages.append(StageTiming(stagepostprocess, duration_ms(time.perf_counter() - t) * 1000)) # 上报记录 report_timing(task_id, model_name, stages) return result return wrapper return decorator这个设计的核心是把与业务无关的埋点逻辑彻底抽出来。业务代码只关注自己的事所有阶段耗时、Token消耗、状态码上报都在公共层完成。后续如果要统计新模型只要在调用时传入model_name就行不需要改动埋点代码本身。4. 成本查询的守门艺术从“事后看账单”到“实时看消耗”成本问题在规模上来之后会变得特别尖锐。我自己见过不少团队一开始跑POC的时候觉得“模型真便宜”但一旦切到生产环境、流量上涨十倍月底看到账单才发现成本完全失控。问题不在于模型本身贵而在于没有建立成本观测的机制导致异常消耗没办法及时发现。4.1 Token计量的关键字段不要只记录一个total_tokens记录Token消耗最基础的做法是拿到接口返回里的usage对象把total_tokens存下来。但如果你想在规模化场景下做成本分析只记录total_tokens远远不够下面三个字段必须记录。第一个是输入Token数prompt_tokens。不同业务场景的输入Token分布差异巨大。比如文档总结类任务输入Token动辄上万而意图识别类任务的输入可能就几百Token。输入Token往往决定了上下文处理的时间也决定了不少模型渠道的计费基准。第二个是缓存Token数cached_tokens或prompt_cache_hit_tokens。现在不少模型服务支持上下文缓存命中了缓存输入部分的价格会低很多。如果不记录缓存Token你在做成本账的时候会发现实际账单和估算对不上。记录缓存命中率某种意义上比记录总Token数更有价值因为它直接反映你的系统设计是否在复用上下文。第三个是输出Token数completion_tokens。输出Token的计费通常比输入Token更高也是生成质量、生成长度的直接体现。单独记录输出Token对于发现异常的“话痨”任务特别有帮助——有的任务设计上只需要输出100字的结论结果不知道什么原因输出了2000字成本翻了不止一倍。4.2 成本归因把Token消耗绑定到业务维度记录Token之后下一步就是归因。传统的做法是把所有调用产生的Token费用加在一起做总账但在多人协作、多业务线并行开发的场景下这种粗放统计很容易引发“这钱到底是谁花的”的争论。合理的做法是在每次调用时就打上业务标签比如业务线/项目名称比如客服助手、文档分析调用场景比如在线问答、批量离线处理、测试调试用户/团队归属避免让个人调试代码产生的Token消耗混入生产统计具体的实现方式仍然是在公共调用层统一从调用上下文里读取这些标签。我见过一些团队习惯把标签信息塞在Prompt里这是不推荐的因为会额外增加Token消耗而且让日志数据变得不干净。更合适的做法是用独立的metadata字段维护这些标签在调用和上报时一并传递。注意成本分析不要只做“平均值”。因为大模型应用的成本遵循长尾分布最有价值的分析角度是找出“消费最高的Top任务/用户/场景”然后去看这些高消耗是否合理。如果一个批量分析任务消耗了全部门80%的Token需要确认的是这个任务是否应该用更小的模型是否可以把一些固定逻辑抽离出来用规则处理4.3 单任务成本预估如何做到“请求发出去之前心里有数”有的场景要求在发起请求之前就预估成本方便做预算管控或用户配额限制。虽然预估永远做不到精确但结合历史统计是可以做到相对靠谱的。预估成本的公式是预估成本 预估输入Token数 × 输入单价 预估输出Token数 × 输出单价问题在于怎么预估输入和输出Token数。输入Token数可以通过历史类似任务的Token密度来估算。比如你有一个知识库问答场景用户平均提问150字平均附带的上下文是3000字那可以参考中文场景约1个汉字对应1.2到1.5个Token的经验值估算输入Token在4000到4500之间。输出Token数则可以通过设置max_tokens参数直接预测但需要注意不同模型服务商对max_tokens的取值含义并不完全一致有的表示“最大生成Token数”有的还包含了推理预留Token。我自己的做法是维护一张“场景级Token消耗基线表”定期更新。每次跑不同类型任务时都会用真实数据去修正这张表的估算参数。这样在上新需求时产品和研发就能基于基线表快速评估“这个需求上线后每月会增加多少模型成本”。5. 失败查询的系统方法把“任务为什么会挂”变成可检索的问题相比耗时和成本失败问题的排查往往更紧急也更容易让人头疼。传统做法是任务报错就查看Error日志如果是偶发失败就重试一次重试成功就不管了。但在规模化场景下不应该指望重试去掩盖所有问题很多失败是需要系统性分析才能根治的。5.1 建立失败类型体系停止使用笼统的“Error”为了能够快速检索和归因我给每个失败都打上了结构化的失败类型字段。下面是我梳理的比较常见的失败类型供大家参考失败类型触发场景典型修复方向timeout任务在某个阶段超过最大等待时间拆分任务、优化超时阈值、扩容rate_limit触发了模型侧的调用频控限制线程池/令牌桶限流、升级配额context_length_exceeded上下文超出模型最大长度做检索压缩、摘要化、裁剪历史bad_response_format模型返回内容无法按预期解析修正Prompt格式说明、增加自修复解析content_filter触发内容安全策略拦截调整输入内容/检查提示注入风险server_error模型侧返回5xx错误服务端已故障应该启动退避重试connection_error网络连接中断或DNS解析失败检查网络链路、配置重试机制把失败类型字段加上之后日常排查模式就从“人肉翻日志找Error”变成了“用SQL或查询面板按失败类型分桶统计”。这在任务量达到每天数千条后会显示出巨大的效率差异。5.2 失败归因的常用SQL/查询模板记录失败日志时我推荐至少保存这些字段任务ID、模型名称、失败类型、失败阶段、HTTP状态码、重试次数、具体错误信息摘要、任务标签用于归因以及发生时间。用一套合适的方法或工具包括但不限于SQL数据库、表格工具查询的时候我常用的查询模板有这几个第一个是与时间相关的算法比如“看最近15分钟内的失败分布”。这类算法用于快速判断线上是否有故障。如果失败集中在同一时间段大概率是模型服务侧有问题如果是零零散散分布则更可能是环境、用户输入或超时问题。-- 按失败类型统计最近15分钟的失败任务分布 SELECT failure_type, COUNT(*) AS failure_count FROM task_failure_log WHERE occurred_at now() - interval 15 minute GROUP BY failure_type ORDER BY failure_count DESC第二个是看“某个业务场景的失败趋势”比如近7天按天聚合失败率。这种用法用于发现缓慢变坏的信号比如某一天某个场景的失败率从0.5%悄悄涨到了5%就值得警惕了。第三个是看“某个特定任务ID的完整失败重试链”。通过任务ID把所有重试记录打出来观察同一次任务经历了哪几次失败、每次失败的间隙是多长判断当前的重试策略是否合理。5.3 失败趋势排查中容易忽略的几个问题排查失败原因时通常还要考虑几个方面。要注意模型版本或渠道商的隐性变更。模型服务一般是动态升级的同一个模型名称背后的实际能力可能已经发生了多次变化。如果某天开始失败率飙升而你的代码没动过需要去确认模型侧是否有版本变化新的版本可能更严格也可能格式变化了。要注意上下文长度相关的隐性失败。有的失败并不会触发context_length_exceeded这样明确的报错而是表现为模型开始“胡说八道”或者输出截断。这类问题建议主动记录上一次可成功调用的上下文Token基线通过对比Token数的变化异常值来辅助定位。要留意重试逻辑是否掩盖了“必然失败”。举个例子如果任务是解析模型返回的JSON但模型的输出被内容安全策略拦了一部分那么重试5次都会失败每次还都消耗同样的输入Token和推理时间。单纯提高重试次数不仅解决不了问题还会成倍放大成本。更合理的做法是设置“重试N次后失败类型自动升级”并触发降级策略或者人工审核流程。6. 把三类查询合到一张表里用任务级明细表实现“一次查询全知道”数据采集和查询逻辑分别讲完后我认为比较高效的方案是把耗时、成本、失败信息整合到同一张任务级明细表里。这样做的好处特别明显当用户来反馈“我这个任务为什么这么慢/这么贵/失败了”时你只要把任务ID拿过来一条SQL就能看到全貌不用再折腾多个系统来回对账。6.1 明细表的核心字段设计一张任务级明细表的核心字段大致如下。命名可以根据实际场景调整但关键维度建议不要缺字段组建议字段说明身份信息task_id, request_id, model_name, business_scene用于快速定位和归因时间信息start_time, end_time, total_duration_ms支持时间范围查询阶段耗时queue_ms, preprocess_ms, inference_ms, postprocess_ms用于瓶颈定位Token统计input_tokens, output_tokens, cached_tokens用于成本核算成本统计estimated_cost, cost_currency, unit_price_version用于成本归因质量信息status_code, failure_type, retry_count, error_message用于失败分析环境信息deployment_env, api_provider用于区分正式环境/测试环境字段设计时有一点要特别提醒不要过度设计。有些团队一开始就把几十个字段全部采集齐结果很多字段根本没被使用。合理的做法是先保证核心字段稳定采集等真正有了需要再往下扩展。6.2 示例查询一个任务从提交到结束的完整视图假设用户报告一个任务执行异常你可以用这样的查询瞬间拉出这个任务的关键信息。不同数据存储方言会有差异我这里只展示核心查询逻辑。-- 查询指定任务ID的耗时 成本 失败信息 SELECT task_id, model_name, business_scene, start_time, total_duration_ms, queue_ms, inference_ms, postprocess_ms, input_tokens, output_tokens, cached_tokens, estimated_cost, status_code, failure_type, retry_count, error_message FROM task_daily_detail WHERE task_id your_task_id通过这种查询方式如果发现inference_ms占总耗时比例很高那就要去看模型服务端是否有瓶颈如果发现output_tokens异常高那要追问一下为什么这个任务输出了这么多内容如果failure_type是rate_limit并且retry_count很高那基本可以定位是限流问题需要调整调用侧并发策略。6.3 数据清洗与口径统一埋点方案里最容易被轻视的部分在做汇总统计前必须要明确几类口径问题否则数据之间会互相矛盾。我这个部分列几个大家最容易踩坑的点时间口径记录耗时到底是用客户端墙钟时间还是模型侧返回的时间戳两边如果有差异在对账时会出现“任务执行了80秒但模型侧统计只有70秒”这类说不清的偏差。Token口径uses缓存的那部分逻辑计算问题。同一个上下文命中缓存或部分命中和完全未命中Token数量和成本都会有很大差异。失败口径重试最终成功到底算失败还是成功建议单位统计时同时记录“原始失败数”和“最终失败数”前者反映稳定性后者反映客户可感知的成功率。这些口径如果在第一天没有对齐后期做数据分析时会在“该听谁的”这个问题上浪费大量时间。越是多人协作的团队越应该在埋点初期就建立一份数据口径文档把这些定义固化下来作为后续数据分析和问题定位的唯一参考基准。7. 异常成本与慢任务的主动发现从“等用户投诉”到“自己先报警”除了被动的“哪里有问题查哪里”更成熟的做法是建立主动发现机制。大模型应用的指标体系比较特殊的地方在于成本、耗时、失败这三类问题在报警阈值上不能简单套用传统Web服务的静态阈值。因为它们随时都可能受到Prompt变化、模型版本变化、业务高峰等因素影响背景噪声天然很大。7.1 设置基线报警的实践我实践下来比较可行的方法是用动态基线代替静态阈值。比如当某个团队的日消耗Token数环比前7天同时间段平均值上涨超过50%时触发报警或者单任务cost分布偏离历史同类任务P95过多时发出提示再或者某类失败类型占比在1小时内从0.1%涨到1%时自动告警。这个思路背后的考量是大模型任务的指标天然不平稳用固定阈值会频繁误报。动态基线至少能在“系统自己突然出现拐点”时帮你快速发现。而模板之所以不推荐在业务代码中散落打点是因为一旦要做动态基线监控所有逻辑都必须收敛在统一的埋点和查询层里才好做联动判定。7.2 耗时相关的成本陷阱如何识别“慢任务正在偷偷吃预算”慢任务和成本超支经常同时出现因为模型推理时间越长往往意味着输出的Token越多而限流重试次数越多成本也会倍数增加。如果某个任务的失败类型不是超时却花了很长时间通常可以从两个角度去查。一个是查看该任务是否有“隐含的多次内部调用”。例如一个Agent任务表面上是一个任务实际上内部可能调用了好几轮模型接口、多次工具调用和多次检索。如果只想改一次接口就完成这样复杂的逻辑链路任务的失败率会显著上升。建议在日志链路里增加一个“内部调用序号”字段用来追踪同一个外层任务内部的所有推理请求。这样如果某任务总消耗很高你就能看清楚是哪一个内部步骤在烧钱。另一个就是查看“上下文反复重放”问题。某些Agent框架在工具调用后会重复把完整历史发给模型如果不对历史做裁剪或摘要压缩上下文会像滚雪球一样越来越大。每多一轮工具调用输入Token都会增长一轮到第10轮时的输入可能已经是第1轮的几倍了。从成本账上看到的现象是“一个任务明明没多少轮对话Token消耗却不合常理地高”。7.3 用最简仪表板扭转团队习惯很多工程团队已经引入了可视化分析工具来做日常监控不一定非得配置得极度复杂关键是让数据“好查”。我自己搭建过一个非常简洁的仪表板只保留了四张核心图表分别是近24小时请求量与端到端耗时趋势按模型拆分的Token消耗占比按失败类型拆分的失败分布Top 10 单任务成本排行榜就这四张图已经足够支撑大部分日常排查。尤其在团队协作中任何人反馈“系统好像有点慢”或“最近成本是不是高了”都可以先甩出这个仪表板请对方自己看一下是哪个环节异动效率比来回翻日志高很多。很多团队不是缺少监控工具而是缺少对“使用数据来回答问题”的习惯。一个低门槛可查的仪表板往往是扭转这种习惯的最佳起点。