Qwen3 技术报告

  • MoE 模型:Qwen3-235B-A22B 和 Qwen3-30B-A3B;其中 235B 和 30B 分别是总参数量,22B 和 3B 分别是激活参数量。
  • 密集模型:Qwen3-32B、Qwen3-14B、Qwen3-8B、Qwen3-4B、Qwen3-1.7B 和 Qwen3-0.6B。

整体架构:

1) 包含num_experts个轻量级专家网络(Qwen3MoeMLP)的并行计算单元;

2) 基于注意力机制的路由网络(gate)。

在计算过程中,路由网络通过动态决策机制为每个输入Token生成路由决策,筛选出匹配度最高的top_k个专家节点。随后,系统将根据路由权重对选定专家的计算结果进行加权融合,最终生成该隐层的表征输出。

那么同样我们对比DeepSeekMOE,Qwen3MOE有两个点的改变:

1)没有shared expert。

2) 优化了MLP架构,变为Qwen3MoeSparseMoeBlock。

模型特性优化总结表

特性实现细节
注意力机制改进的Qwen3Attention(支持Flash Attention优化)
MoE路由策略Top-K专家选择(默认K=2),支持权重归一化
专家结构每个专家为标准MLP(hidden_size → moe_intermediate_size → hidden_size)
动态专家分配每间隔decoder_sparse_step层使用MoE(其他层使用标准MLP)
负载均衡机制通过router_logits计算辅助损失,防止专家极化
计算优化使用index_add操作实现零浪费的专家计算

对比传统MOE优化效果:

优化方向Qwen3-MoE实现方案对比传统MoE模型优势
路由机制Top-K + 动态权重归一化(norm_topk_prob)缓解专家利用不均衡问题,相比Mixtral的固定权重分配更灵活
稀疏模式分层动态稀疏(decoder_sparse_step控制MoE层间隔)混合密集与稀疏计算,相比全MoE结构降低计算开销
内存优化logits_to_keep参数支持部分logits计算长序列生成时内存占用减少,优于Mixtral的全序列计算
注意力机制改进的Flash Attention 3.0集成相比标准Attention实现,训练速度提升,显存占用减少
负载均衡改进的辅助损失函数(load_balancing_loss_func+自研调整系数)专家利用率从Mixtral的提升,防止专家极化
动态计算mlp_only_layers参数跳过MoE层支持按需切换密集/稀疏模式,相比固定结构推理灵活性提升

性能方面,在代码、数学、通用能力等基准测试中,旗舰模型 Qwen3-235B-A22B 与 DeepSeek-R1、o1、o3-mini、Grok-3 和 Gemini-2.5-Pro 等顶级模型表现相当

此外,小型 MoE 模型 Qwen3-30B-A3B 的激活参数数量是 QwQ-32B 的 10%,表现却更胜一筹。甚至像 Qwen3-4B 这样的小模型也能匹敌 Qwen2.5-72B-Instruct 的性能

性能大幅提升的同时,Qwen3 的部署成本还大幅下降,仅需 4 张 H20 即可部署满血版,显存占用仅为性能相近模型的三分之一

核心亮点

  • 多种思考模式

Qwen3 模型支持两种思考模式:

  1. 思考模式:在这种模式下,模型会逐步推理,经过深思熟虑后给出最终答案。这种方法非常适合需要深入思考的复杂问题。
  2. 非思考模式:在此模式中,模型提供快速、近乎即时的响应,适用于那些对速度要求高于深度的简单问题。

这种灵活性使用户能够根据具体任务控制模型进行“思考”的程度。例如,复杂的问题可以通过扩展推理步骤来解决,而简单的问题则可以直接快速作答,无需延迟。至关重要的是,这两种模式的结合大大增强了模型实现稳定且高效的“思考预算”控制能力。如上文所述,Qwen3 展现出可扩展且平滑的性能提升,这与分配的计算推理预算直接相关。这样的设计让用户能够更轻松地为不同任务配置特定的预算,在成本效益和推理质量之间实现更优的平衡。

下图为在 AIME24、AIME25、LiveCodeBech(v5)和 GPQA Diamond 等基准测试集中,非思考模式与思考模式的思考预算变化趋势。

  • 多语言

Qwen3 模型支持 119 种语言和方言。这一广泛的多语言能力为国际应用开辟了新的可能性,让全球用户都能受益于这些模型的强大功能。

语系语种&方言
印欧语系英语、法语、葡萄牙语、德语、罗马尼亚语、瑞典语、丹麦语、保加利亚语、俄语、捷克语、希腊语、乌克兰语、西班牙语、荷兰语、斯洛伐克语、克罗地亚语、波兰语、立陶宛语、挪威语(博克马尔语)、挪威尼诺斯克语、波斯语、斯洛文尼亚语、古吉拉特语、拉脱维亚语、意大利语、奥克语、尼泊尔语、马拉地语、白俄罗斯语、塞尔维亚语、卢森堡语、威尼斯语、阿萨姆语、威尔士语、西里西亚语、阿斯图里亚语、恰蒂斯加尔语、阿瓦德语、迈蒂利语、博杰普尔语、信德语、爱尔兰语、法罗语、印地语、旁遮普语、孟加拉语、奥里雅语、塔吉克语、东意第绪语、伦巴第语、利古里亚语、西西里语、弗留利语、撒丁岛语、加利西亚语、加泰罗尼亚语、冰岛语、托斯克语、阿尔巴尼亚语、林堡语、罗马尼亚语、达里语、南非荷兰语、马其顿语僧伽罗语、乌尔都语、马加希语、波斯尼亚语、亚美尼亚语
汉藏语系中文(简体中文、繁体中文、粤语)、缅甸语
亚非语系阿拉伯语(标准语、内志语、黎凡特语、埃及语、摩洛哥语、美索不达米亚语、塔伊兹-阿德尼语、突尼斯语)、希伯来语、马耳他语
南岛语系印度尼西亚语、马来语、他加禄语、宿务语、爪哇语、巽他语、米南加保语、巴厘岛语、班加语、邦阿西楠语、伊洛科语、瓦雷语(菲律宾)
德拉威语泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语
突厥语系土耳其语、北阿塞拜疆语、北乌兹别克语、哈萨克语、巴什基尔语、鞑靼语
壮侗语系泰语、老挝语
乌拉尔语系芬兰语、爱沙尼亚语、匈牙利语
南亚语系越南语、高棉语
其他日语、韩语、格鲁吉亚语、巴斯克语、海地语、帕皮阿门托语、卡布维尔迪亚努语、托克皮辛语、斯瓦希里语
  • 增强的 Agent 能力

我们优化了 Qwen3 模型的 Agent 和 代码能力,同时也加强了对 MCP 的支持。

预训练

在预训练方面,Qwen3 的数据集相比 Qwen2.5 有了显著扩展。Qwen2.5是在 18 万亿个 token 上进行预训练的,而 Qwen3 使用的数据量几乎是其两倍,达到了约 36 万亿个 token,涵盖了 119 种语言和方言。为了构建这个庞大的数据集,我们不仅从网络上收集数据,还从 PDF 文档中提取信息。我们使用 Qwen2.5-VL 从这些文档中提取文本,并用 Qwen2.5 改进提取内容的质量。为了增加数学和代码数据的数量,我们利用 Qwen2.5-Math 和 Qwen2.5-Coder 这两个数学和代码领域的专家模型合成数据,合成了包括教科书、问答对以及代码片段等多种形式的数据。

Qwen3模型采用三阶段预训练过程:

  1. 通用阶段 (S1): 在第一阶段,所有Qwen3模型使用4,096 token的序列长度,在超过30万亿token的数据上进行训练 。此阶段旨在建立模型的语言能力和通用世界知识基础,训练数据覆盖119种语言和方言 。
  2. 推理阶段 (S2): 为了进一步提升推理能力,此阶段的预训练语料库增加了STEM、编码、推理和合成数据的比例 。模型使用4,096 token的序列长度,在约5万亿高质量token上进行进一步预训练 。在此阶段还加速了学习率衰减 。
  3. 长上下文阶段: 在最后一个预训练阶段,收集高质量长上下文语料库,将Qwen3模型的上下文长度扩展到32,768 token 。长上下文语料库中,75%的文本长度在16,384到32,768 token之间,25%的文本长度在4,096到16,384 token之间 。报告提及沿用Qwen2.5的做法,使用ABF技术将RoPE的基础频率从10,000提高到1,000,000 。同时,引入YARN和Dual Chunk Attention (DCA)技术,在推理过程中实现序列长度容量的四倍增长 。

类似于Qwen2.5,Qwen3根据这三个预训练阶段开发了最优超参数(如学习率调度器和批次大小)预测的缩放律 。通过广泛实验,系统研究了模型架构、训练数据、训练阶段与最优训练超参数之间的关系 。最终为每个密集模型和MoE模型设定了预测的最优学习率和批次大小策略。

由于模型架构的改进、训练数据的增加以及更有效的训练方法,Qwen3 Dense 基础模型的整体性能与参数更多的Qwen2.5基础模型相当。例如,Qwen3-1.7B/4B/8B/14B/32B-Base 分别与 Qwen2.5-3B/7B/14B/32B/72B-Base 表现相当。特别是在 STEM、编码和推理等领域,Qwen3 Dense 基础模型的表现甚至超过了更大规模的 Qwen2.5 模型。对于 Qwen3 MoE 基础模型,它们在仅使用 10% 激活参数的情况下达到了与 Qwen2.5 Dense 基础模型相似的性能。这带来了训练和推理成本的显著节省。

后训练

为了开发能够同时具备思考推理和快速响应能力的混合模型,我们实施了一个四阶段的训练流程。该流程包括:(1)长思维链冷启动,(2)长思维链强化学习,(3)思维模式融合,以及(4)通用强化学习。

后训练部分详细介绍了Qwen3模型的后训练流程和评估结果 。Qwen3的后训练流程策略性地设计了两个核心目标:思维控制和强到弱蒸馏 。

思维控制 (Thinking Control):

思维控制涉及将“非思维”模式和“思维”模式集成到模型中,为用户提供灵活性,选择模型是否进行推理,并通过指定思维过程的token预算来控制思考的深度 。

强到弱蒸馏 (Strong-to-Weak Distillation):

强到弱蒸馏旨在优化轻量级模型的后训练过程 。通过利用大型模型的知识,显著降低了构建小型模型所需的计算成本和开发工作 。

如图1所示,Qwen3系列的旗舰模型遵循复杂的四阶段训练过程 。前两个阶段侧重于发展模型的“思维”能力 。后两个阶段旨在将强大的“非思维”功能整合到模型中 。

初步实验表明,将教师模型的输出logit直接蒸馏到轻量级学生模型中,可以有效增强其性能,同时保持对其推理过程的细粒度控制 。这种方法避免了为每个小型模型单独执行详尽的四阶段训练过程 。它带来了更好的即时性能(通过更高的Pass@1分数体现),也提高了模型的探索能力(通过改进的Pass@64结果反映) 。此外,它以更高的训练效率实现了这些提升,所需的GPU小时仅为四阶段训练方法的1/10 。

在第一阶段,我们使用多样的的长思维链数据对模型进行了微调,涵盖了数学、代码、逻辑推理和 STEM 问题等多种任务和领域。这一过程旨在为模型配备基本的推理能力。后训练始于策划一个涵盖数学、代码、逻辑推理和通用STEM问题等广泛类别的综合数据集 。数据集中的每个问题都配有经过验证的参考答案或基于代码的测试用例 。该数据集作为长链式思维(long-CoT)训练“冷启动”阶段的基础 。数据集构建涉及严格的两阶段过滤过程:查询过滤和响应过滤 。报告详细描述了过滤过程,包括使用Qwen2.5-72B-Instruct识别和移除不易验证的查询,排除无需CoT推理即可正确回答的查询,以及对生成的候选响应进行多项标准的严格过滤 。此阶段的目标是在模型中注入基础的推理模式,而不过度强调即时推理性能 。

