原生多模态 vs Pipeline：生产架构选型框架

直接结论

多模态架构选型应由可观察的工作负载契约决定，而不是由供应商是否把模型称为“原生”决定。统一视觉语言模型 API 可以降低接入复杂度并增强跨模态推理；模块化 Pipeline 可以暴露证据，并让专用阶段独立扩缩容；混合方案能组合两者，但并不是不付代价的默认最优解。

正确方案是：在代表性流量上，同时满足质量、证据、延迟、隐私、恢复和成本要求的最简单候选。

先区分三种“架构”

很多对比把三个层级混在一起：

1. **产品接口：**一个 API 能接收文本、图像、音频或视频。
2. **模型架构：**一个模型制品内部的编码器、Projector、Transformer Backbone、Codec、Diffusion/Flow Head 与任务路径。
3. **应用架构：**模型周围的解析器、检索、业务规则、Cache、人工复核和外部副作用。

统一 API 不能证明模型没有编码器；端到端模型仍可能由异构组件组成；模块化应用可以只调用一个模型，而“一个模型”内部也可能执行计算图。

M* Serving 论文把现代多模态系统建模为带输入相关 Walk 的计算图，其中包含编码器、Backbone、Codec 与非自回归循环。Qwen2-VL则公开了动态分辨率视觉路径与多模态位置编码。因此，架构标签只能作为有范围的描述，不能当作通用实现事实。

三种候选设计

统一模型应用

这种设计减少应用层交接，适合跨模态开放比较、视觉解释、模糊输入，以及需要快速学习任务边界的原型。

它的风险包括中间证据有限、故障域较大、媒体规则依赖供应商、Token 化波动、容量难预测，以及绑定单一模型契约。模型仍不能决定对象权限，不能证明引用区域支持某项论断，也不能让外部副作用恰好执行一次。

模块化应用 Pipeline

这种设计拆分具有不同数据、硬件、质量指标或所有权的阶段。数字原生 PDF 可交给确定性解析器，语音识别器负责时间戳，计算机视觉版面模型保留页面几何信息，再由 LLM 做语义抽取。

它的风险包括契约漂移、有损交接、坐标错误、重复队列和级联故障。“模块化”也不等于确定性：OCR、ASR、检测、排序和生成都可能是概率性的。

路由式或混合系统

当工作负载存在可分离切片时，混合架构才有价值。“简单任务交给便宜模型、困难任务交给聪明模型”不是完整设计。路由器必须测量“困难样本被误判为简单”的风险，两条路径也必须输出同一个证据与生命周期契约。

决策维度

这些只是待验证假设。Pipeline 可能因跨阶段排队而有更高尾延迟；统一模型也可能因为省掉多项服务而更便宜；专用解析器可能在一个文档家族上超过大 VLM，又在另一个家族上严重失败。

定义架构无关契约

让各候选在应用边界可替换。

请求
  subject、tenant、purpose
  source digest 与媒体描述
  任务类型与目标输出 Schema
  延迟、成本、保留与复核政策

结果
  规范化输出
  来源版本与证据引用
  组件/模型版本
  校验发现
  状态：accepted | review | rejected | outcome_unknown
  usage、latency 与 attempt identity

不要把供应商内部名称暴露成业务字段。客户工作流不应依赖某个后端把单位称为 Image Token、Media Part、Crop 还是 Frame。

比较正确的质量层级

OmniDocBench说明一个页面级总分为什么不够：文本、版面、表格、公式、阅读顺序、文档类型和属性会暴露不同弱点。这个原则也适用于文档之外的多模态任务。

每个候选都应报告：

• **感知：**转写、检测、定位和时间对齐；
• **推理：**受证据支持的论断、跨模态一致性和拒答；
• **结构：**Schema 有效性、字段语义正确性和顺序；
• **证据：**来源覆盖、引用精度和坐标偏差；
• **运维：**p50/p95/p99 延迟、吞吐、排队、重试和 OOM；
• **风险：**越权访问、注入成功、高影响操作和删除；
• **经济性：**包含复核与失败尝试的单个合格结果成本。

不能拿端到端模型的整页分数，与一个 OCR 组件的字符准确率直接比较。必须统一到相同业务任务与来源分布。

Serving 与容量属于架构决策

多模态推理可能包含异构计算、按请求变化的路径、大媒体传输和非文本生成。M* 的价值在于把组件放置、调度、Batching、传输、循环与 Streaming 都作为一等 Serving 问题。

每种架构都要压测：

• 媒体上传与解码时间；
• 每个阶段的服务时间与排队时间；
• 输入相关路径的出现比例；
• 目标分辨率、上下文、Batch 和并发下的内存；
• 背压与取消传播；
• Warm/Cold 行为；
• 部分故障与重试放大；
• 供应商或加速器不可用时的容量。

本地模型也不自动等于隐私或低成本。模型下载、Telemetry、日志、浏览器扩展、许可证、能耗、闲置加速器与运维人力都属于边界和总成本。

故障与恢复设计

统一模型故障

• 媒体或上下文被供应商拒绝；
• 结果缺少可检查的中间产物；
• 模型快照升级后输出契约变化；
• 供应商故障或政策变化影响整条路径；
• 模糊超时后的重试重复下游副作用。

