推理结果的日志怎么记？排查的第一手资料

大模型服务出了状况，模型本身没法开口解释，第一手线索全在推理日志里。日志记得好不好，平时看不出差别，出事时高下立判，记什么、怎么串、怎么查决定了排查速度。

一条日志里都记什么

核心字段有五类：请求标识、时间戳、输入输出概况、资源消耗、结果状态。进来的是一次请求的完整生命周期数据，发生的是字段抽取与脱敏，出去的是一条结构化日志。

五类字段各自记什么、排查时顶什么用，摊开对照。

内容取舍有讲究：全文都存撑爆存储还涉隐私，全都不存出事没法查。常见做法是存输入输出的摘要与长度、提示词模板的版本号，原文按需另存并加访问限制。字段设计有个原则：排查要用的一定有，用不上的尽量没有，字段越多写入越慢、存储越贵。脱敏要放在写入前：原文里的人名、账号、手机号先处理后落盘，事后补救既不彻底也来不及，日志一旦扩散就收不回来。

字段之外还要定格式：一行一条的结构化文本最通用，日志平台直接解析；自由文本排查时靠肉眼，效率天差地别。格式定了就别改，改动会让历史日志变成两套方言，检索也跟着断档。

日志怎么串起一次请求

一次请求要经过网关、限流、调度、模型、后处理多个环节，每段各记一条，靠同一个请求标识串成完整链路。进来的是分段事件，发生的是按标识归并，出去的是一条可见全程的轨迹。

串联之外还要对时：各机器时钟有偏差，时间戳比对前先统一校时，否则先后顺序会错乱。轨迹的价值在定位：慢在网关还是模型、错在限流还是后处理，顺着时间戳一比就现形。你在腾讯元宝、讯飞星火反馈问题时，客服能调出当时的处理记录，靠的就是这套串联。串联的标识要贯穿到用户侧：用户报障时给一个时间点加账号，客服按这两样检索出请求标识，链路就打开了，缺这一环等于白记。

排查时先看哪几行

先看状态异常的那批：错误码分布、超时占比、降级触发次数，圈出问题时段与影响面。再看时段内的新变量：模型版本更新、配置变更、流量尖峰，日志里的版本字段就是为这一步准备的。

最后看个体样本：挑几条失败请求沿链路走一遍，从进网关到出结果逐段对照耗时。三步走完，多数问题能定位到具体环节，剩下的交给对应负责人。排查完把结论记回工单，下次同类问题直接翻旧账，排查速度会越来越快。常见问题有常见位置：首字慢先看排队段，输出中断先看网关段，内容异常先看版本字段，先查高频位置再扩大范围，别一上来就通读全量日志。排查要留证据链：问题时段的日志先归档再处理，防止轮转把关键记录冲掉，归档动作越快越好。

• 自查清单：请求标识全程一致？关键字段含版本号？敏感原文已脱敏另存？留存时长覆盖排查窗口？时钟已统一校对？五条齐了再谈排查。

日志是观察其余机制的窗口：上下文超限的报错是怎么触发的？的预检结果要留痕，一次请求的显存峰值出现在哪？内部门道在这靠资源字段看清，吞吐和延迟为什么互相牵制？过程拆开看要靠耗时数据佐证，保首字还是保整段？两种服务策略的差异也能在日志里对出来。

关于推理日志，问得最多的三个

• 日志会影响响应速度吗？：异步落盘几乎无感，同步写全文才有开销，正式服务都用异步。
• 用户提问原文会被存吗？：按需另存且加访问限制，常规日志只留摘要与长度，模板参数单独记录更方便复现。
• 多久的日志值得留？：覆盖问题回溯与用量对账两个场景，常见留数周到数月，涉及对账的场景留得更长。