RTX 4090 on 鬼哥的空间

Qwen Image 40 步对上 Viggle Turbo 6 步：4090 上的四组实测

Mon, 05 Oct 2026 00:00:00 +0000

最近鬼哥在折腾一件挺有意思的事：以自己的 4090 机器为算力核心，在本地搭起一整套做口播视频的工作流和基础服务。语音生成、字幕处理、图像生成、人物口播视频，逐步接进同一个工作台，从一段文案和一张人物图，走到带声音、带字幕的视频。

先放一段已经做出来的成品：Diana 介绍 DI CLI 的口播。下面是带字幕的版本，约 12 秒，视频由 4090 上的 H3 生成。

你的浏览器不支持内嵌视频，可以下载 Diana 口播视频观看。

下载 Diana 口播视频

我想给后面自己做视频剧先铺好路。人物形象、配音、场景和口播都能在本地反复试，就不用每生成一版都去买云端额度了。机器已经在手，日常试错主要花的是电费和等待时间，改台词、换造型时也能更放得开。

当然，一段口播离一部视频剧还有距离，角色一致性、镜头衔接、表演和剪辑都要继续磨。这套基础服务先把素材生成串起来，后面才有条件一集一集往下做。

这篇先聊其中的生图部分。语音、字幕和视频的部署细节留待后面展开；眼下要解决的问题是：给人物换造型、做场景素材时，能不能更快拿到一张可用的图？

从一张咖啡海报开始

一张咖啡海报，左边画了四十步，右边只画了六步。把两张图并排放好，最先吸引我注意的，是它们都把“秋日限定 · 桂花拿铁”写对了。

左边的工作流用了 38.4 秒，右边用了 10.2 秒。杯子、拉花和叶片有变化，但如果只是想给一杯秋日咖啡做张海报，右边已经很有说服力。

这组结果让我想继续看下去：生成快了将近四倍，省下的那些步骤，到底从画面哪里拿走了东西？

我把 Qwen-Image-2.1 和 Viggle 的 Turbo 方案放到自己的 4090 机器上，跑了人像、中文海报、换背景、换衣服四组对比。一共八张图，先看实际效果，再决定值不值得接进本地工作台。

先认清这两位选手

说是“两种模型”，它们其实有很近的亲缘关系。

基础版用的是 Qwen-Image-2.1 的 INT8 权重，这次跑 40 步。Turbo 则在同一个基础模型上，加载 Viggle v0.3 的六步蒸馏 LoRA，rank 128，配合专用采样时间点运行。

可以把每一步理解成模型对画面的一次修正。蒸馏让模型学习用更少的修正走到一个可用结果。因此，要得到这次的六步效果，需要 Turbo 的适配权重和采样配置一起配合。直接把基础版的步数框改成 6，并不等于完成了这套配置。Viggle 模型说明给出了具体用法。

这轮两边都用相同提示词、seed 42、1024 × 1024 输出、CFG 1，并且关闭提示词增强。文生图用同样的文字，编辑任务用同一张参考图。每个场景各跑一次，所以这是一轮样片观察，还不足以给模型的整体能力排座次。

干活的还是那台 4090

这张照片之前放在《桌面 AI Studio》里。机器继续负责重推理，Mac 负责开发和整理结果。这次图像生成也交给它。

先把最容易误会的规格写在前面：这张卡在系统里显示 49140 MiB 显存，约 48GB。 读者如果拿普通 24GB 4090 对照，显存余量得另外算。

硬件	本次机器
CPU	Intel Core i5-13600K，14 核、20 线程
系统内存	64GB，Linux 显示约 62 GiB
GPU	NVIDIA GeForce RTX 4090
显存	`nvidia-smi` 显示 49140 MiB

软件环境也列出来，方便以后对照：

软件 / 模型组件	本次配置
操作系统	Ubuntu 24.04.3 LTS，x86_64
NVIDIA 驱动	570.158.01
Python	3.12，独立虚拟环境
PyTorch	2.11.0+cu128，CUDA 12.8 运行时
ComfyUI	0.38.0，固定提交 `6b747c0428c34`
主模型	Qwen-Image-2.1，INT8 convrot
文本编码器	Qwen3-VL 8B，INT8 convrot
VAE	Qwen-Image-2.1，BF16
Turbo 适配器	Viggle v0.3，6-step LoRA，rank 128
注意力实现	PyTorch SDPA；关闭可选的 kitchen INT8 attention

主模型、文本编码器、VAE 和 LoRA 的权重文件合计约 18GB。这里的 INT8 指权重存储配置，不代表整个计算过程全部使用 INT8。

图像环境有独立的 Python 虚拟环境和 ComfyUI 副本，与现有 H3 视频服务共用 GPU 排队锁。一次图像任务结束，运行时退出并释放显存。八张图跑完后，显存占用回到了 15 MiB，H3 的健康检查也正常。

这个安排很适合我现在的用法：同一张卡轮流承担图像和视频任务，避免两个大任务一起上来争显存。

