同一张RTX 5090，FastH3单张照片请求62秒、Wan 2.2 14B MoE 93.8秒、LTX-2.3同步音频97帧40秒、Waypoint-1.5 INT8 720p能到30 FPS实时——当“实时”和“出片”在同一个硬件上差着两个数量级时，本地部署AI视频的“速度”到底该按推理延迟衡量，还是按“从提示词到一条可用的片子”的全链路时间来衡量？

一、问题的提出：被混用的“速度”

先把四个数字摆清楚。它们分别来自四类不同性质的系统，且都运行在RTX 5090这一级别的单卡上（显存32GB GDDR7， Blackwell架构）。FastH3类单图条件生成，一次请求约62秒；Wan 2.2 14B MoE文生视频，一次约93.8秒；LTX-2.3同步音频生成，97帧约40秒；Waypoint-1.5以INT8量化在720p下达到30 FPS的交互帧率。需要说明的是，上述数值来自公开技术报告、项目页面与社区实测的整合，属于整合数据，不同测试的分辨率、帧数、采样步数与精度设置并不统一，因此不能直接相除比较。本文在第五节会逐项标注口径。

问题的症结在于：这四个数字里，只有最后一个测的是“每帧耗时”的倒数，前三个测的是“一次任务耗时”。把它们并列，读者会本能地得出“Waypoint比Wan快两千多倍”的结论，而这个结论毫无意义——因为Waypoint生成的是可交互的低延迟帧流，Wan生成的是带语义一致性的完整片段。本文评述：工程上真正需要回答的不是“谁更快”，而是“在我的使用场景里，哪个时间项构成了瓶颈”。一个做短视频批量生产的团队，关心的是每小时能出多少条过审的片子；一个做交互式内容原型的团队，关心的是按键到画面变化的延迟。这两类需求对应完全不同的优化目标函数。

因此本文确立一条贯穿全文的分析主线：用“全链路有效吞吐”替代“单次推理延迟”作为本地AI视频部署的一级指标，并把所有系统的性能数字重新放回这个框架中解释。这条主线的价值在于，它能把看似矛盾的数字统一到同一张因果图上，并直接指向可操作的优化杠杆。

二、背景与概念界定：延迟、吞吐与可用性

2.1 三个必须分开的定义

推理延迟（inference latency）指从输入张量进入模型到输出张量可读出的时间，通常以P50/P95分位报告。它排除了模型加载、显存分配、前后处理与I/O。吞吐（throughput）指单位时间内完成的请求数或生成的帧数，在批处理场景下与延迟非线性相关。可用性（usability）则是一个更模糊但更贴近生产的量：一次生成结果是否达到可直接交付的质量门槛。三者构成一条链，任何一环的短板都会压低最终产出率。

本文评述：学术界大量论文报告的是“在A100上生成一段5秒视频需X秒”，这个数字对本地部署者的参考价值有限，因为它默认了模型已加载、显存充足、无需人工挑选。真实工作流中，模型冷启动、显存碎片、生成失败重试、人工筛选淘汰，往往占据总时间的相当比例。笔者在多个本地部署案例中观察到的经验规律是：当单次生成时间低于30秒时，人工筛选与重试时间开始主导总耗时；当单次生成时间高于120秒时，采样计算主导总耗时。这一规律提示，优化重点应随系统所处区间动态切换。

2.2 为什么“实时”在视频生成里是个局部概念

“实时”在图形学与交互系统中有明确阈值：输入到显示的端到端延迟低于约20毫秒可视为即时响应，低于100毫秒可维持操作感，超过200毫秒用户会明显感到迟滞。Waypoint-1.5这类交互式世界模型追求的正是这个区间，其30 FPS对应每帧约33毫秒的预算。但要注意，这个预算里通常不包含高质量语义规划、长程一致性维护与音频同步——这些恰恰是Wan、LTX这类“出片型”系统的核心能力。

笔者认为，把交互式世界模型与文生视频大模型放在同一张“速度排行榜”上，是一种范畴错误。前者优化的是“感知连续性”，后者优化的是“叙事完整性”。二者的计算图结构、时间预算分配、质量评价体系都不同。正确的做法是承认它们服务于不同任务，然后在各自任务内部定义何为“快”。本文提出的E3T框架正是为了在任务内部给出可比口径。

三、E3T框架：全链路时间的六段分解

E3T的定义是：在给定硬件与质量门槛下，单位时间内产出的“可用成片秒数”。其倒数即“每条可用成片的平均全链路耗时”。为便于测量与归因，本文将其分解为六个阶段，每个阶段都有明确的起止事件与可观测指标。

T_total = T_load + T_cond + T_denoise + T_decode + T_post + T_human

T_load    模型权重加载、量化反量化、CUDA Graph捕获、显存预热
T_cond    文本编码、图像编码、参考帧对齐、条件拼接
T_denoise 扩散/流匹配采样循环，含CFG与调度器开销
T_decode  VAE或视频解码器将潜变量还原为像素
T_post    超分、插帧、音频对齐、封装、字幕
T_human   人工预览、筛选、重试、参数微调

