Open WebUI on 鬼哥的空间

口播视频的 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 再开口。鬼哥这次要看的，是她有没有把话说好。

参考资料

32G 的 M6 Mac mini，怎么同时养活聊天和画图两个大模型

Fri, 25 Sep 2026 00:00:00 +0000

新 Mac mini 让人等了快两年。8 月 25 日，苹果终于发布了新款，入门款是苹果第一颗 2nm 芯片 M6，高配款是 M5 Pro。

鬼哥盯着 M5 Pro 看了很久。64G 内存，带宽快了将近一倍，拿来跑本地大模型确实香。可顶配要 3199 美元，折合两万多人民币。鬼哥掐指一算：这得是多少碗米粉。

最后下单的是 M6、32G 那一款。为了它，鬼哥省了好几个月早餐的米粉加一个蛋。

倒也不全是穷。鬼哥的主力工作，写代码、查资料、改长文，都是靠 Claude 和 Codex 的订阅在云端完成的。本地模型对鬼哥来说还是探索：看看它在写作、内容创作、日常开发里到底能帮上多少忙。为一个还在摸索的爱好，把早餐钱全搭进去，不太划算。

问题就来了：32G 这个"够用的下限"，能不能撑起一台私人 AI 工作站？不连云、不花 API 费，能陪鬼哥写东西，也能按一句话画出一张像样的图。

鬼哥决定从写作和内容创作开始试。折腾了两个晚上，答案是能。不过真正难的地方，跟一开始想的不一样。

先让它开口：一行命令的 Open WebUI

机器上原本就装着 Ollama，拉好了 Qwen3.8 的 27B 模型。缺的是一个像样的聊天界面。

Open WebUI 基本就是一个自己托管的 ChatGPT 网页版，对话历史、多用户、知识库、联网搜索一应俱全，还能接各种模型。鬼哥原以为要跟 Python 环境搏斗一晚上，结果官方包用 uv 一行就能跑：

1

DATA_DIR=~/.open-webui uvx --python 3.11 open-webui@latest serve

指定 Python 3.11，是因为 Open WebUI 只认 3.11 到 3.12，而鬼哥系统里的 Python 已经 3.14 了，太新，人家不要。浏览器打开 localhost:8080，第一个注册的账号自动当管理员。它会自己找到本机 11434 端口上的 Ollama，下拉框里直接就有 qwen3.8。

第一题鬼哥出得有点刁：用辛弃疾《青玉案·元夕》的场景，写一篇书生和姑娘惊鸿一瞥的小故事。

它写了一千来字，题目叫《灯火阑珊》。开头是"元宵那夜，汴京的东风是带着花香来的"，结尾有一句鬼哥挺喜欢：

他写的时候手是稳的，可墨迹落纸，“阑珊"二字却洇开了。

一台比饭盒大不了多少的盒子，能写到这个份上，鬼哥是有点意外的。当然也有翻车的地方：写到烟花炸开那句，它突然冒出一个 “fireworks”。辛弃疾要是看到自己的元宵节里放的是洋烟花，大概也会洇开。

Open WebUI 在每条回复下面记了速度：这篇生成了 1021 个 token，每秒约 14 个；读入提示词每秒约 276 个 token。从回车到写完，不到两分钟。

模型在内存里占 18G 左右，是 27.8B 参数、nvfp4 量化的 MLX 版本。其他几段对话里，生成速度大多在每秒 14 到 20 个 token 之间，比鬼哥读小说的速度快。

还有个意外之喜：Open WebUI 默认监听所有网卡，所以装了 Tailscale 的其他设备，用 http://mac-mini的机器名:8080 就能直接访问。桌上这台 Mac mini，从此成了随身 AI 的后端。

想让它画画，先撞上一堵 33G 的墙

会写字了，自然想让它会画画。鬼哥看中的是 Qwen-Image-2.1：7B 参数的图像生成模型，文字渲染是出了名的强，还支持图片编辑和透明背景。

