企业官网建设流程全解析

1. 预测准了业务方还是不签收：可解释性到底卡在哪

去年年底我参与过一个设备能耗预测的项目，模型上线前的评审会开得很难受。离线指标其实不难看：提前 24 小时的点预测，平均绝对百分比误差压到了 6% 出头，比业务方原来拍脑袋排产的方式好了一大截。但评审席上有人问了一句："下周三你们预测这座机房会多耗 18%，凭什么是下周三？是哪台设备、哪个班次、还是天气？"现场没人答得上来。模型只会吐一个数，不会讲理由。这场评审最后卡了两周，期间我们把注意力权重、特征重要性、残差分析全部重新跑了一遍，才把这件事推进下去。

这个经历让我对可解释预测模型这件事的看法彻底变了。以前我觉得可解释性是发论文用的装饰品，只要指标够好，业务方总归会认；后来才明白，预测模型在真实业务里的每一次输出都会引发一个"为什么"，而回答不了"为什么"的模型，就算误差再低也只是个黑箱算命先生。真正让模型进入决策链的，不是精度，是精度加上可被追问的推理路径。

本文围绕基于时域融合 Transformers 的可解释预测模型展开，讲的是这一类架构（业内通常简称 TFT 族模型）在多步时间序列预测场景下的结构原理、数据组织方式、可解释输出怎么读、训练排错怎么做，以及它在哪些业务形态下真正值得上。目标读者是已经会用 LSTM 或者梯度提升树做时序预测、但被"多变量 + 多步 + 要解释"这三件事同时卡住的中级从业者；如果你是刚接触时序预测的新手，前面几节的类比和踩坑记录也能让你少走不少弯路。

1.1 多步预测的难，难在信息在时间轴上错位

单步预测和多步预测完全是两个难度量级。单步预测里，"今天下午三点的用电量"这种目标，模型可以大量依赖最近几个观测点的惯性，做一个高级版的"明天和今天差不多"就能拿到不错的分数。但一旦要预测未来 24 步甚至 168 步，惯性衰减得很快，模型必须开始依赖别的东西：日历信息（明天是不是周末）、计划信息（明天有没有检修排班）、以及更长时间尺度上的周期规律。

问题在于，这几类信息的时间属性完全不同。日历和排班是"未来确定已知"的，你提前一个月就知道下周三是不是节假日；历史观测是"只有过去才有"的，未来的真实用电量当然拿不到；而设备型号、楼层、气候分区这类信息压根不随时间变化，是"静态"的。普通的序列模型要么把这些东西一股脑拼成一个特征向量塞进去，要么干脆只用手工构造的滞后特征。前者会让模型分不清哪些特征在未来是可信的，后者则把大量长程依赖丢给了人工特征工程。

TFT 这一类架构的核心设计动机就来自这里：它不是"又一个 Transformer 变体"，而是把静态协变量、未来已知输入、仅历史观测输入这三类变量在结构层面做了显式切分，让每一类走在自己的通路上，最后在解码阶段融合。这个"融合"就是标题里"时域融合"的实际含义。

1.2 "时域融合"这个说法的两层含义

这里需要澄清一个容易混淆的点。在中文语境里，"时域融合"经常被理解成"把小时级、天级、周级等不同时间分辨率的数据聚合到一起"，也就是多尺度时间聚合。这是一种理解，在部分工程实现里确实存在。

但在这个标题所指的架构语境下，时域融合更准确的指向是：在同一个预测时刻，把来自不同时间语义的信息源（不变的、未来已知的、历史观测的）融合成一条统一的表征，并且融合过程本身是可追溯的。前者是数据预处理层面的操作，后者是模型结构层面的设计。两者不冲突，很多工程实现会同时做，但如果你在复现时把重点放错了位置，只做了多尺度聚合而没有做三类变量的通路切分，模型的可解释输出会变得非常混乱——因为你根本说不清某个权重到底在解释哪一类信息。

