企业官网建设流程全解析

各家云厂商和科技公司把“大模型能否落地”挂在嘴边时，最终都会回到同一个问题上：算力从哪里来。最近看到消息，范式智能规划出资超 10 亿元采购华为昇腾 950 芯片，用于大模型的规模化落地。对长期关注国产 AI 基础设施的开发者来说，这是一个非常值得拆解的信号。

这篇文章不会只讨论新闻本身，而是想从工程视角出发，把昇腾 950 相关的软硬件栈、大模型部署链路、推理优化思路和采购决策关键点梳理一遍。无论你所在团队正准备选型国产算力，还是已经在昇腾环境中做模型迁移，本文内容都有参考价值。

1. 昇腾 950 与大模型落地的背景

1.1 为什么 AI 芯片决定大模型落地质量

大模型从训练到上线推理，是一条完整的工业链路。训练阶段需要大量高密度算力把参数“压”进模型，部署阶段则要保证推理时延、并发吞吐、能耗成本和运维稳定性。过去几年，大家讨论大模型经常把注意力放在模型结构、数据质量和微调方法上，但真正到了上线阶段，AI 芯片的选型往往决定项目成功与否。

大模型推理有几类显著特点：

• 参数量大，单卡显存放不下完整权重，需要多卡并行。
• KV Cache 占用增长快，影响上下文长度和并发数。
• 算子形态复杂，注意力、FFN、MoE 路由、各类归一化都需要底层支持。
• 连续批量、投机采样等优化策略依赖推理框架对硬件指令集的适配。

也就是说，如果芯片本身缺少算子库、图编译工具和推理引擎适配，就算模型权重能用，也会出现显存溢出、算子回退到 CPU、加载时间过长、吞吐上不去这些问题。

1.2 昇腾芯片为什么是国产大模型落地的高频选项

华为昇腾是国产 AI 芯片中生态相对完整的系列，覆盖训练、推理和边缘设备。开发者在昇腾环境里通常会接触三个层级：

• 硬件层：Atlas 系列服务器、训练卡和推理卡。
• 基础软件层：CANN（Compute Architecture for Neural Networks），类似 GPU 的 CUDA 角色，包括算子库、图编译引擎、运行时和驱动。
• 框架与应用层：MindSpore、ModelZoo 以及当前大模型流行的 PyTorch 生态适配方案。

昇腾 950 从命名上可以看出是昇腾家族的新一代高端产品。行业团队关心它的重点往往不是单芯片的 AI 算力跑分，而是这三个问题：

1. 能否在 PyTorch 训练/推理脚本里低成本迁移接入。
2. 算子覆盖率和混合精度支持是否满足主流大模型结构。
3. 在真实生产集群中，多卡互联、故障恢复、推理引擎适配是否成熟。

范式智能计划出资超 10 亿元采购昇腾 950 芯片，意味着大模型厂商不再只把国产算力当备用选项，而是愿意将核心业务、核心推理流量、核心产能搭建在国产芯片生态之上。10 亿元不是小数目，如果只是做 PoC 验证，不需要这个规模的投资；按整批服务器加配套网络、存储和软件许可估算，这个预算已经具备建设大规模推理集群或训推一体平台的基础。

1.3 大模型落地需要什么样的算力基础设施

大模型落到真实业务中，需要把“模型能力”转换成“服务能力”，算力基础设施的规划完全不同于开发机上跑 demo。

从业务角度看有以下几种交付场景：

1. 内部智能助手：员工知识库问答、代码辅助、会议纪要总结，需要中等规模推理集群，峰值集中在工作时间。
2. 对外 API 服务：面向企业客户的接口调用，需要高并发、低时延、严格 SLA，最好使用独立实例或隔离资源池。
3. 多租户模型托管：把模型能力作为平台的一部分，服务于多个内部部门或外部客户，需要租户隔离、按量计费、配额管理。
4. 对话与 Agent 应用：模型输出可能被反复调用工具，逻辑复杂，token 消耗大，需要对整链路时延做优化。

昇腾 950 这类高端 AI 芯片进入采购清单，通常对应第 2 和第 3 类场景。也就是说，这笔投入不只是买一批硬件，而是要为大模型的在线服务提供长期、稳定、低成本的推理供给能力。

2. 昇腾软硬件架构中需要理解的核心要点

2.1 AI 芯片选型不能只看总算力

