💰 AI 语音与视频实战指南（上）：语音克隆、音乐生成与会议输入
2026 年可能是「个人也能完成全流程音视频生产」的分水岭。语音克隆跑进四核 CPU、代码渲染视频不再需要剪辑师、多智能体流水线把数字人口播压到每条几元——门槛塌了之后，真正的问题从「能不能做」变成了「怎么做得又稳又省」。
本文是整个系列的上篇，先把音频侧的三条链路彻底拆开：语音克隆与 TTS 模型选型、可编辑的音乐生成、以及会议录音与麦克风替代。每一节都给出实测级的硬件门槛、可执行的安装命令、关键参数与避坑指南，并逐一纠正了流传甚广的认知误差。视频生产链路的完整拆解见下篇。
一、先看清格局：音视频生产的四层分工
在展开具体项目之前，有必要先建立一个统一的认知框架。音视频生产不是一条流水线，而是四层各自独立、可以分别选型的技术栈。
这个框架的核心价值在于：每一层都可以单独替换而不影响其他层。比如你在第七章提到的「音频优先架构」——先出配音再用音频时长反推分镜时长——就是层次解耦带来的直接收益。反之，如果把四层揉成一个黑盒工具，任何一处不满意就得整体重跑，这在生产上是不可接受的。
第二个关键认知是成本结构的位移。2026 年最大的变化是：代码渲染路线（Remotion、HyperFrames、video-talkcraft）的渲染成本降到了零，真正的开销转移到了模型调用费上。很多人算成本时只算了模型调用，却忽略了规模化后可能出现的工具授权最低消费（详见下篇「成本对照表」）。这一点我在下篇的成本章节详细展开。
第三个认知是本地化驱动力已经变了。原本推动本地部署的是隐私，但 2026 年真正的购买理由变成了合规与成本。具体证据和数据见本篇第四章「本地离线与云端 API 的真实取舍」。
二、语音链路：克隆与 TTS 模型选型
语音是整条链路的地基。视频的口播、有声书的旁白、数字人的声音，全部从这里出发。当前的开源生态提供了从「0.1B 跑在四核 CPU」到「2B 追求录音室级」���完整梯度，选型不再是「能不能用」的问题，而是「匹配哪段硬件预算」。
2.1 GPT-SoVITS：生态最全的少样本克隆工作台
仓库：https://github.com/RVC-Boss/GPT-SoVITS ｜ License：MIT（商用无限制）
GPT-SoVITS 是中文社区最活跃的语音克隆工具，也是很多人的入门首选。它的核心竞争力不在某个指标上的极致，而在于完整的工具链和教程生态——训练 WebUI、推理 WebUI、人声分离、Docker 部署一应俱全。
核心能力：Zero-shot 克隆只需 5 秒参考音频；Few-shot 微调只需 1 分钟训练数据。支持中、英、日、韩、粤五种语言。
版本线是选型的关键。官方同时维护 V1 / V2 / V2Pro / V3 / V4 五条线，共用同一套代码、通过启动参数切换：
官方给出了一条很有价值的选型建议（README 原文）：「训练集音频质量平均的情况下，v1/v2/v2Pro 能给出不错的结果，但 v3/v4 不能。此外 v3/v4 的合成音色和时长更倾向于参考音频而非整个训练集。」
这句话的实际含义是：如果你手里的训练集质量参差不齐，选 V2Pro；如果你有一批高质量录音，选 V4。这不是「越新越好」的简单逻辑。
性能数据（v2ProPlus，官方实测）：
安装：
conda create -n GPTSoVITS python=3.10
conda activate GPTSoVITS
# Linux / macOS
bash install.sh --device <CU126|CU128|ROCM|CPU> --source <HF|HF-Mirror|ModelScope>
# Windows PowerShell
pwsh -F install.ps1 --Device <CU126|CU128|CPU> --Source <HF|HF-Mirror|ModelScope>
Windows 用户有整合包，双击 go-webui.bat 即可。Linux/macOS 上入口脚本是 webui.py（训练）和 GPT_SoVITS/inference_webui.py（推理）。依赖 Python 3.9–3.12、PyTorch 2.5.1/2.7.0、ffmpeg、ffprobe。
关键参数：
训练侧：
batch_size、epochs、save_every_n_epoch、if_save_latest、if_save_every_weights推理侧：
ref_audio_path、prompt_text、prompt_lang、target_text、target_lang、speed_factor、fragment_length、split_method、seedDocker 环境下可用
is_half环境变量开启 fp16 降显存
避坑要点：
macOS GPU 训练质量明显偏低，官方已暂时改用 CPU 训练。Mac 用户若追求音质，建议直接考虑 VoxCPM2 的 Metal 后端。
中文需要额外下载 G2PWModel 放到
GPT_SoVITS/text目录，漏了会导致多音字读错。UVR5 人声分离模型文件名必须包含
roformer字样，且 config 与 ckpt 必须同名对应，否则不被识别。Docker Desktop 默认
shm_size过小会导致异常，需调整到 16g。官方从未公布过参数量。第三方文章常见的「GPT 模块 12 层 Transformer / 512 维」等数字来自技术拆解分析而非官方文档，引用时请注明来源。
2.2 VoxCPM2：Tokenizer-free 的方言与多语种高地
仓库：https://github.com/OpenBMB/VoxCPM ｜ License：Apache-2.0（可商用）｜ 论文：arXiv:2609.24650 / VoxCPM2 arXiv:2606.06928
VoxCPM 是面壁智能（OpenBMB）与清华大学深圳国际研究生院人机语音交互实验室（THUHCSI）联合研发的项目，归属上写「清华开源」不算错，但更准确的表述是深研院合作项目，MiniCPM 团队出品。
它的技术路线非常独特：Tokenizer-free。传统 TTS 先把音频离散化成 token 再建模，会损失信息；VoxCPM 直接在 AudioVAE V2 的潜空间里做端到端 diffusion autoregressive 生成，绕开了离散化环节。
版本演进很能说明问题：
「30+ 语言」是 VoxCPM2 才具备的能力，原始 0.5B 版本只有中英双语——这是版本混淆的高发点。30 种语言包括中、英、日、韩、俄、法、德、西、葡、越、泰、印尼、阿拉伯语、希伯来语、波兰语等，另支持 9 种中文方言：四川话、粤语、吴语、东北话、河南话、陕西话、山东话、天津话、闽南话。输入文本无需语言标签。
Ultimate Cloning 是它最实用的能力：同时提供参考音频和其转写文本，模型从参考处无缝续写，保留全部韵律细节。相比只给音频的方案，韵律保真度明显更好。
安装与调用：
# WebUI
python app.py
# LoRA 微调
python lora_ft_webui.py
wav = model.generate(
text="...",
reference_wav_path="path/to/voice.wav",
cfg_value=2.0, # 引导强度
inference_timesteps=10, # CFM 步数
seed=42,
)
端侧推理走 llama.cpp-omni（GGUF，原生支持 CPU/Metal/CUDA/Vulkan）：
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target voxcpm2-cli -j
./build/bin/voxcpm2-cli -t "文本" -r speaker.wav -o clone.wav \
VoxCPM2-BaseLM-Q8_0.gguf VoxCPM2-Acoustic-F16.gguf
M4 Pro / Metal 下 RTF 约 1.76（Q8_0 量化），完全可接受。官方还提供 vLLM-Omni recipe（带 PagedAttention 与 OpenAI 兼容 API），RTF 可降至约 0.13。
避坑要点：
可控生成稳定性不足——Voice Design 和 Controllable Cloning 每次运行结果可能不同，官方自己建议生成 1~3 次挑选。追求确定性的话，应优先用 Ultimate Cloning 模式。
官方明确禁止用于冒充、欺诈、虚假信息，并要求明确标注 AI 生成内容。
非 30 语言列表内的语种需自行微调。
2.3 MOSS-TTS-Nano：0.1B 参数把门槛压到四核 CPU
仓库：https://github.com/OpenMOSS/MOSS-TTS-Nano ｜ License：Apache-2.0 ｜ 发布：2026-04-10 ｜ 论文：arXiv:2603.18090
这是 2026 年最值得关注的新项目，也是本轮调研中「笔记信息命中率最高」的一条——原始笔记里的「0.1B / 四核 CPU / 流式 / 20种语言 / zero-shot 克隆」全部精确命中。
它由MOSI.AI + OpenMOSS 团队、复旦 NLP Lab 出品，规格如下：
20 种语言：中、英、德、西、法、日、意、匈、韩、俄、波斯、阿、波兰、葡、捷、丹、瑞、希、士。注意：官方未列出任何方言支持，如果你的需求是方言，VoxCPM2 更合适。
配套的 MOSS-Audio-Tokenizer-Nano 约 20M 参数，CNN-free 纯因果 Transformer，RVQ 16 层码本，12.5Hz token 流，可变码率 0.125–2 kbps。
安装：
conda create -n moss-tts-nano python=3.12 -y
conda activate moss-tts-nano
git clone https://github.com/OpenMOSS/MOSS-TTS-Nano.git && cd MOSS-TTS-Nano
pip install -r requirements.txt && pip install -e .
官方首推ONNX CPU 版：
python infer_onnx.py --prompt-audio-path assets/audio/zh_1.wav --text "..."
python app_onnx.py # FastAPI WebUI
# 需要 GPU 时需先卸载 CPU 版 onnxruntime
python infer_onnx.py --execution-provider cuda ...
也提供 PyTorch 版（infer.py）、CLI 打包（moss-tts-nano generate）、以及服务化方案（vLLM-Omni，提供 paged KV cache、streaming、OpenAI 兼容的 /v1/audio/speech）。
避坑要点：
pynini/WeTextProcessing安装冲突是最大痛点，官方给出 Conda workaround：bash conda install -c conda-forge pynini=2.1.6.post1 -y pip install git+https://github.com/WhizZest/WeTextProcessing.git pip install -r requirements.txt
非 Conda 环境需自行寻找匹配 Python 版本与平台的pyniniwheel。README 的 License 章节仍写着「若在 LICENSE 发布前读到此处，视为未授权再分发」——这是遗留文案，实际 LICENSE 文件已是 Apache-2.0。建议引用 LICENSE 文件本体。
音质定位为「实时产品够用」，非录音室级。它和 VoxCPM2 不是替代关系，而是「端侧 vs 精品」的分工。
2.4 腾讯 AuK：一个模型统一十六项音频任务
仓库：https://github.com/Tencent-Hunyuan/AuK ｜ License：MIT ｜ 发布：2026-09-09 ｜ 论文：arXiv:2609.08936
AuK 由腾讯混元 + 上海交通大学 + 上海创智学院联合研发，是目前功能边界最宽的语音模型。它的思路是：用一个模型替代串联 TTS / VC / 降噪 / 分离的多个专用模型，全部任务走同一个 message-based 接口。
16 项任务分五类：
架构上，生成器为 1.5B（MMDiT + single-stream DiT rectified-flow），语义编码器是 Qwen2.5-Omni-3B，配合 50Hz 音频 VAE。训练数据规模是 30.3 亿条指令-音频对 + 195万小时音频，经 RLHF 后训练。
⚠️ 显存数据必须纠正：原始笔记写「6GB 显存即可运行」，这是错的。官方在 A800-80GB 上用 torch.cuda.max_memory_allocated 实测：
最低约 17GB，这是消费级显卡的硬门槛。RTX 4090（24GB）关闭 offload 能否跑通，官方未给数据，建议实测。
安装与推理：
git clone https://github.com/Tencent-Hunyuan/AuK && cd AuK
uv venv --python 3.10 && source .venv/bin/activate
uv pip install -e ".[gradio]" # 或 [comfyui] / [train]
hf download tencent/AuK --local-dir ./ckpts/AuK
hf download tencent/AuK-Flash --local-dir ./ckpts/AuK-Flash
hf download Qwen/Qwen2.5-Omni-3B --local-dir ./ckpts/Qwen2.5-Omni-3B
# Zero-shot TTS
auk-infer --audio ref.wav \
--instruction "Say the following with the same voice: '...'" \
--output out.wav --gen_seconds 6.0
# AuK-Flash：4 步固定，CFG=0
auk-infer --ckpt ckpts/AuK-Flash/auk_flash.safetensors \
--cfg 0 --nfe 4 --sway -1 ...
--instruction 是必填项，这是 AuK 与其他模型最大的交互差异——你必须用自然语言描述「怎么说」，而不只是给文本。
避坑要点：
30 秒硬限制：源/参考音频 + 生成目标合计必须 ≤30 秒，且节点不会自动切分长音频。长内容必须自行分段。
ComfyUI 不支持自动 VRAM offload，需手动在 Loader 里开启
cpu_offload。Prompt Enhancer 读取
.env，必须在启动 ComfyUI 之前加载，否则报错。MLLM 编码器固定 Qwen2.5-Omni-3B，
--qwen_path不支持 Qwen3-Omni。加载 ckpt 时缺
text_encoder.*键是正常现象，编码器和 VAE 是运行时单独加载的。官方 README 的任务表未列出支持语种，中文任务示例存在，但覆盖几种语言、有无方言需查论文正文。
部署生态是AuK 的明显优势：Day-0 支持 SGLang-Omni、vLLM-Omni（单 H100 两阶段管线）、audio.cpp（GGUF --family auk）、Apple Silicon MLX、ComfyUI 官方节点、Gradio，另有完整微调管线。
2.5 abogen：从电子书到带章节的 M4B 有声书
仓库：https://github.com/denizsafak/abogen ｜ License：MIT ｜ 底层模型：Kokoro-82M（Apache-2.0）
abogen 解决的是一个具体但真实的需求：把手头的电子书批量转成能播的有声书。它支持 ePub、PDF、纯文本、Markdown 输入，另支持 TXT、SRT、ASS、VTT。
功能核实全部命中：
M4B 元数据标签写法（写在文本文件开头）：
<<METADATA_TITLE:Title>>
<<METADATA_ARTIST:Author>>
<<METADATA_ALBUM:Album Title>>
<<METADATA_YEAR:Year>>
<<METADATA_ALBUM_ARTIST:Album Artist>>
<<METADATA_COMPOSER:Narrator>>
<<METADATA_GENRE:Audiobook>>
<<METADATA_COVER_PATH:path/to/cover.jpg>>
安装（注意 espeak-ng 必须独立安装，Windows 还要 --index-strategy unsafe-best-match）：
# NVIDIA (Windows, CUDA 12.8)
uv tool install --python 3.12 abogen[cuda] \
--extra-index-url https://download.pytorch.org/whl/cu128 \
--index-strategy unsafe-best-match
# AMD (Linux, ROCm 6.4)
uv tool install --python 3.12 abogen[rocm] \
--extra-index-url https://download.pytorch.org/whl/nightly/rocm6.4 \
--index-strategy unsafe-best-match
# 纯 CPU
uv tool install --python 3.12 abogen
关键参数：语速 0.1x–2.0x；字幕粒度可选 Disabled / Line / Sentence / Sentence+Comma / Sentence+Highlighting / 1-3 words / 自定义；字幕格式支持 SRT 与 ASS（宽/窄/居中宽/居中窄）；输出音频支持 WAV / FLAC / MP3 / OPUS（压缩最佳） / M4B（带章节）；字幕变速策略有 TTS Regeneration（音质好）与 FFmpeg Time-stretch（速度快）两档；另有章节静音间隔与语音混音器（按权重混合 Kokoro 语音并存为 profile）可调。
避坑要点：
单词级字幕仅对英文有效——Kokoro 只为英文提供时间戳 token，中文/日文只能走句子和逗号切分，字幕会偏长。这是中文用户最需要预期管理的限制。
AMD/ROCm 仅 Linux，Windows 用户无法加速。
界面是 PyQt6 桌面端 + 独立的
abogen-web（Flask，端口 8808），两者功能不完全对等——Supertonic TTS、LLM 文本规范化、Audiobookshelf 集成目前只在 web 端。Docker 部署需处理 UID/GID 文件权限；Nginx 反代时需关闭
Block Common Exploits（会剥掉 Authorization 头）。
同类的另一个选择：Audiobook Creator（https://github.com/ezionian/audiobook-creator ）满足部分相同描述，但多出一个 abogen 没有的能力——多声线按角色分配（GLiNER NER + LLM 判定性别年龄）。代价是License 为 GPL-3.0（有传染性），且必须自备 OpenAI 兼容 LLM + Kokoro-FastAPI 服务，Docker 需同时起三个服务并依赖 host 网络，Apple Silicon 走 CPU。
2.6 VoiceStudio：本地 ElevenLabs 替代品
仓库：https://github.com/debpalash/VoiceStudio ｜ 官网：voicestudio.sh ｜ License：AGPL-3.0 ⚠️
VoiceStudio 的定位是「一站式本地语音工作台」，覆盖语音识别、声音设计、语音克隆、视频配音、文字转有声书六项功能，数据全部本地存储。
规模上它是最全的：16 个 TTS 引擎 + 11 个 ASR 引擎，架构为 Electron 桌面壳 + Python FastAPI 后端（仅监听 3900 端口）。
⚠️ 「0 成本」这个说法需要重新表述。 官方描述的确切含义是：没有账号、没有 API key、没有订阅、没有按字符计费，唯一支出是你自己的 CPU/GPU 时间。所以「零 API 费用」成立，但软件本身不是零成本——它是 AGPL-3.0。
商用风险是本次核查中最关键发现：
应用层 AGPL-3.0，允许免费商用，但网络部署（SaaS）会触发源码开放义务
模型权重各持独立许可。README 明确警告：默认 OmniVoice 预训练权重标记为 CC-BY-NC（非商业）
官方结论是「模型许可不限制生成音频，但选模型前必须逐个确认」
若要用于客户的有偿项目，默认引擎 OmniVoice 因CC-BY-NC 直接不可用，必须换引擎
硬件要求：GPU 可选，4GB 显存为加速下限，推荐 8GB+；大型可选引擎需 12–16GB+。CPU 可跑但建议轻量引擎（KittenTTS / Supertonic-3 / PocketTTS）。Intel Mac 无法运行本地后端（PyTorch wheel 不可用），只能连远程后端。
安装：
curl -fsSL https://voicestudio.sh/install | sh
curl -fsSL https://voicestudio.sh/install | sh -s -- --version X.Y.Z
curl -fsSL https://voicestudio.sh/install | sh -s -- --uninstall
也可从 Releases 下载 macOS DMG / Windows x64 installer / Linux AppImage / Docker。
关键参数：
克隆参考音频：3 秒为下限，官方建议 5–15 秒干净单人录音
本地 API（OpenAI 兼容）：
http://localhost:3900/v1MCP：
http://localhost:3900/mcp支持 HTTP / SSE / WebSocket
支持 CUDA / MPS / MLX / ROCm / CPU 四类后端自动路由
避坑要点：
安装包未签名（macOS 未做 notarization），系统必然告警，须从官方 Release 下载并校验 SHA-256。
646 种语言容易被误读——这是 16 个 TTS + 11 个 ASR 引擎的目录合计值，单一引擎通常只支持 9–31 种。
架构变更警告：README 明确「Electron 是唯一的桌面应用与 Web UI，0.5.3 版是最后一个 Tauri 版本」。若参考资料写「Tauri v2 桌面应用」，说明信息已过时。
首次启动要下载数 GB 模型。
注意
latentforge/VoiceStudio（11 stars，Apache-2.0）是另一个同名无关项目，不要混淆。
2.7 横向对比与选型决策树
基础参数与适用场景（✅ 表示支持或无限制，❌ 表示不支持）：
关于「语言数」的常见误读：VoiceStudio 的 646 种是 16 个 TTS + 11 个 ASR 引擎的目录合计值，单一引擎通常只支持 9–31 种。
选型决策树：
关于有声书生成的补充建议：若你的核心需求是「单工具、开箱即用」，选 abogen；若核心需求是「多人角色有声书」，选 Audiobook Creator，但必须提前接受 GPL-3.0 的传染性和更复杂的服务编排。
三、音乐链路：可编辑的音乐生成
「从歌词生成歌曲」现在已经不稀缺了，真正的分水岭是能否编辑。这一节的核心项目 YuE2 之所以值得关注，正是因为它把音乐生成从「盲盒」变成了「可读可改的工程」。
3.1 YuE2：把乐谱变成可读可改的控制面板
仓库：https://github.com/multimodal-art-projection/YuE ｜ License：代码/文档/agent skill 为 Apache-2.0，模型权重为 CC BY-NC 4.0 + 附加创作者许可 ｜ 论文：arXiv:2609.33757
在展开之前必须先澄清一个常见误解：ACE-Step 和 YuE2 解决的是两个不同的问题。ACE-Step 是「歌词生成歌曲」这一半的正确答案，但它没有乐谱层——官方 README 中 midi、notation、symbolic、score（作为乐谱义）零命中。而笔记里「编辑乐谱调整旋律、和弦」这个描述，精确指向YuE2。
YuE2 官方 README 第 66 行的原��最能说明它的设计哲学：
White-box music generation through symbolic planning. Read, play, and change the composition before rendering it. Melody and chords become explicit controls that a person or an agent can inspect and edit.
技术架构：单个 AR–NAR Mixture-of-Transformers 骨干——自回归预测记谱与语义 token，再用 flow matching 生成声学 latent，VAE 解码成立体声。
核心是用 ABC 记谱（不是 MIDI）做规划层，四个关键设置：
ABC 记谱相比 MIDI 的优势在于文本可读、可 diff、可被 agent 直接修改。这对于「让 AI 帮你改歌」的场景是决定性的——MIDI 是二进制结构，agent 难以可靠地编辑；ABC 记谱是纯文本，agent 读得懂、改得动。
ComfyUI 支持是官方原生且已合并：comfyanonymous/ComfyUI#16250「Support Yue2 music model.」创建并合并于 2026-09-11。要求 ComfyUI ≥ v0.35.0（AMD GPU 建议 ≥ v0.35.1）。
模型放置路径：
ComfyUI/models/checkpoints/yue2_3b_int8_convrot.safetensors
ComfyUI/models/audio_encoders/sheetsage2_bf16.safetensors # 仅 cover 需要
ComfyUI 节点的真实参数（以下数字均来自官方文档）：
上下文不足时会自动降预算并在控制台告警：YuE2 music budget reduced to ... tokens (... seconds) to fit the prompt.；完全无空间时报 YuE2 prompt leaves no room for music; shorten the style, lyrics, or ABC.；乐谱被截断会报 YuE2 abc reached its token budget before the end token.，此时需调高 max_abc_tokens。
⚠️ 硬件门槛必须说清。官方明确要求：
Linux · Python 3.12 · NVIDIA GPU with BF16 support and 24 GB VRAM. YuE2 produces 48 kHz stereo audio without quantization.
而 ComfyUI 提供的是 yue2_3b_int8_convrot——int8 量化 + convrot 版本。这就是「官方要求 24GB」与「ComfyUI 能跑在消费级卡上」差异的来源。同一模型在两条路径上的硬件要求差4–6 倍。写方案时必须说清走的是哪条路，否则会误导读者。
Cover 工作流（这是 YuE2 最有差异化的能力）：
Reference Audio → SheetSage2(转录) → Melody ABC 乐谱 → YuE2(新风格 + 新歌词)
关键限制：因为连接原曲的只有旋律，所以新歌词「stay reasonably close to the original phrasing and syllable count」时匹配度最好。建议 cot="melody" + 不带和弦符号的乐谱。
安装：
git clone https://github.com/multimodal-art-projection/YuE.git
cd YuE
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip && python -m pip install .
python examples/generate.py --output outputs/first-song
输出 outputs/first-song/audio.flac，同目录会保留 score、semantic tokens、acoustic latents、生成设置与模型标识——这点对「可审计的生成过程」很有价值。
3.2 ACE-Step：音频域编辑的另一种哲学
如果笔记里指的是「MIDI 导入/导出 + 钢琴卷帘」，最匹配的则是 Plenio（仅 27 star，小众实验项目）；而如果核心诉求是「音频域的编辑能力」，ACE-Step 是这个方向的答案。
两个版本需注意区分：ACE-Step v1（ace-step/ACE-Step，4,881 star，Apache-2.0）已于 2026-02-15 停更；ACE-Step 1.5（ace-step/ACE-Step-1.5，13,073 star，MIT）仍活跃，最后推送 2026-10-05。
v1 的编辑能力（全部为音频域操作，无乐谱/MIDI）：Text2Music / Retake（variance 调节）/ Repainting（指定起止秒数重绘）/ Edit（only_lyrics 保留旋律 vs remix 改变旋律）/ Extend。另有 lyric2vocal、text2sample、RapMachine、StemGen、singing2accompaniment 等 LoRA。
⚠️ 必须澄清的常见混淆：v1.5 支持 BPM / key / scale / 拍号元数据控制——这是元数据控制，不是乐谱编辑，两者常被混为一谈。若你需要真正的旋律/和弦编辑，请用 YuE2。
v1.5 的硬件矩阵（官方README）：≤6GB 用 2B turbo + INT8 量化 + 全 CPU offload（无需 LM）；6–8GB 加 acestep-5Hz-lm-0.6B；8–16GB 可上 1.7B LM（后端 vllm）；16–20GB 用 2B sft 或 XL turbo（XL 需 offload）；20–24GB XL 无需 offload；≥24GB 可用 acestep-5Hz-lm-4B。
其他事实：时长 10 秒–10 分钟；50+ 语言（中英日韩西德法意俄优化）；<4GB VRAM 可跑；A100 <2 秒/首、RTX 3090 <10 秒/首；LoRA 训练「8 首、3090 上 1 小时」。XL 系列（4B DiT）权重约 9GB bf16（2B 为 4.7GB）。
避坑要点：ComfyUI 官方在 2026-02-03 公告 ACE-Step 1.5 支持时明确说明「Cover、Repaint 等功能尚未在 ComfyUI 中支持」。若需要 text→music 之外的编辑，需等官方模板更新，或用第三方节点（hiroki-abe-58/ComfyUI-AceMusic）。
⚠️ 内容安全提示：中文社区流传的两篇 CSDN「ComfyUI_ACE-Step」介绍文章为 AI 生成的伪造内容，文中给出的
https://github.com/ACE-Studio/comfyui-ace-step仓库返回 404，不存在。文中「上传 MIDI 做旋律引导」「乐器比例参数节点」等描述均无对应实现，请勿引用。
3.3 ComfyUI 落地与工程要点
综合两个项目，在 ComfyUI 中做音乐生成的实践要点：
模型放置：YuE2 用
yue2_3b_int8_convrot.safetensors（int8 量化，消费级卡可行）；ACE-Step 1.5 按显存按上表选 2B 或 XL。显存预判：ACE-Step 1.5 在 ≤6GB 显存下可跑但需全 CPU offload；YuE2 的 int8 版在 8–12GB 区间较舒适。两者都不建议在 4GB 以下尝试。
时长控制：两者都受 token 预算约束。YuE2 的每秒 25 个 semantic token 是硬性开销，
Max Duration上限 900 秒，但实际生成时长受 prompt 总长度挤占。可复现性：YuE2 保留完整的 score / semantic tokens / acoustic latents / 生成设置，出了问题可以直接回溯到具体环节；ACE-Step 1.5 无此便利。
版权状态：YuE2 权重是 CC BY-NC 4.0 + 附加创作者许可，商用需仔细阅读附加条款；ACE-Step 1.5 是 MIT，但需确认权重与训练数据的商用边界。