LTX-2 本地 vs 云端：ComfyUI vs WaveSpeed（速度、成本与隐私）

一个小事件把我推向了这个话题：40秒的等待。我在 LTX-2 云端启动了一个批处理任务，然后走开去加满我的杯子。回来时，一个任务以模糊的错误失败了，我无法判断是我的问题、预设问题，还是服务问题。那个微小的停顿留在了我心里。第二天早上，我在本地运行了同样的预设，它在我的邮件应用同步之前就完成了。这个对比就是这篇文章的主题：LTX-2 本地 vs 云端，不是一份功能列表，而是每种方式给日常工作增加或移除的那份分量。

我在2026年1月初在我的16英寸MacBook Pro（M2 Pro，32GB内存）和一台配有RTX 4090的小型Ubuntu服务器上测试了两种设置，同时也测试了位于美国地区的LTX-2云端。你的硬件和地区会改变这些数字，但权衡总是以熟悉的方式排列的。有关该模型的更多技术细节，请参阅 LTX-2研究论文。

快速决策表（按用例选择本地或云端）

这是一个快速参考，我希望在反复切换之前就有它。

使用场景	选择	为什么这样选
单个预览、快速反馈循环	本地	几乎没有排队，快速迭代，更容易调试预设和提示。
大型批处理、有明确截止日期	云端	并行任务，更好的吞吐量，一旦调好了，需要的监护更少。
敏感数据（PII、未发布资产）	本地	不上传：默认情况下你控制保留期和访问权限。
不稳定的工作负载（某些周很重，其他周很轻）	云端	按突发付费：无需在桌子下运行闲置GPU。
离线或网络不稳定	本地	显然，但在Wi-Fi出问题的时刻这很重要。
团队共享和可重现性	云端	集中式预设、日志和权限减少”在我机器上能运行”的问题。
实验操作（自定义构建、边界标志）	本地	你可以固定版本、测试分支，并立即回滚。

我没有预期到会这么分化。但一周后，我发现自己默认在本地预览，任何超过200项的任务都发送到云端。

速度：本地硬件 vs 云端吞吐量

确实，速度在两种不同的感受中分化了。

• 本地对单个任务感觉很快。 在M2 Pro上，单个LTX-2任务在约1-2秒内启动并很快完成，快到我能保持专注。在4090服务器上，一旦预热就基本上是瞬间完成。
• 云端对大量任务感觉很稳定。 第一个任务有时在队列中等待5-15秒，但50个并行任务就平稳了。吞吐量战胜了延迟。

现场的小提醒：冷启动的重要性比我们承认的要大。本地缓存，从权重到中间文件，使重复运行感觉更轻。直到我清除了缓存，一切突然拖累了我才注意到这一点。在云端，我无法控制这层，所以我接受了小的启动成本作为规模换取。

让我惊讶的是：我最快的单个预览总是本地的。我最快的1,000项一小时总是云端的。转折点对我来说大约是150-250项。超过这个数字，输入一条命令让服务分散工作可以拯救下午。少于这个数字，启动本地运行让我留在工作中。

成本：电力+折旧 vs 积分

我试图像一个冷静的会计师而不是炒作者一样为此定价。

本地成本看起来像这样：

• 前期硬件（或按月租赁）
• 电力（我的4090服务器闲置时约90W，负载下约420W）
• 折旧和维护（风扇、存储、偶尔的驱动程序陷阱）

云端成本看起来像这样：

• 按任务或按令牌的积分
• 如果你保留资产，可能有出口/存储费用
• 批处理突增时的超额费用

我的笔记中有两个快速计算：

• 200项批处理，每个任务约1分钟： 本地在我的Mac上耗时约220分钟（没有GPU），基本上除了电力外免费。云端用并行处理在8-12分钟内完成，积分成本在我赶截止日期的那一周很容易合理化。更多实现建议可在 GitHub上找到。
• 持续小流量（每天20-30项）： 本地赢了。让服务器保持就绪意味着我一次性吸收成本。每次我点击运行时，云积分都增加了小小的认知成本。不是昂贵的，只是存在。

我不认为有单一的”更便宜”。如果你已经拥有有能力的硬件且工作负载稳定，本地对钱包很温和。如果你的工作量是不稳定的，为突发容量付费比拥有一个装着风扇的空间加热器更好。我有一个月本地几乎免费，另一个月云端明显更聪明。

隐私：数据保留和团队权限

对我来说这部分很简单。如果是敏感的，我在本地运行LTX-2。不是因为我不信任云端，而是因为我能追踪文件的位置。

