按每秒 $0.02 计算,Decart 的 Lucy 2.5 看似不贵;但一场持续四小时的直播,账单就是 $288。Lucy 2.5 为实时 AI 视频转换提供了一个已广泛开放的 API 通道,不过发布材料中提到的 1080p 并不是 API 文档承诺的输出规格,而所谓的超低延迟,衡量的也是模型侧而非从摄像头采集到观众屏幕显示的全链路。本指南将营销说法与已文档化的能力拆开来看,算清每小时成本,并梳理实际接入路径。
Lucy 2.5 到底能做什么
Lucy 2.5 是 Decart 推出的一款实时视频转视频编辑模型,发布于 2026 年 7 月 16 日,发布文章为 “Raising the Bar for Live AI”。视频通过 WebRTC 接入,用户可用文本提示词和可选的参考图来引导转换,官方称处理后的画面可达 30 fps。重点在于“转换”:Lucy 是在已有的实时画面中重绘风格、替换、添加或移除元素,并不是从零生成一段成片视频。Theoretically Media 的 Tim Simmons 很明确地区分了两者:它更像是叠加在流媒体上的实时特效与合成,不是非线性剪辑工具;目前也仅提供 API,“还没有 app 版本”,Decart 发布视频中手持手机展示的产品“并不是一个可用产品”。
API 文档显示,Lucy 同时支持实时和录制好的视频输入;fal 的模型页面则说明,在其条款范围内允许商用。Decart 已累计融资超过 $450M,其中包括 Radical Ventures 于 2026 年 5 月领投的 $300M 融资。
别再把 1080p 当成 API 规格
发布材料和 fal 模型页面都将 Lucy 2.5 描述为支持 30 fps、1080p。但 Decart 自己的 API 文档写明的是1280 × 720 输出,支持 16:9 横屏和 9:16 竖屏。在公开文档出现 1080p 端点之前,实际项目应按 720p 规划:这是 API 合约中明确写出的规格,价格示例也基于 720p 计算。
帧率也应以同样的方式审视。营销文案虽然写着“30 FPS”,却没有披露测量方法;Decart 也未公开服务端硬件、模型规模,或从采集到播放的完整测试数据。可以参考一个外部案例:2026 年 5 月发布的研究预印本 SANA-Streaming 表示,在单张 RTX 5090 上,其 1280 × 704 的端到端帧率为 24 fps,而扩散 Transformer 核心达到 58 fps。这并不是 Lucy 的基准测试,但它说明,若不定义测量点,单独一句“30 FPS”并不能充分说明实际体验。
“近乎零延迟”究竟指什么
围绕 Lucy 2.5 流传着三种延迟数字,但它们测量的并不是同一个环节。Decart 在随 $300M 融资一同发布的 DOS 2.0 基础设施文章中称模型响应低于 30 ms;Hugging Face 上的社区解读则将 720p 下低于 40 ms 的推理延迟归因于 Decart 的推理栈,包括 MXFP8/NVFP4 量化、动态稀疏注意力和深度 kernel 融合,并提到其对计算受限操作声称有 4× 加速。两者都没有给出从摄像头采集到观众屏幕像素显示的端到端延迟数据。这个链路还会叠加 WebRTC 传输、编码与播放器延迟,且会随网络条件变化。要评估自己的部署,可在摄像头画面中录入可见时间戳,再通过目标网络和播放器链路,将其与最终显示画面对比。
可控性:八种编辑方式,以及 Self-Anchoring 的失效场景
Lucy 2.5 文档中列出八类编辑操作,每一类都可通过文本提示词、参考图,或两者结合来控制:
| 编辑模式 | 常见实时用途 |
|---|---|
| 角色替换 | 替换为 VTuber 虚拟形象或品牌吉祥物 |
| 虚拟试穿 | 直播电商中的服装切换 |
| 添加物体 | 在产品演示中加入交互元素 |
| 替换物体 | 替换背景中的物品 |
| 移除物体 | 清除杂物并重建背景 |
| 属性调整 | 调整颜色、尺寸和位置 |
| 替换背景 | 无需绿幕的实时场景切换 |
| 全局风格迁移 | 从白天风格切换到赛博朋克风格,或实时 VFX |
比模式清单更值得关注的是两个控制细节。首先,Self-Anchoring 会将模型近期输出重新作为参考输入,以减少长时间直播中的人物身份漂移。它默认开启,而且只能在建立连接时修改。Decart 文档提醒,在镜头发生强切、新人物进入画面,或场景出现明显变化时,应关闭这一机制;因为此时锚点对应的是一个已经不存在的场景。这也意味着需要重新连接,多机位方案应提前考虑这一点。
其次,参考图有明确要求:画面必须清晰、光线充足、主体无遮挡,尺寸至少为512 × 512 像素,且构图应与源视频匹配。光线不足或构图不一致的参考图,可能会让替换效果直接失败。
实时生成还是离线生成:该怎么选
Runway、Pika、Sora 同类离线工具与 Lucy 2.5 解决的是不同问题。“哪个更好”没有统一答案,关键在于应用路径。主要看以下四个维度:
- 交互需求。如果需要观众或摄像头在视频进行时即时影响结果,只有实时方案能做到;离线工具仍是“输入提示词、等待生成”的流程。
- 时长。根据 Hugging Face 的对比,Runway、Pika 这一类离线产品通常生成 5 至 60 秒的片段,渲染耗时从数秒到数分钟不等。Lucy 可持续流式处理;fal 声称它可以运行数小时而不发生身份崩坏,但尚未发布长时压力测试。
- 质量下限。如果最终交付物要求 1080p 以上,考虑到 API 已文档化的输出只有 720p,目前离线渲染仍然更有优势。Tim Simmons 提出了一种实用的混合工作流:先用手机拍摄,在 Lucy 中实时套用处理效果来判断镜头,之后再使用离线视频转视频模型进行最终质量渲染。
- 成本形态。离线工具通常按生成片段计费;Lucy 则按流处于活跃生成状态的秒数计费,按小时累计后的差异很大,下一节会具体计算。
用户真正看中的是什么?在 r/generativeAI,u/TastyFooting 的说法很直接:
“通过文本提示词实现实时视频转视频生成。不再需要等待渲染。”(来源)
社区讨论也集中在两个尚未完全验证的问题上:u/ai_art_is_art 在帖子中问道:“这种模型有什么用途?VTubing?”另一位 r/AINewsAndTrends 创作者则关心“脱离演示后是否依然有效”。fal 模型页给出的应用方向包括:直播购物和虚拟试穿、实时产品植入、互动直播、应用内场景转换、游戏,以及直播看房中的虚拟布景;Hugging Face 的解读还加入了 VTubing 和广告素材变体工作流。若想了解实时生成如何改变视频 API 的竞争格局,可查看我们对 SeedRealtime 的报道。
实际成本:$0.02/秒并不是最重要的数字
目前公开的两条接入路径,对应两种价格:
| 接入方式 | 费率 | 活跃生成一小时 | 说明 |
|---|---|---|---|
| Decart 直连 API | $0.02/秒(720p) | $72 | 新账户有测试额度;可协商批量定价 |
| fal Serverless | $0.04/秒 | $144 | 包含 Playground,无最低消费 |
Decart 自己的定价示例展示了较小的使用规模:30 秒实时会话价格为 $0.60,5 秒离线 720p 编辑价格为 $0.20。根据两家平台的定价页,它们计量的都是活跃生成秒数,而不是观众观看时长。真正影响决策的是另一端的成本:
若每个工作日活跃生成四小时,fal 每天的费用约为 $576;按一个月 22 个工作日计算,约为 $12,700,尚未包括网络和内容审核成本。持续生成会让看似很低的单价变成按小时计算的并发问题:如果应用让每位观众独立开启一条 Lucy 流,那么每小时成本还需按并发数相乘。若你正在对比其他生成 API,关于按秒、按片段、按 token 等不同计费维度的差异,可参考我们的视频生成 API 定价指南。
有两种结构性的降本方式。摄像头闲置时不必持续触发生成,可以只在确有内容时开启流;其次,接入路径本身就能将成本减半。对于相同的文档化 720p 输出,Decart 直连价格只有 fal 的一半;而 fal 打包提供 Playground、商用条款和生态能力。最终选哪一家,取决于模型之外你还需要什么。
如何获取和接入:Decart、Playground 与 fal
想最快看到 Lucy 2.5 对自己的脸实时产生效果,可以直接使用 Decart 的浏览器体验 lucy.decart.ai,或演示 Playground demos.decart.ai。根据定价页,新账户可获得测试额度,或许足够完成一次初步测试。正式写代码前,建议先在这里测试参考图和提示词写法。
按照实时 Lucy 2.5 文档,直接接入 Decart API 的流程遵循标准 WebRTC 模式:
- 获取 API 凭据,并为
lucy-2.5模型创建实时会话 - 建立 WebRTC 连接,在连接时配置 Self-Anchoring 和提示词增强功能;之后调整 Self-Anchoring 需要重新连接
- 将实时或录制好的输入媒体接入会话
- 在活跃连接中发送文本提示词和参考图,参考图可在会话中途更新
- 消费编辑后的输出轨道;会话断开时可依赖内置自动重连机制,采用指数退避,最多重试 5 次
通过 fal 集成则分为五步:
npm install --save @fal-ai/client- 创建 fal 账户,并从控制台获取 API key
- 向
decart/lucy-2-5/realtime建立 WebRTC 连接 - 通过
tokenProvider从后端签发短期 JWT;fal 的示例使用 10 秒 token 有效期,因此这不是把 key 放到前端、只用浏览器即可完成的接入方式 - 通过
onResult/onError处理结果和错误,再通过实时连接发送提示词
fal 的模型页显示,JavaScript、Python 和原生 REST 都可作为客户端接入路径。对于 OBS,要区分原型验证和生产使用:将 Decart 浏览器体验作为浏览器源或窗口采集源,适合快速测试视觉效果;生产管线则应接入你自己 API 集成所输出的 WebRTC 流。Hugging Face 的解读提到,可通过 WebRTC 在不改动现有直播配置的前提下接入 OBS,但仍应在自己的技术栈中验证拉流、延迟和重连行为;同一篇文章还提到 Android 和 iOS 移动端 SDK。若需要比较不同版本的行为,fal 上仍可使用 Lucy 2.1。关于 fal 平台本身的更全面评估,可参考我们的 fal.ai 评测。
上线前别忽略:披露要求已经生效
能够实时改变人物、服装和环境的视频模型,会让合规成为工程要求,而不只是政策备注。Decart 的可接受使用政策于 2026 年 2 月 12 日更新,其中禁止在没有清晰、醒目披露和可验证同意的情况下冒充真实人物;同时要求部署方披露 AI 生成或篡改内容、实施适当审核,并在技术可行时保留机器可读标记。此外,自 2026 年 8 月 2 日起生效的欧盟透明度义务,要求可检测的 AI 生成内容使用机器可读标记,并要求深度伪造类用途的部署方进行披露。面向欧盟用户部署前,应先确认适用的透明度和溯源义务,而不是上线后再处理。
现在值得基于 Lucy 2.5 开发吗?
| 项目类型 | 建议 |
|---|---|
| 直播特效、VTubing、观众互动视频 | 现在就做,这正是实时路线最适合的场景 |
| 直播电商试穿、产品植入演示 | 现在就做,先以 720p 做原型,并在自己的素材上验证编辑隔离效果 |
| 基于同一素材制作广告变体或本地化版本 | 现在可以试点,这是一个合理的早期用例,经济账也比较清晰 |
| 离线最终渲染前的实时预览 | 现在就做,30 秒效果测试只需 $0.60,比重新拍摄更划算 |
| 最终交付要求 1080p+ | 等待,当前文档化 API 输出为 720p |
| 预算敏感的大规模持续直播 | 等待或严格设门槛,按小时累积的成本增长速度远快于按片段计费 |
接下来最值得关注的变量是:如果 Decart 推出公开的 1080p 接入路径,离线与实时方案之间的质量差距将明显缩小;在此之前,应把 720p 视为实际合约,而将更高的数字看作未来意图。
Lucy 2.5 实时视频常见问题
Lucy 2.5 真的是实时的吗?
从定义上说是:它会以官方声称的 30 fps 对实时 WebRTC 视频流施加编辑,模型侧延迟则被描述为低于 30–40 ms。但目前没有公开的独立端到端测试,即从采集到播放的测量数据。因此,“实时”目前只能算是演示验证过,尚不是基准测试验证过。
Lucy 2.5 API 输出什么分辨率?
API 文档标明输出为 1280 × 720,支持 16:9 或 9:16。发布材料宣传 1080p,但截至 2026 年 8 月下旬,尚无公开文档记录的 1080p 端点。
Lucy 2.5 每小时多少钱?
Decart 直连 API 在 720p 下按每活跃生成秒 $0.02 计费,即每活跃生成小时 $72。fal 上的同一模型为每秒 $0.04,即每活跃生成小时 $144。两者计量的都是活跃生成时间,不是观众观看时间。
Lucy 2.5 能和 OBS 一起用吗?
可以用于原型验证:浏览器体验可通过浏览器源或窗口采集作为 OBS 来源。若用于生产环境,在正式投入前,应先在自己的直播技术栈中测试 WebRTC 拉流工作流。
选 Lucy 2.5 还是 Lucy 2.1?
根据 fal 的版本对比,Lucy 2.5 扩展了编辑范围,包括物体、服装、角色、属性、背景、风格和 VFX,并声称在提示词遵循度、编辑隔离性和参考图保真度上有所改善。Lucy 2.1 作为更早的实时端点仍可在 fal 使用;若你需要一个已知稳定性的基线,应基于自己的素材同时测试两个版本。