3.3 本地模型概览

3.3 本地模型概览

本节摘要：本节看生成段的另一条部署路线：本地跑开源模型。先说动机的三分法——隐私（素材不能出内网）、成本（批量生产时 API 按次计费会累积成账单）、离线（现场无网或网络不可靠），三者有一条成立就该评估本地。主角是 LTX-2（Lightricks/LTX-2，约 9.8k stars，社区口径、增速需甄别）：开源的音频-视频生成模型，官方提供 Python 推理与 LoRA 训练包，社区另有 ComfyUI 生态的接入方式；本节给跑法概览与硬件量级（全部示意口径，以官方仓库为准），不深入安装细节。然后是本地与 API 的六维对照：成本结构（一次性硬件投入对按次付费）、质量上限、速度、隐私、运维负担、合规责任。最后给选型建议：个人验证期走 API，批量稳定期算总账，隐私敏感场景直接本地。模型怎么生成视频的原理（扩散、时空表征）不在本节，见《多模态大模型》第 8 章第 8.3 节。

学习目标

• 说出评估本地路线的三个动机，并判断自己场景是否命中。
• 描述 LTX-2 的定位、官方包形态与社区接入方式（概览级，以官方仓库为准）。
• 复述本地与 API 的六维对照结论。
• 为个人验证、批量生产、隐私敏感三种场景各给出部署路线。

一、为什么看本地

API 用得顺手时，本地路线常被低估；三种情况会让它变成必选项。隐私：客户素材、企业内部内容不允许出内网，云 API 的数据条款再好也过不了合规审查。成本：API 按次计费，单次几秒片段从约 0.1 到 1 美元不等（示意口径，随供应商与档位浮动），日更十条的栏目一年下来是一笔可预算的账；本地把边际成本压到电费，代价是一次性硬件投入。离线：现场制作、弱网环境，云上排队轮询的三段式直接失效。反向也要说清：本地不解决质量问题——同代模型里，闭源 API 的档位通常仍占质量上风；选本地是选部署位置，不是选更好的模型。

三个具体场景帮判断怎么落地。场景甲（隐私命中）：企业给未发布产品做内部先导片，画面素材来自厂区与车间实拍加模型生成，法务明确素材不得出内网——云 API 直接出局，哪怕它更便宜、效果更好，部署形态只剩「本地单机或内网服务器」一档。场景乙（成本命中）：知识栏目稳定日更，每月生成镜头数以百计（示意值），账单逐月走高，而其中约七成是氛围空镜与背景板类低难度镜头（示意值）——这类镜头恰是开源模型的能力舒适区，值得算迁移账（本节第五部分给完整走查）。场景丙（离线命中）：活动现场的即时混剪工作站，网络只靠临时热点，排队轮询随时断线——本地是唯一稳定解，哪怕牺牲画质档位。三个场景对应三种命中方式，也对应后面不同的部署形态：甲要内网与权限管控，乙要算总账定分流，丙要便携与低依赖。

二、LTX-2：开源音频-视频模型的代表

LTX-2 是 Lightricks 开源的音频-视频生成模型（同仓库含推理与 LoRA 训练代码），在事实基准日 2026-10-16 经 GitHub 接口核实存在，约 9.8k stars（社区口径，增速需甄别）。本地跑法的概览路径有三条，均以官方仓库文档为最终依据：

硬件量级（示意口径，随版本与分辨率档浮动很大）：起步档消费级显卡跑低分辨率短片段；1080p 档建议 24GB 级显存；追求批量吞吐则多卡或集群，硬件预算从一千美元级到数万美元级不等。这些数字会随模型版本快速变化，采购决策前以官方仓库的实测口径为准。

三条路径里，「自部署服务」值得多说一句，因为它决定了「切换部署位置不动流水线」能不能成立。做法是给本地模型包一层薄薄的 HTTP 服务，对齐第 3.1 节三段式的形状：

对齐之后，生成段客户端的三个方法（提交、查状态、拉产物）背后的实现从云换成本地，上层代码零改动——第 1 章模块化承诺在这里第二次兑现（第一次是 6.1 节后半本的 TTS 适配层，同一思想）。这层薄服务的附加收益是团队共用：一张卡跑一个服务、全组共访问，比每人一套环境既省心又省显存。ComfyUI 路径则适合另一个位置——试镜头：把首帧图、提示词、参数拖成一张工作流，出片后把工作流文件与参数一起存档，好结果才可复现。

第一次本地试水，给自己列一张最小验证清单，逐项打钩再谈下一步：

清单全绿才有资格进入第六部分之前的正式评估；任何一项反复调不出来，说明运维成本已超预期，回到 API 路线不丢人。

三、本地与 API：六维对照

判读这张表的钥匙是「量」与「密」：产量大（成本敏感）或内容密（隐私敏感）往本地倾斜，两者都不沾就用 API——运维负担是实打实的隐性人力成本，常常被初次选型低估。

四、选型建议