人像：第一处差别在脸上

第一组提示词要的是成年东亚女性、黑色齐肩发、米色亚麻外套、左侧柔和窗光，以及自然的皮肤纹理。

基础版原尺寸图 · Turbo 原尺寸图

两张图的构图、衣服和光线都很接近。缩小看，六步版没有出现明显的结构崩坏，也没有突然换一种摄影风格。

放大脸部，差别就有了：基础版的眼周、面颊纹理更明显，Turbo 的皮肤更平滑，五官的局部形态也有细微变化。

如果用来试头像方向或看服装配色，我会愿意先用 Turbo。如果想要更有年龄感、更强调皮肤质地的人像，基础版这张更接近提示词里“自然纹理”的要求。这里的平滑是否算损失，取决于你想要什么样的照片。

这一组很能说明问题：六步没有把画面压缩成半成品，但它改变了细节的表达。

中文海报：这次六步没有把字写坏

开头那张海报指定了四行文字：

慢下来，喝杯咖啡
秋日限定 · 桂花拿铁
每日现磨，新鲜烘焙
营业时间 09:00—21:00

基础版原尺寸图 · Turbo 原尺寸图

两边都把这四行文字画得正确、可读。版式也接近：大标题、品名、咖啡主体、小字说明，各自待在该待的位置。

这比“画了一杯好看的咖啡”更让我在意。做中文配图，经常卡在最后几个字上：主体都很漂亮了，标题偏偏多一笔少一画，还得再抽一张。这一组里，六步版保住了文字，省下的等待才真正有用。

当然，四行短句还难不倒所有模型的边界。长段落、密集小字、复杂表格，这次都没跑，不能从一张咖啡海报推导出“中文随便写”。

至于杯形、拉花和叶片的差别，两边各有自己的画法，我没有看到足以让我为了这张海报坚持等待四十步的优势。

换背景：花园来了，人也被轻轻改了一下

后两组用的是现有工作台里的 girl-avatar。先放参考图，方便看清到底保留了什么。

第一项要求是把背景换成有阳光、虚化的花园，同时保留人物。

基础版原尺寸图 · Turbo 原尺寸图

两边都完成了花园背景。发夹、心形耳饰、白领灰衣这些显眼特征也都留住了，乍看很适合继续拿去做人物素材。

但对着参考图看，会发现两版都稍微放宽了取景范围，展示出更多衣服和躯干，皮肤和发丝也有局部重绘。Turbo 的对比感更强一些，细节更平滑。

“人物看起来还是她”和“人物像素完全不动”，是两种不同的要求。 这一组满足了前者，没有做到后者。需要严格保留原片时，仍然要考虑蒙版、抠图和合成流程，不能把一句“只换背景”当成锁定按钮。

值得注意的是，基础版四十步也有这个问题。等得久一点，并没有自动换来像素级的编辑边界。

换衣服：六步已经能拿来试造型

最后一组，把原来的服装改成藏蓝色西装，里面穿白色圆领上衣。

基础版原尺寸图 · Turbo 原尺寸图

两边都完成了换装，脸、表情、发型和饰品整体接近参考图。西装的领口、面料和局部阴影各有差别，皮肤与发丝同样存在重绘。

如果我要为工作台的人物试几个造型，这个结果已经足够让我继续往下做。先看看藏蓝西装是否合适，再决定换成衬衫还是针织衫，十几秒拿到一张图，会更愿意多试几次。

不过，“更愿意多试”是我的使用判断。这里没有做多 seed 的稳定性统计，也没有测试连续编辑几轮后人物会漂移多少。

到底省了多少时间？

四组任务的数据放在一起：

场景	基础版 40 步	Turbo 6 步	工作流加速比	显存峰值：基础 / Turbo
人像生成	38.44 秒	10.15 秒	3.79×	15.99 / 16.58 GiB
中文海报	38.43 秒	10.15 秒	3.78×	15.99 / 16.58 GiB
人物换背景	42.50 秒	12.19 秒	3.49×	20.74 / 21.21 GiB
人物换服装	42.52 秒	12.18 秒	3.49×	20.71 / 21.24 GiB

这里的时间包含模型加载、文本编码、采样和 VAE 解码，是完整工作流耗时。加上独立运行时启动，基础版每张约 43～48 秒，Turbo 约 15～17 秒。如果以后改成长驻服务、复用已加载模型，还需要重新测量，不能直接拿这张表当服务延迟。

四十步变成六步，步数少了约 6.7 倍，整个流程只加速约 3.5～3.8 倍，也很好理解：读模型、理解提示词、解码图片这些工作仍然要做，少采样并不会把它们一起省掉。

另一个容易忽略的地方是显存。Turbo 在这四组里反而略高一点，最高约 21.24 GiB。它加快了生成，但没有在本轮测量中带来显存节省。

这个峰值看起来落在 24GB 以内，我也不会据此承诺普通 24GB 4090 能照搬配置稳定运行。这里用的是 48GB 卡，而且显存数据是每两秒采集一次的全卡占用，可能漏掉短暂尖峰。

