F7 模型能力到业务落地：大语言模型 / 多模态 / 视频生成 / 语音能接哪些业务

编制：观澜｜日期：2026-10-09｜级别：T2 标准级 层级：F 层 · 场景实战（F 层第 7 课；前接 A–D 零件课、F1–F6）素材来源：昇腾官方《MindIE LLM 接口参考》《MindIE Motor 快速入门》《MindIE SD 快速入门》《MindIE SD 特性介绍》《Multimodal SDK 用户指南》《RAG SDK 接口参考》本课定位：F6 解决的是「把一个开源模型部署上架」。　　　　　这一课解决它后面的问题——模型已经在机器上跑起来了，它到底能接哪些业务；　　　　　以及更关键的：把它配进现有的经营 / 生产流程，怎么配、谁用、怎么才算落地。

第一段章前定位

F6 之前，我们把「模型」当成一件零件：装好框架、拉起服务、接口能返回（D 层与 F6 讲透）。那时候的判断标准是「服务起没起来」。

这一课换一个判断标准：服务起来，不等于业务落地。

本课不教你：怎么装驱动、怎么装 CANN、怎么拉起服务、怎么迁模型——这些前面都讲过，重讲一遍是浪费你的时间。

本课不写：任何效率提升百分比、任何金额、任何客户案例。凡是官方文档没有给出的数字，本课一律写「需按实际环境实测」，不编。

本课只回答三个问题：

① 四类模型（大语言模型 / 多模态理解 / 视频生成 / 语音）分别能接什么业务？ ② 这些业务怎么和现有流程配起来——模型是流水线上的哪一站，前一站给它什么、后一站拿它什么？ ③ 怎么判断一个模型业务「真的落地了」，而不是「接口能返回就算完」？

为什么值得单独开一课：部署教程教到「curl 有返回」就结束了；而现场真正会翻车的地方，恰恰是把模型当成万能工具，接了它根本做不了的任务。这一课的重点，一半是「能做什么」，一半是「不能做什么、为什么不能」。

数据纪律声明：本课所有接口、字段、参数上限、能力边界均取自昇腾官方文档（逐条列在附录 A）。 官方没给的（效率提升值、业务准确率阈值、成本），正文一律明写「需按实际环境实测」，不编。

第二段学习目标

学完这一课，你应该能：

✅ 说出四类模型各自三个以上能接的业务，并写清每个业务的输入 / 输出 / 用在哪个环节
✅ 对每一类模型，说出它能做什么、不能做什么，以及不能的原因（这是防翻车的一栏）
✅ 对任意一个模型业务，答出落地四件套：数据从哪来 / 谁用 / 接在哪里 / 验收指标是什么
✅ 画出一条端到端链路，标清每一步「谁做、模型做哪步」
✅ 说出分阶段推进的顺序，以及为什么先做结果容易验证的那一类
✅ 记住常见误用清单——哪些任务交出去会出错，会怎么出错

第三段全景：四类模型，就是四个工位

先给地图。不要把模型想成「一个更聪明的软件」，把它想成流水线上的一台设备：

        这条流水线的原料 = 业务里的 文字 / 图片 / 视频 / 声音
                              │
   ┌──────────────┬──────────────┬──────────────┬──────────────┐
   │   工位 A      │   工位 B      │   工位 C      │   工位 D      │
   │ 大语言模型     │ 多模态理解     │ 视频生成       │ 语音          │
   │ 文字→文字      │ 图/视频/音→文字│ 文字/图→视频   │ 声音→文字     │
   └──────────────┴──────────────┴──────────────┴──────────────┘
                              │
        产出的东西要被「接走」：进网站 / 进微信 / 进门店终端 / 进内部系统

为什么要按「输入 → 输出」分这四类，而不按模型名字分：

业务方只关心「我给它什么、它给我什么」。按输入输出分，业务方自己就能对号入座；
按模型名字分，业务方听不懂，工程方也没法复用经验；
关键的是：四类的接口形态不一样——A/B/D 三类在今天的主流服务里共用一套对话接口（文字、图片、视频、音频都可以作为输入交给同一套接口），C 类（视频生成）是另一套（用脚本拉起推理任务）。这一点直接决定了它们「接在哪里」的方式不同。

工位	输入	输出	接口形态	典型耗时量级
A 大语言模型	文字（可含多轮上下文）	文字	对话式接口（一问一答）	秒级
B 多模态理解	图片 / 视频 / 音频 + 文字	文字	同一套对话式接口	秒级
C 视频生成	文字 / 图片	一段视频文件	脚本拉起任务，产出文件	分钟级（官方示例为 8 卡跑一次）
D 语音	音频	文字	同一套对话式接口	秒级

⚠️ 一个容易记混的地方：B 类的「图片 / 视频输入」和 C 类的「视频生成」都带着「视频」两个字，但方向相反—— B 是「看视频、写文字」（理解），C 是「给文字、出视频」（生成）。方向和接口都不一样，接的时候别搞反。

3.1 工位 A：大语言模型能接的业务

大语言模型的本质是「一段文字进，一段文字出」。它能接的业务，可以归成五类：

