Eleven Music v2.5:把音乐生成拆成可编程产线的闭源梯顶
eleven-music
ElevenLabs 的音乐生成模型,当前版本 v2.5,2026-09-11 发布。它是音频域音乐方向的工程面梯顶,与已收的 Suno 形成对照而不是重复:Suno 的价值集中在产品内部的工序(Studio 多轨时间线、Custom Models、最多 12 轨 stem 与 MIDI 导出),Eleven Music 把同类能力拆成了端点——生成、流式生成、结构化编曲计划、给视频配乐、上传既有音频、分轨、微调、片段级 inpainting,外加一个让创作者互相授权的 Marketplace。所以判断该用哪一条不需要比音质,只要问一句:这段音乐是人坐着调出来的,还是被一条流水线批量要出来的。API 面是九个端点而不是一个生成接口,其中两处对企业采购关键:compose 与 stem-separation 都有 sign_with_c2pa 开关(仅对 mp3 生效),出站文件可以带内容凭证;输出格式与订阅档位绑定,stem-separation 与 video-to-music 上 mp3_44100_192 需 Creator 及以上、pcm_44100 需 Pro 及以上,compose 侧最高 mp3_48000_320,「拿到无损」的门槛按端点不同。⛔ 最容易踩的坑:产品界面里 v2.5 已是默认,但 API 的 model_id 枚举(music_v1/music_v2/music_v2_5)默认值仍是 music_v1,而 output_format=auto 按模型选最优(v1 系给 mp3_44100_128、v2 系给 mp3_48000_192),两件事叠起来就是一个不显式传 model_id 的最小调用会拿到最老那代模型加更低码率,且响应里看不出异常——生产代码里 model id 与 output format 都要写死。⛔ 两套 plan schema 互不通用:music_v1 吃 MusicPrompt,music_v2 与 music_v2_5 吃 CompositionPlan(chunks 的 text 里写方括号段名、歌词行与花括号内联指示),用错直接报错。版权与商用是这条线最结构化的部分:与环球音乐(UMG)的多年期协议在 v2.5 同期宣布且官方注明与 Music 2.5 独立;每个档位(含 Free)生成的曲子归你,Free 可商用但要署名,lossless 下载 Free 每天 5 次、Pro 每月 400 次;基于他人歌曲做出的曲子禁止下载;Marketplace 按 usage type 卖许可,创作者分成从 25% 起;任何许可下都禁止分发到 Spotify 这类流媒体。v2.5 的官方证据是一次自评盲听:47,885 对里多数胜出,差距最大在人声主导与声学密集类型。边界:API 只对付费订阅开放;人声只列英、西、德、日,中文歌更实际的是 YuE2 或 Suno;seed 不保证可复现;闭源无权重不可自托管。置信度 C(厂商宣称):音质未复算、未盲听,但 API 契约逐条可核对,把它们全列进正文。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- API 单曲时长上限(music_length_ms 3000-600000)
- 厂商宣称 · 2026-09
- 成熟度
- 生产
- 研究 → 演示 → 产品 → 生产
编辑判断评为 C 档(vendor-claim),理由是音质上唯一可引用的量化证据是厂商自评盲听:同 prompt 双 take 配对,47,885 对里 v2.5 多数胜出,差距最大在人声主导与声学密集的类型。这个数字规模不小,但它是厂商自己的 A/B,没有第三方基准读数可交叉验证,也没有做过盲听,所以按契约压在 C。真正升到 B 的是另一件事:API 契约是可核对的文档事实——
music_length_ms3000-600000、model_id三个枚举值默认music_v1、output_format的 auto 在 v1 与 v2 系上分别解析成mp3_44100_128与mp3_48000_192、video-to-music 的 10 个视频 / 200MB / 600 秒上限、stem-separation 上 192kbps 需 Creator 而 pcm_44100 需 Pro。这些不是音质证据,是选型时能直接照着写代码的边界,逐条列进正文正是为了让 C 档的这一行仍然可用。它在音频域梯顶扮演的角色是音乐方向的工程面代表,与另一条闭源音乐梯顶 Suno 形成对照而不是重复。Suno 把音乐生产的后半段工序收进一个产品(Studio 多轨时间线、Custom Models、最多 12 轨 stem 与 MIDI 导出),它的价值在「人在界面里做完一首歌」;Eleven Music 把同类能力拆成端点(compose / detailed / stream / composition-plan / video-to-music / upload / stem-separation / finetunes / inpainting),它的价值在「程序把一首歌做完」。所以判断该用哪一条,不需要比音质,只要问一句:这段音乐是人坐着调出来的,还是被一条流水线批量要出来的。视频自动配乐、播客片头、游戏 BGM 批产、agent 自己给成品配乐,是后者;独立音乐人反复改一版副歌,是前者。
第三个理由与音乐本身无关,但对采购最重要:它是目前把版权讲得最结构化的一条线。UMG 多年期战略协议(授权与产品共同开发,官方明确说与 Music 2.5 是两件事)、所有权随曲走且条款变更只对新曲生效、Free 也可商用但要署名 ElevenMusic、引用他人歌曲做出的曲子禁止下载、Marketplace 按 Social Media / Paid Marketing / Offline / Enterprise 四档 usage type 卖许可且创作者分成从 25% 起、任何许可下都禁止分发到 Spotify 与 Apple Music 这类流媒体、以及 compose 与 stem-separation 上的
sign_with_c2pa开关。企业引入生成式音乐时真正会出事的地方是权利链条与内容凭证,不是那 3dB 的音质差;这条线把权利链条写成了可查的条款,这一点在闭源阵营里是稀缺的。四条实操边界。一,别信 SDK 默认值:产品界面里 v2.5 已是默认,而 API 的
model_id默认仍是music_v1,配上output_format=auto就变成「最老模型 + 更低码率」,且响应里看不出异常。生产代码里 model id 与 output format 两个都要显式写死。二,plan schema 不通用:MusicPrompt只喂 v1,CompositionPlan只喂 v2 / v2.5,用错直接报错;段时长在 v1 上可用respect_sections_durations=false放宽,在 v2 系上恒强制。三,中文人声不在支持列表:官方只列英、西、德、日,要中文歌就换 YuE2 或 Suno,不要拿 prompt 硬试。四,文档会滞后于发布:产品文档此刻仍写 v2 是界面默认、导出仍是 44.1kHz 的 128-192kbps,而同周发布文说 v2.5 已默认、全档位可 lossless 下载。矛盾时以 API reference 的参数枚举为准。
它解决的问题:把「生成一首歌」拆成一条能被程序调用的音乐产线
Eleven Music 是 ElevenLabs 的音乐生成模型,当前版本 v2.5,2026-09-11 发布(发布文最后更新 2026-09-20)。它与音频域另一条闭源梯顶 Suno 的分工差异不在音质,而在可编程性:Suno 的价值集中在产品内部的工序(Studio 多轨时间线、Custom Models、最多 12 轨 stem 与 MIDI 导出),Eleven Music 把同一批能力拆成了端点——生成、流式生成、结构化编曲计划、给视频配乐、上传既有音频、分轨、微调、片段级 inpainting,外加一个让创作者互相授权的 Marketplace。所以本站把它列为音频域音乐方向的工程面梯顶:要把音乐生成嵌进自己的产品或 agent 工作流,这条线的覆盖面目前是闭源里最完整的。
v2.5 相对 v2 的官方说法是音质与 prompt 遵循度提升,能力面不变(Audio Reference、composition plan、inpainting 都保留)。厂商给的证据是一次自评盲听:同一个 prompt 两个 take(分别来自两个模型)配对比较,47,885 对里 v2.5 多数胜出,差距最大的是人声主导与声学密集的类型(R&B、soul、hip hop、rock、metal、orchestral、cinematic)。这是厂商自己的 A/B,不是第三方榜单,本站未复算——这条决定了它的置信度档。
API 面:九个端点,不是一个「生成接口」
| 端点 | 方法与路径 | 它解决什么 |
|---|---|---|
| Compose music | POST /v1/music | prompt 或 composition plan 出一首歌,直接回音频文件流 |
| Compose music with details | POST /v1/music/detailed | 同上,但回结构化响应(song id 等元数据在里头,inpainting 要用) |
| Stream music | POST /v1/music/stream(另有 detailed 版) | 边生成边播,交互式产品与 Flows 节点用这条 |
| Create composition plan | POST /v1/music/composition-plan | 把一句 prompt 先展开成 JSON 编曲计划,再由你改完才拿去生成 |
| Video to Music | POST /v1/music/video-to-music | 上传视频直接配乐:最多 10 个视频按顺序拼接、合计 ≤200MB、总时长 ≤600 秒,可附 ≤1000 字符描述与 ≤10 个风格 tag |
| Upload Music / Stem Separation | POST /v1/music/upload、POST /v1/music/stem-separation | 把既有音频拆成分轨,回 ZIP;官方明确警告长文件延迟高 |
| Finetunes | /v1/music/finetunes(list / create / get 等) | 用自己的原创音频训私有风格变体,生成时传 finetune_id |
两处容易被漏掉但对企业采购很关键的细节。一,C2PA 签名:compose 与 stem-separation 都有 sign_with_c2pa 开关(仅对 mp3 生效),意味着出站文件可以带内容凭证,这在「AI 生成音乐要过平台审核」的场景里是硬需求。二,输出格式与订阅档位绑定:stem-separation 与 video-to-music 的 output_format 明写 mp3_44100_192 需要 Creator 及以上、pcm_44100 需要 Pro 及以上,而 compose 侧最高可到 mp3_48000_320。也就是说「拿到无损」这件事在不同端点上的门槛不一样,选型时要按端点查,不能按产品线一概而论。
控制面:composition plan 才是这条产品线里最值钱的一块
只传 prompt 的话,可控参数是这几个:music_length_ms(3000 到 600000,即 3 秒到 10 分钟,不传则由模型按 prompt 自己定长度)、force_instrumental(true 时保证纯器乐)、finetune_id、store_for_inpainting、seed。prompt 与 composition_plan 互斥,seed 与 force_instrumental 也只能配 prompt 用。
真正做交付级编曲要走 plan。这里有个必须读准的点:两套 plan schema 互不通用,用错直接报错。
music_v1 用 MusicPrompt | music_v2 / music_v2_5 用 CompositionPlan | |
|---|---|---|
| 结构单位 | sections(SongSection) | chunks |
| 歌词 | 独立字段 lines,每段 ≤30 行、每行 ≤200 字符 | 写在 text 里:开头方括号段名 [Verse 1],随后歌词行,花括号是内联指示如 {scratching};同样 ≤30 行 × ≤200 字符 |
| 风格 | 全局 positive_global_styles / negative_global_styles + 每段 local 正负风格 | 每个 chunk 自带 positive_styles / negative_styles,官方注明第一个 chunk 的风格最重要,它定全曲基调与类型 |
| 段时长 | duration_ms 3000-120000,且可用 respect_sections_durations=false 放宽(模型为音质与延迟自行调整单段时长,但保住总长) | duration_ms 3000-120000,恒强制执行,那个开关被忽略 |
| inpainting | 段级 source_from(song_id + range + negative_ranges) | 走 inpainting 指南的同一套语义 |
产品侧还有两条不在 API 参数里的控制面。Audio Reference:上传一段 ≤约 30 秒的音频引导 v2 / v2.5 的生成,每个上传都会过版权合规筛查;官方口径写得很清楚——它影响的是 sound、制作风格、配器、速度与情绪,不复制也不 remix 你上传的那段音频。Finetunes 分两类:官方跨类型预训的 curated,以及用你自己原创音频训的 custom。这两条合起来回答的是「怎么让我的音乐听起来一直是我的」,而 prompt 回答不了这个问题。
⛔ 最容易踩的坑:API 默认模型还是 music_v1
产品界面里 v2.5 已经是 prompted 与 reference 生成的默认,但 POST /v1/music 的 model_id 枚举是 music_v1 / music_v2 / music_v2_5,默认值是 music_v1。同时 output_format=auto 的语义是「按模型选最优」:v1 系给 mp3_44100_128,v2 系给 mp3_48000_192。两件事叠起来的后果是:一个不显式传 model_id 的最小调用,拿到的是最老的那代模型加更低的码率,而它在日志里看不出任何异常。官方 quickstart 的示例代码是显式写了 model_id="music_v2_5" 的,但真实项目里被 SDK 默认值带走的调用非常多。落地时两件事都要显式:模型 id,以及输出格式(需要 320kbps 就点名 mp3_48000_320,不要指望 auto)。
另一处要提醒的是文档自身滞后于发布:产品文档页此刻仍写着「Music v2 是 Eleven Music 界面里的默认模型」,而 2026-09-11 的发布文明确说 v2.5 已成为默认;导出格式上产品文档写的是 MP3 44.1kHz、128-192kbps 且「其他格式即将支持」,同一天的发布文却说全档位(含 Free)都能 lossless 下载。遇到这种矛盾,本站的口径是以 API reference 的参数枚举为准——那是会被 SDK 与校验层直接消费的东西,产品文档是给人读的。
版权与商用:UMG 协议、按用途分层的许可、以及一个 25% 起的市场
音乐生成对企业采购的头号风险是版权而不是音质,这一条线上 ElevenLabs 是目前把版权讲得最结构化的一家。
- UMG 多年期战略协议:v2.5 发布同期宣布,覆盖授权与产品共同开发。官方特意注明这与 Music 2.5 是两件独立的事,不要用「新模型=已授权曲库」去理解。
- 所有权与商用:每个档位(含 Free)生成的曲子归你;Free 可商用,条件是署名 ElevenMusic;lossless 下载额度 Free 每天 5 次、Pro 每月 400 次。权限随曲走——退订或降级不会追溯改变你已经生成的曲子,条款若将来收紧也只对当日之后的新曲生效。
- 一条硬限制:基于其他艺人歌曲(Audio Reference 引用他人作品)做出的曲子禁止下载。官方把这条解释为双向保护:保护你的音乐的同一套规则也保护艺人的。
- Music Marketplace:创作者把自己用 ElevenLabs 生成的曲子发布出来,买家按 usage type 买许可——Social Media(自有频道、含变现视频、播客、个人站)、Paid Marketing(付费投放、客户/代理项目、商业产品)、Offline(线下演出、展会、实体场地与装置)、Enterprise & Custom(影视/流媒体 VOD-OTT、大规模商业分发、广播、大型工作室游戏)。创作者分成从购买额的 25% 起,走 ElevenLabs 既有 payout 体系。
- 两件事在任何许可下都不允许:把曲子分发到 Spotify / Apple Music / SoundCloud 这类音乐流媒体平台;以及转售、再许可或主张对音乐的所有权。
边界与失败模式
六条。一,API 只对付费订阅开放,免费档只能在网页产品里做,不能拿它跑后端批产。二,人声语言面窄:官方列的是英、西、德、日四种,中文人声不在支持列表里——要中文歌,本站音频域里更实际的是 YuE2(开源,非商业许可)或 Suno。三,seed 不保证可复现:官方原文是「同 seed 同参数有助于更一致,但不保证精确复现,且输出可能随系统更新变化」,而 seed 又不能与 prompt 同用。需要长期一致音色的项目,自己存 plan 与成品音频,不要指望重放参数。四,单曲 10 分钟上限:超过就要分段生成再靠 inpainting / stem 拼,那是另一套工序与另一笔延迟。五,音质证据是厂商自评盲听,没有可核对的第三方基准读数,置信度因此压在 C 档。六,不可自托管:闭源无权重,未发布的旋律与歌词都要过它的服务,数据主权敏感的场景按这个前提评估;本站音频域可自托管的替代是 YuE2(音乐)与 VoiceStudio、Kokoro-82M(语音)。