企业官网建设流程全解析

DeepSeek 要在内蒙古数据中心用华为昇腾 950DT 跑模型——这消息一出来，圈子里讨论最多的大概不是“哪款模型”，而是“这条链路到底能不能顺畅跑通”。我做了几年大模型推理基础设施，很清楚这种标题背后藏着多少工程量：它不只是把 Hugging Face 上的权重下载下来、插上加速卡直接跑那么简单，而是模型、芯片、服务器、数据中心气候条件、散热方式、供配电容量甚至楼板承重全都得放在一起算一遍。

这篇文章我就从 AI Infra 从业者的角度，把这类部署拆开聊。无论你的目标是评估昇腾 950DT 能不能承接 DeepSeek 推理，还是想在类似场景下做选型和落地，这里面涉及的量化、并行策略、推理框架、液冷设计、机电配套、上线排查，基本都能覆盖。内容偏工程向，但我会尽量把计算逻辑讲清楚，让有基础的同学能直接用，没基础的同学也不至于看不懂。

1. 为什么这个大模型部署值得拆开看

1.1 大模型上国产生态，卡点从来不是“能不能用”

过去很长一段时间，国产大模型跑国产加速卡的方案都停留在“demo 能出来、官网上有截图”的阶段。真实的生产环境要复杂得多：模型要支持高并发，推理延迟要稳定，日志要可追踪，硬件故障要能自动恢复，精度还不能有明显劣化。任何一个环节掉链子，服务上线以后都会被放大成事故。

DeepSeek 和昇腾 950DT 的组合之所以值得关注，是因为它第一次把“模型开源生态”和“国产生态算力”这两个方向拉到了同一条生产链路上。DeepSeek 的模型具备完整的开源权重和部署工具链，昇腾侧有 CANN、MindIE、vLLM-ascend 这些适配层，理论上已经具备工程化基础。但“理论上具备”和“生产上稳定”之间，还隔着大量需要有人在数据中心里真刀真枪调优的细节。

我自己见过太多项目死在这些细节上：权重格式不匹配、算子不支持、HCCL 通信超时、显存估算错误导致 OOM、液冷流量不足导致 NPU 高温降频。这些不是“能不能用”的问题，而是“用起来稳不稳”的问题，也是我觉得这篇拆解比单纯介绍某个产品更实在的原因。

1.2 算力墙、显存墙、带宽墙：先看清三个约束

大模型推理，尤其是 decode 阶段，最大的瓶颈通常不是算力，而是显存带宽。这里有个好理解的类比：生成每个 token，都需要把模型权重从头到尾扫一遍。权重就像图书馆里几十万本藏书，每翻一页新内容，都要把所有藏书在眼前过一遍，图书馆门口那条路的宽度就是显存带宽。哪怕藏书再多、书桌再大，门口通道不够宽，翻书速度也上不去。

用数字算一下就清楚了。假设部署的是 DeepSeek 系列中典型的大版本，总参数约 671B。按 FP8 精度估算，模型权重体积大约是 671GB；如果按 BF16 精度，那要翻倍到 1.34TB 左右。即便按单张加速卡 2TB/s 的 HBM 带宽来估算，单卡一次 decode 步骤扫完 671GB 权重，理想上限也就 3 token/s。注意这是理论纯带宽上限，还没算真实软件栈的损耗和 KV Cache 读取开销。也就是说，单卡硬跑大模型，性能会非常难看。

所以我一直强调，评估这类部署时别只看算力峰值 TFLOPS，显存容量和显存带宽同样重要。prefill 阶段主要吃算力，因为要并行处理很长一段输入；decode 阶段主要吃带宽，因为每生成一个 token 都要遍历权重。理解了这条，后面所有优化手段——量化、并行切分、专家并行、批量调度——其实都是在跟这三堵墙周旋。

1.3 内蒙古的选择：气候、能源与地域条件

从数据中心规划角度看，内蒙古是天然适合承接高密度 AI 算力的区域。气候上冬季漫长、室外温度低，自然冷却的时间窗口非常长；空气干燥，间接蒸发冷却的效率也高。能源结构上风能、太阳能资源丰富，有相当比例的清洁电力，对动辄几十兆瓦级别的 AI 算力集群来说，电力成本和绿电比例都是硬约束。再加上土地资源充裕，电网配套完善，这里已经聚集了不少大型数据中心集群。