第二阶段的重点是大规模强化学习,利用基于规则的奖励来增强模型的探索和钻研能力。推理RL阶段使用的查询-验证对必须满足四个标准:未在冷启动阶段使用、对冷启动模型可学习、尽可能具有挑战性、涵盖广泛的子领域 。共收集了3,995对查询-验证对,并使用GRPO更新模型参数 。报告提及使用大批次大小和每次查询多次rollout,以及利用离线训练提高样本效率,对训练过程有益 。通过控制模型的熵,平衡探索和利用,实现了训练和验证性能的持续改进 。例如,Qwen3-235B-A22B模型的AIME’24分数在170个RL训练步骤中从70.1提高到85.1 

在第三阶段,我们在一份包括长思维链数据和常用的指令微调数据的组合数据上对模型进行微调,将非思考模式整合到思考模型中。确保了推理和快速响应能力的无缝结合。思维模式融合阶段的目标是将“非思维”能力整合到之前开发的“思维”模型中 。这允许开发者管理和控制推理行为,同时降低部署独立模型处理思维和非思维任务的成本和复杂性 。为此,在推理RL模型上进行持续监督微调(SFT),并设计聊天模板来融合两种模式 。

SFT数据构建:SFT数据集结合了“思维”和“非思维”数据 。为了不损害第二阶段模型的性能,“思维”数据是使用第二阶段模型本身通过对第一阶段查询进行拒绝采样生成的 。“非思维”数据则精心策划,涵盖编码、数学、指令遵循、多语言任务、创意写作、问答和角色扮演等广泛任务 。报告还提及使用自动生成的清单评估“非思维”数据的响应质量,并增加低资源语言翻译任务的比例以增强性能 。

聊天模板设计:为了更好地集成两种模式并允许用户动态切换模型的思维过程,Qwen3设计了聊天模板 。通过在用户查询或系统消息中引入/think/no think标志,模型可以根据用户的输入选择适当的思维模式 。即使在非思维模式样本中,也保留了空的思维块,以确保模型内部格式的一致性 。默认情况下,模型在思维模式下运行,因此也包含一些用户查询不含/think标志的思维模式训练样本 。对于更复杂的多轮对话,随机插入多个/think/no think标志,模型响应遵循最后遇到的标志 。

思维预算:思维模式融合的另一个优势是,一旦模型学会以非思维和思维模式响应,它自然会发展出处理中间情况的能力—基于不完整的思考生成响应 。这为实现模型思维过程的预算控制奠定了基础 。当模型的思考长度达到用户定义的阈值时,会手动停止思考过程并插入停止思考指令,然后模型根据其累积的推理生成最终响应 。报告指出,这种能力并非显式训练所得,而是思维模式融合应用自然产生的结果 。

最后,在第四阶段,我们在包括指令遵循、格式遵循和 Agent 能力等在内的 20 多个通用领域的任务上应用了强化学习,以进一步增强模型的通用能力并纠正不良行为。

通用RL阶段旨在广泛增强模型在各种场景下的能力和稳定性 。为此,建立了覆盖20多个不同任务的复杂奖励系统,每个任务都有定制的评分标准 。这些任务专门针对以下核心能力的提升:指令遵循、格式遵循、偏好对齐、Agent能力和专业场景下的能力(如RAG任务) 。

报告提及使用了三种不同类型的奖励来提供反馈:基于规则的奖励(用于推理RL阶段和通用任务,如指令遵循和格式遵循)、基于模型的奖励(带参考答案,允许更灵活地处理多样化任务)、基于模型的奖励(不带参考答案,利用人类偏好数据训练奖励模型,处理更广泛的查询并增强模型的互动性和帮助性)。

强到弱蒸馏 (Strong-to-Weak Distillation):

强到弱蒸馏流程专门为优化轻量级模型而设计,包括5个密集模型(Qwen3-0.6B、1.7B、4B、8B和14B)和1个MoE模型(Qwen3-30B-A3B)。这种方法在增强模型性能的同时,有效赋予了强大的模式切换能力 。蒸馏过程分为两个主要阶段:

  1. 离线蒸馏 (Off-policy Distillation): 在初始阶段,结合教师模型在/think/no think模式下生成的输出进行响应蒸馏 。这有助于轻量级学生模型发展基本的推理技能和在不同思维模式之间切换的能力 。
  2. 在线蒸馏 (On-policy Distillation): 在此阶段,学生模型生成在线序列进行微调 。具体来说,采样提示,学生模型以/think/no think模式生成响应 。然后通过将学生的logit与教师模型(Qwen3-32B或Qwen3-235B-A22B)的logit对齐,最小化KL散度来微调学生模型 。

通过评估Qwen3-32B模型在不同训练阶段的性能,报告得出结论:第三阶段将非思维模式整合到模型中,模型开始具备模式切换的初步能力 。第三阶段还增强了思维模式下的通用和指令遵循能力 。第四阶段进一步加强了模型在思维和非思维模式下的通用、指令遵循和Agent能力,确保了准确的模式切换 。

然而,对于知识、STEM、数学和编码等任务,思维模式融合和通用RL并未带来显著改进,甚至在一些挑战性任务上,思维模式下的性能有所下降 。报告推测这种性能下降是由于模型在更广泛的通用任务上进行训练,可能会损害其在处理复杂问题时的专业能力,并表示在Qwen3开发过程中接受了这种性能权衡以增强模型的整体多功能性 。

高级用法

我们提供了一种软切换机制,允许用户在 enable_thinking=True 时动态控制模型的行为。具体来说,您可以在用户提示或系统消息中添加 /think 和 /no_think 来逐轮切换模型的思考模式。在多轮对话中,模型会遵循最近的指令。

未来发展:

Qwen3 代表了我们在通往通用人工智能(AGI)和超级人工智能(ASI)旅程中的一个重要里程碑。通过扩大预训练和强化学习的规模,我们实现了更高层次的智能。我们无缝集成了思考模式与非思考模式,为用户提供了灵活控制思考预算的能力。此外,我们还扩展了对多种语言的支持,帮助全球更多用户。

展望未来,我们计划从多个维度提升我们的模型。这包括优化模型架构和训练方法,以实现几个关键目标:扩展数据规模、增加模型大小、延长上下文长度、拓宽模态范围,并利用环境反馈推进强化学习以进行长周期推理。我们认为,我们正从专注于训练模型的时代过渡到以训练 Agent 为中心的时代。

CTC 强制对齐-音频和文本

CTC算法

CTC算法的关键在于使用一个特殊的标记,通常称为空白标记(blank token)。这是一个我们人为加入词汇表的额外标记。在这个例子中,空白标记被表示为_。我们用这个特殊的标记来表示字母组之间的硬边界。

CTC模型的完整输出类似于如下的序列:Copied

B_R_II_O_N_||_S_AWW_|||||_S_OMEE_TH_ING_||_C_L_O_S_E||TO|_P_A_N_I_C_||_ON||HHI_S||_OP_P_O_N_EN_T_'SS||_F_AA_C_E||_W_H_EN||THE||M_A_NN_||||_F_I_N_AL_LL_Y||||_RREE_C_O_GG_NN_II_Z_ED|||HHISS|||_ER_RRR_ORR||||

该序列中的|标记是单词分隔符。在这个例子中,我们使用|而不是空格作为单词分隔符,这样可以更容易地看出单词的分隔位置,但它们的作用是一样的。

CTC空白标记使我们能够过滤掉重复的字母。例如预测序列中的最后一个单词,_ER_RRR_ORR。如果没有CTC空白标记,这个单词看起来是这样的:Copied

ERRRRORR

如果我们简单地去掉非CTC结果中的重复字符,那么它就变成了EROR。显然这不是正确的拼写。但是有了CTC空白标记,我们就可以在每个字母组中去掉重复的字母:Copied

_ER_RRR_ORR

变为:Copied

_ER_R_OR

最后我们去掉空白标记_,得到最终的单词:Copied

ERROR

如果我们将这种逻辑应用到整个文本,包括|,并将剩余的|字符替换为空格,那么最终的CTC解码输出会变成:Copied

BRION SAW SOMETHING CLOSE TO PANIC ON HIS OPPONENT'S FACE WHEN THE MAN FINALLY RECOGNIZED HIS ERROR

总结一下,CTC模型对应每20毫秒的输入音频(包括部分重叠)会生成一个预测标记。这样的预测规则会生成很多重复的字母。利用CTC空白标记,我们可以轻松地移除这些重复的字母,而不会破坏单词的正确拼写。这是一种非常简单和方便的方法,可以解决输出文本与输入音频的对齐问题。💡 在实际的Wav2Vec2模型中,CTC空白标记与填充标记“是相同的。模型会预测很多这样的“标记,例如当当前20毫秒的音频没有明确的字符可以预测时。使用相同的标记作为填充和CTC空白标记可以简化解码算法,并有助于保持词汇表的小规模。

我们可以在Transomer编码模型简单地加入CTC:将编码器的输出序列进入一个线性层,该线性层将音频特征映射到词汇表。模型使用特殊的CTC损失进行训练。

CTC的一个缺点在于,它可能会输出听起来正确但拼写不正确的单词。毕竟,CTC分类头只考虑了单个字符,而没有处理整个单词。我们可以使用额外的语言模型来提高音频的转录质量。这个语言模型实际上是作为了CTC输出的拼写检查器。

CTC(Connectionist Temporal Classification)强制对齐是一种将音频与已知文本精确对齐的技术,广泛应用于自动字幕生成、语音切分、语音合成等领域。其核心原理结合了声学模型的输出和动态规划算法(如 Viterbi 算法)来实现字级别的时间戳对齐。


核心原理

1. 输入数据

  • log_probs:模型输出的对数概率张量,形状为 (B, T, C),其中:
    • B:批次大小(当前仅支持 B=1);
    • T:时间帧数;
    • C:字符集大小(包括 blank 符号)。
  • targets:目标文本的索引序列,形状为 (B, L),其中 L 为目标序列长度。
  • input_lengths(可选):输入序列的实际长度。
  • target_lengths(可选):目标序列的实际长度。
  • blank:blank 符号的索引,默认值为 0

2. 对齐过程

forced_align 函数通过动态规划算法(如 Viterbi)在所有可能的对齐路径中寻找概率最高的路径。该算法通过填充一个大小为 (S, T) 的矩阵(其中 S 是目标序列长度,T 是时间帧数),并记录每个状态的最优前驱,以便在填充完成后回溯得到最优路径。

3. 输出结果

  • alignment:每个时间步对应的标签索引,形状为 (T,)
  • scores:每个时间步对应标签的对数概率,形状为 (T,)

通过这些输出,可以确定每个字符在音频中的时间位置,实现字级别的对齐。


🔧 实际应用

为了简化强制对齐的流程,torchaudio 提供了高级 API torchaudio.pipelines.Wav2Vec2FABundle,该 API 集成了预训练的 Wav2Vec2 模型和 forced_align 函数,用户只需提供音频和对应的文本,即可获取每个词或字符的时间戳。该工具支持多语言对齐,适用于各种语音处理任务。

MCP-大模型上下文协议

MCP:大模型接入万物的通用协议,智能体时代的HTTP!

一、什么是MCP(Model Context Protocol)

定义

MCP(Model Context Protocol,模型上下文协议) ,2024年11月底,由 Anthropic 推出的一种开放标准,旨在统一大模型与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题,MCP 使得 AI 应用能够安全地访问和操作本地及远程数据,为 AI 应用提供了连接万物的接口。

Function Calling是AI模型调用函数的机制,MCP是一个标准协议,使大模型与API无缝交互,而AI Agent是一个自主运行的智能系统,利用Function Calling和MCP来分析和执行任务,实现特定目标。

MCP 的价值

举个栗子,在过去,为了让大模型等 AI 应用使用数据,要么复制粘贴,要么上传知识库,非常局限。

即使是最强大模型也会受到数据隔离的限制,形成信息孤岛,要做出更强的大模型,每个新数据源都需要自己重新定制实现,使真正互联的系统难以扩展,存在很多的局限性。

现在,MCP 可以直接在 AI 与数据(包括本地数据和互联网数据)之间架起一座桥梁,通过 MCP 服务器和 MCP 客户端,大家只要都遵循这套协议,就能实现“万物互联”。