我会怎么把它放进工作台

看完这四组图，我倾向于把 Turbo 六步做成快速模式，基础版四十步保留作对照选项。

人像试方向、海报试布局、人物试服装，先用六步出结果。碰到皮肤质地、细小文字或复杂编辑这些值得较真的地方，再拿基础版比较。两种配置生成的细节会不同，基础版也需要逐张判断。

目前做到的是独立命令行评估，图像 API 和 WebUI 还没有接入。这次部署复用了机器上已有的 H3 源码与 CUDA 依赖，并没有完成一台全新 Ubuntu 从 checkout 开始的一键安装验收。

下一轮真正值得加的，是更多随机种子、密集中文、多参考图和更高分辨率。它们会决定六步版能走多远。这四组样片已经回答了一个更小、也更实际的问题：它值得继续接进来试用。

回到开头那杯咖啡。如果六步已经把布局、杯子和四行字交代清楚了，我更愿意把省下的时间用来改一句标题、换一种配色。那句“慢下来，喝杯咖啡”，倒是不必让显卡也照着执行。

本轮参数备忘

实测日期为 2026 年 10 月 5 日。基础版使用 Euler / simple、40 步；Turbo 使用独立、未合并的 LoRA，强度 1.0，以及作者提供的六步 sigma 配置。两边均使用 INT8 主模型与文本编码器、BF16 VAE、CFG 1，关闭提示词增强。

每张图启动新进程，但没有清空操作系统文件缓存；每个场景每种配置只有一次记录，表中没有多次平均。这套 ComfyUI 配置也不等同于逐项复刻作者的 Diffusers 基准。

正文并排图用于快速浏览，图下的原尺寸链接为原始 PNG 无损转换的 WebP，适合放大看细节。主机照片复用本人此前文章中的实拍图。

参考资料

模型页面标注 Qwen Research 许可证；商用前请另行确认对应权重与适配器的许可条件。

口播视频的 API 账单有点贵，鬼哥把 Mac mini 和 4090 接成了一间 AI 演播室

Mon, 05 Oct 2026 00:00:00 +0000

做一个 AI 口播视频，最容易上头的时刻，是人物第一次开口。最容易冷静下来的时刻，是你想改一句文案，再生成一遍。

鬼哥之前做了一套真人口播的 skill：给它人物照片、声音样本和文案，让 MiniMax 克隆声音、生成配音，再交给 HeyGen 做照片驱动的口播视频。先看短预览，满意了再出正式版，素材、任务和成品都能留档。

流程顺了，另一个问题也顺着来了：创作很少一遍就满意。文案要改，语气要调，照片要换，预览看完又想试另一版。让 agent 来回编排会消耗 token，语音和视频服务还有各自的计费方式。省下了操作时间，试错仍然要付钱。

鬼哥看了看桌上的 M6 Mac mini，又看了看自己的 4090：东西都买了，总得让它们多干点活。于是有了这间本地 AI 演播室——Qwen 管声音和人物图，MiniMax H3 管声画视频，Open WebUI 把它们接到同一个页面，字幕最后在 Mac 上收尾。

先看结果。下面是 Diana 介绍 DI CLI 的带字幕口播，约 12 秒，视频由 4090 上的 H3 生成。

你的浏览器不支持内嵌视频，可以下载 Diana 口播视频观看。

下载 Diana 口播视频

这回再想让她换一句台词，本地生成链路不用先看云端 API 余额。当然，机器、电费和折腾时间都有成本；这里的“免费”，说的是不再为每次本地推理付云端调用费。模型许可也得另看，尤其不能把免费试验直接理解成无条件商用。

两台机器，终于不用挤同一张床

在之前那篇 Mac mini 工作站文章里，鬼哥已经让 32G 的小盒子能聊天、能画图了。麻烦是两个大模型留在内存里不走，最后只好安排它们轮流上场。

现在要加配音和视频，继续把所有活塞给 Mac，排队就更长了。这次分工干脆一点：Mac mini 留在桌面上当工作台，做语音和字幕；图像、视频这些重活，交给 Ubuntu 上的 4090。

Mac 上的主角是 Open WebUI 和独立的 local-tts 服务。Open WebUI 保存音色、人物、文案和任务记录，调用模型的动作发生在它的后端。local-tts 用 MLX / Metal 跑 Qwen3-TTS，也提供本地 Whisper 转写。字幕另有独立环境，走 CPU，把统一内存和 GPU 的余量留给语音。

4090 那边跑两个服务：Qwen-Image-2.1 图像 API，和 MiniMax H3 视频 API。底下各有自己的推理环境，避免把语音、图像、视频的 Python 依赖煮成一锅粥。

先说个容易看漏的规格：鬼哥这张卡是 48GB 显存的 4090，主机有 64GB 内存。普通 24GB 4090 能不能照搬，得按模型、量化和工作流重新算，不能只认“4090”这三个数字。

