企业官网建设流程全解析

前阵子帮朋友排查一台训练服务器的环境问题，他上来就问了一句：“昇腾系列有哪些 GPU？”我一听就明白，很多人刚开始接触所谓“国产 GPU”时，第一个困惑不是卡的性能，而是这些卡到底算不算 GPU。昇腾其实不是传统意义上的显卡，它属于 AI 加速器，只是大家口语里叫习惯了“国产 GPU”。

这篇文章不是厂商宣传稿，也不做横向跑分排名。我把自己从接触国产系列加速卡，到能稳定跑起大模型训练和推理的完整经验整理出来，主要包括四件事：国产智能计算芯片有哪些流派、软件栈和 NVIDIA 生态差在哪、拿到一台机器后怎么一步步验证和跑通 PyTorch / vLLM、以及初期最容易踩的一堆坑。无论你是算法工程师、运维还是学生，第一次面对昇腾、寒武纪、摩尔线程这类板卡时，这份内容都能帮你少走点弯路。

1. 先弄明白一件事：国产 GPU 并不都是“GPU”

1.1 CPU、GPU、AI 加速器的定位差异

很多同学把脑子里那套“显卡=GPU”的概念直接套到国产硬件上，结果一看接口和跑起来的日志就懵了。打个比方：CPU 是“一个博士生”，什么题都能算，但一次只能专注做几件事；GPU 是“几千个小学生”，单个人的能力一般，但可以一起做大量重复的算术题。传统 GPU 最初是为了图形渲染，要同时处理几百万个像素点的位置和颜色，天然适合大规模并行计算，后来深度学习火了，大家发现这种并行结构正好能把神经网络里的矩阵乘法跑得飞快。

但 AI 加速器走得更极端。它不关心图形渲染，不关心通用计算，直接在设计上把“矩阵乘加运算”做成硬件的核心单元。谷歌的 TPU、华为昇腾的 NPU、寒武纪的 MLU 都属于这类专用加速芯片。它们可以理解成“专为 AI 数学题定制的计算器”，很多标准 GPU 该有的能力被刻意砍掉，换来的是更高的能耗比和更低的推理时延。

这里就出现了第一层概念差异：真正严格意义上的“国产 GPU”，应该指像摩尔线程这类做图形和通用计算芯片的产品；而昇腾、思元这类主打 AI 训练和推理的芯片，工程上更准确的归类是 AI 加速器。但在行业交流里大家懒得区分，统统叫“国产 GPU”，所以网上才会有“昇腾系列有哪些 GPU”这种搜索词。搞清楚了这层，你再看厂商的软件栈、开发方式，思路就不会乱。

1.2 一张表看清国产智能计算加速卡的几大流派

初识国产系列加速卡，可以先建立一个粗框架，不要一上来就盯某款芯片的参数。目前市面主要分为三类路线：

这张表比较粗，因为芯片迭代很快，每个厂商的真实产品线也比这复杂得多。但它能帮你快速明白一件事：不同的“国产 GPU”，软件生态差异可能比硬件差异还大。你问寒武纪怎么用，别拿昇腾的教程硬套；你说自己卡是“国产 GPU”，还要先确认厂商是谁、属于哪个路线。

另外值得注意，海光 DCU 和沐曦的曦云这类走 GPGPU 路线的芯片，更容易把传统的 CUDA/HPC 代码迁移过来。它们的思路是“既然全世界绝大多数 AI 代码跑在 NVIDIA CUDA 上，那我在指令集和运行时上尽量贴近这套习惯”。昇腾则更坚定地走自己的达芬奇架构和 CANN 软件栈，迁移时需要调用方主动适配。所以选哪家，很多时候不是比谁算力高，而是看你手里的代码谁更容易接住。

1.3 AI 时代对芯片提出了哪些“特殊需求”

既然讨论 AI 芯片，就不能不聊为什么 AI 时代的老牌 CPU 不够用了。近两年大型语言模型和三模态模型就是典型的算力杀手，我结合自己跑模型的经验来拆解：