业务	输入是什么	输出长什么样	用在哪一个环节
知识库问答	用户的一句问题（+ 系统先检索到的一批资料片段）	一段带出处标注的回答	一线接待：客户 / 用户提问的第一道应答
摘要与信息抽取	一份长文档 / 一份访谈记录 / 一份合同	一段摘要，或一组结构化字段（如「金额、日期、双方」）	资料整理：把非结构化材料变成可用信息
文案生成与改写	一段要点 + 风格要求	一份初稿（文章 / 说明 / 话术）	内容生产：从要点到初稿的那一步
分类与意图识别	一条用户留言 / 一封邮件	一个类别标签（如「咨询 / 投诉 / 报价」）	分派：决定这条消息该给谁
结构化输出（供程序调用）	一段自然语言 + 一个字段格式要求	一段符合格式的字段数据（可直接被程序读取）	系统对接：把人说的话变成系统能存的字段

知识库问答为什么要「先检索、再生成」：大语言模型本身不知道企业内部的资料，硬问它会编。主流做法是先在自有资料里检索出相关片段，再把片段和问题一起交给模型——这一步在官方体系里有专门的开发套件（RAG SDK），本课不展开，见 G 层课件。

3.2 工位 B：多模态理解能接的业务

多模态理解是「图片 / 视频 / 音频进，文字出」。官方给出的输入上限是明确的（见附录 A）：

业务	输入是什么	输出长什么样	用在哪一个环节
单据 / 证照识别	一张照片（票据 / 证照 / 表单）	一组字段（官方接口图片上限 40MB）	录入：拍照代替手工敲字
图片内容判断（审看 / 质检）	一张图片	一段判断 + 说明	把关：内容合规抽查、外观初筛
视频画面理解	一段视频（官方接口上限 512MB）	一段画面描述 / 事件说明	巡检：从画面里读出「发生了什么」
图文混合问答	一张图（说明书 / 图纸 / 截图）+ 一个问题	一段回答	支持：对着图回答操作类问题
语音内容理解	一段音频（官方接口上限 40MB）	一段文字，或直接理解后的答复	记录：把说出来的话变成可检索的文字

3.3 工位 C：视频生成能接的业务

视频生成是「文字 / 图片进，一段视频出」。它是四类里最「重」的一类：耗时以分钟计、要 8 卡级别的算力、产出是文件不是文字，接口形态也和前三类不同。

业务	输入是什么	输出长什么样	用在哪一个环节
图生视频（产品 / 展品展示）	一张静态图 + 描述	一段几秒的动态片段	素材制作：把一张图变成可播放的动态素材
文生视频（概念预演 / 分镜）	一段文字描述	一段几秒的视频	前期预演：把脚本里的画面先做出来看效果
氛围镜头 / 空镜补充	一段风格描述	一段氛围素材	素材补充：补拍摄时没拍到的镜头

官方快速入门给的参数能看出它的边界：帧数默认 81 帧、采样步数文生视频默认 50、图生视频默认 40、分辨率有固定档位——这意味着它一次产出的是「几秒的片段」，不是一段成片。

3.4 工位 D：语音能接的业务

语音在官方体系里，做得最扎实的是「语音进、文字出」这一半（识别侧）：

业务	输入是什么	输出长什么样	用在哪一个环节
会议 / 访谈记录	一段录音	一段文字稿	记录：把口头内容变成文字
客服录音整理	一段通话录音	文字稿 + 要点	归档：从录音里提取可检索内容
语音直接问答	一段语音（官方接口音频上限 40MB）	一段回答	交互：用户直接说话，系统直接答

⚠️ 诚实标注（重要）：本课把「语音」单列一类，但截至本课取材时，官方文档中「语音识别」有专门的样例与迁移实践，而「语音合成（文字转语音）」未见独立的推理章节。 因此本课只写「语音识别」侧能接的业务；语音合成侧的部署与接口，需按实际选型到官方文档与开源实现中另行确认——这里不编。

第四段【如果我来做】——把模型配到业务上

这一节是本课的核心。 前面讲的是「四类模型各能干什么」，这一节讲的是：如果现在把已经部署好的模型交给我，我按什么顺序、用什么标准，把它配进一套真实业务。

4.0 先亮结论：我会按这个顺序做

为什么顺序不能反：业务落地最容易犯的错，是先想「用 AI 做点什么」，再去找场景。正确的顺序反过来：先看业务里哪个环节卡着，再看四类模型哪个能接这个环节。

我会按这个顺序做：

① 找环节：在现有流程里找出一个「重复、耗时、有明确输入输出」的环节 ② 对工位：看这个环节的输入输出，对上四类模型里的哪一类 ③ 查边界：先看这一类模型不能做什么——能过边界检查的场景才继续 ④ 四件套：写清数据从哪来 / 谁用 / 接在哪里 / 验收指标 ⑤ 小范围：先在一个环节、少量样本上跑，人工全程复核，只看「错在哪」 ⑥ 定指标：按实际环境实测出验收阈值（不抄网上的百分比） ⑦ 再放权：复核中发现稳定可靠的部分，逐步减少人工复核；不稳的部分退回人工 ⑧ 诚实：官方没给数字的地方，明写「需实测」，不编

下面把每一步展开。

4.1 第 ③ 步最重要：先查「不能」，再谈「能」

这是本课最想让你记住的一条。 给模型派活之前，先拿下面四张表过一遍——凡是落在「不能」栏里的，直接不做，别试。

表 A · 大语言模型的能 / 不能

