做模型推理优化这几年我越来越意识到一个尴尬的事实模型规模翻着倍涨算力预算却永远是紧巴巴的。训练阶段大家都舍得花钱一到推理部署又要求省显存、降延迟、控成本。于是剪枝、量化、蒸馏轮番上阵但很多方法都在做同一件事——把模型变小。可我后来慢慢觉得真正该优化的不只是模型的大小而是计算资源的分配方式。算力应该花在刀刃上也就是花在对当前预测真正有用的关键特征上。FeTSFeature-aware Targeting Strategy特征感知预测框架就是沿着这个思路做的不改造主干网络而是先判断哪些特征值得享受高算力哪些特征只需要低算力再把预算集中到前者。这个框架解决的是典型的“算力约束下的高性能推理”问题。大模型在推理时如果对所有特征一视同仁地跑完整网络大量算力会被无关紧要的噪声特征白白吃掉但如果你粗暴地砍掉一部分计算又很容易伤到决定输出的关键信息。FeTS的思路是“先感知再分配”用一个轻量预测器估算特征的重要性再动态调度不同精度的计算分支让真正的关键特征拿到更多计算资源普通特征走轻量路径。对于做算法落地、推理优化、边缘部署或者在类似 autodl 这种按小时租GPU资源来跑实验的团队这个方向都非常值得试一试。1. 为什么要把算力集中在关键特征上1.1 算力约束下的真实困境先说一个最常见的场景。你接手一个线上推荐模型样本特征几百维用户行为序列几百毫秒模型本身是Transformer和MLP的混合结构。部署时显卡功耗有限、延迟要求又高你只能砍到某个FLOPs上限。于是你开始做特征筛选、做剪枝、做量化但很快发现剪枝剪到一定程度头部流量指标掉了量化到int8某些用户群体预测偏差变大。原因并不复杂。模型里的特征并不是等价的。同一个样本里有些特征对最终预测起决定性作用比如用户刚刚点击的商品ID、当前场景的时间窗有些特征几乎是背景噪声比如长期不动的统计量、大量填充的缺省值。传统优化手段对所有特征使用同一个计算策略要么“全都算”要么“全都不算”这本身就是一种资源错配。你真正需要的不是一味压缩而是让计算预算向价值高的特征倾斜。这也是FeTS出现的动机。它把问题重新定义为“算力配置问题”给定一个固定算力预算如何选择一组特征优先计算才能让模型预测损失下降最多。你可以把它理解成一种“计算层面的注意力机制”——注意力机制决定信息融合时看重哪些tokenFeTS则决定计算资源在特征维度上怎么花。1.2 关键特征怎么定义才靠谱提到“关键特征”不能只凭直觉说“重要”就完了得有一个可优化的数学定义。我在实践里一般从三个角度衡量一个特征对预测的贡献第一损失变化量。把某个特征遮住或者用噪声替换看模型损失变化多少。变化越大说明这个特征对当前预测越关键。这是最朴素但也最稳定的定义。第二预测不确定性下降量。对带概率输出的模型比如分类、点击率预估某个特征能显著降低预测概率的熵它就是高价值特征。这比只看损失更符合“信息量”的直觉。第三梯度信号强度。在反向传播时某个特征对应输入的梯度绝对值大小。梯度大说明预测结果对这个特征敏感也应当视为关键。这三个定义各有侧重但有个共同问题真正算一遍代价太高。你不能在每次推理时都去遮挡特征或者算梯度那还不如老老实实跑完整模型。所以FeTS采取的办法是训练一个“特征重要性预测器”用轻量网络快速估算每个特征的关键程度然后把算力调度建立在预测结果上。1.3 计算图不应该是均质的很多优化方法把整个模型当作一个均匀的、不可拆分的计算整体这是我认为最值得改变的假设。模型推理过程天然是不均质的输入特征里有一部分高度敏感一部分无关紧要网络层里有一部分承担核心语义提取一部分只是做平滑和补全。我经常用一个类比人在看一幅图片时眼睛并不是对全图均匀扫描的而是通过扫视和注视把视觉资源集中到少数几个关键区域。目标检测领域早就发现模型的特征图也只有少数通道和空间位置是活跃的。FeTS正是把这个现象显式地建模出来用一个“控制器”找到当前输入的关键特征然后引导计算模块给这些特征分配更多资源。这样一来整个计算图就变成了一条“动态高速公路”关键特征走重计算主路普通特征走轻计算辅路。从外部看你仍然在使用同一个模型但实际上每一次推理都在根据输入自适应地调整计算路径。这个做法的根本收益是在相同算力预算下模型可以把更多能力用在真正影响输出的特征上而不是浪费在无关细节。2. FeTS框架的整体架构与核心模块2.1 工作流先预测特征的重要性再决定算力花在哪FeTS整体可以拆成五个环节轻量特征编码、重要性预测、算力分配决策、动态计算分支、输出融合与校准。实际推理路径是这样的输入样本先经过一个非常浅的编码器比如一层线性层或者一个小的MLP得到一个紧凑的表征。这个表征不追求完整表达只负责给重要性预测器提供足够信息。预测器输出一个长度等于特征组数量的分数向量每个分数代表对应特征组“值得投入多少计算”。然后调度模块根据分数排序结合当前算力预算把特征划分成高优先级和低优先级两组。高优先级特征送入完整的高精度计算分支低优先级特征送入轻量分支或者干脆跳过部分计算。最后把所有分支的输出通过一个轻量的融合层合并再经过校准层输出最终预测。这里有一个关键点前两个环节的算力开销必须足够小。否则你为了判断哪些特征重要先花了一大笔计算那就得不偿失。我一般把重要性预测器控制在总FLOPs的5%以内这样剩下的95%预算仍然能分配到主计算上。实际工程里它只需要读特征统计量和浅层embedding不需要跑完整主干。2.2 特征重要性预测器的设计与训练重要性预测器可以是任何轻量网络但我推荐先用MLP或单层Transformer而不是上来就上大模型。它的输入不是原始特征而是经过编码的紧凑向量输出则是一个重要性分数。为了让它学得准训练损失不能只用“预测分数和真实重要性的MSE”还要考虑后续调度带来的损失变化。具体训练时我会先跑一个预训练好的完整模型对一批样本做推理记录每个特征组对预测的影响程度。这个“影响程度”就是监督信号。然后用这个信号去训练重要性预测器。等预测器收敛得差不多再把整个FeTS串起来做端到端训练让重要性预测器和下游计算分支联合优化。一个容易踩的坑是重要性预测器的训练分布和推理分布不一致。训练时你用完整模型的特征来计算标签推理时重要性的计算依赖于轻量编码器两者会有偏差。解决方法是引入平滑标签和置信度惩罚让预测器不要输出过于极端的分数。这个细节在后面“问题排查”部分我会再展开。2.3 算力分配执行动态路由、深度选择和混合精度有了重要性分数接下来怎么分配算力FeTS支持三种粒度的调度策略你可以根据实际场景选择第一种是特征路由。把特征划分成若干个特征组每个组可以选择走完整主干网络还是走轻量旁路。这种策略简单直接适合特征维度高、特征之间相对独立的场景比如推荐系统里的用户特征和物品特征。第二种是深度选择。所有特征都进入主干网络但重要特征计算到更深的层非重要特征在网络中间某层就输出了。这本质上是early exit的变体只不过在特征维度上动态变化而不是在样本维度上。第三种是精度选择。重要特征对应的计算路径使用fp16或fp32非重要特征使用int8甚至混合使用。比如矩阵乘法内部按块或者按列指定不同精度这样能在不损失关键信息的前提下明显提速。这里的策略和int8/fp16/fp32/fp64的区别直接相关fp32精度高但算力开销大int8吞吐高但动态范围小FeTS通过特征感知来自动规避int8对敏感特征带来的精度损失。实际实现中这三种策略可以叠加。我建议优先尝试“特征路由精度选择”的组合因为深度选择在动态batch里会带来同步开销工程实现最麻烦。等到前面的策略稳定了再考虑更激进的深度选择。调度策略实现难度算力节省精度风险适用场景特征路由低中低推荐、搜索、特征离散度高的任务深度选择中高中输入长度较一致、硬件同步成本低的任务精度选择低高中对延迟和吞吐有强要求的在线推理三者叠加高很高中算力紧张且特征差异大的复杂系统2.4 输出融合与置信度校准动态计算分支最大的问题是不同特征走不同路径输出空间可能存在不一致。比如重计算分支自信地预测“点击概率0.8”轻量分支预测“0.6”直接平均显然不合理。FeTS在最后接了一个可学习的融合层它会根据重要性分数给不同分支的输出加权再做归一化。这个融合层还要负责置信度校准。因为轻量分支天然会有更高的预测不确定性如果不校准最终输出的概率分布会偏高或偏低直接影响业务决策。我的做法是在训练时给融合层加一个温度缩放参数同时用验证集做事后校准确保最终输出的置信度和真实准确率一致。很多团队忽略这一步结果离线指标不错上线后排序却失衡了。3. 实操落地训练、评测与部署的完整路径3.1 两阶段训练流程FeTS的训练不能一步到位我把它分成两个阶段。第一阶段是“教师标注”。选一个性能好、计算完整的模型作为教师模型在训练集上逐特征组计算重要性标签。这一阶段不更新教师模型只把预测和对应的重要性标签存下来。如果你的数据集很大可以只对代表性子集做标注不必全量跑完。第二阶段是“联合训练”。把FeTS整体端到端跑起来用任务损失加上算力正则项共同优化。这里的算力正则项非常重要它用来抑制模型“故意把重要性分数都打得很高”的偷懒行为。因为如果所有特征都被判定为重要FeTS就退化成原始模型没有任何算力节省。联合训练的伪代码大概长这样for x, y in dataloader: feat light_encoder(x) # 轻量编码 score importance_predictor(feat) # 重要性预测 mask build_mask(score, budget) # 依据预算生成计算掩码 out dynamic_forward(x, mask) # 调度不同分支计算 loss_task criterion(out, y) flops compute_flops(mask) # 当前batch的估算FLOPs loss loss_task lambda * max(0, flops - budget) # 算力约束 loss.backward()这个流程里lambda的取值很关键。我一般从0.01开始调如果模型几乎不触发算力节省就调大如果精度降得明显就调小。最终目标是让系统在略低于预算的情况下保留尽可能多的有效计算。3.2 算力预算与阈值设定方法算力预算怎么定不能拍脑袋。我的建议是先测出原始模型的FLOPs和延迟然后根据业务要求设定一个压缩比。比如原始模型单样本推理1000MFLOPS要求降低30%那预算就是700MFLOPS。有了预算之后FeTS的核心调度逻辑其实是一个在线贪心问题按重要性分数从高到低逐个把特征组分配为“高算力”直到算力预算用完。如果分数最高的特征组都用完了还有剩余预算就按顺序开放次高特征组的深度或精度。这个贪心策略在大部分场景下足够好不需要用复杂的最优化求解器。实际操作中另一个重要指标是“算力集中度”。我定义它为高算力特征组的算力占总算力的比例除以这些特征组在重要性分数上的占比。如果集中度大于1说明算力确实花在了更重要的特征上。这个指标用来监控调度是否真的“按重要性分配”比只看最终FLOPs更有解释性。如果集中度小于1说明调度策略失效了需要检查重要性预测器或者预算分配逻辑。3.3 评估指标体系别只用FLOPs要看有效FLOPs做推理优化的同学有个习惯喜欢拿FLOPs说事。但FeTS这类动态框架有个特殊性FLOPs本身也是动态的不同样本消耗不同算力光看平均FLOPs会掩盖很多问题。我建议建立一套四层的评估指标第一层是精度指标比如AUC、F1、准确率这是最底线。第二层是算力效率指标固定预算下看有效FLOPs也就是“单位FLOPs带来的精度提升”。第三层是资源稳定性指标看P50和P95延迟。动态计算最怕某些样本突然触发大量高算力分支导致P95延迟飙升所以必须监控延迟分布。第四层是重要性的命中率随机抽样一些样本人工检查高算力特征组的top特征是否和直觉一致。很多人会忽略第四层但我觉得它最有价值。它不仅能验证框架是否真的学到了关键特征还能帮你发现潜在的数据泄漏。比如重要性预测器如果总是把某个ID类特征排到最前可能不是因为它重要而是因为训练数据里它和标签有偶然相关性。3.4 工程实现细节mask、量化与批量一致性工程落地时动态调度最容易和现有推理框架打架。PyTorch的eager模式还好可以在forward函数里加mask但一旦你想上TensorRT、ONNX Runtime或者图编译器动态分支会变得非常难处理。第一个实用技巧是批量一致性掩码。不要在batch内让每个样本各自选不同的特征路径那会造成大量padding和kernel lauch开销。更好的做法是在一个batch内根据重要性分数排序统一选取前K个特征组作为高算力路径。这样整个batch走同一条分支只是不同样本的mask可能略有差异但仍能合并成一个大矩阵运算。第二个技巧是量化感知的mask。如果你要上int8不要直接对浮点模型套PTQ再期望FeTS的动态调度依然准确。推荐的做法是先训练一个带伪量化fake quantization的FeTS模型让重要性预测器知道哪些路径是低精度路径从而在训练时就可能倾向于保护敏感特征。这样部署后的精度不会断崖式下跌。第三个技巧是预算控制不要写在Python里。线上推理时如果用Python每隔几个batch算一次FLOPs再决定mask开销很大。正确做法是把重要性预测器和调度逻辑一起编译进图里或者在serving框架层用一个C实现的前置模块完成。我在实际项目中曾把调度逻辑改成查表根据重要性分位数直接映射到预设的mask模板把线上P95延迟降了接近一半。4. 我在实践里踩过的坑与排查方法4.1 特征重要性预测器训练不稳定这个问题我遇到不止一次。表现是离线训练时重要性预测器的loss一直在降但端到端联合训练时task loss震荡得很厉害有时候甚至发散。根因通常是监督信号质量太差。教师模型给的重要性标签本身带有噪声尤其对边界样本特征影响程度可能很小且不稳定。预测器学到的是噪声而不是真实信号。解决方法有几个一是给标签做温度平滑避免出现0和1那种极端值二是增加训练样本的多样性不要只挑高置信度样本三是在端到端训练初期冻结重要性预测器的参数让下游分支先适应它等训练稳定后再一起解冻。4.2 动态路由导致GPU利用率断崖动态计算框架很容易把GPU利用率拉低这不是玩笑。因为如果在一个batch里很多样本走了轻量分支而少数样本走了重计算分支GPU在执行重计算分支时矩阵规模可能很小无法打满整体吞吐反而下降。我在早期版本里遇到过FLOPs指标明明降了20%但线上吞吐反而掉了8%非常反直觉。解决思路是“分组执行”。不要让轻量和重计算分支在同一个kernel里交错执行而是先做一次特征重要性统计把所有样本分到“重计算组”和“轻计算组”再分别调用不同的kernel。这样每组内的矩阵运算依然是规整的大矩阵GPU利用率能维持住。代价是会增加一点延迟但对吞吐型业务影响不大。4.3 高频切换特征导致缓存失效FeTS如果按样本实时选择关键特征很容易出现同一个特征组在一些样本中走重计算、在另一些样本中走轻计算的情况。这会导致特征缓存频繁失效。我们的框架里有一部分特征向量是静态的比如用户长期画像如果这些向量被判定为非关键就可能被跳过但下次又变成关键缓存反复命中失败访存开销居高不下。我的解法是加入一个“关键特征稳定性机制”。具体来说对一组静态特征设定一个滑动窗口比如过去100个batch中某个特征组有超过70%的概率被判定为高算力那就在接下来的推理中直接把它固定为高算力路径。这样牺牲一点点理论上的最优性但工程上稳定很多。对于在线广告、推荐这类高QPS场景工程稳定性往往比理论收益更重要。4.4 精度回退与校准问题有同学会问我已经把关键特征都保住了为什么整体精度还是降通常不是关键特征判错而是两个次生问题一是轻量分支的预测偏差没有被融合层补偿二是依赖轻量分支的下游层可能出现梯度消失导致在线推理时某些输出维度失真。应对办法是在融合层前添加特征残差连接把原始关键特征直接跳到输出端即使重计算分支被误杀了一部分关键信息仍然能通过残差保留。再一个就是做分布校验定期比较线上推理分布和离线训练分布的KL散度。如果偏差过大优先检查动态分支是否产生了不一致的中间表示。4.5 常见问题速查问题可能原因排查思路解决建议重要性预测训不动标签噪声、分布漂移检查标签分布、特征重要性排序温度平滑、冻结预测器、增加样本多样性GPU利用率低分支碎片化、矩阵过小看kernel耗时分布分组执行、批量一致性mask精度下降明显关键特征被误杀对比高算力特征组分布加残差连接、提高预算、调低lambda延迟抖动大动态分支数量不均匀看P95延迟固定关键特征、mask模板化线上分布偏移融合层校准失效KL散度监控重新校准温度、更新教师标签5. 后续演进与更多可能5.1 和模型压缩、知识蒸馏协同使用FeTS并不排斥剪枝和蒸馏相反它们可以叠加。一种推荐组合是先用知识蒸馏得到一个小而全的教师模型再在这个小模型上应用FeTS进一步节省算力。也或者在FeTS的轻量分支中使用蒸馏出的低精度小模型重计算分支保留原模型。这个组合在算力极度受限的场景下非常有效比如端侧推理。我在一个端侧项目里试过原模型1.2GB先蒸馏成400MB再叠加FeTS后平均算力下降38%精度比直接蒸馏高1.2个点。这验证了一个判断压缩方法负责减少模型的“总能力冗余”FeTS负责减少模型的“预算错配”两者并不冲突。5.2 从单卡到异构算力集群的调度FeTS目前主要讨论的是单卡推理场景但它的核心思想也可以扩展到时下热门的异构算力集群。在集群里不同节点可能部署着不同规格的GPU甚至混用CPU和专用加速芯片。此时算力分配不再只是特征组级别而是模型分片级别。我们可以把重要特征对应的计算分片调度到更强的算力节点把低优先级分片调度到弱节点或低精度算力单元。这其实就是现在很多大模型推理系统正在做的事请求级别的动态路由、模型并行下的负载均衡、基于token重要性的KV cache管理。FeTS的“特征感知”思想同样适用——先估算特征的重要性据此决定计算分片部署在哪。如果你的团队正在构建企业级算力调度平台把特征感知预测作为调度策略的一层会显著提升整体资源利用率。5.3 FeTS与int8/fp16/fp32混合精度推理的结合最后聊聊和混合精度的结合。int8、fp16、fp32、fp64这几种精度的算力需求和数值表现差异很大很多线上推理系统为了吞吐直接全部转int8结果碰到某些敏感特征会掉点。FeTS可以帮你精准地知道哪些特征组对精度敏感。实际做法是在训练阶段对特征组分别做敏感性分析得到“精度敏感度”曲线。比如某个特征组在fp32下损失下降是1.0转fp16后下降0.95转int8后只剩0.6那它就是高敏感特征必须留在fp32路径。反之一个特征组转int8后损失下降几乎没有变化那就可以放心分配int8算力。通过这种“精度感知的特征调度”既保留整体吞吐又保护关键预测能力。这套方案比较适合已有成熟量化管线的大团队。小团队可以先在单张GPU上用混合精度模拟不同精度分支验证收益后再投入真实硬件适配避免一上来就陷入int8算子兼容性的泥潭。我个人实际操作下来的体会是FeTS最大的价值不是某个模块有多精巧而是它逼着你去重新审视模型推理中“钱到底花在了哪里”。很多时候我们只看到FLOPs在减少却不知道减少的是噪声计算还是关键计算。只有把算力分配和特征价值真正对应起来才能在资源受限的前提下把模型能力榨干净。如果你也正在为推理算力发愁不妨从一个小模型、一组特征开始先做一个简单的重要性预测器看看把计算集中到关键特征之后指标会发生什么变化。