昇腾平台大模型训练全流程调试与性能调优实战指南

1. 项目概述与全流程拆解1.1 为什么要关注昇腾平台上的训练全流程这两年大模型训练已经成了很多团队的日常工作但真正把一个大模型在昇腾平台上从零跑到收敛中间要趟过的坑远比想象中多。昇腾计算平台基于自家打造的达芬奇架构NPU底层算子库、指令集和CUDA生态并不完全互通很多在GPU上“开箱即用”的代码迁移过来经常是能跑起来但loss就是不降或者性能差得离谱。我见过不少团队在迁移模型时第一反应是“把CUDA调用换成CANN接口”结果换完之后发现训练全流程根本走不通。这篇文章我打算完整梳理一遍昇腾大模型训练从环境准备、数据管线、模型适配、调试手段到性能调优的整条链路。不只是列步骤更会把我在实际调试中踩过的坑、验证过的调优参数、以及昇腾平台与传统GPU平台的差异点都讲清楚。对正在做昇腾适配、或者打算把已有模型迁移到昇腾上的工程师来说这篇文章可以作为一份实操参考。昇腾训练全流程简单说就是数据准备好之后经过加载与预处理送入模型前向计算计算loss之后反向传播更新梯度多个迭代循环直到收敛。听起来和GPU上没区别但每一步落到昇腾上都有“方言”要学。只有把全流程的每个环节都摸透才能真正用好昇腾。1.2 这套流程能解决什么问题昇腾平台的工具链正在快速完善但比起CUDA生态动辄十年的积累很多调试手段还不太成熟。我在调试中最大的感受是很多问题并不是模型本身有错而是框架适配、算子选择、显存管理方式不同所导致。这篇文章的核心目标是解决三类问题模型能跑但loss不降或收敛缓慢需要系统化定位是数据问题、模型结构问题还是数值精度问题。训练速度上不去NPU利用率偏低需要找到性能瓶颈并针对性调优。训练中途频繁报错或设备重启需要从日志、内存管理、故障恢复几个维度去排查。换句话说这篇文章并非某一个模型的具体炼丹记录而是覆盖“全流程调试调优方法论”。我会尽量把每个环节的关键动作和判定标准说清让读者能找到对应的“病根”。1.3 适合谁来参考这篇文章适合几类读者第一类是刚接触昇腾平台手里有训练任务但总是报错的新手第二类是已经在GPU上训练过模型想迁移到昇腾平台但不想踩太多坑的工程师第三类是具备一定基础、想系统了解CANN工具链和调优手段的开发人员。需要说明的是昇腾平台发展非常快硬件型号不同如昇腾310、昇腾910系列等配套的CANN版本、MindSpore或PyTorch适配版本也各不相同很多参数的默认值和行为可能随版本变化。我写的内容基于我在昇腾910系列设备上的实操经验版本相关的部分我会尽量指出但最关键的是方法本身工具版本变了方法论依然适用。2. 训练前的准备与全流程设计2.1 环境准备不止是装个驱动那么简单昇腾的环境准备比一般GPU服务器要繁琐不少。除了常规的驱动安装还要对齐固件、CANN工具包、推理或训练框架版本三者的版本匹配关系非常严格。我见过太多“模型跑不起来”的案例最后发现只是固件和CANN版本不匹配。在开始任何训练之前建议按以下顺序检查环境确认NPU驱动和固件版本可以通过npu-smi info命令查看注意驱动、固件和CANN版本需要配套。官方文档提供了版本配套表这是首先要核对的。安装CANN工具包根据训练框架选择对应版本MindSpore训练用MindSpore版CANNPyTorch迁移训练用PyTorch版CANN。安装训练框架昇腾原生支持MindSpore同时也提供PyTorch适配插件torch_npu。现在很多团队使用PyTorch所以我会重点讲torch_npu场景。设置环境变量昇腾依赖不少环境变量比如ASCEND_DEVICE_ID指定使用的NPU设备编号ASCEND_SLOG_PRINT_TO_STDOUT控制日志输出级别。安装完成后用一个小模型做冒烟测试非常关键。我在每台新机器上都会先跑一个类似ResNet-50的简单模型批次大小不用很大验证训练一条龙流程是否打通。如果小模型跑不通直接上大模型只会让问题更难定位。2.2 数据管线的设计与加载优化数据管线在训练流程中属于“既要又要”的角色既要稳定输出数据又不能拖慢训练速度。我在昇腾上调试时发现数据加载对NPU利用率的影响经常被低估。数据管线的瓶颈导致NPU空转这是最可惜的资源浪费。昇腾数据加载有几个关键配置若使用PyTorchDataLoader的num_workers数量需要根据CPU核心数和数据预处理复杂度来设置。过少会导致数据供给不足过多会造成CPU争抢反而拖慢速度。一般来说每个NPU设备分配4-8个worker是相对合理的起点。昇腾平台推荐使用torch_npu下适配的DataLoader在某些场景下会使用更高效的内存分配策略。如果数据预处理比较重考虑打TFRrecord或MindRecord格式减少读取阶段的小文件随机IO开销。另外环境变量中有个ASCEND_GLOBAL_LOG_LEVEL参数调试时设为1可以看到更多日志但生产训练时建议关闭或设为3因为日志本身会占用不少IO资源。2.3 模型适配与算子选择策略模型从GPU迁移到昇腾最核心的问题是算子兼容性。昇腾的算子库目前已经相当丰富Transformer相关的核心算子都覆盖了但自定义算子或者小众算子仍可能出现不支持的情况。迁移时建议按这个顺序处理算子问题优先用昇腾原生算子替换CANN社区包里有大量高频算子的实现。能用组合算子实现的尽量用组合算子避免一上来就写自定义算子。确实需要自定义算子的场景用TBETensor Boost Engine或AI CPU算子开发这块门槛较高需要单独学习。对于不支持的算子先用框架的CPU回退机制跑通再逐步替换。调试时有个实用技巧用torch_npu的npu.compile模式或torch.npu.optimize可以自动处理部分算子替换和融合在性能没有极端要求时非常省事。如果追求极致性能再手动逐算子调优。训练全流程中还有一点容易被忽略模型保存与加载的格式兼容。GPU上训练好的checkpoint迁移到昇腾权重的加载基本可以做到对等但分布式训练框架的差异可能导致加载失败建议提前验证。2.4 全流程设计的合理性检查在设计训练全流程时我一般会先画一张“流程图”来理清每个节点虽然不推荐在文档里画复杂图表但心里总要有一个完整的节点清单。简单说就是数据加载 - 数据增强/预处理 - 前向计算 - loss计算 - 反向传播 - 梯度更新 - 周期性评估 - checkpoint保存 - 日志记录。实际执行时还需要考虑几个容易遗漏的环节loss缩放Loss Scaling策略如何设置特别是用混合精度训练时。梯度累加Gradient Accumulation与批次大小的换算关系。学习率调度策略是否与总步数匹配。断点续训的保存频率和恢复逻辑。这些环节在GPU上可能默认就能工作但在昇腾上需要显式确认设置是否正确。比如混合精度训练昇腾和GPU的处理方式不尽相同如果配置不当可能出现loss异常甚至训练崩溃。3. 调试方法论与核心环节实现3.1 日志与监控调试的“第一现场”调试大模型训练第一件事就是建立完善的日志与监控体系。昇腾平台的日志体系分三层框架日志、CANN运行时日志、NPU设备日志。三层日志对应的问题层级不同排查时需要结合着看。框架层日志如PyTorch或MindSpore的日志主要暴露模型代码层面的问题比如张量形状不匹配、数据类型错误。CANN日志可以看到算子的执行情况、显存分配信息。设备层日志会记录更底层的异常事件比如NPU报错、硬件健康状态。调试时的具体建议如下把日志级别调整为DEBUG同时输出到文件和控制台。但注意长期开启DEBUG日志会显著降低训练速度一般在定位问题阶段使用问题修复后及时切回。使用npu-smi info周期记录设备状态包括温度、功耗、显存占用、AI Core利用率。可以用脚本定时抓取并保存到文件出现问题时有历史数据才能对比。使用昇腾自带的msprof或ascend_acl_profiler做性能剖析可以拿到算子耗时、内存分配曲线等关键数据。这部分后面详细讲。监控数据的维度建议至少包含loss值、学习率、梯度范数、吞吐量samples/s、NPU利用率和显存使用。把这六个指标按时间维度记录下来很多问题一眼就能看出来。比如loss曲线正常但吞吐量偏低基本可以断定性能瓶颈在算子或通信如果梯度范数突然变成NaN说明有数值稳定性问题。3.2 定位训练发散从loss到梯度逐层排查大模型训练最头大的问题之一就是loss不降或炸掉。我在昇腾平台上调试时总结了一套排查路径按顺序执行能快速缩小范围。第一步检查数据。先用一个很小的数据子集比如几十条样本过拟合训练。如果小数据集上loss还降不下去很可能是模型实现或数据预处理有bug而不是数据量不够。这个技巧能快速排除数据问题。第二步检查前向输出。直接打印特定层的输出张量观察是否有大量NaN或Inf。如果前向输出正常说明问题在反向传播或优化器。第三步检查梯度。在反向传播之后、优化器更新之前打印各层梯度的均值、最大值和范数。梯度消失或梯度爆炸在日志里通常会表现为梯度范数持续为0或突然变成极大值。这一步补充了前向无法发现的问题。第四步检查优化器状态。混合精度训练中优化器的状态如Adam的一阶、二阶矩如果初始化不对也会导致训练不稳定。确认优化器的状态与模型参数类型一致特别是混合精度下Master Weight的处理。实际调试中我遇到过多次训练中途loss突然变NaN的情况。最后定位发现是某个算子在特定输入分布下数值溢出。解决办法多半是给该层输入加一个LayerNorm或调整混合精度中loss scale的更新策略并不是模型结构有本质性错误。3.3 混合精度训练的配置与loss scale策略混合精度训练是大模型训练的标配昇腾平台对FP16的支持已经相当成熟但配置不当依然会让训练不稳定。昇腾上的混合精度设置有几个关键点与GPU平台不同需要重点关注Loss Scale策略。FP16的表示范围有限反向传播时梯度容易下溢为0需要通过loss scale把梯度放大。昇腾的torch_npu在amp模块中提供了动态loss scale的算法建议开启动态模式。手动设置固定loss scale的时候要综合考虑学习率和batch size的关系经验上初始值256比较稳妥训练起来之后根据梯度统计动态调整。Master Weight的处理。FP16训练时模型权重通常保存一份FP32的副本Master Weight优化器更新在FP32精度上进行。昇腾上要确认这个行为默认是开启的否则可能会出现收敛精度下降的问题。在torch_npu中通过torch.npu.ampAPI设置自动混合精度时会默认处理这个逻辑。Loss的计算精度。部分损失函数在FP16下精度损失较大建议保持FP32计算。这属于“混合精度”而非“全FP16”策略的精髓。鉴别方式是看训练几十步之后loss能否稳定下降如果loss在某个值附近震荡无法下降往往就是某些模块的精度不够。3.4 梯度累加与大batch训练的实现大模型训练常遇到显存不够的情况梯度累加是常用手段。昇腾NPU的显存管理方式和GPU不太一样梯度累加的收益往往更明显。但在昇腾上实现梯度累加有几个细节需要注意。PyTorch的梯度累加通常是这样做的# 普通训练没有梯度累加 loss model(data) loss.backward() optimizer.step() optimizer.zero_grad() # 梯度累加accumulation_steps为累加步数 loss model(data) loss loss / accumulation_steps loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()注意在梯度累加时要把loss除以累加步数否则梯度相当于被放大了accumulation_steps倍直接破坏学习率语义。昇腾上损失缩放和梯度累加同时使用的场景可以共用一套loss scale逻辑因为梯度累加只是在数值上把多次反向传播的梯度求和。另外要注意如果启用了梯度裁剪gradient clipping裁剪时机应该是在累加完成之后对最终梯度做裁剪而不是每次反向之后都裁剪。3.5 checkpoint保存、断点续训与容灾大模型训练动辄几天几周中间任何一次设备故障都可能导致从头再来。checkpoint是断点续训的核心昇腾平台上的断点续训设计与GPU类似但有几个平台特有的坑。保存checkpoint时除了模型参数、优化器状态、epoch和step计数强烈建议把随机数生成器的状态也一起保存。训练过程中如果用了Dropout、数据增强的随机性恢复训练时若没有恢复随机状态虽然训练不一定崩但实验的可复现性会受影响。昇腾上断点续训的典型代码实现# 保存checkpoint checkpoint { model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: lr_scheduler.state_dict(), epoch: epoch, step: step, rng_state: torch.get_rng_state(), npu_rng_state: torch.npu.get_rng_state(), } torch.save(checkpoint, save_path) # 恢复checkpoint checkpoint torch.load(save_path) model.load_state_dict(checkpoint[model_state_dict]) optimizer.load_state_dict(checkpoint[optimizer_state_dict]) lr_scheduler.load_state_dict(checkpoint[scheduler_state_dict]) epoch checkpoint[epoch] step checkpoint[step] torch.set_rng_state(checkpoint[rng_state]) torch.npu.set_rng_state(checkpoint[npu_rng_state])实际使用中发现昇腾上的checkpoint加载偶尔会出现设备侧状态不一致的情况特别是分布式训练场景。建议保存时把分布式通信相关的状态一起保存恢复后重新初始化通信组。4. 性能调优的五个关键维度4.1 算子融合与计算图优化性能调优的核心是让NPU的计算单元尽可能忙起来。算子融合是最直接的手段把多个小算子合并成一个大算子减少中间结果的显存读写和kernel启动开销。昇腾的CANN在图编译阶段会做一部分自动融合但很多时候需要手动干预。Transformer类模型中最常见的融合场景Attention计算中的QKV投影、softmax、矩阵乘法这些环节融合。LayerNorm和残差连接的融合。激活函数与线性层的融合比如GELU融合进MatMul后面。在PyTorch场景可以使用torch.npu.optimize中的npu_fusion_allowlist配置自定义融合规则也可以参考CANN文档开启图模式。我在调优阶段一般会先用profiler跑一遍看哪些算子耗时占比最高然后针对Top N的算子做融合。不要一上来就全开融合容易引入难以排查的数值差异。4.2 分布式并行策略的选择与通信优化大模型单卡装不下的情况下需要切分到多卡甚至多机。昇腾分布式并行策略和主流方案类似但通信算子、集合通信库的实现有差异。常用并行策略包括并行策略适用场景关键点数据并行模型可放入单卡希望增大batch size梯度同步开销与卡数线性增长张量并行单层过大需要切分到多卡每层都有通信需求对通信带宽敏感流水线并行多层网络切分到不同卡存在bubble开销需要平衡微批次大小序列并行长序列场景切分序列维度与张量并行配合使用较常见昇腾平台的集合通信库HCCL在单机多卡场景下表现不错跨机场景需要检查RoCE或InfiniBand网络配置。通信瓶颈的典型表现是吞吐量不随卡数线性增长或者卡数增长后瓶颈反而在通信等待上。用profiler查看通信算子耗时占比如果通信耗时超过单step总时长的20%就要考虑优化并行策略或通信方式了。我调优时发现很多团队在数据并行场景下默认使用AllReduce就完事了实践下来几种优化手段效果明显梯度压缩、梯度分桶与通信计算重叠。这些在昇腾平台上都有对应的库或API支持值得研究。4.3 显存管理与内存复用昇腾NPU显存是稀缺资源尤其在训练大模型时经常出现OOM。显存管理和GPU上思路一致但昇腾的内存分配策略有些不一样。几个常用优化手段激活重计算Activation Checkpointing选择性地不保存某些中间激活值反向传播时重新计算。这是省显存最有效的方法之一代价是增加计算量。昇腾上通常用torch.utils.checkpoint接口实现。优化器状态切分大模型训练中优化器状态如Adam的一阶、二阶矩占用的显存可能比模型本身还大。将优化器状态分布到多卡上可以显著降低单卡显存压力。显存碎片整理训练时间长了之后显存碎片会导致明明有总量充足却无法分配。昇腾推荐在训练代码中定期使用torch.npu.empty_cache()清理缓存但这个操作本身有开销不要放在循环里频繁调用。显存排查有个实用小技巧在代码关键节点打印显存使用量观察哪些模块吃掉了大量显存。特别是前向传播和反向传播之间显存峰值差异明显很多时候可以找到是哪个层产生的峰值。# 查看NPU显存使用 import torch import torch_npu print(f当前NPU显存已使用: {torch.npu.memory_allocated() / 1024**3:.2f} GB) print(f当前NPU显存缓存: {torch.npu.memory_reserved() / 1024**3:.2f} GB) print(fNPU显存总量: {torch.npu.get_device_properties(0).total_memory / 1024**3:.2f} GB)4.4 超参数调优与自动化搜索超参数调优在昇腾平台和GPU平台没有本质区别但由于训练成本高每次实验都弥足珍贵。三组超参数对大模型训练影响最显著学习率及调度策略、batch size与梯度累加步数、权重衰减系数。学习率调度在大模型训练中有几个经验值参考Warmup步数通常设置为总步数的1%-3%峰值学习率与batch size呈线性或平方根关系。比如batch size从256翻倍到512学习率也可以相应地执行线性缩放但不是无上限的这在昇腾的混合精度训练下依然成立。如果条件允许建议用自动化调优工具做超参搜索。目前OpenI启智社区、MindSpore生态提供了不少自动调优组件支持随机搜索、贝叶斯优化等策略。相比在GPU上做暴力网格搜索昇腾平台上的自动调优能有效节省宝贵的NPU机时。手动调参阶段我会用一组“黄金超参”作为起点然后每次只改动一个维度。比如先固定batch size和学习率调整权重衰减再将最优权重衰减固定回头调学习率。实验记录尤其重要每条实验的日志、代码版本、超参配置、loss曲线需要完整保存这在后期分析时非常关键。4.5 数据加载与预处理加速前文提过数据加载可能成为瓶颈这里展开讲。昇腾平台的数据读取路径较长磁盘 - CPU内存 - 数据传输 - NPU显存。每个环节都可能成为瓶颈。我常用的优化手段使用AIPPAI Preprocessing在昇腾上做部分图像预处理把归一化、裁剪这些操作从CPU搬到NPU上执行能显著减少CPU负载。但AIPP仅适用特定模型类型如CV模型NLP模型的预处理主要还是靠CPU完成。采用混合精度数据格式存储如将图像数据以uint8存储训练时在CPU端做反归一化。这能减少内存带宽占用但需要注意精度损失。使用预处理缓存如果训练多个epoch每个epoch对相同样本做完全相同的预处理是浪费的。可以缓存预处理后的张量而不是每次从头读原始数据。数据供给充足与否的判断标准很简单观察NPU利用率是否持续稳定在高位。如果NPU利用率呈现周期性锯齿状波动大概率就是数据供给跟不上。5. 常见问题与排查技巧实录5.1 训练到一半报错设备重启这个问题在昇腾平台上不算罕见尤其是长时间高负载训练时。常见原因有几个方向。硬件层面电源功耗不足或散热不及时会导致NPU降频甚至重启。用npu-smi info查看温度如果温度接近阈值就要检查散热系统了。有些服务器在长时间满负载运行之后机房空调不给力设备重启的几率会明显上升。软件层面CANN的某些版本在长时间运行时存在内存泄漏的隐患导致系统不稳定。建议定期检查设备日志查看是否有ECC错误或超阈值事件。如果排除了硬件和散热问题尝试升级到稳定版CANN或回退到更稳定的老版本通过对比找到适合自己硬件型号的版本。5.2 多卡训练吞吐量上不去单卡性能正常但多卡训练加速比不理想这个问题常见于通信配置或并行策略不当。排查步骤首先确认HCCL集合通信库是否正常工作可以通过hccl_tools.py测试点对点带宽。如果通信带宽偏低检查网卡配置、交换机端口速率、以及是否有TCP/IP offload设置问题。再确认数据并行梯度同步是否与计算重叠。在通信算子执行期间NPU计算单元是闲置的这个时间如果能被下一层的前向或反向计算覆盖就能大幅提升整体效率。在代码中可以通过HCCL提供的异步通信API实现计算与通信的重叠。最后如果模型较小而卡数较多通信开销占比相对较高加速比不理想是正常的。此时可以适当增大batch size让通信比例相对降低但也要留意显存上限。5.3 模型迁移后精度下降明显GPU上训练正常的模型迁移到昇腾后精度下降超过可接受范围这是常见迁移痛点。主要原因通常是数值精度差异、随机性差异或算子实现差异。对比GPU和昇腾上的逐层输出是有效的定位手段。固定输入、固定权重跑一次前向逐层对比输出张量的最大绝对误差和相对误差。如果某层误差明显偏大集中排查该层的算子实现。另一个容易被忽略的点BatchNorm在NPU上的计算顺序和GPU可能不同。昇腾对BatchNorm的实现可能有不同的reduce顺序导致大batch场景下误差累积。如果模型对精度敏感考虑换成GroupNorm或LayerNorm。最后是随机性差异。NPU的随机数生成算法与GPU不同导致同样的seed在两种平台上只能保证“同分布”不能保证完全相同的结果。这在调试时要注意不要因为一次训练结果不同就断定迁移引入了bug。5.4 常见问题速查表问题现象可能原因排查/修复动作loss变成NaNFP16溢出、梯度爆炸、输入含NaN降低学习率、调整loss scale、检查输入数据loss不下降学习率过高/过低、数据标签错误、模型结构bug先用小数据集过拟合逐层打印输出对比NPU利用率低数据加载慢、算子未融合、显存不足导致swap优化DataLoader、用profiler定位耗时算子多卡加速比差通信瓶颈、同步点过多、负载不均检查HCCL带宽、开启通信计算重叠、优化并行策略频繁OOM激活值占用过多、显存碎片开启激活重计算、清理显存缓存、优化器状态切分设备温度过高散热问题、风扇故障、机房环境检查散热系统、降低功耗或训练频率算子不支持模型使用了昇腾未覆盖的自定义算子替换为昇腾原生算子、组合算子或写自定义算子6. 实操记录与心得补充6.1 一次典型的loss炸掉排查过程记录分享一个我实际处理的案例。某个基于Transformer的序列模型在昇腾上训练到约2000步时loss突然从2.3跳变到NaN之后无法恢复。我的排查顺序是这样的先检查输入数据确认没有NaN。然后打印模型的最后层输出发现前向输出的logits已经包含NaN。这说明问题出现在网络内部。接着逐层往上排查找到第一个出现NaN的层。发现是Attention中的softmax在FP16下出现了Inf。进一步溯源发现QK^T的值在长序列场景下很大softmax在FP16下上溢。解决办法是采用FlashAttention的实现方式或者手动把QK^T的计算放到FP32下执行并在softmax之前做减法缩放。修复之后loss恢复正常训练继续全程多花了半天时间但收获是理解了该模型在FP16下的数值脆弱点。后续在其他模型上遇到类似问题排查速度就快多了。6.2 我发现“先跑通再调优”是最高效的策略很多工程师在拿到新模型时第一反应就是要把所有调优手段都用上还没跑通就开始并行加速、算子融合。我个人的经验是先放弃性能用最简单的配置小batch、单卡、原生FP32把整条训练链路跑通确认模型能收敛再来逐步加优化。昇腾平台上尤其要遵循这个原则。因为NPU的算子和GPU不完全相同模型在GPU上能正常收敛不代表在昇腾上第一次就能收敛。先把正确性验证好再逐项加性能优化项每加一项都做一次对比实验确认没有引入精度差异。这个策略虽然前期看起来慢但后期节省的时间非常可观。另外做好完整的实验记录很重要。昇腾平台的版本迭代快很多问题升级之后就不复存在了但如果当初没有记录下次遇到同类问题还是要重新排查。我习惯每次训练都保存一份debug信息文件里面包含环境版本、关键超参、最后的loss曲线和profiler摘要。排查问题时翻旧账往往是最高效的方式。6.3 值得长期关注的工具与资源昇腾生态的工具有些推荐新手提早熟悉CANN自带的profiler工具是定位性能瓶颈的核心MindSpore Insight提供训练可视化和调优建议如果团队有资源华为云的ModelArts也提供了托管的模型训练与调优服务适合不想过多折腾底层环境的团队。社区资源方面昇腾社区的官方文档更新频率比较高遇到问题优先查官方文档。另外OpenI启智社区有大量昇腾适配过的模型案例迁移之前先搜一下有没有现成的适配记录能少走不少弯路。大模型训练调试调优是一项系统性工程昇腾平台还在快速发展期很多工具链的成熟度虽然比不上CUDA生态但发展方向是对的。掌握全流程的调试方法比记住某一个具体的命令更重要。希望这篇文章能帮你在昇腾上少踩一些坑把精力放在真正有挑战的模型和算法问题上。