能做	不能做	为什么不能
理解、生成、摘要、改写文本	保证说的话是事实	它按概率生成，说得像真的不等于真的——事实要对来源，不能对模型
按给定格式输出字段	保证每一次都严格合规	输出是概率结果，格式要靠程序再校验一遍，不能直接信
分类、抽取、按要点扩写	准确算数 / 算账	算术不是它的强项，报价单、账单必须由程序或人算
多轮对话、按角色回答	访问你没给它的数据	它只知道你放进上下文里的东西；没给就是不知道（会编）
——	知道最新的事	知识有时间边界，时效要靠外部检索补
——	替你做决定并担责	它是建议者不是责任人，决策与责任必须在人这一侧
——	处理超过上限的输入	官方接口对请求内容有长度上限（见附录 A），超了要切分

表 B · 多模态理解的能 / 不能

能做	不能做	为什么不能
读出图里的文字、物体、场景	当精密测量工具	它理解的是画面语义，不是标定过的尺子；尺寸 / 精度不能靠它
判断内容是否合规、外观是否异常	保证细粒度计数全对	目标多、目标小时会漏会错；计数要有专门方法
读懂视频画面大意	逐帧替代人工看完整段视频	走的是抽帧理解，不是逐帧全量；关键帧可能被跳过
听懂语音内容	处理模糊 / 遮挡 / 低质素材	输入质量差，输出就差；输出好坏跟着输入走
处理规定格式和大小的文件	超过官方大小上限的输入	官方接口有明确上限（图片 / 音频 40MB、视频 512MB），超了要先压缩或分段
——	保证同一输入每次同一结果	生成类任务带随机性，要求严格一致时要固定参数

表 C · 视频生成的能 / 不能

能做	不能做	为什么不能
由文字或图片生成一段视频	保证画面里的文字正确	画面里的文字会糊、会错，不能拿它做必须清晰的文字
生成几秒的动态片段	生成一段完整成片	官方示例的帧数档位决定了一次就是几秒；成片要靠剪辑拼
按分辨率 / 帧数 / 采样步数控制	保证同一个人物前后一致	跨镜头一致性是难点，官方文档也未承诺
快速产出创意参考	替代实拍做主素材	物理真实度与细节达不到实拍；适合预演和补充，不适合完全替代
——	在普通算力上快速产出	官方快速入门以 8 卡为例，生成是分钟级、重算力的任务

表 D · 语音（识别侧）的能 / 不能

能做	不能做	为什么不能
把清晰录音转成文字	保证对模糊 / 口音 / 嘈杂环境都准	识别质量跟着录音质量走；恶劣环境下错误率会明显上升
处理规定格式的音频	超过上限的音频	官方接口音频上限 40MB，长录音要分段或压缩
直接理解语音内容	分辨没听清的内容	听错的地方它不会告诉你它听错了——关键内容要人工核对

一句话：模型的能力边界，就是「它输出的是概率，不是保证」—— 凡是「错了要担责、要精确、要一致」的任务，模型只能当助手，不能当责任方。

4.2 落地四件套（每个场景都要能答）

任何一个模型业务，如果答不上下面四个问题，就还没有到「能落地」的程度：

#	问题	答不上会怎样
①	数据从哪来	模型没数据就是空转；没定数据来源，业务跑不起来
②	谁用（岗位 / 角色）	没人用的功能等于没做；不知道谁用就不知道按谁的习惯设计
③	接在哪里（网站 / 微信 / 门店终端 / 内部系统）	接口调通了但没接进流程，等于一个孤立的演示
④	验收指标是什么（可测）	没有可测指标，就无法判断「到底比原来好还是差」

四件套怎么写，举两个例子：

单据识别场景：① 数据 = 现场拍的单据照片；② 谁用 = 录入岗；③ 接在哪里 = 内部录入系统（识别结果先进待确认列表）；④ 验收指标 =「字段识别正确率（按抽检样本人工评分，阈值需按实际环境实测标定）」+「人工修改率」。
会议记录场景：① 数据 = 会议的录音文件；② 谁用 = 会务 / 记录岗；③ 接在哪里 = 内部知识库（文字稿入库可检索）；④ 验收指标 =「转写可用率（抽检看关键结论有没有被正确识别）」+「人工整理耗时」。

⚠️ 注意：上面所有「阈值」本课都不给具体数字——因为准确率高度依赖你的素材质量、场景和模型，必须按实际环境实测标定。网上抄来的百分比不能作为验收依据。

4.3 与现有流程怎么配：把模型当成流水线上的一个工位

用户点名要的是这一段：工位前一个环节给它什么、后一个环节从它拿什么。 举四条完整的端到端链路。

链路一：内容生产（素材 → 脚本 → 成片 → 发布 → 承接 → 成交 → 数据回收）

① 素材收集   人找素材、定主题                        【人】
② 脚本初稿   把要点交给大语言模型 → 出脚本初稿         【模型 A：文案生成】
③ 脚本定稿   人对初稿做事实核对、定稿                  【人 ← 这一站不能省】
④ 画面成片   视频生成出片段，剪辑成片                  【模型 C + 人剪辑】
⑤ 发布       人到各平台发布                            【人 / 内部系统】
⑥ 承接       用户提问 → 模型按知识库答 → 人工兜底       【模型 A + 人】
⑦ 成交       人谈                              【人】
⑧ 数据回收   把⑥的问答记录下来，回填到下一轮素材      【内部系统】

谁做哪一步：模型做②（初稿）和⑥（第一道应答）；③（事实核对）和⑦（成交）必须是人——这两站错不起。

链路二：咨询应答（问题 → 意图 → 检索 → 生成 → 复核 → 回复 → 归档）