很多团队在早期选型时只看一个指标，比如 FP16 算力 TFLOPS、显存容量、互连带宽，但真实项目里这几个因素是综合发挥作用的。

以昇腾系列服务器的系统架构为例，一个典型的推理节点包含：

• AI 处理器，完成向量、矩阵、标量计算。
• 高带宽显存，存放模型权重和 KV Cache。
• 片间高速互连，支持多卡张量并行。
• 主机 CPU 与内存，完成数据预处理、调度控制。
• RoCE 或以太网卡，支持跨节点推理集群。

采购昇腾 950 芯片时，不能只算单芯片算力能否比肩上一代产品，还要看整机配套是否满足模型规模。举例来说，一个 70B 参数的稠密模型权重 FP16 约 140GB，就算用 BF16 也接近 140GB。跑高并发推理时，KV Cache 还会占显存。如果单卡显存有限，就需要把模型切到多张卡上，张量并行切分越细，通信开销越大。所以很多部署团队关注单卡显存能力、HCCS 互联能力、切分后的显存冗余和推理框架能否高效协同。

2.2 CANN 在昇腾大模型部署中的位置

CANN 是昇腾 AI 处理器的核心软件栈，它承担的任务可以类比为 CUDA + cuDNN + TensorRT 的组合。大模型代码要从 PyTorch 生态迁移到昇腾环境，如果算子层有兼容问题，CANN 很难绕过去。

CANN 的分层逻辑大致如下：

• AscendCL：应用开发接口，负责 Device 管理、Context 管理、Stream 管理和内存管理。
• GE（Graph Engine）：图编译与执行引擎，对模型做图层优化，比如算子融合、内存复用、数据布局转换。
• 算子库：包含常用神经网络算子，如 Conv、Matmul、Softmax、LayerNorm、各类激活函数和 Attention，也包含高维融合算子。
• 运行时与驱动：管理 AI 芯片资源、任务调度、显存和事件同步。

在大模型场景中，Attention 计算是重中之重。Flash Attention 这类技术把 Attention 的中间结果切块计算，减少显存压力，这需要算子层提供高效融合实现。昇腾的 CANN 生态里通过相关融合算子和图引擎优化，把模型脚本里的 Attention 子图映射成芯片上的高效执行序列。团队在做昇腾硬件适配时，需要提前确认目标模型涉及的核心算子在这些库中的覆盖情况。

2.3 PyTorch 生态迁移路径

昇腾早期的模型开发较多绑定 MindSpore，但大模型时代的主流现状是 PyTorch 权重和社区代码占比较高。于是昇腾适配方案也转向“兼容 PyTorch 生态”的方向。实际迁移时有几种常见做法：

1. 将 PyTorch 脚本中的torch调用替换为昇腾适配版本，使用torch_npu插件。
2. 保持模型结构不变，只切换设备对象和关键后端。
3. 通过推理框架（比如 MindIE、vLLM-Ascend 等）直接加载权重并启动服务。

迁移的核心价值在于：团队不需要把模型从 PyTorch 重写成 MindSpore，降低迁移风险。但算子兼容性、显存管理方式、分布式通信细节仍需要验证。比如torch_npu中的torch_npu.npu_format_matmul等 API 有特定布局要求；再比如分布式初始化时，需要将NCCL相关调用替换成HCCL。

CANN 到 PyTorch 的适配如果做得好，一个常见的 Transformer 模型结构只需要修改少量文件：模型定义中设备指定方式、日志回调中的设备名、分布式通信后端、部分显存缓存清理逻辑。

3. 大模型在昇腾 950 环境的部署流程

3.1 部署前置条件

在昇腾服务器上部署大模型推理服务，需要明确环境版本和软件组合。以下是常见的前置条件：

这里有一个非常重要的工程经验：各软件包的版本匹配关系比单个包版本更新更重要。驱动和固件版本与 CANN 版本兼容，CANN 与 torch_npu 版本兼容，torch_npu 又依赖特定 PyTorch 版本。团队在写 Dockerfile 或裸机安装脚本时，要像锁 requirements.txt 一样把版本组合固定下来，避免生产环境里出现“包管理器说成功、运行时提示算子不存在”这类问题。

3.2 模型转换与权重准备

部署大模型时，模型来源主要有两种：

• PyTorch 原生权重：通常包含.bin或.safetensors文件，配合config.json和tokenizer.json使用。
• Hugging Face 格式权重：统一了配置文件和分词器加载方式，昇腾生态工具大多支持。