打开模型页，算了一下账：

组件	官方 BF16 大小
文本编码器（Qwen3-VL-8B）	17.5 GB
图像生成模型（7B DiT）	14.2 GB
VAE	1.4 GB
合计	33.1 GB

鬼哥的机器是 32G。差了 1G，就像米粉钱差一块，老板也不会给你加蛋。

这里得先说清楚 Mac 的内存是怎么回事。PC 上，显卡有自己的显存，显存不够时可以把模型"卸载到内存”。Mac 的 CPU 和 GPU 共用同一块统一内存，所谓卸载到内存，就是把东西从左边口袋放进右边口袋，总重量一克没少。何况 macOS 默认也不会把全部内存都分给 GPU。所以官方示例里的 enable_model_cpu_offload()，在这台机器上帮不了什么忙。

解法是量化。ComfyUI 官方整理了一套 int8 版本：图像模型 7.3G，文本编码器 9.4G，VAE 0.7G，一共 17.3G，差不多瘦身一半。

接下来要挑一个生图工具。Mac 上最省事的是 Draw Things，原生 App，对 Apple 芯片做了深度优化。但鬼哥想要的是在 Open WebUI 里聊着天就能出图，这条路只有 ComfyUI 走得通：它自带 API，Open WebUI 支持把它当生图后端。ComfyUI 的界面是一块节点画布，加载模型、编码提示词、采样、解码、保存，每一步一个方块，用线连起来。第一次看像在拆电视机，看熟了发现什么都能拆开调。

安装本身不复杂：克隆仓库，用 uv 建一个 Python 3.13 环境，装 PyTorch nightly（Mac 上靠它的 MPS 后端调用 GPU），再把三个模型文件放进对应的文件夹。更省心的是，ComfyUI 自带的模板里已经有 Qwen-Image-2.1 的文生图工作流，用的正是这套 int8 文件，推荐参数是 25 步、CFG 1、euler 采样器。鬼哥照着它写了一份 API 格式的工作流，自己测试用，也给 Open WebUI 用。

第一张图：招牌上的字，一个都没错

测试提示词是模型卡上的例子：雨夜里一块霓虹招牌，写着 “QWEN IMAGE 2.1”，湿漉漉的路面有倒影。

1024×1024、25 步，用了 222 秒，每步大约 8 秒。够鬼哥下楼嗦半碗粉。

慢是真慢，但看到图的那一刻，鬼哥原谅它了。“QWEN” 是冷白色的霓虹管，“IMAGE 2.1” 是红色，字母一个没错，连 2 和 1 中间的小数点都在。地面上红灯的倒影、斑马线、远处橱窗里的灯，都像雨夜里手机随手一拍。几年前，本地生图模型写字还像鬼画符。

接入 Open WebUI 之后，鬼哥又画了几张。最喜欢的是这张北京微缩沙盘：长城沿着山脊蜿蜒，故宫、天坛、鸟巢、水立方、央视大楼挤在同一块地图上，浅景深把周围的地图虚化掉，很像旅行杂志的内页。

它也有露怯的时候。让它画一页插画师的手绘设定稿，人物的造型、表情、比例都很有样子，页面上那些手写批注却全是天书。它擅长的是提示词里点名要写的大字；画面里顺手添的小字，基本就是装饰花纹。

还有一张时装人像，左下角冒出来一个谁也没要求的"签名"，看着还挺像那么回事。鬼哥第一反应是在负面提示词里写上"不要水印"，查了参数才发现写了也白写：这套工作流的 CFG 是 1，负面提示词根本不起作用。想去掉签名，得把 “no text, no watermark, no signature” 这类要求直接写进正面提示词。官方模板的示例提示词，结尾就是一长串 “no text, no letters, no logos, no watermark”，看来官方早就防着它这一手。

两个大模型，挤不进同一块内存