所以 DeepSeek 计划把昇腾 950DT 部署在这个区域，单从基础设施角度我并不意外。真正需要在工程上处理的，是如何把“气候条件好”转化成“机柜内部温度稳定”，以及如何在高密度算力场景下把散热、供电、结构承载这些传统数据中心问题重新设计一遍。后面我会逐个拆。

2. 从模型到昇腾芯片：部署方案的关键拆解

2.1 先决定用多少 bit：模型量化与显存计算

模型部署的第一步，不是写推理代码，而是确定精度。精度决定了模型权重占多少显存，也决定了推理速度和最终效果。推荐的经验顺序是：先算显存，再选精度，最后定框架。

模型权重体积的估算公式并不复杂：

权重体积 = 参数量 × 每参数字节数

如果是 671B 参数的大模型：

• BF16/FP16：每参数 2 字节，权重约 1342GB
• FP8：每参数 1 字节，权重约 671GB
• INT8：每参数 1 字节，权重约 671GB
• INT4：每参数 0.5 字节，权重约 335GB

但显存里远不止放权重。模型跑起来以后还有激活值、优化器状态（训练阶段才有）、KV Cache，以及框架自身的运行时开销。KV Cache 会随着并发请求数和上下文长度膨胀，长上下文场景下几十 GB 甚至上百 GB 都很正常。所以单卡显存哪怕有 80GB，想装下 FP8 级别的 671B 模型，至少也要 10 张卡以上才勉强只够放权重，真正要稳定服务，通常得准备 16 卡甚至更多，还要为 KV Cache 留足余量。

量化选择上，我个人建议不要为了省显存一上来就上 INT4。质量损失在部分评测集上不一定看得出来，但在长文本、代码生成、逻辑推理等场景里容易被放大。比较稳的路线是优先用模型官方发布的 FP8/BF16 权重，先把链路跑通，再根据显存余量逐步尝试更低 bit 的量化方案。每次切换精度，都必须在一组固定评测集上做回归对比，不能只凭几个样例判断。

2.2 推理框架选型：CANN、MindIE、vLLM-ascend 怎么选

昇腾平台上的软件栈比 NVIDIA CUDA 生态要复杂一些。最底层是驱动和 CANN 计算库，类似 CUDA；往上会有推理引擎和适配层。目前接触最多的几条路径是 MindIE、vLLM-ascend 以及部分厂商自研引擎。

MindIE 是昇腾官方推出的推理解决方案，对模型编译、算子融合、图优化做得比较深，离线批量推理和在线服务都有对应的能力，适合生产环境追求稳定性的团队。vLLM-ascend 则是把社区流行的 vLLM 框架移植到昇腾上，好处是接口熟悉、持续批处理逻辑成熟，如果团队之前在 NVIDIA 平台上用 vLLM，迁移成本会低不少。

框架选型没有绝对的“最好”，只看场景。我自己判断的标准很简单：如果团队强调快速迭代、自定义逻辑多，优先 vLLM-ascend；如果追求极致性能和生产支持，优先 MindIE。比较忌讳的是两套框架同时上、团队精力分散。无论选哪套，版本对齐都是最容易翻车的地方。CANN 版本、驱动固件、torch_npu 版本、推理框架版本之间往往有严格的对应关系，官网的版本匹配表必须逐项确认，否则会出现各种莫名其妙的算子报错和内存异常。

2.3 并行策略：张量并行、流水线并行和 MoE 专家并行

当模型权重单卡放不下时，并行是必经之路。昇腾多卡之间通过 HCCS 高速互联，多机之间通常走 RDMA 网络。并行策略主要分三种：

张量并行是把一层网络的计算切到多张卡上，每张卡只负责一部分矩阵分片，适合单机多卡场景。因为切分后每步都要做通信同步，跨节点做张量并行往往得不偿失，最好限制在单机内部。流水线并行是把不同层分配到不同卡上，数据逐层传递，跨机可以接受，但“气泡”问题会导致一部分算力空转，需要仔细设计微批次数量。专家并行是 MoE 模型特有的思路，DeepSeek 这类模型有大量专家网络，把不同专家分布到不同的 NPU 上，每次请求只路由到部分专家，这样既能扩大总显存容量，又能避免每次都扫全量权重。