我在第一次复现时就犯过这个错。当时把所有特征拼成一个宽表，静态特征做了 one-hot 之后每个时间步重复一遍，然后直接喂进普通 Transformer。训练能收敛，指标也还行，但一画变量重要性图就崩了：设备型号这种恒定特征在每个时间步都出现，它的累计权重自然最高，可这个结论毫无信息量——它只是在说"不同设备能耗水平不同"，这是常识。真正的结构切分能让静态特征只在变量选择网络里出一次面，权重解读才有意义。

1.3 可解释性在这类模型里是结构副产品，不是事后补丁

很多团队的做法是：先训一个黑箱模型，再用 SHAP、LIME 之类的工具做事后归因。这条路能走通，但对时序模型来说效果往往打折。原因很实在：事后归因工具通常假设样本独立同分布，而时间序列的样本高度自相关，滞后特征之间共线性严重，SHAP 值会在几个高度相关的特征之间随机分配功劳，同一条样本跑两次解释结果可能都不一样，业务方看到这种反复横跳的图，信任度直接归零。

TFT 走的是另一条路：把可解释性做进结构里。变量选择网络在每个时间步输出一组归一化的变量权重，注意力层输出每个预测步对历史各时步的关注分布。这些权重不是训练完再算的，而是前向传播过程中真实参与计算的中间量，模型的实际输出就是这些权重加权求和的结果。这意味着解释和预测是同一套数，不存在"解释和模型不一致"的问题。当然，这种内生可解释性也有它自己的误读风险，后面第 4 节会专门讲。

2. 五个模块拆开看：这套架构在哪些地方做了取舍

把整个模型摊开，核心是五个部件：静态协变量编码器、变量选择网络、门控残差网络、序列到序列的编码解码结构、以及分位数输出头。我在下面逐个拆，重点讲每个部件为什么这么设计，而不是只给公式——公式网上到处都是，但设计动机很少有人讲透，而这恰恰是调参和排错时最需要的东西。

2.1 静态协变量编码器：把"这个实体是谁"压成四个上下文向量

静态特征在这个模型里的地位很特殊。它们不参与时间维度的计算，但需要影响几乎所有的后续环节。处理方式是：把静态特征过一个门控残差网络，得到四个不同用途的上下文向量。

这四个向量各自有明确分工。第一个送给变量选择网络，作用是"根据这个实体的属性，调整它该关注哪些变量"——比如一座位于南方的机房和一座位于北方的机房，空调能耗对气温的敏感度显然不同，静态上下文可以让变量权重随实体自适应。第二个和第三个分别作为 LSTM 编码器的初始隐状态和初始细胞状态，相当于给序列模型一个"先验起点"，避免所有序列都从零状态开始。第四个是静态富化向量，它会被注入到后续每一层的门控跳连接里，让静态信息在深层网络里也不被稀释。

这个设计的实际价值在于：多实体联合训练时不会互相污染。假设你同时预测几百个门店的销量，如果简单地把门店 ID 做 embedding 拼进特征，模型需要自己学会"不同门店要用不同模式"，这个学习过程很慢。显式地把静态信息变成 LSTM 的初始状态，等于直接告诉模型"你现在的起点不一样"，收敛速度的差异在实测中相当明显。我做过一个对比，同样数据量下，带静态编码器的版本在第 8 个 epoch 左右验证损失就进入平台期，不带的需要 20 个 epoch 以上，而且最终损失更高。

2.2 变量选择网络：每个时间步先做一次特征筛选

变量选择网络是我认为这套架构里最实用的部分。它的做法是：在每一个时间步，先把该时间步的输入特征和静态上下文拼起来，过一层门控残差网络，然后接一个 softmax，得到这一时间步上所有变量的归一化权重，再用这组权重对特征做加权求和，压成一个向量。