① 用户提问   用户在网站 / 微信里发一句问题             【入口】
② 意图识别   大语言模型判断这是「咨询 / 投诉 / 报价」   【模型 A：分类】
③ 检索资料   按意图到企业资料里检索相关片段             【检索（G 层 RAG）】
④ 生成回答   问题 + 片段 → 大语言模型出回答             【模型 A：问答】
⑤ 人工复核   一线人员看回答、改、再发                   【人 ← 第一版必须留】
⑥ 回复       发出                                     【入口】
⑦ 归档       把问答存下来，供下一轮检索                【内部系统】

谁做哪一步：模型做②③④；⑤是这一站的安全阀——稳定之后可以只抽检，但一开始必须全查。

链路三：单据 / 资料录入（拍照 → 识别 → 校验 → 入系统 → 抽检）

① 采集       现场拍单据照片                            【人 / 终端】
② 识别       多模态理解把图变成字段                     【模型 B】
③ 校验       程序检查字段格式、必填项、逻辑关系         【程序 ← 不能省】
④ 入系统     通过校验的进系统，没过的进待确认列表       【内部系统】
⑤ 抽检       人工抽查入系统的记录                      【人】

谁做哪一步：模型做②；③的程序校验是关键——模型输出是概率结果，必须由程序再挡一道，不能识别完直接入库。

链路四：会议 / 培训记录（录音 → 转写 → 摘要 → 归档 → 分派）

① 录音       会议 / 培训全程录音                       【人】
② 转写       语音转文字                                【模型 D：识别】
③ 摘要       文字稿 → 大语言模型出纪要要点              【模型 A：摘要】
④ 人工校对   人核对关键结论、纠正错别字                 【人 ← 关键内容必须核对】
⑤ 归档入库   纪要进内部知识库                          【内部系统】
⑥ 分派       把纪要里的任务分给对应的人                 【人】

谁做哪一步：模型做②③；④必须有人——语音识别听错的地方，它自己不会告诉你它听错了。

四条链路看下来，一个共同规律：模型永远是中间某几站，两头（决定做什么、错了怎么办）永远在人这一侧。 把模型配进流程，不是「用模型替掉人」，而是「让原来做这些枯燥段落的人，把精力挪到两头」。

4.4 分阶段推进顺序

先做哪类、后做哪类，有一条清晰的原则：

先做「结果容易验证」的，后做「结果难验证」的；先做「错了代价低」的，后做「错了代价高」的。

按这条原则，四类模型的推进顺序大致是：

阶段	先做	为什么排这个位置
第一阶段	语音识别、单据识别、摘要抽取（输入 → 信息）	输出是「可核对的事实」，错了容易发现；错了代价低，退回人工即可
第二阶段	分类意图、知识库问答（信息 → 信息）	需要知识库配合，输出可抽检；比第一阶段风险高一档，但仍有出处可查
第三阶段	文案生成、视频生成（信息 → 内容）	输出偏主观，需要人工把关；视频生成还重算力、耗时
第四阶段	把模型接进自动化流程、逐步放权	影响面最大，必须等前三阶段的复核数据攒够

每个阶段内部都用同一种推进法（通用表述）：

影子期     模型在后台跑，但输出不生效——只记录「如果用它，会输出什么」
              ↓  对比人工结果，看错在哪、错多少
人工复核期  模型输出生效，但每一条都人工过一遍
              ↓  复核中记录「哪类必错、哪类基本不错」
逐步放权    对「基本不错」的部分减少复核（抽检）；对「必错」的部分退回人工或加规则

为什么不能一步到位：一次上全套、无人复核，最可能的结局是把个别错误放大成批量错误。 模型单条出错不致命，批量出错才致命——所以推进必须是「小范围 → 看结果 → 再扩大」。

第五段怎么确认就位（命令 + 期望输出）

前面讲的是「配业务」，这一段讲的是「怎么确认模型真的能干活」——不是「服务起没起来」，而是「给它一个真实输入，它能不能给出可用输出」。下面每条命令都用 行内码 + 引用块给出，逐条带「含义 / 拆解 / 用法 / 期望 / 不过会怎样」。 {ip}:{port} 用服务业务面的 IP 与端口（官方原文：即 ipAddress 和 port）。

5.1 先看「这条流水线上装了哪些工位」

命令　curl -s http://{ip}:{port}/v1/models

含义：列出当前服务里已经就绪的模型清单——相当于先看「这条线上有哪些工位在岗」拆解：curl（发一次 HTTP 请求）＋ -s（静默，不打印进度条）＋ GET /v1/models（官方兼容 OpenAI 接口的「列举模型」端点）用法：把 {ip}:{port} 换成业务面地址，直接在能访问到服务的机器上敲期望：返回一段 JSON，里面有 data 数组，能在列表里看到你部署的那个模型名，才算这条工位在岗 不过会怎样：连不上（Connection refused）→ 服务没起来或端口不对，回 D 层 / F6 查服务；返回了但列表是空的 → 模型没注册进服务，检查启动配置里的模型名与路径

5.2 验大语言模型工位（文字进、文字出）

命令　curl -s http://{ip}:{port}/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"<模型名>","messages":[{"role":"user","content":"用一句话说明你是谁"}],"stream":false}'

