Sora最先让人记住的，不是模型参数，而是60秒。
2024年2月16日，OpenAI发布Sora。财联社当时整理的公开信息提到，它可以直接生成长达60秒的视频，画面包含细致背景、复杂的多角度镜头，以及多个带有情绪表现的角色。相比此前常见的短片段，60秒已经足以容纳连续动作和一小段叙事。
代价也很直接。证券时报刊发的报道把“算力需求激增”写进了标题。但一段云端样片，和手机、AR眼镜里的实时画面，不是同一道题。样片可以等待，交互不能。用户举起手机或转动头部时，画面要跟着更新，模型同时面对延迟、内存带宽、发热和续航。
60秒不是实时通行证
扩散式生成需要经过多轮去噪。到了视频，每一步还要同时处理画面空间和前后帧关系。目标一旦抬到1080p，中间特征和像素张量的读写量随之增加，内存总线可能比单个算子更早吃紧。
云端可以调用H100这类数据中心GPU并等待结果，手机SoC面对的却是共享内存、持续功耗和机身散热。参数能否装下只是起点。如果NPU、GPU和内存之间不停搬运大块数据，峰值算力再高，也可能在连续运行时被发热拖住。
端侧视频真正要算的，不只是一次推理用了多少算力，而是这套计算能不能稳定重复。
别让模型把每一帧都重画一遍
视频有一个天然的省算力入口：相邻帧通常没有全部改变。人物身份、场景布局和大部分背景可以沿用，真正需要更新的往往是动作、边缘和局部光影。
“关键帧加残差补全”因此比全量生成更适合端侧。一种可行的分工是，云端负责人物、场景和动作意图等语义信息，端侧再用光流预测、局部扩散或像素补全生成中间帧。模型不必每次都从噪声出发，把整个画面重新想一遍。
关键帧究竟每1秒还是2秒生成一次，不能预先写死。镜头稳定时可以多复用几帧，快速运动时则要更频繁地修正。节省多少计算，也取决于分辨率、运动幅度和补全模型，不能脱离测试条件给出一个通用比例。
这比单纯缩小模型更重要。模型小了，重复工作仍然存在；帧间复用处理的，正是这部分浪费。
FP8不是一句“生死线”就能说清
文本模型的INT4经验不能直接搬到视频上。文本里偶发的数值误差未必容易察觉，视频中的误差却会沿时间轴积累，最后变成色块、闪烁或运动边缘撕裂。
FP8保留的数值范围更多，通常更容易兼顾画面质量；INT4占用更低，但对量化方法和模型结构更挑剔。实际部署未必需要在两者之间二选一。更合理的办法可能是混合精度：对时间一致性敏感的部分保留FP8或更高精度，其余层再使用INT4。
到了A19或骁龙8 Gen 5这类移动平台，结果还取决于芯片是否原生支持相应精度和算子，以及内存带宽、调度方式和持续散热。没有模型版本、分辨率、测试时长与散热条件，30fps、5W或低于50毫秒都缺乏可比性。这些数字可以是工程目标，不能直接当成已经验证的结果。
AR眼镜更在意数据搬了几次
手机尚有较大的电池和散热空间，AR眼镜留给计算的余量更小。此时，Arm还是RISC-V并不能单独决定体验，数据怎么走往往更要紧。
摄像头输入如果反复经过内存、CPU、GPU和NPU，每次搬运都在消耗电量。专用的视频解码—生成通路，以及尽量在片上SRAM完成计算，价值就在这里：少一次调度，少一次读写。
局部渲染也比全画面生成实际。用户看向一个真实物体时，设备可以只为物体边缘或指定区域生成AI覆盖层，背景继续使用摄像头画面。需要处理的像素少了，模型和内存的压力都会下降。
因此，把1W—2W或15fps写成AR设备的统一门槛并不严谨。功耗和帧率必须放回具体设备、分辨率与渲染范围里看。
端侧不是缩小版Sora
Sora把“能生成什么”推到了60秒，端侧要解决的则是“哪些东西根本不用再生成一次”：
- 哪些语义判断留在云端；
- 哪些帧可以直接复用；
- 哪些区域只做局部渲染；
- 哪些层可以使用INT4，哪些需要保留FP8或更高精度。
前者靠更多算力摸到画面上限，后者靠少算、少搬、少等待做成产品。只有把这张账算清，AI视频才可能从一次性产出的样片，变成用户抬手、转头时仍能跟上的交互能力。
资料来源