这样一分，Mac 不用为了画一张人物图先把自己的声音服务挤走；4090 也不用承担网页、音色库和字幕编辑。哪台机器擅长哪件事，就让它干哪件事。

`/audio-studio`：名字还是音频，里面已经能拍视频了

浏览器打开 http://localhost:8080/audio-studio，进入的是“视频语音工作台”。这里是鬼哥在本地 Open WebUI 源码上扩展的页面，装一个上游原版不会自动长出这些功能。

先看整套架构：页面在 Mac，重活在 4090

先把页面后面的关系看清楚，后面每点一个按钮，就知道是哪台机器在干活。浏览器只访问 Mac 上的 Open WebUI；配音交给本机 Qwen3-TTS，人物图和口播视频通过两条 SSH 隧道交给 4090，成片返回 Mac，再生成和烧录字幕。

打开可放大的 SVG 架构图

工作台要做的事	Mac 后端访问的地址	真正干活的位置与接口
预设配音、克隆与声音设计	`127.0.0.1:8091`	Mac local-tts：`/v1/audio/speech`
音色管理、录音转写	`127.0.0.1:8091`	Mac local-tts：`/v1/audio/voices`、`/v1/audio/transcriptions`
Qwen 生图、参考图编辑	`127.0.0.1:28093`	SSH 转发到 4090 的 `8093`：`/v1/images/generations`、`/v1/images/edits`
H3 素材与视频任务	`127.0.0.1:28092`	SSH 转发到 4090 的 `8092`：`/v1/video/assets`、`/v1/video/jobs`
字幕识别、对齐与烧录	WebUI 内部调用独立进程	Mac CPU：stable-ts / Whisper + FFmpeg / libass

两条隧道让后端像访问本机一样访问远端 API。远端服务继续只监听回环地址，Mac 本地转发口也绑定回环；图像 API 另外有 Bearer 密钥，由 WebUI 后端保存。当前机器用 launchd 保持隧道并自动重连。

从音色和人物开始，再让她开口

当前导航有音色库、人物库、生成播报、生成视频，管理员还会看到生成图像。把它们放在一起，是因为做 Diana 这样的角色，最常重复使用的其实是她的脸和声音。

音色库先解决“谁来说”。 可以用 Serena 等九种预设音色，也可以上传录音，或用麦克风录制。参考录音支持 1–120 秒，参考原文可选；不想手工抄，就调用本地 Whisper 识别，再校对。音色可以命名、试听、编辑和删除，替换录音会留下新版本，已经排队的任务仍能找到自己那一份素材。

还有个更好玩的入口：文字设计音色。比如描述“年轻女性，声音温暖，普通话清晰，说话自然，像在向朋友介绍一个新工具”，先让 VoiceDesign 生成一段试听。满意了，命名并保存成音色；后面的播报再拿这段录音去克隆。设计声音这一步有随机性，保存满意的样本，比每次重新许愿更适合养一个长期角色。

人物库保存“谁出镜”。 上传人物图片，给角色起名，还可以绑定默认音色。下次选 Diana，不用重新在文件夹里找头像，也不用重新想她该用哪个声音。图像生成是独立入口，出图后仍需把选中的图保存到人物库；这里没有假装一张图出来就自动变成角色。

生成播报负责先把台词说顺。 输入文案、选择音色和语速，后台排队生成，完成后试听、下载 MP3/WAV。结果会留在历史里，还能直接拿去做视频。声音不满意，先在这一步改；没必要每换一个停顿，就让视频模型再忙一轮。

生成视频把人和声音合起来。 可以选已有播报，也可以在视频页直接输入文本、先生成配音。页面分别提供本机 H3（Mac）、4090 H3，以及配置后可用的 HeyGen。走这篇文章的本地路线，就选 4090 H3；HeyGen 仍属于云端付费路线。任务有进度和结果，成片能播放、改名、下载，完成后接着处理字幕。

管理员还可以显式把音频或视频发到 Telegram。那是分享出口，生成本身不需要 Telegram；需要把素材留在本地，下载 MP4 就够了。

Qwen 给 Diana 找声音，也给她换衣服

用户习惯叫它“qwen-voice”，这套部署里实际用的是 Qwen3-TTS，声音服务独立监听 127.0.0.1:8091。

三个模型各有一个用场。CustomVoice 提供预设音色；Base 用参考录音克隆声音；VoiceDesign 按文字描述设计新声音。Mac 端采用 1.7B 的 MLX 8bit 版本。克隆时，声音风格主要来自参考录音，不能把给预设音色用的风格指令当成万能旋钮。

它对外提供熟悉的 OpenAI 风格接口：POST /v1/audio/speech 返回 MP3 或 WAV，GET /v1/audio/voices 列出音色，POST /v1/audio/transcriptions 识别参考录音。Open WebUI 的音频引擎填“OpenAI”，只是选了接口格式；真正开口的是 Mac 上的 Qwen。

想单独验证声音服务，不必先打开工作台：

1
2
3
4