含义：向对话接口发一条文字请求，看它能不能回一段文字——这是大语言模型工位的「干活」验收拆解：POST /v1/chat/completions（官方兼容 OpenAI 接口的推理入口）＋ model（模型名，须与配置文件里的 modelName 一致）＋ messages（消息数组，含 role 与 content）＋ stream:false（一次性返回）用法：官方请求参数里 role 可取 system / user / assistant / tool；单模态文本模型 content 可传字符串期望：返回 JSON，choices 里有 message.content 文本，内容是通顺、切题的中文——才算这条工位真的在干活（⚠️ 官方提醒：「空补全」不算推理成功，内容为空要当失败处理） 不过会怎样：报 model 不匹配 → 名字写错，回 5.1 抄正确的；返回内容为空或乱码 → 权重 / 配置有问题，回 D 层排查；报长度超限 → 超了官方上限（messages 内容 ≤ 4MB，token 数受配置限制）

5.3 验多模态理解工位（图片进、文字出）

命令　curl -s http://{ip}:{port}/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"<模型名>","messages":[{"role":"user","content":[{"type":"text","text":"这张图里有什么"},{"type":"image_url","image_url":{"url":"/data/multimodal_inputs/test.jpg"}}]}]}'

含义：向同一个对话接口交一张图片 + 一句话，看它能不能看图说话——这是多模态理解工位的验收拆解：与 5.2 同一个端点，区别在 content 变成 list：官方规定多模态模型的 content 为 list，元素 type 可取 text / image_url / video_url / audio_url 用法：本地文件方式要把文件放在官方指定目录 /data/multimodal_inputs/；若走 HTTP/HTTPS URL，要先配白名单环境变量 ALLOWED_MEDIA_DOMAINS_ENV 期望：返回 JSON，内容是对图片的正确描述或回答——说明图片解码、理解这条链路通了 不过会怎样：报文件找不到 → 图片没放到 /data/multimodal_inputs/；报域名不允许 → 走 URL 时没配 ALLOWED_MEDIA_DOMAINS_ENV；报图片过大 → 官方上限 40MB，超了要先压缩

5.4 验语音理解工位（音频进、文字出）

命令　curl -s http://{ip}:{port}/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"<模型名>","messages":[{"role":"user","content":[{"type":"text","text":"把这段音频转成文字"},{"type":"audio_url","audio_url":{"url":"/data/multimodal_inputs/test.wav"}}]}]}'

含义：交一段音频，看它能不能理解音频内容——语音侧的验收拆解：同样走对话接口，content 为 list，元素 type 为 audio_url；官方支持服务器本地路径与 URL 两种传入用法：官方支持音频类型 MP3 / WAV / FLAC，单个音频上限 40MB；本地文件同样放 /data/multimodal_inputs/ 期望：返回 JSON，内容与音频里说的话对应（识别为文字，或按音频内容作答） 不过会怎样：报格式不支持 → 音频不是 MP3 / WAV / FLAC；报过大 → 超 40MB，长录音要分段或压缩；返回内容与原话不符 → 录音质量或口音问题，关键内容必须人工核对

5.5 验视频生成工位（文字 / 图进、视频出）

命令　torchrun --nproc_per_node=8 generate.py --task t2v-14B --size 1280*720 --ckpt_dir <权重路径> --sample_steps 50 --prompt "<描述文字>"

含义：用官方脚本拉起一次文生视频推理任务，产出一个视频文件——视频生成工位的验收（注意它不是对话接口，是脚本拉起任务）拆解：torchrun（分布式启动器）＋ --nproc_per_node=8（用 8 张卡）＋ generate.py（官方仓库里的推理脚本）＋ --task（任务类型）＋ --size（分辨率档位）＋ --ckpt_dir（权重目录）＋ --sample_steps（采样步数）＋ --prompt（描述词）用法：出自官方《MindIE SD 快速入门》示例；图生视频还要加 --image（输入图）与 --frame_num（帧数，官方默认 81）；模型名与权重以官方该章节为准 期望：命令跑完，在输出目录里生成一个视频文件，能播放、画面与描述大致相符 不过会怎样：报找不到权重 / 权限错 → 官方要求权重与配置文件权限不超 640、所在文件夹不超 750；卡数不够 → 官方示例为 8 卡，卡数不足会失败；生成结果与描述差很远 → 调 prompt、分辨率与 sample_steps，这类参数需按实际场景调试，无通用最优值

5.6 顺带看一眼：服务在不在、卡忙不忙

命令　ss -lntp | grep {port}

含义：看服务端口有没有在监听——最快判断「服务起没起来」拆解：ss（套接字状态）＋ -l（只看监听中的）＋ -n（端口显示为数字）＋ -t（TCP）＋ -p（显示进程）＋ grep {port}（筛出目标端口）用法：{port} 换成业务面端口；这是通用系统命令，非昇腾专用（本课标注）期望：打印出监听该端口的一行，含进程名 不过会怎样：无输出 → 服务没起或端口填错，回 D 层；有监听但 5.1 连不上 → 多半是防火墙或 IP 填错（业务面 IP 与容器 / 主机 IP 不是一回事）

命令　npu-smi info

含义：看昇腾卡的占用情况——判断「卡上是不是已经有任务占着」，避免多个模型抢卡拆解：npu-smi（昇腾设备管理工具）＋ info（显示设备信息子命令）用法：跑视频生成这类重任务前先看一眼；⚠️ 官方提示 npu-smi 不支持多线程并发使用 期望：一张表，列出每张卡的型号、温度、显存占用、进程 不过会怎样：命令不存在 → 驱动没装（回 A1）；显存已被占满 → 先确认是谁占着，别硬起新任务；列不出卡 → 硬件 / 权限问题，走技术支持

第六段判据与验收