第一是吞吐需求。神经网络训练和推理的核心操作是矩阵乘加，特别是 Attention 里的 QKV 矩阵乘，成百上千亿的参数一次次反复算，通用 CPU 的缓存和分支预测能力在这里派不上用场，只能靠芯片里大量并行的计算单元硬堆。这也是 NVIDIA 靠 Tensor Core、昇腾靠 Cube 单元提升“TOPS 算力”的原因。

第二是精度需求。AI 训练和推理对 FP16、BF16、INT8、FP8 这类低精度数据格式要求极高。传统图形 GPU 早期主要做 FP32，后来发现模型用 FP16 甚至 INT8 后，显存占用更低、计算更快，精度损失在可接受范围内。现在衡量一张卡“AI 性能”，基本要看它的半精度或者整数算力，而不是单精度浮点算力。

第三是存储和互联需求。大模型时代，单卡的显存决定你能不能让模型装下，多卡之间的带宽决定你能否并行训练。模型权重就是一堆数字，必须放在离计算单元近的高带宽存储器里。训练 7B 参数的模型，光是 FP16 权重就要约 14GB，推理时加上 KV Cache 和中间激活值，峰值 16GB 打底。所以先进 AI 卡普遍上 HBM 高带宽显存，也是这个原因。

讲完这些，你再看厂商芯片介绍里的“TOPS”“显存带宽”“互联带宽”这些参数，就能对上号了。它们不是在堆参数，而是在回应 AI 工作负载的真实需求。

2. 初识一块新卡：软硬件准备和第一眼验证

2.1 你要面对的不只是硬件，还有一套软件栈

从 NVIDIA CUDA 生态切到国产芯片，最容易栽跟头的是惯性思维：以为拿到机器后装个 PyTorch 就能像以前一样torch.cuda.is_available()返回 True。实际情况是，驱动装完后还得把厂商的运行时、编译器、算子库、框架插件一层层对齐，缺一个环节都可能跑不起来。

以昇腾为例，完整的软件栈大体是这么几层：

• 底层是驱动和固件，负责把 NPU 设备注册到系统里，提供字符设备和错误上报；
• 再上层是 CANN 工具链，包含昇腾设备管理、AscendCL 编程接口、GE 图引擎、算子库等；
• 接着是深度学习框架适配层，PyTorch 要装torch_npu插件，TensorFlow 有对应适配，MindSpore 则原生支持；
• 最上层才是你平时写的训练脚本和推理服务。

理解软件栈的意义在于，排障时你才知道问题出在哪。npu-smi能看到卡，说明驱动没问题；但 Python 里import torch_npu报错，也许是版本没配对，也许是 CANN 的set_env.sh没有 source。我看到太多人卡在这些不显眼的地方，动辄怀疑卡坏了。其实把软件栈一层层剥开检查，比反复重启机器有效得多。

2.2 驱动装好后的第一次“打招呼”

拿到新机器，第一步不是马上装 PyTorch，而是先确认硬件被系统正确识别。不同厂商的命令不一样，这里以昇腾生态最常用的状态查看命令举例：

npu-smi info

正常执行后你会看到每张 NPU 卡的芯片型号、健康状态、算力使用率、显存占用和温度。我用过的环境打印出来大致是这种感觉：

Chip : Ascend 910B HBM-Usage : 12.6 / 64 GB AI-Core Usage : 37% Temperature : 52 C

看到 C 状态、芯片型号和 HBM 容量，基本能判断驱动层面没问题。如果npu-smi都找不到设备，先检查驱动是否安装、用户是否在npugroup（不同版本组名有差异）这类权限组里，别急着重装系统。

接下来检查 CANN 工具链是否可用。常见安装目录是/usr/local/Ascend/ascend-toolkit，安装后需要加载环境变量：

source /usr/local/Ascend/ascend-toolkit/set_env.sh

我自己的习惯是，把这类环境配置写进~/.bashrc时并不使用某种代理技巧，而是老老实实按厂商脚本导出的ASCEND_HOME_PATH,LD_LIBRARY_PATH,PYTHONPATH等变量来设置。设置完成后执行which npu-smi或者看环境变量有没有正确输出，再进下一步。否则后面 Python 层报“找不到 libascendcl.so”大概率就是这里漏了。