curl --fail-with-body http://127.0.0.1:8091/v1/audio/speech \
 -H 'Content-Type: application/json' \
 -d '{"model":"qwen3-tts","input":"你好，欢迎来到鬼哥的本地 AI 演播室。","voice":"Serena","lang_code":"chinese","response_format":"mp3"}' \
 --output narration.mp3

这个服务返回完整音频文件，不支持 stream=true。长文会按句分段再拼接；语速参数是生成后的 FFmpeg 调速，跟让模型换一种表演节奏是两回事。

人物图则交给 4090 上的 Qwen-Image-2.1。工作台的“生成图像”提供两种模式：默认 Viggle Turbo 六步，或者基础版四十步。没参考图时按提示词生图；传一张参考图，就能做换背景、换衣服这样的编辑，结果可以下载原图。

在前一篇四组实测里，同一台机器的人像和海报工作流，六步版约 10 秒，基础版约 38 秒；人物编辑约 12 秒和 42 秒。加上运行时启动，Turbo 的总时间约 15–17 秒。这些是那次固定配置的记录，工作台还要经过连接和保存，不能直接当成每次点击的承诺。

对角色创作来说，快一点的意义很具体：你更愿意试三套衣服、两个背景，再选适合这次台词的那张。图像编辑仍可能改变局部细节和取景，选人物图时得看脸，也得看构图。Diana 不会因为有了人物库，就自动获得每一帧都不变的身份证。

H3 收到配音后，会重新生成声画

人物和配音都有了，终于轮到视频模型。

这里用的是 MiniMax H3 的 Ref2VA，在 4090 上通过 ComfyUI 的 CUDA 运行时推理。部署采用裁剪后的 INT8 主模型、INT8 文本编码器与视频 VAE，以及 FP32 音频 VAE。整套权重下载约 51.5GB，跟“显存里同时要放多少”不是同一个数。

有个区别会直接影响你怎么看成片：H3 会根据参考人物和音频生成自己的声画音轨。 它不是给一份完全不动的 WAV 配上嘴形。参考配音在引导它，输出的声音、时长和细节仍可能变化，所以工作台保留模型实际生成的结果，不偷偷把原配音换回去。

这也是字幕必须听最终视频的原因。按输入 WAV 的时间轴贴字幕，遇到 H3 改了停顿，字就可能比嘴先到。

当前这套本地封装先收窄到 512×512、24fps、单段参考音频 2–15 秒，默认十二步，可选八步或二十步。官方模型的能力范围更宽，但鬼哥工作台还没有把官方整套高分辨率流程搬进来。

部署时留过一份短样片记录：约 4.1 秒的参考音频、十二步，在这台 4090 上一次成功任务的全流程约 86 秒，输出约 4.49 秒。它说明这条 CUDA 路线已经实际出片，不能拿来按比例保证一分钟视频的耗时。前面的 Diana 约十二秒成片，也是已有结果；这篇没有另外给她编一个生成速度。

长片开关目前关闭。服务已经有按停顿切段、保留已完成片段、继续失败任务的机制，但片段之间的人物姿态和声音衔接还需要验证。先把一段短口播做顺，比急着把它叫作全天候直播间踏实。

模型之间怎么接力，任务怎么留下来

前面那张架构图里的两条连接，落到部署上就是 SSH 端口转发。连接好以后，工作台才能把图像和视频任务送到 4090。

如果已经装好了远端服务，手工连接的核心就是这两条：

1
2
3
4
5
6


# 两条命令分别在独立终端运行；把 user@4090-host 换成自己的 SSH 目标
ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 \
 -L 127.0.0.1:28092:127.0.0.1:8092 user@4090-host

ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 \
 -L 127.0.0.1:28093:127.0.0.1:8093 user@4090-host

它们只是连接方式，还不是把两台空白机器装好的全部命令。当前环境是一步步部署、修复、接通的，全新 Mac / Ubuntu 从 checkout 到整条链路一键可用，还没有完整验收。

视频 API 用持久任务：先上传人物图和音频取得素材 ID，再创建任务，拿任务 ID 查询进度，完成后取 MP4。取消和重试也围绕这个 ID，断开隧道不等于远端任务已经停了，连接恢复后可以继续查。

图像 API 目前是同步请求，没有同样的长队列和取消能力。它与 H3 共用 GPU 锁，约十五秒仍拿不到 GPU 会提示忙，留给用户稍后重试。生成结束，独立运行时退出，把显存还出来。

这一点跟最初那台 32G Mac 的经验呼应上了：服务可以同时开着，大模型没必要同时赖在 GPU 里。做图和拍视频按顺序接力，48GB 也有自己的座位表。

最后一公里：让字幕跟上 Diana 的嘴

口播有画面、有声音了，手机上看的人却未必会开声音。字幕得跟上。

这里有两套容易叫混的 Whisper。local-tts 里的 MLX Whisper 用来识别音色参考录音；成片字幕则放在 Open WebUI 的独立 Python 环境，用 stable-ts 配合本地 Whisper Small，当前走 CPU 四线程。