如果模型只训练好但结构和推理框架要求不一致，可能需要做权重转换，通常包括：把 FP32 权重转成 FP16 或 BF16、把多头注意力结构调整成目标推理库要求的融合结构、对 MoE 模型做 expert 权重重排。

很多推理引擎加载模型时会自带转换工具，但需要注意：转换后的结果要保存并用于多次启动，避免每次启动都重新转换，浪费时间也容易引入版本抖动。

3.3 显存与批量估算

上线前最好做一次显存估算，帮助确定模型切分策略和最大并发数。

单副本显存消耗大致包含三块：

1. 模型权重：参数量乘以每参数字节数。FP16/BF16 是 2 字节，INT8 是 1 字节。
2. KV Cache：依赖隐藏层维度、层数、上下文长度和 batch size。
3. 运行时开销：激活值、临时缓存、推理框架预留显存。

假设有一个 13B 参数的模型，FP16 权重约 26GB。单卡显存不足以支持较长上下文和大 batch，就需要考虑张量并行切 2 卡或 4 卡。量产配置时还会留一部分显存给 KV Cache，否则并发一高上下文变长，很容器出现 OOM。

如果你所在团队准备采购昇腾 950 并有多卡节点，建议先按单节点多卡的主线规划模型的卡数分配，然后在单机内完成张量并行验证，再扩展到跨节点部署。

3.4 一段昇腾环境大模型推理示例

下面的代码演示的是“在昇腾环境使用类 PyTorch 接口加载模型并进行推理”的整体思路。由于不同版本插件接口可能存在差异，示例重点展示结构而非每个 API 的参数细节。

# -*- coding: utf-8 -*- # 文件路径：ascend_infer_demo.py # 说明：在昇腾 NPU 环境下加载 Hugging Face 风格模型的最小推理示例思路 import os import torch # 1. 设置可见 NPU 设备 os.environ["ASCEND_VISIBLE_DEVICES"] = "0" # 2. 导入 torch_npu，触发算子注册 import torch_npu # 3. 将统一设备字符串指向 npu device = torch.device("npu:0") # 4. 模型加载（以 Hugging Face transformers 为例） from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "/data/models/your-model" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, low_cpu_mem_usage=True ) # 5. 将模型放到 NPU 上，并切换到推理模式 model.to(device) model.eval() # 6. 构造输入并推理 prompt = "请用通俗的语言介绍昇腾 AI 芯片在大模型推理中的作用。" inputs = tokenizer(prompt, return_tensors="pt").to(device) with torch.no_grad(): outputs = model.generate( **inputs, max_new_tokens=256, do_sample=False, use_cache=True ) # 7. 解码输出 result = tokenizer.decode(outputs[0], skip_special_tokens=True) print(result)

这个示例说明了迁移到昇腾环境的典型改动点：安装torch_npu，设置设备为npu:0，把inputs放到对应设备上。但生产级部署通常不会直接把模型from_pretrained后逐条生成，而是通过推理框架管理并发请求、动态 batch、和 KV Cache 复用。下面的流程更接近生产形态。

3.5 使用推理框架在高并发下部署

生产环境大模型服务对吞吐有较高要求，如果每条请求都独占整模型权重去做串行推理，硬件利用率会很低。推荐使用支持连续批处理和 PagedAttention 式显存管理的推理框架。

连续批处理是当前大模型推理服务提升吞吐的核心手段。它会维护一个调度队列：当一个请求的生成 token 结束时，立刻把显存空间释放给新的请求，让模型每轮都在处理尽量多的有效序列，而不是等待最慢的请求完成。

昇腾环境下，vLLM 可以借助 Ascend 后端运行。部署时通常包括以下步骤：

1. 创建虚拟环境并安装 vLLM 的昇腾兼容版本及相关依赖。
2. 配置 NPU 可见设备。
3. 启动 OpenAI 兼容的 API 服务，通过参数指定模型路径、张量并行大小、最大上下文长度、KV Cache 大小等。

启动命令示例（命令参数以工具实际版本为准）：

vllm serve /data/models/your-model \ --dtype float16 \ --tensor-parallel-size 4 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

在这条命令中：

• --tensor-parallel-size 4表示模型在 4 张 NPU 上做张量并行。
• --max-model-len 8192限制单条请求的上下文最大长度。
• --gpu-memory-utilization 0.9表示使用可用显存的 90%，预留部分显存给运行时。

