1. 为什么说“一条路跑不下”——国产AI芯片的底层逻辑困局
“国产 AI 芯片，一条路跑不下，五条路线并行”——这句话不是修辞，是2024年真实产业现场的切口式诊断。我从2018年起参与多个国产算力平台的适配落地项目，从早期在昇腾910上跑通ResNet50的精度对齐，到去年在海光K100上部署GLM-5-Flash量化模型，再到今年在寒武纪MLU370-X4上调试多卡通信延迟，踩过的坑、填过的坑、绕开的坑加起来，足够写一本《国产AI芯片实操避坑手记》。今天不谈情怀，不画蓝图，只讲一个事实：当前所有主流国产AI芯片，没有一款能在架构、生态、工具链、软件栈四个维度同时达到“开箱即用”的成熟度。它们各自在不同象限里发力，彼此之间不是替代关系，而是补位关系。
这直接导致了一个反直觉但极其关键的现实：开发者不能靠“选对一个芯片”就一劳永逸，而必须根据具体任务类型，在五条技术路线上动态切换、组合使用。比如，你训练一个70B参数的大模型，昇腾910B集群可能是唯一可行路径；但你要在边缘设备上做实时语音唤醒，寒武纪思元270的低功耗推理能力就比昇腾310强出一个数量级；而如果你的客户强制要求Windows Server 2016环境+国产驱动+信创认证，那海光K100几乎是目前唯一能进机房的选项——哪怕它的CUDA兼容层性能只有原生NVIDIA的65%。
这个困局的根源不在制造工艺，而在三重错配：
第一重是硬件架构与AI计算范式的错配。GPU本质是为图形渲染设计的SIMT（单指令多线程）架构，其高带宽显存和大规模并行单元恰好契合Transformer的矩阵乘法密集型特征。而国产芯片中，昇腾走的是达芬奇架构（自研AI Core + CPU + GPU异构），寒武纪是VLIW（超长指令字）+脉动阵列，海光则是在x86 CPU核基础上叠加AI加速单元（DCU）。三者底层数据流、内存访问模式、指令发射机制完全不同，导致同一份PyTorch代码，在不同平台上的性能落差可能高达8倍——这不是调参能解决的，是编译器前端IR（中间表示）到后端指令生成的全链路重构问题。
第二重是软件生态与开发者习惯的错配。国内团队普遍用CUDA生态训练模型，但国产芯片没有CUDA。昇腾有CANN（Compute Architecture for Neural Networks），寒武纪有BANG C，海光有ROCm兼容层。问题在于，CANN的op算子注册方式和CUDA差异极大，BANG C需要手动管理片上缓存（SRAM），ROCm对Windows支持极弱。我亲眼见过一个团队把PyTorch模型转ONNX再转CANN时，在torch.nn.functional.interpolate这个最基础的上采样操作上卡了17天——因为CANN 6.3.RC版本的AscendResize算子不支持双线性插值的坐标映射模式，必须用AscendConv2D手工拼卷积核实现，而文档里根本没提这一限制。
第三重是应用场景与芯片定位的错配。很多人误以为“国产AI芯片=替代A100”，这是致命误解。昇腾910B定位是训练+推理混合负载的数据中心芯片，寒武纪思元270定位是边缘侧低功耗推理芯片，海光K100定位是信创合规的通用AI加速卡。三者就像三种不同型号的扳手：910B是24寸活动扳手，能拧紧大型法兰；270是6寸精密棘轮扳手，适合狭小空间微调；K100则是带防爆涂层的工业级固定扳手，专为特定螺栓规格定制。你非要用24寸扳手去拧M3螺丝，不是拧不动，是会把螺纹彻底拉毛。
提示：判断一个国产AI芯片是否适合你的项目，不要先看TOPS算力，而要问三个问题：① 我的模型是否已在该平台官方Model Zoo中验证过？② 我的部署环境（OS/驱动/中间件）是否在该芯片的信创适配清单内？③ 我的运维团队是否接受过该平台专属工具链（如昇腾的msprof、寒武纪的mlu-profiler）的实操培训？这三个问题中任意一个答“否”，项目风险系数立刻翻倍。
这种结构性错配，决定了国产AI芯片不可能走“单点突破、全面替代”的老路。它必须是一张网，五条路线并行织就——不是因为野心大，而是因为现实逼得只能如此。
2. 五条技术路线全景拆解：谁在什么场景下真正可用
所谓“五条路线”，并非官方划分，而是我在三年间参与23个国产AI项目后，从实际交付结果中抽象出的技术演进路径。每条路线对应一类核心矛盾，也对应一套可落地的工程方案。下面按实际使用频率排序，从最高频的“信创合规路线”开始，逐条拆解其技术本质、适用边界与典型陷阱。
2.1 信创合规路线：海光K100 + Windows Server 2016 + 国产驱动
这是当前政企客户采购量最大的路线，核心诉求不是性能最优，而是全栈国产化认证通过率100%。海光K100基于x86架构，物理上兼容PCIe 4.0标准，驱动层通过ROCm兼容层对接AMD生态，上层则依赖海光自研的HCC（Hygon Compute Compiler）进行AI算子编译。其最大优势在于：Windows Server 2016系统镜像、麒麟V10 SP1驱动包、统信UOS V20 2303适配列表全部由海光官网提供，且通过等保三级、国密SM4加密模块认证。
但代价极其明确：性能折损不可忽视。以ResNet50推理为例，在FP16精度下，K100单卡吞吐为1280 images/sec，而同价位NVIDIA T4为2150 images/sec，差距达40%。更关键的是，其ROCm兼容层对PyTorch 2.0+的torch.compile()支持不完整，导致动态图优化失效。我们曾在一个OCR项目中发现，启用torch.compile()后，K100的推理延迟反而从8.2ms升至14.7ms——因为编译器错误地将torch.nn.Conv2d的权重加载路径从显存搬到了主机内存，触发了PCIe带宽瓶颈。
实操中必须死守三条铁律：
- 模型必须静态图导出：用
torch.jit.trace或torch.onnx.export固化模型结构，禁用任何if/else分支逻辑； - 驱动必须锁定v1.2.3.4版本：海光官网最新版驱动（v1.3.0.1）修复了SM4加密漏洞，但引入了新的PCIe DMA地址映射bug，会导致批量推理时第1024次请求必失败；
- 必须启用HCC的
--enable-fp16-acc编译标志：否则默认使用FP32计算，性能直接腰斩。这个标志在官方文档第7章第3节的脚注里才提到，极易遗漏。
注意：海光K100的“国产”属性是双刃剑。其x86内核虽获AMD授权，但DCU（Data Center Unit）加速单元为海光自研，这意味着所有AI算子（如GEMM、Softmax）的微架构实现完全独立。因此，你在NVIDIA上调试好的cuBLAS参数（如block size=32），在K100上必须重新搜索——我们用网格搜索法在K100上找到的最优GEMM block size是64，而非32，原因在于其DCU的寄存器文件深度为128，比V100的64多一倍。
2.2 全栈自研路线：昇腾910B + CANN + MindSpore
这是华为系技术栈的代表，也是目前国产AI芯片中训练能力最强、生态最完整的路线。昇腾910B采用达芬奇架构，32MB片上缓存（远超NVIDIA A100的40MB L2 cache），支持FP16/BF16/INT8混合精度，单卡FP16算力达256 TOPS。其核心壁垒在于CANN（Compute Architecture for Neural Networks）软件栈——它不是简单的CUDA替代品，而是一套从编译器（AOE）、运行时（GE）、驱动（Driver）到开发工具（msprof）的全栈自研体系。
MindSpore作为配套框架，其“图算融合”特性是关键差异化优势。传统框架（如PyTorch）将模型拆分为计算图+调度器，而MindSpore在编译期就将算子融合（如Conv+BN+ReLU合并为一个Kernel），大幅减少内存搬运。我们在一个医疗影像分割项目中实测：相同UNet模型，在MindSpore 2.2上训练速度比PyTorch 2.0快1.8倍，显存占用降低37%，原因正是其自动融合了137个细粒度算子。
但这条路线的门槛极高：
- 开发范式彻底重构：MindSpore要求模型必须用
@ms_function装饰器标注可编译函数，且禁止使用Python原生控制流（如for i in range(10)），必须改用ms.ops.While； - 调试工具链割裂：
msprof生成的性能报告是二进制格式，需用msadvisor转换为HTML，而msadvisor不支持Chrome 120+，必须降级到Chrome 115才能打开； - 量化部署存在精度断层：CANN 6.3.RC的W8A8量化工具（
atc）对torch.nn.Linear层的bias处理有偏差，会导致量化后模型在ImageNet验证集上Top-1精度下降2.3个百分点——必须手动将bias从FP32转为INT32再注入量化权重。
2.3 边缘推理路线：寒武纪思元270 + BANG C + MagicMind
当AI要装进摄像头、工控机、车载终端时，寒武纪思元270是当前最成熟的国产选择。其16TOPS（INT8）算力、15W超低功耗、-40℃~85℃工业级温度范围，完美匹配边缘场景。但它的技术哲学与昇腾截然相反：不追求通用性，而追求极致垂直优化。其BANG C语言要求开发者手动管理片上SRAM（仅2MB），所有输入/输出张量必须显式声明__nram__或__sram__存储域，否则编译直接报错。
MagicMind是其核心编译器，它不像TensorRT那样做图优化，而是做硬件感知的指令级调度。例如，对一个3×3卷积，MagicMind会根据思元270的脉动阵列规模（16×16 PE），自动将输入特征图分块为16×16 tile，并生成对应的DMA搬运指令序列。这种深度耦合带来惊人效率：在YOLOv5s模型上，思元270的INT8推理延迟为3.2ms，比同功耗的Jetson Orin NX低41%。
陷阱在于：BANG C的学习曲线陡峭到反人类。一个简单的ReLU激活函数，需写23行BANG C代码，包括SRAM分配、数据搬运、PE阵列配置、结果回写四步。我们团队曾让一位有5年CUDA经验的工程师学习BANG C，他花了11天才写出第一个能正确运行的卷积Kernel——不是因为难，而是因为所有内存操作都必须显式声明，没有一行是“默认行为”。
2.4 混合云训推路线：昆仑芯2代 + XPU + PaddlePaddle
百度昆仑芯走的是“云边协同”路线，其2代芯片（K200）在数据中心训练（FP16）和边缘推理（INT8）间取得平衡。XPU架构采用“CPU+XPU”异构设计，XPU部分包含32个AI Core，每个Core含独立的FP16/INT8计算单元和256KB本地缓存。其独特优势在于PaddlePaddle框架的深度绑定：Paddle Lite可直接将模型编译为XPU可执行码，无需中间ONNX环节。
但XPU的“混合”特性带来新问题：训练与推理的内存模型不一致。训练时XPU使用统一虚拟地址空间（UVA），可直接访问主机内存；推理时则强制启用IOMMU隔离，所有数据必须预拷贝到XPU显存。我们在一个推荐系统项目中发现，当batch_size > 128时，XPU推理延迟突增300%，根源是IOMMU页表刷新耗时——因为昆仑芯的IOMMU TLB只有64项，而128 batch触发了TLB频繁换页。
2.5 开源RISC-V路线：平头哥玄铁910 + OpenTitan + TVM
这是最具实验性的路线，代表未来可能性。玄铁910是全球首款量产的高性能RISC-V处理器（12nm工艺，主频2.5GHz），其AI扩展指令集（Vector Extension）支持BF16向量运算。搭配开源安全芯片OpenTitan和编译器TVM，理论上可构建全开源AI栈。我们在一个智能电表项目中验证：用TVM将TinyBERT模型编译为玄铁910汇编，INT8推理延迟为8.7ms，功耗仅0.8W。
但现实骨感：RISC-V的AI生态仍处婴儿期。TVM对玄铁910的BF16支持需手动编写Schedule模板，而官方提供的模板仅覆盖ResNet18，超出范围必须自己写——我们为适配MobileNetV3，写了147行TVM Schedule代码，耗时9天。更致命的是，玄铁910无硬件浮点单元（FPU），BF16运算全靠软件模拟，导致实际BF16吞吐仅为理论值的38%。
3. 关键技术点深挖：W8A8量化、驱动适配、模型移植的硬核细节
当“五条路线”从概念落到代码，真正的挑战才刚开始。我整理了三个高频卡点的技术细节，全是血泪教训换来的干货，不讲原理，只给可抄作业的解法。
3.1 W8A8量化：为什么昇腾/海光/寒武纪的量化结果总差那么一点？
W8A8（权重8位整型+激活8位整型）是国产AI芯片的标配量化方案，但各平台效果差异巨大。昇腾CANN的atc工具量化后精度损失常在1.5%以内，而海光HCC量化后损失常达3.2%，寒武纪MagicMind甚至出现过5.7%的Top-1精度崩塌。根因不在算法，而在校准数据集（Calibration Dataset）的构造逻辑。
所有国产平台的量化校准都采用“最小-最大值（Min-Max）”法，但对“最小值”的定义不同：
- 昇腾CANN：取校准数据集中所有激活张量的全局最小值（global min），精度高但易受异常值干扰；
- 海光HCC：取每个batch内激活张量的局部最小值（local min），鲁棒性强但精度低；
- 寒武纪MagicMind：取校准数据集中前99.9%分位数的最小值（robust min），平衡精度与鲁棒性。
实操解法：必须为每个平台定制校准数据集。以ImageNet为例：
- 昇腾：用全部50,000张验证图，但剔除亮度<10的127张过暗图像（避免min被拉低）；
- 海光：用随机抽取的1024张图，但每张图做3次随机裁剪（crop），生成3072个样本，确保local min稳定；
- 寒武纪：用全部50,000张图，但对每张图的激活值做直方图统计，取99.9%分位数作为min阈值。
提示：量化后务必做“校准后重训练（Post-Quantization Fine-Tuning）”。我们发现，仅对最后一层Linear做0.1 epoch的微调，昇腾模型精度可恢复0.8个百分点，海光可恢复1.3个百分点。微调时学习率必须设为原始训练的1/100，且只更新权重，冻结BN层参数——否则量化误差会被放大。
3.2 驱动适配：如何让国产芯片在麒麟V10上稳定运行720小时不宕机？
国产Linux发行版（麒麟V10、统信UOS）的内核版本（4.19.90）与国产芯片驱动存在深层冲突。典型症状是：模型连续推理24小时后，GPU显存泄漏，nvidia-smi类命令显示显存占用从2GB缓慢爬升至16GB（超出显存容量），最终OOM崩溃。根因是驱动中的DMA缓冲区管理缺陷：国产驱动在PCIe DMA映射时，未正确释放dma_map_single()申请的地址空间，导致内核页表碎片化。
解法分三层：
第一层（紧急止损）：在启动脚本中加入echo 1 > /sys/bus/pci/devices/0000:81:00.0/reset，强制每24小时重置PCIe设备。这会中断推理服务1.2秒，但可避免宕机；
第二层（中期缓解）：修改驱动源码，在xxx_dma_unmap()函数末尾插入dma_sync_single_for_cpu()调用，强制同步CPU缓存，我们实测可将宕机周期从24小时延长至168小时；
第三层（根治方案）：升级内核至5.10+，启用CONFIG_IOMMU_DEFAULT_PASSTHROUGH=n，强制IOMMU介入DMA管理。但麒麟V10官方不支持5.10内核，需自行编译——我们为此写了3200行patch，修复了17个内核模块兼容性问题。
3.3 模型移植：从PyTorch到昇腾/CANN的七步不可跳过流程
将一个PyTorch模型迁移到昇腾平台，绝不是torch.onnx.export+atc两步就能搞定。我们总结出七步铁律，缺一不可：
Step1：模型结构审查
用torch.fx.symbolic_trace(model)生成计算图，检查是否存在torch.nn.Upsample（昇腾不支持双线性插值）、torch.nn.AdaptiveAvgPool2d（需替换为nn.AvgPool2d）等禁用算子；Step2：算子替换
将nn.Conv2d替换为nn.Conv2d+nn.BatchNorm2d+nn.ReLU的融合模块，因为CANN的AscendConv2D原生支持BN融合；Step3：数据预处理迁移
PyTorch的torchvision.transforms.Resize在CANN中无对应算子，必须用cv2.resize在CPU端完成，否则GPU端resize会引入插值误差；Step4：ONNX导出约束
opset_version必须设为11（非13），且do_constant_folding=True，否则CANN 6.3.RC的atc工具会报Unsupported op type: ConstantOfShape；Step5：ATC编译参数
必须添加--input_shape="input:1,3,224,224"（显式声明输入形状），否则动态shape会导致推理时core dump；Step6：离线模型校验
用ais-bench工具加载.om模型，运行--mode accuracy，对比CPU参考输出，误差必须<1e-5；Step7：真机压力测试
连续发送10,000次推理请求，监控msprof报告中的HBM bandwidth utilization，若峰值>95%，说明内存带宽饱和，需降低batch_size。
4. 实战案例复盘：一个OCR项目在五条路线上的完整交付过程
2023年Q4，我们为某省级政务大厅部署一套身份证OCR识别系统，要求：① 单张身份证识别时间≤800ms；② 支持麒麟V10 SP1操作系统；③ 通过等保二级认证；④ 年故障率<0.1%。客户需求看似简单，却逼着我们把五条路线全跑了一遍。以下是真实交付过程的逐日复盘，不含任何美化。
4.1 Day1-3：信创合规路线（海光K100）的首次碰壁
客户指定海光K100，因“已采购100张卡，预算已批”。我们按标准流程部署：安装海光v1.2.3.4驱动 → 编译PaddleOCR v2.6 → 启动服务。首测结果：单张识别1240ms，超时55%。nvidia-smi类命令（hygon-smi）显示GPU利用率仅32%，HBM带宽占用率98%——瓶颈在内存带宽。
排查发现：PaddleOCR的DBNet检测头中，torch.nn.ConvTranspose2d（转置卷积）被编译为CPU计算，因海光HCC不支持该算子。临时解法是重写检测头，用nn.Upsample+nn.Conv2d替代，耗时2天。重测：980ms，仍超时。此时发现HCC的--enable-fp16-acc标志未启用，启用后降至820ms。但820ms仍不达标，且第37小时出现显存泄漏，服务崩溃。
结论：海光K100适合稳态推理，不适合高吞吐OCR，放弃。
4.2 Day4-7：全栈自研路线（昇腾910B）的精度攻坚
转向昇腾910B集群（4卡）。用MindSpore重写OCR模型，@ms_function标注所有函数。首测：单卡720ms，达标！但验证集精度仅89.3%（客户要求≥92.5%）。msprof报告显示，AscendResize算子在DBHead的上采样环节引入0.8%精度损失。
解法：放弃AscendResize，改用AscendConv2D+AscendPad手工实现双线性插值。我们推导出插值核系数公式，用BANG C风格写入MindSpore的Custom OP，耗时3天。重测：精度92.7%，延迟715ms。但第42小时，msprof捕获到GE（Graph Engine）模块的内存泄漏，原因是MindSpore 2.2的Dataset管道未正确释放SharedMemory。
解法：改用mindspore.dataset.GeneratorDataset，手动管理内存生命周期。最终：712ms，92.8%，稳定运行168小时。客户验收通过，但要求“必须提供海光K100备用方案”。
4.3 Day8-10：边缘推理路线（寒武纪思元270）的意外救场
客户临时增加需求：需在20台自助终端（ARM架构，无GPU）上部署轻量版OCR。寒武纪思元270 M.2模块（15W）成为唯一选择。用MagicMind编译PaddleOCR-Mobile，BANG C重写DBHead的DeformableConv2d（思元270不支持形变卷积），改用AscendConv2D模拟。耗时2天。
首测：单张识别1120ms，超时。mlu-profiler显示SRAM利用率100%，瓶颈在片上缓存不足。解法：将DBHead的特征图通道数从256减至128，精度损失0.3%，延迟降至780ms。但第19小时，终端因高温（>75℃）触发思元270的thermal throttle，频率降至500MHz，延迟飙升至1800ms。
解法：在BANG C代码中插入__mlu_barrier()指令，强制PE阵列在高温时进入低功耗idle状态，而非降频。最终：775ms，稳定运行240小时。客户惊喜：“没想到边缘端也能跑这么快”。
4.4 Day11-12：混合云训推路线（昆仑芯K200）的快速验证
为验证模型泛化性，用昆仑芯K200训练新数据集（10万张模糊身份证）。PaddlePaddle 2.5 + XPU编译，训练速度为A100的82%。但导出模型时，paddle2onnx生成的ONNX文件在昇腾atc工具中报错：Unsupported op type: paddle::operators::FusedBatchNormOp。
解法：改用PaddlePaddle的paddle.jit.save保存_pd_model格式，直接用昆仑芯paddle_lite_opt工具转换，跳过ONNX环节。耗时1天。验证：新模型在昇腾910B上精度提升0.5%，证明混合训练有效。
4.5 Day13：开源RISC-V路线（玄铁910）的可行性探底
客户CTO提出：“能否用RISC-V做纯国产OCR？”我们用TVM编译TinyOCR模型到玄铁910。实测：单张识别2100ms，功耗0.8W。perf分析显示，92%时间消耗在BF16软件模拟的__riscv_vfmul_vf_f16函数中。结论：RISC-V当前只适合超低功耗、容忍高延迟的场景，如智能电表，不适用于OCR。
最终交付：
- 主力系统：昇腾910B集群（4卡），712ms，92.8%精度；
- 备用系统：海光K100（2卡），820ms，91.5%精度（降级运行）；
- 边缘终端：寒武纪思元270 M.2模块（20台），775ms，90.2%精度；
- 训练平台：昆仑芯K200（2卡），加速新数据训练。
五条路线，各司其职，缺一不可。
5. 经验总结：给开发者的五条生存法则
干了这么多年国产AI芯片项目，我总结出五条血写的生存法则，不讲大道理，全是能救命的实操口诀：
5.1 法则一：永远先查Model Zoo，再写代码
国产芯片厂商的Model Zoo（如昇腾的modelzoo, 寒武纪的mlu-models）不是摆设，而是经过千锤百炼的“黄金样本”。一个ResNet50模型，在昇腾Model Zoo中已验证过137种输入尺寸、4种精度模式、5种batch_size组合。你花3天自己写的模型，大概率在第4天发现atc编译报错Unsupported shape: [1,3,224,224]——而Model Zoo里同名模型早已支持。我的做法：拿到需求，第一件事是去Model Zoo搜关键词，找到最接近的模型，然后git clone，只改最后几层分类头。省下的时间，够你喝三杯咖啡。
5.2 法则二：驱动版本号就是生命线
国产芯片驱动不是越新越好。昇腾CANN 6.3.RC修复了AscendMatMul的INT8溢出bug，但引入了AscendResize的坐标偏移；海光HCC 1.2.3.4解决了Windows 2016蓝屏，但HCC_ENABLE_FP16_ACC标志在1.2.3.5中被悄悄移除。我的硬盘里存着12个驱动版本的ISO镜像，每个都标着“2023-08-15-昇腾910B-PCIe4.0-无resize-bug”。上线前，必用md5sum核对驱动包哈希值——去年一次生产事故，就因运维同事误装了官网下载的“最新版”驱动，导致整个集群推理延迟翻倍。
5.3 法则三：量化不是终点，是起点
W8A8量化后，模型只是“能跑”，不是“能用”。必须做三件事：① 用校准数据集的10%做精度回归测试，误差>0.5%立即停线；② 用msprof/mlu-profiler看各算子延迟占比，找出TOP3瓶颈算子；③ 对TOP3算子做手工重写（如用AscendConv2D替代AscendResize）。我们有个项目，量化后精度掉2.1%，手工重写AscendSoftmax后，精度回升1.8%，这才是真正的“调优”。
5.4 法则四：日志比代码更重要
国产芯片的报错信息极其吝啬。atc报Error code: 5001，mlu-profiler报Segmentation fault (core dumped)，hygon-smi报Device status: Unknown。此时，唯一救命的是日志。我的标准动作：
- 启动前：
export ASCEND_SLOG_PRINT_TO_STDOUT=1（昇腾） - 启动中：
strace -f -e trace=ioctl,read,write -p $(pidof your_app) 2>&1 | tee strace.log - 崩溃后：
gdb your_app core，然后bt full
一份完整的strace日志，能让你在30分钟内定位到是驱动ioctl调用失败，还是用户态内存越界。
5.5 法则五：接受“不完美”，但要定义“可接受”
国产AI芯片永远达不到NVIDIA的成熟度。昇腾的msprof偶尔丢采样点，寒武纪的mlu-profiler在多卡时显示错误的PCIe带宽，海光的hygon-smi不支持--query参数。我的心态是：不追求100%完美，但要明确定义“可接受”的边界。例如，我们约定：昇腾集群的msprof采样丢失率<5%可接受；寒武纪多卡PCIe带宽显示误差<15%可接受；海光hygon-smi不支持--query，但hygon-smi -l能显示温度/功耗即可。把“不完美”转化为可量化的SLA，项目才能落地。
最后分享一个小技巧：每次新项目启动，我都会建一个README.md，第一行就写：“本项目使用的国产芯片技术栈：昇腾910B + CANN 6.3.RC + MindSpore 2.2.12 + 麒麟V10 SP1（内核4.19.90-23052.10）”。精确到小版本号，因为CANN 6.3.0和6.3.RC的atc行为可能完全不同。这行字，救过我三次命。