有了MCP,可以和数据和文件系统、开发工具、Web 和浏览器自动化、生产力和通信、各种社区生态能力全部集成,实现强大的协作工作能力,它的价值远不可估量。

MCP 与 Function Calling 的区别

  • MCP(Model Context Protocol),模型上下文协议
  • Function Calling,函数调用

这两种技术都旨在增强 AI 模型与外部数据的交互能力,但 MCP 不止可以增强 AI 模型,还可以是其他的应用系统。

Function Calling

数据安全性

这样一个理想的“万物互联”生态系统看着很让人着迷。

但是大家是不是担心通过 MCP Server 暴露出来的数据会泄露或被非法访问,这个头疼的问题 MCP 也考虑到了。

MCP 通过标准化的数据访问接口,大大减少了直接接触敏感数据的环节,降低了数据泄露的风险。

还有,MCP 内置了安全机制,确保只有经过验证的请求才能访问特定资源,相当于在数据安全又加上了一道防线。同时,MCP协议还支持多种加密算法,以确保数据在传输过程中的安全性。

例如,MCP 服务器自己控制资源,不需要将 API 密钥等敏感信息提供给 LLM 提供商。这样一来,即使 LLM 提供商受到攻击,攻击者也无法获取到这些敏感信息。

不过,MCP 这套协议/标准,需要大家一起来共建,这个生态才会繁荣,现在,只是测试阶段,一切才刚刚开始,当然,还会涌现出更多的问题。

工作原理

MCP 协议采用了一种独特的架构设计,它将 LLM 与资源之间的通信划分为三个主要部分:客户端、服务器和资源。

客户端负责发送请求给 MCP 服务器,服务器则将这些请求转发给相应的资源。这种分层的设计使得 MCP 协议能够更好地控制访问权限,确保只有经过授权的用户才能访问特定的资源。

以下是 MCP 的基本工作流程:

  • 初始化连接:客户端向服务器发送连接请求,建立通信通道。
  • 发送请求:客户端根据需求构建请求消息,并发送给服务器。
  • 处理请求:服务器接收到请求后,解析请求内容,执行相应的操作(如查询数据库、读取文件等)。
  • 返回结果:服务器将处理结果封装成响应消息,发送回客户端。
  • 断开连接:任务完成后,客户端可以主动关闭连接或等待服务器超时关闭。

MCP 核心架构

MCP 遵循客户端-服务器架构(client-server),其中包含以下几个核心概念:

  • MCP 主机(MCP Hosts):发起请求的 LLM 应用程序(例如 Claude Desktop、IDE 或 AI 工具)。
  • MCP 客户端(MCP Clients):在主机程序内部,与 MCP server 保持 1:1 的连接。
  • MCP 服务器(MCP Servers):为 MCP client 提供上下文、工具和 prompt 信息。
  • 本地资源(Local Resources):本地计算机中可供 MCP server 安全访问的资源(例如文件、数据库)。
  • 远程资源(Remote Resources):MCP server 可以连接到的远程资源(例如通过 API)。

共分为了下面五个部分:

  • MCP Hosts: Hosts 是指 LLM 启动连接的应用程序,像 Cursor, Claude Desktop、Cline 这样的应用程序。
  • MCP Clients: 客户端是用来在 Hosts 应用程序内维护与 Server 之间 1:1 连接。
  • MCP Servers: 通过标准化的协议,为 Client 端提供上下文、工具和提示。
  • Local Data Sources: 本地的文件、数据库和 API。
  • Remote Services: 外部的文件、数据库和 API。

整个 MCP 协议核心的在于 Server,因为 Host 和 Client 相信熟悉计算机网络的都不会陌生,非常好理解,但是 Server 如何理解呢?

看看 Cursor 的 AI Agent 发展过程,我们会发现整个 AI 自动化的过程发展会是从 Chat 到 Composer 再进化到完整的 AI Agent。

AI Chat 只是提供建议,如何将 AI 的 response 转化为行为和最终的结果,全部依靠人类,例如手动复制粘贴,或者进行某些修改。

AI Composer 是可以自动修改代码,但是需要人类参与和确认,并且无法做到除了修改代码之外的其它操作。

AI Agent 是一个完全的自动化程序,未来完全可以做到自动读取 Figma 的图片,自动生产代码,自动读取日志,自动调试代码,自动 push 代码到 GitHub。

而 MCP Server 就是为了实现 AI Agent 的自动化而存在的,它是一个中间层,告诉 AI Agent 目前存在哪些服务,哪些 API,哪些数据源,AI Agent 可以根据 Server 提供的信息来决定是否调用某个服务,然后通过 Function Calling 来执行函数。

MCP Client

MCP client 充当 LLM 和 MCP server 之间的桥梁,MCP client 的工作流程如下:

  • MCP client 首先从 MCP server 获取可用的工具列表。
  • 将用户的查询连同工具描述通过 function calling 一起发送给 LLM。
  • LLM 决定是否需要使用工具以及使用哪些工具。
  • 如果需要使用工具,MCP client 会通过 MCP server 执行相应的工具调用。
  • 工具调用的结果会被发送回 LLM。
  • LLM 基于所有信息生成自然语言响应。
  • 最后将响应展示给用户。

Claude Desktop 和Cursor都支持了MCP Server接入能力,它们就是作为 MCP client来连接某个MCP Server感知和实现调用。

MCP Server

MCP server 是 MCP 架构中的关键组件,它可以提供 3 种主要类型的功能:

  • 资源(Resources):类似文件的数据,可以被客户端读取,如 API 响应或文件内容。
  • 工具(Tools):可以被 LLM 调用的函数(需要用户批准)。
  • 提示(Prompts):预先编写的模板,帮助用户完成特定任务。

这些功能使 MCP server 能够为 AI 应用提供丰富的上下文信息和操作能力,从而增强 LLM 的实用性和灵活性。

你可以在 MCP Servers Repository 和 Awesome MCP Servers 这两个 repo 中找到许多由社区实现的 MCP server。使用 TypeScript 编写的 MCP server 可以通过 npx 命令来运行,使用 Python 编写的 MCP server 可以通过 uvx 命令来运行。

通信机制

MCP 协议支持两种主要的通信机制:基于标准输入输出的本地通信和基于SSEServer-Sent Events)的远程通信。

这两种机制都使用 JSON-RPC 2.0 格式进行消息传输,确保了通信的标准化和可扩展性。

  • 本地通信通过 stdio 传输数据,适用于在同一台机器上运行的客户端和服务器之间的通信。
  • 远程通信利用 SSE 与 HTTP 结合,实现跨网络的实时数据传输,适用于需要访问远程资源或分布式部署的场景。

二、MCP的功能与应用:

如何使用 MCP

如果你还没有尝试过如何使用 MCP 的话,我们可以考虑用 Cursor(本人只尝试过 Cursor),Claude Desktop 或者 Cline 来体验一下。

当然,我们并不需要自己开发 MCP Servers,MCP 的好处就是通用、标准,所以开发者并不需要重复造轮子(但是学习可以重复造轮子)。

首先推荐的是官方组织的一些 Server:官方的 MCP Server 列表

目前社区的 MCP Server 还是比较混乱,有很多缺少教程和文档,很多的代码功能也有问题,我们可以自行尝试一下 Cursor Directory 的一些例子,具体的配置和实战笔者就不细讲了,大家可以参考官方文档。

MCP的功能

MCP通过引入多样化的MCP Server能力,显著增强了AI工具的功能,例如我们常用的Cursor和Claude。以下是一些官方参考服务器,展示了MCP的核心功能和SDK的应用:

数据与文件系统:

文件系统:提供安全文件操作,带可配置的访问控制。

PostgreSQL:提供只读数据库访问,具备架构检查功能。

SQLite:支持数据库交互和商业智能功能。

Google Drive:实现Google Drive的文件访问和搜索功能。

开发工具:

Git:工具用于读取、搜索和操作Git仓库。

GitHub:集成仓库管理、文件操作和GitHub API。

GitLab:支持项目管理的GitLab API集成。

Sentry:从http://Sentry.io获取并分析问题。

网络与浏览器自动化:

Brave Search:利用Brave的搜索API进行网络和本地搜索。

Fetch:为LLM优化的网络内容获取和转换。

Puppeteer:提供浏览器自动化和网页抓取功能。

生产力和通信:

Slack:支持频道管理和消息功能。

Google Maps:提供位置服务、路线和地点详情。

Memory:基于知识图谱的持久记忆系统。

AI与专业工具:

EverArt:使用多种模型进行AI图像生成。

Sequential Thinking:通过思维序列进行动态问题解决。

AWS KB Retrieval:使用Bedrock Agent Runtime从AWS知识库检索。

官方集成工具:

这些MCP服务器由公司维护,用于其平台:

Axiom:使用自然语言查询和分析日志、跟踪和事件数据。

Browserbase:云端自动化浏览器交互。

Cloudflare:在Cloudflare开发者平台上部署和管理资源。

E2B:在安全的云沙箱中执行代码。

Neon:与Neon无服务器Postgres平台交互。

Obsidian Markdown Notes:读取和搜索Obsidian知识库中的Markdown笔记。

Qdrant:使用Qdrant向量搜索引擎实现语义记忆。

Raygun:访问崩溃报告和监控数据。

Search1API:统一的API用于搜索、爬虫和网站地图。

Tinybird:与Tinybird无服务器ClickHouse平台交互。

集成工具:

Docker:管理容器、镜像、卷和网络。

Kubernetes:管理pod、部署和服务。

Linear:项目管理和问题跟踪。

Snowflake:与Snowflake数据库交互。

Spotify:控制Spotify播放和管理播放列表。

Todoist:任务管理集成。

三、怎么使用和开发MCP Server

使用

目前支持的部分工具列表(更多见这里):

英文语音识别模型:Parakeet TDT 0.6B V2

https://huggingface.co/nvidia/parakeet-tdt-1.1b

parakeet-tdt-1.1b 是一个自动语音识别 (ASR) 模型,可将语音转录为小写英文字母。该模型由 NVIDIA NeMo 和 Suno.ai 团队联合开发。它是 FastConformer [1] TDT [2](约 11 亿个参数)模型的 XXL 版本。

英伟达在发布了一款开源语音识别模型:Parakeet TDT 0.6B V2,其以 600M 参数登顶 Hugging Face Open ASR 榜单。

平均词错误率(WER)仅 6.05%,超越所有主流闭源模型。它能在 1 秒内转录 60 分钟高质量音频。

基于 FastConformer 架构和 TDT 解码器,仅用 600M 参数实现超低 WER 和极快推理速度。该模型基于 NVIDIA NeMo 和 Suno 团队收集和准备的 64K 小时英语语音进行训练。

该模型采用 FastConformer-TDT 架构

FastConformer 是对传统 Conformer 模型的优化版本,采用了 8 倍深度可分离卷积下采样(8x depthwise-separable convolutional downsampling),以提高计算效率。

TDT(Token-and-Duration Transducer) 是对传统 Transducer 的一种泛化方式,它将 “音素(token)”与“持续时间(duration)”的预测过程解耦。与传统 Transducer 在推理阶段产生大量空白(blank)输出不同,TDT 模型可以通过持续时间预测跳过大多数 blank(例如本模型 parakeet-tdt-1.1b 最多可跳过 4 帧),从而大幅提升推理速度。关于 TDT 的详细内容,请参见文章:Efficient Sequence Transduction by Jointly Predicting Tokens and Durations。

The training dataset consists of private subset with 40K hours of English speech plus 24K hours from the following public datasets:

  • Librispeech 960 hours of English speech
  • Fisher Corpus
  • Switchboard-1 Dataset
  • WSJ-0 and WSJ-1
  • National Speech Corpus (Part 1, Part 6)
  • VCTK
  • VoxPopuli (EN)
  • Europarl-ASR (EN)
  • Multilingual Librispeech (MLS EN) – 2,000 hour subset
  • Mozilla Common Voice (v7.0)
  • People’s Speech – 12,000 hour subset

