在金融大模型的训练竞赛中，时间就是生命。本文讲述了作者团队在30天内训练金融领域专属大模型的惊险历程。他们原本计划使用混合专家模型（MoE）架构，结合DeepSpeed优化器，打造一个在CDM、MOF和XBRL领域拥有专业知识的模型。然而，理想很丰满，现实很骨感，由于对DeepSpeed的复杂性理解不足、对专家网络存在误解以及受到硬件的限制，精心设计的方案彻底崩溃。面对困境，他们果断调整策略，最终在最后两周的冲刺中，凭借Transformers库的巧妙应用，以及对硬件限制的深刻理解，成功逆袭，取得第二名的好成绩。本文将深入探讨他们经历的挑战、做出的决策以及从中汲取的经验教训，为希望在LLM微调领域探索的读者提供有价值的参考。
DeepSpeed的承诺与幻灭：从MoE到OOM
最初，作者团队将希望寄托于微软的DeepSpeed，尤其是其强大的MoE（混合专家模型）实现。DeepSpeed的ZERO优化器承诺可以将不活跃的模型组件卸载到RAM，这对于在冻结专家知识的同时仅训练路由器而言，简直是完美的选择。他们选择了Mistral 3B作为基础专家网络，并且已经在之前的项目中成功使用过Mistral模型。
然而，第一个挑战立刻浮出水面：模型大小限制。大型语言模型（LLM）不仅仅是前馈层，还包括注意力机制、编码器、解码器和分词器等复杂组件。简单地将三个3.32B参数的模型组合在一起并不会创建一个10B参数的模型，而是接近9B，仍然超过了比赛规定的8B参数限制。为了解决这个问题，他们采取了一种巧妙的策略：仅将每隔一层的层转换为MoE，而保持共享的前馈层不变，这才使得模型参数总量降到了限制之内。
但DeepSpeed带来的问题远不止于此。尽管DeepSpeed在理论上提供了强大的模型训练能力，但在实际操作中却遇到了重重阻碍。光是平台配置就花费了作者三个晚上的时间，期间需要进行CUDA降级和解决库兼容性问题。经验教训是：优先创建包含DeepSpeed的conda环境，然后让conda解决依赖关系，而不是将DeepSpeed添加到现有的PyTorch/Transformers环境中。
此外，DeepSpeed即使在本地训练也需要集群配置，这增加了设置的复杂性。更为致命的是，DeepSpeed在很大程度上将他们锁在了Transformers生态系统之外——无法将DeepSpeed MoE模块与标准的Transformers训练和推理混合使用。
最终，压垮骆驼的最后一根稻草是ZERO优化器在MoE模型上的失效。该优化器承诺的参数卸载功能未能正常工作，导致在训练过程中出现内存溢出（OOM）错误。对于依赖参数卸载来解决硬件内存限制的团队来说，这无疑是致命的打击。
专家缝合的失败：激活空间不兼容
在最初的模型组装阶段，当作者尝试将随机初始化的路由与各个专家模型连接起来时，他们期望能够得到相对连贯的输出，因为每个专家都应该包含一个完整的、功能健全的语言模型。然而，实际情况却令人大跌眼镜：输出完全是乱码，甚至无法识别出任何有意义的单词。
最初，作者怀疑是分词器不兼容的问题，但通过简单地将同一个模型复制三遍进行验证，排除了这种可能性。问题的根源在于更深层的原因：激活空间不兼容。
在预训练过程中，每个模型都学习了特定于每一层的特征表示。例如，第N层期望接收来自同一模型的第N-1层的输入。但是，当路由将token发送到不同的专家网络时，激活空间和特征表示变得不兼容。来自专家A的第N层无法有效地处理来自专家B的第N-1层的输出。
此外，每一层的路由决策都是独立的，导致了混乱的推理路径。门控网络无法得知其他层中的路由状态。
这个失败的尝试也揭示了专家模型的一个重要真相：专家专业化并非强制分配，而是训练的结果。研究表明，专家通常不会简单地划分为“金融专家”和“监管专家”，而是更倾向于专注于语法模式、罕见token、数值推理或特定的语言结构。这种专业化是概率性的，并通过训练学习而来，而不是由知识领域预先决定的。强制进行这种专业化是一个需要专门研究的领域，虽然可能实现，但在时间紧迫的情况下，并不明智。
LoRA的非常规应用：有限的训练效果
为了训练基础模型，作者采用了LoRA（Low-Rank Adaptation），这是一种通过在原始Transformer层旁边“附加”并行适配器路径，同时完全关闭对基础网络梯度更新的方法。这些适配器网络是简单的两层瓶颈模块，它们连接到关键位置，例如注意力投影，并且它们的输出会被添加回主信息流，从而创建一种混合设置，其中原始模型保持完全冻结状态，而只有微小的适配器分支进行学习。这些权重可以用于更新基础模型，同时恢复原始架构。
然而，作者在实施LoRA时采用了一种非常规的方法：仅将每隔一层的requires_grad设置为True，保持共享层不变。LoRA通常会创建与冻结的Transformer层并行的适配器路径，但作者需要选择性地训练特定的层，同时为MoE转换做准备。
但结果却令人担忧。与完整网络训练的0.2左右的损失值相比，仅训练每隔一层的模型获得了大约4.0的损失值。这也反映在评估结果上，几乎没有提升。这出乎意料，但作者仍然继续推进，希望MoE架构能够弥补。
Transformers的救赎：从绝望到希望
距离比赛结束只有九天的时候，作者开始寻找现成的解决方案。Transformers库包含一些MoE实现：基本的Switch Transformer模块、JetMoE和Mixtral。但没有一个符合8B参数的限制。
这种被迫的探索带来了一个突破。通过阅读DeepSpeed的源代码，作者发现MoE模块在转换过程中会复制基础模块的参数。这个洞察成为了他们的救命稻草——他们可以使用纯Transformers代码在35行代码中构建相同的功能。
这个解决方案利用了Hugging Face的加载机制。模型由配置和权重组成。通过修改基础配置以指定MoE架构，Transformers会自动加载兼容的组件，同时标记不兼容的组件以进行手动传输。
硬件限制的驱动：短序列与梯度检查点
硬件限制迫使作者做出了一些关键的决策，这些决策最终改进了他们的方法。他们将训练序列减少到1200个字符，将模型缩小到5B参数，启用了梯度检查点，并将批处理大小设置为1。即使进行了这些优化，仍然无法适应RTX 4080的16GB VRAM。
在最后一周，租用具有48GB VRAM的L40服务器使得实际训练成为可能。他们在4080上运行评估，同时在L40上进行训练，以避免内存崩溃影响每个系统。
这些策略极大地提高了训练效率，加速了模型的收敛。这表明，在资源有限的情况下，专注于优化训练流程和模型结构可以带来意想不到的收获。
性能提升：狭窄任务上的专家优势
最终的结果验证了架构方法的有效性，尽管在实施过程中遇到了许多困难：
- MOF任务： 许可缩写和OSI批准任务的性能显著提高——从0.1提高到0.8，提高了8倍。专门的专家擅长这些小的、特定的任务，知识隔离提供了明显的好处。
- 专业化成功： 小型专家网络在狭窄的任务中被证明是优越的。我们的基线Qwen 7B模型几乎没有学习许可批准模式（尽管有负面训练示例，但仍低于0.1），而MoE架构实现了0.8的性能。
- 训练效率： 模型快速收敛——大约3个epoch，耗时8小时。由于每个token仅激活2/16个专家（top_k=2），训练和推理大约使用了完整模型参数的12.5%。
- 金融数学： 训练前的基线接近于零；考虑到在数据集准备期间对该部分的关注较少，达到0.45似乎是一个奇迹。
- XBRL成功： 完全归功于Flan-FinXC数据集的作者。这个数据集单独支撑了我们的XBRL性能。我们的团队从未下载过一份EDGAR报告——我们建议任何构建XBRL模型的人都利用这个惊人的项目。
最后时刻的发现：评估方法的重要性
在提交截止日期前两天，组织者发布了官方基准数据集。整合这些数据集后，作者发现他们的问答（QnA）部分需要更详细的答案——他们优化了简洁性，而基准测试奖励了细节。他们在最后的48小时内重建了QnA训练数据，显著提高了性能。
这个最后的调整被证明至关重要。在生成更详细、更全面的答案后，他们的QnA分数大幅提高。这表明：评估方法对最佳输出风格的影响比最初意识到的要大。
使用ChatGPT作为评委的评估方法需要仔细的提示工程。为了提高评估速度，他们在最后几天从DeepSeek切换到OpenAI，尽管成本更高。
LLM微调的经验教训：架构创新，评估先行
作者团队的这段经历，为LLM微调提供了宝贵的经验教训：
- 架构创新胜过规模： 在特定任务上，自定义架构可以胜过更大的通用模型。他们拥有专业专家的5B参数MoE模型在有针对性的金融任务上击败了7B基线模型。
- 内存限制驱动更好的设计： 硬件限制迫使采取高效的训练实践：更短的序列、梯度检查点和专家稀疏性。这些限制导致了更快的收敛和更专注的学习。
- 评估至关重要： 尽早构建评估基础设施。他们定制的基于ChatGPT的评分系统实现了快速迭代。当官方数据集出现时，他们迅速发现了性能差距并相应地调整了训练数据。
- 文档和生态系统很重要： DeepSpeed提供了强大的功能，但生态系统隔离被证明是有问题的。无法将DeepSpeed MoE模块与标准Transformers基础设施混合使用会造成开发摩擦。最关键的是，ZERO优化器未能支持MoE模型的参数卸载是一个根本性的限制，使他们的整个方法无效。有时，使用更好的工具的更简单的解决方案可以在项目约束范围内提供卓越的结果。
- 专家专业化是自然形成的，不要强迫它： 试图手动将知识领域分配给专家失败了。在训练过程中允许自然专业化会产生更好的结果。专家学习了语法模式、token类型和推理结构，而不是主题知识边界。
结论：创新源于约束，逆境中求生存
作者团队最终取得第二名的混乱之路表明，创新往往来自约束。当最初的计划失败时，务实的工程和快速迭代仍然可以取得有竞争力的结果。面对金融大模型训练的复杂性和不确定性，唯有拥抱变化，快速适应，才能在激烈的竞争中脱颖而出。这次经历也再次印证了LLM微调的真谛：充分利用Transformers库，重视硬件限制带来的影响，并建立完善的评估体系，才能在有限的时间内取得最佳效果。