2.3 常见“替代命令”对照表

用过 NVIDIA 生态的人习惯了nvidia-smi，到了国产板卡上会到处找“类似命令”。这里分享一张我整理过的对照表，方便第一眼定位问题：

这张表不需要背，记住一个原则就行：厂商的实现和命名会不同，但总会提供一个查看设备信息、健康状态和进程占用的命令行工具。拿到新卡先翻官方运维文档，找到对应的监控命令，运行一次确认设备在位，再谈上层开发。

如果你是租云服务器，还可以先看云厂商控制台里实例的“设备信息”或“GPU 详情”，它会直接告诉你有几张什么型号的卡。我有次排查半天程序找不到设备，最后发现控制台上显示的是两张卡，但实际只透传了一张给容器，完全是资源分配的问题。

3. 实操：用国产卡跑起 PyTorch 和大模型推理

3.1 准备 PyTorch 环境时的版本战争

在国产 AI 卡上装 PyTorch，最忌讳的是随便pip install torch就完事。NVIDIA 生态里，PyTorch 官方安装包直接带 CUDA 支持，你装完就能用；但在昇腾这类芯片上，PyTorch 只是“前一半”，关键还得装厂商发布的框架适配插件，比如昇腾的torch_npu、寒武纪的torch_mlu。

版本匹配非常重要。你不能随意拿最新的 PyTorch 2.5 搭配旧版插件，必须去厂商官网查版本适配表，确认 PyTorch 小版本、Python 版本、CANN 版本和插件版本能够对上。比如昇腾官方文档通常会写明“支持 Python 3.8–3.11、PyTorch 2.1.0 配合 torch_npu 某个版本、CANN 8.0 某个版本”。

我自己实际执行过的安装流程一般是：

# 1. 先创建干净的虚拟环境，避免污染系统 Python python -m venv ~/venvs/ascend_test source ~/venvs/ascend_test/bin/activate # 2. 按官方适配表安装指定版本的 torch 和 torch_npu pip install torch==2.1.0 pip install torch_npu==2.1.0 # 3. 安装完成后立刻验证导入是否成功 python -c "import torch; import torch_npu; print(torch.npu.is_available())"

需要提醒的是，很多同学会去问“pip 清华源 torch gpu 怎么装”，在国产卡场景里，这类常规 PyTorch 安装教程只能解决一半问题，另一半是厂商插件有没有正确配好。先保证最小验证能过，再谈跑模型。

3.2 torch_npu 后端与设备切换最小示例

验证完环境，就能跑一段最简单的 tensor 计算来确认 NPU 真的在工作。下面这段代码相当于国产加速器世界的“Hello World”：

import torch import torch_npu # 检查 NPU 是否可用 print("NPU available:", torch.npu.is_available()) # 把张量放到 npu:0 上 x = torch.randn(4096, 4096, device="npu:0") y = torch.randn(4096, 4096, device="npu:0") # 做一次大规模矩阵乘法，验证计算路径 z = x @ y print("Result shape:", z.shape) print("Sum:", z.sum().item())

这里最关键的变化是把torch.cuda换成torch.npu，把device="cuda:0"换成device="npu:0"。代码里凡是写死了cuda的地方，在昇腾环境都会报设备错误。

如果你原来是分布式训练脚本，还要把通信后端从 NCCL 切到厂商自己的集合通信库，昇腾环境常见的是 HCCL：

import torch.distributed as dist # 初始化通信进程组，使用 hccl 后端 dist.init_process_group(backend="hccl", init_method="env://")

这个改动看着不起眼，但架不住多机训练时非常关键。NCCL、HCCL 这类通信库负责在多个加速卡之间同步梯度，后端选错，进程组初始化的第一秒就会报错。

3.3 用 vLLM-Ascend 给大模型做推理的路径

现在大模型推理大多绕不开 vLLM 这套框架，它用 PagedAttention 管理显存，吞吐表现比朴素推理好很多。昇腾社区也维护了对应的适配项目，叫 vLLM-Ascend，专门让 vLLM 跑在昇腾 NPU 上。

