音频输入这件事放到今天的大模型体系里已经远不止“录一段声音”那么简单。我们在多模态项目里经常听到“语音变成 Token”“音频 Token 化”但很多刚入行的同学对“波形到底是怎么变成 Token 的”仍然是一头雾水波形明明是一条连续的、每秒上万个采样点的曲线模型里看到的却是一个个离散符号或者向量这中间到底经历了什么尤其最近“软 Token”这个概念被越来越多地提到它跟传统的硬离散 Token 有什么区别又是怎么从音频波形里得到的我前阵子正好做了一个音频多模态输入的原型从麦克风采集、ADC 采样、分帧、梅尔特征一直到把特征序列送进一个小编码器得到软 Token整条链路亲手走了一遍。这篇文章就把这条链路从头拆到尾重点落在“波形如何变成软 Token”这个核心问题上。如果你在做语音识别、音频理解、多模态大模型或者只是想搞清楚音频预处理和 Token 化的关系这篇文章会给你一个能直接落地的完整认知和可复现代码。1. 先把波形这件事说清楚从声压到数字序列很多做模型的同学一上来就跳进 Transformer 和 Token 的细节反而忽略了最前面的“波形”到底是什么。实际上波形变 Token 的第一步是要把物理世界里的声波变成计算机能处理的数字序列。这一步搞不懂后面再怎么调模型都是空中楼阁。1.1 声波和话筒之间发生了什么声音的本质是空气的疏密变化。说话的时候声带振动带动空气分子形成疏密交替的压力波这个波传到话筒振膜上振膜跟着前后振动。话筒的本质是一个换能器把声压变化转化成电压变化这个电压信号就是模拟的“音频波形”。你在示波器上看到的是一条连续曲线横轴是时间纵轴是电压。这里有两个物理量决定了声音的特征一是振动的快慢也就是频率决定音高二是振动的幅度也就是电压峰值决定响度。一个正弦波 440Hz就是每秒振动 440 次我们听到的是一个标准的 A4 音。但实际语音和音乐远比正弦波复杂是由基频和无数谐波叠加出来的复杂波形这也是为什么波形曲线看起来特别“毛糙”。我自己调试嵌入式设备时最直观的感受是波形在模拟域里的质量问题直接决定了后面数字化之后的信息损失。比如麦克风前置放大器有直流偏置采集到的波形整体抬升了一个电压平台又比如增益拉太高波形顶部被电源电压削平这就是“削波失真”。这类问题在模拟域用示波器一眼就能看到但一旦进了 ADC 变成数字序列就变成“数据看起来很怪但说不清为什么”的玄学问题。1.2 ADC 采样与量化连续变成离散的第一道关模拟波形要进计算机必须经过模数转换ADCADC 做两件事一个是采样一个是量化。采样是按固定时间间隔去“拍照”每秒钟拍的张数就是采样率。音频领域最常见的是 16kHz、44.1kHz、48kHz。根据奈奎斯特采样定理采样率至少要是信号最高频率的两倍才能无失真还原。人耳听觉上限大概是 20kHz所以 CD 音质取 44.1kHz留了足够余量语音任务为了省算力通常只取 16kHz因为语音的有效能量大多集中在 4kHz 以下。量化是把每个采样点的电压值归到有限个等级上。用 16bit 表示就是 65536 个等级用 32bit 浮点表示等级就更多了。量化会带来量化噪声比特数越少噪声越大。这也是为什么嵌入式设备里用 8bit ADC 采集语音听起来“沙沙的”而 16bit 的听感就干净很多。ADC 出来之后波形就变成了一串整数序列这就是 PCM 数据。你可能见过 .wav 文件里的数据段其实就是按固定采样率排列的这些整数。从这一刻起音频在计算机里不再是“波形”而是一个一维数组。数组的长度等于采样率乘以时长比如 16kHz 采 10 秒钟就是 160000 个采样点。这里顺便说一句我看很多搞嵌入式的同学会在调试工具里的波形视图上看 ADC 采集值比如一边给板子灌正弦波一边看采样回来的点是不是正弦形状。这个习惯很好能快速发现接线和量程问题。做音频预处理的时候也建议先用这类可视化手段把原始波形看一眼再做后续加窗、特征提取。很多模型效果差不是模型不行而是波形在源头就已经是坏的。1.3 数字波形和“波形更新率”一个容易被忽视的工程细节做音频项目时很多人会混淆“采样率”和“波形更新率”。采样率是 ADC 每秒钟采多少个点波形更新率是显示界面或者处理管线每秒钟刷新多少个新数据块。你在调试工具里看到波形曲线“一顿一顿”地动不是采集出了问题而是显示缓冲区的刷新率比采样率低。这个认知在做实时音频处理时很重要。比如我用 16kHz 采样每 25ms 推送一次新数据块那每次推送就是 400 个采样点。如果处理流程没赶上这个节奏波形就会越积越多出现延迟和卡顿。我之前踩过一次坑特征提取放在主线程里FFT 算得太慢导致波形更新率跟不上采集速率结果整个 Pipeline 的 Token 生成时间越来越长还以为是模型变慢了。后来才定位到是特征提取阻塞了采集。处理这类问题的原则只有一个采集线程和处理线程分开处理跟不上就丢帧宁可丢也不能阻塞采集。2. 从波形到“帧”语音信号的基本操作单位拿到一长串 PCM 序列之后接下来面临的问题是模型不能把 160000 个点一次性全吞进去也没法直接理解“这个数组代表什么音”。语音信号是短时平稳的也就是说在很短时间内比如 20-30ms音频特征基本稳定但拉长到几百毫秒特征又明显变化。所以处理语音的基本单位不是“采样点”而是“帧”。2.1 为什么不能拿整段信号直接做分析如果对整段 10 秒钟的语音一次性做 FFT得到的是全段时间的频谱平均值也就是把“上午说话”和“下午说话”混在一起取平均完全没有时间分辨率。你说了一个词“早上好”它的声母、韵母、音调变化全都被抹掉了。语音识别和目标说话人区分都依赖时间上的变化信息所以必须切帧。切帧的思路是把波形切成一个个重叠的小段每一段叫一帧。帧长通常取 20-30ms帧移相邻两帧起始点之间的距离取 10ms。16kHz 采样率下25ms 就是 400 个采样点10ms 就是 160 个采样点。相邻帧之间有一半是重叠的这样能避免窗函数边缘把信号衰减掉也让特征序列更平滑。这里要解释一个常见误区帧移越小帧数越多时间分辨率越高但计算量也越大。语音识别系统里 10ms 帧移几乎是默认值因为 10ms 刚好对应音素切换的粒度但做音乐生成或者环境音分类可以放宽到 20ms 甚至 30ms因为音乐的音符持续事件更长不需要那么精细的时间切分。2.2 帧长、帧移与窗函数的取舍切帧不是简单地把数组切成块那样会在帧边界产生频谱泄漏。所谓频谱泄漏是指本来集中在某一个频率上的能量因为边界突变而“漏”到其他频率上导致 FFT 结果出现很多假峰。解决办法是加窗函数让每一帧两端的幅度逐渐衰减到零。常用的窗函数有汉宁窗和海明窗。汉宁窗旁瓣衰减更快频谱更干净海明窗主瓣更窄频率分辨率略高。实际做语音特征时用汉宁窗更多因为它能更好地抑制频谱泄漏。代码里通常用torch.hamming_window或者torch.hann_window一行就能搞定。我个人的习惯是做语音识别用 25ms 窗长、10ms 帧移、汉宁窗做音乐分析用 50ms 窗长、25ms 帧移因为音乐的低频成分更重要需要更长的窗来获得频率分辨率。具体参数没有绝对标准只有一个原则频率分辨率和时间分辨率的平衡。窗越长频率分辨率越高但时间分辨率越低窗越短则相反。做嵌入式音频的同学可能更熟悉 PWM 波形和响度控制不太接触窗函数。但本质是共通的PWM 波形看的是占空比和频率窗函数看的是幅度包络和频谱。你调一个打印机的走纸电机用 PWM 控制转速把 PWM 波形拿到逻辑分析仪上看占空比这个动作和音频里加窗看能量包络思维模型都是一样的从时域波形里提取出有意义的控制特征。3. 时域不够用就换到频域STFT 与梅尔特征怎么把波形变薄分帧之后每一帧还是一个长度几百的向量直接作为特征仍然有两个问题一是维度太高一帧 400 个点10 秒语音就是 1000 帧400000 个数值模型根本吃不消二是时域波形本身对声音内容的表达能力很差同样一个音高不同人说出来波形完全不同但频谱结构却高度相似。所以必须做时频变换。3.1 从 FFT 到短时傅里叶变换频谱要怎样切成时间片对每一帧做 FFT得到这一帧的频谱把所有帧的频谱按时间顺序堆叠成一个二维数组这个二维数组就是短时傅里叶变换STFT的结果。横轴是时间帧序号纵轴是频率颜色深浅代表能量大小。你在很多语音论文里看到的“语谱图”就是这个东西的可视化。STFT 的数学形式不复杂。对第 t 帧信号 x_t(n)加窗后做 N 点 FFT得到 X_t(k)其中 k 对应第 k 个频率点。如果用 512 点 FFT采样率 16kHz那频率分辨率就是 16000/51231.25Hz每个频率点间隔 31.25Hz。也可以用 1024 点 FFT频率分辨率提升到 15.6Hz但每一帧要补零到 1024 点计算量翻倍。实际工程里FFT 点数、帧长、补零策略经常让人晕头转向。我的建议是不用太纠结直接按标准做法来帧长 400 点FFT 4096 点不足部分补零。虽然帧长只有 400 点但 FFT 点数大了之后频谱更平滑后续梅尔滤波的效果更好。这个“补零让频谱更顺滑”的经验是很多教程里不会写的。3.2 梅尔刻度与对数压缩人耳其实不是线性度量声音STFT 出来的线性频谱有上千个频点而且大部分是人耳不敏感的。人耳对频率的感知不是线性的而是对低频敏感、对高频迟钝。100Hz 到 200Hz 的变化我们听得非常清楚但 5000Hz 到 5100Hz 的变化几乎感觉不到。梅尔刻度就是模拟人耳这种非线性感知的标度。把线性频率轴映射到梅尔刻度方法是用一组三角形滤波器。低频区滤波器排列密集高频区排列稀疏每个滤波器对频谱做加权求和得到该频段的能量。通常取 40 个或者 80 个梅尔滤波器这样一帧特征就从几百上千维降到了 40 或 80 维。接着还要做对数压缩。人耳对响度的感知也是对数的声音从 0.1 到 1 的响度变化和从 10 到 100 的响度变化主观感受几乎一样。取对数之后小能量区域被放大大能量被压缩特征分布更均匀模型更容易学习。这里有个细节不能直接对能量取 log因为能量可能为零log(0) 会变成负无穷。通常先加一个极小值比如 1e-10或者用log(max(x, epsilon))。PyTorch 里的torchaudio.transforms.MelSpectrogram已经在内部做了 log 处理但不同版本的行为略有差异用之前最好确认一下。3.3 归一化与细节保留梅尔对数谱得到之后还有一个常见的操作均值归一化。对不同句子的特征做均值方差归一化可以消除不同人发声响度、距离麦克风远近带来的全局差异。我遇到过一个真实场景两段录音一段是贴近麦克风录的一段是隔了半米录的前者的能量整体比后者高 20dB。如果不做归一化模型很可能会把“响度”当成一个区分特征导致识别率下降。做了均值归一化之后这两段录音的特征分布基本一致。但归一化也不能太过。有些可视化工具会把特征直接缩放到 0-1这会丢失动态范围信息。正确做法是先算整个数据集的均值方差再用训练集的均值方差去归一化验证集和测试集。这个“用训练集统计量”的细节和图像任务里的标准化逻辑完全一样但很多人处理音频时总是随手对每个样本单独归一化这就在训练和推理之间制造了分布偏移。从波形到梅尔特征这一步完成之后音频已经从“一维波形”变成了“二维时频图”。你可以把它理解为波形是声音的原始像素梅尔特征是声音的关键视觉特征。但到这里还只是“特征”不是“Token”。4. Token 与软 Token连续向量为什么成了主流现在到了最核心的问题特征图怎么变成 Token这里必须先讲清楚两个概念硬 Token 和软 Token。它们虽然都叫 Token但背后的设计哲学完全不同。4.1 先有硬 TokenVQ 带来的信息瓶颈早期的音频 Token 化走的是“硬离散”路线。思路是把梅尔特征序列或者编码器的输出送入一个矢量量化器VQ把每个连续的帧向量映射到码本中最近的离散编号。比如码本有 1024 个向量那每一帧的 Token 就是 0 到 1023 之间的一个整数。这种做法的优点是Token 序列可以直接套用 NLP 里的 BERT 预训练范式用掩码预测来做自监督学习解码的时候也能像 TTS 那样把离散 Token 序列映射回语音。SoundStream、EnCodec 这类神经音频编解码器用的就是这种方法。硬 Token 的关键问题是信息瓶颈。量化过程是一个有损操作每个向量只能从 1024 个码本向量里挑一个最接近的细节全被磨平了。尤其是打击乐、呼吸声、环境噪声这些没有明显周期结构的成分VQ 很难用有限的码本覆盖。早期做音乐生成的时候我试过把一段架子鼓的录音做 VQ还原出来的声音“塑料味”特别重因为每个鼓点都被归到了相近的码本向量上瞬态细节全丢了。还有一个工程上的头疼问题码本崩塌。也就是训练过程中只有极少数码本向量被频繁使用大部分码本向量变成了“死向量”整个 VQ 表达能力断崖式下降。解决这个问题需要加各种辅助损失、EMA 更新、码本重置调试成本相当高。4.2 软 Token 是靠什么“软”的连续向量序列与编码器软 Token 的思路完全换了个方向不做离散量化直接把特征帧序列经过一个编码器输出一组连续向量。每个向量可以被看作一个“软”的 Token因为它在语义上等价于传统 Token——每个向量对应一个局部时间窗口的内容——但取值是连续的不像硬 Token 那样必须落在离散码本上。具体来说把梅尔特征按帧展开成序列每帧特征向量作为序列中的一个元素。这个序列输入到一个小型编码器通常是一个卷积下采样层加几层 Transformer输出的每个位置向量就是该帧对应的软 Token。这样操作之后“一段音频”就变成了“一串向量”长度等于帧数向量维度可以在 512 到 1024 之间。软 Token 最大的优势是信息损失少。它能保留 VQ 丢掉的那些细节因为没有任何量化误差。而且软 Token 的每个维度都是可学习的模型在训练过程中会自动决定哪些维度吸收哪些信息。这让它在跨模态对齐任务里特别好用比如语音到文本的对比学习两个模态都在连续向量空间里可以直接算相似度没有任何离散符号的硬对齐问题。另一个实际好处是软 Token 省掉了一大堆调码本的功夫。VQ 要调码本大小、码本维度、训练策略软 Token 只要把编码器丢进去一起端到端训练就行。4.3 硬软之争怎么选不纠结从当前的发展趋势看软 Token 在理解类任务里已经完全占据主导。语音理解、音频对齐、多模态问答这些场景几乎没有再用硬离散 Token 的必要。生成类任务里软 Token 也越来越常见因为用扩散模型或者自回归模型直接生成连续向量避免了音频质量受码本限制的问题。但硬 Token 也没有完全退出。它最大的价值是跟 NLP 生态无缝衔接现有的大语言模型都是吃离散 Token 的硬 Token 可以映射到词表空间直接用语言模型做生成。如果你需要让一个现成的文本大模型去处理音频输入又不方便改它的输入层硬 Token 是更省事的路径。软 Token 则需要改模型的输入嵌入层把连续向量接进注意力模块这部分工作不可跳过。我用一个表格来对比项目里做选型时可以直接参考对比维度硬 Token离散量化软 Token连续向量信息保留有损码本有限几乎无损细节完整表达粒度离散编号语义清晰连续向量语义连续可变训练难度需处理码本崩塌和辅助损失端到端训练无额外复杂机制与文本模型兼容好可映射词表需改造输入层典型场景神经音频编解码、传统声学模型多模态理解、跨模态对齐、生成模型最大风险高信息压缩导致细节丢失连续向量语义不够“可解释”这里顺带解释一个我在实际项目中反复碰到的困惑既然软 Token 这么好为什么早期音频模型不用原因很现实——软 Token 需要大规模数据端到端训练如果训练数据不够编码器学不到有效的语义表示连续向量就是一盘散沙而硬 Token 因为有码本约束小数据量下反而更容易学到相对稳定的离散表示。现在数据规模和算力都上来了软 Token 才真正成为主流。5. 动手实现从一段 WAV 到软 Token 的完整管道讲了这么多原理来一段能直接跑通的实现才能真正内化。下面我用 PyTorch 写一个从 WAV 到软 Token 的管道不做任何花哨的东西只求每一步都看得懂、说得清。5.1 工程环境与整体骨架我用到的核心库是 torch、torchaudio、numpy。音频读取用 torchaudio 的后端特征计算用手动实现的 STFT 和梅尔滤波不用现成 transform 一步到位——因为这样你能看清每一步在做什么。序列模型用一个简单的卷积下采样加一层 Transformer 编码器。以下是我的实现骨架import torch import torchaudio import numpy as np # 核心参数 SAMPLE_RATE 16000 FFT_SIZE 400 # 帧长 25ms HOP_SIZE 160 # 帧移 10ms N_MELS 80 # 梅尔滤波通道数 N_FFT 512 # FFT 点数大于帧长会补零 TOKEN_DIM 512 # 软 Token 的维度 def load_wav(path): # 读取并重采样到 16kHz waveform, sr torchaudio.load(path) if sr ! SAMPLE_RATE: waveform torchaudio.functional.resample(waveform, sr, SAMPLE_RATE) # 如果多声道就取平均 if waveform.size(0) 1: waveform torch.mean(waveform, dim0, keepdimTrue) return waveform这里要提一个容易踩的坑torchaudio 读取 WAV 后返回的数值范围是 [-1, 1] 的浮点但有些自定义采集代码读出来是 [-32768, 32767] 的整数。如果混用特征图的能量分布会差几个量级归一化后虽然能救回来一部分但动态范围信息会被压缩。建议在任何项目开始前先统一数据范围约定。5.2 分帧、加窗与 STFT 实现不用 torchaudio 的集成接口我手动实现 STFT 分帧过程def stft(waveform, fft_size400, hop_size160, n_fft512): waveform waveform.squeeze(0) # [T] num_frames 1 (waveform.size(-1) - fft_size) // hop_size # 分帧 frames [ waveform[i * hop_size : i * hop_size fft_size] for i in range(num_frames) ] frames torch.stack(frames) # [num_frames, fft_size] # 加汉宁窗 window torch.hann_window(fft_size) frames frames * window # 补零到 n_fft 大小再做 RFFT padded torch.nn.functional.pad(frames, (0, n_fft - fft_size)) spectrum torch.fft.rfft(padded, dim-1) # [num_frames, n_fft//2 1] return spectrum_stft 返回的是复数谱后续取幅度谱作为特征。这里需要说明 FFT 点数大于帧长的原因FFT 点数越大频域采样就越密梅尔滤波之前频谱更平滑、更稳定。实际使用中如果嫌弃计算量可以直接把帧长设成 512 点32ms帧移 160 点10ms这样就不用补零了。两种方案的差异不大但补零方案的调试可以用不同 FFT 点数而不用改帧长。5.3 梅尔滤波器组的构造与对数谱梅尔滤波器组的构造可以用 torchaudio 来生成也可以手动写。为了减少代码量这里使用 torchaudio 的滤波器组生成函数def log_mel_spectrogram(spectrum, sample_rate16000, n_mels80, n_fft512): # 幅度谱 mag torch.abs(spectrum) ** 2 # 功率谱 # 创建梅尔滤波器组 [n_mels, n_fft//2 1] mel_fb torchaudio.functional.melscale_fbanks( n_freqsn_fft // 2 1, f_min0.0, f_maxsample_rate / 2.0, n_melsn_mels, sample_ratesample_rate, normslaney, ) mel_spec torch.matmul(mag, mel_fb.T) # [num_frames, n_mels] mel_spec torch.clamp(mel_spec, min1e-10) log_mel torch.log(mel_spec) return log_mel有一点要注意Fbank 的 norm 参数不同输出量纲不同。slaney归一化会调整滤波器组的增益让每个梅尔通道的能量更接近实际感知响度如果不加 norm高频通道的原始能量会明显偏小。之前我把一个开源项目的特征跑出来发现频谱高频区域整体发暗排查了半天发现就是 norm 没设对。这种小问题肉眼很难看出来但模型效果会受到直接影响。5.4 帧级编码器把特征序列变成软 Token梅尔特征拿到之后形状是[num_frames, n_mels]。现在要做的是把它变成[num_frames, token_dim]的连续向量序列。我在这里用一个两层卷积加一层 Transformer Encoder 实现class AudioToSoftToken(torch.nn.Module): def __init__(self, n_mels80, token_dim512, num_heads8, num_layers2): super().__init__() # 先用卷积把梅尔特征升维并压缩时间步 self.conv_stack torch.nn.Sequential( torch.nn.Conv1d(n_mels, 256, kernel_size5, stride2, padding2), torch.nn.ReLU(), torch.nn.Conv1d(256, 512, kernel_size5, stride2, padding2), torch.nn.ReLU(), ) # 线性映射到 token_dim self.proj torch.nn.Linear(512, token_dim) # Transformer encoder self.encoder torch.nn.TransformerEncoder( torch.nn.TransformerEncoderLayer( d_modeltoken_dim, nheadnum_heads, dim_feedforward1024, batch_firstTrue, ), num_layersnum_layers, ) def forward(self, log_mel): # log_mel: [batch, frames, n_mels] - 转成卷积输入格式 x log_mel.transpose(1, 2) # [batch, n_mels, frames] x self.conv_stack(x) # [batch, token_dim, frames/4] x x.transpose(1, 2) # [batch, frames/4, token_dim] x self.proj(x) x self.encoder(x) # [batch, frames/4, token_dim] return x注意力细节输入的梅尔特征形状为[batch, frames, n_mels]经过 Conv1d 时要把帧维度放到最后一维才能做时间维卷积。Conv1d 的 stride 为 2两层叠起来时间步会压缩到原来的四分之一。这意味着10 秒音频的 1000 帧经过这个编码器后变成 250 个软 Token。这个时间压缩是故意的——相邻帧之间高度冗余压缩之后序列长度更短Transformer 计算成本大幅下降同时语义单位更接近音素或者音节级别后面的多模态对齐会更稳定。到这里一段 WAV 已经变成了一个[batch, 250, 512]的连续向量序列。这 250 个 512 维向量就是这篇文章标题说的“软 Token”。6. 工程化踩坑笔记波形质量、参数对齐与调试代码跑通只是第一步真正决定项目成败的是工程细节。我把这段时间实验里踩过的坑和验证过有效的调试方法整理出来按严重程度排序。6.1 源头波形坏了后面全白干做音频模型的人最常犯的错误是把精力全花在模型结构上对输入波形质量不管不顾。我接手的一个项目中采集设备的前置放大电路有直流偏置ADC 出来的波形整体上移了 0.3V 左右特征图里所有帧的能量都偏高模型怎么调都学不进去。后来把原始波形打印出来发现波形根本没居中在零刻度线上。处理办法是加一个直流滤波在分帧之前对整段波形减去全局均值或者用一阶高通滤波器比如截止频率 60Hz把直流偏移和次声波噪声干掉。代码很简单# 消除直流偏置 waveform waveform - torch.mean(waveform, dim-1, keepdimTrue)但要注意这种全局减均值对长音频不一定合适因为一段录音里不同时间段的直流漂移可能不同。更好的做法是逐帧减去每帧的均值或者用高通滤波。我后来直接用了一个系数为 0.97 的一阶高通滤波器效果比全局减均值更稳。另一个高频问题就是削波。如果你看到波形的正负峰值都被“削平”了说明前置放大器增益过高。这没法靠代码修复因为削掉的顶部信息已经永久丢失了。遇到这种数据最靠谱的做法是重新采集。如果数据已经存在没法重采可以考虑克制的做法把削波样本直接扔掉不参与训练免得模型学到平顶波形和正常波形之间的伪相关。6.2 参数选择采样率、帧长、FFT 点数的匹配原则我在实践中总结的起步参数如下表基本覆盖大多数语音和音频理解场景任务类型采样率帧长帧移梅尔通道数FFT 点数语音识别/语音理解16kHz25ms / 400点10ms / 160点80512 或 1024音乐理解/音乐生成22.05kHz 或 44.1kHz50ms / 约1102点25ms / 约551点1282048环境音分类16kHz30ms / 480点15ms / 240点641024低功耗嵌入式实时音频8kHz25ms / 200点10ms / 80点40256这里要点明一个原则帧长和 FFT 点数不是互相独立的。帧长决定实际参与 FFT 的信号长度FFT 点数决定频谱平滑度。如果 FFT 点数远大于帧长大量的补零会引入频域插值让频谱看起来平滑但不会增加真实频率分辨率。所以我一般建议先按任务定帧长再选一个比帧长大一些的 FFT 点数通常是帧长的 1.5 到 2 倍。倍数太高纯属浪费算力。嵌入式的读者可能要问了8kHz 采样率的设备帧长 200 个点FFT 256 点够用吗够用。8kHz 采样率对应奈奎斯特频率 4kHz语音的有效信息基本都在这个范围内。FFT 256 点的频率分辨率是 8000/25631.25Hz跟 16kHz/512 点一样。分辨率没有下降只是覆盖频带减半。省下来的采样率和 FFT 算力对 MCU 来说非常宝贵。另外要特别提醒不要在嵌入式设备里直接跑完整的梅尔特征加 Transformer 软 Token。这个算力需求对一般单片机来说不现实。真要做嵌入式端的音频 Token 化一般分两步走设备端只做轻量级的端点检测VAD和波形质量判断把信号切段后上传软 Token 提取放到服务器或者边缘盒子上的 GPU 完成。这种做法在工程上是最稳妥的也方便后续升级模型。6.3 调试软 Token 的方式除了听声音还能看向量软 Token 的特征可视化是确认模型有没有学到有效语义的关键。我的调试流程里有一个固定动作取一段测试音频提取软 Token 序列用 PCA 降到二维或三维空间再画一张随时间变化的轨迹图。如果 Token 轨迹平滑稳定说明编码器已经学到了连续的语义变化如果轨迹剧烈跳动说明特征不稳定需要检查输入数据或者降低学习率。另一个有效的调试手段是看注意力权重热力图。把一段 5 秒语音的软 Token 序列输入到下游 Transformer打印 attention map你会发现有些 Token 会稳定关注到相邻的若干个 Token形成明显的分块结构。这种分块往往对应语义边界。如果注意力图完全杂乱无章通常意味着 Token 序列还带有大量噪声模型没有形成有效的局部依赖关系。还有一个小技巧做跨模态对齐的时候把音频软 Token 和文本 Token 一起输入到同一个对比学习框架然后看相似度矩阵的热力图。如果对角线上有明显的亮块说明音频和文本的对齐关系已经建立如果亮块歪歪扭扭说明时间偏移或者切分粒度不匹配就需要调整卷积下采样的倍数或者帧移大小。顺带回答一个经常被问的问题软 Token 需不需要固定长度训练时最好固定因为 Transformer 的位置编码通常预设了最大长度。推理时可以通过滑动窗口的方式支持长音频把长音频切成若干个带重叠的段每段提取软 Token 后再拼接。重叠部分后处理时可以做平均或者取置信度更高的一侧具体要看下游任务要求。这个方案我在实际项目里验证过10 分钟长音频切成 30 秒一段重叠 2 秒最终拼接结果没有明显的接缝问题。6.4 调试波形常用的几个利器做音频项目离不开波形可视化我把实际项目中用过、确实好用的方法列一下非广子纯粹是从排查效率出发。第一类是在嵌入式采集阶段用的常见嵌入式开发环境里都自带波形显示功能有些支持从目标板实时读 ADC 采样并绘制波形。调试时我习惯先把正弦波灌进麦克风输入端看采集回来的波形是否是干净的正弦。如果波形变形、台阶状、顶部削平基本可以断定是模拟前端的问题不用再往后面查。第二步才是录一段真实语音观察波形包络是否自然、是否有 DC 偏置。这一步看似简单但能省掉后续大量的玄学排查。第二类是仿真阶段做 FPGA 或者芯片验证的同学经常需要抓内部信号的时序。仿真波形窗口里如果信号显示为红色或者类似异常高亮状态通常不是“这个信号没接好”而是仿真库里的信号没有初始化或者存在多驱动冲突。处理办法是给信号赋初值、检查多驱动、确认复位时序。这些波形工具虽然针对数字时序设计但我在做音频接口的时序验证时也经常用原理是相通的通过波形观察把“看起来不对”变成“具体是哪一段信号不对”排查效率完全是两个量级。第三类是总线调试阶段I2C、SPI 这类低速总线上如果看到时钟线或数据线上的信号边沿变缓出现明显的“台阶”现象大概率是上拉电阻阻值过大总线电容太大导致边沿充电时间变长。这时候要先解决硬件斜率问题而不是加软件延时或者重写驱动层。很多同学遇到 I2C 读写不稳定第一反应是去改代码加延时其实用示波器看一眼波形就知道是电平翻转不干净。这种习惯放到音频采集上同样适用波形边缘不干净数字化的结果就会多出很多高频噪声。这些工具的使用逻辑都有一个共性波形的可视化不只是一个“好看”的功能而是用于区分“问题出在物理层、时序层还是算法层”。6.5 一个完整的验证实验软 Token 到底保留了哪些信息最后分享一个我自己做的验证实验帮大家直观感受软 Token 和硬 Token 的信息差异。我取了一段 10 秒的语音分别用两类方法处理一类是传统的 VQ 方式码本 1024维度 512另一类是我上面写的软 Token 编码器。然后做两件事第一把两类 Token 序列分别通过一个小型解码器还原成波形听感受还原效果第二把两类 Token 序列分别投影到二维空间看不同发音之间距离的关系。还原实验的结果很能说明问题硬 Token 还原的语音能听清内容但明显有“颗粒感”像是加了轻微降噪的音质软 Token 还原的语音有更多呼吸声、唇齿摩擦的细节听感更自然。投影实验里软 Token 中相近发音的向量距离更近远音发音的向量距离更远语义拓扑关系比硬 Token 更清晰。这说明软 Token 在保留“发音内容”之外还保留了大量副语言信息包括说话人的音色特征、情绪微变化、环境空间感。对理解类任务来说这是优势对以“只关注文本内容”的任务来说也可能是冗余。所以选型时要想清楚你到底需要模型理解什么内容。如果你只是要做关键词唤醒硬 Token 的低维信息反而更抗噪如果你要做一个理解语气和语境的多模态助手软 Token 的丰富信息就是不可替代的。我自己的体会是软 Token 不是对硬 Token 的简单“升级”而是换了一种表示哲学硬 Token 追求把音频压缩成“语言里的词”软 Token 则把音频转成“可供模型充分感知的连续状态”。这两种哲学对应不同的目标谈不上谁更先进。你在设计系统时可以先用我在第五节给的管道跑一版软 Token再用 VQ 替换做一版硬 Token两边在主任务指标和调试成本上的差距会给你最直观的选依据。最后再补一个小细节无论硬 Token 还是软 Token随机种子都要固定。我之前复现一个音频多模态项目怎么都跟论文指标对不上最后发现是编码器初始化没有固定种子导致软 Token 空间每次训练都换一个方向。固定随机种子之后指标就稳了。这个坑看似不起眼却在多模态项目里特别容易忽略。 
长河君 · 2026/10/26 4:24:06 · 阅读 1.2k 音频波形如何变成软Token：从声波到连续向量的完整链路
音频输入这件事放到今天的大模型体系里已经远不止“录一段声音”那么简单。我们在多模态项目里经常听到“语音变成 Token”“音频 Token 化”但很多刚入行的同学对“波形到底是怎么变成 Token 的”仍然是一头雾水波形明明是一条连续的、每秒上万个采样点的曲线模型里看到的却是一个个离散符号或者向量这中间到底经历了什么尤其最近“软 Token”这个概念被越来越多地提到它跟传统的硬离散 Token 有什么区别又是怎么从音频波形里得到的我前阵子正好做了一个音频多模态输入的原型从麦克风采集、ADC 采样、分帧、梅尔特征一直到把特征序列送进一个小编码器得到软 Token整条链路亲手走了一遍。这篇文章就把这条链路从头拆到尾重点落在“波形如何变成软 Token”这个核心问题上。如果你在做语音识别、音频理解、多模态大模型或者只是想搞清楚音频预处理和 Token 化的关系这篇文章会给你一个能直接落地的完整认知和可复现代码。1. 先把波形这件事说清楚从声压到数字序列很多做模型的同学一上来就跳进 Transformer 和 Token 的细节反而忽略了最前面的“波形”到底是什么。实际上波形变 Token 的第一步是要把物理世界里的声波变成计算机能处理的数字序列。这一步搞不懂后面再怎么调模型都是空中楼阁。1.1 声波和话筒之间发生了什么声音的本质是空气的疏密变化。说话的时候声带振动带动空气分子形成疏密交替的压力波这个波传到话筒振膜上振膜跟着前后振动。话筒的本质是一个换能器把声压变化转化成电压变化这个电压信号就是模拟的“音频波形”。你在示波器上看到的是一条连续曲线横轴是时间纵轴是电压。这里有两个物理量决定了声音的特征一是振动的快慢也就是频率决定音高二是振动的幅度也就是电压峰值决定响度。一个正弦波 440Hz就是每秒振动 440 次我们听到的是一个标准的 A4 音。但实际语音和音乐远比正弦波复杂是由基频和无数谐波叠加出来的复杂波形这也是为什么波形曲线看起来特别“毛糙”。我自己调试嵌入式设备时最直观的感受是波形在模拟域里的质量问题直接决定了后面数字化之后的信息损失。比如麦克风前置放大器有直流偏置采集到的波形整体抬升了一个电压平台又比如增益拉太高波形顶部被电源电压削平这就是“削波失真”。这类问题在模拟域用示波器一眼就能看到但一旦进了 ADC 变成数字序列就变成“数据看起来很怪但说不清为什么”的玄学问题。1.2 ADC 采样与量化连续变成离散的第一道关模拟波形要进计算机必须经过模数转换ADCADC 做两件事一个是采样一个是量化。采样是按固定时间间隔去“拍照”每秒钟拍的张数就是采样率。音频领域最常见的是 16kHz、44.1kHz、48kHz。根据奈奎斯特采样定理采样率至少要是信号最高频率的两倍才能无失真还原。人耳听觉上限大概是 20kHz所以 CD 音质取 44.1kHz留了足够余量语音任务为了省算力通常只取 16kHz因为语音的有效能量大多集中在 4kHz 以下。量化是把每个采样点的电压值归到有限个等级上。用 16bit 表示就是 65536 个等级用 32bit 浮点表示等级就更多了。量化会带来量化噪声比特数越少噪声越大。这也是为什么嵌入式设备里用 8bit ADC 采集语音听起来“沙沙的”而 16bit 的听感就干净很多。ADC 出来之后波形就变成了一串整数序列这就是 PCM 数据。你可能见过 .wav 文件里的数据段其实就是按固定采样率排列的这些整数。从这一刻起音频在计算机里不再是“波形”而是一个一维数组。数组的长度等于采样率乘以时长比如 16kHz 采 10 秒钟就是 160000 个采样点。这里顺便说一句我看很多搞嵌入式的同学会在调试工具里的波形视图上看 ADC 采集值比如一边给板子灌正弦波一边看采样回来的点是不是正弦形状。这个习惯很好能快速发现接线和量程问题。做音频预处理的时候也建议先用这类可视化手段把原始波形看一眼再做后续加窗、特征提取。很多模型效果差不是模型不行而是波形在源头就已经是坏的。1.3 数字波形和“波形更新率”一个容易被忽视的工程细节做音频项目时很多人会混淆“采样率”和“波形更新率”。采样率是 ADC 每秒钟采多少个点波形更新率是显示界面或者处理管线每秒钟刷新多少个新数据块。你在调试工具里看到波形曲线“一顿一顿”地动不是采集出了问题而是显示缓冲区的刷新率比采样率低。这个认知在做实时音频处理时很重要。比如我用 16kHz 采样每 25ms 推送一次新数据块那每次推送就是 400 个采样点。如果处理流程没赶上这个节奏波形就会越积越多出现延迟和卡顿。我之前踩过一次坑特征提取放在主线程里FFT 算得太慢导致波形更新率跟不上采集速率结果整个 Pipeline 的 Token 生成时间越来越长还以为是模型变慢了。后来才定位到是特征提取阻塞了采集。处理这类问题的原则只有一个采集线程和处理线程分开处理跟不上就丢帧宁可丢也不能阻塞采集。2. 从波形到“帧”语音信号的基本操作单位拿到一长串 PCM 序列之后接下来面临的问题是模型不能把 160000 个点一次性全吞进去也没法直接理解“这个数组代表什么音”。语音信号是短时平稳的也就是说在很短时间内比如 20-30ms音频特征基本稳定但拉长到几百毫秒特征又明显变化。所以处理语音的基本单位不是“采样点”而是“帧”。2.1 为什么不能拿整段信号直接做分析如果对整段 10 秒钟的语音一次性做 FFT得到的是全段时间的频谱平均值也就是把“上午说话”和“下午说话”混在一起取平均完全没有时间分辨率。你说了一个词“早上好”它的声母、韵母、音调变化全都被抹掉了。语音识别和目标说话人区分都依赖时间上的变化信息所以必须切帧。切帧的思路是把波形切成一个个重叠的小段每一段叫一帧。帧长通常取 20-30ms帧移相邻两帧起始点之间的距离取 10ms。16kHz 采样率下25ms 就是 400 个采样点10ms 就是 160 个采样点。相邻帧之间有一半是重叠的这样能避免窗函数边缘把信号衰减掉也让特征序列更平滑。这里要解释一个常见误区帧移越小帧数越多时间分辨率越高但计算量也越大。语音识别系统里 10ms 帧移几乎是默认值因为 10ms 刚好对应音素切换的粒度但做音乐生成或者环境音分类可以放宽到 20ms 甚至 30ms因为音乐的音符持续事件更长不需要那么精细的时间切分。2.2 帧长、帧移与窗函数的取舍切帧不是简单地把数组切成块那样会在帧边界产生频谱泄漏。所谓频谱泄漏是指本来集中在某一个频率上的能量因为边界突变而“漏”到其他频率上导致 FFT 结果出现很多假峰。解决办法是加窗函数让每一帧两端的幅度逐渐衰减到零。常用的窗函数有汉宁窗和海明窗。汉宁窗旁瓣衰减更快频谱更干净海明窗主瓣更窄频率分辨率略高。实际做语音特征时用汉宁窗更多因为它能更好地抑制频谱泄漏。代码里通常用torch.hamming_window或者torch.hann_window一行就能搞定。我个人的习惯是做语音识别用 25ms 窗长、10ms 帧移、汉宁窗做音乐分析用 50ms 窗长、25ms 帧移因为音乐的低频成分更重要需要更长的窗来获得频率分辨率。具体参数没有绝对标准只有一个原则频率分辨率和时间分辨率的平衡。窗越长频率分辨率越高但时间分辨率越低窗越短则相反。做嵌入式音频的同学可能更熟悉 PWM 波形和响度控制不太接触窗函数。但本质是共通的PWM 波形看的是占空比和频率窗函数看的是幅度包络和频谱。你调一个打印机的走纸电机用 PWM 控制转速把 PWM 波形拿到逻辑分析仪上看占空比这个动作和音频里加窗看能量包络思维模型都是一样的从时域波形里提取出有意义的控制特征。3. 时域不够用就换到频域STFT 与梅尔特征怎么把波形变薄分帧之后每一帧还是一个长度几百的向量直接作为特征仍然有两个问题一是维度太高一帧 400 个点10 秒语音就是 1000 帧400000 个数值模型根本吃不消二是时域波形本身对声音内容的表达能力很差同样一个音高不同人说出来波形完全不同但频谱结构却高度相似。所以必须做时频变换。3.1 从 FFT 到短时傅里叶变换频谱要怎样切成时间片对每一帧做 FFT得到这一帧的频谱把所有帧的频谱按时间顺序堆叠成一个二维数组这个二维数组就是短时傅里叶变换STFT的结果。横轴是时间帧序号纵轴是频率颜色深浅代表能量大小。你在很多语音论文里看到的“语谱图”就是这个东西的可视化。STFT 的数学形式不复杂。对第 t 帧信号 x_t(n)加窗后做 N 点 FFT得到 X_t(k)其中 k 对应第 k 个频率点。如果用 512 点 FFT采样率 16kHz那频率分辨率就是 16000/51231.25Hz每个频率点间隔 31.25Hz。也可以用 1024 点 FFT频率分辨率提升到 15.6Hz但每一帧要补零到 1024 点计算量翻倍。实际工程里FFT 点数、帧长、补零策略经常让人晕头转向。我的建议是不用太纠结直接按标准做法来帧长 400 点FFT 4096 点不足部分补零。虽然帧长只有 400 点但 FFT 点数大了之后频谱更平滑后续梅尔滤波的效果更好。这个“补零让频谱更顺滑”的经验是很多教程里不会写的。3.2 梅尔刻度与对数压缩人耳其实不是线性度量声音STFT 出来的线性频谱有上千个频点而且大部分是人耳不敏感的。人耳对频率的感知不是线性的而是对低频敏感、对高频迟钝。100Hz 到 200Hz 的变化我们听得非常清楚但 5000Hz 到 5100Hz 的变化几乎感觉不到。梅尔刻度就是模拟人耳这种非线性感知的标度。把线性频率轴映射到梅尔刻度方法是用一组三角形滤波器。低频区滤波器排列密集高频区排列稀疏每个滤波器对频谱做加权求和得到该频段的能量。通常取 40 个或者 80 个梅尔滤波器这样一帧特征就从几百上千维降到了 40 或 80 维。接着还要做对数压缩。人耳对响度的感知也是对数的声音从 0.1 到 1 的响度变化和从 10 到 100 的响度变化主观感受几乎一样。取对数之后小能量区域被放大大能量被压缩特征分布更均匀模型更容易学习。这里有个细节不能直接对能量取 log因为能量可能为零log(0) 会变成负无穷。通常先加一个极小值比如 1e-10或者用log(max(x, epsilon))。PyTorch 里的torchaudio.transforms.MelSpectrogram已经在内部做了 log 处理但不同版本的行为略有差异用之前最好确认一下。3.3 归一化与细节保留梅尔对数谱得到之后还有一个常见的操作均值归一化。对不同句子的特征做均值方差归一化可以消除不同人发声响度、距离麦克风远近带来的全局差异。我遇到过一个真实场景两段录音一段是贴近麦克风录的一段是隔了半米录的前者的能量整体比后者高 20dB。如果不做归一化模型很可能会把“响度”当成一个区分特征导致识别率下降。做了均值归一化之后这两段录音的特征分布基本一致。但归一化也不能太过。有些可视化工具会把特征直接缩放到 0-1这会丢失动态范围信息。正确做法是先算整个数据集的均值方差再用训练集的均值方差去归一化验证集和测试集。这个“用训练集统计量”的细节和图像任务里的标准化逻辑完全一样但很多人处理音频时总是随手对每个样本单独归一化这就在训练和推理之间制造了分布偏移。从波形到梅尔特征这一步完成之后音频已经从“一维波形”变成了“二维时频图”。你可以把它理解为波形是声音的原始像素梅尔特征是声音的关键视觉特征。但到这里还只是“特征”不是“Token”。4. Token 与软 Token连续向量为什么成了主流现在到了最核心的问题特征图怎么变成 Token这里必须先讲清楚两个概念硬 Token 和软 Token。它们虽然都叫 Token但背后的设计哲学完全不同。4.1 先有硬 TokenVQ 带来的信息瓶颈早期的音频 Token 化走的是“硬离散”路线。思路是把梅尔特征序列或者编码器的输出送入一个矢量量化器VQ把每个连续的帧向量映射到码本中最近的离散编号。比如码本有 1024 个向量那每一帧的 Token 就是 0 到 1023 之间的一个整数。这种做法的优点是Token 序列可以直接套用 NLP 里的 BERT 预训练范式用掩码预测来做自监督学习解码的时候也能像 TTS 那样把离散 Token 序列映射回语音。SoundStream、EnCodec 这类神经音频编解码器用的就是这种方法。硬 Token 的关键问题是信息瓶颈。量化过程是一个有损操作每个向量只能从 1024 个码本向量里挑一个最接近的细节全被磨平了。尤其是打击乐、呼吸声、环境噪声这些没有明显周期结构的成分VQ 很难用有限的码本覆盖。早期做音乐生成的时候我试过把一段架子鼓的录音做 VQ还原出来的声音“塑料味”特别重因为每个鼓点都被归到了相近的码本向量上瞬态细节全丢了。还有一个工程上的头疼问题码本崩塌。也就是训练过程中只有极少数码本向量被频繁使用大部分码本向量变成了“死向量”整个 VQ 表达能力断崖式下降。解决这个问题需要加各种辅助损失、EMA 更新、码本重置调试成本相当高。4.2 软 Token 是靠什么“软”的连续向量序列与编码器软 Token 的思路完全换了个方向不做离散量化直接把特征帧序列经过一个编码器输出一组连续向量。每个向量可以被看作一个“软”的 Token因为它在语义上等价于传统 Token——每个向量对应一个局部时间窗口的内容——但取值是连续的不像硬 Token 那样必须落在离散码本上。具体来说把梅尔特征按帧展开成序列每帧特征向量作为序列中的一个元素。这个序列输入到一个小型编码器通常是一个卷积下采样层加几层 Transformer输出的每个位置向量就是该帧对应的软 Token。这样操作之后“一段音频”就变成了“一串向量”长度等于帧数向量维度可以在 512 到 1024 之间。软 Token 最大的优势是信息损失少。它能保留 VQ 丢掉的那些细节因为没有任何量化误差。而且软 Token 的每个维度都是可学习的模型在训练过程中会自动决定哪些维度吸收哪些信息。这让它在跨模态对齐任务里特别好用比如语音到文本的对比学习两个模态都在连续向量空间里可以直接算相似度没有任何离散符号的硬对齐问题。另一个实际好处是软 Token 省掉了一大堆调码本的功夫。VQ 要调码本大小、码本维度、训练策略软 Token 只要把编码器丢进去一起端到端训练就行。4.3 硬软之争怎么选不纠结从当前的发展趋势看软 Token 在理解类任务里已经完全占据主导。语音理解、音频对齐、多模态问答这些场景几乎没有再用硬离散 Token 的必要。生成类任务里软 Token 也越来越常见因为用扩散模型或者自回归模型直接生成连续向量避免了音频质量受码本限制的问题。但硬 Token 也没有完全退出。它最大的价值是跟 NLP 生态无缝衔接现有的大语言模型都是吃离散 Token 的硬 Token 可以映射到词表空间直接用语言模型做生成。如果你需要让一个现成的文本大模型去处理音频输入又不方便改它的输入层硬 Token 是更省事的路径。软 Token 则需要改模型的输入嵌入层把连续向量接进注意力模块这部分工作不可跳过。我用一个表格来对比项目里做选型时可以直接参考对比维度硬 Token离散量化软 Token连续向量信息保留有损码本有限几乎无损细节完整表达粒度离散编号语义清晰连续向量语义连续可变训练难度需处理码本崩塌和辅助损失端到端训练无额外复杂机制与文本模型兼容好可映射词表需改造输入层典型场景神经音频编解码、传统声学模型多模态理解、跨模态对齐、生成模型最大风险高信息压缩导致细节丢失连续向量语义不够“可解释”这里顺带解释一个我在实际项目中反复碰到的困惑既然软 Token 这么好为什么早期音频模型不用原因很现实——软 Token 需要大规模数据端到端训练如果训练数据不够编码器学不到有效的语义表示连续向量就是一盘散沙而硬 Token 因为有码本约束小数据量下反而更容易学到相对稳定的离散表示。现在数据规模和算力都上来了软 Token 才真正成为主流。5. 动手实现从一段 WAV 到软 Token 的完整管道讲了这么多原理来一段能直接跑通的实现才能真正内化。下面我用 PyTorch 写一个从 WAV 到软 Token 的管道不做任何花哨的东西只求每一步都看得懂、说得清。5.1 工程环境与整体骨架我用到的核心库是 torch、torchaudio、numpy。音频读取用 torchaudio 的后端特征计算用手动实现的 STFT 和梅尔滤波不用现成 transform 一步到位——因为这样你能看清每一步在做什么。序列模型用一个简单的卷积下采样加一层 Transformer 编码器。以下是我的实现骨架import torch import torchaudio import numpy as np # 核心参数 SAMPLE_RATE 16000 FFT_SIZE 400 # 帧长 25ms HOP_SIZE 160 # 帧移 10ms N_MELS 80 # 梅尔滤波通道数 N_FFT 512 # FFT 点数大于帧长会补零 TOKEN_DIM 512 # 软 Token 的维度 def load_wav(path): # 读取并重采样到 16kHz waveform, sr torchaudio.load(path) if sr ! SAMPLE_RATE: waveform torchaudio.functional.resample(waveform, sr, SAMPLE_RATE) # 如果多声道就取平均 if waveform.size(0) 1: waveform torch.mean(waveform, dim0, keepdimTrue) return waveform这里要提一个容易踩的坑torchaudio 读取 WAV 后返回的数值范围是 [-1, 1] 的浮点但有些自定义采集代码读出来是 [-32768, 32767] 的整数。如果混用特征图的能量分布会差几个量级归一化后虽然能救回来一部分但动态范围信息会被压缩。建议在任何项目开始前先统一数据范围约定。5.2 分帧、加窗与 STFT 实现不用 torchaudio 的集成接口我手动实现 STFT 分帧过程def stft(waveform, fft_size400, hop_size160, n_fft512): waveform waveform.squeeze(0) # [T] num_frames 1 (waveform.size(-1) - fft_size) // hop_size # 分帧 frames [ waveform[i * hop_size : i * hop_size fft_size] for i in range(num_frames) ] frames torch.stack(frames) # [num_frames, fft_size] # 加汉宁窗 window torch.hann_window(fft_size) frames frames * window # 补零到 n_fft 大小再做 RFFT padded torch.nn.functional.pad(frames, (0, n_fft - fft_size)) spectrum torch.fft.rfft(padded, dim-1) # [num_frames, n_fft//2 1] return spectrum_stft 返回的是复数谱后续取幅度谱作为特征。这里需要说明 FFT 点数大于帧长的原因FFT 点数越大频域采样就越密梅尔滤波之前频谱更平滑、更稳定。实际使用中如果嫌弃计算量可以直接把帧长设成 512 点32ms帧移 160 点10ms这样就不用补零了。两种方案的差异不大但补零方案的调试可以用不同 FFT 点数而不用改帧长。5.3 梅尔滤波器组的构造与对数谱梅尔滤波器组的构造可以用 torchaudio 来生成也可以手动写。为了减少代码量这里使用 torchaudio 的滤波器组生成函数def log_mel_spectrogram(spectrum, sample_rate16000, n_mels80, n_fft512): # 幅度谱 mag torch.abs(spectrum) ** 2 # 功率谱 # 创建梅尔滤波器组 [n_mels, n_fft//2 1] mel_fb torchaudio.functional.melscale_fbanks( n_freqsn_fft // 2 1, f_min0.0, f_maxsample_rate / 2.0, n_melsn_mels, sample_ratesample_rate, normslaney, ) mel_spec torch.matmul(mag, mel_fb.T) # [num_frames, n_mels] mel_spec torch.clamp(mel_spec, min1e-10) log_mel torch.log(mel_spec) return log_mel有一点要注意Fbank 的 norm 参数不同输出量纲不同。slaney归一化会调整滤波器组的增益让每个梅尔通道的能量更接近实际感知响度如果不加 norm高频通道的原始能量会明显偏小。之前我把一个开源项目的特征跑出来发现频谱高频区域整体发暗排查了半天发现就是 norm 没设对。这种小问题肉眼很难看出来但模型效果会受到直接影响。5.4 帧级编码器把特征序列变成软 Token梅尔特征拿到之后形状是[num_frames, n_mels]。现在要做的是把它变成[num_frames, token_dim]的连续向量序列。我在这里用一个两层卷积加一层 Transformer Encoder 实现class AudioToSoftToken(torch.nn.Module): def __init__(self, n_mels80, token_dim512, num_heads8, num_layers2): super().__init__() # 先用卷积把梅尔特征升维并压缩时间步 self.conv_stack torch.nn.Sequential( torch.nn.Conv1d(n_mels, 256, kernel_size5, stride2, padding2), torch.nn.ReLU(), torch.nn.Conv1d(256, 512, kernel_size5, stride2, padding2), torch.nn.ReLU(), ) # 线性映射到 token_dim self.proj torch.nn.Linear(512, token_dim) # Transformer encoder self.encoder torch.nn.TransformerEncoder( torch.nn.TransformerEncoderLayer( d_modeltoken_dim, nheadnum_heads, dim_feedforward1024, batch_firstTrue, ), num_layersnum_layers, ) def forward(self, log_mel): # log_mel: [batch, frames, n_mels] - 转成卷积输入格式 x log_mel.transpose(1, 2) # [batch, n_mels, frames] x self.conv_stack(x) # [batch, token_dim, frames/4] x x.transpose(1, 2) # [batch, frames/4, token_dim] x self.proj(x) x self.encoder(x) # [batch, frames/4, token_dim] return x注意力细节输入的梅尔特征形状为[batch, frames, n_mels]经过 Conv1d 时要把帧维度放到最后一维才能做时间维卷积。Conv1d 的 stride 为 2两层叠起来时间步会压缩到原来的四分之一。这意味着10 秒音频的 1000 帧经过这个编码器后变成 250 个软 Token。这个时间压缩是故意的——相邻帧之间高度冗余压缩之后序列长度更短Transformer 计算成本大幅下降同时语义单位更接近音素或者音节级别后面的多模态对齐会更稳定。到这里一段 WAV 已经变成了一个[batch, 250, 512]的连续向量序列。这 250 个 512 维向量就是这篇文章标题说的“软 Token”。6. 工程化踩坑笔记波形质量、参数对齐与调试代码跑通只是第一步真正决定项目成败的是工程细节。我把这段时间实验里踩过的坑和验证过有效的调试方法整理出来按严重程度排序。6.1 源头波形坏了后面全白干做音频模型的人最常犯的错误是把精力全花在模型结构上对输入波形质量不管不顾。我接手的一个项目中采集设备的前置放大电路有直流偏置ADC 出来的波形整体上移了 0.3V 左右特征图里所有帧的能量都偏高模型怎么调都学不进去。后来把原始波形打印出来发现波形根本没居中在零刻度线上。处理办法是加一个直流滤波在分帧之前对整段波形减去全局均值或者用一阶高通滤波器比如截止频率 60Hz把直流偏移和次声波噪声干掉。代码很简单# 消除直流偏置 waveform waveform - torch.mean(waveform, dim-1, keepdimTrue)但要注意这种全局减均值对长音频不一定合适因为一段录音里不同时间段的直流漂移可能不同。更好的做法是逐帧减去每帧的均值或者用高通滤波。我后来直接用了一个系数为 0.97 的一阶高通滤波器效果比全局减均值更稳。另一个高频问题就是削波。如果你看到波形的正负峰值都被“削平”了说明前置放大器增益过高。这没法靠代码修复因为削掉的顶部信息已经永久丢失了。遇到这种数据最靠谱的做法是重新采集。如果数据已经存在没法重采可以考虑克制的做法把削波样本直接扔掉不参与训练免得模型学到平顶波形和正常波形之间的伪相关。6.2 参数选择采样率、帧长、FFT 点数的匹配原则我在实践中总结的起步参数如下表基本覆盖大多数语音和音频理解场景任务类型采样率帧长帧移梅尔通道数FFT 点数语音识别/语音理解16kHz25ms / 400点10ms / 160点80512 或 1024音乐理解/音乐生成22.05kHz 或 44.1kHz50ms / 约1102点25ms / 约551点1282048环境音分类16kHz30ms / 480点15ms / 240点641024低功耗嵌入式实时音频8kHz25ms / 200点10ms / 80点40256这里要点明一个原则帧长和 FFT 点数不是互相独立的。帧长决定实际参与 FFT 的信号长度FFT 点数决定频谱平滑度。如果 FFT 点数远大于帧长大量的补零会引入频域插值让频谱看起来平滑但不会增加真实频率分辨率。所以我一般建议先按任务定帧长再选一个比帧长大一些的 FFT 点数通常是帧长的 1.5 到 2 倍。倍数太高纯属浪费算力。嵌入式的读者可能要问了8kHz 采样率的设备帧长 200 个点FFT 256 点够用吗够用。8kHz 采样率对应奈奎斯特频率 4kHz语音的有效信息基本都在这个范围内。FFT 256 点的频率分辨率是 8000/25631.25Hz跟 16kHz/512 点一样。分辨率没有下降只是覆盖频带减半。省下来的采样率和 FFT 算力对 MCU 来说非常宝贵。另外要特别提醒不要在嵌入式设备里直接跑完整的梅尔特征加 Transformer 软 Token。这个算力需求对一般单片机来说不现实。真要做嵌入式端的音频 Token 化一般分两步走设备端只做轻量级的端点检测VAD和波形质量判断把信号切段后上传软 Token 提取放到服务器或者边缘盒子上的 GPU 完成。这种做法在工程上是最稳妥的也方便后续升级模型。6.3 调试软 Token 的方式除了听声音还能看向量软 Token 的特征可视化是确认模型有没有学到有效语义的关键。我的调试流程里有一个固定动作取一段测试音频提取软 Token 序列用 PCA 降到二维或三维空间再画一张随时间变化的轨迹图。如果 Token 轨迹平滑稳定说明编码器已经学到了连续的语义变化如果轨迹剧烈跳动说明特征不稳定需要检查输入数据或者降低学习率。另一个有效的调试手段是看注意力权重热力图。把一段 5 秒语音的软 Token 序列输入到下游 Transformer打印 attention map你会发现有些 Token 会稳定关注到相邻的若干个 Token形成明显的分块结构。这种分块往往对应语义边界。如果注意力图完全杂乱无章通常意味着 Token 序列还带有大量噪声模型没有形成有效的局部依赖关系。还有一个小技巧做跨模态对齐的时候把音频软 Token 和文本 Token 一起输入到同一个对比学习框架然后看相似度矩阵的热力图。如果对角线上有明显的亮块说明音频和文本的对齐关系已经建立如果亮块歪歪扭扭说明时间偏移或者切分粒度不匹配就需要调整卷积下采样的倍数或者帧移大小。顺带回答一个经常被问的问题软 Token 需不需要固定长度训练时最好固定因为 Transformer 的位置编码通常预设了最大长度。推理时可以通过滑动窗口的方式支持长音频把长音频切成若干个带重叠的段每段提取软 Token 后再拼接。重叠部分后处理时可以做平均或者取置信度更高的一侧具体要看下游任务要求。这个方案我在实际项目里验证过10 分钟长音频切成 30 秒一段重叠 2 秒最终拼接结果没有明显的接缝问题。6.4 调试波形常用的几个利器做音频项目离不开波形可视化我把实际项目中用过、确实好用的方法列一下非广子纯粹是从排查效率出发。第一类是在嵌入式采集阶段用的常见嵌入式开发环境里都自带波形显示功能有些支持从目标板实时读 ADC 采样并绘制波形。调试时我习惯先把正弦波灌进麦克风输入端看采集回来的波形是否是干净的正弦。如果波形变形、台阶状、顶部削平基本可以断定是模拟前端的问题不用再往后面查。第二步才是录一段真实语音观察波形包络是否自然、是否有 DC 偏置。这一步看似简单但能省掉后续大量的玄学排查。第二类是仿真阶段做 FPGA 或者芯片验证的同学经常需要抓内部信号的时序。仿真波形窗口里如果信号显示为红色或者类似异常高亮状态通常不是“这个信号没接好”而是仿真库里的信号没有初始化或者存在多驱动冲突。处理办法是给信号赋初值、检查多驱动、确认复位时序。这些波形工具虽然针对数字时序设计但我在做音频接口的时序验证时也经常用原理是相通的通过波形观察把“看起来不对”变成“具体是哪一段信号不对”排查效率完全是两个量级。第三类是总线调试阶段I2C、SPI 这类低速总线上如果看到时钟线或数据线上的信号边沿变缓出现明显的“台阶”现象大概率是上拉电阻阻值过大总线电容太大导致边沿充电时间变长。这时候要先解决硬件斜率问题而不是加软件延时或者重写驱动层。很多同学遇到 I2C 读写不稳定第一反应是去改代码加延时其实用示波器看一眼波形就知道是电平翻转不干净。这种习惯放到音频采集上同样适用波形边缘不干净数字化的结果就会多出很多高频噪声。这些工具的使用逻辑都有一个共性波形的可视化不只是一个“好看”的功能而是用于区分“问题出在物理层、时序层还是算法层”。6.5 一个完整的验证实验软 Token 到底保留了哪些信息最后分享一个我自己做的验证实验帮大家直观感受软 Token 和硬 Token 的信息差异。我取了一段 10 秒的语音分别用两类方法处理一类是传统的 VQ 方式码本 1024维度 512另一类是我上面写的软 Token 编码器。然后做两件事第一把两类 Token 序列分别通过一个小型解码器还原成波形听感受还原效果第二把两类 Token 序列分别投影到二维空间看不同发音之间距离的关系。还原实验的结果很能说明问题硬 Token 还原的语音能听清内容但明显有“颗粒感”像是加了轻微降噪的音质软 Token 还原的语音有更多呼吸声、唇齿摩擦的细节听感更自然。投影实验里软 Token 中相近发音的向量距离更近远音发音的向量距离更远语义拓扑关系比硬 Token 更清晰。这说明软 Token 在保留“发音内容”之外还保留了大量副语言信息包括说话人的音色特征、情绪微变化、环境空间感。对理解类任务来说这是优势对以“只关注文本内容”的任务来说也可能是冗余。所以选型时要想清楚你到底需要模型理解什么内容。如果你只是要做关键词唤醒硬 Token 的低维信息反而更抗噪如果你要做一个理解语气和语境的多模态助手软 Token 的丰富信息就是不可替代的。我自己的体会是软 Token 不是对硬 Token 的简单“升级”而是换了一种表示哲学硬 Token 追求把音频压缩成“语言里的词”软 Token 则把音频转成“可供模型充分感知的连续状态”。这两种哲学对应不同的目标谈不上谁更先进。你在设计系统时可以先用我在第五节给的管道跑一版软 Token再用 VQ 替换做一版硬 Token两边在主任务指标和调试成本上的差距会给你最直观的选依据。最后再补一个小细节无论硬 Token 还是软 Token随机种子都要固定。我之前复现一个音频多模态项目怎么都跟论文指标对不上最后发现是编码器初始化没有固定种子导致软 Token 空间每次训练都换一个方向。固定随机种子之后指标就稳了。这个坑看似不起眼却在多模态项目里特别容易忽略。