服务启动后，客户端可以用 OpenAI SDK 兼容方式调用：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "your-model", "messages": [{"role": "user", "content": "什么是昇腾 950？"}], "max_tokens": 512, "temperature": 0.7 }'

如果生产负载不仅是对话补全，还可能涉及 Agent 的多次工具调用和长文档处理，可以考虑把推理服务放在 Kubernetes 中，使用 Deployment 管理多副本，再通过 Gateway 做路由和限流。昇腾 950 节点在集群里的标签规划和调度策略，需要单独控制，避免不同模型任务互相抢占显存。

4. 从模型能力到工程性能优化

4.1 性能调优的核心指标

芯片采购回来后，开发和运维团队最需要注意的是怎么把硬件能力转成业务指标。

做推理压测时，通常关注以下指标：

大模型在线服务时，首 Token 时延和生成吞吐存在一定平衡。如果请求排队很多，GPU/NPU 需要先处理已有批次中所有 token 的注意力计算，新请求首 Token 的等待时间就会变长。比较合理的做法是设置适合服务规格的排队长度上限，让过载请求快速失败，再让客户端做重试，避免整批请求一起变慢。

4.2 KV Cache 与显存优化

大模型推理的显存大头不只是权重。随请求增加，KV Cache 的占用会线性增长。可以对 KV Cache 做量化，例如把缓存从 FP16 降到 INT8，缓存占用几乎减半，精度损失在多数任务上可控。昇腾的推理引擎中如果支持 KV Cache 量化，推荐先做小样本评测，再放大并发压测。

此外还可以设置max-model-len来控制最大序列长度。不要让生产环境的模型接受无限长的输入，因为上下文长度越涨，显存压力和时延越不可控。建议区分场景：短对话场景限制在 4K 或 8K，长文档场景单独开一组配置更高上下文长度的实例。

4.3 编译优化与算子融合

大模型推理中，性能差距往往不在单个算子，而在算子之间的通信和搬运。CANN 的图编译会把连续的矩阵乘、残差连接、归一化等操作融合成一个大算子，减少中间显存读写。

部署工作里，业务团队要检查日志中是否存在大量算子回退或“unsupported”的警告，如果某个关键算子不支持，整张图无法完全融合，性能会有明显下降。这时至少要找出回退算子出现在哪个子图。

如果模型结构太新，昇腾算子适配跟不上，也可以采用两种思路：

1. 尽量使用主流模型结构，像 LLaMA 系列中常见的 RMSNorm、SwiGLU、RoPE、GQA 在昇腾算子生态里通常优先支持。
2. 修改模型代码，把没有融合的自定义 Python 算子改写成支持图编译的原语组合。

4.4 多节点集群与通信优化

单个昇腾 950 节点内的多卡通信通常比跨节点通信快很多。当模型规模单节点放不下时，跨节点部署就要考虑 RoCE 网络的带宽和拓扑。

部署策略上有几个经验：

• 先做单节点最强的承载能力验证，不要轻易跨节点，以减少通信开销。
• 如果必须跨节点，尽量保持每节点内卡数一致，避免张量并行切分不均匀。
• 将计算密集和通信密集阶段错峰，通过推理引擎的调度减少同步等待。

采购 10 亿元量级的昇腾设备，大概率会形成几十台甚至上百台的集群。这种规模下，网络规划和集群调度会直接决定最终效能。建议提前将节点分成推理集群、微调集群、开发验证集群等不同逻辑池，避免业务级联影响。

5. 导入昇腾芯片时的高频问题与风险控制

5.1 常见问题速查

5.2 版本锁定与灰度发布

昇腾 950 相关软件环境迭代速度比较快，不建议频繁在生产环境更换底层版本。每次升级驱动、CANN 或推理框架前，都要做一次完整的模型服务压测与回归。

在 Kubernetes 场景，可以按下面的思路控制变更：

1. 把镜像中的驱动、CANN、torch_npu、Python 依赖全部固化。
2. 新增模型或新版本时，先部署到一个独立测试命名空间。
3. 压测通过后再扩容到生产节点池。
4. 若升级失败，使用旧镜像快速回滚。

5.3 资金投入后的工程准备清单

10 亿元级别的芯片采购并不是购买动作本身结束，而是一个长期技术工程的开始。团队如果决定采购昇腾 950 芯片，需要在到货之前就完成以下准备工作：