整个上手过程我拆成四步：

1. 准备好一个你已经有权限访问的模型权重目录。比如一份 7B 或 13B 的对话模型，本地路径或可访问的模型仓库路径都行。
2. 根据官方文档安装 vLLM-Ascend 依赖，一般是在已有 Python 环境里安装相关 wheel 包。
3. 用类似下面的命令启动 OpenAI 兼容的推理服务：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --device npu \ --max-model-len 4096 \ --tensor-parallel-size 1

不同版本参数略有差异，但关键在--device npu，让推理框架去调用昇腾后端而不是默认的 CUDA。

4. 启动完成后，可以用 curl 或者 Python requests 打一个测试请求：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{"model": "/path/to/model", "prompt": "介绍一下国产AI加速卡", "max_tokens": 128}'

我第一次在这类卡上启动 vLLM 时，最大感受是初始化日志和 CUDA 版不太一样，它会在日志里打印 NPU 设备数、显存总量、是否成功申请到内存等。看到init engine过程中没有致命错误，基本就成功一半。后续测试可以用一轮请求的total_tokens和耗时估算 tokens/s，用这个衡量部署是否达到能用水平。

3.4 多卡/多机下的“伪 CUDA 直觉”要改掉

很多人拿到机器上的多张加速卡，第一反应是按照 NVIDIA 那边CUDA_VISIBLE_DEVICES的习惯去设置。昇腾环境里对应的环境变量通常叫ASCEND_RT_VISIBLE_DEVICES。比如只想让当前进程用编号 2 和 3 两张卡：

export ASCEND_RT_VISIBLE_DEVICES=2,3 python train.py

如果你用过CUDA_VISIBLE_DEVICES，会发现这个思路非常像，但千万别猜，得去查对应厂商的“设备可见性”环境变量。寒武纪、海光也各有自己的写法，名称不统一是国产生态当下的常态。

多卡训练时，还要注意卡间通信拓扑。单机多卡，要确认卡间互联走的是 PCIe 还是更高带宽的专用互连（比如类 NVLink 的方案）。多机训练则要关注 RoCE 或 InfiniBand 网卡是否配置好。这些资源虽然不像 GPU 本身那么显眼，但大模型训练时梯度同步的流量非常恐怖，网络不通或者带宽不足，卡再多也快不起来。

4. 初识期最容易踩的坑

4.1 卡明明在，程序就是找不到设备

这种问题在国产卡初期出现频率最高。卡上电了，npu-smi能看到，但 PyTorch 里is_available()返回 False，或者运行时报错Device 0 does not exist。

我看到的常见原因有三个：

• 环境变量没加载，Python 进程找不到 CANN 的动态库；
• 用户没有设备访问权限，进程无法打开设备文件；
• 安装的插件版本和 PyTorch 版本不匹配，导致插件初始化失败。

排查路径按顺序来：先跑一次厂商自带的诊断脚本，确认设备和驱动没问题；再手动 source 环境变量文件，确保终端里echo $ASCEND_HOME_PATH有输出；最后在 Python 里分别导入 torch 和插件，看哪一步抛异常。很多新手一上来就把“找不到设备”升级成“重装驱动”，其实最费时间的反而是环境没有 source。

4.2 算子缺失与不支持，“图模式”很多时候是解药

跑大模型时，经常遇到“某个算子不支持”或者“算子执行失败”。原因很直接：厂商的算子库覆盖面不会像 NVIDIA cuDNN 那么全，新模型用的新算子可能不在适配列表里。

遇到这种情况，第一反应不要是骂硬件，先上网查算子名，看官方是否有替代实现。其次可以尝试把 PyTorch 的torch.compile或者厂商提供的图模式打开。图模式会把多个小算子融合成大算子，有时候能规避某些底层算子不生效的问题。

我自己的体会是，兼容性问题不一定出现在推理主干，更多是出现在 Tokenizer、后处理、beam search 之类的小算子。所以调试时要学会看完整堆栈，是模型 forward 挂了，还是前后处理挂了，分开排查能省一半时间。如果确实卡在一个第三方库的算子，优先找升级版或换等价库。