自动语音识别(ASR)模型的性能通常通过词错误率(Word Error Rate, WER)来衡量。由于该数据集在多个领域上进行了训练,并且包含了更大规模的语料库,因此在通用音频转写任务中通常表现更好。

下表总结了本集合中各可用模型在使用Transducer 解码器下的性能表现。所有 ASR 模型的性能均以贪婪解码(greedy decoding)方式计算的 词错误率(WER%) 进行报告。

模型TokenizerVocabulary SizeAMIEarnings-22Giga SpeechLS test-cleanSPGI SpeechTEDLIUM-v3Vox PopuliCommon Voice
指标SentencePiece Unigram102415.9014.659.551.392.623.423.565.48

核心优势

  • • 极致转录效率:60 分钟音频仅需 1 秒内完成转录(A100 推理)
  • • OpenASR 榜首表现:超越 Whisper、Conformer、Wav2Vec 等主流闭源模型
  • • 极小参数量:仅 0.6B(轻量级,适合边缘设备)
  • • 高精度:平均 WER 6.05%(Hugging Face Open ASR 榜单),优于 Whisper-large-v3
  • • 高鲁棒性:多语速、多口音、多录音环境下表现稳定(英文)

应用场景推荐

  • • 实时会议转写
  • • 手机/设备端语音助手
  • • 视频字幕生成
  • • 大模型音频输入预处理器
  • • 教育/课程转录系统

技术构建说明

  • • 架构:TDT(Time-Depth Transformer),专注于时间维度建模
  • • 数据:英伟达自建 + 公共语音数据集大规模训练
  • • 推理引擎优化:支持 TensorRT / ONNX Runtime 等高性能部署方案

LLM分词器-SentencePiece/tiktoken/subword-nmt

SentencePiece 简介

https://github.com/google/sentencepiece

SentencePiece 是一种无监督的文本 tokenizer 和 detokenizer,主要用于基于神经网络的文本生成系统,其中,词汇量在神经网络模型训练之前就已经预先确定了。 SentencePiece 实现了subword单元(例如,字节对编码 (BPE))和 unigram 语言模型),并可以直接从原始句子训练字词模型(subword model)。 这使得我们可以制作一个不依赖于特定语言的预处理和后处理的纯粹的端到端系统。

SentencePiece 在大模型领域主要用于文本的 分词 和 编码

分词 是将文本分割成一个个独立的词语或符号。传统的中文分词方法,例如 BMM 分词、HMM 分词,都是基于规则的,需要人工制定分词规则。而 SentencePiece 则是基于 无监督学习 的,它可以自动学习文本的语义和结构,并根据学习结果进行分词。

编码 是将分词后的词语或符号转换为数字形式,以便计算机能够处理。SentencePiece 使用了一种称为 字节对编码 的方法,它可以将每个词语或符号编码成一个或多个字节。字节对编码的优点是能够有效地利用空间,并且可以将词语或符号之间的关系编码到编码中。

SentencePiece 在大模型领域具有以下优势:

  • 分词效果好,能够准确地识别词语和符号的边界。
  • 编码效率高,能够节省空间。
  • 能够将词语或符号之间的关系编码到编码中,有利于模型学习。

因此,SentencePiece 已经被广泛应用于各大模型,例如 Google 的 BERTGPT-3,以及阿里巴巴的 M6 等。

简单来说,SentencePiece 就是大模型领域的一个 分词和编码工具。它可以帮助大模型更好地理解和处理文本。

自监督训练原理

SentencePiece 的自监督训练模型原理是通过 无监督学习 的方式,学习文本的语义和结构,并根据学习结果进行分词和编码。

具体来说,SentencePiece 的训练过程可以分为以下几个步骤:

  1. 数据准备:首先需要准备一个文本语料库,语料库中的文本可以是任何类型,例如新闻文章、书籍、代码等。
  2. 模型训练:使用无监督学习算法训练 SentencePiece 模型,模型的输入是文本语料库,输出是分词后的文本。
  3. 模型评估:使用评估指标评估模型的性能,例如分词准确率、召回率等。

SentencePiece 使用的无监督学习算法是一种称为 Masked Language Modeling (MLM) 的算法。MLM 的基本思想是:将文本中的部分词语或符号进行遮蔽,然后让模型预测被遮蔽的词语或符号。通过这种方式,模型可以学习文本的语义和结构。

在 SentencePiece 中,MLM 的具体实现如下:

  1. 随机选择文本中的部分词语或符号进行遮蔽。
  2. 将被遮蔽的词语或符号替换为一个特殊符号,例如 [MASK]
  3. 将处理后的文本输入模型,让模型预测被遮蔽的词语或符号。

通过这种方式,模型可以学习到被遮蔽词语或符号与周围词语或符号之间的关系,从而提高分词和编码的准确性。

SentencePiece 的自监督训练模型具有以下优势:

  • 不需要人工制定分词规则,能够自动学习文本的语义和结构。
  • 分词效果好,能够准确地识别词语和符号的边界。
  • 编码效率高,能够节省空间。

SentencePiece 的自监督训练模型已经被广泛应用于各大模型,例如 Google 的 BERT、GPT-3,以及阿里巴巴的 M6 等。

SentencePiece中包含有四个部分:

  • Normalizer: 规一化操作,类似Unicode把字符转为统一格式。
  • Trainer: 从规一化后的语料中学习subword的切分模型。
  • Encoder: 对应预处理时的tokenization操作,把句子转为对应的subword或id。
  • Decoder: 对应后处理时的detokenization操作,把subword或id还原为原有句子

和 SentencePiece 类似的工具

  • Jieba:Jieba 是一个中文分词工具,它使用了一种称为 最大似然法 的方法进行分词。Jieba 的分词效果较好,并且速度较快。
  • Hmmseg:Hmmseg 是另一个中文分词工具,它使用了一种称为 隐马尔可夫模型 的方法进行分词。Hmmseg 的分词效果较好,并且可以支持多种语言。
  • Stanford CoreNLP:Stanford CoreNLP 是一个自然语言处理工具包,它包含了分词、词性标注、句法分析等功能。Stanford CoreNLP 的分词效果较好,并且可以支持多种语言。

使用建议:

  • 如果需要对中文文本进行分词,并且对分词效果要求较高,可以选择 SentencePiece、Jieba 或 Hmmseg。
  • 如果需要对多种语言文本进行分词,可以选择 Stanford CoreNLP。
  • 如果需要对文本进行分词和编码,并且对速度要求较高,可以选择 Jieba。
  • 如果需要对文本进行分词和编码,并且对分词效果要求较高,可以选择 SentencePiece 或 Hmmseg。

TiToken 简介

Tiktoken 的功能与 SentencePiece 类似,都是用于文本的 分词 和 编码

Tiktoken 是一个基于 BPE 算法的 快速分词器,它专门针对 GPT-4 和 ChatGPT 等大模型进行了优化。Tiktoken 的主要特点如下:

  • 速度快:Tiktoken 的分词速度比 SentencePiece 快很多,可以满足大模型训练和推理的需求。
  • 效果好:Tiktoken 的分词效果与 SentencePiece 相当,能够准确地识别词语和符号的边界。
  • 易用性:Tiktoken 提供了简单的 API 接口,方便使用。

Tiktoken 与 SentencePiece 的主要区别 如下:

  • 分词算法:Tiktoken 使用 BPE 算法进行分词,而 SentencePiece 使用的是无监督学习算法
  • 速度:Tiktoken 的分词速度比 SentencePiece 快很多。
  • 模型:Tiktoken 专门针对 GPT-4 和 ChatGPT 等大模型进行了优化,而 SentencePiece 则是通用的。

具体使用建议:

  • 如果需要对文本进行快速分词,并且对分词效果要求较高,可以选择 Tiktoken。
  • 如果需要对文本进行分词和编码,并且需要支持多种语言,可以选择 SentencePiece。
  • 如果需要对 GPT-4 或 ChatGPT 等大模型进行训练或推理,可以选择 Tiktoken。

LLM分词算法

分词算法有BPE(Byte Pair Encoding,BPE )、BBPE(Byte-level BPE)、WordPiece、ULM【Unigram Language Model】等。

Byte Pair Encoding (BPE)

BPE最早是一种数据压缩算法,由Sennrich等人于2015年引入到NLP领域并很快得到推广。该算法简单有效,因而目前它是最流行的方法。GPT-2和RoBERTa使用的Subword算法都是BPE。

BPE获得Subword的步骤如下:

  1. 准备足够大的训练语料,并确定期望的Subword词表大小;
  2. 将单词拆分为成最小单元。比如英文中26个字母加上各种符号,这些作为初始词表;
  3. 在语料上统计单词内相邻单元对的频数,选取频数最高的单元对合并成新的Subword单元;
  4. 重复第3步直到达到第1步设定的Subword词表大小或下一个最高频数为1.

Byte-level BPE

Unicode: Unicode 是一种字符集,旨在涵盖地球上几乎所有的书写系统和字符。它为每个字符分配了一个唯一的代码点(code point)用于标识字符。Unicode 不关注字符在计算机内部的具体表示方式,而只是提供了一种字符到代码点的映射。Unicode 的出现解决了字符集的碎片化问题,使得不同的语言和字符能够在一个共同的标准下共存。然而,Unicode 并没有规定如何在计算机内存中存储和传输这些字符。

UTF-8: UTF-8(Unicode Transformation Format-8)是一种变长的字符编码方案,它将 Unicode 中的代码点转换为字节序列。UTF-8 的一个重要特点是它是向后兼容 ASCII 的,这意味着标准的 ASCII 字符在 UTF-8 中使用相同的字节表示,从而确保现有的 ASCII 文本可以无缝地与 UTF-8 共存。在 UTF-8 编码中,字符的表示长度可以是1到4个字节,不同范围的 Unicode 代码点使用不同长度的字节序列表示,这样可以高效地表示整个 Unicode 字符集。UTF-8 的编码规则是:

  • 单字节字符(ASCII 范围内的字符)使用一个字节表示,保持与 ASCII 编码的兼容性。
  • 带有更高代码点的字符使用多个字节表示。UTF-8 使用特定的字节序列来指示一个字符所需的字节数,以及字符的实际数据。

例如,英文字母 “A” 的 Unicode 代码点是U+0041,在 UTF-8 中表示为 0x41(与 ASCII 编码相同);而中文汉字 “你” 的 Unicode 代码点是U+4F60,在 UTF-8 中表示为0xE4 0xBD 0xA0三个字节的序列。

所以简单的来说:

  • Unicode 是字符集,为每个字符分配唯一的代码点。
  • UTF-8 是一种基于 Unicode 的字符编码方式,用于在计算机中存储和传输字符。

Byte(字节):计算机存储和数据处理时,字节是最小的单位。一个字节包含8个(Bit)二进制位,每个位可以是0或1,每位的不同排列和组合可以表示不同的数据,所以一个字节能表示的范围是256个。

BBPE核心思想将BPE的从字符级别扩展到子节(Byte)级别。BPE的一个问题是如果遇到了unicode编码,基本字符集可能会很大。BBPE就是以一个字节一种“字符”,不管实际字符集用了几个字节来表示一个字符。这样的话,基础字符集的大小就锁定在了256(2^8)。采用BBPE的好处是可以跨语言共用词表,显著压缩词表的大小。而坏处就是,对于类似中文这样的语言,一段文字的序列长度会显著增长。因此,BBPE based模型可能比BPE based模型表现的更好。然而,BBPE sequence比起BPE来说略长,这也导致了更长的训练/推理时间。BBPE其实与BPE在实现上并无大的不同,只不过基础词表使用256的字节集

Byte-level BPE(BBPE)和Byte-Pair Encoding (BPE)区别就是BPE是最小词汇是字符级别,而BBPE是字节级别的,通过UTF-8的编码方式这一个字节的256的范围理论上可以表示这个世界上的所有字符。

