1. 从一次模型适配说起国产算力生态的真实进展最近技术圈里讨论比较多的一件事就是深度求索团队的大模型在昇腾算力平台上完成了适配和优化。很多朋友看到新闻标题的第一反应是“又一个合作公告”但如果你真正在推理侧部署过模型就会知道这件事的分量远不止一纸公告那么简单。它意味着从模型权重、算子库、推理引擎到硬件调度这一整条链路开始有了一个可以实际跑通、并且性能可接受的国产化组合方案。我自己在过去一年多的时间里陆续在几种不同的算力平台上部署过开源大模型踩过的坑包括算子不支持导致回退到CPU、显存碎片化引发OOM、通信库版本不匹配导致多卡并行效率暴跌等等。所以当我看到这次适配的消息时第一反应不是兴奋而是想知道到底适配到了什么程度是能跑起来还是跑得好支持的是训练还是推理单卡还是多卡这些细节决定了它对普通开发者和企业用户的实际价值。这篇文章我想从一线部署的视角把这件事拆开来讲。核心关键词包括国产大模型、昇腾算力、推理部署、算子适配、多卡并行。适合正在做模型选型的技术负责人、需要做私有化部署的工程师以及对国产算力生态感兴趣但还没实际动手的开发者。我会尽量把原理讲清楚把操作步骤写具体把踩过的坑说明白让你看完之后能判断这套方案是否适合你的场景以及如果要用该怎么上手。2. 这件事到底解决了什么问题2.1 大模型部署的算力困局先说说背景。过去两年大模型的推理部署几乎被一种硬件生态垄断。不是说其他硬件不能用而是软件栈的成熟度差距太大。一个典型的推理链路包括模型权重加载、计算图优化、算子融合、内存管理、多卡通信、请求调度。每一个环节都需要硬件厂商提供对应的库和工具链支持。如果某个环节缺失你要么自己写算子要么回退到低效实现要么干脆换硬件。我去年帮一个团队做7B模型的私有化部署当时选了一款国产加速卡理论上算力够用但实际部署时发现注意力机制里的某个算子没有优化实现推理延迟比预期高了四倍。最后只能改模型结构绕开那个算子但精度又受了影响。这就是生态不成熟带来的真实代价——不是不能用而是用起来处处掣肘。2.2 适配的核心价值在哪里这次深度求索模型与昇腾平台的适配核心价值体现在三个层面。第一是算子层面的对齐。大模型里最吃算力的几个操作比如矩阵乘、注意力计算、归一化、激活函数都需要有对应的高效算子实现。适配工作意味着这些算子已经在昇腾上做了针对性优化而不是简单调用通用实现。这一点从推理吞吐的提升幅度可以间接验证。第二是推理引擎的集成。模型要跑起来需要一个推理引擎来管理计算图和内存。昇腾有自己的推理引擎深度求索的模型需要转换成引擎能识别的格式并且保证转换后的精度损失在可接受范围内。这一步的难点在于动态shape的处理和量化策略的兼容性。第三是多卡并行的支持。大模型单卡放不下是常态需要张量并行或流水线并行。这涉及到卡间通信库的配合以及并行策略与硬件拓扑的匹配。如果通信效率上不去加卡带来的收益会被通信开销吃掉。注意适配公告里通常不会写清楚具体支持到什么程度。你需要关注的是支持的是推理还是训练支持的模型规模上限是多少多卡并行的效率如何这些才是决定能否落地的关键。2.3 对普通开发者的实际影响你可能觉得这些是大厂才关心的事但实际影响会逐层传导。最直接的是如果你所在的公司有国产化要求或者你想用性价比更高的算力方案现在多了一个经过验证的选择。其次开源社区会基于这套组合做更多工具和教程降低后来者的上手门槛。最后竞争会推动整个生态进步最终受益的是所有需要算力的人。3. 核心细节拆解适配到底做了什么3.1 模型侧的准备权重转换与图优化深度求索的模型通常是基于主流深度学习框架训练的权重格式和计算图定义都遵循那套体系。要在昇腾上运行第一步是权重转换。这个过程不是简单的格式转换还涉及到算子映射——把原框架的算子映射到昇腾的算子库。我实际操作过的流程大致是这样的先用转换工具把模型导出成中间格式然后针对昇腾平台做图优化包括算子融合、常量折叠、内存复用规划。这里有个容易忽略的点动态shape的处理。大模型推理时输入长度是变化的如果推理引擎只支持固定shape要么每次变长都重新编译图要么padding到固定长度浪费算力。好的适配会支持动态shape或者至少支持有限范围的动态。# 权重转换的示意流程基于常见实践 # 1. 加载原始权重 # 2. 逐层映射到目标算子 # 3. 导出为目标平台格式 # 4. 校验数值精度精度校验这一步千万别省。我见过转换后某些层数值偏差累积导致输出完全不可用的情况。通常的做法是跑一组标准输入对比转换前后的输出差异确保在容忍范围内。3.2 算子优化性能的关键所在算子优化是适配工作中最耗时的部分。以注意力机制为例标准的实现包含多次矩阵乘和softmax如果每个操作单独调用中间结果的读写会消耗大量带宽。优化的做法是算子融合把多个操作合并成一个核函数减少内存访问。昇腾平台有自己的算子开发框架支持自定义算子。深度求索团队大概率是针对模型里的关键算子做了定制实现。从公开的性能数据看优化后的推理吞吐相比通用实现有显著提升这说明算子层面确实下了功夫。另一个关键是量化支持。大模型推理成本高量化是降本的重要手段。常见的量化方案包括INT8和INT4但量化会带来精度损失需要在精度和性能之间找平衡。适配工作是否包含量化方案的调优直接影响实际部署的成本。3.3 多卡并行通信是瓶颈大模型多卡部署通常采用张量并行把单个矩阵乘拆到多张卡上每张卡算一部分然后通过通信汇总结果。这种方式的瓶颈在通信——卡越多通信开销越大。昇腾平台有自己的集合通信库适配工作包括把并行策略映射到通信原语上以及优化通信与计算的重叠。我实测过的经验是如果通信和计算不能有效重叠四卡并行的效率可能只有单卡的三倍甚至更低。所以看适配效果时要关注多卡扩展效率这个指标。并行方式适用场景通信开销实现难度张量并行单层参数过大高中流水线并行层数多中高数据并行吞吐优先低低混合并行超大模型很高很高提示如果你部署的模型单卡能放下优先考虑数据并行做吞吐扩展实现简单且效率高。只有单卡放不下时才需要张量并行或流水线并行。3.4 推理引擎的调度策略推理引擎负责接收请求、组batch、调度计算、返回结果。大模型推理的特点是请求长度差异大如果调度策略不合理会出现长请求阻塞短请求的情况。好的推理引擎会做连续批处理把不同请求的动态合并提高算力利用率。适配工作在这一层的价值在于引擎能正确识别昇腾的硬件特性比如显存大小、计算单元数量从而做出更合理的调度决策。这部分通常是引擎自动完成的但你可以通过配置参数来调整比如最大batch size、显存预留比例等。4. 实操过程从零部署一个适配模型4.1 环境准备与依赖安装假设你拿到了一台搭载昇腾加速卡的服务器想部署深度求索的模型。第一步是装驱动和固件这一步必须严格按照官方文档的版本对应关系来。我踩过的坑是驱动版本和推理引擎版本不匹配导致初始化失败排查了半天才发现是版本问题。装完驱动后需要安装推理引擎和对应的Python接口。通常官方会提供一个安装脚本或者包管理命令。这里要注意的是Python版本和依赖库的兼容性建议用虚拟环境隔离。# 示意命令具体以官方文档为准 # 安装推理引擎 # pip install 推理引擎包 # 验证安装 # python -c import 推理引擎; print(推理引擎.__version__)环境变量也需要配置主要是库文件路径和日志级别。日志级别建议先设成INFO方便排查问题稳定后再调高。4.2 模型获取与转换模型权重可以从官方渠道获取。拿到权重后需要用转换工具转成推理引擎支持的格式。转换过程中有几个参数需要关注输入shape的范围、量化配置、输出节点名称。如果转换工具支持精度对比一定要开启确保转换前后输出一致。转换完成后建议先用小输入跑一遍确认能正常输出再进行完整测试。我习惯用几个典型长度的输入做冒烟测试比如短句、中等长度、接近最大长度观察延迟和显存占用。4.3 推理服务启动与压测启动推理服务时需要配置模型路径、监听端口、最大并发数、显存预留等参数。显存预留这个参数很关键留太少容易OOM留太多浪费显存。我的经验是预留10%到15%比较稳妥。启动后先用单请求测试确认功能正常。然后用压测工具模拟并发请求观察吞吐和延迟曲线。重点关注两个指标首token延迟和每token生成时间。首token延迟影响用户的第一印象每token生成时间决定整体响应速度。# 压测示意代码基于常见实践 # 构造不同长度的请求 # 并发发送 # 统计延迟分布和吞吐压测时要注意观察显存变化和温度。如果显存持续增长不释放可能有内存泄漏如果温度过高降频性能会波动。4.4 多卡配置与调优如果需要多卡部署配置会复杂一些。首先要确认卡间互联的拓扑是全连接还是环形这决定了通信效率。然后配置并行策略包括张量并行的切分方式和通信组初始化。启动多卡服务后重点观察扩展效率。理想情况下四卡吞吐是单卡的四倍但实际能达到三倍以上就不错了。如果扩展效率低检查通信是否与计算重叠以及batch size是否足够大以摊薄通信开销。注意多卡部署时任何一张卡出问题都会导致整个服务不可用。建议做好健康检查发现异常卡及时隔离。5. 常见问题与排查技巧实录5.1 模型加载失败最常见的原因是权重格式不匹配或文件损坏。排查步骤先确认转换工具版本和模型版本对应再检查权重文件完整性最后看日志里的具体报错。如果报的是算子不支持说明转换时映射失败需要检查算子映射表。另一个原因是显存不足。加载时如果显存不够会直接失败。解决办法是减少预留显存或者用更小的精度加载。5.2 推理结果异常如果输出乱码或重复首先检查精度。转换过程中的精度损失可能导致输出异常。可以对比原始框架的输出定位是哪一层开始出现偏差。如果是量化导致的尝试调整量化策略或改用更高精度。如果输出正常但延迟高检查是否触发了回退。有些算子如果没有优化实现会回退到低效路径。通过性能分析工具可以看到每个算子的耗时定位瓶颈。5.3 多卡通信超时多卡部署时通信超时是高频问题。原因可能是网络配置错误、通信组初始化失败、或者某张卡负载过高。排查时先确认所有卡状态正常再检查通信库的日志。如果是偶发超时可能是负载不均调整并行策略或batch分配。问题现象可能原因排查方法解决思路加载失败格式不匹配检查转换日志重新转换输出异常精度损失逐层对比调整量化延迟高算子回退性能分析替换算子通信超时负载不均检查卡状态调整并行显存泄漏内存未释放监控显存更新引擎5.4 性能不达预期如果实测性能远低于官方数据先确认测试条件是否一致。batch size、输入长度、并发数都会影响结果。然后检查是否有后台进程占用算力以及散热是否导致降频。最后看推理引擎的配置是否最优比如是否开启了连续批处理、是否用了最优的算子实现。我个人的经验是官方数据通常是在理想条件下测的实际部署能达到七八成就算不错。不要期望完全复现而是关注是否满足你的业务需求。6. 这套方案适合谁不适合谁6.1 适合的场景如果你有国产化要求或者想降低对单一硬件生态的依赖这套方案值得认真评估。特别是推理场景适配成熟度比训练高落地风险相对小。对于7B到70B级别的模型如果单卡或四卡能覆盖部署难度可控。另外如果你在做模型选型可以把这套组合作为一个备选方案和现有方案做对比测试。测试时重点关注精度、延迟、吞吐、稳定性四个维度。6.2 需要谨慎的场景超大模型的训练场景目前适配成熟度可能还不够。训练对通信和算子的要求比推理高得多生态完善需要时间。如果你的模型超过百B级别建议先做小规模验证。对延迟极度敏感的场景也要谨慎。虽然适配做了优化但和成熟生态相比可能还有差距。建议先用真实业务流量做测试确认满足SLA再上线。6.3 后续可以关注的方向一是量化方案的持续优化这直接关系到部署成本。二是更多模型规模的适配覆盖从边缘到云端的全场景。三是工具链的完善降低上手门槛。我会持续关注这些方向的进展有新的实操经验再分享。我在实际部署中的体会是国产算力生态的进步是肉眼可见的从“能跑”到“跑得好”的转变正在发生。但选型时还是要回归业务需求不要为了国产化而国产化也不要因为偏见而错过一个可用的方案。实测数据比任何宣传都有说服力。 
长河君 · 2026/10/20 16:07:20 · 阅读 1.2k 国产大模型昇腾算力适配实战：推理部署与算子优化全解析
1. 从一次模型适配说起国产算力生态的真实进展最近技术圈里讨论比较多的一件事就是深度求索团队的大模型在昇腾算力平台上完成了适配和优化。很多朋友看到新闻标题的第一反应是“又一个合作公告”但如果你真正在推理侧部署过模型就会知道这件事的分量远不止一纸公告那么简单。它意味着从模型权重、算子库、推理引擎到硬件调度这一整条链路开始有了一个可以实际跑通、并且性能可接受的国产化组合方案。我自己在过去一年多的时间里陆续在几种不同的算力平台上部署过开源大模型踩过的坑包括算子不支持导致回退到CPU、显存碎片化引发OOM、通信库版本不匹配导致多卡并行效率暴跌等等。所以当我看到这次适配的消息时第一反应不是兴奋而是想知道到底适配到了什么程度是能跑起来还是跑得好支持的是训练还是推理单卡还是多卡这些细节决定了它对普通开发者和企业用户的实际价值。这篇文章我想从一线部署的视角把这件事拆开来讲。核心关键词包括国产大模型、昇腾算力、推理部署、算子适配、多卡并行。适合正在做模型选型的技术负责人、需要做私有化部署的工程师以及对国产算力生态感兴趣但还没实际动手的开发者。我会尽量把原理讲清楚把操作步骤写具体把踩过的坑说明白让你看完之后能判断这套方案是否适合你的场景以及如果要用该怎么上手。2. 这件事到底解决了什么问题2.1 大模型部署的算力困局先说说背景。过去两年大模型的推理部署几乎被一种硬件生态垄断。不是说其他硬件不能用而是软件栈的成熟度差距太大。一个典型的推理链路包括模型权重加载、计算图优化、算子融合、内存管理、多卡通信、请求调度。每一个环节都需要硬件厂商提供对应的库和工具链支持。如果某个环节缺失你要么自己写算子要么回退到低效实现要么干脆换硬件。我去年帮一个团队做7B模型的私有化部署当时选了一款国产加速卡理论上算力够用但实际部署时发现注意力机制里的某个算子没有优化实现推理延迟比预期高了四倍。最后只能改模型结构绕开那个算子但精度又受了影响。这就是生态不成熟带来的真实代价——不是不能用而是用起来处处掣肘。2.2 适配的核心价值在哪里这次深度求索模型与昇腾平台的适配核心价值体现在三个层面。第一是算子层面的对齐。大模型里最吃算力的几个操作比如矩阵乘、注意力计算、归一化、激活函数都需要有对应的高效算子实现。适配工作意味着这些算子已经在昇腾上做了针对性优化而不是简单调用通用实现。这一点从推理吞吐的提升幅度可以间接验证。第二是推理引擎的集成。模型要跑起来需要一个推理引擎来管理计算图和内存。昇腾有自己的推理引擎深度求索的模型需要转换成引擎能识别的格式并且保证转换后的精度损失在可接受范围内。这一步的难点在于动态shape的处理和量化策略的兼容性。第三是多卡并行的支持。大模型单卡放不下是常态需要张量并行或流水线并行。这涉及到卡间通信库的配合以及并行策略与硬件拓扑的匹配。如果通信效率上不去加卡带来的收益会被通信开销吃掉。注意适配公告里通常不会写清楚具体支持到什么程度。你需要关注的是支持的是推理还是训练支持的模型规模上限是多少多卡并行的效率如何这些才是决定能否落地的关键。2.3 对普通开发者的实际影响你可能觉得这些是大厂才关心的事但实际影响会逐层传导。最直接的是如果你所在的公司有国产化要求或者你想用性价比更高的算力方案现在多了一个经过验证的选择。其次开源社区会基于这套组合做更多工具和教程降低后来者的上手门槛。最后竞争会推动整个生态进步最终受益的是所有需要算力的人。3. 核心细节拆解适配到底做了什么3.1 模型侧的准备权重转换与图优化深度求索的模型通常是基于主流深度学习框架训练的权重格式和计算图定义都遵循那套体系。要在昇腾上运行第一步是权重转换。这个过程不是简单的格式转换还涉及到算子映射——把原框架的算子映射到昇腾的算子库。我实际操作过的流程大致是这样的先用转换工具把模型导出成中间格式然后针对昇腾平台做图优化包括算子融合、常量折叠、内存复用规划。这里有个容易忽略的点动态shape的处理。大模型推理时输入长度是变化的如果推理引擎只支持固定shape要么每次变长都重新编译图要么padding到固定长度浪费算力。好的适配会支持动态shape或者至少支持有限范围的动态。# 权重转换的示意流程基于常见实践 # 1. 加载原始权重 # 2. 逐层映射到目标算子 # 3. 导出为目标平台格式 # 4. 校验数值精度精度校验这一步千万别省。我见过转换后某些层数值偏差累积导致输出完全不可用的情况。通常的做法是跑一组标准输入对比转换前后的输出差异确保在容忍范围内。3.2 算子优化性能的关键所在算子优化是适配工作中最耗时的部分。以注意力机制为例标准的实现包含多次矩阵乘和softmax如果每个操作单独调用中间结果的读写会消耗大量带宽。优化的做法是算子融合把多个操作合并成一个核函数减少内存访问。昇腾平台有自己的算子开发框架支持自定义算子。深度求索团队大概率是针对模型里的关键算子做了定制实现。从公开的性能数据看优化后的推理吞吐相比通用实现有显著提升这说明算子层面确实下了功夫。另一个关键是量化支持。大模型推理成本高量化是降本的重要手段。常见的量化方案包括INT8和INT4但量化会带来精度损失需要在精度和性能之间找平衡。适配工作是否包含量化方案的调优直接影响实际部署的成本。3.3 多卡并行通信是瓶颈大模型多卡部署通常采用张量并行把单个矩阵乘拆到多张卡上每张卡算一部分然后通过通信汇总结果。这种方式的瓶颈在通信——卡越多通信开销越大。昇腾平台有自己的集合通信库适配工作包括把并行策略映射到通信原语上以及优化通信与计算的重叠。我实测过的经验是如果通信和计算不能有效重叠四卡并行的效率可能只有单卡的三倍甚至更低。所以看适配效果时要关注多卡扩展效率这个指标。并行方式适用场景通信开销实现难度张量并行单层参数过大高中流水线并行层数多中高数据并行吞吐优先低低混合并行超大模型很高很高提示如果你部署的模型单卡能放下优先考虑数据并行做吞吐扩展实现简单且效率高。只有单卡放不下时才需要张量并行或流水线并行。3.4 推理引擎的调度策略推理引擎负责接收请求、组batch、调度计算、返回结果。大模型推理的特点是请求长度差异大如果调度策略不合理会出现长请求阻塞短请求的情况。好的推理引擎会做连续批处理把不同请求的动态合并提高算力利用率。适配工作在这一层的价值在于引擎能正确识别昇腾的硬件特性比如显存大小、计算单元数量从而做出更合理的调度决策。这部分通常是引擎自动完成的但你可以通过配置参数来调整比如最大batch size、显存预留比例等。4. 实操过程从零部署一个适配模型4.1 环境准备与依赖安装假设你拿到了一台搭载昇腾加速卡的服务器想部署深度求索的模型。第一步是装驱动和固件这一步必须严格按照官方文档的版本对应关系来。我踩过的坑是驱动版本和推理引擎版本不匹配导致初始化失败排查了半天才发现是版本问题。装完驱动后需要安装推理引擎和对应的Python接口。通常官方会提供一个安装脚本或者包管理命令。这里要注意的是Python版本和依赖库的兼容性建议用虚拟环境隔离。# 示意命令具体以官方文档为准 # 安装推理引擎 # pip install 推理引擎包 # 验证安装 # python -c import 推理引擎; print(推理引擎.__version__)环境变量也需要配置主要是库文件路径和日志级别。日志级别建议先设成INFO方便排查问题稳定后再调高。4.2 模型获取与转换模型权重可以从官方渠道获取。拿到权重后需要用转换工具转成推理引擎支持的格式。转换过程中有几个参数需要关注输入shape的范围、量化配置、输出节点名称。如果转换工具支持精度对比一定要开启确保转换前后输出一致。转换完成后建议先用小输入跑一遍确认能正常输出再进行完整测试。我习惯用几个典型长度的输入做冒烟测试比如短句、中等长度、接近最大长度观察延迟和显存占用。4.3 推理服务启动与压测启动推理服务时需要配置模型路径、监听端口、最大并发数、显存预留等参数。显存预留这个参数很关键留太少容易OOM留太多浪费显存。我的经验是预留10%到15%比较稳妥。启动后先用单请求测试确认功能正常。然后用压测工具模拟并发请求观察吞吐和延迟曲线。重点关注两个指标首token延迟和每token生成时间。首token延迟影响用户的第一印象每token生成时间决定整体响应速度。# 压测示意代码基于常见实践 # 构造不同长度的请求 # 并发发送 # 统计延迟分布和吞吐压测时要注意观察显存变化和温度。如果显存持续增长不释放可能有内存泄漏如果温度过高降频性能会波动。4.4 多卡配置与调优如果需要多卡部署配置会复杂一些。首先要确认卡间互联的拓扑是全连接还是环形这决定了通信效率。然后配置并行策略包括张量并行的切分方式和通信组初始化。启动多卡服务后重点观察扩展效率。理想情况下四卡吞吐是单卡的四倍但实际能达到三倍以上就不错了。如果扩展效率低检查通信是否与计算重叠以及batch size是否足够大以摊薄通信开销。注意多卡部署时任何一张卡出问题都会导致整个服务不可用。建议做好健康检查发现异常卡及时隔离。5. 常见问题与排查技巧实录5.1 模型加载失败最常见的原因是权重格式不匹配或文件损坏。排查步骤先确认转换工具版本和模型版本对应再检查权重文件完整性最后看日志里的具体报错。如果报的是算子不支持说明转换时映射失败需要检查算子映射表。另一个原因是显存不足。加载时如果显存不够会直接失败。解决办法是减少预留显存或者用更小的精度加载。5.2 推理结果异常如果输出乱码或重复首先检查精度。转换过程中的精度损失可能导致输出异常。可以对比原始框架的输出定位是哪一层开始出现偏差。如果是量化导致的尝试调整量化策略或改用更高精度。如果输出正常但延迟高检查是否触发了回退。有些算子如果没有优化实现会回退到低效路径。通过性能分析工具可以看到每个算子的耗时定位瓶颈。5.3 多卡通信超时多卡部署时通信超时是高频问题。原因可能是网络配置错误、通信组初始化失败、或者某张卡负载过高。排查时先确认所有卡状态正常再检查通信库的日志。如果是偶发超时可能是负载不均调整并行策略或batch分配。问题现象可能原因排查方法解决思路加载失败格式不匹配检查转换日志重新转换输出异常精度损失逐层对比调整量化延迟高算子回退性能分析替换算子通信超时负载不均检查卡状态调整并行显存泄漏内存未释放监控显存更新引擎5.4 性能不达预期如果实测性能远低于官方数据先确认测试条件是否一致。batch size、输入长度、并发数都会影响结果。然后检查是否有后台进程占用算力以及散热是否导致降频。最后看推理引擎的配置是否最优比如是否开启了连续批处理、是否用了最优的算子实现。我个人的经验是官方数据通常是在理想条件下测的实际部署能达到七八成就算不错。不要期望完全复现而是关注是否满足你的业务需求。6. 这套方案适合谁不适合谁6.1 适合的场景如果你有国产化要求或者想降低对单一硬件生态的依赖这套方案值得认真评估。特别是推理场景适配成熟度比训练高落地风险相对小。对于7B到70B级别的模型如果单卡或四卡能覆盖部署难度可控。另外如果你在做模型选型可以把这套组合作为一个备选方案和现有方案做对比测试。测试时重点关注精度、延迟、吞吐、稳定性四个维度。6.2 需要谨慎的场景超大模型的训练场景目前适配成熟度可能还不够。训练对通信和算子的要求比推理高得多生态完善需要时间。如果你的模型超过百B级别建议先做小规模验证。对延迟极度敏感的场景也要谨慎。虽然适配做了优化但和成熟生态相比可能还有差距。建议先用真实业务流量做测试确认满足SLA再上线。6.3 后续可以关注的方向一是量化方案的持续优化这直接关系到部署成本。二是更多模型规模的适配覆盖从边缘到云端的全场景。三是工具链的完善降低上手门槛。我会持续关注这些方向的进展有新的实操经验再分享。我在实际部署中的体会是国产算力生态的进步是肉眼可见的从“能跑”到“跑得好”的转变正在发生。但选型时还是要回归业务需求不要为了国产化而国产化也不要因为偏见而错过一个可用的方案。实测数据比任何宣传都有说服力。