TLive-Omni：把直播间的声音和画面按时间对齐，商品问答才可信

直播间的货为什么这么难懂：证据散在两个维度，还要边答边真

主播举着焦糖色风衣，嘴里念「63% 聚酯纤维」，右上角贴片闪「到手价 299」，弹幕里有人问「这是纯棉吗」。要在这一秒答对，模型得把三处线索凑齐：材质在话里，价格在贴片上，衣服在画面里，而这三句话可能分别发生在开播后的第 12 分钟和第 19 分钟。一个上了长上下文的模型当然「看得见也听得见」，可它仍然可能答错，因为它不知道第 12 分钟的那句台词和第 12 分钟的那几帧画面，是同一时刻发生的事情。看得见，不等于答得对。

一句话概括这个场景的难处，就是跨时段证据同步（cross-time evidence synchronization）：事实散落在不同的时间点上，模型得先知道哪段台词和哪几帧画面属于同一时刻，才能把证据拼起来。这也是论文 TLive-Omni（arXiv:2608.20958）给自己立的问题。它来自阿里淘宝天猫团队，把难点拆得很具体：一个直播间的信息同时来自五条路，主播语音、视频帧、商品图、叠加在画面上的文字、还有观众提问。品牌、材质、颜色、型号、价格这些商品事实不集中在一处，散在这五条路里，而且经常出现在长直播流的不同时刻。模型要把跨时段、跨模态的证据拼起来，再在观众等着的时候给出回答 TLive-Omni。

跨时段证据同步的难处在于，它必须在两个约束下完成，缺一个都不算数。一是忠实（faithfulness）：从各时段汇拢来的证据必须是真凭实据，价格不能说成别的数，材质不能拿记忆里的百科凑数，带货场景里一次编造就可能是一次客诉。二是实时（timeliness）：观众的问题要秒答，对话窗口一错过，这单生意就没了。边答边真，边答边快，同步只有在这两个条件同时成立时才算完成。

更值得注意的是，离这个场景最近的两条赛道，都没有为「跨时段证据」做过设计。通用全模态模型（MiniCPM-o、Qwen3-Omni 这一代）追求的是任意模态输入输出，交互式和问答式能力都强，但没有一条数据通路是专门为「商品事实跨时段散落」组织的。通用电商模型 Valley3 用 6 任务的 EComm 基准覆盖产品理解、售后、搜索推荐、直播、短视频、治理，直播只是其中一项 Valley3。非商业直播基准 LiViBench 有 24 个任务、3168 个视频，但它研究的是唱歌、聊天、跳舞这类互动直播，数据筛选时还明确排除了电商 LiViBench。两条路各自说明，「直播」不是一个任务；而要把「产品中心」和「跨时段证据同步」并进同一个问题的直播电商，恰好是空位。

图注：TLive-Omni 面对的输入。主播语音、视频帧、商品图、叠加文字、用户提问五路信号同时涌进同一个模型，模型要输出关于商品的忠实回答。这张自绘图把「同时听、看、读、等提问」的并发感摆出来，后文每一个设计都在为这个场景服务。

五路信号怎么进同一扇门：统一表示空间，和两块现成的积木

要把五路信号送进同一个模型，第一步是把它们翻译成同一种语言。这就是统一表示空间（unified representation space）。文本、图像、视频、音频都被切成 token，token 是模型处理信息时的最小单位，每个 token 变成同一维度空间里的一个向量（embedding）。向量进了同一个空间，注意力才能跨模态工作，模型才能把「主播嘴里的材质」和「商品图上的成分表」放在一起推理。这一步 TLive-Omni 基本是站在巨人肩膀上拼出来的，两块积木都是现成的。

视觉语言这一块，骨干直接来自 Qwen3.5 家族，跟 Qwen3-VL 同源。它由三部分组成：SigLIP-2 视觉编码器把图像和视频帧变成视觉 token，两层的 MLP merger 把每 2×2 个视觉特征压成一个 token 并对齐到语言模型的隐藏维度，最后接 Qwen3 的 LLM 解码器。Qwen3-VL 还把视觉编码器中间层的特征通过 DeepStack 机制注入 LLM 前几层，并原生支持 256K token 的上下文窗口，这对动辄几十分钟的直播片段是刚需 Qwen3-VL。视觉这一路，论文没有改动。

