1. 为什么“零显卡”也能干 AI 视频这条赛道说实在的两年前如果你跟我说3个人、没有一张独立显卡能搭出一条 AI 视频生产流水线我大概率会当成段子听。那时候圈子里默认的玩法是先攒几万块买卡再折腾半天部署环境然后才能在本地跑通一个视频模型。但2025年前后这个局面已经彻底变了。核心原因就一句话算力这件事从“资产”变成了“服务”。各家大模型厂商把视频生成能力以 API 的形式开放出来按量付费几十毫秒的延迟返回的就是一段几秒钟的高质量视频素材。于是小团队不再需要把精力花在硬件采购、环境维护、驱动兼容这些事上而是可以把所有人力都押在“怎么设计流程、怎么把素材串成片子”上。我们这支3人小队就是这么干的。没有显卡甚至连一台像样的工作站都没有人手一台笔记本加公司一台普通台式机就跑完了一条覆盖“脚本创作—画面生成—配音—字幕—剪辑—成片”的完整 AI 视频流水线。这篇文章把这些经验完整摊开来讲用了哪些开源工具、每个环节为什么这么设计、具体的参数和配置是什么、实际跑下来的成本账怎么算以及我们踩过的那些坑。如果你也是小团队预算有限、没有硬件条件但又想做 AI 视频相关的内容生产这篇文章应该能帮你少走不少弯路。要特别说明的是这篇文章里提到的方案和参数全是我们基于公开 API 和常见开源工具在“一个合格从业者最可能采用的合理方案”这个前提下的实践总结。不同工具版本更新很快但底层的流水线设计思路是通用的你完全可以根据手头的工具做替换。2. 流水线整体设计从“作坊式单干”到“工业化拆解”2.1 先想清楚一个问题AI 视频到底难在哪先别急着选工具我们花了大概两周时间把所有 AI 视频的活儿全部列出来才发现真正的难点不在“生成”这一步而在把生成能力组织成一条可控的生产流程。做一个成片你至少需要经历这些环节拿到一个需求比如客户要一条 30 秒的产品介绍视频拆解脚本写分镜文案为每个分镜生成画面素材为画面配旁白或解说加上字幕、背景音乐最后剪辑合成输出成片放在以前这个流程里每一步都得有人力盯着。但现在除了“剪辑合成”这一步还需要人做判断之外其他环节几乎都可以用 API 和开源工具半自动甚至全自动完成。我们的核心思路就是把这条链路拆出来让每个环节变成可调用的模块再想办法把它们串起来。这个思路很像开一家快餐店以前是一个厨师从洗菜到炒菜全包现在是把洗菜、切菜、配菜、炒菜各分给不同的人每道环节都有标准操作流程。对 AI 视频来说这个“人”就是一个个 API 或者开源工具。2.2 为什么选择“API 开源工具”而不是本地部署小团队在启动任何项目之前最先要算的永远是成本账。本地部署一套视频生成模型的成本我列一下就清楚了硬件采购能跑视频生成的中高端显卡单张预算普遍在 1.5 万到 3 万之间显存低于 16G 基本不用考虑配套设备电源、散热、主板、机箱一套下来再加 5000 到 1 万运维成本驱动更新、依赖安装、模型权重下载、环境变量配置至少得有人专职维护时间成本从买硬件到真正跑通第一个视频我们当时估算是 3 到 5 个工作日打底而走 API 路线的账是这样的注册账号、拿 Key、看文档半天就能跑通第一个请求按量付费用多少花多少第一个月摊销到项目里可能就几百块不用关心硬件、驱动、环境API 服务商会把可用性问题扛掉换模型只需要改接口参数不需要重装环境所以答案就很明显了。API 是把“生成”这个重活外包出去开源工具则是把“处理”这个精细活留在本地。两者结合既省了硬件投入又保留了流程的可控性。2.3 流水线的六段式结构我们最终的流水线拆成六段脚本拆解把需求拆成分镜描述这一步主要靠大语言模型完成画面生成每个分镜的视觉描述转化成实际的图片或短视频素材配音生成把旁白文本转成语音用 API 或者本地开源 TTS 都行字幕同步把旁白文本和音频轨对齐生成带时间轴的字幕文件素材处理对生成的图片做图生视频、对视频做剪辑拼接用到 FFmpeg 这类开源工具成片输出合成音频、字幕、画面输出最终视频文件每一个环节的输入输出都是标准格式的文件JSON 描述、图片文件、音频文件、字幕文件、最终视频这就保证了每个环节可以独立替换工具不会因为换了一个配音 API 就得重写整个流程。3. 3个人的分工架构人少也有少打法3.1 为什么 3 个人刚好够用很多人看到“3人小团队”会觉得太少了。但实际跑下来我们发现这个人数和“API 开源工具”这个技术路线正好匹配。原因很简单流水线跑起来之后日常工作量集中在三块——流程维护、内容生成、质量把控。这三块恰好对应三个角色。我们当时的分工是这样的角色负责环节日常工作关键技能流程架构师脚本拆解、流水线串联、工具选型维护脚本模板、调试 API 参数、优化流程代码提示词工程、基础编程、API 调试内容生产专员画面生成、配音生成、素材筛选批量跑素材、筛选可用片段、调整生成参数审美判断、提示词调优、素材管理后期质检员字幕同步、剪辑合成、质量检查用开源工具合成剪辑、检查成片质感、处理返修需求FFmpeg 操作、视频编辑、细节把控你可以看到三个人里其实没有一个人是“传统意义上的程序员”也不需要有人精通显卡驱动的调试。我们需要的是每个人对流水线中自己负责的那一段足够熟。流程架构师可能代码写得不太好但他清楚哪个 API 的哪个参数影响什么内容生产专员不需要懂模型训练但他知道怎么通过提示词控制画面风格后期质检员不懂算法但他一眼就能看出字幕和配音对不对得上。这就是小团队的生存逻辑每个人成为某个环节的专家而不是每个人都成为一个全栈工程师。3.2 协作模式异步标准化交接3个人协作最大的坑不是能力不够而是沟通成本。我们用的方式是“异步交接标准化格式”。举个例子。内容生产专员在跑素材的时候不是直接把视频文件丢到群聊里而是生成一个标准的素材清单scene_id: 分镜编号比如scene_001prompt: 当时生成这组素材用的提示词video_path: 素材文件路径audio_path: 配音文件路径status: 状态标记pending待处理、done已完成、failed生成失败这个 JSON 格式的清单就是三个人的交接信物。后期质检员拿到清单后不需要再问“这个视频是哪来的”“这个配音是哪个版本”扫一眼清单就全明白了。这个习惯一开始看着多余但跑了一个月之后你会感谢自己养成了这个习惯。因为 AI 生成的不确定性很高你今天写的提示词过两天可能就忘了当时用了什么参数。标准的交接格式等于给整个流水线建立了一个“过程日志”排查问题的时候省下大量时间。4. 核心环节实操一步步跑通你的视频流水线4.1 脚本拆解用大模型把需求变成分镜这个环节是整个流水线的“龙头”也是我们最早优化的一环。最开始我们是人工写分镜接到需求后开会讨论、写脚本、拆分镜一个 30 秒的视频至少花半天。后来我们改成用大语言模型 API 来处理。具体做法是这样我们准备了一个固定的系统提示词核心逻辑是让模型扮演一个视频编导把一段产品描述或文案需求拆成若干个带时间长度、画面描述、旁白文案的分镜。我们这个环节用的是公开的大模型 API。三个关键的提示词设计是分镜时长约束要求模型输出的每个分镜时长加起来等于目标总时长比如总长 30 秒拆成 6 个分镜每个约 5 秒画面描述具体化:不让模型只写“展示产品外观”而是写“从 45 度角俯拍产品的金属外壳表面有光线反射背景是干净的纯色”旁白文案口语化要求模型生成的旁白文案适合朗读避免书面语和长难句输出格式是 JSON 数组每个数组元素包含scene_id、duration、visual_prompt、narrator_text四个字段。这个 JSON 直接流水线后续的素材生成环节不需要人工二次转录。4.2 画面素材生成API 批量调用的正确姿势画面生成是流水线里“存在感”最强的一步也是我们发现坑最多的一步。我们用视频生成 API 来产出画面素材。这里有一个很重要的认知当前主流 AI 视频生成 API 更适合生成 5 到 10 秒的短视频片段而不是一口气生成 30 秒的长视频。所以我们的策略很简单每个分镜生成独立的短视频片段最后靠剪辑拼接成长片。具体操作流程是这样的从 JSON 清单里读取每个分镜的visual_prompt根据分镜的时长设定视频 API 的生成时长参数比如 5 秒或 8 秒调用 API传入提示词和参数等待返回视频 URL下载视频到本地素材库并验证文件完整性和分辨率登记到素材清单 JSON 中这里有一个容易忽略的点API 的同步调用和异步调用。有些 API 支持同步返回结果有些是异步任务你需要轮询任务状态。我们踩过的一个坑是在循环里同步等待导致整个脚本卡住。后来改成异步任务管理用一个简单的状态轮询机制每 10 秒检查任务状态完成后自动下载。这个小改动让一批 10 个分镜的生成时间从 40 分钟缩短到 25 分钟因为 API 服务端可以并行处理多个任务你同步等反而浪费了并发能力。批量跑了半个月之后我们还总结出一个性价比很高的经验同一分镜至少生成 2 到 3 个候选版本。AI 生成有随机性同一段提示词出来的画面可能第一次就很好也可能第三次才好。我们一般每个分镜生成 3 个版本后期质检时挑选最符合需求的一个。这个做法把返工重跑的概率从 30% 降到 5% 左右。4.3 配音与字幕开源工具 TTS 的双保险画面素材就位后下一步是配音。这个环节我们走的是“开源本地 API 兜底”的双保险路线。本地开源 TTS 我们用的是比较常见的开源模型比如 GPT-SoVITS、CosyVoice 或者 edge-tts 这些项目。本地跑的好处是免费、可控、不用纠结 token 消耗但有个前提——你电脑没有显卡也能跑。我们实测下来某些开源 TTS 模型用纯 CPU 跑也不是不行就是慢一些30 秒的旁白文本大概需要 2 到 3 分钟生成才完成。如果客户对声音有特定要求比如指定某种音色或者语气我们就走 API 路线。多家大厂的语音合成 API 都支持音色定制和情感控制参数灵活性更高但按字符计费一篇 300 字的旁白大概几分钱到几毛钱成本可以接受。配音生成之后紧接着就是字幕。字幕生成我们完全用的是开源工具。思路是先生成语音文本的时间戳再把文本目录映射到时间轴输出标准的 SRT 字幕文件。这里有个实用小技巧如果你用的是 OpenAI 系的音频转写接口它在返回文本时自带每个单词或字符的时间戳信息你可以直接利用这些时间戳来对齐字幕。如果用的是本地开源模型可以退而求其次按“每句话”做切分再手动微调偏移量。我强烈建议在流水线设计阶段就把字幕生成接到配音环节之后不要让字幕生成独立于音频。因为字幕的准确性高度依赖音频的实际时间轴你单独拿文本去生成字幕最后大概率要对不齐。4.4 剪辑合成FFmpeg 是你最该熟悉的开源工具画面、配音、字幕都有了之后核心工作就是把它们合成一部完整的视频。这一步我们用的主力开源工具是FFmpeg。FFmpeg 这个名字可能有些人没听过但它在视频处理界的地位相当于文字处理界的 Word。剪裁、拼接、转码、音频混流、字幕烧录几乎你能想到的所有视频处理能力它都支持而且是命令行操作天然适合写脚本自动化。我们的合成步骤大致如下第一步把每个分镜的视频片段按顺序拼接起来。这里用 FFmpeg 的 concat 滤镜注意不同片段的编码参数必须一致否则拼接时会花屏或者报错。第二步把配音音频文件和拼接后的视频合流用-c copy参数可以做到完全无重编码的快速合并。第三步把 SRT 字幕文件烧录到视频里。这里要注意烧录字幕意味着重新编码耗时较长但成片直接自带字幕方便交付。第四步如果还需要加背景音乐用 FFmpeg 的 amix 滤镜做混音同时控制配音和 BGM 的音量比例。这里分享一个 FFmpeg 的参数心得拼接视频时用 concat 协议要比用 filter 性能好很多因为前者不需要逐帧解码。条件是所有素材必须有相同的分辨率、帧率和编码格式。所以我们会在素材入库时统一做一次标准化ffmpeg -i input.mp4 -vf scale1920:1080,fps30 -c:v libx264 -preset medium -crf 23 -c:a aac output_standard.mp4这条命令把任何来源的视频统一转成 1080p、30 帧、H.264 编码之后再进拼接流程能省掉 80% 的兼容性问题。FFmpeg 的完整命令示例、参数解释网上资料很多我这里不逐条展开了。但有一点要提醒FFmpeg 的命令行参数很“反人类”第一次用时一定要保留一份常用的命令模板否则每次都要重新查文档。5. 零显卡带来的约束如何反而帮了我们5.1 迫使你专注在“流程”而非“炫技”上零显卡这件事刚开头看着像劣势但跑通整条流水线之后我们反而觉得它是福因。原因在于没有本地算力你压根没机会去碰那些“看起来很酷但实际用不起来的模型本地部署”的问题也不需要纠结“要不要自己微调一个模型”这种话题。很多有显卡的团队反而容易陷进去买了几张卡总想着“不跑点什么就觉得亏”于是开始折腾模型微调、训练数据清洗、权重量化一个月过去了视频一条没产出。我们因为没有这个选项就只能把全部精力放在流程优化上。比如怎么让脚本拆解更稳定、怎么减少素材生成失败的次数、怎么缩短字幕对齐的时间。这些看着不性感的“脏活累活”恰恰是一条视频流水线能持续跑起来的关键。5.2 成本策略按量付费反而更利于小步快跑本地部署的算力成本是“先掏钱后使用”而且无论你用不用硬件的折旧和电费都在流失。API 的方案是“先使用后付费”用多少花多少。对小团队来说这种模式最大的价值不是便宜而是试错成本极低。举个例子。我们刚开始做素材生成的时候提示词风格经常调不准一个分镜可能生成 5、6 次才能找到合适的画面。如果走本地部署路线这种试错基本等于白烧电费但走走 API 路线单张图片生成一次可能才几分钱到几毛钱5、6 次也就几块钱。这种低成本试错让我们敢大胆尝试各种风格、各种提示词组合做出来的内容反而更丰富了。当然成本也有失控的风险。我们吃过的亏是某个晚上批量生成素材时忘了设轮询间隔导致发出去太多并行任务第二天一查账单那一天的费用是平时的 5 倍。从那以后我们给所有批量脚本都加了一个硬性约束单日预算上限用环境变量控制超过阈值直接停止发送新请求。这种“预算熔断”机制强烈建议所有用 API 做生产的小伙伴都加上不然哪天账单就能给你一个“惊喜”。6. 实操中踩过的坑问题排查与避坑技巧6.1 API 限流与并发不是你想多快就能多快视频生成 API 的限流策略通常分两层一是每秒请求数限制二是每日可用配额。我们最开始并不知道这两个是分开算的导致程序只在第一层做了限速结果跑到下午就撞上了每日配额上限任务全部失败整条流水线停摆半天。解决方案是做一个“动态熔断器”每次请求前先查当前配额剩余低于总量的 20% 就切换到低速模式降低并发数并延长重试间隔低于 5% 就完全暂停改用邮件告警通知负责人手动处理。另外API 返回的报错信息一定要认真看。我们遇到过这种情况明明同样的代码早上跑就正常下午跑就报错排查半天才发现是 API 服务商在特定时间段做了降级把并发数从 10 降到了 3。这类问题你改代码没用只能在代码里做好重试和退避逻辑把失败任务自动放入重试队列。6.2 素材风格一致性AI 生成最让人头疼的问题AI 生成的画面素材单看每一段都不错但拼在一起就很容易出现“风格断裂感”。比如第一个分镜的画面像电影质感第二个分镜却像短视频滤镜拼接后观众一眼就觉得出戏。这个问题我们最终的解法是加了一道“风格锚点”工序。具体就是在每个分镜的提示词里统一注入一个“风格描述前缀”比如“影像风格为浅灰色背景、柔和自然光、产品特写镜头”然后所有分镜都带这段前缀。同时我们把分辨率、帧率、色偏参数在入库时全部统一标准化。这个操作虽然不能做到 100% 一致但至少能消除那种一眼就能看出来的割裂感达到可用标准。6.3 字幕对不齐看似小问题实际上最消耗时间字幕对不齐这个问题是我们整个流水线里返工率最高的环节。排查下来根因往往不是字幕工具的问题而是配音本身“有情绪”。我们实测发现TTS 生成的音频在语气词、停顿、重音处的时长波动比预期大得多。比如旁白文本写的是“这款产品非常耐用”TTS 可能会在“非常”后面多停半秒导致字幕时间轴和音频对不上。解决思路是不用“逐字时间戳”去生成字幕而是按“语义断句”生成字幕。也就是在脚本拆解环节就让大模型把旁白按语义切好生成带标签的文本块配个别生成后再单独给每块文本分配时间轴。这个方式的粒度更粗但更稳定字幕和听感对齐效果反而更好。6.4 开源工具的版本兼容问题开源工具迭代快是好事但也带来了兼容性问题。我们遇到过几次升级后 API 接口变了、参数名改了导致流水线脚本直接跑不通的情况。解决办法是项目启动时锁定版本不轻易升级。如果确实需要升级也要在测试环境跑完一条完整的分镜流程再上生产环境。另外开源工具的文档质量参差不齐一个重要建议是对常用的开源工具建一个本地知识库把关键操作步骤和踩过的坑记下来。我们在本地维护了一个 Markdown 文件记录 FFmpeg 常用命令、TTS 模型参数设置、字幕生成工具的使用要点。这个文档现在已经成了团队内部最重要的资产之一。7. 整体成本与效率账算明白才安心很多人关心零显卡的 API 方案到底要花多少钱。我直接用我们实际跑过的数据说话。我们做一条 30 秒的短视频流水线跑一轮的典型消耗是脚本拆解调用大模型 API处理约 1000 字文本消耗约 3000 tokens成本不到 0.1 元画面生成6 个分镜 x 3 个候选版本 18 次视频生成调用费用因不同服务商而不同一般在 10 到 30 元之间配音30 秒旁白开源本地 TTS 免费如果用 API大约 2 到 5 元字幕开源工具本地处理免费剪辑合成FFmpeg 本地处理免费这样算下来一条 30 秒成片的直接成本集中在画面生成环节总成本大约 15 到 40 元。相比本地部署买显卡的一次性投入这种按量付费的模式让我们在第一个月就实现了正向现金流。效率方面一条 30 秒的片子第一次跑通全流程需要约 2 小时其中一大半时间是等素材生成。跑了三周后优化了并发和流程衔接时间压缩到 45 分钟左右。这个速度放在传统视频生产方式里是不可想象的。但这笔账有一个前提你的模板和流程已经跑通。在早期调试阶段成本和时间投入会明显偏高那个阶段不要急着算产出比先把流程稳定下来再说。8. 一条流水线的迭代方向与最后想说的事跑通基础流水线之后我们还在持续做几件事这里分享出来供参考。一是建立素材库复用机制。AI 生成的素材虽然每次都不一样但很多镜头是可以复用的。比如“产品特写”“场景过渡”“空镜”这三类镜头基本每条视频都用得上。我们把这些镜头按类别归档做成一个可检索的本地素材库。后续生成新视频时先查一遍素材库能复用的就不重新生成这样不仅省钱还让成片风格越来越统一。二是引入人工反馈闭环。我们每次交付成片后都会记录客户对哪些镜头不满意、原因是什么。这些反馈会定期反哺到大模型的提示词调整上。比如客户反馈“第一个镜头的产品角度不够有冲击力”我们就会在对应分镜的视觉描述里加入“低角度仰拍”“广角镜头”等措辞让后续生成更贴合需求。做过三轮之后分镜一次通过率有了明显提升。三是尝试“批量生产”模式。视频生成 API 的随机性意味着你无法精确预测每一次的结果但如果你允许“冗余生成”即一次多生成几个候选再从中挑选那么用同样的预算和耗时就能产出更多可交付的素材。这个思路也适合接一些批量类的订单比如电商平台需要大量短视频素材时冗余生成就相当于“概率性交付”。最后说句实在话。零显卡做 AI 视频这件事最核心的体会不是“省钱”或者“不需要硬件”而是它逼着你把注意力从技术炫技转回到生产效率和内容质量本身。算力可以租模型可以用现成的但流程设计、素材管理、质量把控这些能力才是小团队真正的护城河。如果你也打算走这条路建议从最小闭环开始一个脚本拆解、一个画面生成 API、一个 FFmpeg 拼接命令先跑出 10 秒的片子再慢慢扩展环节。跑通一次之后后面的优化方向自然就清楚了。