尧图网页设计 
MiniMind-O序列格式设计文本与8路音频码流如何在同一条序列中建模【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-oMiniMind-O 是一个从 0 训练的约 0.1B 参数开源端到端 Omni 模型能听、能说、能看。这篇文章拆解它最核心的一块设计——序列格式文本 token 流与 8 路 Mimi 音频码流如何布局在同一条序列里联合建模以及这种布局如何同时支撑语音理解、流式语音输出与实时打断。从级联到统一序列为什么不串 ASR TTS ️把语音纳入语言模型有两条路一条是把 ASR → LLM → TTS 串成级联链路语音先转文字再处理另一条是让语音与文本在隐状态层面直接连通。级联链路工程上直接但多出的文本转写会带来延迟语气和情绪信息也会打折扣。MiniMind-O 选择后者不经过文字中转站而是把音频用 Mimi 编解码器压成离散码流8 个 codebook、帧率 12.5 Hz、24 kHz 重建再把这些码和文本 token 一起放进同一个 Transformer 序列中建模。核心布局1路文本 8路音频码的9路张量 整个序列格式的核心是一个形状为9 × T的输入张量前 8 行是 Talker 的音频码流L0–L7对应 Mimi 的 8 个 codebook第 9 行是 Thinker 的文本流。训练时两者对齐到同一时间轴推理时两条流也共享同一个 KV Cache 前缀。图中 (a) 是默认音色(b) 是音色克隆。底部还展示了 5 种多模态变体——Text、Audio、TextAudio、TextImage、AudioImage——它们全部复用同一套 9 路布局只是各区域填的内容不同这让一套权重天然覆盖多种交互形态。各区域的角色分工如下Thinker 文本流|im_start| ... |im_end|标准的对话结构语音输入以|audio_pad|占位符序列注入真实语音特征由冻结的 SenseVoice 编码后经 MLP projector 填进占位符图像则是 64 个|image_pad|占位符Talker 音频流PAD → SPK → REF → 目标 CODE → STOP。SPK 位置承载说话人 embeddingREF 是参考音色的码流右对齐贴到回复起点之前目标码从回复起点之后开始一个巧妙细节音色克隆时参考码REF在序列里右对齐到回复开始位置之前并且训练时 50% 概率直接丢弃 REF 只保留 SPK——这让模型既学会听声克隆又不会过度依赖参考片段。Thinker–Talker 之间的 Bridge语义条件如何变成语音文本与音频不是简单的各算各的。Thinker 的中间层隐状态bridge_layer 层数/2 - 1被取出来作为 Talker 的语义条件embedding 层语义不足最后一层又太贴近下一个词预测目标中间层恰好融合了上下文却未被 LM head 过度塑形。Talker 的输入是两项加权和语义条件(Thinker中间层) × 3.0 音频码嵌入 × 1.0输出端同样共享 轻量适配Talker 用 MTPMulti-Token Prediction一次预测 8 层码输出头是一个共享主体 8 个低秩 adapter音频嵌入侧也是共享 embedding 8 个 adapter。这样既保留各 codebook 的分布差异又不为每层复制整套参数把 0.1B 的预算花在刀刃上。损失掩码设计只有回复区域参与训练 统一序列里有一个必须回答的问题哪些位置算预测目标规则非常干净文本标签只在最后一个 assistant 回复区间内计算prompt 与 reference 区域全部置-100忽略——它们只提供条件不作为重构目标音频标签8 层码各自错位 1 步起始第 i 层从回复起点后第 i1 步开始这就是 MTP 的延迟调度——每层码比上一层晚一步形成时间上的阶梯stop token 加权 10 倍音频码流末尾的|audio_stop|是流式生成能否准时收口的关键训练中把它损失权重放大到 10 倍保证 8 层都能可靠地喊停5% 调度采样小概率把部分历史真实码替换成随机码让模型学会从自己的错误历史中恢复增强长句稳定性文本与音频损失等权相加训练日志会分别汇报text与audio两条曲线便于观察语音链路是否跟上了语言链路。从序列到波形流式解码与实时打断 ⚡推理时解码循环非常精炼Thinker 每产出一个文本 token音频侧按延迟 1 步的节奏让 L0 起步随后 L1、L2……依次接力当某个 step 上 8 层都已有对应码时就取[codes[i][step-7i]]拼成一帧喂给 Mimi 解码器增量恢复 24 kHz 波形——固定 7 帧的错峰正好被对齐换来的是边说边播语音不必等回答结束。这条流式序列格式直接支撑了实时交互用户停话后 Thinker 先完成语义 prefillTalker 随即逐步吐出音频码Mimi 边收码边出波形用户中途再次开口触发 barge-in 时系统中断当前生成、重新进入 prefill–reply 循环。动手读源码关键代码位置 想验证本文的每个结论代码都只有几百行重点看这几处9 路张量拼装input_ids (9, T-1)与 REF/SPK 右对齐dataset/omni_dataset.pyforward 中拆分文本流/音频流与 Talker 融合model/model_omni.py共享主体 8 adapter 的输出头与嵌入model/model_omni.py流式生成延迟调度与帧对齐step-7imodel/model_omni.py8 层音频损失与 stop 加权trainer/train_sft_omni.py小结MiniMind-O 的序列格式可以概括为一句话把说什么文本流与怎么发出声音8 路码流压进同一张时间轴上用中间层 Bridge 传递语义、用延迟调度错峰 8 层码、用掩码划分条件与目标区域。这套设计让 0.1B 的小模型同时拥有了多模态理解、流式语音合成与近似双工交互也正因为全部代码和权重开源你可以亲手复现并改造这条完整链路。【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-o创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MiniMind-O序列格式设计：文本与8路音频码流如何在同一条序列中建模
MiniMind-O序列格式设计文本与8路音频码流如何在同一条序列中建模【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-oMiniMind-O 是一个从 0 训练的约 0.1B 参数开源端到端 Omni 模型能听、能说、能看。这篇文章拆解它最核心的一块设计——序列格式文本 token 流与 8 路 Mimi 音频码流如何布局在同一条序列里联合建模以及这种布局如何同时支撑语音理解、流式语音输出与实时打断。从级联到统一序列为什么不串 ASR TTS ️把语音纳入语言模型有两条路一条是把 ASR → LLM → TTS 串成级联链路语音先转文字再处理另一条是让语音与文本在隐状态层面直接连通。级联链路工程上直接但多出的文本转写会带来延迟语气和情绪信息也会打折扣。MiniMind-O 选择后者不经过文字中转站而是把音频用 Mimi 编解码器压成离散码流8 个 codebook、帧率 12.5 Hz、24 kHz 重建再把这些码和文本 token 一起放进同一个 Transformer 序列中建模。核心布局1路文本 8路音频码的9路张量 整个序列格式的核心是一个形状为9 × T的输入张量前 8 行是 Talker 的音频码流L0–L7对应 Mimi 的 8 个 codebook第 9 行是 Thinker 的文本流。训练时两者对齐到同一时间轴推理时两条流也共享同一个 KV Cache 前缀。图中 (a) 是默认音色(b) 是音色克隆。底部还展示了 5 种多模态变体——Text、Audio、TextAudio、TextImage、AudioImage——它们全部复用同一套 9 路布局只是各区域填的内容不同这让一套权重天然覆盖多种交互形态。各区域的角色分工如下Thinker 文本流|im_start| ... |im_end|标准的对话结构语音输入以|audio_pad|占位符序列注入真实语音特征由冻结的 SenseVoice 编码后经 MLP projector 填进占位符图像则是 64 个|image_pad|占位符Talker 音频流PAD → SPK → REF → 目标 CODE → STOP。SPK 位置承载说话人 embeddingREF 是参考音色的码流右对齐贴到回复起点之前目标码从回复起点之后开始一个巧妙细节音色克隆时参考码REF在序列里右对齐到回复开始位置之前并且训练时 50% 概率直接丢弃 REF 只保留 SPK——这让模型既学会听声克隆又不会过度依赖参考片段。Thinker–Talker 之间的 Bridge语义条件如何变成语音文本与音频不是简单的各算各的。Thinker 的中间层隐状态bridge_layer 层数/2 - 1被取出来作为 Talker 的语义条件embedding 层语义不足最后一层又太贴近下一个词预测目标中间层恰好融合了上下文却未被 LM head 过度塑形。Talker 的输入是两项加权和语义条件(Thinker中间层) × 3.0 音频码嵌入 × 1.0输出端同样共享 轻量适配Talker 用 MTPMulti-Token Prediction一次预测 8 层码输出头是一个共享主体 8 个低秩 adapter音频嵌入侧也是共享 embedding 8 个 adapter。这样既保留各 codebook 的分布差异又不为每层复制整套参数把 0.1B 的预算花在刀刃上。损失掩码设计只有回复区域参与训练 统一序列里有一个必须回答的问题哪些位置算预测目标规则非常干净文本标签只在最后一个 assistant 回复区间内计算prompt 与 reference 区域全部置-100忽略——它们只提供条件不作为重构目标音频标签8 层码各自错位 1 步起始第 i 层从回复起点后第 i1 步开始这就是 MTP 的延迟调度——每层码比上一层晚一步形成时间上的阶梯stop token 加权 10 倍音频码流末尾的|audio_stop|是流式生成能否准时收口的关键训练中把它损失权重放大到 10 倍保证 8 层都能可靠地喊停5% 调度采样小概率把部分历史真实码替换成随机码让模型学会从自己的错误历史中恢复增强长句稳定性文本与音频损失等权相加训练日志会分别汇报text与audio两条曲线便于观察语音链路是否跟上了语言链路。从序列到波形流式解码与实时打断 ⚡推理时解码循环非常精炼Thinker 每产出一个文本 token音频侧按延迟 1 步的节奏让 L0 起步随后 L1、L2……依次接力当某个 step 上 8 层都已有对应码时就取[codes[i][step-7i]]拼成一帧喂给 Mimi 解码器增量恢复 24 kHz 波形——固定 7 帧的错峰正好被对齐换来的是边说边播语音不必等回答结束。这条流式序列格式直接支撑了实时交互用户停话后 Thinker 先完成语义 prefillTalker 随即逐步吐出音频码Mimi 边收码边出波形用户中途再次开口触发 barge-in 时系统中断当前生成、重新进入 prefill–reply 循环。动手读源码关键代码位置 想验证本文的每个结论代码都只有几百行重点看这几处9 路张量拼装input_ids (9, T-1)与 REF/SPK 右对齐dataset/omni_dataset.pyforward 中拆分文本流/音频流与 Talker 融合model/model_omni.py共享主体 8 adapter 的输出头与嵌入model/model_omni.py流式生成延迟调度与帧对齐step-7imodel/model_omni.py8 层音频损失与 stop 加权trainer/train_sft_omni.py小结MiniMind-O 的序列格式可以概括为一句话把说什么文本流与怎么发出声音8 路码流压进同一张时间轴上用中间层 Bridge 传递语义、用延迟调度错峰 8 层码、用掩码划分条件与目标区域。这套设计让 0.1B 的小模型同时拥有了多模态理解、流式语音合成与近似双工交互也正因为全部代码和权重开源你可以亲手复现并改造这条完整链路。【免费下载链接】minimind-o️ A 0.1B Omni model trained from scratch, capable of listening, speaking, and seeing!项目地址: https://gitcode.com/gh_mirrors/mi/minimind-o创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考