完整视频有对应完整文案时，使用强制对齐：拿文字去最终音轨里找时间位置。截短预览或缺少文案时走 ASR，从实际音轨重新识别，避免把整篇台词硬塞进十几秒的预览。两种方式都可能出错，尤其是产品名、英文缩写和模型没有严格照读的地方，最后还是要看着成片校一次。

新视频完成后会自动生成并烧录字幕，成功后卡片默认播放、下载字幕版。要改文字和时间，可以打开编辑器，逐句定位、拆分、合并；字号、颜色、上下位置、边距和底框也能调整。保存以后重新烧录，才得到这版字幕对应的 MP4。字幕失败可以单独重试，不必再跑一遍 H3。

SRT、VTT、ASS 都能导出；想拿去剪辑软件继续做，用字幕文件；想直接发给朋友，用 FFmpeg / libass 烧好的视频。原片另保留一份，不会被字幕覆盖。

中文还有一个朴素的坑：系统里有字体，不代表 libass 真选中了它。此前成片出现过汉字方框，最终在 Mac 上显式加载 Heiti SC 才修好。模型说得再流利，字幕变成口口口，也像主持人忘了带提词器。

从一段短口播开始，把试错留给自己

拿 Diana 这样的角色来走这条链路，我会先选好人物图和声音，试听一小段台词。声音顺了，再送到 4090 H3；成片回来检查嘴形、人物和实际音轨，然后校字幕、下载。想换背景，就去图像页改；想换一句话，先重新配音。每一步都有自己的产物，出了问题能回到那一步。

文案可以自己写，也可以让本地聊天模型帮忙。现有 Open WebUI / Ollama 的聊天路线能继续用，但 Audio Studio 目前仍需要你输入文案、选择素材和提交任务，尚未做到“给一个主题，自动拍完整支视频”。这里的端到端，是从文案、人物图走到带字幕成片，而不是把所有创作判断都省掉。

还有一笔账要分清：Qwen-Image-2.1 和 Turbo 适配器有研究用途的许可条件，H3 用社区许可。自己的研究试验与收费交付是两回事，做商业内容前得逐项读模型条款；人物肖像和声音也要有相应授权。

对鬼哥来说，这套系统目前最有价值的，是能反复试。角色库里放好一个 Diana，今天介绍工具，明天换个背景、换一段台词，不用每次从上传素材和充值开始。短片能力已经能用，更长的视频、连续的角色表演，留着往后磨。

当初做 skill，是想让口播少一点手工操作。现在把后端搬回自己的机器，是想让“再试一版”少一点犹豫。

桌上的 Mac mini 接文案，4090 开始干活，Diana 再开口。鬼哥这次要看的，是她有没有把话说好。

参考资料

一张 4090 跑 Gemma4 26B：用 Ollama 搭本地 AI 开发环境实测

Mon, 04 May 2026 00:00:00 +0000

以前本地大模型像玩具：能聊天，但一进开发工作流就露怯。现在一张 4090 已经能把 Gemma4 26B 跑起来，还能接 Codex、Claude Code、Hermes Agent。问题只剩一个：它到底是生产力，还是昂贵的电子暖手宝？

这篇文章不讲玄学，直接上手：用 Ollama 部署本地模型、用 API 对话、接入开发工具，再看 RTX 4090 上的真实推理数据。

先看结论

我这台机器的实测环境：

项目	数据
GPU	NVIDIA GeForce RTX 4090
`nvidia-smi` 显存	49140 MiB
NVIDIA Driver	570.158.01
CUDA	12.8
Ollama	0.23.0
模型	`gemma4:26b`
模型文件大小	17 GB
Ollama 加载后显存	约 24.5 GB
持续输出速度	约 160-166 tokens/s
长输出功耗	约 260-265W
长输出温度	54-60C

先打补丁：我这张 4090 在 nvidia-smi 里显示约 48GB 显存，不是常见 24GB 版本。普通 24GB 4090 也可以参考这篇文章的方法，但长上下文、并发和 Agent 场景要更保守。

我的结论是：

本地 26B 模型已经能做日常开发副驾，但还不能无脑替代云端顶级模型。

它适合解释私有代码、写脚本、生成小模块、做初步 code review；但复杂重构、跨仓库规划、长链路 Agent，仍然会被模型能力、上下文和工具链沙盒卡住。

Ollama 解决了什么

Ollama 的价值不是让模型变聪明，而是把本地部署降到几条命令：

1
2


ollama pull gemma4:26b
ollama run gemma4:26b

没有 Ollama，你要处理权重格式、量化版本、CUDA、服务启动、API 适配。用 Ollama 之后，它更像一个本地模型网关：

1
2
3
4
5
6
7


开发工具 / 脚本 / Agent
 |
 v
http://localhost:11434
 |
 v
本地 Gemma4 26B

查看模型：

1

ollama list

我本机输出里有：

1
2
3
4
5
6


NAME SIZE
gemma4:26b 17 GB
gemma4:e2b 7.2 GB
gemma4:latest 9.6 GB
gpt-oss:20b 13 GB
gpt-oss:120b 65 GB