实际部署时，我一般建议优先把单机的卡通过张量并行或专家并行用起来，再考虑跨机扩展。MoE 模型尤其值得投入时间做专家并行，因为它的激活参数远小于总参数，专家权重不全部被读取，这能显著缓解带宽瓶颈。并行度的选择还要看通信拓扑，HCCS 带宽高、延迟低，张量并行开到 8 通常没问题；如果跨机，优先选专家并行或流水线并行，减少同步频率。

3. 数据中心侧落地：散热、供电和结构承载

3.1 高密度算力机柜的冷却方案与自然冷源利用

AI 服务器和传统通用服务器最大的区别之一，是单机柜功耗密度完全不同。传统 IDC 一个机柜 4-8kW 已经很常见了，但 AI 训练/推理集群一个机柜动辄 20-40kW。早期连 10kW 的机柜都能让运维头疼，到了这个量级，机房空调思路得彻底换。

风冷在高密度场景下会遇到极限。就算机房空调送风温度够低，机柜内部的热点也压不住，风扇转速拉满后噪音和功耗都上升。现在更常见的是冷板式液冷：CPU、NPU 这些主要发热器件通过冷板和冷却液接触，热量由液体带走，冷却液再经过室外散热装置释放热量。冷板式液冷的优势是改动相对小，服务器外形接近标准设备，对既有机房改造友好；浸没式液冷把整台服务器泡在绝缘冷却液里，散热能力更强，但运维方式和机房承重、密封要求完全不一样。

内蒙古的自然条件对液冷部署很友好。冬季室外温度低，即使液冷系统使用冷却塔或干冷器，也能获得很长的自然冷却时间。不少数据中心还会配 AHU 间接蒸发冷却机组，利用室外干冷空气通过换热芯给室内空气降温，同时保持空气隔离、避免灰尘进入机房。在干燥、寒冷地区，这种方案比传统机械制冷省电得多，PUE 可以压到很低。但要注意，气候冷归冷，不代表机柜内部不会局部过热，液冷系统的流量分配、板换效率、冬季防冻、低湿环境下的静电防护，都是实际运维必须盯住的点。

3.2 余热回收为什么在寒冷地区更有意义

AI 机房通常被当成“耗电大户”，其实它同时也是“产热大户”。普通风冷机房排出的热风温度低，不好利用；但液冷系统可以把服务器热量以 40-60℃ 的温水形式带出来，这个温度在冬季恰好可以用来做园区供暖、温室保温、办公采暖。

内蒙古冬季气温低、取暖时间长，余热回收的应用场景非常明确。把液冷系统出液端接入热泵或板式换热器，热量直接供给周边建筑，虽然不能直接降低单台服务器的 PUE，但能显著提升整个园区的一次能源利用效率。算经济账的时候，不能只看设备成本，还要把供暖季时长、热负荷需求、当地供暖价格全放进去。很多北方项目之所以愿意上余热回收，就是因为回收周期在寒冷地区明显更短。

当然，余热回收也意味着系统复杂度上升。冷却液回路、水质管理、热量输配、末端负荷的匹配都要重新设计，运维要求也更高。如果只是单纯追求 PUE 数字，这条链路可能不是最优解；但从碳中和和综合能源角度看，它是大趋势。

3.3 活荷载、供配电与能效监控要重新算

很多人关注 AI 数据中心时只看算力，我却建议把建筑结构承重也纳入决策。楼面活荷载，简单说就是除楼板自重以外，楼面还能承载的可变重量。普通办公楼的活荷载设计一般在 2-3kN/m²，传统机房通常在 8-10kN/m²，而高密度 AI 机房因为要上重型液冷机柜、大型 UPS、电池组、变压器，活荷载可能需要做到 12-20kN/m² 甚至更高。这不是拍脑袋，需要结构工程师根据机柜重量、摆放距离、架空地板高度一项项核算。老机房改造前如果不做结构评估，设备还没上完，楼板已经吃不消了。

供配电同样要重算。单机柜 20kW 以上时，传统机柜 PDU 的容量和插接方式都可能不够，列头柜、母线槽、备用发电机的容量都得跟着涨。大模型推理负载还有一个特点：请求量时高时低，功率波动比传统 Web 服务大得多。如果园区接了风电、光伏这类波动电源，就必须有储能和柴发做兜底，否则电网频率波动很容易让整排昇腾节点掉线。