所以实现的步骤和BPE就是实现的粒度不一样,其他的都是一样的。

  1. 初始词表:构建初始词表,包含一个字节的所有表示(256)
  2. 构建频率统计:统计所有子词单元对(两个连续的子词)在文本中的出现频率。
  3. 合并频率最高的子词对:选择出现频率最高的子词对,将它们合并成一个新的子词单元,并更新词汇表。
  4. 重复合并步骤:不断重复步骤 2 和步骤 3,直到达到预定的词汇表大小、合并次数,或者直到不再有有意义的合并(即,进一步合并不会显著提高词汇表的效益)。
  5. 分词:使用最终得到的词汇表对文本进行分词。

大模型中,以Byte-level BPE(BBPE)这种方式进行分词是不会出现OOV

WordPiece

WordPiece算法与 BPE(Byte-Pair Encoding)都是子词分词算法,但它们在合并策略上存在关键区别。WordPiece的主要目标是通过最大化训练数据的似然(likelihood),即在每次迭代中,选择能最大化训练数据似然增益的子词对(subword pair)进行合并。

Google的Bert模型在分词的时候使用的是WordPiece算法。与BPE算法类似,WordPiece算法也是每次从词表中选出两个子词合并成新的子词。与BPE的最大区别在于,如何选择两个子词进行合并:BPE选择频数最高的相邻子词合并,而WordPiece选择能够提升语言模型概率最大的相邻子词加入词表。

看到这里,你可能不清楚WordPiece是如何选取子词的。这里,通过形式化方法,能够清楚地理解WordPiece在合并这一步是如何作出选择的。假设句子S=(t1,t2,…,tn)由n个子词组成,ti表示子词,且假设各个子词之间是独立存在的,则句子S的语言模型似然值等价于所有子词概率的乘积:

假设把相邻位置的x和y两个子词进行合并,合并后产生的子词记为z,此时句子S似然值的变化可表示为:

从上面的公式,很容易发现,似然值的变化就是两个子词之间的互信息。简而言之,WordPiece每次选择合并的两个子词,他们具有最大的互信息值,也就是两子词在语言模型上具有较强的关联性,它们经常在语料中以相邻方式同时出现。

算法流程如下:

  1. 准备足够大的训练语料
  2. 确定期望的subword词表大小
  3. 将单词拆分成字符序列
  4. 基于第3步数据训练语言模型
  5. 从所有可能的subword单元中选择加入语言模型后能最大程度地增加训练数据概率的单元作为新的单元
  6. 重复第5步直到达到第2步设定的subword词表大小或概率增量低于某一阈值

Unigram Language Model (ULM)

与WordPiece一样,Unigram Language Model(ULM)同样使用语言模型来挑选子词。不同之处在于,BPE和WordPiece算法的词表大小都是从小到大变化,属于增量法。Unigram Language Model则是减量法,即先初始化一个大词表,根据评估准则不断丢弃词表,直到满足限定条件。ULM算法考虑了句子的不同分词可能,因而能够输出带概率的多个子词分段。

我们接下来看看ULM是如何操作的。

对于句子S,x→=(x1,x2,…,xm)为句子的一个分词结果,由m个子词组成。所以,当前分词下句子S的似然值可以表示为:

对于句子S,挑选似然值最大的作为分词结果,则可以表示为

这里U(x)包含了句子的所有分词结果。在实际应用中,词表大小有上万个,直接罗列所有可能的分词组合不具有操作性。针对这个问题,可通过维特比算法得到x∗来解决。

那怎么求解每个子词的概率P(xi)呢?ULM通过EM算法来估计。假设当前词表V, 则M步最大化的对象是如下似然函数:

其中,|D|是语料库中语料数量。上述公式的一个直观理解是,将语料库中所有句子的所有分词组合形成的概率相加。

但是,初始时,词表V并不存在。因而,ULM算法采用不断迭代的方法来构造词表以及求解分词概率:

  1. 初始时,建立一个足够大的词表。一般,可用语料中的所有字符加上常见的子字符串初始化词表,也可以通过BPE算法初始化。
  2. 针对当前词表,用EM算法求解每个子词在语料上的概率。
  3. 对于每个子词,计算当该子词被从词表中移除时,总的loss降低了多少,记为该子词的loss。
  4. 将子词按照loss大小进行排序,丢弃一定比例loss最小的子词(比如20%),保留下来的子词生成新的词表。这里需要注意的是,单字符不能被丢弃,这是为了避免OOV情况。
  5. 重复步骤2到4,直到词表大小减少到设定范围。

可以看出,ULM会保留那些以较高频率出现在很多句子的分词结果中的子词,因为这些子词如果被丢弃,其损失会很大。

算法

  1. 准备足够大的训练语料
  2. 确定期望的subword词表大小
  3. 给定词序列优化下一个词出现的概率
  4. 计算每个subword的损失
  5. 基于损失对subword排序并保留前X%。为了避免OOV,建议保留字符级的单元
  6. 重复第3至第5步直到达到第2步设定的subword词表大小或第5步的结果不再变化

BPE分词算法-原理和代码实现

三种主流的Subword算法,它们分别是:Byte Pair Encoding (BPE)、WordPiece和Unigram Language Model。

执行分词的算法模型称为分词器(Tokenizer),划分好的一个个词称为Token(中文叫词元,为啥不直接叫Word?接着往后看),这个过程称为Tokenization

我们将一个个的token(可以理解为小片段)表示向量,我们分词的目的就是尽可能的让这些向量蕴含更多有用的信息,然后把这些向量输入到算法模型中。

由于一篇文本的词往往太多了,为了方便算法模型训练,我们会选取出频率(也可能是其它的权重)最高的若干个词组成一个词表(Vocabulary)

‼️古典分词方法的缺点

一个句子,使用不同的规则,将有许多种不同的分词结果。古典分词方法的缺点非常明显:

  • 对于未在词表中出现的词(Out Of Vocabulary, OOV),模型将无法处理(未知符号标记为 [UNK])。
  • 词表中的低频词/稀疏词在模型训无法得到训练(因为词表大小有限,太大的话会影响效率)。
  • ⭐️很多语言难以用空格进行分词,例如英语单词的多形态,”look”衍生出的”looks”, “looking”, “looked”,其实都是一个意思,但是在词表中却被当作不同的词处理,模型也无法通过old, older, oldest之间的关系学到smart, smarter, smartest之间的关系。这一方面增加了训练冗余,另一方面也造成了大词汇量问题。

Character embedding,是一种更为极端的分词方法,直接把一个词分成一个一个的字母和特殊符号。虽然能解决OOV问题,也避免了大词汇量问题,但缺点也太明显了,粒度太细,训练花费的成本太高,但这种思想或许我们后面会用到。

BERT算法的横空出世,NLP中的很多领域都被颠覆性的改变了,BERT也称为了一个非常主流的NLP算法。由于BERT的特性,要求分词方法也必须作出改变。这就对应提出了Subword算法(或成为WordPiece),该算法已经成为一种标配。

基于子词的分词方法(Subword Tokenization)

可见不论是传统分词算法的局限性,还是BERT的横空出世,都要求我们提出新的分词算法,下面就轮到本文的主角登场:基于子词的分词方法(Subword Tokenization),简称为Subword算法,意思就是把一个词切成更小的一块一块的子词。如果我们能使用将一个token分成多个subtokens,上面的问题就能很好的解决

这种方法的目的是通过一个有限的词表来解决所有单词的分词问题,同时尽可能将结果中token的数目降到最低。例如,可以用更小的词片段来组成更大的词,例如:

unfortunately” = “un” + “for” + “tun” + “ate” + “ly”。

可以看到,有点类似英语中的词根词缀拼词法,其中的这些小片段又可以用来构造其他词。可见这样做,既可以降低词表的大小同时对相近词也能更好地处理

Subword与传统分词方法的比较

  • 传统词表示方法无法很好的处理未知或罕见的词汇(OOV问题)。
  • 传统词tokenization方法不利于模型学习词缀之间的关系,例如模型学到的“old”, “older”, and “oldest”之间的关系无法泛化到“smart”, “smarter”, and “smartest”。
  • Character embedding作为OOV的解决方法粒度太细。
  • Subword粒度在词与字符之间,能够较好的平衡OOV问题。

目前有三种主流的Subword算法,它们分别是:Byte Pair Encoding (BPE)、WordPiece和Unigram Language Model。

字节对编码(BPE, Byte Pair Encoding)

字节对编码(BPE, Byte Pair Encoder),又称digram coding双字母组合编码,是一种数据压缩算法,用来在固定大小的词表中实现可变⻓度的子词。该算法简单有效,因而目前它是最流行的方法。

BPE首先将词分成单个字符,然后依次用另一个字符替换频率最高一对字符,直到循环次数结束。

接下来详细介绍BPE在分词中的算法过程:

算法过程

  1. 准备语料库,确定期望的subword词表大小等参数
  2. 通常在每个单词末尾添加后缀</w>,统计每个单词出现的频率,例如,low的频率为5,那么我们将其改写为"l o w </ w>”:5 注:停止符</w>的意义在于标明subword是词后缀。举例来说:st不加</w>可以出现在词首,如st ar;加了</w>表明该子词位于词尾,如we st</w>,二者意义截然不同
  3. 将语料库中所有单词拆分为单个字符,用所有单个字符建立最初的词典,并统计每个字符的频率,本阶段的subword的粒度是字符
  4. 挑出频次最高的符号对,比如说 th 组成的 th,将新字符加入词表,然后将语料中所有该字符对融合(merge),即所有 th 都变为 th。 注:新字符依然可以参与后续的merge,有点类似哈夫曼树,BPE实际上就是一种贪心算法
  5. 重复遍历 2和 3 操作,直到词表中单词数达到设定量下一个最高频数为1,如果已经打到设定量,其余的词汇直接丢弃

注:看似我们要维护两张表,一个词表,一个字符表,实际上只有一张,词表只是为了我们方便理解。</w> 是为了明确 subword 是否是词尾,它在训练、merge 过程中和普通字符一样对待,在最终输出时作为重建原词的标记使用。

我们举一个完整的例子,来直观地看一下这个过程:

1、获取语料库,这样一段话为例:FloydHub is the fastest way to build, train and deploy deep learning models. Build deep learning models in the cloud. Train deep learning models.

2、拆分,加后缀,统计词频:

3、建立词表,统计字符频率(顺便排个序):

4、以第一次迭代为例,将字符频率最高的de替换为de,后面依次迭代:

5、更新词表 继续迭代直到达到预设的subwords词表大小或下一个最高频的字节对出现频率为1。

如果将词表大小设置为10,最终的结果为:

d e
r n
rn i
rni n
rnin g</w>
o de
ode l
m odel
l o
l e

这样我们就得到了更加合适的词表,这个词表可能会出现一些不是单词的组合,但是其本身有意义的一种形式

BPE的优点

上面例子中的语料库很小,知识为了方便我们理解BPE的过程,但实际中语料库往往非常非常大,无法给每个词(token)都放在词表中。BPE的优点就在于,可以很有效地平衡词典大小和编码步骤数(将语料编码所需要的token数量)。

随着合并的次数增加,词表大小通常先增加后减小。迭代次数太小,大部分还是字母,没什么意义;迭代次数多,又重新变回了原来那几个词。所以词表大小要取一个中间值。

BPE的缺点

  • 对于同一个句子, 例如Hello world,如图所示,可能会有不同的Subword序列。不同的Subword序列会产生完全不同的id序列表示,这种歧义可能在解码阶段无法解决。在翻译任务中,不同的id序列可能翻译出不同的句子,这显然是错误的。
  • 在训练任务中,如果能对不同的Subword进行训练的话,将增加模型的健壮性,能够容忍更多的噪声,而BPE的贪心算法无法对随机分布进行学习。

个人理解:我感觉缺点直接可以忽略

BPE的适用范围

BPE一般适用在欧美语言拉丁语系中,因为欧美语言大多是字符形式,涉及前缀、后缀的单词比较多。而中文的汉字一般不用BPE进行编码,因为中文是字无法进行拆分。对中文的处理通常只有分词和分字两种。理论上分词效果更好,更好的区别语义。分字效率高、简洁,因为常用的字不过3000字,词表更加简短。

BPE的实现

实现代码如下:

import re, collections

