模型再强，为什么Demo还是进不了生产？

“业务要的不是偶尔做对一次，而是成千上万次稳定运行。”

9 月 12 日，在 Lance 开发者沙龙上海站现场，火山引擎数智平台算法工程师曾骞以 LAS 多模态算子体系为例，结合具身智能、电商素材和视频投流三个规模化场景，分享了如何把已经足够强的模型能力真正搬进企业的生产系统。

他提出的问题很直接：当模型已经能理解和生成文本、图片、音频、视频，为什么不少能力仍停留在演示阶段？

“可用”其实有三个台阶

曾骞把“可用”拆成了三层：能力可用，是一次调用成功；生产可用，是链路能稳定交付；规模可用，是同一套能力可以跨业务复用，底层模型升级时，上层系统不必整体重写。

这三层之间的落差，就是生产化的“最后一公里”——把不确定的模型输出，变成可交付、可复用的业务产出。

真实系统里的麻烦往往很琐碎：输入格式可能不统一，长视频可能超出上下文窗口，生成结果会波动，任务失败后还要能定位、重试和控制成本。这些问题单独看都不大，却共同决定了模型能否进入生产。

卡住落地的三道鸿沟

仅靠大模型或 Agent 自身，很难稳定、低成本地完成数据的解析、清洗与应用。曾骞把规模化生产的关键瓶颈归纳为三道鸿沟。

• 模型能力鸿沟：大模型存在输入规格限制、长视频理解效果差、视频生成抽卡成功率低等瓶颈。一整段长视频无法被整段理解或生成，需要抽帧、分镜、音轨分离和语义压缩；一份复杂 PDF 要恢复标题、表格、公式、页码与图文关系，也不是调一次大模型就能解决。
• 工程链路鸿沟：真实的数据处理往往同时涉及 CPU 预处理、GPU 推理、规则校验、存储与任务管理。如果每来一个新场景都要重新写一遍连接上下游的代码，上线周期和维护成本就很难降下来。
• 效果确定性鸿沟：视频生成存在随机性，有时一条可用素材需要反复尝试。只返回一次生成结果无法满足批量交付，还必须把输入校验、自动评估、定向修复、重试和人工确认纳入处理过程。

LAS 的思路，是把这些差异和限制封装进算子：输入前做校验和预处理，执行中记录参数与状态，输出后自动评估；发现局部问题时定向修复，而不是整条任务从头再跑。

150 多个算子，四层全景

目前 LAS 已沉淀 150 多个算子，覆盖视频、音频、文本、文档、图像五类模态，支撑具身智能、智能驾驶、电商营销、广告制作等多个场景。曾骞把算子服务全景拆成四层。

最上层是门店质检、金融研报解析、具身智能预训练、高光剪辑、电商素材、广告生成和出海等应用场景。服务层提供三种入口：用于批量处理的 API、供 Agent 调用的 CLI/Skills，以及实时交互的 Studio WebUI，三种形态共享同一套能力。

再向下是算子矩阵。视频类覆盖理解、剪辑、生成、修复和切分；音频类包含转写、切分、语种识别和降噪，其中 ASR 支持 99 种语种；文本与文档链路可进行 176 种语种识别，并支持结构化解析与语义切分；图像类负责生成、裁剪和质量评分。底层则是数据集管理、计算队列、监控告警、安全和计费。

四层解耦后，上游业务不必感知模型差异，下游系统可以稳定消费结果。

算子数量不是目标，契约才是

曾骞强调，一个被多个业务反复调用的算子，比一批躺在文档里、没有人使用的算子更有价值。真正决定复用率的，是稳定的契约和实际的处理效果。

所谓契约，就是业务系统可以依赖的一套明确约定：输入什么、输出什么、怎么调用、失败如何处理，以及结果怎样才算合格。他称之为生产级算子的“三个统一”。

统一输入输出：每个算子都要明确输入介质、文件限制、参数、输出结构、状态和错误含义。比如视频分镜算子输出镜头、人物、场景、道具与时间线；训练数据处理算子输出可追溯的数据集版本和质量结果。

统一调用协议：短任务采用同步调用，长视频、批量文档和生成任务采用异步协议。任务需要有可追踪的 ID、明确的状态、幂等语义和失败原因，支持重试及历史版本保留，同时兼顾在线低延迟交互与离线批量处理。

统一质量规范：接入 API、让任务跑起来还不够。如果结果不能用，前面的投入就没有转化成交付。输入端要校验格式、尺寸、时长与内容可用性，处理过程中要记录模型、参数、版本和中间结果，输出端再由规则、模型评估或人工审核判断是否合格。

因此，算子不只是模型接口的包装，而是一份稳定契约，把模型能力、前后处理、资源调度和质量要求组合成可复用的生产单元。

把业务策略写进链路

有了完善的算子体系，还要让它们在业务系统里真正运行起来。工作流编排的作用，是把业务目标、质量标准和异常处理策略写进处理链路。

评估结果决定下一步：达到标准就直接返回；未达标但可以修复，就定位问题片段、调整参数并局部重试；品牌、安全、合规等场景无法自动判断时，则进入人工确认。人审结论会继续反哺评估标准，逐步减少重复审核。

这种编排也在优化算力。格式转换、切分、抽帧和文本清洗由 CPU 承担，生成、理解和增强交给 GPU。系统按节点分配资源、控制并发、拆分批次，让昂贵算力集中在真正需要推理的环节。按分享中的不同统计口径，LAS 以 AI Native 分布式计算引擎支撑批量并发，单算子支持千级别高并发处理。并发数字之外，更重要的是失败可定位、任务可恢复、成本可约束。

具身智能：Ego 视频进 Lance，VLA 模型直读训练

训练数据处理是典型的高吞吐、长周期、多模态混合任务。数据量大、环节多，失败和返工的代价也高，因此它很能检验算子体系是否真正“生产可用”。

原始数据变成训练资产，离不开四层底座共同发力：应用层面向预训练语料、多模态理解、视频生成、语音与音频、图文文档等训练场景；标准算子层提供文本清洗去重、视频理解与生成、语音处理、文档解析、语义切分、质量评估、检测估计、语种识别、图像处理等算子；计算编排层负责批量任务提交、CPU 与 GPU 分级调度、并发与批次拆分、失败重试与恢复、数据集版本管理、血缘与运行记录；最底层的数据资产层由 Lance 承载，做到图文与向量同表、增量标签列与版本回溯、零拷贝随机读与训练直读。

在具身智能场景中，算子先把第一视角或多相机 Ego 视频加工为 Caption、事件状态、动作时序、目标轨迹等结构化标注；Lance 再把视频、标注和向量放进同一张表，通过增量列、版本回溯和训练直读，把标注结果变成可持续迭代的训练资产。标注结果还会经过一致性和置信度评分，低置信度与疑难样本进入人工复核，形成“预标注→复核→二检→回流”的人机协同闭环。

在该场景实践口径下，核心标注任务准确率达到 90%以上，标注与交付周期由月级缩短到周级。

电商素材与视频投流：复用结构，而不是像素

电商爆款素材复刻的思路，是复用结构而不是像素。视频投流场景同样如此——批量生成、批量评估、批量修复，靠的不是单次生成运气好，而是把评估和重试写进链路。

回到最初的问题：模型再强，为什么 Demo 还是进不了生产？曾骞给出的答案不在模型本身，而在模型之外的生产化工程——把不确定的模型输出，变成可以交付、可以复用的业务产出。