FlexiSLM：支持 4-12.5Hz 可变、动态帧率的端到端语音大模型

论文链接：https://arxiv.org/abs/2606.31247
项目主页：https://flexislm.github.io
开源代码：https://github.com/AmphionTeam/FlexiSLM
开源数据集：https://huggingface.co/datasets/FlexiSLM/FlexiSLM-Data-4M-s2s
文章来源：Amphion

现存问题

从 Qwen-Omni 到 Kimi-Audio，端到端语音大模型正在快速走向更自然、更低延迟的交互。但在这些模型背后，有一个长期被忽视的效率问题：

不管一句话的信息量高低，现有 Speech LLM 通常都以固定帧率处理和生成语音。

沉默、拖音、重复发音需要固定数量的语音 Token；信息密集的关键词也使用同样的表示粒度。就像一辆汽车只有一个挡位——无论是在高速公路上行驶，还是堵在市中心，都只能以相同方式消耗算力。

例如，Qwen2.5-Omni 的语音输入、输出表示分别达到 25 Hz 和 50 Hz，Kimi-Audio、Qwen3-Omni 等模型也采用固定帧率。帧率代表模型每秒需要处理的语音帧数：帧率越高，Token 序列通常越长，计算与生成开销也越大。

更关键的是，固定帧率还意味着模型部署后几乎无法根据设备性能、网络状况或业务预算，动态调整语音质量与生成速度。

为了解决这一问题，我们提出 FlexiSLM（Flexible Spoken Language Model），首个同时支持语音输入端和输出端动态帧率与可控帧率的语音大模型：

在信息密集的位置保留更多语音帧；
在停顿和冗余片段自动合并帧；
推理时直接指定目标帧率；
同一个模型可在 4.0～12.5 Hz 间运行，无需重新训练。

在高帧率设置下，FlexiSLM 超越了多款固定帧率 7B 语音模型；当输出帧率从降至 6.25 Hz 时，推理时间接近减半，同时仍保持较强的 Speech-to-Speech 能力。

FlexiSLM：支持 4-12.5Hz 可变、动态帧率的端到端语音大模型 — 主流语音大模型帧率与动态控制能力对比

核心痛点：为什么固定帧率并非最高效的表示？

当前的端到端语音大模型，通常需要把连续音频转换成语音特征或离散 Token，再交给 LLM 进行理解和生成。

为了方便建模，绝大多数系统采用固定时间间隔切分语音。例如：

25 Hz：每秒产生 25 个语音帧；
12.5 Hz：每秒产生 12.5 个语音帧；

这种设计简单，但忽略了语音信息密度并不均匀。

一句话中的关键词、数字和专有名词，可能需要精细表示；但停顿、拖音以及相邻高度相似的声音片段，往往存在大量冗余。固定帧率依然为这些片段分配等量的 Token，造成的问题包括：

推理成本被无效 Token 拉高：Speech LLM 的 Thinker 和 Talker 通常需要围绕语音序列反复进行自回归计算。输出 Token 越多，模型前向计算次数越多，响应时间也越长。
质量与速度只能“一次性选定”：固定帧率模型在完成训练后，帧率被锁死。服务器和移动端设备只能运行同一种配置，难以根据情况调整。

FlexiSLM 的输出语音token采用本团队在ICLR2026会议发表的动态帧率语音编解码器FlexiCodec，核心洞察是：

Speech LLM 不应该用固定数量的 Token 表示每一秒语音，而应该根据信息密度动态分配 Token。

而在语音输入端，FlexiSLM采用重新初始化的frame merging模块来产生动态、可变帧率连续表征。

FlexiSLM架构：为Thinker-Talker架构引入动态帧率表示

FlexiSLM 延续了 Thinker–Talker 的端到端 Speech LLM 架构，但在语音输入和输出两端同时引入了动态帧率表示。

整个系统可以理解为四个核心部分：

