---
title: 昇腾博客 - 昇腾AI技术深度解析与交流分享 | 昇腾社区
description: 昇腾博客是昇腾AI开发者社区的技术分享平台，提供关于CANN、MindSpore、模型训练、推理优化、硬件配置等领域的深度技术文章、实践案例与行业洞察。加入我们，获取最新的昇腾AI技术动态，学习开发者实践经验，探索AI创新的无限可能。
keywords: 昇腾博客，昇腾AI技术文章，CANN技术解析，MindSpore实践分享，AI模型训练案例，模型推理优化指南，昇腾硬件配置教程，AI开发者实践，深度学习技术分享，Ascend C算子开发
url: https://www.hiascend.com/developer/blog
section: (其他)
---

# 昇腾博客 - 昇腾AI技术深度解析与交流分享 | 昇腾社区

URL: https://www.hiascend.com/developer/blog
描述: 昇腾博客是昇腾AI开发者社区的技术分享平台，提供关于CANN、MindSpore、模型训练、推理优化、硬件配置等领域的深度技术文章、实践案例与行业洞察。加入我们，获取最新的昇腾AI技术动态，学习开发者实践经验，探索AI创新的无限可能。
关键词: 昇腾博客，昇腾AI技术文章，CANN技术解析，MindSpore实践分享，AI模型训练案例，模型推理优化指南，昇腾硬件配置教程，AI开发者实践，深度学习技术分享，Ascend C算子开发

我的关注全部昇腾主版块Deepseek专区Ascend CCANNMindIEMindSporeMindStudioModelZoo应用使能Atlas 200I DK A2Atlas 200I A2香橙派昇腾硬件Atlas 200I Pro

...

全部类型

精华

热门

推荐

最新发布

最新回复

最多回复

顶

Atlas 350 SuperSuite UBL4查表反向算子如何达到业界2倍性能？

新人帖

算子