应使用模型 Adapter、不可变请求记录、有界输出、独立校验、经过测试的 Fallback 与幂等副作用执行。

模块化 Pipeline 故障

• 阶段 Schema 或坐标漂移；
• Crop 丢掉决定性上下文；
• 一个陈旧阶段版本污染新任务；
• 队列放大尾延迟；
• 重试混合不同来源或模型版本的产物。

应使用内容寻址产物、版本化 Schema、血缘检查、阶段 Deadline、兼容重放与规范化结果模型。

混合系统故障

• 路由器把困难样例送到弱路径；
• Fallback 与主路径共享同一个根因；
• 只有一条路径正确实现删除或鉴权；
• 聚合指标掩盖路由伤害。

指标必须按路径和切片报告。路由决策先做 Shadow，再影响用户，并始终保留简单基线用于回滚。

可运行的 Go 决策门禁

下面的程序用产品政策评估模拟结果。它不会预设“原生、Pipeline 或混合”谁更好。候选必须通过全部硬门禁，之后才按单个合格结果成本选优。

package main

import (
	"fmt"
	"sort"
)

type Result struct {
	Name             string
	TaskSuccess      float64
	EvidenceCoverage float64
	HarmfulErrorRate float64
	P95LatencyMS     int
	CostPerAccepted  float64
	DeletionConforms bool
	ReplayConforms   bool
}

func eligible(result Result) bool {
	return result.TaskSuccess >= 0.90 &&
		result.EvidenceCoverage >= 0.92 &&
		result.HarmfulErrorRate <= 0.01 &&
		result.P95LatencyMS <= 1800 &&
		result.DeletionConforms &&
		result.ReplayConforms
}

func main() {
	results := []Result{
		{Name: "unified", TaskSuccess: 0.92, EvidenceCoverage: 0.86, HarmfulErrorRate: 0.009, P95LatencyMS: 1100, CostPerAccepted: 0.021, DeletionConforms: true, ReplayConforms: true},
		{Name: "modular", TaskSuccess: 0.91, EvidenceCoverage: 0.96, HarmfulErrorRate: 0.007, P95LatencyMS: 1450, CostPerAccepted: 0.016, DeletionConforms: true, ReplayConforms: true},
		{Name: "hybrid", TaskSuccess: 0.94, EvidenceCoverage: 0.95, HarmfulErrorRate: 0.006, P95LatencyMS: 2050, CostPerAccepted: 0.027, DeletionConforms: true, ReplayConforms: true},
	}

	passed := make([]Result, 0, len(results))
	for _, result := range results {
		if eligible(result) {
			passed = append(passed, result)
		}
	}
	if len(passed) == 0 {
		fmt.Println("no architecture passed")
		return
	}

	sort.Slice(passed, func(i, j int) bool {
		return passed[i].CostPerAccepted < passed[j].CostPerAccepted
	})
	fmt.Printf("selected=%s cost_per_accepted=%.3f\n",
		passed[0].Name,
		passed[0].CostPerAccepted,
	)
}

预期输出：

selected=modular cost_per_accepted=0.016

Fixture 展示的是方法，不是市场结论。换一个工作负载或政策，胜出的架构可能不同。

不推倒重来的迁移方法

1. 先把现有系统放到架构无关的请求与结果契约后面。
2. 收集有代表性且符合权限要求的 Fixture 与生产 Trace。
3. 新候选先以 Shadow 模式运行，不改变下游副作用。
4. 按切片比较输出、证据、故障、延迟和成本。
5. 只迁移候选真正通过的切片。
6. 在重放、删除和回滚被证明前，保持旧产物可读。
7. 只有组件的独特证据与恢复职责被替代后，才移除它。

常见问题

统一多模态 API 就是端到端模型吗？

不一定。API 边界可能隐藏编码器、语音 Codec、检索、工具、路由或多个模型。产品层应称为“统一 API”，只有公开证据充分时才描述内部架构。

Pipeline 更可审计吗？

Pipeline 可以暴露更多中间产物，但审计仍需要版本化血缘、访问控制、保留策略和可解释校验。一目录未标版本的 OCR 文件不是审计轨迹。

Pipeline 是确定性的吗？

只有部分阶段可能是。对固定输入与版本，PDF 解析和 Checksum 可以确定；OCR、ASR、检测、排序和 LLM 生成可能仍是概率性的。应逐阶段描述确定性。

什么时候应该放弃混合架构？

路由没有超过简单基线、两条路径无法共用同一证据与生命周期契约，或额外运维成本高于实测质量收益时，应放弃混合。

模型 Benchmark 怎样参与选型？

它们用于筛选候选和发现失败切片，不能替代对自身输入、Prompt、Schema、硬件、权限和业务损失的评测。引用任何结果时都要保留其测试条件。

一手资料

• M*：复合多模态模型的模块化 Serving 系统
• OmniDocBench：Pipeline 与端到端文档评测
• PaddleOCR-VL 完整 Pipeline 文档
• Qwen2-VL 架构与动态分辨率
• Visual Instruction Tuning（LLaVA）
• 多模态文档 Pipeline 工程