生成式 AI 全景图
想象一下:你按一个按钮,AI 就画出了一张专业级图片。这背后的机器是怎么运转的?
你已经在使用它了
打开 Open Generative AI,输入一段描述,点击"生成"——几秒钟后,一张从未存在过的图片出现在屏幕上。这个过程感觉像魔法,但实际上是一条精心设计的流水线在工作。
这门课要做的,就是把这条流水线的每一个工位打开来看清楚——这样当你告诉 AI 「帮我加个视频生成功能」时,你知道该往哪里加。
文生图
输入文字描述,输出图片。200+ 个模型在幕后竞争这个任务。
文生视频
文字变成几秒到几十秒的视频片段。计算量是图片的 50-100 倍。
唇形同步
让图片中的人物「开口说话」,口型与音频完美匹配。
Cinema 模式
组合多种能力,生成有叙事感的完整短片。
闭源 vs 开源:一个关键选择
市面上有 Higgsfield、Freepik、Krea 这些闭源平台——付费、有内容审查、功能受限。Open Generative AI 的定位是它们的开源替代品:你下载源码,在自己的机器上跑,什么模型都能用,没有内容过滤器。
Open Generative AI 本身不训练任何模型。它是一个调度层——把用户请求路由到合适的 AI 模型。这个设计让它能以极低成本接入 200+ 个模型。
用户看到的界面,运行在浏览器里
统一的 AI 模型访问入口,管理密钥和配额
Stable Diffusion、WAN 2.1、Happy Horse 1.0 等
知识检验
你想给 Open Generative AI 接入一个全新的图片生成模型。根据它的架构,你最应该修改哪里?
Open Generative AI 提供了 macOS/Windows 桌面安装包(.dmg/.exe)。这是通过哪种技术实现的?
模型路由架构
200+ 个 AI 模型,系统怎么知道该用哪一个?
大楼的总台服务员
想象一栋大楼里有 200 多个专科诊室。你走进大厅,告诉前台「我想生成一张图片,用 FLUX 模型」。前台查了一下记录,找到 B4 诊室——那里是 FLUX 专科——给你签了个号,送你过去。
Open Generative AI 的路由层就是这个前台。它读取 models_dump.json 这份「诊室名录」,把每个请求精确派发给对应的 AI 模型。
这个文件定义了每个模型的 ID、输入参数格式、支持的功能,以及它属于哪个类别(t2i 文生图 / t2v 文生视频 / lipsync 唇形同步 / cinema 影院)。系统所有的下拉菜单、参数表单,都从这里动态生成。
代码解读:API 代理路由
当你在界面上点击「生成」,前端会发起一个请求,经过 Next.js 的API 代理,抵达 muAPI 网关。看看这段代码是怎么工作的:
const MUAPI_BASE = 'https://api.muapi.ai';
function getApiKey(request) {
const headerKey = request.headers.get('x-api-key');
if (headerKey) return headerKey;
const cookieKey = request.cookies
.get('muapi_key')?.value;
return cookieKey;
}
所有 AI 请求都发往 muAPI 这个统一网关地址
这个函数负责找到用户的 API 密钥
先在请求头里找——这是给程序对接用的方式
如果头里没有,就去 Cookie 里找——这是浏览器登录后保存的
返回找到的密钥(两种方式都支持)
组件对话:一次生成请求的旅程
点击「生成」之后,系统内部发生了什么?看这场对话:
知识检验
有一个新的图片生成模型发布了,你想把它接入 Open Generative AI。最少需要修改哪个文件?
图像生成管道
从你输入的一行文字,到屏幕上出现的那张图片,中间发生了什么?
照相馆的暗房
老式照相馆里,摄影师按下快门后,胶卷要经过一道道化学处理才能变成照片:显影→定影→冲洗→放大。每一步都不能跳过,顺序不能乱。
文生图的扩散模型管道就是这样:从一团随机噪点开始,每一步精细调整,最终「显影」出你描述的图片。
四个 Studio 的分工
Open Generative AI 的界面分为四个工作室,每个都是独立的图像处理场景,背后调用不同的模型类型:
为什么生成图片要选宽高比?因为扩散模型的输出分辨率是固定的,宽高比 1:1、16:9、9:16 对应不同的像素矩阵形状。选错了裁剪出来的图片会模糊或变形。当你告诉 AI「生成一张手机壁纸」时,记得说「9:16 竖版」——这就是宽高比的实际意义。
图像生成的隐藏参数
models_dump.json 里,每个模型都声明了自己接受哪些参数。这些参数直接决定生成质量:
prompt
描述你想要什么图片的文字 — 越详细效果越好
aspect_ratio
宽高比,影响图片形状(1:1 / 16:9 / 9:16)
num_images
一次生成几张,越多消耗越多 API 额度
style_type
风格预设(写实 / 动漫 / 油画等),快速调整整体感觉
知识检验
用户反馈说生成的图片细节不够丰富,有些模糊。如果这个模型支持调整迭代步数(steps),应该怎么改?
视频生成管道
视频生成为什么比图片难 100 倍?答案在于时间这个维度。
拍电影 vs 拍照片
拍一张照片,你只需要处理一个瞬间。拍一段 5 秒的视频(24fps),你要处理 120 个瞬间,而且每一帧都必须和前后帧时间一致——猫的耳朵不能在第 30 帧突然出现在不同的位置。
这就是为什么视频生成模型(如 WAN 2.1、Happy Horse 1.0)的计算成本是图片的 50-100 倍,生成时间也从几秒变成几十秒到几分钟。
图片生成
处理 1 帧,约 3-8 秒,计算量:1x
5 秒视频
处理 120 帧 + 帧间连贯性,约 1-3 分钟,计算量:50-100x
唇形同步
还要对齐音频波形,约 30-90 秒,需要人脸检测前处理
视频生成的两条路径
系统支持两种视频生成方式,适合不同场景:
只输入文字描述,AI 完全自由发挥场景、动作、光线。适合从零开始创作,但结果不可完全预测。
先提供一张参考图,AI 让这张图「动起来」。结果更可控,主体外观更稳定——猫的颜色不会变。
在实际工作中,推荐的工作流是:先用文生图生成一张满意的参考图,再用图生视频让它动起来。这样既能控制外观,又能有动态效果。这也是「Cinema 模式」的底层逻辑。
知识检验
一个品牌想用 AI 生成一段产品展示视频,要求视频中的产品外观和提供的参考图完全一致。应该选择哪种生成方式?
自托管与规模扩展
把这套系统部署到自己的服务器上——从单机到高并发,你需要知道哪些关键决策?
三种部署方式
Open Generative AI 提供了三种部署路径,复杂度和控制程度递增:
下载 .dmg/.exe,双击安装,API Key 填进去就能用。适合个人或小团队,不需要任何技术背景。
克隆源码,npm install,npm run dev。适合开发者二次开发,可以修改功能、添加自定义模型。
用 docker-compose.yml 一键启动,适合生产环境。可以部署到云服务器,多用户共享使用。
规模化的瓶颈在哪里?
当用户数从 1 个增长到 100 个时,哪里会先撑不住?