def get_vocab(filename):
    vocab = collections.defaultdict(int)
    with open(filename, 'r', encoding='utf-8') as fhand:
        for line in fhand:
            words = line.strip().split()
            for word in words:
                vocab[' '.join(list(word)) + ' </w>'] += 1
    return vocab

def get_stats(vocab):
    pairs = collections.defaultdict(int)
    for word, freq in vocab.items():
        symbols = word.split()
        for i in range(len(symbols)-1):
            pairs[symbols[i],symbols[i+1]] += freq
    return pairs

def merge_vocab(pair, v_in):
    v_out = {}
    bigram = re.escape(' '.join(pair))
    p = re.compile(r'(?<!\S)' + bigram + r'(?!\S)')
    for word in v_in:
        w_out = p.sub(''.join(pair), word)
        v_out[w_out] = v_in[word]
    return v_out

def get_tokens(vocab):
    tokens = collections.defaultdict(int)
    for word, freq in vocab.items():
        word_tokens = word.split()
        for token in word_tokens:
            tokens[token] += freq
    return tokens

跑一个例子试一下,这里已经对原句子进行了预处理:

vocab = {'l o w </w>': 5, 'l o w e r </w>': 2, 'n e w e s t </w>': 6, 'w i d e s t </w>': 3}
print('==========')
print('Tokens Before BPE')
tokens = get_tokens(vocab)
print('Tokens: {}'.format(tokens))
print('Number of tokens: {}'.format(len(tokens)))
print('==========')

num_merges = 5
for i in range(num_merges):
    pairs = get_stats(vocab)
    if not pairs:
        break
    best = max(pairs, key=pairs.get)
    vocab = merge_vocab(best, vocab)
    print('Iter: {}'.format(i))
    print('Best pair: {}'.format(best))
    tokens = get_tokens(vocab)
    print('Tokens: {}'.format(tokens))
    print('Number of tokens: {}'.format(len(token

结果:

==========
Tokens Before BPE
Tokens: defaultdict(<class 'int'>, {'l': 7, 'o': 7, 'w': 16, '</w>': 16, 'e': 17, 'r': 2, 'n': 6, 's': 9, 't': 9, 'i': 3, 'd': 3})
Number of tokens: 11
==========
Iter: 0
Best pair: ('e', 's')
Tokens: defaultdict(<class 'int'>, {'l': 7, 'o': 7, 'w': 16, '</w>': 16, 'e': 8, 'r': 2, 'n': 6, 'es': 9, 't': 9, 'i': 3, 'd': 3})
Number of tokens: 11
==========
Iter: 1
Best pair: ('es', 't')
Tokens: defaultdict(<class 'int'>, {'l': 7, 'o': 7, 'w': 16, '</w>': 16, 'e': 8, 'r': 2, 'n': 6, 'est': 9, 'i': 3, 'd': 3})
Number of tokens: 10
==========
Iter: 2
Best pair: ('est', '</w>')
Tokens: defaultdict(<class 'int'>, {'l': 7, 'o': 7, 'w': 16, '</w>': 7, 'e': 8, 'r': 2, 'n': 6, 'est</w>': 9, 'i': 3, 'd': 3})
Number of tokens: 10
==========
Iter: 3
Best pair: ('l', 'o')
Tokens: defaultdict(<class 'int'>, {'lo': 7, 'w': 16, '</w>': 7, 'e': 8, 'r': 2, 'n': 6, 'est</w>': 9, 'i': 3, 'd': 3})
Number of tokens: 9
==========
Iter: 4
Best pair: ('lo', 'w')
Tokens: defaultdict(<class 'int'>, {'low': 7, '</w>': 7, 'e': 8, 'r': 2, 'n': 6, 'w': 9, 'est</w>': 9, 'i': 3, 'd': 3})
Number of tokens: 9
==========

编码与解码

上面的过程称为编码。解码过程比较简单,如果相邻子词间没有中止符,则将两子词直接拼接,否则两子词之间添加分隔符。 如果仍然有子字符串没被替换但所有token都已迭代完毕,则将剩余的子词替换为特殊token,如<unk>。例如:

# 编码序列
["the</w>", "high", "est</w>", "moun", "tain</w>"]

# 解码序列
"the</w> highest</w> mountain</w>"

如何调包使用BPE

BPE 可以直接用最经典的 subword-nmt 包,不需要自己实现

Nexa AI OmniAudio-2.6B:全球最快的边缘部署音频语言模型

OmniAudio 是全球最快、最高效的音频语言模型——OmniAudio – 2.6B 是一款高性能的多模态音频语言模型,参数量为 2.6B,能够高效处理文本和音频输入。它将 Gemma – 2 – 2B、WhisperTurbo 以及定制的 Projector 模块集成到一个统一框架中,突破了传统模型串联 ASR(自动语音识别)和 LLM(大语言模型)的架构限制,实现了更低延迟、更高效能的音频 – 文本一体化处理。这种一体化的设计使得音频信息能够直接在模型内部进行处理和转换,避免了传统架构中多次数据传输和处理带来的延迟和资源浪费。

huggingface : https://huggingface.co/NexaAIDev/OmniAudio-2.6B

二、技术原理

1、模型架构

Gemma – 2 – 2B:作为负责文本处理的基础语言模型,它拥有强大的语言理解和生成能力。其内部的神经网络结构经过精心设计和训练,能够对音频文本转换后的文本进行深入分析和理解。例如,在处理复杂的语义关系时,Gemma – 2 – 2B 可以准确地识别出词汇之间的逻辑联系,从而为后续的语言生成提供准确的基础。

  • WhisperTurbo是优化后的音频编码器,能够生成高质量的音频嵌入。它通过对音频信号进行特征提取和编码,将音频信息转化为模型可处理的形式。WhisperTurbo 在处理音频信号时,能够捕捉到音频中的细微特征,如语音的语调、语速变化等,这些特征对于准确理解音频内容至关重要。
  • 定制Projector模块:将 Whisper 的音频 token 转化为与 Gemma 文本嵌入对齐的序列,确保音频 – 文本模态的高效融合。它通过一种特殊的映射机制,使得音频和文本在向量空间中能够准确对应,同时保持语言模型的原始性能。这种对齐方式使得模型在处理音频输入时,能够像处理文本输入一样高效地进行语言理解和生成。

2、训练方法

  • 预训练阶段:基于 MLSEnglish10K 转录数据集进行基础的音频 – 文本对齐能力训练。为了支持多任务应用,数据集中引入了特殊的 <|transcribe|>token,用以区分语音转文本和内容补全任务,确保模型在不同场景下性能的一致性。在预训练过程中,模型通过大量的音频 – 文本对数据学习,逐渐掌握音频和文本之间的对应关系,形成初步的音频处理和语言理解能力。
  • 监督微调阶段(SFT):使用合成数据集进行指令调优。数据集同样以 MLSEnglish10K 为基础,结合专有模型对上下文进行扩展,生成丰富的 “音频 – 文本” 对。通过这种方式,模型具备了更强的音频输入语义理解和会话生成能力。例如,在处理特定领域的音频数据时,模型能够根据微调数据中的领域知识,准确理解音频中的专业术语和特定表达方式。
  • 直接偏好优化(DPO):利用 GPT – 4O API 对模型初始输出进行评估,标注不正确的输出为 “拒绝”(rejected),并生成替代答案作为 “偏好”(preferred)参考。为了保持 Gemma – 2 的文本处理性能,额外增加了偏好训练步骤,使用 Gemma – 2 的原始文本作为 “标准” 训练模型,在处理音频输入时匹配其高水平表现。通过 DPO,模型能够不断优化自己的输出,使其更加符合人类的语言习惯和实际需求。

三、功能特点

1、处理速度快

在 2024 Mac Mini M4 Pro 上,使用 Nexa SDK 并采用 FP16 GGUF 格式时,模型可实现每秒 35.23 个令牌的处理速度,而在 Q4_K_M GGUF 格式下,可处理每秒 66 个令牌。相比之下,Qwen2 – Audio – 7B 在相似硬件上只能处理每秒 6.38 个令牌,展示出显著的速度优势,能够满足实时音频处理的需求。例如,在实时语音翻译场景中,快速的处理速度可以确保翻译结果几乎与语音同步输出,大大提高了沟通效率。

2、资源效率高

模型的紧凑设计有效减少了对云资源的依赖,使其成为功率和带宽受限的可穿戴设备、汽车系统及物联网设备的理想选择,降低了设备的运行成本和对网络的依赖。在一些网络信号不稳定的偏远地区,或者在电池续航有限的可穿戴设备上,OmniAudio – 2.6B 能够凭借其低资源消耗的特点,稳定地运行并提供准确的音频处理服务。

3、高准确性和灵活性

尽管 OmniAudio – 2.6B 专注于速度和效率,但其在准确性方面也表现不俗,适用于转录、翻译、摘要等多种任务。无论是实时语音处理还是复杂的语言任务,OmniAudio – 2.6B 都能够提供精准的结果。例如,在处理学术讲座的音频转录时,模型能够准确识别专业术语和复杂的句子结构,生成高质量的文字转录稿。

四、应用场景

1、智能家居

可以集成到智能家居设备中,如智能音箱、智能家电等,实现语音控制和交互。用户可以通过语音指令控制家电的开关、调节温度、查询信息等,提供更加便捷的智能家居体验。例如,用户只需说出 “打开客厅的灯”,智能音箱中的 OmniAudio – 2.6B 模型就能准确识别指令并控制灯光设备,让家居生活更加智能和便捷。

2、车载系统

在汽车中,OmniAudio – 2.6B 可以用于语音导航、语音娱乐系统、车辆状态查询等功能。驾驶员可以通过语音与车辆进行交互,提高驾驶安全性和便利性。比如,驾驶员在行驶过程中无需手动操作,只需说出 “导航到最近的加油站”,车载系统就能快速响应并规划路线,避免了分心驾驶带来的安全隐患。

3、远程医疗

在远程医疗领域,该模型可以用于实时转录医生与患者的对话、翻译医疗文件和语音指令等,提高医疗服务的效率和质量,方便医患之间的沟通。例如,在跨国远程会诊中,OmniAudio – 2.6B 可以实时翻译不同语言的对话,让医生和患者能够无障碍交流,确保诊断和治疗的准确性。

4、可穿戴设备

如智能手表、智能耳机等可穿戴设备可以利用 OmniAudio – 2.6B 实现语音助手功能,用户可以通过语音查询天气、设置提醒、发送短信等,为用户提供更加便捷的操作方式。比如,用户在运动时双手不方便操作,只需对着智能手表说出 “设置明天早上 7 点的闹钟”,手表就能快速完成设置,提升了用户体验。

Kimi-Audio 音频基础大模型

遵循自然语言处理领域的发展轨迹,音频处理正快速从”单任务专用模型”向”多任务通用模型”演进。

Kimi-Audio被设计为一个通用的音频基础模型,能够在单一统一框架内处理多种音频处理任务。主要特性包括:

  • 通用能力:支持自动语音识别(ASR)、音频问答(AQA)、自动音频描述(AAC)、语音情感识别(SER)、声音事件/场景分类(SEC/ASC)以及端到端语音对话等多样化任务。
  • 顶尖性能:在多项音频基准测试中达到最先进水平(参见评估部分和技术报告)。
  • 大规模预训练:基于超过1300万小时的多样化音频数据(语音、音乐、环境声)和文本数据进行预训练,具备强大的音频推理和语言理解能力。
  • 创新架构:采用混合音频输入(连续声学向量+离散语义标记)和具有并行输出头的LLM核心架构,可同步生成文本和音频标记。
  • 高效推理:配备基于流匹配技术的分块流式解码器,实现低延迟音频生成。
  • 开源计划:公开预训练和指令微调的代码与模型检查点,并发布完整评估工具包以促进社区研发。

Introduction

现有研究在构建通用音频基础模型方面仍存在不足:

1)仅聚焦特定任务类型(如音频理解、音频生成或语音对话);

2)忽视音频预训练,仅在下游任务微调LLM

Kimi-Audio作为开源音频基础模型,通过三大核心要素实现技术突破:

• 架构创新
模型包含音频分词器(输入)、解分器(输出)和音频LLM核心(处理)三大组件。采用离散语义音频标记作为基础表征,同时在输入端融合连续声学向量以增强感知能力,在输出端结合离散文本token以提升生成能力。通过将音频token率压缩至12.5Hz,有效弥合文本与音频序列的模态鸿沟。

• 数据工程
构建包含语音增强、说话人分离、转写过滤等流程的数据处理管线,采集超1300万小时预训练数据针对监督微调阶段,我们创新提出纯开源数据解决方案——仅依赖公开资源与处理工具即可构建高质量SFT数据集,无需商业数据采购

• 训练策略
基于预训练LLM初始化模型,设计三级渐进式预训练任务:1)单模态(纯文本/音频)知识学习;2)音频-文本跨模态映射;3)音文交错联合建模。在微调阶段开发高效训练方案提升任务泛化性。