音频这一块直接用 Qwen3-Omni 训练好的 AuT 编码器。AuT 从零在 2000 万小时监督音频上训练而成，大约 0.6B 参数，输入是 128 通道的 mel 频谱，输出是把语音压成每秒约 13 个 token 的流，每个 token 大约对应 80 毫秒的音频。它吞进一整句话，吐出来一小串 token，模型靠这串 token 就能知道主播说了什么。TLive-Omni 只取 AuT 的 encoder 部分，再接一个轻量的两层 audio aligner，把音频向量投到和视觉、文本一样的维度 Qwen3-Omni。注意两条通道的产出节奏完全不同：视觉按帧、音频按时长流式前进，这个节奏差就是下一章要补的洞。

图注：AuT 的内部数据流。左侧 128 通道 mel 频谱输入，经 Conv2D 8 倍下采样后进入 attention encoder，再连一个自回归 decoder。图上标注了 ASR 与音频理解两个训练目标，以及 12.5 Hz 的 token 率。TLive-Omni 只复用它的 encoder 部分。Qwen3-Omni

所以「五路信号进同一扇门」这件事本身不是这篇论文的创新点。两块积木只是被拼在一起，AuT 吐出的 token 流和文本 token 天然同构，都是按时间线性排列的离散表示，这让音频和语言模型的接口最简单，两层 aligner 就够用。它的新工作全部集中在门后面：token 序列是线性的，模型怎么知道哪段音频对应哪几帧画面？这就是下一章 Per-vGrid 要解决的问题。

对不上时间的音画等于没看见：Per-vGrid 把同一时刻绑成一组

token 序列是一维的，像一条拉直的磁带，画面 token 和音频 token 都铺在这条线上。如果只是按模态顺序排，模型看到的是一大堆视觉 token 挨着一大堆音频 token，它无从知道「第 12 分钟的这句话」该和「第 12 分钟的画面」放在一起理解。Qwen3-Omni 的做法是用 TM-RoPE 给每个音频 token 配一个绝对时间位置，每 80 毫秒一格，让位置编码自己提示对应关系 Qwen3-Omni。这套设计在短视频上够用，但直播流里有两个它管不住的因素：音频按固定节拍前进，视频却是按需抽帧，二者的步长天然对不齐。更麻烦的是，请求的采样率并不等于实际采到的帧率 TLive-Omni。

Per-vGrid 换了个思路：不靠模型去猜对应关系，干脆把对应关系写进 token 序列本身。它把视频按时间窗切成 grid（网格），每个 grid 里同时放这个时间窗的视频帧 token 和同一时间窗的音频 token，绑成一组。每组前面写一个明文的时间戳，组与组之间用显式的 boundary token 隔开。可以把它想成剪辑软件里的多轨时间线：每一格画面素材下面挂着同一时钟的波形，素材与素材之间是剪辑点，任何一帧画面都能靠时间码找到自己的声音。Per-vGrid 的 textual timestamp 就是时间码，boundary token 就是剪辑点，模型读序列时不用推断，直接看见「这段画面 + 这段声音 + 这个时刻」是一体的。

一个完整算例最能说明这组设计。假设源视频有 119 帧、30 FPS，约 3.97 秒，请求采样率是 2 FPS。按 2 FPS 算应该取大约 8 帧，但实际采样器取到的帧索引是 [0, 20, 39, 59, 79, 98, 118]，一共 7 帧，折合实际帧率 7/119×30，约等于 1.76 FPS。7 帧每 2 帧一组，最后一组只有 1 帧做 padding，得到 4 个 grid。每个满格覆盖 2/1.76，约 1.13 秒，而不是请求采样率暗示的 1.0 秒。音频按每秒约 13 个 token 折算，一个 grid 的音频跨度就从约 13 个 token 变成约 14 到 15 个 token。核心就在这里：音频跨度跟着实际采到的帧走，而不是跟着请求的采样率走。2 FPS 和 1.76 FPS 之间差出的 13%，正是对齐误差的来源 TLive-Omni。另外，时间戳以明文文本 token 的形式存在，还有一个位置编码给不了的特性：它是模型可以逐字读到的。位置编码只能改变注意力计算的远近，文本时间戳却可以参与语言模型自己的推理，让「这段画面 + 这段声音 + 这个时刻」的三元组真正进入模型的思考。

和 Qwen3-Omni 默认的插法比，Per-vGrid 加了四样东西：每组前置明文时间戳、组间边界显式化、组内音画 token 连续、相邻组在序列层面分开。这四个改动的目的只有一个，让模型在长直播里做到「指哪打哪」。观众问主播是几点说的材质，模型能从时间戳读出证据位置，时间定位（temporal grounding）这类任务才有地基。