这个分解的工程价值在于：它把“玄学慢”变成可定位的六个数字。以Wan 2.2 14B MoE的93.8秒为例，若T_denoise占70秒、T_decode占12秒、T_load占8秒、其余占3.8秒，那么优化优先级就非常清楚——先动采样，再动解码，最后才是加载。反之，若一个系统单次仅20秒，但T_human高达60秒，那么再优化采样也只是把20秒变成15秒，对总产出率几乎无影响，此时应优化的是提示词模板、批量预览与自动筛选。

本文评述：E3T框架并非全新发明，它借鉴了服务级目标（SLO）与流水线吞吐的经典思想，但在视频生成语境下有两个特殊之处。其一，T_human不可忽略且高度依赖质量分布，质量越不稳定，重试次数越多，T_human越长。其二，T_load在本地部署中占比远高于云端，因为云端可以常驻模型而本地往往按需加载。这两点使得“云端跑分”与“本地体验”之间存在系统性偏差，这也是本文强调必须用全链路口径的原因。

四、四个系统的机制解剖与数字归因

4.1 FastH3：单图条件为何是62秒

单图条件生成的核心开销在条件编码与参考对齐。图像需经视觉编码器映射到与文本共享的语义空间，再与噪声潜变量做交叉注意力。62秒这一量级通常对应中等分辨率、数十步采样的配置。其时间构成中，条件编码往往只占数秒，主体仍是去噪循环。值得注意的是，单图条件的优势在于语义约束强、一次成功率较高，因此T_human相对短——这正是它在生产场景中“体感不慢”的原因。

4.2 Wan 2.2 14B MoE：93.8秒的构成

14B参数、MoE结构意味着每步前向只激活部分专家，理论FLOPs低于同规模稠密模型，但路由开销与专家并行的显存访问模式会带来额外延迟。93.8秒对于一段数秒级视频而言，说明采样步数与分辨率都不低。MoE在此处的意义主要是“以较小激活成本换取较大容量”，对单卡本地部署而言，其收益体现在质量而非速度。笔者认为，把MoE当作速度优化手段是一种误读，它优化的是质量-参数效率的权衡，而非延迟。

4.3 LTX-2.3：97帧带音频40秒的启示

97帧约合4秒（按24FPS），40秒完成，折算约0.41秒/帧。这个数字介于“出片型”与“交互型”之间，关键在于它同步生成音频。音视频联合生成的计算图需要额外的时间对齐模块，但其帧率仍能维持在可用区间，说明该架构在潜空间压缩比与采样效率上做了较强优化。本文评述：同步音频不是锦上添花，它显著降低了T_post中的对齐工作量，从全链路角度看是净收益。

4.4 Waypoint-1.5 INT8：30 FPS的边界

720p、INT8量化、30 FPS，这三个条件共同定义了它的适用边界。INT8把权重与激活压到8比特，显存占用与带宽需求大幅下降，是达成实时的主要杠杆。但量化会引入精度损失，在长程一致性与细节纹理上可能劣化。笔者认为，交互式世界模型的评价不应只看FPS，还要看“在多少秒内保持场景一致”。若一致性在十数秒后崩溃，那么30 FPS的实用价值就要打折。

五、关键数据与横向对比

下表把四个系统的公开/整合数据按E3T六段做粗略归因。需要强调：除注明外，各段数值为基于公开信息的整合估算，用于说明量级与瓶颈位置，不作为精确基准。分辨率、帧数、步数等口径差异已在备注中说明。

从表中可以读出一个反直觉的结论：四个系统的瓶颈几乎都落在T_denoise，但它们的“去噪”含义完全不同。出片型系统做的是多步迭代去噪，交互型系统往往做单步或少步前向。因此，“优化采样步数”对前者是主要杠杆，对后者几乎无效——后者要优化的是单步前向的算子效率与内存带宽。本文评述：这正是E3T框架的价值，它迫使分析者先问“瓶颈在哪一段”，再问“这一段由什么决定”，而不是笼统地谈“模型快慢”。

另一个值得注意的现象是T_human的分布差异。出片型系统单次成功率高但单次成本高，交互型系统单次成本低但需要连续多帧才构成可用内容。若把“可用成片”定义为一段数秒的连贯视频，那么交互型系统需要累积上百帧，其等效全链路时间并不像FPS数字显示的那么低。这一点在选型时极易被忽略。

六、工程实践：可复现的测量与优化路径

6.1 测量：先打点，再优化

没有测量就没有优化。建议在代码中显式插入计时点，把六段分别记录，并至少跑20次取P50与P95。下面的伪代码展示了打点位置，实际实现可用CUDA Event或Python的time.perf_counter配合torch.cuda.synchronize。

import time, torch