「模型业务落地了」跟「模型服务起来了」的判据不一样——服务起来只是前提，落地看的是「接进流程没有、能不能测」。

#	判据	验证方式	不过说明问题在
①	接口能返回可用内容	5.2–5.4 有通顺输出（空返回不算成功）	服务 / 模型（回 D 层、F6）
②	边界检查做过	4.1 的四张「能 / 不能」表逐条对过，没有把「不能」的任务派出去	场景选型（最防翻车的一步）
③	四件套答得上来	数据来源 / 谁用 / 接在哪里 / 验收指标四项都有答案	需求没想清
④	链路两端在人	端到端链路里，决定做什么、错了怎么办这两端都是人	流程设计（想用模型替人）
⑤	指标可测	验收指标能从日志 / 系统里取到数（哪怕只是一个抽检正确率）	指标没定义
⑥	复核机制在	影子期 / 复核期的记录留存，能看出「错在哪类」	放权过早
⑦	能说清「哪里不能」	给一个场景，能判断该不该交给模型、不能的原因	本课的核心能力

第 ② 条和第 ⑦ 条是本课区别于「模型介绍文」的地方：讲模型能力的文章基本只讲「能做什么」，而现场翻车，多半是把「不能做」的那部分派出去了。

一句验收口径：

「接口能返回」不算落地，
「边界查过、四件套答得上来、端到端链路接进流程、有可测指标」才算落地。

第七段出问题怎么查

排查原则：先分清「是模型不行」还是「是流程没配好」，再谈技术细节。

模型业务的问题，绝大多数能归到下面六类：

现象	大概是什么	先查什么
接口能返回，但内容明显不对	不是服务问题，是任务超出了模型边界	回 4.1 四张表，看这个任务在不在「不能」栏
同一个输入，两次结果不一样	生成类任务的随机性	固定随机种子与生成参数；确认这是不是可接受的
内容对但格式乱、程序读不进去	把模型输出直接当了结构化数据	加一道程序校验（4.3 链路三的②③之间那一步）
识别 / 理解明显变差	输入质量（图片太糊、录音太吵、文件超限）	先看输入素材质量与大小（图 40MB / 音 40MB / 视频 512MB 上限）
接了 URL 图片 / 音频就报域名错	白名单没配	配 `ALLOWED_MEDIA_DOMAINS_ENV`
视频生成很慢或失败	算力 / 参数问题	看 `npu-smi info` 卡占用；核对分辨率 / 帧数 / 采样步数档位

⭐ 一个判断法（按「模型问题 vs 流程问题」归类）：

换个简单输入试，还是错              →  大概率是模型 / 服务问题（回 D 层、F6）
换个人工核对，发现是「它做了不该做的」 →  是场景选型问题（回 4.1）
输出对但下游系统读不进去             →  是流程没加校验（回 4.3）
时好时坏、坏在复杂输入上             →  是输入质量问题（查素材）

⭐ 模型业务特有的排查顺序（这是本课的重点）：

① 先用「最简单的输入」确认服务本身没问题（5.2）
② 再用「真实业务的输入」复现，看错在哪一类
③ 拿 4.1 的表判：这个任务本来就不该给模型 → 退回去
④ 该给模型、但结果不稳 → 调参数 / 加校验 / 换更合适的模型
⑤ 全流程跑一遍，确认错在「模型这一站」还是「前后站」

记住一条：接口报错好查，内容出错难查——接口报错有码可查（E 层），内容出错往往没有报错，只能靠人工复核记录 + 边界检查发现。所以复核记录本身，就是最重要的排查工具。

第八段常见误用清单与报错清单

误用的共同点：把「输出是概率」的东西，当成了「输出是保证」。

误用	会发生什么	正确做法
让大语言模型直接对客户报价格 / 交期	它会编，且没人担责	价格 / 交期由程序或人给，模型只做话术
让大语言模型算账、做报价单	算术出错且看不出来	计算交给程序，模型只做理解与表达
把模型输出不校验直接写数据库	脏数据入库，污染下游	加程序校验（格式 / 必填 / 逻辑）后再入库
让多模态读精密尺寸 / 仪表读数	精度不够，读数不可靠	精密测量交给专业设备
用视频生成的作品替代实拍主素材	细节 / 一致性不足，容易被识破	只用于预演和补充，不替代实拍
一次上全套、无人复核	个别错误被放大成批量错误	影子期 → 复核期 → 逐步放权
拿模型当唯一判断、替人决策	责任真空，出事后无人负责	模型只给建议，决策与责任留给人
把关键内容（金额、人名、结论）只靠语音识别	听错了它不会告诉你	关键内容人工核对
以为「接口调通了」就是「落地了」	功能孤立在流程外，没人用	按四件套接进流程

常见报错清单（先按现象定位）：

现象	大概属于	先查什么
`curl` 连不上业务面端口	服务未起 / 端口或 IP 错	5.6 看端口监听；核对业务面 IP
`/v1/models` 返回空列表	模型未注册	检查启动配置里的模型名与权重路径
报 `model` 不匹配	模型名写错	用 5.1 的返回值抄正确名字（须与配置 `modelName` 一致）
返回内容为空 / 乱码	权重 / 配置异常	回 D 层排查；空返回当失败处理
请求内容长度超限	超过官方上限	缩短或切分输入（`messages` ≤ 4MB 等）
图片 / 音频报文件找不到	没放对目录	本地文件放 `/data/multimodal_inputs/`
URL 媒体报域名不允许	白名单未配	配 `ALLOWED_MEDIA_DOMAINS_ENV`
图片 / 音频 / 视频过大	超官方大小上限	图 / 音 40MB、视频 512MB，超了压缩或分段
视频生成脚本报权限错	权重 / 目录权限不符	权重文件 ≤ 640、所在文件夹 ≤ 750
视频生成卡数不够	算力不足	官方示例为 8 卡；核对该型号支持的卡数

