YumCut 开源 AI 短视频生成器：自托管部署条件与成本账怎么算

YumCut 是一套开源的 AI 短视频生成器，输入一句创意或一段现成脚本，它会依次完成写稿、配音、字幕对齐和渲染，直接输出 9:16 的竖屏成片。项目有两种用法：直接用官方托管版 yumcut.com，或者把源码拉下来部署在自己的服务器上，仓库地址是 GitHub 上的 IgorShadurin/app.yumcut.com。

这篇文章的信息以官方仓库文档和官网页面为准核实过一遍。重点放在三件事上：它实际能做到什么程度、自托管要付出多少配置代价、以及这笔账落到国内团队手里怎么算。

从一句创意到成片的流水线

YumCut 的生成流水线：创意到成片一条线走完

官方 README 对这套流程的表述是，用户提供想法，系统负责脚本、配音、画面、字幕和最终剪辑，产出可以直接发布的 9:16 视频。落到具体功能上，官网列出的能力包括模板库（Reddit 话题、创始人日记、产品发布等类型自带动效设计）、字幕与动态文字跟配音时间轴自动对齐、把一段 30 分钟录音批量拆成多条短片，以及把同一个提示词翻译成多语言版本。

角色一致性这一项需要留意。官网 FAQ 里对”能否在多条故事中保持同一个角色”的回答是 Upgrade to lock in your hero，也就是需要升级套餐才能锁定形象、声音和动作的连贯性，并非基础功能。

更要紧的限制在语言上。官网 FAQ 明确列出目前可用的脚本语言为俄语、英语、德语、西班牙语、葡萄牙语、法语和意大利语，中文不在其中。做中文内容的团队用托管版会卡在第一步，只有自部署时替换掉文案模型与语音合成链路才有中文可能，而这部分官方没有提供现成配置。

图：YumCut 官网首页，首屏排列的是各语言模板生成的样片

托管版的实际使用条件

注册这一关先要过。查询 app.yumcut.com/api/auth/providers 返回的登录方式，目前只有 Google 和 Apple 两种 OAuth，没有邮箱密码注册的入口。国内用户想用托管版，需要先有可用的 Google 或 Apple 账号。站点整体走 Cloudflare 回源，打开速度取决于各自的网络环境。

移动端方面，仓库里已经有完整的 iOS 登录接口实现（/api/mobile/auth/google 与 /api/mobile/auth/apple），官网页脚也挂着 App Store 下载入口。运营主体在页脚标注为 WOWCODED THINGS LTD，注册地在英国。

自托管要准备的东西比想象中多

按官方部署手册（docs/server.md）整理的自托管服务结构

先说一个容易被低估的点：自托管不是克隆一个仓库就能跑起来。官方的服务器安装手册在部署环节要拉取六个仓库，主应用、渲染守护进程、静态存储、短视频工具集、幻灯片模块和字幕视频生成器各占一个目录。

git clone [email protected]:IgorShadurin/app.yumcut.com.git /var/www/app.yumcut.com
git clone [email protected]:IgorShadurin/app.yumcut.com.git /var/www/yumcut-daemon
git clone https://github.com/IgorShadurin/yumcut-storage.git /var/www/static.yumcut.com
git clone [email protected]:IgorShadurin/yumcut-shorts-tools.git /var/www/yumcut-shorts-tools
git clone [email protected]:IgorShadurin/video-slides.git /var/www/video-slides
git clone [email protected]:IgorShadurin/yumcut-captions-video-maker.git /var/www/yumcut-captions-video-maker

其中四个是 SSH 地址，意味着部署机需要先配好有权限的 GitHub 密钥。手册里给出的环境基线是 Ubuntu 22.04 或 24.04、Node 24（用 nvm 安装）、pm2 托管进程、Apache 做反向代理，数据库是 MySQL 8 以上，建库时要用 utf8mb4 以保证 emoji 不出问题。

mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS \`yumcut\` CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"
mysql -uroot -p -e "CREATE USER 'yumcut'@'%' IDENTIFIED BY 'STRONG_PASSWORD'; GRANT ALL PRIVILEGES ON \`yumcut\`.* TO 'yumcut'@'%'; FLUSH PRIVILEGES;"

FFmpeg 的版本要求是硬性的。手册写明渲染守护进程启动时会校验 FFmpeg 版本，低于 7.1.1 直接退出，官方给的解决办法是加 Ubuntu Handbook 的 PPA（ppa:ubuntuhandbook1/ffmpeg7）装对应构建。Ubuntu 22.04 仓库自带的版本达不到这个线，这一步无法省略。

数据库结构用 Prisma 迁移初始化，跑通之后再启进程：

npm run prisma:migrate:deploy && npm run prisma:generate

cd /var/www/static.yumcut.com
npm ci && npm run build
pm2 start "npm run start -- -p 3333" --name static.yumcut.com

cd /var/www/app.yumcut.com
npm ci && npm run build
pm2 start "npm run start -- -p 3111" --name app.yumcut.com

cd /var/www/yumcut-daemon
npm ci && npm run build
pm2 start "npm run daemon" --name yumcut-daemon

手册在安全上的要求也写得比较细：pm2 一律以非 root 的 deploy 用户运行，数据库只监听本机，防火墙只放 22、80、443 和一个 4404 端口，所有 Node 服务都藏在 Apache 后面，.env 权限设成 640。这套做法对一个会长期跑在公网上、还持有各家模型 API 密钥的服务来说是必要的。

这里要更正流传中的两条说法。ahhhhfs 的介绍文提到自部署”推荐配备 GPU，NVIDIA 加速效果最佳”，以及”字幕对齐高度依赖 Whisper 链路”。官方的服务器安装手册和技术文档里并没有出现 GPU、NVIDIA 或 Whisper 的字样，整套部署说明是围绕 Ubuntu 上的 Node、MySQL 和 FFmpeg 展开的。这两条更像是经验推断，规划硬件时建议按自己的实际渲染并发量实测，不要直接照搬。

成本账：省下的是订阅费，付出去的是 API 费

开源版本的成本结构是自带密钥（BYOK）模式，模型调用费用由部署方自己承担。真实开销分三块：渲染算力的 CPU 时长、脚本与配音的模型调用、以及成片存储和带宽。团队想把单条成本算清楚，最直接的办法是记录每条视频的渲染耗时和每条脚本、配音消耗的 token 或秒数，两项相加就是单条上限。

托管版的定价可以从仓库的配置模板反推。example.env 里注明周订阅 2.99 美元发放 75 个 token、月订阅 19.99 美元发放 750 个 token、月度 Pro 34.99 美元发放 1500 个 token；技术文档里还列出同价位的一次性充值档。按 1 美元约合 7.1 元人民币粗算，三档分别约合 21 元、142 元和 248 元。这个价位在 AI 视频工具里属于偏低的一档，对小团队来说，先用托管版跑通流程再考虑自建，比一上来就搭六个服务划算。

README 里关于成本有一句表述需要单独说明：项目方称 YumCut 的视频生成成本可以比常见的闭源视频生成器低约十倍，同时注明这取决于具体的技术栈和供应商选择。README 中列为对比对象的是 Veo、Runway Gen 系列、Pika 付费档和 Luma Dream Machine 付费档。这个倍数是项目方自己的口径，实际差距要看你接哪家模型、生成什么长度和画质。

有一个细节对做预算的团队有用：官方的用户 API 里有一个 /project-cost 接口，可以在建项目之前先报价。批量生产前用它跑一遍估算，比事后对账更可控。

图：YumCut 的 GitHub 仓库页面，截图为访问时点状态

自动化接口与团队接入

仓库里带了一套 bearer key 鉴权的用户 API，设计目标就是让外部工具、后台任务和 AI Agent 直接驱动生产流程。用户在应用内自行创建 API 密钥，接口覆盖报价、建项目、轮询状态、停止任务、改设置、读取素材目录和取成片下载地址。实测 app.yumcut.com/api/user/v1/openapi.json 可以正常拉到完整 schema，交互式文档在 /api/user/v1/docs。

接口路径里能看出流程是带人工审核节点的：脚本有 script/request 和 script/approve，配音有 audios/request 与 audios/approve，画面还能单独 images/regenerate 或 images/replace。对要求把关的团队来说，这种分段确认的设计比一次性出片更实用，可以在脚本阶段就拦掉跑偏的内容，不必等渲染完成才发现问题。

项目状态变更还能接 Telegram 通知，配置 TELEGRAM_BOT_TOKEN 等三个变量之后，需要人工审批、报错或处理完成时机器人会主动推送。

许可条款需要先读清楚

这一项容易被”开源”两个字带过去。README 写明个人使用免费，但如果要替客户托管、出售访问权限，或者把它作为商业服务运营，需要另行购买商业许可，授权联系方式是作者邮箱。GitHub 仓库的协议标识显示为 Other，并非 OSI 认可的标准开源协议，实际约束以仓库内的 LICENSE 文件为准。打算拿它做对外服务的团队，这一步不能省。

素材版权是另一个要处理的问题。如果工作流会自动匹配背景素材和音乐，商用发布前应当把默认素材换成自有授权或明确可商用的素材库，并对版权、商标、肖像、品牌露出做一遍审核。自托管在这件事上的优势是素材来源可控、可追溯。

谁适合用，谁可以跳过

做英语、俄语或欧洲语种的无人出镜频道，又已经在按周批量产出短片，YumCut 的托管版是值得先试一轮的选择，月度档位的价格低于同类闭源工具。需要多客户隔离、素材可审计、或者想把生成环节接进自己后台系统的代理商和增长团队，才有必要承担六个服务的部署成本。

两类需求不建议在这里耗时间。一是把长视频切成短片的场景，YumCut 的主路线是从想法生成视频，虽然支持把长录音或长稿拆成多条模板化短片，但它不是长链接自动解析切片工具，这类需求找专门的切片产品更合适。二是纯中文内容生产，托管版不支持中文脚本，自部署改造中文链路需要自行集成语音合成与识别并调参，投入不小。类似的中文场景，站内此前介绍过的 Toonflow 开源 AI 短剧生成工具和 AI 短视频工厂 Short Video Factory 在中文支持上更省事；配音环节要本地化的话，Voice-Pro 开源 AI 配音工具可以补上这一段。