1. 选定 1 至 2 个核心业务模型作为首批适配对象，不要铺开迁移所有模型。
2. 准备一套独立的开发与测试环境，用低规格昇腾服务器完成算子验证。
3. 建立从模型文件到推理服务的自动化发布脚本。
4. 规划推理服务容量和弹性伸缩策略。
5. 明确性能基线与验收标准，比如首 Token 时延小于 XX 毫秒、吞吐不低于某个值。
6. 培养或引进能同时看懂 PyTorch 和 CANN 报错的算法工程师与系统工程师。

6. 国产算力平台建设的最佳实践

6.1 从单模型试点到平台化

如果一次性上线大量模型，维护成本会很高。建议先做一个最小闭环：选一个流量适中的业务，完成昇腾 950 上的模型推理全流程，观察量化效果、连续批处理吞吐、稳定性指标。这个过程产生的文档和脚本将成为后续扩容的模板。

平台化阶段可以建设一个模型推理中台，提供以下能力：

• 模型仓库：统一管理不同版本的权重、配置和推理引擎信息。
• 资源配额：按业务线分配 NPU 卡数、并发上限、日调用量。
• 服务发布：模型测试通过后一键发布到生产网关。
• 可观测性：接入 Prometheus 监控 NPU 利用率、显存使用、请求成功率、时延分位数。

6.2 安全与权限最小化

大模型服务涉及数据输入、模型权重与用户日志，建议在生产环境中遵循最小权限原则。

1. 模型文件存放在受控文件系统，只有部署机器人和服务账号可读。
2. 推理服务调用需要 API Key 或认证 Token，不能裸奔到内网。
3. 用户输入和模型输出记录脱敏后再进日志系统。
4. 模型更新使用单独的发布账号，禁止直接在节点上用 root 操作权重目录。
5. 如果需要微调或全量训练，单独分配高性能资源池，不要干扰在线推理集群。

6.3 成本核算与资源管理

大模型项目的成本，不是单看硬件采购价。还需要统计这些项：

• 机房空间、电力与散热成本。
• 网络设备与带宽成本。
• 软件许可与 toolchain 支持费用。
• 运维团队人力成本。
• 模型适配与迁移过程中的开发成本。
• 低峰时段资源闲置成本。

10 亿元建起来的昇腾集群，如果没有合理的资源调度，很容易出现白天排队、晚上闲置。建议通过弹性伸缩任务调度，把微调任务放到推理低峰期跑，提高整体芯片利用率。同时基于队列和配额做集群共享，避免不同团队互相争抢。

6.4 供应链与备件策略

大规模采购昇腾 950 芯片时，也要考虑服务器整机交付周期、故障替换备件和维保服务。AI 推理集群一旦出现芯片故障，对应节点上的服务会中断，必须有明确的故障处置流程。

采购层面的建议：

1. 与供应商确认故障率与替换时效，合同中约定维修响应时间。
2. 预留一定比例的备件，例如整机数量的 5% 到 10%。
3. 建立节点健康检查机制，比如定期执行 AI 算子自检、压测和显存检测。

7. 后续可以深入的方向

昇腾 950 采购消息背后，是国产大模型算力从“可用”向“好用”演进的趋势。如果你所在团队接下来也要做相关迁移，建议沿着下面几条主线提升：

1. 学习 CANN 和昇腾推理引擎的算子映射方式，能够看懂模型结构到芯片执行的转换过程。
2. 掌握大模型推理服务化技能，包括连续批处理、PagedAttention、动态显存分配、量化和服务编排。
3. 关注昇腾硬件在多机多卡场景下的互联调优，理解张量并行、流水线并行与数据并行的适用边界。
4. 建设一套合适的监控体系，让模型性能变化能被数据感知，而不是等业务投诉后被动排查。

如果你在模型适配过程中遇到算子不兼容、推理性能低于预期或者服务不稳定等情况，也可以从版本匹配、模型结构选择、显存规划和推理引擎配置这几个方向逐一排查。昇腾 950 芯片能发挥多大价值，一定程度上取决于软件栈和业务场景的磨合程度。

动手实践是理解这套体系最好的方式。可以先申请或使用已有的昇腾开发者环境，拿一个小规模模型完整跑通“模型加载—NPU 推理—性能观测”链路，再逐步扩大参数量与并发规模。跑通一次后，你对国产 AI 芯片大模型落地的理解会真实很多。