这个机制解决了一个真实痛点：不同时间步该关注的特征本来就不一样。还是拿能耗举例，工作日的白天，气温对能耗的影响远大于其他因素；到了深夜，气温的影响退居其次，班次排产的影响上升。传统的全局特征重要性只能给出一张静态的排序表，而变量选择网络给出的是"每个时间步一张表"，这就是它能画出热力图的原因。

需要注意一个实现细节：变量选择是分组进行的。静态变量、未来已知变量、历史观测变量各走各的选择网络，权重在组内归一化。这意味着组间的权重不可直接比较——你不能说"气温的权重是 0.3，设备型号的权重是 0.5，所以设备型号更重要"，因为 0.3 和 0.5 分别是在各自组内 softmax 出来的，量纲不同。这个坑我在第一次给业务方做汇报时就踩了，图上两个不同颜色的权重条并排放，对方直接问"为什么这个比那个大"，我当场解释不清。

2.3 门控残差网络：比普通残差多了什么

门控残差网络（GRN）在这套架构里出现了十几次，是名副其实的基础砖块。它的结构是在普通残差的基础上做了两处改动：一是引入了门控线性单元，二是引入了外部上下文注入。

普通残差是输出 = 输入 + 变换(输入)，门控残差的思路是输出 = LayerNorm(输入 + 门控(主分支 + 上下文分支))。门控部分用 sigmoid 做闸门、用另一条线性通路做内容，两者逐元素相乘。这个改动看起来只是加了几个矩阵乘法，但它带来两个实际好处。

第一个好处是信息可以整层跳过。sigmoid 输出接近 0 的时候，这一层的变换结果被完全抑制，信息直接通过残差通路流走。深层网络里这个特性很重要，它让模型在"这一层没必要用"的时候有办法表达这个意思。第二个好处是上下文可以逐层注入而不需要拼接。静态富化向量在每一层都通过上下文分支参与计算，避免了把静态特征拼到每个时间步输入里那种粗暴做法。

我在小样本场景下做过对照实验：把 GRN 全部换成普通残差加 ReLU，参数量反而略少，但训练损失震荡明显加剧，验证集上出现过两次明显的性能回退。换成 GRN 之后曲线平滑很多。这个差异在样本量少于 5 万条窗口时尤其明显，样本量超过 50 万之后两种结构的差距会收窄。

2.4 编码器-解码器与因果注意力的分工

序列处理部分采用了典型的编码器-解码器结构，但分工很明确：编码器只处理历史区间的观测输入，解码器只处理预测区间的未来已知输入。注意，解码器看到的不是"未来的观测值"，而是"未来的已知协变量"——比如明天的日历信息、已经确定的排班计划。历史观测和未来已知这两条通路在结构上是隔离的，这个隔离非常关键，后面第 3 节会讲它如何避免一类隐蔽的数据泄漏。

两条通路的输出会在每个时间步拼接，然后送入注意力层。这里的注意力是带掩码的因果注意力：预测第 t 步时，只能看到第 t 步及之前的位置，不能看后面的。这个掩码必须手动加，忘了加的话训练损失会好看得不正常，上线后直接崩。

实际部署时还有一个常被忽略的点：解码器长度必须一次性对齐预测步长。如果你预测 24 步，解码器的输入就应该是 24 个时间步的未来协变量。有些实现为了省事，只喂 1 步然后递归预测，这在 TFT 里是不合适的，因为注意力机制在递归模式下每一步都要重跑一遍全序列，成本高且误差会累积。直接多步输出是这个架构的先天优势，别浪费。

2.5 分位数输出头：点预测之外的区间价值

输出层是一层线性映射，形状是分位数个数 × 预测步长。也就是说，如果你设了 7 个分位数、预测 24 步，输出就是 168 个数。损失函数用分位数损失（也叫弹球损失），它对每个分位数单独计算：

