你接到一个需求：图片、音频、视频里挑信息，再生成一段带图的回复。第一反应是找一家「多模态最强」的接口，结果接上去发现单个请求塞不下、链路里某一步延迟特别高、账单还说不清是哪一环烧的。这篇不讲谁家强，只给一套判断顺序：先分清你的任务属于哪一种多模态、再决定用原生多模态接口还是拆成节点编排、最后把成本和延迟拆到每一环去量。
你接到一个需求：从图片、音频、视频里挑出信息，再生成一段带图的回复。多数人的第一反应是找一家「多模态最强」的接口，接上去才发现单个请求塞不下、链路里某一步延迟特别高、月底账单说不清是哪一环烧的。这篇不讲谁家强，只给一套判断顺序：先分清任务属于哪一种多模态，再决定用原生多模态接口还是拆成节点编排，最后把成本和延迟拆到每一环去量。
Google 这一支的能力分布比较散，理解、生成、音视频处理经常不在同一个入口上，所以更需要先定口径再选接口。下面每一节都给出「怎么判断」和「什么情况下不适用」，数字部分一律不写死，需要时去站内对应页面核对当时的口径。
先分清你要的是哪一类多模态任务
把需求拆成四类：图生文（理解、标注、抽取）、文生图（生成、编辑）、图文交错（对话里带图）、音视频理解。这四类的接口形态和计费口径完全不同，别用同一套经验去套。判断依据看输入主模态和输出主模态，而不是看产品形态——一个「拍照搜同款」的 App 本质是图生文加检索，不是文生图，接口选错整条链路都会别扭。
| 任务类型 | 输入主模态 | 输出主模态 | 常见误判 |
|---|---|---|---|
| 图生文 | 图片 | 文本 | 以为是生成任务，其实只要结构化字段 |
| 文生图 | 文本 | 图片 | 把编辑类需求当纯生成做，忽略原图约束 |
| 图文交错 | 图文混排 | 图文混排 | 按单轮问答设计，忽略多轮里图片的指代 |
| 音视频理解 | 音频/视频 | 文本或摘要 | 当成图片链路处理，忽略时长和分段 |
什么情况下不适用这套分法：如果任务里图片只是偶尔出现的附件、主体还是长文本问答，那优先按纯文本链路做，多模态当兜底，别为偶尔一张图重构整条链路。选型前先到 /multimodal 看当前有哪些多模态模型在列，再到 /official-api/providers/google 核对 Google 这一支的规格与计费口径。
原生多模态接口还是拆成流水线
原生多模态是一次请求同时给图和文，模型自己对齐，适合理解类、图文交错对话、单轮任务，链路短、出错点少。流水线是先 OCR 或转写出文本，再喂文本模型，适合需要留中间产物、需要人工复核、或同一份素材要反复复用的场景。常见误判是「图多就一定用原生」：如果每张图只需抽取几个字段，转写加结构化输出往往更稳、更好排查，因为每一步的输入输出都能落盘。
- 原生适合：版式、颜色、空间关系决定语义，转写会丢关键信息，比如仪表盘、设计稿评审
- 流水线适合：抽取字段固定、需要复核、素材要复用，中间产物能存下来反复跑
- 混合做法：先原生做粗理解，再由文本模型做结构化输出，两头都留痕
- 切换信号：原生一次请求塞不下或经常超时，就该考虑拆节点；反之字段抽取总丢信息，就该回到原生
不适用条件很明确：素材里信息高度依赖版式和空间关系时，转写会丢关键信息，还是得走原生多模态。对照概念时可以看 /ai-dict/category/tech 对齐底层术语，避免把「上下文长度」和「单次能传几张图」混为一谈。
工作流编排：节点怎么切、状态往哪放
每个节点只干一件事，并且输入输出都能序列化。理解节点、抽取节点、生成节点、审核节点分开，出问题时能单独重跑而不必整条链重来。把「模型调用」和「业务状态」解耦：工作流引擎只关心节点入参出参，别把会话状态塞进模型的上下文里当唯一存储，那样一换模型状态就丢。
- 切节点按输入输出类型切，而不是按业务名词切；每个节点能单独用一个样例跑通，跑不通就说明切错了
- 定状态中间产物落盘或入库，工作流只传引用；验证方式是重启引擎后能从上一个成功节点续跑
- 设失败层单节点失败重试，整链失败从上一个成功节点续跑；两层不分开，一次限流就会让整批素材重跑
- 选编排位置先想清楚是在框架里编排还是在自己代码里写死顺序；只有一个模型调用、没有分支和人工环节时，直接调用更好维护
编排框架可以先看 /stacks/frameworks 里列的目录，智能体类工具看 /ai-nav/category/ai-agent。不要一上来就上重框架，先用最简单的顺序调用跑通一条样例，再决定要不要引入编排。
成本与延迟要拆到每一环
多模态请求的贵，往往不在模型单价，而在同一份素材被重复传了几次。先把素材做成可复用的中间产物（转写文本、缩略图、向量），再谈省钱。延迟同理：给每一步单独打点，记录排队、上传、推理、回传四段耗时；只记总耗时会让你误以为是模型慢，其实是素材上传慢。
| 要量的环节 | 怎么量 | 常见结论 |
|---|---|---|
| 上传 | 记录素材大小与上传耗时 | 大文件上传经常是总延迟主因 |
| 排队 | 看限流与并发档位 | 并发打满时排队会盖过推理时间 |
| 推理 | 单节点单独计时 | 拆节点后反而更容易定位 |
| 回传 | 记录响应体大小 | 大图回传也是成本 |
给流水线做档位：能同步返回的走同步，批量离线任务走批量接口，别用一套参数跑所有场景。不适用条件：如果单次请求成本已经可以忽略、且用户能接受秒级等待，就不必为省钱把链路拆得七零八落，维护成本会更贵。
上线前的核对清单
上线前把接口层、数据层、稳定性、预算层过一遍。这四项里只要有一项没确认，多模态链路在生产流量下就很容易出你预料不到的行为，尤其是静默截断和脱敏这类不报错的问题。
- 接口层：确认素材的格式、大小、张数上限，以及超限时返回的是报错还是静默截断
- 数据层：确认传出去的图片和音视频是否脱敏、中间产物存在哪里、保留多久
- 稳定性：给链路加一个「降级到纯文本」的兜底分支，多模态这一环挂了也不至于整个功能不可用
- 预算层：按最坏情况估一次全量跑批的花费，再去 /tools/model-cost-calculator 按当时的单价折算
这四项里，最容易被跳过的是静默截断和兜底分支。验证方式很简单：故意传一张超限的图和一段超时的音频，看系统是报错还是悄悄少处理一部分；再手动断开多模态这一环，看功能是否还能以纯文本方式跑通。
下一步把上面四类任务、原生与流水线的取舍、成本和延迟拆解都对照一遍，再去站内把当时的数字核准确，避免拿旧口径做新决策。→常见问题
多模态工作流是不是一定要用原生多模态模型？
不一定。判断标准是你的任务依赖不依赖版式、颜色、空间关系这类非文本信息。依赖就走原生，不依赖就转写成文本再处理，链路更短也更好排查。很多团队误以为图多就必须原生，其实逐张抽取字段的场景，转写加结构化输出更稳。
一条多模态链路里，最容易被忽略的成本在哪？
通常在素材的重复传输和重复推理上，而不是模型单价。同一张图如果被多个节点各传一次、或者失败重试时整批重跑，账单会涨得很快。做法是把素材先做成可复用的中间产物，再让后续节点消费它。具体单价到站内官方 API 页面看当时的数字。
链路跑不稳，先查哪一步？
先看素材这一层：格式是否被接受、大小和张数是否超限、超限时是报错还是静默截断。很多「模型不听话」其实是传进去的内容已经被截掉了一部分。确认素材没问题，再去看是不是上传或排队阶段拖慢了整体耗时。