第一章 引言 —— 为什么做这件事 1.1 推荐系统的算力黑洞 现代推荐系统离不开 Embedding 层，Embedding 表动辄千万甚至上亿行，每次训练迭代都要完成海量反向传播计算。这是推荐系统训练的头号算力瓶颈，原因有三： - GM 带宽饥渴：高稀疏 key 重复场景下，同一个 key 被不同样本共享，GM 读写量膨胀数倍。 - 原子操作风暴：多个样本共享同一个 key 时，所有线程争抢同一个 GM 地址的更新权，流水线停滞。 - 优化器计算碎片化：Adagrad、Adam、SGD 等优化器逐行逐元素计算，无法充分利用向量引擎并行能力。 1.2 目标 Meta 开源的 [fbgemm](https://github.com/pytorch/FBGEMM) 是推荐系统 Embedding 训练的事实标准，在Atlas 350 SuperSuite UBL4超节点套件 上达到业界 + fbgemm的 2 倍性能。 Atlas 350 SuperSuite UBL4超节点套件 提供了独特的硬件优势——大容量 UB、强大的 Vector 引擎、灵活的 SIMT 编程模型，使算法层面优化成为可能。我们从"减少 GM 原子竞争"、"消除冗余 GM 读写"和"批量向量化计算"三个方向出发，进行了系统性架构重构。 第二章 整体架构 2.1 端到端数据流 图 1：Embedding 反向传播端到端数据流 Pipeline 2.2 Workspace 哈希桶原子标记去重机制 同一个 batch 内多条样本可能引用相同 hash key，不做去重会导致冗余计算和写入冲突。我们的方案是基于哈希桶的原子状态标记去重机制：将 hash key 映射为 Workspace 数组下标，利用 GM AtomicCas 进行原子竞争仲裁，实现跨 Block 的分布式去重。 图 2：Workspace 哈希桶原子标记去重机制 Workspace 分为两个连续区域： 区域 地址范围 内容 说明 标记位区 workspace[0 .. totalHashSize) 每个 hash key 对应一个 uint32_t 标记位 CLEAR(0) = 空闲，NEED_UPDATE(1) = 已被认领 扩展索引区 workspace[totalHashSize .. totalHashSize + N×5]

zxorange321

1天前

12

0

精

荐

热

顶

vLLM-Ascend安装部署类问题踩坑分享（2026.8.12更新）

环境部署模型推理问题咨询困惑答疑

Q1：vLLM-Ascend文档在哪里看？镜像在哪下载？选择什么版本的镜像？ 问题描述： vLLM-Ascend文档在哪里看？支持哪些模型部署？有相关使用教程吗？在哪下载镜像使用呢？ 解决方案： （1）vLLM-Ascend文档中包含快速入门、支持模型列表和模型部署教程等相关内容 vLLM-Ascend文档：https://docs.vllm.ai/projects/ascend/zh-cn/latest/ （2）vLLM-Ascend建议使用最新发布候选（RC）版本或最新正式版本（具体情况视模型的适配版本而定） vLLM-Ascend镜像：https://quay.io/repository/ascend/vllm-ascend?tab=tags Q2：vLLM-Ascend部署模型，加载权重时卡住。 问题描述： 使用vLLM-Ascend部署模型，在拉起服务时未报错，但一直卡在权重加载阶段。 解决方案： 1.临时方案： （1）在启动参数中添加：--safetensors-load-strategy eager； （2）为避免启动超时，增加环境变量：export VLLM_ENGINE_READY_TIMEOUT_S=100000。 2.长期方案： （1）升级HDK： ●26 系列——升级26.0.RC3 及后续版本； ●25 系列——25.5.3 或更高版本。 （2）系统内核变更： ●升级内核：部署已合入修复补丁的内核版本，参考：https://gitee.com/openeuler/kernel/pulls/18855/files ●降级内核：将内核版本回退至 5.19 以下版本。 Q3：A2双机直连，vLLM-Ascend部署模型开启专家并行报错：call aclnnMoeDistributeDispatchV4 failed 问题描述： 基于A2双机直连，使用vLLM-Ascend部署GLM5，报错call aclnnMoeDistributeDispatchV4 failed, error code is 561000，专家并行后，成功拉起服务 解决方案： 在vllm_ascend/ascend_forward_context.py中，将_select_a2_moe_comm_method函数的返回（即通信算子）强行设置为MoECommType.AL

绿豆饼

3天前

271

2

精

荐

顶

昇腾7月精选博文

Atlas 200 AI 加速模块Ascend C

版块 昵称 帖子名称及链接 （点击名称查看帖子详情） Ascend C ddjikongzhongxin 昇思 ACL 模型 Host 异步调度原理与代码实现 xuexiaoliding 昇思 AscendCL：aclrtSetDevice 指定运算 Device 昇思 AscendCL：内存直接加载单算子模型实战 崇理 【Ascend C实战】打比赛摸出来的算子开发经验，从入门到性能翻倍 Atlas 200I A2 hgc Atlas 200I A2启动介质分析与Debian操作系统移植 Atlas 200I Pro 崇理 Atlas 200I Pro 上跑 YOLOv5：从烧录镜像到 OM 推理的一次完整记录 Atlas 200I Pro 边缘推理部署调优实战笔记 Deepseek专区 Yeats_Liao DeepSeek-V4-w8a8 在昇腾 A2 上 PD 分离部署：吞吐提升 2.8 倍的完整实操指南 MindIE ajjjxl MindIE SD 关键特性：扩散模型动态更新参数 崇理 【MindIE实战】打昇腾大赛踩坑记录：从零把Qwen2推理速度干到原生3倍 昇腾主版块 崇理 【昇腾实战】从入门到拿奖，我用三个月啃下了昇腾大模型推理优化 hid_btfyg1lorhjtiif 常见错误码（如E1001， E2001）深度解析与根因排查流程 往期精选内容推荐： ●昇腾6月精选博文：点击查看 ●昇腾5月精选博文：点击查看 ●昇腾4月精选博文：点击查看 ●昇腾3月精选博文：点击查看

社区博客小助手

4天前

145

0

精

荐

热

顶

昇腾产品模型配套指南

新人帖

PyTorch模型推理AI昇腾硬件

引言 本文档汇总昇腾硬件平台支持部署的模型全量适配信息，并按主流推理引擎（vLLM-Ascend、MindIE、SGLang）分类说明其硬件要求、版本匹配及部署实践 一、模型适配资源查询矩阵 查询渠道 定位说明 官方入口 昇腾模型查询助手 按推理引擎及版本精准查询充分测试验证过的适配模型 昇腾模型查询助手 昇腾模型生态全景平台 基于模型视角的全量适配生态，按模型系列和应用场景对模型分类 昇腾模型生态全景平台 框架官方支持矩阵 直接查看各推理引擎的版本兼容性与特性支持清单 vLLM-Ascend：vLLM-Ascend模型支持列表 MindIE：MindIE模型支持列表 SGLang：SGLang模型支持列表 Ascend-SACT 支持按多模态、自然语言处理等类别查看该团队的模型适配项目 Ascend-SACT模型适配说明 💡建议： ①优先通过“昇腾模型查询助手”按目标引擎筛选，若需了解该引擎的最新全量适配模型情况，可查看该框架的模型支持矩阵（见上表） ②若您设备的NPU卡与已支持硬件NPU型号一致（例如：300I Duo的NPU为310P），可参考对应硬件的部署方案尝试部署，但无法保证非标准型号 100% 兼容。 二、推理引擎适配信息 2.1 vLLM-Ascend ●支持硬件：https://docs.vllm.ai/projects/ascend/zh-cn/latest/quick_start.html 例如： ●模型支持矩阵：vLLM-Ascend模型支持列表 📌 注：矩阵中可根据硬件型号进行适配模型切换（如下图），查看特性支持情况，其中✅表示官方充分验证过的适配模型。 2.2 MindIE ●支持硬件：Atlas 300I Duo、Atlas 800I A2、Atlas 800 I A3（当前300I Pro，300V，300V Pro官方无明确支持，可参考300I Duo的部署教程进行部署） ●模型支持矩阵：MindIE模型支持列表 2.3 SGLang ●支持硬件：仅支持Atlas 800I A2推理系列（Atlas 800I A2）和Atlas 800I A3推理系列（Atlas 800I A3） ●模型支持矩阵：SGLang模型支持列表 ●SGLang文档：https://docs.sglang.io/docs/hardware-platfo

绿豆饼

08/05

469

4

荐

热

顶

DeepSeek-V4-w8a8 在昇腾 A2 上 PD 分离部署：吞吐提升 2.8 倍的完整实操指南

环境部署AI昇腾硬件

DeepSeek-V4 发布后，MoE（混合专家）架构的推理部署成为昇腾社区最热的话题之一。我们在 Atlas 800I A2（昇腾 910B，64GB HBM × 8）上部署 DeepSeek-V4-w8a8 模型时，PD 混部模式下单次请求的 Prefill 阶段耗时高达 15 秒（8K 输入），Decode 阶段的 TTFT（Time To First Token）波动超过 200%，严重影响了多轮对话场景下的用户体验。本文记录了我们将部署模式从 PD 混部切换为 PD 分离（Prefill 和 Decode 拆分为独立服务）的完整过程，最终实现吞吐提升 2.8 倍、TTFT P99 波动从 200% 降至 15%。（注：本机 8 卡仅适合承载混部的一份权重，需配合 W4A8 等激进量化；PD 分离涉及两份权重，真实落地需跨节点扩展，详见下文显存核算。） 一、现象与告警 业务为内部 AI 助手平台，基于 DeepSeek-V4-w8a8（671B 总参数 / 37B 激活参数，MoE 架构），支持 128K 上下文。需注意：单机 8 卡（共 512GB HBM）连一份 671B-W8A8 权重（约 671GB）都装不下，混部需 W4A8 等激进量化，PD 分离需要两份权重、至少两组各 8 卡（共 16 卡）跨节点。下文为讲清原理先用 4+4 作架构示意，真实 671B 部署请按文末显存核算调整卡数。日均请求 5 万次，平均输入 2K token，平均输出 512 token。 上线 PD 混部模式（vLLM-Ascend 0.18.0，Prefill 和 Decode 共享同一组 NPU 卡）后，连续出现三类异常： 1.TTFT 抖动严重：当系统中同时存在多个长输入请求的 Prefill 和大量短请求的 Decode 时，Prefill 的高内存占用挤占了 Decode 的计算资源。P50 TTFT 为 1.2s，但 P99 飙升至 8.5s，波动超过 200%； 2.吞吐上不去：8 卡混部模式下，实测吞吐约 1800 tokens/s，AICORE 利用率仅 45%，大量算力在 Prefill/Decode 切换的空闲期被浪费； 3.显存碎片化：MoE 模型的专家路由导致不同请求激活的专家不同，KV Cache 的显存分配模式不规律，vLLM 的 Paged

Yeats_Liao

07/24

396

2

荐

顶

昇思 ACL 模型 Host 异步调度原理与代码实现

Ascend C

一、Host 异步调度核心原理 昇思 MindSpore 对接 CANN ACL 时，Host 异步调度是高并发推理核心方案，区别于同步阻塞aclmdlExecute，采用aclmdlExecuteAsync下发推理任务至 NPU Stream 队列，Host CPU 无需阻塞等待 Device 计算，可并行处理数据预处理、业务逻辑、多流任务调度，大幅提升吞吐。 1. 核心组件 Stream：任务队列，异步内存拷贝、推理、回调全部挂载同一 Stream 串行执行； Callback 回调线程：独立线程调用aclrtProcessReport阻塞监听任务完成事件，通过aclrtSubscribeReport绑定 Stream，推理结束自动触发回调处理结果； 异步数据流：aclrtMemcpyAsync异步 Host<->Device 数据搬运，无 CPU 等待； 任务上下文：封装输入输出 Dataset、内存指针、业务标识，透传给回调函数区分多批次推理结果。 2. 完整执行链路 ACL 初始化→创 Context/Stream→创建回调监听线程→加载 OM 模型→批量预处理→异步拷贝 Host2Device→异步下发推理ExecuteAsync→aclrtLaunchCallback挂载回调任务→Host 继续处理下一批数据→Device 推理完成后唤醒回调线程→回调内异步拷贝 Device2Host、后处理、释放临时内存→循环调度→程序结束销毁全部资源。 同步推理会阻塞 CPU，单卡并发 QPS 极低；Host 异步调度实现计算、数据拷贝、业务处理三线并行，适配视频流、多请求在线推理场景。下文提供 C++ 完整可运行代码，覆盖全流程异步调度逻辑。 二、完整 C++ 异步调度代码 cpp 运行 #include "acl/acl.h" #include "acl/acl_rt.h" #include #include #include #include #include // 全局常量配置 #define DEVICE_ID 0 #define MODEL_PATH "./resnet50.om" #define CALLBACK_TIMEOUT 1000 // 回调监听超时ms #define INPUT_SIZE 1*3*224*224 // resnet50输入

ddjikongzhongxin

07/19

208

0

荐

顶

Atlas 200I Pro 上跑 YOLOv5：从烧录镜像到 OM 推理的一次完整记录

Atlas 200 DK 开发者套件Atlas 200I DK A2 开发者套件

板子拿到手先别急着写代码，Atlas 200I Pro 这套东西，环境一步没对后面全白搭。我把完整流程走了一遍，把每个会卡住的地方都记下来了，照着做基本能一次跑通。 一、硬件和镜像准备 Atlas 200I Pro 开发套件核心是 Ascend 310P 处理器，板载 8GB LPDDR4X，对外给了千兆网口、USB、HDMI 和一组 GPIO。推理算力对 YOLOv5s 这种级别的网络完全够用，单路 640×640 推理能稳在 30 FPS 以上。 你需要准备的东西： ●一张至少 32GB 的 Micro SD 卡，读写速度尽量上 U3 / V30。别用那种几块钱的杂牌卡，后面烧录和运行时 IO 瓶颈会非常明显。 ●一根网线，板子和开发机直连最省事。 ●5V / 4A 以上的独立电源。USB 供电口带不动整块板子，长时间推理会莫名重启。 官方提供的系统镜像是 Ubuntu 22.04（aarch64），驱动和固件已经打进去了，所以不用单独装 driver / firmware。镜像解压后是一个 .img 文件。 二、烧录 Windows 下用 balenaEtcher 或者 Win32DiskImager 都行，选对盘符直接刷。有个细节：刷完第一次别急着拔卡，等写入校验走完。我第一次就是没等校验完强行拔卡，开机直接进 emergency mode，又重刷了一遍。 刷好后把卡插进板子，接电源，接网线到开发机。电源灯常亮、网口灯闪就说明起来了。 三、网络与首次登录 开发机和板子直连时，把开发机网卡手动设成固定 IP，例如 192.168.137.100 / 24。板子的默认地址看镜像文档，不同批次镜像默认地址不一样，以你手里的镜像说明为准。我这台是 192.168.137.100。ssh HwHiAiUser@192.168.137.100 默认密码一般是 HwHiAiUser 或者 Mind@123。登进去第一件事改密码，顺手把 sudo 配好，后面装 CANN 要 root 权限。 确认一下驱动状态：npu-smi info 能正常打出芯片信息，说明驱动没问题，可以往下走。 四、装 CANN Atlas 200I Pro 上做开发，板上直接装 toolkit 就行，不用搞 x86 交叉编译那一套。需要两个包： ●Ascend-cann-toolkit_{版本}_l

崇理

07/15

50

0

荐

顶

Atlas 200I Pro 边缘推理部署调优实战笔记

Atlas 200 AI 加速模块Atlas 200 DK 开发者套件

一、写在前面 最近在做一个边缘侧的多路视频分析项目，板子用的是 Atlas 200I Pro。之前只在 310P 的 PCIe 卡上跑过模型，真正把整套 pipeline 压到这个 SoC 模块上的时候，还是踩了不少坑。这里整理一下从环境搭建到性能调优的完整过程，都是实际跑出来的结论，不是搬 datasheet。 二、硬件架构先理清楚 很多人上来直接装环境跑模型，连算力构成都没搞明白，调优全靠瞎试。先把 200I Pro 的底子说清楚： ●AI Core：昇腾 310P 芯片，内置 10 个 AI Core，FP16 算力 22 TOPS。注意是 10 个不是 8 个，和早期 310 不一样。 ●CPU 部分：集成的是 8 核 ARM Cortex-A55，主频最高 2.0 GHz。别指望这颗 CPU 干重活，预处理尽量往 DVPP 和 AI Core 上 offload。 ●DVPP：硬件编解码 + 图像预处理单元，支持 JPEG 编解码、VPC 缩放裁剪色域转换、PNG 解码。这部分是调优关键，很多人 CPU 瓶颈都卡在这里。 ●内存：LPDDR4X，片上统一内存架构，意味着 Host 和 Device 之间没有 PCIe 拷贝开销。这是 200I Pro 对比 PCIe 加速卡最大的优势之一，但很多人写法还是按 PCIe 的习惯来，白白浪费了零拷贝的特性。 三、环境部署的几个坑 3.1 固件与驱动版本匹配 官方给的固件包和驱动包版本号必须严格对应，差一个小版本都可能出问题。最常见的现象是 npu-smi 能查到卡，但模型加载直接报内部错误。建议直接用完整的驱动固件一体包，不要分开升级。 另外，内核版本要注意。如果自己编译过内核，缺了某些配置项驱动是加载不起来的。最容易漏的是 CONFIG_CMA 和 CONFIG_DMA_SHARED_BUFFER，CMA 的预留大小也得够，默认值有时候跑大模型会报内存不足。 3.2 容器部署注意事项 如果用 Docker 部署，设备映射别只挂 /dev/davinci0。完整的设备节点包括 davinci_manager、hisi_hpre、hisi_sec 等等，少一个算子运行就会异常。最稳妥的方式是直接用 --device /dev/davinci_manager --device /dev/hisi_hpre 这样逐个

崇理

07/11

29

1

登录后可发布博客

登录

官方技术文章查看更多

vLLM流式Function Call工具调用内容缺失问题排查与解决

Atlas 800I A2 物理机场景下算力切分导致业务拉起失败

Atlas 200T A2 Box16 多机推理部署中 MindIE 启动失败

双机容器场景下 HCCL_Test 执行报错 "No such file or directory"

明星创作榜查看更多

hw_wihudnz.

关注

椰椰泡鲁达

关注

刘

刘喜强

关注

C

ccchhh

关注

H

hw_baobao

关注

H

hid_tqqsfahmh2sk2u0

关注

Z

zhoujl5071

关注

D

deeplearns

关注

H

hid_i_reekzky5k_fmx

关注

昇腾维护_gzm

关注

优秀博文推荐换一换

1

vLLM-Ascend安装部署类问题踩坑分享（2026.8.12更新）

2

昇腾7月精选博文

3

昇腾产品模型配套指南

4

关联开源社区账号，让开源贡献“积“速成长，兑丰富好礼

5

GLM5/5.1 常见问题

热门标签推荐查看更多

AI问题咨询MindSporeCANN模型推理困惑答疑环境部署昇腾硬件Ascend C算子