图注：TLive-Omni 整体架构。左侧 AuT 音频编码器经小型 Audio Aligner 进入同一表示空间，右侧是 Qwen3.5 骨干，顶部视觉通路进入 LLM。右下角 inset 画的是 Per-vGrid：每个 grid 把少量视频帧 token 与同一时段的音频 token 绑在一组，配 boundary token 与时间戳。inset 是 7 帧 4 grid 的示意，正文算例则是 119 帧的完整推导。TLive-Omni

训练数据从哪来：造七类信号的工厂，再分三步把能力喂出来

架构把时间对齐的问题解决了，下一个问题更现实：拿什么学？直播电商没有现成的配对数据集。通用多模态管线（看图说话、视频问答）造出来的监督信号，解决不了「这件衣服是不是主播刚才说的那件」这类问题，因为答案要同时用上声音、画面、文字三条线索。论文的应对是把直播理解拆成七类原子能力，再建一个数据生产引擎，把直播的音频、图像、视频三类原始流分别加工成这七类的训练信号。

七类能力按模态分三条路。音频路负责直播间的 ASR（语音转文字）、说话人归属、音频描述与问答；图像路负责商品视觉定位和文字识别定位；视频路负责时间定位、稠密视频描述和视频问答。每条路都有自己的质检工序：音频路让多个 ASR 模型投票，再用 LLM 挖出「剪标」「尾货」这类直播间低频领域词补进词典，说话人归属则用纯音频的说话人分离模型和视觉线索互相校验，temporal IoU 对不上的回看口型复核。音频描述再拆成声音、音乐、说话内容、说话人节奏四类分别生成，最后由 LLM 合并成描述和问答对。图像路跑 Detector-Judger loop，检测器提候选框、judger 过滤，被拒的样本也不扔，留着当训练信号。贴片文字的处理则把解析出的内容重渲染回图片和原图对比，而不是直接信 VLM 说的。视频路先用 TransNet V2 做物理镜头切分，再让 VLM 按语义事件切分、直接生成问答对和时间定位标注，最后用 VLM 当裁判检查事实与时间戳是否一致。三路的产出汇聚成后续三个训练阶段的数据混合物 TLive-Omni。

图注：三阶段 SFT 数据构造框架示意图。左侧 Audio / Image / Video 三路各自走「来源 → 构造 → 过滤 → 输出」的独立管线，音频路含 ASR 集成与说话人 IoU 校验，图像路含 Detector-Judger loop，视频路含镜头切分与语义事件切分，右侧汇聚成 Stage 1/2/3 的数据混合物。图中的阈值与数量为示意。TLive-Omni

这里要澄清一点，免得把论文当成在发明任务。时间定位和稠密视频描述不是新造的东西，它们在视频时序定位（VTG）这条研究线里是定义得相当成熟的任务族：时刻检索、密集描述、高光检测、时序问答各有各的基准和指标。TLive-Omni 只是借用了任务族的定义，评测协议用的是自己的：时序定位用 TimeLens-Bench 和 mIoU，稠密描述用生成描述后让外部模型做选择题的协议。这些和任何标准基准都不直接可比 VTG survey。

图注：VTG-MLLM 综述给「视频时间定位」研究画的三维分类树，三个主干维度是模型功能角色、训练范式、特征处理方式，再往下各自细分，叶节点是综述覆盖的代表方法。TLive-Omni 不在图中，它只借用这一谱系的任务定义。VTG survey

数据有了，怎么喂？论文用三阶段监督微调（SFT）逐级解锁能力，每一级只放开一部分模块。Stage 1 用 500 万条 ASR 样本，冻结语言模型和音频编码器，只训两层 audio aligner，目标是把「音频到文本」这条最底层的通道打通。Stage 2 加 2600 万条音频混合数据，包括转写、音频描述和音频问答，放开音频编码器和 aligner，语言模型仍冻结，把能力从转写扩展到声音事件、音乐、说话人线索。Stage 3 用 1400 万条全模态数据，反向冻结两个编码器，放开 aligners 和语言模型，在七类原子能力上联合训练。顺序是有讲究的：先打通最底层的音频映射，再扩展单模态能力，最后才全模态联合，每一步出了问题都能定位到具体阶段。直播理解的能力不是模型大就有，而是先把可靠的监督信号按任务造出来，再按依赖关系逐级解锁，能力是这么长出来的。