按团队阶段给三条默认路线，例外按六维表自己算。验证期（个人或小团队起步）：全走 API，钱花在刀刃上，先验证内容与流程，别先买显卡。批量期（栏目化日更、多客户）：拿第 10 章（后半本）的成核算法定阈值——月账单持续高于一档显卡摊销时，把高频低难度镜头（背景、氛围空镜）迁本地，高难度镜头留 API，混合部署。密期（隐私或离线硬约束）：本地是唯一解，接受质量与运维代价，用 LoRA 微调（LTX-2 官方包支持）逼近领域风格。无论哪条路线，生成段都套 3.1 节的适配层接口——切换部署位置不应改动流水线任何其他段，这是第 1 章模块化承诺的验收时刻。

三条路线也不是一次定终身的静态选择，成熟团队常见的迁移节奏是三步：先影子（本地与云并排跑、只对比不切流），再分流（低难度镜头切本地、高难度留云），后扩容（本地占比随账单与质量数据逐步上调）。每一步都有退路——适配层还在，切回云 API 只是改一行配置。反方向同理：本地跑得好的团队遇到质量要求突然拔高的项目，把该项目的任务全部指回云档即可。部署位置成为运营变量而不是架构决定，正是适配层存在的意义。

五、混合部署走查

把第四部分的「批量期混合部署」落成一次完整走查。背景：知识栏目月度盘点发现生成段 API 账单约 300 美元（示意值），其中氛围空镜与背景板类任务约占七成（示意值）。决策分四步。

第一步，盘点：从近一个月的生成日志统计任务类型分布，按「高难度镜头」（人物特写、复杂动作）与「低难度镜头」（空镜、背景、纹理）打标签。第二步，测算：低难度类月均约 210 个任务（示意值），按 API 单价折算约每月 200 美元（示意值）；一张 24GB 显卡整机约 2000 美元（示意值），按三年摊销每月约 55 美元（示意值）加电费——账面约十个月打平（示意测算，不含运维人力）。第三步，灰度：本地服务先以影子模式跑两周，同参数出片与云结果并排对比，确认低难度镜头的本地质量可接受。第四步，切换：路由规则上线，任务清单里带 easy 标签的走本地，其余走云 API。

# hybrid_router —— 混合部署的分流结构（示意）
                ┌──────────────────────┐
 生成任务清单 ──▶│  生成段适配层          │──▶ 云 API：高难度镜头
 tasks.json     │  按 tag 分流           │
                └──────────────────────┘
                          │
                          ▼
                本地自部署服务：氛围空镜、背景板
                （对齐三段式形状，客户端代码零改动）
​

分流路由本身只有十几行：

# route_tasks.py —— 生成任务的本地与云分流（纯标准库，产物名为示意）
import json
from pathlib import Path

def route(tasks_path):
    tasks = json.loads(Path(tasks_path).read_text(encoding="utf-8"))["tasks"]
    local = [t for t in tasks if t.get("tag") == "easy"]
    cloud = [t for t in tasks if t.get("tag") != "easy"]
    out = Path("build/03_assets")
    out.mkdir(parents=True, exist_ok=True)
    (out / "tasks_local.json").write_text(
        json.dumps({"tasks": local}, ensure_ascii=False, indent=2),
        encoding="utf-8")
    (out / "tasks_cloud.json").write_text(
        json.dumps({"tasks": cloud}, ensure_ascii=False, indent=2),
        encoding="utf-8")
    print("本地 %d 个，云 %d 个" % (len(local), len(cloud)))

if __name__ == "__main__":
    route("build/03_assets/tasks.json")
​

路由器刻意写得笨：只认 tag、只切两份清单，不碰 prompt、不碰参数。切换上线后的首月还要盯三个观察指标：本地任务成功率（与影子期对比是否滑坡）、单任务平均等待（本地排队是否堆积）、质量驳回率（下游人审打回的比例）。三项都在预期内，混合部署才算真正站住。

走查的三条纪律。分流规则进配置不进代码：哪些标签走本地是会变的经营决策，写进 project.json，路由器只读配置。灰度不可缺少：账算得再好，质量掉线就把省下的钱加倍赔回去。两条出口的产物参数必须一致：本地与云出来的片段最终汇入同一个 04_clips，分辨率、帧率、像素格式的全片统一是硬要求（第 3.1 节），不一致就在本地服务出口加一道统一转码（第 5.1 节）。

六、常见问题与排查

本地路线的故障集中在环境与资源两层：

这张表的气质与云 API 排障完全不同：云上是「读状态码改参数」，本地是「读日志修环境」——第三部分「运维负担」四个字，在这张表里具象成六行。这也是「产量与密级都不沾就用 API」一再强调的原因。

本节要点回顾

• 本地三动机：隐私、成本、离线；命中一条就值得评估，但本地不是质量升级。
• LTX-2 官方包、ComfyUI、自部署服务三条跑法路径，硬件量级以官方口径为准。
• 六维对照的判读钥匙是产量与内容密级，运维是常被低估的隐性成本。
• 三阶段默认路线：验证走 API、批量算总账混合部署、密级场景直接本地。

生成段的两条部署路线都清楚了，下一章补它上游的弹药库——首帧图从哪来、素材怎么管、授权怎么查。