上个月,我公布了一个基准 显示一个1.125×速度 从块-剩余缓存 4位FLUX。
主要教训不是乘数。
是因为我最初的质量衡量标准是错的, 加速要求常常将速度,轨迹保存, 和知觉质量 合并成一个数字。
对于后续,我选择了更严格的目标:在Apple M5 Max上实时自递传播视频,在结果可见前定义"实时"被冻结.
测试的配置没有达到这一目标。
符合要求的最快结果为每秒1.418个本地生成帧,而FPS目标为16个.
这是一个11.28x差距。
我发表这个结果,是因为衡量的瓶颈、一个系统改进和两个被拒绝的假设,即使没有实时结果,也是有用的。
可从仓库检查中检查证据: 所设置的LiveFrame评价了以Wan2.1-T2V-1.3B为基础的基于NVIDIA H100 CUDA和苹果M5 Max MLX/Metal的因果视频模型.
实验包括: CUDA-to-MLX可移植性研究 CUDA-Causal Forcing++ H100缓存-再用实验的 CUDA-对MLX可移植性研究 CAusal Forcing++ 清洁的M5固定在480×832出产了81个像素框架,与模型原生的16个FPS对应5.06秒.
在出现抵制结果之前,相关协议冻结了它们的提示、种子、内容层、地平线、阈值、汇总规则和停止规则。
对于跨运行时间的实验,斯多克特式输入被连为一次BF16分数.
CUDA和MLX消耗的字节-等同的分数计,而不是依赖名义上的匹配随机种子.
LiveFrame 分离出四个索赔层: 数值轨迹: 候选人是否遵循参考潜入?
内在品质:候选视频独立于参考轨迹能否被接受?.
同种种子身份:是否可以识别出同一种生成的视频?.
完整墙性能:所测量的生成管道需要多长时间,包括强制刷新,VAE解码,实现,同步,并编码?
干净的M5行排除了模型加载和即时编码,因此它是一个完整的被测量的生成墙,而不是应用程序的启动时间.
结果1:一个系统加速与匹配的RGB文摘记录相匹配 将MLX的捆绑自由缓存从 1 GiB 压缩为 4 GiB 将被冻结固定的完全测量的墙壁时间从 69.167 秒缩短为 57.127 秒.
这是1.2108x的速度,或墙上时间缩短了17.41%。
所有测量试验:为97,044,480字节前编码RGB输出录入相同的SHA-256文摘,通过被固定的潜在锚 添加了零交换 原始RGB有效载荷本身没有被保留.
因此,准确产出的证据包括载有相同摘要的反复不可更改的审判记录,而不是原始像素可独立再分配的副本。
所保留的H.264输出及其已解码的RGB有单独的散列.
简介比乘数更丰富。
在这种M5配置中,因果VAE解码消耗了72.33%到78.69%的完整被测量的壁时间.
变压器已经蒸馏成去诺斯步骤。
对于这种配置,解码器执行和内存再利用是更大的优化目标.
结果2:测量到的缺口为实时,包括了分配器的改进,固定装置达到1.418个原生FPS.
LiveFrame将实时定义为至少16个原生生成的FPS持续60秒流,时间为第一帧,p95块活度,内存,热态,质量,身份,并被披露出漂移.
内插或重复的演示框不计入本土生成率。
测量差距为:16 ÷ 1.4179056 = 11.2842× 这一结果有两个重要界限: 这是一个81个框架的干净固定装置,而不是持续60秒的性能结果。
这不是苹果硅不可能的结果。
量子化,分辨分级分级