F 层部署指南 · 场景实战
一页读懂这一部分：A–D 讲的是"怎么装"（零件），F 讲的是"怎么用"（把零件串成场景）。 前面几层的终点是"能跑起来"，F 部分的起点才是"跑起来之后遇到真问题"。
本指南是 F 部分 7 课的浓缩版（F1 模型迁移 / F2 精度调试 / F3 多卡与分布式 / F4 性能调优 / F5 国产算力适配 / F6 开源模型部署上架 / F7 模型能力到业务落地）， 只保留"什么时候用、怎么用、怎么算成了"。
一、这一部分是什么（职能）
| 项 | 内容 |
|---|---|
| 位置 | 跨层 —— 它不新装东西，而是把 A–D 的零件串起来用 |
| 一句话职责 | 解决"跑起来之后"的真实问题。 |
| 和 A–D 的区别 | A–D 回答"怎么装"，F 回答"怎么用"。 |
| 它要处理的问题类型 | 搬过来 / 结果不对 / 卡不够 / 太慢 / 环境换了一套 |
⭐ 七个场景一览
| 课 | 场景 | 一句话 | 官方物 |
|---|---|---|---|
| F1 | 模型迁移 | 把 GPU 上跑通的脚本搬到昇腾 | 迁移工具 + transfer_to_npu |
| F2 | 精度调试 | 搬过来了，但结果不对 | msProbe |
| F3 | 多卡与分布式 | 单卡不够用，要上多卡 | HCCL + torchrun |
| F4 | 性能调优 | 能跑，但跑得慢 | msProf |
| F5 | 国产算力适配 | 换到客户机房（信创环境） | OS 兼容性列表 / 配对表 |
| F6 | 开源模型部署上架 | 只有一个模型名字，要变成别人能调用的服务 | vLLM Ascend + MindIE SD |
| F7 | 模型能力到业务落地 | 服务起来了，业务怎么接上去 | MindIE / Multimodal SDK / RAG SDK |
⭐ 一条贯穿七个场景的共同纪律：
先跑通，再改。 F1 的铁律：迁移前脚本必须能在 GPU 或 CPU 上跑通（否则出错分不清是迁移引入的还是本来就有的）； F4 的原则：先看清 → 再判断 → 才动手改。 都不是巧合，是同一件事。
二、场景一 · 模型迁移（F1）
2.1 解决的什么问题
你手上有一份在 GPU 上跑得好好的脚本，要让它跑到昇腾上。
2.2 ⭐⭐ 第一条铁律（官方 CAUTION）
迁移前要保证该脚本能在 GPU 或 CPU 上运行。
意思是：迁移是"换执行设备"，不是"修 bug"。 一份本来就跑不通的脚本，迁过来只会以一种你更不熟悉的方式跑不通。
2.3 三种方式（判据只有一个：转换发生在什么时候）
| 方式 | 什么时候转换 | 一句话记住 | 官方推荐度 |
|---|---|---|---|
| 自动迁移 | 边训练边转换 | 加一行代码，跑起来它自己换 | ⭐ 推荐 |
| 工具迁移 | 先转换脚本，再训练 | 跑个工具，产出改好的脚本 + 一份报告 | 次选 |
| 手工迁移 | 人自己改 | 对比 GPU / NPU 接口，逐个动手改 | 最后手段 |
⭐ 记法：自动迁移是「边跑边换」，工具迁移是「先换再跑」。
选哪条的判据：
想省事、脚本不太特殊 → 自动迁移
要一份「改了什么」的书面记录 → 工具迁移（它产迁移报告）
自动迁移用不了（见下面三条约束） → 工具迁移
工具迁移也搞不定 → 手工迁移
命令 from torch_npu.contrib import transfer_to_npu
含义：自动迁移 —— 在脚本里加这一行 拆解：从 TorchNPU 的 contrib 里导入
transfer_to_npu用法：加在脚本靠前的位置，之后代码不用改 期望：脚本能在昇腾上跑起来 不过会怎样：撞上下面三条约束之一 → 必须改用工具迁移
2.4 ⭐ 自动迁移的三条约束（一条都不能漏）
| 约束 | 说明 |
|---|---|
① 不支持 channel_last |
用 contiguous 代替 |
② nccl 会被自动替换，但字符串判断不会 |
代码里的 if backend == 'nccl'、assert backend in ['gloo','nccl'] 要手动把字符串改成 'hccl' |
③ torch.jit.script 会冲突 |
必须用它就只能走工具迁移（这是选方式的硬判据） |
2.5 工具迁移的价值在"迁移报告"
它产出三样： - 脚本转换日志 - ⭐ 不支持算子的列表 - 脚本修改记录
⚠️ 官方明说：转换后可能因算子差异抛异常，需用户自行调试 —— 它不保证迁移后一定跑通。
⭐ 一个很好用的细节：输出目录名不带 _multi = 单卡，带 _multi = 多卡 —— 跑完不用猜结果在哪。
2.6 验收（唯一硬判据）
| # | 判据 | 怎么看 |
|---|---|---|
| ① | 迁移前能在 CPU / GPU 上跑通 | 先跑一遍，记录输出 |
| ② | 迁移后能跑完 | 不报错跑完一轮 |
| ③ | ⭐ 结果与迁移前一致 | 对比两次的输出 / 指标 |
三、场景二 · 精度调试（F2）
3.1 解决的什么问题
F1 解决了"跑不跑得动"，F2 解决"跑得动但结果不对"。
判据是：与参考平台一致（而不是"有没有报错"）。
⚠️ 一个前提：官方明说 msProbe 的快速入门仅支持标准化 CANN 容器（裸机路径要按主文档逐条确认）。
3.2 怎么用（官方六步思路）
主导方法是「整网数据比对」：
① 两侧 dump（在参考平台和昇腾上分别采集）
② msprobe compare（比对）
③ -da 找首差异算子节点 ← 关键一步
④ 堆栈回溯到代码
如果是 NaN / Inf：走 overflow_check，找首个溢出的节点。
命令 msprobe compare -da <参数>
含义：比对两侧数据，并直接找出「第一个出现差异的算子节点」 拆解：
compare（比对）＋-da（dump analysis，指定差异分析） 用法：按官方《精度调试》文档的参数格式 期望：输出首个差异算子节点及其堆栈 不过会怎样：结果全在阈值内 → 说明差异不在算子层，往配置 / 环境方向查
命令 msprobe overflow_check
含义：查首个溢出节点（NaN / Inf 场景） 用法：
msprobe overflow_check <参数>期望：定位到首个溢出的算子 不过会怎样：⚠️ 官方文档有一处口径差异 —— dump 的「功能特点」把overflow_check列为采集模式，但config.json的task可选值里并没有它 （它实际是独立子命令）→ 以实际命令为准
3.3 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 能采集到两侧数据 | dump 文件生成 |
| ② | 能比出差异 | compare 有结果 |
| ③ | ⭐ 能定位到具体算子 | 有首差异节点 |
| ④ | 能回溯到代码行 | 有堆栈 |
⚠️ 官方未给出的事（诚实标注）：
不存在通用的「哪些算子精度一定不准」清单 —— 必须针对你的具体模型实测。
也没有「整网比对通过」的统一阈值（官方只给单指标可接受阈值，如 Cosine>0.99、MaxAbsErr<0.001）。
四、场景三 · 多卡与分布式（F3）
4.1 解决的什么问题
模型太大或要提速，单卡不够用，要上多卡。
4.2 先分清：这一课不管什么
| 不归 F3 管 | 归谁 |
|---|---|
| PD 分离 / 混部的服务化调度 | D4 |
| 多卡的性能瓶颈在哪 | F4 |
| 结果对不对 | F2 |
F3 只管：脚本层面从单卡改成多卡要改什么。
4.3 怎么用（先摸三件事，再启动）
命令 python3 -c "import torch, torch_npu; print(torch.npu.device_count())"
含义：先确认框架认了几张卡 期望：数字 ≥ 你要用的卡数 不过会怎样：数字小于物理卡数 → 卡没全挂进容器 / 环境（回 L0 和 B5）
命令 torchrun --nproc_per_node=<每机卡数> <脚本>
含义：单机多卡的标准启动方式 拆解：
--nproc_per_node（每台机器起几个进程，一般等于卡数） 用法：torchrun --nproc_per_node=8 train.py期望：每个进程拿到自己的 rank，正常训练 不过会怎样： -backend相关报错 → 检查代码里有没有if backend == 'nccl'这类字符串判断（要改成'hccl'） - 多机场景还要配RANK_TABLE_FILE与hccn_tool的 device IP
命令 torch_npu_run <参数> <脚本>
含义：
torchrun在大集群场景的改进版，提升集群建链性能 拆解：官方口径 —— 建链复杂度从 O(n) 降到 O(√n) 用法：大集群场景替换torchrun期望：建链更快、更稳 不过会怎样：小规模场景用torchrun就够，不必换
4.4 ⚠️ 两个一定要先做的准备
| 准备 | 为什么 |
|---|---|
端口预留（官方示例：60000-60015） |
多卡通信要占端口，没预留会被防火墙或别的进程抢 |
HCCL_SOCKET_IFNAME 指定网卡 |
多机场景选错网卡 → 通信极慢或连不上 |
命令 mpirun -np <卡数> all_reduce_test
含义：单独验证集合通信通不通（不跑训练，先验通信） 拆解：
all_reduce_test是官方 HCCL 性能测试工具里的用例 期望：check_result全为success不过会怎样：有 fail → 通信链路有问题（网卡 / 端口 / rank table）
4.5 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 框架认到全部卡 | device_count() 等于预期 |
| ② | 通信通 | all_reduce_test 的 check_result 全 success |
| ③ | 训练能跑完 | 不报错 |
| ④ | ⭐ 数据没被算多遍 | 对比单卡与多卡在同一小数据集上的结果 |
⚠️ 官方未给出的事：任何多卡加速比数字、hccl_test 的合格带宽阈值（官方只定义"算法带宽"，没给"多少算正常"）。
五、场景四 · 性能调优（F4）
5.1 解决的什么问题
服务稳定但时延 / 吞吐不达标 —— 跑得慢怎么变快。
5.2 ⭐ 先划清和 D5 的边界
| D5《可用性与调优》 | F4《性能调优》 | |
|---|---|---|
| 问的问题 | 服务别挂 | 跑得慢怎么变快 |
| 视角 | 服务视角 | 设备与执行视角 |
| 触发场景 | 服务起来了但不稳定 | 服务稳定但时延 / 吞吐不达标 |
一句话分工：D5 管"活着"，F4 管"跑得快不快"。
5.3 怎么用（性能调优是一条链：先看清 → 再判断 → 才动手改）
本课的重点在前两步：
⚠️ 第一个坑：Profiling 默认不采
命令 msprof --output=<路径> --application="<你的命令>"
含义：采集性能数据（默认是不采的，必须显式开） 拆解：
--output（数据存放路径）＋--application（要采的那个程序） 用法：把要跑的命令包在--application里 期望：输出路径下生成性能数据文件 不过会怎样： - 忘了开采集 → 什么数据都没有，只能靠猜 - 参数随版本变，以官方《msprof 采集命令》为准
⭐ 采集的副作用：采集本身会影响性能（官方只给了影响因素排序，没给固定的膨胀比例）。
第二步：把采下来的文件读懂，判断瓶颈属于哪一类：
| 瓶颈类别 | 看什么 |
|---|---|
| 算力 | Cube 利用率够不够 |
| 带宽 / 搬运 | 数据搬运占比 |
| 通信 | Wait Time Ratio、带宽使用率 |
| 下发 / 调度 | Host Bound |
命令 npu-smi info watch -s u
含义：实时看利用率（快速初步判断） 拆解：
watch（持续刷新）＋-s u（按利用率显示） 期望：看到利用率数值 不过会怎样：⚠️ 官方明确npu-smi的利用率「不含 vector core、只是初步查看」 —— 别拿它当最终结论，深入分析要用 Profiling
5.4 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 能采到数据 | msprof 有输出文件 |
| ② | 能读出瓶颈类别 | 能说出是算力 / 带宽 / 通信 / 下发哪一类 |
| ③ | ⭐ 改动有前后对比 | 改之前有基线数据，改后能量化对比 |
⚠️⚠️ 一条数据纪律（性能数字极易被编造）： 凡官方给出阈值 / 公式的，写明出处 + 版本；官方没给的，明写「官方未给出，需现场确认」。 本指南不给任何加速比数字 —— 官方文档里也没有。
⚠️ 另一个坑：官方的性能阈值分散在不同产品、不同场景下，口径并不统一 —— 别把它们合成一张"通用红线表"（例如 MindSpeed 的那张表原文就声明不适用于在线推理、服务化调度）。
六、场景五 · 国产算力适配（F5）
6.1 解决的什么问题
换到客户机房的信创环境，前面学的东西哪里会不一样。
6.2 ⭐⭐ 一句话记住：外围变了三样，中间四层不变
| 通用环境 | 信创环境（客户机房） | |
|---|---|---|
| ① CPU 架构 | x86_64 |
aarch64（国产 CPU 多为 ARM64） |
| ② OS 家族 | Ubuntu / CentOS | openEuler / 麒麟 / 统信 / BCLinux … |
| ② 内核版本 | 常见、多数包里带编 | 常落在"要改驱动包"那一档 |
| ③ 部署形态 | 物理机为主 | 常上虚拟化 / 容器（先查配对表） |
不变的中间四层：驱动→固件顺序 / CANN 三个包 / 环境变量 / 框架 / 服务层 —— 装法一模一样。
6.3 怎么用（装之前必须确认的三件事）
命令 uname -m && cat /etc/*release && uname -r
含义：一次拿到架构 + OS + 内核版本 —— 信创环境的头号前置动作 拆解：
uname -m（架构）＋cat /etc/*release（发行版）＋uname -r（内核版本） 期望：三个值都拿到 不过会怎样：拿不到就下不了驱动 —— 官方《安装NPU驱动固件》第一步就是确认操作系统和内核版本
⭐ 为什么内核对信创特别关键： 驱动包是把内核版本编进去的 —— 对不上要装编译依赖，或改驱动包。
命令 ls /lib/modules/$(uname -r)/build
含义：检查内核头文件在不在（编译驱动需要） 拆解：
$(uname -r)（把当前内核版本塞进去） 期望：目录存在 不过会怎样：不存在 → 要装kernel-headers/kernel-devel
命令 lsmod | grep drv_pcie_host
含义：看驱动模块加载了没有 期望：有输出 不过会怎样：没有 → 驱动没装好或没加载
6.4 ⚠️ 两条信创专属的注意
| # | 注意 | 为什么 |
|---|---|---|
| 1 | 用虚拟化要先查「物理机 OS × 虚拟机 OS 配对表」 | ⭐ 查错要重装系统 —— 这是最容易返工的一步 |
| 2 | 下包前先对「OS 兼容性列表」 | 官方有明确的 OS 支持清单（openEuler / Kylin / UOS / BCLinux / CTyunOS / CULinux …） |
⭐ 官方对虚拟化场景的原话：
使用虚拟化（AVI）要先过《安装前必读·OS 兼容性列表》。
6.5 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 架构 / OS / 内核三个值拿到 | 记录清楚 |
| ② | 包按架构选对 | aarch64 的包 |
| ③ | 驱动装上、模块加载 | lsmod 有输出、npu-smi info 有表 |
| ④ | 和通用环境对照过差异 | 能说清这次哪里不一样 |
⚠️ 官方未给出的事：信创 vs 通用环境的性能差异数字（官方未给任何数字）、 「国产 CPU 型号 × 昇腾卡」的独立组合清单（要走官方兼容性查询助手）。
七、场景六 · 开源模型部署上架（F6）
7.1 解决的什么问题
你手里只有一个模型名字（比如 Qwen3、Wan2.1），怎么让它变成别人能调用的服务。
和 F1 的分工：F1 搬的是训练脚本，F6 搬的是模型与权重 —— 从一个模型名字开始，到外部能用接口调到它为止。 本场景同时覆盖两条线：大语言模型（LLM）与开源视频生成模型 —— 流程一样，判据与资源差得很远。
7.2 ⭐⭐ 一句话记住：先定「完成态」，再反推资源（顺序不能反）
| 线 | 完成态（可验证） | 验证方式 |
|---|---|---|
| LLM | ① 端口在听 ② 接口返回非空内容 ③ /v1/models 能列出模型名 |
ss / curl |
| 视频生成模型 | ① 推理跑完不报错 ② 产出可播放的文件 ③ 时长/分辨率/帧率符合预期 ④ 重复跑结果稳定 | 看输出文件 + 播放器 / ffprobe |
为什么先做这一步：权重一下就是几小时、几十 GB，改主意的成本全是重下。 最常见的错法：先把权重下下来（几十 GB、几小时），才发现卡数不够、量化档选错。 先算资源再动手：按官方分模型推荐卡数表选模型与量化档 —— LLM 示例：Qwen3-32B-W8A8 用 1 台 Atlas A3（64GB × 16）或 1 台 Atlas A2（64GB × 8）； 视频示例：Wan2.1 官方均用 8 卡。
⚠️ 官方未给「显存用量 = 参数量 × 系数」这类通用估算公式 —— 用官方「分模型推荐卡数表」选，不要用公式猜（表里的卡数是已验证过的配置，不是硬门槛）。
7.3 怎么用（最短路径：拿权重 → 校验 → 落盘权限 → 起服务 → 验证）
第一步 · 拿权重（官方三类渠道）：ModelZoo 模型库 / 权重库、开源社区（Hugging Face / ModelScope，国内推荐 ModelScope）、镜像（昇腾官方镜像仓库 / quay.io/ascend/vllm-ascend:<TAG>）。
第二步 · 下完第一件事是校验（官方明写用 sha256sum）：
命令 sha256sum ./model-00001-of-00005.safetensors
含义：算权重分片的 sha256，与官方明细页的值比对 —— 下完先校验 用法：每个分片各跑一次（
model-00001-of-00005…-00005-of-00005都要） 期望：摘要与官方文件明细页显示的值逐位一致 不过会怎样：不一致 → 文件不完整或下坏了，重下该分片，别硬上（残缺权重报错极难查）
第三步 · 落盘（容器根盘小）+ 权限配对：
命令 ls -l /path-to-weights/Wan2.1-T2V-14B
含义：看权重文件与目录的权限位是否满足官方要求 用法：逐个核对；不符就用
chmod/chgrp调整（属主要与执行用户一致） 期望：文件三组权限不超过 640，文件夹不超过 750，且属组与执行用户一致 不过会怎样：权限不对 → MindIE SD 的权限安全校验直接拒 —— 服务不是跑错，而是读不到权重
第四步 · 起服务（LLM 线，基于 vLLM Ascend v0.23.0）：
命令 vllm serve your_model_path --served-model-name qwen3 --trust-remote-code --quantization ascend --tensor-parallel-size 4 --max-model-len 5500 --port 8000
含义：用 vLLM Ascend 起一个 OpenAI 兼容的推理服务 拆解：
your_model_path（本地权重目录，不是模型 ID）＋--quantization ascend（昇腾量化档）＋--tensor-parallel-size 4（4 卡，要与ASCEND_RT_VISIBLE_DEVICES对齐）＋--port期望：日志出现服务启动完成，端口进入监听 不过会怎样：报显存不足 → 换更小模型或降量化档；报权重格式失败 → 查权重是否残缺、--quantization与权重档（W8A8 / W4A4）是否匹配；报设备不可用 → 回 L0 / L1
第四步 · 起服务（视频线，MindIE SD 官方脚本推理，8 卡示例）：
命令 torchrun --nproc_per_node=8 generate.py --task t2v-14B --size 1280*720 --ckpt_dir ${model_base} --sample_steps 50 --ulysses_size 8 --prompt "..."
含义：用 MindIE SD 跑一次文生视频 拆解：
--nproc_per_node=8（8 卡起）＋--task t2v-14B（任务类型）＋--size 1280*720（分辨率档）＋--ckpt_dir（权重路径）＋--sample_steps 50（扩散迭代步数） 用法：图生视频换--task i2v-14B（采样步数默认 40）并加--image期望：跑完不报错 不过会怎样：报并行数不匹配 → 核对官方约束ulysses_size × cfg_size = nproc_per_node；报读不到权重 → 先查权限；报 OOM → 降分辨率或减卡
第五步 · 验证（本场景最关键，两条线判据不同）：
命令 curl --fail http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"qwen3","messages":[{"role":"user","content":"who are you?"}],"max_tokens":32}'
含义：发一次真实推理请求 —— LLM 线的最终验收动作 期望：返回 JSON，
choices[0]里有非空生成内容 不过会怎样：返回 200 但内容是空的 → 官方判据：空补全不算推理成功；{"detail":"Service is not available"}→ 不是端口错，是服务没就绪（回 D3）
命令 ls -lh <输出目录> | grep -E '\.(mp4|avi|mov)$'
含义：检查视频推理的产物 —— LLM 看返回值，视频模型看文件 用法：
<输出目录>官方未给出默认落盘路径，需按运行打印确认 期望：有非零字节的视频文件，再用播放器 /ffprobe核对时长 / 分辨率 / 帧率符合--size/--frame_num预期 不过会怎样：无文件 → 推理其实没产出；文件 0 字节或打不开 → 生成失败，别当成成功
7.4 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 权重完整 | sha256sum 与官方值一致 |
| ② | 权重落数据盘 | 不在根盘，df -h 有富余 |
| ③ | 权重权限配对 | 文件 ≤640、目录 ≤750，属组与执行用户一致 |
| ④ | 服务环境自检 | 输出含 vLLM Ascend environment: OK |
| ⑤ | 端口在听 + 能列模型 | ss -lntp 有 LISTEN；/v1/models 有模型名 |
| ⑥ | ⭐ LLM 推理非空 | /v1/chat/completions 的 content 非空 |
| ⑦ | ⭐ 视频产出可播放 | 非零字节 + 可播放 + 时长 / 分辨率符合预期 |
| ⑧ | 版本可回滚 | 旧镜像 tag 与旧权重目录都留着 |
⭐ 上线前一句话：官方 12 条 checklist 全过，才算「上架」（清单见课件 4.9）。
7.5 ⚠️ 最容易做错的那一步
拿 LLM 的判据去验收视频模型 —— LLM 的产物是「一段文字」，视频模型的产物是「一个文件」。 「跑完没报错」在视频线里常常是假阳性：进程正常退出，但产物是零字节或黑屏。 所以视频线的判据必须落到「文件」上，不能落到「退出码」上。
另两个高频错：顺序反了（先下权重才发现卡不够）、权限没配对（文件明明在那里却报读不到）。
八、场景七 · 模型能力到业务落地（F7）
8.1 解决的什么问题
F6 把模型部署上架了 —— 本场景解决它后面的问题：模型跑起来了，它到底能接哪些业务，怎么才算落地。
判据换了：服务起来，不等于业务落地。 服务起来只是前提，落地看的是「接进流程没有、能不能测」。
8.2 ⭐⭐ 一句话记住：先查「不能」，再谈「能」
模型输出的是概率，不是保证。 给模型派活之前，先过一遍边界：
| 能做 | 不能做（为什么不能） |
|---|---|
| 大语言模型：理解 / 生成 / 摘要 / 改写文本 | 保证说的话是事实（它按概率生成，事实要对来源） |
| 大语言模型：按给定格式输出字段 | 准确算数 / 算账（算术要交给程序或人） |
| 多模态理解：读出图里的文字、物体、场景 | 当精密测量工具（尺寸 / 精度不能靠它） |
| 视频生成：由文字或图片生成一段视频 | 生成一段完整成片（一次就是几秒，成片靠剪辑拼） |
| 语音（识别侧）：把清晰录音转成文字 | 保证对模糊 / 口音 / 嘈杂环境都准（关键内容要人工核对） |
凡是「错了要担责、要精确、要一致」的任务，模型只能当助手，不能当责任方。
8.3 怎么用（按「输入 → 输出」对号入座 → 四件套 → 端到端链路）
四类模型就是四个工位：
| 工位 | 输入 | 输出 | 接口形态 |
|---|---|---|---|
| A 大语言模型 | 文字 | 文字 | 对话式接口（一问一答） |
| B 多模态理解 | 图片 / 视频 / 音频 + 文字 | 文字 | 同一套对话式接口 |
| C 视频生成 | 文字 / 图片 | 一段视频文件 | 脚本拉起任务 |
| D 语音 | 音频 | 文字 | 同一套对话式接口 |
⭐ 记法：A / B / D 共用一套对话接口（靠 content 是字符串还是 list 区分单模态 / 多模态）；C 是独立的脚本任务。
验「工位在岗」：
命令 curl -s http://{ip}:{port}/v1/models
含义：列出当前服务里已就绪的模型清单 —— 先看「这条线上有哪些工位在岗」 期望：返回 JSON，
data数组里能看到你部署的那个模型名 不过会怎样：连不上 → 服务没起或端口不对（回 D 层 / F6）；返回了但列表是空的 → 模型没注册进服务
验大语言模型工位（文字进、文字出）：
命令 curl -s http://{ip}:{port}/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"<模型名>","messages":[{"role":"user","content":"用一句话说明你是谁"}],"stream":false}'
含义：向对话接口发一条文字请求，看它能不能回一段文字 拆解：
model（须与配置文件里的modelName一致）＋messages（含role/content）＋stream:false（一次性返回） 期望：choices里有message.content，内容是通顺、切题的中文 不过会怎样：空返回或乱码要当失败（官方提醒：空补全不算推理成功）；报长度超限 →messages内容 ≤ 4MB
验多模态理解工位（图片进、文字出）：同一端点，content 变成 list，元素 type 取 text / image_url / video_url / audio_url。
本地文件要放官方指定目录 /data/multimodal_inputs/；走 URL 要先配白名单 ALLOWED_MEDIA_DOMAINS_ENV。
官方大小上限：图片 40MB / 音频 40MB / 视频 512MB。
验视频生成工位（文字 / 图进、视频出）：它不是对话接口，是脚本拉起任务（同 7.3 的 torchrun generate.py）—— 产出一个视频文件才算成。
落地四件套（每个场景都要能答）：
| # | 问题 | 答不上会怎样 |
|---|---|---|
| ① | 数据从哪来 | 模型没数据就是空转 |
| ② | 谁用（岗位 / 角色） | 没人用的功能等于没做 |
| ③ | 接在哪里（网站 / 微信 / 门店终端 / 内部系统） | 接口调通了但没接进流程，等于一个孤立的演示 |
| ④ | 验收指标是什么（可测） | 无法判断「到底比原来好还是差」 |
⚠️ 验收阈值本场景不给数字 —— 准确率高度依赖素材质量、场景与模型，必须按实际环境实测标定，网上抄来的百分比不能作依据。
分阶段推进顺序：先做「结果容易验证、错了代价低」的，后做「难验证、代价高」的。 第一阶段 语音识别 / 单据识别 / 摘要抽取 → 第二阶段 分类意图 / 知识库问答 → 第三阶段 文案生成 / 视频生成 → 第四阶段 接进自动化流程、逐步放权。 每阶段内部：影子期（输出不生效，只记录）→ 人工复核期（每条人工过一遍）→ 逐步放权（基本不错的抽检）。
8.4 验收
| # | 判据 | 通过标准 |
|---|---|---|
| ① | 接口能返回可用内容 | 有通顺输出（空返回不算成功） |
| ② | 边界检查做过 | 四张「能 / 不能」表逐条对过，没把「不能」的任务派出去 |
| ③ | 四件套答得上来 | 数据来源 / 谁用 / 接在哪里 / 验收指标四项都有答案 |
| ④ | 链路两端在人 | 决定做什么、错了怎么办这两端都是人 |
| ⑤ | 指标可测 | 验收指标能从日志 / 系统里取到数 |
| ⑥ | 复核机制在 | 影子期 / 复核期记录留存，能看出「错在哪类」 |
| ⑦ | ⭐ 能说清「哪里不能」 | 给一个场景，能判断该不该交给模型、不能的原因 |
8.5 ⚠️ 最容易做错的那一步
以为「接口调通了」就是「落地了」 —— 接口能返回只是前提，没接进流程、没有可测指标，就是一个孤立的演示。
另一半错法更隐蔽：把模型输出当保证用 —— 让它直接对客户报价格、算账、把输出不校验直接写库、 用视频生成作品替代实拍主素材。它输出的是概率，错的地方它不会告诉你。
九、七个场景的验收总表
| 场景 | 核心判据 | ⚠️ 最容易做错的 |
|---|---|---|
| F1 迁移 | 结果与迁移前一致 | 没先跑通原平台就迁移 |
| F2 精度 | 能定位到具体算子 | 拿"没报错"当"结果对" |
| F3 多卡 | 通信 success + 结果没被算多遍 |
backend 字符串判断没改 |
| F4 性能 | 有改动前后对比 | 忘了开采集、拿 npu-smi 利用率当结论 |
| F5 信创 | 三个值（架构/OS/内核）拿到 | 没查配对表就装虚拟化 |
| F6 上架 | LLM 非空补全 / 视频可播放文件 | 拿 LLM 判据去验收视频；权限没配对 |
| F7 落地 | 边界查过 + 四件套答得上来 | 把"接口能返回"当"落地了" |
⭐ 七个场景的共同纪律：
先跑通 / 先看清 → 再改 → 改完要有对比。
附 · 命令速查（复制即用）
# ── F1 模型迁移 ──
# 脚本里加一行（自动迁移）：
# from torch_npu.contrib import transfer_to_npu
# 手工检查字符串判断：grep -rn "nccl" <脚本>
# ── F2 精度调试（msProbe）──
msprobe compare -da <参数> # 找首差异算子节点
msprobe overflow_check # NaN/Inf 找首溢出节点
# ⚠️ 官方快速入门仅支持标准化 CANN 容器
# ── F3 多卡与分布式 ──
python3 -c "import torch, torch_npu; print(torch.npu.device_count())" # 先看认了几张卡
torchrun --nproc_per_node=8 train.py # 单机多卡
torch_npu_run ... # 大集群改进版
mpirun -np <卡数> all_reduce_test # 单独验通信
# 官方示例端口预留：60000-60015
# ── F4 性能调优 ──
msprof --output=<路径> --application="<你的命令>" # ⚠️ 默认不采，必须显式开
npu-smi info watch -s u # 快速看利用率（初步，非结论）
# ── F5 国产算力适配 ──
uname -m && cat /etc/*release && uname -r # 架构 + OS + 内核
ls /lib/modules/$(uname -r)/build # 内核头文件在不在
lsmod | grep drv_pcie_host # 驱动模块加载了吗
# ── F6 开源模型部署上架 ──
sha256sum ./model-00001-of-00005.safetensors # 下完先校验权重完整性
ls -l /path-to-weights/Wan2.1-T2V-14B # 权限：文件 ≤640 / 目录 ≤750
vllm serve your_model_path --served-model-name qwen3 --quantization ascend --tensor-parallel-size 4 --port 8000
curl --fail http://localhost:8000/v1/models # 能列出模型名
curl --fail http://localhost:8000/v1/chat/completions ... # LLM 判据：content 非空（空补全不算成功）
torchrun --nproc_per_node=8 generate.py --task t2v-14B --size 1280*720 --ckpt_dir ${model_base} --sample_steps 50 --ulysses_size 8
# ulysses_size × cfg_size = nproc_per_node
ls -lh <输出目录> | grep -E '\.(mp4|avi|mov)$' # 视频判据：非零字节 + 可播放
# ── F7 模型能力到业务落地 ──
curl -s http://{ip}:{port}/v1/models # 先看「工位在岗」
curl -s http://{ip}:{port}/v1/chat/completions -d '{"model":"<模型名>",...}'
# A 大语言模型：content 用字符串
# B 多模态 / D 语音：同一端点，content 改成 list（type = text / image_url / video_url / audio_url）
# 本地文件放 /data/multimodal_inputs/；URL 走白名单 ALLOWED_MEDIA_DOMAINS_ENV
# 上限：图 40MB / 音 40MB / 视频 512MB；messages ≤ 4MB
torchrun --nproc_per_node=8 generate.py --task t2v-14B ... # C 视频生成：脚本拉起任务，产出文件才算成
ss -lntp | grep {port} # 看端口在不在听
附 · 本部分的"官方素材在哪"
| 场景 | 官方物 |
|---|---|
| F1 | ModelZoo → PyTorch → model_migration/（迁移方式比较 / 自动 / 工具 / 手工） |
| F2 | MindStudio → 精度调试 msProbe |
| F3 | CANN → HCCL 集合通信库 + HCCL 性能测试工具；ModelZoo《PyTorch·执行训练》 |
| F4 | msProf 性能数据采集 + msprof-analyze 解析工具 |
| F5 | CANN《软件安装》操作系统兼容性 + 《虚拟机配置指南》OS 兼容性列表 |
| F6 | vLLM Ascend《模型教程·Qwen3-Dense》《安装指南》；MindIE 3.1.0《MindIE 视图生成推理快速入门》；MindSpeed《快速入门》；《Hello，ModelZoo》 |
| F7 | 《MindIE LLM 接口参考》；《MindIE SD 快速入门》《MindIE SD 特性介绍》；《Multimodal SDK 用户指南》；《RAG SDK 接口参考》 |
本部分浓缩自：
昇腾部署课件_F1_模型迁移/_F2_精度调试/_F3_多卡与分布式/_F4_性能调优/_F5_国产算力适配/_F6_开源模型部署上架/_F7_模型能力到业务落地上一层：E 部分 · 排障 下一部分：G 部分 · 企业落地