FlashLabs Chroma 1.0：具有个性化语音克隆能力的实时端到端语音对话模型 FlashLabs Chroma 1.0: A Real-Time End-to-End Spoken Dialogue Model with Personalized Voice Cloning
首个开源实时端到端语音对话模型，同时实现低延迟流式生成和高保真个性化语音克隆
前置知识
神经音频编解码器（Neural Audio Codec）
神经音频编解码器是一种将连续语音波形压缩为离散token序列的深度学习模型，典型代表是EnCodec。它通过残差向量量化（RVQ）技术，将音频信号编码为多个层次的离散码本序列，其中第一层（c0）捕捉粗粒度语义信息，后续层（c1到cN-1）逐步补充细粒度声学细节如音色、韵律等。解码器则将这些离散token重建为高质量波形。这种离散化表示使得语音可以像文本一样被语言模型处理，是构建端到端语音系统的基础。
Chroma的核心创新建立在RVQ码本之上，理解多层码本的结构和作用是理解整个系统分层生成策略的关键
残差向量量化（Residual Vector Quantization, RVQ）
RVQ是一种多阶段量化方法，第一层码本对原始信号进行粗粒度量化，后续每一层对前一层的量化残差进行细化。在本文中使用N=8层码本，第一层c0由Chroma Backbone生成，代表粗粒度声学表示；后续7层c1到c7由轻量级Chroma Decoder生成，逐步补充音高、音色、发音细节等细粒度特征。这种分层设计使得系统可以在保持生成质量的同时大幅降低计算开销。
理解RVQ的分层结构是理解Chroma为什么采用Backbone+Decoder两阶段生成策略的理论基础
交错文本-音频Token调度（Interleaved Text-Audio Token Schedule）
这是Chroma的核心技术之一，以1:2的比例将文本token与音频token交错排列。具体而言，每当Reasoner生成一个文本token，Backbone就会并行生成两个音频码本token（c0层）。这种调度方式使得语义理解和声学生成可以同步进行，无需等待完整文本序列生成完毕才开始语音合成，从而将首token延迟（TTFT）降低到亚秒级。
这是实现低延迟实时流式生成的关键机制，直接决定了系统的响应速度
实时因子（Real-Time Factor, RTF）
RTF是衡量语音生成系统效率的核心指标，定义为生成时间与音频时长的比值。RTF < 1表示系统生成速度快于实时播放，意味着可以进行实时交互。Chroma实现了RTF=0.43，即生成速度是实时播放的2.3倍，这意味着系统能在播放上一句回复的同时已经准备好下一句，非常适合实时对话场景。
RTF直接体现了Chroma相比级联式系统和其他端到端系统的速度优势
说话人相似度（Speaker Similarity, SIM）
SIM使用WavLM-Large模型从生成语音和参考语音中提取192维说话人嵌入向量，计算两者的余弦相似度来衡量语音克隆质量。该指标基于SEED-TTS-EVAL框架评估，数值越接近1表示克隆效果越好。Chroma达到0.817的SIM分数，超过人类基线0.73约10.96%，这是该领域的重要突破。
SIM是本文最核心的评估指标，直接衡量语音克隆的保真度
首Token延迟（Time-to-First-Token, TTFT）
TTFT衡量从接收用户语音输入到系统生成第一个音频token的时间，是决定对话自然度的关键指标。在实时对话中，人类通常期望在0.5-1秒内得到响应。Chroma通过预填充策略和交错调度，将整体TTFT压缩到146.87毫秒，其中Reasoner处理占119.12ms，Backbone生成首个token仅需8.48ms，远低于人类感知阈值。
TTFT直接关系到用户体验，是Chroma实现实时对话体验的技术指标保障
研究动机
当前实时语音对话系统主要采用级联式架构：先用ASR将语音转为文本，再由LLM处理文本生成回复，最后用TTS将文本转回语音。这种管道式设计存在三个核心问题：首先，端到端延迟累积严重，ASR、LLM、TTS三个模块串行处理导致响应时间长，在实时对话场景中用户体验差；其次，错误会在各模块间级联传播，ASR的识别错误会被LLM放大，进而影响TTS生成质量；最关键的是，语音中的副语言信息（paralinguistic information）如说话人身份、语速、音色、情感和韵律在文本化过程中被丢弃，导致下游系统无法保持说话人一致性和情感表达。虽然现有端到端系统如Moshi、Spirit LM、GLM-4-Voice等已经尝试直接处理离散语音token，但它们要么在说话人身份保持方面能力有限，要么无法同时实现低延迟流式生成和高保真语音克隆。商业系统如ElevenLabs虽然能实现高质量语音克隆，但采用两阶段设计（先提取声纹再生成语音），在多轮对话中难以保持一致的说话人特征，且缺乏实时流式能力。
本文的目标是本文的核心目标是构建第一个开源的、实时的、端到端语音对话系统，同时实现两个看似矛盾的能力：亚秒级的低延迟交互和高保真的个性化语音克隆。具体而言，系统需要在对话过程中仅依赖几秒钟的参考音频就能克隆说话人的音色特征，并在多轮对话中保持一致；同时系统必须支持流式生成，首token延迟控制在亚秒级别，实时因子低于1.0以确保生成速度快于实时播放。此外，作者希望在仅4B参数的规模下保持强大的推理和对话能力，使语音克隆功能不会显著损害系统的认知和语言能力。
与已有工作不同的是，Chroma的独特切入角度在于提出了一种分层生成架构，将语音合成任务分解为粗粒度声学建模和细粒度声学细化两个阶段。与现有方法的本质区别在于：(1) 与Moshi等全双工系统不同，Chroma不牺牲说话人保真度来换取低延迟，而是通过交错文本-音频调度(1:2)让语义理解和声学生成并行进行；(2) 与Spirit LM等使用统一token表示的模型不同，Chroma保留了文本和音频的模态区分，通过Reasoner提供语义上下文、Backbone负责粗粒度生成、Decoder负责细粒度细化的分工协作；(3) 与Qwen-Omni等并行双流架构不同，Chroma的Backbone和Decoder是串行但轻量级的，Decoder仅需100M参数且不依赖长上下文，从而在保持生成质量的同时大幅降低推理延迟。这种架构设计使得Chroma能够在不增加过多计算开销的情况下同时满足低延迟和高保真的双重需求。
核心方法
Chroma的整体思路可以理解为一个精心设计的分层生成流水线，将端到端语音对话分解为四个协同工作的模块。直觉上，人类说话时先形成语义意图（想说什么），再转化为语音信号（怎么说），最后补充音色、情感等个人特征。Chroma模仿这一过程：首先由Chroma Reasoner（基于Qwen2-Audio）处理输入语音，提取语义和声学特征并生成文本回复；然后Chroma Backbone（1B参数LLaMA变体）以1:2的比例交错生成文本token和粗粒度音频码本c0；接着轻量级Chroma Decoder（100M参数）基于Backbone的输出生成剩余7层RVQ码本c1到c7；最后Chroma Codec Decoder将完整码本序列重建为连续波形。这种设计的精妙之处在于，Reasoner提供语义上下文但不参与生成，Backbone专注于时序结构建模，Decoder负责细粒度声学细节，各模块各司其职又紧密配合。
Chroma的核心创新在于提出了交错文本-音频token调度和分层RVQ生成两个互补的技术方案。交错调度(1:2)是解决低延迟问题的关键：每当Reasoner输出一个文本token，Backbone就并行生成两个c0层音频token，这使得语义理解和声学生成可以同步进行，无需等待完整文本序列。与Spirit LM的简单交错不同，Chroma的交错比例经过精心设计为1:2，既能保持足够的语义上下文（每个文本token对应2帧音频，约40ms），又能最大化并行度。分层RVQ生成是解决高保真问题的关键：将8层RVQ码本的生成任务分解给两个模块——Backbone生成决定语音内容和时序结构的c0层，Decoder在每个时间步基于Backbone的hidden state和c0自回归生成c1到c7层，补充音色、韵律、发音细节。这种分解使得Decoder可以只关注当前帧，无需处理长上下文，从而将每帧的计算延迟控制在17.56ms。与Qwen3-Omni的MTP（多码本token预测）不同，Chroma的Decoder是轻量级的独立模块，不增加Backbone的复杂度。
方法步骤详情
Chroma的完整工作流程包含以下步骤：(1) 输入编码阶段，用户语音经过Qwen2-Audio编码器处理，提取声学特征，同时参考音频及其转录文本通过CSM-1B编码为embedding prompt，显式注入说话人音色信息；(2) 语义理解阶段，Chroma Reasoner使用交叉模态注意力机制融合文本和音频特征，通过TM-RoPE（时间对齐多模态旋转位置编码）实现时序对齐，输出文本token序列和多模态隐藏状态；(3) 粗粒度生成阶段，Reasoner的token embedding和hidden state作为统一上下文输入Backbone，Backbone以1:2比例交错生成文本token和c0层音频码本，每个文本token对应2个c0音频token；(4) 细粒度细化阶段，Chroma Decoder以Backbone当前时间步的hidden state h_t^B 和c0码本为条件，通过层特定投影头自回归生成剩余RVQ层 c_1^t, ..., c_{N-1}^t；(5) 波形重建阶段，Chroma Codec Decoder将每帧的完整码本序列 (c_0, c_1, ..., c_{N-1}) 拼接后输入因果CNN解码器，重建连续语音波形。在推理时，系统使用预填充策略：先将提示文本和提示音频编码为KV缓存，避免推理时重复计算，从而将TTFT压缩到146.87ms。
技术新颖性
Chroma的技术新颖性体现在多个层面：架构层面，它是首个将实时流式生成和个性化语音克隆统一在单一端到端系统中的模型，打破了这两个能力互斥的传统认知。与Moshi牺牲音色保真度换取实时性、ElevenLabs牺牲实时性换取保真度不同，Chroma通过精巧的分层设计同时实现了两者。技术层面，1:2交错调度比例是一个经过权衡的设计——1:1会降低并行度增加延迟，1:3会减少语义上下文降低生成质量，1:2在实验中取得了最佳平衡。分层RVQ生成将原本需要Backbone处理8层码本的任务分解为Backbone处理1层（决定内容）、Decoder处理7层（决定音质），使得Decoder可以使用更小的模型（100M vs Backbone的1B）和更短的上下文（仅当前帧 vs 完整历史），同时保持生成质量。训练策略上，两阶段训练（第一阶段联合训练Backbone和Decoder权重lambda=0.5，第二阶段冻结Backbone仅训练Decoder权重lambda=1）确保了粗粒度结构和细粒度细节的渐进式优化。数据方面，作者提出了LLM+TTS协同的数据生成管线，解决了高质量语音对话数据稀缺的问题——先用LLM生成文本回复，再用TTS合成匹配参考音频音色的语音作为训练目标。
实验结果
Chroma的实验结果展示了其在多个维度的出色表现。在最核心的语音克隆任务上，Chroma在CommonVoice数据集上的零样本说话人相似度（SIM）达到0.817，超过人类基线0.73达10.96%的相对提升，同时超越了F5-TTS（0.64）、Seed-TTS（0.76）、CosyVoice 3（0.72）等所有对比模型。在与商业系统ElevenLabs的对比中，Chroma在说话人相似度维度（SCMOS）获得40.6%的偏好率，与ElevenLabs的42.4%仅差1.8个百分点，表明在捕捉说话人特征方面具有可比能力。一个有趣的发现是，在直接对比ElevenLabs输出与真实人声的实验中，92%的评估者偏好ElevenLabs的合成语音而非真实录音，揭示了主观评估中自然度偏好对说话人保真度的压倒性影响。在系统效率方面，Chroma实现了146.87ms的TTFT（其中Reasoner占119.12ms、Backbone仅8.48ms）和0.43的RTF，生成速度是实时播放的2.3倍。在推理和对话能力评估中，尽管Chroma主要针对语音克隆优化，仍在URO-Bench上展现出竞争力：在推理任务Storal上达到71.14%（仅比9B参数的GLM-4-Voice低2.66个百分点），在口语对话任务MLC和CommonVoice上分别达到60.26%和62.07%为所有模型最高。这些结果表明，Chroma在保持强大认知能力的同时实现了高质量语音克隆，且仅需4B参数。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 零样本语音克隆 | 说话人相似度 SIM | 0.817 | 人类基线 0.73 / Seed-TTS 0.76 / CosyVoice 3 0.72 | 相对人类基线提升10.96%，超越所有对比模型 |
| 与ElevenLabs对比-说话人相似度 | SCMOS偏好率 | 40.6% | ElevenLabs 42.4% | 仅差1.8个百分点，可比能力 |
| 与ElevenLabs对比-自然度 | NCMOS偏好率 | 24.4% | ElevenLabs 57.2% | ElevenLabs在自然度方面领先 |
| 系统效率 | 首Token延迟 TTFT | 146.87ms | 亚秒级要求 | 远低于实时交互阈值 |
| 系统效率 | 实时因子 RTF | 0.43 | RTF<1.0为实时 | 生成速度为实时播放的2.3倍 |
| URO-Bench推理-TruthfulQA | 准确率 | 51.69% | GLM-4-Voice(9B) 59.28% | 仅4B参数，排名第二 |
| URO-Bench推理-GSM8K | 准确率 | 22.74% | GLM-4-Voice(9B) 30.93% | 仅4B参数，排名第二 |
| URO-Bench口语对话-MLC | 准确率 | 60.26% | GLM-4-Voice(9B) 57.82% | 所有模型最高 |
局限与改进
Chroma当前存在几个明显的局限性。首先，系统目前仅支持英语语音输出，虽然Reasoner支持中英文输入理解，但Codec Decoder和整体语音生成流程仅针对英语优化，这限制了系统在中文、多语言场景的应用。其次，Chroma不支持批处理（batch processing），所有延迟测量均在并发度为1的条件下进行，在实际部署中面对多用户并发请求时性能表现未知。第三，系统尚未集成RLHF或DPO等人类偏好优化技术，论文作者也承认这可能导致对话自然度和指令遵循能力的提升空间受限——这在与ElevenLabs的NCMOS对比中已有体现（24.4% vs 57.2%）。第四，语音克隆的伦理风险不容忽视，仅需几秒参考音频就能高保真克隆声音可能被用于欺诈、冒充等恶意用途，虽然论文讨论了伦理考量但尚未提供实际的防护机制。此外，从实验设计角度，URO-Bench评估使用的是基础（basic）轨道，可能无法充分反映系统在复杂对话场景下的表现；与ElevenLabs的对比样本量较小（15个样本x2维度=30对比较），统计显著性有待验证。
独立分析的弱点
尽管Chroma取得了显著成果，仍存在几个值得深入分析的弱点：(1) 自然度与保真度的权衡问题——NCMOS实验显示ElevenLabs在自然度上大幅领先（57.2% vs 24.4%），而真实人声对比实验更揭示92%的听众偏好合成语音而非真实录音，这说明Chroma的高保真克隆可能保留了真实人声中的不完美（如呼吸声、口音变化），反而降低了主观自然度感知。改进方向可以是引入可控的自然度增强模块，在保持说话人身份的同时优化听感。(2) Decoder的串行自回归生成——虽然单帧延迟仅17.56ms，但在生成38.8秒音频时仍需8.57秒（占总延迟的51.7%），成为系统瓶颈。可以探索并行解码策略或预测式MTP技术来加速。(3) 参考音频编码使用CSM-1B作为外部依赖——CSM-1B并非专门为实时对话设计，其编码质量和效率可能不是最优的，且引入额外的模型依赖增加了系统复杂度。改进方向是将参考音频编码整合进端到端训练流程。(4) 训练数据完全依赖合成数据——使用LLM+TTS管线生成训练数据可能导致分布偏移和误差累积，真实世界对话中的噪声、打断、情绪变化等复杂情况可能未被充分覆盖。(5) 缺乏工具调用和任务特定后训练——系统不具备调用外部API、执行命令等能力，限制了其作为通用助手的应用场景。
未来方向
论文作者和基于当前成果可以延伸出多个有价值的研究方向：(1) 多语言支持——当前系统仅输出英语语音，扩展Codec训练和Decoder模块以支持中文、多语言输出，特别是实现跨语言语音克隆（输入中文、用克隆音色输出英文）将大幅提升实用价值。(2) 集成MTP（多码本token预测）技术——Qwen3-Omni的MTP模块可以在Decoder阶段并行预测多层RVQ码本而非串行生成，这可能在不损害克隆质量的前提下进一步降低首包延迟。(3) 人类偏好优化——引入RLHF或DPO技术优化对话自然度和指令遵循能力，特别是在自然度维度缩小与ElevenLabs的差距。(4) 探索编码器-解码器架构——当前采用的仅解码器架构在可控性和跨模态对齐方面可能不如编码器-解码器设计，值得探索。(5) 工具调用和任务特定后训练——使系统能够调用外部API执行日程查询、信息检索等任务，扩展应用场景。(6) 水印和溯源技术——为生成的语音嵌入不可感知的水印，以应对语音克隆的伦理风险和法律合规需求。(7) 批处理和多用户并发支持——优化系统架构以支持高效的批处理推理，满足实际部署需求。
复现评估
Chroma在可复现性方面做出了重要贡献。作者已将完整的代码库、训练流程和预训练模型权重公开发布在GitHub（FlashLabs-AI-Corp/FlashLabs-Chroma）和HuggingFace（FlashLabs/Chroma-4B）。训练配置明确：基于PyTorch 2.7.1，使用AdamW优化器（学习率5乘以10的-5次方，批量大小4），在8块NVIDIA H200 GPU（141GB显存）上训练100K步，约6小时收敛。然而，复现存在一定门槛：(1) 训练需要8块H200 GPU（总显存1128GB），这对于大多数研究团队是难以企及的算力配置；(2) 训练数据使用LLM+TTS管线合成而非公开数据集，其他研究者需要自行构建类似管线；(3) 评估使用的SEED-TTS-EVAL框架和URO-Bench虽然公开但需要额外配置；(4) 与ElevenLabs的对比实验依赖商业API，其他人无法完全复现该部分结果。总体而言，代码和模型权重的开源使得推理复现相对容易，但训练复现需要较大的算力投入和数据构建工作。
论文图表