这个设计比点预测实用得多。业务方嘴上说要"一个准数"，实际决策时用的永远是区间：排产要用中位数，备货要用上界，成本核算要用下界。一次性把整条分位数曲线给出来，比训练三个模型分别预测均值、上界、下界要经济得多，而且分位数之间天然满足单调性约束（在同一时刻，0.9 分位数的预测值应该不低于 0.5 分位数），这一点在训练充分时能自动保证，但如果训练不足或者分位数设置过密，是会出现交叉的，需要单独检查。

提示：分位数交叉是这类模型最常见的输出异常。上线前务必写一段校验代码，逐时刻检查预测值是否随分位数单调不减，出现交叉的样本比例超过 1% 就要回看训练配置，通常是分位数间隔太窄（比如 0.48、0.5、0.52 这种）导致的，改成 0.1 / 0.5 / 0.9 这样的宽间隔会好很多。

3. 把原始数据切成三类变量：最容易出错的一步

模型结构再精巧，数据切错了全是白搭。我见过不止一个团队在这里翻车，包括我自己。这一节讲的是数据组织，但重点不是"怎么做"，而是"哪里会错"。

3.1 三类变量的判定标准：问一句"预测时刻我知道吗"

判定一个特征属于哪一类，只需要问一个问题：在做出预测的那个时刻，这个特征在预测区间内的每一个时间点，我是否已经确切知道它的值？

知道，且不随时间变化——静态变量。设备型号、门店面积、气候分区、楼层朝向都属于这一类。

知道，且随时间变化——未来已知变量。节假日标记、星期几、促销排期、已确定的检修计划、已签订单量都属于这一类。这里要特别小心"已签订单量"这种特征：它在预测时刻对历史区间是确定的，但对预测区间是否确定，取决于业务上有没有提前锁定。有些业务里订单是当天才产生的，那它就不是未来已知变量，硬塞进去就是泄漏。

不知道——仅历史观测变量。真实的目标值、实时传感器读数、当天的实际客流，都属于这一类，只能作为编码器的输入。

这个判定看起来简单，实际操作中最容易出问题的是"伪未来已知"特征。举个例子：很多能耗数据集里有一个"当日总能耗"字段，看起来像是可以提前拿到的统计数据，实际上它是当天结束才汇总的。如果你把它当成未来已知变量喂进解码器，模型在训练时会获得完美的信息，损失曲线漂亮得不像话，上线后这个字段拿不到真实值，只能填昨天的数，性能断崖式下跌。我在一个项目里见过这种事故，离线 MASE 0.42，上线第一周直接飙到 1.8，排查了三天才发现是这个问题。

3.2 时间索引对齐：一个步长的错位毁掉整轮训练

时序模型最容易出现的静默错误是窗口错位。构造训练样本时，输入窗口和输出窗口必须严格对齐到时间索引上，中间不能重叠也不能有间隙。

举个具体的：如果你用过去 168 小时预测未来 24 小时，输入窗口应该是[t-168, t-1]，输出窗口是[t, t+23]。如果代码里索引算错一位，变成输入[t-167, t]，输出[t, t+23]，那么目标值 t 就出现在了输入里，模型会立刻学会"抄答案"，训练损失迅速趋近于零，验证损失也很低——因为验证集用了同样的错误构造方式。等你上线，输入里没有答案了，模型直接失效。

这种错误很难通过看损失曲线发现，因为训练和验证都"正常"。唯一的防御手段是构造完数据集后手动抽查几条样本，把时间戳打印出来，肉眼确认输入和输出没有重叠。这一步花五分钟，能省掉三天排查。

3.3 归一化的泄漏陷阱与统计量的保存时机

标准化看起来是最无脑的一步，实际却是泄漏的高发区。常见的错误做法是在全量数据上算均值和标准差，然后切分训练集和验证集。这样一来，验证集的统计信息已经渗进了训练过程，离线指标会系统性偏乐观。