Audio Encoder：把用户语音编码成连续特征；
Frame Merging Module：动态压缩输入语音帧；
Thinker LLM：完成语义理解和文本响应生成；
Talker + Audio Decoder：生成动态帧率语音 Token，并重建最终波形。

其 Audio Encoder 初始化自 Qwen2.5-Omni，输出 25 Hz 连续语音特征；Thinker 则以 Qwen2.5-7B-Instruct 为基础。输入端的 Frame Merging Module 将特征动态压缩至不高于 12.5 Hz，输出端则复用预训练 FlexiCodec 的动态语音表示与 Flow-Matching 解码器。

架构设计一：动态帧合并语音特征

FlexiSLM复用预训练的FlexiCodec token，同时将这一机制扩展到SLM的音频输入上。其机制是计算相邻语义特征之间的余弦相似度进行压缩：

当两帧高度相似时，说明其承载的信息可能重复，系统将它们合并并取平均；
当两帧差异明显时，则分别保留；
多个连续的高相似度帧，可以被压缩成一个动态语音帧；
合并后的 Token 会携带一个 Frame Length，记录它对应多少个原始帧。

因此，模型可以用较少 Token 表示停顿和稳定发音，同时为变化剧烈、信息丰富的片段保留更高时间分辨率。动态帧率带来的另一个好处是能够实现可控帧率生成，模型能在训练时见过各种帧率的语音表示，在条件控制下能够生成对应帧率的token，在后文会有更详细的解释。

架构设计二：Talker 同时预测“说什么”和“说多久”

传统语音生成模型通常只预测语音 Token。FlexiSLM 的 Talker 则同时输出两条并行序列：

FlexiCodec FSQ Token：描述当前语音帧的内容；
Frame Length Token：描述该语音帧持续多少个基础时间单位。

这相当于让模型不仅决定“发出什么声音”，还要决定“这个声音持续多久”。语音 Token 的长度信息是语音信号精准重建的关键。

Talker 的输入同时包含 Thinker 隐藏状态、目标帧率条件，以及此前生成的语音 Token 和长度信息。最终，动态语音 Token 由冻结的非自回归 Flow-Matching 解码器重建为 24 kHz 语音。

可控帧率机制创新：支持直接输入目标帧率

FlexiCodec等动态 Codec 通常通过调整合并相似度阈值控制压缩程度：

阈值高，合并较少，帧率较高；
阈值低，合并更多，帧率较低。

于是，我们可以通过把“阈值”设置为SLM的输入条件，进而控制SLM输出的token的帧率。但这种控制十分间接：同一个阈值作用在不同语音上，最终可能产生完全不同的平均帧率，这是一个一对多的映射，也难以预测实际延迟和计算预算。

FlexiSLM 直接让用户指定目标值，例如设置：
“帧率 ≈ 6.25 Hz”

模型会把目标帧率编码成连续的正弦位置表示，作为条件输入 Talker。训练时，系统随机采样不同压缩阈值，并将实际得到的帧率作为监督条件，从而学习“目标帧率—语音生成方式”之间的映射。

最终，一个 FlexiSLM 模型就能覆盖多个帧率工作点，而不用针对 12.5 Hz、6.25 Hz、4 Hz 分别训练不同版本。

03 数据与训练方案

FlexiSLM 采用三阶段流程。其中第一阶段使用开源的TTS数据进行Talker模块预训练，第二、三阶段的训练数据覆盖Speech-to-Speech 问答、TTS、ASR、音频理解。第二与第三阶段的差异在于，第二阶段对 Thinker 使用 LoRA（Talker等其他模块不使用LoRA），而第三阶段使用全参数微调，并开启 Talker-to-Thinker Connection，把已经生成的语音 Token 信息反馈给 Thinker，使 Thinker 能够明确感知“自己刚才已经说了什么”。