⚠️ 诚实标注：上表中「业务内容出错」这一类官方文档不会给出报错原文——它根本不是「报错」，是「输出不合预期」。这类问题只能靠人工复核记录与 4.1 的边界检查发现，不能指望日志。

第九段小结与下一课

这一课要带走的三句话：

四类模型就是四个工位：大语言模型（文字 ↔ 文字）、多模态理解（图 / 视频 / 音 → 文字）、视频生成（文字 / 图 → 视频）、语音（音 → 文字）。按「输入 → 输出」对号入座，业务方也能自己判断。
先查「不能」，再谈「能」：模型输出的是概率不是保证—— 凡是「错了要担责、要精确、要一致」的任务，模型只能当助手，不能当责任方。
落地看四件套 + 端到端链路：数据从哪来 / 谁用 / 接在哪里 / 验收指标可测—— 再画清「前一站给什么、后一站拿什么」，两头（决定做什么、错了怎么办）永远在人这一侧。

本课的选择顺序（串联全课）：

找环节 → 对工位 → 【查边界：先看不能做什么】→ 四件套 → 小范围（影子 / 复核）
      → 实测定指标 → 逐步放权 → 诚实（没数字的地方写"需实测"）

自测（能答上来才算学会）：

举一个你熟悉的业务环节，说清它的输入输出，并对上四类模型里的哪一类。
对上述场景，写出四件套的四项答案。
说出这一类模型的三个「不能做」，以及为什么不能。
把你选的场景画成一条端到端链路，标清每一步谁做、模型做哪步。
说出为什么「语音识别、单据识别、摘要」要排在「文案生成、视频生成」前面。

下一课预告（F 层收尾）：本课回答的是「模型部署出来，业务怎么接上去」。 F 层到这里，从「把零件串成场景」告一段落；再往后，企业落地会进入更靠业务的一层—— 私有化与数据流向、企业知识库怎么建、检索与问答怎么调、怎么评估效果与规划容量。它们和本课的关系是：本课给的是「模型能接什么」的全景，再往后的部分给的是「企业里怎么把它建稳、管住、测准」。

附录 A · 本课引用的官方出处

内容	来源文档
对话接口 `POST /v1/chat/completions`、`GET /v1/models`、`model` / `messages` / `role`（system / user / assistant / tool）/ `content` / `stream` 等参数说明	《MindIE LLM 接口参考》·API接口说明·RESTful API参考·EndPoint业务面RESTful接口·兼容 OpenAI 接口 · 推理接口 / 列举当前模型列表
`content` 为 list、`type` 取 `text` / `image_url` / `video_url` / `audio_url`；图片 40MB / 视频 512MB / 音频 40MB 上限；`ALLOWED_MEDIA_DOMAINS_ENV` 与本地目录 `/data/multimodal_inputs/`；磁盘预留公式	同上·推理接口（多媒体文件使用说明）
`messages` 内容 ≤ 4MB、token 上限（`maxInputTokenLen` / `maxSeqLen`）；Function Call 仅部分模型支持；原生接口 `/infer` 即将下线、建议改用 OpenAI 接口	同上·推理接口 / 文本 / 流式推理接口（MindIE 原生接口）
「空补全」不算推理成功	见本体系 D2 课；官方口径见 MindIE 服务化相关说明（本课沿用）
Multimodal SDK：图像解码 / resize / crop、视频帧解码（`video_decode`，`frame_indices` / `sample_num`）、音频加载（`load_audio`，`sr` 重采样）；图片 jpg / jpeg、视频 mp4、音频 wav	《Multimodal SDK 用户指南》·样例和指导（图片 / 视频 / 音频处理）
多模态预处理 Adapter（Qwen2VL / InternVL2 加速）、vLLM 推理框架集成（patcher）	同上·下一步 / Adapter / patcher
MindIE SD 文生视频 / 图生视频：`torchrun --nproc_per_node`、`generate.py`、`--task t2v-14B` / `i2v-14B`、`--size`、`--ckpt_dir`、`--frame_num`（默认 81）、`--sample_steps`（t2v 50 / i2v 40）、`--prompt`	《MindIE SD 快速入门》（MindIE 3.1.0）·模型推理
视频生成权重权限要求（文件 ≤ 640、文件夹 ≤ 750）、容器启动参数、容器内组件路径、模型仓库获取方式	同上·获取模型权重 / 启动容器
稀疏注意力（RainFusion2.0 强制首帧参与全注意力，80% 稀疏率下质量基本无损；官方称达 1.5–1.8× 端到端加速）与量化特性、仅 Atlas 800I A2 支持	《MindIE SD 特性介绍》·稀疏 / 量化
MindIE Motor PD 分离快速入门（P/D 实例配置、`user_config.json`、环境变量、`deploy.py`）	《MindIE Motor 快速入门》（MindIE 3.1.0）
语音识别样例（从输入语音解析出文本）	《Atlas 200I DK A2 开发者套件·应用开发入门》·体验预置应用·语音识别样例
文字识别（OCR）样例、目标检测样例	同上·文字识别样例 / 内容介绍
知识库问答「先检索、再生成」、RAG SDK 定位	《RAG SDK 接口参考》；本体系 G 层课件
文档解析中的 OCR（第三方 PaddleOCR，识别精度依赖第三方模型）	《RAG SDK 接口参考》·知识管理

