过去一年我大部分时间都泡在国产AI加速卡的训练集群上折腾的不是那种演示级别的玩具模型而是真正要落地到具体行业里的垂域大模型。垂直行业的模型训练和微调跟互联网那种亿万级通用数据训练完全是两码事数据量没那么多但对精度和可控性的要求极高而且行业数据往往敏感压根不能放到公网上去跑。这就催生了一个现实问题——怎样在一套完全自主可控的硬件架构上把从底座到微调的整条链路跑通还能做到稳定、高效、能出活。这篇文章就把我们这段实践的核心内容做一个梳理从硬件选型到分布策略从算子适配到评测反馈每一步都说清楚为什么这么做以及我们踩过的坑。目标是让准备在国产硬件上做垂域大模型项目的团队少走几周甚至几个月的弯路。1. 为什么非要跟国产算力死磕垂域模型绕不开的现实约束1.1 不能只算成本账要算安全账和可用性账很多人最开始对国产算力的态度是“能用但不想用”觉得生态不够成熟同样的模型迁移过去要费不少劲。这个想法放在一年前非常普遍但放到今天的垂域场景里会发现其实没得选。垂域大模型的核心资产是行业数据这些数据很多涉及生产管理、工艺参数、客户信息等敏感内容合规要求决定了它们必须留在本地环境处理。公有云上的训练服务再便宜数据出境和平台归属这一关就过不了。所以算力底座必须落在可自主控制的环境里这时候国产硬件就不是备选项而是必选项。还有一个被低估的点是供应链风险。通用计算卡的价格和供货节奏不受自己控制而很多行业项目的采购周期是固定的一旦卡不到位整个项目就得往后拖。我们在某制造类项目里就遇到过原计划的算力节点因为外部原因迟迟无法到货最后不得不重新规划改用非通用方案来顶上。吃了一次亏之后后续所有涉及行业训练的项目我都优先建议客户用国产硬件来搭底座。原因很简单算力自主不代表性能最强但代表项目周期可预期交付节奏掌握在自己手里。1.2 垂域模型需要的不只是更大的模型而是更稳的控制链路行业大模型跟通用大模型有一个非常根本的区别通用模型追求的是知识广度和生成多样性垂域模型追求的是稳定输出和领域准确性。比如一个用来做设备运维知识问答的模型它不能一本正经地胡说八道也不能把不同产线的参数搞混。要达到这种可控性光靠增加模型参数量是不够的更重要的是围绕行业数据做深度的监督微调让模型的行为边界收敛到业务规则之内。这决定了垂域模型项目的技术栈会跟通用大模型训练很不一样训练数据量通常就几万到几十万条但每条数据的质量要求极高训练过程不会跑广撒网式的预训练更多是基座模型加各种微调的组合。这种小规模、高迭代频率的训练负载在国产硬件上其实反而更容易优化。因为模型不大不需要那种超级复杂的分布式优化主要精力可以放在提高单卡效率和通信效率上。也正因为这样国产硬件在垂域场景里并不是“退而求其次”的选择而是一种“恰到好处”的匹配。2. 算力底座搭建从卡到集群的完整链路2.1 选型心法算力、显存与互联带宽的三角平衡在真实项目里选型从来不是单看峰值算力而是把场景代入后看整体效率。国产加速卡这几年迭代很快从推理卡到训练卡都有覆盖但真正能稳定支撑百亿级模型训练的还是得选高显存、高互联带宽的训练型号。我们衡量一个卡能不能用通常会看三个关键指标单卡FP16算力要达到一定水平显存要能装下模型和梯度的整体需求卡间互联带宽则决定了数据并行和模型并行时的通信效率。这三个指标必须放在一起看只看某一个都会踩坑。举一个具体的例子我们某次准备跑一个七十亿参数的行业基座模型最开始拿到的样卡单卡算力不错但显存只有几十GB卡间互联用的还是普通网络。结果模型塞进去之后勉强能做单机训练一旦想上并行策略就发现梯度同步的通信时间比计算时间还长整体利用率掉到三成以下。后来换了显存更大、互联带宽更高的训练卡同样的模型规模训练吞吐直接翻了三倍。这件事让团队达成了一个共识在国产硬件上做训练选型阶段就要带着你的模型图和并行方案去模拟不能光看规格表。如果要给一个参考标准我们目前的做法是百亿参数以下的垂域模型优先选单卡显存足够容纳全量模型加优化器状态配置的卡显存不够再用模型并行来补卡间互联至少要支持高速RDMA或者同构的高速直连保证多卡扩展时的效率不出现断崖式下跌。这个标准可能不是最优解但一定不会错。2.2 组网与存储模型并行对交换机和存储的压力集群组网是很多人容易忽略的一环。很多人以为买了几张卡插到服务器里就能训练了实际上垂域模型训练的场景里几机几卡的规模很常见单机内部的卡间通信通常走高速总线高性能计算节点之间则需要通过高速交换网络互连。如果你组网的时候用的是一般千兆或者万兆网络那模型并行基本跑不起来梯度同步会成为整个训练流程的瓶颈。我们的实践经验是训练集群至少是非阻塞的高带宽以太网拓扑配合RDMA协议使用。规模不大的时候可以用两台上联交换机做冗余规模大的时候就一定得用更高规格的叶脊架构避免多个节点同时通信时出现拥塞。存储方面更容易被低估。大模型训练过程中需要频繁读写检查点文件一个七十亿参数的模型每两小时存一次检查点一个检查点就好几个GB如果存储系统吞吐不够训练进程就会因为存文件而阻塞。我们后来统一换成了全闪分布式存储专门给训练集群用检查点保存时间从原来的好几分钟压缩到了二十秒以内几乎不再影响训练节奏。2.3 软件栈框架、编译器与算子库的磨合国产硬件架构下做训练软件栈的掌握程度直接决定了开发效率。目前主流的做法是在国产化AI框架之上做二次开发底层编译器把模型图转换成在硬件上高效执行的指令序列上层用Python接口跟训练逻辑交互。看起来跟通用GPU平台没有特别大的区别但实际深入之后会发现算子库的覆盖度才是最大的变量。我们在迁移一个经典对话模型的训练脚本时一开始直接跑结果发现有一个自定义激活函数编译失败原因是这个算子在底层算子库中不支持对应的变形。这种问题在通用平台上太少见了因为那里功能完整、报错少。解决办法要么是改写模型代码用组合算子替代自定义算子要么是给算子库提交扩展。我们的策略是尽量不修改模型结构优先用框架原生的算子组合去表达同一个计算逻辑。比如很多自定义激活函数其实可以拆成几个基础数学运算的组合性能略有损失但开发效率高。在国产软件栈里需要培养一个思维要尊重算子库现有的能力边界学会“用库支持的算子来搭建模型”而不是盲目依赖JIT自动生成。3. 训练适配把模型从通用平台搬过来的核心步骤3.1 算子适配与图模式转换的实操记录迁移模型到国产硬件第一步是先把模型代码在训练框架中跑通。这里就涉及算子适配和图模式转换两层工作。算子适配解决的是“能不能跑”的问题图模式转换解决的是“跑得快不快”的问题。我们在做的第一个垂域生产模型时原模型里有不少底层API调用这些API在不同框架下行为差异很大有的甚至名字相同但语义却有微妙差别直接搬过来结果完全不对。我们的做法是专门做了一张算子映射表把原模型里用到的每一个关键算子都在目标框架里做对照测试输入一组随机数据和对应梯度比较前向计算结果和反向传播梯度。这样虽然麻烦但能在正式训练之前把兼容性问题暴露清楚。图模式转换则需要开启混合计算图模式把动态图模式下的Python逻辑编译成静态图执行。动态图的好处是灵活调试但性能差静态图的好处是能对整个图做算子融合和内存复用优化。我们通常调试阶段用动态图确认收敛之后切到静态图做正式训练两边切换需要小心保存状态和理解统计量。静态图编译一旦通过训练速度提升非常明显有个模型在动态图模式下每秒只能处理不到两百条样本切到静态图模式后直接提升到了上千条。3.2 并行策略改写的几个关键选择垂域模型虽然规模不及通用大模型但只要过了十亿参数单卡就往往会遇到显存瓶颈多卡并行是躲不开的。在国产硬件上做并行最优先使用的是数据并行因为实现最简单多卡各自算一条数据然后梯度做AllReduce同步。但数据并行有个边界当单卡显存放不下模型时就必须叠加模型并行或者流水并行。我们实践下来对十亿到百亿参数范围的垂域模型最优性价比方案是数据并行 分片并行。分片并行并不是简单地把不同层分配到不同卡上而是把模型参数、梯度和优化器状态都切碎均匀分布在所有卡上每张卡只保留自己需要的分片。这样单卡显存压力大大降低而且通信量相对可控。这里面最难处理的是动态形状和计算依赖一旦模型里有复杂的条件分支分片维度就需要手工调优。我们在某个代码生成类模型上试过把动态形状的层单独固定在一张卡上其余的大部分层走分片混合方案跑起来比单纯的分片快了不少。这种混合并行策略需要谨慎调试但对垂域模型而言收益远比想象的直接。3.3 精度对齐既要一致性也要可容忍差异在国产硬件上训练经常要回答一个灵魂拷问“模型结果跟通用平台上跑出来的是不是一模一样”我们刚开始也追求完全相同后来发现这是不现实也没有必要的。不同硬件的浮点运算中间结果可能不完全一致特别是使用了不同的数学库和融合策略之后微小数级的误差会被放大。真正需要关注的是训练过程能否收敛以及下游任务的最终效果是否达标。我们的做法是设定一个“精度验证阈值”拿同样一份验证集在通用平台和国产硬件上各训练一个版本如果两个版本在领域评测集上的关键指标差距在可接受范围内就认为迁移成功。在项目汇报时也把这一套对比数据摆出来客户看到的是“效果没有因为换硬件而变差”自然就能接受。这比单纯强调“技术完全一致”要更有说服力因为做技术的人都知道完全一致在数值计算里往往不是常态而是一种概率事件。4. 垂域微调实战围绕业务数据做文章4.1 行业数据从原始文本到训练语料的关键工序垂域微调的第一道工序不是调参是处理数据。行业数据的原始状态往往混乱不堪有的数据是老旧系统导出的Excel表格有的是扫描件转的文字还有的是老师傅口述录音转写。这些数据直接喂给模型轻则学到一堆噪声重则让模型输出被污染。我们每接手一个项目都会先做一轮“数据体检”把明显的格式错误、编码混乱、信息缺失的样本清洗掉然后用规则加模型结合的方式做章节切分和关键信息抽取。更关键的是把业务知识变成模型能够学习的形式。比如在制造业设备运维场景里一条“电机过载自动保护触发”的日志单纯的一句话对模型训练价值有限我们需要把它扩展成“现象描述-故障原因-处理动作-预防措施”的完整结构。这个扩展过程不能完全依赖自动化必须让行业专家参与进来做标注否则模型学到的只是一种伪知识。我们曾经让算法工程师凭直觉扩展了一批语料结果训出来的模型在真实咨询场景里回答得磕磕绊绊后来花了双倍时间拉上现场工程师重新梳理才把微调效果提上来。所以这里的经验是数据清洗可以用工具批量做但知识结构化必须有人参与最好是有行业经验的人。4.2 指令微调与LoRA用最小成本激活垂直能力当基座模型已经具备一定的通用能力之后垂域微调通常采用两种主流方式全量指令微调和轻量微调。全量微调效果稳定但对算力和数据量的要求更高做一次往往要消耗不少卡时轻量微调也就是用LoRA或Q-LoRA这类方法则是一种更经济的做法。它的思路是冻结大模型的基础权重只训练额外的低秩因子矩阵。这样单张卡也能启动微调训练时间大幅缩短我们在多个项目里用它来快速验证垂域数据的有效性。不过用LoRA有几个必须注意的点。第一是秩的设定秩太小表达能力不足秩太大又失去了轻量化的意义我们在实践中通常从16开始视数据复杂度调到32或64。第二是需要根据地层模块的插入位置不是每一层都要插相同的LoRA模块像注意力模块的某些线性层对领域知识的影响更大我们会优先在这些位置加。第三LoRA训练完成之后一般需要将低秩因子与原始权重合并导出但合并后精度有少许变化要在评估集上重新验证一遍。我们在一个工业知识库问答项目里用LoRA只用了全量微调大概五分之一的训练时间就在关键指标上逼近了全量微调的效果这对快速迭代非常有帮助。4.3 效果评估不能只看模型指标还要看业务反馈垂域模型微调最终是要给人用的所以效果评估必须双轨并行。技术环节我们做的是评测集指标比如答案准确率、召回率、格式通过率业务环节则要去做用户接受度调查。技术指标优秀的模型不一定业务好用这是我们在多次实践中感受到的。比如一个模型在测试集上的答对率高达百分之九十但用户实际使用时发现回答老是带一段冗长的免责声明或者格式不符合线下作业习惯那它在真实场景就是不好用。因此我们后来设计了一套“模拟问答-专家评分-线上小范围试用”三层评估流程。先在内部构造几百个真实业务问题做自动评分再请业务专家对抽样结果打分最后选一个业务单元做小范围的线上试用。只有三层都通过模型才会进入正式发布流程。这中间还有个小细节评测集要动态更新每隔一段时间就要把线上出现的新问题、新回答纳入评测集防止模型线上使用一段时间后效果悄悄退化而我们毫无察觉。5. 踩坑记录与排查手册5.1 训练稳定性的坑Loss突发NAN的常见原因垂域模型训练中最容易让人心态崩溃的问题就是训练到一半Loss突然变成NAN。我们在国产硬件上排查过很多次原因主要有三个方向。一是数据问题检查数据清洗流程看是不是有未归一化的异常大值或缺失值混进了训练样本造成梯度爆炸。二是学习率过大尤其在微调阶段模型已经在一个较好的局部极小附近学习率如果沿用预训练阶段的数值很容易把参数更新到不稳定区域。三是硬件或底层库的数值问题某些算子在特定输入下可能触发溢出通常建议先切到低精度的混合精度训练开关将涉及Loss计算的算子单独保持高精度。我们的排查步骤是先硬编码固定随机种子并加入梯度裁剪再把训练数据分批二分定位接着单独跑有问题的批次检查输入数据。这一套流程走下来大部分Loss NAN问题都能锁定只有极少数是真需要跟底层算子库团队联合定位的。遇到这种情况最好的办法就是做一个最小的复现脚本把问题从复杂模型里剥离出来用十几行代码去触发异常这样沟通效率最高。5.2 通信效率黑洞卡数变多速度却上不去很多团队从单机实验转到多机训练时都会遇到一个诡异现象加了卡等待时间反而变长训练步长时间呈现锯齿状波动。这通常是通信瓶颈的典型表现。我们在国产集群上第一个模型并行训练时就遇到配置了高速互联协议但实际通信带宽并没有跑满的问题。后来才发现是网络配置里没有正确启用RDMA数据还在走TCP链路CPU都在忙着处理网络包根本顾不上计算。另外一个常见的通信陷阱是数据加载与计算重叠不足。如果数据加载线程每次在下一次迭代开始时才准备数据那么GPU就不得不等。解决思路是在训练主循环之外独立开一个数据预处理流水线把数据提前加载到内存再通过异步队列传给计算设备。我们调整过之后训练吞吐提升了接近百分之三十。这个问题的排查方法很简单看每步训练时间分布中是否存在明显的空闲等待如果有优先看看是不是踩了网络协议或数据加载这两个坑。5.3 推理侧的瓶颈微调模型跑起来容易跑得快难微调完成之后模型最终要部署为在线服务这时候推理性能往往成为新瓶颈。在国产硬件上做推理一般要考虑两件事一是要用编译优化的推理引擎不能直接用训练框架跑因为推理不需要保存梯度可以省掉大量中间状态二是要充分利用动态批处理和模型量化。垂域模型参数量不大用INT8量化往往能在几乎不掉点的情况下提升推理吞吐。不过量化前一定要做校准选一批有代表性的业务数据去统计各层激活值的分布否则可能某些任务的效果会出现明显下滑。我们碰到的具体问题是一个多轮对话模型推理时显存占用很高并发一上来就超限。后来检查发现是默认把历史对话全部拼进了上下文导致输入长度越来越长。优化方案是设置轮次截断只保留最近几轮对话内容显存占用立刻降下来。这种问题不在框架层而在算法策略层反而提醒我们垂域模型部署更多时候要站在业务使用习惯的角度去做针对性优化而不是一味地追求硬件层面的极简参数。写在最后的一些体会从算力底座到模型微调再到最后的推理部署国产硬件架构下的垂域大模型实践本质上是一场系统化工程。它要求团队既要懂模型算法又要熟悉底层芯片特性还要对行业业务有足够的敏感度。我最深的感受是在国产硬件上做项目不能用“保底兼容”的心态来做而要用“原生适配”的心态来投入。把硬件的能力极致地压榨出来针对它的特性和边界去设计模型结构和训练策略很多看似不如人的地方反而会给人意想不到的惊喜。最后再分享一个小技巧一定要给自己团队留一个“复盘清单”的赛季。每跑完一个项目把算子适配、组网调优、数据清洗、评测反馈里遇到的所有问题都记录下来形成自己的知识库。行业模型的积累是多层次的模型的权重固然有商业价值但真正难以复制的是你对这个硬件平台和业务场景交叉地带的深刻理解。这套理解才是未来一个又一个垂域模型落地时最值钱的资产。
过去一年我大部分时间都泡在国产AI加速卡的训练集群上折腾的不是那种演示级别的玩具模型而是真正要落地到具体行业里的垂域大模型。垂直行业的模型训练和微调跟互联网那种亿万级通用数据训练完全是两码事数据量没那么多但对精度和可控性的要求极高而且行业数据往往敏感压根不能放到公网上去跑。这就催生了一个现实问题——怎样在一套完全自主可控的硬件架构上把从底座到微调的整条链路跑通还能做到稳定、高效、能出活。这篇文章就把我们这段实践的核心内容做一个梳理从硬件选型到分布策略从算子适配到评测反馈每一步都说清楚为什么这么做以及我们踩过的坑。目标是让准备在国产硬件上做垂域大模型项目的团队少走几周甚至几个月的弯路。1. 为什么非要跟国产算力死磕垂域模型绕不开的现实约束1.1 不能只算成本账要算安全账和可用性账很多人最开始对国产算力的态度是“能用但不想用”觉得生态不够成熟同样的模型迁移过去要费不少劲。这个想法放在一年前非常普遍但放到今天的垂域场景里会发现其实没得选。垂域大模型的核心资产是行业数据这些数据很多涉及生产管理、工艺参数、客户信息等敏感内容合规要求决定了它们必须留在本地环境处理。公有云上的训练服务再便宜数据出境和平台归属这一关就过不了。所以算力底座必须落在可自主控制的环境里这时候国产硬件就不是备选项而是必选项。还有一个被低估的点是供应链风险。通用计算卡的价格和供货节奏不受自己控制而很多行业项目的采购周期是固定的一旦卡不到位整个项目就得往后拖。我们在某制造类项目里就遇到过原计划的算力节点因为外部原因迟迟无法到货最后不得不重新规划改用非通用方案来顶上。吃了一次亏之后后续所有涉及行业训练的项目我都优先建议客户用国产硬件来搭底座。原因很简单算力自主不代表性能最强但代表项目周期可预期交付节奏掌握在自己手里。1.2 垂域模型需要的不只是更大的模型而是更稳的控制链路行业大模型跟通用大模型有一个非常根本的区别通用模型追求的是知识广度和生成多样性垂域模型追求的是稳定输出和领域准确性。比如一个用来做设备运维知识问答的模型它不能一本正经地胡说八道也不能把不同产线的参数搞混。要达到这种可控性光靠增加模型参数量是不够的更重要的是围绕行业数据做深度的监督微调让模型的行为边界收敛到业务规则之内。这决定了垂域模型项目的技术栈会跟通用大模型训练很不一样训练数据量通常就几万到几十万条但每条数据的质量要求极高训练过程不会跑广撒网式的预训练更多是基座模型加各种微调的组合。这种小规模、高迭代频率的训练负载在国产硬件上其实反而更容易优化。因为模型不大不需要那种超级复杂的分布式优化主要精力可以放在提高单卡效率和通信效率上。也正因为这样国产硬件在垂域场景里并不是“退而求其次”的选择而是一种“恰到好处”的匹配。2. 算力底座搭建从卡到集群的完整链路2.1 选型心法算力、显存与互联带宽的三角平衡在真实项目里选型从来不是单看峰值算力而是把场景代入后看整体效率。国产加速卡这几年迭代很快从推理卡到训练卡都有覆盖但真正能稳定支撑百亿级模型训练的还是得选高显存、高互联带宽的训练型号。我们衡量一个卡能不能用通常会看三个关键指标单卡FP16算力要达到一定水平显存要能装下模型和梯度的整体需求卡间互联带宽则决定了数据并行和模型并行时的通信效率。这三个指标必须放在一起看只看某一个都会踩坑。举一个具体的例子我们某次准备跑一个七十亿参数的行业基座模型最开始拿到的样卡单卡算力不错但显存只有几十GB卡间互联用的还是普通网络。结果模型塞进去之后勉强能做单机训练一旦想上并行策略就发现梯度同步的通信时间比计算时间还长整体利用率掉到三成以下。后来换了显存更大、互联带宽更高的训练卡同样的模型规模训练吞吐直接翻了三倍。这件事让团队达成了一个共识在国产硬件上做训练选型阶段就要带着你的模型图和并行方案去模拟不能光看规格表。如果要给一个参考标准我们目前的做法是百亿参数以下的垂域模型优先选单卡显存足够容纳全量模型加优化器状态配置的卡显存不够再用模型并行来补卡间互联至少要支持高速RDMA或者同构的高速直连保证多卡扩展时的效率不出现断崖式下跌。这个标准可能不是最优解但一定不会错。2.2 组网与存储模型并行对交换机和存储的压力集群组网是很多人容易忽略的一环。很多人以为买了几张卡插到服务器里就能训练了实际上垂域模型训练的场景里几机几卡的规模很常见单机内部的卡间通信通常走高速总线高性能计算节点之间则需要通过高速交换网络互连。如果你组网的时候用的是一般千兆或者万兆网络那模型并行基本跑不起来梯度同步会成为整个训练流程的瓶颈。我们的实践经验是训练集群至少是非阻塞的高带宽以太网拓扑配合RDMA协议使用。规模不大的时候可以用两台上联交换机做冗余规模大的时候就一定得用更高规格的叶脊架构避免多个节点同时通信时出现拥塞。存储方面更容易被低估。大模型训练过程中需要频繁读写检查点文件一个七十亿参数的模型每两小时存一次检查点一个检查点就好几个GB如果存储系统吞吐不够训练进程就会因为存文件而阻塞。我们后来统一换成了全闪分布式存储专门给训练集群用检查点保存时间从原来的好几分钟压缩到了二十秒以内几乎不再影响训练节奏。2.3 软件栈框架、编译器与算子库的磨合国产硬件架构下做训练软件栈的掌握程度直接决定了开发效率。目前主流的做法是在国产化AI框架之上做二次开发底层编译器把模型图转换成在硬件上高效执行的指令序列上层用Python接口跟训练逻辑交互。看起来跟通用GPU平台没有特别大的区别但实际深入之后会发现算子库的覆盖度才是最大的变量。我们在迁移一个经典对话模型的训练脚本时一开始直接跑结果发现有一个自定义激活函数编译失败原因是这个算子在底层算子库中不支持对应的变形。这种问题在通用平台上太少见了因为那里功能完整、报错少。解决办法要么是改写模型代码用组合算子替代自定义算子要么是给算子库提交扩展。我们的策略是尽量不修改模型结构优先用框架原生的算子组合去表达同一个计算逻辑。比如很多自定义激活函数其实可以拆成几个基础数学运算的组合性能略有损失但开发效率高。在国产软件栈里需要培养一个思维要尊重算子库现有的能力边界学会“用库支持的算子来搭建模型”而不是盲目依赖JIT自动生成。3. 训练适配把模型从通用平台搬过来的核心步骤3.1 算子适配与图模式转换的实操记录迁移模型到国产硬件第一步是先把模型代码在训练框架中跑通。这里就涉及算子适配和图模式转换两层工作。算子适配解决的是“能不能跑”的问题图模式转换解决的是“跑得快不快”的问题。我们在做的第一个垂域生产模型时原模型里有不少底层API调用这些API在不同框架下行为差异很大有的甚至名字相同但语义却有微妙差别直接搬过来结果完全不对。我们的做法是专门做了一张算子映射表把原模型里用到的每一个关键算子都在目标框架里做对照测试输入一组随机数据和对应梯度比较前向计算结果和反向传播梯度。这样虽然麻烦但能在正式训练之前把兼容性问题暴露清楚。图模式转换则需要开启混合计算图模式把动态图模式下的Python逻辑编译成静态图执行。动态图的好处是灵活调试但性能差静态图的好处是能对整个图做算子融合和内存复用优化。我们通常调试阶段用动态图确认收敛之后切到静态图做正式训练两边切换需要小心保存状态和理解统计量。静态图编译一旦通过训练速度提升非常明显有个模型在动态图模式下每秒只能处理不到两百条样本切到静态图模式后直接提升到了上千条。3.2 并行策略改写的几个关键选择垂域模型虽然规模不及通用大模型但只要过了十亿参数单卡就往往会遇到显存瓶颈多卡并行是躲不开的。在国产硬件上做并行最优先使用的是数据并行因为实现最简单多卡各自算一条数据然后梯度做AllReduce同步。但数据并行有个边界当单卡显存放不下模型时就必须叠加模型并行或者流水并行。我们实践下来对十亿到百亿参数范围的垂域模型最优性价比方案是数据并行 分片并行。分片并行并不是简单地把不同层分配到不同卡上而是把模型参数、梯度和优化器状态都切碎均匀分布在所有卡上每张卡只保留自己需要的分片。这样单卡显存压力大大降低而且通信量相对可控。这里面最难处理的是动态形状和计算依赖一旦模型里有复杂的条件分支分片维度就需要手工调优。我们在某个代码生成类模型上试过把动态形状的层单独固定在一张卡上其余的大部分层走分片混合方案跑起来比单纯的分片快了不少。这种混合并行策略需要谨慎调试但对垂域模型而言收益远比想象的直接。3.3 精度对齐既要一致性也要可容忍差异在国产硬件上训练经常要回答一个灵魂拷问“模型结果跟通用平台上跑出来的是不是一模一样”我们刚开始也追求完全相同后来发现这是不现实也没有必要的。不同硬件的浮点运算中间结果可能不完全一致特别是使用了不同的数学库和融合策略之后微小数级的误差会被放大。真正需要关注的是训练过程能否收敛以及下游任务的最终效果是否达标。我们的做法是设定一个“精度验证阈值”拿同样一份验证集在通用平台和国产硬件上各训练一个版本如果两个版本在领域评测集上的关键指标差距在可接受范围内就认为迁移成功。在项目汇报时也把这一套对比数据摆出来客户看到的是“效果没有因为换硬件而变差”自然就能接受。这比单纯强调“技术完全一致”要更有说服力因为做技术的人都知道完全一致在数值计算里往往不是常态而是一种概率事件。4. 垂域微调实战围绕业务数据做文章4.1 行业数据从原始文本到训练语料的关键工序垂域微调的第一道工序不是调参是处理数据。行业数据的原始状态往往混乱不堪有的数据是老旧系统导出的Excel表格有的是扫描件转的文字还有的是老师傅口述录音转写。这些数据直接喂给模型轻则学到一堆噪声重则让模型输出被污染。我们每接手一个项目都会先做一轮“数据体检”把明显的格式错误、编码混乱、信息缺失的样本清洗掉然后用规则加模型结合的方式做章节切分和关键信息抽取。更关键的是把业务知识变成模型能够学习的形式。比如在制造业设备运维场景里一条“电机过载自动保护触发”的日志单纯的一句话对模型训练价值有限我们需要把它扩展成“现象描述-故障原因-处理动作-预防措施”的完整结构。这个扩展过程不能完全依赖自动化必须让行业专家参与进来做标注否则模型学到的只是一种伪知识。我们曾经让算法工程师凭直觉扩展了一批语料结果训出来的模型在真实咨询场景里回答得磕磕绊绊后来花了双倍时间拉上现场工程师重新梳理才把微调效果提上来。所以这里的经验是数据清洗可以用工具批量做但知识结构化必须有人参与最好是有行业经验的人。4.2 指令微调与LoRA用最小成本激活垂直能力当基座模型已经具备一定的通用能力之后垂域微调通常采用两种主流方式全量指令微调和轻量微调。全量微调效果稳定但对算力和数据量的要求更高做一次往往要消耗不少卡时轻量微调也就是用LoRA或Q-LoRA这类方法则是一种更经济的做法。它的思路是冻结大模型的基础权重只训练额外的低秩因子矩阵。这样单张卡也能启动微调训练时间大幅缩短我们在多个项目里用它来快速验证垂域数据的有效性。不过用LoRA有几个必须注意的点。第一是秩的设定秩太小表达能力不足秩太大又失去了轻量化的意义我们在实践中通常从16开始视数据复杂度调到32或64。第二是需要根据地层模块的插入位置不是每一层都要插相同的LoRA模块像注意力模块的某些线性层对领域知识的影响更大我们会优先在这些位置加。第三LoRA训练完成之后一般需要将低秩因子与原始权重合并导出但合并后精度有少许变化要在评估集上重新验证一遍。我们在一个工业知识库问答项目里用LoRA只用了全量微调大概五分之一的训练时间就在关键指标上逼近了全量微调的效果这对快速迭代非常有帮助。4.3 效果评估不能只看模型指标还要看业务反馈垂域模型微调最终是要给人用的所以效果评估必须双轨并行。技术环节我们做的是评测集指标比如答案准确率、召回率、格式通过率业务环节则要去做用户接受度调查。技术指标优秀的模型不一定业务好用这是我们在多次实践中感受到的。比如一个模型在测试集上的答对率高达百分之九十但用户实际使用时发现回答老是带一段冗长的免责声明或者格式不符合线下作业习惯那它在真实场景就是不好用。因此我们后来设计了一套“模拟问答-专家评分-线上小范围试用”三层评估流程。先在内部构造几百个真实业务问题做自动评分再请业务专家对抽样结果打分最后选一个业务单元做小范围的线上试用。只有三层都通过模型才会进入正式发布流程。这中间还有个小细节评测集要动态更新每隔一段时间就要把线上出现的新问题、新回答纳入评测集防止模型线上使用一段时间后效果悄悄退化而我们毫无察觉。5. 踩坑记录与排查手册5.1 训练稳定性的坑Loss突发NAN的常见原因垂域模型训练中最容易让人心态崩溃的问题就是训练到一半Loss突然变成NAN。我们在国产硬件上排查过很多次原因主要有三个方向。一是数据问题检查数据清洗流程看是不是有未归一化的异常大值或缺失值混进了训练样本造成梯度爆炸。二是学习率过大尤其在微调阶段模型已经在一个较好的局部极小附近学习率如果沿用预训练阶段的数值很容易把参数更新到不稳定区域。三是硬件或底层库的数值问题某些算子在特定输入下可能触发溢出通常建议先切到低精度的混合精度训练开关将涉及Loss计算的算子单独保持高精度。我们的排查步骤是先硬编码固定随机种子并加入梯度裁剪再把训练数据分批二分定位接着单独跑有问题的批次检查输入数据。这一套流程走下来大部分Loss NAN问题都能锁定只有极少数是真需要跟底层算子库团队联合定位的。遇到这种情况最好的办法就是做一个最小的复现脚本把问题从复杂模型里剥离出来用十几行代码去触发异常这样沟通效率最高。5.2 通信效率黑洞卡数变多速度却上不去很多团队从单机实验转到多机训练时都会遇到一个诡异现象加了卡等待时间反而变长训练步长时间呈现锯齿状波动。这通常是通信瓶颈的典型表现。我们在国产集群上第一个模型并行训练时就遇到配置了高速互联协议但实际通信带宽并没有跑满的问题。后来才发现是网络配置里没有正确启用RDMA数据还在走TCP链路CPU都在忙着处理网络包根本顾不上计算。另外一个常见的通信陷阱是数据加载与计算重叠不足。如果数据加载线程每次在下一次迭代开始时才准备数据那么GPU就不得不等。解决思路是在训练主循环之外独立开一个数据预处理流水线把数据提前加载到内存再通过异步队列传给计算设备。我们调整过之后训练吞吐提升了接近百分之三十。这个问题的排查方法很简单看每步训练时间分布中是否存在明显的空闲等待如果有优先看看是不是踩了网络协议或数据加载这两个坑。5.3 推理侧的瓶颈微调模型跑起来容易跑得快难微调完成之后模型最终要部署为在线服务这时候推理性能往往成为新瓶颈。在国产硬件上做推理一般要考虑两件事一是要用编译优化的推理引擎不能直接用训练框架跑因为推理不需要保存梯度可以省掉大量中间状态二是要充分利用动态批处理和模型量化。垂域模型参数量不大用INT8量化往往能在几乎不掉点的情况下提升推理吞吐。不过量化前一定要做校准选一批有代表性的业务数据去统计各层激活值的分布否则可能某些任务的效果会出现明显下滑。我们碰到的具体问题是一个多轮对话模型推理时显存占用很高并发一上来就超限。后来检查发现是默认把历史对话全部拼进了上下文导致输入长度越来越长。优化方案是设置轮次截断只保留最近几轮对话内容显存占用立刻降下来。这种问题不在框架层而在算法策略层反而提醒我们垂域模型部署更多时候要站在业务使用习惯的角度去做针对性优化而不是一味地追求硬件层面的极简参数。写在最后的一些体会从算力底座到模型微调再到最后的推理部署国产硬件架构下的垂域大模型实践本质上是一场系统化工程。它要求团队既要懂模型算法又要熟悉底层芯片特性还要对行业业务有足够的敏感度。我最深的感受是在国产硬件上做项目不能用“保底兼容”的心态来做而要用“原生适配”的心态来投入。把硬件的能力极致地压榨出来针对它的特性和边界去设计模型结构和训练策略很多看似不如人的地方反而会给人意想不到的惊喜。最后再分享一个小技巧一定要给自己团队留一个“复盘清单”的赛季。每跑完一个项目把算子适配、组网调优、数据清洗、评测反馈里遇到的所有问题都记录下来形成自己的知识库。行业模型的积累是多层次的模型的权重固然有商业价值但真正难以复制的是你对这个硬件平台和业务场景交叉地带的深刻理解。这套理解才是未来一个又一个垂域模型落地时最值钱的资产。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