查看运行状态：

1

ollama ps

实测加载后：

1
2


NAME SIZE PROCESSOR CONTEXT
gemma4:26b 25 GB 100% GPU 262144

这行信息很关键：100% GPU 说明没有明显落到 CPU，262144 说明上下文窗口很大，但不代表每次都应该塞满。

先直接对话

命令行对话：

1

ollama run gemma4:26b

然后直接问：

1

用三句话解释 Ollama 是什么。

如果要从程序里调用，用 Ollama 原生 API：

1
2
3
4
5
6
7
8


curl http://localhost:11434/api/chat \
 -d '{
 "model": "gemma4:26b",
 "messages": [
 {"role": "user", "content": "用三句话解释 Ollama 是什么。"}
 ],
 "stream": false
 }'

Ollama 返回的 JSON 里有性能字段：

字段	含义
`load_duration`	模型加载耗时
`prompt_eval_count`	输入 token 数
`prompt_eval_duration`	输入处理耗时
`eval_count`	输出 token 数
`eval_duration`	输出生成耗时

核心公式：

1

输出速度 = eval_count / eval_duration_seconds

这比手动掐秒表靠谱。

接入 Codex：默认沙盒失败，授权后跑通

Codex CLI 版本：

1

codex-cli 0.128.0

启动方式：

1

codex --oss --local-provider ollama -m gemma4:26b

我先跑了一个只读任务：

1
2
3
4
5
6
7


codex exec \
 --oss \
 --local-provider ollama \
 -m gemma4:26b \
 -s read-only \
 --ephemeral \
 "请阅读当前目录的 benchmark.sh，简要说明它会如何测试 Ollama 本地模型性能，不要修改任何文件。"

Codex 成功识别了 Ollama provider：

1
2
3


model: gemma4:26b
provider: ollama
sandbox: read-only

但默认 read-only sandbox 下，内部执行读文件命令时失败：

1

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

这个结果很有价值：本地模型速度够，不代表 Agent 工具链一定顺。 这次不是模型不行，而是当前 Linux 环境下 bubblewrap sandbox 权限受限。

随后我显式授权绕过 Codex 内部 sandbox，仍然使用同一个只读任务：

1
2
3
4
5
6
7


codex exec \
 --oss \
 --local-provider ollama \
 -m gemma4:26b \
 --dangerously-bypass-approvals-and-sandbox \
 --ephemeral \
 "请阅读当前目录的 benchmark.sh，简要说明它会如何测试 Ollama 本地模型性能，不要修改任何文件。"

这次跑通了。Codex 成功执行：

1

cat benchmark.sh

并总结出脚本会调用本地 Ollama /api/chat，保存原始 JSON，再用 jq 计算 load_s、prompt_tokens_per_s、output_tokens_per_s 等指标。换句话说，Codex + Ollama + Gemma4 26B 是可用的，但在这台机器上需要绕过 Codex sandbox 才能读文件。

遇到类似问题，优先检查：

是否在受限容器、远程桌面、特殊 sandbox 里运行
系统是否允许 user namespace
Codex sandbox 模式是否过严
是否需要换普通终端或调整权限策略

接入 Claude Code：真实可用

Claude Code 版本：

1

2.1.126 (Claude Code)

Ollama 提供了 Anthropic-compatible API，所以可以这样接：

1
2
3
4
5


export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434

claude --model gemma4:26b

我用完整路径跑了一个非交互只读任务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


env ANTHROPIC_AUTH_TOKEN=ollama \
 ANTHROPIC_BASE_URL=http://localhost:11434 \
 ANTHROPIC_API_KEY= \
 /home/luoli/.local/bin/claude \
 -p \
 --model gemma4:26b \
 --no-session-persistence \
 --permission-mode dontAsk \
 --tools Read \
 --output-format json \
 "请阅读当前目录的 benchmark.sh，简要说明它如何测试 Ollama 本地模型性能。不要修改任何文件。"

结果成功：

指标	数据
状态	success
总耗时	7889 ms
API 耗时	7824 ms
轮数	2
输入 token	16319
输出 token	713
permission denials	0

Claude Code 正确读取了 benchmark.sh，并总结出脚本会用 5 个 case 调用 Ollama /api/chat，保存原始 JSON，再用 jq 提取 total_s、load_s、prompt_tokens_per_s、output_tokens_per_s 等指标。

这就是一个正面案例：同样是 Gemma4 26B，本地模型不只会聊天，也能通过 Claude Code 的 Read 工具进入真实开发上下文。

接入 Hermes Agent

Hermes Agent 版本：

1

Hermes Agent v0.12.0 (2026.4.30)

快速启动：

1

ollama launch hermes

也可以 oneshot 测试：

1
2
3


hermes --provider ollama \
 -m gemma4:26b \
 -z "请用三句话说明你当前是否在通过 Ollama 本地模型运行，并给一个开发建议。"

我本机能跑通。再用：

