ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

从AI视频到AI世界:实时交互模型的关键工程与实践

从AI视频到AI世界:实时交互模型的关键工程与实践 过去两年AI 视频生成几乎成为内容行业最快的变量。用一句提示词生成十几秒、甚至几十秒的高质量视频已经不算新鲜事短视频、广告、动漫、影视预览里到处能看到这类工具的影子。但如果你把需求从“生成一段视频”换成“生成一个可以走进去、能实时操作、回头再看同一场景还保持一致的交互世界”技术栈和成本结构会发生根本变化。这正是 Decart AI 最近让我重新关注它的原因。它的交互世界模型 Oasis把“AI 视频”一路推到了“AI 世界”玩家用鼠标键盘给出动作模型按帧实时生成画面没有传统游戏引擎没有预置关卡整个世界由模型权重实时演算。看起来它像一个游戏 demo但硅谷资本对它的关注显然不只是因为 demo 效果酷炫。这篇文章我想拆开讲三件事第一为什么“AI 世界”和“AI 视频”是两种完全不同的系统而不是更长视频的延伸第二Decart AI 这类公司真正被资本看中的工程能力是什么第三如果你想从 AI 视频转向 AI 世界相关的项目有哪些门槛、评估方法和落地路径。1. 这次不是从短到长而是从单向输出变成实时闭环1.1 传统 AI 视频的边界生成结束交互就结束了现阶段我们熟悉的 AI 视频生成多数是单向生成链路。用户输入提示词多模态模型把它转换成一个 token 序列或 latent 序列再通过扩散模型或自回归模型解码成画面。输出是一段固定的、有起止的视频。哪怕你调用可控生成接口在生成前把人物、镜头、配色、运动轨迹全部锁好视频一旦输出用户也无法再改变里面任何一个物体的走向。这决定了传统 AI 视频本质上是一个“离线的渲染器”。它擅长解决的是内容创作的速度问题原来要花两天搭场景、做动效现在用提示词几十分钟就能完成。但它不擅长解决用户和内容之间的实时互动问题。你没法让观众点一下屏幕就让主角改变路线再让整个世界的物理规则跟着改变。过去有不少团队尝试在视频生成中加入控制条件比如用姿态序列控制角色动作、用深度图控制镜头构图、用运动轨迹控制物体运动。这些方法提升了可控性但仍然是一次性的参数调节。用户不是生成过程的参与者而是生成结果的观看者。换句话说从“生成式创作”到“实时交互”中间差的并不是视频长度而是是否存在一个循环回路。1.2 从 AI 视频到 AI 世界本质是“环路”变化Decart AI 的 Oasis 给我的第一印象是“画面有点粗糙”但很快会发现这个项目的真正价值不在画质。它的核心机制是把视频生成从单次任务改成了长期闭环用户移动鼠标或按下键盘模型根据当前画面、历史上下文和最新动作指令实时推理出下一帧。玩家不是在观看一段视频而是在与一台“会玩游戏的神经网络”连续对话。这里的难点是交互世界模型必须像游戏引擎一样以每秒几十帧的速度对外部输入做出响应。但它的世界里没有物理引擎没有碰撞体没有预加载地图地面、墙壁、光影、物体的移动全部由神经网络从训练数据中学到的隐式规则决定。这让它和传统游戏引擎的架构完全不同后者按照代码规则精确计算下一状态前者则是在高维向量空间中预测最可能的下一帧。如果你接触过文本对话模型会发现这个世界模型的结构和你熟悉的聊天机器人有相似之处都是输入到输出的循环。聊天模型接收用户文本生成一段回答再把这段回答和新的用户消息一起作为上下文继续生成下一轮回答。AI 世界模型也是同样的逻辑只不过它的“文本 token”变成了“画面帧”它的“答案”不是一段文案而是用户能看到、能操作、能持续演化的环境。这个差异带来一个关键变化传统 AI 视频解决的是“让机器生成一个好看的画面”而 AI 世界解决的是“让机器在有限算力下持续判断一个世界应该是什么样子”。前者是内容生成后者是环境模拟。这也是为什么业界越来越多地把这类模型称为“世界模型”而不是升级版视频模型。1.3 为什么“世界模型”比“视频模型”更接近下一代应用平台单看内容生产视频模型已经是很好的工具但如果看“用户停留时长”和“交互深度”世界模型的机会更大。视频模型完成后交付物是文件用户只能观看不能改变内容。世界模型则更像一个平台用户不断输入操作模型不断输出画面双方来回交互形成长时间的会话。每一次用户操作都产生新的数据模型可以在后续迭代里利用这些数据优化世界规则。这种数据飞轮是纯视频生成没有的。资本很早就看懂了这一点。押注视频模型本质上是押注内容生产效率而押注世界模型是在押注新一代用户界面。当用户不只是想看一段 AI 生成的画面而是想在其中移动、探索、做选择时产品就变成了游戏、教育、社交或仿真环境的入口。这种入口的想象空间比提升一段视频的分辨率和帧率要大得多。2. 资本押注的不是 demo而是把推理成本做下去的工程能力2.1 视频和世界模型的真正瓶颈在推理效率很多人在评测 AI 视频模型时会优先看画质、文案一致性、动作流畅度在做 AI 视频产品时则会关注生成一个视频要多少钱、要等多长时间。把这两件事放到一起你能看到一个很容易被忽略的事实视频生成模型的成本主要不是训练阶段而是推理阶段。文本模型生成一个回答通常只需要几十到几百个 token计算量相对可控。视频模型生成一帧画面计算量就高出几个数量级如果要生成一个可以实时玩的交互世界相当于要在推理链路里持续以 20fps 甚至更高频率输出画面。用户每移动一次鼠标模型就要完成一次前向传播用户连续玩十分钟模型的推理次数可能已经超过了传统视频项目生成上百条短片的总次数。我习惯用一组很粗略的数字帮助理解假设模型以 20fps 运行用户玩 1 分钟就是 1200 次前向传播玩 10 分钟就是 12000 次。每一次前向传播都涉及对当前画面、动作指令和历史上下文的处理计算量远超文本对话中的一步。对普通团队来说这种量级的推理成本几乎无法用单块显卡扛住更别说同时服务多名用户。这种推理压力会直接转化为硬件成本、延迟和产品定价。如果单用户一小时的使用成本高到无法承受再优秀的 demo 也无法产品化。这也是为什么我判断世界模型的竞争重点将从“谁的画质更接近电影”转向“谁能在同等画质下把单帧推理成本和延迟压得更低”。2.2 Decart AI 的差异化推理引擎与异构计算从公开信息看Decart AI 并不是一家单纯刷榜单的模型公司它更强调把推理基础设施做深。Oasis 在技术展示中为了做到可玩级别的流畅度引入了较多的推理系统设计通过把模型的不同层分配到不同特性的算力设备上让视觉编码、注意力机制、MLP 等不同计算单元并行拆分再由推理引擎统一调度尽可能压低整体延迟。这类方案的效果取决于具体场景。不同层在计算密度、内存访问模式和延迟需求上有显著区别统一放在同一张卡上会相互挤占拆开放置则能发挥不同硬件的长处。你可以把它理解为一家餐厅的分工如果所有菜都让一个人从头做到尾复杂度高而且速度慢如果把切配、炒制、装盘拆给不同岗位整体吞吐量会明显上升但调度和交接机制必须精确不然很容易出现等菜、错配、积压。这种做法的意义不只是在 Oasis 这一个项目上跑得更快。如果它沉淀成一套通用的推理优化能力未来任何多模态大模型、视频生成模型、交互世界模型都可能用类似的思路降低单位生成成本。资本愿意押注的往往是这种“能影响一整类应用”的基础设施级别能力。2.3 为什么效率型公司更容易获得长期资本关注回看近几轮生成式 AI 的投资会发现一个规律单点模型类项目的估值容易波动因为模型能力迭代太快几个月就可能被新一代模型超越但效率型项目尤其是把大模型落地成可负担、可大规模服务的推理基础设施项目通常有更长的价值周期。原因是模型能力会快速迭代而“单位成本下的延迟和吞吐”是所有上层应用都绕不开的底座。这个逻辑有点像淘金热里的故事。模型公司是挖金子的人过段时间可能换一批更厉害的人来挖但卖铲子、修路、提供能源的人只要金矿还在就一直有生意。Decart AI 把推理优化作为自己的核心能力相当于在生成式 AI 产业链里占据了一个更底层的环节。即便未来视频模型换了一代推理优化经验仍然可以复用到新模型上。这也能解释为什么它不只是做产品而是在做基础设施。当各种 AI 应用公司都在争夺模型排行榜时一家能把“AI 世界”类实时交互任务跑起来、并且控制住成本的公司天然会成为更稀缺的资产。3. 实时 AI 世界背后的四大工程难题比模型本身更难解决3.1 顺序依赖让预计算几乎失效AI 视频可以分成多段并行生成再拼接调整而交互世界模型有强顺序依赖当前帧必须基于上一帧的历史和最新动作输入任何两步并行都会打破世界的一致性。这种顺序依赖导致推理引擎无法像离线渲染那样大规模并行只能退化为一个循环不断读取上下文、执行前向传播、输出帧、再写入新的历史。实际操作中的影响是虽然可以预先部署很多 GPU但单用户请求很难被拆成多个并行任务如果模型上下文过大显存和内存会随运行时长持续增长最终导致推理越来越慢。工程上要做的是设计合理的上下文窗口、关键帧缓存、记忆压缩和提前预载策略而不是等着硬件跑得更快。如果你之前做过大模型的 KV cache 优化会更容易理解这个问题。自回归生成中每一步都要读取历史键值对历史越长显存占用越多推理延迟也越高。世界模型的“历史”不只是文本还包括画面帧和中间特征规模比文本场景大得多。所以你会发现世界模型真正难的不是“生成一帧”而是“持续生成很多帧还不崩”。3.2 一致性需要记忆但不能无限记忆交互式 AI 世界的难点在于模型既要把短期记忆保留足够长确保用户转身后世界不会变得陌生又不能在推理时把所有历史帧都塞进上下文。这里存在三组矛盾记忆长度与推理速度、记忆长度与显存占用、记忆完整性与输出稳定性。业界常见的处理思路包括对历史帧做采样缓存用全局摘要代替逐帧记忆在关键帧之间做隐状态传递或者在用户走远时通过场景脚本重设部分上下文。这些都属于工程取舍。比如你可以在每 8 帧里只保留 1 帧的完整特征其他帧只保留运动向量和差分信息也可以每隔一段时间生成一段“场景摘要”描述当前世界的地点、物体状态和用户位置再在后续生成时把这段摘要作为条件输入。实际落地时如果你发现世界一致性不好不要急着怀疑模型权重先检查自己的上下文管理策略再看推理模块是否丢了关键历史。很多情况下问题不是出在“模型想不出合理的画面”而是出在“模型已经没有足够的上下文去记住之前的画面”。3.3 用户体验还取决于推流和浏览器渲染即便模型能在极短时间内生成一帧画面真实用户也未必感受到它快。因为在云端生成后一帧画面还要经过视频编码、网络传输、客户端解码、浏览器渲染最后才能在屏幕上显示。任何一个环节抖动都会把模型推理节省下来的时间重新吃掉。这里经常被低估的是网络环境的多样性。同一套系统在演示现场的高速网络下流畅不代表普通用户的常速网络也能有同样体验。更常见的情况是在本地 GPU 上测试时一切正常一到联调就出现花屏、掉帧、画面延迟和声音错位。解决这类问题需要引入自适应码率、分辨率动态调整、帧率控制以及前端渲染降级策略并且在不同网络条件下做真实环境测试。浏览器侧还有一个容易踩坑的点是自动播放策略。大部分浏览器对自动播放音频和视频有严格限制用户必须至少进行过一次点击页面才能正常播放有声内容。如果交互世界需要提供声音反馈前端团队需要提前处理这些策略否则用户进入世界后可能一直处于静音状态而问题看起来却像是“音频模块坏了”。3.4 规模化部署成本、并发和观测缺一不可从单人 demo 到可商用服务还会遇到另一个量级的瓶颈并发。单个用户实时推理已经需要可观算力想象一下同时接入 1000 个用户每个用户都要求模型持续生成画面这时的 GPU 集群调度、排队策略、弹性扩容和失败重试就成了产品能否上线的前提。我建议所有想尝试这类项目的团队都提前建好一套观测体系至少包含四个指标单帧推理延迟、端到端显示延迟、失败率、单位交互成本。缺少这套指标你无法判断“看起来卡”到底是网络问题、模型问题、还是服务器过载。很多项目倒下不是模型不够好而是问题发生的时候团队连问题出在哪一层都不知道。这里可以给一个简单的排查顺序。先看现象是全局卡顿、局部掉帧还是直接断连。再看网络带宽、丢包率、视频编码
返回列表