Mochi 1 是 Genmo 公司在 2024 年 10 月发布的开源文生视频大模型，以 Apache 2.0 许可开放了模型权重与推理代码，是当时少数几个允许商业使用的开源视频生成方案之一。模型基于非对称扩散 Transformer（Asymmetric Diffusion Transformer，简称 AsymmDiT）架构，参数量达 10B，单次推理可生成 5.4 秒、720p、30fps 的视频片段，并引入了以「前向生成轨迹重建」为核心的训练方法，用于提升时序一致性。官方推理代码在 Linux + CUDA 环境下运行，完整序列推理约需 77GB 以上显存，也可通过 ComfyUI 等社区方案以分块方式将显存需求降到 24GB 级别。本文基于官方仓库与公开资料，从安装配置、快速上手、核心能力、生产部署、同类选型五个维度展开，帮助 AI 工程师在本地或云端把 Mochi 1 跑起来，并评估其实际应用边界。全文所有版本信息均截至 2025 年 6 月。
掌握 Mochi 1 意味着你具备独立部署、评测和二次开发开源视频生成模型的完整能力，这是进入 AIGC 视频方向的重要工程基础。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Mochi 1：开源视频生成缺乏高质量基线
在 Mochi 1 发布之前，文生视频市场被 Runway、Pika 等闭源工具把持，API 调用成本高、生成逻辑不透明，研究团队难以在模型层进行微调或二次开发。Sora 在 2024 年初展示了令人惊艳的效果，但从未开放权重，社区始终缺少一个可复现、可商用的高质量开源基线。Mochi 1 以 Apache 2.0 协议同时开放代码与 10B 参数的模型权重，直接填补了这一空白——从这一天起，团队可以在自己的 GPU 上部署具备接近商业级质量的文生视频模型，且无需支付授权费用。
从工程角度看，Mochi 1 的意义在于它提供了完整、可扩展的推理链路：文本编码、VAE 压缩、扩散采样、视频解码全部开源，用户可以替换其中任意模块（如换 VAE、改采样步数）进行实验。相比同期开源方案，Mochi 1 在 720p 分辨率、30fps、5.4 秒片段这三个指标上同时达标，运动连贯性显著优于基于 U-Net 的早期方案，因此很快成为研究社区对比评测的默认基线。
在同类工具中，Mochi 1 的气质偏「研究友好 + 生产可用」：它不像 Open-Sora 那样强调复现 Sora 的训练流程，也不像 CogVideoX 那样聚焦特定风格优化，而是给出一套开箱即跑的官方案例，让团队能把主要精力放在提示词工程、后处理管线与业务集成上，而不是从零调试采样器。
安装与环境配置：5 步完成本地部署
Mochi 1 官方代码面向 Linux + NVIDIA GPU 设计。官方完整序列推理需要 77GB 以上显存（如 H100 80GB / A100 80GB），若使用 ComfyUI 分块方案，24GB 显存的 RTX 4090 也具备可行性。环境准备包括三部分：Python 虚拟环境、PyTorch CUDA 环境、模型权重。具体步骤如下。
第一步，克隆官方仓库并安装依赖。需要 Python 3.10 及以上版本，pip install -e . 会自动解析 PyTorch、transformers、diffusers 等核心依赖。第二步，登录 Hugging Face 并下载权重。Mochi 1 Preview 权重约 20GB，存放在 checkpoints/mochi-1-preview 目录下。第三步，验证 PyTorch 是否可调用 CUDA。第四步，下载 VAE 与 T5 文本编码器（权重包内已包含）。第五步，运行推理命令，确认能生成 MP4 文件。
安装过程中最常见的失败点是 PyTorch 版本与 CUDA 驱动不匹配。Mochi 1 官方默认依赖在 pyproject.toml 中锁定，若本机已有其他版本 PyTorch，建议在独立虚拟环境中安装，避免污染现有项目。权重下载建议使用 huggingface-cli download 而非 git clone，前者支持断点续传，避免大文件传输中断导致模型文件损坏。
# 1. 克隆仓库并创建虚拟环境git clone https://github.com/genmoai/mochi.gitcd mochipython -m venv .venv && source .venv/bin/activate # 2. 安装依赖pip install -e . # 3. 验证 CUDA 可用python -c "import torch; print('CUDA OK:', torch.cuda.is_available())" # 4. 下载权重（需先执行 huggingface-cli login 完成认证）huggingface-cli download genmo/mochi-1-preview --local-dir checkpoints/mochi-1-preview # 5. 查看目录结构，确认包含 diffusion_pytorch_model.safetensors 等文件ls checkpoints/mochi-1-preview
快速上手：3 分钟跑通第一个 5 秒视频
最小可用流程是：准备一条描述清晰的英文提示词 → 调用官方 CLI 推理 → 生成 MP4 输出。Mochi 1 的文本编码器为 T5-XXL，对中文支持有限，建议统一使用英文提示词。完整序列推理在一张 H100 80GB 上约耗时 3 分钟（480p 分辨率），720p 输出耗时会进一步增加，建议第一次运行时将分辨率调整为较低档位以快速验证链路。
操作步骤分为三步。第一步，在 .venv 激活状态下进入项目根目录，确认权重已就位。第二步，执行推理命令，其中 --prompt 为提示词、--seed 为随机种子，固定种子可复现相同结果。第三步，等待程序运行结束，在输出目录中找到生成的 .mp4 文件，用视频播放器检查画面与运动是否匹配提示词。进阶技巧：将采样步数调低（如从默认 50 步降至 30 步）可显著缩短推理时间，画面质量降低幅度在可接受范围内。
若日志中出现 CUDA out of memory，说明显存不足，有两个应对方向：一是改用 ComfyUI 社区分块推理方案，将整体采样拆分为多个时间窗口，显存需求可降至 24GB 左右；二是降低输出分辨率到 480p。如果出现 Cannot find checkpoint 报错，则说明 --model_dir 路径下的权重文件不完整，需重新下载。
# 最小推理命令：生成 5.4 秒 720p 视频python -m mochi_preview.cli_v2 \ --model_dir "checkpoints/mochi-1-preview" \ --prompt "a red truck is driving on a mountain road, cinematic lighting, high detail" \ --seed 42
核心能力详解：4 大技术支柱
支柱一：AsymmDiT 非对称扩散 Transformer 架构。 Mochi 1 采用 10B 参数的非对称扩散 Transformer，视频 token 通过完整的扩散 Transformer 计算去噪过程，而文本 token 经过冻结的 T5-XXL 编码后仅通过轻量映射层与视频特征交互，避免文本侧重复计算带来显存浪费。这种设计使模型在同等算力下能处理更长的视频 token 序列，是 5.4 秒 720p 生成得以实现的结构基础。
支柱二：前向生成轨迹重建指导（Reconstruction Guidance）。 这是 Genmo 在官方技术博客中重点介绍的训练方法创新。传统扩散模型以噪声预测为回归目标，Mochi 1 则额外引入前向生成轨迹作为回归目标，让模型在每个去噪步骤中都参考真实视频的演化路径。推理时配合重建指导项，可有效抑制画面闪烁与物体形变，这是 Mochi 1 运动连贯性优于同期开源模型的关键原因。
支柱三：时空 VAE 与 T5-XXL 文本编码。 Mochi 1 的 VAE（变分自编码器，用于将视频压缩为低维潜空间表示）采用因果 3D 卷积结构，将视频映射为紧凑的潜空间 token 序列，官方 5.4 秒片段约对应 219K 个 token。文本侧使用 T5-XXL 编码器，最大支持 256 个 token 的提示词输入，超出部分会被截断，因此提示词应精炼、聚焦主体动作，而非堆砌描述。
支柱四：异步推理管线。 官方推理代码支持批量调度与异步生成，单卡在排队处理多个提示词时，GPU 利用率远高于逐个同步调用，实测吞吐量可提升数倍。异步管线还允许在等待生成时并行执行视频后处理（如插帧、字幕合成），整个生产流程的端到端延迟大幅下降。
生产部署与监控：从上线到运维
部署方式一：官方 CLI 批量脚本。 适合以离线批处理为核心的生产场景。将提示词列表写入 JSON 文件，循环调用 cli_v2 生成视频，配合 nohup 或 systemd 实现后台运行与自动重试。单张 80GB 显存 GPU 的典型吞吐量为每小时 15-20 条 5.4 秒片段（720p），团队可据此估算算力成本。如需更高吞吐，可在多台机器上并行运行多个推理实例，各自处理不同提示词分片，互不依赖。
部署方式二：ComfyUI 工作流集成。 ComfyUI 社区已提供 Mochi 1 的加载器与采样器节点，通过 ComfyUI-Manager 即可安装。24GB 显存显卡可通过分块采样跑通完整生成，配合工作流可视化界面，非算法背景的内容团队也能快速上手。此方案适合小规模内容生产与原型验证，但由于分块牺牲了部分全局一致性，输出质量略低于官方完整序列推理。
可观测性。 生产环境需关注五项指标：GPU 显存峰值（避免 OOM）、GPU 利用率（低于 70% 说明存在数据加载瓶颈）、单片段生成耗时（耗时突增提示权重或驱动问题）、失败率（解码阶段报错需检查 ffmpeg 与容器权限）、任务队列长度（超额说明需扩容）。日志建议按提示词 ID 打点，便于回溯每条素材的生成链路。GPU 温度与功耗需纳入基础监控，长时间满载推理对散热要求较高。
<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>坑 1：Windows 原生环境直接运行官方代码。 官方依赖与 CUDA 工具链针对 Linux 设计，在 Windows 下常出现编译失败或推理崩溃。正确做法是使用 WSL2 或 Linux Docker 容器，并确保 NVIDIA Container Toolkit 已配置。</li><li>坑 2：提示词写超过 256 个 token。 超出部分被 T5 编码器直接截断，用户以为模型「没听懂」，实际是输入根本没进入模型。写提示词时控制在 3-4 句英文以内，聚焦主体、动作、环境与镜头语言。</li><li>坑 3：权重下载不全导致推理报错。 使用 git clone 下载大文件容易静默中断，产生损坏的 safetensors 文件。务必用 huggingface-cli download 并核对文件大小，或启动前校验 SHA256 校验和。</li></ul>
| 维度 | Mochi 1 | CogVideoX | Open-Sora | Wan 2.1 |
|---|---|---|---|---|
| 定位 | 开源高性能文生视频基线 | 智谱开源视频生成模型 | 开源 Sora 复现研究项目 | 阿里开源视频生成系列 |
| 架构规模 | AsymmDiT 10B | 3D-VAE + DiT 5B | STDiT 1.3B | 14B DiT 系列 |
| 输出规格 | 720p / 30fps / 5.4s | 720p / 8fps / 6s | 720p / 约 2-3s | 720p / 5s（可扩展） |
| 推理硬件 | 官方 77GB+，分块可 24GB | 20-60GB | 24GB 可跑 | 40-80GB |
| 文本编码 | T5-XXL | T5-XXL | CLIP + T5 | T5 系列 |
| 生态集成 | ComfyUI 原生支持 | ComfyUI、Hugging Face | 自有训练仓库、ComfyUI | ComfyUI、官方推理仓库 |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| 适合谁 | 追求质量与控制力的工程团队 | 中文生态、风格化内容团队 | 研究与教学场景 | 阿里云生态规模化部署 |
选型建议：追求单片段质量与运动连贯性，优先选 Mochi 1，但其显存门槛较高。若团队只有 24GB 级别显卡且需要快速出片，CogVideoX-5B 的部署成本更低、中文提示词支持更好。Open-Sora 适合想深入训练细节的研究团队，Wan 2.1 则更适合阿里云基础设施上需要长时长扩展的规模化场景。
版本迭代
Mochi 1 的版本演进聚焦于「从可用到好用」：2024 年 10 月发布的 Preview 版本确立了 Apache 2.0 开源协议与 AsymmDiT 基础架构，11 月发布的 HD 版本在生成质量上做了整体升级。截至 2025 年 6 月，Mochi 1 HD 仍是 Genmo 开源权重线的最终正式版，官方产品重心已转向更新的模型系列。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| Mochi 1 Preview | 2024-10 | 首版开源权重与推理代码 | 确立 10B AsymmDiT 架构、Apache 2.0 协议、720p/30fps/5.4s 输出规格 |
| Mochi 1 HD | 2024-11 | 生成质量全面升级 | 视频清晰度与物体细节显著提升，在 genmo.ai 网页端上线并支持异步推理 |
Mochi 1 未公开 VBench 等第三方评测分数，社区评测主要以与 CogVideoX、Open-Sora 的对比为主，结论集中在运动连贯性占优、风格多样性稍弱。选型时建议将其视为开源视频生成的质量基线，而非最终产品——实际落地时往往需要配合超分、插帧等后处理链路。截至 2025 年 6 月，Genmo 已不再更新 Mochi 1 权重（截至训练数据，可能已有更新版本）。
AI 应用场景
广告素材批量化生成
阶段：AIGC 视频生产 / 内容工业化
解决的问题：传统广告素材拍摄成本高、排期长，创意团队难以快速验证多个脚本方向。Mochi 1 可将「提示词 → 视频素材」的链路压缩到分钟级，且 Apache 2.0 协议允许商业使用，不存在版权合规风险。
具体案例：某品牌营销团队将 20 条产品卖点脚本转为英文提示词，在 4 张 A100 GPU 上离线批量渲染，半天内产出 60 条 5 秒短视频素材，由 2 名设计师筛选出 12 条投放。相比外包拍摄，素材生产成本下降约 80%，从脚本到成片周期从 1-2 周压缩到 2 天。
影视分镜预可视化
阶段：影视前期创作 / 概念验证
解决的问题：导演与美术团队在正式拍摄前需要低成本验证镜头运动、光线氛围与场景调度。Mochi 1 支持 720p 分辨率、30fps 帧率，生成的动态分镜可直接用于团队评审与投资人演示。
具体案例：某微短剧团队用 Mochi 1 为 40 个关键场景生成动态分镜，每个场景用 2-3 条提示词对比不同机位与光线方案，分镜制作成本从传统手绘的约 3 万元降至 5000 元以内，前期沟通效率提升 3 倍，拍摄阶段返工率明显下降。
游戏动画概念原型生成
阶段：游戏资产预研 / 动态效果验证
解决的问题：游戏美术团队在制作正式动画资产前，需要快速验证角色动作、技能特效与场景互动的可行性。Mochi 1 的文本到视频能力可直接将策划描述转为动态原型，避免在 3D 管线中反复返工。
具体案例：某独立游戏工作室使用 Mochi 1 为 15 个技能设计生成动作原型视频，策划与美术基于原型统一预期后，再交给 3D 动画师制作最终资源，单个技能的初版制作时间从 3 天缩短到 1 天，整体动画外包预算节省约 30%。
常见误区
误区Mochi 1 既然能生成 5.4 秒视频，那我把提示词写长一点，或者多跑几次拼接起来，就能得到几分钟的连贯长视频。
正解Mochi 1 的单次生成时长固定为 5.4 秒，30fps 对应 162 帧，模型本身不具备长视频时序建模能力——训练数据的时长上限决定了它无法理解超过这一长度的运动逻辑。拼接多个片段只能得到独立场景的剪辑，画面主体、光线和运动方向不会天然保持一致。如需长视频，必须在生产管线上叠加关键帧衔接、风格锁定或视频插值等外部方案。
为何常见：Sora 等商业模型展示了长视频能力，用户容易默认同一个赛道的开源模型也具备类似能力，而忽略了训练数据与算力投入的巨大差距。
误区社区教程说 4090 能跑 Mochi 1，那我的 4090 24GB 应该也能像官方演示一样生成高质量 720p 视频。
正解官方完整序列推理的显存需求约为 77GB，24GB 显卡能跑通的前提是 ComfyUI 的分块采样方案——将 162 帧拆成多个时间窗口分别去噪，牺牲了全局时序一致性，且推理速度比完整序列慢 3-5 倍。4090 生成一条 5.4 秒视频通常需要 30 分钟以上，而 H100 完整推理只需约 3 分钟。24GB 适合原型验证，不适合生产级批量生成。
为何常见：社区展示的「4090 可跑」截图只说明了可行性，未说明分块带来的质量损失与耗时差异，用户容易把「能跑」等同于「能高效生产」。
误区Apache 2.0 就是完全免费，我可以把 Mochi 1 集成进自己的产品，不需要保留任何声明。
正解Apache 2.0 允许商业使用、修改和再分发，但有明确义务：必须保留原作者的版权声明、NOTICE 文件与许可文本；如果修改了代码，需在修改文件中标注变更说明；不能使用 Genmo 的名称或 Logo 为衍生产品背书。商用前建议由法务审查并保留完整的许可文件副本。
为何常见：国内团队对开源协议的理解普遍停留在「免费」层面，容易忽略协议附带的条件条款，在商业产品中埋下合规隐患。
误区我把完整的画面描述、镜头运动、光线方向、情绪氛围都写进提示词，模型应该能完美按指令生成。
正解Mochi 1 文本编码器 T5-XXL 的最大输入为 256 个 token，超长提示词会被直接截断，后半部分指令完全失效。更关键的是，扩散模型对指令性描述（如「镜头缓慢推进」）的遵循能力有限，往往只响应主体与动作类关键词。实测有效的策略是 3-4 句英文短句，聚焦主体及其动作、环境背景、整体风格三类信息。
为何常见：商业模型（如 Runway Gen-3）对长指令的遵循能力较强，用户把这种使用习惯迁移到开源模型上，忽略了文本编码器的 token 上限与模型训练目标差异。
误区把采样步数从 50 降到 10，生成速度快 5 倍，画面应该只是稍微模糊一点。
正解扩散模型的步数与质量不是线性关系。步数过低（如低于 20 步）时，去噪过程来不及收敛，会出现明显的画面残影、物体变形和闪烁。Mochi 1 官方默认 50 步，社区实践显示 30 步左右是质量与速度的平衡点，低于 20 步的画面基本不可用。如果想加速，优先考虑减少异步批处理间隔或升级 GPU，而非激进降低步数。
为何常见：图像生成模型的「步数换速度」经验被直接迁移到视频生成，但视频扩散对时序一致性的要求远高于单帧图像，收敛不足的缺陷会被时序放大。
面试题
Q1. Mochi 1 的开源许可证是以下哪一个？
- A.Apache 2.0← 正确答案
- B.MIT
- C.CC-BY-NC
- D.GPL-3.0
答案：A。Mochi 1 的代码与权重均以 Apache 2.0 协议发布，允许商业使用、修改与再分发。MIT 与 GPL 的条款与 Apache 2.0 不同，MIT 不要求保留 NOTICE 文件，GPL 要求衍生作品同样开源。CC-BY-NC 是非商业许可，与 Mochi 1 的属性不符。
Q2. Mochi 1 单次推理生成的视频规格是？
- A.720p / 30fps / 5.4 秒← 正确答案
- B.1080p / 60fps / 10 秒
- C.480p / 24fps / 15 秒
- D.4K / 30fps / 3 秒
答案：A。Mochi 1 的官方输出规格固定为 720p 分辨率、30fps 帧率、5.4 秒时长，对应 162 帧画面。这是训练数据的分布上限，无法通过提示词或推理参数突破。其余选项的规格与官方公布数据不符。
Q3. 官方完整序列推理所需的显存门槛约为？
- A.24GB
- B.48GB
- C.77GB← 正确答案
- D.160GB
答案：C。官方文档与发布说明明确，完整序列推理（一次处理全部 162 帧）需要约 77GB-99GB 显存，对应 H100 或 A100 80GB 级别显卡。24GB 是社区分块方案的显存需求，48GB 不足以覆盖全部中间激活值，160GB 超出了实际需求规模。
Q4. Mochi 1 使用的架构名称是？
- A.U-Net
- B.Asymmetric Diffusion Transformer← 正确答案
- C.Mamba
- D.GAN
答案：B。Mochi 1 采用 Asymmetric Diffusion Transformer（简写 AsymmDiT），核心特点是非对称处理文本与视频 token。U-Net 是早期扩散模型的常用骨架（如 Stable Diffusion 1.x），Mamba 与 GAN 均不属于 Mochi 1 的技术栈。
Q5. Mochi 1 的文本编码器采用哪个模型？
- A.CLIP
- B.T5-XXL← 正确答案
- C.BERT
- D.GPT-2
答案：B。Mochi 1 使用冻结的 T5-XXL 编码器处理文本提示，最大输入 256 个 token。CLIP 是图像与文本对齐编码器，主要用于图像生成模型（如 Stable Diffusion），BERT 与 GPT-2 的语义表征能力均不如 T5 适合视频生成任务。
Q6. 在 ComfyUI 中以 24GB 显存运行 Mochi 1 的原理是？
- A.降低模型精度
- B.分块采样← 正确答案
- C.使用 CPU 推理
- D.压缩视频分辨率
答案：B。社区方案将 162 帧的完整序列拆分为多个时间窗口，逐块执行去噪推理，峰值显存大幅下降。代价是全局时序一致性受损且耗时增加。降低模型精度与压缩分辨率是辅助手段，CPU 推理因速度过慢不具备实用价值。
Q7. 关于 AsymmDiT 的「非对称」，以下说法正确的是？
- A.文本 token 使用冻结的 T5 编码器处理← 正确答案
- B.视频 token 经过完整的扩散 Transformer 计算← 正确答案
- C.文本与视频使用完全相同的权重参数
- D.文本 token 仅通过轻量映射层与视频特征交互← 正确答案
答案：ABD。非对称性体现在文本与视频 token 的计算路径不同：文本侧编码后只做轻量映射，视频侧执行完整 Transformer 去噪。选项 C 错误，若权重完全相同则架构是对称的，实际二者是解耦的双流设计。
Q8. Mochi 1 官方支持的推理环境是？
- A.Windows 原生 PowerShell
- B.Linux + NVIDIA CUDA← 正确答案
- C.macOS Metal
- D.Android
答案：B。官方代码基于 Linux 与 CUDA 工具链开发，Windows 用户需要通过 WSL2 或 Docker 容器运行。macOS Metal 无法运行依赖 CUDA 的 PyTorch 算子，Android 平台不存在官方支持。
Q9. Mochi 1 官方生成流程包含哪些核心组件？
- A.时空 VAE← 正确答案
- B.AsymmDiT 扩散模型← 正确答案
- C.前向轨迹重建指导← 正确答案
- D.CLIP 图像编码器
答案：ABC。完整流程为文本经 T5-XXL 编码 → VAE 将视频压缩为潜空间 token → AsymmDiT 执行扩散去噪 → VAE 解码输出画面。前向轨迹重建指导是训练阶段引入的关键方法。CLIP 图像编码器不属于 Mochi 1 流程，它用于图文对齐任务。
Q10. 在官方推理中，若日志提示 Cannot find checkpoint，最可能的原因是？
- A.提示词 token 超限
- B.权重文件下载不完整← 正确答案
- C.GPU 显存不足
- D.采样步数过低
答案：B。Cannot find checkpoint 表示 --model_dir 指向的目录中缺少模型权重文件或文件损坏，通常是使用 git clone 下载大文件时静默中断导致 safetensors 文件不完整。token 超限对应截断提示，显存不足报 CUDA out of memory，步数过低不会产生此报错。修复方式是重新用 huggingface-cli 完整下载并核对文件大小。
参考来源
- webpageMochi 官方 GitHub 仓库官方推理代码、安装说明与已知问题列表
- webpageGenmo 官网网页端在线体验与产品信息