1

hermes status

看到：

1
2


Model: gemma4
Provider: ollama-launch

这里有个细节：模型回答里可能说自己是 custom provider，但工具状态显示 ollama-launch。所以验证 Agent 是否真的接入本地模型，不要只看模型自述，要看工具的 status 或配置。

4090 + Gemma4 26B 实测

我写了一个 benchmark 脚本：

1

content/post/ollama-local-dev/benchmark.sh

它测试 5 类任务：

Case	目的
Short chat	短对话
Long Chinese output	长中文输出
Code generation	代码生成
Code review	代码审查
Agent planning	Agent 规划

实测结果：

Case	总耗时	输出 tokens	输出速度
短对话	4.790s	697	165.93 tokens/s
长中文输出	18.728s	2785	160.84 tokens/s
代码生成	13.337s	1985	161.66 tokens/s
代码审查	14.430s	2143	161.16 tokens/s
Agent 规划	13.631s	2028	161.48 tokens/s
长输出监控	24.020s	3554	159.79 tokens/s

结论很稳定：

1

Gemma4 26B 在这台机器上的持续输出速度约 160 tokens/s

显存、功耗和温度

模型加载后：

1
2
3
4


GPU Memory: 24527MiB / 49140MiB
Power: 72W
Temp: 51C
Process: /usr/local/bin/ollama

长输出期间用：

1

nvidia-smi dmon -s pucvmet -c 20

观察到：

指标	数据
功耗	260-265W
温度	54-60C
SM 利用率	82-87%
显存占用	约 24529MB
显存利用率	50-55%
显存频率	10501 MHz
核心频率	2670-2685 MHz

这说明推理确实主要在 GPU 上跑，而且负载不低。长时间跑 Agent 时，真正要关注的不只是 tokens/s，还有散热、风噪、电费和显存被其他任务抢占。

一个容易误判的点：thinking 也算 token

第一次烟测里，我只是问：

1

用三句话解释 Ollama 是什么。

但 API 返回里的 eval_count 到了 887，因为模型生成了不少 thinking 内容。

所以做 benchmark 时不要只看“用户看到多少字”。对推理耗时来说，模型实际生成的 token 才是成本，包括 thinking。

适合怎么用

我建议这样分工：

场景	本地 Gemma4 26B 是否适合
私有代码解释	很适合
写脚本 / 小工具	很适合
生成测试样例	适合
初步 code review	适合
大型重构	谨慎
跨仓库复杂任务	不建议只靠本地
高风险生产改动	必须人工复核

最舒服的用法不是“让本地模型全自动开发完整系统”，而是：

1
2


本地模型负责高频、低风险、隐私敏感任务；
云端强模型负责低频、高难度、强推理任务。

Takeaway

回顾一下，搭一个能用于开发的本地 AI 环境，只需要四步：

用 Ollama 拉取模型：ollama pull gemma4:26b
用 API 或 CLI 确认模型能稳定对话
把 Codex、Claude Code、Hermes 接到 localhost:11434
用 tokens/s、显存、功耗、温度和 Agent 成功率一起评估体验

这次实测最重要的结论不是“4090 很快”，而是：

本地模型的下限已经很高，但上限取决于工具链。

Claude Code 能顺利读取文件，Codex 在同一环境里被 sandbox 卡住，Hermes 能跑通但 provider 映射要核验。这才是真实的本地 AI 开发体验：模型只是发动机，方向盘、刹车和路况一样重要。

RTX 4090 on 鬼哥的空间

Qwen Image 40 步对上 Viggle Turbo 6 步：4090 上的四组实测

从一张咖啡海报开始

先认清这两位选手

干活的还是那台 4090

人像：第一处差别在脸上

中文海报：这次六步没有把字写坏

换背景：花园来了，人也被轻轻改了一下

换衣服：六步已经能拿来试造型

到底省了多少时间？

我会怎么把它放进工作台

本轮参数备忘

参考资料

口播视频的 API 账单有点贵，鬼哥把 Mac mini 和 4090 接成了一间 AI 演播室

两台机器，终于不用挤同一张床

/audio-studio：名字还是音频，里面已经能拍视频了

先看整套架构：页面在 Mac，重活在 4090

从音色和人物开始，再让她开口

Qwen 给 Diana 找声音，也给她换衣服

H3 收到配音后，会重新生成声画

模型之间怎么接力，任务怎么留下来

最后一公里：让字幕跟上 Diana 的嘴

从一段短口播开始，把试错留给自己

参考资料

一张 4090 跑 Gemma4 26B：用 Ollama 搭本地 AI 开发环境实测

先看结论

Ollama 解决了什么

先直接对话

接入 Codex：默认沙盒失败，授权后跑通

接入 Claude Code：真实可用

接入 Hermes Agent

4090 + Gemma4 26B 实测

显存、功耗和温度

一个容易误判的点：thinking 也算 token

适合怎么用

Takeaway

参考资料

`/audio-studio`：名字还是音频，里面已经能拍视频了