一台 128GB 统一内存的端侧设备，怎么跑通视频生成 AI 智能体 全链路

    这次我们在端侧设备上把AI视频生成模型 MiniMax-H3 从零搭到出片，包括 TTS 配音、关键帧续写、Skill 集成，整条链路打通。

    这篇文章记录了我们这几天来踩过的各种坑、做的各种选择，以及为什么我们认为“短视频生成的 Agent 化”这件事，真的到了可以认真做的节点了。

让 AI 帮我们生成一段视频

    我们测试的场景是这样的：用户对 AI 智能体说「帮我生成一个奥特曼大战哆啦A梦的视频」，AI 自己去进行视频生成、等结果、把生成好的视频文件丢回去。

▲ 【本节配套演示视频见公众号原文】

    这件事放之前肯定就是调用seedance2.0的API来生成，但是面对高额的费用很多人只能望而兴叹。而随着H3的发布，我们自己做了一遍，真的跑通了。

下面这张图是seedance2.0的价格：

    我们目前部署使用的是MiniMax-H3（NVFP4 权重），跑在一台端侧的设备上（GB10 芯片，128GB 统一内存）。

    想表达的并不是我们搞定了多酷，而是这件事为什么对做应用、做 Agent 的来讲是非常有意义的。

▲ 【本节配套演示视频见公众号原文】

硬件背景

    我们的端侧设备是一台DGX Spark，128GB 统一内存，这个设备很早之前，我们就介绍过。DGX Spark双机实测：当200GB IB线串联起两台"桌面超算"，没有传统意义上的「显存」，nvidia-smi 直接给你一句 FB Memory Total: N/A，Addressing Mode: ATS。

这意味着常规的 GPU 部署思路全失效：

• device_map='auto'
   这种依赖显存检测的方案根本用不了
• 模型加载到 64% 的时候，进程直接被 OOM Killer 干掉
• BitsAndBytes 这种在线量化库，在 aarch64 上兼容性拉胯

MiniMax-H3 BF16 全量权重 135GB，这台「显卡」只有 128GB 共享内存，从数字上看就一个字：装不下。

但如果换设备就失去了我们端侧验证的目的，所以果断换了量化版本。

第一次尝试：BF16 + diffusers

    第一次尝试照着社区教程走：diffusers 的 MiniMaxH3ModularPipeline 加载 BF16 权重，配合 BitsAndBytes 在线 NF4 量化。

    结果：加载到 64% 时系统 OOM，进程被杀。

    原因很简单，也很容易踩坑：在线量化需要先加载 BF16 权重到内存再转换，峰值内存远超 128GB。

    diffusers 的模型格式和 ModelScope 上的权重格式也不兼容，这条路走到一半就走不通了。

第二次尝试：DiffSynth-Studio + 预量化 NF4 权重

    换思路，不在线量化，直接用预量化好的 NVFP4 权重。

    DiffSynth-Studio 是 MiniMax-H3 官方推荐的推理框架，ModelScope 上有 NF4 量化版本（DiffSynth-Studio/MiniMax-H3-NF4），总大小约 34GB，大约是 BF16 的 135GB 的 1/4。

关键配置长这样：

```pythonvram_config = { "offload_dtype": "disk", "offload_device": "disk", "onload_dtype": torch.bfloat16, "onload_device": "cpu", "preparing_dtype": torch.bfloat16, "preparing_device": "cuda", "computation_dtype": torch.bfloat16, "computation_device": "cuda", } ```

    磁盘卸载是这个方案的核心：模型主体存在磁盘上，推理时按需加载到 CPU 再搬到 GPU，用完即释放。832×480 分辨率、56 帧、20 步推理，大约 3 分钟出片。

    数据上看起来不算快，但把 135GB 模型塞进 128GB 机器里跑通，本身就是验证一件事情的可行性：硬件不再是绝对瓶颈，方案选择才是。

踩坑记录

    整个部署过程里我们踩了四个坑，都记录了下来分享给愿意自己折腾的人省点时间。

1. flash-attn 在 GB10 上崩溃