聊天和生图各自都能跑了，鬼哥在 Open WebUI 的图像设置里填上 ComfyUI 的地址，上传工作流，把提示词、尺寸、步数、种子分别对应到工作流里的节点。然后在聊天框里打开生图开关，直接用中文描述想要的画面。

流程是这样的：Qwen3.8 先把你的描述扩写成一段详细的英文提示词，交给 ComfyUI；四分钟后，图片出现在对话里，Qwen3.8 再补一句说明。

第一次端到端跑通，图出来了，鬼哥顺手看了一眼系统状态，笑容凝固了：swap 已用从 4G 涨到了 14G，交换空间上限才 15G。

原因不复杂，但事先没想到：两边都舍不得放下模型。Ollama 默认会把模型在内存里留 5 分钟，方便你接着聊；ComfyUI 出完图，也会把模型留着，方便画下一张。Qwen3.8 刚写完提示词，占着 18G 不走，ComfyUI 紧接着又要加载将近 17G 的生图模型。两个加起来超过 32G，macOS 只能把内存往 SSD 上的 swap 里硬塞。

两个胖子挤一张单人床，谁也睡不好。这次速度倒没怎么掉，但每生成一张图，SSD 上就要写进去十来 G 的 swap。swap 一旦用满，轻则卡顿，重则进程被系统请出去。

**在 32G 的统一内存上，两个大模型不能同时在内存里，只能轮流用。**如果当初买的是 64G 的 M5 Pro，这一节大概可以直接跳过。可谁让鬼哥省下的只是米粉钱，那就只能让它们学会排队。一共三处调整。

第一处，让 Ollama 早点放手。鬼哥先用 launchctl setenv OLLAMA_KEEP_ALIVE 1m 把全局保留时间改成 1 分钟，然后就以为万事大吉了。后来查进程的环境变量才发现，Ollama 一直没重启，这个设置根本没生效。真正起作用的，是在 Open WebUI 里给 qwen3.8 设的 keep_alive = 1m。这个设置存在 Open WebUI 的数据库里，电脑重启也不会丢。

第二处，ComfyUI 一接到任务，就立刻请 Ollama 让位。Qwen3.8 的提示词已经写完、交到 ComfyUI 手里了，这一步它没事可干，占着位置纯属浪费。鬼哥在 ComfyUI 的起停脚本里加了一个后台循环：发现队列从空变成有任务，就查一下 Ollama 当前加载了哪些模型，挨个发一个 keep_alive: 0 的请求。这只是把模型请出内存，文件还在硬盘上。

第三处，ComfyUI 出完图，5 秒内收拾走人。这里 Mac 又有个特别的地方：ComfyUI 的 /free 接口，只带 unload_models 参数的话，模型只是从"显存"挪到"内存"，在 Mac 上又是左口袋换右口袋。必须同时带上 free_memory，把节点缓存也清掉，内存才会真正还回来。实测，出完图后 ComfyUI 的内存占用从 9.8G 降到了 0.6G。

第一处调整之后，鬼哥每改一步就盯一次生图，每 5 秒记一次 swap。三次记录放在一起看：

	只把 keep_alive 改成 1 分钟	再加上生图开始时卸载 Ollama	再加上出图后 5 秒释放
生图开始时 swap 峰值	15.5 GB	3.7 GB	4.0 GB
生图过程中 swap	约 5 GB	3.7 GB	3.8 GB
出图后 swap 峰值	—	12.0 GB	7.5 GB，几秒后回落
1024 图耗时	243 秒	234 秒	235 秒

最后那 3.8G 是其他程序早先换出去的内存，一直留在 swap 里，跟这套工作站无关。出图后那几秒的小峰值，是 Qwen3.8 急着回来写回复，ComfyUI 还没来得及收拾完，两边在门口撞了一下。内存压力不大，鬼哥决定不跟它计较。

现在这台工作站长什么样

整理下来，一次"聊着天出张图"的完整过程是这样的：