对于Speech-to-Speech 问答，论文专门构建了包含约 140 万条 Speech-to-Speech 样本的 FlexiSLM-Data，回答由 Qwen3-Omni 蒸馏生成。我们开源的Speech-to-Speech SLM训练数据采用相同的数据管线复现。

Prompt收集与文本回复生成。 我们从公开的问答、指令遵循和对话数据集中收集user questions。Assistant response由 Qwen3-Omni-30B-A3B 生成。
语音合成。 将所得文本对中 assistant response 部分回复由 Qwen3-TTS 固定音色合成，user questions则由 Fish-Audio 合成，说话人随机采样。所得约 420 万条样本、约 2.6 万小时音频。
质量过滤与压缩。 采用更严格的过滤，并将全部音频转为 MP3。精简版发布包含 243 万条样本、约 1.48 万小时音频，体积约 385 GB；我们发现训练出来的模型质量与采用全量数据版本几乎没有差别。

我们已将每一步处理后的数据开源至HuggingFace。我们认为这可能是目前开源领域最大的语音问答数据集。

04 实验结果

论文在 OpenAudioBench、VoiceBench 和 LibriSpeech 等评测上，对比了 Qwen2.5-Omni、Kimi-Audio、Mimo-Audio 等模型。

结果一：有竞争力的 7B 规模 Speech-to-Speech (S2S) 结果

在 12.5 Hz 输入、12.5 Hz 输出配置下，FlexiSLM-Stage3 获得：

S2T / S2S：72.4 / 67.2

优于基线模型：

Qwen2.5-Omni-7B：66.7 / 63.3
Kimi-Audio-7B：69.7 / 57.2
Mimo-Audio-7B：70.6 / 59.0

保持输入为 12.5 Hz，仅将输出从 12.5 Hz 降至 6.25 Hz：

S2T：72.4 → 72.3
S2S：67.2 → 66.2

输出语音 Token 数量接近减半，但 Speech-to-Speech 综合得分只下降 1 分。即使输入和输出都降到 6.25 Hz，模型仍获得 70.2 / 64.3，S2S 表现依旧超过论文中的所有固定帧率 7B 基线。

结果二：目标帧率控制误差小于 0.1 Hz

传统阈值控制存在明显波动。例如使用固定阈值尝试生成约 8 Hz 语音时，不同样本的实际帧率可能分布在 3.91～10.74 Hz。

FlexiSLM 的直接帧率控制则非常稳定：

请求 6.25 Hz，实际均值约为 6.24～6.25 Hz；
请求 4.0 Hz，实际均值约为 3.99～4.00 Hz；
不同数据集上的误差均低于 0.1 Hz。

这意味着部署方可以更准确地预估 Token 数量、计算成本和服务延迟。

结果三：推理时间近乎减半，最高比 Qwen2.5-Omni 快 2.7 倍

当输出帧率从 12.5 Hz 降至 6.25 Hz时，完整响应 RTF：1.17 → 0.59。与 Qwen2.5-Omni-7B 的 1.57 RTF 相比，FlexiSLM 6.25 Hz 输出配置最高约快 2.7 倍。实验也说明，效率收益主要来自输出端降帧率：因为 Talker 的自回归语音生成是整体计算开销的主要来源。

结果四：支持多种语音理解任务

我们在训练数据中加入LLaSO-Instruct开源语音理解数据，结果显示，在不同输入帧率下，模型在不同语音理解任务，如情感、口音、音频事件、乐器检测中具有良好性能。我们计划未来开源更多语音任务的数据并延伸FlexiSLM模型能力。

05 消融实验

论文进一步验证了三个关键设计: 动态输出帧率提升语音生成质量，动态输入帧率增强语音理解，以及直接帧率控制改善 Talker 生成。其中，将直接帧率条件换成阈值条件后，S2T 和 ASR 变化不大，但 S2S 与 TTS 质量明显下降。这说明模糊的阈值条件会增加 Talker 的学习难度，而明确的目标帧率能提供更稳定的生成目标。