本地：

• 无上传。工件保留在我的磁盘或网络共享上。
• 我可以遵循自己的保留规则：X天后自动清除，静态加密，就这样。

云端：

• 开箱即用的更好的团队控制：角色、项目边界和不依赖我记忆的日志。
• 保留是基于策略的。这很好，但仍然是与供应商的协议。阅读文档并确认默认值：有些服务保留日志和工件的时间比你预期的要长。

对于跨越小团队的协作，云端感觉更安全，不是在隐私意义上，而是在”我们不会丢失规范预设”的意义上。对于任何有未发布资产或PII的东西，本地让我的肩膀放松。两者都可以做好。对于一般的开放权重和基准，你可以参考 Papers With Code。

稳定性：依赖更新和节点崩溃

我因为驱动程序更新损失了一个下午。这是在本地运行的诚实部分。当它工作时，很棒。当一个依赖突增而另一个滞后时，你就是SRE。

本地稳定性现场笔记：

• 尽可能固定一切。容器、环境文件，甚至OS更新如果你必须的话。
• 保留一个”已知良好”预设+版本列表。我在项目旁边用提交哈希和关键标志保留一个短文本文件。
• 在重批处理下预期偶尔的崩溃。这很少是灾难性的，但它破坏流程。

云端稳定性现场笔记：

• 更少的惊喜：更多黑匣子。任务通常完成，如果不完成，错误消息有时比帮助更礼貌。
• 供应商升级不经宣传推出。当它改进速度时很好：当改变影响输出时很烦人。

都不是完全平静的。本地给你杠杆和额外的杂务。云端给你更少的杠杆和更少的杂务。我根据那一周我愿意忍受哪种中断而选择。

最佳混合方法（本地预览+云端批处理）

最终对我坚持住的是一个简单的节奏：

• 在本地草稿和预览。 我保留一个小样本集，10-20项，反映边界情况。我迭代直到输出看起来对两次，不是一次。
• 在云端批处理。 我导出精确的预设并用时间戳任务名称运行它。我查看前5%的日志，然后走开。

为什么这感觉对：

• 本地预览保持延迟接近零。我可以调整提示、权重或参数而不上下文切换。
• 云端批处理保持我的机器自由。我可以继续写作，或者我可以合上盖子走出去。

两个帮助过的小技巧：

• 我固定了我的”预览集”。早期，我不断交换输入并失去了变化的跟踪。有了固定的集，我知道改进是真实的。
• 我在每个大运行前快照预设。甚至一个小版本颠簸也能轻推输出：快照使差异明显。

在工作较少的周，我有时保持一切本地，特别是如果我离线或旅行。在生产周，我不与云端对抗。LTX-2 本地 vs 云端的要点不是忠诚度，而是选择减少你面前工作的摩擦力的环境。这就是我们构建 WaveSpeed的原因——无需监护队列就能处理本地预览和云端批处理。这是我们团队每天使用的。

迁移检查清单（工作流/预设转移）

在写下步骤后，LTX-2本地和云端之间的移动更顺利了。这是我现在使用的检查清单。它很无聊，这就是它工作的原因。

预设奇偶性

• 导出/导入预设而不是手动复制。如果直接导出不可用，将预设存储在版本控制中为JSON/YAML。
• 固定版本。记下模型/构建ID、任何扩展版本和相关标志。
• 如果确定性重要，记录种子/随机性设置。

资产路径

• 规范化路径。本地绝对路径不会存在于云端：使用相对路径或预上传资产到已知桶或项目文件夹。
• 确认编解码器和格式。不匹配在这里以安静的方式破坏管道。

环境

• 单独记录环境变量和秘密。从不将秘密烘烤到预设中。
• 对齐硬件假设。如果你的本地预设期望某个内存占用，在云端先测试一个较小批处理。

验证

• 运行一个小批处理（完整集的1-5%）并逐输入比较输出。
• 为每个环境中的第一个成功运行保留日志。当以后的东西漂移时，它们成为基线。

回滚

• 在两边保留一个”最后已知良好”预设。用日期和简短备注命名它，比如，“CUDA更新前”或”为版本v1发布锁定种子”。 这花十安静的分钟，在第一次有东西变化时为自己付钱。我仍然不时忘记一个步骤：检查清单原谅那个。

如果你在权衡LTX-2 本地 vs 云端，这是我无论如何都会从这部分开始的。即使你永远不切换，写下你的假设也能平静工作。