4.3 显存、日志与崩溃现场

大模型推理中最常见的崩溃是显存溢出（OOM）。但国产卡上的 OOM 有时表现得很奇怪，可能是申请时告警、运行到一半时进程被杀、也可能只是打印一行内存不足就不动了。

如果你想在命令窗口里看实时算力占用，周期性执行一下npu-smi info或者配套监控命令即可。不过我建议直接把显存占用、算力使用率、模型吞吐这些指标接到监控系统里，定期看趋势，而不是等崩溃后再翻终端。

还有一类现象是程序崩溃时，日志目录里留下 crash dump 或 coredump 文件。很多人看到crash dump triggered这类字样就慌了，其实它只是说明驱动捕获了异常并生成了转储文件。这种情况下，先把 core dump 保留好，再根据日志里的设备号、错误码去查厂商文档，或者在社区里搜一下，往往能找到具体原因。动不动就重启设备，反而会把现场破坏掉。

4.4 一张问题速查表

下面这张表是我在实际转换项目时反复用到的问题排查清单：

还有个小点想提醒做推理的伙伴：如果你之前习惯在 NVIDIA 卡上用 Ollama 快速拉起一个模型，到了国产系列卡上别急着照搬。Ollama 本身对硬件后端的支持依赖底层运行时，并不是所有生态都直接支持。先确认有人帮你把适配层做好，否则你装了 Ollama 大概率只会看到“未使用 GPU”的效果。

5. 我的使用体会和一点建议

5.1 迁移工作比预想大，但要分清轻重

国产加速卡的迁移成本，主要不是来自硬件，而是来自“你用了多少 CUDA 生态的深度能力”。如果你平时只跑torchvision或者 Hugging Face 模型，迁移成本总体来说可控，改设备名、调版本、跑通算子，基本两天内能完成。但如果你依赖 CUDA 编译的 C++ 扩展、自定义算子、特殊库，那复杂度会上一个量级，甚至需要读懂厂商的编程手册重写部分逻辑。

所以决策上我建议先做减法：把项目里“必须绑死 CUDA”的模块找出来，评估替代方案。实际验证下来，大多数纯 Python 模型代码经过小幅度改动就能跑，真正的风险在依赖链的底层。

5.2 选型建议：以应用反推硬件条件

做技术选型时先问自己一个问题：我要处理的模型有多大，实时性要求多高？训练卡和推理卡需求不同。如果你只是做 RAG 应用和常规模型推理，很多推理型加速器就够用，不一定非要上最高端的训练卡；如果你要微调 70B 大模型，就得认真计算显存总和、张量并行可行性以及通信带宽。

我的建议是做一个最小概念验证（POC）。挑一个你线上最核心的模型，用真实数据跑完整链路，记录 throughput 和时延。千万不要只拿 mnist 或者 resnet18 这种演示模型验证一下就上线。我在国产卡上见到的翻车场景，大多是 POC 阶段太简单，真实模型一上就撞到算子缺失或显存瓶颈。

5.3 把设备访问抽象出来，别在代码里写死厂商名

如果团队需要同时兼容多种硬件，代码层最好尽早做设备抽象。我在项目里经常用一个很小的工具函数：

import torch def detect_device(): try: import torch_npu if torch.npu.is_available(): return "npu" except ImportError: pass if torch.cuda.is_available(): return "cuda" return "cpu"

模型加载和 tensor 创建时都通过这个函数决定设备，后续切换硬件只需要换环境，不需要改整份代码。当然这个写法只是最简单的一层，实际工程里可能还要做算子差异封装、性能调优参数隔离，但先做到“不写死”，后续维护会轻松很多。

最后分享一个不起眼但很重要的经验：不要同时在一个开发环境里塞满各家加速卡的插件。不同厂商的后端可能修改同一个库的依赖版本，互相打架的案例我见过太多次。给昇腾、寒武纪、CUDA 环境各自建独立的虚拟环境，甚至用独立的容器镜像，才是更让人省心的做法。国产系列 GPU 生态还在快速演进，今天的坑可能过半年就没了，但版本隔离和环境规范这些基本功，什么时候都不会过时。