GB10 是 ARM 架构，flash-attn-4 beta 版本没有 flash_attn_func 函数。虽然 FLASH_ATTN_2_AVAILABLE = True，但实际调用直接崩。

解决：设置环境变量 DIFFSYNTH_ATTENTION_IMPLEMENTATION=torch，强制使用 PyTorch SDPA 后端。

2. ModelConfig 参数陷阱

ModelConfig(model_id="...") 会触发重新下载到缓存目录，ModelConfig(path="/full/local/path.safetensors") 才是直接使用本地权重。参数名用错，几十 GB 又白下了。

3. fps 参数位置

MiniMaxH3Pipeline.call() 没有 fps 参数，fps 只在 write_video_audio() 写文件时使用。传错了直接 TypeError。

4. 帧数约束

num_frames % 17 == 5 是硬性约束，不满足会自动取整。常用值是 56 帧（≈1.9s@30fps）、122 帧（≈4.1s）、223 帧（≈7.4s）、365 帧（≈12.2s）。

四个坑都不大，但任何一个都让我们卡了半天。这是开源视频模型的现实：技术能跑通，但工程化细节还是要靠自己磨。

部署架构：双服务 + 一套 Skill

最终我们把它搭成双服务架构，视频生成和 TTS 配音在同一台服务器上：

• 视频服务（:30010）：FastAPI + DiffSynth-Studio，支持 FL2VA / Ref2VA / 关键帧续写 / 图片上传
• TTS 服务（:7860）：Qwen3-TTS，支持 voice_clone / voice_design / 自定义音色
• NF4 量化权重：约 34GB 总计（fl2va + text_encoder + video_vae + audio_vae + ref2va）

API 功能

生成流程

核心流程：用户输入 → 提示词优化 → 视频生成（同时可选 TTS 配音）→ ffmpeg 合并 → 如需长视频则分段续写拼接。

长视频方案：分段生成 + 关键帧续写

模型单次最长约 12 秒（365 帧 @30fps）。

要生成 60 秒视频：

1. 分段生成：60 秒拆成 5 段 × 12 秒 

2. 关键帧续写：第 1 段纯文本生成，后续段用前一段最后一帧作为 keyframe 

3. ffmpeg 拼接：所有段生成后 concat 合并 

4. 可选配音：用 Qwen3-TTS 生成语音，ffmpeg 混入视频

Skill 集成

最后一步是写一个Skill，让 AI 智能体通过自然语言就能调用视频生成：

`` 用户：帮我生成一个奥特曼大战哆啦A梦的视频 AI：调用 MiniMax-H3 API → 生成视频 → 返回链接 ``

Skill 目录结构：

`` minimax-video-generation/  ├── scripts/ │    ├── generate.py         # 基础视频生成 │    ├── continue.py         # 关键帧续写 │    ├── ref_generate.py     # Ref2VA 参考图生成 │    ├── video_with_tts.py   # 视频+TTS配音 │    ├── long_video.py       # 长视频分段+拼接 │    └── health.py           # 服务健康检查  └── references/    ├── api.md                # API 完整参考    ├── prompts.md            # 提示词工程    └── tts.md                # TTS 集成参考 ``

    写完这个 Skill 的那一刻，「视频生成的 Agent 化」这件事才真正闭环。模型不再是一个孤立的 API，而是一个能被 AI 调起来、组合起来、完成任务的工具。

性能数据

芯知解读：为什么这是 Agent 化的拐点

    做完这次部署，感受最深的一点是：视频生成从「能跑」到「能放进 Agent」，差的不是技术突破，而是工程闭环。