正确做法是：只用训练集算统计量，然后把这组统计量序列化保存，验证集、测试集、以及上线后的推理全部复用同一组数值。这件事在离线实验里容易被忽略，因为影响不大；但在生产环境里，如果你每次推理都重新算一遍统计量，模型的输出会随输入批次的内容漂移，同一时刻的两次预测可能给出不同结果，业务方一定会发现。

注意：目标变量和特征变量要分开处理。特征用 z-score 标准化问题不大，但如果你的目标变量里有大量零值或者长尾分布，直接 z-score 会让分位数损失的计算变得不友好。经验做法是对目标做一次对数变换或者幂变换之后再标准化，预测结果再逆变换回来。逆变换时要注意分位数不能简单取指数，因为指数变换对分位数是保序的，可以直接变换，但如果你用的是更复杂的变换，需要单独验证保序性。

4. 可解释输出怎么读：权重、注意力与三种典型误读

模型训完，接下来才是真正有技术含量的部分：把中间权重读成业务能听懂的话。这部分我花的时间比调参还多。

4.1 变量选择权重的两个观察角度

变量选择网络的输出是一个三维张量：样本 × 时间步 × 变量。直接画图是没法看的，通常从两个角度切。

第一个角度是按时间平均，得到一条变量重要性的排序。这个视角回答"整体上哪些变量在起作用"，适合做初步筛特征。但它的信息量有限，因为平均会掩盖掉时间上的波动。

第二个角度是保留时间维度画热力图，横轴是时间步，纵轴是变量，颜色是权重。这个视角才能真正体现价值。我印象最深的一次，是给一个零售场景做预测，热力图显示"促销标记"这个变量在周末的权重是工作日的三倍多，但在某些特定的连续促销期，它的权重反而下降，同时"历史同期销量"的权重上升。业务方看到这个图之后自己就解释了：连续促销期间消费者已经形成预期，促销本身的边际刺激作用减弱，大家更多参考去年同期的表现。这个洞察不是我们从数据里"发现"的，是模型把它显式化了，业务方一看就认。

需要注意的是，热力图的颜色刻度要统一。不同样本之间如果用各自的归一化，图看起来都差不多，会严重误导判断。统一刻度之后你会发现，有些样本的所有变量权重都很平均（说明模型这个时刻确实没找到强信号），有些样本则高度集中在一两个变量上（说明信号明确），这个"权重集中度"本身就是个有用的诊断指标。

4.2 注意力图上的两类模式与一个反例

注意力权重反映的是"预测某个未来时刻时，模型回头看了历史哪些时刻"。业界常用的分析方法是把多个样本的注意力权重取平均，然后观察分布形态，通常能识别出两类模式。

一类是近因偏好：权重集中在最近的若干时步。说明模型主要靠近期状态外推，这在平稳序列上是合理的，但如果你的业务明确存在强周期，出现这种模式就要警惕，可能意味着周期信号没被学到。

另一类是周期定位：权重在固定的滞后位置上出现峰值，比如在 lag 24、lag 168 附近集中。这说明模型捕捉到了日周期和周周期，是很健康的信号。

但这里有个反例必须说清楚：注意力权重高不等于因果关系。注意力只是信息路由的一种方式，它告诉你"模型从这里取了信息"，不告诉你"这个信息导致了结果"。有一条业务线曾经拿着注意力图跟我们说，模型高度关注三周前的某次异常事件，是不是说明那次事件对现在还有影响？我们查了之后发现，那次事件之后紧接着有一批补货动作，模型真正学到的是补货的节奏，三周前那个时点只是因为这个节奏恰好对齐才被关注。如果按字面理解去解释，结论就完全跑偏了。

4.3 三种典型误读与对应的验证手段

第三种误读特别常见。静态变量的权重在这个架构里的语义是"这个实体的属性在多大程度上调节了它对动态变量的敏感度"，而不是"这个属性直接决定了预测值"。如果你直接把它和动态变量权重放在一张图上排名，结论必然是错的。