本课未做的事（数据纪律）：

未给任何效率提升百分比、任何金额、任何客户案例——官方文档未给出这类数字，故不编造。
未给业务验收的准确率阈值（如识别正确率、问答可用率应达到多少）——这类阈值高度依赖场景与素材，必须按实际环境实测标定，本课只给方法（四件套的④）。
未给成本数据（算力成本、单位调用成本）——需按实际环境实测。
未给「语音合成（文字转语音）」的部署与接口——截至取材时官方文档未见独立推理章节，需按实际选型另行确认（正文 3.4 已标注）。
视频生成的 1.5–1.8× 加速为官方《MindIE SD 特性介绍·稀疏》文档中的表述，引用时标注出处（本附录）；在具体硬件与参数下的实际表现，需按实际环境实测。
未点名任何具体商业公司 / 产品品牌作为业务案例；正文提到的模型能力与参数均来自官方接口与快速入门文档。
未覆盖：把模型接进具体业务系统时的鉴权、并发、限流、日志审计等工程细节（属企业落地与服务化的范围）。

附录 B · 接口与命令逐条详解

B.1 四类工位的接口一览

工位	主接口	形态	关键字段	官方上限
A 大语言模型	`POST /v1/chat/completions`	对话式	`model` / `messages`（`role`,`content`）/ `stream`	`messages` ≤ 4MB；token 受配置限制
B 多模态理解	`POST /v1/chat/completions`	对话式	`content` 为 list，`type` = `text` / `image_url` / `video_url` / `audio_url`	图 40MB / 视频 512MB / 音 40MB
C 视频生成	官方脚本 `generate.py`（`torchrun` 拉起）	任务式	`--task` / `--size` / `--frame_num` / `--sample_steps` / `--prompt` / `--image`	官方示例 8 卡；帧数默认 81
D 语音	`POST /v1/chat/completions`	对话式	`content` 为 list，`type` = `audio_url`	音频 40MB（MP3 / WAV / FLAC）

记忆点：A/B/D 共用一套对话接口，靠 content 是字符串还是 list 来区分单模态 / 多模态；C 是独立的脚本任务。 这就是为什么 A/B/D「接在哪里」的方式相似（都能直接挂在网页 / 微信后端），而 C 更像一个「异步出片」的后台任务。

B.2 `/v1/models` 与 `/v1/chat/completions` 请求要点

项	说明
`GET /v1/models`	列举当前模型列表；确认「工位在岗」用
`GET /v1/models/{model}`	查询单个模型信息
`POST /v1/chat/completions`	推理入口；URL 与 `v1/chat` 一致，靠配置里 `openAiSupport` 区分走哪套兼容接口（取 `vllm` 或缺失时走 vLLM 兼容 OpenAI 接口）
`model`	必选，须与配置文件 `modelName` 一致
`messages[].role`	`system` / `user` / `assistant` / `tool`
`messages[].content`	单模态文本模型：字符串；多模态模型：list（含 `type` 元素）
`stream`	`true` 流式（边生成边返回），`false` 一次性返回

B.3 多模态输入的两条路径

路径	怎么给	前提
HTTP / HTTPS URL	`"url": "http(s)://..."`	先配 `ALLOWED_MEDIA_DOMAINS_ENV` 白名单；官方提示避免解析到本地 / 内网 IP 与可解析到任意 IP 的域名
本地文件	`"url": "/data/multimodal_inputs/<文件名>"`	文件放在官方指定目录 `/data/multimodal_inputs/`

磁盘预留（官方给的计算式）：单请求最大文件大小 × 最大并发数 × 1.5（预留系数） ——官方举例：单请求最大 512MB、并发 1000，则磁盘预留应大于 750G。

B.4 视频生成关键参数

参数	含义	官方默认 / 示例
`--task`	任务类型	文生视频 / 图生视频
`--size`	生成分辨率	有固定档位（如 1280×720、832×480）
`--frame_num`	生成帧数	默认 81
`--sample_steps`	采样步数	文生视频 50 / 图生视频 40
`--prompt`	文本提示词	用户自定义，控制画面
`--image`	输入图（图生视频）	用户提供
`--base_seed` / 种子	随机种子	需复现时固定

为什么视频生成要写成「脚本任务」而不是「一问一答」：它耗时长、吃算力、产出是文件—— 适合当后台任务跑，跑完再取文件；不适合像对话那样实时等返回。这是它「接在哪里」与 A/B/D 不同的根本原因。

B.5 卡在哪一类 —— 一张对照表

你看到的	属于	第一动作
接口连不上 / 端口不监听	服务层	5.6 看端口 → 回 D 层 / F6
接口返回空 / 乱码	模型 / 服务	回 D 层排查；空返回算失败
内容不对、明显编	任务超边界	回 4.1 四张「能 / 不能」表
结果时好时坏	输入质量	查素材（模糊 / 嘈杂 / 超限）
输出对但下游读不了	流程缺校验	加程序校验（4.3 链路三）
视频生成慢 / 失败	算力 / 参数	`npu-smi info` 看卡；核对分辨率 / 帧数 / 步数档位

这张表的价值：模型业务的问题，一半不是模型的问题——先分清是「模型不行」还是「流程没配好」，别一上来就怀疑模型。