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 字节权重约 1342GBFP8每参数 1 字节权重约 671GBINT8每参数 1 字节权重约 671GBINT4每参数 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_VENDORascend 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 上线前的检查清单从“跑通了”到“能上线”我习惯用一张检查清单收口。大模型服务最怕的不是功能问题而是容量和稳定性问题。表格里的每一项我建议都在正式切流量前检查一遍检查项验证内容关注点模型精度在固定评测集上对比参考结果量化后质量是否有劣化并发与延迟目标并发下的 TPOT、首 token 延迟高并发是否触发 OOM长上下文接近 max-model-len 的请求是否稳定KV Cache 是否爆显存高可用模拟单卡故障、进程重启服务能否自动恢复可观测性日志、指标、告警是否齐全出问题时能否快速定位安全认证API 鉴权、限流、审计是否开启防止接口被滥用机房环境机柜功率、温湿度、漏水检测是否正常液冷系统是否有告警这张表看起来基础但实际执行时你会发现每条都能延伸出不少细节。比如高可用测试很多团队只在部署当天做过一次进程重启验证结果半年以后真正遇到 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 快速排查速查表症状可能原因处理建议初始化即 OOM并行度不够、权重精度太高增大 TP/EP或降低精度请求后 OOMKV Cache 过大、并发过高调小 max-model-len限制并发算子编译失败CANN 版本低、自定义算子升级 CANN替换算子实现首 token 延迟高prefill 慢、框架批处理未生效检查输入长度开启 continuous batching生成速度忽快忽慢batch 波动、慢请求拖尾限制单批最大 token设置超时NPU 温度过高液冷流量不足、机柜热点调大流量检查冷板贴合日志出现 HCCL 超时网络抖动、多卡通信异常检查 RDMA/组网降低跨机并行度API 偶发 503实例过载、健康检查失败增加副本配置限流与重试最后聊一点个人体会。昇腾 950DT 这类国产加速卡和 DeepSeek 这类大模型的组合很多团队在落地时容易陷入两个误区要么只关心单卡峰值算力忽略了显存带宽对 decode 速度的制约要么只盯着模型层调参不把数据中心散热、供电、结构承重这些“无形基础设施”当回事。我自己的习惯是做这类项目先不要追求一步到位的“大集群”老老实实从最小可用拓扑跑通再逐步扩展。每次升级 CANN、驱动或推理框架都先做一轮回归测试再上生产。把这些基本功做扎实DeepSeek 加昇腾 950DT 的方案才真正有机会从“能跑 demo”走向“扛得住线上流量”。
DeepSeek部署昇腾950DT：从模型量化到液冷数据中心的全面拆解
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 字节权重约 1342GBFP8每参数 1 字节权重约 671GBINT8每参数 1 字节权重约 671GBINT4每参数 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_VENDORascend 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 上线前的检查清单从“跑通了”到“能上线”我习惯用一张检查清单收口。大模型服务最怕的不是功能问题而是容量和稳定性问题。表格里的每一项我建议都在正式切流量前检查一遍检查项验证内容关注点模型精度在固定评测集上对比参考结果量化后质量是否有劣化并发与延迟目标并发下的 TPOT、首 token 延迟高并发是否触发 OOM长上下文接近 max-model-len 的请求是否稳定KV Cache 是否爆显存高可用模拟单卡故障、进程重启服务能否自动恢复可观测性日志、指标、告警是否齐全出问题时能否快速定位安全认证API 鉴权、限流、审计是否开启防止接口被滥用机房环境机柜功率、温湿度、漏水检测是否正常液冷系统是否有告警这张表看起来基础但实际执行时你会发现每条都能延伸出不少细节。比如高可用测试很多团队只在部署当天做过一次进程重启验证结果半年以后真正遇到 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 快速排查速查表症状可能原因处理建议初始化即 OOM并行度不够、权重精度太高增大 TP/EP或降低精度请求后 OOMKV Cache 过大、并发过高调小 max-model-len限制并发算子编译失败CANN 版本低、自定义算子升级 CANN替换算子实现首 token 延迟高prefill 慢、框架批处理未生效检查输入长度开启 continuous batching生成速度忽快忽慢batch 波动、慢请求拖尾限制单批最大 token设置超时NPU 温度过高液冷流量不足、机柜热点调大流量检查冷板贴合日志出现 HCCL 超时网络抖动、多卡通信异常检查 RDMA/组网降低跨机并行度API 偶发 503实例过载、健康检查失败增加副本配置限流与重试最后聊一点个人体会。昇腾 950DT 这类国产加速卡和 DeepSeek 这类大模型的组合很多团队在落地时容易陷入两个误区要么只关心单卡峰值算力忽略了显存带宽对 decode 速度的制约要么只盯着模型层调参不把数据中心散热、供电、结构承重这些“无形基础设施”当回事。我自己的习惯是做这类项目先不要追求一步到位的“大集群”老老实实从最小可用拓扑跑通再逐步扩展。每次升级 CANN、驱动或推理框架都先做一轮回归测试再上生产。把这些基本功做扎实DeepSeek 加昇腾 950DT 的方案才真正有机会从“能跑 demo”走向“扛得住线上流量”。