5. 训练过程的调参与排错实录

聊完结构和解读，说点更实操的。这部分内容我在文档里几乎没见过，都是从失败的训练里攒出来的。

5.1 分位数设置与损失权重

分位数的数量不是越多越好。设 3 个（0.1 / 0.5 / 0.9）适合快速验证，设 7 个（0.02 / 0.1 / 0.25 / 0.5 / 0.75 / 0.9 / 0.98）适合正式生产。设到 11 个以上，边际收益迅速衰减，训练时间却线性增长，而且分位数交叉的概率明显上升。

如果业务上对某一侧区间特别敏感（比如备货场景更关心上界），可以给对应分位数更大的损失权重。做法是在分位数损失外面乘一个权重向量。但要控制幅度，权重比超过 1:3 之后，中间分位数的预测质量会明显退化，中位数开始向上界偏移。

5.2 一组可以直接抄的起步配置

这几个数不是拍脑袋来的。隐藏层维度跟样本量的关系大致是：参数量控制在样本量的百分之一到千分之一之间比较安全，超过这个比例过拟合会非常快。梯度裁剪阈值在论文里给的是 0.1 到 1.0 之间，实测中小数据用小阈值更合适，因为小批量下梯度方差大，裁剪太松基本没作用。

学习率调度用按验证损失衰减的方式，patience 设 5，衰减系数 0.5，最少学习率 1e-5。这套配置在多个数据集上都跑得通，可以作为默认起点。

5.3 一条完整的不收敛排查链路

说一个我实际遇到过的案例。某次训练，损失在前 3 个 epoch 快速下降，然后开始剧烈震荡，验证损失来回跳，最高点和最低点差了三倍多。顺着下面这条链路查下来，最后定位到两个问题叠加。

第一步，检查输入尺度。打印每个特征在训练集上的均值和方差，发现有一个特征的方差比其他特征大四个数量级。这类特征在标准化之后看着正常，但如果你的标准化代码漏掉了这一列（比如类别特征 one-hot 之后忘了标记为已处理），它就会以原始尺度进网络。

第二步，检查梯度范数。在每个 batch 记录梯度范数，画出来看。正常情况下梯度范数应该缓慢下降，如果出现周期性的尖峰，说明某些批次的数据分布异常。顺着查，发现是某个批次的窗口里包含了疫情期的极端值，那一段的能耗只有正常水平的 5%。处理方式是在训练集里对极端值做截尾，或者给这些样本降权。

第三步，检查静态上下文的初始状态。这个比较隐蔽。如果你用的静态特征里有取值非常稀疏的类别（比如某个类别只占 0.1% 的样本），经过静态编码器之后，这几个样本的 LSTM 初始状态会落在分布边缘，导致它们的损失远高于平均水平。解决办法是给稀疏类别做合并，或者在静态编码之后加一层 LayerNorm。

第四步，检查分位数损失的计算。这一步最容易被跳过。分位数损失里有个max(α·误差, (α-1)·误差)的结构，如果实现时符号搞反了，损失在数值上看起来还是会下降，但学的其实是最小化而不是分位数回归，训练会时不时发散一下。建议直接拿一个小规模的合成数据跑一遍，验证预测出来的 0.9 分位数确实在整个分布的上方十分之一处，而不是别的位置。

顺着这四步查下来，那次的问题定位在第一步和第三步的叠加：一个未标准化的特征加上稀疏静态类别导致部分样本梯度异常。修复之后，损失曲线平滑下来，验证指标提升了大概 12%。

5.4 评估指标：别只盯着平均绝对百分比误差

百分比误差类指标在时序场景里有个硬伤：目标值接近零时它会爆炸。能耗数据凌晨时段可能接近待机功耗，销量数据有大量零值，这些位置上百分比误差会给出几百甚至几千的数值，把整体指标拉得毫无参考价值。