这个判断不是凭空来的。回头看视频生成这三年的演化，节奏很清楚：

    2024 年的视频模型，能跑但没人用。跑一次成本太高、时长太短、没法控制、没法拼接。Runway Gen-3 的 API 一次生成 4 秒要 50 美分，国内厂商的开放接口几乎都是 demo 性质。这一年里你几乎听不到任何一家 AI 产品把「视频生成」当作核心功能上线。

    2025 年的视频模型，能跑也能调了。通过 API 暴露能力，但调用方依然要懂模型参数、显存管理、ffmpeg 拼接。可灵、Pika、seedance 都在这一年商业化，真正接入生产链路的产品极少。Sora 2 上线后最大的反馈不是「画面好」，而是「不会用」。这是个标志，技术能力已经溢出了，但工程接口没有跟上。

    今年我们这次搭的这条链路，视频生成第一次变成了一个普通工具。AI 助手不用懂模型细节，只需要知道「我想生成一段视频」这个意图，剩下的事情模型 + 工程管线自己消化。

这是 Agent 化的信号：技术能力下沉成基础设施，对调用者透明。

具体到行业层面，三个判断。

    如果你的产品里需要视频生成能力，现在已经不是必须自己训练或微调模型了。把现成的开源模型 + 工程管线包成 API，再套一层 Skill，就是一个完整产品。门槛从「懂模型」降到「懂集成」。

举几个我们看到的具体例子：

• HeyGen 在 2025 年 Q3 把视频生成 API 接入自己的 SaaS 后，ARR 在两个季度内翻了一倍。它的视频质量不算比 Runway 好，但把「数字人视频生成」做成了一个普通 SaaS 功能，客户不需要懂模型，只需要传一段文案和一张头像照片。
• Captions 在 2026 年初做的短视频自动剪辑产品，把视频生成、剪辑、TTS 全部封装成一个 Skill，集成进剪映海外版 CapCut。开发者用三行代码就能调用，他们自己不做模型，只做工程。
• 国内某头部电商的内容平台（具体名字就不点了），把开源视频模型 + 内部商品库 + 投放模板打包成一个内部 Skill，让运营直接通过自然语言生成投放视频，人工剪辑环节砍掉了 60%。这家公司自己没有算法团队，靠的是工程集成能力。

    对开发者：关注重点从「怎么把模型跑起来」转到「怎么让模型被调用起来」。模型工程化、API 设计、Agent 框架集成，是接下来一年的主要工作。

几个值得重点投入的方向：

• 量化方案适配：FP16 / BF16 / NF4 / INT8 各自的适用场景、显存/质量 trade-off、跨硬件兼容性（aarch64、Hopper、Blackwell），这些都是工程刚需
• 磁盘卸载与分层加载：模型大小超过硬件容量是常态，能不能优雅地按需加载，决定能不能在生产环境跑
• 关键帧续写与拼接：单次生成时长有限（MiniMax-H3 是 12 秒），分段生成 + 续写 + 拼接是绕不开的工程模式
• Skill 模板化：让 AI 助手能「读懂」视频生成 API，需要的是结构化的工具描述，不是 API 文档

    对模型厂商：开源模型的「最后一公里」不是预训练，是配套的工程化能力。提供量化版本、推理框架、Skill 模板、踩坑文档，比单纯刷 benchmark 更能赢得开发者。

    在视频生成领域，benchmark 的领先者未必是商业化的赢家。Stable Video Diffusion 在学术 benchmark 上长期领先，商业落地远不如可灵和 Veo。原因是可灵和 Veo 从一开始就按「产品 API」的思路设计模型接口，不是按「学术 demo」的思路。可灵的设计里有大量的工程冗余，这些都是为了在生产环境稳定运行付出的代价。

    我们自己在做的事情，就是把 MiniMax-H3 的工程闭环做完整。下一个版本会开放更完整的 Skill 模板和 API 文档，希望能让同行少走一些我们走过的弯路。

    最后说一句有点主观的判断：2026 下半年到 2027 上半年，会是「视频生成 Skill」的爆发期。原因很简单，视频生成的最后一公里已经被打通，剩下的就是谁能更快地把它包装成工具。模型本身会继续演进，但工程化能力会成为新的护城河。这一波机会窗口，对工程团队友好，对纯算法团队未必友好。

别上头

    我们做下来，同样想给大家提个醒。都是我们在某个时间点差点把自己骗进去的。

