音乐大模型的闭环之困：从表示、长歌生成到可编辑交付
2026 年的音乐模型已经能生成几分钟的完整歌曲，也能听歌问答、续写段落、替换局部、导出 stem，甚至在演奏中实时响应。单看 demo，音乐似乎早该有自己的 ChatGPT 时刻。把这些能力放进同一条创作链，裂缝又会出现：理解模型输出文字，生成器预测 codec token 或连续 latent，评价器给一段音频打分，编辑器重写波形区间，产品最后用分轨、转写和时间线把它们接起来。能力都在，状态没有贯通。
本文把音乐的 LLM moment 定义为一个可检验的系统性质：系统能在同一首作品上完成 听取 → 理解 → 规划 → 生成 → 评价 → 编辑 → 交付，并让用户意图、音乐结构、声学细节、修改历史与权利信息在各环节保持可追踪的一致性。这个判据比“能生成好听样本”严格，也比“所有能力必须塞进一个神经网络”更实用。产品可以由多个模型组成；关键是接口是否保存了下一步真正需要的状态，评价结果能否触发可验证的修改。
基于截至 2026-07-11 核验的论文、模型页、代码与产品文档，本文的结论是：音乐基础模型已经越过单点生成阶段，并在统一入口、共享骨干和可传递中间状态上取得进展；在本文核验的公开语料中，尚未发现一个 music-native 系统把歌曲级理解、可执行规划、生成、诊断、迭代编辑与可继续制作的交付对象闭合起来。本文据此把跨阶段状态协议识别为核心问题之一；数据与评价有效性、训练许可、实时算力和真实创作者研究仍是并列限制。
1. 范围、方法与判据
Queen Mary University of London 牵头的多机构 Foundation Models for Music: A Survey(2024) 已经系统梳理表示学习、生成、多模态模型、数据、评价与伦理。本文保留这一宽范围，但换一个问题：这些进展能否组成音乐创作闭环？时间主轴覆盖 2022—2026 年，必要时追溯神经音频编码、音乐信息检索和文本偏好学习。音乐是主体；语音、通用音频、图像和视频只在它们提供可迁移的接口或评价方法时出现。
检索采用时间跨度优先、近期工作日期优先的组合。Hugging Face Papers 用于发现和读取 arXiv 全文，关键方法、机构、年份和实验边界再回到论文首页、正文、正式项目页或官方仓库核验。查询覆盖 music foundation model、music/audio language model、song generation、music tokenizer/codec、preference/reward/evaluation、editing、real-time 与 provenance。既有本地证据库用于保证范围不收缩。这是一篇叙事性、证据导向综述；数据库没有穷尽，未检索到的系统也不据此判定为不存在。
证据分四层：论文正文支撑方法和实验；官方代码或模型页支撑开放内容；产品文档只支撑用户可见功能；跨论文比较形成本文判断。闭源产品的功能不能反推出训练数据、主干架构、DPO/RLHF、内部 song object 或线上排序机制。
闭环判据包含六项能力要求与一项跨阶段追踪要求：
| 环节 | 最低可验证能力 | 常见替代指标为何不够 |
|---|---|---|
| 理解 | 从音频中定位段落、节拍、旋律、歌词、人声与制作属性 | 会写 caption 可能依赖语言先验，也未必给出可靠时间坐标 |
| 规划 | 产生可检查、可执行、可干预的修改计划 | 一段自然语言解释或隐藏 CoT 不等于 renderer 能消费的状态 |
| 生成 | 在长时结构、歌词和声学质量上实现计划 | 好听的短片段不能证明整首作品的结构与可控性 |
| 评价 | 说明哪里好、哪里错，给出不确定性与适用人群 | FAD、CLAP 或单一 reward 只覆盖部分质量 |
| 编辑 | 改变目标属性，同时保持非目标属性和边界连续 | 重新生成一段 waveform 不等于可重复、可撤销的工程编辑 |
| 交付 | 输出 mix、stem、时间线或其他可继续制作的对象，并保留来源记录 | 下载音频文件不等于完成创作工作流与 provenance |
| 跨阶段追踪 | 每次分析、计划、生成、评分和编辑都引用同一作品版本、时间坐标与对象 | 六项能力分别存在，仍可能无法形成可验证循环 |
2. 共同坐标系：音乐模型到底在传递什么
文本 LLM 的优势不只来自离散 token。输入、推理草稿、工具参数、回答和偏好反馈大多仍能落回文字。音乐包含多层时间对象：波形和频谱承载音色、瞬态、空间与母带；演奏层包含力度、唱法和 groove；音乐结构包含旋律、和声、节拍、段落与重复变奏；歌词还要处理语言、音素、时值和 melisma；制作层则关心 stem、take、区域、自动化曲线和版本历史。
Google Research 的 MuLan(2022) 把音乐音频与自然语言对齐到共同 embedding，Google Research 的 MusicLM(2023) 随后用文本条件、语义 token 与声学 token 分级生成音乐。Meta FAIR 的 MusicGen(2023) 则把 EnCodec 的多组 RVQ token 交给单阶段 AR Transformer，并专门设计 codebook delay pattern。两条路线都能生成强音频，也都揭示同一事实：音乐进入生成器前已经被某个表示系统重新定义。
表示至少承担四种不同职责：
- 重建：decoder 能否恢复人声、乐器、瞬态、空间和混音。
- 语义：风格、乐器、歌词与结构是否容易被识别和条件化。
- 可学习性：在固定训练预算下，AR、diffusion 或 flow 是否容易建模这个空间。
- 可编辑性：局部变化能否保持其余内容，偏离训练流形的 latent 能否被稳定解码。
这些目标可以协同，也会冲突。音乐领域尚无证据表明一个 token 空间在相同码率、模型规模和训练预算下同时最优。现有系统的主流做法是分解：语义与声学、推理与重建、人声与伴奏、结构计划与渲染状态分别编码，再设计接口连接它们。
本文所说的共享状态协议是一组最低可操作约束。每首作品与每次修改拥有稳定的 ID 和版本父子关系；段落、歌词、和弦、stem 与声学区间使用可互相换算的时间坐标；计划必须声明目标对象、目标变化和需要保持的不变量；评价必须引用具体版本、区间和对象，并能触发一个可执行动作；交付记录输入素材、模型/工具、编辑操作和输出资产之间的关系。一个系统只有在修改后仍能追踪这些字段，并验证“目标发生变化、非目标保持、历史可回放”，才通过协议判据。协议不要求所有字段由同一神经网络生成。
Music-native 在本文中指音乐结构参与模型的训练、状态传递和评价，而非把 music 当作通用音频任务列表中的一个标签。系统至少要显式处理段落/节拍/旋律/和声、歌词/演唱或 stem/制作对象中的一类，并让这些对象进入生成或编辑验证。UALM、UniAudio 2.0、Audio-Omni 等 general-audio 系统因此仍是重要正例；它们需要额外的歌曲级证据才能满足本文的 music-native 闭环判据。
3. 作品内状态如何从感知走到生成
以下三节采用同一个组织单位：每节都是作品状态从感知到生成时的一次相邻转换，依次回答波形如何成为模型状态、局部状态如何成为完整作品、理解结果如何成为可执行操作。论文可以跨越多节；分类对象是状态转换，不是模型所属的唯一流派。
3.1 波形到模型状态：表示从压缩器变成训练对象
早期神经 codec 常以重建和码率为中心。生成模型把问题改了：token 序列的帧率决定上下文长度，codebook 的相关结构决定 next-token 难度，latent 的几何决定噪声轨迹是否容易学习，decoder 还要处理生成状态偏离真实编码分布的情况。
M-A-P、Manchester、Sheffield、CMU 与 HKUST 等机构合作的 MERT(2023) 和 ByteDance SAMI 的 MusicFM(2023) 先在理解侧证明，音乐表征需要保留音高、节拍、和弦、结构与标签信息。它们是 MIR encoder，并不生成音频。后来的生成系统开始把这类 teacher 放进表示或生成器内部。
Stability AI 的 Stable Audio 3.0(2026) 用 SAME 把 44.1 kHz 立体声音频压成约 10.76 Hz 的连续序列，同时优化重建、对抗、diffusion alignment、语义回归和对比对齐。ACE Studio 的 ACE-Step(2025) 在 DCAE latent 上训练 flow-matching DiT，并把中间特征对齐到 MERT 与 mHuBERT。论文还报告后期降低 mHuBERT 对齐权重，因为过强的语音表征会压制器乐和音乐性。语义 teacher 并非免费增益；它会改变生成器保留什么。
到 2026 年，tokenizer-generator co-design 成为更明确的研究问题。National Taiwan University 与 ASUS 的 LLM-Codec(2026) 把未来 token 可预测性和音文语义对齐写进 codec encoder 的训练目标，直接针对重建目标与 LM 目标的错配。它的强实证主要来自语音，音乐侧只足以提供方法线索。Central Conservatory of Music 与 Zhipu AI 的 BandTok(2026) 则把频谱组织为时间—频带二维 token，用共享 codebook 和 2D 位置编码减少 residual codebook 的串行依赖，在学术规模的音乐 AR 实验里给出更直接的生成证据。
εar-lab 与 initi
香港中文大学的 UniAudio 2.0(2026) 是统一接口的强正例，也构成结构性反证。ReasoningCodec 把 5 Hz、文本对齐的 reasoning tokens 与 reconstruction tokens 分开；后者还按语音、音乐和环境声引入不同特征。统一 AR 模型能处理理解和生成，代价是表示与 Transformer 层继续功能分化。这个设计说明一套序列接口可以统一任务，同时说明理解状态仍不足以重建波形。
机构署名仅为 HeartMuLa Teams 的 HeartMuLa(2026) 又给出生态级解法：HeartCLAP 负责音文对齐，HeartTranscriptor 负责歌词识别，HeartCodec 以 12.5 Hz token 服务长歌 AR，HeartMuLa 负责条件生成。它扩大了开放音乐模型的可复现实证，但“同一模型族”仍不同于共享参数、共享状态或生成后自我评价。
图像与视频 tokenizer 研究提供的是实验方法，不是音乐结论。New York University 的 RAE(2025) 把冻结的 foundation representation encoder、decoder 与 DiT 放进协同设计；CMU、Adobe Research 与 University of Michigan 的 RobusTok(2025) 专门检查 decoder 面对生成/扰动 latent 的分布偏移；Google DeepMind 的 Unified Latents(2026) 联合约束 encoder、prior 与 decoder。音乐可以迁移“重建状态、生成状态与 decoder 接受域要一起测”的问题形式，不能把视觉 FID 结果改写成音乐实证。
这一接口的结论很具体：codec 不是透明前处理；重建、语义、可预测性和编辑稳健性需要在同一实验协议里测。音乐领域更缺的是固定生成器、固定预算、固定数据下的 tokenizer 比较，以及对歌词时值、长时结构、stem 保持和 generated-latent 偏移的诊断。
3.2 局部状态到完整作品：长时生成需要结构分工
音乐生成常被概括为 AR 与 diffusion/flow 的竞争。这个二分掩盖了表示、条件、采样和系统实现。Hebrew University 与 Meta FAIR 的 Auto-Regressive vs Flow-Matching(2025) 提供了少见的受控比较：作者复用同一数据、latent、训练配置和近似 Transformer 骨干，只改变建模范式。AR 的感知质量与时序条件遵循略强；受监督 flow inpainting 的边界衔接更自然；flow 在许多单卡、小 batch 或长序列条件下更快，减少采样步数又会损失质量。严格的和弦、旋律和鼓条件还让两种路线都出现控制—听感折中。
这组实验比模型榜单更有解释力。AR 把时间因果关系直接写进序列，却承担长序列、多 codebook 和串行推理成本。Flow 在连续 latent 上并行更新全局状态，天然获得双侧上下文并不意味着自动理解段落；它仍需时间锚、block 因果、teacher 表征或显式 planner。
M-A-P 与 HKUST 的 YuE(2025) 用 semantic-acoustic tokenizer、两阶段 LM、主唱/伴奏 track-decoupled prediction 和逐段结构条件推进长歌 AR。Tsinghua SIGS、Tencent AI Lab 等机构合作的 LeVo(2025) 同时预测 mixed tokens 与人声/伴奏双轨 token：前者保留全局旋律、节奏、速度与和声关系，后者恢复局部细节。这个设计把整首歌关系与分轨声学明确为两种状态需求。
ASLP/Northwestern Polytechnical University 的 DiffRhythm(2025) 用句级歌词时间锚帮助 latent diffusion 生成完整歌曲；同一团队的 DiffRhythm 2(2025) 在 block 内并行、block 间自回归，并用 MuQ 表征引导 block。连续路线同样能做长歌，代价转移到低帧率细节、block 边界与偏好/结构平衡。两条路线都必须决定结构状态在哪里、以多长时间尺度更新；“AR 负责结构、flow 负责速度”无法概括这些系统。
混合系统把这项决定显式化。Tencent AI Lab、CUHK-Shenzhen 等机构的 SongBloom(2025) 交错生成低频率 AR sketch 与 diffusion 声学 patch，让后续计划读取已经渲染的声音。Kunlun Inc. 的 MusiCoT(2025) 把约 10 秒音乐片段的 CLAP embedding 量化为 musical thought tokens，再生成声学 token。这里的 “CoT” 是学习到的语义计划，不是自然语言推理，也没有被证明可由创作者审计。
ACE Studio 的 ACE-Step 1.5(2026) 把分工推进到清晰的 planner-renderer：Qwen planner 先输出 BPM、调性、时长、段落等 YAML 计划和低帧率 code，约 2B 的 DiT renderer 再在 48 kHz 立体声 latent 上完成生成、翻唱、重绘、分轨和叠加。它是当前开放系统中最接近“规划—渲染—编辑工具箱”的案例之一；planner 与 renderer 仍通过 YAML、FSQ code 和条件特征连接，论文的 intrinsic reward 也不是人类偏好反馈。
长时生成因此是一个时间尺度分配问题：哪些依赖由因果序列承担，哪些结构由段落或 sketch 显式表达，哪些声学细节交给并行 renderer，计划是否能在听到中间结果后更新。现有系统大多只在一次采样轨迹中交换状态，离“评价后重规划”还有一步。
3.3 听觉理解到可执行操作：统一入口已经出现
音乐理解模型的进展很快。Tencent AI Lab 的 MuQ(2025) 用 Mel-RVQ 自监督目标学习音乐表征，MuQ-MuLan 又把它接到音文对齐；Zhejiang University 与 NetEase Cloud Music 的 MuFun(2025) 用分块和长上下文训练处理整首歌的描述与问答。它们可以成为数据清洗、条件、teacher 或 judge 的底座，但论文没有声学生成器。
理解侧也在扩展可执行工具和时间范围。Sony Group/Sony AI 的 OpenMU(2024) 把 caption、歌词、reasoning 与 MIR 工具调用放进一个系统，工具可以把 tempo 等专用分析器的结果交给 LLM；NVIDIA 与 University of Maryland 的 Music Flamingo(2025) 用音乐理论、歌词、长歌描述和 GRPO 式后训练扩展音乐问答，论文明确不评价音频合成。HKUST AIS/M-A-P、Shenzhen University 与 Queen Mary University of London 的 ReasonMusic(2024) 在符号任务中发现，LLM 的多步音乐理论推理、和弦约束和结构化生成仍容易出错。这三项工作把“会描述”“会调用测量工具”和“能执行音乐约束”分成了不同证据层。
问答成绩也不能直接等同 grounded understanding。Universitat Pompeu Fabra、Queen Mary University of London 与 Universal Music Group 合作的 MuChoMusic(2024) 通过相关/不相关选项和替换音频测试发现，多种 audio-language model 会借语言先验答题。Queen Mary University of London 与 Yamaha 的 CMI-Bench(2025) 把调性、音高、节拍、旋律、歌词等 14 类 MIR 任务改写成自然语言指令，开放 audio-text LLM 除 caption 外普遍落后于专用监督模型。一个模型能谈论歌曲，仍可能无法给出编辑所需的准确拍点或歌词时间线。
统一骨干已经成为旧结论的反例。NVIDIA 与 Carnegie Mellon University 的 UALM(2025) 在同一模型中训练理解、音频生成和跨模态 reasoning，以富 caption 作为生成 blueprint；输入用连续表征，输出预测离散 X-codec token。UniAudio 2.0 进一步统一文本、reasoning 与 reconstruction 流。两项工作都明确留下表示差异、音乐弱于语音或分层审美指标不足等问题。准确说法已经从“理解与生成从未统一”变成：共享骨干已出现，歌曲级共享可执行状态尚未验证。
Tencent ARC Lab 与 NUS 的 MuMu-LLaMA(2024) 代表另一条路：冻结音乐/图像/视频 encoder，用 adapter 接入 LLaMA，再通过 projector 调用外部 MusicGen 或 AudioLDM2。它能提供统一用户入口，作者也把对外部生成器的依赖列为瓶颈。HKUST、Tencent 与 Peking University 的 Audio-Omni(2026) 用冻结多模态 LLM 加 projector 和可训练 DiT，在超过一百万 instruction-guided editing pairs 上统一语音、声音和音乐生成/编辑。理解知识确实可以传给 renderer；内部仍是 decoupled architecture。
符号音乐给出了更干净的测试。University of Padova 与 Universitat Pompeu Fabra 的 LilyBench(2026) 让同一批 LLM 同时完成 LilyPond 理解与生成。部分模型的可编译率很高，小节计数和错误检测却接近失效；few-shot 还能提高可编译率同时损害分布指标。共享字符、共享骨干、共享语料没有自动让生成流畅性变成结构理解。
真正缺少的接口是从诊断到操作：模型需要把“副歌第二遍层次不足”映射到时间段、stem、目标属性、保留约束和可回滚动作。自然语言解释、latent plan、MIR 工具和 renderer condition 都是候选表示；公开研究还没有在同一协议下比较它们的可执行性。
4. 评价如何反馈模型训练
音乐评价正在经历三个阶段。第一阶段用 FAD、KL、CLAP/MuLan 相似度等方便代理测集合分布或文本对齐。第二阶段把人类判断做成可训练数据。第三阶段把 learned reward 接进 best-of-N、latent optimization、DPO/RLHF 和自训练。2026 年的重要变化是第三阶段已经发生；评价错误也从排行榜误差变成模型行为问题。
不同人评协议测量的是不同对象。ETH Zurich 的 Benchmarking Music Generation Models and Metrics via Human Preference Studies(2025) 让 2,500 多名年轻英语流媒体用户比较 6,000 个 10 秒纯音乐片段。Nankai University 与 AISHELL 的 MusicEval(2025) 让音乐专家评价短片段的整体印象和文本对齐。Northwestern Polytechnical University 与 Shanghai Conservatory of Music 的 SongEval(2025) 转向 2—8 分钟完整中英歌曲。Tsinghua SIGS 与 Tencent 的 SongBench(2026) 又拆成人声、器乐、旋律、结构、编曲、混音和音乐性七维。把这些标签合并成一个“人类偏好”会丢掉人群、场景、长度和专业目标。
CMU、UC San Diego、Sony AI 与 Cornell University 的 MusicPrefs/MAD(2025) 把开放人类偏好与自动指标放进同一 meta-evaluation，标准 FAD 与人类排序的相关性很弱，MAD 更高但论文没有主张它能替代人评。CMU、LMArena、Sony AI 与 Georgia Tech 的 Music Arena(2025) 让用户提交提示、匿名比较两种模型并记录最低收听与投票，评价因此可以随模型更新。平台用户构成、模型路由、提示分布与 API 版本会改变榜单；live feedback 比静态测试更接近产品，也仍是一种有选择偏差的人群测量。
Google DeepMind 的 MusicRL(2024) 是规模化偏好后训练的起点之一。AI Test Kitchen 用户在两段 20 秒结果之间选择，形成约 300,000 对偏好；初始化自 MusicLM 的 reward model 再用于 RL。论文报告自动 reward 与人类 reward 的组合改善人评，也观察到用户 reward 在不到 2,000 步内过优化。偏好有用，reward 也会被利用。
LeVo 把歌词对齐、prompt 一致性、音乐性和音质分别用于多偏好 DPO；ASLP/Northwestern Polytechnical University 的 DiffRhythm+(2025) 用 SongEval 和 Audiobox-aesthetic 筛选数据并构造 diffusion-DPO 对。Wuhan University、Tencent AI Lab、Tsinghua SIGS 等机构合作的 Hallucination-Free Music(2025) 又用声源分离、ASR、音素转换和 PER 构造歌词错漏偏好，比较 DPO、PPO 与 GRPO。它们证明完整歌曲和局部可靠性目标能进入后训练，同时大量依赖 ASR/PER、embedding 相似度和 learned aesthetic score。某一代理变好，可能只意味着歌词更容易被 ASR 识别，未必意味着唱法更自然。
2026 年的开放 reward 基础设施进一步推进闭环。Stevens Institute of Technology 与 Columbia University 的 MuQ-Eval(2026) 在系统级和样本级相关性上很强，却在 pitch shift 与 tempo stretch 控制退化上接近随机。Queen Mary University of London 等机构的 CMI-RewardBench(2026) 同时评价文本、歌词和参考音频条件；其 best-of-N 收益会饱和，作者还报告 reward head 纠缠和流派/语言偏差。
CMU、Sony AI、Georgia Tech 等机构的 TuneJury(2026) 聚合约 17.5K 开放人类 pair，训练小型 pairwise ranker，并把它用于 best-of-N、latent optimization 与 expert iteration。奖励上升时，某些模型的参考分布或旁路对齐指标反而变差。Georgia Tech、KAIST、Peking University、QMUL 与 CMU 的 Human Preference Rewards(2026) 进一步显示，在固定小模型挑战中，top-decile expert iteration 是主要增益，显式 preference tuning 的变化很小，最后还依赖源分离和响度归一化。
这些结果支持一个更克制的结论：音乐后训练已经可行，单一 reward 的充分性仍未建立。下一步需要在扩大偏好数据的同时保留“谁、在什么任务里、听多长、重视什么”，并用结构约束、跨 evaluator 验证、真实人评和分布保真共同检查 reward hacking。
5. 编辑与交付如何保存作品状态
5.1 从局部编辑到工程对象
学术论文常把编辑定义为 inpaint、repaint、extend 或重新生成一个区间。专业创作还要求目标变化发生、非目标属性保持、边界无伪影、结果能再次编辑，并能导出给 DAW。Meta FAIR 与 Hebrew University 的 JASCO(2024) 把和弦、旋律、鼓与 audio prompt 等时序控制注入连续 latent generator；ByteDance Seed Team 的 Seed-Music(2024) 在同一系统报告中组合 audio token、lead-sheet/symbolic token、vocoder latent 与编辑模块。这些系统说明符号层没有消失，它更像控制面和交付面，而非最终音频的替代品。
ByteDance San Jose、Queen Mary University of London 与 CUHK 的 SymPAC(2024) 用 prompt bars 和有限状态机约束多轨符号生成；Queen Mary University of London 与 Singapore University of Technology and Design 的 Text2MIDI(2024) 把文字 caption 转成可在 DAW 继续编辑的 MIDI。它们不承担人声、音色、混音和母带，却让段落、和弦与轨道约束成为可检查的计划和导出对象。显式符号由此成为波形系统的一种控制接口，范围与声学 renderer 清楚分开。
Singapore University of Technology and Design 的 SonicMaster(2025) 把 EQ、动态、混响、幅度和立体声等 19 类恢复/母带操作交给一个文本引导 flow 模型。它覆盖了生产末端，却不会理解歌曲后自主提出修改计划。研究生成器与专业 DAW 之间仍缺工程对象：stem、歌词时间线、take、自动化曲线、撤销历史和版本图。
编排式编辑把语言计划接到外部工具。University of Pennsylvania 的 SmartDJ(2025) 把高层指令拆成 add、remove、extract、音量和空间等原子操作，再交给 latent diffusion editor；Tongyi Lab/Alibaba、HKUST 与 Zhejiang University 的 ThinkSound(2025) 用多模态语言模型的步骤描述引导视频配音生成和目标编辑。前者更接近可执行编辑计划，后者主要是通用音视频场景；两者都没有保存歌曲工程的版本图，也未展示评价结果自动触发下一轮修改。
产品已经让这种需求变得可见。Suno Studio 的官方文档确认 full song、时间选区、对齐的 multitrack stems、WAV 与 MIDI-from-stems 导出；Udio 的 Audio Upload、Sessions 与 Styles 分别确认用户自有权利素材上传、时间线 replace/extend/take/undo，以及 style reference；Mureka API 把 lyrics-to-song、prompt-to-song、vocal cloning、stem、track generation、region editing 和 remix 做成接口。它们证明用户需要可迭代工作流和权利入口，不能证明内部基础模型原生保存统一 song object。MIDI 也可能来自后处理转写，stem 可能来自分离器，时间线可能只是产品数据库。
5.2 实时系统保存交互状态
实时生成又改变了目标函数。Google DeepMind/Magenta 的 Live Music Models(2025) 把 48 kHz 立体声音频按 2 秒 chunk 持续生成，并接受文本、音频与参数控制。实时系统必须同时满足吞吐、因果流式和控制延迟；离线模型“生成快于播放”仍可能无法演奏。UC San Diego、MIT 与 Adobe 的 Live Music Diffusion Models(2026) 通过因果路由、KV cache 和 rollout post-training 让 diffusion 进入互动场景；Sony Computer Science Laboratories Paris、Queen Mary University of London 与 Johannes Kepler University Linz 的 LiveBand(2026) 则直接听取现场输入生成伴奏。响应、连续性、共同创作体验和长会话漂移需要独立评测，不能由离线 FAD 代替。
5.3 来源记录与权利边界
交付还包含来源和权利。Google DeepMind 的 SynthID 为自家生成音频嵌入不可听水印；C2PA 2.4 能为音频资产保存签名的来源、修改和 ingredient/action history。两者回答不同问题：水印提供系统来源信号，C2PA 验证一组声明和签名是否被篡改。它们都不能独自证明训练许可、作者身份、作品相似性或版权归属。
训练许可、上传权利和声音同意属于另外三类记录。Stable Audio 3 披露授权与 Creative Commons 数据来源；Udio 要求用户对上传素材拥有权利；Mureka 暴露 vocal cloning 接口，但公开 API 功能本身不能证明一套完整同意协议。欧盟 AI Act 要求通用 AI 提供者建立版权政策和训练内容摘要等透明度接口，美国版权局 AI 报告 则分别讨论人类创作贡献和训练的事实依赖问题。它们约束治理与交付证据，没有规定音乐模型必须采用某种 tokenizer、song object 或水印架构。
Duke University 与 Google 的 AudioMarkBench(2024) 以及 University of Hawaii at Manoa 与 Michigan State University 的 Audio Watermarking SoK(2025) 还显示，公开水印会在某些移除、伪造、变调、重录或生成式转换攻击下失效。由于两项研究没有测试闭源 SynthID 音乐实现，它们不能直接否定官方系统；它们足以否定“水印单独解决 provenance”的外推。
一个强形式的交付对象应接近：
mix + stems + lyrics timeline + chord/section/melody sketch+ edit/version graph + reference/voice consent + watermark/credentials这仍是研究目标，不是当前商业系统已经公开证明的内部结构。
6. 横切证据：规模、训练栈与开放性
音乐模型的规模不能简化成参数量。一个生成系统常同时训练或调用 tokenizer/autoencoder、主生成器、vocoder/decoder、歌词或结构条件器、音文表征、reward/judge 和产品筛选器。能力来自一条训练栈：
表示训练 → 生成预训练 → 条件/任务训练 → 高质量 SFT → 偏好后训练或筛选 → 产品反馈与交付ACE-Step 报告约 100K 小时预训练音乐和 20K 小时高质量微调子集，并公开百卡级训练阶段；YuE 报告大规模长歌 token 训练与 0.5B/2B/7B 扩展；LeVo 把约 110K 小时歌曲、双轨建模和多偏好对齐放进一个流程；Stable Audio 3 又把大量容量投入 SAME 表示训练。这些数字说明开放音乐模型已经进入大数据、多模块、多阶段区间。由于数据定义、许可、过滤、采样和评价不同，它们不适合作为简单排行榜。
开放性也需要拆开：权重、推理代码、tokenizer/vocoder、训练音频清单、清洗脚本、训练 recipe、偏好数据、评测提示和输出音频可以分别开放。HeartMuLa、ACE-Step 1.5 与 Magenta RealTime 扩大了可检查范围；MusicRL 的 300K 偏好与基础模型仍未开放；强商业系统通常只能复现输出行为。开放权重不等于训练栈可复现，闭源也不等于产品能力无法比较。
数据治理会直接影响能力和证据。音乐受版权约束，公开训练集较小，弱标签噪声和 benchmark 污染更难排查。CMI-Bench 观察到模型在训练重合任务上往往最好。2025—2026 的评价器又常复用 MusicEval、SongEval、Music Arena 等相同标签源；多个指标互相相关，可能只说明共享训练数据，而不是独立共识。
7. 从现有缺口推出的研究议程
这些方向不是愿望清单。每一项都对应正文已经出现的证据缺口，并给出能够收口的实验。
7.1 音乐专用的 generation-friendly tokenizer 基准
在固定数据、AR/flow 骨干、参数量和训练预算下比较 codec/tokenizer，至少同时报告：
- 重建：多尺度频谱、FAD/MOS、人声与混音相似度；
- 可学习性：收敛速度、LM perplexity、token rate、codebook 使用与固定预算生成质量；
- 结构：节拍、和弦、段落、旋律轮廓、歌词音素和人声/伴奏关系；
- 稳健性：generated/off-manifold latent、token dropout、扰动后 decoder 行为；
- 编辑：局部歌词、和弦、段落和 stem 修改时的目标变化与非目标保持。
它可以检验“重建更好是否让生成更好”，也能把 LLM-Codec 的 LM-facing 目标、BandTok 的频带几何、ReasoningCodec 的功能分解放在同一音乐协议中比较。
7.2 可执行的音乐规划状态
固定 renderer 和数据，比较四种计划：自然语言/YAML、MIR 符号结构、CLAP/MuQ latent sketch、端到端可学习 token。计划需要被独立 probe，并允许人工干预。评价不只看最终听感，还要看 plan fidelity：修改调性、段落、歌词时值或能量曲线后，目标是否出现，其他属性是否保持。
7.3 从诊断到编辑坐标
下一代 evaluator 应输出带时间和对象的诊断，而非总分。基准可以要求系统指出问题区间、涉及的 stem/歌词/和弦、置信度和建议操作，再由固定 editor 执行。闭环成功由三部分决定：诊断正确、编辑命中、上下文保持。这个协议可用于检验 CMI-Bench 的可操作 MIR、SongBench 的细维度和 SonicMaster/Audio-Omni 的编辑能力能否接通。
7.4 分层、场景化的偏好后训练
偏好数据应记录评价者背景、使用场景、片段长度和维度。专家可评价结构、编曲、混音与演唱；普通用户可评价整体偏好和情绪；代理指标负责歌词对齐、音文匹配和技术质量。训练时报告各维度的 Pareto 变化，跨 TuneJury、CMI-RM、MuQ-Eval 和独立人评做外部验证，保留 reward 未覆盖的失败集。
7.5 多轮创作与可追溯 song object
建立真实创作者任务：从草稿开始，经过多轮听取、批注、局部修改、撤销与导出。评价任务完成率、修改次数、非目标属性损失、DAW 接续成本、长会话漂移和最终可用性。交付同时保存 mix、stem、时间线、版本图和 provenance；水印与 C2PA 作为来源信号进入协议，但不替代权利判断。
7.6 实时系统的独立评测
实时音乐是持续控制，而非缩短版 text-to-song。应单独测启动和控制延迟、音频连续性、对现场输入的跟随、纠错成本、硬件条件、长会话漂移、MIDI/DAW 集成与共同创作体验。器乐伴奏、风格流和带歌词歌曲也应分开，避免用一个实时分数覆盖不同任务。
8. 结论
音乐模型的单点组件已经相当丰富。表示侧有 semantic-acoustic codec、低帧率 token、continuous latent 和 reasoning/reconstruction factorization；生成侧有 AR、flow、block 与 planner-renderer；理解侧有长歌问答、MIR 指令和统一音频 LM；评价侧有人类偏好、live arena 与开放 reward；产品侧有时间线、stem、MIDI、实时控制和水印。
这些进展共同改变了问题。到 2026 年，继续问“AR 还是 diffusion”“离散还是连续”“有没有 RLHF”已经不够。更关键的是：理解结果能否成为 renderer 可执行的计划，生成状态能否支持局部而可逆的修改，评价能否指出编辑坐标，产品能否保存可继续制作和可追踪的作品对象。
因此，本文把共享状态协议视为音乐 LLM moment 的一条高价值路线。它可以由多个模型实现，但要让同一首歌在理解、规划、生成、评价、编辑和交付之间保持身份、结构与历史。在本文核验的公开语料中，系统已经触及统一入口和共享骨干，局部建立了 planner、reward 与编辑接口；完整、可审计的 music-native 创作循环仍待验证。共享协议也不会自动解决训练数据许可、文化和场景偏差、评价有效性、实时算力或专业用户研究，这些限制需要各自的证据与工程方案。
评论区将在滚动到这里时加载