我一般同时看这几个：平均绝对误差（绝对值，业务方听得懂）、对称平均绝对百分比误差（对零值相对友好）、平均绝对标度误差（用训练集的朴素预测误差做分母，跨数据集可比）、以及分位数损失本身。区间预测还要额外看两个：区间覆盖率（真实值落在预测区间内的比例，理论上应该接近设定的分位数区间宽度）和区间平均宽度（越窄越好，但要和覆盖率一起看）。

区间覆盖率这个指标特别值得推荐给业务方。它有个非常直观的解释："我们说 90% 置信区间，实际有 87% 的真实值落在里面"——这种话业务方能听懂，也能自己判断能不能接受。相比之下，解释分位数损失是什么要花十分钟。

6. 落地形态与选型：什么时候该上，什么时候别浪费

6.1 三个适配度高的典型场景

多实体的批量预测是这套架构最舒服的场景。几百上千个实体，每个实体有自己的静态属性，共享一套动态特征，联合训练比给每个实体单独建模效果好得多，静态编码器的作用能充分发挥。典型形态是连锁门店的日销量预测、多站点的气象相关负荷预测。

存在明确未来协变量的场景也很适合。如果你的业务里有大量"提前确定"的信息——排班表、促销日历、已签订单、计划检修——这些信息在传统模型里很难用，因为大部分时序模型只接受历史序列。TFT 的解码器通路天生就是为这类信息设计的。

需要对预测结果做归因的场景是第三个。风控、能耗审计、产能规划这类业务，光给数值不够，必须能说出驱动因素。这类场景下内生可解释性的价值远高于事后归因。

6.2 与常见方案的横向对比

这张表里最需要注意的是最后一列。这套架构的参数量比树模型大一个量级以上，样本量少于一万条窗口时，树模型加滞后特征往往是更务实的选择，指标不会差，训练成本低一个数量级。我一般建议的门槛是：实体数量超过 50 个、历史长度超过两年、且确实存在未来协变量，才值得上这套结构。三个条件缺一个，先试试更轻的方案。

6.3 工程化时的两个成本项

第一个是显存。多步输出加上多头注意力，序列长度 168、预测步长 24、批大小 128 的配置下，单卡显存占用在 4-8 GB 区间，具体取决于隐藏层维度。如果预测步长拉到 336 以上，序列长度会显著推高注意力层的显存，这时候要么减小批大小，要么把历史窗口做下采样（比如从小时级降到 2 小时级）。

第二个是推理延迟。单条样本的前向耗时通常在几十毫秒量级，批量推理时这个数字会被摊薄，但如果业务要求实时响应（比如每次请求都要跑一次），需要提前做模型量化和算子融合。可解释输出的额外开销也要算进去——变量权重和注意力权重如果每次都全量保存，存储成本会比预测结果本身高两个数量级，实践中只对抽查样本或者异常样本保存完整权重，其余只存聚合统计量就够了。

还有一个部署细节值得单独提一句：要把训练期的标准化统计量和模型权重一起打包。我见过不止一次因为统计量没跟着走，导致线上推理的输入分布和训练时完全错位，模型输出整体偏移，而且偏移是渐变的，监控告警很久才发现。稳妥的做法是把统计量直接嵌进推理服务的初始化逻辑里，让它和权重文件绑定在一起，从物理上杜绝版本错配。

最后分享一个小经验。这类模型上线后，业务方的第一个问题往往不是"准不准"，而是"它凭什么这么说"。与其等他们问，不如在交付时主动给一份"解释说明书"：告诉他们变量权重的颜色代表什么、注意力图的峰值意味着什么、哪些解读是合理的、哪些是过度推断。这份文档花不了半天时间，但能省掉后面无数轮的拉扯。我在第一个项目上就是因为没做这件事，后面被迫用两周时间反复解释同一张图，那种体验真的不想再来一次。