我不知道你现在手头在做什么样的深度学习项目反正我最近这半年的工作重心几乎全被大语言模型、多模态生成和配套的训练推理基础设施占满了。每隔一段时间我都会强迫自己把手头接触过的模型架构、训练方法和工程方案整理成一份技术摘要不然很容易被具体业务带走失去了对整体技术方向的判断。这篇文章就是最新一轮的摘要笔记主要围绕四个方向大语言模型的架构变化、多模态生成模型、对齐技术、训练与推理基础设施。适合正在做模型训练或部署的工程师也适合准备从传统深度学习切入生成式AI方向的同学读完可以对当前的技术版图有一个比较清晰的整体认知。1. 大语言模型从拼规模到改架构1.1 专家混合MoE凭什么成为主流大语言模型最直观的变化是参数量越来越大但粗暴地堆参数很快就碰上了两堵墙训练算力成本和推理时的显存与延迟。于是大家把目光转向了稀疏激活架构其中最成熟的代表就是专家混合Mixture of ExpertsMoE。MoE的思路很简单把一个巨大的网络拆成若干“专家”子网络每次处理输入时由路由模块挑选最相关的少数几个专家参与计算而不是把全部参数都跑一遍。我习惯用一个类比来解释一个大而全的咨询团队接到新需求时不会让全体成员都上手而是根据需求方向快速筛选出最对口的几个小组来干活。团队规模是大的但真正投入的人力是可控的。这个机制的好处非常直接参数量可以做得很高理论上能装下足够多的知识但每次前向计算只激活一小部分专家训练和推理的浮点运算量被压下来GPU显存和延迟压力也随之缓解。实践中我见到的绝大多数中大规模模型都采用了类似的稀疏结构专家数量常用8、16、32路由通常选top-2也就是每个token只交给两个最强的专家处理这是目前性价比最高的组合之一。但MoE的工程坑不少。第一个坑是路由坍塌routing collapse如果辅助负载均衡loss的系数设得太大路由会倾向于把所有token都丢给同一个强专家稀疏激活就失去了意义但如果这个系数设得太小某些专家又会被饿死训练不充分。第二个坑是通信开销专家分布在多张卡上token去别的卡找专家就要走网络跨节点通信很容易成为瓶颈。第三个坑是显存规划虽然激活参数少了但要把全部专家和优化器状态装进显存需要的总显存并不少。我的经验是如果想在有限GPU数量下训练大参数量模型MoE是一个性价比很高的方向但一定要事先做通信带宽的评估并留出这部分余量。1.2 长上下文不止是把窗口拉长长上下文是最近绕不开的另一个关键词。早期的语言模型能处理的序列长度只有几千token现在一些开源模型已经把窗口推到几十万甚至百万级。这个变化冲击的不只是模型结构还有下游的检索、文档解析、Agent记忆管理。但长上下文远不是“把max_len参数改大”这么简单自注意力机制的计算量随序列长度呈平方级增长窗口从8K拉到32K注意力部分的理论计算量直接翻16倍。位置编码是长文本项目里最容易出问题的地方。目前的主流方案是旋转位置编码RoPE以及它的一堆变体。RoPE的优点是外推性强训练时没用过的长度推理时也能勉强接上但直接硬外推会带来明显效果衰减。我实测比较稳的做法是要么在训练阶段就把序列拉长到目标长度要么在微调时配合频率缩放例如把底座频率从1e4提高到5e5或1e6做短到长的渐进式延展。后者的训练成本低很多但需要分阶段安排数据先短后长不能一步到位。部署层面长上下文的杀手是KV Cache。即使模型结构不变缓存key和value也会占掉大量显存。对于那些“看过一遍就不再看”的历史内容很多工程方案会选择提前压缩或丢弃部分KV或者引入检索式上下文只把最相关的文档片段拼进窗口。我在实际项目中的体会是面向长文本的业务优先把精力放在“如何选进窗口”和“如何淘汰窗口”这两件事上而不是一味追求模型本身能读多长。1.3 推理期缩放让模型多想一会儿传统观点认为模型能力在训练完成那一刻就固定了推理只是把参数里的知识“读”出来。但最近大家发现推理阶段也可以有策略地消耗更多计算量换取回答质量的提升。这个过程通常被称为推理期缩放inference-time scaling简单说就是让模型在给出最终回答前多生成几个候选、自己检查一遍或者换几种思路重试。这和人类考试时的行为很像时间充裕的时候做完题还会验算、换一种方法复核。我在实际工程里常用的做法是best-of-n采样让模型对同一个问题生成多个候选答案再用一个评分器可以是奖励模型也可以是规则打分选出最优的返回。候选数量n一般取8到16左右收益和成本比较均衡继续往上加质量的提升会明显变平。另一种做法是让模型对自己生成的答案做多轮修正但要注意控制轮数超过两三轮之后模型经常把本来正确的答案改错出现来回震荡。所以我的经验是如果要把推理期计算量作为产品质量的提升手段最好搭配一个强验证器而不是完全依赖模型自我感觉。这里还有一个容易被忽略的点推理期缩放的效果和训练阶段的对齐方式要匹配。如果训练时模型从没见过这种“多步修正”的格式推理时强行让它在多个候选里反复挑效果往往很一般。理想的做法是在对齐阶段就把这类数据混进去让模型在训练时就适应“生成候选、评分、重写”的交互流程。2. 多模态与生成模型统一世界的表征2.1 从单模态到统一表征多模态这两年最大的变化不是单纯把图像识别和文本理解拼在一起而是尝试把不同模态统一成同一种表征空间。图像先被切成patch再token化音频被抽成离散token然后这些和文本token一起进入同一个序列。这样一来模型既能理解图文也能生成图文处理视频也只是把连续帧压成更长的token序列。这种“一切皆token”的建模思路是当前多模态大模型的主流框架。从训练目标看主流的做法分两类一类是对比式学习把图像和文本的表示拉到同一个空间让匹配的图文向量更接近这个思路在早期的图文检索任务里非常有效另一类是生成式训练直接让模型学习“根据文本生成图像patch”或者“根据图像生成文本描述”。目前业界的趋势是把两者融合起来用对比损失做粗对齐再用生成损失做细粒度建模。实际落地时我发现大部分多模态项目的瓶颈都不在模型结构而在数据。字幕caption质量尤其关键一段模糊的“一只狗站在草地上”和一段精确的“一只金毛犬蹲在清晨阳光下的草坪上背景有栅栏和木屋”对模型的可控性影响是完全不同的。我在做这类项目时会把数据清洗分成几个层级先做基础去重和过滤再做caption的丰富度评测最后做图文一致性的自动校验比如用反向一致性分数挑出“图文不匹配”的样本。数据质量到位了模型的提升往往比换一个更大规模的骨干网络更明显。2.2 视频生成从图像到时间的跨越视频生成比图像生成上了一个台阶难就难在要在时间维度上保持一致性。图像生成只需要理解一个静态画面视频生成却要让画面里的物体在几十上百帧里保持形状、颜色、运动轨迹的一致。现在的主流路线大致是先用自编码器把视频压缩成低维的时空特征再用扩散或流匹配模型在这个隐空间里生成最后解码回像素。这个思路可以理解为“先压缩时间和空间再在压缩后的世界里生成”。实际操作中视频生成项目最折磨人的是两件事一是时序抖动画面单帧看着都正常连起来就有闪烁、变形、物体漂移二是运动可控性比如用户希望镜头缓缓推进模型却输出了一段快切镜头。针对时序抖动常见做法是在训练时增加帧间一致性的损失约束推理时也可以对相邻帧做特征层面的平滑。针对运动可控性比较好的方案是把运动描述镜头推拉、物体位移、速度作为条件输入而不是让模型自己脑补。另外一个容易被低估的点是视频数据的清洗成本。图像数据可以靠检测模型粗筛视频数据还必须处理片段切分、运动幅度筛选、时间标注等问题。我见过不少团队把大量时间花在模型调参上最后发现训练数据的运动分布太窄模型生成的视频要么全是静止镜头要么运动幅度过大完全失控。数据分布统计这一步在视频项目里值得专门做一轮分析报告。2.3 多模态评估别让指标骗了你多模态模型的评估是另一个容易被低估的环节。自动指标确实方便比如图像生成常用的FID、CLIP-Score视频方面也有帧间一致性指标但它们和人的主观感受经常对不上。我在一个图像生成项目里就有过教训某轮实验自动指标全部变绿但人工一看生成图像开始出现多余的装饰性元素整体风格明显偏离业务要求。自动指标喜欢“平均意义上和文本更接近”但平均不代表业务上正确。所以我现在做多模态项目一定会搭一套人工评测流水线固定一批覆盖常规、困难、对抗三类场景的评测集让至少两三个人独立打分并记录偏好原因。同时控制评测集规模不需要很大两三百条高质量问题往往就能反映出版本之间的真实差距。另外评测集要定期更新避免模型过拟合到测试集风格上。多模态项目的效果波动往往比纯文本项目大得多评测频次也要相应提高。3. 对齐技术让模型学会说人话3.1 从RLHF到DPO的逻辑模型预训练学的是“预测下一个token”但会预测不代表会沟通。以前那种海量语料训练出来的模型回答经常是语法正确但空洞、重复、甚至有毒。对齐alignment技术的目标就是通过人类偏好数据把模型的输出风格、行为方式和交互习惯校准到符合预期。最经典的路径是RLHF先用人工标注的偏好数据训练一个奖励模型再用这个奖励模型给策略模型打分通过强化学习优化策略。它的本质是“用奖励函数做指挥棒”。DPO是近几年比较受欢迎的新方法核心思想是绕开奖励模型直接从偏好数据推导出策略优化目标。不再需要单独训练一个奖励模型也不用跑PPO那套复杂的强化学习流程只要把“被偏好的回答”和“不被偏好的回答”成对地喂给模型让它学习更偏好前者。我用一个类比来理解RLHF像是先找一个经验丰富的评委奖励模型再让选手根据评委的评分去练动作DPO则更像是直接把“好动作和坏动作”的录像放给选手看让它自己悟。DPO的工程复杂度低很多迭代速度快特别适合中小团队。下面这个表格是实际选型时我会参考的对比对比维度RLHFDPO训练流程预训练、SFT、奖励模型、强化学习预训练、SFT、偏好优化跳过奖励模型工程复杂度高需要维护奖励模型和强化学习链路低训练逻辑接近普通监督微调稳定性超参数多容易波动稳定性较好但对偏好数据质量敏感适用场景数据量大、基础设施强、需要细粒度控制中小团队、快速迭代、算力有限3.2 偏好数据的质量比算法更关键对齐算法再先进也救不了烂数据。我的经验是偏好数据的质量直接决定对齐效果的天花板。最关键的指标是偏好对之间的差异度如果被偏好和未被偏好的两个回答只在措辞上有细微差别模型很难学到有用的信号训练还会不稳定。我通常会先做一轮自动筛选去掉那些差异度太低的pair再用规则或者模型打分做一遍质量过滤。重复数据也在必清之列同一个pair在多个epoch里被反复看到会直接导致DPO训练发散loss突然冲高。训练参数上DPO的beta温度系数对结果的影响很大。beta越小模型越激进地向偏好方向偏移容易把自己学歪beta越大偏移越保守但可能效果不明显。我常用的初始范围是0.1到0.3具体再根据验证集效果调整。另外DPO需要冻结一个参考模型来约束偏移量训练时这个参考模型不能更新为了降低遗忘风险我还会在优化数据里掺入一部分普通的监督微调样本比例大概在5%到15%让模型在学偏好的同时保持基本能力。关于停止点对齐训练最好用留出的偏好验证集做监控观察偏好准确率的同时也要盯通用能力指标。如果通用指标开始下滑即使偏好准确率还在涨也该停了。这个度很难拿捏但比盲目跑满固定步数要稳妥得多。3.3 安全与能力的天平对齐中的安全性话题这几年讨论很多落到工程上就是“拒绝回答”和“能力可用性”之间的平衡。过度追求安全很容易让模型变成惊弓之鸟问什么都先道歉或拒绝业务完全没法用但完全不设防也不行面向海量用户的产品是巨大的风险。我在实际项目中总结的做法是评测集里专门设计两类对抗样本一类是真危险内容一类是看似敏感但实际无害的良性样本然后监控模型在两类样本上的表现。理想状态是危险的能挡掉良性的又能正常回答。如果拒答率在良性样本上过高就说明安全对齐过重了需要回退调整。除此之外输出的语气和风格也会在对齐阶段被大幅改变。我踩过的坑是某次用DPO做一轮风格优化模型确实变得更礼貌了但同时回答变得冗长、废话变多因为偏好数据里的“更受欢迎”回答普遍更长。后来我才意识到需要在偏好数据构造阶段主动控制长度和措辞的变量把“风格是否更好”和“长度是否更长”解耦否则模型学会的不是风格而是“多说废话”。4. 训练与推理基础设施真正决定项目成败的部分4.1 并行策略怎么选模型算法再好最终都要落到训练和部署上我见过太多项目死在基础设施这一环。先说分布式训练。并行策略并不神秘本质是解决两件事模型参数放不下怎么办数据量太多算不完怎么办。最常用的几个手段是数据并行、张量并行、流水线并行以及介于数据并行和参数分片之间的全分片数据并行如FSDP。选择逻辑其实很简单优先算一下单卡显存能不能放下一份完整的模型权重、梯度和优化器状态如果能优先用纯数据并行通信开销最小如果单卡放不下一个层或多头注意力计算再引入张量并行按层内切分如果模型层数极深就用流水线并行把不同层分配到不同设备上。真正容易翻车的是混用多种并行策略后的通信拓扑设计。模型并行会在每步训练中增加all-reduce、all-gather等集合通信如果机架间的网络带宽跟不上显存是省下来了训练吞吐量反而会暴跌。我踩过的一次坑是某次实验为了在单机四卡上跑一个参数量更大的模型过度使用张量并行结果每个训练step的通信时间比计算时间还长整卡利用率掉到30%以下。后来改成层间切分加梯度通信优化吞吐量才恢复正常。我的建议是在加入任何并行策略之前先用profiler工具测一下当前的计算通信比例再决定怎么切。4.2 混合精度与数值稳定性混合精度训练已经是标配但真正把它用好的人不多。现在的主流选择是BF16它和FP16一样只占两个字节但动态范围比FP16大得多不需要频繁做损失缩放训练稳定性高。缺点是精度稍微低一点但对于常见的大模型训练任务完全够用。FP8是更新的选择能把权重占用再砍一半显存和带宽都更友好不过对硬件和框架的支持要求更高数值敏感的层比如LayerNorm、最后的分类头通常需要保留更高精度。我的经验是如果硬件不支持FP8或者框架的缩放机制不够成熟老老实实用BF16别为了省显存给自己找麻烦。训练稳定性方面我总结过一套排查流程。loss突然出现尖峰先看学习率是否过高再看数据顺序是否突然变化然后检查梯度是否出现NaN或Inf。梯度裁剪gradient clipping是必开项我一般把全局梯度范数上限设在1.0到2.0之间它对训练稳定性的贡献比大多数人想象得大。另一个常被忽略的点是优化器状态Adam类的二阶矩估计受数值震荡影响很大如果某个batch的梯度异常后续很多步都会受牵连。所以在怀疑数值稳定问题时不要只盯着当前loss要多翻几轮之前的状态日志。4.3 推理侧的三个关键优化点模型训练完了部署环节决定的是真实成本。推理优化我一般会从三个点入手量化、KV Cache、请求调度。量化方面目前对生成任务影响最小的组合通常是对权重做INT8或W4A16同时保留激活值的高精度。权重从FP16压缩到INT8绝大多数业务场景的精度损失可以忽略但显存占用和带宽压力明显下降。如果还想更激进可以做4bit权重但这时需要配合更好的校准集和混合精度恢复策略而且不同任务的退化程度不一样。另外KV Cache是长上下文场景下的显存大头可以单独对KV做INT8量化我实测在多数任务上损失很小但显存占用能降四成以上。请求调度层面连续批处理continuous batching是最值得优先引入的优化它打破了过去一个batch必须同步完成的限制请求到达就能插入当前批次吞吐量提升非常明显。配合前缀缓存能让多个共享相同上下文前缀的请求复用计算结果这在大语言模型Agent场景里尤其有用。投机采样speculative decoding则适合追求低延迟的场景用一个更快的小模型先草拟一批token再由大模型一次性验证能在不损失精度的前提下把解码速度提上去一个档次。下面是我常用的方案选择表优化手段适合场景效果预期注意事项权重INT8或W4A16量化显存紧张、吞吐优先显存降30%-50%4bit需要校准集KV Cache量化长上下文、高并发显存降40%以上极端序列下需验证精度连续批处理高并发在线服务吞吐提升明显需要框架支持调度投机采样低延迟对话延迟降低1.5-2倍草稿模型质量需要匹配前缀缓存Agent反复调用首token延迟大幅降低缓存命中率依赖业务特征5. 前沿架构与个人实践建议5.1 注意力之外的探索Transformer自诞生以来统治了几乎所有主流模型但它有一个绕不开的软肋二次方复杂度。为此研究社区一直在寻找替代方案。状态空间模型SSM及其衍生架构是近年最受关注的方向之一它把序列建模复杂度降到线性而且在长序列上表现突出。纯SSM的能力说实话还不稳定但“注意力SSM混合”的架构已经在一些场景里表现出非常好的性价比长距离依赖用注意力捕捉局部模式用SSM高效建模既保住质量又压住了计算量。除了架构层面的探索硬件协同设计也在成为新的竞争点稀疏计算、算子融合、专用加速芯片都在试图从底层降低大模型训练和推理的成本。我的建议是对这类新技术保持关注和灰度测试但不要急着把核心业务迁移到未经充分验证的架构上。我见过不少团队看到某个新架构在论文指标上有优势就全面切换结果在真实数据上被长尾问题反复折磨。理性做法是先在旁路实验里验证用你自己的数据和评测集跑一两个月确认稳定收益后再考虑迁移。5.2 给工程师的落地建议最后聊点实在的。如果你的目标不是发论文而是做产品我的第一个建议是不要被层出不穷的新架构扰乱节奏。当前阶段最稳妥的技术路径仍然是大语言模型基础架构加上监督微调和偏好优化再针对业务场景做数据工程和推理优化。这个组合成熟、工具链完善、社区资料多能把大多数业务的八成需求覆盖掉。等你发现这个组合确实存在瓶颈比如长文本效果不行、推理成本无法承受再动手研究新架构也不迟。第二个建议是数据工作投入的收益往往被严重低估。一个小模型配上高质量、覆盖均衡的数据效果可以轻松超过一个大模型配上粗糙数据。尤其在微调和多模态项目里数据清洗、标注规范、分布分析这些看起来“不性感”的工作恰恰是决定最终效果上限的部分。我自己的项目时间分配最近半年已经有超过一半花在数据和评测上真正调模型结构的时间反而不多。第三个建议是把成本当成核心指标。很多生成式AI项目在技术demo阶段光彩照人一上线就被推理成本压垮。所以从项目一开始就要估算单次推理的成本、并发峰值下的GPU数量、以及优化预算的分配。我看项目是否健康第一眼看的往往不是模型的精度榜单而是单位成本能换多少有效产出。这些就是我在最近这段时间整理的技术摘要里最主要的观察。如果让我浓缩成一句话那就是前沿技术的门槛正在从“训练一个大模型”转向“用合理的成本运营一个模型系统”。