针对音频模型评估标准不统一的问题,开发了包含语音识别、音频理解、语音对话等全维度评测工具包。

Architecture

Kimi-Audio作为一种音频基础模型,采用统一架构实现音频理解、生成与对话的全方位处理。如图2所示,系统包含三大核心组件:

  1. 音频分词器:通过12.5Hz帧率的向量量化将输入音频转换为离散语义标记,同时提取连续声学向量增强感知能力;
  2. 音频大模型:采用共享Transformer层处理多模态输入后,通过并行输出头同步生成语义标记与文本标记,提升生成能力;
  3. 音频解码器:基于流匹配技术将预测的离散语义标记重建为连贯音频波形。

该一体化架构使Kimi-Audio能在单一模型中无缝处理语音识别、理解及对话等多样化任务。

音频分词器

本模型采用离散语义标记+连续声学向量的混合分词策略,在保留离散标记语义效率的同时,通过连续表征捕捉丰富声学细节。

离散语义token:继承GLM-4-Voice方案,基于Whisper编码器架构引入向量量化层,通过单码本将语音表征压缩为12.5Hz低帧率的离散标记序列。该组件源自监督式语音分词器,由ASR模型驱动优化。

连续声学特征:从预训练Whisper模型提取50Hz帧率的连续特征,通过适配器降采样至12.5Hz后与离散标记嵌入相加,作为音频LLM的联合输入。

技术优势:离散标记提供高效语义表征、连续特征保留细粒度声学信息、12.5Hz统一帧率实现模态对齐

音频大语言模型

该模型能产生多模态输出,包括音频的离散语义标记和对应文本标记,以增强生成能力。为实现音频语义标记与文本响应的同步生成,我们改造了标准LLM架构,将其划分为共享功能模块与专用功能模块:原始Transformer底层(即最初若干层)的大部分被用作共享层,这些层通过处理输入序列学习跨模态表征,整合输入或上下文中文本与音频模态的信息。基于共享层,架构分叉为两个并行的Transformer层头部——文本头部专门自回归预测文本标记以形成文本输出,音频头部则预测离散音频语义标记,这些预测的音频标记随后传入音频解标记器模块合成最终波形输出。

为充分利用预训练文本LLM的强大语言能力,共享Transformer层和文本头部的参数直接初始化为预训练文本LLM的权重,音频头部层则随机初始化。该策略确保模型在习得高效音频处理与生成能力的同时,始终保持卓越的文本理解与生成性能。

音频解码器

音频解码器的目标是根据离散语义音频标记生成高质量、富有表现力的语音。我们采用与MoonCast相同的解标记器架构,该架构包含两部分:

  • 1)流匹配模块,将12.5Hz的语义标记转换为50Hz梅尔频谱图
  • 2)声码器,将梅尔频谱图转换为波形。

为降低语音生成延迟,我们设计了一种分块流式解标记器。初步实验表明,若简单将语义标记分块独立解码,会在块边界出现断续问题。因此,我们提出了一种带前瞻机制的分块自回归流式框架。

分块自回归流式框架
将音频分割为块(如每块1秒):{c₁, c₂, …, cᵢ, …, c_N},其中N为总块数。首先,为匹配语义标记(12.5Hz)与梅尔频谱图(50Hz)的序列长度,将语义标记上采样4倍。其次,在训练和推理时应用分块因果掩码——对于当前块cᵢ,所有先前块cⱼ(j<i)均作为提示。设cᵢ的梅尔频谱图为mᵢ,对应离散语义音频标记为aᵢᵈ。流匹配模型的前向步骤会将mᵢ与高斯噪声混合,反向步骤则在条件aᵢᵈ和历史提示cⱼ(含mⱼ与aⱼᵈ)下去噪生成纯净的mᵢ。推理时,当LLM生成一个音频块后,流匹配模型会立即将其解标记为梅尔频谱图,最终通过BigVGAN码器逐块生成波形。

前瞻机制
实验发现,因果注意力机制因无法感知块边界未来上下文,导致生成音频在边界处仍存在断续。为此,我们提出无需训练的前瞻机制:对于当前块cᵢ,从下一块cᵢ₊₁提取n个(如4个)未来语义标记拼接至cᵢ末端,形成扩展块ĉᵢ。解标记ĉᵢ生成梅尔频谱图后,仅保留原始cᵢ对应的部分。该机制仅会使首块生成延迟n个标记的时间,但显著改善边界连续性。

Data

预训练数据

我们的预训练语料库包含单模态(纯文本、纯音频)和多模态(文本-音频)数据。纯音频预训练数据覆盖了广泛的现实场景,包括有声书、播客和访谈等,约包含1300万小时的原始音频,涵盖丰富的声学事件、音乐、环境音、人声以及多语言信息。

大多数音频语料仅包含原始音频,缺乏对应的转录文本、语言类型、说话人标注和分段边界。此外,原始音频中常存在背景噪声、混响和说话人重叠等干扰因素。我们开发了高效的自动音频数据处理流程以生成高质量标注,最终形成多模态(音频-文本)数据。相较于以往主要生成无上下文信息的短音频片段的数据流程,我们的流程旨在提供具有连贯长上下文的长音频标注。该流程按步骤包含以下核心组件(如图3所示):

语音增强
为抑制背景噪声和混响,我们基于Band-Split RNN(BSRNN)架构开发了语音增强模型(图3A)。该模型可进行48kHz语音增强。实验发现语音增强会消除环境音和音乐,可能损害音频理解能力,因此在预训练阶段我们以1:1比例随机选择原始或增强后的音频。

基于聚类分割的分段
我们采用说话人聚类分割方法处理长音频,使用PyAnnote工具包¹进行说话人聚类(图3B),该工具会对音频分段并标注说话人标签。但原始输出效果欠佳,因此我们开发了后处理流程来优化:

  • 说话人聚类合并:PyAnnote可能将同一说话人标注为多个聚类,导致碎片化。我们计算每个初始聚类的代表性说话人嵌入向量,合并余弦相似度超过0.6的聚类对(图3C)。
  • 基于分块的重分配初始分割可能产生包含多说话人的片段。为提纯:1)先将所有片段切分为1.5秒分块;2)对相邻分块,若余弦相似度低于0.5则视为不同说话人,并将其重分配到相似度最高的说话人聚类(图3D)。
  • 片段合并:初始分割可能导致片段长度差异过大(短于1秒或长于100秒)。我们迭代合并标注为同一说话人的相邻片段(重分配后),合并终止条件为:累计长度超过27秒或片段间静音间隔大于2秒(图3E)。
    经此优化后的分割结果比基线输出具有更准确的说话人轮换和更一致的片段长度。

语音转写
为获取各语音片段的语言类型和文本转录,我们首先使用Whisper-large-v3模型检测语言类型。本研究仅保留英语和汉语片段进行转写:英语片段直接使用Whisper-large-v3生成带标点的文本;汉语片段采用FunASR工具包³的Paraformer-Zh模型生成带字级时间戳的文本。由于Paraformer-Zh无法输出标点,我们按以下策略添加:若相邻字符间隔大于0.5秒但小于1.0秒,插入”逗号”;若超过1.0秒,则插入”句号”。

实施细节
该数据处理流程部署在30个云实例组成的集群上,每个实例配备128个虚拟CPU(vCore)、1TB内存和8块NVIDIA L20 GPU,采用支持AMX等向量化加速指令的英特尔至强铂金8575C处理器。整个集群总计提供3,840个vCore、30TB内存和240块NVIDIA L20 GPU。经深度优化后,该流程每日可处理约20万小时原始音频数据。

监督微调(SFT)数据

在预训练阶段之后,我们通过监督微调(SFT)进一步提升 Kimi-Audio 在指令跟随和音频处理任务上的性能。SFT 数据主要分为三类:音频理解语音对话 和 音频转文本对话

音频理解

我们主要采用开源数据集进行音频理解训练,涵盖 6 种任务

  • 自动语音识别(ASR)
  • 音频问答(AQA)
  • 自动音频描述(AAC)
  • 语音情感识别(SER)
  • 声音事件分类(SEC)
  • 音频场景分类(ASC)

具体数据集及 SFT 阶段的训练轮次详见表 1。

除开源数据外,我们还使用了:

  • 55,000 小时 内部 ASR 数据
  • 5,200 小时 内部音频数据(覆盖 AAC/AQA 任务)

语音对话

为了激活 Kimi-Audio 模型在不同对话场景下生成多样化风格、高表现力语音的能力,我们构建了大规模的语音对话数据,这些数据由一系列用户查询助手响应组成的多轮对话构成。

用户查询生成

  • 我们指导 大语言模型(LLM) 编写用户查询文本,然后使用 Kimi-TTS 系统将其转换为语音。
  • 提示语音(prompt speech)从包含 超过 125,000 种音色 的大规模音色库中随机选择。

助手响应生成

  • 我们选择一位配音演员作为 Kimi-Audio 的固定音色,并以该音色合成具有合适风格和情感的助手响应。
  • 以下介绍 Kimi-Audio 配音演员的数据录制过程,以及用于合成多样化风格和表现力响应的 Kimi-TTS 和 Kimi-VC 系统。

Kimi-Audio 配音演员的数据录制

为了实现生成语音的多样化风格和高表现力,我们选择了一位配音演员作为 Kimi-Audio 的固定音色,并在专业录音棚中精心录制了该音色的数据集。

录制设计

  • 20+ 种风格和情感(如开心、悲伤、愤怒、严肃等),每种情感进一步分为 5 个强度等级,以体现不同的情感表达程度。
  • 对于每种风格和情感等级,我们录制了参考音频,以确保不同文本句子之间的情感和风格一致性。
  • 整个录制过程由专业录音导演指导,确保高质量数据。

Kimi-TTS(零样本语音合成系统)

我们开发了一个零样本文本转语音(TTS)系统,称为 Kimi-TTS,仅需 3 秒的提示语音即可生成语音,并保持提示语音的音色、情感和风格

应用场景

  1. 用户查询语音合成:使用大规模音色库(125K+ 音色)为不同用户查询生成多样化音色的语音。
  2. 助手响应语音合成:使用 Kimi-Audio 配音演员录制的风格和情感数据,合成助手的响应语音。

技术架构

  • 类似 MoonCast 的架构,采用 LLM 根据提示语音和输入文本生成语音 token。
  • 使用基于流匹配(flow-matching)的语音解 token 器生成高质量语音波形。

训练数据与优化

  • 在 100 万小时(由自动数据流水线生)的数据上训练。
  • 采用强化学习(RL)进一步提升生成语音的鲁棒性和质量

Kimi-VC(语音转换系统)

由于配音演员难以覆盖所有风格、情感和口音,我们开发了一个语音转换(VC)系统,称为 Kimi-VC,用于将不同说话人/音色的语音转换为 Kimi-Audio 固定音色,同时保留原始语音的风格、情感和口音

技术架构

  • 基于 Seed-VC  框架。
  • 在训练阶段引入音色扰动(timbre-shifting),以缓解信息泄露,并确保训练和推理阶段的对齐。

优化与数据

  • 使用 Kimi-Audio 配音演员录制的语音数据进行微调,确保高质量的语音转换。

音频到文本对话

