特征感知预测框架FeTS：动态门控与稀疏路由实现算力优化

1. 从算力焦虑说起为什么我们需要特征感知预测框架做预测模型的人这两年应该都有一个共同感受数据量在涨、特征维度在涨、模型复杂度在涨唯独算力预算没怎么涨。尤其是大语言模型火了之后GPU 资源被大量挤占很多做结构化数据预测、时序预测、推荐排序的团队能分到的算力反而更紧张了。我身边不少朋友都在吐槽以前跑一个 XGBoost 或者 LightGBM 几分钟出结果现在动不动就要上深度模型训练一次几个小时起步调参周期被拉得特别长。这个矛盾的本质是什么是算力分配和特征价值之间的错配。传统预测框架在处理特征时基本是一视同仁的——所有特征都走同样的计算路径都参与同样的注意力计算或者全连接变换。但实际上一个预测任务里真正起决定作用的往往只是少数几个关键特征。比如做用户流失预测可能最近7天登录次数和近30天消费金额这两个特征的贡献占了80%剩下几十个特征加起来才贡献20%。你花大力气给那几十个边缘特征做复杂变换算力花了不少模型效果提升却很有限。FeTS 这个框架要解决的就是这个问题。它的全称是 Feature-aware Temporal/Transferable Selection核心思想是让算力跟着特征价值走——先快速识别出哪些是关键特征然后把主要的计算资源集中到这些特征上做深度处理边缘特征则用轻量化的方式处理甚至直接降权。这不是简单的特征选择而是一套完整的特征感知机制贯穿数据预处理、模型前向计算、梯度回传整个链路。我最初接触这个思路是在一个工业级时序预测项目上。当时我们有将近200个特征训练一个 Transformer 变体模型单卡 A100 跑一轮要40多分钟。后来尝试引入特征感知的稀疏计算策略把关键特征识别出来之后只对 Top-30 的特征做完整的注意力计算其余特征走轻量 MLP 分支训练时间直接降到12分钟而预测精度只掉了0.3个百分点。这个 trade-off 在工程上是非常划算的。FeTS 就是把这类经验系统化、框架化了。这篇文章我会从设计思路、核心机制、实操落地、问题排查几个维度把这个框架拆开讲清楚。不管你是做推荐系统、风控模型、时序预测还是 NLP 下游任务只要面临算力约束下的特征处理问题这套思路都能直接参考。我会尽量把每个设计决策背后的为什么讲透让你不仅知道怎么用还能根据自己的场景做调整。2. 核心设计思路拆解算力到底该花在哪里2.1 特征价值的二八定律与算力分配逻辑先讲一个我反复验证过的观察在绝大多数预测任务里特征的重要性分布是极度长尾的。头部10%到20%的特征贡献了70%到90%的预测能力剩下的特征更多是起兜底和微调作用。这个规律在结构化数据上特别明显在文本和图像任务上稍微弱一些但依然存在。传统框架的问题在于它假设所有特征需要同等程度的计算。一个标准的 Transformer 层每个 token这里可以理解为每个特征都要和所有其他 token 做注意力计算计算复杂度是 O(n²)。当你有200个特征时注意力矩阵就是200×200其中大量计算是在处理那些本来就不重要的特征对之间的关系。这就像开一个200人的会议讨论决策但其实只有20个人是真正有决策权的剩下180个人只是列席你却让所有人都两两对话一遍效率可想而知。FeTS 的算力分配逻辑是这样的用少量算力做特征价值评估把节省下来的大量算力投入到关键特征的深度计算上。具体来说它会在每个训练批次里先用一个轻量的评估网络通常就是几层 MLP快速给每个特征打一个重要性分数然后根据这个分数做两件事一是决定哪些特征进入重量级计算分支二是决定重量级分支里注意力计算的稀疏模式。这里有个关键设计特征重要性评估不是静态的而是动态的、随训练过程演化的。因为模型在训练初期和后期关注的特征可能完全不同。初期可能更依赖统计类特征后期可能更依赖交互类特征。如果用一个静态的特征重要性排序很容易在训练后期把真正重要的特征给漏掉。FeTS 用的是一个可学习的门控机制每个特征有一个门控权重这个权重参与梯度回传会随着训练自动调整。2.2 为什么是特征感知而不是特征选择很多人第一反应会问这不就是特征选择吗做一次特征重要性分析把不重要的特征删掉不就行了我一开始也这么想但实操下来发现两个问题。第一特征选择是离散的、不可逆的一旦删掉某个特征后续训练中模型就再也看不到它了。但有些特征在特定样本上可能是关键的全局删掉会损失这部分信息。第二特征之间的交互作用很难通过单特征重要性捕捉。A特征单独看重要性不高B特征单独看也不高但A和B的组合可能是强信号。特征选择很容易把这种组合信号给切掉。FeTS 的做法是软性的不删除特征而是动态分配计算资源。不重要的特征依然参与计算但走的是轻量分支计算量可能只有重量分支的十分之一。这样既节省了算力又保留了特征信息还允许模型在需要时临时提升某个特征的计算权重。这个设计在工业场景里特别实用因为线上数据分布会漂移今天不重要的特征明天可能就重要了硬删除的风险太大。2.3 框架整体架构与数据流FeTS 的整体架构可以分成四个模块我用文字描述一下数据流方便你理解各部分的衔接关系。输入层接收原始特征向量先经过一个特征嵌入模块把不同量纲、不同类型的特征统一映射到同一维度空间。这一步和常规做法差不多数值特征做分桶或标准化后线性映射类别特征做 embedding 查表。然后是特征价值评估模块这是 FeTS 的核心。它用一个轻量网络通常是2到3层 MLP参数量控制在总参数的5%以内计算每个特征的动态重要性分数。这个分数会经过 softmax 归一化形成一个概率分布表示当前批次下算力应该按什么比例分配给各特征。接下来是稀疏计算路由模块。根据重要性分数特征被分成两组Top-K 的关键特征进入重量级分支做完整的自注意力计算和深层变换其余特征进入轻量分支只做简单的线性变换或浅层 MLP。K 的取值是超参数通常设为总特征数的15%到30%。最后是特征融合与预测模块把两个分支的输出拼接或加权融合送入最终的预测头。整个过程中特征价值评估模块的梯度会通过路由机制回传到评估网络形成闭环。这个架构的好处是模块化程度高你可以把重量级分支换成任何你喜欢的结构——Transformer、GNN、甚至就是一个更宽的全连接层FeTS 负责的是把算力花在刀刃上这件事具体刀刃怎么磨你可以自己定。3. 核心机制深度解析门控、路由与梯度回传3.1 动态门控机制的工作原理门控机制是 FeTS 实现特征感知的关键。我把它拆成三个步骤来讲。第一步是特征级打分。对于第 i 个特征评估网络输出一个标量分数 s_i。这个分数不是直接用的而是先经过一个温度缩放的 softmaxalpha_i exp(s_i / T) / sum_j(exp(s_j / T))其中 T 是温度系数。T 越大分布越平滑算力分配越均匀T 越小分布越尖锐算力越集中在少数特征上。我在实践中发现T 取0.5到1.0之间比较合适。T 太小会导致训练不稳定因为算力过度集中边缘特征完全得不到更新T 太大就退化成均匀分配失去了 FeTS 的意义。第二步是硬路由与软路由的混合。纯软路由按 alpha_i 加权的问题是计算效率提升不明显因为所有特征还是都要算只是权重不同。纯硬路由只取 Top-K的问题是梯度无法回传到未选中的特征评估网络学不好。FeTS 用的是混合策略前向计算时用硬路由只对 Top-K 特征做重量级计算反向传播时用软路由的梯度让所有特征都能收到梯度信号只是强度不同。第三步是门控权重的归一化与约束。为了防止门控机制退化比如所有 alpha 都趋近于均匀分布或者过度集中到一两个特征FeTS 加了两个约束。一个是对 alpha 分布的熵做正则鼓励适度集中而不是极端集中。另一个是对每个特征的门控权重做滑动平均避免单个批次的噪声导致路由剧烈波动。注意门控温度 T 和 Top-K 的 K 值是两个最敏感的超参数。我的经验是先用较大的 T比如1.0和较大的 K比如30%跑通流程确认模型能正常收敛后再逐步降低 T 和 K 来压缩算力。直接上激进配置很容易训崩。3.2 稀疏计算路由的实现细节路由模块的实现有几个工程上的坑我逐个说。第一个坑是批次内的路由一致性问题。如果每个样本独立做路由同一个特征在样本A里走重量分支在样本B里走轻量分支那实现起来会非常麻烦因为 GPU 上的矩阵运算要求形状一致。FeTS 的做法是批次级路由对一个批次内所有样本用平均特征重要性来做路由决策。这样整个批次的计算路径是统一的实现简单GPU 利用率也高。代价是损失了一些样本级的自适应性但实测下来影响很小。第二个坑是Top-K 操作的不可导问题。argmax 或 topk 操作本身没有梯度如果你直接用评估网络就学不到东西。解决方案是用 straight-through estimator前向用硬路由的结果反向时把梯度直接传给软路由的 alpha 值。这个技巧在量化训练里很常见搬到路由上同样有效。第三个坑是路由抖动。训练初期特征重要性分数波动很大可能导致路由频繁切换模型难以收敛。FeTS 用了一个动量更新策略维护一个路由决策的滑动平均实际路由时用滑动平均的结果而不是当前批次的瞬时结果。动量系数一般取0.9到0.99。3.3 梯度回传路径与训练稳定性FeTS 的梯度回传有三条路径理解这三条路径对调试模型很重要。第一条是主预测损失的回传。预测损失通过融合模块回传到两个分支再回传到特征嵌入和评估网络。这条路径是常规的。第二条是路由决策的梯度。评估网络的输出 alpha 决定了哪些特征进入重量分支这个决策影响最终预测所以预测损失对 alpha 是有梯度的。这条路径让评估网络学会什么样的特征应该被重视。第三条是负载均衡约束的梯度。为了防止算力过度集中FeTS 加了一个辅助损失惩罚 alpha 分布的过度集中。这个损失也回传到评估网络。三条路径的梯度需要做加权平衡。我的经验是主损失权重为1.0路由梯度权重为0.1到0.3负载均衡权重为0.01到0.05。路由梯度权重太小评估网络学不动太大会干扰主任务的优化。负载均衡权重太大会强制算力均匀分配失去 FeTS 的意义。训练稳定性方面我踩过最大的坑是评估网络和主网络的学习率不匹配。评估网络如果学得太快路由决策剧烈变化主网络跟不上学得太慢路由决策滞后算力分配不合理。后来我的做法是给评估网络单独设一个更小的学习率通常是主网络学习率的0.1到0.3倍并且用余弦退火调度让后期路由决策趋于稳定。4. 实操落地从数据准备到模型部署的完整流程4.1 环境准备与依赖配置FeTS 本身是一个框架思路不是某个特定的库所以你可以用 PyTorch 或 TensorFlow 自己实现。我这边以 PyTorch 为例讲一下环境配置。基础依赖就是常规的深度学习环境Python 3.8以上PyTorch 1.12以上CUDA 11.6以上。另外建议装一个 einops 库做张量维度变换比原生 permute 和 reshape 清晰很多。如果要做大规模稀疏计算可以考虑装 torch.sparse但实测下来在特征维度不超过500时稠密计算加掩码的效率反而更高因为稀疏操作的 overhead 不小。硬件方面FeTS 的收益在特征维度越高时越明显。特征数少于50时收益有限可能不值得引入额外的复杂度。特征数在100到500之间是甜点区通常能省30%到50%的算力。特征数超过1000时收益更大但要注意评估网络本身的开销别让评估网络变成新的瓶颈。4.2 特征预处理与嵌入层设计特征预处理这一步FeTS 和常规框架的区别在于要保留特征的独立标识。因为后续要做特征级的路由每个特征必须能单独寻址。所以嵌入层的输出形状是 [batch_size, num_features, embed_dim]而不是常规的 [batch_size, total_embed_dim]。数值特征的处理先做分位数分桶通常20到50个桶然后查 embedding 表。为什么不直接用数值本身因为数值的尺度差异太大直接输入会让评估网络难以判断重要性。分桶之后每个桶有独立的 embedding评估网络更容易学到这个特征的某个取值区间很重要这样的模式。类别特征的处理常规的 embedding 查表但要注意高频类别和低频类别的区分。低频类别出现次数少于100次建议统一映射到一个其他类别否则 embedding 学不好还会干扰评估网络。缺失值处理FeTS 对缺失值比较友好因为缺失本身可以作为一个特征信号。我的做法是给每个特征加一个缺失指示位缺失时 embedding 用一个专门的缺失向量同时指示位设为1。这样评估网络可以学到这个特征缺失时它的重要性如何变化。4.3 评估网络与主网络的联合训练联合训练是 FeTS 落地的核心环节。我给出一个具体的训练流程。初始化阶段评估网络用较小的随机初始化比如标准差0.01主网络用常规初始化。评估网络的初始输出应该接近均匀分布避免一开始就过度集中。预热阶段前1到2个 epoch把温度 T 设得很大比如5.0让算力分配接近均匀主网络先学到一个基本的表示。这个阶段路由基本不起作用相当于常规训练。逐步收紧阶段从第3个 epoch 开始逐步降低 T每个 epoch 降10%到20%直到降到目标值。同时逐步引入负载均衡损失。这个渐进过程能让模型平滑过渡到稀疏计算模式。稳定训练阶段T 和 K 固定后正常训练。这个阶段要监控路由分布的变化如果发现路由剧烈波动说明评估网络学习率可能偏大或者动量系数需要调整。我实测下来整个训练周期比常规训练多20%到30%的时间因为多了评估网络的开销和预热阶段。但训练完成后的推理阶段算力节省是实打实的通常能省40%以上。所以如果你的场景是训练一次、推理很多次FeTS 的收益非常明显。如果是一次性训练、一次性推理收益就没那么大。4.4 推理阶段的算力优化与部署推理阶段是 FeTS 真正发挥价值的地方。训练完成后路由决策基本稳定你可以做进一步的优化。第一个优化是固化路由模式。统计验证集上的平均路由结果把那些在95%以上样本中都进入重量分支的特征标记为核心特征在95%以上样本中都进入轻量分支的标记为边缘特征。推理时核心特征直接走重量分支边缘特征直接走轻量分支只有那些路由不稳定的特征才需要动态评估。这样可以把评估网络的开销降到最低。第二个优化是分支剪枝。轻量分支如果只是简单的线性变换可以直接融合到特征嵌入层里省掉一次单独的前向计算。重量分支如果用的是 Transformer可以考虑用 FlashAttention 之类的优化实现进一步压缩显存和计算时间。第三个优化是批处理策略调整。因为路由是批次级的批次大小会影响路由的稳定性。推理时批次可以设大一些比如256或512让路由决策更稳定同时提高 GPU 利用率。部署方面FeTS 模型可以导出成 ONNX 或 TorchScript常规的推理服务框架都能支持。需要注意的是如果推理时要做动态路由要确保推理框架支持条件分支。如果固化了路由模式那就和普通模型没区别了。5. 常见问题与排查技巧实录5.1 模型不收敛或收敛变慢这是最常见的问题。表现是训练损失下降缓慢或者下降到一定程度就卡住。排查思路按优先级来。先看评估网络的学习率如果设得和主网络一样大大概率是这个问题。把评估网络学习率降到主网络的0.1倍试试。再看温度 T 的初始值如果一开始就设得很小算力过度集中边缘特征得不到更新模型表达能力受限。把初始 T 调到2.0以上跑几个 epoch 再降。最后看负载均衡损失的权重如果太大算力被强制均匀分配FeTS 退化成常规模型但至少应该能收敛。如果连均匀分配都不收敛那问题可能不在 FeTS而在主网络结构或数据本身。我遇到过一次特殊情况评估网络和主网络用了同一个优化器结果评估网络的梯度把主网络的动量给带偏了。后来改成两个独立的优化器问题解决。这个坑比较隐蔽分享出来供参考。5.2 路由分布异常集中或异常均匀路由分布异常集中表现为少数几个特征占据了90%以上的算力其余特征几乎不参与计算。这通常是因为温度 T 太小或者负载均衡损失权重太小。解决方案是调大 T 或调大负载均衡权重。但要注意如果数据本身确实只有少数特征重要那集中是合理的不要强行拉平。路由分布异常均匀表现为所有特征的算力分配差不多FeTS 没有起到稀疏化作用。这通常是因为温度 T 太大或者评估网络的梯度回传被阻断了。检查一下 straight-through estimator 的实现是否正确梯度有没有正常传到评估网络。5.3 训练和推理行为不一致这个问题表现为训练时效果很好推理时效果明显下降。原因通常是训练时用了批次级路由推理时批次大小变了路由决策跟着变了。解决方案有两个。一是推理时保持和训练时相同的批次大小但这在实际部署中往往不现实。二是固化路由模式用训练时统计的平均路由结果推理时不再动态评估。我推荐第二种既稳定又高效。还有一个隐蔽的原因是 BatchNorm 层。如果主网络里用了 BatchNorm训练和推理的统计量不一致也会导致行为差异。FeTS 本身不引入这个问题但如果你在重量分支里用了 BatchNorm要注意这个常规坑。5.4 常见问题速查表问题现象可能原因排查方向解决方案训练损失不下降评估网络学习率过大检查两个网络的学习率配置评估网络学习率设为主网络的0.1到0.3倍训练损失不下降初始温度过低查看训练日志中的路由分布初始T设为2.0以上逐步降低路由过度集中温度过低或均衡损失过小统计路由分布的熵调大T或调大均衡损失权重路由过度均匀温度过高或梯度阻断检查评估网络梯度范数调小T检查STE实现训练推理不一致批次级路由不稳定对比训练和推理的路由分布固化路由模式推理速度没提升评估网络开销过大profile各模块耗时固化路由剪枝轻量分支精度下降明显K值过小对比不同K值的验证精度增大K或提高温度平滑过渡5.5 独家避坑经验分享几个文档里不会写、但实操中很关键的经验。第一个是特征顺序会影响结果。因为路由是批次级的如果特征顺序在预处理时被打乱评估网络需要更长时间才能学到稳定的重要性排序。建议在预处理阶段就固定特征顺序并且把语义相近的特征放在相邻位置这样评估网络更容易捕捉到特征组的重要性。第二个是不要用 FeTS 处理图像特征。图像的空间特征之间有强烈的局部相关性强行做特征级路由会破坏这种结构。FeTS 适合的是特征之间相对独立、重要性差异明显的场景比如结构化数据、多模态特征的后期融合。第三个是监控路由分布的熵。这个指标比损失更能反映 FeTS 是否在工作。熵太高说明退化成均匀分配熵太低说明过度集中。健康的训练过程中熵应该从高逐步降低最后稳定在一个中间值。我通常把熵的变化曲线和损失曲线放在一起看两者应该同步下降然后稳定。第四个是小数据集上慎用。FeTS 的评估网络需要一定量的数据才能学到可靠的特征重要性。如果训练样本少于1万条评估网络很容易过拟合路由决策不可靠。这种情况下建议先用全量特征训练一个基线模型做一次静态特征重要性分析然后手动设定路由而不是让 FeTS 动态学习。6. 不同场景下的适配与扩展思路6.1 时序预测场景的适配时序预测是 FeTS 应用效果比较好的场景之一。时序特征通常包括历史滞后项、滑动窗口统计量、时间编码等特征数量多且重要性差异大。适配要点是在评估网络里加入时间维度的信息。常规 FeTS 的评估网络只看当前批次的特征值但时序任务里特征的重要性可能随时间变化。比如促销期间价格相关特征的重要性会飙升。我的做法是在评估网络的输入里拼接一个时间编码向量让评估网络能感知到当前处于什么时间阶段。另一个要点是多步预测的路由一致性。如果做多步预测每一步都独立路由会导致计算路径频繁切换。建议对整个预测窗口用统一的路由决策或者按预测步长分组相近的步长共享路由。6.2 推荐系统场景的适配推荐系统的特征是典型的高维稀疏特征用户ID、物品ID、各类行为统计动辄几百上千维。FeTS 在这个场景的收益很大但要注意几点。第一是ID类特征的特殊处理。用户ID和物品ID的 embedding 维度通常很高如果进入重量分支计算量会很大。我的做法是把ID类特征单独分组用专门的轻量分支处理不参与主路由。因为ID类特征的重要性更多体现在 embedding 质量上而不是计算深度上。第二是实时性要求。推荐系统的推理延迟要求很严通常几十毫秒。FeTS 的动态路由会引入额外开销建议在推荐场景下直接固化路由模式训练完就把路由定死推理时零开销。6.3 与大语言模型特征处理的结合现在很多任务会用大语言模型做特征提取然后把提取的表示送入下游预测模型。这种场景下FeTS 可以用在下游模型的特征处理上。大语言模型输出的表示通常是高维稠密向量比如768维或1024维。如果直接送入下游模型计算量不小。用 FeTS 的思路可以把这高维表示拆成若干段每段视为一个特征评估各段的重要性只对重要段做深度处理。实测下来在文本分类和语义匹配任务上这种做法能省30%左右的下游计算量精度损失在1个百分点以内。需要注意的是大语言模型的表示各维度之间没有明确的语义对应关系所以路由的可解释性不如结构化特征。但纯从算力优化的角度效果是成立的。6.4 算力评估与资源配置建议最后说一下怎么评估 FeTS 能给你省多少算力以及怎么配置资源。算力节省的粗略估算公式是节省比例 ≈ (1 - K/N) × (1 - 轻量分支开销占比)。其中 N 是总特征数K 是进入重量分支的特征数。比如 N200K40轻量分支开销是重量分支的10%那节省比例 ≈ (1 - 0.2) × (1 - 0.1) ≈ 72%。实际节省会少一些因为还有评估网络的开销通常打个七折也就是50%左右。资源配置方面FeTS 对显存的需求比常规模型略高因为要同时维护两个分支的中间激活。建议显存预留比常规模型多20%。计算方面训练时因为多了评估网络和预热阶段总时间可能增加20%到30%但推理时间能省40%以上。所以 FeTS 最适合的是训练资源相对充裕、推理资源紧张、或者推理频次远高于训练频次的场景。如果你在犹豫要不要上 FeTS我的建议是先用一个小规模实验验证拿你现有的模型统计一下特征重要性分布如果头部20%特征的贡献确实超过70%那 FeTS 大概率能帮到你。如果特征重要性比较均匀那 FeTS 的收益有限不如把精力花在特征工程上。我在实际项目里用 FeTS 最大的体会是它不是一个即插即用的框架而是一套需要根据场景调优的思路。温度、K值、学习率、均衡权重这几个参数需要反复试。但一旦调好算力节省和精度保持的平衡点确实比常规方法好很多。尤其是当你的特征维度超过100、推理 QPS 又比较高的时候这套东西的价值就体现出来了。