鬼哥在 Open WebUI 里用中文说想要什么画面；
Qwen3.8-27B 把它写成详细的英文提示词；
ComfyUI 接到任务，先请 Ollama 把 Qwen3.8 卸载掉，再加载 Qwen-Image-2.1 的 int8 模型；
大约 4 分钟后出图，图片回到对话里；
ComfyUI 5 秒内释放模型，Qwen3.8 重新加载，补一句说明。

有几件事最好提前知道。速度上，一张 1024 的图要 4 分钟左右；官方默认的 2048 尺寸像素是它的 4 倍，按比例估算要十几分钟，这个鬼哥还没试，怕等到饿。许可上，Qwen-Image-2.1 用的是 Qwen Research License，个人研究和玩没问题，商用要先读条款。至于 Open WebUI 本身，0.11.4 版本新建对话时生成标题会报一个 KeyError，对话只是没有自动标题，其他功能都正常，等上游修就好。

它不会比云端服务快，也不会比云端的旗舰模型聪明。但写故事、改文章、画张配图这类日常活，它都能在鬼哥的桌上完成：数据不出门，不按次计费，断网也能用。深夜想到一个画面，不用先去看 API 余额，这一点比预想的更让人舒服。何况这台机器是用早餐钱换的，每多画一张图，那几个月的蛋就吃得更值一点。

回到那个元夕故事。那天夜里，书生在灯海里寻了那个姑娘千百回，最后在一盏快燃尽的旧灯下找到了她。这台 Mac mini 上的两个大模型，比那两个人好安排：一个写完提示词就退场，一个画完图也退场，同一时刻，内存里只留一个。

32G 统一内存能同时装下的大模型，其实只有一个。它能当私人 AI 工作站，靠的是让两个模型轮流用这块内存。

这篇文章的封面，也是这台 Mac mini 上的 Qwen-Image-2.1 画的：1344×768，大约 8 分钟。

附：关键配置速查

Open WebUI 图像设置（管理员面板 → 设置 → 图像）

设置项	值
引擎	ComfyUI
Base URL	`http://127.0.0.1:8188`
默认模型	`qwen_image_2.1_int8_convrot.safetensors`
尺寸 / 步数	`1024x1024` / `25`
节点映射	prompt → 文本编码节点的 `prompt`；width/height → EmptyLatentImage；steps/seed → KSampler；model → UNETLoader 的 `unet_name`

模型文件（来自 Comfy-Org/Qwen-Image-2.1）

1
2
3


models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors 7.3 GB
models/text_encoders/qwen3vl_8b_int8_convrot.safetensors 9.4 GB
models/vae/qwen_image_2.1_vae_bf16.safetensors 0.7 GB

让两个模型轮流用内存的核心逻辑（ComfyUI 起停脚本里的后台循环）

1
2
3
4
5
6
7
8


# 队列从空闲变成有任务：卸载 Ollama 里所有已加载的模型
for name in $(curl -s localhost:11434/api/ps | grep -o '"name":"[^"]*"' | cut -d'"' -f4); do
 curl -s localhost:11434/api/generate -d "{\"model\": \"$name\", \"keep_alive\": 0}" >/dev/null
done

# 队列空闲 5 秒：卸载 ComfyUI 的模型并清掉缓存（Mac 上两个参数缺一不可）
curl -s localhost:8188/free -H 'Content-Type: application/json' \
 -d '{"unload_models": true, "free_memory": true}'

Open WebUI on 鬼哥的空间

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

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

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

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

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

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

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

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

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

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

参考资料

32G 的 M6 Mac mini，怎么同时养活聊天和画图两个大模型

先让它开口：一行命令的 Open WebUI

想让它画画，先撞上一堵 33G 的墙

第一张图：招牌上的字，一个都没错

两个大模型，挤不进同一块内存

现在这台工作站长什么样

附：关键配置速查

参考资料

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