能效监控方面，PUE 依然是衡量机房基础设施效率的通用标准，但对 AI 负载来说，只看 PUE 不够。我建议同时盯 NPU 利用率和“每千 token 耗电”这类业务导向指标。一个 NPU 利用率只有 20% 的集群，就算 PUE 只有 1.1，单位 token 的能耗也一定很难看。让模型负载尽量跑满硬件，远比单纯降低空调功耗更值得投入。

4. 实操过程：在昇腾节点上把服务跑起来

4.1 环境检查与软件栈安装

真到动手部署的那天，我先做的是环境检查。昇腾平台上最常用的硬件检查命令是npu-smi info，它能显示 NPU 数量、使用率、温度、显存占用和功耗。第一次到现场，我会把每个节点的这张表截图留档，确认设备健康、固件版本一致，再往下走。

软件栈安装强烈建议用官方提供的昇腾容器镜像或统一安装包，自己手动拼版本会非常痛苦。基本流程是：创建干净的 Python 虚拟环境，安装 CANN toolkit，再安装和 CANN 版本对应的 torch_npu，最后安装推理框架如 vLLM-ascend 或 MindIE。这个顺序不能乱。装完之后先用一个小模型做冒烟测试，确认 NPU 能被框架正确调用，再放大模型。

一个小技巧：记录下每个环境里所有关键组件的版本号，连同安装时间一起写进部署文档。后期排查问题的时候，这个文档往往比日志更值钱，因为很多问题就是“升级了框架，但 CANN 没跟着升”导致的版本错位。

4.2 模型下载、格式转换与校验

模型权重一般以 safetensors 格式下载。下载后我做的第一件事不是急着跑，而是核对 SHA256 校验值，权重文件不完整会在推理时出现莫名其妙的乱码，浪费大量排查时间。

昇腾平台拿到 PyTorch 权重后，通常会经过模型格式处理和编译。有些框架支持直接加载 safetensors 权重，方便做功能验证；生产环境我更建议用官方工具把模型编译成 OM 格式，这样算子融合、图优化都提前完成，运行时性能更稳定。如果中间使用 ONNX 作为过渡格式，转换完可以顺手做个结构校验：

import onnx model = onnx.load("deepseek_chunk.onnx") onnx.checker.check_model(model) print("ONNX model is valid.")

这种检查不能完全保证算子都能在昇腾上跑，但能提前拦截掉一批图结构损坏或节点信息缺失的问题，减少后续 ATC 编译报错时的排障范围。

4.3 启动推理服务并完成一次 API 调用

功能验证阶段，我会优先用 vLLM-ascend 起一个 OpenAI 兼容接口，这样后面接任何客户端都比较方便。启动命令大致长这样：

export VLLM_USE_VENDOR=ascend python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek \ --dtype bfloat16 \ --tensor-parallel-size 8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --served-model-name deepseek-local

几个参数值得解释一下。--tensor-parallel-size要和单机卡数匹配，一般设成节点内 NPU 数；--max-model-len决定模型能接受多长的上下文，设得越大，KV Cache 占用越大，并发能力越低；--gpu-memory-utilization是让框架尽量用满显存，但不要设成 1.0，留一点余量给运行时开销会更稳。

服务起来之后，用 curl 就能验证：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-local", "messages": [{"role": "user", "content": "用一句话介绍昇腾 950DT"}], "max_tokens": 200 }'

如果响应正常，说明整条链路已经通了。接下来就可以做更细的压测和调优。在此基础上，很多开发者关心“怎么把我的 IDE 或自研系统接进来”，其实思路很简单：只要服务暴露的是 OpenAI 兼容接口，就可以把客户端工具的 base_url 指向这台昇腾节点的 8000 端口，模型名填--served-model-name里定义的名字，就能在本地用 DeepSeek 能力了。

4.4 上线前的检查清单

从“跑通了”到“能上线”，我习惯用一张检查清单收口。大模型服务最怕的不是功能问题，而是容量和稳定性问题。表格里的每一项我建议都在正式切流量前检查一遍：

这张表看起来基础，但实际执行时你会发现每条都能延伸出不少细节。比如高可用测试，很多团队只在部署当天做过一次进程重启验证，结果半年以后真正遇到 NPU 故障，才发现告警没接入、自动拉起脚本早就被系统更新覆盖了。上线前把这些问题拦住，比上线后救火成本低得多。