def timed_pipeline(pipe, prompt, image=None, n=20):
    stats = {k: [] for k in ["load","cond","denoise","decode","post"]}
    for _ in range(n):
        torch.cuda.synchronize(); t0 = time.perf_counter()
        pipe.ensure_loaded()                      # T_load（常驻后可置零）
        torch.cuda.synchronize(); t1 = time.perf_counter()
        cond = pipe.encode(prompt, image)         # T_cond
        torch.cuda.synchronize(); t2 = time.perf_counter()
        lat = pipe.denoise(cond)                  # T_denoise
        torch.cuda.synchronize(); t3 = time.perf_counter()
        frames = pipe.decode(lat)                 # T_decode
        torch.cuda.synchronize(); t4 = time.perf_counter()
        out = pipe.postprocess(frames)            # T_post
        torch.cuda.synchronize(); t5 = time.perf_counter()
        for k, a, b in zip(stats, [t0,t1,t2,t3,t4], [t1,t2,t3,t4,t5]):
            stats[k].append(b - a)
    return {k: sorted(v)[len(v)//2] for k, v in stats.items()}

本文评述：打点本身有成本，频繁的synchronize会破坏流水线并行，因此测量版本与生产版本应分开。测量时追求准确，生产时追求吞吐，二者目标不同。这一点在批处理场景下尤其重要——批处理会拉高单次延迟但压低单帧成本，若用单次延迟做决策就会误判。

6.2 优化杠杆：按瓶颈段对症下药

若瓶颈在T_load，可采取模型常驻、权重预量化、CUDA Graph捕获、页锁定内存等策略。若瓶颈在T_denoise，杠杆包括减少采样步数（配合蒸馏或一致性模型）、降低分辨率后超分、使用更高效的调度器、开启注意力算子融合。若瓶颈在T_decode，可考虑分块解码、更低精度的VAE、或异步解码与下一批采样重叠。若瓶颈在T_human，则应投资于提示词模板库、批量预览网格、自动质量打分与失败重试策略。

笔者认为，最容易被低估的是T_human的优化。很多团队把预算全押在模型加速上，却忽略了“一次生成十条、人工挑一条”这种朴素策略的威力——它把T_human从串行变成并行，等效吞吐提升往往超过任何算子级优化。当然，这要求生成成本足够低，否则批量生成的算力开销会反噬。这是一个需要实测的权衡点。

6.3 可操作的落地步骤

1. 定义质量门槛：明确“可用”的客观标准（如人工评分≥4/5，或自动指标阈值），否则E3T无从计算。
2. 建立基线：在目标硬件上跑20次，记录六段P50/P95，形成基线表。
3. 定位主瓶颈：找出占总时长比例最高的两段，优先处理。
4. 单变量实验：每次只改一个杠杆（步数、分辨率、精度、批大小），记录E3T变化。
5. 回归验证：优化后重测质量分布，确认没有以质量换速度导致T_human反弹。

拓展阅读方面，可参考Hugging Face Diffusers官方文档中关于推理优化与量化的章节（Diffusers Optimization），以及NVIDIA关于TensorRT与INT8量化的开发者博客（NVIDIA Developer Blog）。视频生成方向的公开项目页如Wan、LTX的官方仓库也提供了可复现的推理脚本，适合作为基线搭建的起点。

七、局限、边界条件与常见误判

E3T框架的第一个局限是它对质量门槛的敏感性。门槛定得松，T_human骤降，E3T虚高；门槛定得严，重试激增，E3T骤降。因此任何E3T数字都必须附带门槛定义，否则不可比。第二个局限是它对硬件状态的依赖。显存碎片、温度墙、驱动版本都会影响测量，跨设备比较需谨慎。第三个局限是它难以覆盖创意类任务，因为创意任务的质量分布长尾极重，平均值意义有限。

常见误判有三类。其一，把FPS当吞吐：30 FPS不等于每秒产出30帧可用内容，因为一致性崩溃后的帧不可用。其二，把单次延迟当产能：忽略T_human与失败重试，会高估产能数倍。其三，把云端跑分当本地预期：云端常驻模型、批处理、专用算子，本地往往不具备这些条件。本文评述：避免这三类误判的方法只有一个——在自己的硬件上、用自己的质量门槛、按E3T口径实测。任何二手数字都只能用于量级参考。

“实时”回答的是“我按下按键后多久看到变化”，“出片”回答的是“我多久能拿到一条能发的片子”。前者是交互指标，后者是生产指标。把两者放进同一个排行榜，是当前本地AI视频评测中最普遍的方法论错误。

八、结论与展望

回到标题的问题：本地部署AI视频的“速度”该按推理延迟还是全链路时间衡量？本文的答案是分场景的。对交互式应用，应以帧级延迟与一致性维持时长为核心指标；对生产式应用，应以E3T为核心指标，并把T_human显式纳入。二者不可通约，但可在同一六段框架下分别度量。四个系统的数字差异，本质上是任务定义差异的投影，而非单纯的工程优劣。

展望未来，笔者认为有三个方向值得关注。第一，蒸馏与少步采样会持续压缩T_denoise，使“出片型”系统向数十秒区间靠拢。第二，量化与算子融合会继续压低交互型系统的单帧成本，但其瓶颈将逐渐转移到长程一致性的算法层面。第三，自动化质量评估的成熟会显著压缩T_human，这可能是未来两年对E3T提升最大的单一因素。对从业者而言，建立自己的E3T基线表，比追逐任何单一跑分都更有长期价值。