答得快、答得真、不瞎编：Faithful-RFT 在 GRPO 上做的取舍

三阶段 SFT 让模型会答了，但「会答」和「答得真」之间还隔着一道坎。SFT 学的是模仿训练数据里的答案分布，数据里没出现过的商品属性，模型可能一本正经地编一个出来。直播场景里编错一次材质就是一次客诉，所以论文在 SFT 之后又加了一个强化微调阶段，叫 Faithful-RFT，目标就两个：答得忠实，答得快。

Faithful-RFT 的底座是 GRPO（Group Relative Policy Optimization），先把它讲明白。传统强化学习要有一个额外的打分模型（critic）来评估动作好坏，这个打分模型和主模型差不多大，训练开销显著增加。GRPO 不要打分模型：给同一个问题，让模型自己出 8 个候选答案，然后拿每个答案的得分跟同组 8 个的平均水平比，高于平均的往上推，低于平均的往下压。组内平均就是基准，所以叫组内相对优势。去掉 critic 不只是省显存。GRPO 去掉的是学习价值基线的 critic，奖励来源仍由具体任务设计决定。归一化公式只有一条：$\hat{A}_i = (r_i - \overline{r}) / \sigma_r$，得分减组均值再除组标准差，大于 0 就多学一点，小于 0 就少学一点 GRPO。

Faithful-RFT 在这个底座上做了一个刻意的取舍：奖励按评估机制分三类——规则型分数、LLM 裁判和格式奖励，而且只对最终回答打分，每一分都必须任务可验证。规则型分数能核对就核对，选择题答案对不对、定位框准不准、OCR 对不对都是硬账。开放生成型的回答找更强的模型当裁判。格式奖励这一类专门压掉思考标签，明确不奖励推理长度。每条奖励函数声明自己适用的任务集，不适用的返回无效标记直接剔除，剩下有效的按配置权重重新归一化求和，作为这条候选答案的总分 TLive-Omni。图像、带音频视频、不带音频视频、纯音频四路数据混在同一个 GRPO 阶段里训，每条样本带一个任务标签，按标签路由到对应的奖励。这一条把 Faithful-RFT 和推理式 RL 划开了界限。DeepSeek-R1 用同一个 GRPO 证明了它能跑到前沿规模，奖励信号是规则可验证的最终答案正确性，R1-Zero 甚至跳过 SFT 冷启动直接从基座模型强化，目标都是让长链推理自己涌现 DeepSeek-R1。直播场景恰好相反：观众等不起一串思考标签，模型需要的是立刻说出钉在证据上的答案，所以 Faithful-RFT 从 Stage-3 模型出发，不另做冷启动 SFT，也不给任何思考过程加分。它跟传统拒绝采样微调（RFT）也是两种物种。RFT 是采样一批候选、留下对的、再当训练数据做一次 SFT，本质还是模仿学习 RFT。Faithful-RFT 用的是策略梯度，按组内相对优势给每个候选分配不同的学习强度，这是强化学习，不是过滤完再重训一遍。

最后是让这套混合模态训练真正跑起来的工程。多模态数据长短悬殊，随机采样会把显存浪费在 padding 上，也会让各 worker 负载不均。同步长度分组采样器分两阶段解决：Phase I 只跑一次，按模态分桶、桶内按 token 长度排序、切成固定大小的全局 batch，切不完的余数直接丢掉。Phase II 每个 epoch 让所有 worker 共享同一个随机种子，按剩余 batch 数比例选模态，所有 worker 弹出同一个全局 batch，每人取自己那一段。序列 packing 是显式关闭的，全局 batch 大小保持不变。

图注：同步长度分组采样器的两阶段流程。Phase I 只跑一次，负责构建按模态、按长度的 batch 注册表。Phase II 每个 epoch 让所有 worker 按同一随机种子同步调度，保证弹出同一个全局 batch。图据论文 Algorithm 1 重绘。TLive-Omni

这个方案能成立还有一个基础设施前提：rollout 用的 vLLM 引擎把 KV 缓存切成不连续的分页 block，按需分配显存，长度对齐带来的小块 padding 在显存上几乎不浪费。vLLM 论文报告同延迟下相对 FasterTransformer 和 Orca 有 2 到 4 倍吞吐，那是它自己的测量，不是 TLive-Omni 的 vLLM。另一处工程是动态重采样：如果组内 8 个答案得分几乎一样，相对优势就趋近于零，梯度没有意义，训练器会检测组内方差，把近零方差的组用调整后的生成参数或改写后的 prompt 重新生成，同时用一个饥饿计数器防止某些模态长期不被选到 TLive-Omni。忠实与实时这两个直播硬约束，到这里被翻译成了一条明确的规则：不奖励思考过程，只奖励最终答案是否可验证。