为了让 Kimi-Audio 具备基础的对话能力,我们从文本领域收集了开源的监督微调(SFT)数据(如表 2 所示),并将用户查询转换为多种音色的语音,从而构建音频到文本对话数据(用户输入为语音,助手响应为文本)。

数据预处理

由于部分文本难以直接转换为语音,我们进行了以下优化:

  1. 过滤不适用内容:剔除包含复杂数学、代码、表格、复杂多语言内容或过长文本的数据。
  2. 口语化改写:将书面化表达调整为更自然的对话风格。
  3. 单轮转多轮优化:将复杂指令的单轮问答数据拆解为更简洁、易理解的多轮对话形式。

模型训练

预训练阶段

Kimi-Audio的预训练目标是从真实世界的音频文本领域学习知识,并在模型的潜在空间中对齐这两个模态,从而支持复杂任务如音频理解、音频到文本对话和语音对话。为此,我们设计了多阶段预训练任务:

  1. 单模态预训练(音频/文本独立学习)
  2. 音频-文本映射学习
  3. 三种跨模态交织任务(进一步 bridging 音频与文本)

数据表示形式

给定原始音频A,数据处理流水线会将其分割为N个片段{S₁, S₂, …, Sₙ},每个片段Sᵢ包含:

  • 音频信号aᵢ
  • 对应文本转录tᵢ

我们对音频片段aᵢ提取两种特征:

  • 连续声学向量 aᵢᶜ
  • 离散语义token aᵢᵈ

为适配模型架构(以离散语义token为主输入/输出,同时输入连续声学token和输出离散文本token),训练序列表示为:

{a₁ᶜ/a₁ᵈ/t₁, a₂ᶜ/a₂ᵈ/t₂, ..., aₙᶜ/aₙᵈ/tₙ}

其中:

  • 通过填充空白token确保音频与文本序列等长
  • 实际训练片段可为以下任意组合:
    • 纯音频:aᵢᵈ 或 aᵢᶜ/aᵢᵈ
    • 纯文本:tᵢ
    • 跨模态对:aᵢᵈ/tᵢ

对于连续+离散音频联合输入(aᵢᶜ/aᵢᵈ):

  1. 将离散语义token通过查表转换为嵌入向量
  2. 与连续声学向量相加得到最终音频特征aᵢ

对于音频-文本联合输入(aᵢᵈ/tᵢ):

  • 将音频语义token和文本token分别嵌入后相加
  • 通过各自独立的输出头生成对应token

具体预训练任务设计见表3,下文将详细介绍。

aᵢᵈ 表示音频片段 *i* 的离散语义标记;
aᵢᶜ 表示音频片段 *i* 的连续声学向量;
aᵢ 表示音频片段 *i* 的 aᵢᵈ 和 aᵢᶜ 的组合;
下划线 表示该部分在训练时会计算损失。

音频/文本单模态预训练
我们首先分别学习文本和音频的知识。对于文本预训练,我们直接使用MoonLight[44]中的文本数据,这些数据质量高且全面,适合训练大语言模型。我们仅对文本标记进行下一标记预测。对于音频预训练,针对每个片段Si,我们对其离散语义标记序列a_d^i进行下一标记预测。

音频-文本映射预训练
直观上,为了在统一空间中对齐音频和文本,学习两种模态之间的映射是有帮助的。因此,我们设计了自动语音识别(ASR)和文本到语音合成(TTS)预训练任务。对于ASR,我们将训练序列构建为{a1, t1, a2, t2, …, aN, tN}。对于TTS,训练序列构建为{t1, a_d^1, t2, a_d^2, …, tN, a_d^N}。我们仅在ASR中计算文本标记的损失,在TTS中计算音频语义标记的损失

音频-文本交错预训练
为了进一步弥合音频和文本模态之间的差距,我们设计了三种音频-文本交错预训练任务:

  • 音频到语义标记交错:将训练序列构建为{a1, a_d^2, a3, a_d^4, …, aN−1, a_d^N},然后仅计算语义音频标记a_d^i的损失,而不计算ai−1的损失。
  • 音频到文本交错:将训练序列构建为{a1, t2, a3, t4, …, aN−1, tN},仅计算文本标记ti的损失。
  • 音频到语义标记+文本交错:将训练序列构建为{a1, a_d^2/t2, a3, a_d^4/t4, …, aN−1, a_d^N/tN}。对于a_d^i/ti,由于语义音频标记序列总是比文本标记序列长,语义标记的预测类似于流式文本到语音任务。实验发现,前几个语义标记的预测较难,因为模型需要同时预测下一个文本标记及其语义音频标记。我们通过在语义音频标记前添加6个特殊空白标记(根据初步实验在生成质量和延迟之间权衡确定)来延迟前几个语义音频标记的预测,从而解决这一问题。

 预训练方案

我们基于预训练的 Qwen2.5 7B 模型初始化 Kimi-Audio 的音频大语言模型,并通过添加语义音频标记和特殊标记扩展其词表。我们按照 1 : 7 : 1 : 1 : 1 : 1 : 2 的任务权重(如表3所示)对上述预训练任务进行训练。Kimi-Audio 的预训练数据包含 5850亿音频标记 和 5850亿文本标记,训练 1个周期

优化器采用 AdamW,学习率按余弦衰减从 2e⁻⁵ 降至 2e⁻⁶,并使用 1% 的token进行学习率预热。

音频分词器的连续声学特征提取模块:该模块基于 Whisper large-v3初始化,能够捕捉输入音频信号中的细粒度声学特征。在预训练的初始阶段(约 20% 的token训练完成前),该 Whisper 特征提取器的参数保持冻结。随后解冻,使其参数能够与模型其余部分联合微调,从而更好地适应训练数据的细节和目标任务的需求。

监督微调

任务设计:在通过海量真实音频与文本数据完成预训练后,我们对 Kimi-Audio 进行监督微调,使其具备指令跟随能力。具体设计如下:

  1. 任务通用性:下游任务多样,因此不设置特殊任务切换操作,而是采用自然语言指令描述每个任务;
  2. 多模态指令为每条指令同时构建音频版(由 Kimi-TTS 根据文本零样本生成)和文本版,训练时随机选择一种形式;
  3. 指令增强:通过大语言模型生成 200条ASR任务指令30条其他任务指令,每个训练样本随机选取一条以增强鲁棒性。监督微调数据规模约 30万小时

微调方案:对每个数据源进行 2-4个周期 的微调。优化器采用 AdamW,学习率按余弦衰减从 1e⁻⁵ 降至 1e⁻⁶,并使用 10% 的标记进行预热。

音频解码器训练分为三个阶段:

  1. 预训练阶段:使用约 100万小时 预训练音频数据,联合训练流匹配模型和声码器,学习多样化的音色、韵律和音质特征;
  2. 分块微调:在同一数据集上采用动态分块策略(块长0.5秒至3秒)进行优化;
  3. 高质量精调:最终基于 Kimi-Audio 发言人 的高质量单人录音数据进行微调,进一步提升生成效果。

推理与部署

Kimi-Audio 设计用于处理多种音频相关任务,包括语音识别、音频理解、音频-文本对话及语音-语音对话。由于实时语音对话在基础设施和工程实现上复杂度最高,本节以其为例阐述 Kimi-Audio 的部署实践。我们首先说明客户端(如 Kimi APP 或网页浏览器)与服务器(Kimi-Audio 服务)间的实时语音对话流程,随后介绍产品化部署方案。

实时语音对话流程

图4展示了用户客户端(如 Kimi APP)与服务器(Kimi-Audio 服务)之间的语音-语音对话流程。每轮对话按以下步骤执行:

  1. 用户语音输入:用户通过客户端(如 Kimi APP 或浏览器)说话,音频数据被采集并实时流式传输至服务器;
  2. 端点检测:服务器端的语音活动检测(VAD)模块判断用户是否结束说话;
  3. 触发推理:当用户停止说话时,服务器发送提交信号并启动 Kimi-Audio 模型的推理流程;
  4. 实时流式播放:推理过程中,客户端实时接收生成的音频片段并立即播放给用户。
  5. 客户端(手机或网页浏览器)将接收到的音频片段实时播放给用户。

服务端的 Kimi-Audio 在每轮对话中的推理流程如下:

  1. 音频编码:通过音频分词器将输入音频转换为离散语义标记和连续声学向量;
  2. 输入构建:将系统提示标记、音频标记和对话历史标记拼接为 Audio LLM 的输入序列;
  3. 模型推理:Audio LLM 接收标记序列并生成输出标记;
  4. 音频合成:通过反分词器将输出标记还原为音频波形。

生产环境部署
如图5所示,在生产环境中,所有核心组件(音频分词器、音频大语言模型和音频反分词器)均属于计算密集型模块,需要可扩展且高效的基础架构支撑。为此我们设计了如下生产级部署架构:

Kimi-Audio实时通信服务
该服务作为客户端交互接口,负责接收用户音频数据并转发至推理调度器,同时将生成的音频分块返回客户端。我们采用WebRTC协议确保稳定低延时的通信连接。

推理调度器
推理调度器通过在后端存储中以token形式维护对话历史来管理会话流程。每轮交互执行以下步骤:
• 调用分词器服务将用户音频转换为token
• 将新token与对话历史拼接构建模型输入
• 将输入发送至大语言模型服务生成响应token
• 调用反分词器服务将响应token转换为音频输出

此外,该系统会将所有输出token作为持续更新的对话历史存储,确保多轮对话的连贯性。

实验

首先开发了面向音频理解、生成及对话任务的开源评估工具包。【https://github.com/MoonshotAI/Kimi-Audio-Evalkit.】该工具目前集成支持Kimi-Audio及系列前沿音频大模型,并可扩展评估其他音频基础模型,主要特性包括:

• 标准化评估框架
基于Qwen-2-Audio实现标准化词错误率计算,并集成GPT-4o-mini作为智能评判器,克服指标不一致和简单字符串匹配的局限,实现公平对比。

• 统一比较平台
提供支持多模型多版本的统一平台,简化横向对比。通过定义和共享标准化推理参数与提示策略(”配方”),直接解决评估设置不一致问题,显著提升不同研究成果间的可复现性。

挑战与未来趋势

尽管Kimi-Audio在构建通用音频基础模型方面取得显著进展,但要实现更强大、更智能的音频处理系统仍存在诸多挑战。我们梳理现存问题并指出以下极具潜力的发展方向:

从语音转写到音频描述

当前音频基础模型的预训练范式通常依赖音频-文本对齐训练,其中文本数据多通过ASR(自动语音识别)从语音转写获得。但转写文本仅聚焦口语内容(”说了什么”),忽略了音频中的副语言信息(如情感、风格、音色、语调)、声学场景和非语言声音等重要特征。未来需引入描述性文本(如音频字幕)来构建更丰富的上下文表征。通过同时融合转写文本与描述文本,模型不仅能更好地理解与生成口语内容,还能处理复杂的声学环境,为构建更细腻的多模态音频处理系统和更通用的音频智能奠定基础。

更优的音频表征

现有音频表征主要采用语义token或声学token:

  • 语义token:通常通过ASR辅助损失函数获取,侧重转写导向的信息,但难以捕捉对理解与生成至关重要的声学细节
  • 声学token:通过音频重构损失函数学习,侧重描述导向的声学特征,但缺乏连接文本智能所需的抽象语义信息

关键研究方向是开发能同时整合转写导向语义与描述导向声学特征的新型表征,在保留高层抽象信息的同时,涵盖说话人身份、情感、环境音等细微特征,这对实现更复杂的音频理解与生成至关重要。

摒弃ASR/TTS的建模依赖

现有音频基础模型在预训练和微调阶段严重依赖ASR/TTS生成训练数据,其质量受限于:

  • ASR的文本识别准确率
  • TTS合成语音的表现力/多样性/质量

这种模式下,音频模型本质上只是现有ASR/TTS系统的精馏版本性能天花板受制于ASR/TTS系统的上限,无法实现真正的自主音频智能。未来应探索不依赖ASR/TTS伪音频数据、直接基于原生音频数据的训练范式,这将大幅提升模型性能上限。