别迷信「模型越大越好」

    2024 年那波视频模型军备竞赛里，参数和算力被当成主要竞争维度。结果呢？商业落地最好的反而是参数不算大、但工程接口做得扎实的模型。视频生成和语言模型不一样，计算成本主要在推理时延和显存占用，不在模型容量。一个 30GB 的工程化做得好的模型，往往比 100GB 的学术领先模型更适合做产品。

    我们这次部署 MiniMax-H3-34GB 的 NF4 版本在工程上比 135GB 的 BF16 实用得多。不是说 BF16 没意义，但在生产环境，可部署性 > benchmark 分数。

别以为「分段拼接」就能任意拉长视频

关键帧续写 + ffmpeg 拼接这件事，听起来简单，做起来一堆问题：

• 分段之间的人物形象、构图、色调、节奏很难保持一致。拼接 5 段以上，肉眼能看出明显的断裂感
• 长视频的语义连贯性是另一个难题。人物动作、场景逻辑、台词连续性，模型没有跨段记忆
• 拼接引入了额外的时间错位风险，每多一段，错位概率指数级增长

    我们做过实验，超过 4 分钟的视频，纯靠分段拼接几乎一定有可见瑕疵。要真正做长视频，靠的不是拼接技巧，而是模型本身的长上下文能力。这一块目前还在 12 秒单段，但我们下一个目标就是直接生成分钟级。

别把「套壳 API」当产品

    这是我们见过最多、最普遍的误区，以为接一个视频生成 API 就是一个产品了，结果就是：同质化严重、商业模式脆弱、用户没有任何切换成本。

    真正的产品价值不在「能不能生成」，而在「生成能不能解决具体场景的问题」。给电商做投放视频？给教育做课程演示？给短视频博主做选题模板？给企业做内训视频？场景定义权才是护城河，技术调用能力不是。

    比如有个朋友的团队做了个「全场景 AI 视频生成」app，接了 5 个模型的 API，用户量起得很快，6 个月后留存腰斩。因为用户发现别家也能做，没差异点。后来他们团队就直接转向「电商投放视频自动化」，聚焦 5 个具体场景，反而活下来了。

    所以我们的判断是：视频生成的「工具化」阶段已经结束，「场景化」阶段刚开始。能定义清楚具体场景、打通具体工作流的团队，才有真正的护城河。

芯知见解

最后列几个我们这次部署里实实在在的认知转变，给大家做参考。

关于硬件选型

    原本我们以为视频生成对显存要求是绝对瓶颈，跑通之后才发现，显存不是问题，方案设计才是问题。

    一台 128GB 统一内存的"小"机器，配上磁盘卸载 + 预量化权重 + 关键帧续写，能跑通 135GB 模型。这件事让我们重新评估了硬件选型的逻辑，不必追求最顶配硬件，要把硬件约束变成工程创新。

关于开源 vs 闭源

    原本我们以为闭源商业模型的工程化做得更好，跑通之后发现，开源模型的工程化能力正在快速追平。

    DiffSynth-Studio 这样的开源框架，提供了和商业模型几乎一样稳定的推理能力，关键是免费、可改造、可集成。

    这对于做 Agent 集成的团队是好事，不再被单一供应商绑定。

关于 Skill 的价值

    写完 Skill 的那一刻，我们获得了一个挺关键的转变。Skill 不是 API 文档的换皮，而是 AI 助手能"读懂"的结构化工具描述。一个好的 Skill 应该包含：什么时候用、怎么用、参数含义、错误处理、和其它 Skill 的组合方式。这件事本质上是「工具设计」而不是「文档写作」。

关于"工程化最后一公里"

    开源视频模型从"能跑"到"能用"，中间差的不是一点点。光是踩过的那些坑（flash-attn 兼容性、ModelConfig 参数、帧数约束、磁盘卸载策略），随便哪个都能让一个新团队卡上一两周。开源模型生态的成熟度，不能只看模型本身，要看踩坑文档、Skill 模板、社区问答这些"非模型"资产。

    这些认知不算新鲜，但从一个团队的实战里说出来，比从 paper 里读出来实在。

    这是我们这次最大的收获：模型能力下沉成基础设施的过程里，工程团队是最重要的角色。