数字说话：真提升在哪、哪没赢、论文没回答什么

效果如何？论文报了两大块：一是自建的直播电商评测套件，从语音识别到商品检测到时序定位到视频问答。二是通用公开基准。下面的数字全部照抄论文表格原文，要注意这是论文自己的评测协议，和外面任何 benchmark 都不直接可比。

数字自己会说话，但要读懂它们，得看两栏。左半边是直播域，全部 open-source best，而且不是侥幸：CER 6.46 把 Qwen3-Omni 30B 的 6.75 和 Qwen2.5-Omni 7B 的 7.86 都压了下去，时序定位 mIoU 81.49 把闭源的 Gemini 3 Pro（77.90）也甩在身后，视频问答准确率到了 93.23。这说明围绕「产品中心 + 时间对齐 + 忠实」组织起来的问题定义、数据配方和训练路径，确实把直播这件事做对了。右半边是通用域，多数是渐进提升或第二，少数拿到 best，而 MVBench 和 LVBench 上 open-source best 是别家，AVUT 上闭源模型也更高。值得注意的是，时序定位的三个 TimeLens 子集是最贴近直播任务的通用基准，上面反而是 4B 全部拿下 open-source best（Charades-TL 57.0、ActivityNet-TL 58.2、QVHighlights-TL 69.2）。所以正确的读法是：直播域是真提升，通用域是不掉队。这不是一篇全域碾压式的 SOTA 论文。

论文没回答的事，和它回答了的事一样重要。第一，TLive-Omni 是 understanding-only，它听懂并写出回答，但不生成语音，也没有全双工的实时交互，别期待它能开口跟主播对话。第二，全文没有任何消融实验，Per-vGrid、三阶段 SFT、Faithful-RFT、同步采样、动态重采样，每个设计的贡献都没有被单独隔离验证，论文也没有报告 RFT 和 Faithful-RFT 的定量对比，分阶段的算力消耗同样没有给出，所以任何「这个提升来自那个模块」的归因都只能算推测。第三，端到端推理时延没有被量化，256K 上下文、vLLM rollout、动态重采样都是工程承诺，但论文没有给出 TPS、TTFT、每千 token 成本这类数字，也没有讨论平台侧的编码与解码约束。第四，数据生产引擎大量依赖 VLM 当裁判，人工审核的占比没有披露 TLive-Omni。论文自己在结尾也承认，更长、更嘈杂、更多样的直播流，以及在信息不完整、模态互相矛盾时如何校准时间证据，都还是下一步的事。

放到同行坐标系里看，Valley3 走的是通用电商路线，和 TLive-Omni 的直播电商是两个落点，两家各自证明「通用模型撑不起电商」这一判断独立成立，而 TLive-Omni 把「原子能力 + 数据管线」这条路挖得更深 Valley3。合上论文时值得记住的是：它用一整套工程把「看得见」推进到了「答得对」，但每个螺丝钉为什么转，都还是开放问题。对想复现的人来说，配方写得很全。对想验证某个设计的人来说，桌子还没摆好。

想深入可以读原文：TLive-Omni: An Omni-Modal Understanding Model for E-Commerce Live Streaming — arXiv:2608.20958

参考文献

• TLive-Omni（绝对主线，问题定义、架构、数据、训练、评测与局限的唯一主源）：arXiv:2608.20958
• Qwen3-Omni（AuT 音频编码器与 TM-RoPE 对照基线）：arXiv:2509.17765
• Qwen3-VL（视觉语言骨干、DeepStack、256K 上下文）：arXiv:2511.21631
• DeepSeekMath（GRPO 原始论文，组内相对优势公式）：arXiv:2402.03300
• DeepSeek-R1（GRPO 前沿规模验证与选边对照）：arXiv:2501.12948
• RFT（拒绝采样微调谱系）：arXiv:2308.01825
• Valley3（通用电商垂直同行）：arXiv:2605.01278
• LiViBench（非商业互动直播基准）：arXiv:2601.15016
• vLLM / PagedAttention（rollout 引擎基础设施）：arXiv:2309.06180
• VTG-MLLM Survey（视频时间定位任务族学术锚）：arXiv:2508.10922