5. 常见问题与排查实录

5.1 显存不足和 OOM

昇腾平台跑大模型最常见的故障就是out of memory，但 OOM 背后可能有好几种原因。最直接的是模型权重本身太大，单卡或并行度不够；其次是max-model-len设得偏大，长上下文请求把显存撑爆；还有一种容易被忽略，是请求并发上来后，KV Cache 突增导致显存瞬间被占满。

排查顺序一般是这样：先用npu-smi info看每卡显存占用，确认是初始化阶段就爆，还是请求过程中才爆。初始化阶段爆，优先调整并行度或精度；请求过程中爆，优先降低gpu-memory-utilization、限制max-model-len，或者限制并发数。这里我建议别把显存占用率压得太满，经验值是 90%-93% 是安全区，再高就会牺牲稳定性。

5.2 算子不支持或编译失败

昇腾平台报算子问题时，日志里经常出现“operator not supported”或类似关键词。这种情况优先确认 CANN 版本是不是太旧，很多新算子需要新版 CANN 才能编译。其次看模型里是否用了特殊的自定义算子，MoE 架构中常见的 group GEMM、RoPE 融合实现，在不同框架上支持程度不一样。

常规处理办法是把模型尽量换成官方权重和官方推理路径，避免过度自定义。如果要跑社区魔改模型，先检查它用的算子是否在昇腾支持列表里。升级 CANN 之后，记得重新编译模型格式，不能只升级运行库不重编译，否则会继续报算子和权重不匹配的错误。

5.3 吞吐上不去与延迟抖动

服务能跑但性能不达标，是这类部署里最磨人的问题。我见过很多团队把全部注意力放在 NPU 利用率上，结果利用率高，吞吐还是低。这里要区分阶段：prefill 阶段算力密集，NPU 利用率高是正常的；decode 阶段看的是显存带宽和批量调度效率，NPU 计算单元本来就不会被完全打满。

吞吐上不去的常见原因有：并发不够导致 batch 太小、continuous batching 未生效、权重精度太高导致带宽压力大、跨机并行通信开销过大。可以按顺序做三件事：把并发请求数打上去，确认框架日志里 batch size 在动态变化；开启 prefix caching，让重复请求的前缀结果被复用；最后再考虑把精度从 BF16 降到 FP8，这一步降带宽压力效果明显，但要做精度回归。延迟抖动则需要看是不是有个别慢请求拖慢了整个批次，按最大 token 数拆分请求、设置合理的超时策略会好很多。如果发现 NPU 温度过高触发降频，那就要回到底层看散热了，这种情况下调软件参数都是白搭。

5.4 数据中心侧故障与巡检要点

模型层跑得再稳，数据中心出问题一样会全盘崩溃。液冷场景最怕漏液，巡检时要重点看快接头、冷板四周有无渗漏痕迹，机房地面和机柜底部漏水检测绳要定期测试。供配电方面，要关注 UPS 电池健康度和柴发带载测试结果，AI 负载功率波动大，比传统负载更容易触发备用电源切换。

内蒙古这类寒冷地区，冬天要特别注意液冷管路的防冻问题。长时间低负载甚至停机状态下，管路里的冷却液可能接近冰点；如果冷却液浓度配置不足，管路冻裂就是大事故。相反，夏季如果室外温度偶尔偏高，又要警惕自然冷却能力不足导致的冷量缺口。运维团队最好把液冷系统的供回水温度、流量、室外温湿度这些指标做成自动化监控，而不是靠人工巡检。数据比感觉可靠。

5.5 快速排查速查表

最后聊一点个人体会。昇腾 950DT 这类国产加速卡和 DeepSeek 这类大模型的组合，很多团队在落地时容易陷入两个误区：要么只关心单卡峰值算力，忽略了显存带宽对 decode 速度的制约；要么只盯着模型层调参，不把数据中心散热、供电、结构承重这些“无形基础设施”当回事。我自己的习惯是，做这类项目先不要追求一步到位的“大集群”，老老实实从最小可用拓扑跑通，再逐步扩展。每次升级 CANN、驱动或推理框架，都先做一轮回归测试再上生产。把这些基本功做扎实，DeepSeek 加昇腾 950DT 的方案才真正有机会从“能跑 demo”走向“扛得住线上流量”。